Remove the use of mp_ring and use a simple array and a bunch of
variables instead. This is way less awkwad.
The change in reserve_reply fixes incorrect tracking of free events.
Now they can be paused and resumed.
Since pausing and disabling the timer is essentially the same underlying
operation, we also just provide one method for it.
mp.cancel_timer probably still works, but I'm considering this
deprecated, and it's removed from the manpage. (We didn't have a release
with this function yet, so no formal deprecation.)
Change the type of the property from a string list (alternating
key/value entries) to a map. Using the client API, this will return
MPV_FORMAT_NODE_MAP, while Lua mp.get_property_native returns a
dictionary-like table.
We've just checked whether a sub-path started with "name/", but that
changes behavior whether the property name has a trailing '/' or not.
Using a helper function to split of path components avoids this problem.
This played the file at a wrong sample rate if the rate was out of
certain bounds.
A comment says this was for the sake of libaf/af_resample.c. This
resampler has been long removed. Our current resampler
(libav/swresample) checks supported sample rates on reconfiguration, and
will error out if a sample rate is not supported. And I think that is
the correct behavior.
This commit introduces new stream protocols: bdnav(and others).
bdnav stream shares lots of codes with original bluray stream, so
it's not separated in different source file.
Major difference from bluray is that bdnav does not support longest
title because there is no way to query that information.
bdnav://menu and bdnav://first correspond to top menu title and
first play title respectively, though they often point same title.
Also, binary position based seeking has been removed, because it
didn't have no point.
Reduce most dependencies on struct mp_csp_details, which was a bad first
attempt at dealing with colorspace stuff. Instead, consistently use
mp_image_params.
Code which retrieves colorspace matrices from csputils.c still uses this
type, though.
It's possible that MPContext has a chapter list, but the demuxer
doesn't. In this case, accesing the chapter-metadata property would
lead to invalid accesses.
(This fixes the out of bound access, but in theory, the returned data
can still be incorrect, since MPContext chapters don't need to map
directly to demuxer chapters.)
This was usually handled at the end of the switch statement, so if
something returns from the function before that, the event has to be
freed explicitly.
Previous implementation updated video resolution when highlight
event was given. However, this may not work if highlight event
is given before video size is queried.
This commit adds checking routine into rendering function, too.
dvdnav.c did not handle event in regular sequence. Usually this
does not make any trouble except around MP_NAV_EVENT_RESET_ALL.
Those events should be handled in regular sequence. If they're
mixed, it can make wrong result.
For instance, MP_NAV_EVENT_HIGHLIGHT right after
MP_NAV_EVENT_RESET_ALL should not be ignored but it might be
because MP_NAV_EVENT_RESET_ALL makes the demuxer reloaded and osd
hidden.
And consistently use MP_NOPTS_VALUE as error value for the users of this
function. This is better than using -1, especially because negative
values can be valid timestamps.
Instead of comparing the current chapter every time, set the playback
end timestamp to the chapter end. Likewise, don't execute an extra seek
for the start chapter.
Maybe we could also use the timeline facility to restrict playback to
the given chapter range, but this would be strange when using
--chapter=N to start playback at a given chapter. Then you couldn't seek
back, which is possibly not what the user wants.
Instead, always use the mpctx->chapters array. Before this commit, this
array was used only for ordered chapters and such, but now it's always
populated if there are chapters.
Stream-level chapters (like DVD etc.) did potentially not have
timestamps for each chapter, so STREAM_CTRL_SEEK_TO_CHAPTER and
STREAM_CTRL_GET_CURRENT_CHAPTER were needed to navigate chapters. We've
switched everything to use timestamps and that seems to work, so we can
simplify the code and remove this old mechanism.
This commit makes 'disc-title' property writable using
STREAM_CTRL_SET_CURRENT_TITLE. This commit also contains
implementation of STREAM_CTRL_SET_CURRENT_TITLE for stream_bluray.
Currently, 'disc-title' is writable only for stream_dvdnav and
stream_bluray and stream_dvd is not supported.
"enable-osc" will make the OSC appear at any time (although it'll
quickly disappear again if the mouse is not inside the OSC). "disable-
osc" will make it disappear permanently.
Also, if the OSC is visible, force remap the DEL key to make the OSC
disappear.
Change script_message to broadcast the message to all clients. Add a new
script_message_to command, which does what the old script_message
command did.
This is intended as simplification, although it might lead to chaos too.
Instead of parsing the ASS file in demux_libass.c and trying to pass the
ASS_Track to the subtitle renderer, just read all file data in
demux_libass.c, and let the subtitle renderer pass the file contents to
ass_process_codec_private(). (This happens to parse full files too.)
Makes the code simpler, though it also relies harder on the (messy)
probe logic in demux_libass.c.
They're strictly DVD-only, so it's better to mark them as such. This
also documentes the "title" (now renamed to "dvd-title") property.
This also avoids collision with the --title option. (Technically, there
was no problem. But it might be confusing for users, since we have a
policy of naming properties and options the same if they refer to the
same underlying functionality.)
This commit adds new property 'title' which indicates current
playing title of disc. This property is useful when using a stream
whose title can be changed during playback, e.g., dvdnav.
Xlib.h (included from x11_common.h) defines a macro 'Status' as 'int'.
This messed up a bunch of definitions in windows.h and broke the build
in Cygwin. Including windows.h first seems to solve the problem.
This commit also removes the definition of an unused flag.
This reverts commit 75dd3ec210.
This broke seeking with ordered chapters in some situations. While
the reverted commit was perfectly fine for playback of normal files,
it overlooked that in the ordered chapters case switching segments
actually reinitialized the audio chain completely, including the
decoder. And decoders still read packets on initialization. We can
restore the original commit as soon as decoders stop doing this.
This obviously doesn't work. It wasn't much of a problem in the past
because most passthrough formats use 2 channels, which is also the
default for downmix.
This is probably "safer". Without it, we will play 1 sample, because the
logic was written in a way to decode 1 sample if audio is paused. 1
sample usually will initialize the audio PTS, but not play any real
audio. Also see previous commit.
In ancient times, this actually used 1 byte (instead of 1 sample), so
clearly no sample was written, unless the audio was 8-bit mono.
Remove the ao_buffer_playable_samples field. This contained the number
of samples that fill_audio_out_buffers() wanted to write to the AO (i.e.
this data was supposed to be played at some point), but ao_play()
rejected it due to partial fill.
This could happen with many AOs, notably those which align all written
data to an internal period size (often called "outburst" in the AO
code), and the accepted number of samples is rounded down to period
boundaries. The left-over samples at the end were still kept in
mpctx->ao_buffer, and had to be played later.
The reason ao_buffer_playable_samples had to exist was to make sure that
at EOF, the correct number of left-over samples was played (and not
possibly other data in the buffer that had to be sliced off due to
endpts in fill_audio_out_buffers()). (You'd think you could just slice
the entire buffer, but I suspect this wasn't done because the end time
could actually change due to A/V sync changes. Maybe that was the reason
it's so complicated.)
Some commits ago, ao.c gained internal buffering, and ao_play() will
never return partial writes - as long as you don't try to write more
samples than ao_get_space() reports. This is always the case. The only
exception is filling the audio buffers while paused. In this case, we
decode and play only 1 sample in order to initialize decoding (e.g. on
seeking). Actually playing this 1 sample is in fact a bug, but even of
the AO doesn't have period size alignment, you won't notice it. In
summary, this means we can safely remove the code.
Until now, this was always conflated with uninit. This was ugly, and
also many AOs emulated this manually (or just ignored it). Make draining
an explicit operation, so AOs which support it can provide it, and for
all others generic code will emulate it.
For ao_wasapi, we keep it simple and basically disable the internal
draining implementation (maybe it should be restored later).
Tested on Linux only.
We want to move the AO to its own thread. There's no technical reason
for making the ao struct opaque to do this. But it helps us sleep at
night, because we can control access to shared state better.
This field will be moved out of the ao struct. The encoding code was
basically using an invalid way of accessing this field.
Since the AO will be moved into its own thread too and will do its own
buffering, the AO and the playback core might not even agree which
sample a PTS timestamp belongs to. Add some extrapolation code to handle
this case.
For example, consider the case when audio initialization fails. Then the
audio track is deselected. Before this commit, this would have been
equivalent to the user disabling audio. This is bad when multiple files
are played at once (the next file would have audio disabled, even if it
works), or if playback resume is used (if e.g. audio output failed to
initialize, then audio would be disabled when resuming, even if the
system's audio driver was fixed).
The OSC used significant CPU time while the player was paused. It turned
out that the "tick" event sent during pause is the problem. The OSC
accesses the player core when receiving a tick event, which in turn will
cause the core to send another tick event, leading to infinite feedback.
Fix this by sending an idle tick only every 500ms. This is not very
proper, but the idea behind the tick event isn't very clean to begin
with (and the OSC should use timers instead).
The playloop usually waits in select(), using a timeout needed for
refilling audio and video buffers. This means the client API needs
a separate mechanism to interrupt the select() call. This mechanism
exists, but I forgot to use it. This commit fixes it.
If it works, this will make the client API react faster, epsecially
in audio-only mode. If video is enabled, the reaction time is capped
to 50ms (or somewhat faster if the framerate is >20 fps), because
the playloop stops reacting to anything in order to render and time
the next video frame. (This will be fixed later by moving the VO
to its own thread.)
luaL_loadstring(), which was used until now, uses the start of the Lua
code itself as chunk name. Since the chunk name shows up even with
runtime errors triggered by e.g. Lua code loaded from user scripts, this
looks a but ugly. Switch to luaL_loadbuffer(), which is almost the same
as luaL_loadstring(), but allows setting a chunk name.
Sending an asynchronous request and then calling mpv_destroy() would
crash the player when trying to send the reply to the removed client.
Fix this by waiting until all remaining replies have been sent.
The step argument for "add volume <step>" was ignored until now. Fix it.
There is one problem: by defualt, "add volume" should use the value set
with --volstep. This value is 3 by default. Since the default volue for
the step argument is always 1 (and we don't really want to make the
generic code more complicated by introducing custom step sizes), we
simply multiply the step argument with --volstep to keep it compatible.
The --volstep option should probably be just removed in the future.
The value range is 0-100, so fractional values don't make much sense.
But the underlying data type is probably float to avoid getting "stuck"
when doing small volume increments. So step this around and pretend it's
an integer just on display.
Lua doesn't distinguish between arrays and maps on the language level;
there are just tables. Use metatables to mark these tables with their
actual types. In particular, it allows distinguishing empty arrays from
empty tables.
Always map MPV_FORMAT_STRING to setting property value directly through
M_PROPERTY_SET_STRING, instead of trying to go through
M_PROPERTY_SET_NODE.
This treats a direct MPV_FORMAT_STRING query differently from a
MPV_FORMAT_STRING wrapped in a mpv_node. This was already the case in
mpv_get_property(). The reason for all this is that mpv_node is supposed
to be the exact type, while a direct MPV_FORMAT_STRING goes through all
possible conversions.
Not sure if these semantics are good.
1. Cannot set option after initialized: it seems that this bug has
existed since libmpv was introduced first. Maybe just a typo.
2. Crash when setting property with native format: mpv_set_property
just causes a crash when using a native format. I found an invalid
casting and fixed it.
3. Wrong error value for mpv_get_property: when an error occurred,
mpv_get_property always returns wrong format error because every
error for property except M_PROPERTY_NOT_IMPLEMENTED is just ignored.
Signed-off-by: wm4 <wm4@nowhere>
Closes pull request #593. Does not incldue the first fix, which was not
correct. The underlying bug will be fixed by a later commit.
Commit message extracted from pull request and slightly edited.
E.g. binding MOUSE_BTN0 always used the user defined binding. While it
is ok that the user can override mouse_move and mouse_leave (for
whatever reasons), we want to strictly override the bindings when input
is sent to the OSC itself.
Regression since 03624a1.
This lowers the number of data stored in the resume config a bit
further, because some properties can't be read at program start and when
e.g. the VO wasn't created yet.
Some fields still need to be read from a property (actually only
"volume-restore-data", a hack to save the full volume information). So
abuse the "options/" property, and make use of the fact that changing
things at runtime also changes the options.
This is approximate: we read each option value on program start
(before starting playback of a file), and when writing the resume
config, compare each value to the current state. This also means
when a value is changed and then changed back, it's not stored. In
particular, option values set in config files and on the command
line are considered the default.
This should help reducing the numbers of options overridden by the
resume config. If too much is overridden, it becomes an inconvenience,
because changes in config files will apparently have no effect when
resuming a file.
Also see github issue #574.
This created an essentially empty config file. This is not really
needed and probably causes more trouble than it solves (such as
littering the home directory with crap), so get rid of it.
Not sure about this... might redo.
At least this provides a case of a broadcasted event, which requires
per-event data allocation.
See github issue #576.
May or may not be useful in some ways.
We require a context parameter for this just to be sure, even if the
internal implementation currently doesn't.
That's one less mpv internal function for the Lua wrapper.
There are some complications because the client API distinguishes
between integers and floats, while Lua has only "numbers" (which are
usually floats). But I think this should work now.
This is only half-implemented: actually the option will first be
converted from mpv_node to its native type, then it's converted to a
string, and then back to its native type. This is because the option
API was made for strings and not anything else.
Other than being grossly inelegant, the only downside is probably with
string lists and key/value lists, which don't escape strings containing
syntax elements correctly.
This actually makes use of the client.h declarations and the mpv_node
mechanisms added some commits ago.
For now, using MPV_FORMAT_STRING will usually fallback to explicit
string conversion, but not in the other cases. E.g. reading a numeric
property as string will work, but not reading a string property as
number. Other than that, only MPV_FORMAT_INT64->MPV_FORMAT_DOUBLE does
an automatic conversion.
I'm not sure whether these semantics and API are good, so comments and
suggestions are welcome.
With mpv_set_property(h, "property", MPV_FORMAT_STRING, ptr), ptr now
has to be of type char** instead of char*. This makes it more consistent
with mpv_get_property() and also non-pointer formats, which will be
introduced in the following commits. mpv_set_property() of course does
not change its interface (only its implementation is adjusted to keep
its interface).
This also affects mpv_set_option(), but again not
mpv_set_option_string().
Until now, strings were the only allowed dynamically allocated argument
type in input commands. Extend it so that it works for any type. (The
string expansion in command.c is of course still string specific.)
Some code accessed m_option.name to get the property name. (Maybe only
show_property_osd() had a significant use of it.) Remove that, and
remove setting names and dummy names as well.
The old code usually assumed that the name was set, and
show_property_osd() used it to get the proper name of deprecated
aliases.
The "vf" property was listed as "vf*". Not sure why that was done, but
it works without anyway.
M_OPT_PARSE_ESCAPES was pretty stupid, and broke the (useful) assumption
that string variables contain exactly the same value as set by the
option. Simplify it, and move escape handling to the place where it's
used.
Escape handling itself is not terribly useful, but still allows useful
things like multiline custom OSD with "\n".
MP_CMD_COMMAND_LIST commands (used to implement key bindings with
multiple commands) were not checked for abort commands. Implement it.
Remove the remarks about multi-commands being special from the manpage.
Seek coalescing is handled differently now, and the issue with abort
commands is fixed with this commit.
The old way still works, and is fine to use. Still discourage it,
because it might conflict with other ways to access this property, such
as the one added in the next commit.
This is a regression introduced from moving Lua scripts (including the
OSC) to their own threads. Now OSC and dvdnav can add their bindings at
the same time without coordination, which seems to result in the OSC
winning most time, and thus overriding the dvdnav menu bindings.
Fix this by adding a flag that makes dvdnav menu bindings take priority
over all other bindings.
When timeline was used, and the --start option was not used, the initial
seek (needed to switch to the first timeline segment) seeked to -1 due
to an oversight.
There was already an undocumented mechanism provided by
mp.set_key_bindings and other functions, but this was relatively
verbose, and also weird. It was mainly to make the OSC happy (including
being efficient and supporting weird corner cases), while the new
functions try to be a bit simpler.
This also provides a way to let users rebind script-provided commands.
(This mechanism is less efficient, because it's O(n^2) for n added key
bindings, but it shouldn't matter.)
Until now, the --no-config was explicitly checked in multiple places to
suppress loading of config files.
Add such a check to the config path code itself, and refuse to resolve
_any_ configuration file locations if the option is set.
osc.lua needs a small fixup, because it didn't handle the situation when
no path was returned. There may some of such cases in the C code too,
but I didn't find any on a quick look.
Instead, chain them.
Note that there's no logic to prevent the other event handlers to be run
from an event handler (like it's popular in GUI toolkits), because I
think that's not very useful for this purpose.
In particular, this affects drag & drop of subtitles, which uses sub_add
internally. This will make the subtitles show up immediately, instead of
requiring manual selection of the added subtitle.
Might be not so ideal when adding multiple subtitles at once, because
that leads to multiple sub_add commands, and will end up with the last
subtitle instead of the first selected. But this is a minor detail.
The initialization code was split and refactored for the libmpv changes.
One change, moving a part of cocoa initialization, accidentally broke
--force-window on OSX, which creates a VO in a certain initialization
stage. We still don't know how cocoa should behave with libmpv, so fix
this with a hack to beat it back into working. Untested.
Return the error Lua-style, instead of raising it as Lua error. This is
better, because raising errors is reserved for more "fatal" conditions.
Pretending they're exceptions and trying to do exception-style error
handling will just lead to pain in this language.
This library will export the client API functions.
Note that this doesn't allow compiling the command line player to link
against this library yet. The reason is that there's lots of weird stuff
required to setup the execution environment (mostly Windows and OSX
specifics), as well as things which are out of scope of the client API
and every application has to do on its own. However, since the mpv
command line player basically reuses functions from the mpv core to
implement these things, it's not very easy to separate the command
line player form the mpv core.
This is partial only, and it still accesses some MPContext internals.
Specifically, chapter and track lists are still read directly, and OSD
access is special-cased too.
The OSC seems to work fine, except using the fast-forward/backward
buttons. These buttons behave differently, because the OSC code had
certain assumptions how often its update code is called.
The Lua interface changes slightly.
Note that this has the odd property that Lua script and video start
at the same time, asynchronously. If this becomes an issue, explicit
synchronization could be added.
Add a client API, which is intended to be a stable API to get some rough
control over the player. Basically, it reflects what can be done with
input.conf commands or the old slavemode. It will replace the old
slavemode (and enable the implementation of a new slave protocol).
This avoids trouble if another mpv instance is initialized in the same
process.
Since timeBeginPeriod/timeEndPeriod are hereby not easily matched
anymore, use an atexit() handler to call timeEndPeriod, so that we
can be sure these calls are matched, even if we allow multiple
initializations later when introducing the client API.
This sometimes happened when changing playback speed (= reinitializing
audio) after seeking of playback start. The assertion in audio.c:441 was
triggered, because buffer_playable_samples wasn't reset correctly when
the audio buffer was cleared or shortened. The assertion is correct and
should hold up any time.
The code removed from handle_input_and_seek_coalesce() did two things:
1. If there's a queued seek, stop accepting non-seek commands, and delay
them to the next playloop iteration.
2. If a seek is executing (i.e. the seek was unqueued, and now it's
trying to decode and display the first video frame), stop accepting
seek commands (and in fact all commands that were queued after the
first seek command). This logic is disabled if seeking started longer
than 300ms ago. (To avoid starvation.)
I'm not sure why 1. would be needed. It's still possible that a command
immediately executed after a seek command sees a "seeking in progress"
state, because it affects queued seeks only, and not seeks in progress.
Drop this code, since it can easily lead to input starvation, and I'm
not aware of any disadvantages.
The logic in 2. is good to make seeking behave much better, as it
guarantees that the video display is updated frequently. Keep the core
idea, but implement it differently. Now this logic is applied to seeks
only. Commands after the seek can execute freely, and like with 1., I
don't see a reason why they couldn't. However, in some cases, seeks are
supposed to be executed instantly, so queue_seek() needs an additional
parameter to signal the need for immediate update.
One nice thing is that commands like sub_seek automatically profit from
the seek delay logic. On the other hand, hitting chapter seek multiple
times still does not update the video on chapter boundaries (as it
should be).
Note that the main goal of this commit is actually simplification of the
input processing logic and to allow all commands to be executed
immediately.
Instead of printing lines like:
Demuxer info GENRE changed to Alternative Rock
Just output all tags once they change. The assumption is that individual
tags rarely change, while all tags change in the common case.
This changes tag updates to use polling. This could be fixed later,
although the ICY stuff makes it a bit painful, so maybe it will remain
this way.
Also remove DEMUXER_CTRL_UPDATE_INFO. This was intended to check for tag
updates, but now we use a different approach.
Windows applications that use LoadLibrary are vulnerable to DLL
preloading attacks if a malicious DLL with the same name as a system DLL
is placed in the current directory. mpv had some code to avoid this in
ao_wasapi.c. This commit just moves it to main.c, since there's no
reason it can't be used process-wide.
This change can affect how plugins are loaded in AviSynth, but it
shouldn't be a problem since MPC-HC also does this and it's a very
popular AviSynth client.
Windows users expect this when a program crashes. Without it, the
program just disappears. Also change the SetErrorMode call to use macros
instead of a hardcoded constant.
If there's more than one edition, print the list of editions, including
the edition name, whether the edition is selected, whether the edition
is default, and the command line option to select the edition. (Similar
to stream list.)
Move reading the tags to a separate function process_tags(), which is
called when all other state is parsed. Otherwise, that tags will be lost
if chapters are read after the tags.
Do two things:
1. add locking to struct osd_state
2. make struct osd_state opaque
While 1. is somewhat simple, 2. is quite horrible. Lots of code accesses
lots of osd_state (and osd_object) members. To make sure everything is
accessed synchronously, I prefer making osd_state opaque, even if it
means adding pretty dumb accessors.
All of this is meant to allow running VO in their own threads.
Eventually, VOs will request OSD on their own, which means osd_state
will be accessed from foreign threads.
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
These were needed before the last commit, but now they don't do anything
anymore. (They were used to decide whether to replace or stack the
previous OSD message when a new one was displayed.)
If certain OSD messages were displayed at the same time, the hidden
messages were put on the stack, and displayed again once the higher
priority messages disappeared. The idea was probably that lower priority
messages could not hide higher priority ones, and also that the lower
messages did not get lost.
But in practice, this gives confusing results with OSD messages randomly
reappearing for a brief time. Remove it.
