Until now, these options took effect only at program start. This could
be confusing when e.g. doing "mpv list.m3u --shuffle". Make them always
take effect when a playlist is loaded either via a playlist file, or
with the "loadlist" command.
Essentially, don't make it the mmap() argument, and just add it to the
memory address. This hides tricky things like alignment reequirements
from the user.
Strictly speaking, this is not entirely backwards compatible: this adds
the regression that you can't access past 2 or 4 GB of a file on 32 bit
systems anymore. But I doubt anyone cared about this.
In theory, we could be clever, and just align the offset manually and
pass that to mmap(). This would also be transparent to the user, but
minimally more effort, so this is left as exercise to the reader.
Makes all of overlay_add work on windows/mingw.
Since we now don't explicitly check for mmap() anymore (it's always
present), this also requires us to make af_export.c compile, but I
haven't tested it.
Padding with spaces is very useless for OSD (because most fonts are
variable width), but it's good when using it on the terminal, e.g. for
reproducing the default terminal status line.
This was requested.
It seems libdvdread can't get the duration for titlesets other than the
currently opened title. The data structures contain dangling pointers
for these, and MPlayer works this around by opening every title
separately for the purpose of dumping the title list.
The result isn't quite what I imagined, because the A-point is never
marked as a seek point (so you can't jump between A and B), but it's
still slightly better than before.
There were complaints that a chapter seek past the last chapter was
quitting the player. Change the behavior to what is expected: the last
frame.
If no chapters are available, this still does nothing.
Running "sub_add file.srt auto" during hook execution automatically
selected the first added track. This happened because all tracks added
with sub_add are marked as "external", and external subtitles are always
selected by default.
Fix this by negating the "external" flag when autoselecting subtitles
during loading. The no_default flag exists for this purpose; it was
probably added for libquvi originally, where we had the same issue.
In all of these situations, NULL is logically not allowed, making the
checks redundant.
Coverity complained about accessing the pointers before checking them
for NULL later.
Does the same thing as the drop_buffers command. When implementing that
command, it turned out that resetting the higher level playback state
was more effective for achieving smooth recovery.
Untested; I don't even have any DVDs or DVD images with multiple angles.
This command was actually requested on IRC ages ago, but I forgot about
it.
The main purpose is that the decoding state can be reset without issuing
a seek, in particular in situations where you can't seek.
This restarts decoding from the middle of the packet stream; since it
discards the packet buffer intentionally, and the decoder will typically
not output "incomplete" frames until it has recovered, it can skip a
large amount of data.
It doesn't clear the byte stream cache - I'm not sure if it should.
Probably needs to be polished a bit more. Also, might require a key
binding that can set/clear the loop points in a more intuitive way.
For now, something like this can be put into input.conf to use it:
ctrl+y set ab-loop-a ${time-pos} # set A
ctrl+x set ab-loop-b ${time-pos} # set B
ctrl+c set ab-loop-a no # clear (mostly)
Fixes#1241.
Due to the current code structure, the "current" entry and the entry
which is playing can be different. This is probably silly, but still
try to mark the entries correctly.
Refs #1260.
This actually doesn't even write/return the new sub-property, because
I dislike the idea of dumping that field for every single playlist
entry, even though it's "needed" only for one.
Fixes#1260.
This might be interesting for GUIs and such.
It's probably still a little bit insufficient. For example, the filter
and audio/video output lists are not available through this.
This rewrites the audio decode loop to some degree. Audio filters don't
do refcounted frames yet, so af.c contains a hacky "emulation".
Remove some of the weird heuristic-heavy code in dec_audio.c. Instead of
estimating how much audio we need to filter, we always filter full
frames. Maybe this should be adjusted later: in case filtering increases
the volume of the audio data, we should try not to buffer too much
filter output by reducing the input that is fed at once.
For ad_spdif.c and ad_mpg123.c, we don't avoid extra copying yet - it
doesn't seem worth the trouble.
Causes the player to reload the demuxer and to relist the found
streams. Probably slightly dangerous/broken, because the demuxer
thread and possibly even the decoders will keep reading data from
the new title before the new demuxer takes over.
Fixes#1250.
This is what you would expect. Before this commit, each
ao_request_reload() call would just queue a reload command, and then
recreate the AO for the number of times the function was called.
Instead of sending a command, introduce some sort of event retrieval
mechanism. At least for the reload case, use atomics, because we're too
lazy to setup an extra mutex.
Call VOCTRL_GET_DISPLAY_NAMES it when the property is
requested. The vo should return the names of the displays that the mpv
window is covering. For example, with x11 vos, xrandr names LVDS1,
HDMI1, etc.
update_subtitle() already uees playback_pts to make subtitles work
better in no-audio mode. Using get_current_time() usually gets
playback_pts, but also has the advantage that it will use the seek
target time during seeks. This will result in multiple sub_seek commands
doing the right thing (at least as long as they're far enough apart so
that seeking is actually initiated when the second command is run).
Add a generic mechanism to the VO to relay "extra" events from VO to
player. Use it to notify the core of window resizes, which in turn will
be used to mark all affected properties ("window-scale" in this case) as
changed.
(I refrained from hacking this as internal command into input_ctx, or to
poll the state change, etc. - but in the end, maybe it would be best to
actually pass the client API context directly to the places where events
can happen.)
Instead of defining a separate data structure in the core.
For some odd reason, demux_chapter exported the chapter time in
nano-seconds. Change that to the usual timestamps (rename the field
to make any code relying on this to fail compilation), and also remove
the unused chapter end time.
Use the codepath that is normally used for DVD/BD title switching and
DVB channel switching. Removes some extra artifacts from the client API:
now MPV_EVENT_END_FILE will never be called on reloads (and neither is
MPV_EVENT_START_FILE).
No development activity (or even any sign of life) for almost a year.
A replacement based on youtube-dl will probably be provided before the
next mpv release. Ask on the IRC channel if you want to test.
Simplify the Lua check too: libquvi linking against a different Lua
version than mpv was a frequent issue, but with libquvi gone, no
direct dependency uses Lua, and such a clash is rather unlikely.
So a client API user can know when a window is created or destroyed.
Also might be useful for the OSC: it could disable itself if video is
disabled.
Before this commit, there were only indirect ways of detecting this.
The behavior of reverse cycling (with the "!reverse" magic value) was a
bit weird and acted with a "delay". This was because the command set the
value the _next_ command should use. Change this and make each command
invocation select and use the next command directly. This requires an
"uninitialized" special index in the counter, but that is no problem at
all.
Due to the way video-rotate currently works, the state will be
automatically updated once new video is decoded. So the filter chain
doesn't need to be reinitialized automatically, but there is a need to
trigger the video instant refresh code path instead.
Also move the support function closer to an annoying similar yet
different function. They probably can be unified next time major changes
are done to this code.
Allows properly changing/updating the cursor state. Useful for client
API window embedding, because the host application may not want the mpv
window to grab mouse input, and this has to manually handle the cursor.
Changing the cursor of foreign windows is usually not sane.
It might make sense to allow changing the cursor icon, but that would be
much more complicated, so I won't add it unless someone actually
requests it.
Apparently using the stream index is the best way to refer to the same
streams across multiple FFmpeg-using programs, even if the stream index
itself is rarely meaningful in any way.
For Matroska, there are some possible problems, depending how FFmpeg
actually adds streams. Normally they seem to match though.
A vague idea to get something similar what libquvi did.
Undocumented because it might change a lot, or even be removed. To give
an idea what it does, a Lua script could do the following:
-- type ID priority
mp.commandv("hook_add", "on_load", 0, 0)
mp.register_script_message("hook_run", function(param, param2)
-- param is "0", the user-chosen ID from the hook_add command
-- param2 is the magic value that has to be passed to finish
-- the hook
mp.resume_all()
-- do something, maybe set options that are reset on end:
mp.set_property("file-local-options/name", "value")
-- or change the URL that's being opened:
local url = mp.get_property("stream-open-filename")
mp.set_property("stream-open-filename", url .. ".png")
-- let the player (or the next script) continue
mp.commandv("hook_ack", param2)
end)
Showed "Volume: (unavailable)%". That was dumb.
The message string is now a bit convoluted; mostly because the property
expand syntax can't do "if-else", just "if".
CC: @mpv-player/stable
This does nothing good. This reverts a change made over a year ago - I
don't remember why this was originally done this way.
The main problem is that even if the volume option is set (something
like "--volume=75"), the volume property will always return "100" until
audio is initialized. If audio is uninitialized again, the volume
property will remain frozen at its last value.
Whether you consider the semantics weird or not depends on your use
case, but I suppose it's a bit confusing anyway. At this point, we keep
MPV_EVENT_PAUSE/UNPAUSE for compatibility only.
Make the "core-idle" property somewhat more useful in this context.
Each subsystem (or similar thing) had an INITIALIZED_ flag assigned. The
main use of this was that you could pass a bitmask of these flags to
uninit_player(). Except in some situations where you wanted to
uninitialize nearly everything, this wasn't really useful. Moreover, it
was quite annoying that subsystems had most of the code in a specific
file, but the uninit code in loadfile.c (because that's where
uninit_player() was implemented).
Simplify all this. Remove the flags; e.g. instead of testing for the
INITIALIZED_AO flag, test whether mpctx->ao is set. Move uninit code
to separate functions, e.g. uninit_audio_out().
For the sake of libmpv. Might make things much easier for the user,
especially on Windows. On the other hand, it's a bit sketchy that a
command exists that makes the player access arbitrary memory regions.
(But do note that input commands are not meant to be "secure" and never
were - for example, there's the "run" command, which obviously allows
running random shell commands.)
Somewhat more flexible: now there's a separate overlay struct, and you
don't need to coerce all state into struct sub_bitmap. Also, removing
the previous mapping (munmap call) is now all in one place, the
replace_overlay function.
Makes the next commit easier to implement.
This warning makes absolutely no sense. Passing an empty string to
printf-like functions is perfectly fine. In the OSD case, it just sets
an empty message, practically clearing the OSD.
Be less annoying, print the actual OSD level instead of something
meaningless, but still clear the OSD if OSD level 0 (no OSD) is set.
Remove the special handling for terminal OSD, that was just dumb.
This means that if a property not listed in property_osd_display[] is
changed, it will be shown on the OSD as "name: ${name}".
Properties that are listed in property_osd_display[] and have osd_name
not set stay invisible by default. This is used for "pause" and
"fullscreen", which (like before this commit) are not shown by default,
because it would be annoying.
The defaults still can be changed with command prefixes (osd-msg,
no-osd, others).
Probably not many user-visible changes. One notable change is that the
terminal OSD code for OSD bar fallback handling is removed with no
replacement. Instead, terminal OSD gets the same text message as normal
OSD. For volume, this is ok, because the text message is reasonable.
Other properties will look worse, but could be adjusted, and there are
in fact no other such properties that would be useful in audio-only
mode.
The fallback message for seeking falls away as well, but that message
was useless anyway - the terminal status line provides all information
anyway.
I believe the show_property_osd() code is now much easier to follow.
If no VO was open, these options couldn't be changed or even queried.
Although these properties are nearly useless if no VO exists, there's
actually no good reason to forbid querying or setting them. Also, even
if the VO is created, it doesn't mean the VO window was created.
Why bother?
Also, since now some properties could be mapped to non-existing options,
but mp_property_generic_option() is used, deal with this case and return
a not-found error code.
If there's a command that uses the OSD by default, then always print the
associated message (or a fallback made of name + value), even if the
command has an associated OSD bar.
This means volume, gamma, panscan, etc. all show both a message and a
OSD bar.
Also, add a '%' to the volume message. The extra_msg thing is not needed
anymore.
See issue #1103.
It's just confusing; users are encouraged to edit input.conf instead
(changing the argument to the "add" command).
Update input.conf to keep the old behavior.
We don't allow this by default, because it would be silly if random
external data (like filenames or file tags) could accidentally trigger
them.
Add a property that magically disables this ASS tag escaping.
Note that malicious input could still disable ASS tag escaping by
itself. This would be annoying but harmless.
Don't attempt to resync after speed changes. Note that most other cases
of audio reinit (like switching tracks etc.) still resync, but other
code paths take care of setting the audio_status accordingly.
This restores the old behavior of not trying to fix audio desync, which
was probably changed with commit 261506e3.
Note that the code as of now wasn't even entirely correct, since the A/V
sync values are slightly shifted. The dsync depends on the audio buffer
size, so a larger buffer size will show more extreme desync. Also see
mplayer2 commit 213a224e, which should fixed this - it was not merged
into mpv, because it disabled audio for too long, resulting in a worse
user experience. This is similar to the issue this commit attempts to
fix.
Fixes: #1042 (probably)
CC: @mpv-player-stable
This mostly uses the same idea as with vo_vdpau.c, but much simplified.
On X11, it tries to get the display framerate with XF86VM, and limits
the frequency of new video frames against it. Note that this is an old
extension, and is confirmed not to work correctly with multi-monitor
setups. But we're using it because it was already around (it is also
used by vo_vdpau).
This attempts to predict the next vsync event by using the time of the
last frame and the display FPS. Even if that goes completely wrong,
the results are still relatively good.
On other systems, or if the X11 code doesn't return a display FPS, a
framerate of 1000 is assumed. This is infinite for all practical
purposes, and means that only frames which are definitely too late are
dropped. This probably has worse results, but is still useful.
"--framedrop=yes" is basically replaced with "--framedrop=decoder". The
old framedropping mode is kept around, and should perhaps be improved.
Dropping on the decoder level is still useful if decoding itself is too
slow.
This code was sending a string to a different thread, and then
deallocated the string shortly after, which means most of the time
the other thread was accessing a dangling pointer.
It's possible that this is the cause for #1002.
Trying to jump chapters in a gile that has no chapters does nothing,
not even show a warning. This is confusing. The reason is that the
"add chapter" command will just bail out completely if the property
is unavailable.
This was because it exited when it couldn't get the property type.
Instead of exiting, just don't enter the code that needs the type.
(I'm not sure when this behavior changed. I consider it a regression.
It was probably caused by changes to the chapter code, which perhaps
started returning UNAVAILABLE instead of OK if there are no chapters.)
The client API exports this state via events already, but maybe it's
better to explicitly provide this property in order to facilitate use on
OSD and similar cases.
Internally, there are two mechanisms which can trigger property
notification as used with "observed" properties in the client API.
The first mechanism associates events with a group of properties that
are potentially changed by a certain event. mp_event_property_change[]
declares these associations, and maps each event to a set of strings.
When an event happens, the set of strings is matched against the list of
observed properties of each client. Make this more efficient by
comparing bitsets of events instead. This way, only a bit-wise "and" is
needed for each observed property. Even better, we can completely skip
clients which have no observed properties that match.
The second mechanism just updates individual properties explicitly by
name. Optimize this by using the property index instead. It would be
nice if we could reuse the first mechanism for the second one, but
there are too many properties to fit into a 64 bit mask.
(Though the limit on 64 events might get us into trouble later...)
"Internal" events were added in the previous commits to leverage the
client API property mechanism, without making weird properties public.
But they were sent to clients too (and returned by mpv_wait_event()).
Achieve this by polling. Will be used by the OSC. Basically a bad hack -
but the point is that the mpv core itself is in the best position to
improve this later.
Regression since commit 261506e3. Internally speaking, playback was
often not properly terminated, and the main part of handle_keep_open()
was just executed once, instead of any time the user tries to seek. This
means playback_pts was not set, and the "current time" was determined by
the seek target PTS.
So fix this aspect of video EOF handling, and also remove the now
unnecessary eof_reached field.
The pause check before calling pause_player() is a lazy workaround for
a strange event feedback loop that happens on EOF with --keep-open.
Actually free the old mmap region when readding an overlay of the same
ID without removing it before. (This is explicitly documented as
working.)
Replace the OSD atomically. Before this commit, the overlays were
removed and then readded to avoid synchronization problems.
Simplify the code: now there is no weird mapping between index and ID.
The OSD sub-bitmap list still needs to be prepared to skip unused IDs
(since each sub-bitmap list entry must be in use), but the code for this
is relatively separated now.
Fixes issue #956.
Currently entries are added after the current playlist element. This is kinda
confusing, more so given that "loadfile append" appends at the end of the
playlist.
"loadfile filename append-play" will now always append the file to the
playlist, and if nothing is playing yet, start playback. I don't want to
change the semantics of "append" mode, so a new mode is needed.
Probably fixes issue #950.
This called demux_flush(), but that doesn't make any sense with an
asynchronously running demuxer. It would just keep reading and add new
packets again. Explicitly pause the demuxer, so that this can't happen.
Also, when flushing, data will be missing, so the decoders should
always be reinitialized, even if the operation fails.
This adds a thread to the demuxer which reads packets asynchronously.
It will do so until a configurable minimum packet queue size is
reached. (See options.rst additions.)
For now, the thread is disabled by default. There are some corner cases
that have to be fixed, such as fixing cache behavior with webradios.
Note that most interaction with the demuxer is still blocking, so if
e.g. network dies, the player will still freeze. But this change will
make it possible to remove most causes for freezing.
Most of the new code in demux.c actually consists of weird caches to
compensate for thread-safety issues (with the previously single-threaded
design), or to avoid blocking by having to wait on the demuxer thread.
Most of the changes in the player are due to the fact that we must not
access the source stream directly. the demuxer thread already accesses
it, and the stream stuff is not thread-safe.
For timeline stuff (like ordered chapters), we enable the thread for the
current segment only. We also clear its packet queue on seek, so that
the remaining (unconsumed) readahead buffer doesn't waste memory.
Keep in mind that insane subtitles (such as ASS typesetting muxed into
mkv files) will practically disable the readahead, because the total
queue size is considered when checking whether the minimum queue size
was reached.
Until now, changing the properties showed the VO colorspace parameters
on OSD. This didn't work quite well, because it showed the VO parameters
_before_ the change. This is because at least one video frame with the
new parameters has to be shown, and this doesn't happen right after
changing the property, but a bit later.
Also fix a random typo in unrelated code.
No reason to wait until the audio has been played. This isn't a problem
with gapless audio disabled, and since gapless is now default, this
behavior might be perceived as regression.
CC: @mpv-player/stable
This also means that the printed size is always rounded to KBs, because
the cache properties are returned in KB. I think this doesn't matter
much. But if it does, the cache properties should probably changed to
return bytes in the first place.
Instead of absuing m_option to store the property list, introduce a
separate type for properties. m_option is still used to handle data
types. The property declaration itself now never contains the option
type, and instead it's always queried with M_PROPERTY_GET_TYPE. (This
was already done with some properties, now all properties use it.)
This also fixes that the function signatures did not match the function
type with which these functions were called. They were called as:
int (*)(const m_option_t*, int, void*, void*)
but the actual function signatures were:
int (*)(m_option_t*, int, void*, MPContext *)
Two arguments were mismatched.
This adds one line per property implementation. With additional the
reordering of the parameters, this makes most of the changes in this
commit.
While I'm not very fond of "const", it's important for declarations
(it decides whether a symbol is emitted in a read-only or read/write
section). Fix all these cases, so we have writeable global data only
when we really need.
Convert all these commands to properties. (Except tv_last_channel, not
sure what to do with this.) Also, internally, don't access stream
details directly, but dispatch commands with stream ctrls.
Many of the new properties are a bit strange, because they're write-
only. Also remove some OSD output these commands produced, because I
couldn't be bothered to port these.
In general, this makes everything much cleaner, and will also make it
easier to e.g. move the demuxer to its own thread.
Don't bother updating input.conf, but changes.rst documents how old
commands map to the new ones.
Mostly untested, due to lack of hardware.
Until now, an error was reported only if the command couldn't be parsed.
Attempt to do more fine-grained reporting. This is not necessarily
perfect, but it's an improvement.
The i_bps members of the sh_audio and dev_video structs are mostly used
for displaying the average audio and video bitrates. Keeping them in
bits-per-second avoids truncating them to bytes-per-second and changing
them back lateron.
Stop using it in most places, and prefer STREAM_CTRL_GET_SIZE. The
advantage is that always the correct size will be used. There can be no
doubt anymore whether the end_pos value is outdated (as it happens often
with files that are being downloaded).
Some streams still use end_pos. They don't change size, and it's easier
to emulate STREAM_CTRL_GET_SIZE using end_pos, instead of adding a
STREAM_CTRL_GET_SIZE implementation to these streams.
Make sure int64_t is always used for STREAM_CTRL_GET_SIZE (it was
uint64_t before).
Remove the seek flags mess, and replace them with a seekable flag. Every
stream must set it consistently now, and an assertion in stream.c checks
this. Don't distinguish between streams that can only be forward or
backwards seeked, since we have no such stream types.
stream.start_pos was needed for optical media only, and (apparently) not
for very good reasons. Just get rid of it.
For stream_dvd, we don't need to do anything. Byte seeking was already
removed from it earlier.
For stream_cdda and stream_vcd, emulate the start_pos by offsetting the
stream pos as seen by the rest of mpv.
The bits in discnav.c and loadfile.c were for dealing with the code
seeking back to the start in demux.c. Handle this differently by
assuming the demuxer is always initialized with the stream at start
position, and instead seek back if initializing the demuxer fails.
Remove the --sb option, which worked by modifying stream.start_pos. If
someone really wants this option, it could be added back by creating a
"slice" stream (actually ffmpeg already has such a thing).
The quit command has an optional argument that is used as exit code.
Extend that to the quit_watch_later command. Actually, unify the
implementations of the two commands.
Requested in #798.
The code paths for setting options by string and by direct "raw" value
were too different, which resulted in some weird code. Make the code
paths closer to each other.
Also, use this to remove the weirdness in the mpv_set_option()
implementation.
These are now equivalent to combining commands with the "cycle pause" or
"set pause" commands, and thus are not needed anymore. They were also
obscure and undocumented.
This is done after filters, so things like framerate-doubling
deinterlacing is accounted for.
Unfortunately, framedropping can cause inaccuracies (especially after
precise seeks), and we can't really know when that happens. Even though
we know that the decoder might drop a frame if we request it to do so,
we don't know when the dropped frame will start or stop affecting the
video filter chain. Video filters can have frames buffered, and we
can't tell at which point the dropped frame would have been output.
It's not even possible to mark a discontinuity after seek, because
again we don't know if the filter chain still has the discontinuity
within its buffers.
So we have to live with the fact that the output of this property can
be completely broken after seek, unless --no-hr-seek-framedrop is used.
Make it more suitable for chaining. This means a function formatting a
value to a string using a static buffer can work exactly like
mp_snprintf_append itself.
Also rename it to mp_snprintf_cat, because that's shorter.
Give up on the deint_filters[] array, and probe using explicit code
instead. Add additional checks to test the pixel format to avoid
annoying warnings when a hardware deinterlacer is inserted when the
current video chain is obviously incompatible.
lavfi would segfault due to a NULL dereference if it was asked for its
metadata and none had been allocated (oops). This happens for libav
which has no concept of filter metadata.
And slightly adjust the semantics of MPV_EVENT_PAUSE/MPV_EVENT_UNPAUSE.
The real pause state can now be queried with the "core-idle" property,
the user pause state with the "pause" property, whether the player is
paused due to cache with "paused-for-cache", and the keep open event can
be guessed with the "eof-reached" property.
This property is set to "yes" if playback was paused due to --keep-open.
The change notification might not always be perfect; maybe that should
be improved.
Currently this is (probably) equivalent to "paused-for-cache", but the
latter is a bit special, while this new property is a bit more general.
One case where they might actually be different is dvdnav menus, but I
haven't checked.
Also add property change notifications for these two properties.
This is a read-only property that uses VFCTRL_GET_METADATA
to retrieve mp_tags metadata from a filter specified by label
Signed-off-by: wm4 <wm4@nowhere>
These playlist parsers are all what's left from the old mplayer playlist
parsing code. All of it is old code that does little error checking; the
type of C string parsing code that gives you nightmare.
Some playlist parsers have been rewritten and are located in
demux_playlist.c. The removed formats were not reimplemented. ASX and
SMIL use XML, and since we don't want to depend on a full blown XML
parser, this is not so easy. Possibly these formats could be supported
by writing a very primitive XML-like lexer, which would lead to success
with most real world files, but I haven't attempted that. As for NSC, I
couldn't find any URL that worked with MPlayer, and in general this
formats seems to be more than dead.
Move playlist_parse_file() to playlist.c. It's pretty small now, and
basically just opens a stream and a demuxer. No use keeping
playlist_parser.c just for this.
This is needed if you want to reimplement the status line in lua
I could only test drop-frame-count because I didn't find an easy way to
trigger paused-for-cache and total-avsync-change
Signed-off-by: wm4 <wm4@nowhere>
The only tricky part is keeping the cache contents, which is made simple
by allocating the new cache while still keeping the old cache around,
and then copying the old data.
To explain the "Don't use this when playing DVD or Bluray." comment: the
cache also associates timestamps to blocks of bytes, but throws away the
timestamps on seek. Thus you will experience strange behavior after
resizing the cache until the old cached region is exhausted.
Some of these property implementations already send notifications on
their own, but most don't. This takes care of them.
Of course this still doesn't handle all propertry changes - this is
impossible without special-casing each property that can change on its
own.
This turned out ridiculously complex. I think it will have to be
simplified some day. Main reason for the complexity are:
- filtering properties by forcing clients to observe individual
properties explicitly
(to avoid spamming clients with changes they don't want)
- optional retrieval of property value with the notification
(the basic idea was that this is more user friendly)
- allowing to the client to specify a format in which the value
should be retrieved
(because if a property changes its type, the client API couldn't
convert it properly, and compatibility would break)
I don't know yet which of these are important, and everything could
change. In particular, the interface and semantics should be adjusted
to reduce the implementation complexity.
While I consider the API complete, there could (and probably will) be
bugs left. Also while the implementation is complete, it's inefficient.
The complexity of the property matching is O(a*b*c) with a clients,
b observed properties, and c properties changing at once. I threw away
an earlier implementation using bitmasks, because it was too unwieldy.
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.
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 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.
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.
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.
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 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.
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.
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".
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.
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.
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).
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.
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.
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.
Before that, it just returned -1.
The print case is inconsistent with that, but I'll leave it for now,
because it's consistent with status line / show_progress behavior.
The terminal OSD code includes the handling of the terminal status line,
showing player OSD messages on the terminal, and showing subtitles on
terminal (the latter two only if there is no video window, or if
terminal OSD is forced).
This didn't handle some corner cases correctly. For example, showing an
OSD message on the terminal always cleared the previous line, even if
the line was an important message (or even just the command prompt, if
most other messages were silenced).
Attempt to handle this correctly by keeping track of how many lines the
terminal OSD currently consists of. Since there could be race conditions
with other messages being printed, implement this in msg.c. Now msg.c
expects that MSGL_STATUS messages rewrite the status line, so the caller
is forced to use a single mp_msg() call to set the status line.
Instead of littering print_status() all over the place, update the
status only once per playloop iteration in update_osd_msg(). In audio-
only mode, the status line might now be a little bit off, but it's
perhaps ok.
Print the status line only if it has changed, or if another message was
printed. This might help with extremely slow terminals, although in
audio+video mode, it'll still be updated very often (A-V sync display
changes on every frame).
Instead of hardcoding the terminal sequences, use
terminfo/termcap to get the sequences. Remove the --term-osd-esc option,
which allowed to override the hardcoded escapes - it's useless now.
The fallback for terminals with no escape sequences for moving the
cursor and clearing a line is removed. This somewhat breaks status line
display on these terminals, including the MS Windows console: instead of
querying the terminal size and clearing the line manually by padding the
output with spaces, the line is simply not cleared. I don't expect this
to be a problem on UNIX, and on MS Windows we could emulate escape
sequences. Note that terminal OSD (other than the status line) was
broken anyway on these terminals.
In osd.c, the function get_term_width() is not used anymore, so remove
it. To remind us that the MS Windows console apparently adds a line
break when writint the last column, adjust screen_width in terminal-
win.c accordingly.
Use the video chain for this instead. This is for facilitating coming
changes, which will clean up the vo->aspdat stuff, and this code would
be in the way.
Note that we can't use mp_msg, because it's not async-signal safe (we
might be running other threads while forking, so only functions
specified to be async-signal safe can be called, and this doesn't
include stdio; mp_msg acquires a mutex too).
Also, always print a \n before running the program to flush the status
line. The effect is that a program running successfully as well as the
error message will effectively start on a new line.
This is relatively hacky, but it's Christmas, so it's ok. This does two
things: 1. allow selecting two subtitle tracks, and 2. include a hack
that renders the second subtitle always as toptitle. See manpage
additions how to use this.
There's a single mp_msg() in path.c, but all path lookup functions seem
to depend on it, so we get a rat-tail of stuff we have to change. This
is probably a good thing though, because we can have the path lookup
functions also access options, so we could allow overriding the default
config path, or ignore the MPV_HOME environment variable, and such
things.
Also take the chance to consistently add talloc_ctx parameters to the
path lookup functions.
Also, this change causes a big mess on configfiles.c. It's the same
issue: everything suddenly needs a (different) context argument. Make it
less wild by providing a mp_load_auto_profiles() function, which
isolates most of it to configfiles.c.
Always pass around mp_log contexts in the option parser code. This of
course affects all users of this API as well.
In stream.c, pass a mp_null_log, because we can't do it properly yet.
This will be fixed later.
wm4
Alessandro Ghedini
Kevin Mitchell
Ben Boeckel
Ryan Jacobs
Andrey Morozov
Tsukasa OMOTO
Niklas Haas
Marcoen Hirschberg
Marcoen Hirschberg
Martin
Martin Herkt
David Weber
xylosper