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.
Also remove MSGL_SMODE and friends.
Note: The indent in options.rst was added to work around a bug in
ReportLab that causes the PDF manual build to fail.
When loading a video, and a script reacts to MPV_EVENT_VIDEO_RECONFIG,
and the script inserts a video filter, the first frame can be skipped.
This happens simply because the first frame is (usually) still queued in
the video filter chain, and changing the filter chain will drop all
queued frames. So this is just a corner case that just happens in a
weird situation.
But it's still annoying when having such a script, and starting
something where the first frame is very visible, and not starting in
paused mode. (All in all, a corner case.) Do this by immediately queuing
1 filtered frame to the VO immediately after reconfig, instead of
leaving it to the video loop doing it as "incremental" work. Simply
fallthrough to the next case. We must not overwrite "r" in this case,
because that contains the current status.
Note that the first frame will not be filtered using the inserted
filter.
This wasn't really fine, and could (perhaps) cause weird corner cases on
reinit or when the player was paused.
Before eb9d20, video_left was also set to true if vo->frame_loaded was
set, and this variable basically indicated whether the previous
update_video() call was successful. This was overlooked when changing
everything. Simply always call update_video(), it should be equivalent.
Apparently the value of a pointer is "indeterminate" after a free()
call, even if you never dereference the pointer after the free. Since
talloc_free() calls free(), this applies here.
This affects the return value of mp.script_name, the "client name"
(what's returned by mpv_client_name()) and all associated features, as
well as the mpv terminal output module prefix when scripts print
something.
As discussed in #748.
Change how the video decoding loop works. The structure should now be a
bit easier to follow. The interactions on format changes are (probably)
simpler. This also aligns the decoding loop with future planned changes,
such as moving various things to separate threads.
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.
Commit 5e4e248 added a mp_image_params field to mp_image, and moved many
parameters to that struct. display_w/h was left redundant with
mp_image_params.d_w/d_h. These fields were supposed to be always in
sync, but it seems some code forgot to do this correctly, such as
vf_fix_img_params() or mp_image_copy_attributes(). This led to the
problem in github issue #756, because display_w/_h could become
incorrect.
It turns out that most code didn't use the old fields anyway. Just
remove them. Note that mp_image_params.d_w/d_h are supposed to be always
valid, so the additional checks for 0 shouldn't be needed. Remove these
checks as well.
Fixes#756.
Or in other words, add support for properly draining remaining frames
from video filters. vf_yadif is buffering at least one frame, and the
buffered frame was not retrieved on EOF.
For most filters, ignore this for now, and just adjust them to the
changed semantics of filter_ext. But for vf_lavfi (used by vf_yadif),
real support is implemented. libavfilter handles this simply by passing
a NULL frame to av_buffersrc_add_frame(), so we just have to make
mp_to_av() handle NULL arguments.
In load_next_vo_frame(), we first try to output a frame buffered in the
VO, then the filter, and then (if EOF is reached and there's still no
new frame) the VO again, with draining enabled. I guess this was
implemented slightly incorrectly before, because the filter chain still
could have had remaining output frames.
The interrupt callback will can be called from another thread if the
cache is enabled, and the stream disconnects. Then stream_reconnect()
will call this function from within the cache thread.
mp_input_check_interrupt() is not thread-safe due to read_events() not
being thread-safe. It will call input callbacks added with
mp_input_add_fd() - these callbacks lead to code not protected by locks,
such as reading X11 events.
Solve this by adding a stupid hack, which checks whether the calling
thread is the main playback thread (i.e. calling the input callbacks
will be safe). We can remove this hack later, but it requires at least
moving the VO to its own thread first.
This used global variables for the asynchronous interrupt callback.
Pick the simple and dumb solution and stuff the callback into
mpv_global. Do this because interrupt checking should also work in the
connect phase, and currently stream creation equates connecting.
Ideally, this would be passed to the stream on creation instead, or
connecting would be separated from creation. But since I don't know yet
which is better, and since moving stream/demuxer into their own thread
is something that will happen later, go with the mpv_global solution.
This was part of osdep/threads.c out of laziness. But it doesn't contain
anything OS dependent. Note that the rest of threads.c actually isn't
all that OS dependent either (just some minor ifdeffery to work around
the lack of clock_gettime() on OSX).
This should fix some issues, such as not being able to set the
"no-video" option with MPV_FORMAT_FLAG.
Note that this changes semantics a bit. Now setting an option strictly
overwrite it, even if the corresponding command line option does not.
For example, if we change --sub to append by default, then setting the
"sub" option via the client API would still never append. (Oddly, this
also applies to --vf-add, which will overwrite the old value when using
the client API.)
I'm doing this because there's no proper separation between the command
line parser and setting an option using the MPV_FORMAT_STRING format.
Maybe the solution to this mess would be adding format aware code (i.e.
m_option_set_node) to every option type, and falling back to strings
only if needed - but this would mean that you couldn't set e.g. an
integer option using MPV_FORMAT_STRING, which doesn't seem to be ideal
either.
In conclusion, the current approach seems to be most robust, but I'm
open to suggestions should someone find that these semantics are a
problem.
If the VO can't do rotation, insert a filter to do this. Note that this
doesn't reuse the filter insertion code from command.c (used by "vf"
input command), because that would end up more complicated: we don't
even want to change the user filter option.
Often, user configs set options that are not suitable for encoding.
Usually, playback and encoding are pretty different things, so it makes
sense to keep them strictly separate. There are several possible
solutions. The approach taken by this commit is to basically ignore the
default config settings, and switch to an [encoding] config profile
section instead. This also makes it impossible to have --o in a config
file, because --o enables encode mode.
See github issue #727 for discussion.
Not needed anymore. I'm not opposed to having asm, but inline asm is too
much of a pain, and it was planned long ago to eventually get rid fo all
inline asm uses.
For the note, the inline asm use that was removed with the previous
commits was almost worthless. It was confined to video filters, and most
video filtering is now done with libavfilter. Some mpv filters (like
vf_pullup) actually redirect to libavfilter if possible.
If asm is added in the future, it should happen in the form of external
files.
For some reason, the buffered_audio variable was used to "cache" the
ao_get_delay() result. But I can't really see any reason why this should
be done, and it just seems to complicate everything.
One reason might be that the value should be checked only if the AO
buffers have been recently filled (as otherwise the delay could go low
and trigger an accidental EOF condition), but this didn't work anyway,
since buffered_audio is set from ao_get_delay() anyway at a later point
if it was unset. And in both cases, the value is used _after_ filling
the audio buffers anyway.
Simplify it. Also, move the audio EOF condition to a separate function.
(Note that ao_eof_reached() probably could/should whether the last
ao_play() call had AOPLAY_FINAL_CHUNK set to avoid accidental EOF on
underflows, but for now let's keep the code equivalent.)
This should probably be an AO function, but since the playloop still has
some strange stuff (using the buffered_audio variable instead of calling
ao_get_delay() directly), just leave it and make it more explicit.
This collects statistics and other things. The option dumps raw data
into a file. A script to visualize this data is included too.
Litter some of the player code with calls that generate these
statistics.
In general, this will be helpful to debug timing dependent issues, such
as A/V sync problems. Normally, one could argue that this is the task of
a real profiler, but then we'd have a hard time to include extra
information like audio/video PTS differences. We could also just
hardcode all statistics collection and processing in the player code,
but then we'd end up with something like mplayer's status line, which
was cluttered and required a centralized approach (i.e. getting the data
to the status line; so it was all in mplayer.c). Some players can
visualize such statistics on OSD, but that sounds even more complicated.
So the approach added with this commit sounds sensible.
The stats-conv.py script is rather primitive at the moment and its
output is semi-ugly. It uses matplotlib, so it could probably be
extended to do a lot, so it's not a dead-end.
The audio subsystem now wakes up the playback thread explicitly, and we
don't need this anymore.
It still could cause dropouts and such if there are bugs in the recently
introduced audio changes, so this is a thing to watch out for.
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.
Basically a cheap hack to fix that the --msgmodule prefix will cause an
unwanted linebreak by making the line too long.
Suggested by Hamuko in github issue #710.
Fixes#710.
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>
