The comment says that it wakes up the main thread if 50% has been
played, but in reality the value was 0.74/2 => 37.5%. Correct this. This
probably changes little, because it's a very fuzzy heuristic in the
first place.
Also move down the min_wait calculation to where it's actually used.
mp3 has a hack lowering the probescore for format detection. This is
because detecting mp3s is hard due to their nature, and the fact that
ID3v2 tags are sometimes several megabytes big.
When playing mp3 from network, the mime-type is usually set, and that
matches the format hack entry meant for webradios, overriding the normal
mp3 entry. This can lead to network mp3s not being detected. Lower the
network case to the same probescore as on-disk mp3s. The difference is
that for network mp3s, we don't load the full probe-buffer, and we lower
the amount of audio the demuxer will read to collect data on opening
(0.5 seconds instead of typically 5 seconds).
This was a minor code duplication between vf_vdpaupp.c and vo_vdpau.c.
(In theory, we could always require using vf_vdpaupp with vo_vdpau, but
I think it's better if vo_vdpau can work standalone.)
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.
This can happen when the input stream is somehow blocking on network,
and the user still send input in one way or another, and one of the
commands is a compound command ("cmd a ; cmd b").
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.
vf_fix_img_params() takes care of overwriting image parameters that are
normally not set correctly by filters. But this makes no sense for input
images. So instead, check that the input is correct.
It still has to be done for the first input image, because that's used
to handle some overrides (see video_reconfig_filters()).
These replace vf_read_output_frame(), although we still emulate that
function. This change is preparation for another commit (and this is
basically just to reduce the diff and signal/noise ratio in that
commit).
Basically, if we feed the filter a new image even after the EOF state
has been reached (e.g. because the input stream "recovered"), we want
the filter to restart, instead of returning an error forever.
Some non-deinterlacing filters (potentially denoising) also use
additional frames for filtering. The vdpau docs suggest providing at
least 1 future and 2 past _fields_, which means we need to provide 1
past frame (the future field is already the other field of the current
field, and both fields are in the same frame).
We can easily achieve this by buffering an additional frame in the non-
deint case.
Remove the special casing of vo_vdpau vs. other VOs. Replace the
complicated interaction between vo.c and vo_vdpau.c with a simple queue
in vo.c. VOs other than vdpau are handled by setting the length of the
queue to 1 (this is essentially what waiting_mpi was).
Note that vo_vdpau.c seems to have buffered only 1 or 2 frames into the
future, while the remaining 3 or 4 frames were past frames. So the new
code buffers 2 frames (vo_vdpau.c requests this queue length by setting
vo->max_video_queue to 2). It should probably be investigated why
vo_vdpau.c kept so many past frames.
The field vo->redrawing is removed. I'm not really sure what that would
be needed for; it seems pointless.
Future directions include making the interface between playloop and VO
simpler, as well as making rendering a frame a single operation, as
opposed to the weird 3-step sequence of rendering, drawing OSD, and
flipping.
