And remove the same thing from the client API code.
The command.c code has to deal with many specialized M_PROPERTY_SET_*
actions, and we bother with a subset only.
If a mpv_node wrapped a string, the behavior was different from calling
mpv_set_property() with MPV_FORMAT_STRING directly. Change this.
The original intention was to be strict about types if MPV_FORMAT_NODE
is used. But I think the result was less than ideal, and the same change
towards less strict behavior was made to mpv_set_option() ages ago.
Commit 57506b27 accidentally broke this. The status (including the
usually always active demuxer cache) should be shown only if the stream
cache is actually enabled.
Instead of having a separate for each, which also requires separate
additional caching in the demuxer. (The demuxer adds an indirection,
since STREAM_CTRLs are not thread-safe.)
Since this includes the cache speed, this should fix#3003.
This would get stuck in reconfiguring the filter chain forever, because
params was mutated ("params.rotate = 0;"). This was used as input for
vf_reconfig(), but the filter chain input must always be equivalent to
the decoder output, or filter chain reconfiguration will be triggered.
The line of code to reset the rotation is from a time when this used to
work differently.
Also remove the unnecessary try_filter() parameter.
This implements the JSON IPC protocol with named pipes, which are
probably the closest Windows equivalent to Unix domain sockets in terms
of functionality. Like with Unix sockets, this will allow mpv to listen
for IPC connections and handle multiple IPC clients at once. A few cross
platform libraries and frameworks (Qt, node.js) use named pipes for IPC
on Windows and Unix sockets on Linux and Unix, so hopefully this will
ease the creation of portable JSON IPC clients.
Unlike the Unix implementation, this doesn't share code with
--input-file, meaning --input-file on Windows won't understand JSON
commands (yet.) Sharing code and removing the separate implementation in
pipe-win32.c is definitely a possible future improvement.
Should reflect I/O speed.
This could go into the terminal status line. But I'm not sure how to put
it there, since it already uses too much space, so it's not there yet.
This changes behavior somewhat. The old behavior can be restored by
running "mp.use_suspend=true". It was originally introduced for the OSC,
but I can't reproduce whatever misbehavior I was seeing.
(See mp.suspend()/resume() for explanations what the suspend mechanism
does.)
This pause stuff is bothersome and is needed only for a few corner-
cases. This commit removes it from the demuxer public API and replaces
it with a demux_run_on_thread() function and refactors the code which
needed demux_pause(). The next commit will change the implementation.
Changing the byte stream position without cooperation of the demuxer
seems a bit insane, and is certainly useless. A user should do factor
seeks instead. For formats like ts, this will actually translate to byte
seeks, while treating the rest of the playback chain a bit more
gracefully. With this argument, remove write access to this property.
If someone really complains, proper byte seeks could be added as seek
mode (although I'm going to need a convincing argument for this).
Read access changes too, but in a more subtle way.
No need to have them everywhere. The only exception/annoyance is
MAX_OSD_PARTS, which is now basically duplicated (and at runtime
initialization is checked with an assert()).
Until now, there was only 1 global ASS overlay that could be set by all
scripts. This was often perceived as bug when multiple scripts tried to
set their own ASS overlay.
This was kind of hard to solve because the script could set its own ASS
PlayResX/Y, which makes it impossible to share a single ASS_Renderer for
multiple scripts. The OSC unfortunately makes use of this feature (and
unfortunately can't be fixed because it's a POS), so we're stuck with
this complication.
Implement the worst-case solution and fix this by creating separate ASS
track and renderer objects for each script that wants to set an ASS
overlay.
The z-order is decided by the order the scripts set their text first.
This is essentially random, unless you do it at script init, and you
pass scripts in a specific order. Script initialization is currently
serialized (as a feature), so the first loaded script gets lowest
Z-order.
The Lua script API interestingly remains the same. (And also will remain
undocumented, unsupported, and potentially volatile.)
Do not scale OSD mouse input to the ASS OSD script resolution. The
original idea of this mechanism was that the user doesn't have to care
about the actual resolution of anything, and can just use the OSD
resolution consistently. But this made things worse.
Remove the implicit scaling, and always use the screen resolution.
(Except with --vo=xv, where additional scaling is forced upon
everything.)
Drop get_osd_resolution(). There is no replacement. Rename
get_screen_size() and get_screen_margins() to use "osd" instead of
"screen". For anything but --vo=xv these are equivalent, but with
--vo=xv the OSD resolution has additional implicit scaling.
Add code to osc.lua which emulates the old behavior.
Note that none of the changed functions were public API, so implicit
breakage of scripts which used it is just going to happen.
Subtitles can be preloaded, which means they're fully read and copied
into ASS_Track. This in turn is mainly for the sake of being able to do
subtitle seeking (when it comes down to it, subtitle seeking is the
cause for most trouble here).
Commit a714f8e92 broke preloaded subtitles which have events with
unknown duration, such as some MicroDVD samples. The event list gets
cleared on every seek, so the property of being preloaded obviously gets
lost.
Fix this by moving most of the preloading logic to dec_sub.c. If the
subtitle list gets cleared, they are not considered preloaded anymore,
and the logic for demuxed subtitles is used.
As another minor thing, preloadeding subtitles did neither disable the
demux stream, nor did it discard packets. Thus you could get queue
overflows in theory (harmless, but annoying). Fix this by explicitly
discarding packets in preloaded mode.
In summary, now the only difference between preloaded and normal
demuxing are:
1. a seek is issued, and all packets are read on start
2. during playback, discard the packets instead of feeding them to the
subtitle decoder
This is still petty annoying. It would be nice if maintaining the
subtitle index (and maybe a subtitle packet cache for instant subtitle
presentation when seeking back) could be maintained in the demuxer
instead. Half of all file formats with interleaved subtitles have
this anyway (mp4, mkv muxed with newer mkvmerge).
Commit 8d4a179c made subtitle decoders pick up fonts strictly from the
same source file (i.e. the same demuxer).
It breaks some fucked up use-case, and 2 people on this earth complained
about the change because of this. Add it back.
This copies all attached fonts on each subtitle init. I considered
converting attachments to use refcounting, but it'd probably be much
more complex.
Since it's slightly harder to get a list of active demuxers with
duplicate removed, the prev_demuxer variable serves as a hack to achieve
almost the same thing, except in weird corner cases. (In which fonts
could be added twice.)
Was only available via --vd=help and --ad=help (i.e. not at all via
client API). Not bothering with separating audio and video codecs, since
this list isn't all that useful anyway in general. If someone complains,
a type field could be added.
Export a number of container fields, which may or may not be useful in
some scenarios. They are explicitly marked as originating from the
demuxer, in order to make it explicit that they might be unreliable.
I'd actually like to remove all other cases where container information
is exported, but those numerous cases are going to be somewhat hard to
deprecate.
Also, not directly related, export the description of the currently
active decoder. (This has been requested before.)
Ever since a change in mplayer2 or so, relative seeks were translated to
absolute seeks before sending them to the demuxer in most cases. The
only exception in current mpv is DVD seeking.
Remove the SEEK_ABSOLUTE flag; it's not the implied default. SEEK_FACTOR
is kept, because it's sometimes slightly useful for seeking in things
like transport streams. (And maybe mkv files without duration set?)
DVD seeking is terrible because DVD and libdvdnav are terrible, but
mostly because libdvdnav is terrible. libdvdnav does not expose seeking
with seek tables. (Although I know xbmc/kodi use an undocumented API
that is not declared in the headers by dladdr()ing it - I think the
function is dvdnav_jump_to_sector_by_time().) With the current mpv
policy if not giving a shit about DVD, just revert our half-working seek
hacks and always use dvdnav_time_search(). Relative seeking might get
stuck sometimes; in this case --hr-seek=always is recommended.
Adds always-on mode by internally utilizing hidetimeout as negative and
forbidding the user to set negative values.
This removes script-message to enable/disable the osc, and instead introduces a
combined 'visibility' control with the values never/auto/always.
It's available via script_opts and script_message as 'osc-visibility'.
As message, it also supports a 'cycle' value.
The del key is bound to cycling the visibility modes.
There were few issues:
- When it's disabled and then enabled, it was displaying the osc briefly and
then autohide right away. Don't do that.
- When it's enabled and then disabled, it was not removing the osc from screen
if called while the osc is visible (because tick() is responsible for the hide
but it doesn't render() the empty osc when the osc is disabled).
- Due to delayed/async unbinding of mouse events it was possible to show_osc()
after it got disabled e.g. from mouse_move. Prevent this.
_Of course_ the previous commit broke --force-window behavior (like it
does every single time I touch it).
vo_has_frame() gets cleared after a seek, so e.g. stopping playback of a
file and going to the next by keeping the seek key down will enter a
short moment without video at the end of the first file, which will set
the stalled_video variable to true. Prevent it by using the indication
whether the window was properly created (which is probably exactly what
we want here).
This function is also responsible for destroying the window when needed,
and obviously we should never do that while video is active. (This is
the actual bug, although the other change in this commit already hides
the common breakage it caused.)
Some oddity that is not needed anymore. The only thing which still
referenced them was avoiding loading external files more than once,
which is now prevented by checking the list of tracks instead.
wm4
Martin Herkt
James Ross-Gowan
▟ ▖▟ ▖
Avi Halachmi (:avih)