2013-10-29 21:38:29 +00:00
|
|
|
/*
|
2015-04-13 07:36:54 +00:00
|
|
|
* This file is part of mpv.
|
2013-10-29 21:38:29 +00:00
|
|
|
*
|
player: change license of most core files to LGPL
These files have all in common that they were fully or mostly taken from
mplayer.c. (mplayer.c was a huge file that contains almost all of the
playback core, until it was split into multiple parts.) This was
probably the hardest part to relicense, because so much code was moved
around all the time.
player/audio.c still does not compile. We'll have to redo audio
filtering. Once that is done, we can probably actually provide an
actual LGPL configure switch.
Here is a relatively detailed list of potential issues:
8d190244: author did not reply, parts were made GPL-only in a previous
commit.
7882ea9b: author could not be reached, but the code is gone. wscript
still has --datadir switch, but I don't think this is relevant to
copyright.
f197efd5: unclear origin, but I consider the code gone anyway (replaced
with generic OSD mechanisms).
8337d9c2: author did not reply, but only the option still exists (under
a different name), other code was removed.
d8fd7131: did not reply. Disabled in a previous commit.
05258251: same author as above. Both fields actually seem to have
vanished (even when tracking renames), so no action taken.
d459e644, 268b2c1a: author did not reply, but we reuse only the options
(with different names and slightly or fully different semantics, and
completely different implementations), so I don't think this is relevant
for copyright.
09e742fe, 17c39c4e: same as above.
e8a173de, bff4b3ee: author could not be reached. The commands were
reworked to properties, and the code outside of the TV code were moved
back to the TV code. So I don't think copyright applies to the current
command.c parts (mp_property_tv_color, mp_property_tv_freq,
mp_property_tv_scan). The TV parts remain GPL.
0810e427: could not be reached. Disabled in a previous commit.
43744a2d: unknown author, but this was replaced by dynamic alloc (if the
change is even copyrightable).
116ca0c7: unknown author; reasoning see input.c relicensing commit.
e7e4d1d8: these semantics still exist, but as generic code, and this
code was fully removed.
f1175cd9: the author of the cited patch is unknown, and upon inspection
it turns out that I was only using the idea to pause the player on EOF,
so I claim it's not copyright relevant.
25affdcc: author could not be reached (yet) - but it's only a function
rename, not copyrightable.
5728504c was committed by Arpi (who agreed), but hints that it might be
by a different author. In fact it seems to be mostly this patch:
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2001-November/002041.html
The author did not respond, but it all seems to have been removed later.
It's a terrible mess though. Arpi reverted the A-V sync code at first,
but left the RTC code for a while. The following commits remove these
changes 100%: 14b35442, 7181a091, 31482783, 614f8475, df58e822.
cehoyos did explicitly not agree to LGPL, but was involved in the
following changes:
c99d8fc8: applied a patch and didn't modify it, the original author
agreed.
40ac0d31: author could not be reached, but all code is gone anyway. The
"af" command has a similar function, but works completely different and
actually reuses a mechanism older than this patch.
54350436: applied a patch, but didn't modify it, except for adding a
German translation, which was removed later.
a2dda036: same situation as above
240b743e: this was made GPL-only in a previous commit
7b25afd7: same as above (for now)
kirijua could not be reached, but was a regular patch contributor:
c2c997fd: video equalizer code move; probably not copyrightable. Is GPL
due to Nick anyway.
be54f481: technically, this became the audio track property later. But
all what is left is the fact that you pass a track ID to it, so consider
the original coypright non-relevant.
2f376d1b: this was rewritten in b7052b43, but for now we can afford to
be careful, so this was marked as GPL only in a previous commit.
43844d09: remaining parts in main.c were reverted in a previous commit.
anders has mostly disagreed with the LGPL relicensing. Does not want
libaf to become LGPL, but made some concessions. In particular, he
granted us permission to relicense 4943e9c52c and 242aa6ebd4. We also
consider some of his changes remaining in mpv not relevant for copyright
(such as 735de602 - we won't remove the this option completely). We will
completely remove his other contributions, including the entire audio
filter chain. For now, this stuff is marked as GPL only. The remaining
question is how much code in player/audio.c (based on the former
mplayer.c and dec_audio.c) is under his copyright. I made claims about
this in a previous commit.
Nick(ols) Kurshev, svn username "nick" and "nickols_k", could not be
reached. He had a lot of changes in early MPlayer. It seems all of that
was removed, at least in mpv. His main work, like VIDIX or libswscale
work, does not exist in mpv anymore, but the changes to mplayer.c and
other core parts still deserve attention:
a4119f6b, fb927549, ad3529b8, e11b23dc, 5f2178be, 93c371d5: removed in
b43d67e0, d1628d12, 24ed01fe, df58e822.
0a83c6ec, 104c125e, 4e067f62, aec5dcc8, b587a3d6, f3de6e6b: DR, VAA, and
"tune" stuff was fully removed later on or replaced with other
mechanisms.
340183b0: screenshots were redone later (the VOCTRL was even removed,
with an independent implementation using the same VOCTRL a few years
later), so not relevant anymore. Basically only the 's' shortcut remains
(but not its implementation).
92c5c274, bffd4007, 555c6766: for now marked as GPL only in a previous
commit.
Might contain some trace amounts of "michael"'s copyright, who agreed to
LGPL only once the core is relicensed. This will still be respected, but
I don't think it matters at this in this case. (Some code touched by him
was merged into mplayer.c, and then disappeared after heavy
refactoring.)
I tried to be as careful and as complete as possible. It can't be
excluded that amends to this will be made later.
This does not make the player LGPL yet.
2017-06-23 13:53:41 +00:00
|
|
|
* mpv is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
2013-10-29 21:38:29 +00:00
|
|
|
*
|
2015-04-13 07:36:54 +00:00
|
|
|
* mpv is distributed in the hope that it will be useful,
|
2013-10-29 21:38:29 +00:00
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
player: change license of most core files to LGPL
These files have all in common that they were fully or mostly taken from
mplayer.c. (mplayer.c was a huge file that contains almost all of the
playback core, until it was split into multiple parts.) This was
probably the hardest part to relicense, because so much code was moved
around all the time.
player/audio.c still does not compile. We'll have to redo audio
filtering. Once that is done, we can probably actually provide an
actual LGPL configure switch.
Here is a relatively detailed list of potential issues:
8d190244: author did not reply, parts were made GPL-only in a previous
commit.
7882ea9b: author could not be reached, but the code is gone. wscript
still has --datadir switch, but I don't think this is relevant to
copyright.
f197efd5: unclear origin, but I consider the code gone anyway (replaced
with generic OSD mechanisms).
8337d9c2: author did not reply, but only the option still exists (under
a different name), other code was removed.
d8fd7131: did not reply. Disabled in a previous commit.
05258251: same author as above. Both fields actually seem to have
vanished (even when tracking renames), so no action taken.
d459e644, 268b2c1a: author did not reply, but we reuse only the options
(with different names and slightly or fully different semantics, and
completely different implementations), so I don't think this is relevant
for copyright.
09e742fe, 17c39c4e: same as above.
e8a173de, bff4b3ee: author could not be reached. The commands were
reworked to properties, and the code outside of the TV code were moved
back to the TV code. So I don't think copyright applies to the current
command.c parts (mp_property_tv_color, mp_property_tv_freq,
mp_property_tv_scan). The TV parts remain GPL.
0810e427: could not be reached. Disabled in a previous commit.
43744a2d: unknown author, but this was replaced by dynamic alloc (if the
change is even copyrightable).
116ca0c7: unknown author; reasoning see input.c relicensing commit.
e7e4d1d8: these semantics still exist, but as generic code, and this
code was fully removed.
f1175cd9: the author of the cited patch is unknown, and upon inspection
it turns out that I was only using the idea to pause the player on EOF,
so I claim it's not copyright relevant.
25affdcc: author could not be reached (yet) - but it's only a function
rename, not copyrightable.
5728504c was committed by Arpi (who agreed), but hints that it might be
by a different author. In fact it seems to be mostly this patch:
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2001-November/002041.html
The author did not respond, but it all seems to have been removed later.
It's a terrible mess though. Arpi reverted the A-V sync code at first,
but left the RTC code for a while. The following commits remove these
changes 100%: 14b35442, 7181a091, 31482783, 614f8475, df58e822.
cehoyos did explicitly not agree to LGPL, but was involved in the
following changes:
c99d8fc8: applied a patch and didn't modify it, the original author
agreed.
40ac0d31: author could not be reached, but all code is gone anyway. The
"af" command has a similar function, but works completely different and
actually reuses a mechanism older than this patch.
54350436: applied a patch, but didn't modify it, except for adding a
German translation, which was removed later.
a2dda036: same situation as above
240b743e: this was made GPL-only in a previous commit
7b25afd7: same as above (for now)
kirijua could not be reached, but was a regular patch contributor:
c2c997fd: video equalizer code move; probably not copyrightable. Is GPL
due to Nick anyway.
be54f481: technically, this became the audio track property later. But
all what is left is the fact that you pass a track ID to it, so consider
the original coypright non-relevant.
2f376d1b: this was rewritten in b7052b43, but for now we can afford to
be careful, so this was marked as GPL only in a previous commit.
43844d09: remaining parts in main.c were reverted in a previous commit.
anders has mostly disagreed with the LGPL relicensing. Does not want
libaf to become LGPL, but made some concessions. In particular, he
granted us permission to relicense 4943e9c52c and 242aa6ebd4. We also
consider some of his changes remaining in mpv not relevant for copyright
(such as 735de602 - we won't remove the this option completely). We will
completely remove his other contributions, including the entire audio
filter chain. For now, this stuff is marked as GPL only. The remaining
question is how much code in player/audio.c (based on the former
mplayer.c and dec_audio.c) is under his copyright. I made claims about
this in a previous commit.
Nick(ols) Kurshev, svn username "nick" and "nickols_k", could not be
reached. He had a lot of changes in early MPlayer. It seems all of that
was removed, at least in mpv. His main work, like VIDIX or libswscale
work, does not exist in mpv anymore, but the changes to mplayer.c and
other core parts still deserve attention:
a4119f6b, fb927549, ad3529b8, e11b23dc, 5f2178be, 93c371d5: removed in
b43d67e0, d1628d12, 24ed01fe, df58e822.
0a83c6ec, 104c125e, 4e067f62, aec5dcc8, b587a3d6, f3de6e6b: DR, VAA, and
"tune" stuff was fully removed later on or replaced with other
mechanisms.
340183b0: screenshots were redone later (the VOCTRL was even removed,
with an independent implementation using the same VOCTRL a few years
later), so not relevant anymore. Basically only the 's' shortcut remains
(but not its implementation).
92c5c274, bffd4007, 555c6766: for now marked as GPL only in a previous
commit.
Might contain some trace amounts of "michael"'s copyright, who agreed to
LGPL only once the core is relicensed. This will still be respected, but
I don't think it matters at this in this case. (Some code touched by him
was merged into mplayer.c, and then disappeared after heavy
refactoring.)
I tried to be as careful and as complete as possible. It can't be
excluded that amends to this will be made later.
This does not make the player LGPL yet.
2017-06-23 13:53:41 +00:00
|
|
|
* GNU Lesser General Public License for more details.
|
2013-10-29 21:38:29 +00:00
|
|
|
*
|
player: change license of most core files to LGPL
These files have all in common that they were fully or mostly taken from
mplayer.c. (mplayer.c was a huge file that contains almost all of the
playback core, until it was split into multiple parts.) This was
probably the hardest part to relicense, because so much code was moved
around all the time.
player/audio.c still does not compile. We'll have to redo audio
filtering. Once that is done, we can probably actually provide an
actual LGPL configure switch.
Here is a relatively detailed list of potential issues:
8d190244: author did not reply, parts were made GPL-only in a previous
commit.
7882ea9b: author could not be reached, but the code is gone. wscript
still has --datadir switch, but I don't think this is relevant to
copyright.
f197efd5: unclear origin, but I consider the code gone anyway (replaced
with generic OSD mechanisms).
8337d9c2: author did not reply, but only the option still exists (under
a different name), other code was removed.
d8fd7131: did not reply. Disabled in a previous commit.
05258251: same author as above. Both fields actually seem to have
vanished (even when tracking renames), so no action taken.
d459e644, 268b2c1a: author did not reply, but we reuse only the options
(with different names and slightly or fully different semantics, and
completely different implementations), so I don't think this is relevant
for copyright.
09e742fe, 17c39c4e: same as above.
e8a173de, bff4b3ee: author could not be reached. The commands were
reworked to properties, and the code outside of the TV code were moved
back to the TV code. So I don't think copyright applies to the current
command.c parts (mp_property_tv_color, mp_property_tv_freq,
mp_property_tv_scan). The TV parts remain GPL.
0810e427: could not be reached. Disabled in a previous commit.
43744a2d: unknown author, but this was replaced by dynamic alloc (if the
change is even copyrightable).
116ca0c7: unknown author; reasoning see input.c relicensing commit.
e7e4d1d8: these semantics still exist, but as generic code, and this
code was fully removed.
f1175cd9: the author of the cited patch is unknown, and upon inspection
it turns out that I was only using the idea to pause the player on EOF,
so I claim it's not copyright relevant.
25affdcc: author could not be reached (yet) - but it's only a function
rename, not copyrightable.
5728504c was committed by Arpi (who agreed), but hints that it might be
by a different author. In fact it seems to be mostly this patch:
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2001-November/002041.html
The author did not respond, but it all seems to have been removed later.
It's a terrible mess though. Arpi reverted the A-V sync code at first,
but left the RTC code for a while. The following commits remove these
changes 100%: 14b35442, 7181a091, 31482783, 614f8475, df58e822.
cehoyos did explicitly not agree to LGPL, but was involved in the
following changes:
c99d8fc8: applied a patch and didn't modify it, the original author
agreed.
40ac0d31: author could not be reached, but all code is gone anyway. The
"af" command has a similar function, but works completely different and
actually reuses a mechanism older than this patch.
54350436: applied a patch, but didn't modify it, except for adding a
German translation, which was removed later.
a2dda036: same situation as above
240b743e: this was made GPL-only in a previous commit
7b25afd7: same as above (for now)
kirijua could not be reached, but was a regular patch contributor:
c2c997fd: video equalizer code move; probably not copyrightable. Is GPL
due to Nick anyway.
be54f481: technically, this became the audio track property later. But
all what is left is the fact that you pass a track ID to it, so consider
the original coypright non-relevant.
2f376d1b: this was rewritten in b7052b43, but for now we can afford to
be careful, so this was marked as GPL only in a previous commit.
43844d09: remaining parts in main.c were reverted in a previous commit.
anders has mostly disagreed with the LGPL relicensing. Does not want
libaf to become LGPL, but made some concessions. In particular, he
granted us permission to relicense 4943e9c52c and 242aa6ebd4. We also
consider some of his changes remaining in mpv not relevant for copyright
(such as 735de602 - we won't remove the this option completely). We will
completely remove his other contributions, including the entire audio
filter chain. For now, this stuff is marked as GPL only. The remaining
question is how much code in player/audio.c (based on the former
mplayer.c and dec_audio.c) is under his copyright. I made claims about
this in a previous commit.
Nick(ols) Kurshev, svn username "nick" and "nickols_k", could not be
reached. He had a lot of changes in early MPlayer. It seems all of that
was removed, at least in mpv. His main work, like VIDIX or libswscale
work, does not exist in mpv anymore, but the changes to mplayer.c and
other core parts still deserve attention:
a4119f6b, fb927549, ad3529b8, e11b23dc, 5f2178be, 93c371d5: removed in
b43d67e0, d1628d12, 24ed01fe, df58e822.
0a83c6ec, 104c125e, 4e067f62, aec5dcc8, b587a3d6, f3de6e6b: DR, VAA, and
"tune" stuff was fully removed later on or replaced with other
mechanisms.
340183b0: screenshots were redone later (the VOCTRL was even removed,
with an independent implementation using the same VOCTRL a few years
later), so not relevant anymore. Basically only the 's' shortcut remains
(but not its implementation).
92c5c274, bffd4007, 555c6766: for now marked as GPL only in a previous
commit.
Might contain some trace amounts of "michael"'s copyright, who agreed to
LGPL only once the core is relicensed. This will still be respected, but
I don't think it matters at this in this case. (Some code touched by him
was merged into mplayer.c, and then disappeared after heavy
refactoring.)
I tried to be as careful and as complete as possible. It can't be
excluded that amends to this will be made later.
This does not make the player LGPL yet.
2017-06-23 13:53:41 +00:00
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
|
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
|
2013-10-29 21:38:29 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <stddef.h>
|
|
|
|
|
#include <stdbool.h>
|
|
|
|
|
#include <inttypes.h>
|
|
|
|
|
#include <math.h>
|
|
|
|
|
#include <assert.h>
|
|
|
|
|
|
2016-01-11 18:03:40 +00:00
|
|
|
#include "mpv_talloc.h"
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2013-12-17 01:39:45 +00:00
|
|
|
#include "common/msg.h"
|
2013-12-17 01:02:25 +00:00
|
|
|
#include "options/options.h"
|
2014-04-20 21:54:13 +00:00
|
|
|
#include "options/m_config.h"
|
|
|
|
|
#include "options/m_option.h"
|
2013-12-17 01:39:45 +00:00
|
|
|
#include "common/common.h"
|
|
|
|
|
#include "common/encode.h"
|
2013-12-17 01:02:25 +00:00
|
|
|
#include "options/m_property.h"
|
2014-07-30 21:24:08 +00:00
|
|
|
#include "osdep/timer.h"
|
2013-10-29 21:38:29 +00:00
|
|
|
|
|
|
|
|
#include "audio/out/ao.h"
|
2017-09-21 10:48:30 +00:00
|
|
|
#include "audio/format.h"
|
2013-10-29 21:38:29 +00:00
|
|
|
#include "demux/demux.h"
|
|
|
|
|
#include "stream/stream.h"
|
2013-11-24 11:58:06 +00:00
|
|
|
#include "sub/osd.h"
|
2013-11-23 20:26:31 +00:00
|
|
|
#include "video/hwdec.h"
|
video: make decoder wrapper a filter
Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes
a source filter. vd.h mostly disappears, because mp_filter takes care of
the dataflow, but its remains are in struct mp_decoder_fns.
One goal is to simplify dataflow by letting the filter framework handle
it (or more accurately, using its conventions). One result is that the
decode calls disappear from video.c, because we simply connect the
decoder wrapper and the filter chain with mp_pin_connect().
Another goal is to eventually remove the code duplication between the
audio and video paths for this. This commit prepares for this by trying
to make f_decoder_wrapper.c extensible, so it can be used for audio as
well later.
Decoder framedropping changes a bit. It doesn't seem to be worse than
before, and it's an obscure feature, so I'm content with its new state.
Some special code that was apparently meant to avoid dropping too many
frames in a row is removed, though.
I'm not sure how the source code tree should be organized. For one,
video/decode/vd_lavc.c is the only file in its directory, which is a bit
annoying.
2018-01-28 09:08:45 +00:00
|
|
|
#include "filters/f_decoder_wrapper.h"
|
2013-10-29 21:38:29 +00:00
|
|
|
#include "video/out/vo.h"
|
|
|
|
|
|
2013-12-17 00:08:53 +00:00
|
|
|
#include "core.h"
|
2013-10-29 21:38:29 +00:00
|
|
|
#include "command.h"
|
2014-07-30 21:24:08 +00:00
|
|
|
#include "screenshot.h"
|
|
|
|
|
|
|
|
|
|
enum {
|
|
|
|
|
// update_video() - code also uses: <0 error, 0 eof, >0 progress
|
|
|
|
|
VD_ERROR = -1,
|
|
|
|
|
VD_EOF = 0, // end of file - no new output
|
|
|
|
|
VD_PROGRESS = 1, // progress, but no output; repeat call with no waiting
|
|
|
|
|
VD_NEW_FRAME = 2, // the call produced a new frame
|
|
|
|
|
VD_WAIT = 3, // no EOF, but no output; wait until wakeup
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const char av_desync_help_text[] =
|
2015-06-30 17:06:00 +00:00
|
|
|
"\n"
|
|
|
|
|
"Audio/Video desynchronisation detected! Possible reasons include too slow\n"
|
|
|
|
|
"hardware, temporary CPU spikes, broken drivers, and broken files. Audio\n"
|
|
|
|
|
"position will not match to the video (see A-V status field).\n"
|
2023-10-07 18:30:52 +00:00
|
|
|
"Consider trying `--profile=fast` and/or `--hwdec=auto-safe` as they may help.\n"
|
2015-06-30 17:06:00 +00:00
|
|
|
"\n";
|
2013-10-29 21:38:29 +00:00
|
|
|
|
video: rewrite filtering glue code
Get rid of the old vf.c code. Replace it with a generic filtering
framework, which can potentially handle more than just --vf. At least
reimplementing --af with this code is planned.
This changes some --vf semantics (including runtime behavior and the
"vf" command). The most important ones are listed in interface-changes.
vf_convert.c is renamed to f_swscale.c. It is now an internal filter
that can not be inserted by the user manually.
f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed
once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is
conceptually easy, but a big mess due to the data flow changes).
The existing filters are all changed heavily. The data flow of the new
filter framework is different. Especially EOF handling changes - EOF is
now a "frame" rather than a state, and must be passed through exactly
once.
Another major thing is that all filters must support dynamic format
changes. The filter reconfig() function goes away. (This sounds complex,
but since all filters need to handle EOF draining anyway, they can use
the same code, and it removes the mess with reconfig() having to predict
the output format, which completely breaks with libavfilter anyway.)
In addition, there is no automatic format negotiation or conversion.
libavfilter's primitive and insufficient API simply doesn't allow us to
do this in a reasonable way. Instead, filters can use f_autoconvert as
sub-filter, and tell it which formats they support. This filter will in
turn add actual conversion filters, such as f_swscale, to perform
necessary format changes.
vf_vapoursynth.c uses the same basic principle of operation as before,
but with worryingly different details in data flow. Still appears to
work.
The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are
heavily changed. Fortunately, they all used refqueue.c, which is for
sharing the data flow logic (especially for managing future/past
surfaces and such). It turns out it can be used to factor out most of
the data flow. Some of these filters accepted software input. Instead of
having ad-hoc upload code in each filter, surface upload is now
delegated to f_autoconvert, which can use f_hwupload to perform this.
Exporting VO capabilities is still a big mess (mp_stream_info stuff).
The D3D11 code drops the redundant image formats, and all code uses the
hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a
big mess for now.
f_async_queue is unused.
2018-01-16 10:53:44 +00:00
|
|
|
static bool recreate_video_filters(struct MPContext *mpctx)
|
2013-10-29 21:38:29 +00:00
|
|
|
{
|
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
2016-01-13 23:18:48 +00:00
|
|
|
struct vo_chain *vo_c = mpctx->vo_chain;
|
2016-01-17 17:07:50 +00:00
|
|
|
assert(vo_c);
|
2013-10-29 21:38:29 +00:00
|
|
|
|
video: rewrite filtering glue code
Get rid of the old vf.c code. Replace it with a generic filtering
framework, which can potentially handle more than just --vf. At least
reimplementing --af with this code is planned.
This changes some --vf semantics (including runtime behavior and the
"vf" command). The most important ones are listed in interface-changes.
vf_convert.c is renamed to f_swscale.c. It is now an internal filter
that can not be inserted by the user manually.
f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed
once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is
conceptually easy, but a big mess due to the data flow changes).
The existing filters are all changed heavily. The data flow of the new
filter framework is different. Especially EOF handling changes - EOF is
now a "frame" rather than a state, and must be passed through exactly
once.
Another major thing is that all filters must support dynamic format
changes. The filter reconfig() function goes away. (This sounds complex,
but since all filters need to handle EOF draining anyway, they can use
the same code, and it removes the mess with reconfig() having to predict
the output format, which completely breaks with libavfilter anyway.)
In addition, there is no automatic format negotiation or conversion.
libavfilter's primitive and insufficient API simply doesn't allow us to
do this in a reasonable way. Instead, filters can use f_autoconvert as
sub-filter, and tell it which formats they support. This filter will in
turn add actual conversion filters, such as f_swscale, to perform
necessary format changes.
vf_vapoursynth.c uses the same basic principle of operation as before,
but with worryingly different details in data flow. Still appears to
work.
The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are
heavily changed. Fortunately, they all used refqueue.c, which is for
sharing the data flow logic (especially for managing future/past
surfaces and such). It turns out it can be used to factor out most of
the data flow. Some of these filters accepted software input. Instead of
having ad-hoc upload code in each filter, surface upload is now
delegated to f_autoconvert, which can use f_hwupload to perform this.
Exporting VO capabilities is still a big mess (mp_stream_info stuff).
The D3D11 code drops the redundant image formats, and all code uses the
hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a
big mess for now.
f_async_queue is unused.
2018-01-16 10:53:44 +00:00
|
|
|
return mp_output_chain_update_filters(vo_c->filter, opts->vf_settings);
|
2013-10-29 21:38:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int reinit_video_filters(struct MPContext *mpctx)
|
|
|
|
|
{
|
2016-01-13 23:18:48 +00:00
|
|
|
struct vo_chain *vo_c = mpctx->vo_chain;
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2016-01-17 17:07:50 +00:00
|
|
|
if (!vo_c)
|
2014-03-30 17:21:54 +00:00
|
|
|
return 0;
|
2013-10-29 21:38:29 +00:00
|
|
|
|
video: rewrite filtering glue code
Get rid of the old vf.c code. Replace it with a generic filtering
framework, which can potentially handle more than just --vf. At least
reimplementing --af with this code is planned.
This changes some --vf semantics (including runtime behavior and the
"vf" command). The most important ones are listed in interface-changes.
vf_convert.c is renamed to f_swscale.c. It is now an internal filter
that can not be inserted by the user manually.
f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed
once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is
conceptually easy, but a big mess due to the data flow changes).
The existing filters are all changed heavily. The data flow of the new
filter framework is different. Especially EOF handling changes - EOF is
now a "frame" rather than a state, and must be passed through exactly
once.
Another major thing is that all filters must support dynamic format
changes. The filter reconfig() function goes away. (This sounds complex,
but since all filters need to handle EOF draining anyway, they can use
the same code, and it removes the mess with reconfig() having to predict
the output format, which completely breaks with libavfilter anyway.)
In addition, there is no automatic format negotiation or conversion.
libavfilter's primitive and insufficient API simply doesn't allow us to
do this in a reasonable way. Instead, filters can use f_autoconvert as
sub-filter, and tell it which formats they support. This filter will in
turn add actual conversion filters, such as f_swscale, to perform
necessary format changes.
vf_vapoursynth.c uses the same basic principle of operation as before,
but with worryingly different details in data flow. Still appears to
work.
The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are
heavily changed. Fortunately, they all used refqueue.c, which is for
sharing the data flow logic (especially for managing future/past
surfaces and such). It turns out it can be used to factor out most of
the data flow. Some of these filters accepted software input. Instead of
having ad-hoc upload code in each filter, surface upload is now
delegated to f_autoconvert, which can use f_hwupload to perform this.
Exporting VO capabilities is still a big mess (mp_stream_info stuff).
The D3D11 code drops the redundant image formats, and all code uses the
hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a
big mess for now.
f_async_queue is unused.
2018-01-16 10:53:44 +00:00
|
|
|
if (!recreate_video_filters(mpctx))
|
|
|
|
|
return -1;
|
2016-01-15 21:23:01 +00:00
|
|
|
|
2016-02-09 21:19:01 +00:00
|
|
|
mp_force_video_refresh(mpctx);
|
|
|
|
|
|
2016-01-15 21:23:01 +00:00
|
|
|
mp_notify(mpctx, MPV_EVENT_VIDEO_RECONFIG, NULL);
|
2014-03-30 17:21:54 +00:00
|
|
|
|
video: rewrite filtering glue code
Get rid of the old vf.c code. Replace it with a generic filtering
framework, which can potentially handle more than just --vf. At least
reimplementing --af with this code is planned.
This changes some --vf semantics (including runtime behavior and the
"vf" command). The most important ones are listed in interface-changes.
vf_convert.c is renamed to f_swscale.c. It is now an internal filter
that can not be inserted by the user manually.
f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed
once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is
conceptually easy, but a big mess due to the data flow changes).
The existing filters are all changed heavily. The data flow of the new
filter framework is different. Especially EOF handling changes - EOF is
now a "frame" rather than a state, and must be passed through exactly
once.
Another major thing is that all filters must support dynamic format
changes. The filter reconfig() function goes away. (This sounds complex,
but since all filters need to handle EOF draining anyway, they can use
the same code, and it removes the mess with reconfig() having to predict
the output format, which completely breaks with libavfilter anyway.)
In addition, there is no automatic format negotiation or conversion.
libavfilter's primitive and insufficient API simply doesn't allow us to
do this in a reasonable way. Instead, filters can use f_autoconvert as
sub-filter, and tell it which formats they support. This filter will in
turn add actual conversion filters, such as f_swscale, to perform
necessary format changes.
vf_vapoursynth.c uses the same basic principle of operation as before,
but with worryingly different details in data flow. Still appears to
work.
The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are
heavily changed. Fortunately, they all used refqueue.c, which is for
sharing the data flow logic (especially for managing future/past
surfaces and such). It turns out it can be used to factor out most of
the data flow. Some of these filters accepted software input. Instead of
having ad-hoc upload code in each filter, surface upload is now
delegated to f_autoconvert, which can use f_hwupload to perform this.
Exporting VO capabilities is still a big mess (mp_stream_info stuff).
The D3D11 code drops the redundant image formats, and all code uses the
hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a
big mess for now.
f_async_queue is unused.
2018-01-16 10:53:44 +00:00
|
|
|
return 0;
|
2016-01-13 23:18:48 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void vo_chain_reset_state(struct vo_chain *vo_c)
|
|
|
|
|
{
|
|
|
|
|
vo_seek_reset(vo_c->vo);
|
player: partially rework --cache-pause
The --cache-pause feature (enabled by default) will pause playback for a
while if network runs out of data. If this is not done, then playback
will go on frame-wise (as packets are slowly read from the network and
then instantly decoded and displayed). This feature is actually useless,
as you won't get nice playback no matter what if network is too slow,
but I guess I still prefer this behavior for some reason.
This commit changes this behavior from using the demuxer cache state
only, to trying to use underrun information from the AO/VO. This means
if you have a very large audio buffer, then cache-pausing will trigger
once that buffer is depleted, which will be some time _after_ the
demuxer cache has run out.
This requires explicit support from the AO. Otherwise, the behavior
should be mostly the same as before this commit.
This does not care about the AO buffer. In theory, the AO may underrun,
then the player will write some data to the AO buffer, then the AO will
recover and play this bit of data, then the player will probably trigger
the cache-pause behavior. The probability of this happening should be
pretty low, so I will hold off fixing this until the next refactor of
the AO chain (if ever).
The VO underflow detection was devised and tested in 5 minutes, and may
not be correct. At least I'm fairly sure that the combination of all the
factors should make incorrect behavior relatively unlikely, but problems
are possible.
Also, the demux_reader_state.underrun field may be inaccurate. It's only
the present state at the time demux_get_reader_state() was called, and
may exclude past underruns. In theory, this could cause "close" cases to
be missed. Then you might get an audio underrun without cache-pausing
acting on it. If the stars align, this could happen multiple times in
the row, effectively making this feature not work.
The most user-visible consequence of this change is that the user
will now see an AO underrun warning every time the cache runs out.
Maybe this cache-pause feature should just be removed...
2019-10-11 17:34:04 +00:00
|
|
|
vo_c->underrun = false;
|
2019-12-16 00:15:43 +00:00
|
|
|
vo_c->underrun_signaled = false;
|
2013-10-29 21:38:29 +00:00
|
|
|
}
|
|
|
|
|
|
2014-07-30 21:01:55 +00:00
|
|
|
void reset_video_state(struct MPContext *mpctx)
|
|
|
|
|
{
|
2019-06-03 00:05:52 +00:00
|
|
|
if (mpctx->vo_chain) {
|
2016-01-13 23:18:48 +00:00
|
|
|
vo_chain_reset_state(mpctx->vo_chain);
|
2019-06-03 00:05:52 +00:00
|
|
|
struct track *t = mpctx->vo_chain->track;
|
|
|
|
|
if (t && t->dec)
|
f_decoder_wrapper: replace most public fields with setters/getters
I may (optionally) move decoding to a separate thread in a future
change. It's a bit attractive to move the entire decoder wrapper to
there, so if the demuxer has a new packet, it doesn't have to wake up
the main thread, and can directly wake up the decoder. (Although that's
bullshit, since there's a queue in between, and libavcodec's
multi-threaded decoding plays cross-threads ping pong with packets
anyway. On the other hand, the main thread would still have to shuffle
the packets around, so whatever, just seems like better design.)
As preparation, there shouldn't be any mutable state exposed by the
wrapper. But there's still a large number of corner-caseish crap, so
just use setters/getters for them. This recorder thing will inherently
not work, so it'll have to be disabled if threads are used.
This is a bit painful, but probably still the right thing. Like
speculatively pulling teeth.
2020-02-28 20:17:55 +00:00
|
|
|
mp_decoder_wrapper_set_play_dir(t->dec, mpctx->play_dir);
|
2019-06-03 00:05:52 +00:00
|
|
|
}
|
2014-07-30 21:01:55 +00:00
|
|
|
|
2015-07-01 17:22:40 +00:00
|
|
|
for (int n = 0; n < mpctx->num_next_frames; n++)
|
|
|
|
|
mp_image_unrefp(&mpctx->next_frames[n]);
|
|
|
|
|
mpctx->num_next_frames = 0;
|
2014-12-07 01:47:09 +00:00
|
|
|
mp_image_unrefp(&mpctx->saved_frame);
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
|
2014-07-30 21:01:55 +00:00
|
|
|
mpctx->delay = 0;
|
|
|
|
|
mpctx->time_frame = 0;
|
2014-08-22 12:20:00 +00:00
|
|
|
mpctx->video_pts = MP_NOPTS_VALUE;
|
2016-12-21 17:18:24 +00:00
|
|
|
mpctx->last_frame_duration = 0;
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
mpctx->num_past_frames = 0;
|
2014-07-30 21:01:55 +00:00
|
|
|
mpctx->total_avsync_change = 0;
|
2015-05-24 18:57:31 +00:00
|
|
|
mpctx->last_av_difference = 0;
|
2015-10-30 13:05:41 +00:00
|
|
|
mpctx->mistimed_frames_total = 0;
|
2014-07-30 21:01:55 +00:00
|
|
|
mpctx->drop_message_shown = 0;
|
2015-08-10 16:43:25 +00:00
|
|
|
mpctx->display_sync_drift_dir = 0;
|
2023-11-05 18:37:16 +00:00
|
|
|
mpctx->display_sync_error = 0;
|
2014-07-30 21:01:55 +00:00
|
|
|
|
2016-01-17 17:07:50 +00:00
|
|
|
mpctx->video_status = mpctx->vo_chain ? STATUS_SYNCING : STATUS_EOF;
|
2014-07-30 21:01:55 +00:00
|
|
|
}
|
|
|
|
|
|
2014-10-03 17:57:49 +00:00
|
|
|
void uninit_video_out(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
uninit_video_chain(mpctx);
|
2015-09-22 09:19:39 +00:00
|
|
|
if (mpctx->video_out) {
|
2014-10-03 17:57:49 +00:00
|
|
|
vo_destroy(mpctx->video_out);
|
2015-09-22 09:19:39 +00:00
|
|
|
mp_notify(mpctx, MPV_EVENT_VIDEO_RECONFIG, NULL);
|
|
|
|
|
}
|
2014-10-03 17:57:49 +00:00
|
|
|
mpctx->video_out = NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2016-01-13 23:18:48 +00:00
|
|
|
static void vo_chain_uninit(struct vo_chain *vo_c)
|
|
|
|
|
{
|
2016-02-05 22:19:56 +00:00
|
|
|
struct track *track = vo_c->track;
|
|
|
|
|
if (track) {
|
|
|
|
|
assert(track->vo_c == vo_c);
|
|
|
|
|
track->vo_c = NULL;
|
video: make decoder wrapper a filter
Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes
a source filter. vd.h mostly disappears, because mp_filter takes care of
the dataflow, but its remains are in struct mp_decoder_fns.
One goal is to simplify dataflow by letting the filter framework handle
it (or more accurately, using its conventions). One result is that the
decode calls disappear from video.c, because we simply connect the
decoder wrapper and the filter chain with mp_pin_connect().
Another goal is to eventually remove the code duplication between the
audio and video paths for this. This commit prepares for this by trying
to make f_decoder_wrapper.c extensible, so it can be used for audio as
well later.
Decoder framedropping changes a bit. It doesn't seem to be worse than
before, and it's an obscure feature, so I'm content with its new state.
Some special code that was apparently meant to avoid dropping too many
frames in a row is removed, though.
I'm not sure how the source code tree should be organized. For one,
video/decode/vd_lavc.c is the only file in its directory, which is a bit
annoying.
2018-01-28 09:08:45 +00:00
|
|
|
if (vo_c->dec_src)
|
|
|
|
|
assert(track->dec->f->pins[0] == vo_c->dec_src);
|
|
|
|
|
talloc_free(track->dec->f);
|
|
|
|
|
track->dec = NULL;
|
2016-02-05 22:19:56 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (vo_c->filter_src)
|
2018-01-26 03:36:47 +00:00
|
|
|
mp_pin_disconnect(vo_c->filter_src);
|
2016-02-05 22:19:56 +00:00
|
|
|
|
video: rewrite filtering glue code
Get rid of the old vf.c code. Replace it with a generic filtering
framework, which can potentially handle more than just --vf. At least
reimplementing --af with this code is planned.
This changes some --vf semantics (including runtime behavior and the
"vf" command). The most important ones are listed in interface-changes.
vf_convert.c is renamed to f_swscale.c. It is now an internal filter
that can not be inserted by the user manually.
f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed
once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is
conceptually easy, but a big mess due to the data flow changes).
The existing filters are all changed heavily. The data flow of the new
filter framework is different. Especially EOF handling changes - EOF is
now a "frame" rather than a state, and must be passed through exactly
once.
Another major thing is that all filters must support dynamic format
changes. The filter reconfig() function goes away. (This sounds complex,
but since all filters need to handle EOF draining anyway, they can use
the same code, and it removes the mess with reconfig() having to predict
the output format, which completely breaks with libavfilter anyway.)
In addition, there is no automatic format negotiation or conversion.
libavfilter's primitive and insufficient API simply doesn't allow us to
do this in a reasonable way. Instead, filters can use f_autoconvert as
sub-filter, and tell it which formats they support. This filter will in
turn add actual conversion filters, such as f_swscale, to perform
necessary format changes.
vf_vapoursynth.c uses the same basic principle of operation as before,
but with worryingly different details in data flow. Still appears to
work.
The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are
heavily changed. Fortunately, they all used refqueue.c, which is for
sharing the data flow logic (especially for managing future/past
surfaces and such). It turns out it can be used to factor out most of
the data flow. Some of these filters accepted software input. Instead of
having ad-hoc upload code in each filter, surface upload is now
delegated to f_autoconvert, which can use f_hwupload to perform this.
Exporting VO capabilities is still a big mess (mp_stream_info stuff).
The D3D11 code drops the redundant image formats, and all code uses the
hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a
big mess for now.
f_async_queue is unused.
2018-01-16 10:53:44 +00:00
|
|
|
talloc_free(vo_c->filter->f);
|
2016-01-13 23:18:48 +00:00
|
|
|
talloc_free(vo_c);
|
2016-01-16 20:19:52 +00:00
|
|
|
// this does not free the VO
|
2016-01-13 23:18:48 +00:00
|
|
|
}
|
|
|
|
|
|
2014-10-03 17:57:49 +00:00
|
|
|
void uninit_video_chain(struct MPContext *mpctx)
|
|
|
|
|
{
|
2016-01-17 17:07:50 +00:00
|
|
|
if (mpctx->vo_chain) {
|
2014-10-03 17:57:49 +00:00
|
|
|
reset_video_state(mpctx);
|
2016-01-13 23:18:48 +00:00
|
|
|
vo_chain_uninit(mpctx->vo_chain);
|
|
|
|
|
mpctx->vo_chain = NULL;
|
2016-02-05 22:19:56 +00:00
|
|
|
|
2014-10-03 17:57:49 +00:00
|
|
|
mpctx->video_status = STATUS_EOF;
|
2016-02-25 21:44:50 +00:00
|
|
|
|
2015-09-22 09:19:39 +00:00
|
|
|
mp_notify(mpctx, MPV_EVENT_VIDEO_RECONFIG, NULL);
|
2014-10-03 17:57:49 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-05 20:50:37 +00:00
|
|
|
int init_video_decoder(struct MPContext *mpctx, struct track *track)
|
|
|
|
|
{
|
video: make decoder wrapper a filter
Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes
a source filter. vd.h mostly disappears, because mp_filter takes care of
the dataflow, but its remains are in struct mp_decoder_fns.
One goal is to simplify dataflow by letting the filter framework handle
it (or more accurately, using its conventions). One result is that the
decode calls disappear from video.c, because we simply connect the
decoder wrapper and the filter chain with mp_pin_connect().
Another goal is to eventually remove the code duplication between the
audio and video paths for this. This commit prepares for this by trying
to make f_decoder_wrapper.c extensible, so it can be used for audio as
well later.
Decoder framedropping changes a bit. It doesn't seem to be worse than
before, and it's an obscure feature, so I'm content with its new state.
Some special code that was apparently meant to avoid dropping too many
frames in a row is removed, though.
I'm not sure how the source code tree should be organized. For one,
video/decode/vd_lavc.c is the only file in its directory, which is a bit
annoying.
2018-01-28 09:08:45 +00:00
|
|
|
assert(!track->dec);
|
2016-02-05 20:50:37 +00:00
|
|
|
if (!track->stream)
|
|
|
|
|
goto err_out;
|
|
|
|
|
|
video: make decoder wrapper a filter
Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes
a source filter. vd.h mostly disappears, because mp_filter takes care of
the dataflow, but its remains are in struct mp_decoder_fns.
One goal is to simplify dataflow by letting the filter framework handle
it (or more accurately, using its conventions). One result is that the
decode calls disappear from video.c, because we simply connect the
decoder wrapper and the filter chain with mp_pin_connect().
Another goal is to eventually remove the code duplication between the
audio and video paths for this. This commit prepares for this by trying
to make f_decoder_wrapper.c extensible, so it can be used for audio as
well later.
Decoder framedropping changes a bit. It doesn't seem to be worse than
before, and it's an obscure feature, so I'm content with its new state.
Some special code that was apparently meant to avoid dropping too many
frames in a row is removed, though.
I'm not sure how the source code tree should be organized. For one,
video/decode/vd_lavc.c is the only file in its directory, which is a bit
annoying.
2018-01-28 09:08:45 +00:00
|
|
|
struct mp_filter *parent = mpctx->filter_root;
|
2016-09-09 08:59:09 +00:00
|
|
|
|
video: make decoder wrapper a filter
Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes
a source filter. vd.h mostly disappears, because mp_filter takes care of
the dataflow, but its remains are in struct mp_decoder_fns.
One goal is to simplify dataflow by letting the filter framework handle
it (or more accurately, using its conventions). One result is that the
decode calls disappear from video.c, because we simply connect the
decoder wrapper and the filter chain with mp_pin_connect().
Another goal is to eventually remove the code duplication between the
audio and video paths for this. This commit prepares for this by trying
to make f_decoder_wrapper.c extensible, so it can be used for audio as
well later.
Decoder framedropping changes a bit. It doesn't seem to be worse than
before, and it's an obscure feature, so I'm content with its new state.
Some special code that was apparently meant to avoid dropping too many
frames in a row is removed, though.
I'm not sure how the source code tree should be organized. For one,
video/decode/vd_lavc.c is the only file in its directory, which is a bit
annoying.
2018-01-28 09:08:45 +00:00
|
|
|
// If possible, set this as parent so the decoder gets the hwdec and DR
|
|
|
|
|
// interfaces.
|
2021-11-29 11:39:20 +00:00
|
|
|
// Note: We rely on being able to get rid of all references to the VO by
|
|
|
|
|
// destroying the VO chain. Thus, decoders not linked to vo_chain
|
|
|
|
|
// must not use the hwdec context.
|
video: make decoder wrapper a filter
Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes
a source filter. vd.h mostly disappears, because mp_filter takes care of
the dataflow, but its remains are in struct mp_decoder_fns.
One goal is to simplify dataflow by letting the filter framework handle
it (or more accurately, using its conventions). One result is that the
decode calls disappear from video.c, because we simply connect the
decoder wrapper and the filter chain with mp_pin_connect().
Another goal is to eventually remove the code duplication between the
audio and video paths for this. This commit prepares for this by trying
to make f_decoder_wrapper.c extensible, so it can be used for audio as
well later.
Decoder framedropping changes a bit. It doesn't seem to be worse than
before, and it's an obscure feature, so I'm content with its new state.
Some special code that was apparently meant to avoid dropping too many
frames in a row is removed, though.
I'm not sure how the source code tree should be organized. For one,
video/decode/vd_lavc.c is the only file in its directory, which is a bit
annoying.
2018-01-28 09:08:45 +00:00
|
|
|
if (track->vo_c)
|
|
|
|
|
parent = track->vo_c->filter->f;
|
2016-02-05 20:50:37 +00:00
|
|
|
|
video: make decoder wrapper a filter
Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes
a source filter. vd.h mostly disappears, because mp_filter takes care of
the dataflow, but its remains are in struct mp_decoder_fns.
One goal is to simplify dataflow by letting the filter framework handle
it (or more accurately, using its conventions). One result is that the
decode calls disappear from video.c, because we simply connect the
decoder wrapper and the filter chain with mp_pin_connect().
Another goal is to eventually remove the code duplication between the
audio and video paths for this. This commit prepares for this by trying
to make f_decoder_wrapper.c extensible, so it can be used for audio as
well later.
Decoder framedropping changes a bit. It doesn't seem to be worse than
before, and it's an obscure feature, so I'm content with its new state.
Some special code that was apparently meant to avoid dropping too many
frames in a row is removed, though.
I'm not sure how the source code tree should be organized. For one,
video/decode/vd_lavc.c is the only file in its directory, which is a bit
annoying.
2018-01-28 09:08:45 +00:00
|
|
|
track->dec = mp_decoder_wrapper_create(parent, track->stream);
|
|
|
|
|
if (!track->dec)
|
|
|
|
|
goto err_out;
|
2016-02-05 20:50:37 +00:00
|
|
|
|
video: make decoder wrapper a filter
Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes
a source filter. vd.h mostly disappears, because mp_filter takes care of
the dataflow, but its remains are in struct mp_decoder_fns.
One goal is to simplify dataflow by letting the filter framework handle
it (or more accurately, using its conventions). One result is that the
decode calls disappear from video.c, because we simply connect the
decoder wrapper and the filter chain with mp_pin_connect().
Another goal is to eventually remove the code duplication between the
audio and video paths for this. This commit prepares for this by trying
to make f_decoder_wrapper.c extensible, so it can be used for audio as
well later.
Decoder framedropping changes a bit. It doesn't seem to be worse than
before, and it's an obscure feature, so I'm content with its new state.
Some special code that was apparently meant to avoid dropping too many
frames in a row is removed, though.
I'm not sure how the source code tree should be organized. For one,
video/decode/vd_lavc.c is the only file in its directory, which is a bit
annoying.
2018-01-28 09:08:45 +00:00
|
|
|
if (!mp_decoder_wrapper_reinit(track->dec))
|
2016-02-05 20:50:37 +00:00
|
|
|
goto err_out;
|
|
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
|
|
err_out:
|
2016-02-05 22:19:56 +00:00
|
|
|
if (track->sink)
|
2018-01-26 03:36:47 +00:00
|
|
|
mp_pin_disconnect(track->sink);
|
2016-02-05 22:19:56 +00:00
|
|
|
track->sink = NULL;
|
2016-02-05 20:50:37 +00:00
|
|
|
error_on_track(mpctx, track);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-12 21:08:48 +00:00
|
|
|
void reinit_video_chain(struct MPContext *mpctx)
|
2016-02-05 22:19:56 +00:00
|
|
|
{
|
2017-08-12 21:08:48 +00:00
|
|
|
struct track *track = mpctx->current_track[0][STREAM_VIDEO];
|
|
|
|
|
if (!track || !track->stream) {
|
|
|
|
|
error_on_track(mpctx, track);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
reinit_video_chain_src(mpctx, track);
|
2016-02-05 22:19:56 +00:00
|
|
|
}
|
|
|
|
|
|
video: make decoder wrapper a filter
Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes
a source filter. vd.h mostly disappears, because mp_filter takes care of
the dataflow, but its remains are in struct mp_decoder_fns.
One goal is to simplify dataflow by letting the filter framework handle
it (or more accurately, using its conventions). One result is that the
decode calls disappear from video.c, because we simply connect the
decoder wrapper and the filter chain with mp_pin_connect().
Another goal is to eventually remove the code duplication between the
audio and video paths for this. This commit prepares for this by trying
to make f_decoder_wrapper.c extensible, so it can be used for audio as
well later.
Decoder framedropping changes a bit. It doesn't seem to be worse than
before, and it's an obscure feature, so I'm content with its new state.
Some special code that was apparently meant to avoid dropping too many
frames in a row is removed, though.
I'm not sure how the source code tree should be organized. For one,
video/decode/vd_lavc.c is the only file in its directory, which is a bit
annoying.
2018-01-28 09:08:45 +00:00
|
|
|
static void filter_update_subtitles(void *ctx, double pts)
|
|
|
|
|
{
|
|
|
|
|
struct MPContext *mpctx = ctx;
|
|
|
|
|
|
|
|
|
|
if (osd_get_render_subs_in_filter(mpctx->osd))
|
|
|
|
|
update_subtitles(mpctx, pts);
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-12 21:08:48 +00:00
|
|
|
// (track=NULL creates a blank chain, used for lavfi-complex)
|
|
|
|
|
void reinit_video_chain_src(struct MPContext *mpctx, struct track *track)
|
2013-10-29 21:38:29 +00:00
|
|
|
{
|
2016-01-13 23:18:48 +00:00
|
|
|
assert(!mpctx->vo_chain);
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2015-02-03 22:09:02 +00:00
|
|
|
if (!mpctx->video_out) {
|
2014-12-31 18:01:28 +00:00
|
|
|
struct vo_extra ex = {
|
|
|
|
|
.input_ctx = mpctx->input,
|
|
|
|
|
.osd = mpctx->osd,
|
|
|
|
|
.encode_lavc_ctx = mpctx->encode_lavc_ctx,
|
2016-09-16 12:23:54 +00:00
|
|
|
.wakeup_cb = mp_wakeup_core_cb,
|
|
|
|
|
.wakeup_ctx = mpctx,
|
2014-12-31 18:01:28 +00:00
|
|
|
};
|
|
|
|
|
mpctx->video_out = init_best_video_out(mpctx->global, &ex);
|
2013-10-29 21:38:29 +00:00
|
|
|
if (!mpctx->video_out) {
|
|
|
|
|
MP_FATAL(mpctx, "Error opening/initializing "
|
2016-12-08 17:08:04 +00:00
|
|
|
"the selected video_out (--vo) device.\n");
|
2014-10-28 15:19:07 +00:00
|
|
|
mpctx->error_playing = MPV_ERROR_VO_INIT_FAILED;
|
2013-10-29 21:38:29 +00:00
|
|
|
goto err_out;
|
|
|
|
|
}
|
|
|
|
|
mpctx->mouse_cursor_visible = true;
|
|
|
|
|
}
|
|
|
|
|
|
2013-11-09 23:49:13 +00:00
|
|
|
update_window_title(mpctx, true);
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2016-01-17 17:07:50 +00:00
|
|
|
struct vo_chain *vo_c = talloc_zero(NULL, struct vo_chain);
|
|
|
|
|
mpctx->vo_chain = vo_c;
|
|
|
|
|
vo_c->log = mpctx->log;
|
|
|
|
|
vo_c->vo = mpctx->video_out;
|
video: rewrite filtering glue code
Get rid of the old vf.c code. Replace it with a generic filtering
framework, which can potentially handle more than just --vf. At least
reimplementing --af with this code is planned.
This changes some --vf semantics (including runtime behavior and the
"vf" command). The most important ones are listed in interface-changes.
vf_convert.c is renamed to f_swscale.c. It is now an internal filter
that can not be inserted by the user manually.
f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed
once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is
conceptually easy, but a big mess due to the data flow changes).
The existing filters are all changed heavily. The data flow of the new
filter framework is different. Especially EOF handling changes - EOF is
now a "frame" rather than a state, and must be passed through exactly
once.
Another major thing is that all filters must support dynamic format
changes. The filter reconfig() function goes away. (This sounds complex,
but since all filters need to handle EOF draining anyway, they can use
the same code, and it removes the mess with reconfig() having to predict
the output format, which completely breaks with libavfilter anyway.)
In addition, there is no automatic format negotiation or conversion.
libavfilter's primitive and insufficient API simply doesn't allow us to
do this in a reasonable way. Instead, filters can use f_autoconvert as
sub-filter, and tell it which formats they support. This filter will in
turn add actual conversion filters, such as f_swscale, to perform
necessary format changes.
vf_vapoursynth.c uses the same basic principle of operation as before,
but with worryingly different details in data flow. Still appears to
work.
The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are
heavily changed. Fortunately, they all used refqueue.c, which is for
sharing the data flow logic (especially for managing future/past
surfaces and such). It turns out it can be used to factor out most of
the data flow. Some of these filters accepted software input. Instead of
having ad-hoc upload code in each filter, surface upload is now
delegated to f_autoconvert, which can use f_hwupload to perform this.
Exporting VO capabilities is still a big mess (mp_stream_info stuff).
The D3D11 code drops the redundant image formats, and all code uses the
hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a
big mess for now.
f_async_queue is unused.
2018-01-16 10:53:44 +00:00
|
|
|
vo_c->filter =
|
|
|
|
|
mp_output_chain_create(mpctx->filter_root, MP_OUTPUT_CHAIN_VIDEO);
|
|
|
|
|
mp_output_chain_set_vo(vo_c->filter, vo_c->vo);
|
video: make decoder wrapper a filter
Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes
a source filter. vd.h mostly disappears, because mp_filter takes care of
the dataflow, but its remains are in struct mp_decoder_fns.
One goal is to simplify dataflow by letting the filter framework handle
it (or more accurately, using its conventions). One result is that the
decode calls disappear from video.c, because we simply connect the
decoder wrapper and the filter chain with mp_pin_connect().
Another goal is to eventually remove the code duplication between the
audio and video paths for this. This commit prepares for this by trying
to make f_decoder_wrapper.c extensible, so it can be used for audio as
well later.
Decoder framedropping changes a bit. It doesn't seem to be worse than
before, and it's an obscure feature, so I'm content with its new state.
Some special code that was apparently meant to avoid dropping too many
frames in a row is removed, though.
I'm not sure how the source code tree should be organized. For one,
video/decode/vd_lavc.c is the only file in its directory, which is a bit
annoying.
2018-01-28 09:08:45 +00:00
|
|
|
vo_c->filter->update_subtitles = filter_update_subtitles;
|
|
|
|
|
vo_c->filter->update_subtitles_ctx = mpctx;
|
2016-01-17 17:07:50 +00:00
|
|
|
|
2017-08-12 21:08:48 +00:00
|
|
|
if (track) {
|
2016-02-05 22:19:56 +00:00
|
|
|
vo_c->track = track;
|
|
|
|
|
track->vo_c = vo_c;
|
|
|
|
|
if (!init_video_decoder(mpctx, track))
|
|
|
|
|
goto err_out;
|
|
|
|
|
|
video: make decoder wrapper a filter
Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes
a source filter. vd.h mostly disappears, because mp_filter takes care of
the dataflow, but its remains are in struct mp_decoder_fns.
One goal is to simplify dataflow by letting the filter framework handle
it (or more accurately, using its conventions). One result is that the
decode calls disappear from video.c, because we simply connect the
decoder wrapper and the filter chain with mp_pin_connect().
Another goal is to eventually remove the code duplication between the
audio and video paths for this. This commit prepares for this by trying
to make f_decoder_wrapper.c extensible, so it can be used for audio as
well later.
Decoder framedropping changes a bit. It doesn't seem to be worse than
before, and it's an obscure feature, so I'm content with its new state.
Some special code that was apparently meant to avoid dropping too many
frames in a row is removed, though.
I'm not sure how the source code tree should be organized. For one,
video/decode/vd_lavc.c is the only file in its directory, which is a bit
annoying.
2018-01-28 09:08:45 +00:00
|
|
|
vo_c->dec_src = track->dec->f->pins[0];
|
f_decoder_wrapper: replace most public fields with setters/getters
I may (optionally) move decoding to a separate thread in a future
change. It's a bit attractive to move the entire decoder wrapper to
there, so if the demuxer has a new packet, it doesn't have to wake up
the main thread, and can directly wake up the decoder. (Although that's
bullshit, since there's a queue in between, and libavcodec's
multi-threaded decoding plays cross-threads ping pong with packets
anyway. On the other hand, the main thread would still have to shuffle
the packets around, so whatever, just seems like better design.)
As preparation, there shouldn't be any mutable state exposed by the
wrapper. But there's still a large number of corner-caseish crap, so
just use setters/getters for them. This recorder thing will inherently
not work, so it'll have to be disabled if threads are used.
This is a bit painful, but probably still the right thing. Like
speculatively pulling teeth.
2020-02-28 20:17:55 +00:00
|
|
|
vo_c->filter->container_fps =
|
|
|
|
|
mp_decoder_wrapper_get_container_fps(track->dec);
|
2020-09-27 22:04:21 +00:00
|
|
|
vo_c->is_coverart = !!track->attached_picture;
|
player: dumb seeking related stuff, make audio hr-seek default
Try to deal with various corner cases. But when I fix one thing, another
thing breaks. (And it's 50/50 whether I find the breakage immediately or
a few months later.) So results may vary.
The default for--hr-seek is changed to "default" (not creative enough to
find a better name). In this mode, audio seeking is exact if there is no
video, or if the video has only a single frame. This change is actually
pretty dumb, since audio frames are usually small enough that exact
seeking does not really add much. But it gets rid of some weird special
cases.
Internally, the most important change is that is_coverart and is_sparse
handling is merged. is_sparse was originally just a special case for
weird .ts streams that have the corresponding low-level flag set. The
idea is that they're pretty similar anyway, so this would reduce the
number of corner cases. But I'm not sure if this doesn't break the
original intended use case for it (I don't have a sample anyway).
This changes last-frame handling, and respects the duration of the last
frame only if audio is disabled. This is mostly "coincidental" due to
the need to make seeking past EOF trigger player exit, and is caused by
setting STATUS_EOF early. On the other hand, this might have been this
way before (see removed chunk close to it).
2020-02-28 16:15:07 +00:00
|
|
|
vo_c->is_sparse = track->stream->still_image || vo_c->is_coverart;
|
2015-04-20 21:21:38 +00:00
|
|
|
|
2020-09-27 22:04:21 +00:00
|
|
|
if (vo_c->is_coverart)
|
|
|
|
|
mp_decoder_wrapper_set_coverart_flag(track->dec, true);
|
|
|
|
|
|
2016-02-05 22:19:56 +00:00
|
|
|
track->vo_c = vo_c;
|
|
|
|
|
vo_c->track = track;
|
video: make decoder wrapper a filter
Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes
a source filter. vd.h mostly disappears, because mp_filter takes care of
the dataflow, but its remains are in struct mp_decoder_fns.
One goal is to simplify dataflow by letting the filter framework handle
it (or more accurately, using its conventions). One result is that the
decode calls disappear from video.c, because we simply connect the
decoder wrapper and the filter chain with mp_pin_connect().
Another goal is to eventually remove the code duplication between the
audio and video paths for this. This commit prepares for this by trying
to make f_decoder_wrapper.c extensible, so it can be used for audio as
well later.
Decoder framedropping changes a bit. It doesn't seem to be worse than
before, and it's an obscure feature, so I'm content with its new state.
Some special code that was apparently meant to avoid dropping too many
frames in a row is removed, though.
I'm not sure how the source code tree should be organized. For one,
video/decode/vd_lavc.c is the only file in its directory, which is a bit
annoying.
2018-01-28 09:08:45 +00:00
|
|
|
|
|
|
|
|
mp_pin_connect(vo_c->filter->f->pins[0], vo_c->dec_src);
|
2016-02-05 22:19:56 +00:00
|
|
|
}
|
2016-01-17 17:07:50 +00:00
|
|
|
|
video: rewrite filtering glue code
Get rid of the old vf.c code. Replace it with a generic filtering
framework, which can potentially handle more than just --vf. At least
reimplementing --af with this code is planned.
This changes some --vf semantics (including runtime behavior and the
"vf" command). The most important ones are listed in interface-changes.
vf_convert.c is renamed to f_swscale.c. It is now an internal filter
that can not be inserted by the user manually.
f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed
once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is
conceptually easy, but a big mess due to the data flow changes).
The existing filters are all changed heavily. The data flow of the new
filter framework is different. Especially EOF handling changes - EOF is
now a "frame" rather than a state, and must be passed through exactly
once.
Another major thing is that all filters must support dynamic format
changes. The filter reconfig() function goes away. (This sounds complex,
but since all filters need to handle EOF draining anyway, they can use
the same code, and it removes the mess with reconfig() having to predict
the output format, which completely breaks with libavfilter anyway.)
In addition, there is no automatic format negotiation or conversion.
libavfilter's primitive and insufficient API simply doesn't allow us to
do this in a reasonable way. Instead, filters can use f_autoconvert as
sub-filter, and tell it which formats they support. This filter will in
turn add actual conversion filters, such as f_swscale, to perform
necessary format changes.
vf_vapoursynth.c uses the same basic principle of operation as before,
but with worryingly different details in data flow. Still appears to
work.
The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are
heavily changed. Fortunately, they all used refqueue.c, which is for
sharing the data flow logic (especially for managing future/past
surfaces and such). It turns out it can be used to factor out most of
the data flow. Some of these filters accepted software input. Instead of
having ad-hoc upload code in each filter, surface upload is now
delegated to f_autoconvert, which can use f_hwupload to perform this.
Exporting VO capabilities is still a big mess (mp_stream_info stuff).
The D3D11 code drops the redundant image formats, and all code uses the
hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a
big mess for now.
f_async_queue is unused.
2018-01-16 10:53:44 +00:00
|
|
|
if (!recreate_video_filters(mpctx))
|
|
|
|
|
goto err_out;
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2022-11-15 21:50:38 +00:00
|
|
|
update_content_type(mpctx, track);
|
2016-10-02 10:33:34 +00:00
|
|
|
update_screensaver_state(mpctx);
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2020-08-27 09:43:06 +00:00
|
|
|
vo_set_paused(vo_c->vo, get_internal_paused(mpctx));
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2014-07-30 21:01:55 +00:00
|
|
|
reset_video_state(mpctx);
|
2021-08-12 23:51:13 +00:00
|
|
|
term_osd_set_subs(mpctx, NULL);
|
2013-10-29 21:38:29 +00:00
|
|
|
|
2017-08-12 21:08:48 +00:00
|
|
|
return;
|
2013-10-29 21:38:29 +00:00
|
|
|
|
|
|
|
|
err_out:
|
2014-10-03 17:57:49 +00:00
|
|
|
uninit_video_chain(mpctx);
|
2016-02-05 22:41:44 +00:00
|
|
|
error_on_track(mpctx, track);
|
2013-10-29 21:38:29 +00:00
|
|
|
handle_force_window(mpctx, true);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Try to refresh the video by doing a precise seek to the currently displayed
|
|
|
|
|
// frame. This can go wrong in all sorts of ways, so use sparingly.
|
|
|
|
|
void mp_force_video_refresh(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
2016-01-16 20:19:52 +00:00
|
|
|
struct vo_chain *vo_c = mpctx->vo_chain;
|
2014-03-30 17:21:54 +00:00
|
|
|
|
video: rewrite filtering glue code
Get rid of the old vf.c code. Replace it with a generic filtering
framework, which can potentially handle more than just --vf. At least
reimplementing --af with this code is planned.
This changes some --vf semantics (including runtime behavior and the
"vf" command). The most important ones are listed in interface-changes.
vf_convert.c is renamed to f_swscale.c. It is now an internal filter
that can not be inserted by the user manually.
f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed
once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is
conceptually easy, but a big mess due to the data flow changes).
The existing filters are all changed heavily. The data flow of the new
filter framework is different. Especially EOF handling changes - EOF is
now a "frame" rather than a state, and must be passed through exactly
once.
Another major thing is that all filters must support dynamic format
changes. The filter reconfig() function goes away. (This sounds complex,
but since all filters need to handle EOF draining anyway, they can use
the same code, and it removes the mess with reconfig() having to predict
the output format, which completely breaks with libavfilter anyway.)
In addition, there is no automatic format negotiation or conversion.
libavfilter's primitive and insufficient API simply doesn't allow us to
do this in a reasonable way. Instead, filters can use f_autoconvert as
sub-filter, and tell it which formats they support. This filter will in
turn add actual conversion filters, such as f_swscale, to perform
necessary format changes.
vf_vapoursynth.c uses the same basic principle of operation as before,
but with worryingly different details in data flow. Still appears to
work.
The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are
heavily changed. Fortunately, they all used refqueue.c, which is for
sharing the data flow logic (especially for managing future/past
surfaces and such). It turns out it can be used to factor out most of
the data flow. Some of these filters accepted software input. Instead of
having ad-hoc upload code in each filter, surface upload is now
delegated to f_autoconvert, which can use f_hwupload to perform this.
Exporting VO capabilities is still a big mess (mp_stream_info stuff).
The D3D11 code drops the redundant image formats, and all code uses the
hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a
big mess for now.
f_async_queue is unused.
2018-01-16 10:53:44 +00:00
|
|
|
if (!vo_c)
|
2014-03-30 17:21:54 +00:00
|
|
|
return;
|
2013-10-29 21:38:29 +00:00
|
|
|
|
|
|
|
|
// If not paused, the next frame should come soon enough.
|
2017-08-14 12:02:13 +00:00
|
|
|
if (opts->pause || mpctx->time_frame >= 0.5 ||
|
|
|
|
|
mpctx->video_status == STATUS_EOF)
|
2015-07-10 16:07:39 +00:00
|
|
|
{
|
2017-08-14 12:02:13 +00:00
|
|
|
issue_refresh_seek(mpctx, MPSEEK_VERY_EXACT);
|
2015-03-04 16:21:05 +00:00
|
|
|
}
|
2013-10-29 21:38:29 +00:00
|
|
|
}
|
|
|
|
|
|
video: make decoder wrapper a filter
Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes
a source filter. vd.h mostly disappears, because mp_filter takes care of
the dataflow, but its remains are in struct mp_decoder_fns.
One goal is to simplify dataflow by letting the filter framework handle
it (or more accurately, using its conventions). One result is that the
decode calls disappear from video.c, because we simply connect the
decoder wrapper and the filter chain with mp_pin_connect().
Another goal is to eventually remove the code duplication between the
audio and video paths for this. This commit prepares for this by trying
to make f_decoder_wrapper.c extensible, so it can be used for audio as
well later.
Decoder framedropping changes a bit. It doesn't seem to be worse than
before, and it's an obscure feature, so I'm content with its new state.
Some special code that was apparently meant to avoid dropping too many
frames in a row is removed, though.
I'm not sure how the source code tree should be organized. For one,
video/decode/vd_lavc.c is the only file in its directory, which is a bit
annoying.
2018-01-28 09:08:45 +00:00
|
|
|
static void check_framedrop(struct MPContext *mpctx, struct vo_chain *vo_c)
|
2014-05-01 21:53:18 +00:00
|
|
|
{
|
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
|
|
|
|
// check for frame-drop:
|
2014-08-13 19:50:23 +00:00
|
|
|
if (mpctx->video_status == STATUS_PLAYING && !mpctx->paused &&
|
2016-01-29 21:46:28 +00:00
|
|
|
mpctx->audio_status == STATUS_PLAYING && !ao_untimed(mpctx->ao) &&
|
video: make decoder wrapper a filter
Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes
a source filter. vd.h mostly disappears, because mp_filter takes care of
the dataflow, but its remains are in struct mp_decoder_fns.
One goal is to simplify dataflow by letting the filter framework handle
it (or more accurately, using its conventions). One result is that the
decode calls disappear from video.c, because we simply connect the
decoder wrapper and the filter chain with mp_pin_connect().
Another goal is to eventually remove the code duplication between the
audio and video paths for this. This commit prepares for this by trying
to make f_decoder_wrapper.c extensible, so it can be used for audio as
well later.
Decoder framedropping changes a bit. It doesn't seem to be worse than
before, and it's an obscure feature, so I'm content with its new state.
Some special code that was apparently meant to avoid dropping too many
frames in a row is removed, though.
I'm not sure how the source code tree should be organized. For one,
video/decode/vd_lavc.c is the only file in its directory, which is a bit
annoying.
2018-01-28 09:08:45 +00:00
|
|
|
vo_c->track && vo_c->track->dec && (opts->frame_dropping & 2))
|
2014-05-01 21:53:18 +00:00
|
|
|
{
|
2018-02-01 08:20:25 +00:00
|
|
|
float fps = vo_c->filter->container_fps;
|
video: make decoder wrapper a filter
Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes
a source filter. vd.h mostly disappears, because mp_filter takes care of
the dataflow, but its remains are in struct mp_decoder_fns.
One goal is to simplify dataflow by letting the filter framework handle
it (or more accurately, using its conventions). One result is that the
decode calls disappear from video.c, because we simply connect the
decoder wrapper and the filter chain with mp_pin_connect().
Another goal is to eventually remove the code duplication between the
audio and video paths for this. This commit prepares for this by trying
to make f_decoder_wrapper.c extensible, so it can be used for audio as
well later.
Decoder framedropping changes a bit. It doesn't seem to be worse than
before, and it's an obscure feature, so I'm content with its new state.
Some special code that was apparently meant to avoid dropping too many
frames in a row is removed, though.
I'm not sure how the source code tree should be organized. For one,
video/decode/vd_lavc.c is the only file in its directory, which is a bit
annoying.
2018-01-28 09:08:45 +00:00
|
|
|
// it's a crappy heuristic; avoid getting upset by incorrect fps
|
|
|
|
|
if (fps <= 20 || fps >= 500)
|
|
|
|
|
return;
|
|
|
|
|
double frame_time = 1.0 / fps;
|
|
|
|
|
// try to drop as many frames as we appear to be behind
|
f_decoder_wrapper: replace most public fields with setters/getters
I may (optionally) move decoding to a separate thread in a future
change. It's a bit attractive to move the entire decoder wrapper to
there, so if the demuxer has a new packet, it doesn't have to wake up
the main thread, and can directly wake up the decoder. (Although that's
bullshit, since there's a queue in between, and libavcodec's
multi-threaded decoding plays cross-threads ping pong with packets
anyway. On the other hand, the main thread would still have to shuffle
the packets around, so whatever, just seems like better design.)
As preparation, there shouldn't be any mutable state exposed by the
wrapper. But there's still a large number of corner-caseish crap, so
just use setters/getters for them. This recorder thing will inherently
not work, so it'll have to be disabled if threads are used.
This is a bit painful, but probably still the right thing. Like
speculatively pulling teeth.
2020-02-28 20:17:55 +00:00
|
|
|
mp_decoder_wrapper_set_frame_drops(vo_c->track->dec,
|
|
|
|
|
MPCLAMP((mpctx->last_av_difference - 0.010) / frame_time, 0, 100));
|
2017-01-10 13:03:41 +00:00
|
|
|
}
|
video: display last frame, drain frames on video reconfig
Until now, the player didn't care to drain frames on video reconfig.
Instead, the VO was reconfigured (i.e. resized) before the queued frames
finished displaying. This can for example be observed by passing
multiple images with different size as mf:// filename. Then the window
would resize one frame before image with the new size is displayed. With
--vo=vdpau, the effect is worse, because this VO queues more than 1
frame internally.
Fix this by explicitly draining buffered frames before video reconfig.
Raise the display time of the last frame. Otherwise, the last frame
would be shown for a very short time only. This usually doesn't matter,
but helps when playing image files. This is a byproduct of frame
draining, because normally, video timing is based on the frames queued
to the VO, and we can't do that with frames of different size or format.
So we pretend that the frame before the change is the last frame in
order to time it. This code is incorrect though: it tries to use the
framerate, which often doesn't make sense. But it's good enough to test
this code with mf://.
2013-12-10 18:33:11 +00:00
|
|
|
}
|
|
|
|
|
|
2014-08-22 12:19:01 +00:00
|
|
|
/* Modify video timing to match the audio timeline. There are two main
|
|
|
|
|
* reasons this is needed. First, video and audio can start from different
|
|
|
|
|
* positions at beginning of file or after a seek (MPlayer starts both
|
|
|
|
|
* immediately even if they have different pts). Second, the file can have
|
|
|
|
|
* audio timestamps that are inconsistent with the duration of the audio
|
|
|
|
|
* packets, for example two consecutive timestamp values differing by
|
|
|
|
|
* one second but only a packet with enough samples for half a second
|
|
|
|
|
* of playback between them.
|
|
|
|
|
*/
|
|
|
|
|
static void adjust_sync(struct MPContext *mpctx, double v_pts, double frame_time)
|
2013-10-29 21:38:29 +00:00
|
|
|
{
|
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
2014-05-01 21:53:18 +00:00
|
|
|
|
player/video: loosen logic checks for adjust_sync
Previously, the av sync change calculation was only done if the
audio_status was STATUS_PLAYING, but there is at least one or two more
states where this should be done. player/audio is capable of adding
delay if the state is anything besides STATUS_EOF. This means that while
calling adjust_sync, the delay value could have changed from the audio
side of the equation from the previous playloop, and it doesn't
necessarily mean that the current audio_status is STATUS_PLAYING either.
So the old code would technically skip this case. In practice, this is
just one frame so it hardly matters, but it should be taken into
account. For example, STATUS_READY is definitely possible here in
adjust_sync. I'm not sure if it's actually possible for STATUS_SYNCING
to happen but the audio code can change add delay with that status, so
it doesn't hurt. STATUS_DRAINING is probably not relevant, but again
include it to mirror the audio code logic. Of course, STATUS_EOF is
obviously a no-no since that means no audio at all, so we return from
there. I didn't take hard measurements or anything, but this does seem
to result in slightly smaller av sync fluctuations on discontinuities
(like seeking) which makes sense because we're now making an additional
correction that wasn't previously done.
Another change is to always try adjust_sync as long as the frame_time is
nonzero. The old logic only did this if the video_status was playing or
greater, but it is possible to get new frames with a different PTS that
do not have that status. The audio is still playing so logically it
should be adjusted as well. Again, this happens for just one frame, so
it doesn't really matter in practice but it should make more sense. A
zero frame_time is skipped since that would mean the pts did not advance
and the previous playloop should have done the adjustment for that time
already.
2023-10-29 05:22:02 +00:00
|
|
|
if (mpctx->audio_status == STATUS_EOF)
|
2014-08-22 12:19:01 +00:00
|
|
|
return;
|
2014-05-01 23:28:52 +00:00
|
|
|
|
2023-10-24 03:57:53 +00:00
|
|
|
mpctx->delay -= frame_time;
|
2015-01-29 11:10:07 +00:00
|
|
|
double a_pts = written_audio_pts(mpctx) + opts->audio_delay - mpctx->delay;
|
2014-08-22 12:19:01 +00:00
|
|
|
double av_delay = a_pts - v_pts;
|
|
|
|
|
|
|
|
|
|
double change = av_delay * 0.1;
|
2016-10-20 18:20:23 +00:00
|
|
|
double factor = fabs(av_delay) < 0.3 ? 0.1 : 0.4;
|
2014-08-22 12:19:01 +00:00
|
|
|
double max_change = opts->default_max_pts_correction >= 0 ?
|
2016-10-20 18:20:23 +00:00
|
|
|
opts->default_max_pts_correction : frame_time * factor;
|
2014-08-22 12:19:01 +00:00
|
|
|
if (change < -max_change)
|
|
|
|
|
change = -max_change;
|
|
|
|
|
else if (change > max_change)
|
|
|
|
|
change = max_change;
|
|
|
|
|
mpctx->delay += change;
|
|
|
|
|
mpctx->total_avsync_change += change;
|
2015-10-27 19:56:58 +00:00
|
|
|
|
|
|
|
|
if (mpctx->display_sync_active)
|
|
|
|
|
mpctx->total_avsync_change = 0;
|
2013-10-29 21:38:29 +00:00
|
|
|
}
|
|
|
|
|
|
2015-07-01 17:22:40 +00:00
|
|
|
// Make the frame at position 0 "known" to the playback logic. This must happen
|
|
|
|
|
// only once for each frame, so this function has to be called carefully.
|
|
|
|
|
// Generally, if position 0 gets a new frame, this must be called.
|
|
|
|
|
static void handle_new_frame(struct MPContext *mpctx)
|
2015-03-25 12:33:34 +00:00
|
|
|
{
|
2015-07-01 17:22:40 +00:00
|
|
|
assert(mpctx->num_next_frames >= 1);
|
2015-03-25 12:33:34 +00:00
|
|
|
|
|
|
|
|
double frame_time = 0;
|
2015-07-01 17:22:40 +00:00
|
|
|
double pts = mpctx->next_frames[0]->pts;
|
2018-05-03 02:29:11 +00:00
|
|
|
bool is_sparse = mpctx->vo_chain && mpctx->vo_chain->is_sparse;
|
|
|
|
|
|
2015-03-25 12:33:34 +00:00
|
|
|
if (mpctx->video_pts != MP_NOPTS_VALUE) {
|
|
|
|
|
frame_time = pts - mpctx->video_pts;
|
2018-05-03 02:29:11 +00:00
|
|
|
double tolerance = mpctx->demuxer->ts_resets_possible &&
|
|
|
|
|
!is_sparse ? 5 : 1e4;
|
2015-05-20 12:24:55 +00:00
|
|
|
if (frame_time <= 0 || frame_time >= tolerance) {
|
|
|
|
|
// Assume a discontinuity.
|
2015-03-25 12:33:34 +00:00
|
|
|
MP_WARN(mpctx, "Invalid video timestamp: %f -> %f\n",
|
|
|
|
|
mpctx->video_pts, pts);
|
2015-12-04 15:55:55 +00:00
|
|
|
frame_time = 0;
|
2015-03-25 12:33:34 +00:00
|
|
|
}
|
|
|
|
|
}
|
2019-11-16 12:47:23 +00:00
|
|
|
mpctx->time_frame += frame_time / mpctx->video_speed;
|
player/video: loosen logic checks for adjust_sync
Previously, the av sync change calculation was only done if the
audio_status was STATUS_PLAYING, but there is at least one or two more
states where this should be done. player/audio is capable of adding
delay if the state is anything besides STATUS_EOF. This means that while
calling adjust_sync, the delay value could have changed from the audio
side of the equation from the previous playloop, and it doesn't
necessarily mean that the current audio_status is STATUS_PLAYING either.
So the old code would technically skip this case. In practice, this is
just one frame so it hardly matters, but it should be taken into
account. For example, STATUS_READY is definitely possible here in
adjust_sync. I'm not sure if it's actually possible for STATUS_SYNCING
to happen but the audio code can change add delay with that status, so
it doesn't hurt. STATUS_DRAINING is probably not relevant, but again
include it to mirror the audio code logic. Of course, STATUS_EOF is
obviously a no-no since that means no audio at all, so we return from
there. I didn't take hard measurements or anything, but this does seem
to result in slightly smaller av sync fluctuations on discontinuities
(like seeking) which makes sense because we're now making an additional
correction that wasn't previously done.
Another change is to always try adjust_sync as long as the frame_time is
nonzero. The old logic only did this if the video_status was playing or
greater, but it is possible to get new frames with a different PTS that
do not have that status. The audio is still playing so logically it
should be adjusted as well. Again, this happens for just one frame, so
it doesn't really matter in practice but it should make more sense. A
zero frame_time is skipped since that would mean the pts did not advance
and the previous playloop should have done the adjustment for that time
already.
2023-10-29 05:22:02 +00:00
|
|
|
if (frame_time)
|
2015-03-25 12:33:34 +00:00
|
|
|
adjust_sync(mpctx, pts, frame_time);
|
|
|
|
|
MP_TRACE(mpctx, "frametime=%5.3f\n", frame_time);
|
|
|
|
|
}
|
|
|
|
|
|
2015-07-01 17:24:28 +00:00
|
|
|
// Remove the first frame in mpctx->next_frames
|
|
|
|
|
static void shift_frames(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
if (mpctx->num_next_frames < 1)
|
|
|
|
|
return;
|
|
|
|
|
talloc_free(mpctx->next_frames[0]);
|
|
|
|
|
for (int n = 0; n < mpctx->num_next_frames - 1; n++)
|
|
|
|
|
mpctx->next_frames[n] = mpctx->next_frames[n + 1];
|
|
|
|
|
mpctx->num_next_frames -= 1;
|
|
|
|
|
}
|
|
|
|
|
|
player: dumb seeking related stuff, make audio hr-seek default
Try to deal with various corner cases. But when I fix one thing, another
thing breaks. (And it's 50/50 whether I find the breakage immediately or
a few months later.) So results may vary.
The default for--hr-seek is changed to "default" (not creative enough to
find a better name). In this mode, audio seeking is exact if there is no
video, or if the video has only a single frame. This change is actually
pretty dumb, since audio frames are usually small enough that exact
seeking does not really add much. But it gets rid of some weird special
cases.
Internally, the most important change is that is_coverart and is_sparse
handling is merged. is_sparse was originally just a special case for
weird .ts streams that have the corresponding low-level flag set. The
idea is that they're pretty similar anyway, so this would reduce the
number of corner cases. But I'm not sure if this doesn't break the
original intended use case for it (I don't have a sample anyway).
This changes last-frame handling, and respects the duration of the last
frame only if audio is disabled. This is mostly "coincidental" due to
the need to make seeking past EOF trigger player exit, and is caused by
setting STATUS_EOF early. On the other hand, this might have been this
way before (see removed chunk close to it).
2020-02-28 16:15:07 +00:00
|
|
|
static bool use_video_lookahead(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
return mpctx->video_out &&
|
|
|
|
|
!(mpctx->video_out->driver->caps & VO_CAP_NORETAIN) &&
|
|
|
|
|
!(mpctx->opts->untimed || mpctx->video_out->driver->untimed) &&
|
|
|
|
|
!mpctx->opts->video_latency_hacks;
|
|
|
|
|
}
|
|
|
|
|
|
2015-07-01 17:22:40 +00:00
|
|
|
static int get_req_frames(struct MPContext *mpctx, bool eof)
|
|
|
|
|
{
|
|
|
|
|
// On EOF, drain all frames.
|
2015-11-13 21:42:42 +00:00
|
|
|
if (eof)
|
2015-07-01 17:22:40 +00:00
|
|
|
return 1;
|
|
|
|
|
|
player: dumb seeking related stuff, make audio hr-seek default
Try to deal with various corner cases. But when I fix one thing, another
thing breaks. (And it's 50/50 whether I find the breakage immediately or
a few months later.) So results may vary.
The default for--hr-seek is changed to "default" (not creative enough to
find a better name). In this mode, audio seeking is exact if there is no
video, or if the video has only a single frame. This change is actually
pretty dumb, since audio frames are usually small enough that exact
seeking does not really add much. But it gets rid of some weird special
cases.
Internally, the most important change is that is_coverart and is_sparse
handling is merged. is_sparse was originally just a special case for
weird .ts streams that have the corresponding low-level flag set. The
idea is that they're pretty similar anyway, so this would reduce the
number of corner cases. But I'm not sure if this doesn't break the
original intended use case for it (I don't have a sample anyway).
This changes last-frame handling, and respects the duration of the last
frame only if audio is disabled. This is mostly "coincidental" due to
the need to make seeking past EOF trigger player exit, and is caused by
setting STATUS_EOF early. On the other hand, this might have been this
way before (see removed chunk close to it).
2020-02-28 16:15:07 +00:00
|
|
|
if (!use_video_lookahead(mpctx))
|
2018-02-16 03:57:34 +00:00
|
|
|
return 1;
|
|
|
|
|
|
2018-05-03 02:29:11 +00:00
|
|
|
if (mpctx->vo_chain && mpctx->vo_chain->is_sparse)
|
|
|
|
|
return 1;
|
|
|
|
|
|
video: always decode 2 frames on playback restart
Unless --video-latency-hacks, always decode 2 frames on playback
restart. This in turn will always compute the correct frame duration
(even for the first frame), which in turn happens to fix that playback
with an image at the beginning breaks display.
If a still image precedes video, and the size/format of the frame is
different from that of the video following it, the incorrect frame
duration caused vo_reconfig2() to be called early, causing the window to
resize, and the renderer to clear the image to black. Specifically, it
hit the default value of 1 second duration (for still images), so the
image was displayed for 1 second, and changed to black until the next
proper video frame was displayed.
Normally this does not happen. Even if a video file displays still
images, it normally repeats the still image at the video's FPS (which is
sane). But you can construct such files, or use EDL to construct
something similarly behaving.
This change may increase seek latency a bit in audio video-sync mode
(the default). It needs to wait until 2 frames are decoded, before it
bothers to display the first frame. This is done even when seeking. In
theory it might be good to introduce a "seek preview" mode, which shows
the target image without all the preparations needed for starting
playback. (For example, it could not decode audio.) But since I'm using
video-sync=display-resample, which already needed to always decode 2
frames, I don't think this is a terribly high priority, nor do I
consider the slightly slower seeking a regression.
Fixes: #6765
2019-10-06 20:20:10 +00:00
|
|
|
// Normally require at least 2 frames, so we can compute a frame duration.
|
player: dumb seeking related stuff, make audio hr-seek default
Try to deal with various corner cases. But when I fix one thing, another
thing breaks. (And it's 50/50 whether I find the breakage immediately or
a few months later.) So results may vary.
The default for--hr-seek is changed to "default" (not creative enough to
find a better name). In this mode, audio seeking is exact if there is no
video, or if the video has only a single frame. This change is actually
pretty dumb, since audio frames are usually small enough that exact
seeking does not really add much. But it gets rid of some weird special
cases.
Internally, the most important change is that is_coverart and is_sparse
handling is merged. is_sparse was originally just a special case for
weird .ts streams that have the corresponding low-level flag set. The
idea is that they're pretty similar anyway, so this would reduce the
number of corner cases. But I'm not sure if this doesn't break the
original intended use case for it (I don't have a sample anyway).
This changes last-frame handling, and respects the duration of the last
frame only if audio is disabled. This is mostly "coincidental" due to
the need to make seeking past EOF trigger player exit, and is caused by
setting STATUS_EOF early. On the other hand, this might have been this
way before (see removed chunk close to it).
2020-02-28 16:15:07 +00:00
|
|
|
int min = 2;
|
2018-03-02 14:37:34 +00:00
|
|
|
|
2015-11-13 21:42:42 +00:00
|
|
|
// On the first frame, output a new frame as quickly as possible.
|
|
|
|
|
if (mpctx->video_pts == MP_NOPTS_VALUE)
|
video: always decode 2 frames on playback restart
Unless --video-latency-hacks, always decode 2 frames on playback
restart. This in turn will always compute the correct frame duration
(even for the first frame), which in turn happens to fix that playback
with an image at the beginning breaks display.
If a still image precedes video, and the size/format of the frame is
different from that of the video following it, the incorrect frame
duration caused vo_reconfig2() to be called early, causing the window to
resize, and the renderer to clear the image to black. Specifically, it
hit the default value of 1 second duration (for still images), so the
image was displayed for 1 second, and changed to black until the next
proper video frame was displayed.
Normally this does not happen. Even if a video file displays still
images, it normally repeats the still image at the video's FPS (which is
sane). But you can construct such files, or use EDL to construct
something similarly behaving.
This change may increase seek latency a bit in audio video-sync mode
(the default). It needs to wait until 2 frames are decoded, before it
bothers to display the first frame. This is done even when seeking. In
theory it might be good to introduce a "seek preview" mode, which shows
the target image without all the preparations needed for starting
playback. (For example, it could not decode audio.) But since I'm using
video-sync=display-resample, which already needed to always decode 2
frames, I don't think this is a terribly high priority, nor do I
consider the slightly slower seeking a regression.
Fixes: #6765
2019-10-06 20:20:10 +00:00
|
|
|
return min;
|
2015-11-13 21:42:42 +00:00
|
|
|
|
2015-07-20 19:12:46 +00:00
|
|
|
int req = vo_get_num_req_frames(mpctx->video_out);
|
2018-03-02 14:37:34 +00:00
|
|
|
return MPCLAMP(req, min, MP_ARRAY_SIZE(mpctx->next_frames) - 1);
|
2015-07-01 17:22:40 +00:00
|
|
|
}
|
|
|
|
|
|
2015-03-25 12:33:34 +00:00
|
|
|
// Whether it's fine to call add_new_frame() now.
|
|
|
|
|
static bool needs_new_frame(struct MPContext *mpctx)
|
|
|
|
|
{
|
2015-07-01 17:22:40 +00:00
|
|
|
return mpctx->num_next_frames < get_req_frames(mpctx, false);
|
2015-03-25 12:33:34 +00:00
|
|
|
}
|
|
|
|
|
|
2015-07-01 17:22:40 +00:00
|
|
|
// Queue a frame to mpctx->next_frames[]. Call only if needs_new_frame() signals ok.
|
2015-03-25 12:33:34 +00:00
|
|
|
static void add_new_frame(struct MPContext *mpctx, struct mp_image *frame)
|
|
|
|
|
{
|
2016-01-12 22:49:00 +00:00
|
|
|
assert(mpctx->num_next_frames < MP_ARRAY_SIZE(mpctx->next_frames));
|
2015-03-25 12:33:34 +00:00
|
|
|
assert(frame);
|
2015-07-01 17:22:40 +00:00
|
|
|
mpctx->next_frames[mpctx->num_next_frames++] = frame;
|
|
|
|
|
if (mpctx->num_next_frames == 1)
|
|
|
|
|
handle_new_frame(mpctx);
|
2015-03-25 12:33:34 +00:00
|
|
|
}
|
|
|
|
|
|
2014-09-18 17:20:22 +00:00
|
|
|
// Enough video filtered already to push one frame to the VO?
|
2015-03-25 12:33:34 +00:00
|
|
|
// Set eof to true if no new frames are to be expected.
|
|
|
|
|
static bool have_new_frame(struct MPContext *mpctx, bool eof)
|
2014-09-18 17:20:22 +00:00
|
|
|
{
|
2015-07-01 17:22:40 +00:00
|
|
|
return mpctx->num_next_frames >= get_req_frames(mpctx, eof);
|
2014-09-18 17:20:22 +00:00
|
|
|
}
|
|
|
|
|
|
2015-07-01 17:22:40 +00:00
|
|
|
// Fill mpctx->next_frames[] with a newly filtered or decoded image.
|
player: dumb seeking related stuff, make audio hr-seek default
Try to deal with various corner cases. But when I fix one thing, another
thing breaks. (And it's 50/50 whether I find the breakage immediately or
a few months later.) So results may vary.
The default for--hr-seek is changed to "default" (not creative enough to
find a better name). In this mode, audio seeking is exact if there is no
video, or if the video has only a single frame. This change is actually
pretty dumb, since audio frames are usually small enough that exact
seeking does not really add much. But it gets rid of some weird special
cases.
Internally, the most important change is that is_coverart and is_sparse
handling is merged. is_sparse was originally just a special case for
weird .ts streams that have the corresponding low-level flag set. The
idea is that they're pretty similar anyway, so this would reduce the
number of corner cases. But I'm not sure if this doesn't break the
original intended use case for it (I don't have a sample anyway).
This changes last-frame handling, and respects the duration of the last
frame only if audio is disabled. This is mostly "coincidental" due to
the need to make seeking past EOF trigger player exit, and is caused by
setting STATUS_EOF early. On the other hand, this might have been this
way before (see removed chunk close to it).
2020-02-28 16:15:07 +00:00
|
|
|
// logical_eof: is set to true if there is EOF after currently queued frames
|
2014-07-18 13:11:21 +00:00
|
|
|
// returns VD_* code
|
player: make repeated hr-seeks past EOF trigger EOF as expected
If you have a normal file with audio and video, and keep "spamming"
forward hr-seeks, the player just kept showing the last video frame
instead of exiting or playing the next file. This started happening
since commit 6bcda94cb. Although not a bug per se, it was odd, and very
user-noticable.
The main problem was that the pending seek command was processed before
the EOF was "noticed". Processing the command reset everything, so the
player did not terminate playback, but repeated the seek.
This commit restores the old behavior.
For one, it makes video return the correct status (video.c). The
parameter is a bit ugly, but better than duplicating the logic or having
another MPContext field. (As a minor detail, setting r=VD_EOF makes sure
have_new_frame() returns true, rather than going through another
iteration or whatever the hell will happen instead, which would clobber
logical_eof.)
Another thing is making the seek logic actually wait until the seek
outcome has been determined if audio is also active. Audio needs to wait
for video in order to get the video seek target position. (Which in turn
is because hr-seek still "snaps" to video frames. You can't seek in
between two frames, so audio can't just use the seek target, but always
has to wait on the timestamp of the video frame. This has other
disadvantages and is a misdesign, but not something I'll fix today.)
In theory, this might make hr-seeks less responsive, because it needs to
fully decode/filter the audio too, but in practice most time is spent on
video, which had to be fully decoded before this change. (In general,
hr-seek could probably just show a random frame when a queued hr-seek
overrides the current hr-seek, which would probably lead to a better
user experience, but that's out of scope.)
Fixes: #7206
2019-12-14 13:17:16 +00:00
|
|
|
static int video_output_image(struct MPContext *mpctx, bool *logical_eof)
|
2013-10-29 21:38:29 +00:00
|
|
|
{
|
2016-02-01 21:14:32 +00:00
|
|
|
struct vo_chain *vo_c = mpctx->vo_chain;
|
2019-11-17 00:37:59 +00:00
|
|
|
bool hrseek = false;
|
|
|
|
|
double hrseek_pts = mpctx->hrseek_pts;
|
player: don't apply weird timestamp tolerance on backstep
Hr-seek has some sort of tolerance against timestamps, where it allows
for up to 5ms deviation. This means it can work only for videos with up
to 200 FPS framerate. There were complains about how it doesn't work
with videos beyond some high fps. (1000 was mentioned, although that
sounds more like it's about the limit that .mkv has.)
I suspect this is because otherwise, it might be hard to hit a timestamp
with --start, which specifies timestamps as integer, and thus will most
likely never represent a timestamp exactly. Another part of the problem
is that mpv uses 64 bit floats for timestamps, so fractional parts are
never represented exactly. (Both the "tolerance" and using floats for
timestamps were things introduced before my time.)
Anyway, in the backstep case, we can be relatively sure that the
timestamp will be exact (as in, the same unmodified value that was
returned by the filter chain), so we can make an exception for that, in
order to fix backstep.
Untested. (For that you have users.)
May help with #7208.
2019-12-03 20:43:32 +00:00
|
|
|
double tolerance = mpctx->hrseek_backstep ? 0 : .005;
|
2019-11-17 00:37:59 +00:00
|
|
|
if (mpctx->video_status == STATUS_SYNCING) {
|
|
|
|
|
hrseek = mpctx->hrseek_active;
|
|
|
|
|
// playback_pts is normally only set when audio and video have started
|
|
|
|
|
// playing normally. If video is in syncing mode, then this must mean
|
|
|
|
|
// video was just enabled via track switching - skip to current time.
|
|
|
|
|
if (!hrseek && mpctx->playback_pts != MP_NOPTS_VALUE) {
|
|
|
|
|
hrseek = true;
|
|
|
|
|
hrseek_pts = mpctx->playback_pts;
|
|
|
|
|
}
|
|
|
|
|
}
|
2014-12-07 01:47:09 +00:00
|
|
|
|
2016-02-01 21:14:32 +00:00
|
|
|
if (vo_c->is_coverart) {
|
player: dumb seeking related stuff, make audio hr-seek default
Try to deal with various corner cases. But when I fix one thing, another
thing breaks. (And it's 50/50 whether I find the breakage immediately or
a few months later.) So results may vary.
The default for--hr-seek is changed to "default" (not creative enough to
find a better name). In this mode, audio seeking is exact if there is no
video, or if the video has only a single frame. This change is actually
pretty dumb, since audio frames are usually small enough that exact
seeking does not really add much. But it gets rid of some weird special
cases.
Internally, the most important change is that is_coverart and is_sparse
handling is merged. is_sparse was originally just a special case for
weird .ts streams that have the corresponding low-level flag set. The
idea is that they're pretty similar anyway, so this would reduce the
number of corner cases. But I'm not sure if this doesn't break the
original intended use case for it (I don't have a sample anyway).
This changes last-frame handling, and respects the duration of the last
frame only if audio is disabled. This is mostly "coincidental" due to
the need to make seeking past EOF trigger player exit, and is caused by
setting STATUS_EOF early. On the other hand, this might have been this
way before (see removed chunk close to it).
2020-02-28 16:15:07 +00:00
|
|
|
*logical_eof = true;
|
2014-08-22 12:20:30 +00:00
|
|
|
if (vo_has_frame(mpctx->video_out))
|
2014-07-18 13:11:21 +00:00
|
|
|
return VD_EOF;
|
2016-01-16 20:19:52 +00:00
|
|
|
hrseek = false;
|
2014-08-13 19:55:46 +00:00
|
|
|
}
|
|
|
|
|
|
2015-03-25 12:33:34 +00:00
|
|
|
if (have_new_frame(mpctx, false))
|
2014-09-22 16:06:59 +00:00
|
|
|
return VD_NEW_FRAME;
|
|
|
|
|
|
2014-09-18 17:17:38 +00:00
|
|
|
// Get a new frame if we need one.
|
2014-09-22 16:06:59 +00:00
|
|
|
int r = VD_PROGRESS;
|
2015-03-25 12:33:34 +00:00
|
|
|
if (needs_new_frame(mpctx)) {
|
2014-09-22 16:06:59 +00:00
|
|
|
// Filter a new frame.
|
video: rewrite filtering glue code
Get rid of the old vf.c code. Replace it with a generic filtering
framework, which can potentially handle more than just --vf. At least
reimplementing --af with this code is planned.
This changes some --vf semantics (including runtime behavior and the
"vf" command). The most important ones are listed in interface-changes.
vf_convert.c is renamed to f_swscale.c. It is now an internal filter
that can not be inserted by the user manually.
f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed
once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is
conceptually easy, but a big mess due to the data flow changes).
The existing filters are all changed heavily. The data flow of the new
filter framework is different. Especially EOF handling changes - EOF is
now a "frame" rather than a state, and must be passed through exactly
once.
Another major thing is that all filters must support dynamic format
changes. The filter reconfig() function goes away. (This sounds complex,
but since all filters need to handle EOF draining anyway, they can use
the same code, and it removes the mess with reconfig() having to predict
the output format, which completely breaks with libavfilter anyway.)
In addition, there is no automatic format negotiation or conversion.
libavfilter's primitive and insufficient API simply doesn't allow us to
do this in a reasonable way. Instead, filters can use f_autoconvert as
sub-filter, and tell it which formats they support. This filter will in
turn add actual conversion filters, such as f_swscale, to perform
necessary format changes.
vf_vapoursynth.c uses the same basic principle of operation as before,
but with worryingly different details in data flow. Still appears to
work.
The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are
heavily changed. Fortunately, they all used refqueue.c, which is for
sharing the data flow logic (especially for managing future/past
surfaces and such). It turns out it can be used to factor out most of
the data flow. Some of these filters accepted software input. Instead of
having ad-hoc upload code in each filter, surface upload is now
delegated to f_autoconvert, which can use f_hwupload to perform this.
Exporting VO capabilities is still a big mess (mp_stream_info stuff).
The D3D11 code drops the redundant image formats, and all code uses the
hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a
big mess for now.
f_async_queue is unused.
2018-01-16 10:53:44 +00:00
|
|
|
struct mp_image *img = NULL;
|
|
|
|
|
struct mp_frame frame = mp_pin_out_read(vo_c->filter->f->pins[1]);
|
video: make decoder wrapper a filter
Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes
a source filter. vd.h mostly disappears, because mp_filter takes care of
the dataflow, but its remains are in struct mp_decoder_fns.
One goal is to simplify dataflow by letting the filter framework handle
it (or more accurately, using its conventions). One result is that the
decode calls disappear from video.c, because we simply connect the
decoder wrapper and the filter chain with mp_pin_connect().
Another goal is to eventually remove the code duplication between the
audio and video paths for this. This commit prepares for this by trying
to make f_decoder_wrapper.c extensible, so it can be used for audio as
well later.
Decoder framedropping changes a bit. It doesn't seem to be worse than
before, and it's an obscure feature, so I'm content with its new state.
Some special code that was apparently meant to avoid dropping too many
frames in a row is removed, though.
I'm not sure how the source code tree should be organized. For one,
video/decode/vd_lavc.c is the only file in its directory, which is a bit
annoying.
2018-01-28 09:08:45 +00:00
|
|
|
if (frame.type == MP_FRAME_NONE) {
|
|
|
|
|
r = vo_c->filter->got_output_eof ? VD_EOF : VD_WAIT;
|
|
|
|
|
} else if (frame.type == MP_FRAME_EOF) {
|
video: rewrite filtering glue code
Get rid of the old vf.c code. Replace it with a generic filtering
framework, which can potentially handle more than just --vf. At least
reimplementing --af with this code is planned.
This changes some --vf semantics (including runtime behavior and the
"vf" command). The most important ones are listed in interface-changes.
vf_convert.c is renamed to f_swscale.c. It is now an internal filter
that can not be inserted by the user manually.
f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed
once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is
conceptually easy, but a big mess due to the data flow changes).
The existing filters are all changed heavily. The data flow of the new
filter framework is different. Especially EOF handling changes - EOF is
now a "frame" rather than a state, and must be passed through exactly
once.
Another major thing is that all filters must support dynamic format
changes. The filter reconfig() function goes away. (This sounds complex,
but since all filters need to handle EOF draining anyway, they can use
the same code, and it removes the mess with reconfig() having to predict
the output format, which completely breaks with libavfilter anyway.)
In addition, there is no automatic format negotiation or conversion.
libavfilter's primitive and insufficient API simply doesn't allow us to
do this in a reasonable way. Instead, filters can use f_autoconvert as
sub-filter, and tell it which formats they support. This filter will in
turn add actual conversion filters, such as f_swscale, to perform
necessary format changes.
vf_vapoursynth.c uses the same basic principle of operation as before,
but with worryingly different details in data flow. Still appears to
work.
The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are
heavily changed. Fortunately, they all used refqueue.c, which is for
sharing the data flow logic (especially for managing future/past
surfaces and such). It turns out it can be used to factor out most of
the data flow. Some of these filters accepted software input. Instead of
having ad-hoc upload code in each filter, surface upload is now
delegated to f_autoconvert, which can use f_hwupload to perform this.
Exporting VO capabilities is still a big mess (mp_stream_info stuff).
The D3D11 code drops the redundant image formats, and all code uses the
hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a
big mess for now.
f_async_queue is unused.
2018-01-16 10:53:44 +00:00
|
|
|
r = VD_EOF;
|
|
|
|
|
} else if (frame.type == MP_FRAME_VIDEO) {
|
|
|
|
|
img = frame.data;
|
|
|
|
|
} else {
|
|
|
|
|
MP_ERR(mpctx, "unexpected frame type %s\n",
|
|
|
|
|
mp_frame_type_str(frame.type));
|
|
|
|
|
mp_frame_unref(&frame);
|
|
|
|
|
return VD_ERROR;
|
|
|
|
|
}
|
2014-09-18 17:17:38 +00:00
|
|
|
if (img) {
|
2016-02-27 19:02:51 +00:00
|
|
|
double endpts = get_play_end_pts(mpctx);
|
2019-05-25 21:04:26 +00:00
|
|
|
if (endpts != MP_NOPTS_VALUE)
|
|
|
|
|
endpts *= mpctx->play_dir;
|
2016-08-18 18:37:25 +00:00
|
|
|
if ((endpts != MP_NOPTS_VALUE && img->pts >= endpts) ||
|
|
|
|
|
mpctx->max_frames == 0)
|
|
|
|
|
{
|
video: rewrite filtering glue code
Get rid of the old vf.c code. Replace it with a generic filtering
framework, which can potentially handle more than just --vf. At least
reimplementing --af with this code is planned.
This changes some --vf semantics (including runtime behavior and the
"vf" command). The most important ones are listed in interface-changes.
vf_convert.c is renamed to f_swscale.c. It is now an internal filter
that can not be inserted by the user manually.
f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed
once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is
conceptually easy, but a big mess due to the data flow changes).
The existing filters are all changed heavily. The data flow of the new
filter framework is different. Especially EOF handling changes - EOF is
now a "frame" rather than a state, and must be passed through exactly
once.
Another major thing is that all filters must support dynamic format
changes. The filter reconfig() function goes away. (This sounds complex,
but since all filters need to handle EOF draining anyway, they can use
the same code, and it removes the mess with reconfig() having to predict
the output format, which completely breaks with libavfilter anyway.)
In addition, there is no automatic format negotiation or conversion.
libavfilter's primitive and insufficient API simply doesn't allow us to
do this in a reasonable way. Instead, filters can use f_autoconvert as
sub-filter, and tell it which formats they support. This filter will in
turn add actual conversion filters, such as f_swscale, to perform
necessary format changes.
vf_vapoursynth.c uses the same basic principle of operation as before,
but with worryingly different details in data flow. Still appears to
work.
The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are
heavily changed. Fortunately, they all used refqueue.c, which is for
sharing the data flow logic (especially for managing future/past
surfaces and such). It turns out it can be used to factor out most of
the data flow. Some of these filters accepted software input. Instead of
having ad-hoc upload code in each filter, surface upload is now
delegated to f_autoconvert, which can use f_hwupload to perform this.
Exporting VO capabilities is still a big mess (mp_stream_info stuff).
The D3D11 code drops the redundant image formats, and all code uses the
hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a
big mess for now.
f_async_queue is unused.
2018-01-16 10:53:44 +00:00
|
|
|
mp_pin_out_unread(vo_c->filter->f->pins[1], frame);
|
2016-08-18 18:37:25 +00:00
|
|
|
img = NULL;
|
2015-03-25 12:58:14 +00:00
|
|
|
r = VD_EOF;
|
player: don't apply weird timestamp tolerance on backstep
Hr-seek has some sort of tolerance against timestamps, where it allows
for up to 5ms deviation. This means it can work only for videos with up
to 200 FPS framerate. There were complains about how it doesn't work
with videos beyond some high fps. (1000 was mentioned, although that
sounds more like it's about the limit that .mkv has.)
I suspect this is because otherwise, it might be hard to hit a timestamp
with --start, which specifies timestamps as integer, and thus will most
likely never represent a timestamp exactly. Another part of the problem
is that mpv uses 64 bit floats for timestamps, so fractional parts are
never represented exactly. (Both the "tolerance" and using floats for
timestamps were things introduced before my time.)
Anyway, in the backstep case, we can be relatively sure that the
timestamp will be exact (as in, the same unmodified value that was
returned by the filter chain), so we can make an exception for that, in
order to fix backstep.
Untested. (For that you have users.)
May help with #7208.
2019-12-03 20:43:32 +00:00
|
|
|
} else if (hrseek && (img->pts < hrseek_pts - tolerance ||
|
2019-11-16 22:54:43 +00:00
|
|
|
mpctx->hrseek_lastframe))
|
|
|
|
|
{
|
|
|
|
|
/* just skip - but save in case it was the last frame */
|
2014-12-07 01:47:09 +00:00
|
|
|
mp_image_setrefp(&mpctx->saved_frame, img);
|
2014-09-18 17:17:38 +00:00
|
|
|
} else {
|
2016-01-16 20:19:52 +00:00
|
|
|
if (hrseek && mpctx->hrseek_backstep) {
|
2016-01-12 22:49:00 +00:00
|
|
|
if (mpctx->saved_frame) {
|
|
|
|
|
add_new_frame(mpctx, mpctx->saved_frame);
|
|
|
|
|
mpctx->saved_frame = NULL;
|
|
|
|
|
} else {
|
|
|
|
|
MP_WARN(mpctx, "Backstep failed.\n");
|
|
|
|
|
}
|
|
|
|
|
mpctx->hrseek_backstep = false;
|
|
|
|
|
}
|
2020-02-28 00:26:08 +00:00
|
|
|
mp_image_unrefp(&mpctx->saved_frame);
|
2015-03-25 12:33:34 +00:00
|
|
|
add_new_frame(mpctx, img);
|
2015-03-25 12:58:14 +00:00
|
|
|
img = NULL;
|
2014-09-18 17:17:38 +00:00
|
|
|
}
|
2015-03-25 12:58:14 +00:00
|
|
|
talloc_free(img);
|
2014-09-18 17:17:38 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-28 00:26:08 +00:00
|
|
|
if (!hrseek)
|
|
|
|
|
mp_image_unrefp(&mpctx->saved_frame);
|
|
|
|
|
|
player: dumb seeking related stuff, make audio hr-seek default
Try to deal with various corner cases. But when I fix one thing, another
thing breaks. (And it's 50/50 whether I find the breakage immediately or
a few months later.) So results may vary.
The default for--hr-seek is changed to "default" (not creative enough to
find a better name). In this mode, audio seeking is exact if there is no
video, or if the video has only a single frame. This change is actually
pretty dumb, since audio frames are usually small enough that exact
seeking does not really add much. But it gets rid of some weird special
cases.
Internally, the most important change is that is_coverart and is_sparse
handling is merged. is_sparse was originally just a special case for
weird .ts streams that have the corresponding low-level flag set. The
idea is that they're pretty similar anyway, so this would reduce the
number of corner cases. But I'm not sure if this doesn't break the
original intended use case for it (I don't have a sample anyway).
This changes last-frame handling, and respects the duration of the last
frame only if audio is disabled. This is mostly "coincidental" due to
the need to make seeking past EOF trigger player exit, and is caused by
setting STATUS_EOF early. On the other hand, this might have been this
way before (see removed chunk close to it).
2020-02-28 16:15:07 +00:00
|
|
|
if (r == VD_EOF) {
|
|
|
|
|
// If hr-seek went past EOF, use the last frame.
|
|
|
|
|
if (mpctx->saved_frame)
|
|
|
|
|
add_new_frame(mpctx, mpctx->saved_frame);
|
2014-12-07 01:47:09 +00:00
|
|
|
mpctx->saved_frame = NULL;
|
player: make repeated hr-seeks past EOF trigger EOF as expected
If you have a normal file with audio and video, and keep "spamming"
forward hr-seeks, the player just kept showing the last video frame
instead of exiting or playing the next file. This started happening
since commit 6bcda94cb. Although not a bug per se, it was odd, and very
user-noticable.
The main problem was that the pending seek command was processed before
the EOF was "noticed". Processing the command reset everything, so the
player did not terminate playback, but repeated the seek.
This commit restores the old behavior.
For one, it makes video return the correct status (video.c). The
parameter is a bit ugly, but better than duplicating the logic or having
another MPContext field. (As a minor detail, setting r=VD_EOF makes sure
have_new_frame() returns true, rather than going through another
iteration or whatever the hell will happen instead, which would clobber
logical_eof.)
Another thing is making the seek logic actually wait until the seek
outcome has been determined if audio is also active. Audio needs to wait
for video in order to get the video seek target position. (Which in turn
is because hr-seek still "snaps" to video frames. You can't seek in
between two frames, so audio can't just use the seek target, but always
has to wait on the timestamp of the video frame. This has other
disadvantages and is a misdesign, but not something I'll fix today.)
In theory, this might make hr-seeks less responsive, because it needs to
fully decode/filter the audio too, but in practice most time is spent on
video, which had to be fully decoded before this change. (In general,
hr-seek could probably just show a random frame when a queued hr-seek
overrides the current hr-seek, which would probably lead to a better
user experience, but that's out of scope.)
Fixes: #7206
2019-12-14 13:17:16 +00:00
|
|
|
*logical_eof = true;
|
2014-12-07 01:47:09 +00:00
|
|
|
}
|
|
|
|
|
|
2015-03-25 12:33:34 +00:00
|
|
|
return have_new_frame(mpctx, r <= 0) ? VD_NEW_FRAME : r;
|
2013-10-29 21:38:29 +00:00
|
|
|
}
|
2014-07-30 21:24:08 +00:00
|
|
|
|
video: rewrite filtering glue code
Get rid of the old vf.c code. Replace it with a generic filtering
framework, which can potentially handle more than just --vf. At least
reimplementing --af with this code is planned.
This changes some --vf semantics (including runtime behavior and the
"vf" command). The most important ones are listed in interface-changes.
vf_convert.c is renamed to f_swscale.c. It is now an internal filter
that can not be inserted by the user manually.
f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed
once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is
conceptually easy, but a big mess due to the data flow changes).
The existing filters are all changed heavily. The data flow of the new
filter framework is different. Especially EOF handling changes - EOF is
now a "frame" rather than a state, and must be passed through exactly
once.
Another major thing is that all filters must support dynamic format
changes. The filter reconfig() function goes away. (This sounds complex,
but since all filters need to handle EOF draining anyway, they can use
the same code, and it removes the mess with reconfig() having to predict
the output format, which completely breaks with libavfilter anyway.)
In addition, there is no automatic format negotiation or conversion.
libavfilter's primitive and insufficient API simply doesn't allow us to
do this in a reasonable way. Instead, filters can use f_autoconvert as
sub-filter, and tell it which formats they support. This filter will in
turn add actual conversion filters, such as f_swscale, to perform
necessary format changes.
vf_vapoursynth.c uses the same basic principle of operation as before,
but with worryingly different details in data flow. Still appears to
work.
The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are
heavily changed. Fortunately, they all used refqueue.c, which is for
sharing the data flow logic (especially for managing future/past
surfaces and such). It turns out it can be used to factor out most of
the data flow. Some of these filters accepted software input. Instead of
having ad-hoc upload code in each filter, surface upload is now
delegated to f_autoconvert, which can use f_hwupload to perform this.
Exporting VO capabilities is still a big mess (mp_stream_info stuff).
The D3D11 code drops the redundant image formats, and all code uses the
hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a
big mess for now.
f_async_queue is unused.
2018-01-16 10:53:44 +00:00
|
|
|
static bool check_for_hwdec_fallback(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
struct vo_chain *vo_c = mpctx->vo_chain;
|
|
|
|
|
|
2023-07-25 23:18:32 +00:00
|
|
|
if (!vo_c->filter->failed_output_conversion || !vo_c->track || !vo_c->track->dec)
|
video: rewrite filtering glue code
Get rid of the old vf.c code. Replace it with a generic filtering
framework, which can potentially handle more than just --vf. At least
reimplementing --af with this code is planned.
This changes some --vf semantics (including runtime behavior and the
"vf" command). The most important ones are listed in interface-changes.
vf_convert.c is renamed to f_swscale.c. It is now an internal filter
that can not be inserted by the user manually.
f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed
once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is
conceptually easy, but a big mess due to the data flow changes).
The existing filters are all changed heavily. The data flow of the new
filter framework is different. Especially EOF handling changes - EOF is
now a "frame" rather than a state, and must be passed through exactly
once.
Another major thing is that all filters must support dynamic format
changes. The filter reconfig() function goes away. (This sounds complex,
but since all filters need to handle EOF draining anyway, they can use
the same code, and it removes the mess with reconfig() having to predict
the output format, which completely breaks with libavfilter anyway.)
In addition, there is no automatic format negotiation or conversion.
libavfilter's primitive and insufficient API simply doesn't allow us to
do this in a reasonable way. Instead, filters can use f_autoconvert as
sub-filter, and tell it which formats they support. This filter will in
turn add actual conversion filters, such as f_swscale, to perform
necessary format changes.
vf_vapoursynth.c uses the same basic principle of operation as before,
but with worryingly different details in data flow. Still appears to
work.
The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are
heavily changed. Fortunately, they all used refqueue.c, which is for
sharing the data flow logic (especially for managing future/past
surfaces and such). It turns out it can be used to factor out most of
the data flow. Some of these filters accepted software input. Instead of
having ad-hoc upload code in each filter, surface upload is now
delegated to f_autoconvert, which can use f_hwupload to perform this.
Exporting VO capabilities is still a big mess (mp_stream_info stuff).
The D3D11 code drops the redundant image formats, and all code uses the
hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a
big mess for now.
f_async_queue is unused.
2018-01-16 10:53:44 +00:00
|
|
|
return false;
|
|
|
|
|
|
video: make decoder wrapper a filter
Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes
a source filter. vd.h mostly disappears, because mp_filter takes care of
the dataflow, but its remains are in struct mp_decoder_fns.
One goal is to simplify dataflow by letting the filter framework handle
it (or more accurately, using its conventions). One result is that the
decode calls disappear from video.c, because we simply connect the
decoder wrapper and the filter chain with mp_pin_connect().
Another goal is to eventually remove the code duplication between the
audio and video paths for this. This commit prepares for this by trying
to make f_decoder_wrapper.c extensible, so it can be used for audio as
well later.
Decoder framedropping changes a bit. It doesn't seem to be worse than
before, and it's an obscure feature, so I'm content with its new state.
Some special code that was apparently meant to avoid dropping too many
frames in a row is removed, though.
I'm not sure how the source code tree should be organized. For one,
video/decode/vd_lavc.c is the only file in its directory, which is a bit
annoying.
2018-01-28 09:08:45 +00:00
|
|
|
if (mp_decoder_wrapper_control(vo_c->track->dec,
|
|
|
|
|
VDCTRL_FORCE_HWDEC_FALLBACK, NULL) != CONTROL_OK)
|
video: rewrite filtering glue code
Get rid of the old vf.c code. Replace it with a generic filtering
framework, which can potentially handle more than just --vf. At least
reimplementing --af with this code is planned.
This changes some --vf semantics (including runtime behavior and the
"vf" command). The most important ones are listed in interface-changes.
vf_convert.c is renamed to f_swscale.c. It is now an internal filter
that can not be inserted by the user manually.
f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed
once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is
conceptually easy, but a big mess due to the data flow changes).
The existing filters are all changed heavily. The data flow of the new
filter framework is different. Especially EOF handling changes - EOF is
now a "frame" rather than a state, and must be passed through exactly
once.
Another major thing is that all filters must support dynamic format
changes. The filter reconfig() function goes away. (This sounds complex,
but since all filters need to handle EOF draining anyway, they can use
the same code, and it removes the mess with reconfig() having to predict
the output format, which completely breaks with libavfilter anyway.)
In addition, there is no automatic format negotiation or conversion.
libavfilter's primitive and insufficient API simply doesn't allow us to
do this in a reasonable way. Instead, filters can use f_autoconvert as
sub-filter, and tell it which formats they support. This filter will in
turn add actual conversion filters, such as f_swscale, to perform
necessary format changes.
vf_vapoursynth.c uses the same basic principle of operation as before,
but with worryingly different details in data flow. Still appears to
work.
The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are
heavily changed. Fortunately, they all used refqueue.c, which is for
sharing the data flow logic (especially for managing future/past
surfaces and such). It turns out it can be used to factor out most of
the data flow. Some of these filters accepted software input. Instead of
having ad-hoc upload code in each filter, surface upload is now
delegated to f_autoconvert, which can use f_hwupload to perform this.
Exporting VO capabilities is still a big mess (mp_stream_info stuff).
The D3D11 code drops the redundant image formats, and all code uses the
hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a
big mess for now.
f_async_queue is unused.
2018-01-16 10:53:44 +00:00
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
mp_output_chain_reset_harder(vo_c->filter);
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2023-07-16 02:38:59 +00:00
|
|
|
static bool check_for_forced_eof(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
struct vo_chain *vo_c = mpctx->vo_chain;
|
|
|
|
|
|
2023-07-25 23:18:32 +00:00
|
|
|
if (!vo_c->track || !vo_c->track->dec)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
struct mp_decoder_wrapper *dec = vo_c->track->dec;
|
2023-07-16 02:38:59 +00:00
|
|
|
bool forced_eof = false;
|
2023-07-25 23:18:32 +00:00
|
|
|
|
2023-07-16 02:38:59 +00:00
|
|
|
mp_decoder_wrapper_control(dec, VDCTRL_CHECK_FORCED_EOF, &forced_eof);
|
|
|
|
|
return forced_eof;
|
|
|
|
|
}
|
|
|
|
|
|
2014-08-13 19:54:13 +00:00
|
|
|
/* Update avsync before a new video frame is displayed. Actually, this can be
|
|
|
|
|
* called arbitrarily often before the actual display.
|
|
|
|
|
* This adjusts the time of the next video frame */
|
|
|
|
|
static void update_avsync_before_frame(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
|
|
|
|
struct vo *vo = mpctx->video_out;
|
|
|
|
|
|
2019-11-17 00:39:54 +00:00
|
|
|
if (mpctx->video_status < STATUS_READY) {
|
2014-08-13 19:54:13 +00:00
|
|
|
mpctx->time_frame = 0;
|
2022-04-06 21:58:32 +00:00
|
|
|
} else if (mpctx->display_sync_active || vo->opts->video_sync == VS_NONE) {
|
2015-08-10 16:43:25 +00:00
|
|
|
// don't touch the timing
|
2014-08-13 19:54:13 +00:00
|
|
|
} else if (mpctx->audio_status == STATUS_PLAYING &&
|
|
|
|
|
mpctx->video_status == STATUS_PLAYING &&
|
|
|
|
|
!ao_untimed(mpctx->ao))
|
|
|
|
|
{
|
|
|
|
|
double buffered_audio = ao_get_delay(mpctx->ao);
|
2015-02-01 17:32:26 +00:00
|
|
|
|
2015-08-10 16:40:16 +00:00
|
|
|
double predicted = mpctx->delay / mpctx->video_speed +
|
2015-02-01 17:32:26 +00:00
|
|
|
mpctx->time_frame;
|
|
|
|
|
double difference = buffered_audio - predicted;
|
|
|
|
|
MP_STATS(mpctx, "value %f audio-diff", difference);
|
2014-08-13 19:54:13 +00:00
|
|
|
|
|
|
|
|
if (opts->autosync) {
|
|
|
|
|
/* Smooth reported playback position from AO by averaging
|
2023-03-27 20:42:17 +00:00
|
|
|
* it with the value expected based on previous value and
|
2014-08-13 19:54:13 +00:00
|
|
|
* time elapsed since then. May help smooth video timing
|
|
|
|
|
* with audio output that have inaccurate position reporting.
|
|
|
|
|
* This is badly implemented; the behavior of the smoothing
|
|
|
|
|
* now undesirably depends on how often this code runs
|
|
|
|
|
* (mainly depends on video frame rate). */
|
|
|
|
|
buffered_audio = predicted + difference / opts->autosync;
|
|
|
|
|
}
|
|
|
|
|
|
2015-08-10 16:40:16 +00:00
|
|
|
mpctx->time_frame = buffered_audio - mpctx->delay / mpctx->video_speed;
|
2014-08-13 19:54:13 +00:00
|
|
|
} else {
|
|
|
|
|
/* If we're more than 200 ms behind the right playback
|
|
|
|
|
* position, don't try to speed up display of following
|
|
|
|
|
* frames to catch up; continue with default speed from
|
|
|
|
|
* the current frame instead.
|
|
|
|
|
* If untimed is set always output frames immediately
|
|
|
|
|
* without sleeping.
|
|
|
|
|
*/
|
|
|
|
|
if (mpctx->time_frame < -0.2 || opts->untimed || vo->driver->untimed)
|
|
|
|
|
mpctx->time_frame = 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2015-10-28 22:50:54 +00:00
|
|
|
// Update the A/V sync difference when a new video frame is being shown.
|
|
|
|
|
static void update_av_diff(struct MPContext *mpctx, double offset)
|
2014-07-30 21:24:08 +00:00
|
|
|
{
|
2015-01-29 11:10:07 +00:00
|
|
|
struct MPOpts *opts = mpctx->opts;
|
|
|
|
|
|
2014-09-19 20:38:00 +00:00
|
|
|
mpctx->last_av_difference = 0;
|
2014-08-22 12:20:30 +00:00
|
|
|
|
2014-07-30 21:24:08 +00:00
|
|
|
if (mpctx->audio_status != STATUS_PLAYING ||
|
|
|
|
|
mpctx->video_status != STATUS_PLAYING)
|
|
|
|
|
return;
|
|
|
|
|
|
2018-05-03 02:29:11 +00:00
|
|
|
if (mpctx->vo_chain && mpctx->vo_chain->is_sparse)
|
|
|
|
|
return;
|
|
|
|
|
|
2014-07-30 21:24:08 +00:00
|
|
|
double a_pos = playing_audio_pts(mpctx);
|
2015-10-28 22:50:54 +00:00
|
|
|
if (a_pos != MP_NOPTS_VALUE && mpctx->video_pts != MP_NOPTS_VALUE) {
|
|
|
|
|
mpctx->last_av_difference = a_pos - mpctx->video_pts
|
|
|
|
|
+ opts->audio_delay + offset;
|
|
|
|
|
}
|
2014-07-30 21:24:08 +00:00
|
|
|
|
2015-10-28 22:50:54 +00:00
|
|
|
if (fabs(mpctx->last_av_difference) > 0.5 && !mpctx->drop_message_shown) {
|
2014-07-30 21:24:08 +00:00
|
|
|
MP_WARN(mpctx, "%s", av_desync_help_text);
|
|
|
|
|
mpctx->drop_message_shown = true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
double calc_average_frame_duration(struct MPContext *mpctx)
|
2015-08-10 16:38:57 +00:00
|
|
|
{
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
double total = 0;
|
|
|
|
|
int num = 0;
|
|
|
|
|
for (int n = 0; n < mpctx->num_past_frames; n++) {
|
2016-09-09 16:56:45 +00:00
|
|
|
double dur = mpctx->past_frames[n].approx_duration;
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
if (dur <= 0)
|
|
|
|
|
continue;
|
|
|
|
|
total += dur;
|
|
|
|
|
num += 1;
|
2015-08-10 16:38:57 +00:00
|
|
|
}
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
return num > 0 ? total / num : 0;
|
2015-08-10 16:38:57 +00:00
|
|
|
}
|
|
|
|
|
|
2015-11-13 21:47:14 +00:00
|
|
|
// Find a speed factor such that the display FPS is an integer multiple of the
|
|
|
|
|
// effective video FPS. If this is not possible, try to do it for multiples,
|
|
|
|
|
// which still leads to an improved end result.
|
|
|
|
|
// Both parameters are durations in seconds.
|
2022-08-06 01:45:59 +00:00
|
|
|
static double calc_best_speed(double vsync, double frame,
|
|
|
|
|
double max_change, int max_factor)
|
2015-11-13 21:47:14 +00:00
|
|
|
{
|
|
|
|
|
double ratio = frame / vsync;
|
2020-05-23 01:48:51 +00:00
|
|
|
for (int factor = 1; factor <= max_factor; factor++) {
|
2015-11-13 21:47:14 +00:00
|
|
|
double scale = ratio * factor / rint(ratio * factor);
|
2022-08-06 01:45:59 +00:00
|
|
|
if (fabs(scale - 1) <= max_change)
|
|
|
|
|
return scale;
|
2015-11-13 21:47:14 +00:00
|
|
|
}
|
2022-08-06 01:45:59 +00:00
|
|
|
return -1;
|
2015-11-13 21:47:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static double find_best_speed(struct MPContext *mpctx, double vsync)
|
|
|
|
|
{
|
|
|
|
|
double total = 0;
|
|
|
|
|
int num = 0;
|
|
|
|
|
for (int n = 0; n < mpctx->num_past_frames; n++) {
|
|
|
|
|
double dur = mpctx->past_frames[n].approx_duration;
|
|
|
|
|
if (dur <= 0)
|
|
|
|
|
continue;
|
2022-08-06 01:45:59 +00:00
|
|
|
double best = calc_best_speed(vsync, dur / mpctx->opts->playback_speed,
|
|
|
|
|
mpctx->opts->sync_max_video_change / 100,
|
2020-05-23 01:48:51 +00:00
|
|
|
mpctx->opts->sync_max_factor);
|
2022-08-06 01:45:59 +00:00
|
|
|
if (best <= 0)
|
|
|
|
|
continue;
|
|
|
|
|
total += best;
|
2015-11-13 21:47:14 +00:00
|
|
|
num++;
|
|
|
|
|
}
|
2022-08-06 01:45:59 +00:00
|
|
|
// If it doesn't work, play at normal speed.
|
2015-11-13 21:47:14 +00:00
|
|
|
return num > 0 ? total / num : 1;
|
|
|
|
|
}
|
|
|
|
|
|
2015-08-10 16:43:25 +00:00
|
|
|
static bool using_spdif_passthrough(struct MPContext *mpctx)
|
|
|
|
|
{
|
2016-07-24 17:19:24 +00:00
|
|
|
if (mpctx->ao_chain && mpctx->ao_chain->ao) {
|
audio: introduce a new type to hold audio frames
This is pretty pointless, but I believe it allows us to claim that the
new code is not affected by the copyright of the old code. This is
needed, because the original mp_audio struct was written by someone who
has disagreed with LGPL relicensing (it was called af_data at the time,
and was defined in af.h).
The "GPL'ed" struct contents that surive are pretty trivial: just the
data pointer, and some metadata like the format, samplerate, etc. - but
at least in this case, any new code would be extremely similar anyway,
and I'm not really sure whether it's OK to claim different copyright. So
what we do is we just use AVFrame (which of course is LGPL with 100%
certainty), and add some accessors around it to adapt it to mpv
conventions.
Also, this gets rid of some annoying conventions of mp_audio, like the
struct fields that require using an accessor to write to them anyway.
For the most part, this change is only dumb replacements of mp_audio
related functions and fields. One minor actual change is that you can't
allocate the new type on the stack anymore.
Some code still uses mp_audio. All audio filter code will be deleted, so
it makes no sense to convert this code. (Audio filters which are LGPL
and which we keep will have to be ported to a new filter infrastructure
anyway.) player/audio.c uses it because it interacts with the old filter
code. push.c has some complex use of mp_audio and mp_audio_buffer, but
this and pull.c will most likely be rewritten to do something else.
2017-08-16 19:00:20 +00:00
|
|
|
int samplerate;
|
|
|
|
|
int format;
|
|
|
|
|
struct mp_chmap channels;
|
|
|
|
|
ao_get_format(mpctx->ao_chain->ao, &samplerate, &format, &channels);
|
|
|
|
|
return !af_fmt_is_pcm(format);
|
2016-07-24 17:19:24 +00:00
|
|
|
}
|
2015-08-10 16:43:25 +00:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2015-11-14 20:42:18 +00:00
|
|
|
// Compute the relative audio speed difference by taking A/V dsync into account.
|
|
|
|
|
static double compute_audio_drift(struct MPContext *mpctx, double vsync)
|
2015-11-13 21:51:39 +00:00
|
|
|
{
|
2015-11-14 20:42:18 +00:00
|
|
|
// Least-squares linear regression, using relative real time for x, and
|
|
|
|
|
// audio desync for y. Assume speed didn't change for the frames we're
|
2015-11-13 21:51:39 +00:00
|
|
|
// looking at for simplicity. This also should actually use the realtime
|
|
|
|
|
// (minus paused time) for x, but use vsync scheduling points instead.
|
|
|
|
|
if (mpctx->num_past_frames <= 10)
|
|
|
|
|
return NAN;
|
|
|
|
|
int num = mpctx->num_past_frames - 1;
|
|
|
|
|
double sum_x = 0, sum_y = 0, sum_xy = 0, sum_xx = 0;
|
|
|
|
|
double x = 0;
|
|
|
|
|
for (int n = 0; n < num; n++) {
|
|
|
|
|
struct frame_info *frame = &mpctx->past_frames[n + 1];
|
|
|
|
|
if (frame->num_vsyncs < 0)
|
|
|
|
|
return NAN;
|
2015-11-14 20:42:18 +00:00
|
|
|
double y = frame->av_diff;
|
2015-11-13 21:51:39 +00:00
|
|
|
sum_x += x;
|
|
|
|
|
sum_y += y;
|
|
|
|
|
sum_xy += x * y;
|
|
|
|
|
sum_xx += x * x;
|
|
|
|
|
x -= frame->num_vsyncs * vsync;
|
|
|
|
|
}
|
|
|
|
|
return (sum_x * sum_y - num * sum_xy) / (sum_x * sum_x - num * sum_xx);
|
|
|
|
|
}
|
|
|
|
|
|
2022-08-03 21:47:07 +00:00
|
|
|
static void adjust_audio_drift_compensation(struct MPContext *mpctx, double vsync)
|
2015-11-04 18:37:15 +00:00
|
|
|
{
|
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
2022-04-06 21:58:32 +00:00
|
|
|
int mode = mpctx->video_out->opts->video_sync;
|
2015-11-13 21:50:58 +00:00
|
|
|
|
2022-08-03 21:47:07 +00:00
|
|
|
if ((mode != VS_DISP_RESAMPLE && mode != VS_DISP_TEMPO) ||
|
|
|
|
|
mpctx->audio_status != STATUS_PLAYING)
|
|
|
|
|
{
|
2015-11-13 21:50:58 +00:00
|
|
|
mpctx->speed_factor_a = mpctx->speed_factor_v;
|
|
|
|
|
return;
|
2015-11-04 18:37:15 +00:00
|
|
|
}
|
|
|
|
|
|
2015-11-13 21:50:58 +00:00
|
|
|
// Try to smooth out audio timing drifts. This can happen if either
|
|
|
|
|
// video isn't playing at expected speed, or audio is not playing at
|
|
|
|
|
// the requested speed. Both are unavoidable.
|
|
|
|
|
// The audio desync is made up of 2 parts: 1. drift due to rounding
|
|
|
|
|
// errors and imperfect information, and 2. an offset, due to
|
|
|
|
|
// unaligned audio/video start, or disruptive events halting audio
|
|
|
|
|
// or video for a small time.
|
|
|
|
|
// Instead of trying to be clever, just apply an awfully dumb drift
|
|
|
|
|
// compensation with a constant factor, which does what we want. In
|
|
|
|
|
// theory we could calculate the exact drift compensation needed,
|
|
|
|
|
// but it likely would be wrong anyway, and we'd run into the same
|
|
|
|
|
// issues again, except with more complex code.
|
|
|
|
|
// 1 means drifts to positive, -1 means drifts to negative
|
|
|
|
|
double max_drift = vsync / 2;
|
|
|
|
|
double av_diff = mpctx->last_av_difference;
|
|
|
|
|
int new = mpctx->display_sync_drift_dir;
|
|
|
|
|
if (av_diff * -mpctx->display_sync_drift_dir >= 0)
|
|
|
|
|
new = 0;
|
|
|
|
|
if (fabs(av_diff) > max_drift)
|
|
|
|
|
new = av_diff >= 0 ? 1 : -1;
|
|
|
|
|
|
|
|
|
|
bool change = mpctx->display_sync_drift_dir != new;
|
|
|
|
|
if (new || change) {
|
|
|
|
|
if (change)
|
|
|
|
|
MP_VERBOSE(mpctx, "Change display sync audio drift: %d\n", new);
|
|
|
|
|
mpctx->display_sync_drift_dir = new;
|
2015-11-04 18:37:15 +00:00
|
|
|
|
2015-11-13 21:50:58 +00:00
|
|
|
double max_correct = opts->sync_max_audio_change / 100;
|
|
|
|
|
double audio_factor = 1 + max_correct * -mpctx->display_sync_drift_dir;
|
2015-11-13 21:51:39 +00:00
|
|
|
|
|
|
|
|
if (new == 0) {
|
|
|
|
|
// If we're resetting, actually try to be clever and pick a speed
|
|
|
|
|
// which compensates the general drift we're getting.
|
2015-11-14 20:42:18 +00:00
|
|
|
double drift = compute_audio_drift(mpctx, vsync);
|
2015-11-13 21:51:39 +00:00
|
|
|
if (isnormal(drift)) {
|
2015-11-14 20:42:18 +00:00
|
|
|
// other = will be multiplied with audio_factor for final speed
|
|
|
|
|
double other = mpctx->opts->playback_speed * mpctx->speed_factor_v;
|
|
|
|
|
audio_factor = (mpctx->audio_speed - drift) / other;
|
2015-11-13 21:51:39 +00:00
|
|
|
MP_VERBOSE(mpctx, "Compensation factor: %f\n", audio_factor);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
audio_factor = MPCLAMP(audio_factor, 1 - max_correct, 1 + max_correct);
|
2015-11-13 21:50:58 +00:00
|
|
|
mpctx->speed_factor_a = audio_factor * mpctx->speed_factor_v;
|
|
|
|
|
}
|
2015-11-04 18:37:15 +00:00
|
|
|
}
|
|
|
|
|
|
2015-08-10 16:43:25 +00:00
|
|
|
// Manipulate frame timing for display sync, or do nothing for normal timing.
|
|
|
|
|
static void handle_display_sync_frame(struct MPContext *mpctx,
|
|
|
|
|
struct vo_frame *frame)
|
|
|
|
|
{
|
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
|
|
|
|
struct vo *vo = mpctx->video_out;
|
2022-04-06 21:58:32 +00:00
|
|
|
int mode = vo->opts->video_sync;
|
2015-08-10 16:43:25 +00:00
|
|
|
|
|
|
|
|
if (!mpctx->display_sync_active) {
|
|
|
|
|
mpctx->display_sync_error = 0.0;
|
|
|
|
|
mpctx->display_sync_drift_dir = 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
mpctx->display_sync_active = false;
|
|
|
|
|
|
video: do not disable display-sync on A/V desync
On a audio/video desync by more than 0.5 seconds, display-sync mode was
disabled, and not enabled again (until playback restart, e.g. a seek).
The idea was that it this only happens when this playback mode is broken
and can't perform well anyway (A/V desync is a clear indication that
something is very wrong). Instead of behaving like a god damn POS, it
should revert to the more robust audio-sync mode.
Unfortunately, this could happen sporadically due to temporary system
performance problems, such as toggling fullscreen. Users didn't like
this, and asked for a function to disable it, or to recover in some
other way.
This mechanism is questionable anyway. If an ignorant user enables
display-sync, and encounters problems with it (without being able to
determine that display-sync is messing up), the player will still behave
like a POS on every playback, and even after every seek. It might
actually be helpful to fail more consistently. Also, I've found that
it's sill relatively reliable anyway even without this mechanism.
So just remove the fallback.
Fixes: #7048
2019-10-17 17:23:35 +00:00
|
|
|
if (!VS_IS_DISP(mode))
|
2015-11-27 13:40:52 +00:00
|
|
|
return;
|
2015-08-10 16:43:25 +00:00
|
|
|
bool resample = mode == VS_DISP_RESAMPLE || mode == VS_DISP_RESAMPLE_VDROP ||
|
|
|
|
|
mode == VS_DISP_RESAMPLE_NONE;
|
|
|
|
|
bool drop = mode == VS_DISP_VDROP || mode == VS_DISP_RESAMPLE ||
|
2022-08-03 21:47:07 +00:00
|
|
|
mode == VS_DISP_ADROP || mode == VS_DISP_RESAMPLE_VDROP ||
|
|
|
|
|
mode == VS_DISP_TEMPO;
|
2018-03-13 11:54:48 +00:00
|
|
|
drop &= frame->can_drop;
|
2015-08-10 16:43:25 +00:00
|
|
|
|
|
|
|
|
if (resample && using_spdif_passthrough(mpctx))
|
2015-11-27 13:40:52 +00:00
|
|
|
return;
|
2015-08-10 16:43:25 +00:00
|
|
|
|
2023-09-16 02:45:24 +00:00
|
|
|
double vsync = vo_get_vsync_interval(vo) / 1e9;
|
2015-08-10 16:43:25 +00:00
|
|
|
if (vsync <= 0)
|
2015-11-27 13:40:52 +00:00
|
|
|
return;
|
2015-08-10 16:43:25 +00:00
|
|
|
|
2015-12-04 16:07:50 +00:00
|
|
|
double adjusted_duration = MPMAX(0, mpctx->past_frames[0].approx_duration);
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
adjusted_duration /= opts->playback_speed;
|
2015-12-04 16:07:50 +00:00
|
|
|
if (adjusted_duration > 0.5)
|
2015-11-27 13:40:52 +00:00
|
|
|
return;
|
2015-08-10 16:43:25 +00:00
|
|
|
|
2015-11-26 17:53:32 +00:00
|
|
|
mpctx->speed_factor_v = 1.0;
|
2022-08-06 01:45:59 +00:00
|
|
|
if (mode != VS_DISP_VDROP)
|
|
|
|
|
mpctx->speed_factor_v = find_best_speed(mpctx, vsync);
|
2015-08-10 16:43:25 +00:00
|
|
|
|
|
|
|
|
// Determine for how many vsyncs a frame should be displayed. This can be
|
|
|
|
|
// e.g. 2 for 30hz on a 60hz display. It can also be 0 if the video
|
|
|
|
|
// framerate is higher than the display framerate.
|
|
|
|
|
// We use the speed-adjusted (i.e. real) frame duration for this.
|
2015-11-04 18:37:15 +00:00
|
|
|
double frame_duration = adjusted_duration / mpctx->speed_factor_v;
|
2015-08-10 16:43:25 +00:00
|
|
|
double ratio = (frame_duration + mpctx->display_sync_error) / vsync;
|
2015-11-11 18:52:35 +00:00
|
|
|
int num_vsyncs = MPMAX(lrint(ratio), 0);
|
2015-10-31 12:19:38 +00:00
|
|
|
double prev_error = mpctx->display_sync_error;
|
2015-08-10 16:43:25 +00:00
|
|
|
mpctx->display_sync_error += frame_duration - num_vsyncs * vsync;
|
|
|
|
|
|
2017-09-28 09:53:57 +00:00
|
|
|
MP_TRACE(mpctx, "s=%f vsyncs=%d dur=%f ratio=%f err=%.20f (%f/%f)\n",
|
|
|
|
|
mpctx->speed_factor_v, num_vsyncs, adjusted_duration, ratio,
|
|
|
|
|
mpctx->display_sync_error, mpctx->display_sync_error / vsync,
|
|
|
|
|
mpctx->display_sync_error / frame_duration);
|
2015-08-10 16:43:25 +00:00
|
|
|
|
video: do not disable display-sync on A/V desync
On a audio/video desync by more than 0.5 seconds, display-sync mode was
disabled, and not enabled again (until playback restart, e.g. a seek).
The idea was that it this only happens when this playback mode is broken
and can't perform well anyway (A/V desync is a clear indication that
something is very wrong). Instead of behaving like a god damn POS, it
should revert to the more robust audio-sync mode.
Unfortunately, this could happen sporadically due to temporary system
performance problems, such as toggling fullscreen. Users didn't like
this, and asked for a function to disable it, or to recover in some
other way.
This mechanism is questionable anyway. If an ignorant user enables
display-sync, and encounters problems with it (without being able to
determine that display-sync is messing up), the player will still behave
like a POS on every playback, and even after every seek. It might
actually be helpful to fail more consistently. Also, I've found that
it's sill relatively reliable anyway even without this mechanism.
So just remove the fallback.
Fixes: #7048
2019-10-17 17:23:35 +00:00
|
|
|
double av_diff = mpctx->last_av_difference;
|
2015-11-04 18:37:15 +00:00
|
|
|
MP_STATS(mpctx, "value %f avdiff", av_diff);
|
|
|
|
|
|
|
|
|
|
// Intended number of additional display frames to drop (<0) or repeat (>0)
|
|
|
|
|
int drop_repeat = 0;
|
|
|
|
|
|
2015-11-13 21:53:38 +00:00
|
|
|
// If we are too far ahead/behind, attempt to drop/repeat frames.
|
2015-11-04 18:37:15 +00:00
|
|
|
// Tolerate some desync to avoid frame dropping due to jitter.
|
2015-11-13 21:53:38 +00:00
|
|
|
if (drop && fabs(av_diff) >= 0.020 && fabs(av_diff) / vsync >= 1)
|
2015-11-04 18:37:15 +00:00
|
|
|
drop_repeat = -av_diff / vsync; // round towards 0
|
|
|
|
|
|
2015-08-10 16:43:25 +00:00
|
|
|
// We can only drop all frames at most. We can repeat much more frames,
|
|
|
|
|
// but we still limit it to 10 times the original frames to avoid that
|
|
|
|
|
// corner cases or exceptional situations cause too much havoc.
|
|
|
|
|
drop_repeat = MPCLAMP(drop_repeat, -num_vsyncs, num_vsyncs * 10);
|
|
|
|
|
num_vsyncs += drop_repeat;
|
|
|
|
|
|
2016-04-24 18:14:51 +00:00
|
|
|
// Always show the first frame.
|
|
|
|
|
if (mpctx->num_past_frames <= 1 && num_vsyncs < 1)
|
|
|
|
|
num_vsyncs = 1;
|
|
|
|
|
|
2015-08-10 16:43:25 +00:00
|
|
|
// Estimate the video position, so we can calculate a good A/V difference
|
2015-10-28 22:50:54 +00:00
|
|
|
// value below. This is used to estimate A/V drift.
|
2015-11-14 20:44:59 +00:00
|
|
|
double time_left = vo_get_delay(vo);
|
|
|
|
|
|
2015-08-10 16:43:25 +00:00
|
|
|
// We also know that the timing is (necessarily) off, because we have to
|
|
|
|
|
// align frame timings on the vsync boundaries. This is unavoidable, and
|
2015-10-31 12:19:38 +00:00
|
|
|
// for the sake of the A/V sync calculations we pretend it's perfect.
|
|
|
|
|
time_left += prev_error;
|
2015-10-28 22:50:37 +00:00
|
|
|
// Likewise, we know sync is off, but is going to be compensated.
|
2015-10-28 22:50:54 +00:00
|
|
|
time_left += drop_repeat * vsync;
|
|
|
|
|
|
player: fix display-sync timing if audio take long on resume
In display-sync mode, the very first video frame is idiotically fully
timed, even though audio has not been synced yet at this point, and the
video frame is more like a "preview" frame. But since it's fully timed,
an underflow is detected if audio takes longer than the display time of
the frame (we send the second frame only after audio is done).
The timing code will try to compensate for the determined desync, but it
really shouldn't. So explicitly discard the timing info in this specific
case. On the other hand, if the first frame still hasn't finished
display, we can pretend everything is ok.
This is a hack - ideally, we either would send a frame without timing
info (and then send it again or so when playback starts properly), or we
would add real pause support to the VO, and pause it during syncing.
2016-08-07 12:06:54 +00:00
|
|
|
// If syncing took too long, disregard timing of the first frame.
|
|
|
|
|
if (mpctx->num_past_frames == 2 && time_left < 0) {
|
|
|
|
|
vo_discard_timing_info(vo);
|
|
|
|
|
time_left = 0;
|
|
|
|
|
}
|
|
|
|
|
|
2015-11-25 21:07:47 +00:00
|
|
|
if (drop_repeat) {
|
2015-10-30 13:05:41 +00:00
|
|
|
mpctx->mistimed_frames_total += 1;
|
2015-11-25 21:07:47 +00:00
|
|
|
MP_STATS(mpctx, "mistimed");
|
|
|
|
|
}
|
2015-10-30 13:05:41 +00:00
|
|
|
|
2015-10-27 19:56:58 +00:00
|
|
|
mpctx->total_avsync_change = 0;
|
2015-11-01 18:53:48 +00:00
|
|
|
update_av_diff(mpctx, time_left * opts->playback_speed);
|
2015-10-28 22:50:54 +00:00
|
|
|
|
2015-11-13 21:48:32 +00:00
|
|
|
mpctx->past_frames[0].num_vsyncs = num_vsyncs;
|
2015-11-13 21:51:39 +00:00
|
|
|
mpctx->past_frames[0].av_diff = mpctx->last_av_difference;
|
2015-11-13 21:48:32 +00:00
|
|
|
|
2022-08-03 21:47:07 +00:00
|
|
|
if (resample || mode == VS_DISP_ADROP || mode == VS_DISP_TEMPO) {
|
|
|
|
|
adjust_audio_drift_compensation(mpctx, vsync);
|
2015-11-13 21:50:58 +00:00
|
|
|
} else {
|
|
|
|
|
mpctx->speed_factor_a = 1.0;
|
|
|
|
|
}
|
2015-11-04 18:37:15 +00:00
|
|
|
|
2015-10-28 22:50:54 +00:00
|
|
|
// A bad guess, only needed when reverting to audio sync.
|
|
|
|
|
mpctx->time_frame = time_left;
|
2015-08-10 16:43:25 +00:00
|
|
|
|
2015-11-27 21:04:44 +00:00
|
|
|
frame->vsync_interval = vsync;
|
2015-11-28 14:45:35 +00:00
|
|
|
frame->vsync_offset = -prev_error;
|
|
|
|
|
frame->ideal_frame_duration = frame_duration;
|
2015-08-10 16:43:25 +00:00
|
|
|
frame->num_vsyncs = num_vsyncs;
|
|
|
|
|
frame->display_synced = true;
|
|
|
|
|
|
|
|
|
|
mpctx->display_sync_active = true;
|
2023-10-29 04:26:54 +00:00
|
|
|
// Try to avoid audio underruns that may occur if we update
|
|
|
|
|
// the playback speed while in the STATUS_SYNCING state.
|
|
|
|
|
if (mpctx->video_status != STATUS_SYNCING)
|
|
|
|
|
update_playback_speed(mpctx);
|
2015-08-10 16:43:25 +00:00
|
|
|
|
2015-11-13 21:50:58 +00:00
|
|
|
MP_STATS(mpctx, "value %f aspeed", mpctx->speed_factor_a - 1);
|
|
|
|
|
MP_STATS(mpctx, "value %f vspeed", mpctx->speed_factor_v - 1);
|
2015-11-27 13:40:52 +00:00
|
|
|
}
|
2015-08-10 16:43:25 +00:00
|
|
|
|
2015-11-27 13:40:52 +00:00
|
|
|
static void schedule_frame(struct MPContext *mpctx, struct vo_frame *frame)
|
|
|
|
|
{
|
|
|
|
|
handle_display_sync_frame(mpctx, frame);
|
2015-08-10 16:43:25 +00:00
|
|
|
|
2015-11-13 21:49:50 +00:00
|
|
|
if (mpctx->num_past_frames > 1 &&
|
|
|
|
|
((mpctx->past_frames[1].num_vsyncs >= 0) != mpctx->display_sync_active))
|
|
|
|
|
{
|
2015-08-10 16:43:25 +00:00
|
|
|
MP_VERBOSE(mpctx, "Video sync mode %s.\n",
|
|
|
|
|
mpctx->display_sync_active ? "enabled" : "disabled");
|
|
|
|
|
}
|
2015-10-28 22:50:54 +00:00
|
|
|
|
|
|
|
|
if (!mpctx->display_sync_active) {
|
2015-11-13 21:50:58 +00:00
|
|
|
mpctx->speed_factor_a = 1.0;
|
|
|
|
|
mpctx->speed_factor_v = 1.0;
|
|
|
|
|
update_playback_speed(mpctx);
|
|
|
|
|
|
2015-10-28 22:50:54 +00:00
|
|
|
update_av_diff(mpctx, mpctx->time_frame > 0 ?
|
|
|
|
|
mpctx->time_frame * mpctx->video_speed : 0);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
// Determine the mpctx->past_frames[0] frame duration.
|
|
|
|
|
static void calculate_frame_duration(struct MPContext *mpctx)
|
2015-08-01 20:17:09 +00:00
|
|
|
{
|
2018-02-01 08:20:25 +00:00
|
|
|
struct vo_chain *vo_c = mpctx->vo_chain;
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
assert(mpctx->num_past_frames >= 1 && mpctx->num_next_frames >= 1);
|
2015-08-01 20:17:09 +00:00
|
|
|
|
2018-02-01 08:20:25 +00:00
|
|
|
double demux_duration = vo_c->filter->container_fps > 0
|
|
|
|
|
? 1.0 / vo_c->filter->container_fps : -1;
|
2016-09-26 15:55:00 +00:00
|
|
|
double duration = demux_duration;
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
|
|
|
|
|
if (mpctx->num_next_frames >= 2) {
|
|
|
|
|
double pts0 = mpctx->next_frames[0]->pts;
|
|
|
|
|
double pts1 = mpctx->next_frames[1]->pts;
|
|
|
|
|
if (pts0 != MP_NOPTS_VALUE && pts1 != MP_NOPTS_VALUE && pts1 >= pts0)
|
|
|
|
|
duration = pts1 - pts0;
|
2015-08-01 20:17:09 +00:00
|
|
|
}
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
|
|
|
|
|
// The following code tries to compensate for rounded Matroska timestamps
|
|
|
|
|
// by "unrounding" frame durations, or if not possible, approximating them.
|
2016-08-29 15:15:06 +00:00
|
|
|
// These formats usually round on 1ms. Some muxers do this incorrectly,
|
|
|
|
|
// and might go off by 1ms more, and compensate for it later by an equal
|
|
|
|
|
// rounding error into the opposite direction.
|
|
|
|
|
double tolerance = 0.001 * 3 + 0.0001;
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
|
|
|
|
|
double total = 0;
|
|
|
|
|
int num_dur = 0;
|
|
|
|
|
for (int n = 1; n < mpctx->num_past_frames; n++) {
|
|
|
|
|
// Eliminate likely outliers using a really dumb heuristic.
|
|
|
|
|
double dur = mpctx->past_frames[n].duration;
|
|
|
|
|
if (dur <= 0 || fabs(dur - duration) >= tolerance)
|
|
|
|
|
break;
|
|
|
|
|
total += dur;
|
|
|
|
|
num_dur += 1;
|
|
|
|
|
}
|
2015-11-13 21:46:55 +00:00
|
|
|
double approx_duration = num_dur > 0 ? total / num_dur : duration;
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
|
|
|
|
|
// Try if the demuxer frame rate fits - if so, just take it.
|
|
|
|
|
if (demux_duration > 0) {
|
|
|
|
|
// Note that even if each timestamp is within rounding tolerance, it
|
|
|
|
|
// could literally not add up (e.g. if demuxer FPS is rounded itself).
|
|
|
|
|
if (fabs(duration - demux_duration) < tolerance &&
|
2018-05-10 14:49:50 +00:00
|
|
|
fabs(total - demux_duration * num_dur) < tolerance &&
|
|
|
|
|
(num_dur >= 16 || num_dur >= mpctx->num_past_frames - 4))
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
{
|
|
|
|
|
approx_duration = demux_duration;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
mpctx->past_frames[0].duration = duration;
|
|
|
|
|
mpctx->past_frames[0].approx_duration = approx_duration;
|
2016-08-29 15:15:06 +00:00
|
|
|
|
|
|
|
|
MP_STATS(mpctx, "value %f frame-duration", MPMAX(0, duration));
|
|
|
|
|
MP_STATS(mpctx, "value %f frame-duration-approx", MPMAX(0, approx_duration));
|
2015-08-01 20:17:09 +00:00
|
|
|
}
|
|
|
|
|
|
2023-09-09 22:50:38 +00:00
|
|
|
static void apply_video_crop(struct MPContext *mpctx, struct vo *vo)
|
2023-09-09 00:27:15 +00:00
|
|
|
{
|
2023-09-09 22:50:38 +00:00
|
|
|
for (int n = 0; n < mpctx->num_next_frames; n++) {
|
|
|
|
|
struct m_geometry *gm = &vo->opts->video_crop;
|
|
|
|
|
struct mp_image_params p = mpctx->next_frames[n]->params;
|
2023-09-18 11:28:59 +00:00
|
|
|
if (gm->xy_valid || (gm->wh_valid && (gm->w > 0 || gm->h > 0)))
|
2023-09-09 22:50:38 +00:00
|
|
|
{
|
|
|
|
|
m_rect_apply(&p.crop, p.w, p.h, gm);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (p.crop.x1 == 0 && p.crop.y1 == 0)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
if (!mp_image_crop_valid(&p)) {
|
2023-09-09 00:27:15 +00:00
|
|
|
char *str = m_option_type_rect.print(NULL, gm);
|
|
|
|
|
MP_WARN(vo, "Ignoring invalid --video-crop=%s for %dx%d image\n",
|
2023-09-09 22:50:38 +00:00
|
|
|
str, p.w, p.h);
|
2023-09-09 00:27:15 +00:00
|
|
|
talloc_free(str);
|
2023-09-09 22:50:38 +00:00
|
|
|
*gm = (struct m_geometry){0};
|
|
|
|
|
mp_property_do("video-crop", M_PROPERTY_SET, gm, mpctx);
|
|
|
|
|
return;
|
2023-09-09 00:27:15 +00:00
|
|
|
}
|
2023-09-09 22:50:38 +00:00
|
|
|
mpctx->next_frames[n]->params.crop = p.crop;
|
2023-09-09 00:27:15 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-27 19:02:51 +00:00
|
|
|
void write_video(struct MPContext *mpctx)
|
2014-07-30 21:24:08 +00:00
|
|
|
{
|
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
|
|
|
|
|
2016-01-17 17:07:50 +00:00
|
|
|
if (!mpctx->vo_chain)
|
2014-07-30 21:24:08 +00:00
|
|
|
return;
|
2016-02-05 22:41:44 +00:00
|
|
|
struct track *track = mpctx->vo_chain->track;
|
video: rewrite filtering glue code
Get rid of the old vf.c code. Replace it with a generic filtering
framework, which can potentially handle more than just --vf. At least
reimplementing --af with this code is planned.
This changes some --vf semantics (including runtime behavior and the
"vf" command). The most important ones are listed in interface-changes.
vf_convert.c is renamed to f_swscale.c. It is now an internal filter
that can not be inserted by the user manually.
f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed
once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is
conceptually easy, but a big mess due to the data flow changes).
The existing filters are all changed heavily. The data flow of the new
filter framework is different. Especially EOF handling changes - EOF is
now a "frame" rather than a state, and must be passed through exactly
once.
Another major thing is that all filters must support dynamic format
changes. The filter reconfig() function goes away. (This sounds complex,
but since all filters need to handle EOF draining anyway, they can use
the same code, and it removes the mess with reconfig() having to predict
the output format, which completely breaks with libavfilter anyway.)
In addition, there is no automatic format negotiation or conversion.
libavfilter's primitive and insufficient API simply doesn't allow us to
do this in a reasonable way. Instead, filters can use f_autoconvert as
sub-filter, and tell it which formats they support. This filter will in
turn add actual conversion filters, such as f_swscale, to perform
necessary format changes.
vf_vapoursynth.c uses the same basic principle of operation as before,
but with worryingly different details in data flow. Still appears to
work.
The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are
heavily changed. Fortunately, they all used refqueue.c, which is for
sharing the data flow logic (especially for managing future/past
surfaces and such). It turns out it can be used to factor out most of
the data flow. Some of these filters accepted software input. Instead of
having ad-hoc upload code in each filter, surface upload is now
delegated to f_autoconvert, which can use f_hwupload to perform this.
Exporting VO capabilities is still a big mess (mp_stream_info stuff).
The D3D11 code drops the redundant image formats, and all code uses the
hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a
big mess for now.
f_async_queue is unused.
2018-01-16 10:53:44 +00:00
|
|
|
struct vo_chain *vo_c = mpctx->vo_chain;
|
|
|
|
|
struct vo *vo = vo_c->vo;
|
|
|
|
|
|
|
|
|
|
if (vo_c->filter->reconfig_happened) {
|
|
|
|
|
mp_notify(mpctx, MPV_EVENT_VIDEO_RECONFIG, NULL);
|
|
|
|
|
vo_c->filter->reconfig_happened = false;
|
|
|
|
|
}
|
2014-07-30 21:24:08 +00:00
|
|
|
|
2014-08-13 19:51:26 +00:00
|
|
|
// Actual playback starts when both audio and video are ready.
|
|
|
|
|
if (mpctx->video_status == STATUS_READY)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
if (mpctx->paused && mpctx->video_status >= STATUS_READY)
|
|
|
|
|
return;
|
|
|
|
|
|
player: make repeated hr-seeks past EOF trigger EOF as expected
If you have a normal file with audio and video, and keep "spamming"
forward hr-seeks, the player just kept showing the last video frame
instead of exiting or playing the next file. This started happening
since commit 6bcda94cb. Although not a bug per se, it was odd, and very
user-noticable.
The main problem was that the pending seek command was processed before
the EOF was "noticed". Processing the command reset everything, so the
player did not terminate playback, but repeated the seek.
This commit restores the old behavior.
For one, it makes video return the correct status (video.c). The
parameter is a bit ugly, but better than duplicating the logic or having
another MPContext field. (As a minor detail, setting r=VD_EOF makes sure
have_new_frame() returns true, rather than going through another
iteration or whatever the hell will happen instead, which would clobber
logical_eof.)
Another thing is making the seek logic actually wait until the seek
outcome has been determined if audio is also active. Audio needs to wait
for video in order to get the video seek target position. (Which in turn
is because hr-seek still "snaps" to video frames. You can't seek in
between two frames, so audio can't just use the seek target, but always
has to wait on the timestamp of the video frame. This has other
disadvantages and is a misdesign, but not something I'll fix today.)
In theory, this might make hr-seeks less responsive, because it needs to
fully decode/filter the audio too, but in practice most time is spent on
video, which had to be fully decoded before this change. (In general,
hr-seek could probably just show a random frame when a queued hr-seek
overrides the current hr-seek, which would probably lead to a better
user experience, but that's out of scope.)
Fixes: #7206
2019-12-14 13:17:16 +00:00
|
|
|
bool logical_eof = false;
|
|
|
|
|
int r = video_output_image(mpctx, &logical_eof);
|
player: dumb seeking related stuff, make audio hr-seek default
Try to deal with various corner cases. But when I fix one thing, another
thing breaks. (And it's 50/50 whether I find the breakage immediately or
a few months later.) So results may vary.
The default for--hr-seek is changed to "default" (not creative enough to
find a better name). In this mode, audio seeking is exact if there is no
video, or if the video has only a single frame. This change is actually
pretty dumb, since audio frames are usually small enough that exact
seeking does not really add much. But it gets rid of some weird special
cases.
Internally, the most important change is that is_coverart and is_sparse
handling is merged. is_sparse was originally just a special case for
weird .ts streams that have the corresponding low-level flag set. The
idea is that they're pretty similar anyway, so this would reduce the
number of corner cases. But I'm not sure if this doesn't break the
original intended use case for it (I don't have a sample anyway).
This changes last-frame handling, and respects the duration of the last
frame only if audio is disabled. This is mostly "coincidental" due to
the need to make seeking past EOF trigger player exit, and is caused by
setting STATUS_EOF early. On the other hand, this might have been this
way before (see removed chunk close to it).
2020-02-28 16:15:07 +00:00
|
|
|
MP_TRACE(mpctx, "video_output_image: r=%d/eof=%d/st=%s\n", r, logical_eof,
|
|
|
|
|
mp_status_str(mpctx->video_status));
|
2014-07-30 21:24:08 +00:00
|
|
|
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
if (r < 0)
|
|
|
|
|
goto error;
|
2014-07-30 21:24:08 +00:00
|
|
|
|
player: partially rework --cache-pause
The --cache-pause feature (enabled by default) will pause playback for a
while if network runs out of data. If this is not done, then playback
will go on frame-wise (as packets are slowly read from the network and
then instantly decoded and displayed). This feature is actually useless,
as you won't get nice playback no matter what if network is too slow,
but I guess I still prefer this behavior for some reason.
This commit changes this behavior from using the demuxer cache state
only, to trying to use underrun information from the AO/VO. This means
if you have a very large audio buffer, then cache-pausing will trigger
once that buffer is depleted, which will be some time _after_ the
demuxer cache has run out.
This requires explicit support from the AO. Otherwise, the behavior
should be mostly the same as before this commit.
This does not care about the AO buffer. In theory, the AO may underrun,
then the player will write some data to the AO buffer, then the AO will
recover and play this bit of data, then the player will probably trigger
the cache-pause behavior. The probability of this happening should be
pretty low, so I will hold off fixing this until the next refactor of
the AO chain (if ever).
The VO underflow detection was devised and tested in 5 minutes, and may
not be correct. At least I'm fairly sure that the combination of all the
factors should make incorrect behavior relatively unlikely, but problems
are possible.
Also, the demux_reader_state.underrun field may be inaccurate. It's only
the present state at the time demux_get_reader_state() was called, and
may exclude past underruns. In theory, this could cause "close" cases to
be missed. Then you might get an audio underrun without cache-pausing
acting on it. If the stars align, this could happen multiple times in
the row, effectively making this feature not work.
The most user-visible consequence of this change is that the user
will now see an AO underrun warning every time the cache runs out.
Maybe this cache-pause feature should just be removed...
2019-10-11 17:34:04 +00:00
|
|
|
if (r == VD_WAIT) {
|
|
|
|
|
// Heuristic to detect underruns.
|
2019-12-16 00:15:43 +00:00
|
|
|
if (mpctx->video_status == STATUS_PLAYING && !vo_still_displaying(vo) &&
|
|
|
|
|
!vo_c->underrun_signaled)
|
|
|
|
|
{
|
player: partially rework --cache-pause
The --cache-pause feature (enabled by default) will pause playback for a
while if network runs out of data. If this is not done, then playback
will go on frame-wise (as packets are slowly read from the network and
then instantly decoded and displayed). This feature is actually useless,
as you won't get nice playback no matter what if network is too slow,
but I guess I still prefer this behavior for some reason.
This commit changes this behavior from using the demuxer cache state
only, to trying to use underrun information from the AO/VO. This means
if you have a very large audio buffer, then cache-pausing will trigger
once that buffer is depleted, which will be some time _after_ the
demuxer cache has run out.
This requires explicit support from the AO. Otherwise, the behavior
should be mostly the same as before this commit.
This does not care about the AO buffer. In theory, the AO may underrun,
then the player will write some data to the AO buffer, then the AO will
recover and play this bit of data, then the player will probably trigger
the cache-pause behavior. The probability of this happening should be
pretty low, so I will hold off fixing this until the next refactor of
the AO chain (if ever).
The VO underflow detection was devised and tested in 5 minutes, and may
not be correct. At least I'm fairly sure that the combination of all the
factors should make incorrect behavior relatively unlikely, but problems
are possible.
Also, the demux_reader_state.underrun field may be inaccurate. It's only
the present state at the time demux_get_reader_state() was called, and
may exclude past underruns. In theory, this could cause "close" cases to
be missed. Then you might get an audio underrun without cache-pausing
acting on it. If the stars align, this could happen multiple times in
the row, effectively making this feature not work.
The most user-visible consequence of this change is that the user
will now see an AO underrun warning every time the cache runs out.
Maybe this cache-pause feature should just be removed...
2019-10-11 17:34:04 +00:00
|
|
|
vo_c->underrun = true;
|
2019-12-16 00:15:43 +00:00
|
|
|
vo_c->underrun_signaled = true;
|
|
|
|
|
}
|
player: partially rework --cache-pause
The --cache-pause feature (enabled by default) will pause playback for a
while if network runs out of data. If this is not done, then playback
will go on frame-wise (as packets are slowly read from the network and
then instantly decoded and displayed). This feature is actually useless,
as you won't get nice playback no matter what if network is too slow,
but I guess I still prefer this behavior for some reason.
This commit changes this behavior from using the demuxer cache state
only, to trying to use underrun information from the AO/VO. This means
if you have a very large audio buffer, then cache-pausing will trigger
once that buffer is depleted, which will be some time _after_ the
demuxer cache has run out.
This requires explicit support from the AO. Otherwise, the behavior
should be mostly the same as before this commit.
This does not care about the AO buffer. In theory, the AO may underrun,
then the player will write some data to the AO buffer, then the AO will
recover and play this bit of data, then the player will probably trigger
the cache-pause behavior. The probability of this happening should be
pretty low, so I will hold off fixing this until the next refactor of
the AO chain (if ever).
The VO underflow detection was devised and tested in 5 minutes, and may
not be correct. At least I'm fairly sure that the combination of all the
factors should make incorrect behavior relatively unlikely, but problems
are possible.
Also, the demux_reader_state.underrun field may be inaccurate. It's only
the present state at the time demux_get_reader_state() was called, and
may exclude past underruns. In theory, this could cause "close" cases to
be missed. Then you might get an audio underrun without cache-pausing
acting on it. If the stars align, this could happen multiple times in
the row, effectively making this feature not work.
The most user-visible consequence of this change is that the user
will now see an AO underrun warning every time the cache runs out.
Maybe this cache-pause feature should just be removed...
2019-10-11 17:34:04 +00:00
|
|
|
// Demuxer will wake us up for more packets to decode.
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
return;
|
player: partially rework --cache-pause
The --cache-pause feature (enabled by default) will pause playback for a
while if network runs out of data. If this is not done, then playback
will go on frame-wise (as packets are slowly read from the network and
then instantly decoded and displayed). This feature is actually useless,
as you won't get nice playback no matter what if network is too slow,
but I guess I still prefer this behavior for some reason.
This commit changes this behavior from using the demuxer cache state
only, to trying to use underrun information from the AO/VO. This means
if you have a very large audio buffer, then cache-pausing will trigger
once that buffer is depleted, which will be some time _after_ the
demuxer cache has run out.
This requires explicit support from the AO. Otherwise, the behavior
should be mostly the same as before this commit.
This does not care about the AO buffer. In theory, the AO may underrun,
then the player will write some data to the AO buffer, then the AO will
recover and play this bit of data, then the player will probably trigger
the cache-pause behavior. The probability of this happening should be
pretty low, so I will hold off fixing this until the next refactor of
the AO chain (if ever).
The VO underflow detection was devised and tested in 5 minutes, and may
not be correct. At least I'm fairly sure that the combination of all the
factors should make incorrect behavior relatively unlikely, but problems
are possible.
Also, the demux_reader_state.underrun field may be inaccurate. It's only
the present state at the time demux_get_reader_state() was called, and
may exclude past underruns. In theory, this could cause "close" cases to
be missed. Then you might get an audio underrun without cache-pausing
acting on it. If the stars align, this could happen multiple times in
the row, effectively making this feature not work.
The most user-visible consequence of this change is that the user
will now see an AO underrun warning every time the cache runs out.
Maybe this cache-pause feature should just be removed...
2019-10-11 17:34:04 +00:00
|
|
|
}
|
2014-07-30 21:24:08 +00:00
|
|
|
|
2014-08-22 12:18:40 +00:00
|
|
|
if (r == VD_EOF) {
|
video: rewrite filtering glue code
Get rid of the old vf.c code. Replace it with a generic filtering
framework, which can potentially handle more than just --vf. At least
reimplementing --af with this code is planned.
This changes some --vf semantics (including runtime behavior and the
"vf" command). The most important ones are listed in interface-changes.
vf_convert.c is renamed to f_swscale.c. It is now an internal filter
that can not be inserted by the user manually.
f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed
once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is
conceptually easy, but a big mess due to the data flow changes).
The existing filters are all changed heavily. The data flow of the new
filter framework is different. Especially EOF handling changes - EOF is
now a "frame" rather than a state, and must be passed through exactly
once.
Another major thing is that all filters must support dynamic format
changes. The filter reconfig() function goes away. (This sounds complex,
but since all filters need to handle EOF draining anyway, they can use
the same code, and it removes the mess with reconfig() having to predict
the output format, which completely breaks with libavfilter anyway.)
In addition, there is no automatic format negotiation or conversion.
libavfilter's primitive and insufficient API simply doesn't allow us to
do this in a reasonable way. Instead, filters can use f_autoconvert as
sub-filter, and tell it which formats they support. This filter will in
turn add actual conversion filters, such as f_swscale, to perform
necessary format changes.
vf_vapoursynth.c uses the same basic principle of operation as before,
but with worryingly different details in data flow. Still appears to
work.
The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are
heavily changed. Fortunately, they all used refqueue.c, which is for
sharing the data flow logic (especially for managing future/past
surfaces and such). It turns out it can be used to factor out most of
the data flow. Some of these filters accepted software input. Instead of
having ad-hoc upload code in each filter, surface upload is now
delegated to f_autoconvert, which can use f_hwupload to perform this.
Exporting VO capabilities is still a big mess (mp_stream_info stuff).
The D3D11 code drops the redundant image formats, and all code uses the
hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a
big mess for now.
f_async_queue is unused.
2018-01-16 10:53:44 +00:00
|
|
|
if (check_for_hwdec_fallback(mpctx))
|
|
|
|
|
return;
|
2023-07-16 02:38:59 +00:00
|
|
|
if (check_for_forced_eof(mpctx)) {
|
|
|
|
|
uninit_video_chain(mpctx);
|
|
|
|
|
handle_force_window(mpctx, true);
|
|
|
|
|
return;
|
|
|
|
|
}
|
video: rewrite filtering glue code
Get rid of the old vf.c code. Replace it with a generic filtering
framework, which can potentially handle more than just --vf. At least
reimplementing --af with this code is planned.
This changes some --vf semantics (including runtime behavior and the
"vf" command). The most important ones are listed in interface-changes.
vf_convert.c is renamed to f_swscale.c. It is now an internal filter
that can not be inserted by the user manually.
f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed
once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is
conceptually easy, but a big mess due to the data flow changes).
The existing filters are all changed heavily. The data flow of the new
filter framework is different. Especially EOF handling changes - EOF is
now a "frame" rather than a state, and must be passed through exactly
once.
Another major thing is that all filters must support dynamic format
changes. The filter reconfig() function goes away. (This sounds complex,
but since all filters need to handle EOF draining anyway, they can use
the same code, and it removes the mess with reconfig() having to predict
the output format, which completely breaks with libavfilter anyway.)
In addition, there is no automatic format negotiation or conversion.
libavfilter's primitive and insufficient API simply doesn't allow us to
do this in a reasonable way. Instead, filters can use f_autoconvert as
sub-filter, and tell it which formats they support. This filter will in
turn add actual conversion filters, such as f_swscale, to perform
necessary format changes.
vf_vapoursynth.c uses the same basic principle of operation as before,
but with worryingly different details in data flow. Still appears to
work.
The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are
heavily changed. Fortunately, they all used refqueue.c, which is for
sharing the data flow logic (especially for managing future/past
surfaces and such). It turns out it can be used to factor out most of
the data flow. Some of these filters accepted software input. Instead of
having ad-hoc upload code in each filter, surface upload is now
delegated to f_autoconvert, which can use f_hwupload to perform this.
Exporting VO capabilities is still a big mess (mp_stream_info stuff).
The D3D11 code drops the redundant image formats, and all code uses the
hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a
big mess for now.
f_async_queue is unused.
2018-01-16 10:53:44 +00:00
|
|
|
if (vo_c->filter->failed_output_conversion)
|
|
|
|
|
goto error;
|
|
|
|
|
|
2014-07-30 21:24:08 +00:00
|
|
|
mpctx->delay = 0;
|
|
|
|
|
mpctx->last_av_difference = 0;
|
2016-08-17 20:45:44 +00:00
|
|
|
|
|
|
|
|
if (mpctx->video_status <= STATUS_PLAYING) {
|
|
|
|
|
mpctx->video_status = STATUS_DRAINING;
|
|
|
|
|
get_relative_time(mpctx);
|
player: dumb seeking related stuff, make audio hr-seek default
Try to deal with various corner cases. But when I fix one thing, another
thing breaks. (And it's 50/50 whether I find the breakage immediately or
a few months later.) So results may vary.
The default for--hr-seek is changed to "default" (not creative enough to
find a better name). In this mode, audio seeking is exact if there is no
video, or if the video has only a single frame. This change is actually
pretty dumb, since audio frames are usually small enough that exact
seeking does not really add much. But it gets rid of some weird special
cases.
Internally, the most important change is that is_coverart and is_sparse
handling is merged. is_sparse was originally just a special case for
weird .ts streams that have the corresponding low-level flag set. The
idea is that they're pretty similar anyway, so this would reduce the
number of corner cases. But I'm not sure if this doesn't break the
original intended use case for it (I don't have a sample anyway).
This changes last-frame handling, and respects the duration of the last
frame only if audio is disabled. This is mostly "coincidental" due to
the need to make seeking past EOF trigger player exit, and is caused by
setting STATUS_EOF early. On the other hand, this might have been this
way before (see removed chunk close to it).
2020-02-28 16:15:07 +00:00
|
|
|
if (vo_c->is_sparse && !mpctx->ao_chain) {
|
2016-08-21 10:27:48 +00:00
|
|
|
MP_VERBOSE(mpctx, "assuming this is an image\n");
|
2016-08-17 20:45:44 +00:00
|
|
|
mpctx->time_frame += opts->image_display_duration;
|
2016-12-21 17:18:24 +00:00
|
|
|
} else if (mpctx->last_frame_duration > 0) {
|
|
|
|
|
MP_VERBOSE(mpctx, "using demuxer frame duration for last frame\n");
|
|
|
|
|
mpctx->time_frame += mpctx->last_frame_duration;
|
2016-08-17 20:45:44 +00:00
|
|
|
} else {
|
|
|
|
|
mpctx->time_frame = 0;
|
|
|
|
|
}
|
2018-04-26 16:46:18 +00:00
|
|
|
// Encode mode can't honor this; it'll only delay finishing.
|
|
|
|
|
if (mpctx->encode_lavc_ctx)
|
|
|
|
|
mpctx->time_frame = 0;
|
2016-08-17 20:45:44 +00:00
|
|
|
}
|
|
|
|
|
|
2018-04-29 14:04:50 +00:00
|
|
|
// Wait for the VO to signal actual EOF, then exit if the frame timer
|
|
|
|
|
// has expired.
|
2019-01-11 10:02:23 +00:00
|
|
|
bool has_frame = vo_has_frame(vo); // maybe not configured
|
2018-04-29 14:04:50 +00:00
|
|
|
if (mpctx->video_status == STATUS_DRAINING &&
|
2019-01-11 10:02:23 +00:00
|
|
|
(vo_is_ready_for_frame(vo, -1) || !has_frame))
|
2018-04-29 14:04:50 +00:00
|
|
|
{
|
2016-08-17 20:45:44 +00:00
|
|
|
mpctx->time_frame -= get_relative_time(mpctx);
|
2016-09-16 12:24:15 +00:00
|
|
|
mp_set_timeout(mpctx, mpctx->time_frame);
|
2019-01-11 10:02:23 +00:00
|
|
|
if (mpctx->time_frame <= 0 || !has_frame) {
|
2016-08-17 20:45:44 +00:00
|
|
|
MP_VERBOSE(mpctx, "video EOF reached\n");
|
|
|
|
|
mpctx->video_status = STATUS_EOF;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-10 16:31:56 +00:00
|
|
|
// Avoid pointlessly spamming the logs every frame.
|
|
|
|
|
if (!vo_c->is_sparse || !vo_c->sparse_eof_signalled) {
|
|
|
|
|
MP_DBG(mpctx, "video EOF (status=%d)\n", mpctx->video_status);
|
|
|
|
|
vo_c->sparse_eof_signalled = vo_c->is_sparse;
|
|
|
|
|
}
|
2014-07-31 19:57:05 +00:00
|
|
|
return;
|
2014-07-30 21:24:08 +00:00
|
|
|
}
|
|
|
|
|
|
2014-08-22 12:18:40 +00:00
|
|
|
if (mpctx->video_status > STATUS_PLAYING)
|
|
|
|
|
mpctx->video_status = STATUS_PLAYING;
|
|
|
|
|
|
|
|
|
|
if (r != VD_NEW_FRAME) {
|
2016-09-16 12:24:15 +00:00
|
|
|
mp_wakeup_core(mpctx); // Decode more in next iteration.
|
2014-07-30 21:24:08 +00:00
|
|
|
return;
|
2014-08-22 12:18:40 +00:00
|
|
|
}
|
2014-07-30 21:24:08 +00:00
|
|
|
|
player: dumb seeking related stuff, make audio hr-seek default
Try to deal with various corner cases. But when I fix one thing, another
thing breaks. (And it's 50/50 whether I find the breakage immediately or
a few months later.) So results may vary.
The default for--hr-seek is changed to "default" (not creative enough to
find a better name). In this mode, audio seeking is exact if there is no
video, or if the video has only a single frame. This change is actually
pretty dumb, since audio frames are usually small enough that exact
seeking does not really add much. But it gets rid of some weird special
cases.
Internally, the most important change is that is_coverart and is_sparse
handling is merged. is_sparse was originally just a special case for
weird .ts streams that have the corresponding low-level flag set. The
idea is that they're pretty similar anyway, so this would reduce the
number of corner cases. But I'm not sure if this doesn't break the
original intended use case for it (I don't have a sample anyway).
This changes last-frame handling, and respects the duration of the last
frame only if audio is disabled. This is mostly "coincidental" due to
the need to make seeking past EOF trigger player exit, and is caused by
setting STATUS_EOF early. On the other hand, this might have been this
way before (see removed chunk close to it).
2020-02-28 16:15:07 +00:00
|
|
|
if (logical_eof && !mpctx->num_past_frames && mpctx->num_next_frames == 1 &&
|
|
|
|
|
use_video_lookahead(mpctx) && !vo_c->is_sparse)
|
|
|
|
|
{
|
|
|
|
|
// Too much danger to accidentally mark video as sparse when e.g.
|
|
|
|
|
// seeking exactly to the last frame, so as a heuristic, do this only
|
|
|
|
|
// if it looks like the "first" video frame (unreliable, but often
|
|
|
|
|
// works out well). Helps with seeking with single-image video tracks,
|
|
|
|
|
// as well as detecting whether as video track is really an image.
|
|
|
|
|
if (mpctx->next_frames[0]->pts == 0) {
|
|
|
|
|
MP_VERBOSE(mpctx, "assuming single-image video stream\n");
|
|
|
|
|
vo_c->is_sparse = true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-09-09 00:27:15 +00:00
|
|
|
// Inject vo crop to notify and reconfig if needed
|
2023-09-09 22:50:38 +00:00
|
|
|
apply_video_crop(mpctx, vo);
|
2023-09-09 00:27:15 +00:00
|
|
|
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
// Filter output is different from VO input?
|
2023-08-25 17:06:00 +00:00
|
|
|
struct mp_image_params *p = &mpctx->next_frames[0]->params;
|
|
|
|
|
if (!vo->params || !mp_image_params_equal(p, vo->params)) {
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
// Changing config deletes the current frame; wait until it's finished.
|
2023-10-06 18:32:45 +00:00
|
|
|
if (vo_still_displaying(vo))
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
const struct vo_driver *info = mpctx->video_out->driver;
|
2014-11-02 16:34:02 +00:00
|
|
|
char extra[20] = {0};
|
2023-08-25 17:06:00 +00:00
|
|
|
if (p->p_w != p->p_h) {
|
2015-12-19 19:04:31 +00:00
|
|
|
int d_w, d_h;
|
2023-08-25 17:06:00 +00:00
|
|
|
mp_image_params_get_dsize(p, &d_w, &d_h);
|
2015-12-19 19:04:31 +00:00
|
|
|
snprintf(extra, sizeof(extra), " => %dx%d", d_w, d_h);
|
|
|
|
|
}
|
2017-01-29 11:53:58 +00:00
|
|
|
char sfmt[20] = {0};
|
2023-08-25 17:06:00 +00:00
|
|
|
if (p->hw_subfmt)
|
|
|
|
|
snprintf(sfmt, sizeof(sfmt), "[%s]", mp_imgfmt_to_name(p->hw_subfmt));
|
2017-01-29 11:53:58 +00:00
|
|
|
MP_INFO(mpctx, "VO: [%s] %dx%d%s %s%s\n",
|
2023-08-25 17:06:00 +00:00
|
|
|
info->name, p->w, p->h, extra, mp_imgfmt_to_name(p->imgfmt), sfmt);
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
MP_VERBOSE(mpctx, "VO: Description: %s\n", info->description);
|
|
|
|
|
|
2018-04-22 17:36:16 +00:00
|
|
|
int vo_r = vo_reconfig2(vo, mpctx->next_frames[0]);
|
2014-10-28 15:19:07 +00:00
|
|
|
if (vo_r < 0) {
|
|
|
|
|
mpctx->error_playing = MPV_ERROR_VO_INIT_FAILED;
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
goto error;
|
2014-10-28 15:19:07 +00:00
|
|
|
}
|
video: redo video equalizer option handling
I really wouldn't care much about this, but some parts of the core code
are under HAVE_GPL, so there's some need to get rid of it. Simply turn
the video equalizer from its current fine-grained handling with vf/vo
fallbacks into global options. This makes updating them much simpler.
This removes any possibility of applying video equalizers in filters,
which affects vf_scale, and the previously removed vf_eq. Not a big
loss, since the preferred VOs have this builtin.
Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and
vo_xv. I'm not going to waste my time on these legacy VOs.
vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which
exists _only_ to trigger a redraw. This seems silly, but for now I feel
like this is less of a pain. The rest of the equalizer using code is
self-updating.
See commit 96b906a51d5 for how some video equalizer code was GPL only.
Some command line option names and ranges can probably be traced back to
a GPL only committer, but we don't consider these copyrightable.
2017-08-22 15:01:35 +00:00
|
|
|
mp_notify(mpctx, MPV_EVENT_VIDEO_RECONFIG, NULL);
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
}
|
|
|
|
|
|
2015-01-30 20:18:30 +00:00
|
|
|
mpctx->time_frame -= get_relative_time(mpctx);
|
|
|
|
|
update_avsync_before_frame(mpctx);
|
|
|
|
|
|
2016-11-18 12:01:46 +00:00
|
|
|
// Enforce timing subtitles to video frames.
|
|
|
|
|
osd_set_force_video_pts(mpctx->osd, MP_NOPTS_VALUE);
|
|
|
|
|
|
2015-12-29 00:35:52 +00:00
|
|
|
if (!update_subtitles(mpctx, mpctx->next_frames[0]->pts)) {
|
2017-10-23 08:53:28 +00:00
|
|
|
MP_VERBOSE(mpctx, "Video frame delayed due to waiting on subtitles.\n");
|
2015-12-29 00:35:52 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 21:02:08 +00:00
|
|
|
double time_frame = MPMAX(mpctx->time_frame, -1);
|
2023-09-18 01:44:05 +00:00
|
|
|
int64_t pts = mp_time_ns() + (int64_t)(time_frame * 1e9);
|
2014-07-30 21:24:08 +00:00
|
|
|
|
2015-01-03 02:01:58 +00:00
|
|
|
// wait until VO wakes us up to get more frames
|
2015-08-10 16:43:25 +00:00
|
|
|
// (NB: in theory, the 1st frame after display sync mode change uses the
|
|
|
|
|
// wrong waiting mode)
|
video: make decoder wrapper a filter
Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes
a source filter. vd.h mostly disappears, because mp_filter takes care of
the dataflow, but its remains are in struct mp_decoder_fns.
One goal is to simplify dataflow by letting the filter framework handle
it (or more accurately, using its conventions). One result is that the
decode calls disappear from video.c, because we simply connect the
decoder wrapper and the filter chain with mp_pin_connect().
Another goal is to eventually remove the code duplication between the
audio and video paths for this. This commit prepares for this by trying
to make f_decoder_wrapper.c extensible, so it can be used for audio as
well later.
Decoder framedropping changes a bit. It doesn't seem to be worse than
before, and it's an obscure feature, so I'm content with its new state.
Some special code that was apparently meant to avoid dropping too many
frames in a row is removed, though.
I'm not sure how the source code tree should be organized. For one,
video/decode/vd_lavc.c is the only file in its directory, which is a bit
annoying.
2018-01-28 09:08:45 +00:00
|
|
|
if (!vo_is_ready_for_frame(vo, mpctx->display_sync_active ? -1 : pts))
|
2015-01-03 02:01:58 +00:00
|
|
|
return;
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 21:02:08 +00:00
|
|
|
|
2015-07-01 17:22:40 +00:00
|
|
|
assert(mpctx->num_next_frames >= 1);
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
|
|
|
|
|
if (mpctx->num_past_frames >= MAX_NUM_VO_PTS)
|
|
|
|
|
mpctx->num_past_frames--;
|
|
|
|
|
MP_TARRAY_INSERT_AT(mpctx, mpctx->past_frames, mpctx->num_past_frames, 0,
|
|
|
|
|
(struct frame_info){0});
|
2015-11-13 21:48:32 +00:00
|
|
|
mpctx->past_frames[0] = (struct frame_info){
|
|
|
|
|
.pts = mpctx->next_frames[0]->pts,
|
|
|
|
|
.num_vsyncs = -1,
|
|
|
|
|
};
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
calculate_frame_duration(mpctx);
|
|
|
|
|
|
2016-07-07 14:10:13 +00:00
|
|
|
int req = vo_get_num_req_frames(mpctx->video_out);
|
|
|
|
|
assert(req >= 1 && req <= VO_MAX_REQ_FRAMES);
|
2015-07-28 21:54:39 +00:00
|
|
|
struct vo_frame dummy = {
|
|
|
|
|
.pts = pts,
|
|
|
|
|
.duration = -1,
|
2015-08-25 19:48:11 +00:00
|
|
|
.still = mpctx->step_frames > 0,
|
2018-03-13 11:54:48 +00:00
|
|
|
.can_drop = opts->frame_dropping & 1,
|
2016-07-07 14:10:13 +00:00
|
|
|
.num_frames = MPMIN(mpctx->num_next_frames, req),
|
2015-08-10 16:43:25 +00:00
|
|
|
.num_vsyncs = 1,
|
2015-07-28 21:54:39 +00:00
|
|
|
};
|
|
|
|
|
for (int n = 0; n < dummy.num_frames; n++)
|
|
|
|
|
dummy.frames[n] = mpctx->next_frames[n];
|
|
|
|
|
struct vo_frame *frame = vo_frame_ref(&dummy);
|
|
|
|
|
|
2015-11-13 21:48:32 +00:00
|
|
|
double diff = mpctx->past_frames[0].approx_duration;
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
if (opts->untimed || vo->driver->untimed)
|
|
|
|
|
diff = -1; // disable frame dropping and aspects of frame timing
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
if (diff >= 0) {
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 21:02:08 +00:00
|
|
|
// expected A/V sync correction is ignored
|
2015-08-10 16:40:16 +00:00
|
|
|
diff /= mpctx->video_speed;
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 21:02:08 +00:00
|
|
|
if (mpctx->time_frame < 0)
|
|
|
|
|
diff += mpctx->time_frame;
|
2023-09-18 01:44:05 +00:00
|
|
|
frame->duration = MPCLAMP(diff, 0, 10) * 1e9;
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 21:02:08 +00:00
|
|
|
}
|
2014-07-30 21:24:08 +00:00
|
|
|
|
2015-07-01 17:22:40 +00:00
|
|
|
mpctx->video_pts = mpctx->next_frames[0]->pts;
|
2016-12-21 17:18:24 +00:00
|
|
|
mpctx->last_frame_duration =
|
|
|
|
|
mpctx->next_frames[0]->pkt_duration / mpctx->video_speed;
|
2014-07-30 21:24:08 +00:00
|
|
|
|
player: refactor display-sync frame duration calculations
Get rid of get_past_frame_durations(), which was a bit too messy. Add
a past_frames array, which contains the same information in a more
reasonable way. This also means that we can get the exact current and
past frame durations without going through awful stuff. (The main
problem is that vo_pts_history contains future frames as well, which is
needed for frame backstepping etc., but gets in the way here.)
Also disable the automatic disabling of display-sync if the frame
duration changes, and extend the frame durations allowed for display
sync. To allow arbitrarily high durations, vo.c needs to be changed
to pause and potentially redraw OSD while showing a single frame, so
they're still limited.
In an attempt to deal with VFR, calculate the overall speed using the
average FPS. The frame scheduling itself does not use the average FPS,
but the duration of the current frame. This does not work too well,
but provides a good base for further improvements.
Where this commit actually helps a lot is dealing with rounded
timestamps, e.g. if the container framerate is wrong or unknown, or
if the muxer wrote incorrectly rounded timestamps. While the rounding
errors apparently can't be get rid of completely in the general case,
this is still much better than e.g. disabling display-sync completely
just because some frame durations go out of bounds.
2015-11-13 21:45:40 +00:00
|
|
|
shift_frames(mpctx);
|
|
|
|
|
|
2015-10-28 22:50:54 +00:00
|
|
|
schedule_frame(mpctx, frame);
|
2015-01-30 20:18:30 +00:00
|
|
|
|
2014-09-25 18:25:24 +00:00
|
|
|
mpctx->osd_force_update = true;
|
2014-07-30 21:24:08 +00:00
|
|
|
update_osd_msg(mpctx);
|
|
|
|
|
|
2015-07-28 21:54:39 +00:00
|
|
|
vo_queue_frame(vo, frame);
|
2015-07-01 17:24:28 +00:00
|
|
|
|
video: make decoder wrapper a filter
Move dec_video.c to filters/f_decoder_wrapper.c. It essentially becomes
a source filter. vd.h mostly disappears, because mp_filter takes care of
the dataflow, but its remains are in struct mp_decoder_fns.
One goal is to simplify dataflow by letting the filter framework handle
it (or more accurately, using its conventions). One result is that the
decode calls disappear from video.c, because we simply connect the
decoder wrapper and the filter chain with mp_pin_connect().
Another goal is to eventually remove the code duplication between the
audio and video paths for this. This commit prepares for this by trying
to make f_decoder_wrapper.c extensible, so it can be used for audio as
well later.
Decoder framedropping changes a bit. It doesn't seem to be worse than
before, and it's an obscure feature, so I'm content with its new state.
Some special code that was apparently meant to avoid dropping too many
frames in a row is removed, though.
I'm not sure how the source code tree should be organized. For one,
video/decode/vd_lavc.c is the only file in its directory, which is a bit
annoying.
2018-01-28 09:08:45 +00:00
|
|
|
check_framedrop(mpctx, vo_c);
|
|
|
|
|
|
2015-07-01 17:22:40 +00:00
|
|
|
// The frames were shifted down; "initialize" the new first entry.
|
|
|
|
|
if (mpctx->num_next_frames >= 1)
|
|
|
|
|
handle_new_frame(mpctx);
|
2015-03-25 12:33:34 +00:00
|
|
|
|
2014-07-30 21:24:08 +00:00
|
|
|
mpctx->shown_vframes++;
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 21:02:08 +00:00
|
|
|
if (mpctx->video_status < STATUS_PLAYING) {
|
2014-07-30 21:24:08 +00:00
|
|
|
mpctx->video_status = STATUS_READY;
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 21:02:08 +00:00
|
|
|
// After a seek, make sure to wait until the first frame is visible.
|
2018-03-02 14:37:34 +00:00
|
|
|
if (!opts->video_latency_hacks) {
|
|
|
|
|
vo_wait_frame(vo);
|
|
|
|
|
MP_VERBOSE(mpctx, "first video frame after restart shown\n");
|
|
|
|
|
}
|
video: move display and timing to a separate thread
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
2014-08-12 21:02:08 +00:00
|
|
|
}
|
2014-07-30 21:24:08 +00:00
|
|
|
|
|
|
|
|
mp_notify(mpctx, MPV_EVENT_TICK, NULL);
|
|
|
|
|
|
player: dumb seeking related stuff, make audio hr-seek default
Try to deal with various corner cases. But when I fix one thing, another
thing breaks. (And it's 50/50 whether I find the breakage immediately or
a few months later.) So results may vary.
The default for--hr-seek is changed to "default" (not creative enough to
find a better name). In this mode, audio seeking is exact if there is no
video, or if the video has only a single frame. This change is actually
pretty dumb, since audio frames are usually small enough that exact
seeking does not really add much. But it gets rid of some weird special
cases.
Internally, the most important change is that is_coverart and is_sparse
handling is merged. is_sparse was originally just a special case for
weird .ts streams that have the corresponding low-level flag set. The
idea is that they're pretty similar anyway, so this would reduce the
number of corner cases. But I'm not sure if this doesn't break the
original intended use case for it (I don't have a sample anyway).
This changes last-frame handling, and respects the duration of the last
frame only if audio is disabled. This is mostly "coincidental" due to
the need to make seeking past EOF trigger player exit, and is caused by
setting STATUS_EOF early. On the other hand, this might have been this
way before (see removed chunk close to it).
2020-02-28 16:15:07 +00:00
|
|
|
// hr-seek past EOF -> returns last frame, but terminates playback. The
|
|
|
|
|
// early EOF is needed to trigger the exit before the next seek is executed.
|
|
|
|
|
// Always using early EOF breaks other cases, like images.
|
|
|
|
|
if (logical_eof && !mpctx->num_next_frames && mpctx->ao_chain)
|
player: make repeated hr-seeks past EOF trigger EOF as expected
If you have a normal file with audio and video, and keep "spamming"
forward hr-seeks, the player just kept showing the last video frame
instead of exiting or playing the next file. This started happening
since commit 6bcda94cb. Although not a bug per se, it was odd, and very
user-noticable.
The main problem was that the pending seek command was processed before
the EOF was "noticed". Processing the command reset everything, so the
player did not terminate playback, but repeated the seek.
This commit restores the old behavior.
For one, it makes video return the correct status (video.c). The
parameter is a bit ugly, but better than duplicating the logic or having
another MPContext field. (As a minor detail, setting r=VD_EOF makes sure
have_new_frame() returns true, rather than going through another
iteration or whatever the hell will happen instead, which would clobber
logical_eof.)
Another thing is making the seek logic actually wait until the seek
outcome has been determined if audio is also active. Audio needs to wait
for video in order to get the video seek target position. (Which in turn
is because hr-seek still "snaps" to video frames. You can't seek in
between two frames, so audio can't just use the seek target, but always
has to wait on the timestamp of the video frame. This has other
disadvantages and is a misdesign, but not something I'll fix today.)
In theory, this might make hr-seeks less responsive, because it needs to
fully decode/filter the audio too, but in practice most time is spent on
video, which had to be fully decoded before this change. (In general,
hr-seek could probably just show a random frame when a queued hr-seek
overrides the current hr-seek, which would probably lead to a better
user experience, but that's out of scope.)
Fixes: #7206
2019-12-14 13:17:16 +00:00
|
|
|
mpctx->video_status = STATUS_EOF;
|
|
|
|
|
|
2014-08-03 18:25:03 +00:00
|
|
|
if (mpctx->video_status != STATUS_EOF) {
|
|
|
|
|
if (mpctx->step_frames > 0) {
|
|
|
|
|
mpctx->step_frames--;
|
2017-04-14 16:22:45 +00:00
|
|
|
if (!mpctx->step_frames)
|
|
|
|
|
set_pause_state(mpctx, true);
|
2014-08-03 18:25:03 +00:00
|
|
|
}
|
2015-07-08 19:31:31 +00:00
|
|
|
if (mpctx->max_frames == 0 && !mpctx->stop_play)
|
2014-10-10 13:14:11 +00:00
|
|
|
mpctx->stop_play = AT_END_OF_FILE;
|
2014-08-03 18:25:03 +00:00
|
|
|
if (mpctx->max_frames > 0)
|
|
|
|
|
mpctx->max_frames--;
|
|
|
|
|
}
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
|
2019-12-16 00:15:43 +00:00
|
|
|
vo_c->underrun_signaled = false;
|
|
|
|
|
|
2020-04-09 23:28:06 +00:00
|
|
|
if (mpctx->video_status == STATUS_EOF || mpctx->stop_play)
|
|
|
|
|
mp_wakeup_core(mpctx);
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
error:
|
|
|
|
|
MP_FATAL(mpctx, "Could not initialize video chain.\n");
|
2014-10-03 17:57:49 +00:00
|
|
|
uninit_video_chain(mpctx);
|
2016-02-05 22:41:44 +00:00
|
|
|
error_on_track(mpctx, track);
|
video: fix and simplify video format changes and last frame display
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
2014-08-12 21:17:35 +00:00
|
|
|
handle_force_window(mpctx, true);
|
2016-09-16 12:24:15 +00:00
|
|
|
mp_wakeup_core(mpctx);
|
2014-07-30 21:24:08 +00:00
|
|
|
}
|
