Fixes PNG cover art not showing up immediately (for example when running
with --pause).
libavformat exports embedded cover art as a single packet. For example,
a PNG attachment simply contains the PNG image, which can be sent to the
decoder. Normally you would expect that the PNG decoder would return 1
frame for 1 packet, without any delays. But this stopped working, and it
incurs a 1 frame delay.
This is perfectly legal (even if unexpected), so let our code feed the
decoder packets until we get something back. (In theory feeding the
packet instead of a real flush packet is still somewhat questionable.)
last_av_difference can be MP_NOPTS_VALUE under certain circumstances
(like no video timestamp yet). This triggered the desync message,
because fabs(MP_NOPTS_VALUE) is quite a large value. We don't want to
show a message in this situation.
libavcodec makes it impossible to distinguish dropped frames (requested
with AVCodecContext.skip_frame), and cases when the decoder simply does
not return a frame by default (such as with VP9, which has invisible
reference frames).
This confuses users when decoding VP9 video. It's basically a cosmetic
issue, so just paint it over by ignoring them if framedropping is
disabled.
When playing cover art, it conceptually reaches EOF as soon as the image
was put on the VO, causing the EOF message to be repeated every time new
audio was decoded. Just silence the message.
Use OPT_CHOICE_C() instead of the custom parser. The functionality is
pretty much equivalent.
(On a side note, it seems --video-stereo-mode can't be removed, because
it controls whether to "reduce" stereo video to mono, which is also the
default. In fact I'm not sure how this should be handled at all.)
"Non-monotonic" isn't even 100% correct; it's missing "strictly" (for
briefness I guess), and also the message is printed if the PTS jumps
forward. So just print something that is likely a bit easier to
understand.
For some reason there were two points in the code where it warned
against non-monotonic video PTS. The one in video.c triggered on PTS
going backwards or making large jumps forwards, while dec_video.c
triggered on PTS going backwards or PTS not changing. Merge them into a
single check, which warns against all cases.
Broken drivers are an issue rather often. Maybe this gives the user an
idea that this could be the reason. (We can't dump much more info on a
80x24 terminal.)
In ancient times, this was needed because it was not default, and many
VOs had problems with it. But it was always default in mpv, and all VOs
are required to deal with it. Also, running --fixed-vo=no is not useful
and just creates weird corner cases. Get rid of it.
This reverts commit 7b3feecbc2.
It's broken, hr-seek never ends at a video position before seek pts.
Not sure what I was thinking, although it did work anyway when
artificially forcing a video frame to display before seek pts.
At least there is _some_ problem if this happens. It would mean that
audio is playing slower than video. Normally, video is synced to audio,
so if audio stops playback completely, video will not advance at all.
But using things like --autosync, it's well possible that this kind of
desync happens.
Move the update_avsync_before_frame() call further down. Moving it
closer to where the time_frame value is used (and which the function
updates) should make the code more readable. With this change, there's
no need anymore to reset the time_frame value on the video reconfig
path.
Move the update_avsync_after_frame() up. Now no meaningful amount of
time passes since the previous get_relative_time() call anymore, and the
second one can be removed.
mpctx->audio_delay always has the same value as opts->audio_delay. (This
was not the case a long time ago, when the audio-delay property didn't
actually write to opts->audio_delay. I think.)
This allows seeking audio between two video frames that are relatively
far away.
The implementation of this is a bit subtle. It pretend the audio
position is different, and the actual PTS adjustment happens in audio.c
with this line:
sync_pts -= mpctx->audio_delay - mpctx->delay;
Effectively this is the same as setting sync_pts to hrseek_pts after
this line, though. (I'm actually not sure if this could be written in a
more straightforward way; probably yes.)
We still need to send the VO a duration in these cases. Disabling
framedrop has logically absolutely nothing to do with these cases; it
was overlooked in commit 918b06c4.
So we always send the frame duration (or a guess for it), and check
whether framedropping is actually enabled in the VO code. (It would
be cleaner to send framedrop as a flag, but I don't care about that
right now.)
The last video frame is another case that has a separate code path,
although it's pretty similar to the one in commit 73e5aa87. Fix this
in a different way, which also takes care of the last frame case,
although without context the code becomes slightly more tricky.
As further cleanup, move the decision about framedropping itself to
the same place, so the check in vo.c becomes much simpler. The check
for the vo->driver->encode flag, which is remvoed completely, was
redundant too.
Fixes#1480.
If the video format changes (e.g. different frame size), a special code
path is entered to wait until the currently displayed frame is done.
Otherwise, the frame before the change would be destroyed by the
vo_reconfig() call.
This code path didn't respect --untimed; correct this.
Fixes#1475.
There are currently 568 pixel formats (actually fewer, but the namespace
is this big), and for each format elaborate synchronization was done to
call it synchronously on the VO. This is completely unnecessary, and we
can do with just a single call.
This is basically a hack; but apparently a needed one, since many
vapoursynth filters insist on having a FPS set.
We need to apply the FPS override before creating the filters. Also
change some terminal output related to the FPS value.
Most of this is explained in the code comments. This change should
improve performance with vapoursynth, especially if concurrent requests
are used.
This should change nothing if vf_vapoursynth is not in the filter chain,
since non-threaded filters obviously can not asynchronously finish
filtering of frames.
This adds API to libmpv that lets host applications use the mpv opengl
renderer. This is a more flexible (and possibly more portable) option to
foreign window embedding (via --wid).
This assumes that methods like context sharing and multithreaded OpenGL
rendering are infeasible, and that a way is needed to integrate it with
an application that uses a single thread to render everything.
Add an example that does this with QtQuick/qml. The example is
relatively lazy, but still shows how relatively simple the integration
is. The FBO indirection could probably be avoided, but would require
more work (and would probably lead to worse QtQuick integration, because
it would have to ignore transformations like rotation).
Because this makes mpv directly use the host application's OpenGL
context, there is no platform specific code involved in mpv, except
for hw decoding interop.
main.qml is derived from some Qt example.
The following things are still missing:
- a way to do better video timing
- expose GL renderer options, allow changing them at runtime
- support for color equalizer controls
- support for screenshots
It feels strange that seeking past EOF with --keep-open actually leaves
the player at a random position. You can't even unpause, because the
demuxer is in the EOF state, and what you see on screen is just what was
around before the seek.
Improve this by attempting to seek to the last video frame if EOF
happens. We explicitly don't do this if EOF was reached normally to
increase robustness (if the VO got a frame since the last seek, it
obviously means we had normal playback before EOF).
If an error happens when trying to find the last frame (such as not
actually finding a last frame because e.g. the demuxer misbehaves), this
will probably turn your CPU into a heater. There is no logic to prevent
reinitiating the last-frame search if the last-frame search reached EOF.
(Pausing usually prevents that EOF is reached again after a successful
last-frame search.)
Fixes#819.
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.
This was shown only if decoder-framedropping was enabled, and only if at
least 50 frames were dropped by it. Since drop_frame_cnt used to mean
"number of late frames", this code made sense, but this is not the case
anymore: drop_frame_cnt can be even 0, all while video gets hopelessly
behind audio.
One problem with this is that short desync spikes (which usually can
probably dealt with) will also cause this message to be shown. If it
gets triggered too often, the code will need to be adjusted.
The player was supposed to exit playback if both video and audio failed
to initialize (or if one of the streams was not selected when the other
stream failed). This didn't work; for one this check was missing from
one of the failure paths. And more importantly, both checked the
current_track array incorrectly.
Fix these issues, and move the failure handling code into a common
function.
CC: @mpv-player/stable
This could produce an extra frame, because reaching the maximum merely
signals the playloop to exit, without strictly enforcing the limit.
Fixes#1181.
CC: @mpv-player/stable
For cover art, we pretend that the video stream is infinite, but also
stop decoding once we have an image on the VO (this seems advantageous
for the case when strange filters are inserted or the VO image gets
lost). Since a while ago, the video chain started decoding 2 images
though ("Non-monotonic video pts: 0.000000 <= 0.000000"), which is
annoying and wasteful.
Improve this by handling a certain corner case at initialization, which
will decode a second image while the first one is still stuck in the
filter chain. Also, just in case there are filters which buffer a lot,
also force EOF filtering (which means we tell the filters to flush
buffered frames).
CC: @mpv-player/stable
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().
wm4
Marcin Kurczewski
Julian