2013-10-29 22:38:29 +01:00
|
|
|
/*
|
2015-04-13 09:36:54 +02:00
|
|
|
* This file is part of mpv.
|
2013-10-29 22:38:29 +01: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 15:53:41 +02: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 22:38:29 +01:00
|
|
|
*
|
2015-04-13 09:36:54 +02:00
|
|
|
* mpv is distributed in the hope that it will be useful,
|
2013-10-29 22:38:29 +01: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 15:53:41 +02:00
|
|
|
* GNU Lesser General Public License for more details.
|
2013-10-29 22:38:29 +01: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 15:53:41 +02: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 22:38:29 +01:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <stddef.h>
|
|
|
|
|
#include <stdbool.h>
|
|
|
|
|
#include <inttypes.h>
|
|
|
|
|
#include <math.h>
|
|
|
|
|
#include <assert.h>
|
|
|
|
|
|
|
|
|
|
#include "config.h"
|
2016-01-11 19:03:40 +01:00
|
|
|
#include "mpv_talloc.h"
|
2013-10-29 22:38:29 +01:00
|
|
|
|
2013-12-17 02:39:45 +01:00
|
|
|
#include "common/msg.h"
|
2013-12-17 02:02:25 +01:00
|
|
|
#include "options/options.h"
|
2013-12-17 02:39:45 +01:00
|
|
|
#include "common/common.h"
|
|
|
|
|
#include "common/encode.h"
|
2017-02-07 17:05:17 +01:00
|
|
|
#include "common/recorder.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 10:08:45 +01:00
|
|
|
#include "filters/f_decoder_wrapper.h"
|
2016-09-23 12:09:48 +02:00
|
|
|
#include "options/m_config.h"
|
2013-12-17 02:02:25 +01:00
|
|
|
#include "options/m_property.h"
|
2013-12-17 02:39:45 +01:00
|
|
|
#include "common/playlist.h"
|
2013-12-17 01:23:09 +01:00
|
|
|
#include "input/input.h"
|
2013-10-29 22:38:29 +01:00
|
|
|
|
2014-04-23 20:37:57 +02:00
|
|
|
#include "misc/dispatch.h"
|
2013-12-19 21:31:27 +01:00
|
|
|
#include "osdep/terminal.h"
|
2013-10-29 22:38:29 +01:00
|
|
|
#include "osdep/timer.h"
|
|
|
|
|
|
|
|
|
|
#include "audio/out/ao.h"
|
|
|
|
|
#include "demux/demux.h"
|
|
|
|
|
#include "stream/stream.h"
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 02:10:51 +02:00
|
|
|
#include "sub/dec_sub.h"
|
2013-11-24 12:58:06 +01:00
|
|
|
#include "sub/osd.h"
|
2013-10-29 22:38:29 +01:00
|
|
|
#include "video/out/vo.h"
|
|
|
|
|
|
2013-12-17 01:08:53 +01:00
|
|
|
#include "core.h"
|
2014-08-28 17:35:50 +02:00
|
|
|
#include "client.h"
|
2013-10-29 22:38:29 +01:00
|
|
|
#include "command.h"
|
|
|
|
|
|
2016-09-16 14:23:54 +02:00
|
|
|
// Wait until mp_wakeup_core() is called, since the last time
|
2016-09-16 14:25:50 +02:00
|
|
|
// mp_wait_events() was called.
|
|
|
|
|
void mp_wait_events(struct MPContext *mpctx)
|
2014-09-06 16:57:46 +02:00
|
|
|
{
|
2017-02-21 15:16:38 +01:00
|
|
|
bool sleeping = mpctx->sleeptime > 0;
|
|
|
|
|
if (sleeping)
|
2016-09-16 14:25:50 +02:00
|
|
|
MP_STATS(mpctx, "start sleep");
|
|
|
|
|
|
|
|
|
|
mp_dispatch_queue_process(mpctx->dispatch, mpctx->sleeptime);
|
|
|
|
|
|
|
|
|
|
mpctx->sleeptime = INFINITY;
|
|
|
|
|
|
2017-02-21 15:16:38 +01:00
|
|
|
if (sleeping)
|
2016-09-16 14:25:50 +02:00
|
|
|
MP_STATS(mpctx, "end sleep");
|
2014-09-06 16:57:46 +02:00
|
|
|
}
|
|
|
|
|
|
2016-09-16 14:24:15 +02:00
|
|
|
// Set the timeout used when the playloop goes to sleep. This means the
|
|
|
|
|
// playloop will re-run as soon as the timeout elapses (or earlier).
|
|
|
|
|
// mp_set_timeout(c, 0) is essentially equivalent to mp_wakeup_core(c).
|
|
|
|
|
void mp_set_timeout(struct MPContext *mpctx, double sleeptime)
|
|
|
|
|
{
|
2018-04-15 11:43:49 +02:00
|
|
|
if (mpctx->sleeptime > sleeptime) {
|
|
|
|
|
mpctx->sleeptime = sleeptime;
|
|
|
|
|
int64_t abstime = mp_add_timeout(mp_time_us(), sleeptime);
|
|
|
|
|
mp_dispatch_adjust_timeout(mpctx->dispatch, abstime);
|
|
|
|
|
}
|
2016-09-16 14:24:15 +02:00
|
|
|
}
|
|
|
|
|
|
2016-09-16 14:23:54 +02:00
|
|
|
// Cause the playloop to run. This can be called from any thread. If called
|
|
|
|
|
// from within the playloop itself, it will be run immediately again, instead
|
|
|
|
|
// of going to sleep in the next mp_wait_events().
|
|
|
|
|
void mp_wakeup_core(struct MPContext *mpctx)
|
|
|
|
|
{
|
2016-09-16 14:25:50 +02:00
|
|
|
mp_dispatch_interrupt(mpctx->dispatch);
|
2016-09-16 14:23:54 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Opaque callback variant of mp_wakeup_core().
|
|
|
|
|
void mp_wakeup_core_cb(void *ctx)
|
|
|
|
|
{
|
|
|
|
|
struct MPContext *mpctx = ctx;
|
|
|
|
|
mp_wakeup_core(mpctx);
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-06 18:27:18 +02:00
|
|
|
void mp_core_lock(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
mp_dispatch_lock(mpctx->dispatch);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void mp_core_unlock(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
mp_dispatch_unlock(mpctx->dispatch);
|
|
|
|
|
}
|
|
|
|
|
|
2014-09-06 16:57:46 +02:00
|
|
|
// Process any queued input, whether it's user input, or requests from client
|
|
|
|
|
// API threads. This also resets the "wakeup" flag used with mp_wait_events().
|
|
|
|
|
void mp_process_input(struct MPContext *mpctx)
|
|
|
|
|
{
|
2014-09-07 20:44:54 +02:00
|
|
|
for (;;) {
|
|
|
|
|
mp_cmd_t *cmd = mp_input_read_cmd(mpctx->input);
|
|
|
|
|
if (!cmd)
|
|
|
|
|
break;
|
2018-05-12 18:46:37 +02:00
|
|
|
run_command(mpctx, cmd, NULL, NULL, NULL);
|
2014-09-06 16:57:46 +02:00
|
|
|
}
|
2016-09-16 14:25:50 +02:00
|
|
|
mp_set_timeout(mpctx, mp_input_get_delay(mpctx->input));
|
2014-09-06 16:57:46 +02:00
|
|
|
}
|
|
|
|
|
|
Relicense some non-MPlayer source files to LGPL 2.1 or later
This covers source files which were added in mplayer2 and mpv times
only, and where all code is covered by LGPL relicensing agreements.
There are probably more files to which this applies, but I'm being
conservative here.
A file named ao_sdl.c exists in MPlayer too, but the mpv one is a
complete rewrite, and was added some time after the original ao_sdl.c
was removed. The same applies to vo_sdl.c, for which the SDL2 API is
radically different in addition (MPlayer supports SDL 1.2 only).
common.c contains only code written by me. But common.h is a strange
case: although it originally was named mp_common.h and exists in MPlayer
too, by now it contains only definitions written by uau and me. The
exceptions are the CONTROL_ defines - thus not changing the license of
common.h yet.
codec_tags.c contained once large tables generated from MPlayer's
codecs.conf, but all of these tables were removed.
From demux_playlist.c I'm removing a code fragment from someone who was
not asked; this probably could be done later (see commit 15dccc37).
misc.c is a bit complicated to reason about (it was split off mplayer.c
and thus contains random functions out of this file), but actually all
functions have been added post-MPlayer. Except get_relative_time(),
which was written by uau, but looks similar to 3 different versions of
something similar in each of the Unix/win32/OSX timer source files. I'm
not sure what that means in regards to copyright, so I've just moved it
into another still-GPL source file for now.
screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but
they're all gone.
2016-01-19 18:36:06 +01:00
|
|
|
double get_relative_time(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
int64_t new_time = mp_time_us();
|
|
|
|
|
int64_t delta = new_time - mpctx->last_time;
|
|
|
|
|
mpctx->last_time = new_time;
|
|
|
|
|
return delta * 0.000001;
|
|
|
|
|
}
|
|
|
|
|
|
2017-04-14 18:56:03 +02:00
|
|
|
void update_core_idle_state(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
bool eof = mpctx->video_status == STATUS_EOF &&
|
|
|
|
|
mpctx->audio_status == STATUS_EOF;
|
2018-05-19 18:25:54 +02:00
|
|
|
bool active = !mpctx->paused && mpctx->restart_complete &&
|
2019-03-11 18:15:55 +01:00
|
|
|
!mpctx->stop_play && mpctx->in_playloop && !eof;
|
2017-04-14 18:56:03 +02:00
|
|
|
|
|
|
|
|
if (mpctx->playback_active != active) {
|
|
|
|
|
mpctx->playback_active = active;
|
|
|
|
|
|
|
|
|
|
update_screensaver_state(mpctx);
|
|
|
|
|
|
|
|
|
|
mp_notify(mpctx, MP_EVENT_CORE_IDLE, NULL);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-04-14 18:22:45 +02:00
|
|
|
// The value passed here is the new value for mpctx->opts->pause
|
|
|
|
|
void set_pause_state(struct MPContext *mpctx, bool user_pause)
|
2013-10-29 22:38:29 +01:00
|
|
|
{
|
2017-04-14 18:22:45 +02:00
|
|
|
struct MPOpts *opts = mpctx->opts;
|
|
|
|
|
bool send_update = false;
|
2013-10-29 22:38:29 +01:00
|
|
|
|
2017-04-14 18:22:45 +02:00
|
|
|
if (opts->pause != user_pause)
|
|
|
|
|
send_update = true;
|
|
|
|
|
opts->pause = user_pause;
|
2016-09-16 14:24:15 +02:00
|
|
|
|
2017-04-14 18:22:45 +02:00
|
|
|
bool internal_paused = opts->pause || mpctx->paused_for_cache;
|
|
|
|
|
if (internal_paused != mpctx->paused) {
|
|
|
|
|
mpctx->paused = internal_paused;
|
|
|
|
|
send_update = true;
|
2013-10-29 22:38:29 +01:00
|
|
|
|
2017-04-14 18:22:45 +02:00
|
|
|
if (mpctx->ao && mpctx->ao_chain) {
|
|
|
|
|
if (internal_paused) {
|
|
|
|
|
ao_pause(mpctx->ao);
|
|
|
|
|
} else {
|
|
|
|
|
ao_resume(mpctx->ao);
|
|
|
|
|
}
|
|
|
|
|
}
|
2013-10-29 22:38:29 +01:00
|
|
|
|
2017-04-14 18:22:45 +02:00
|
|
|
if (mpctx->video_out)
|
|
|
|
|
vo_set_paused(mpctx->video_out, internal_paused);
|
2013-10-29 22:38:29 +01:00
|
|
|
|
2017-04-14 18:22:45 +02:00
|
|
|
mpctx->osd_function = 0;
|
|
|
|
|
mpctx->osd_force_update = true;
|
2013-10-29 22:38:29 +01:00
|
|
|
|
2017-04-14 18:22:45 +02:00
|
|
|
mp_wakeup_core(mpctx);
|
video: add VO framedropping mode
This mostly uses the same idea as with vo_vdpau.c, but much simplified.
On X11, it tries to get the display framerate with XF86VM, and limits
the frequency of new video frames against it. Note that this is an old
extension, and is confirmed not to work correctly with multi-monitor
setups. But we're using it because it was already around (it is also
used by vo_vdpau).
This attempts to predict the next vsync event by using the time of the
last frame and the display FPS. Even if that goes completely wrong,
the results are still relatively good.
On other systems, or if the X11 code doesn't return a display FPS, a
framerate of 1000 is assumed. This is infinite for all practical
purposes, and means that only frames which are definitely too late are
dropped. This probably has worse results, but is still useful.
"--framedrop=yes" is basically replaced with "--framedrop=decoder". The
old framedropping mode is kept around, and should perhaps be improved.
Dropping on the decoder level is still useful if decoding itself is too
slow.
2014-08-15 23:33:33 +02:00
|
|
|
|
2017-04-14 18:22:45 +02:00
|
|
|
if (internal_paused) {
|
|
|
|
|
mpctx->step_frames = 0;
|
|
|
|
|
mpctx->time_frame -= get_relative_time(mpctx);
|
|
|
|
|
} else {
|
|
|
|
|
(void)get_relative_time(mpctx); // ignore time that passed during pause
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-09-16 14:24:15 +02:00
|
|
|
|
2017-04-14 18:56:03 +02:00
|
|
|
update_core_idle_state(mpctx);
|
|
|
|
|
|
|
|
|
|
if (send_update)
|
2017-04-14 18:22:45 +02:00
|
|
|
mp_notify(mpctx, opts->pause ? MPV_EVENT_PAUSE : MPV_EVENT_UNPAUSE, 0);
|
|
|
|
|
}
|
2014-02-24 22:49:07 +01:00
|
|
|
|
2017-04-14 18:22:45 +02:00
|
|
|
void update_internal_pause_state(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
set_pause_state(mpctx, mpctx->opts->pause);
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
|
|
|
|
|
2016-10-02 12:33:34 +02:00
|
|
|
void update_screensaver_state(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
if (!mpctx->video_out)
|
|
|
|
|
return;
|
|
|
|
|
|
2017-04-14 18:56:03 +02:00
|
|
|
bool saver_state = !mpctx->playback_active || !mpctx->opts->stop_screensaver;
|
2017-02-21 14:18:30 +01:00
|
|
|
vo_control_async(mpctx->video_out, saver_state ? VOCTRL_RESTORE_SCREENSAVER
|
|
|
|
|
: VOCTRL_KILL_SCREENSAVER, NULL);
|
2016-10-02 12:33:34 +02:00
|
|
|
}
|
|
|
|
|
|
2013-10-29 22:38:29 +01:00
|
|
|
void add_step_frame(struct MPContext *mpctx, int dir)
|
|
|
|
|
{
|
2016-01-17 18:07:50 +01:00
|
|
|
if (!mpctx->vo_chain)
|
2013-10-29 22:38:29 +01:00
|
|
|
return;
|
|
|
|
|
if (dir > 0) {
|
|
|
|
|
mpctx->step_frames += 1;
|
2017-04-14 18:22:45 +02:00
|
|
|
set_pause_state(mpctx, false);
|
2013-10-29 22:38:29 +01:00
|
|
|
} else if (dir < 0) {
|
2016-04-27 17:01:17 +02:00
|
|
|
if (!mpctx->hrseek_active) {
|
2016-08-15 21:07:32 +02:00
|
|
|
queue_seek(mpctx, MPSEEK_BACKSTEP, 0, MPSEEK_VERY_EXACT, 0);
|
2017-04-14 18:22:45 +02:00
|
|
|
set_pause_state(mpctx, true);
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-30 23:01:55 +02:00
|
|
|
// Clear some playback-related fields on file loading or after seeks.
|
|
|
|
|
void reset_playback_state(struct MPContext *mpctx)
|
2013-10-29 22:38:29 +01: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 11:53:44 +01:00
|
|
|
mp_filter_reset(mpctx->filter_root);
|
|
|
|
|
|
2014-07-30 23:01:55 +02:00
|
|
|
reset_video_state(mpctx);
|
|
|
|
|
reset_audio_state(mpctx);
|
|
|
|
|
reset_subtitle_state(mpctx);
|
2013-10-29 22:38:29 +01:00
|
|
|
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 02:10:51 +02:00
|
|
|
for (int n = 0; n < mpctx->num_tracks; n++) {
|
|
|
|
|
struct track *t = mpctx->tracks[n];
|
|
|
|
|
if (t->dec)
|
|
|
|
|
t->dec->play_dir = mpctx->play_dir;
|
|
|
|
|
if (t->d_sub)
|
|
|
|
|
sub_set_play_dir(t->d_sub, mpctx->play_dir);
|
|
|
|
|
}
|
|
|
|
|
|
2013-10-29 22:38:29 +01:00
|
|
|
mpctx->hrseek_active = false;
|
2014-12-07 02:47:09 +01:00
|
|
|
mpctx->hrseek_lastframe = false;
|
2016-01-12 23:49:00 +01:00
|
|
|
mpctx->hrseek_backstep = false;
|
2017-08-14 14:02:13 +02:00
|
|
|
mpctx->current_seek = (struct seek_params){0};
|
2013-10-29 22:38:29 +01:00
|
|
|
mpctx->playback_pts = MP_NOPTS_VALUE;
|
2014-11-29 00:24:51 +01:00
|
|
|
mpctx->step_frames = 0;
|
2016-08-18 20:40:23 +02:00
|
|
|
mpctx->ab_loop_clip = true;
|
2014-07-28 20:40:43 +02:00
|
|
|
mpctx->restart_complete = false;
|
2018-01-06 15:49:32 +01:00
|
|
|
mpctx->paused_for_cache = false;
|
|
|
|
|
mpctx->cache_buffer = 100;
|
2018-01-17 07:07:15 +01:00
|
|
|
mpctx->seek_slave = NULL;
|
2013-10-29 22:38:29 +01:00
|
|
|
|
|
|
|
|
encode_lavc_discontinuity(mpctx->encode_lavc_ctx);
|
2017-04-14 18:56:03 +02:00
|
|
|
|
2018-01-06 15:49:32 +01:00
|
|
|
update_internal_pause_state(mpctx);
|
2017-04-14 18:56:03 +02:00
|
|
|
update_core_idle_state(mpctx);
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
|
|
|
|
|
2016-06-08 12:04:56 +02:00
|
|
|
static void mp_seek(MPContext *mpctx, struct seek_params seek)
|
2013-10-29 22:38:29 +01:00
|
|
|
{
|
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
|
|
|
|
|
2018-01-17 07:07:15 +01:00
|
|
|
if (!mpctx->demuxer || !seek.type || seek.amount == MP_NOPTS_VALUE)
|
2016-06-08 12:04:56 +02:00
|
|
|
return;
|
2013-10-29 22:38:29 +01:00
|
|
|
|
2015-03-04 17:21:05 +01:00
|
|
|
bool hr_seek_very_exact = seek.exact == MPSEEK_VERY_EXACT;
|
2016-02-28 19:43:07 +01:00
|
|
|
double current_time = get_current_time(mpctx);
|
2016-10-20 20:43:17 +02:00
|
|
|
if (current_time == MP_NOPTS_VALUE && seek.type == MPSEEK_RELATIVE)
|
|
|
|
|
return;
|
2016-02-28 19:43:07 +01:00
|
|
|
if (current_time == MP_NOPTS_VALUE)
|
|
|
|
|
current_time = 0;
|
|
|
|
|
double seek_pts = MP_NOPTS_VALUE;
|
|
|
|
|
int demux_flags = 0;
|
2015-08-21 15:37:07 +02:00
|
|
|
|
|
|
|
|
switch (seek.type) {
|
|
|
|
|
case MPSEEK_ABSOLUTE:
|
2016-02-28 19:43:07 +01:00
|
|
|
seek_pts = seek.amount;
|
2015-08-21 15:37:07 +02:00
|
|
|
break;
|
2016-01-12 23:49:00 +01:00
|
|
|
case MPSEEK_BACKSTEP:
|
2016-02-28 19:43:07 +01:00
|
|
|
seek_pts = current_time;
|
|
|
|
|
hr_seek_very_exact = true;
|
2016-01-12 23:49:00 +01:00
|
|
|
break;
|
2015-08-21 15:37:07 +02:00
|
|
|
case MPSEEK_RELATIVE:
|
2017-10-23 19:05:39 +02:00
|
|
|
demux_flags = seek.amount > 0 ? SEEK_FORWARD : 0;
|
2016-02-28 19:43:07 +01:00
|
|
|
seek_pts = current_time + seek.amount;
|
2015-08-21 15:37:07 +02:00
|
|
|
break;
|
|
|
|
|
case MPSEEK_FACTOR: ;
|
|
|
|
|
double len = get_time_length(mpctx);
|
|
|
|
|
if (len >= 0)
|
2016-02-28 19:43:07 +01:00
|
|
|
seek_pts = seek.amount * len;
|
2015-08-21 15:37:07 +02:00
|
|
|
break;
|
2016-02-28 19:43:07 +01:00
|
|
|
default: abort();
|
2015-08-21 15:37:07 +02:00
|
|
|
}
|
|
|
|
|
|
2016-02-28 19:43:07 +01:00
|
|
|
double demux_pts = seek_pts;
|
|
|
|
|
|
|
|
|
|
bool hr_seek = opts->correct_pts && seek.exact != MPSEEK_KEYFRAME &&
|
|
|
|
|
((opts->hr_seek == 0 && seek.type == MPSEEK_ABSOLUTE) ||
|
|
|
|
|
opts->hr_seek > 0 || seek.exact >= MPSEEK_EXACT) &&
|
|
|
|
|
seek_pts != MP_NOPTS_VALUE;
|
|
|
|
|
|
2013-10-29 22:38:29 +01:00
|
|
|
if (seek.type == MPSEEK_FACTOR || seek.amount < 0 ||
|
|
|
|
|
(seek.type == MPSEEK_ABSOLUTE && seek.amount < mpctx->last_chapter_pts))
|
|
|
|
|
mpctx->last_chapter_seek = -2;
|
2015-08-21 15:37:07 +02:00
|
|
|
|
2016-02-28 19:43:07 +01:00
|
|
|
// Under certain circumstances, prefer SEEK_FACTOR.
|
|
|
|
|
if (seek.type == MPSEEK_FACTOR && !hr_seek &&
|
|
|
|
|
(mpctx->demuxer->ts_resets_possible || seek_pts == MP_NOPTS_VALUE))
|
2015-08-21 15:37:07 +02:00
|
|
|
{
|
2016-02-28 19:43:07 +01:00
|
|
|
demux_pts = seek.amount;
|
|
|
|
|
demux_flags |= SEEK_FACTOR;
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
2015-08-21 15:37:07 +02:00
|
|
|
|
2019-05-24 02:30:44 +02:00
|
|
|
int play_dir = opts->play_dir;
|
|
|
|
|
if (play_dir < 0)
|
|
|
|
|
demux_flags |= SEEK_SATAN;
|
|
|
|
|
|
2016-02-28 19:43:07 +01:00
|
|
|
if (hr_seek) {
|
|
|
|
|
double hr_seek_offset = opts->hr_seek_demuxer_offset;
|
|
|
|
|
// Always try to compensate for possibly bad demuxers in "special"
|
|
|
|
|
// situations where we need more robustness from the hr-seek code, even
|
|
|
|
|
// if the user doesn't use --hr-seek-demuxer-offset.
|
|
|
|
|
// The value is arbitrary, but should be "good enough" in most situations.
|
|
|
|
|
if (hr_seek_very_exact)
|
|
|
|
|
hr_seek_offset = MPMAX(hr_seek_offset, 0.5); // arbitrary
|
2016-08-04 11:26:57 +02:00
|
|
|
for (int n = 0; n < mpctx->num_tracks; n++) {
|
|
|
|
|
double offset = 0;
|
|
|
|
|
if (!mpctx->tracks[n]->is_external)
|
|
|
|
|
offset += get_track_seek_offset(mpctx, mpctx->tracks[n]);
|
|
|
|
|
hr_seek_offset = MPMAX(hr_seek_offset, -offset);
|
|
|
|
|
}
|
2019-05-25 17:33:48 +02:00
|
|
|
demux_pts -= hr_seek_offset * play_dir;
|
2017-10-23 19:05:39 +02:00
|
|
|
demux_flags = (demux_flags | SEEK_HR) & ~SEEK_FORWARD;
|
2019-05-24 02:30:44 +02:00
|
|
|
// For HR seeks in backward playback mode, the correct seek rounding
|
|
|
|
|
// direction is forward instead of backward.
|
|
|
|
|
if (play_dir < 0)
|
|
|
|
|
demux_flags |= SEEK_FORWARD;
|
2015-01-19 20:45:31 +01:00
|
|
|
}
|
2013-10-29 22:38:29 +01:00
|
|
|
|
player: allow seeking in cached parts of unseekable streams
Before this change and before the seekable stream cache became a thing,
we could possibly seek using the stream cache. But we couldn't know
whether the seek would succeed. We knew the available byte range, but
could in general not tell whether a demuxer would stay within the range
when trying to seek to a specific time position. We preferred to have
safe defaults, so seeking in streams that were detected as unseekable
were not honored. We allowed overriding this via --force-seekable=yes,
in which case it depended on your luck whether the seek would work, or
the player crapped its pants.
With the demuxer packet cache, we can tell exactly whether a seek will
work (at least if there's only 1 seek range). We can just let seeks go
through. Everything to allow this is already in place, and this commit
just moves around some minor things.
Note that the demux_seek() return value was not used before, because low
level (i.e. network level) seeks are usually asynchronous, and if they
fail, the state is pretty much undefined. We simply repurpose the return
value to signal whether cache seeking worked. If it didn't, we can just
resume playback normally, because demuxing continues unaffected, and no
decoder are reset.
This should be particularly helpful to people who for some reason stream
data into stdin via streamlink and such.
2017-12-23 22:28:08 +01:00
|
|
|
if (!mpctx->demuxer->seekable)
|
|
|
|
|
demux_flags |= SEEK_CACHED;
|
|
|
|
|
|
|
|
|
|
if (!demux_seek(mpctx->demuxer, demux_pts, demux_flags)) {
|
|
|
|
|
if (!mpctx->demuxer->seekable) {
|
2018-01-17 07:07:15 +01:00
|
|
|
MP_ERR(mpctx, "Cannot seek in this stream.\n");
|
player: allow seeking in cached parts of unseekable streams
Before this change and before the seekable stream cache became a thing,
we could possibly seek using the stream cache. But we couldn't know
whether the seek would succeed. We knew the available byte range, but
could in general not tell whether a demuxer would stay within the range
when trying to seek to a specific time position. We preferred to have
safe defaults, so seeking in streams that were detected as unseekable
were not honored. We allowed overriding this via --force-seekable=yes,
in which case it depended on your luck whether the seek would work, or
the player crapped its pants.
With the demuxer packet cache, we can tell exactly whether a seek will
work (at least if there's only 1 seek range). We can just let seeks go
through. Everything to allow this is already in place, and this commit
just moves around some minor things.
Note that the demux_seek() return value was not used before, because low
level (i.e. network level) seeks are usually asynchronous, and if they
fail, the state is pretty much undefined. We simply repurpose the return
value to signal whether cache seeking worked. If it didn't, we can just
resume playback normally, because demuxing continues unaffected, and no
decoder are reset.
This should be particularly helpful to people who for some reason stream
data into stdin via streamlink and such.
2017-12-23 22:28:08 +01:00
|
|
|
MP_ERR(mpctx, "You can force it with '--force-seekable=yes'.\n");
|
|
|
|
|
}
|
|
|
|
|
return;
|
|
|
|
|
}
|
2013-10-29 22:38:29 +01:00
|
|
|
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 02:10:51 +02:00
|
|
|
mpctx->play_dir = play_dir;
|
|
|
|
|
|
2013-12-24 11:08:26 +01:00
|
|
|
// Seek external, extra files too:
|
2018-01-17 07:07:15 +01:00
|
|
|
bool has_video = false;
|
|
|
|
|
struct track *external_audio = NULL;
|
2013-12-23 20:14:54 +01:00
|
|
|
for (int t = 0; t < mpctx->num_tracks; t++) {
|
|
|
|
|
struct track *track = mpctx->tracks[t];
|
2013-12-24 11:08:26 +01:00
|
|
|
if (track->selected && track->is_external && track->demuxer) {
|
2016-02-28 19:43:07 +01:00
|
|
|
double main_new_pos = demux_pts;
|
2016-08-04 11:26:57 +02:00
|
|
|
if (!hr_seek || track->is_external)
|
|
|
|
|
main_new_pos += get_track_seek_offset(mpctx, track);
|
2016-02-28 19:43:07 +01:00
|
|
|
if (demux_flags & SEEK_FACTOR)
|
|
|
|
|
main_new_pos = seek_pts;
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 02:10:51 +02:00
|
|
|
demux_seek(track->demuxer, main_new_pos, demux_flags & SEEK_SATAN);
|
2018-01-17 07:07:15 +01:00
|
|
|
if (track->type == STREAM_AUDIO && !external_audio)
|
|
|
|
|
external_audio = track;
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
2018-01-17 07:07:15 +01:00
|
|
|
if (track->selected && !track->is_external && track->stream &&
|
|
|
|
|
track->type == STREAM_VIDEO && !track->stream->attached_picture)
|
|
|
|
|
has_video = true;
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
|
|
|
|
|
2016-08-18 20:40:23 +02:00
|
|
|
if (!(seek.flags & MPSEEK_FLAG_NOFLUSH))
|
|
|
|
|
clear_audio_output_buffers(mpctx);
|
|
|
|
|
|
2014-07-30 23:01:55 +02:00
|
|
|
reset_playback_state(mpctx);
|
2017-02-07 17:05:17 +01:00
|
|
|
if (mpctx->recorder)
|
|
|
|
|
mp_recorder_mark_discontinuity(mpctx->recorder);
|
2013-10-29 22:38:29 +01:00
|
|
|
|
2018-01-17 07:07:15 +01:00
|
|
|
// When doing keyframe seeks (hr_seek=false) backwards (no SEEK_FORWARD),
|
|
|
|
|
// then video can seek before the external audio track (because video seek
|
|
|
|
|
// granularity is coarser than audio). The result would be playing video with
|
|
|
|
|
// silence until the audio seek target is reached. Work around by blocking
|
|
|
|
|
// the demuxer (decoders can't read) and seeking to video position later.
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 02:10:51 +02:00
|
|
|
if (has_video && external_audio && !hr_seek && mpctx->play_dir > 0 &&
|
|
|
|
|
!(demux_flags & SEEK_FORWARD))
|
|
|
|
|
{
|
2018-01-17 07:07:15 +01:00
|
|
|
MP_VERBOSE(mpctx, "delayed seek for aid=%d\n", external_audio->user_tid);
|
|
|
|
|
demux_block_reading(external_audio->demuxer, true);
|
|
|
|
|
mpctx->seek_slave = external_audio;
|
|
|
|
|
}
|
|
|
|
|
|
2013-10-29 22:38:29 +01:00
|
|
|
/* Use the target time as "current position" for further relative
|
|
|
|
|
* seeks etc until a new video frame has been decoded */
|
2016-02-28 19:43:07 +01:00
|
|
|
mpctx->last_seek_pts = seek_pts;
|
2013-10-29 22:38:29 +01:00
|
|
|
|
2016-02-15 21:03:51 +01:00
|
|
|
if (hr_seek) {
|
2013-10-29 22:38:29 +01:00
|
|
|
mpctx->hrseek_active = true;
|
2016-02-28 19:43:07 +01:00
|
|
|
mpctx->hrseek_backstep = seek.type == MPSEEK_BACKSTEP;
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 02:10:51 +02:00
|
|
|
mpctx->hrseek_pts = seek_pts * mpctx->play_dir;
|
2015-06-18 22:31:55 +02: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 10:08:45 +01:00
|
|
|
// allow decoder to drop frames before hrseek_pts
|
|
|
|
|
bool hrseek_framedrop = !hr_seek_very_exact && opts->hr_seek_framedrop;
|
|
|
|
|
|
2016-01-12 23:49:00 +01:00
|
|
|
MP_VERBOSE(mpctx, "hr-seek, skipping to %f%s%s\n", mpctx->hrseek_pts,
|
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 10:08:45 +01:00
|
|
|
hrseek_framedrop ? "" : " (no framedrop)",
|
2016-01-12 23:49:00 +01:00
|
|
|
mpctx->hrseek_backstep ? " (backstep)" : "");
|
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 10:08:45 +01:00
|
|
|
|
|
|
|
|
for (int n = 0; n < mpctx->num_tracks; n++) {
|
|
|
|
|
struct track *track = mpctx->tracks[n];
|
|
|
|
|
struct mp_decoder_wrapper *dec = track->dec;
|
|
|
|
|
if (dec && hrseek_framedrop)
|
|
|
|
|
mp_decoder_wrapper_set_start_pts(dec, mpctx->hrseek_pts);
|
|
|
|
|
}
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
|
|
|
|
|
2016-02-28 19:43:07 +01:00
|
|
|
if (mpctx->stop_play == AT_END_OF_FILE)
|
|
|
|
|
mpctx->stop_play = KEEP_PLAYING;
|
|
|
|
|
|
2013-10-29 22:38:29 +01:00
|
|
|
mpctx->start_timestamp = mp_time_sec();
|
2016-09-16 14:24:15 +02:00
|
|
|
mp_wakeup_core(mpctx);
|
2013-10-29 22:38:29 +01:00
|
|
|
|
2014-07-30 23:01:55 +02:00
|
|
|
mp_notify(mpctx, MPV_EVENT_SEEK, NULL);
|
2014-07-29 00:07:54 +02:00
|
|
|
mp_notify(mpctx, MPV_EVENT_TICK, NULL);
|
player: gross hack to improve non-hr seeking with external audio tracks
Relative seeks backwards with external audio tracks does not always work
well: it tends to happen that video seek back further than audio, so
audio will remain silent until the audio's after-seek position is
reached. This happens because we strictly seek both video and audio
demuxer to the approximate desirted target PTS, and then start decoding
from that.
Commit 81358380 removes an older method that was supposed to deal with
this. It was sort of bad, because it could lead to the playback core
freezing by waiting on network.
Ideally, the demuxer layer would probably somehow deal with such seeks,
and do them in a way the audio is seeked after video. Currently this is
infeasible, because the demuxer layer assumes a single demuxer, and
external tracks simply use separate demuxer layers. (MPlayer actually
had a pseudo-demuxer that joined external tracks into a single demuxer,
but this is not flexible enough - and also, the demuxer layer as it
currently exists can't deal with dynamically removing external tracks
either. Maybe some time in the future.)
Instead, add a gross hack, that essentially reseeks the audio if it
detects that it's too far off. The result is actually not too bad,
because we can reuse the mechanism that is used for instant track
switching. This way we can make sure of the right position, without
having to care about certain other issues.
It should be noted that if the audio demuxer is used for other tracks
too, and the demuxer does not support refresh seeking, audio will
probably be off by even a higher amount. But this should be rare.
2016-08-07 16:29:13 +02:00
|
|
|
|
player: modify/simplify AB-loop behavior
This changes the behavior of the --ab-loop-a/b options. In addition, it
makes it work with backward playback mode.
The most obvious change is that the both the A and B point need to be
set now before any looping happens. Unlike before, unset points don't
implicitly use the start or end of the file. I think the old behavior
was a feature that was explicitly added/wanted. Well, it's gone now.
This is because of 2 reasons:
1. I never liked this feature, and it always got in my way (as user).
2. It's inherently annoying with backward playback mode.
In backward playback mode, the user wants to set A/B in the wrong order.
The ab-loop command will first set A, then B, so if you use this command
during backward playback, A will be set to a higher timestamps than B.
If you switch back to forward playback mode, the loop would stop
working. I want the loop to just continue to work, and the chosen
solution conflicts with the removed feature.
The order issue above _could_ be fixed by also switching the AB-loop
user option values around on direction switch. But there are no other
instances of option changes magically affecting other options, and doing
this would probably lead to unexpected misery (dying from corner cases
and such).
Another solution is sorting the A/B points by timestamps after copying
them from the user options. Then A/B options set in backward mode will
work in forward mode. This is the chosen solution. If you sort the
points, you don't know anymore whether the unset point is supposed to
signify the end or the start of the file.
The AB-loop code is slightly better abstracted now, so it should be easy
to restore the removed feature. It would still require coming up with a
solution for backwards playback, though.
A minor change is that if one point is set and the other is unset, I'm
rendering both the chapter markers and the marker for the set point.
Why? I don't know. My test file had chapters, and I guess I decided this
looked better.
This commit also fixes some subtle and obvious issues that I already
forgot about when I wrote this commit message. It cleans up some minor
code duplication and nonsense too.
Regarding backward playback, the code uses an unsanitary mix of internal
("transformed") and user timestamps. So the play_dir variable appears
more than usual.
To mention one unfixed issue: if you set an AB-loop that is completely
past the end of the file, it will get stuck in an infinite seeking loop
once playback reaches the end of the file. Fixing this reliably seemed
annoying, so the fix is "just don't do this". It's not a hard freeze
anyway.
2019-05-27 01:24:22 +02:00
|
|
|
update_ab_loop_clip(mpctx);
|
2017-08-12 23:08:48 +02:00
|
|
|
|
2017-08-14 14:02:13 +02:00
|
|
|
mpctx->current_seek = seek;
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
|
|
|
|
|
player: handle seek delays differently
The code removed from handle_input_and_seek_coalesce() did two things:
1. If there's a queued seek, stop accepting non-seek commands, and delay
them to the next playloop iteration.
2. If a seek is executing (i.e. the seek was unqueued, and now it's
trying to decode and display the first video frame), stop accepting
seek commands (and in fact all commands that were queued after the
first seek command). This logic is disabled if seeking started longer
than 300ms ago. (To avoid starvation.)
I'm not sure why 1. would be needed. It's still possible that a command
immediately executed after a seek command sees a "seeking in progress"
state, because it affects queued seeks only, and not seeks in progress.
Drop this code, since it can easily lead to input starvation, and I'm
not aware of any disadvantages.
The logic in 2. is good to make seeking behave much better, as it
guarantees that the video display is updated frequently. Keep the core
idea, but implement it differently. Now this logic is applied to seeks
only. Commands after the seek can execute freely, and like with 1., I
don't see a reason why they couldn't. However, in some cases, seeks are
supposed to be executed instantly, so queue_seek() needs an additional
parameter to signal the need for immediate update.
One nice thing is that commands like sub_seek automatically profit from
the seek delay logic. On the other hand, hitting chapter seek multiple
times still does not update the video on chapter boundaries (as it
should be).
Note that the main goal of this commit is actually simplification of the
input processing logic and to allow all commands to be executed
immediately.
2014-02-07 22:29:50 +01:00
|
|
|
// This combines consecutive seek requests.
|
2013-10-29 22:38:29 +01:00
|
|
|
void queue_seek(struct MPContext *mpctx, enum seek_type type, double amount,
|
2016-08-15 21:07:32 +02:00
|
|
|
enum seek_precision exact, int flags)
|
2013-10-29 22:38:29 +01:00
|
|
|
{
|
|
|
|
|
struct seek_params *seek = &mpctx->seek;
|
2015-06-16 23:07:46 +02:00
|
|
|
|
2016-09-16 14:24:15 +02:00
|
|
|
mp_wakeup_core(mpctx);
|
|
|
|
|
|
2015-06-16 23:07:46 +02:00
|
|
|
if (mpctx->stop_play == AT_END_OF_FILE)
|
|
|
|
|
mpctx->stop_play = KEEP_PLAYING;
|
|
|
|
|
|
2013-10-29 22:38:29 +01:00
|
|
|
switch (type) {
|
|
|
|
|
case MPSEEK_RELATIVE:
|
2016-08-15 21:07:32 +02:00
|
|
|
seek->flags |= flags;
|
2013-10-29 22:38:29 +01:00
|
|
|
if (seek->type == MPSEEK_FACTOR)
|
|
|
|
|
return; // Well... not common enough to bother doing better
|
|
|
|
|
seek->amount += amount;
|
|
|
|
|
seek->exact = MPMAX(seek->exact, exact);
|
|
|
|
|
if (seek->type == MPSEEK_NONE)
|
|
|
|
|
seek->exact = exact;
|
|
|
|
|
if (seek->type == MPSEEK_ABSOLUTE)
|
|
|
|
|
return;
|
|
|
|
|
seek->type = MPSEEK_RELATIVE;
|
|
|
|
|
return;
|
|
|
|
|
case MPSEEK_ABSOLUTE:
|
|
|
|
|
case MPSEEK_FACTOR:
|
2016-01-12 23:49:00 +01:00
|
|
|
case MPSEEK_BACKSTEP:
|
2013-10-29 22:38:29 +01:00
|
|
|
*seek = (struct seek_params) {
|
|
|
|
|
.type = type,
|
|
|
|
|
.amount = amount,
|
|
|
|
|
.exact = exact,
|
2016-08-15 21:07:32 +02:00
|
|
|
.flags = flags,
|
2013-10-29 22:38:29 +01:00
|
|
|
};
|
|
|
|
|
return;
|
|
|
|
|
case MPSEEK_NONE:
|
|
|
|
|
*seek = (struct seek_params){ 0 };
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
abort();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void execute_queued_seek(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
if (mpctx->seek.type) {
|
2014-07-29 19:59:56 +02:00
|
|
|
// Let explicitly imprecise seeks cancel precise seeks:
|
2015-03-04 17:21:05 +01:00
|
|
|
if (mpctx->hrseek_active && mpctx->seek.exact == MPSEEK_KEYFRAME)
|
2014-07-29 19:59:56 +02:00
|
|
|
mpctx->start_timestamp = -1e9;
|
player: handle seek delays differently
The code removed from handle_input_and_seek_coalesce() did two things:
1. If there's a queued seek, stop accepting non-seek commands, and delay
them to the next playloop iteration.
2. If a seek is executing (i.e. the seek was unqueued, and now it's
trying to decode and display the first video frame), stop accepting
seek commands (and in fact all commands that were queued after the
first seek command). This logic is disabled if seeking started longer
than 300ms ago. (To avoid starvation.)
I'm not sure why 1. would be needed. It's still possible that a command
immediately executed after a seek command sees a "seeking in progress"
state, because it affects queued seeks only, and not seeks in progress.
Drop this code, since it can easily lead to input starvation, and I'm
not aware of any disadvantages.
The logic in 2. is good to make seeking behave much better, as it
guarantees that the video display is updated frequently. Keep the core
idea, but implement it differently. Now this logic is applied to seeks
only. Commands after the seek can execute freely, and like with 1., I
don't see a reason why they couldn't. However, in some cases, seeks are
supposed to be executed instantly, so queue_seek() needs an additional
parameter to signal the need for immediate update.
One nice thing is that commands like sub_seek automatically profit from
the seek delay logic. On the other hand, hitting chapter seek multiple
times still does not update the video on chapter boundaries (as it
should be).
Note that the main goal of this commit is actually simplification of the
input processing logic and to allow all commands to be executed
immediately.
2014-02-07 22:29:50 +01:00
|
|
|
/* If the user seeks continuously (keeps arrow key down)
|
|
|
|
|
* try to finish showing a frame from one location before doing
|
|
|
|
|
* another seek (which could lead to unchanging display). */
|
2016-08-15 21:07:32 +02:00
|
|
|
bool delay = mpctx->seek.flags & MPSEEK_FLAG_DELAY;
|
|
|
|
|
if (delay && mpctx->video_status < STATUS_PLAYING &&
|
player: handle seek delays differently
The code removed from handle_input_and_seek_coalesce() did two things:
1. If there's a queued seek, stop accepting non-seek commands, and delay
them to the next playloop iteration.
2. If a seek is executing (i.e. the seek was unqueued, and now it's
trying to decode and display the first video frame), stop accepting
seek commands (and in fact all commands that were queued after the
first seek command). This logic is disabled if seeking started longer
than 300ms ago. (To avoid starvation.)
I'm not sure why 1. would be needed. It's still possible that a command
immediately executed after a seek command sees a "seeking in progress"
state, because it affects queued seeks only, and not seeks in progress.
Drop this code, since it can easily lead to input starvation, and I'm
not aware of any disadvantages.
The logic in 2. is good to make seeking behave much better, as it
guarantees that the video display is updated frequently. Keep the core
idea, but implement it differently. Now this logic is applied to seeks
only. Commands after the seek can execute freely, and like with 1., I
don't see a reason why they couldn't. However, in some cases, seeks are
supposed to be executed instantly, so queue_seek() needs an additional
parameter to signal the need for immediate update.
One nice thing is that commands like sub_seek automatically profit from
the seek delay logic. On the other hand, hitting chapter seek multiple
times still does not update the video on chapter boundaries (as it
should be).
Note that the main goal of this commit is actually simplification of the
input processing logic and to allow all commands to be executed
immediately.
2014-02-07 22:29:50 +01:00
|
|
|
mp_time_sec() - mpctx->start_timestamp < 0.3)
|
|
|
|
|
return;
|
2016-02-15 21:03:51 +01:00
|
|
|
mp_seek(mpctx, mpctx->seek);
|
2013-10-29 22:38:29 +01:00
|
|
|
mpctx->seek = (struct seek_params){0};
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-24 13:58:57 +01:00
|
|
|
// NOPTS (i.e. <0) if unknown
|
2013-10-29 22:38:29 +01:00
|
|
|
double get_time_length(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
struct demuxer *demuxer = mpctx->demuxer;
|
2017-11-24 13:58:57 +01:00
|
|
|
return demuxer && demuxer->duration >= 0 ? demuxer->duration : MP_NOPTS_VALUE;
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
double get_current_time(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
struct demuxer *demuxer = mpctx->demuxer;
|
2015-10-16 16:16:10 +02:00
|
|
|
if (demuxer) {
|
|
|
|
|
if (mpctx->playback_pts != MP_NOPTS_VALUE)
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 02:10:51 +02:00
|
|
|
return mpctx->playback_pts * mpctx->play_dir;
|
2015-10-16 16:16:10 +02:00
|
|
|
if (mpctx->last_seek_pts != MP_NOPTS_VALUE)
|
|
|
|
|
return mpctx->last_seek_pts;
|
|
|
|
|
}
|
|
|
|
|
return MP_NOPTS_VALUE;
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
|
|
|
|
|
2014-06-29 19:27:46 +02:00
|
|
|
double get_playback_time(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
double cur = get_current_time(mpctx);
|
2015-10-16 16:16:10 +02:00
|
|
|
if (cur == MP_NOPTS_VALUE)
|
|
|
|
|
return cur;
|
2015-04-28 22:03:18 +02:00
|
|
|
// During seeking, the time corresponds to the last seek time - apply some
|
|
|
|
|
// cosmetics to it.
|
|
|
|
|
if (mpctx->playback_pts == MP_NOPTS_VALUE) {
|
|
|
|
|
double length = get_time_length(mpctx);
|
|
|
|
|
if (length >= 0)
|
2015-11-16 22:47:17 +01:00
|
|
|
cur = MPCLAMP(cur, 0, length);
|
2015-04-28 22:03:18 +02:00
|
|
|
}
|
2015-11-16 22:47:17 +01:00
|
|
|
return cur;
|
2014-06-29 19:27:46 +02:00
|
|
|
}
|
|
|
|
|
|
2013-10-29 22:38:29 +01:00
|
|
|
// Return playback position in 0.0-1.0 ratio, or -1 if unknown.
|
|
|
|
|
double get_current_pos_ratio(struct MPContext *mpctx, bool use_range)
|
|
|
|
|
{
|
|
|
|
|
struct demuxer *demuxer = mpctx->demuxer;
|
|
|
|
|
if (!demuxer)
|
|
|
|
|
return -1;
|
|
|
|
|
double ans = -1;
|
2015-11-16 22:47:17 +01:00
|
|
|
double start = 0;
|
2013-10-29 22:38:29 +01:00
|
|
|
double len = get_time_length(mpctx);
|
|
|
|
|
if (use_range) {
|
2017-12-04 02:26:42 +01:00
|
|
|
double startpos = get_play_start_pts(mpctx);
|
2013-10-29 22:38:29 +01:00
|
|
|
double endpos = get_play_end_pts(mpctx);
|
player: modify/simplify AB-loop behavior
This changes the behavior of the --ab-loop-a/b options. In addition, it
makes it work with backward playback mode.
The most obvious change is that the both the A and B point need to be
set now before any looping happens. Unlike before, unset points don't
implicitly use the start or end of the file. I think the old behavior
was a feature that was explicitly added/wanted. Well, it's gone now.
This is because of 2 reasons:
1. I never liked this feature, and it always got in my way (as user).
2. It's inherently annoying with backward playback mode.
In backward playback mode, the user wants to set A/B in the wrong order.
The ab-loop command will first set A, then B, so if you use this command
during backward playback, A will be set to a higher timestamps than B.
If you switch back to forward playback mode, the loop would stop
working. I want the loop to just continue to work, and the chosen
solution conflicts with the removed feature.
The order issue above _could_ be fixed by also switching the AB-loop
user option values around on direction switch. But there are no other
instances of option changes magically affecting other options, and doing
this would probably lead to unexpected misery (dying from corner cases
and such).
Another solution is sorting the A/B points by timestamps after copying
them from the user options. Then A/B options set in backward mode will
work in forward mode. This is the chosen solution. If you sort the
points, you don't know anymore whether the unset point is supposed to
signify the end or the start of the file.
The AB-loop code is slightly better abstracted now, so it should be easy
to restore the removed feature. It would still require coming up with a
solution for backwards playback, though.
A minor change is that if one point is set and the other is unset, I'm
rendering both the chapter markers and the marker for the set point.
Why? I don't know. My test file had chapters, and I guess I decided this
looked better.
This commit also fixes some subtle and obvious issues that I already
forgot about when I wrote this commit message. It cleans up some minor
code duplication and nonsense too.
Regarding backward playback, the code uses an unsanitary mix of internal
("transformed") and user timestamps. So the play_dir variable appears
more than usual.
To mention one unfixed issue: if you set an AB-loop that is completely
past the end of the file, it will get stuck in an infinite seeking loop
once playback reaches the end of the file. Fixing this reliably seemed
annoying, so the fix is "just don't do this". It's not a hard freeze
anyway.
2019-05-27 01:24:22 +02:00
|
|
|
if (endpos > MPMAX(0, len))
|
2015-11-16 22:47:17 +01:00
|
|
|
endpos = MPMAX(0, len);
|
2013-10-29 22:38:29 +01:00
|
|
|
if (endpos < startpos)
|
|
|
|
|
endpos = startpos;
|
|
|
|
|
start = startpos;
|
|
|
|
|
len = endpos - startpos;
|
|
|
|
|
}
|
|
|
|
|
double pos = get_current_time(mpctx);
|
2015-01-14 22:14:20 +01:00
|
|
|
if (len > 0)
|
2013-10-29 22:38:29 +01:00
|
|
|
ans = MPCLAMP((pos - start) / len, 0, 1);
|
2015-01-14 22:14:20 +01:00
|
|
|
if (ans < 0 || demuxer->ts_resets_possible) {
|
2018-09-07 21:58:46 +02:00
|
|
|
int64_t size = demuxer->filesize;
|
|
|
|
|
if (size > 0 && demuxer->filepos >= 0)
|
|
|
|
|
ans = MPCLAMP(demuxer->filepos / (double)size, 0, 1);
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
|
|
|
|
if (use_range) {
|
|
|
|
|
if (mpctx->opts->play_frames > 0)
|
|
|
|
|
ans = MPMAX(ans, 1.0 -
|
|
|
|
|
mpctx->max_frames / (double) mpctx->opts->play_frames);
|
|
|
|
|
}
|
|
|
|
|
return ans;
|
|
|
|
|
}
|
|
|
|
|
|
2014-12-20 17:31:58 +01:00
|
|
|
// 0-100, -1 if unknown
|
2013-10-29 22:38:29 +01:00
|
|
|
int get_percent_pos(struct MPContext *mpctx)
|
|
|
|
|
{
|
2014-12-20 17:31:58 +01:00
|
|
|
double pos = get_current_pos_ratio(mpctx, false);
|
|
|
|
|
return pos < 0 ? -1 : pos * 100;
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// -2 is no chapters, -1 is before first chapter
|
|
|
|
|
int get_current_chapter(struct MPContext *mpctx)
|
|
|
|
|
{
|
2014-03-25 02:10:24 +01:00
|
|
|
if (!mpctx->num_chapters)
|
|
|
|
|
return -2;
|
2013-10-29 22:38:29 +01:00
|
|
|
double current_pts = get_current_time(mpctx);
|
2014-03-25 02:10:24 +01:00
|
|
|
int i;
|
2014-07-31 22:54:57 +02:00
|
|
|
for (i = 0; i < mpctx->num_chapters; i++)
|
2014-11-02 17:20:04 +01:00
|
|
|
if (current_pts < mpctx->chapters[i].pts)
|
2014-03-25 02:10:24 +01:00
|
|
|
break;
|
|
|
|
|
return MPMAX(mpctx->last_chapter_seek, i - 1);
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
char *chapter_display_name(struct MPContext *mpctx, int chapter)
|
|
|
|
|
{
|
|
|
|
|
char *name = chapter_name(mpctx, chapter);
|
2014-08-28 00:16:03 +02:00
|
|
|
char *dname = NULL;
|
2013-10-29 22:38:29 +01:00
|
|
|
if (name) {
|
|
|
|
|
dname = talloc_asprintf(NULL, "(%d) %s", chapter + 1, name);
|
|
|
|
|
} else if (chapter < -1) {
|
|
|
|
|
dname = talloc_strdup(NULL, "(unavailable)");
|
|
|
|
|
} else {
|
|
|
|
|
int chapter_count = get_chapter_count(mpctx);
|
|
|
|
|
if (chapter_count <= 0)
|
|
|
|
|
dname = talloc_asprintf(NULL, "(%d)", chapter + 1);
|
|
|
|
|
else
|
|
|
|
|
dname = talloc_asprintf(NULL, "(%d) of %d", chapter + 1,
|
|
|
|
|
chapter_count);
|
|
|
|
|
}
|
|
|
|
|
return dname;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// returns NULL if chapter name unavailable
|
|
|
|
|
char *chapter_name(struct MPContext *mpctx, int chapter)
|
|
|
|
|
{
|
2014-03-25 02:10:24 +01:00
|
|
|
if (chapter < 0 || chapter >= mpctx->num_chapters)
|
|
|
|
|
return NULL;
|
2015-08-12 11:10:45 +02:00
|
|
|
return mp_tags_get_str(mpctx->chapters[chapter].metadata, "title");
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
|
|
|
|
|
2015-07-10 12:11:14 +02:00
|
|
|
// returns the start of the chapter in seconds (NOPTS if unavailable)
|
2013-10-29 22:38:29 +01:00
|
|
|
double chapter_start_time(struct MPContext *mpctx, int chapter)
|
|
|
|
|
{
|
|
|
|
|
if (chapter == -1)
|
2015-11-16 22:47:17 +01:00
|
|
|
return 0;
|
2014-03-25 02:10:24 +01:00
|
|
|
if (chapter >= 0 && chapter < mpctx->num_chapters)
|
2014-11-02 17:20:04 +01:00
|
|
|
return mpctx->chapters[chapter].pts;
|
2014-03-25 02:18:12 +01:00
|
|
|
return MP_NOPTS_VALUE;
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int get_chapter_count(struct MPContext *mpctx)
|
|
|
|
|
{
|
2014-03-25 02:05:48 +01:00
|
|
|
return mpctx->num_chapters;
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
|
|
|
|
|
player: modify/simplify AB-loop behavior
This changes the behavior of the --ab-loop-a/b options. In addition, it
makes it work with backward playback mode.
The most obvious change is that the both the A and B point need to be
set now before any looping happens. Unlike before, unset points don't
implicitly use the start or end of the file. I think the old behavior
was a feature that was explicitly added/wanted. Well, it's gone now.
This is because of 2 reasons:
1. I never liked this feature, and it always got in my way (as user).
2. It's inherently annoying with backward playback mode.
In backward playback mode, the user wants to set A/B in the wrong order.
The ab-loop command will first set A, then B, so if you use this command
during backward playback, A will be set to a higher timestamps than B.
If you switch back to forward playback mode, the loop would stop
working. I want the loop to just continue to work, and the chosen
solution conflicts with the removed feature.
The order issue above _could_ be fixed by also switching the AB-loop
user option values around on direction switch. But there are no other
instances of option changes magically affecting other options, and doing
this would probably lead to unexpected misery (dying from corner cases
and such).
Another solution is sorting the A/B points by timestamps after copying
them from the user options. Then A/B options set in backward mode will
work in forward mode. This is the chosen solution. If you sort the
points, you don't know anymore whether the unset point is supposed to
signify the end or the start of the file.
The AB-loop code is slightly better abstracted now, so it should be easy
to restore the removed feature. It would still require coming up with a
solution for backwards playback, though.
A minor change is that if one point is set and the other is unset, I'm
rendering both the chapter markers and the marker for the set point.
Why? I don't know. My test file had chapters, and I guess I decided this
looked better.
This commit also fixes some subtle and obvious issues that I already
forgot about when I wrote this commit message. It cleans up some minor
code duplication and nonsense too.
Regarding backward playback, the code uses an unsanitary mix of internal
("transformed") and user timestamps. So the play_dir variable appears
more than usual.
To mention one unfixed issue: if you set an AB-loop that is completely
past the end of the file, it will get stuck in an infinite seeking loop
once playback reaches the end of the file. Fixing this reliably seemed
annoying, so the fix is "just don't do this". It's not a hard freeze
anyway.
2019-05-27 01:24:22 +02:00
|
|
|
// If the current playback position (or seek target) falls before the B
|
|
|
|
|
// position, actually make playback loop when reaching the B point. The
|
|
|
|
|
// intention is that you can seek out of the ab-loop range.
|
|
|
|
|
void update_ab_loop_clip(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
double pts = get_current_time(mpctx);
|
|
|
|
|
double ab[2];
|
|
|
|
|
mpctx->ab_loop_clip = pts != MP_NOPTS_VALUE &&
|
|
|
|
|
get_ab_loop_times(mpctx, ab) &&
|
|
|
|
|
pts * mpctx->play_dir <= ab[1] * mpctx->play_dir;
|
|
|
|
|
}
|
|
|
|
|
|
2014-08-03 19:09:22 +02:00
|
|
|
static void handle_osd_redraw(struct MPContext *mpctx)
|
2013-10-29 22:38:29 +01:00
|
|
|
{
|
|
|
|
|
if (!mpctx->video_out || !mpctx->video_out->config_ok)
|
2014-08-03 19:09:22 +02:00
|
|
|
return;
|
|
|
|
|
// If we're playing normally, let OSD be redrawn naturally as part of
|
|
|
|
|
// video display.
|
2014-08-10 13:11:46 +02:00
|
|
|
if (!mpctx->paused) {
|
|
|
|
|
if (mpctx->sleeptime < 0.1 && mpctx->video_status == STATUS_PLAYING)
|
|
|
|
|
return;
|
|
|
|
|
}
|
2014-08-03 19:09:22 +02:00
|
|
|
// Don't redraw immediately during a seek (makes it significantly slower).
|
2016-04-23 16:39:46 +02:00
|
|
|
bool use_video = mpctx->vo_chain && !mpctx->vo_chain->is_coverart;
|
|
|
|
|
if (use_video && mp_time_sec() - mpctx->start_timestamp < 0.1) {
|
2016-09-16 14:24:15 +02:00
|
|
|
mp_set_timeout(mpctx, 0.1);
|
2014-08-03 19:09:22 +02:00
|
|
|
return;
|
2014-10-03 21:57:16 +02:00
|
|
|
}
|
2014-10-03 21:53:32 +02:00
|
|
|
bool want_redraw = osd_query_and_reset_want_redraw(mpctx->osd) ||
|
|
|
|
|
vo_want_redraw(mpctx->video_out);
|
2014-06-15 20:46:57 +02:00
|
|
|
if (!want_redraw)
|
2014-08-03 19:09:22 +02:00
|
|
|
return;
|
2014-06-15 20:46:57 +02:00
|
|
|
vo_redraw(mpctx->video_out);
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
|
|
|
|
|
2019-05-17 21:59:52 +02:00
|
|
|
static void handle_update_cache(struct MPContext *mpctx)
|
2013-10-29 22:38:29 +01:00
|
|
|
{
|
2016-04-19 22:01:30 +02:00
|
|
|
bool force_update = false;
|
2013-10-29 22:38:29 +01:00
|
|
|
struct MPOpts *opts = mpctx->opts;
|
2014-07-16 22:40:21 +02:00
|
|
|
if (!mpctx->demuxer)
|
2014-05-19 23:27:09 +02:00
|
|
|
return;
|
player: redo how stream caching and pausing on low cache works
Add the --cache-secs option, which literally overrides the value of
--demuxer-readahead-secs if the stream cache is active. The default
value is very high (10 seconds), which means it can act as network
cache.
Remove the old behavior of trying to pause once the byte cache runs
low. Instead, do something similar wit the demuxer cache. The nice
thing is that we can guess how many seconds of video it has cached,
and we can make better decisions. But for now, apply a relatively
naive heuristic: if the cache is below 0.5 secs, pause, and wait
until at least 2 secs are available.
Note that due to timestamp reordering, the estimated cached duration
of video might be inaccurate, depending on the file format. If the
file format has DTS, it's easy, otherwise the duration will seemingly
jump back and forth.
2014-08-27 01:13:20 +02:00
|
|
|
|
2016-04-20 10:50:22 +02:00
|
|
|
double now = mp_time_sec();
|
|
|
|
|
|
2018-09-07 22:26:48 +02:00
|
|
|
struct demux_reader_state s;
|
|
|
|
|
demux_get_reader_state(mpctx->demuxer, &s);
|
2014-08-27 22:42:28 +02:00
|
|
|
|
2016-04-19 22:01:30 +02:00
|
|
|
int cache_buffer = 100;
|
2018-08-31 12:48:36 +02:00
|
|
|
bool use_pause_on_low_cache = demux_is_network_cached(mpctx->demuxer) &&
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 02:10:51 +02:00
|
|
|
opts->cache_pause && mpctx->play_dir > 0;
|
2018-01-06 15:49:32 +01:00
|
|
|
|
|
|
|
|
if (!mpctx->restart_complete) {
|
|
|
|
|
// Audio or video is restarting, and initial buffering is enabled. Make
|
|
|
|
|
// sure we actually restart them in paused mode, so no audio gets
|
|
|
|
|
// dropped and video technically doesn't start yet.
|
|
|
|
|
use_pause_on_low_cache &= opts->cache_pause_initial &&
|
|
|
|
|
(mpctx->video_status == STATUS_READY ||
|
|
|
|
|
mpctx->audio_status == STATUS_READY);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool is_low = use_pause_on_low_cache && !s.idle &&
|
|
|
|
|
s.ts_duration < opts->cache_pause_wait;
|
|
|
|
|
|
|
|
|
|
// Enter buffering state only if there actually was an underrun (or if
|
|
|
|
|
// initial caching before playback restart is used).
|
|
|
|
|
if (is_low && !mpctx->paused_for_cache && mpctx->restart_complete)
|
|
|
|
|
is_low = s.underrun;
|
|
|
|
|
|
|
|
|
|
if (mpctx->paused_for_cache != is_low) {
|
|
|
|
|
mpctx->paused_for_cache = is_low;
|
|
|
|
|
update_internal_pause_state(mpctx);
|
|
|
|
|
force_update = true;
|
|
|
|
|
if (is_low)
|
|
|
|
|
mpctx->cache_stop_time = now;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (mpctx->paused_for_cache) {
|
|
|
|
|
cache_buffer =
|
|
|
|
|
100 * MPCLAMP(s.ts_duration / opts->cache_pause_wait, 0, 0.99);
|
|
|
|
|
mp_set_timeout(mpctx, 0.2);
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
player: redo how stream caching and pausing on low cache works
Add the --cache-secs option, which literally overrides the value of
--demuxer-readahead-secs if the stream cache is active. The default
value is very high (10 seconds), which means it can act as network
cache.
Remove the old behavior of trying to pause once the byte cache runs
low. Instead, do something similar wit the demuxer cache. The nice
thing is that we can guess how many seconds of video it has cached,
and we can make better decisions. But for now, apply a relatively
naive heuristic: if the cache is below 0.5 secs, pause, and wait
until at least 2 secs are available.
Note that due to timestamp reordering, the estimated cached duration
of video might be inaccurate, depending on the file format. If the
file format has DTS, it's easy, otherwise the duration will seemingly
jump back and forth.
2014-08-27 01:13:20 +02:00
|
|
|
|
2014-07-31 04:19:41 +02:00
|
|
|
// Also update cache properties.
|
2018-08-31 12:48:36 +02:00
|
|
|
bool busy = !s.idle;
|
player: redo how stream caching and pausing on low cache works
Add the --cache-secs option, which literally overrides the value of
--demuxer-readahead-secs if the stream cache is active. The default
value is very high (10 seconds), which means it can act as network
cache.
Remove the old behavior of trying to pause once the byte cache runs
low. Instead, do something similar wit the demuxer cache. The nice
thing is that we can guess how many seconds of video it has cached,
and we can make better decisions. But for now, apply a relatively
naive heuristic: if the cache is below 0.5 secs, pause, and wait
until at least 2 secs are available.
Note that due to timestamp reordering, the estimated cached duration
of video might be inaccurate, depending on the file format. If the
file format has DTS, it's easy, otherwise the duration will seemingly
jump back and forth.
2014-08-27 01:13:20 +02:00
|
|
|
if (busy || mpctx->next_cache_update > 0) {
|
2014-07-31 04:19:41 +02:00
|
|
|
if (mpctx->next_cache_update <= now) {
|
player: redo how stream caching and pausing on low cache works
Add the --cache-secs option, which literally overrides the value of
--demuxer-readahead-secs if the stream cache is active. The default
value is very high (10 seconds), which means it can act as network
cache.
Remove the old behavior of trying to pause once the byte cache runs
low. Instead, do something similar wit the demuxer cache. The nice
thing is that we can guess how many seconds of video it has cached,
and we can make better decisions. But for now, apply a relatively
naive heuristic: if the cache is below 0.5 secs, pause, and wait
until at least 2 secs are available.
Note that due to timestamp reordering, the estimated cached duration
of video might be inaccurate, depending on the file format. If the
file format has DTS, it's easy, otherwise the duration will seemingly
jump back and forth.
2014-08-27 01:13:20 +02:00
|
|
|
mpctx->next_cache_update = busy ? now + 0.25 : 0;
|
2016-04-19 22:01:30 +02:00
|
|
|
force_update = true;
|
2014-07-31 04:19:41 +02:00
|
|
|
}
|
2016-09-16 14:24:15 +02:00
|
|
|
if (mpctx->next_cache_update > 0)
|
|
|
|
|
mp_set_timeout(mpctx, mpctx->next_cache_update - now);
|
2014-07-31 04:19:41 +02:00
|
|
|
}
|
2016-04-19 22:01:30 +02:00
|
|
|
|
|
|
|
|
if (mpctx->cache_buffer != cache_buffer) {
|
2018-01-06 15:49:32 +01:00
|
|
|
if ((mpctx->cache_buffer == 100) != (cache_buffer == 100)) {
|
2016-04-19 22:01:30 +02:00
|
|
|
if (cache_buffer < 100) {
|
2018-05-02 21:34:43 +02:00
|
|
|
MP_VERBOSE(mpctx, "Enter buffering (buffer went from %d%% -> %d%%) [%fs].\n",
|
|
|
|
|
mpctx->cache_buffer, cache_buffer, s.ts_duration);
|
2016-04-19 22:01:30 +02:00
|
|
|
} else {
|
2016-04-20 10:50:22 +02:00
|
|
|
double t = now - mpctx->cache_stop_time;
|
2018-05-02 21:34:43 +02:00
|
|
|
MP_VERBOSE(mpctx, "End buffering (waited %f secs) [%fs].\n",
|
|
|
|
|
t, s.ts_duration);
|
2016-04-19 22:01:30 +02:00
|
|
|
}
|
2018-05-02 21:34:43 +02:00
|
|
|
} else {
|
|
|
|
|
MP_VERBOSE(mpctx, "Still buffering (buffer went from %d%% -> %d%%) [%fs].\n",
|
|
|
|
|
mpctx->cache_buffer, cache_buffer, s.ts_duration);
|
2016-04-19 22:01:30 +02:00
|
|
|
}
|
|
|
|
|
mpctx->cache_buffer = cache_buffer;
|
|
|
|
|
force_update = true;
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-18 19:02:50 +01:00
|
|
|
if (s.eof && !busy)
|
|
|
|
|
prefetch_next(mpctx);
|
|
|
|
|
|
2016-04-19 22:01:30 +02:00
|
|
|
if (force_update)
|
|
|
|
|
mp_notify(mpctx, MP_EVENT_CACHE_UPDATE, NULL);
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
|
|
|
|
|
2016-04-19 22:01:30 +02:00
|
|
|
int get_cache_buffering_percentage(struct MPContext *mpctx)
|
2014-10-07 22:07:07 +02:00
|
|
|
{
|
2016-04-19 22:01:30 +02:00
|
|
|
return mpctx->demuxer ? mpctx->cache_buffer : -1;
|
2014-10-07 22:07:07 +02:00
|
|
|
}
|
|
|
|
|
|
2013-10-29 22:38:29 +01:00
|
|
|
static void handle_cursor_autohide(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
|
|
|
|
struct vo *vo = mpctx->video_out;
|
|
|
|
|
|
|
|
|
|
if (!vo)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
bool mouse_cursor_visible = mpctx->mouse_cursor_visible;
|
2014-07-18 15:04:46 +02:00
|
|
|
double now = mp_time_sec();
|
2013-10-29 22:38:29 +01:00
|
|
|
|
|
|
|
|
unsigned mouse_event_ts = mp_input_get_mouse_event_counter(mpctx->input);
|
|
|
|
|
if (mpctx->mouse_event_ts != mouse_event_ts) {
|
|
|
|
|
mpctx->mouse_event_ts = mouse_event_ts;
|
2014-07-18 15:04:46 +02:00
|
|
|
mpctx->mouse_timer = now + opts->cursor_autohide_delay / 1000.0;
|
2013-10-29 22:38:29 +01:00
|
|
|
mouse_cursor_visible = true;
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-18 15:04:46 +02:00
|
|
|
if (mpctx->mouse_timer > now) {
|
2016-09-16 14:24:15 +02:00
|
|
|
mp_set_timeout(mpctx, mpctx->mouse_timer - now);
|
2014-07-18 15:04:46 +02:00
|
|
|
} else {
|
2013-10-29 22:38:29 +01:00
|
|
|
mouse_cursor_visible = false;
|
2014-07-18 15:04:46 +02:00
|
|
|
}
|
2013-10-29 22:38:29 +01:00
|
|
|
|
|
|
|
|
if (opts->cursor_autohide_delay == -1)
|
|
|
|
|
mouse_cursor_visible = true;
|
|
|
|
|
|
|
|
|
|
if (opts->cursor_autohide_delay == -2)
|
|
|
|
|
mouse_cursor_visible = false;
|
|
|
|
|
|
2016-08-30 23:50:57 +02:00
|
|
|
if (opts->cursor_autohide_fs && !opts->vo->fullscreen)
|
2013-10-29 22:38:29 +01:00
|
|
|
mouse_cursor_visible = true;
|
|
|
|
|
|
|
|
|
|
if (mouse_cursor_visible != mpctx->mouse_cursor_visible)
|
|
|
|
|
vo_control(vo, VOCTRL_SET_CURSOR_VISIBILITY, &mouse_cursor_visible);
|
|
|
|
|
mpctx->mouse_cursor_visible = mouse_cursor_visible;
|
|
|
|
|
}
|
|
|
|
|
|
2014-11-02 20:26:51 +01:00
|
|
|
static void handle_vo_events(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
struct vo *vo = mpctx->video_out;
|
2014-11-09 10:00:21 +01:00
|
|
|
int events = vo ? vo_query_and_reset_events(vo, VO_EVENTS_USER) : 0;
|
2014-11-02 20:26:51 +01:00
|
|
|
if (events & VO_EVENT_RESIZE)
|
|
|
|
|
mp_notify(mpctx, MP_EVENT_WIN_RESIZE, NULL);
|
2014-11-02 20:48:45 +01:00
|
|
|
if (events & VO_EVENT_WIN_STATE)
|
|
|
|
|
mp_notify(mpctx, MP_EVENT_WIN_STATE, NULL);
|
2016-09-23 12:09:48 +02:00
|
|
|
if (events & VO_EVENT_FULLSCREEN_STATE) {
|
|
|
|
|
// The only purpose of this is to update the fullscreen flag on the
|
|
|
|
|
// playloop side if it changes "from outside" on the VO.
|
|
|
|
|
int fs = mpctx->opts->vo->fullscreen;
|
|
|
|
|
vo_control(vo, VOCTRL_GET_FULLSCREEN, &fs);
|
|
|
|
|
m_config_set_option_raw_direct(mpctx->mconfig,
|
|
|
|
|
m_config_get_co(mpctx->mconfig, bstr0("fullscreen")), &fs, 0);
|
|
|
|
|
}
|
2014-11-02 20:26:51 +01:00
|
|
|
}
|
|
|
|
|
|
2013-10-29 22:38:29 +01:00
|
|
|
static void handle_sstep(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
2014-08-03 20:25:03 +02:00
|
|
|
if (mpctx->stop_play || !mpctx->restart_complete)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
if (opts->step_sec > 0 && !mpctx->paused) {
|
2013-10-29 22:38:29 +01:00
|
|
|
set_osd_function(mpctx, OSD_FFW);
|
2016-08-15 21:07:32 +02:00
|
|
|
queue_seek(mpctx, MPSEEK_RELATIVE, opts->step_sec, MPSEEK_DEFAULT, 0);
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
2014-08-03 20:25:03 +02:00
|
|
|
|
2014-08-26 20:45:41 +02:00
|
|
|
if (mpctx->video_status >= STATUS_EOF) {
|
2015-07-08 21:31:31 +02:00
|
|
|
if (mpctx->max_frames >= 0 && !mpctx->stop_play)
|
2014-10-14 13:29:38 +02:00
|
|
|
mpctx->stop_play = AT_END_OF_FILE; // force EOF even if audio left
|
2014-08-03 20:25:03 +02:00
|
|
|
if (mpctx->step_frames > 0 && !mpctx->paused)
|
2017-04-14 18:22:45 +02:00
|
|
|
set_pause_state(mpctx, true);
|
2014-08-03 20:25:03 +02:00
|
|
|
}
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
|
|
|
|
|
2014-04-17 23:55:04 +02:00
|
|
|
static void handle_loop_file(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
2016-08-18 20:40:23 +02:00
|
|
|
|
2019-05-27 01:33:35 +02:00
|
|
|
if (mpctx->stop_play != AT_END_OF_FILE)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
double target = MP_NOPTS_VALUE;
|
|
|
|
|
enum seek_precision prec = MPSEEK_DEFAULT;
|
|
|
|
|
|
player: modify/simplify AB-loop behavior
This changes the behavior of the --ab-loop-a/b options. In addition, it
makes it work with backward playback mode.
The most obvious change is that the both the A and B point need to be
set now before any looping happens. Unlike before, unset points don't
implicitly use the start or end of the file. I think the old behavior
was a feature that was explicitly added/wanted. Well, it's gone now.
This is because of 2 reasons:
1. I never liked this feature, and it always got in my way (as user).
2. It's inherently annoying with backward playback mode.
In backward playback mode, the user wants to set A/B in the wrong order.
The ab-loop command will first set A, then B, so if you use this command
during backward playback, A will be set to a higher timestamps than B.
If you switch back to forward playback mode, the loop would stop
working. I want the loop to just continue to work, and the chosen
solution conflicts with the removed feature.
The order issue above _could_ be fixed by also switching the AB-loop
user option values around on direction switch. But there are no other
instances of option changes magically affecting other options, and doing
this would probably lead to unexpected misery (dying from corner cases
and such).
Another solution is sorting the A/B points by timestamps after copying
them from the user options. Then A/B options set in backward mode will
work in forward mode. This is the chosen solution. If you sort the
points, you don't know anymore whether the unset point is supposed to
signify the end or the start of the file.
The AB-loop code is slightly better abstracted now, so it should be easy
to restore the removed feature. It would still require coming up with a
solution for backwards playback, though.
A minor change is that if one point is set and the other is unset, I'm
rendering both the chapter markers and the marker for the set point.
Why? I don't know. My test file had chapters, and I guess I decided this
looked better.
This commit also fixes some subtle and obvious issues that I already
forgot about when I wrote this commit message. It cleans up some minor
code duplication and nonsense too.
Regarding backward playback, the code uses an unsanitary mix of internal
("transformed") and user timestamps. So the play_dir variable appears
more than usual.
To mention one unfixed issue: if you set an AB-loop that is completely
past the end of the file, it will get stuck in an infinite seeking loop
once playback reaches the end of the file. Fixing this reliably seemed
annoying, so the fix is "just don't do this". It's not a hard freeze
anyway.
2019-05-27 01:24:22 +02:00
|
|
|
double ab[2];
|
2019-05-27 01:33:35 +02:00
|
|
|
if (get_ab_loop_times(mpctx, ab) && mpctx->ab_loop_clip) {
|
|
|
|
|
target = ab[0];
|
|
|
|
|
prec = MPSEEK_EXACT;
|
|
|
|
|
} else if (opts->loop_file) {
|
|
|
|
|
if (opts->loop_file > 0)
|
|
|
|
|
opts->loop_file--;
|
|
|
|
|
target = 0;
|
2016-08-18 20:40:23 +02:00
|
|
|
}
|
|
|
|
|
|
2019-05-27 01:33:35 +02:00
|
|
|
if (target != MP_NOPTS_VALUE) {
|
2017-12-28 16:23:12 +01:00
|
|
|
mpctx->stop_play = KEEP_PLAYING;
|
|
|
|
|
set_osd_function(mpctx, OSD_FFW);
|
2019-05-27 01:33:35 +02:00
|
|
|
mark_seek(mpctx);
|
|
|
|
|
|
|
|
|
|
// Assumes execute_queued_seek() happens before next audio/video is
|
|
|
|
|
// attempted to be decoded or filtered.
|
|
|
|
|
queue_seek(mpctx, MPSEEK_ABSOLUTE, target, prec, MPSEEK_FLAG_NOFLUSH);
|
2014-04-17 23:55:04 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2014-12-08 17:27:07 +01:00
|
|
|
void seek_to_last_frame(struct MPContext *mpctx)
|
2014-12-07 02:47:09 +01:00
|
|
|
{
|
2016-01-17 18:07:50 +01:00
|
|
|
if (!mpctx->vo_chain)
|
2014-12-07 02:47:09 +01:00
|
|
|
return;
|
player: hack against --keep-open misbehaving with broken files
If a file (or a demuxer) is broken, seeking close to the end of the file
doesn't work, and seek_to_last_frame() will be called over and over
again, burning CPU for no reason.
Observed with incomplete mp4 files. That this can happen was already
mentioned in commit 090f6cfc, but I guess now I'll do something against
it.
hrseek_lastframe is cleared by reset_playback_state(), so it's only set
if seek_to_last_frame() was called, and no other seek happened since
then. If finding the last frame succeeds, no EOF will happen (unless the
user unpauses, but then it will simply remain at the last frame). If it
fails, then it will return immediately, without retrying.
2014-12-24 15:12:11 +01:00
|
|
|
if (mpctx->hrseek_lastframe) // exit if we already tried this
|
|
|
|
|
return;
|
2014-12-07 02:47:09 +01:00
|
|
|
MP_VERBOSE(mpctx, "seeking to last frame...\n");
|
|
|
|
|
// Approximately seek close to the end of the file.
|
|
|
|
|
// Usually, it will seek some seconds before end.
|
|
|
|
|
double end = get_play_end_pts(mpctx);
|
|
|
|
|
if (end == MP_NOPTS_VALUE)
|
|
|
|
|
end = get_time_length(mpctx);
|
|
|
|
|
mp_seek(mpctx, (struct seek_params){
|
|
|
|
|
.type = MPSEEK_ABSOLUTE,
|
|
|
|
|
.amount = end,
|
2015-03-04 17:21:05 +01:00
|
|
|
.exact = MPSEEK_VERY_EXACT,
|
2016-02-15 21:03:51 +01:00
|
|
|
});
|
2014-12-07 02:47:09 +01:00
|
|
|
// Make it exact: stop seek only if last frame was reached.
|
|
|
|
|
if (mpctx->hrseek_active) {
|
player: replace a magic numer by another magic number
This code attempts to seek to the last frame by seeking close to the
end, and then decoding until the last frame has been reached. To do so
it sets hrseek_lastframe, which for video enables some logic to "catch"
this last frame, and completely ignores hrseek_pts. But audio still may
use hrseek_pts
I don't know if the original author (me) was thinking, if anything, when
setting this variable to 1e99, essentially a random, number. It's very
large, and a timestamp like this will never happen, so it does its job.
But it's random.
Use INFINITY instead. It will skip all audio samples in the audio code
correctly. This change doesn't fix anything, but it does get rid of the
random looking number.
2019-05-26 14:03:06 +02:00
|
|
|
mpctx->hrseek_pts = INFINITY;
|
2014-12-07 02:47:09 +01:00
|
|
|
mpctx->hrseek_lastframe = true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2013-10-29 22:38:29 +01:00
|
|
|
static void handle_keep_open(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
2014-09-24 01:56:53 +02:00
|
|
|
if (opts->keep_open && mpctx->stop_play == AT_END_OF_FILE &&
|
2014-12-12 23:45:16 +01:00
|
|
|
(opts->keep_open == 2 || !playlist_get_next(mpctx->playlist, 1)) &&
|
2015-02-12 22:41:45 +01:00
|
|
|
opts->loop_times == 1)
|
2014-09-24 01:56:53 +02:00
|
|
|
{
|
2013-10-29 22:38:29 +01:00
|
|
|
mpctx->stop_play = KEEP_PLAYING;
|
2016-01-17 18:07:50 +01:00
|
|
|
if (mpctx->vo_chain) {
|
2014-12-07 02:47:09 +01:00
|
|
|
if (!vo_has_frame(mpctx->video_out)) // EOF not reached normally
|
|
|
|
|
seek_to_last_frame(mpctx);
|
2014-09-24 01:37:07 +02:00
|
|
|
mpctx->playback_pts = mpctx->last_vo_pts;
|
2014-12-07 02:47:09 +01:00
|
|
|
}
|
2019-08-30 20:11:39 +02:00
|
|
|
if (opts->keep_open_pause) {
|
|
|
|
|
if (mpctx->ao)
|
|
|
|
|
ao_drain(mpctx->ao);
|
2017-04-14 18:22:45 +02:00
|
|
|
set_pause_state(mpctx, true);
|
2019-08-30 20:11:39 +02:00
|
|
|
}
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2014-04-27 22:28:07 +02:00
|
|
|
static void handle_chapter_change(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
int chapter = get_current_chapter(mpctx);
|
|
|
|
|
if (chapter != mpctx->last_chapter) {
|
|
|
|
|
mpctx->last_chapter = chapter;
|
|
|
|
|
mp_notify(mpctx, MPV_EVENT_CHAPTER_CHANGE, NULL);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2015-09-21 21:22:20 +02:00
|
|
|
// Execute a forceful refresh of the VO window. This clears the window from
|
|
|
|
|
// the previous video. It also creates/destroys the VO on demand.
|
|
|
|
|
// It tries to make the change only in situations where the window is
|
|
|
|
|
// definitely needed or not needed, or if the force parameter is set (the
|
|
|
|
|
// latter also decides whether to clear an existing window, because there's
|
|
|
|
|
// no way to know if this has already been done or not).
|
|
|
|
|
int handle_force_window(struct MPContext *mpctx, bool force)
|
2013-10-29 22:38:29 +01:00
|
|
|
{
|
2015-09-21 21:22:20 +02:00
|
|
|
// True if we're either in idle mode, or loading of the file has finished.
|
|
|
|
|
// It's also set via force in some stages during file loading.
|
2018-05-19 18:25:54 +02:00
|
|
|
bool act = mpctx->stop_play || mpctx->playback_initialized || force;
|
2015-09-21 21:22:20 +02:00
|
|
|
|
2016-02-24 22:19:00 +01:00
|
|
|
// On the other hand, if a video track is selected, but no video is ever
|
|
|
|
|
// decoded on it, then create the window.
|
|
|
|
|
bool stalled_video = mpctx->playback_initialized && mpctx->restart_complete &&
|
|
|
|
|
mpctx->video_status == STATUS_EOF && mpctx->vo_chain &&
|
2016-02-25 11:21:54 +01:00
|
|
|
!mpctx->video_out->config_ok;
|
2016-02-24 22:19:00 +01:00
|
|
|
|
|
|
|
|
// Don't interfere with real video playback
|
|
|
|
|
if (mpctx->vo_chain && !stalled_video)
|
|
|
|
|
return 0;
|
|
|
|
|
|
2015-09-20 17:58:02 +02:00
|
|
|
if (!mpctx->opts->force_vo) {
|
2016-02-25 11:21:54 +01:00
|
|
|
if (act && !mpctx->vo_chain)
|
2015-09-20 23:03:00 +02:00
|
|
|
uninit_video_out(mpctx);
|
2015-09-20 17:58:02 +02:00
|
|
|
return 0;
|
|
|
|
|
}
|
2013-10-29 22:38:29 +01:00
|
|
|
|
2015-09-21 21:22:20 +02:00
|
|
|
if (mpctx->opts->force_vo != 2 && !act)
|
|
|
|
|
return 0;
|
|
|
|
|
|
2015-09-20 17:58:02 +02:00
|
|
|
if (!mpctx->video_out) {
|
|
|
|
|
struct vo_extra ex = {
|
|
|
|
|
.input_ctx = mpctx->input,
|
|
|
|
|
.osd = mpctx->osd,
|
|
|
|
|
.encode_lavc_ctx = mpctx->encode_lavc_ctx,
|
2016-09-16 14:23:54 +02:00
|
|
|
.wakeup_cb = mp_wakeup_core_cb,
|
|
|
|
|
.wakeup_ctx = mpctx,
|
2015-09-20 17:58:02 +02:00
|
|
|
};
|
|
|
|
|
mpctx->video_out = init_best_video_out(mpctx->global, &ex);
|
|
|
|
|
if (!mpctx->video_out)
|
|
|
|
|
goto err;
|
|
|
|
|
mpctx->mouse_cursor_visible = true;
|
|
|
|
|
}
|
|
|
|
|
|
2015-09-21 21:22:20 +02:00
|
|
|
if (!mpctx->video_out->config_ok || force) {
|
2014-10-03 19:57:49 +02:00
|
|
|
struct vo *vo = mpctx->video_out;
|
2013-10-29 22:38:29 +01:00
|
|
|
// Pick whatever works
|
|
|
|
|
int config_format = 0;
|
2015-01-03 17:23:01 +01:00
|
|
|
uint8_t fmts[IMGFMT_END - IMGFMT_START] = {0};
|
|
|
|
|
vo_query_formats(vo, fmts);
|
2013-10-29 22:38:29 +01:00
|
|
|
for (int fmt = IMGFMT_START; fmt < IMGFMT_END; fmt++) {
|
2015-01-03 17:23:01 +01:00
|
|
|
if (fmts[fmt - IMGFMT_START]) {
|
2013-10-29 22:38:29 +01:00
|
|
|
config_format = fmt;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
int w = 960;
|
|
|
|
|
int h = 480;
|
|
|
|
|
struct mp_image_params p = {
|
|
|
|
|
.imgfmt = config_format,
|
|
|
|
|
.w = w, .h = h,
|
2015-12-19 20:04:31 +01:00
|
|
|
.p_w = 1, .p_h = 1,
|
2013-10-29 22:38:29 +01:00
|
|
|
};
|
2015-10-03 18:20:16 +02:00
|
|
|
if (vo_reconfig(vo, &p) < 0)
|
2015-09-20 17:58:02 +02:00
|
|
|
goto err;
|
2016-10-26 20:35:12 +02:00
|
|
|
update_screensaver_state(mpctx);
|
2014-09-09 00:54:34 +02:00
|
|
|
vo_set_paused(vo, true);
|
2014-06-15 20:46:57 +02:00
|
|
|
vo_redraw(vo);
|
2014-02-17 02:52:26 +01:00
|
|
|
mp_notify(mpctx, MPV_EVENT_VIDEO_RECONFIG, NULL);
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
2015-09-20 17:58:02 +02:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
err:
|
|
|
|
|
mpctx->opts->force_vo = 0;
|
|
|
|
|
uninit_video_out(mpctx);
|
|
|
|
|
MP_FATAL(mpctx, "Error opening/initializing the VO window.\n");
|
|
|
|
|
return -1;
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
|
|
|
|
|
2014-08-03 20:25:03 +02:00
|
|
|
// Potentially needed by some Lua scripts, which assume TICK always comes.
|
|
|
|
|
static void handle_dummy_ticks(struct MPContext *mpctx)
|
|
|
|
|
{
|
2019-05-17 21:53:55 +02:00
|
|
|
if ((mpctx->video_status != STATUS_PLAYING &&
|
|
|
|
|
mpctx->video_status != STATUS_DRAINING) ||
|
|
|
|
|
mpctx->paused)
|
|
|
|
|
{
|
2015-06-23 19:21:20 +02:00
|
|
|
if (mp_time_sec() - mpctx->last_idle_tick > 0.050) {
|
2014-08-03 20:25:03 +02:00
|
|
|
mpctx->last_idle_tick = mp_time_sec();
|
|
|
|
|
mp_notify(mpctx, MPV_EVENT_TICK, NULL);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-05-09 22:54:49 +02:00
|
|
|
// Update current playback time.
|
|
|
|
|
static void handle_playback_time(struct MPContext *mpctx)
|
|
|
|
|
{
|
2018-05-03 04:29:11 +02:00
|
|
|
if (mpctx->vo_chain &&
|
|
|
|
|
!mpctx->vo_chain->is_coverart &&
|
|
|
|
|
!mpctx->vo_chain->is_sparse &&
|
2016-05-09 22:54:49 +02:00
|
|
|
mpctx->video_status >= STATUS_PLAYING &&
|
|
|
|
|
mpctx->video_status < STATUS_EOF)
|
|
|
|
|
{
|
|
|
|
|
mpctx->playback_pts = mpctx->video_pts;
|
|
|
|
|
} else if (mpctx->audio_status >= STATUS_PLAYING &&
|
|
|
|
|
mpctx->audio_status < STATUS_EOF)
|
|
|
|
|
{
|
|
|
|
|
mpctx->playback_pts = playing_audio_pts(mpctx);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-01-17 07:07:15 +01:00
|
|
|
static void handle_delayed_audio_seek(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
if (mpctx->seek_slave) {
|
|
|
|
|
if (mpctx->video_pts != MP_NOPTS_VALUE) {
|
|
|
|
|
// We know the video position now, so seek external audio to the
|
|
|
|
|
// correct position.
|
|
|
|
|
double pts = mpctx->video_pts +
|
|
|
|
|
get_track_seek_offset(mpctx, mpctx->seek_slave);
|
|
|
|
|
demux_seek(mpctx->seek_slave->demuxer, pts, 0);
|
|
|
|
|
mpctx->seek_slave = NULL;
|
|
|
|
|
} else if (mpctx->video_status >= STATUS_EOF) {
|
|
|
|
|
// We won't get a video position; don't stall the audio stream.
|
|
|
|
|
demux_block_reading(mpctx->seek_slave->demuxer, false);
|
|
|
|
|
mpctx->seek_slave = NULL;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2015-01-29 12:37:10 +01:00
|
|
|
// We always make sure audio and video buffers are filled before actually
|
|
|
|
|
// starting playback. This code handles starting them at the same time.
|
2016-02-27 20:02:51 +01:00
|
|
|
static void handle_playback_restart(struct MPContext *mpctx)
|
2013-10-29 22:38:29 +01:00
|
|
|
{
|
|
|
|
|
struct MPOpts *opts = mpctx->opts;
|
2015-01-29 12:37:10 +01:00
|
|
|
|
2018-05-03 04:29:11 +02:00
|
|
|
// Do not wait for video stream if it only has sparse frames.
|
2018-05-24 20:00:13 +02:00
|
|
|
if (mpctx->vo_chain && mpctx->vo_chain->is_sparse &&
|
|
|
|
|
mpctx->video_status < STATUS_READY)
|
|
|
|
|
{
|
2018-05-03 04:29:11 +02:00
|
|
|
mpctx->video_status = STATUS_READY;
|
|
|
|
|
}
|
|
|
|
|
|
2015-01-29 12:37:10 +01:00
|
|
|
if (mpctx->audio_status < STATUS_READY ||
|
|
|
|
|
mpctx->video_status < STATUS_READY)
|
|
|
|
|
return;
|
|
|
|
|
|
2019-05-17 21:59:52 +02:00
|
|
|
handle_update_cache(mpctx);
|
2018-01-03 21:48:42 +01:00
|
|
|
|
2015-01-29 12:37:10 +01:00
|
|
|
if (mpctx->video_status == STATUS_READY) {
|
|
|
|
|
mpctx->video_status = STATUS_PLAYING;
|
|
|
|
|
get_relative_time(mpctx);
|
2016-09-16 14:24:15 +02:00
|
|
|
mp_wakeup_core(mpctx);
|
2015-01-29 12:37:10 +01:00
|
|
|
}
|
|
|
|
|
|
2016-05-09 22:54:49 +02:00
|
|
|
if (mpctx->audio_status == STATUS_READY) {
|
|
|
|
|
// If a new seek is queued while the current one finishes, don't
|
|
|
|
|
// actually play the audio, but resume seeking immediately.
|
|
|
|
|
if (mpctx->seek.type && mpctx->video_status == STATUS_PLAYING) {
|
|
|
|
|
handle_playback_time(mpctx);
|
|
|
|
|
execute_queued_seek(mpctx);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2018-01-06 17:19:11 +01:00
|
|
|
// Video needed, but not started yet -> wait.
|
2018-05-03 04:29:11 +02:00
|
|
|
if (mpctx->vo_chain &&
|
|
|
|
|
!mpctx->vo_chain->is_coverart &&
|
|
|
|
|
!mpctx->vo_chain->is_sparse &&
|
2018-01-06 17:19:11 +01:00
|
|
|
mpctx->video_status <= STATUS_READY)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
MP_VERBOSE(mpctx, "starting audio playback\n");
|
|
|
|
|
mpctx->audio_status = STATUS_PLAYING;
|
2016-02-27 20:02:51 +01:00
|
|
|
fill_audio_out_buffers(mpctx); // actually play prepared buffer
|
2018-01-06 17:19:11 +01:00
|
|
|
mp_wakeup_core(mpctx);
|
2016-05-09 22:54:49 +02:00
|
|
|
}
|
2015-01-29 12:37:10 +01:00
|
|
|
|
|
|
|
|
if (!mpctx->restart_complete) {
|
|
|
|
|
mpctx->hrseek_active = false;
|
|
|
|
|
mpctx->restart_complete = true;
|
2017-08-14 14:02:13 +02:00
|
|
|
mpctx->current_seek = (struct seek_params){0};
|
2016-08-18 20:40:23 +02:00
|
|
|
handle_playback_time(mpctx);
|
2015-01-29 12:37:10 +01:00
|
|
|
mp_notify(mpctx, MPV_EVENT_PLAYBACK_RESTART, NULL);
|
2017-04-14 18:56:03 +02:00
|
|
|
update_core_idle_state(mpctx);
|
2015-01-29 12:37:10 +01:00
|
|
|
if (!mpctx->playing_msg_shown) {
|
2015-02-18 21:10:08 +01:00
|
|
|
if (opts->playing_msg && opts->playing_msg[0]) {
|
2015-01-29 12:37:10 +01:00
|
|
|
char *msg =
|
|
|
|
|
mp_property_expand_escaped_string(mpctx, opts->playing_msg);
|
2015-07-13 13:06:09 +02:00
|
|
|
struct mp_log *log = mp_log_new(NULL, mpctx->log, "!term-msg");
|
|
|
|
|
mp_info(log, "%s\n", msg);
|
|
|
|
|
talloc_free(log);
|
2015-01-29 12:37:10 +01:00
|
|
|
talloc_free(msg);
|
|
|
|
|
}
|
2015-02-18 21:10:08 +01:00
|
|
|
if (opts->osd_playing_msg && opts->osd_playing_msg[0]) {
|
2015-01-29 12:37:10 +01:00
|
|
|
char *msg =
|
|
|
|
|
mp_property_expand_escaped_string(mpctx, opts->osd_playing_msg);
|
|
|
|
|
set_osd_msg(mpctx, 1, opts->osd_duration, "%s", msg);
|
|
|
|
|
talloc_free(msg);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
mpctx->playing_msg_shown = true;
|
2016-09-16 14:24:15 +02:00
|
|
|
mp_wakeup_core(mpctx);
|
player: modify/simplify AB-loop behavior
This changes the behavior of the --ab-loop-a/b options. In addition, it
makes it work with backward playback mode.
The most obvious change is that the both the A and B point need to be
set now before any looping happens. Unlike before, unset points don't
implicitly use the start or end of the file. I think the old behavior
was a feature that was explicitly added/wanted. Well, it's gone now.
This is because of 2 reasons:
1. I never liked this feature, and it always got in my way (as user).
2. It's inherently annoying with backward playback mode.
In backward playback mode, the user wants to set A/B in the wrong order.
The ab-loop command will first set A, then B, so if you use this command
during backward playback, A will be set to a higher timestamps than B.
If you switch back to forward playback mode, the loop would stop
working. I want the loop to just continue to work, and the chosen
solution conflicts with the removed feature.
The order issue above _could_ be fixed by also switching the AB-loop
user option values around on direction switch. But there are no other
instances of option changes magically affecting other options, and doing
this would probably lead to unexpected misery (dying from corner cases
and such).
Another solution is sorting the A/B points by timestamps after copying
them from the user options. Then A/B options set in backward mode will
work in forward mode. This is the chosen solution. If you sort the
points, you don't know anymore whether the unset point is supposed to
signify the end or the start of the file.
The AB-loop code is slightly better abstracted now, so it should be easy
to restore the removed feature. It would still require coming up with a
solution for backwards playback, though.
A minor change is that if one point is set and the other is unset, I'm
rendering both the chapter markers and the marker for the set point.
Why? I don't know. My test file had chapters, and I guess I decided this
looked better.
This commit also fixes some subtle and obvious issues that I already
forgot about when I wrote this commit message. It cleans up some minor
code duplication and nonsense too.
Regarding backward playback, the code uses an unsanitary mix of internal
("transformed") and user timestamps. So the play_dir variable appears
more than usual.
To mention one unfixed issue: if you set an AB-loop that is completely
past the end of the file, it will get stuck in an infinite seeking loop
once playback reaches the end of the file. Fixing this reliably seemed
annoying, so the fix is "just don't do this". It's not a hard freeze
anyway.
2019-05-27 01:24:22 +02:00
|
|
|
update_ab_loop_clip(mpctx);
|
2019-03-24 16:25:09 +01:00
|
|
|
MP_VERBOSE(mpctx, "playback restart complete @ %f\n", mpctx->playback_pts);
|
2015-01-29 12:37:10 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-15 21:03:51 +01:00
|
|
|
static void handle_eof(struct MPContext *mpctx)
|
2015-01-29 12:37:10 +01:00
|
|
|
{
|
|
|
|
|
/* Don't quit while paused and we're displaying the last video frame. On the
|
|
|
|
|
* other hand, if we don't have a video frame, then the user probably seeked
|
|
|
|
|
* outside of the video, and we do want to quit. */
|
|
|
|
|
bool prevent_eof =
|
|
|
|
|
mpctx->paused && mpctx->video_out && vo_has_frame(mpctx->video_out);
|
|
|
|
|
/* It's possible for the user to simultaneously switch both audio
|
|
|
|
|
* and video streams to "disabled" at runtime. Handle this by waiting
|
|
|
|
|
* rather than immediately stopping playback due to EOF.
|
|
|
|
|
*/
|
2016-01-21 22:24:20 +01:00
|
|
|
if ((mpctx->ao_chain || mpctx->vo_chain) && !prevent_eof &&
|
2015-01-29 12:37:10 +01:00
|
|
|
mpctx->audio_status == STATUS_EOF &&
|
2016-02-15 21:03:51 +01:00
|
|
|
mpctx->video_status == STATUS_EOF &&
|
|
|
|
|
!mpctx->stop_play)
|
2015-01-29 12:37:10 +01:00
|
|
|
{
|
2016-02-15 21:03:51 +01:00
|
|
|
mpctx->stop_play = AT_END_OF_FILE;
|
2015-01-29 12:37:10 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void run_playloop(struct MPContext *mpctx)
|
|
|
|
|
{
|
2013-10-29 22:38:29 +01:00
|
|
|
if (encode_lavc_didfail(mpctx->encode_lavc_ctx)) {
|
|
|
|
|
mpctx->stop_play = PT_QUIT;
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-16 22:40:21 +02:00
|
|
|
update_demuxer_properties(mpctx);
|
2013-10-29 22:38:29 +01:00
|
|
|
|
2014-07-30 23:24:08 +02:00
|
|
|
handle_cursor_autohide(mpctx);
|
2014-11-02 20:26:51 +01:00
|
|
|
handle_vo_events(mpctx);
|
2015-02-14 15:13:58 +01:00
|
|
|
handle_command_updates(mpctx);
|
2013-10-29 22:38:29 +01:00
|
|
|
|
2018-01-26 04:36:47 +01:00
|
|
|
if (mpctx->lavfi && mp_filter_has_failed(mpctx->lavfi))
|
|
|
|
|
mpctx->stop_play = AT_END_OF_FILE;
|
2016-02-05 23:19:56 +01:00
|
|
|
|
2016-05-09 22:54:49 +02:00
|
|
|
fill_audio_out_buffers(mpctx);
|
|
|
|
|
write_video(mpctx);
|
|
|
|
|
|
2018-01-17 07:07:15 +01:00
|
|
|
handle_delayed_audio_seek(mpctx);
|
|
|
|
|
|
2016-02-27 20:02:51 +01:00
|
|
|
handle_playback_restart(mpctx);
|
2013-10-29 22:38:29 +01:00
|
|
|
|
2016-05-09 22:54:49 +02:00
|
|
|
handle_playback_time(mpctx);
|
|
|
|
|
|
2014-08-03 20:25:03 +02:00
|
|
|
handle_dummy_ticks(mpctx);
|
|
|
|
|
|
2014-07-28 20:40:43 +02:00
|
|
|
update_osd_msg(mpctx);
|
2016-10-31 13:55:32 +01:00
|
|
|
if (mpctx->video_status == STATUS_EOF)
|
2015-12-29 01:35:52 +01:00
|
|
|
update_subtitles(mpctx, mpctx->playback_pts);
|
2013-10-29 22:38:29 +01:00
|
|
|
|
2016-02-15 21:03:51 +01:00
|
|
|
handle_eof(mpctx);
|
2013-10-29 22:38:29 +01:00
|
|
|
|
2014-09-24 01:31:45 +02:00
|
|
|
handle_loop_file(mpctx);
|
|
|
|
|
|
2014-07-30 00:22:25 +02:00
|
|
|
handle_keep_open(mpctx);
|
|
|
|
|
|
2014-08-03 20:25:03 +02:00
|
|
|
handle_sstep(mpctx);
|
2013-10-29 22:38:29 +01:00
|
|
|
|
2017-04-14 18:56:03 +02:00
|
|
|
update_core_idle_state(mpctx);
|
|
|
|
|
|
2014-07-18 15:04:46 +02:00
|
|
|
if (mpctx->stop_play)
|
2014-08-03 19:14:30 +02:00
|
|
|
return;
|
2014-07-18 15:04:46 +02:00
|
|
|
|
2014-08-03 19:09:22 +02:00
|
|
|
handle_osd_redraw(mpctx);
|
2014-07-18 15:04:46 +02: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 11:53:44 +01:00
|
|
|
if (mp_filter_run(mpctx->filter_root))
|
|
|
|
|
mp_wakeup_core(mpctx);
|
2016-09-16 14:25:50 +02:00
|
|
|
mp_wait_events(mpctx);
|
2013-10-29 22:38:29 +01:00
|
|
|
|
2019-05-17 21:59:52 +02:00
|
|
|
handle_update_cache(mpctx);
|
2013-10-29 22:38:29 +01:00
|
|
|
|
2014-09-06 16:57:46 +02:00
|
|
|
mp_process_input(mpctx);
|
2013-10-29 22:38:29 +01:00
|
|
|
|
2014-04-27 22:28:07 +02:00
|
|
|
handle_chapter_change(mpctx);
|
|
|
|
|
|
2013-10-29 22:38:29 +01:00
|
|
|
handle_force_window(mpctx, false);
|
|
|
|
|
|
|
|
|
|
execute_queued_seek(mpctx);
|
|
|
|
|
}
|
|
|
|
|
|
2014-10-06 21:20:38 +02:00
|
|
|
void mp_idle(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
handle_dummy_ticks(mpctx);
|
2016-09-16 14:25:50 +02:00
|
|
|
mp_wait_events(mpctx);
|
2014-10-06 21:20:38 +02:00
|
|
|
mp_process_input(mpctx);
|
2015-05-02 17:53:25 +02:00
|
|
|
handle_command_updates(mpctx);
|
2019-05-17 21:59:52 +02:00
|
|
|
handle_update_cache(mpctx);
|
2014-10-10 18:51:44 +02:00
|
|
|
handle_cursor_autohide(mpctx);
|
2014-11-02 20:26:51 +01:00
|
|
|
handle_vo_events(mpctx);
|
2014-10-06 21:20:38 +02:00
|
|
|
update_osd_msg(mpctx);
|
|
|
|
|
handle_osd_redraw(mpctx);
|
|
|
|
|
}
|
|
|
|
|
|
2013-10-29 22:38:29 +01:00
|
|
|
// Waiting for the slave master to send us a new file to play.
|
|
|
|
|
void idle_loop(struct MPContext *mpctx)
|
|
|
|
|
{
|
|
|
|
|
// ================= idle loop (STOP state) =========================
|
|
|
|
|
bool need_reinit = true;
|
|
|
|
|
while (mpctx->opts->player_idle_mode && !mpctx->playlist->current
|
|
|
|
|
&& mpctx->stop_play != PT_QUIT)
|
|
|
|
|
{
|
2014-02-26 20:45:24 +01:00
|
|
|
if (need_reinit) {
|
2014-10-03 19:57:49 +02:00
|
|
|
uninit_audio_out(mpctx);
|
2013-10-29 22:38:29 +01:00
|
|
|
handle_force_window(mpctx, true);
|
2016-09-16 14:24:15 +02:00
|
|
|
mp_wakeup_core(mpctx);
|
2015-08-20 15:25:32 +02:00
|
|
|
mp_notify(mpctx, MPV_EVENT_IDLE, NULL);
|
2014-09-13 01:13:36 +02:00
|
|
|
need_reinit = false;
|
2014-02-26 20:45:24 +01:00
|
|
|
}
|
2014-10-06 21:20:38 +02:00
|
|
|
mp_idle(mpctx);
|
2013-10-29 22:38:29 +01:00
|
|
|
}
|
|
|
|
|
}
|