2009-05-08 21:51:13 +00:00
|
|
|
/*
|
2015-04-13 07:36:54 +00:00
|
|
|
* This file is part of mpv.
|
2009-05-08 21:51:13 +00:00
|
|
|
*
|
demux: change license to LGPL
As usual, the history of these files is a bit murky. It starts with the
initial commit. (At which some development had already been done,
according to the AUTHORS and ChangeLog files at the time, we should be
but covered with relicensing agreements, though.) then it goes on with
complete lack of modularization, which was cleaned up later (cd68e161).
As usual, we don't consider the copyright of the stuff that has been
moved out cleanly.
There were also contributions to generic code by people who could not be
reached or who did not agree to the relicensing, but this was all
removed.
The only patches that we could not relicense and which were still in the
current code in some form are from Dénes Balatoni: 422b0d2a, 32937181.
We could not reach him, so commits f34e1a0d and 18905298 remove his
additions. It still leaves the demux_control() declaration itself, but
we don't consider it copyrightable. It's basically an idiom that existed
in MPlayer before that change, applied to the demuxer struct. (We even
went as far as making sure to remove all DEMUXER_CTRLs the original
author added.)
Commit be54f481 might be a bit of a corner case, but this was rewritten,
and we consider the old copyright removed long ago.
2017-06-20 12:09:46 +00:00
|
|
|
* mpv is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
2009-05-08 21:51:13 +00:00
|
|
|
*
|
2015-04-13 07:36:54 +00:00
|
|
|
* mpv is distributed in the hope that it will be useful,
|
2009-05-08 21:51:13 +00:00
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
demux: change license to LGPL
As usual, the history of these files is a bit murky. It starts with the
initial commit. (At which some development had already been done,
according to the AUTHORS and ChangeLog files at the time, we should be
but covered with relicensing agreements, though.) then it goes on with
complete lack of modularization, which was cleaned up later (cd68e161).
As usual, we don't consider the copyright of the stuff that has been
moved out cleanly.
There were also contributions to generic code by people who could not be
reached or who did not agree to the relicensing, but this was all
removed.
The only patches that we could not relicense and which were still in the
current code in some form are from Dénes Balatoni: 422b0d2a, 32937181.
We could not reach him, so commits f34e1a0d and 18905298 remove his
additions. It still leaves the demux_control() declaration itself, but
we don't consider it copyrightable. It's basically an idiom that existed
in MPlayer before that change, applied to the demuxer struct. (We even
went as far as making sure to remove all DEMUXER_CTRLs the original
author added.)
Commit be54f481 might be a bit of a corner case, but this was rewritten,
and we consider the old copyright removed long ago.
2017-06-20 12:09:46 +00:00
|
|
|
* GNU Lesser General Public License for more details.
|
2009-05-08 21:51:13 +00:00
|
|
|
*
|
demux: change license to LGPL
As usual, the history of these files is a bit murky. It starts with the
initial commit. (At which some development had already been done,
according to the AUTHORS and ChangeLog files at the time, we should be
but covered with relicensing agreements, though.) then it goes on with
complete lack of modularization, which was cleaned up later (cd68e161).
As usual, we don't consider the copyright of the stuff that has been
moved out cleanly.
There were also contributions to generic code by people who could not be
reached or who did not agree to the relicensing, but this was all
removed.
The only patches that we could not relicense and which were still in the
current code in some form are from Dénes Balatoni: 422b0d2a, 32937181.
We could not reach him, so commits f34e1a0d and 18905298 remove his
additions. It still leaves the demux_control() declaration itself, but
we don't consider it copyrightable. It's basically an idiom that existed
in MPlayer before that change, applied to the demuxer struct. (We even
went as far as making sure to remove all DEMUXER_CTRLs the original
author added.)
Commit be54f481 might be a bit of a corner case, but this was rewritten,
and we consider the old copyright removed long ago.
2017-06-20 12:09:46 +00:00
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
|
2009-05-08 21:51:13 +00:00
|
|
|
*/
|
2001-02-24 20:28:24 +00:00
|
|
|
|
2001-04-23 03:42:17 +00:00
|
|
|
#include <stdio.h>
|
|
|
|
#include <stdlib.h>
|
2001-11-27 00:42:39 +00:00
|
|
|
#include <string.h>
|
2011-08-20 17:25:43 +00:00
|
|
|
#include <assert.h>
|
2001-08-01 09:14:02 +00:00
|
|
|
#include <unistd.h>
|
2016-09-06 18:09:56 +00:00
|
|
|
#include <limits.h>
|
2014-07-16 20:40:21 +00:00
|
|
|
#include <pthread.h>
|
2001-08-01 09:14:02 +00:00
|
|
|
|
2014-03-28 11:38:42 +00:00
|
|
|
#include <math.h>
|
|
|
|
|
2001-08-01 09:14:02 +00:00
|
|
|
#include <sys/types.h>
|
|
|
|
#include <sys/stat.h>
|
2001-02-24 20:28:24 +00:00
|
|
|
|
2001-07-21 22:37:55 +00:00
|
|
|
#include "config.h"
|
2016-09-06 18:09:56 +00:00
|
|
|
#include "options/m_config.h"
|
|
|
|
#include "options/m_option.h"
|
2016-01-11 18:03:40 +00:00
|
|
|
#include "mpv_talloc.h"
|
2013-12-17 01:39:45 +00:00
|
|
|
#include "common/msg.h"
|
2013-12-21 19:24:20 +00:00
|
|
|
#include "common/global.h"
|
2014-10-19 21:32:34 +00:00
|
|
|
#include "osdep/threads.h"
|
2001-07-21 22:37:55 +00:00
|
|
|
|
2007-03-15 18:36:36 +00:00
|
|
|
#include "stream/stream.h"
|
2012-11-09 00:06:43 +00:00
|
|
|
#include "demux.h"
|
Rewrite ordered chapters and timeline stuff
This uses a different method to piece segments together. The old
approach basically changes to a new file (with a new start offset) any
time a segment ends. This meant waiting for audio/video end on segment
end, and then changing to the new segment all at once. It had a very
weird impact on the playback core, and some things (like truly gapless
segment transitions, or frame backstepping) just didn't work.
The new approach adds the demux_timeline pseudo-demuxer, which presents
an uniform packet stream from the many segments. This is pretty similar
to how ordered chapters are implemented everywhere else. It also reminds
of the FFmpeg concat pseudo-demuxer.
The "pure" version of this approach doesn't work though. Segments can
actually have different codec configurations (different extradata), and
subtitles are most likely broken too. (Subtitles have multiple corner
cases which break the pure stream-concatenation approach completely.)
To counter this, we do two things:
- Reinit the decoder with each segment. We go as far as allowing
concatenating files with completely different codecs for the sake
of EDL (which also uses the timeline infrastructure). A "lighter"
approach would try to make use of decoder mechanism to update e.g.
the extradata, but that seems fragile.
- Clip decoded data to segment boundaries. This is equivalent to
normal playback core mechanisms like hr-seek, but now the playback
core doesn't need to care about these things.
These two mechanisms are equivalent to what happened in the old
implementation, except they don't happen in the playback core anymore.
In other words, the playback core is completely relieved from timeline
implementation details. (Which honestly is exactly what I'm trying to
do here. I don't think ordered chapter behavior deserves improvement,
even if it's bad - but I want to get it out from the playback core.)
There is code duplication between audio and video decoder common code.
This is awful and could be shareable - but this will happen later.
Note that the audio path has some code to clip audio frames for the
purpose of codec preroll/gapless handling, but it's not shared as
sharing it would cause more pain than it would help.
2016-02-15 20:04:07 +00:00
|
|
|
#include "timeline.h"
|
2001-07-21 22:37:55 +00:00
|
|
|
#include "stheader.h"
|
2015-05-19 19:36:52 +00:00
|
|
|
#include "cue.h"
|
2002-03-15 15:53:11 +00:00
|
|
|
|
2005-08-05 19:57:47 +00:00
|
|
|
// Demuxer list
|
EDL: add support for new EDL file format
The timeline code previously added to support Matroska ordered
chapters allows constructing a playback timeline from segments picked
from multiple source files. Add support for a new EDL format to make
this machinery available for use with file formats other than Matroska
and in a manner easier to use than creating files with ordered
chapters.
Unlike the old -edl option which specifies an additional file with
edits to apply to the video file given as the main argument, the new
EDL format is used by giving only the EDL file as the file to play;
that file then contains the filename(s) to use as source files where
actual video segments come from. Filename paths in the EDL file are
ignored. Currently the source files are only searched for in the
directory of the EDL file; support for a search path option will
likely be added in the future.
Format of the EDL files
The first line in the file must be "mplayer EDL file, version 2".
The rest of the lines belong to one of these classes:
1) lines specifying source files
2) empty lines
3) lines specifying timeline segments.
Lines beginning with '<' specify source files. These lines first
contain an identifier used to refer to the source file later, then the
filename separated by whitespace. The identifier must start with a
letter. Filenames that start or end with whitespace or contain
newlines are not supported.
On other lines '#' characters delimit comments. Lines that contain
only whitespace after comments have been removed are ignored.
Timeline segments must appear in the file in chronological order. Each
segment has the following information associated with it:
- duration
- output start time
- output end time (= output start time + duration)
- source id (specifies the file the content of the segment comes from)
- source start time (timestamp in the source file)
- source end time (= source start time + duration)
The output timestamps must form a continuous timeline from 0 to the
end of the last segment, such that each new segment starts from the
time the previous one ends at. Source files and times may change
arbitrarily between segments.
The general format for lines specifying timeline segments is
[output time info] source_id [source time info]
source_id must be an identifier defined on a '<' line. Both the time
info parts consists of zero or more of the following elements:
1) timestamp
2) -timestamp
3) +duration
4) *
5) -*
, where "timestamp" and "duration" are decimal numbers (computations
are done with nanosecond precision). Whitespace around "+" and "-" is
optional. 1) and 2) specify start and end time of the segment on
output or source side. 3) specifies duration; the semantics are the
same whether this appears on output or source side. 4) and 5) are
ignored on the output side (they're always implicitly assumed). On the
source side 4) specifies that the segment starts where the previous
segment _using this source_ ended; if there was no previous segment
time 0 is used. 5) specifies that the segment ends where the next
segment using this source starts.
Redundant information may be omitted. It will be filled in using the
following rules:
- output start for first segment is 0
- two of [output start, output end, duration] imply third
- two of [source start, source end, duration] imply third
- output start = output end of previous segment
- output end = output start of next segment
- if "*", source start = source end of earlier segment
- if "-*", source end = source start of a later segment
As a special rule, a last zero-duration segment without a source
specification may appear. This will produce no corresponding segment
in the resulting timeline, but can be used as syntax to specify the
end time of the timeline (with effect equal to adding -time on the
previous line).
Examples:
----- begin -----
mplayer EDL file, version 2
< id1 filename
0 id1 123
100 id1 456
200 id1 789
300
----- end -----
All segments come from the source file "filename". First segment
(output time 0-100) comes from time 123-223, second 456-556, third
789-889.
----- begin -----
mplayer EDL file, version 2
< f filename
f 60-120
f 600-660
f 30- 90
----- end -----
Play first seconds 60-120 from the file, then 600-660, then 30-90.
----- begin -----
mplayer EDL file, version 2
< id1 filename1
< id2 filename2
+10 id1 *
+10 id2 *
+10 id1 *
+10 id2 *
+10 id1 *
+10 id2 *
----- end -----
This plays time 0-10 from filename1, then 0-10 from filename1, then
10-20 from filename1, then 10-20 from filename2, then 20-30 from
filename1, then 20-30 from filename2.
----- begin -----
mplayer EDL file, version 2
< t1 filename1
< t2 filename2
t1 * +2 # segment 1
+2 t2 100 # segment 2
t1 * # segment 3
t2 *-* # segment 4
t1 3 -* # segment 5
+0.111111 t2 102.5 # segment 6
7.37 t1 5 +1 # segment 7
----- end -----
This rather pathological example illustrates the rules for filling in
implied data. All the values can be determined by recursively applying
the rules given above, and the full end result is this:
+2 0-2 t1 0-2 # segment 1
+2 2-4 t2 100-102 # segment 2
+0.758889 4-4.758889 t1 2-2.758889 # segment 3
+0.5 4.4758889-5.258889 t2 102-102.5 # segment 4
+2 5.258889-7.258889 t1 3-5 # segment 5
+0.111111 7.258889-7.37 t2 102.5-102.611111 # segment 6
+1 7.37-8.37 t1 5-6 # segment 7
2011-02-14 11:05:35 +00:00
|
|
|
extern const struct demuxer_desc demuxer_desc_edl;
|
2012-01-01 16:45:24 +00:00
|
|
|
extern const struct demuxer_desc demuxer_desc_cue;
|
2008-01-13 16:00:39 +00:00
|
|
|
extern const demuxer_desc_t demuxer_desc_rawaudio;
|
|
|
|
extern const demuxer_desc_t demuxer_desc_rawvideo;
|
|
|
|
extern const demuxer_desc_t demuxer_desc_tv;
|
|
|
|
extern const demuxer_desc_t demuxer_desc_mf;
|
|
|
|
extern const demuxer_desc_t demuxer_desc_matroska;
|
|
|
|
extern const demuxer_desc_t demuxer_desc_lavf;
|
2013-08-25 18:40:21 +00:00
|
|
|
extern const demuxer_desc_t demuxer_desc_playlist;
|
2014-07-14 23:49:02 +00:00
|
|
|
extern const demuxer_desc_t demuxer_desc_disc;
|
2015-03-24 20:29:09 +00:00
|
|
|
extern const demuxer_desc_t demuxer_desc_rar;
|
stream: libarchive wrapper for reading compressed archives
This works similar to the existing .rar support, but uses libarchive.
libarchive supports a number of formats, including zip and (most of)
rar.
Unfortunately, seeking does not work too well. Most libarchive readers
do not support seeking, so it's emulated by skipping data until the
target position. On backwards seek, the file is reopened. This works
fine on a local machine (and if the file is not too large), but will
perform not so well over network connection.
This is disabled by default for now. One reason is that we try
libarchive on every file we open, before trying libavformat, and I'm not
sure if I trust libarchive that much yet. Another reason is that this
breaks multivolume rar support. While libarchive supports seeking in
rar, and (probably) supports multivolume archive, our support of
libarchive (probably) does not. I don't care about multivolume rar, but
vocal users do.
2015-08-16 22:55:26 +00:00
|
|
|
extern const demuxer_desc_t demuxer_desc_libarchive;
|
2016-03-04 22:51:55 +00:00
|
|
|
extern const demuxer_desc_t demuxer_desc_null;
|
Rewrite ordered chapters and timeline stuff
This uses a different method to piece segments together. The old
approach basically changes to a new file (with a new start offset) any
time a segment ends. This meant waiting for audio/video end on segment
end, and then changing to the new segment all at once. It had a very
weird impact on the playback core, and some things (like truly gapless
segment transitions, or frame backstepping) just didn't work.
The new approach adds the demux_timeline pseudo-demuxer, which presents
an uniform packet stream from the many segments. This is pretty similar
to how ordered chapters are implemented everywhere else. It also reminds
of the FFmpeg concat pseudo-demuxer.
The "pure" version of this approach doesn't work though. Segments can
actually have different codec configurations (different extradata), and
subtitles are most likely broken too. (Subtitles have multiple corner
cases which break the pure stream-concatenation approach completely.)
To counter this, we do two things:
- Reinit the decoder with each segment. We go as far as allowing
concatenating files with completely different codecs for the sake
of EDL (which also uses the timeline infrastructure). A "lighter"
approach would try to make use of decoder mechanism to update e.g.
the extradata, but that seems fragile.
- Clip decoded data to segment boundaries. This is equivalent to
normal playback core mechanisms like hr-seek, but now the playback
core doesn't need to care about these things.
These two mechanisms are equivalent to what happened in the old
implementation, except they don't happen in the playback core anymore.
In other words, the playback core is completely relieved from timeline
implementation details. (Which honestly is exactly what I'm trying to
do here. I don't think ordered chapter behavior deserves improvement,
even if it's bad - but I want to get it out from the playback core.)
There is code duplication between audio and video decoder common code.
This is awful and could be shareable - but this will happen later.
Note that the audio path has some code to clip audio frames for the
purpose of codec preroll/gapless handling, but it's not shared as
sharing it would cause more pain than it would help.
2016-02-15 20:04:07 +00:00
|
|
|
extern const demuxer_desc_t demuxer_desc_timeline;
|
2005-08-05 19:57:47 +00:00
|
|
|
|
2008-01-28 16:03:22 +00:00
|
|
|
/* Please do not add any new demuxers here. If you want to implement a new
|
2008-01-28 22:09:21 +00:00
|
|
|
* demuxer, add it to libavformat, except for wrappers around external
|
|
|
|
* libraries and demuxers requiring binary support. */
|
2008-01-28 16:03:22 +00:00
|
|
|
|
2008-04-12 15:51:08 +00:00
|
|
|
const demuxer_desc_t *const demuxer_list[] = {
|
2014-07-14 23:49:02 +00:00
|
|
|
&demuxer_desc_disc,
|
EDL: add support for new EDL file format
The timeline code previously added to support Matroska ordered
chapters allows constructing a playback timeline from segments picked
from multiple source files. Add support for a new EDL format to make
this machinery available for use with file formats other than Matroska
and in a manner easier to use than creating files with ordered
chapters.
Unlike the old -edl option which specifies an additional file with
edits to apply to the video file given as the main argument, the new
EDL format is used by giving only the EDL file as the file to play;
that file then contains the filename(s) to use as source files where
actual video segments come from. Filename paths in the EDL file are
ignored. Currently the source files are only searched for in the
directory of the EDL file; support for a search path option will
likely be added in the future.
Format of the EDL files
The first line in the file must be "mplayer EDL file, version 2".
The rest of the lines belong to one of these classes:
1) lines specifying source files
2) empty lines
3) lines specifying timeline segments.
Lines beginning with '<' specify source files. These lines first
contain an identifier used to refer to the source file later, then the
filename separated by whitespace. The identifier must start with a
letter. Filenames that start or end with whitespace or contain
newlines are not supported.
On other lines '#' characters delimit comments. Lines that contain
only whitespace after comments have been removed are ignored.
Timeline segments must appear in the file in chronological order. Each
segment has the following information associated with it:
- duration
- output start time
- output end time (= output start time + duration)
- source id (specifies the file the content of the segment comes from)
- source start time (timestamp in the source file)
- source end time (= source start time + duration)
The output timestamps must form a continuous timeline from 0 to the
end of the last segment, such that each new segment starts from the
time the previous one ends at. Source files and times may change
arbitrarily between segments.
The general format for lines specifying timeline segments is
[output time info] source_id [source time info]
source_id must be an identifier defined on a '<' line. Both the time
info parts consists of zero or more of the following elements:
1) timestamp
2) -timestamp
3) +duration
4) *
5) -*
, where "timestamp" and "duration" are decimal numbers (computations
are done with nanosecond precision). Whitespace around "+" and "-" is
optional. 1) and 2) specify start and end time of the segment on
output or source side. 3) specifies duration; the semantics are the
same whether this appears on output or source side. 4) and 5) are
ignored on the output side (they're always implicitly assumed). On the
source side 4) specifies that the segment starts where the previous
segment _using this source_ ended; if there was no previous segment
time 0 is used. 5) specifies that the segment ends where the next
segment using this source starts.
Redundant information may be omitted. It will be filled in using the
following rules:
- output start for first segment is 0
- two of [output start, output end, duration] imply third
- two of [source start, source end, duration] imply third
- output start = output end of previous segment
- output end = output start of next segment
- if "*", source start = source end of earlier segment
- if "-*", source end = source start of a later segment
As a special rule, a last zero-duration segment without a source
specification may appear. This will produce no corresponding segment
in the resulting timeline, but can be used as syntax to specify the
end time of the timeline (with effect equal to adding -time on the
previous line).
Examples:
----- begin -----
mplayer EDL file, version 2
< id1 filename
0 id1 123
100 id1 456
200 id1 789
300
----- end -----
All segments come from the source file "filename". First segment
(output time 0-100) comes from time 123-223, second 456-556, third
789-889.
----- begin -----
mplayer EDL file, version 2
< f filename
f 60-120
f 600-660
f 30- 90
----- end -----
Play first seconds 60-120 from the file, then 600-660, then 30-90.
----- begin -----
mplayer EDL file, version 2
< id1 filename1
< id2 filename2
+10 id1 *
+10 id2 *
+10 id1 *
+10 id2 *
+10 id1 *
+10 id2 *
----- end -----
This plays time 0-10 from filename1, then 0-10 from filename1, then
10-20 from filename1, then 10-20 from filename2, then 20-30 from
filename1, then 20-30 from filename2.
----- begin -----
mplayer EDL file, version 2
< t1 filename1
< t2 filename2
t1 * +2 # segment 1
+2 t2 100 # segment 2
t1 * # segment 3
t2 *-* # segment 4
t1 3 -* # segment 5
+0.111111 t2 102.5 # segment 6
7.37 t1 5 +1 # segment 7
----- end -----
This rather pathological example illustrates the rules for filling in
implied data. All the values can be determined by recursively applying
the rules given above, and the full end result is this:
+2 0-2 t1 0-2 # segment 1
+2 2-4 t2 100-102 # segment 2
+0.758889 4-4.758889 t1 2-2.758889 # segment 3
+0.5 4.4758889-5.258889 t2 102-102.5 # segment 4
+2 5.258889-7.258889 t1 3-5 # segment 5
+0.111111 7.258889-7.37 t2 102.5-102.611111 # segment 6
+1 7.37-8.37 t1 5-6 # segment 7
2011-02-14 11:05:35 +00:00
|
|
|
&demuxer_desc_edl,
|
2012-01-01 16:45:24 +00:00
|
|
|
&demuxer_desc_cue,
|
2008-04-12 15:51:08 +00:00
|
|
|
&demuxer_desc_rawaudio,
|
|
|
|
&demuxer_desc_rawvideo,
|
2013-07-16 11:28:28 +00:00
|
|
|
#if HAVE_TV
|
2008-04-12 15:51:08 +00:00
|
|
|
&demuxer_desc_tv,
|
2013-07-07 23:40:13 +00:00
|
|
|
#endif
|
2008-04-12 15:51:08 +00:00
|
|
|
&demuxer_desc_matroska,
|
stream: libarchive wrapper for reading compressed archives
This works similar to the existing .rar support, but uses libarchive.
libarchive supports a number of formats, including zip and (most of)
rar.
Unfortunately, seeking does not work too well. Most libarchive readers
do not support seeking, so it's emulated by skipping data until the
target position. On backwards seek, the file is reopened. This works
fine on a local machine (and if the file is not too large), but will
perform not so well over network connection.
This is disabled by default for now. One reason is that we try
libarchive on every file we open, before trying libavformat, and I'm not
sure if I trust libarchive that much yet. Another reason is that this
breaks multivolume rar support. While libarchive supports seeking in
rar, and (probably) supports multivolume archive, our support of
libarchive (probably) does not. I don't care about multivolume rar, but
vocal users do.
2015-08-16 22:55:26 +00:00
|
|
|
#if HAVE_LIBARCHIVE
|
|
|
|
&demuxer_desc_libarchive,
|
|
|
|
#endif
|
2015-03-24 20:29:09 +00:00
|
|
|
&demuxer_desc_rar,
|
2008-04-12 15:51:08 +00:00
|
|
|
&demuxer_desc_lavf,
|
2013-08-12 18:40:39 +00:00
|
|
|
&demuxer_desc_mf,
|
2013-08-25 18:40:21 +00:00
|
|
|
&demuxer_desc_playlist,
|
2016-03-04 22:51:55 +00:00
|
|
|
&demuxer_desc_null,
|
2008-04-12 15:51:08 +00:00
|
|
|
NULL
|
2005-08-05 19:57:47 +00:00
|
|
|
};
|
|
|
|
|
2016-09-06 18:09:56 +00:00
|
|
|
struct demux_opts {
|
2018-01-24 00:32:56 +00:00
|
|
|
int64_t max_bytes;
|
|
|
|
int64_t max_bytes_bw;
|
2016-09-06 18:09:56 +00:00
|
|
|
double min_secs;
|
|
|
|
int force_seekable;
|
|
|
|
double min_secs_cache;
|
2016-12-04 22:15:31 +00:00
|
|
|
int access_references;
|
2017-10-21 17:26:33 +00:00
|
|
|
int seekable_cache;
|
2017-11-03 12:55:32 +00:00
|
|
|
int create_ccs;
|
2016-09-06 18:09:56 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
#define OPT_BASE_STRUCT struct demux_opts
|
|
|
|
|
|
|
|
const struct m_sub_options demux_conf = {
|
|
|
|
.opts = (const struct m_option[]){
|
|
|
|
OPT_DOUBLE("demuxer-readahead-secs", min_secs, M_OPT_MIN, .min = 0),
|
2018-01-24 00:32:56 +00:00
|
|
|
OPT_BYTE_SIZE("demuxer-max-bytes", max_bytes, 0, 0, INT_MAX),
|
|
|
|
OPT_BYTE_SIZE("demuxer-max-back-bytes", max_bytes_bw, 0, 0, INT_MAX),
|
2016-09-06 18:09:56 +00:00
|
|
|
OPT_FLAG("force-seekable", force_seekable, 0),
|
|
|
|
OPT_DOUBLE("cache-secs", min_secs_cache, M_OPT_MIN, .min = 0),
|
2016-12-04 22:15:31 +00:00
|
|
|
OPT_FLAG("access-references", access_references, 0),
|
2017-11-10 15:30:43 +00:00
|
|
|
OPT_CHOICE("demuxer-seekable-cache", seekable_cache, 0,
|
|
|
|
({"auto", -1}, {"no", 0}, {"yes", 1})),
|
2017-11-03 12:55:32 +00:00
|
|
|
OPT_FLAG("sub-create-cc-track", create_ccs, 0),
|
2016-09-06 18:09:56 +00:00
|
|
|
{0}
|
|
|
|
},
|
|
|
|
.size = sizeof(struct demux_opts),
|
|
|
|
.defaults = &(const struct demux_opts){
|
|
|
|
.max_bytes = 400 * 1024 * 1024,
|
2017-11-10 11:37:19 +00:00
|
|
|
.max_bytes_bw = 400 * 1024 * 1024,
|
2016-09-06 18:09:56 +00:00
|
|
|
.min_secs = 1.0,
|
2017-12-17 20:39:09 +00:00
|
|
|
.min_secs_cache = 10.0 * 60 * 60,
|
2017-11-10 15:30:43 +00:00
|
|
|
.seekable_cache = -1,
|
2016-12-04 22:15:31 +00:00
|
|
|
.access_references = 1,
|
2016-09-06 18:09:56 +00:00
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2014-07-16 20:40:21 +00:00
|
|
|
struct demux_internal {
|
|
|
|
struct mp_log *log;
|
|
|
|
|
|
|
|
// The demuxer runs potentially in another thread, so we keep two demuxer
|
|
|
|
// structs; the real demuxer can access the shadow struct only.
|
|
|
|
// Since demuxer and user threads both don't use locks, a third demuxer
|
|
|
|
// struct d_buffer is used to copy data between them in a synchronized way.
|
|
|
|
struct demuxer *d_thread; // accessed by demuxer impl. (producer)
|
|
|
|
struct demuxer *d_user; // accessed by player (consumer)
|
|
|
|
struct demuxer *d_buffer; // protected by lock; used to sync d_user/thread
|
|
|
|
|
|
|
|
// The lock protects the packet queues (struct demux_stream), d_buffer,
|
2016-03-09 23:06:13 +00:00
|
|
|
// and the fields below.
|
2014-07-16 20:40:21 +00:00
|
|
|
pthread_mutex_t lock;
|
|
|
|
pthread_cond_t wakeup;
|
|
|
|
pthread_t thread;
|
|
|
|
|
|
|
|
// -- All the following fields are protected by lock.
|
|
|
|
|
|
|
|
bool thread_terminate;
|
|
|
|
bool threading;
|
|
|
|
void (*wakeup_cb)(void *ctx);
|
|
|
|
void *wakeup_cb_ctx;
|
|
|
|
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
struct sh_stream **streams;
|
|
|
|
int num_streams;
|
|
|
|
|
|
|
|
int events;
|
|
|
|
|
2014-07-16 20:40:21 +00:00
|
|
|
bool warned_queue_overflow;
|
2014-07-18 13:08:38 +00:00
|
|
|
bool last_eof; // last actual global EOF status
|
|
|
|
bool eof; // whether we're in EOF state (reset for retry)
|
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-26 23:13:20 +00:00
|
|
|
bool idle;
|
2014-07-16 20:40:21 +00:00
|
|
|
bool autoselect;
|
2014-08-16 15:07:36 +00:00
|
|
|
double min_secs;
|
2015-08-05 21:41:29 +00:00
|
|
|
int max_bytes;
|
2017-10-21 17:26:33 +00:00
|
|
|
int max_bytes_bw;
|
2017-11-10 15:30:43 +00:00
|
|
|
bool seekable_cache;
|
2014-07-16 20:40:21 +00:00
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
// At least one decoder actually requested data since init or the last seek.
|
|
|
|
// Do this to allow the decoder thread to select streams before starting.
|
|
|
|
bool reading;
|
|
|
|
|
player: improve instant track switching
When switching tracks, we normally have the problem that data gets lost
due to readahead buffering. (Which in turn is because we're stubborn and
instruct the demuxers to discard data on unselected streams.) The
demuxer layer has a hack that re-reads discarded buffered data if a
stream is enabled mid-stream, so track switching will seem instant.
A somewhat similar problem is when all tracks of an external files were
disabled - when enabling the first track, we have to seek to the target
position.
Handle these with the same mechanism. Pass the "current time" to the
demuxer's stream switch function, and let the demuxer figure out what to
do. The demuxer will issue a refresh seek (if possible) to update the
new stream, or will issue a "normal" seek if there was no active stream
yet.
One case that changes is when a video/audio stream is enabled on an
external file with only a subtitle stream active, and the demuxer does
not support rrefresh seeks. This is a fuzzy case, because subtitles are
sparse, and the demuxer might have skipped large amounts of data. We
used to seek (and send the subtitle decoder some subtitle packets
twice). This case is sort of obscure and insane, and the fix would be
questionable, so we simply don't care.
Should mostly fix #3392.
2016-08-06 13:47:04 +00:00
|
|
|
// Set if we know that we are at the start of the file. This is used to
|
|
|
|
// avoid a redundant initial seek after enabling streams. We could just
|
|
|
|
// allow it, but to avoid buggy seeking affecting normal playback, we don't.
|
|
|
|
bool initial_state;
|
|
|
|
|
2014-08-06 17:25:37 +00:00
|
|
|
bool tracks_switched; // thread needs to inform demuxer of this
|
|
|
|
|
2014-07-21 17:27:24 +00:00
|
|
|
bool seeking; // there's a seek queued
|
|
|
|
int seek_flags; // flags for next seek (if seeking==true)
|
|
|
|
double seek_pts;
|
|
|
|
|
2018-01-05 15:41:16 +00:00
|
|
|
// (fields for debugging)
|
|
|
|
double seeking_in_progress; // low level seek state
|
|
|
|
int low_level_seeks; // number of started low level seeks
|
|
|
|
double demux_ts; // last demuxed DTS or PTS
|
|
|
|
|
player: improve instant track switching
When switching tracks, we normally have the problem that data gets lost
due to readahead buffering. (Which in turn is because we're stubborn and
instruct the demuxers to discard data on unselected streams.) The
demuxer layer has a hack that re-reads discarded buffered data if a
stream is enabled mid-stream, so track switching will seem instant.
A somewhat similar problem is when all tracks of an external files were
disabled - when enabling the first track, we have to seek to the target
position.
Handle these with the same mechanism. Pass the "current time" to the
demuxer's stream switch function, and let the demuxer figure out what to
do. The demuxer will issue a refresh seek (if possible) to update the
new stream, or will issue a "normal" seek if there was no active stream
yet.
One case that changes is when a video/audio stream is enabled on an
external file with only a subtitle stream active, and the demuxer does
not support rrefresh seeks. This is a fuzzy case, because subtitles are
sparse, and the demuxer might have skipped large amounts of data. We
used to seek (and send the subtitle decoder some subtitle packets
twice). This case is sort of obscure and insane, and the fix would be
questionable, so we simply don't care.
Should mostly fix #3392.
2016-08-06 13:47:04 +00:00
|
|
|
double ts_offset; // timestamp offset to apply to everything
|
2015-11-16 21:47:17 +00:00
|
|
|
|
2016-03-09 23:06:13 +00:00
|
|
|
void (*run_fn)(void *); // if non-NULL, function queued to be run on
|
|
|
|
void *run_fn_arg; // the thread as run_fn(run_fn_arg)
|
|
|
|
|
2017-11-04 22:39:04 +00:00
|
|
|
// (sorted by least recent use: index 0 is least recently used)
|
|
|
|
struct demux_cached_range **ranges;
|
|
|
|
int num_ranges;
|
|
|
|
|
|
|
|
size_t total_bytes; // total sum of packet data buffered
|
|
|
|
size_t fw_bytes; // sum of forward packet data in current_range
|
|
|
|
|
|
|
|
// Range from which decoder is reading, and to which demuxer is appending.
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
// This is never NULL. This is always ranges[num_ranges - 1].
|
2017-11-04 22:39:04 +00:00
|
|
|
struct demux_cached_range *current_range;
|
|
|
|
|
2017-12-24 00:56:09 +00:00
|
|
|
double highest_av_pts; // highest non-subtitle PTS seen - for duration
|
|
|
|
|
2018-01-17 06:07:15 +00:00
|
|
|
bool blocked;
|
|
|
|
|
2014-07-16 20:40:21 +00:00
|
|
|
// Cached state.
|
2014-11-12 20:47:41 +00:00
|
|
|
bool force_cache_update;
|
2014-07-16 20:40:21 +00:00
|
|
|
struct mp_tags *stream_metadata;
|
2016-03-29 09:29:52 +00:00
|
|
|
struct stream_cache_info stream_cache_info;
|
2014-07-16 20:40:21 +00:00
|
|
|
int64_t stream_size;
|
2014-10-24 13:40:01 +00:00
|
|
|
// Updated during init only.
|
|
|
|
char *stream_base_filename;
|
2014-07-16 20:40:21 +00:00
|
|
|
};
|
|
|
|
|
2017-11-04 22:39:04 +00:00
|
|
|
// A continuous range of cached packets for all enabled streams.
|
|
|
|
// (One demux_queue for each known stream.)
|
|
|
|
struct demux_cached_range {
|
|
|
|
// streams[] is indexed by demux_stream->index
|
|
|
|
struct demux_queue **streams;
|
|
|
|
int num_streams;
|
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
// Computed from the stream queue's values. These fields (unlike as with
|
|
|
|
// demux_queue) are always either NOPTS, or fully valid.
|
2017-11-04 22:39:04 +00:00
|
|
|
double seek_start, seek_end;
|
demux: include EOF state in cached seekable range
This means if the user tries to seek past EOF, and we know EOF was seen
already, then use a cached seek, instead of triggering a low level seek.
This requires some annoying tracking, but seems pretty simple otherwise.
One advantage of doing this is that if the user tries to do this kind of
seek, there's no unnecessary waiting for a reaction by network (and in
most cases, redundant downloading of data just to discard it again).
Another is that this avoids creating overlapping seek ranges: previously, the
low level seek would naturally create a new range. Then it would read and add
data from the end of the stream due to the low level demuxer not being able to
seek to the target and selecting the last seek point before the end of the
stream. Consequently, this new range would overlap with the previous cached
range. But since the cache joining code is written such that you join the
current range with the _next_ range (instead of the previous as it would be
needed in this case), the overlapping ranges were left alone, until seeking back
to the previous range. That was ugly, sort of harmless, and could happen in
other cases, but this avoidable case was pretty easy to trigger.
2018-01-05 16:38:09 +00:00
|
|
|
|
2018-01-09 21:02:25 +00:00
|
|
|
bool is_bof; // set if the file begins with this range
|
|
|
|
bool is_eof; // set if the file ends with this range
|
2017-11-04 22:39:04 +00:00
|
|
|
};
|
|
|
|
|
2017-11-10 11:17:34 +00:00
|
|
|
#define MAX_INDEX_ENTRIES 16
|
|
|
|
|
2017-11-04 22:39:04 +00:00
|
|
|
// A continuous list of cached packets for a single stream/range. There is one
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
// for each stream and range. Also contains some state for use during demuxing
|
|
|
|
// (keeping it across seeks makes it easier to resume demuxing).
|
2017-11-04 22:39:04 +00:00
|
|
|
struct demux_queue {
|
|
|
|
struct demux_stream *ds;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
struct demux_cached_range *range;
|
2017-11-04 22:39:04 +00:00
|
|
|
|
|
|
|
struct demux_packet *head;
|
|
|
|
struct demux_packet *tail;
|
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
struct demux_packet *next_prune_target; // cached value for faster pruning
|
|
|
|
|
|
|
|
bool correct_dts; // packet DTS is strictly monotonically increasing
|
|
|
|
bool correct_pos; // packet pos is strictly monotonically increasing
|
|
|
|
int64_t last_pos; // for determining correct_pos
|
|
|
|
double last_dts; // for determining correct_dts
|
|
|
|
double last_ts; // timestamp of the last packet added to queue
|
|
|
|
|
|
|
|
// for incrementally determining seek PTS range
|
|
|
|
double keyframe_pts, keyframe_end_pts;
|
|
|
|
struct demux_packet *keyframe_latest;
|
|
|
|
|
|
|
|
// incrementally maintained seek range, possibly invalid
|
2017-11-04 22:39:04 +00:00
|
|
|
double seek_start, seek_end;
|
2017-11-10 07:57:37 +00:00
|
|
|
double last_pruned; // timestamp of last pruned keyframe
|
2017-11-10 11:17:34 +00:00
|
|
|
|
2018-01-09 21:02:25 +00:00
|
|
|
bool is_bof; // started demuxing at beginning of file
|
demux: include EOF state in cached seekable range
This means if the user tries to seek past EOF, and we know EOF was seen
already, then use a cached seek, instead of triggering a low level seek.
This requires some annoying tracking, but seems pretty simple otherwise.
One advantage of doing this is that if the user tries to do this kind of
seek, there's no unnecessary waiting for a reaction by network (and in
most cases, redundant downloading of data just to discard it again).
Another is that this avoids creating overlapping seek ranges: previously, the
low level seek would naturally create a new range. Then it would read and add
data from the end of the stream due to the low level demuxer not being able to
seek to the target and selecting the last seek point before the end of the
stream. Consequently, this new range would overlap with the previous cached
range. But since the cache joining code is written such that you join the
current range with the _next_ range (instead of the previous as it would be
needed in this case), the overlapping ranges were left alone, until seeking back
to the previous range. That was ugly, sort of harmless, and could happen in
other cases, but this avoidable case was pretty easy to trigger.
2018-01-05 16:38:09 +00:00
|
|
|
bool is_eof; // received true EOF here
|
|
|
|
|
2017-11-10 11:17:34 +00:00
|
|
|
// incomplete index to somewhat speed up seek operations
|
|
|
|
// the entries in index[] must be in packet queue append/removal order
|
|
|
|
int num_index; // valid index[] entries
|
|
|
|
double index_distance; // minimum keyframe distance to add index element
|
|
|
|
struct demux_packet *index[MAX_INDEX_ENTRIES];
|
2017-11-04 22:39:04 +00:00
|
|
|
};
|
|
|
|
|
2013-07-11 17:20:25 +00:00
|
|
|
struct demux_stream {
|
2014-07-16 20:40:21 +00:00
|
|
|
struct demux_internal *in;
|
2017-11-04 22:39:04 +00:00
|
|
|
struct sh_stream *sh; // ds->sh->ds == ds
|
|
|
|
enum stream_type type; // equals to sh->type
|
|
|
|
int index; // equals to sh->index
|
2017-10-21 17:26:33 +00:00
|
|
|
// --- all fields are protected by in->lock
|
|
|
|
|
|
|
|
// demuxer state
|
2014-07-16 20:40:21 +00:00
|
|
|
bool selected; // user wants packets from this stream
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
bool eager; // try to keep at least 1 packet queued
|
2015-04-20 20:53:33 +00:00
|
|
|
// if false, this stream is disabled, or passively
|
|
|
|
// read (like subtitles)
|
demux: always discard cached packets on track switches
This fixes weird behavior in the following case:
- open a file
- make sure the max. demuxer forward cache is smaller than the
file's video track
- make sure the max. readahead duration is larger than the file's
duration
- disable the audio track
- seek to the beginning of the file
- once the cache has filled enable the audio track
- a queue overflow warning should appear
(- looking at the seek ranges is also interesting)
The queue overflow warning happens because the packed queue for the
video track will use up the full quota set by --demuxer-max-bytes. When
the audio track is enabled, reading an audio packet would technically
overflow the packet cache by the size of whatever packet is read next.
This means the demuxer signals EOF to the decoder, and once playback has
consumed enough video packets so that audio packets can be read again,
the decoder resumes from EOF. This interacts badly with A/V
synchronization and the whole thing can randomly crap itself until audio
has fully recovered.
We didn't care about this so far, but we want to raise the readahead
duration to something very high, so that the demuxer cache is fully
used. This means this case can be hit quite quickly by switching audio
or subtitle tracks, and is not really an obscure corner case anymore.
Fix this by always losing all cache. Since the cache can't be used
anyway until the newly selected track has been read, this is not much of
a disadvantage. The only thing that could be brought up is that
unselecting the track again could resume operation normally. (Maybe this
would be useful if network died completely without chance of recovery.
Then you could watch the already buffered video anyway by deselecting
the audio track again.) But given the headaches, this seems like the
better solution.
Unfortunately this requires adding new new strange fields and strangely
fragmenting state management functions again. I'm sure whoever works on
this in the future will hate me. Currently it seems like the lesser
evil, and much simpler and robust than the other potential solutions.
In case this needs to be revisited, here is a reminder for readers from
the future what alternative solutions were considered, without those
disadvantages:
A first attempted solution allowed the demuxer to buffer some additional
packets on track switching. This would allow it to read enough data to
feed the decoder at least. But it was still awkward, as it didn't allow
the demuxer to continue prefetching the newly selected track. It also
barely worked, because you could make the forward buffer "over full" by
seeking back with seekable cache enabled, and then it couldn't read
packets anyway.
As alternative solution, we could always demux and cache all tracks,
even if they're deselected. This would also not require a network-level
seek for the "refresh" logic (it's the thing that lets the video decoder
continue as if nothing happened, while actually seeking back in the
stream to get the missing audio packets, in the case of enabling a
previously disabled audio track). But it would also possibly waste
network and memory resources, depending on what the user actually wants.
A second solution would just account the queue sizes for each stream
separately. We could freely fill up the audio packet queue, even if the
video queue is full. Since the demuxer API returns interleaved packets
and doesn't let you predict which packet type comes next, this is not as
simple as it sounds, but it'd probably tie in nicely with the "refresh"
logic.
A third solution would be removing buffered video packets from the end
of the packet queue. Since the "refresh" logic gets these anyway, there
is no reason to keep them if they prevent the audio packet queue from
catching up with the video one. But this would require additional logic,
would interact badly with a bunch of other corner cases. And as far as
the code goes, it's rather complex, because all the logic is written
with FIFO behavior in mind (including the fact that the packet queue is
a singly linked list with no backwards links, making removal from the
end harder).
2017-12-17 20:34:50 +00:00
|
|
|
bool refreshing; // finding old position after track switches
|
|
|
|
bool eof; // end of demuxed stream? (true if no more packets)
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
|
2017-11-04 22:39:04 +00:00
|
|
|
bool global_correct_dts;// all observed so far
|
|
|
|
bool global_correct_pos;
|
2017-10-21 17:26:33 +00:00
|
|
|
|
2017-11-04 22:39:04 +00:00
|
|
|
// current queue - used both for reading and demuxing (this is never NULL)
|
|
|
|
struct demux_queue *queue;
|
|
|
|
|
2017-10-21 17:26:33 +00:00
|
|
|
// reader (decoder) state (bitrate calculations are part of it because we
|
|
|
|
// want to return the bitrate closest to the "current position")
|
|
|
|
double base_ts; // timestamp of the last packet returned to decoder
|
2014-12-12 00:00:58 +00:00
|
|
|
double last_br_ts; // timestamp of last packet bitrate was calculated
|
|
|
|
size_t last_br_bytes; // summed packet sizes since last bitrate calculation
|
|
|
|
double bitrate;
|
2017-11-04 22:39:04 +00:00
|
|
|
size_t fw_packs; // number of packets in buffer (forward)
|
|
|
|
size_t fw_bytes; // total bytes of packets in buffer (forward)
|
2017-10-21 17:26:33 +00:00
|
|
|
struct demux_packet *reader_head; // points at current decoder position
|
demux: fix cached SEEK_FORWARD seeks into end of cached regions/EOF
Although seeking past the cached range will trigger a low level seek, a
seek into the region between cache end and last video key frame would
simply seek to the video key frame. This meant that you could get
"stuck" at the end of the file instead of terminating playback when
trying to seek past the end.
One change is that we fix this by _actually_ allowing SEEK_FORWARD to
seek past the last video keyframe in find_seek_target().
In that case, or otherwise seeking to cache buffer end, it could happen
that we set ds->reader_head=NULL if the seek target is after the current
packet. We allow this, because the end of the cached region is defined
by the existence of "any" packet, not necessarily a key frame. Seeking
there still makes sense, because we know that there is going to be more
packets (or EOF) that satisfy the seek target.
The problem is that just resuming demuxing with reader_head==NULL will
simply return any packets that come its way, even non-keyframe ones.
Some decoders will produce ugly soup in this case. (In practice, this
was not a problem, because seeking at the end of the cached region was
rare before this commit, and also some decoders like h264 will skip
broken frames by default anyway.)
So the other change of this commit is to enable key frame skipping.
As a nasty implementation detail, we use a separate flag, instead of
setting reader_head to the first key frame encounted (reader_head being
NULL can happen after a normal seek or on playback start, and then we
want to mirror the underlying demuxer behavior, for better or worse).
This change is relatively untested, so you get to keep the pieces for
yourself.
2017-10-23 18:09:21 +00:00
|
|
|
bool skip_to_keyframe;
|
2017-01-10 13:03:41 +00:00
|
|
|
bool attached_picture_added;
|
|
|
|
|
demux: always discard cached packets on track switches
This fixes weird behavior in the following case:
- open a file
- make sure the max. demuxer forward cache is smaller than the
file's video track
- make sure the max. readahead duration is larger than the file's
duration
- disable the audio track
- seek to the beginning of the file
- once the cache has filled enable the audio track
- a queue overflow warning should appear
(- looking at the seek ranges is also interesting)
The queue overflow warning happens because the packed queue for the
video track will use up the full quota set by --demuxer-max-bytes. When
the audio track is enabled, reading an audio packet would technically
overflow the packet cache by the size of whatever packet is read next.
This means the demuxer signals EOF to the decoder, and once playback has
consumed enough video packets so that audio packets can be read again,
the decoder resumes from EOF. This interacts badly with A/V
synchronization and the whole thing can randomly crap itself until audio
has fully recovered.
We didn't care about this so far, but we want to raise the readahead
duration to something very high, so that the demuxer cache is fully
used. This means this case can be hit quite quickly by switching audio
or subtitle tracks, and is not really an obscure corner case anymore.
Fix this by always losing all cache. Since the cache can't be used
anyway until the newly selected track has been read, this is not much of
a disadvantage. The only thing that could be brought up is that
unselecting the track again could resume operation normally. (Maybe this
would be useful if network died completely without chance of recovery.
Then you could watch the already buffered video anyway by deselecting
the audio track again.) But given the headaches, this seems like the
better solution.
Unfortunately this requires adding new new strange fields and strangely
fragmenting state management functions again. I'm sure whoever works on
this in the future will hate me. Currently it seems like the lesser
evil, and much simpler and robust than the other potential solutions.
In case this needs to be revisited, here is a reminder for readers from
the future what alternative solutions were considered, without those
disadvantages:
A first attempted solution allowed the demuxer to buffer some additional
packets on track switching. This would allow it to read enough data to
feed the decoder at least. But it was still awkward, as it didn't allow
the demuxer to continue prefetching the newly selected track. It also
barely worked, because you could make the forward buffer "over full" by
seeking back with seekable cache enabled, and then it couldn't read
packets anyway.
As alternative solution, we could always demux and cache all tracks,
even if they're deselected. This would also not require a network-level
seek for the "refresh" logic (it's the thing that lets the video decoder
continue as if nothing happened, while actually seeking back in the
stream to get the missing audio packets, in the case of enabling a
previously disabled audio track). But it would also possibly waste
network and memory resources, depending on what the user actually wants.
A second solution would just account the queue sizes for each stream
separately. We could freely fill up the audio packet queue, even if the
video queue is full. Since the demuxer API returns interleaved packets
and doesn't let you predict which packet type comes next, this is not as
simple as it sounds, but it'd probably tie in nicely with the "refresh"
logic.
A third solution would be removing buffered video packets from the end
of the packet queue. Since the "refresh" logic gets these anyway, there
is no reason to keep them if they prevent the audio packet queue from
catching up with the video one. But this would require additional logic,
would interact badly with a bunch of other corner cases. And as far as
the code goes, it's rather complex, because all the logic is written
with FIFO behavior in mind (including the fact that the packet queue is
a singly linked list with no backwards links, making removal from the
end harder).
2017-12-17 20:34:50 +00:00
|
|
|
// for refresh seeks: pos/dts of last packet returned to reader
|
|
|
|
int64_t last_ret_pos;
|
|
|
|
double last_ret_dts;
|
|
|
|
|
2015-12-22 01:35:15 +00:00
|
|
|
// for closed captions (demuxer_feed_caption)
|
|
|
|
struct sh_stream *cc;
|
2017-10-21 17:26:33 +00:00
|
|
|
bool ignore_eof; // ignore stream in underrun detection
|
2013-07-11 17:20:25 +00:00
|
|
|
};
|
2013-07-11 17:17:51 +00:00
|
|
|
|
2014-11-03 20:54:49 +00:00
|
|
|
// Return "a", or if that is NOPTS, return "def".
|
|
|
|
#define PTS_OR_DEF(a, def) ((a) == MP_NOPTS_VALUE ? (def) : (a))
|
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-26 23:13:20 +00:00
|
|
|
// If one of the values is NOPTS, always pick the other one.
|
2014-11-03 20:54:49 +00:00
|
|
|
#define MP_PTS_MIN(a, b) MPMIN(PTS_OR_DEF(a, b), PTS_OR_DEF(b, a))
|
|
|
|
#define MP_PTS_MAX(a, b) MPMAX(PTS_OR_DEF(a, b), PTS_OR_DEF(b, a))
|
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-26 23:13:20 +00:00
|
|
|
|
2015-11-16 21:47:17 +00:00
|
|
|
#define MP_ADD_PTS(a, b) ((a) == MP_NOPTS_VALUE ? (a) : ((a) + (b)))
|
|
|
|
|
2014-07-16 20:40:21 +00:00
|
|
|
static void demuxer_sort_chapters(demuxer_t *demuxer);
|
|
|
|
static void *demux_thread(void *pctx);
|
|
|
|
static void update_cache(struct demux_internal *in);
|
stream: report chapter times, use time seeks for DVD chapters
Allow the stream layer to report chapter times. Extend stream_dvd to do
this. I'm not 100% sure whether the re-used code is bug-free (because it
was used for slave-mode and/or debugging only).
MAke the frontend do time-based seeks when switching DVD chapters. I'm
not sure if there's a real reason STREAM_CTRL_SEEK_TO_CHAPTER exists
(maybe/hopefully not), but we will see.
Note that querying chapter times in demuxer_chapter_time() with the new
STREAM_CTRL_GET_CHAPTER_TIME could be excessively slow, especially with
the cache enabled. The frontend likes to query chapter times very often.
Additionally, stream_dvd uses some sort of quadratic algorithm to list
times for all chapters. For this reason, we try to query all chapters on
start (after the demuxer is opened), and add the chapters to the demuxer
chapter list. demuxer_chapter_time() will get the time from that list,
instead of asking the stream layer over and over again.
This assumes stream_dvd knows the list of chapters at the start, and
also that the list of chapters never changes during playback. This
seems to be true, and the only exception, switching DVD titles, is not
supported at runtime (and doesn't need to be supported).
2013-05-03 23:20:39 +00:00
|
|
|
|
2017-11-04 22:39:04 +00:00
|
|
|
#if 0
|
|
|
|
// very expensive check for redundant cached queue state
|
|
|
|
static void check_queue_consistency(struct demux_internal *in)
|
|
|
|
{
|
|
|
|
size_t total_bytes = 0;
|
|
|
|
size_t total_fw_bytes = 0;
|
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
assert(in->current_range && in->num_ranges > 0);
|
|
|
|
assert(in->current_range == in->ranges[in->num_ranges - 1]);
|
|
|
|
|
2017-11-04 22:39:04 +00:00
|
|
|
for (int n = 0; n < in->num_ranges; n++) {
|
|
|
|
struct demux_cached_range *range = in->ranges[n];
|
demux: fix crash due to incorrect seek range accounting
update_seek_ranges() has some special code that attempts to correctly
adjust seek ranges for subtitle tracks. (Subtitle are a nightmare for
seek ranges, because they are sparse, so using the packet list is not
enough to reliably determine the valid cached range.)
This had code like this inside the modified if statement:
range->seek_start = MP_PTS_MAX(range->seek_start, <something>);
If seek_start is NOPTS, then seek_start will be set to <something>,
breaking some other code that checks seek_start for NOPTS to see if it's
empty. Fix this by explicitly checking whether seek_start is NOPTS
before adjusting it.
The crash happened in prune_old_packets() because the range was marked
as non-empty, yet there was no packet in it to prune. This was with
files with muxed subtitles, when seeking back to the start. This should
not happen anymore with the change. Also add an assert() to
check_queue_consistency() that checks for this specific case.
There's still some mess. In theory, subtitle tracks could be completely
empty, yet their seek range would span the entire file. Seek range
tracking of subtitle files is slightly broken (even before this change).
Some of this should probably be revisited later, including not just
using seek_start to determine whether a seek range should be pruned due
to being empty.
2018-01-05 14:51:40 +00:00
|
|
|
int range_num_packets = 0;
|
2017-11-04 22:39:04 +00:00
|
|
|
|
|
|
|
assert(range->num_streams == in->num_streams);
|
|
|
|
|
|
|
|
for (int i = 0; i < range->num_streams; i++) {
|
|
|
|
struct demux_queue *queue = range->streams[i];
|
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
assert(queue->range == range);
|
|
|
|
|
2017-11-04 22:39:04 +00:00
|
|
|
size_t fw_bytes = 0;
|
|
|
|
size_t fw_packs = 0;
|
|
|
|
bool is_forward = false;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
bool kf_found = false;
|
|
|
|
bool npt_found = false;
|
2017-11-10 11:17:34 +00:00
|
|
|
int next_index = 0;
|
2017-11-04 22:39:04 +00:00
|
|
|
for (struct demux_packet *dp = queue->head; dp; dp = dp->next) {
|
|
|
|
is_forward |= dp == queue->ds->reader_head;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
kf_found |= dp == queue->keyframe_latest;
|
|
|
|
npt_found |= dp == queue->next_prune_target;
|
2017-11-04 22:39:04 +00:00
|
|
|
|
|
|
|
size_t bytes = demux_packet_estimate_total_size(dp);
|
|
|
|
total_bytes += bytes;
|
|
|
|
if (is_forward) {
|
|
|
|
fw_bytes += bytes;
|
|
|
|
fw_packs += 1;
|
|
|
|
assert(range == in->current_range);
|
|
|
|
assert(queue->ds->queue == queue);
|
|
|
|
}
|
demux: fix crash due to incorrect seek range accounting
update_seek_ranges() has some special code that attempts to correctly
adjust seek ranges for subtitle tracks. (Subtitle are a nightmare for
seek ranges, because they are sparse, so using the packet list is not
enough to reliably determine the valid cached range.)
This had code like this inside the modified if statement:
range->seek_start = MP_PTS_MAX(range->seek_start, <something>);
If seek_start is NOPTS, then seek_start will be set to <something>,
breaking some other code that checks seek_start for NOPTS to see if it's
empty. Fix this by explicitly checking whether seek_start is NOPTS
before adjusting it.
The crash happened in prune_old_packets() because the range was marked
as non-empty, yet there was no packet in it to prune. This was with
files with muxed subtitles, when seeking back to the start. This should
not happen anymore with the change. Also add an assert() to
check_queue_consistency() that checks for this specific case.
There's still some mess. In theory, subtitle tracks could be completely
empty, yet their seek range would span the entire file. Seek range
tracking of subtitle files is slightly broken (even before this change).
Some of this should probably be revisited later, including not just
using seek_start to determine whether a seek range should be pruned due
to being empty.
2018-01-05 14:51:40 +00:00
|
|
|
range_num_packets += 1;
|
2017-11-04 22:39:04 +00:00
|
|
|
|
|
|
|
if (!dp->next)
|
|
|
|
assert(queue->tail == dp);
|
2017-11-10 11:17:34 +00:00
|
|
|
|
|
|
|
if (next_index < queue->num_index && queue->index[next_index] == dp)
|
|
|
|
next_index += 1;
|
2017-11-04 22:39:04 +00:00
|
|
|
}
|
|
|
|
if (!queue->head)
|
|
|
|
assert(!queue->tail);
|
2017-11-10 11:17:34 +00:00
|
|
|
assert(next_index == queue->num_index);
|
2017-11-04 22:39:04 +00:00
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
// If the queue is currently used...
|
|
|
|
if (queue->ds->queue == queue) {
|
|
|
|
// ...reader_head and others must be in the queue.
|
|
|
|
assert(is_forward == !!queue->ds->reader_head);
|
|
|
|
assert(kf_found == !!queue->keyframe_latest);
|
|
|
|
}
|
|
|
|
|
|
|
|
assert(npt_found == !!queue->next_prune_target);
|
|
|
|
|
2017-11-04 22:39:04 +00:00
|
|
|
total_fw_bytes += fw_bytes;
|
|
|
|
|
|
|
|
if (range == in->current_range) {
|
|
|
|
assert(queue->ds->fw_bytes == fw_bytes);
|
|
|
|
assert(queue->ds->fw_packs == fw_packs);
|
|
|
|
} else {
|
|
|
|
assert(fw_bytes == 0 && fw_packs == 0);
|
|
|
|
}
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
|
|
|
|
if (queue->keyframe_latest)
|
|
|
|
assert(queue->keyframe_latest->keyframe);
|
2017-11-04 22:39:04 +00:00
|
|
|
}
|
demux: fix crash due to incorrect seek range accounting
update_seek_ranges() has some special code that attempts to correctly
adjust seek ranges for subtitle tracks. (Subtitle are a nightmare for
seek ranges, because they are sparse, so using the packet list is not
enough to reliably determine the valid cached range.)
This had code like this inside the modified if statement:
range->seek_start = MP_PTS_MAX(range->seek_start, <something>);
If seek_start is NOPTS, then seek_start will be set to <something>,
breaking some other code that checks seek_start for NOPTS to see if it's
empty. Fix this by explicitly checking whether seek_start is NOPTS
before adjusting it.
The crash happened in prune_old_packets() because the range was marked
as non-empty, yet there was no packet in it to prune. This was with
files with muxed subtitles, when seeking back to the start. This should
not happen anymore with the change. Also add an assert() to
check_queue_consistency() that checks for this specific case.
There's still some mess. In theory, subtitle tracks could be completely
empty, yet their seek range would span the entire file. Seek range
tracking of subtitle files is slightly broken (even before this change).
Some of this should probably be revisited later, including not just
using seek_start to determine whether a seek range should be pruned due
to being empty.
2018-01-05 14:51:40 +00:00
|
|
|
|
|
|
|
// Invariant needed by pruning; violation has worse effects than just
|
|
|
|
// e.g. broken seeking due to incorrect seek ranges.
|
|
|
|
if (range->seek_start != MP_NOPTS_VALUE)
|
|
|
|
assert(range_num_packets > 0);
|
2017-11-04 22:39:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
assert(in->total_bytes == total_bytes);
|
|
|
|
assert(in->fw_bytes == total_fw_bytes);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
static void recompute_buffers(struct demux_stream *ds)
|
2017-11-04 22:39:04 +00:00
|
|
|
{
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
ds->fw_packs = 0;
|
|
|
|
ds->fw_bytes = 0;
|
2017-11-04 22:39:04 +00:00
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
for (struct demux_packet *dp = ds->reader_head; dp; dp = dp->next) {
|
|
|
|
ds->fw_bytes += demux_packet_estimate_total_size(dp);
|
|
|
|
ds->fw_packs++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// (this doesn't do most required things for a switch, like updating ds->queue)
|
|
|
|
static void set_current_range(struct demux_internal *in,
|
|
|
|
struct demux_cached_range *range)
|
|
|
|
{
|
|
|
|
in->current_range = range;
|
|
|
|
|
|
|
|
// Move to in->ranges[in->num_ranges-1] (for LRU sorting/invariant)
|
|
|
|
for (int n = 0; n < in->num_ranges; n++) {
|
|
|
|
if (in->ranges[n] == range) {
|
|
|
|
MP_TARRAY_REMOVE_AT(in->ranges, in->num_ranges, n);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
MP_TARRAY_APPEND(in, in->ranges, in->num_ranges, range);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Refresh range->seek_start/end.
|
|
|
|
static void update_seek_ranges(struct demux_cached_range *range)
|
|
|
|
{
|
2017-11-04 22:39:04 +00:00
|
|
|
range->seek_start = range->seek_end = MP_NOPTS_VALUE;
|
2018-01-09 21:02:25 +00:00
|
|
|
range->is_bof = true;
|
demux: include EOF state in cached seekable range
This means if the user tries to seek past EOF, and we know EOF was seen
already, then use a cached seek, instead of triggering a low level seek.
This requires some annoying tracking, but seems pretty simple otherwise.
One advantage of doing this is that if the user tries to do this kind of
seek, there's no unnecessary waiting for a reaction by network (and in
most cases, redundant downloading of data just to discard it again).
Another is that this avoids creating overlapping seek ranges: previously, the
low level seek would naturally create a new range. Then it would read and add
data from the end of the stream due to the low level demuxer not being able to
seek to the target and selecting the last seek point before the end of the
stream. Consequently, this new range would overlap with the previous cached
range. But since the cache joining code is written such that you join the
current range with the _next_ range (instead of the previous as it would be
needed in this case), the overlapping ranges were left alone, until seeking back
to the previous range. That was ugly, sort of harmless, and could happen in
other cases, but this avoidable case was pretty easy to trigger.
2018-01-05 16:38:09 +00:00
|
|
|
range->is_eof = true;
|
2017-11-04 22:39:04 +00:00
|
|
|
|
|
|
|
for (int n = 0; n < range->num_streams; n++) {
|
|
|
|
struct demux_queue *queue = range->streams[n];
|
2017-11-10 07:57:37 +00:00
|
|
|
|
|
|
|
if (queue->ds->selected && queue->ds->eager) {
|
2017-11-04 22:39:04 +00:00
|
|
|
range->seek_start = MP_PTS_MAX(range->seek_start, queue->seek_start);
|
|
|
|
range->seek_end = MP_PTS_MIN(range->seek_end, queue->seek_end);
|
|
|
|
|
demux: include EOF state in cached seekable range
This means if the user tries to seek past EOF, and we know EOF was seen
already, then use a cached seek, instead of triggering a low level seek.
This requires some annoying tracking, but seems pretty simple otherwise.
One advantage of doing this is that if the user tries to do this kind of
seek, there's no unnecessary waiting for a reaction by network (and in
most cases, redundant downloading of data just to discard it again).
Another is that this avoids creating overlapping seek ranges: previously, the
low level seek would naturally create a new range. Then it would read and add
data from the end of the stream due to the low level demuxer not being able to
seek to the target and selecting the last seek point before the end of the
stream. Consequently, this new range would overlap with the previous cached
range. But since the cache joining code is written such that you join the
current range with the _next_ range (instead of the previous as it would be
needed in this case), the overlapping ranges were left alone, until seeking back
to the previous range. That was ugly, sort of harmless, and could happen in
other cases, but this avoidable case was pretty easy to trigger.
2018-01-05 16:38:09 +00:00
|
|
|
range->is_eof &= queue->is_eof;
|
2018-01-09 21:02:25 +00:00
|
|
|
range->is_bof &= queue->is_bof;
|
demux: include EOF state in cached seekable range
This means if the user tries to seek past EOF, and we know EOF was seen
already, then use a cached seek, instead of triggering a low level seek.
This requires some annoying tracking, but seems pretty simple otherwise.
One advantage of doing this is that if the user tries to do this kind of
seek, there's no unnecessary waiting for a reaction by network (and in
most cases, redundant downloading of data just to discard it again).
Another is that this avoids creating overlapping seek ranges: previously, the
low level seek would naturally create a new range. Then it would read and add
data from the end of the stream due to the low level demuxer not being able to
seek to the target and selecting the last seek point before the end of the
stream. Consequently, this new range would overlap with the previous cached
range. But since the cache joining code is written such that you join the
current range with the _next_ range (instead of the previous as it would be
needed in this case), the overlapping ranges were left alone, until seeking back
to the previous range. That was ugly, sort of harmless, and could happen in
other cases, but this avoidable case was pretty easy to trigger.
2018-01-05 16:38:09 +00:00
|
|
|
|
2017-11-10 07:57:37 +00:00
|
|
|
if (queue->seek_start >= queue->seek_end) {
|
2017-11-04 22:39:04 +00:00
|
|
|
range->seek_start = range->seek_end = MP_NOPTS_VALUE;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-11-10 07:57:37 +00:00
|
|
|
// Sparse stream behavior is not very clearly defined, but usually we don't
|
|
|
|
// want it to restrict the range of other streams, unless
|
|
|
|
// This is incorrect in any of these cases:
|
|
|
|
// - sparse streams only (it's unknown how to determine an accurate range)
|
|
|
|
// - if sparse streams have non-keyframe packets (we set queue->last_pruned
|
|
|
|
// to the start of the pruned keyframe range - we'd need the end or so)
|
|
|
|
// We also assume that ds->eager equals to a stream being sparse (usually
|
|
|
|
// true, except if only sparse streams are selected).
|
|
|
|
// We also rely on the fact that the demuxer position will always be ahead
|
|
|
|
// of the seek_end for audio/video, because they need to prefetch at least
|
|
|
|
// 1 packet to detect the end of a keyframe range. This means that we're
|
|
|
|
// relatively guaranteed to have all sparse (subtitle) packets within the
|
|
|
|
// seekable range.
|
|
|
|
for (int n = 0; n < range->num_streams; n++) {
|
|
|
|
struct demux_queue *queue = range->streams[n];
|
|
|
|
if (queue->ds->selected && !queue->ds->eager &&
|
demux: fix crash due to incorrect seek range accounting
update_seek_ranges() has some special code that attempts to correctly
adjust seek ranges for subtitle tracks. (Subtitle are a nightmare for
seek ranges, because they are sparse, so using the packet list is not
enough to reliably determine the valid cached range.)
This had code like this inside the modified if statement:
range->seek_start = MP_PTS_MAX(range->seek_start, <something>);
If seek_start is NOPTS, then seek_start will be set to <something>,
breaking some other code that checks seek_start for NOPTS to see if it's
empty. Fix this by explicitly checking whether seek_start is NOPTS
before adjusting it.
The crash happened in prune_old_packets() because the range was marked
as non-empty, yet there was no packet in it to prune. This was with
files with muxed subtitles, when seeking back to the start. This should
not happen anymore with the change. Also add an assert() to
check_queue_consistency() that checks for this specific case.
There's still some mess. In theory, subtitle tracks could be completely
empty, yet their seek range would span the entire file. Seek range
tracking of subtitle files is slightly broken (even before this change).
Some of this should probably be revisited later, including not just
using seek_start to determine whether a seek range should be pruned due
to being empty.
2018-01-05 14:51:40 +00:00
|
|
|
queue->last_pruned != MP_NOPTS_VALUE &&
|
|
|
|
range->seek_start != MP_NOPTS_VALUE)
|
2017-11-10 07:57:37 +00:00
|
|
|
{
|
|
|
|
// (last_pruned is _exclusive_ to the seekable range, so add a small
|
|
|
|
// value to exclude it from the valid range.)
|
|
|
|
range->seek_start =
|
|
|
|
MP_PTS_MAX(range->seek_start, queue->last_pruned + 0.1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-11-04 22:39:04 +00:00
|
|
|
if (range->seek_start >= range->seek_end)
|
|
|
|
range->seek_start = range->seek_end = MP_NOPTS_VALUE;
|
|
|
|
}
|
|
|
|
|
2017-11-10 10:35:19 +00:00
|
|
|
// Remove queue->head from the queue. Does not update in->fw_bytes/in->fw_packs.
|
|
|
|
static void remove_head_packet(struct demux_queue *queue)
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
{
|
2017-11-10 10:35:19 +00:00
|
|
|
struct demux_packet *dp = queue->head;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
|
|
|
|
assert(queue->ds->reader_head != dp);
|
|
|
|
if (queue->next_prune_target == dp)
|
|
|
|
queue->next_prune_target = NULL;
|
|
|
|
if (queue->keyframe_latest == dp)
|
|
|
|
queue->keyframe_latest = NULL;
|
2018-01-09 21:02:25 +00:00
|
|
|
queue->is_bof = false;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
|
|
|
|
queue->ds->in->total_bytes -= demux_packet_estimate_total_size(dp);
|
|
|
|
|
2017-11-10 11:17:34 +00:00
|
|
|
if (queue->num_index && queue->index[0] == dp)
|
|
|
|
MP_TARRAY_REMOVE_AT(queue->index, queue->num_index, 0);
|
|
|
|
|
2017-11-10 10:35:19 +00:00
|
|
|
queue->head = dp->next;
|
|
|
|
if (!queue->head)
|
|
|
|
queue->tail = NULL;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
|
|
|
|
talloc_free(dp);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void clear_queue(struct demux_queue *queue)
|
|
|
|
{
|
|
|
|
struct demux_stream *ds = queue->ds;
|
|
|
|
struct demux_internal *in = ds->in;
|
|
|
|
|
|
|
|
struct demux_packet *dp = queue->head;
|
|
|
|
while (dp) {
|
|
|
|
struct demux_packet *dn = dp->next;
|
|
|
|
in->total_bytes -= demux_packet_estimate_total_size(dp);
|
|
|
|
assert(ds->reader_head != dp);
|
|
|
|
talloc_free(dp);
|
|
|
|
dp = dn;
|
|
|
|
}
|
|
|
|
queue->head = queue->tail = NULL;
|
|
|
|
queue->next_prune_target = NULL;
|
|
|
|
queue->keyframe_latest = NULL;
|
2017-11-10 07:57:37 +00:00
|
|
|
queue->seek_start = queue->seek_end = queue->last_pruned = MP_NOPTS_VALUE;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
|
2017-11-10 11:17:34 +00:00
|
|
|
queue->num_index = 0;
|
|
|
|
queue->index_distance = 1.0;
|
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
queue->correct_dts = queue->correct_pos = true;
|
|
|
|
queue->last_pos = -1;
|
|
|
|
queue->last_ts = queue->last_dts = MP_NOPTS_VALUE;
|
|
|
|
queue->keyframe_latest = NULL;
|
|
|
|
queue->keyframe_pts = queue->keyframe_end_pts = MP_NOPTS_VALUE;
|
demux: include EOF state in cached seekable range
This means if the user tries to seek past EOF, and we know EOF was seen
already, then use a cached seek, instead of triggering a low level seek.
This requires some annoying tracking, but seems pretty simple otherwise.
One advantage of doing this is that if the user tries to do this kind of
seek, there's no unnecessary waiting for a reaction by network (and in
most cases, redundant downloading of data just to discard it again).
Another is that this avoids creating overlapping seek ranges: previously, the
low level seek would naturally create a new range. Then it would read and add
data from the end of the stream due to the low level demuxer not being able to
seek to the target and selecting the last seek point before the end of the
stream. Consequently, this new range would overlap with the previous cached
range. But since the cache joining code is written such that you join the
current range with the _next_ range (instead of the previous as it would be
needed in this case), the overlapping ranges were left alone, until seeking back
to the previous range. That was ugly, sort of harmless, and could happen in
other cases, but this avoidable case was pretty easy to trigger.
2018-01-05 16:38:09 +00:00
|
|
|
|
|
|
|
queue->is_eof = false;
|
2018-01-09 21:02:25 +00:00
|
|
|
queue->is_bof = false;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void clear_cached_range(struct demux_internal *in,
|
|
|
|
struct demux_cached_range *range)
|
|
|
|
{
|
|
|
|
for (int n = 0; n < range->num_streams; n++)
|
|
|
|
clear_queue(range->streams[n]);
|
|
|
|
update_seek_ranges(range);
|
|
|
|
}
|
|
|
|
|
2017-11-10 11:32:40 +00:00
|
|
|
// Remove ranges with no data (except in->current_range). Also remove excessive
|
|
|
|
// ranges.
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
static void free_empty_cached_ranges(struct demux_internal *in)
|
|
|
|
{
|
|
|
|
assert(in->current_range && in->num_ranges > 0);
|
|
|
|
assert(in->current_range == in->ranges[in->num_ranges - 1]);
|
|
|
|
|
2017-11-10 11:32:40 +00:00
|
|
|
while (1) {
|
|
|
|
struct demux_cached_range *worst = NULL;
|
|
|
|
|
|
|
|
for (int n = in->num_ranges - 2; n >= 0; n--) {
|
|
|
|
struct demux_cached_range *range = in->ranges[n];
|
2017-12-10 04:07:36 +00:00
|
|
|
if (range->seek_start == MP_NOPTS_VALUE || !in->seekable_cache) {
|
2017-11-10 11:32:40 +00:00
|
|
|
clear_cached_range(in, range);
|
|
|
|
MP_TARRAY_REMOVE_AT(in->ranges, in->num_ranges, n);
|
|
|
|
} else {
|
|
|
|
if (!worst || (range->seek_end - range->seek_start <
|
|
|
|
worst->seek_end - worst->seek_start))
|
|
|
|
worst = range;
|
|
|
|
}
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
}
|
2017-11-10 11:32:40 +00:00
|
|
|
|
|
|
|
if (in->num_ranges <= MAX_SEEK_RANGES)
|
|
|
|
break;
|
|
|
|
|
|
|
|
clear_cached_range(in, worst);
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
demux: always discard cached packets on track switches
This fixes weird behavior in the following case:
- open a file
- make sure the max. demuxer forward cache is smaller than the
file's video track
- make sure the max. readahead duration is larger than the file's
duration
- disable the audio track
- seek to the beginning of the file
- once the cache has filled enable the audio track
- a queue overflow warning should appear
(- looking at the seek ranges is also interesting)
The queue overflow warning happens because the packed queue for the
video track will use up the full quota set by --demuxer-max-bytes. When
the audio track is enabled, reading an audio packet would technically
overflow the packet cache by the size of whatever packet is read next.
This means the demuxer signals EOF to the decoder, and once playback has
consumed enough video packets so that audio packets can be read again,
the decoder resumes from EOF. This interacts badly with A/V
synchronization and the whole thing can randomly crap itself until audio
has fully recovered.
We didn't care about this so far, but we want to raise the readahead
duration to something very high, so that the demuxer cache is fully
used. This means this case can be hit quite quickly by switching audio
or subtitle tracks, and is not really an obscure corner case anymore.
Fix this by always losing all cache. Since the cache can't be used
anyway until the newly selected track has been read, this is not much of
a disadvantage. The only thing that could be brought up is that
unselecting the track again could resume operation normally. (Maybe this
would be useful if network died completely without chance of recovery.
Then you could watch the already buffered video anyway by deselecting
the audio track again.) But given the headaches, this seems like the
better solution.
Unfortunately this requires adding new new strange fields and strangely
fragmenting state management functions again. I'm sure whoever works on
this in the future will hate me. Currently it seems like the lesser
evil, and much simpler and robust than the other potential solutions.
In case this needs to be revisited, here is a reminder for readers from
the future what alternative solutions were considered, without those
disadvantages:
A first attempted solution allowed the demuxer to buffer some additional
packets on track switching. This would allow it to read enough data to
feed the decoder at least. But it was still awkward, as it didn't allow
the demuxer to continue prefetching the newly selected track. It also
barely worked, because you could make the forward buffer "over full" by
seeking back with seekable cache enabled, and then it couldn't read
packets anyway.
As alternative solution, we could always demux and cache all tracks,
even if they're deselected. This would also not require a network-level
seek for the "refresh" logic (it's the thing that lets the video decoder
continue as if nothing happened, while actually seeking back in the
stream to get the missing audio packets, in the case of enabling a
previously disabled audio track). But it would also possibly waste
network and memory resources, depending on what the user actually wants.
A second solution would just account the queue sizes for each stream
separately. We could freely fill up the audio packet queue, even if the
video queue is full. Since the demuxer API returns interleaved packets
and doesn't let you predict which packet type comes next, this is not as
simple as it sounds, but it'd probably tie in nicely with the "refresh"
logic.
A third solution would be removing buffered video packets from the end
of the packet queue. Since the "refresh" logic gets these anyway, there
is no reason to keep them if they prevent the audio packet queue from
catching up with the video one. But this would require additional logic,
would interact badly with a bunch of other corner cases. And as far as
the code goes, it's rather complex, because all the logic is written
with FIFO behavior in mind (including the fact that the packet queue is
a singly linked list with no backwards links, making removal from the
end harder).
2017-12-17 20:34:50 +00:00
|
|
|
static void ds_clear_reader_queue_state(struct demux_stream *ds)
|
2013-07-11 17:20:25 +00:00
|
|
|
{
|
2017-11-04 22:39:04 +00:00
|
|
|
ds->in->fw_bytes -= ds->fw_bytes;
|
2017-10-21 17:26:33 +00:00
|
|
|
ds->reader_head = NULL;
|
demux: always discard cached packets on track switches
This fixes weird behavior in the following case:
- open a file
- make sure the max. demuxer forward cache is smaller than the
file's video track
- make sure the max. readahead duration is larger than the file's
duration
- disable the audio track
- seek to the beginning of the file
- once the cache has filled enable the audio track
- a queue overflow warning should appear
(- looking at the seek ranges is also interesting)
The queue overflow warning happens because the packed queue for the
video track will use up the full quota set by --demuxer-max-bytes. When
the audio track is enabled, reading an audio packet would technically
overflow the packet cache by the size of whatever packet is read next.
This means the demuxer signals EOF to the decoder, and once playback has
consumed enough video packets so that audio packets can be read again,
the decoder resumes from EOF. This interacts badly with A/V
synchronization and the whole thing can randomly crap itself until audio
has fully recovered.
We didn't care about this so far, but we want to raise the readahead
duration to something very high, so that the demuxer cache is fully
used. This means this case can be hit quite quickly by switching audio
or subtitle tracks, and is not really an obscure corner case anymore.
Fix this by always losing all cache. Since the cache can't be used
anyway until the newly selected track has been read, this is not much of
a disadvantage. The only thing that could be brought up is that
unselecting the track again could resume operation normally. (Maybe this
would be useful if network died completely without chance of recovery.
Then you could watch the already buffered video anyway by deselecting
the audio track again.) But given the headaches, this seems like the
better solution.
Unfortunately this requires adding new new strange fields and strangely
fragmenting state management functions again. I'm sure whoever works on
this in the future will hate me. Currently it seems like the lesser
evil, and much simpler and robust than the other potential solutions.
In case this needs to be revisited, here is a reminder for readers from
the future what alternative solutions were considered, without those
disadvantages:
A first attempted solution allowed the demuxer to buffer some additional
packets on track switching. This would allow it to read enough data to
feed the decoder at least. But it was still awkward, as it didn't allow
the demuxer to continue prefetching the newly selected track. It also
barely worked, because you could make the forward buffer "over full" by
seeking back with seekable cache enabled, and then it couldn't read
packets anyway.
As alternative solution, we could always demux and cache all tracks,
even if they're deselected. This would also not require a network-level
seek for the "refresh" logic (it's the thing that lets the video decoder
continue as if nothing happened, while actually seeking back in the
stream to get the missing audio packets, in the case of enabling a
previously disabled audio track). But it would also possibly waste
network and memory resources, depending on what the user actually wants.
A second solution would just account the queue sizes for each stream
separately. We could freely fill up the audio packet queue, even if the
video queue is full. Since the demuxer API returns interleaved packets
and doesn't let you predict which packet type comes next, this is not as
simple as it sounds, but it'd probably tie in nicely with the "refresh"
logic.
A third solution would be removing buffered video packets from the end
of the packet queue. Since the "refresh" logic gets these anyway, there
is no reason to keep them if they prevent the audio packet queue from
catching up with the video one. But this would require additional logic,
would interact badly with a bunch of other corner cases. And as far as
the code goes, it's rather complex, because all the logic is written
with FIFO behavior in mind (including the fact that the packet queue is
a singly linked list with no backwards links, making removal from the
end harder).
2017-12-17 20:34:50 +00:00
|
|
|
ds->fw_bytes = 0;
|
|
|
|
ds->fw_packs = 0;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
ds->eof = false;
|
demux: always discard cached packets on track switches
This fixes weird behavior in the following case:
- open a file
- make sure the max. demuxer forward cache is smaller than the
file's video track
- make sure the max. readahead duration is larger than the file's
duration
- disable the audio track
- seek to the beginning of the file
- once the cache has filled enable the audio track
- a queue overflow warning should appear
(- looking at the seek ranges is also interesting)
The queue overflow warning happens because the packed queue for the
video track will use up the full quota set by --demuxer-max-bytes. When
the audio track is enabled, reading an audio packet would technically
overflow the packet cache by the size of whatever packet is read next.
This means the demuxer signals EOF to the decoder, and once playback has
consumed enough video packets so that audio packets can be read again,
the decoder resumes from EOF. This interacts badly with A/V
synchronization and the whole thing can randomly crap itself until audio
has fully recovered.
We didn't care about this so far, but we want to raise the readahead
duration to something very high, so that the demuxer cache is fully
used. This means this case can be hit quite quickly by switching audio
or subtitle tracks, and is not really an obscure corner case anymore.
Fix this by always losing all cache. Since the cache can't be used
anyway until the newly selected track has been read, this is not much of
a disadvantage. The only thing that could be brought up is that
unselecting the track again could resume operation normally. (Maybe this
would be useful if network died completely without chance of recovery.
Then you could watch the already buffered video anyway by deselecting
the audio track again.) But given the headaches, this seems like the
better solution.
Unfortunately this requires adding new new strange fields and strangely
fragmenting state management functions again. I'm sure whoever works on
this in the future will hate me. Currently it seems like the lesser
evil, and much simpler and robust than the other potential solutions.
In case this needs to be revisited, here is a reminder for readers from
the future what alternative solutions were considered, without those
disadvantages:
A first attempted solution allowed the demuxer to buffer some additional
packets on track switching. This would allow it to read enough data to
feed the decoder at least. But it was still awkward, as it didn't allow
the demuxer to continue prefetching the newly selected track. It also
barely worked, because you could make the forward buffer "over full" by
seeking back with seekable cache enabled, and then it couldn't read
packets anyway.
As alternative solution, we could always demux and cache all tracks,
even if they're deselected. This would also not require a network-level
seek for the "refresh" logic (it's the thing that lets the video decoder
continue as if nothing happened, while actually seeking back in the
stream to get the missing audio packets, in the case of enabling a
previously disabled audio track). But it would also possibly waste
network and memory resources, depending on what the user actually wants.
A second solution would just account the queue sizes for each stream
separately. We could freely fill up the audio packet queue, even if the
video queue is full. Since the demuxer API returns interleaved packets
and doesn't let you predict which packet type comes next, this is not as
simple as it sounds, but it'd probably tie in nicely with the "refresh"
logic.
A third solution would be removing buffered video packets from the end
of the packet queue. Since the "refresh" logic gets these anyway, there
is no reason to keep them if they prevent the audio packet queue from
catching up with the video one. But this would require additional logic,
would interact badly with a bunch of other corner cases. And as far as
the code goes, it's rather complex, because all the logic is written
with FIFO behavior in mind (including the fact that the packet queue is
a singly linked list with no backwards links, making removal from the
end harder).
2017-12-17 20:34:50 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void ds_clear_reader_state(struct demux_stream *ds)
|
|
|
|
{
|
|
|
|
ds_clear_reader_queue_state(ds);
|
|
|
|
|
2017-10-21 17:26:33 +00:00
|
|
|
ds->base_ts = ds->last_br_ts = MP_NOPTS_VALUE;
|
|
|
|
ds->last_br_bytes = 0;
|
|
|
|
ds->bitrate = -1;
|
demux: fix cached SEEK_FORWARD seeks into end of cached regions/EOF
Although seeking past the cached range will trigger a low level seek, a
seek into the region between cache end and last video key frame would
simply seek to the video key frame. This meant that you could get
"stuck" at the end of the file instead of terminating playback when
trying to seek past the end.
One change is that we fix this by _actually_ allowing SEEK_FORWARD to
seek past the last video keyframe in find_seek_target().
In that case, or otherwise seeking to cache buffer end, it could happen
that we set ds->reader_head=NULL if the seek target is after the current
packet. We allow this, because the end of the cached region is defined
by the existence of "any" packet, not necessarily a key frame. Seeking
there still makes sense, because we know that there is going to be more
packets (or EOF) that satisfy the seek target.
The problem is that just resuming demuxing with reader_head==NULL will
simply return any packets that come its way, even non-keyframe ones.
Some decoders will produce ugly soup in this case. (In practice, this
was not a problem, because seeking at the end of the cached region was
rare before this commit, and also some decoders like h264 will skip
broken frames by default anyway.)
So the other change of this commit is to enable key frame skipping.
As a nasty implementation detail, we use a separate flag, instead of
setting reader_head to the first key frame encounted (reader_head being
NULL can happen after a normal seek or on playback start, and then we
want to mirror the underlying demuxer behavior, for better or worse).
This change is relatively untested, so you get to keep the pieces for
yourself.
2017-10-23 18:09:21 +00:00
|
|
|
ds->skip_to_keyframe = false;
|
2017-10-21 17:26:33 +00:00
|
|
|
ds->attached_picture_added = false;
|
demux: always discard cached packets on track switches
This fixes weird behavior in the following case:
- open a file
- make sure the max. demuxer forward cache is smaller than the
file's video track
- make sure the max. readahead duration is larger than the file's
duration
- disable the audio track
- seek to the beginning of the file
- once the cache has filled enable the audio track
- a queue overflow warning should appear
(- looking at the seek ranges is also interesting)
The queue overflow warning happens because the packed queue for the
video track will use up the full quota set by --demuxer-max-bytes. When
the audio track is enabled, reading an audio packet would technically
overflow the packet cache by the size of whatever packet is read next.
This means the demuxer signals EOF to the decoder, and once playback has
consumed enough video packets so that audio packets can be read again,
the decoder resumes from EOF. This interacts badly with A/V
synchronization and the whole thing can randomly crap itself until audio
has fully recovered.
We didn't care about this so far, but we want to raise the readahead
duration to something very high, so that the demuxer cache is fully
used. This means this case can be hit quite quickly by switching audio
or subtitle tracks, and is not really an obscure corner case anymore.
Fix this by always losing all cache. Since the cache can't be used
anyway until the newly selected track has been read, this is not much of
a disadvantage. The only thing that could be brought up is that
unselecting the track again could resume operation normally. (Maybe this
would be useful if network died completely without chance of recovery.
Then you could watch the already buffered video anyway by deselecting
the audio track again.) But given the headaches, this seems like the
better solution.
Unfortunately this requires adding new new strange fields and strangely
fragmenting state management functions again. I'm sure whoever works on
this in the future will hate me. Currently it seems like the lesser
evil, and much simpler and robust than the other potential solutions.
In case this needs to be revisited, here is a reminder for readers from
the future what alternative solutions were considered, without those
disadvantages:
A first attempted solution allowed the demuxer to buffer some additional
packets on track switching. This would allow it to read enough data to
feed the decoder at least. But it was still awkward, as it didn't allow
the demuxer to continue prefetching the newly selected track. It also
barely worked, because you could make the forward buffer "over full" by
seeking back with seekable cache enabled, and then it couldn't read
packets anyway.
As alternative solution, we could always demux and cache all tracks,
even if they're deselected. This would also not require a network-level
seek for the "refresh" logic (it's the thing that lets the video decoder
continue as if nothing happened, while actually seeking back in the
stream to get the missing audio packets, in the case of enabling a
previously disabled audio track). But it would also possibly waste
network and memory resources, depending on what the user actually wants.
A second solution would just account the queue sizes for each stream
separately. We could freely fill up the audio packet queue, even if the
video queue is full. Since the demuxer API returns interleaved packets
and doesn't let you predict which packet type comes next, this is not as
simple as it sounds, but it'd probably tie in nicely with the "refresh"
logic.
A third solution would be removing buffered video packets from the end
of the packet queue. Since the "refresh" logic gets these anyway, there
is no reason to keep them if they prevent the audio packet queue from
catching up with the video one. But this would require additional logic,
would interact badly with a bunch of other corner cases. And as far as
the code goes, it's rather complex, because all the logic is written
with FIFO behavior in mind (including the fact that the packet queue is
a singly linked list with no backwards links, making removal from the
end harder).
2017-12-17 20:34:50 +00:00
|
|
|
ds->last_ret_pos = -1;
|
|
|
|
ds->last_ret_dts = MP_NOPTS_VALUE;
|
2017-10-21 17:26:33 +00:00
|
|
|
}
|
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
static void update_stream_selection_state(struct demux_internal *in,
|
2017-11-10 03:08:15 +00:00
|
|
|
struct demux_stream *ds)
|
2017-10-21 17:26:33 +00:00
|
|
|
{
|
2017-11-10 03:08:15 +00:00
|
|
|
ds->eof = false;
|
|
|
|
ds->refreshing = false;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
|
2017-11-10 03:08:15 +00:00
|
|
|
ds_clear_reader_state(ds);
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
|
|
|
|
// We still have to go over the whole stream list to update ds->eager for
|
|
|
|
// other streams too, because they depend on other stream's selections.
|
2017-11-04 22:39:04 +00:00
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
bool any_av_streams = false;
|
2018-01-17 06:07:15 +00:00
|
|
|
bool any_streams = false;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
|
|
|
|
for (int n = 0; n < in->num_streams; n++) {
|
|
|
|
struct demux_stream *s = in->streams[n]->ds;
|
|
|
|
|
|
|
|
s->eager = s->selected && !s->sh->attached_picture;
|
|
|
|
if (s->eager)
|
|
|
|
any_av_streams |= s->type != STREAM_SUB;
|
2018-01-17 06:07:15 +00:00
|
|
|
any_streams |= s->selected;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Subtitles are only eagerly read if there are no other eagerly read
|
|
|
|
// streams.
|
|
|
|
if (any_av_streams) {
|
|
|
|
for (int n = 0; n < in->num_streams; n++) {
|
|
|
|
struct demux_stream *s = in->streams[n]->ds;
|
|
|
|
|
|
|
|
if (s->type == STREAM_SUB)
|
|
|
|
s->eager = false;
|
|
|
|
}
|
|
|
|
}
|
demux: fix accounting for seekable ranges on track switches
This fixes missing audio when cycling through audio tracks with anything
that uses nested demuxers, such as demux_timeline, which us used for
EDL, --merge-files, ordered chapters, and youtube-dl pseudo DASH
support. When this bug happened, reenabling an audio track would lead to
silence for the duration of the readahead amount.
The underlying reason is the incorrectly updated buffered range on track
switch. It accidentally included the amount covered by the deselected
stream. But the cause of the observed effect was that demux_timeline
issued a refresh seek to the underlying slave demuxer, which in turn
thought it could do a cache seek, because the seek range still included
everything.
update_stream_selection_state() calls update_seek_ranges() to update the
seek ranges after a track switch. When reenabling the track, ds->eager
was set to false during update_seek_ranges(), which made it think the
stream was sparse, and thus it didn't restrict the current seek range
(making later code think everything was buffered). Fix this by moving
some code, so we first update the ds->eager flag, then the seek ranges.
Also verbose log the low level stream selection calls.
2017-12-10 03:43:25 +00:00
|
|
|
|
2018-01-17 06:07:15 +00:00
|
|
|
if (!any_streams)
|
|
|
|
in->blocked = false;
|
|
|
|
|
demux: fix accounting for seekable ranges on track switches
This fixes missing audio when cycling through audio tracks with anything
that uses nested demuxers, such as demux_timeline, which us used for
EDL, --merge-files, ordered chapters, and youtube-dl pseudo DASH
support. When this bug happened, reenabling an audio track would lead to
silence for the duration of the readahead amount.
The underlying reason is the incorrectly updated buffered range on track
switch. It accidentally included the amount covered by the deselected
stream. But the cause of the observed effect was that demux_timeline
issued a refresh seek to the underlying slave demuxer, which in turn
thought it could do a cache seek, because the seek range still included
everything.
update_stream_selection_state() calls update_seek_ranges() to update the
seek ranges after a track switch. When reenabling the track, ds->eager
was set to false during update_seek_ranges(), which made it think the
stream was sparse, and thus it didn't restrict the current seek range
(making later code think everything was buffered). Fix this by moving
some code, so we first update the ds->eager flag, then the seek ranges.
Also verbose log the low level stream selection calls.
2017-12-10 03:43:25 +00:00
|
|
|
// Make sure any stream reselection or addition is reflected in the seek
|
|
|
|
// ranges, and also get rid of data that is not needed anymore (or
|
|
|
|
// rather, which can't be kept consistent). This has to happen after we've
|
|
|
|
// updated all the subtle state (like s->eager).
|
|
|
|
for (int n = 0; n < in->num_ranges; n++) {
|
|
|
|
struct demux_cached_range *range = in->ranges[n];
|
|
|
|
|
|
|
|
if (!ds->selected)
|
|
|
|
clear_queue(range->streams[ds->index]);
|
|
|
|
|
|
|
|
update_seek_ranges(range);
|
|
|
|
}
|
|
|
|
|
|
|
|
free_empty_cached_ranges(in);
|
2013-07-11 17:20:25 +00:00
|
|
|
}
|
|
|
|
|
2015-11-16 21:47:17 +00:00
|
|
|
void demux_set_ts_offset(struct demuxer *demuxer, double offset)
|
|
|
|
{
|
|
|
|
struct demux_internal *in = demuxer->in;
|
|
|
|
pthread_mutex_lock(&in->lock);
|
|
|
|
in->ts_offset = offset;
|
|
|
|
pthread_mutex_unlock(&in->lock);
|
|
|
|
}
|
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
static void add_missing_streams(struct demux_internal *in,
|
|
|
|
struct demux_cached_range *range)
|
|
|
|
{
|
|
|
|
for (int n = range->num_streams; n < in->num_streams; n++) {
|
|
|
|
struct demux_stream *ds = in->streams[n]->ds;
|
|
|
|
|
|
|
|
struct demux_queue *queue = talloc_ptrtype(range, queue);
|
|
|
|
*queue = (struct demux_queue){
|
|
|
|
.ds = ds,
|
|
|
|
.range = range,
|
|
|
|
};
|
|
|
|
clear_queue(queue);
|
|
|
|
MP_TARRAY_APPEND(range, range->streams, range->num_streams, queue);
|
|
|
|
assert(range->streams[ds->index] == queue);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
// Allocate a new sh_stream of the given type. It either has to be released
|
|
|
|
// with talloc_free(), or added to a demuxer with demux_add_sh_stream(). You
|
|
|
|
// cannot add or read packets from the stream before it has been added.
|
|
|
|
struct sh_stream *demux_alloc_sh_stream(enum stream_type type)
|
2012-08-03 10:24:55 +00:00
|
|
|
{
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
struct sh_stream *sh = talloc_ptrtype(NULL, sh);
|
2013-07-11 17:20:25 +00:00
|
|
|
*sh = (struct sh_stream) {
|
2012-08-03 10:24:55 +00:00
|
|
|
.type = type,
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
.index = -1,
|
|
|
|
.ff_index = -1, // may be overwritten by demuxer
|
|
|
|
.demuxer_id = -1, // ... same
|
2016-01-12 22:48:19 +00:00
|
|
|
.codec = talloc_zero(sh, struct mp_codec_params),
|
2016-08-12 19:39:32 +00:00
|
|
|
.tags = talloc_zero(sh, struct mp_tags),
|
2014-07-16 20:40:21 +00:00
|
|
|
};
|
2016-01-12 22:48:19 +00:00
|
|
|
sh->codec->type = type;
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
return sh;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Add a new sh_stream to the demuxer. Note that as soon as the stream has been
|
|
|
|
// added, it must be immutable, and must not be released (this will happen when
|
|
|
|
// the demuxer is destroyed).
|
2017-11-03 12:55:32 +00:00
|
|
|
static void demux_add_sh_stream_locked(struct demux_internal *in,
|
|
|
|
struct sh_stream *sh)
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
{
|
|
|
|
assert(!sh->ds); // must not be added yet
|
|
|
|
|
2017-11-04 22:39:04 +00:00
|
|
|
sh->index = in->num_streams;
|
|
|
|
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
sh->ds = talloc(sh, struct demux_stream);
|
2014-07-16 20:40:21 +00:00
|
|
|
*sh->ds = (struct demux_stream) {
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
.in = in,
|
2017-10-21 18:35:03 +00:00
|
|
|
.sh = sh,
|
2014-07-16 20:40:21 +00:00
|
|
|
.type = sh->type,
|
2017-11-04 22:39:04 +00:00
|
|
|
.index = sh->index,
|
2017-11-10 03:08:15 +00:00
|
|
|
.selected = in->autoselect,
|
2017-11-04 22:39:04 +00:00
|
|
|
.global_correct_dts = true,
|
|
|
|
.global_correct_pos = true,
|
2013-07-11 17:20:25 +00:00
|
|
|
};
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
|
2016-01-12 22:48:19 +00:00
|
|
|
if (!sh->codec->codec)
|
|
|
|
sh->codec->codec = "";
|
|
|
|
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
if (sh->ff_index < 0)
|
|
|
|
sh->ff_index = sh->index;
|
|
|
|
if (sh->demuxer_id < 0) {
|
|
|
|
sh->demuxer_id = 0;
|
|
|
|
for (int n = 0; n < in->num_streams; n++) {
|
|
|
|
if (in->streams[n]->type == sh->type)
|
|
|
|
sh->demuxer_id += 1;
|
|
|
|
}
|
2012-08-03 10:24:55 +00:00
|
|
|
}
|
2013-07-11 17:22:24 +00:00
|
|
|
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
MP_TARRAY_APPEND(in, in->streams, in->num_streams, sh);
|
2017-11-04 22:39:04 +00:00
|
|
|
assert(in->streams[sh->index] == sh);
|
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
for (int n = 0; n < in->num_ranges; n++)
|
|
|
|
add_missing_streams(in, in->ranges[n]);
|
2017-11-04 22:39:04 +00:00
|
|
|
|
|
|
|
sh->ds->queue = in->current_range->streams[sh->ds->index];
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
|
2017-11-10 03:08:15 +00:00
|
|
|
update_stream_selection_state(in, sh->ds);
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
in->events |= DEMUX_EVENT_STREAMS;
|
|
|
|
if (in->wakeup_cb)
|
|
|
|
in->wakeup_cb(in->wakeup_cb_ctx);
|
2017-11-03 12:55:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// For demuxer implementations only.
|
|
|
|
void demux_add_sh_stream(struct demuxer *demuxer, struct sh_stream *sh)
|
|
|
|
{
|
|
|
|
struct demux_internal *in = demuxer->in;
|
|
|
|
pthread_mutex_lock(&in->lock);
|
|
|
|
demux_add_sh_stream_locked(in, sh);
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
pthread_mutex_unlock(&in->lock);
|
|
|
|
}
|
|
|
|
|
2016-08-12 19:39:32 +00:00
|
|
|
// Update sh->tags (lazily). This must be called by demuxers which update
|
|
|
|
// stream tags after init. (sh->tags can be accessed by the playback thread,
|
|
|
|
// which means the demuxer thread cannot write or read it directly.)
|
|
|
|
// Before init is finished, sh->tags can still be accessed freely.
|
|
|
|
// Ownership of tags goes to the function.
|
|
|
|
void demux_set_stream_tags(struct demuxer *demuxer, struct sh_stream *sh,
|
|
|
|
struct mp_tags *tags)
|
|
|
|
{
|
|
|
|
struct demux_internal *in = demuxer->in;
|
|
|
|
assert(demuxer == in->d_thread);
|
|
|
|
|
|
|
|
if (sh->ds) {
|
|
|
|
while (demuxer->num_update_stream_tags <= sh->index) {
|
|
|
|
MP_TARRAY_APPEND(demuxer, demuxer->update_stream_tags,
|
|
|
|
demuxer->num_update_stream_tags, NULL);
|
|
|
|
}
|
|
|
|
talloc_free(demuxer->update_stream_tags[sh->index]);
|
|
|
|
demuxer->update_stream_tags[sh->index] = talloc_steal(demuxer, tags);
|
|
|
|
|
|
|
|
demux_changed(demuxer, DEMUX_EVENT_METADATA);
|
|
|
|
} else {
|
|
|
|
// not added yet
|
|
|
|
talloc_free(sh->tags);
|
|
|
|
sh->tags = talloc_steal(sh, tags);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
// Return a stream with the given index. Since streams can only be added during
|
|
|
|
// the lifetime of the demuxer, it is guaranteed that an index within the valid
|
|
|
|
// range [0, demux_get_num_stream()) always returns a valid sh_stream pointer,
|
|
|
|
// which will be valid until the demuxer is destroyed.
|
|
|
|
struct sh_stream *demux_get_stream(struct demuxer *demuxer, int index)
|
|
|
|
{
|
|
|
|
struct demux_internal *in = demuxer->in;
|
|
|
|
pthread_mutex_lock(&in->lock);
|
|
|
|
assert(index >= 0 && index < in->num_streams);
|
|
|
|
struct sh_stream *r = in->streams[index];
|
|
|
|
pthread_mutex_unlock(&in->lock);
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
// See demux_get_stream().
|
|
|
|
int demux_get_num_stream(struct demuxer *demuxer)
|
|
|
|
{
|
|
|
|
struct demux_internal *in = demuxer->in;
|
|
|
|
pthread_mutex_lock(&in->lock);
|
|
|
|
int r = in->num_streams;
|
|
|
|
pthread_mutex_unlock(&in->lock);
|
|
|
|
return r;
|
2012-08-03 10:24:55 +00:00
|
|
|
}
|
|
|
|
|
2008-04-12 15:51:08 +00:00
|
|
|
void free_demuxer(demuxer_t *demuxer)
|
|
|
|
{
|
2013-08-25 18:40:21 +00:00
|
|
|
if (!demuxer)
|
|
|
|
return;
|
2014-07-16 20:40:21 +00:00
|
|
|
struct demux_internal *in = demuxer->in;
|
|
|
|
assert(demuxer == in->d_user);
|
|
|
|
|
|
|
|
demux_stop_thread(demuxer);
|
|
|
|
|
2008-04-12 15:51:08 +00:00
|
|
|
if (demuxer->desc->close)
|
2014-07-16 20:40:21 +00:00
|
|
|
demuxer->desc->close(in->d_thread);
|
2017-10-21 17:26:33 +00:00
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
demux_flush(demuxer);
|
|
|
|
assert(in->total_bytes == 0);
|
2017-10-21 17:26:33 +00:00
|
|
|
|
2017-11-10 02:26:40 +00:00
|
|
|
for (int n = 0; n < in->num_streams; n++)
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
talloc_free(in->streams[n]);
|
2014-07-16 20:40:21 +00:00
|
|
|
pthread_mutex_destroy(&in->lock);
|
|
|
|
pthread_cond_destroy(&in->wakeup);
|
2009-03-16 03:11:22 +00:00
|
|
|
talloc_free(demuxer);
|
2001-08-22 23:54:57 +00:00
|
|
|
}
|
|
|
|
|
2015-02-20 20:08:10 +00:00
|
|
|
void free_demuxer_and_stream(struct demuxer *demuxer)
|
|
|
|
{
|
|
|
|
if (!demuxer)
|
|
|
|
return;
|
|
|
|
struct stream *s = demuxer->stream;
|
|
|
|
free_demuxer(demuxer);
|
|
|
|
free_stream(s);
|
|
|
|
}
|
|
|
|
|
2014-07-16 20:40:21 +00:00
|
|
|
// Start the demuxer thread, which reads ahead packets on its own.
|
|
|
|
void demux_start_thread(struct demuxer *demuxer)
|
2008-04-12 15:51:08 +00:00
|
|
|
{
|
2014-07-16 20:40:21 +00:00
|
|
|
struct demux_internal *in = demuxer->in;
|
|
|
|
assert(demuxer == in->d_user);
|
|
|
|
|
|
|
|
if (!in->threading) {
|
|
|
|
in->threading = true;
|
|
|
|
if (pthread_create(&in->thread, NULL, demux_thread, in))
|
|
|
|
in->threading = false;
|
2001-02-24 20:28:24 +00:00
|
|
|
}
|
2013-07-11 17:20:25 +00:00
|
|
|
}
|
|
|
|
|
2014-07-16 20:40:21 +00:00
|
|
|
void demux_stop_thread(struct demuxer *demuxer)
|
2013-07-11 17:20:25 +00:00
|
|
|
{
|
2014-07-16 20:40:21 +00:00
|
|
|
struct demux_internal *in = demuxer->in;
|
|
|
|
assert(demuxer == in->d_user);
|
|
|
|
|
|
|
|
if (in->threading) {
|
|
|
|
pthread_mutex_lock(&in->lock);
|
|
|
|
in->thread_terminate = true;
|
|
|
|
pthread_cond_signal(&in->wakeup);
|
|
|
|
pthread_mutex_unlock(&in->lock);
|
|
|
|
pthread_join(in->thread, NULL);
|
|
|
|
in->threading = false;
|
|
|
|
in->thread_terminate = false;
|
|
|
|
}
|
2013-07-11 17:20:25 +00:00
|
|
|
}
|
|
|
|
|
2014-07-16 20:40:21 +00:00
|
|
|
// The demuxer thread will call cb(ctx) if there's a new packet, or EOF is reached.
|
|
|
|
void demux_set_wakeup_cb(struct demuxer *demuxer, void (*cb)(void *ctx), void *ctx)
|
2013-07-11 17:20:25 +00:00
|
|
|
{
|
2014-07-16 20:40:21 +00:00
|
|
|
struct demux_internal *in = demuxer->in;
|
|
|
|
pthread_mutex_lock(&in->lock);
|
|
|
|
in->wakeup_cb = cb;
|
|
|
|
in->wakeup_cb_ctx = ctx;
|
|
|
|
pthread_mutex_unlock(&in->lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *stream_type_name(enum stream_type type)
|
|
|
|
{
|
|
|
|
switch (type) {
|
|
|
|
case STREAM_VIDEO: return "video";
|
|
|
|
case STREAM_AUDIO: return "audio";
|
|
|
|
case STREAM_SUB: return "sub";
|
|
|
|
default: return "unknown";
|
|
|
|
}
|
2001-02-24 20:28:24 +00:00
|
|
|
}
|
|
|
|
|
2017-11-03 12:55:32 +00:00
|
|
|
static struct sh_stream *demuxer_get_cc_track_locked(struct sh_stream *stream)
|
2015-12-22 01:35:15 +00:00
|
|
|
{
|
|
|
|
struct sh_stream *sh = stream->ds->cc;
|
|
|
|
|
|
|
|
if (!sh) {
|
|
|
|
sh = demux_alloc_sh_stream(STREAM_SUB);
|
2017-11-03 12:55:32 +00:00
|
|
|
if (!sh)
|
|
|
|
return NULL;
|
2015-12-22 01:35:15 +00:00
|
|
|
sh->codec->codec = "eia_608";
|
2017-11-03 12:55:32 +00:00
|
|
|
sh->default_track = true;
|
2015-12-22 01:35:15 +00:00
|
|
|
stream->ds->cc = sh;
|
2017-11-03 12:55:32 +00:00
|
|
|
demux_add_sh_stream_locked(stream->ds->in, sh);
|
|
|
|
sh->ds->ignore_eof = true;
|
2015-12-22 01:35:15 +00:00
|
|
|
}
|
|
|
|
|
2017-11-03 12:55:32 +00:00
|
|
|
return sh;
|
|
|
|
}
|
|
|
|
|
|
|
|
void demuxer_feed_caption(struct sh_stream *stream, demux_packet_t *dp)
|
|
|
|
{
|
|
|
|
struct demux_internal *in = stream->ds->in;
|
2017-10-20 20:30:59 +00:00
|
|
|
|
2017-11-03 12:55:32 +00:00
|
|
|
pthread_mutex_lock(&in->lock);
|
|
|
|
struct sh_stream *sh = demuxer_get_cc_track_locked(stream);
|
|
|
|
if (!sh) {
|
|
|
|
pthread_mutex_unlock(&in->lock);
|
|
|
|
talloc_free(dp);
|
|
|
|
return;
|
|
|
|
}
|
2017-10-20 20:30:59 +00:00
|
|
|
|
|
|
|
dp->pts = MP_ADD_PTS(dp->pts, -in->ts_offset);
|
|
|
|
dp->dts = MP_ADD_PTS(dp->dts, -in->ts_offset);
|
|
|
|
pthread_mutex_unlock(&in->lock);
|
|
|
|
|
2016-01-19 13:19:50 +00:00
|
|
|
demux_add_packet(sh, dp);
|
2015-12-22 01:35:15 +00:00
|
|
|
}
|
|
|
|
|
2017-11-10 11:17:34 +00:00
|
|
|
// Add the keyframe to the end of the index. Not all packets are actually added.
|
|
|
|
static void add_index_entry(struct demux_queue *queue, struct demux_packet *dp)
|
|
|
|
{
|
|
|
|
assert(dp->keyframe && dp->kf_seek_pts != MP_NOPTS_VALUE);
|
|
|
|
|
|
|
|
if (queue->num_index) {
|
|
|
|
double prev = queue->index[queue->num_index - 1]->kf_seek_pts;
|
|
|
|
if (dp->kf_seek_pts < prev + queue->index_distance)
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (queue->num_index == MAX_INDEX_ENTRIES) {
|
|
|
|
for (int n = 0; n < MAX_INDEX_ENTRIES / 2; n++)
|
|
|
|
queue->index[n] = queue->index[n * 2];
|
|
|
|
queue->num_index = MAX_INDEX_ENTRIES / 2;
|
|
|
|
queue->index_distance *= 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
queue->index[queue->num_index++] = dp;
|
|
|
|
}
|
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
// Check whether the next range in the list is, and if it appears to overlap,
|
|
|
|
// try joining it into a single range.
|
|
|
|
static void attempt_range_joining(struct demux_internal *in)
|
|
|
|
{
|
|
|
|
struct demux_cached_range *next = NULL;
|
|
|
|
double next_dist = INFINITY;
|
|
|
|
|
|
|
|
assert(in->current_range && in->num_ranges > 0);
|
|
|
|
assert(in->current_range == in->ranges[in->num_ranges - 1]);
|
|
|
|
|
|
|
|
for (int n = 0; n < in->num_ranges - 1; n++) {
|
|
|
|
struct demux_cached_range *range = in->ranges[n];
|
|
|
|
|
|
|
|
if (in->current_range->seek_start <= range->seek_start) {
|
|
|
|
// This uses ">" to get some non-0 overlap.
|
|
|
|
double dist = in->current_range->seek_end - range->seek_start;
|
|
|
|
if (dist > 0 && dist < next_dist) {
|
|
|
|
next = range;
|
|
|
|
next_dist = dist;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!next)
|
|
|
|
return;
|
|
|
|
|
|
|
|
MP_VERBOSE(in, "going to join ranges %f-%f + %f-%f\n",
|
|
|
|
in->current_range->seek_start, in->current_range->seek_end,
|
|
|
|
next->seek_start, next->seek_end);
|
|
|
|
|
|
|
|
// Try to find a join point, where packets obviously overlap. (It would be
|
|
|
|
// better and faster to do this incrementally, but probably too complex.)
|
|
|
|
// The current range can overlap arbitrarily with the next one, not only by
|
|
|
|
// by the seek overlap, but for arbitrary packet readahead as well.
|
|
|
|
// We also drop the overlapping packets (if joining fails, we discard the
|
|
|
|
// entire next range anyway, so this does no harm).
|
|
|
|
for (int n = 0; n < in->num_streams; n++) {
|
|
|
|
struct demux_stream *ds = in->streams[n]->ds;
|
|
|
|
|
|
|
|
struct demux_queue *q1 = in->current_range->streams[n];
|
|
|
|
struct demux_queue *q2 = next->streams[n];
|
|
|
|
|
|
|
|
if (!ds->global_correct_pos && !ds->global_correct_dts) {
|
|
|
|
MP_WARN(in, "stream %d: ranges unjoinable\n", n);
|
|
|
|
goto failed;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct demux_packet *end = q1->tail;
|
|
|
|
bool join_point_found = !end; // no packets yet -> joining will work
|
|
|
|
if (end) {
|
|
|
|
while (q2->head) {
|
|
|
|
struct demux_packet *dp = q2->head;
|
|
|
|
|
|
|
|
// Some weird corner-case. We'd have to search the equivalent
|
|
|
|
// packet in q1 to update it correctly. Better just give up.
|
|
|
|
if (dp == q2->keyframe_latest) {
|
2018-01-06 15:04:23 +00:00
|
|
|
MP_VERBOSE(in, "stream %d: not enough keyframes for join\n", n);
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
goto failed;
|
|
|
|
}
|
|
|
|
|
2017-11-10 10:06:07 +00:00
|
|
|
if ((ds->global_correct_dts && dp->dts == end->dts) ||
|
|
|
|
(ds->global_correct_pos && dp->pos == end->pos))
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
{
|
|
|
|
// Do some additional checks as a (imperfect) sanity check
|
|
|
|
// in case pos/dts are not "correct" across the ranges (we
|
|
|
|
// never actually check that).
|
|
|
|
if (dp->dts != end->dts || dp->pos != end->pos ||
|
|
|
|
dp->pts != end->pts || dp->len != end->len)
|
|
|
|
{
|
|
|
|
MP_WARN(in, "stream %d: weird demuxer behavior\n", n);
|
|
|
|
goto failed;
|
|
|
|
}
|
|
|
|
|
2018-01-09 20:37:14 +00:00
|
|
|
// q1 usually meets q2 at a keyframe. q1 will end on a key-
|
|
|
|
// frame (because it tries joining when reading a keyframe).
|
|
|
|
// Obviously, q1 can not know the kf_seek_pts yet; it would
|
|
|
|
// have to read packets after it to compute it. Ideally,
|
|
|
|
// we'd remove it and use q2's packet, but the linked list
|
|
|
|
// makes this hard, so copy this missing metadata instead.
|
|
|
|
end->kf_seek_pts = dp->kf_seek_pts;
|
|
|
|
|
2017-11-10 10:35:19 +00:00
|
|
|
remove_head_packet(q2);
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
join_point_found = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2017-11-10 10:06:07 +00:00
|
|
|
// This happens if the next range misses the end packet. For
|
|
|
|
// normal streams (ds->eager==true), this is a failure to find
|
|
|
|
// an overlap. For subtitles, this can mean the current_range
|
|
|
|
// has a subtitle somewhere before the end of its range, and
|
|
|
|
// next has another subtitle somewhere after the start of its
|
|
|
|
// range.
|
|
|
|
if ((ds->global_correct_dts && dp->dts > end->dts) ||
|
|
|
|
(ds->global_correct_pos && dp->pos > end->pos))
|
|
|
|
break;
|
|
|
|
|
2017-11-10 10:35:19 +00:00
|
|
|
remove_head_packet(q2);
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// For enabled non-sparse streams, always require an overlap packet.
|
|
|
|
if (ds->eager && !join_point_found) {
|
|
|
|
MP_WARN(in, "stream %d: no joint point found\n", n);
|
|
|
|
goto failed;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Actually join the ranges. Now that we think it will work, mutate the
|
2017-11-10 09:46:54 +00:00
|
|
|
// data associated with the current range.
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
|
|
|
|
in->fw_bytes = 0;
|
|
|
|
|
|
|
|
for (int n = 0; n < in->num_streams; n++) {
|
|
|
|
struct demux_queue *q1 = in->current_range->streams[n];
|
|
|
|
struct demux_queue *q2 = next->streams[n];
|
|
|
|
|
|
|
|
struct demux_stream *ds = in->streams[n]->ds;
|
|
|
|
|
2017-11-10 09:46:54 +00:00
|
|
|
if (q2->head) {
|
|
|
|
if (q1->head) {
|
|
|
|
q1->tail->next = q2->head;
|
|
|
|
} else {
|
|
|
|
q1->head = q2->head;
|
|
|
|
}
|
|
|
|
q1->tail = q2->tail;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
}
|
|
|
|
|
2017-11-10 09:46:54 +00:00
|
|
|
q1->seek_end = q2->seek_end;
|
|
|
|
q1->correct_dts &= q2->correct_dts;
|
|
|
|
q1->correct_pos &= q2->correct_pos;
|
|
|
|
q1->last_pos = q2->last_pos;
|
|
|
|
q1->last_dts = q2->last_dts;
|
|
|
|
q1->last_ts = q2->last_ts;
|
|
|
|
q1->keyframe_pts = q2->keyframe_pts;
|
|
|
|
q1->keyframe_end_pts = q2->keyframe_end_pts;
|
|
|
|
q1->keyframe_latest = q2->keyframe_latest;
|
demux: include EOF state in cached seekable range
This means if the user tries to seek past EOF, and we know EOF was seen
already, then use a cached seek, instead of triggering a low level seek.
This requires some annoying tracking, but seems pretty simple otherwise.
One advantage of doing this is that if the user tries to do this kind of
seek, there's no unnecessary waiting for a reaction by network (and in
most cases, redundant downloading of data just to discard it again).
Another is that this avoids creating overlapping seek ranges: previously, the
low level seek would naturally create a new range. Then it would read and add
data from the end of the stream due to the low level demuxer not being able to
seek to the target and selecting the last seek point before the end of the
stream. Consequently, this new range would overlap with the previous cached
range. But since the cache joining code is written such that you join the
current range with the _next_ range (instead of the previous as it would be
needed in this case), the overlapping ranges were left alone, until seeking back
to the previous range. That was ugly, sort of harmless, and could happen in
other cases, but this avoidable case was pretty easy to trigger.
2018-01-05 16:38:09 +00:00
|
|
|
q1->is_eof = q2->is_eof;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
|
2017-11-10 09:46:54 +00:00
|
|
|
q2->head = q2->tail = NULL;
|
|
|
|
q2->next_prune_target = NULL;
|
|
|
|
q2->keyframe_latest = NULL;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
|
2017-11-10 11:17:34 +00:00
|
|
|
for (int i = 0; i < q2->num_index; i++)
|
|
|
|
add_index_entry(q1, q2->index[i]);
|
|
|
|
q2->num_index = 0;
|
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
recompute_buffers(ds);
|
|
|
|
in->fw_bytes += ds->fw_bytes;
|
|
|
|
|
|
|
|
// For moving demuxer position.
|
2017-11-10 02:18:45 +00:00
|
|
|
ds->refreshing = ds->selected;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
}
|
|
|
|
|
2017-11-10 09:46:54 +00:00
|
|
|
update_seek_ranges(in->current_range);
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
|
|
|
|
// Move demuxing position to after the current range.
|
|
|
|
in->seeking = true;
|
|
|
|
in->seek_flags = SEEK_HR;
|
|
|
|
in->seek_pts = next->seek_end - 1.0;
|
|
|
|
|
|
|
|
MP_VERBOSE(in, "ranges joined!\n");
|
|
|
|
|
|
|
|
failed:
|
2017-11-10 09:46:54 +00:00
|
|
|
clear_cached_range(in, next);
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
free_empty_cached_ranges(in);
|
|
|
|
}
|
|
|
|
|
2017-11-04 22:02:25 +00:00
|
|
|
// Determine seekable range when a packet is added. If dp==NULL, treat it as
|
|
|
|
// EOF (i.e. closes the current block).
|
|
|
|
// This has to deal with a number of corner cases, such as demuxers potentially
|
|
|
|
// starting output at non-keyframes.
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
// Can join seek ranges, which messes with in->current_range and all.
|
2017-11-04 22:02:25 +00:00
|
|
|
static void adjust_seek_range_on_packet(struct demux_stream *ds,
|
|
|
|
struct demux_packet *dp)
|
|
|
|
{
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
struct demux_queue *queue = ds->queue;
|
|
|
|
bool attempt_range_join = false;
|
|
|
|
|
2017-11-04 22:02:25 +00:00
|
|
|
if (!ds->in->seekable_cache)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!dp || dp->keyframe) {
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
if (queue->keyframe_latest) {
|
|
|
|
queue->keyframe_latest->kf_seek_pts = queue->keyframe_pts;
|
|
|
|
double old_end = queue->range->seek_end;
|
|
|
|
if (queue->seek_start == MP_NOPTS_VALUE)
|
|
|
|
queue->seek_start = queue->keyframe_pts;
|
|
|
|
if (queue->keyframe_end_pts != MP_NOPTS_VALUE)
|
|
|
|
queue->seek_end = queue->keyframe_end_pts;
|
demux: include EOF state in cached seekable range
This means if the user tries to seek past EOF, and we know EOF was seen
already, then use a cached seek, instead of triggering a low level seek.
This requires some annoying tracking, but seems pretty simple otherwise.
One advantage of doing this is that if the user tries to do this kind of
seek, there's no unnecessary waiting for a reaction by network (and in
most cases, redundant downloading of data just to discard it again).
Another is that this avoids creating overlapping seek ranges: previously, the
low level seek would naturally create a new range. Then it would read and add
data from the end of the stream due to the low level demuxer not being able to
seek to the target and selecting the last seek point before the end of the
stream. Consequently, this new range would overlap with the previous cached
range. But since the cache joining code is written such that you join the
current range with the _next_ range (instead of the previous as it would be
needed in this case), the overlapping ranges were left alone, until seeking back
to the previous range. That was ugly, sort of harmless, and could happen in
other cases, but this avoidable case was pretty easy to trigger.
2018-01-05 16:38:09 +00:00
|
|
|
queue->is_eof = !dp;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
update_seek_ranges(queue->range);
|
|
|
|
attempt_range_join = queue->range->seek_end > old_end;
|
2017-11-10 11:17:34 +00:00
|
|
|
if (queue->keyframe_latest->kf_seek_pts != MP_NOPTS_VALUE)
|
|
|
|
add_index_entry(queue, queue->keyframe_latest);
|
2017-11-04 22:02:25 +00:00
|
|
|
}
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
queue->keyframe_latest = dp;
|
|
|
|
queue->keyframe_pts = queue->keyframe_end_pts = MP_NOPTS_VALUE;
|
2017-11-04 22:02:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (dp) {
|
|
|
|
dp->kf_seek_pts = MP_NOPTS_VALUE;
|
|
|
|
|
2017-11-10 03:35:55 +00:00
|
|
|
double ts = PTS_OR_DEF(dp->pts, dp->dts);
|
2017-11-04 17:18:42 +00:00
|
|
|
if (dp->segmented && (ts < dp->start || ts > dp->end))
|
|
|
|
ts = MP_NOPTS_VALUE;
|
2017-11-04 22:02:25 +00:00
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
queue->keyframe_pts = MP_PTS_MIN(queue->keyframe_pts, ts);
|
|
|
|
queue->keyframe_end_pts = MP_PTS_MAX(queue->keyframe_end_pts, ts);
|
demux: include EOF state in cached seekable range
This means if the user tries to seek past EOF, and we know EOF was seen
already, then use a cached seek, instead of triggering a low level seek.
This requires some annoying tracking, but seems pretty simple otherwise.
One advantage of doing this is that if the user tries to do this kind of
seek, there's no unnecessary waiting for a reaction by network (and in
most cases, redundant downloading of data just to discard it again).
Another is that this avoids creating overlapping seek ranges: previously, the
low level seek would naturally create a new range. Then it would read and add
data from the end of the stream due to the low level demuxer not being able to
seek to the target and selecting the last seek point before the end of the
stream. Consequently, this new range would overlap with the previous cached
range. But since the cache joining code is written such that you join the
current range with the _next_ range (instead of the previous as it would be
needed in this case), the overlapping ranges were left alone, until seeking back
to the previous range. That was ugly, sort of harmless, and could happen in
other cases, but this avoidable case was pretty easy to trigger.
2018-01-05 16:38:09 +00:00
|
|
|
|
|
|
|
if (queue->is_eof) {
|
|
|
|
queue->is_eof = false;
|
|
|
|
update_seek_ranges(queue->range);
|
|
|
|
}
|
2017-10-21 17:26:33 +00:00
|
|
|
}
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
|
|
|
|
if (attempt_range_join)
|
|
|
|
attempt_range_joining(ds->in);
|
2017-10-21 17:26:33 +00:00
|
|
|
}
|
|
|
|
|
2015-10-17 12:27:55 +00:00
|
|
|
void demux_add_packet(struct sh_stream *stream, demux_packet_t *dp)
|
2013-07-11 17:17:51 +00:00
|
|
|
{
|
2013-07-11 17:20:25 +00:00
|
|
|
struct demux_stream *ds = stream ? stream->ds : NULL;
|
2017-11-06 16:13:42 +00:00
|
|
|
if (!dp || !dp->len || !ds) {
|
2014-07-16 20:40:21 +00:00
|
|
|
talloc_free(dp);
|
2015-10-17 12:27:55 +00:00
|
|
|
return;
|
2014-07-16 20:40:21 +00:00
|
|
|
}
|
|
|
|
struct demux_internal *in = ds->in;
|
|
|
|
pthread_mutex_lock(&in->lock);
|
demux: hack for instant stream switching
This removes the delay when switching audio tracks in mkv or mp4 files.
Other formats are not enabled, because it's not clear whether the
demuxers fulfill the requirements listed in demux.h. (Many formats
definitely do not with libavformat.)
Background:
The demuxer packet cache buffers a certain amount of packets. This
includes only packets from selected streams. We discard packets from
other streams for various reasons. This introduces a problem: switching
to a different audio track introduces a delay. The delay is as big as
the demuxer packet cache buffer, because while the file was read ahead
to fill the packet buffer, the process of reading packets also discarded
all packets from the previously not selected audio stream. Once the
remaining packet buffer has been played, new audio packets are available
and you hear audio again.
We could probably just not discard packets from unselected streams. But
this would require additional memory and CPU resources, and also it's
hard to tell when packets from unused streams should be discarded (we
don't want to keep them forever; it'd be a memory leak).
We could also issue a player hr-seek to the current playback position,
which would solve the problem in 1 line of code or so. But this can be
rather slow.
So what we do in this commit instead is: we just seek back to the
position where our current packet buffer starts, and start demuxing from
this position again. This way we can get the "past" packets for the
newly selected stream. For streams which were already selected the
packets are simply discarded until the previous position is reached
again.
That latter part is the hard part. We really want to skip packets
exactly until the position where we left off previously, or we will skip
packets or feed packets to the decoder twice. If we assume that the
demuxer is deterministic (returns exactly the same packets after a seek
to a previous position), then we can try to check whether it's the same
packet as the one at the end of the packet buffer. If it is, we know
that the packet after it is where we left off last time.
Unfortunately, this is not very robust, and maybe it can't be made
robust. Currently we use the demux_packet.pos field as unique packet
ID - which works fine in some scenarios, but will break in arbitrary
ways if the basic requirement to the demuxer (as listed in the demux.h
additions) are broken. Thus, this is enabled only for the internal mkv
demuxer and the libavformat mp4 demuxer.
(libavformat mkv does not work, because the packet positions are not
unique. Probably could be fixed upstream, but it's not clear whether
it's a bug or a feature.)
2015-02-13 20:17:17 +00:00
|
|
|
|
2018-01-09 21:02:25 +00:00
|
|
|
in->initial_state = false;
|
|
|
|
|
2018-01-05 15:41:16 +00:00
|
|
|
double ts = dp->dts == MP_NOPTS_VALUE ? dp->pts : dp->dts;
|
|
|
|
if (dp->segmented)
|
|
|
|
ts = MP_PTS_MIN(ts, dp->end);
|
|
|
|
|
|
|
|
if (ts != MP_NOPTS_VALUE)
|
|
|
|
in->demux_ts = ts;
|
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
struct demux_queue *queue = ds->queue;
|
|
|
|
|
2018-01-09 20:41:51 +00:00
|
|
|
bool drop = !ds->selected || in->seeking || ds->sh->attached_picture;
|
2017-11-10 09:23:49 +00:00
|
|
|
if (!drop && ds->refreshing) {
|
demux: hack for instant stream switching
This removes the delay when switching audio tracks in mkv or mp4 files.
Other formats are not enabled, because it's not clear whether the
demuxers fulfill the requirements listed in demux.h. (Many formats
definitely do not with libavformat.)
Background:
The demuxer packet cache buffers a certain amount of packets. This
includes only packets from selected streams. We discard packets from
other streams for various reasons. This introduces a problem: switching
to a different audio track introduces a delay. The delay is as big as
the demuxer packet cache buffer, because while the file was read ahead
to fill the packet buffer, the process of reading packets also discarded
all packets from the previously not selected audio stream. Once the
remaining packet buffer has been played, new audio packets are available
and you hear audio again.
We could probably just not discard packets from unselected streams. But
this would require additional memory and CPU resources, and also it's
hard to tell when packets from unused streams should be discarded (we
don't want to keep them forever; it'd be a memory leak).
We could also issue a player hr-seek to the current playback position,
which would solve the problem in 1 line of code or so. But this can be
rather slow.
So what we do in this commit instead is: we just seek back to the
position where our current packet buffer starts, and start demuxing from
this position again. This way we can get the "past" packets for the
newly selected stream. For streams which were already selected the
packets are simply discarded until the previous position is reached
again.
That latter part is the hard part. We really want to skip packets
exactly until the position where we left off previously, or we will skip
packets or feed packets to the decoder twice. If we assume that the
demuxer is deterministic (returns exactly the same packets after a seek
to a previous position), then we can try to check whether it's the same
packet as the one at the end of the packet buffer. If it is, we know
that the packet after it is where we left off last time.
Unfortunately, this is not very robust, and maybe it can't be made
robust. Currently we use the demux_packet.pos field as unique packet
ID - which works fine in some scenarios, but will break in arbitrary
ways if the basic requirement to the demuxer (as listed in the demux.h
additions) are broken. Thus, this is enabled only for the internal mkv
demuxer and the libavformat mp4 demuxer.
(libavformat mkv does not work, because the packet positions are not
unique. Probably could be fixed upstream, but it's not clear whether
it's a bug or a feature.)
2015-02-13 20:17:17 +00:00
|
|
|
// Resume reading once the old position was reached (i.e. we start
|
|
|
|
// returning packets where we left off before the refresh).
|
demux: make refresh seek handling more generic
Remove the explicit whitelisting of formats for refresh seeks. Instead,
check whether the packet position is somewhat reliable during demuxing.
If there are packets without position, or the packet position is not
monotonically increasing, then do not use them for refresh seeks.
This does not make sure of some requirements, such as deterministic
seeks. If that happens, mpv will mess up a bit on stream switching.
Also, add another method that uses DTS to identify packets, and prefer
it to the packet position method. Even if there's a demuxer which
randomizes packet positions, it hardly can do that with DTS. The DTS
method is not always available either, though. Some formats do not have
a DTS, and others are not always strictly monotonic (possibly due to
libavformat codec parsing and timestamp determination issues).
2016-08-06 17:24:25 +00:00
|
|
|
// If it's the same position, drop, but continue normally next time.
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
if (queue->correct_dts) {
|
|
|
|
ds->refreshing = dp->dts < queue->last_dts;
|
|
|
|
} else if (queue->correct_pos) {
|
|
|
|
ds->refreshing = dp->pos < queue->last_pos;
|
demux: make refresh seek handling more generic
Remove the explicit whitelisting of formats for refresh seeks. Instead,
check whether the packet position is somewhat reliable during demuxing.
If there are packets without position, or the packet position is not
monotonically increasing, then do not use them for refresh seeks.
This does not make sure of some requirements, such as deterministic
seeks. If that happens, mpv will mess up a bit on stream switching.
Also, add another method that uses DTS to identify packets, and prefer
it to the packet position method. Even if there's a demuxer which
randomizes packet positions, it hardly can do that with DTS. The DTS
method is not always available either, though. Some formats do not have
a DTS, and others are not always strictly monotonic (possibly due to
libavformat codec parsing and timestamp determination issues).
2016-08-06 17:24:25 +00:00
|
|
|
} else {
|
|
|
|
ds->refreshing = false; // should not happen
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
MP_WARN(in, "stream %d: demux refreshing failed\n", ds->index);
|
demux: make refresh seek handling more generic
Remove the explicit whitelisting of formats for refresh seeks. Instead,
check whether the packet position is somewhat reliable during demuxing.
If there are packets without position, or the packet position is not
monotonically increasing, then do not use them for refresh seeks.
This does not make sure of some requirements, such as deterministic
seeks. If that happens, mpv will mess up a bit on stream switching.
Also, add another method that uses DTS to identify packets, and prefer
it to the packet position method. Even if there's a demuxer which
randomizes packet positions, it hardly can do that with DTS. The DTS
method is not always available either, though. Some formats do not have
a DTS, and others are not always strictly monotonic (possibly due to
libavformat codec parsing and timestamp determination issues).
2016-08-06 17:24:25 +00:00
|
|
|
}
|
2017-11-10 09:23:49 +00:00
|
|
|
drop = true;
|
demux: hack for instant stream switching
This removes the delay when switching audio tracks in mkv or mp4 files.
Other formats are not enabled, because it's not clear whether the
demuxers fulfill the requirements listed in demux.h. (Many formats
definitely do not with libavformat.)
Background:
The demuxer packet cache buffers a certain amount of packets. This
includes only packets from selected streams. We discard packets from
other streams for various reasons. This introduces a problem: switching
to a different audio track introduces a delay. The delay is as big as
the demuxer packet cache buffer, because while the file was read ahead
to fill the packet buffer, the process of reading packets also discarded
all packets from the previously not selected audio stream. Once the
remaining packet buffer has been played, new audio packets are available
and you hear audio again.
We could probably just not discard packets from unselected streams. But
this would require additional memory and CPU resources, and also it's
hard to tell when packets from unused streams should be discarded (we
don't want to keep them forever; it'd be a memory leak).
We could also issue a player hr-seek to the current playback position,
which would solve the problem in 1 line of code or so. But this can be
rather slow.
So what we do in this commit instead is: we just seek back to the
position where our current packet buffer starts, and start demuxing from
this position again. This way we can get the "past" packets for the
newly selected stream. For streams which were already selected the
packets are simply discarded until the previous position is reached
again.
That latter part is the hard part. We really want to skip packets
exactly until the position where we left off previously, or we will skip
packets or feed packets to the decoder twice. If we assume that the
demuxer is deterministic (returns exactly the same packets after a seek
to a previous position), then we can try to check whether it's the same
packet as the one at the end of the packet buffer. If it is, we know
that the packet after it is where we left off last time.
Unfortunately, this is not very robust, and maybe it can't be made
robust. Currently we use the demux_packet.pos field as unique packet
ID - which works fine in some scenarios, but will break in arbitrary
ways if the basic requirement to the demuxer (as listed in the demux.h
additions) are broken. Thus, this is enabled only for the internal mkv
demuxer and the libavformat mp4 demuxer.
(libavformat mkv does not work, because the packet positions are not
unique. Probably could be fixed upstream, but it's not clear whether
it's a bug or a feature.)
2015-02-13 20:17:17 +00:00
|
|
|
}
|
|
|
|
|
2017-11-10 09:23:49 +00:00
|
|
|
if (drop) {
|
2014-07-16 20:40:21 +00:00
|
|
|
pthread_mutex_unlock(&in->lock);
|
2013-07-11 17:20:25 +00:00
|
|
|
talloc_free(dp);
|
2015-10-17 12:27:55 +00:00
|
|
|
return;
|
2013-07-11 17:20:25 +00:00
|
|
|
}
|
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
queue->correct_pos &= dp->pos >= 0 && dp->pos > queue->last_pos;
|
|
|
|
queue->correct_dts &= dp->dts != MP_NOPTS_VALUE && dp->dts > queue->last_dts;
|
|
|
|
queue->last_pos = dp->pos;
|
|
|
|
queue->last_dts = dp->dts;
|
|
|
|
ds->global_correct_pos &= queue->correct_pos;
|
|
|
|
ds->global_correct_dts &= queue->correct_dts;
|
demux: make refresh seek handling more generic
Remove the explicit whitelisting of formats for refresh seeks. Instead,
check whether the packet position is somewhat reliable during demuxing.
If there are packets without position, or the packet position is not
monotonically increasing, then do not use them for refresh seeks.
This does not make sure of some requirements, such as deterministic
seeks. If that happens, mpv will mess up a bit on stream switching.
Also, add another method that uses DTS to identify packets, and prefer
it to the packet position method. Even if there's a demuxer which
randomizes packet positions, it hardly can do that with DTS. The DTS
method is not always available either, though. Some formats do not have
a DTS, and others are not always strictly monotonic (possibly due to
libavformat codec parsing and timestamp determination issues).
2016-08-06 17:24:25 +00:00
|
|
|
|
2013-11-16 20:28:59 +00:00
|
|
|
dp->stream = stream->index;
|
|
|
|
dp->next = NULL;
|
|
|
|
|
2017-10-25 13:25:25 +00:00
|
|
|
// (keep in mind that even if the reader went out of data, the queue is not
|
|
|
|
// necessarily empty due to the backbuffer)
|
|
|
|
if (!ds->reader_head && (!ds->skip_to_keyframe || dp->keyframe)) {
|
|
|
|
ds->reader_head = dp;
|
|
|
|
ds->skip_to_keyframe = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
size_t bytes = demux_packet_estimate_total_size(dp);
|
2017-11-04 22:39:04 +00:00
|
|
|
ds->in->total_bytes += bytes;
|
2017-10-25 13:25:25 +00:00
|
|
|
if (ds->reader_head) {
|
|
|
|
ds->fw_packs++;
|
|
|
|
ds->fw_bytes += bytes;
|
2017-11-04 22:39:04 +00:00
|
|
|
in->fw_bytes += bytes;
|
2017-10-25 13:25:25 +00:00
|
|
|
}
|
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
if (queue->tail) {
|
2013-07-11 17:20:25 +00:00
|
|
|
// next packet in stream
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
queue->tail->next = dp;
|
|
|
|
queue->tail = dp;
|
2013-07-11 17:17:51 +00:00
|
|
|
} else {
|
2013-07-11 17:20:25 +00:00
|
|
|
// first packet in stream
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
queue->head = queue->tail = dp;
|
2013-07-11 17:17:51 +00:00
|
|
|
}
|
2017-10-21 17:26:33 +00:00
|
|
|
|
2017-10-20 20:30:59 +00:00
|
|
|
if (!ds->ignore_eof) {
|
|
|
|
// obviously not true anymore
|
|
|
|
ds->eof = false;
|
|
|
|
in->last_eof = in->eof = false;
|
|
|
|
}
|
2013-11-16 19:40:37 +00:00
|
|
|
|
2013-11-25 22:13:01 +00:00
|
|
|
// For video, PTS determination is not trivial, but for other media types
|
|
|
|
// distinguishing PTS and DTS is not useful.
|
|
|
|
if (stream->type != STREAM_VIDEO && dp->pts == MP_NOPTS_VALUE)
|
|
|
|
dp->pts = dp->dts;
|
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
if (ts != MP_NOPTS_VALUE && (ts > queue->last_ts || ts + 10 < queue->last_ts))
|
|
|
|
queue->last_ts = ts;
|
2014-08-16 15:07:36 +00:00
|
|
|
if (ds->base_ts == MP_NOPTS_VALUE)
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
ds->base_ts = queue->last_ts;
|
2014-08-16 15:07:36 +00:00
|
|
|
|
2017-11-10 03:35:55 +00:00
|
|
|
MP_TRACE(in, "append packet to %s: size=%d pts=%f dts=%f pos=%"PRIi64" "
|
|
|
|
"[num=%zd size=%zd]\n", stream_type_name(stream->type),
|
|
|
|
dp->len, dp->pts, dp->dts, dp->pos, ds->fw_packs, ds->fw_bytes);
|
2014-07-16 20:40:21 +00:00
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
adjust_seek_range_on_packet(ds, dp);
|
|
|
|
|
2017-12-24 00:56:09 +00:00
|
|
|
// Possible update duration based on highest TS demuxed (but ignore subs).
|
|
|
|
if (stream->type != STREAM_SUB) {
|
|
|
|
if (dp->segmented)
|
|
|
|
ts = MP_PTS_MIN(ts, dp->end);
|
|
|
|
if (ts > in->highest_av_pts) {
|
|
|
|
in->highest_av_pts = ts;
|
|
|
|
double duration = in->highest_av_pts - in->d_thread->start_time;
|
|
|
|
if (duration > in->d_thread->duration) {
|
|
|
|
in->d_thread->duration = duration;
|
|
|
|
// (Don't wakeup like like demux_changed(), would be too noisy.)
|
|
|
|
in->d_thread->events |= DEMUX_EVENT_DURATION;
|
|
|
|
in->d_buffer->duration = duration;
|
|
|
|
in->d_buffer->events |= DEMUX_EVENT_DURATION;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-10-21 17:26:33 +00:00
|
|
|
// Wake up if this was the first packet after start/possible underrun.
|
demux: fix cached SEEK_FORWARD seeks into end of cached regions/EOF
Although seeking past the cached range will trigger a low level seek, a
seek into the region between cache end and last video key frame would
simply seek to the video key frame. This meant that you could get
"stuck" at the end of the file instead of terminating playback when
trying to seek past the end.
One change is that we fix this by _actually_ allowing SEEK_FORWARD to
seek past the last video keyframe in find_seek_target().
In that case, or otherwise seeking to cache buffer end, it could happen
that we set ds->reader_head=NULL if the seek target is after the current
packet. We allow this, because the end of the cached region is defined
by the existence of "any" packet, not necessarily a key frame. Seeking
there still makes sense, because we know that there is going to be more
packets (or EOF) that satisfy the seek target.
The problem is that just resuming demuxing with reader_head==NULL will
simply return any packets that come its way, even non-keyframe ones.
Some decoders will produce ugly soup in this case. (In practice, this
was not a problem, because seeking at the end of the cached region was
rare before this commit, and also some decoders like h264 will skip
broken frames by default anyway.)
So the other change of this commit is to enable key frame skipping.
As a nasty implementation detail, we use a separate flag, instead of
setting reader_head to the first key frame encounted (reader_head being
NULL can happen after a normal seek or on playback start, and then we
want to mirror the underlying demuxer behavior, for better or worse).
This change is relatively untested, so you get to keep the pieces for
yourself.
2017-10-23 18:09:21 +00:00
|
|
|
if (ds->in->wakeup_cb && ds->reader_head && !ds->reader_head->next)
|
2014-07-16 20:40:21 +00:00
|
|
|
ds->in->wakeup_cb(ds->in->wakeup_cb_ctx);
|
|
|
|
pthread_cond_signal(&in->wakeup);
|
|
|
|
pthread_mutex_unlock(&in->lock);
|
2013-07-11 17:17:51 +00:00
|
|
|
}
|
|
|
|
|
2014-07-16 20:40:21 +00:00
|
|
|
// Returns true if there was "progress" (lock was released temporarily).
|
|
|
|
static bool read_packet(struct demux_internal *in)
|
2013-02-14 13:49:50 +00:00
|
|
|
{
|
2014-07-16 20:40:21 +00:00
|
|
|
in->eof = false;
|
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-26 23:13:20 +00:00
|
|
|
in->idle = true;
|
2014-07-16 20:40:21 +00:00
|
|
|
|
2018-01-17 06:07:15 +00:00
|
|
|
if (!in->reading || in->blocked)
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
return false;
|
|
|
|
|
2014-07-16 20:40:21 +00:00
|
|
|
// Check if we need to read a new packet. We do this if all queues are below
|
|
|
|
// the minimum, or if a stream explicitly needs new packets. Also includes
|
|
|
|
// safe-guards against packet queue overflow.
|
2017-12-22 00:56:25 +00:00
|
|
|
bool read_more = false, prefetch_more = false, refresh_more = false;
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
for (int n = 0; n < in->num_streams; n++) {
|
|
|
|
struct demux_stream *ds = in->streams[n]->ds;
|
demux: avoid queue overflow warning when joining two ranges
If the backbuffer is much larger than the forward buffer, and if you
join a small range with a large range (larger than the forward buffer),
then the seek issues to the end of the range after joining will overflow
the queue.
Normally, read_more will be false when the forward buffer is full, but
the resume seek after joining will set need_refresh to true, which
forces more reading and thus triggers the overfloe warning.
Attempt to fix this by not setting read_more to true on refresh seeks.
Set prefetch_more instead. read_more will still be set if an A/V stream
has no data.
This doesn't help with the following problems related to using refresh
seeks for track switching:
- If the forward buffer is full, then enabling another track will
obviously immediately overflow the queue, and immediately lead to
marking the new track as having no more data (i.e. EOF). We could cut
down the forward buffer or so, but there's no simple way to implement
it. Another possibility would be dropping all buffers and trying to
resume again, but this would likely be complex as well.
- Subtitle tracks will not even show a warning (because they are sparse,
and we have no way of telling whether a packet is missing, or there's
just no packet near the current position). Before this commit,
enabling an empty subtitle track would probably have overflown the
queue, because ds->refreshing was never set to true. Possibly this
could be solved by determining a demuxer read position, which would
reflect until which PTS all subtitle packets should have been demuxed.
The forward buffer limit was intended as a last safeguard to avoid
excessive memory usage against badly interleaved files or decoders going
crazy (up to reading the whole into memory and OOM'ing the user's
system). It's not good at all to limit prefetch. Possibly solutions
include having another smaller limit for prefetch, or maybe having only
a total buffer limit, and discarding back buffer if more data has to be
read. The current solution is making the forward buffer larger than the
forward duration (--cache-secs) would require, but of course this
depends on the stream's bitrate.
2017-11-11 04:51:17 +00:00
|
|
|
read_more |= ds->eager && !ds->reader_head;
|
2017-12-22 00:56:25 +00:00
|
|
|
refresh_more |= ds->refreshing;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
if (ds->eager && ds->queue->last_ts != MP_NOPTS_VALUE &&
|
|
|
|
in->min_secs > 0 && ds->base_ts != MP_NOPTS_VALUE &&
|
|
|
|
ds->queue->last_ts >= ds->base_ts)
|
|
|
|
prefetch_more |= ds->queue->last_ts - ds->base_ts < in->min_secs;
|
|
|
|
}
|
2017-12-22 00:56:25 +00:00
|
|
|
MP_TRACE(in, "bytes=%zd, read_more=%d prefetch_more=%d, refresh_more=%d\n",
|
|
|
|
in->fw_bytes, read_more, prefetch_more, refresh_more);
|
2017-11-04 22:39:04 +00:00
|
|
|
if (in->fw_bytes >= in->max_bytes) {
|
demux: avoid queue overflow warning when joining two ranges
If the backbuffer is much larger than the forward buffer, and if you
join a small range with a large range (larger than the forward buffer),
then the seek issues to the end of the range after joining will overflow
the queue.
Normally, read_more will be false when the forward buffer is full, but
the resume seek after joining will set need_refresh to true, which
forces more reading and thus triggers the overfloe warning.
Attempt to fix this by not setting read_more to true on refresh seeks.
Set prefetch_more instead. read_more will still be set if an A/V stream
has no data.
This doesn't help with the following problems related to using refresh
seeks for track switching:
- If the forward buffer is full, then enabling another track will
obviously immediately overflow the queue, and immediately lead to
marking the new track as having no more data (i.e. EOF). We could cut
down the forward buffer or so, but there's no simple way to implement
it. Another possibility would be dropping all buffers and trying to
resume again, but this would likely be complex as well.
- Subtitle tracks will not even show a warning (because they are sparse,
and we have no way of telling whether a packet is missing, or there's
just no packet near the current position). Before this commit,
enabling an empty subtitle track would probably have overflown the
queue, because ds->refreshing was never set to true. Possibly this
could be solved by determining a demuxer read position, which would
reflect until which PTS all subtitle packets should have been demuxed.
The forward buffer limit was intended as a last safeguard to avoid
excessive memory usage against badly interleaved files or decoders going
crazy (up to reading the whole into memory and OOM'ing the user's
system). It's not good at all to limit prefetch. Possibly solutions
include having another smaller limit for prefetch, or maybe having only
a total buffer limit, and discarding back buffer if more data has to be
read. The current solution is making the forward buffer larger than the
forward duration (--cache-secs) would require, but of course this
depends on the stream's bitrate.
2017-11-11 04:51:17 +00:00
|
|
|
// if we hit the limit just by prefetching, simply stop prefetching
|
2017-11-03 15:36:21 +00:00
|
|
|
if (!read_more)
|
|
|
|
return false;
|
2014-07-16 20:40:21 +00:00
|
|
|
if (!in->warned_queue_overflow) {
|
|
|
|
in->warned_queue_overflow = true;
|
2016-08-22 10:10:55 +00:00
|
|
|
MP_WARN(in, "Too many packets in the demuxer packet queues:\n");
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
for (int n = 0; n < in->num_streams; n++) {
|
|
|
|
struct demux_stream *ds = in->streams[n]->ds;
|
2014-07-16 20:40:21 +00:00
|
|
|
if (ds->selected) {
|
2017-11-10 02:18:45 +00:00
|
|
|
MP_WARN(in, " %s/%d: %zd packets, %zd bytes%s%s\n",
|
2017-10-21 17:26:33 +00:00
|
|
|
stream_type_name(ds->type), n,
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
ds->fw_packs, ds->fw_bytes,
|
2017-11-10 02:18:45 +00:00
|
|
|
ds->eager ? "" : " (lazy)",
|
|
|
|
ds->refreshing ? " (refreshing)" : "");
|
2014-07-16 20:40:21 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
for (int n = 0; n < in->num_streams; n++) {
|
|
|
|
struct demux_stream *ds = in->streams[n]->ds;
|
2017-10-21 17:26:33 +00:00
|
|
|
bool eof = !ds->reader_head;
|
2016-02-24 21:04:18 +00:00
|
|
|
if (eof && !ds->eof) {
|
|
|
|
if (in->wakeup_cb)
|
|
|
|
in->wakeup_cb(in->wakeup_cb_ctx);
|
2017-11-03 15:36:59 +00:00
|
|
|
pthread_cond_signal(&in->wakeup);
|
2016-02-24 21:04:18 +00:00
|
|
|
}
|
|
|
|
ds->eof |= eof;
|
2014-07-16 20:40:21 +00:00
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2017-12-22 00:56:25 +00:00
|
|
|
if (!read_more && !prefetch_more && !refresh_more)
|
2014-07-16 20:40:21 +00:00
|
|
|
return false;
|
|
|
|
|
2018-01-09 21:02:25 +00:00
|
|
|
if (in->initial_state) {
|
|
|
|
for (int n = 0; n < in->num_streams; n++)
|
|
|
|
in->current_range->streams[n]->is_bof = in->streams[n]->ds->selected;
|
|
|
|
}
|
|
|
|
|
2014-07-16 20:40:21 +00:00
|
|
|
// Actually read a packet. Drop the lock while doing so, because waiting
|
|
|
|
// for disk or network I/O can take time.
|
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-26 23:13:20 +00:00
|
|
|
in->idle = false;
|
player: improve instant track switching
When switching tracks, we normally have the problem that data gets lost
due to readahead buffering. (Which in turn is because we're stubborn and
instruct the demuxers to discard data on unselected streams.) The
demuxer layer has a hack that re-reads discarded buffered data if a
stream is enabled mid-stream, so track switching will seem instant.
A somewhat similar problem is when all tracks of an external files were
disabled - when enabling the first track, we have to seek to the target
position.
Handle these with the same mechanism. Pass the "current time" to the
demuxer's stream switch function, and let the demuxer figure out what to
do. The demuxer will issue a refresh seek (if possible) to update the
new stream, or will issue a "normal" seek if there was no active stream
yet.
One case that changes is when a video/audio stream is enabled on an
external file with only a subtitle stream active, and the demuxer does
not support rrefresh seeks. This is a fuzzy case, because subtitles are
sparse, and the demuxer might have skipped large amounts of data. We
used to seek (and send the subtitle decoder some subtitle packets
twice). This case is sort of obscure and insane, and the fix would be
questionable, so we simply don't care.
Should mostly fix #3392.
2016-08-06 13:47:04 +00:00
|
|
|
in->initial_state = false;
|
2014-07-16 20:40:21 +00:00
|
|
|
pthread_mutex_unlock(&in->lock);
|
player: improve instant track switching
When switching tracks, we normally have the problem that data gets lost
due to readahead buffering. (Which in turn is because we're stubborn and
instruct the demuxers to discard data on unselected streams.) The
demuxer layer has a hack that re-reads discarded buffered data if a
stream is enabled mid-stream, so track switching will seem instant.
A somewhat similar problem is when all tracks of an external files were
disabled - when enabling the first track, we have to seek to the target
position.
Handle these with the same mechanism. Pass the "current time" to the
demuxer's stream switch function, and let the demuxer figure out what to
do. The demuxer will issue a refresh seek (if possible) to update the
new stream, or will issue a "normal" seek if there was no active stream
yet.
One case that changes is when a video/audio stream is enabled on an
external file with only a subtitle stream active, and the demuxer does
not support rrefresh seeks. This is a fuzzy case, because subtitles are
sparse, and the demuxer might have skipped large amounts of data. We
used to seek (and send the subtitle decoder some subtitle packets
twice). This case is sort of obscure and insane, and the fix would be
questionable, so we simply don't care.
Should mostly fix #3392.
2016-08-06 13:47:04 +00:00
|
|
|
|
2014-07-16 20:40:21 +00:00
|
|
|
struct demuxer *demux = in->d_thread;
|
player: improve instant track switching
When switching tracks, we normally have the problem that data gets lost
due to readahead buffering. (Which in turn is because we're stubborn and
instruct the demuxers to discard data on unselected streams.) The
demuxer layer has a hack that re-reads discarded buffered data if a
stream is enabled mid-stream, so track switching will seem instant.
A somewhat similar problem is when all tracks of an external files were
disabled - when enabling the first track, we have to seek to the target
position.
Handle these with the same mechanism. Pass the "current time" to the
demuxer's stream switch function, and let the demuxer figure out what to
do. The demuxer will issue a refresh seek (if possible) to update the
new stream, or will issue a "normal" seek if there was no active stream
yet.
One case that changes is when a video/audio stream is enabled on an
external file with only a subtitle stream active, and the demuxer does
not support rrefresh seeks. This is a fuzzy case, because subtitles are
sparse, and the demuxer might have skipped large amounts of data. We
used to seek (and send the subtitle decoder some subtitle packets
twice). This case is sort of obscure and insane, and the fix would be
questionable, so we simply don't care.
Should mostly fix #3392.
2016-08-06 13:47:04 +00:00
|
|
|
|
2017-02-04 21:50:45 +00:00
|
|
|
bool eof = true;
|
|
|
|
if (demux->desc->fill_buffer && !demux_cancel_test(demux))
|
|
|
|
eof = demux->desc->fill_buffer(demux) <= 0;
|
2014-07-16 20:40:21 +00:00
|
|
|
update_cache(in);
|
player: improve instant track switching
When switching tracks, we normally have the problem that data gets lost
due to readahead buffering. (Which in turn is because we're stubborn and
instruct the demuxers to discard data on unselected streams.) The
demuxer layer has a hack that re-reads discarded buffered data if a
stream is enabled mid-stream, so track switching will seem instant.
A somewhat similar problem is when all tracks of an external files were
disabled - when enabling the first track, we have to seek to the target
position.
Handle these with the same mechanism. Pass the "current time" to the
demuxer's stream switch function, and let the demuxer figure out what to
do. The demuxer will issue a refresh seek (if possible) to update the
new stream, or will issue a "normal" seek if there was no active stream
yet.
One case that changes is when a video/audio stream is enabled on an
external file with only a subtitle stream active, and the demuxer does
not support rrefresh seeks. This is a fuzzy case, because subtitles are
sparse, and the demuxer might have skipped large amounts of data. We
used to seek (and send the subtitle decoder some subtitle packets
twice). This case is sort of obscure and insane, and the fix would be
questionable, so we simply don't care.
Should mostly fix #3392.
2016-08-06 13:47:04 +00:00
|
|
|
|
2014-10-24 13:56:45 +00:00
|
|
|
pthread_mutex_lock(&in->lock);
|
2014-07-16 20:40:21 +00:00
|
|
|
|
2016-08-06 13:50:46 +00:00
|
|
|
if (!in->seeking) {
|
|
|
|
if (eof) {
|
2017-11-04 22:02:25 +00:00
|
|
|
for (int n = 0; n < in->num_streams; n++) {
|
|
|
|
struct demux_stream *ds = in->streams[n]->ds;
|
|
|
|
if (!ds->eof)
|
|
|
|
adjust_seek_range_on_packet(ds, NULL);
|
|
|
|
ds->eof = true;
|
|
|
|
}
|
2016-08-06 13:50:46 +00:00
|
|
|
// If we had EOF previously, then don't wakeup (avoids wakeup loop)
|
|
|
|
if (!in->last_eof) {
|
|
|
|
if (in->wakeup_cb)
|
|
|
|
in->wakeup_cb(in->wakeup_cb_ctx);
|
|
|
|
pthread_cond_signal(&in->wakeup);
|
|
|
|
MP_VERBOSE(in, "EOF reached.\n");
|
|
|
|
}
|
2014-07-16 20:40:21 +00:00
|
|
|
}
|
2016-08-06 13:50:46 +00:00
|
|
|
in->eof = in->last_eof = eof;
|
2013-02-14 13:49:50 +00:00
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-10-21 17:26:33 +00:00
|
|
|
static void prune_old_packets(struct demux_internal *in)
|
|
|
|
{
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
assert(in->current_range == in->ranges[in->num_ranges - 1]);
|
|
|
|
|
2017-10-21 17:26:33 +00:00
|
|
|
// It's not clear what the ideal way to prune old packets is. For now, we
|
|
|
|
// prune the oldest packet runs, as long as the total cache amount is too
|
|
|
|
// big.
|
2017-11-04 16:32:34 +00:00
|
|
|
size_t max_bytes = in->seekable_cache ? in->max_bytes_bw : 0;
|
2017-11-06 16:11:31 +00:00
|
|
|
while (in->total_bytes - in->fw_bytes > max_bytes) {
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
// (Start from least recently used range.)
|
|
|
|
struct demux_cached_range *range = in->ranges[0];
|
2017-10-21 17:26:33 +00:00
|
|
|
double earliest_ts = MP_NOPTS_VALUE;
|
2017-11-04 16:32:34 +00:00
|
|
|
struct demux_stream *earliest_stream = NULL;
|
2017-10-21 17:26:33 +00:00
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
for (int n = 0; n < range->num_streams; n++) {
|
|
|
|
struct demux_queue *queue = range->streams[n];
|
|
|
|
struct demux_stream *ds = queue->ds;
|
2017-10-21 17:26:33 +00:00
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
if (queue->head && queue->head != ds->reader_head) {
|
|
|
|
struct demux_packet *dp = queue->head;
|
2017-11-04 22:02:25 +00:00
|
|
|
double ts = dp->kf_seek_pts;
|
2017-10-21 17:26:33 +00:00
|
|
|
// Note: in obscure cases, packets might have no timestamps set,
|
|
|
|
// in which case we still need to prune _something_.
|
2017-11-04 16:32:34 +00:00
|
|
|
bool prune_always =
|
|
|
|
!in->seekable_cache || ts == MP_NOPTS_VALUE || !dp->keyframe;
|
|
|
|
if (prune_always || !earliest_stream || ts < earliest_ts) {
|
2017-10-21 17:26:33 +00:00
|
|
|
earliest_ts = ts;
|
2017-11-04 16:32:34 +00:00
|
|
|
earliest_stream = ds;
|
|
|
|
if (prune_always)
|
|
|
|
break;
|
2017-10-21 17:26:33 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-11-06 16:11:31 +00:00
|
|
|
assert(earliest_stream); // incorrect accounting of buffered sizes?
|
2017-11-04 16:32:34 +00:00
|
|
|
struct demux_stream *ds = earliest_stream;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
struct demux_queue *queue = range->streams[ds->index];
|
2017-10-21 17:26:33 +00:00
|
|
|
|
|
|
|
// Prune all packets until the next keyframe or reader_head. Keeping
|
|
|
|
// those packets would not help with seeking at all, so we strictly
|
|
|
|
// drop them.
|
2017-10-25 14:26:03 +00:00
|
|
|
// In addition, we need to find the new possibly min. seek target,
|
|
|
|
// which in the worst case could be inside the forward buffer. The fact
|
|
|
|
// that many keyframe ranges without keyframes exist (audio packets)
|
|
|
|
// makes this much harder.
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
if (in->seekable_cache && !queue->next_prune_target) {
|
2017-11-04 22:39:04 +00:00
|
|
|
// (Has to be _after_ queue->head to drop at least 1 packet.)
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
struct demux_packet *prev = queue->head;
|
2017-11-10 07:57:37 +00:00
|
|
|
if (queue->seek_start != MP_NOPTS_VALUE)
|
|
|
|
queue->last_pruned = queue->seek_start;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
queue->seek_start = MP_NOPTS_VALUE;
|
|
|
|
queue->next_prune_target = queue->tail; // (prune all if none found)
|
2017-11-04 22:02:25 +00:00
|
|
|
while (prev->next) {
|
|
|
|
struct demux_packet *dp = prev->next;
|
|
|
|
// Note that the next back_pts might be above the lowest buffered
|
|
|
|
// packet, but it will still be only viable lowest seek target.
|
|
|
|
if (dp->keyframe && dp->kf_seek_pts != MP_NOPTS_VALUE) {
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
queue->seek_start = dp->kf_seek_pts;
|
|
|
|
queue->next_prune_target = prev;
|
2017-11-04 22:02:25 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
prev = prev->next;
|
2017-10-25 14:26:03 +00:00
|
|
|
}
|
2017-11-04 22:39:04 +00:00
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
update_seek_ranges(range);
|
2017-10-25 14:26:03 +00:00
|
|
|
}
|
|
|
|
|
2017-11-04 22:02:25 +00:00
|
|
|
bool done = false;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
while (!done && queue->head && queue->head != ds->reader_head) {
|
2017-11-10 10:35:19 +00:00
|
|
|
done = queue->next_prune_target == queue->head;
|
|
|
|
remove_head_packet(queue);
|
2017-10-21 17:26:33 +00:00
|
|
|
}
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
|
|
|
|
if (range != in->current_range && range->seek_start == MP_NOPTS_VALUE)
|
|
|
|
free_empty_cached_ranges(in);
|
2017-10-21 17:26:33 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-08-06 17:25:37 +00:00
|
|
|
static void execute_trackswitch(struct demux_internal *in)
|
|
|
|
{
|
|
|
|
in->tracks_switched = false;
|
|
|
|
|
2016-01-18 17:34:44 +00:00
|
|
|
bool any_selected = false;
|
|
|
|
for (int n = 0; n < in->num_streams; n++)
|
|
|
|
any_selected |= in->streams[n]->ds->selected;
|
|
|
|
|
2014-08-06 17:25:37 +00:00
|
|
|
pthread_mutex_unlock(&in->lock);
|
|
|
|
|
|
|
|
if (in->d_thread->desc->control)
|
|
|
|
in->d_thread->desc->control(in->d_thread, DEMUXER_CTRL_SWITCHED_TRACKS, 0);
|
|
|
|
|
2016-01-18 17:34:44 +00:00
|
|
|
stream_control(in->d_thread->stream, STREAM_CTRL_SET_READAHEAD,
|
|
|
|
&(int){any_selected});
|
|
|
|
|
2014-08-06 17:25:37 +00:00
|
|
|
pthread_mutex_lock(&in->lock);
|
|
|
|
}
|
|
|
|
|
2014-07-21 17:27:24 +00:00
|
|
|
static void execute_seek(struct demux_internal *in)
|
|
|
|
{
|
|
|
|
int flags = in->seek_flags;
|
|
|
|
double pts = in->seek_pts;
|
|
|
|
in->seeking = false;
|
2018-01-05 15:41:16 +00:00
|
|
|
in->seeking_in_progress = pts;
|
|
|
|
in->demux_ts = MP_NOPTS_VALUE;
|
|
|
|
in->low_level_seeks += 1;
|
player: improve instant track switching
When switching tracks, we normally have the problem that data gets lost
due to readahead buffering. (Which in turn is because we're stubborn and
instruct the demuxers to discard data on unselected streams.) The
demuxer layer has a hack that re-reads discarded buffered data if a
stream is enabled mid-stream, so track switching will seem instant.
A somewhat similar problem is when all tracks of an external files were
disabled - when enabling the first track, we have to seek to the target
position.
Handle these with the same mechanism. Pass the "current time" to the
demuxer's stream switch function, and let the demuxer figure out what to
do. The demuxer will issue a refresh seek (if possible) to update the
new stream, or will issue a "normal" seek if there was no active stream
yet.
One case that changes is when a video/audio stream is enabled on an
external file with only a subtitle stream active, and the demuxer does
not support rrefresh seeks. This is a fuzzy case, because subtitles are
sparse, and the demuxer might have skipped large amounts of data. We
used to seek (and send the subtitle decoder some subtitle packets
twice). This case is sort of obscure and insane, and the fix would be
questionable, so we simply don't care.
Should mostly fix #3392.
2016-08-06 13:47:04 +00:00
|
|
|
in->initial_state = false;
|
2014-07-21 17:27:24 +00:00
|
|
|
|
|
|
|
pthread_mutex_unlock(&in->lock);
|
|
|
|
|
2015-06-18 20:31:55 +00:00
|
|
|
MP_VERBOSE(in, "execute seek (to %f flags %d)\n", pts, flags);
|
|
|
|
|
2014-07-21 17:27:24 +00:00
|
|
|
if (in->d_thread->desc->seek)
|
|
|
|
in->d_thread->desc->seek(in->d_thread, pts, flags);
|
|
|
|
|
2015-06-18 20:31:55 +00:00
|
|
|
MP_VERBOSE(in, "seek done\n");
|
|
|
|
|
2014-07-21 17:27:24 +00:00
|
|
|
pthread_mutex_lock(&in->lock);
|
2018-01-05 15:41:16 +00:00
|
|
|
|
|
|
|
in->seeking_in_progress = MP_NOPTS_VALUE;
|
2014-07-21 17:27:24 +00:00
|
|
|
}
|
|
|
|
|
2017-11-10 01:55:02 +00:00
|
|
|
// Make demuxing progress. Return whether progress was made.
|
|
|
|
static bool thread_work(struct demux_internal *in)
|
|
|
|
{
|
|
|
|
if (in->run_fn) {
|
|
|
|
in->run_fn(in->run_fn_arg);
|
|
|
|
in->run_fn = NULL;
|
|
|
|
pthread_cond_signal(&in->wakeup);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
if (in->tracks_switched) {
|
|
|
|
execute_trackswitch(in);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
if (in->seeking) {
|
|
|
|
execute_seek(in);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
if (!in->eof) {
|
|
|
|
if (read_packet(in))
|
|
|
|
return true; // read_packet unlocked, so recheck conditions
|
|
|
|
}
|
|
|
|
if (in->force_cache_update) {
|
|
|
|
pthread_mutex_unlock(&in->lock);
|
|
|
|
update_cache(in);
|
|
|
|
pthread_mutex_lock(&in->lock);
|
|
|
|
in->force_cache_update = false;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-07-16 20:40:21 +00:00
|
|
|
static void *demux_thread(void *pctx)
|
2008-04-12 15:51:08 +00:00
|
|
|
{
|
2014-07-16 20:40:21 +00:00
|
|
|
struct demux_internal *in = pctx;
|
2014-10-19 21:32:34 +00:00
|
|
|
mpthread_set_name("demux");
|
2014-07-16 20:40:21 +00:00
|
|
|
pthread_mutex_lock(&in->lock);
|
|
|
|
while (!in->thread_terminate) {
|
2017-11-10 01:55:02 +00:00
|
|
|
if (thread_work(in))
|
2014-07-21 17:27:24 +00:00
|
|
|
continue;
|
2014-07-16 20:40:21 +00:00
|
|
|
pthread_cond_signal(&in->wakeup);
|
|
|
|
pthread_cond_wait(&in->wakeup, &in->lock);
|
2001-07-29 21:07:34 +00:00
|
|
|
}
|
2014-07-16 20:40:21 +00:00
|
|
|
pthread_mutex_unlock(&in->lock);
|
|
|
|
return NULL;
|
2001-02-24 20:28:24 +00:00
|
|
|
}
|
2001-04-20 23:00:11 +00:00
|
|
|
|
2014-07-18 13:08:05 +00:00
|
|
|
static struct demux_packet *dequeue_packet(struct demux_stream *ds)
|
|
|
|
{
|
2017-10-21 18:35:03 +00:00
|
|
|
if (ds->sh->attached_picture) {
|
2017-01-10 13:03:41 +00:00
|
|
|
ds->eof = true;
|
|
|
|
if (ds->attached_picture_added)
|
|
|
|
return NULL;
|
|
|
|
ds->attached_picture_added = true;
|
2017-10-25 10:28:33 +00:00
|
|
|
struct demux_packet *pkt = demux_copy_packet(ds->sh->attached_picture);
|
|
|
|
if (!pkt)
|
|
|
|
abort();
|
|
|
|
pkt->stream = ds->sh->index;
|
|
|
|
return pkt;
|
2017-01-10 13:03:41 +00:00
|
|
|
}
|
2018-01-17 06:07:15 +00:00
|
|
|
if (!ds->reader_head || ds->in->blocked)
|
2014-07-18 13:08:05 +00:00
|
|
|
return NULL;
|
2017-10-21 17:26:33 +00:00
|
|
|
struct demux_packet *pkt = ds->reader_head;
|
|
|
|
ds->reader_head = pkt->next;
|
|
|
|
|
|
|
|
// Update cached packet queue state.
|
|
|
|
ds->fw_packs--;
|
|
|
|
size_t bytes = demux_packet_estimate_total_size(pkt);
|
|
|
|
ds->fw_bytes -= bytes;
|
2017-11-04 22:39:04 +00:00
|
|
|
ds->in->fw_bytes -= bytes;
|
2017-10-21 17:26:33 +00:00
|
|
|
|
demux: always discard cached packets on track switches
This fixes weird behavior in the following case:
- open a file
- make sure the max. demuxer forward cache is smaller than the
file's video track
- make sure the max. readahead duration is larger than the file's
duration
- disable the audio track
- seek to the beginning of the file
- once the cache has filled enable the audio track
- a queue overflow warning should appear
(- looking at the seek ranges is also interesting)
The queue overflow warning happens because the packed queue for the
video track will use up the full quota set by --demuxer-max-bytes. When
the audio track is enabled, reading an audio packet would technically
overflow the packet cache by the size of whatever packet is read next.
This means the demuxer signals EOF to the decoder, and once playback has
consumed enough video packets so that audio packets can be read again,
the decoder resumes from EOF. This interacts badly with A/V
synchronization and the whole thing can randomly crap itself until audio
has fully recovered.
We didn't care about this so far, but we want to raise the readahead
duration to something very high, so that the demuxer cache is fully
used. This means this case can be hit quite quickly by switching audio
or subtitle tracks, and is not really an obscure corner case anymore.
Fix this by always losing all cache. Since the cache can't be used
anyway until the newly selected track has been read, this is not much of
a disadvantage. The only thing that could be brought up is that
unselecting the track again could resume operation normally. (Maybe this
would be useful if network died completely without chance of recovery.
Then you could watch the already buffered video anyway by deselecting
the audio track again.) But given the headaches, this seems like the
better solution.
Unfortunately this requires adding new new strange fields and strangely
fragmenting state management functions again. I'm sure whoever works on
this in the future will hate me. Currently it seems like the lesser
evil, and much simpler and robust than the other potential solutions.
In case this needs to be revisited, here is a reminder for readers from
the future what alternative solutions were considered, without those
disadvantages:
A first attempted solution allowed the demuxer to buffer some additional
packets on track switching. This would allow it to read enough data to
feed the decoder at least. But it was still awkward, as it didn't allow
the demuxer to continue prefetching the newly selected track. It also
barely worked, because you could make the forward buffer "over full" by
seeking back with seekable cache enabled, and then it couldn't read
packets anyway.
As alternative solution, we could always demux and cache all tracks,
even if they're deselected. This would also not require a network-level
seek for the "refresh" logic (it's the thing that lets the video decoder
continue as if nothing happened, while actually seeking back in the
stream to get the missing audio packets, in the case of enabling a
previously disabled audio track). But it would also possibly waste
network and memory resources, depending on what the user actually wants.
A second solution would just account the queue sizes for each stream
separately. We could freely fill up the audio packet queue, even if the
video queue is full. Since the demuxer API returns interleaved packets
and doesn't let you predict which packet type comes next, this is not as
simple as it sounds, but it'd probably tie in nicely with the "refresh"
logic.
A third solution would be removing buffered video packets from the end
of the packet queue. Since the "refresh" logic gets these anyway, there
is no reason to keep them if they prevent the audio packet queue from
catching up with the video one. But this would require additional logic,
would interact badly with a bunch of other corner cases. And as far as
the code goes, it's rather complex, because all the logic is written
with FIFO behavior in mind (including the fact that the packet queue is
a singly linked list with no backwards links, making removal from the
end harder).
2017-12-17 20:34:50 +00:00
|
|
|
ds->last_ret_pos = pkt->pos;
|
|
|
|
ds->last_ret_dts = pkt->dts;
|
|
|
|
|
2017-10-21 17:26:33 +00:00
|
|
|
// The returned packet is mutated etc. and will be owned by the user.
|
|
|
|
pkt = demux_copy_packet(pkt);
|
|
|
|
if (!pkt)
|
|
|
|
abort();
|
2014-07-18 13:08:05 +00:00
|
|
|
pkt->next = NULL;
|
|
|
|
|
2017-10-21 17:26:33 +00:00
|
|
|
double ts = PTS_OR_DEF(pkt->dts, pkt->pts);
|
2014-08-16 15:07:36 +00:00
|
|
|
if (ts != MP_NOPTS_VALUE)
|
|
|
|
ds->base_ts = ts;
|
|
|
|
|
2016-03-05 11:48:58 +00:00
|
|
|
if (pkt->keyframe && ts != MP_NOPTS_VALUE) {
|
2014-12-12 00:00:58 +00:00
|
|
|
// Update bitrate - only at keyframe points, because we use the
|
|
|
|
// (possibly) reordered packet timestamps instead of realtime.
|
|
|
|
double d = ts - ds->last_br_ts;
|
2016-03-05 11:48:58 +00:00
|
|
|
if (ds->last_br_ts == MP_NOPTS_VALUE || d < 0) {
|
2014-12-12 00:00:58 +00:00
|
|
|
ds->bitrate = -1;
|
|
|
|
ds->last_br_ts = ts;
|
|
|
|
ds->last_br_bytes = 0;
|
2017-05-10 19:45:42 +00:00
|
|
|
} else if (d >= 0.5) { // a window of least 500ms for UI purposes
|
2014-12-12 00:00:58 +00:00
|
|
|
ds->bitrate = ds->last_br_bytes / d;
|
|
|
|
ds->last_br_ts = ts;
|
|
|
|
ds->last_br_bytes = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
ds->last_br_bytes += pkt->len;
|
|
|
|
|
2014-07-18 13:08:05 +00:00
|
|
|
// This implies this function is actually called from "the" user thread.
|
2014-09-02 23:59:40 +00:00
|
|
|
if (pkt->pos >= ds->in->d_user->filepos)
|
2014-07-18 13:08:05 +00:00
|
|
|
ds->in->d_user->filepos = pkt->pos;
|
|
|
|
|
2015-11-16 21:47:17 +00:00
|
|
|
pkt->pts = MP_ADD_PTS(pkt->pts, ds->in->ts_offset);
|
|
|
|
pkt->dts = MP_ADD_PTS(pkt->dts, ds->in->ts_offset);
|
|
|
|
|
2017-11-10 03:35:55 +00:00
|
|
|
if (pkt->segmented) {
|
|
|
|
pkt->start = MP_ADD_PTS(pkt->start, ds->in->ts_offset);
|
|
|
|
pkt->end = MP_ADD_PTS(pkt->end, ds->in->ts_offset);
|
|
|
|
}
|
2016-02-20 15:22:15 +00:00
|
|
|
|
2017-10-21 17:26:33 +00:00
|
|
|
prune_old_packets(ds->in);
|
2014-07-18 13:08:05 +00:00
|
|
|
return pkt;
|
|
|
|
}
|
|
|
|
|
2013-07-11 17:10:33 +00:00
|
|
|
// Read a packet from the given stream. The returned packet belongs to the
|
|
|
|
// caller, who has to free it with talloc_free(). Might block. Returns NULL
|
|
|
|
// on EOF.
|
|
|
|
struct demux_packet *demux_read_packet(struct sh_stream *sh)
|
2006-04-24 10:58:40 +00:00
|
|
|
{
|
2013-07-11 17:20:25 +00:00
|
|
|
struct demux_stream *ds = sh ? sh->ds : NULL;
|
2017-11-10 03:41:56 +00:00
|
|
|
if (!ds)
|
|
|
|
return NULL;
|
|
|
|
struct demux_internal *in = ds->in;
|
|
|
|
pthread_mutex_lock(&in->lock);
|
|
|
|
if (ds->eager) {
|
|
|
|
const char *t = stream_type_name(ds->type);
|
|
|
|
MP_DBG(in, "reading packet for %s\n", t);
|
|
|
|
in->eof = false; // force retry
|
2018-01-17 06:07:15 +00:00
|
|
|
while (ds->selected && !ds->reader_head && !in->blocked) {
|
2017-11-10 03:41:56 +00:00
|
|
|
in->reading = true;
|
|
|
|
// Note: the following code marks EOF if it can't continue
|
|
|
|
if (in->threading) {
|
|
|
|
MP_VERBOSE(in, "waiting for demux thread (%s)\n", t);
|
|
|
|
pthread_cond_signal(&in->wakeup);
|
|
|
|
pthread_cond_wait(&in->wakeup, &in->lock);
|
|
|
|
} else {
|
|
|
|
thread_work(in);
|
2017-01-10 10:54:34 +00:00
|
|
|
}
|
2017-11-10 03:41:56 +00:00
|
|
|
if (ds->eof)
|
|
|
|
break;
|
2017-01-10 10:54:34 +00:00
|
|
|
}
|
2013-06-02 23:28:14 +00:00
|
|
|
}
|
2017-11-10 03:41:56 +00:00
|
|
|
struct demux_packet *pkt = dequeue_packet(ds);
|
|
|
|
pthread_cond_signal(&in->wakeup); // possibly read more
|
|
|
|
pthread_mutex_unlock(&in->lock);
|
2014-07-16 20:40:21 +00:00
|
|
|
return pkt;
|
2001-04-20 23:00:11 +00:00
|
|
|
}
|
|
|
|
|
2014-07-18 13:08:05 +00:00
|
|
|
// Poll the demuxer queue, and if there's a packet, return it. Otherwise, just
|
|
|
|
// make the demuxer thread read packets for this stream, and if there's at
|
|
|
|
// least one packet, call the wakeup callback.
|
2015-12-29 00:35:52 +00:00
|
|
|
// Unlike demux_read_packet(), this always enables readahead (except for
|
|
|
|
// interleaved subtitles).
|
2014-07-18 13:08:05 +00:00
|
|
|
// Returns:
|
|
|
|
// < 0: EOF was reached, *out_pkt=NULL
|
|
|
|
// == 0: no new packet yet, but maybe later, *out_pkt=NULL
|
|
|
|
// > 0: new packet read, *out_pkt is set
|
2015-12-29 00:35:52 +00:00
|
|
|
// Note: when reading interleaved subtitles, the demuxer won't try to forcibly
|
|
|
|
// read ahead to get the next subtitle packet (as the next packet could be
|
|
|
|
// minutes away). In this situation, this function will just return -1.
|
2014-07-18 13:08:05 +00:00
|
|
|
int demux_read_packet_async(struct sh_stream *sh, struct demux_packet **out_pkt)
|
|
|
|
{
|
|
|
|
struct demux_stream *ds = sh ? sh->ds : NULL;
|
|
|
|
int r = -1;
|
|
|
|
*out_pkt = NULL;
|
2017-11-10 03:41:56 +00:00
|
|
|
if (!ds)
|
|
|
|
return r;
|
|
|
|
if (ds->in->threading) {
|
|
|
|
pthread_mutex_lock(&ds->in->lock);
|
|
|
|
*out_pkt = dequeue_packet(ds);
|
|
|
|
if (ds->eager) {
|
|
|
|
r = *out_pkt ? 1 : (ds->eof ? -1 : 0);
|
|
|
|
ds->in->reading = true; // enable readahead
|
|
|
|
ds->in->eof = false; // force retry
|
|
|
|
pthread_cond_signal(&ds->in->wakeup); // possibly read more
|
2014-07-18 13:08:05 +00:00
|
|
|
} else {
|
|
|
|
r = *out_pkt ? 1 : -1;
|
|
|
|
}
|
2017-11-10 03:41:56 +00:00
|
|
|
pthread_mutex_unlock(&ds->in->lock);
|
2018-01-17 06:07:15 +00:00
|
|
|
} else if (ds->in->blocked) {
|
|
|
|
r = 0;
|
2017-11-10 03:41:56 +00:00
|
|
|
} else {
|
|
|
|
*out_pkt = demux_read_packet(sh);
|
|
|
|
r = *out_pkt ? 1 : -1;
|
2014-07-18 13:08:05 +00:00
|
|
|
}
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2013-07-11 17:10:33 +00:00
|
|
|
// Return whether a packet is queued. Never blocks, never forces any reads.
|
|
|
|
bool demux_has_packet(struct sh_stream *sh)
|
2006-04-27 11:13:21 +00:00
|
|
|
{
|
2014-07-16 20:40:21 +00:00
|
|
|
bool has_packet = false;
|
|
|
|
if (sh) {
|
|
|
|
pthread_mutex_lock(&sh->ds->in->lock);
|
2017-10-21 17:26:33 +00:00
|
|
|
has_packet = sh->ds->reader_head;
|
2014-07-16 20:40:21 +00:00
|
|
|
pthread_mutex_unlock(&sh->ds->in->lock);
|
|
|
|
}
|
|
|
|
return has_packet;
|
2002-05-02 10:25:48 +00:00
|
|
|
}
|
|
|
|
|
Rewrite ordered chapters and timeline stuff
This uses a different method to piece segments together. The old
approach basically changes to a new file (with a new start offset) any
time a segment ends. This meant waiting for audio/video end on segment
end, and then changing to the new segment all at once. It had a very
weird impact on the playback core, and some things (like truly gapless
segment transitions, or frame backstepping) just didn't work.
The new approach adds the demux_timeline pseudo-demuxer, which presents
an uniform packet stream from the many segments. This is pretty similar
to how ordered chapters are implemented everywhere else. It also reminds
of the FFmpeg concat pseudo-demuxer.
The "pure" version of this approach doesn't work though. Segments can
actually have different codec configurations (different extradata), and
subtitles are most likely broken too. (Subtitles have multiple corner
cases which break the pure stream-concatenation approach completely.)
To counter this, we do two things:
- Reinit the decoder with each segment. We go as far as allowing
concatenating files with completely different codecs for the sake
of EDL (which also uses the timeline infrastructure). A "lighter"
approach would try to make use of decoder mechanism to update e.g.
the extradata, but that seems fragile.
- Clip decoded data to segment boundaries. This is equivalent to
normal playback core mechanisms like hr-seek, but now the playback
core doesn't need to care about these things.
These two mechanisms are equivalent to what happened in the old
implementation, except they don't happen in the playback core anymore.
In other words, the playback core is completely relieved from timeline
implementation details. (Which honestly is exactly what I'm trying to
do here. I don't think ordered chapter behavior deserves improvement,
even if it's bad - but I want to get it out from the playback core.)
There is code duplication between audio and video decoder common code.
This is awful and could be shareable - but this will happen later.
Note that the audio path has some code to clip audio frames for the
purpose of codec preroll/gapless handling, but it's not shared as
sharing it would cause more pain than it would help.
2016-02-15 20:04:07 +00:00
|
|
|
// Read and return any packet we find. NULL means EOF.
|
2014-07-05 14:57:56 +00:00
|
|
|
struct demux_packet *demux_read_any_packet(struct demuxer *demuxer)
|
|
|
|
{
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
struct demux_internal *in = demuxer->in;
|
|
|
|
assert(!in->threading); // doesn't work with threading
|
2014-07-19 10:34:07 +00:00
|
|
|
bool read_more = true;
|
2018-01-17 06:07:15 +00:00
|
|
|
while (read_more && !in->blocked) {
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
for (int n = 0; n < in->num_streams; n++) {
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
in->reading = true; // force read_packet() to read
|
|
|
|
struct demux_packet *pkt = dequeue_packet(in->streams[n]->ds);
|
2014-07-19 10:19:12 +00:00
|
|
|
if (pkt)
|
|
|
|
return pkt;
|
2014-07-06 17:02:58 +00:00
|
|
|
}
|
|
|
|
// retry after calling this
|
2017-11-10 01:55:02 +00:00
|
|
|
pthread_mutex_lock(&in->lock); // lock only because thread_work unlocks
|
|
|
|
read_more = thread_work(in);
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
read_more &= !in->eof;
|
|
|
|
pthread_mutex_unlock(&in->lock);
|
2014-07-05 14:57:56 +00:00
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2013-12-21 19:24:20 +00:00
|
|
|
void demuxer_help(struct mp_log *log)
|
2005-08-05 19:57:47 +00:00
|
|
|
{
|
2008-04-12 15:51:08 +00:00
|
|
|
int i;
|
|
|
|
|
2013-12-21 19:24:20 +00:00
|
|
|
mp_info(log, "Available demuxers:\n");
|
|
|
|
mp_info(log, " demuxer: info:\n");
|
2008-04-12 15:51:08 +00:00
|
|
|
for (i = 0; demuxer_list[i]; i++) {
|
2013-12-21 19:24:20 +00:00
|
|
|
mp_info(log, "%10s %s\n",
|
|
|
|
demuxer_list[i]->name, demuxer_list[i]->desc);
|
2008-04-12 15:51:08 +00:00
|
|
|
}
|
2005-08-05 19:57:47 +00:00
|
|
|
}
|
2005-02-13 13:39:19 +00:00
|
|
|
|
2013-07-12 19:58:11 +00:00
|
|
|
static const char *d_level(enum demux_check level)
|
|
|
|
{
|
|
|
|
switch (level) {
|
|
|
|
case DEMUX_CHECK_FORCE: return "force";
|
|
|
|
case DEMUX_CHECK_UNSAFE: return "unsafe";
|
|
|
|
case DEMUX_CHECK_REQUEST:return "request";
|
|
|
|
case DEMUX_CHECK_NORMAL: return "normal";
|
2008-04-12 15:51:08 +00:00
|
|
|
}
|
2013-07-12 19:58:11 +00:00
|
|
|
abort();
|
2005-08-05 19:57:47 +00:00
|
|
|
}
|
2001-12-27 21:24:56 +00:00
|
|
|
|
2014-03-28 11:38:42 +00:00
|
|
|
static int decode_float(char *str, float *out)
|
|
|
|
{
|
|
|
|
char *rest;
|
|
|
|
float dec_val;
|
|
|
|
|
|
|
|
dec_val = strtod(str, &rest);
|
|
|
|
if (!rest || (rest == str) || !isfinite(dec_val))
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
*out = dec_val;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-08-12 19:39:32 +00:00
|
|
|
static int decode_gain(struct mp_log *log, struct mp_tags *tags,
|
|
|
|
const char *tag, float *out)
|
2014-03-28 11:38:42 +00:00
|
|
|
{
|
|
|
|
char *tag_val = NULL;
|
|
|
|
float dec_val;
|
|
|
|
|
2016-08-12 19:39:32 +00:00
|
|
|
tag_val = mp_tags_get_str(tags, tag);
|
2014-12-04 20:07:45 +00:00
|
|
|
if (!tag_val)
|
2014-03-28 11:38:42 +00:00
|
|
|
return -1;
|
|
|
|
|
2016-08-13 13:09:03 +00:00
|
|
|
if (decode_float(tag_val, &dec_val) < 0) {
|
2016-08-12 19:39:32 +00:00
|
|
|
mp_msg(log, MSGL_ERR, "Invalid replaygain value\n");
|
2014-03-28 11:38:42 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
*out = dec_val;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-08-12 19:39:32 +00:00
|
|
|
static int decode_peak(struct mp_log *log, struct mp_tags *tags,
|
|
|
|
const char *tag, float *out)
|
2014-03-28 11:38:42 +00:00
|
|
|
{
|
|
|
|
char *tag_val = NULL;
|
|
|
|
float dec_val;
|
|
|
|
|
|
|
|
*out = 1.0;
|
|
|
|
|
2016-08-12 19:39:32 +00:00
|
|
|
tag_val = mp_tags_get_str(tags, tag);
|
2014-03-28 11:38:42 +00:00
|
|
|
if (!tag_val)
|
|
|
|
return 0;
|
|
|
|
|
2016-08-13 13:09:03 +00:00
|
|
|
if (decode_float(tag_val, &dec_val) < 0 || dec_val <= 0.0)
|
|
|
|
return -1;
|
2014-03-28 11:38:42 +00:00
|
|
|
|
|
|
|
*out = dec_val;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-08-12 19:39:32 +00:00
|
|
|
static struct replaygain_data *decode_rgain(struct mp_log *log,
|
|
|
|
struct mp_tags *tags)
|
2014-03-28 11:38:42 +00:00
|
|
|
{
|
2015-07-12 17:31:06 +00:00
|
|
|
struct replaygain_data rg = {0};
|
2014-03-28 11:38:42 +00:00
|
|
|
|
2016-08-13 13:09:03 +00:00
|
|
|
if (decode_gain(log, tags, "REPLAYGAIN_TRACK_GAIN", &rg.track_gain) >= 0 &&
|
|
|
|
decode_peak(log, tags, "REPLAYGAIN_TRACK_PEAK", &rg.track_peak) >= 0)
|
2014-03-28 11:38:42 +00:00
|
|
|
{
|
2016-08-13 13:09:03 +00:00
|
|
|
if (decode_gain(log, tags, "REPLAYGAIN_ALBUM_GAIN", &rg.album_gain) < 0 ||
|
|
|
|
decode_peak(log, tags, "REPLAYGAIN_ALBUM_PEAK", &rg.album_peak) < 0)
|
2016-08-13 13:06:45 +00:00
|
|
|
{
|
|
|
|
rg.album_gain = rg.track_gain;
|
|
|
|
rg.album_peak = rg.track_peak;
|
|
|
|
}
|
2018-01-18 09:08:48 +00:00
|
|
|
return talloc_dup(NULL, &rg);
|
2014-03-28 11:38:42 +00:00
|
|
|
}
|
2015-07-12 17:33:34 +00:00
|
|
|
|
2016-08-13 13:09:03 +00:00
|
|
|
if (decode_gain(log, tags, "REPLAYGAIN_GAIN", &rg.track_gain) >= 0 &&
|
|
|
|
decode_peak(log, tags, "REPLAYGAIN_PEAK", &rg.track_peak) >= 0)
|
2015-07-12 17:33:34 +00:00
|
|
|
{
|
|
|
|
rg.album_gain = rg.track_gain;
|
|
|
|
rg.album_peak = rg.track_peak;
|
2018-01-18 09:08:48 +00:00
|
|
|
return talloc_dup(NULL, &rg);
|
2016-08-12 19:39:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void demux_update_replaygain(demuxer_t *demuxer)
|
|
|
|
{
|
|
|
|
struct demux_internal *in = demuxer->in;
|
|
|
|
for (int n = 0; n < in->num_streams; n++) {
|
|
|
|
struct sh_stream *sh = in->streams[n];
|
|
|
|
if (sh->type == STREAM_AUDIO && !sh->codec->replaygain_data) {
|
|
|
|
struct replaygain_data *rg = decode_rgain(demuxer->log, sh->tags);
|
|
|
|
if (!rg)
|
|
|
|
rg = decode_rgain(demuxer->log, demuxer->metadata);
|
2016-08-13 13:06:07 +00:00
|
|
|
if (rg)
|
2016-08-12 19:39:32 +00:00
|
|
|
sh->codec->replaygain_data = talloc_steal(in, rg);
|
|
|
|
}
|
2015-07-12 17:33:34 +00:00
|
|
|
}
|
2014-03-28 11:38:42 +00:00
|
|
|
}
|
|
|
|
|
2014-07-16 20:40:21 +00:00
|
|
|
// Copy all fields from src to dst, depending on event flags.
|
|
|
|
static void demux_copy(struct demuxer *dst, struct demuxer *src)
|
|
|
|
{
|
|
|
|
if (src->events & DEMUX_EVENT_INIT) {
|
2015-02-17 22:44:31 +00:00
|
|
|
// Note that we do as shallow copies as possible. We expect the data
|
2014-07-16 20:40:21 +00:00
|
|
|
// that is not-copied (only referenced) to be immutable.
|
|
|
|
// This implies e.g. that no chapters are added after initialization.
|
|
|
|
dst->chapters = src->chapters;
|
|
|
|
dst->num_chapters = src->num_chapters;
|
|
|
|
dst->editions = src->editions;
|
|
|
|
dst->num_editions = src->num_editions;
|
|
|
|
dst->edition = src->edition;
|
|
|
|
dst->attachments = src->attachments;
|
|
|
|
dst->num_attachments = src->num_attachments;
|
|
|
|
dst->matroska_data = src->matroska_data;
|
|
|
|
dst->playlist = src->playlist;
|
|
|
|
dst->seekable = src->seekable;
|
2015-01-26 12:46:33 +00:00
|
|
|
dst->partially_seekable = src->partially_seekable;
|
2014-07-16 20:40:21 +00:00
|
|
|
dst->filetype = src->filetype;
|
|
|
|
dst->ts_resets_possible = src->ts_resets_possible;
|
2015-02-18 20:10:43 +00:00
|
|
|
dst->fully_read = src->fully_read;
|
2014-07-16 20:40:21 +00:00
|
|
|
dst->start_time = src->start_time;
|
2017-06-20 11:57:58 +00:00
|
|
|
dst->duration = src->duration;
|
2016-08-26 10:31:09 +00:00
|
|
|
dst->is_network = src->is_network;
|
2015-02-17 22:47:54 +00:00
|
|
|
dst->priv = src->priv;
|
2014-07-16 20:40:21 +00:00
|
|
|
}
|
2016-08-12 19:39:32 +00:00
|
|
|
|
2014-07-16 20:40:21 +00:00
|
|
|
if (src->events & DEMUX_EVENT_METADATA) {
|
|
|
|
talloc_free(dst->metadata);
|
|
|
|
dst->metadata = mp_tags_dup(dst, src->metadata);
|
2016-08-12 19:39:32 +00:00
|
|
|
|
|
|
|
if (dst->num_update_stream_tags != src->num_update_stream_tags) {
|
2016-08-16 08:48:54 +00:00
|
|
|
dst->num_update_stream_tags = src->num_update_stream_tags;
|
2016-08-12 19:39:32 +00:00
|
|
|
talloc_free(dst->update_stream_tags);
|
|
|
|
dst->update_stream_tags =
|
|
|
|
talloc_zero_array(dst, struct mp_tags *, dst->num_update_stream_tags);
|
|
|
|
}
|
|
|
|
for (int n = 0; n < dst->num_update_stream_tags; n++) {
|
|
|
|
talloc_free(dst->update_stream_tags[n]);
|
|
|
|
dst->update_stream_tags[n] =
|
|
|
|
talloc_steal(dst->update_stream_tags, src->update_stream_tags[n]);
|
|
|
|
src->update_stream_tags[n] = NULL;
|
|
|
|
}
|
2014-07-16 20:40:21 +00:00
|
|
|
}
|
2016-08-12 19:39:32 +00:00
|
|
|
|
2017-12-24 00:56:09 +00:00
|
|
|
if (src->events & DEMUX_EVENT_DURATION)
|
|
|
|
dst->duration = src->duration;
|
|
|
|
|
2014-07-16 20:40:21 +00:00
|
|
|
dst->events |= src->events;
|
|
|
|
src->events = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
// This is called by demuxer implementations if certain parameters change
|
|
|
|
// at runtime.
|
|
|
|
// events is one of DEMUX_EVENT_*
|
|
|
|
// The code will copy the fields references by the events to the user-thread.
|
|
|
|
void demux_changed(demuxer_t *demuxer, int events)
|
|
|
|
{
|
|
|
|
assert(demuxer == demuxer->in->d_thread); // call from demuxer impl. only
|
|
|
|
struct demux_internal *in = demuxer->in;
|
|
|
|
|
|
|
|
demuxer->events |= events;
|
|
|
|
|
|
|
|
update_cache(in);
|
|
|
|
|
2014-10-24 13:56:45 +00:00
|
|
|
pthread_mutex_lock(&in->lock);
|
|
|
|
|
2014-07-16 20:40:21 +00:00
|
|
|
if (demuxer->events & DEMUX_EVENT_INIT)
|
|
|
|
demuxer_sort_chapters(demuxer);
|
|
|
|
|
|
|
|
demux_copy(in->d_buffer, demuxer);
|
|
|
|
|
2014-12-04 20:09:17 +00:00
|
|
|
if (in->wakeup_cb)
|
|
|
|
in->wakeup_cb(in->wakeup_cb_ctx);
|
2014-07-16 20:40:21 +00:00
|
|
|
pthread_mutex_unlock(&in->lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Called by the user thread (i.e. player) to update metadata and other things
|
|
|
|
// from the demuxer thread.
|
|
|
|
void demux_update(demuxer_t *demuxer)
|
|
|
|
{
|
|
|
|
assert(demuxer == demuxer->in->d_user);
|
|
|
|
struct demux_internal *in = demuxer->in;
|
|
|
|
|
2014-08-06 22:34:14 +00:00
|
|
|
if (!in->threading)
|
|
|
|
update_cache(in);
|
2014-10-24 13:56:45 +00:00
|
|
|
|
|
|
|
pthread_mutex_lock(&in->lock);
|
2014-07-16 20:40:21 +00:00
|
|
|
demux_copy(demuxer, in->d_buffer);
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
demuxer->events |= in->events;
|
|
|
|
in->events = 0;
|
2016-08-12 19:39:32 +00:00
|
|
|
if (demuxer->events & DEMUX_EVENT_METADATA) {
|
|
|
|
int num_streams = MPMIN(in->num_streams, demuxer->num_update_stream_tags);
|
|
|
|
for (int n = 0; n < num_streams; n++) {
|
|
|
|
struct mp_tags *tags = demuxer->update_stream_tags[n];
|
|
|
|
demuxer->update_stream_tags[n] = NULL;
|
|
|
|
if (tags) {
|
|
|
|
struct sh_stream *sh = in->streams[n];
|
|
|
|
talloc_free(sh->tags);
|
|
|
|
sh->tags = talloc_steal(sh, tags);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Often useful audio-only files, which have metadata in the audio track
|
|
|
|
// metadata instead of the main metadata (especially OGG).
|
|
|
|
if (in->num_streams == 1)
|
|
|
|
mp_tags_merge(demuxer->metadata, in->streams[0]->tags);
|
|
|
|
|
|
|
|
if (in->stream_metadata)
|
|
|
|
mp_tags_merge(demuxer->metadata, in->stream_metadata);
|
|
|
|
}
|
|
|
|
if (demuxer->events & (DEMUX_EVENT_METADATA | DEMUX_EVENT_STREAMS))
|
|
|
|
demux_update_replaygain(demuxer);
|
2014-07-16 20:40:21 +00:00
|
|
|
pthread_mutex_unlock(&in->lock);
|
|
|
|
}
|
|
|
|
|
2014-10-24 13:40:01 +00:00
|
|
|
static void demux_init_cache(struct demuxer *demuxer)
|
|
|
|
{
|
|
|
|
struct demux_internal *in = demuxer->in;
|
|
|
|
struct stream *stream = demuxer->stream;
|
|
|
|
|
|
|
|
char *base = NULL;
|
|
|
|
stream_control(stream, STREAM_CTRL_GET_BASE_FILENAME, &base);
|
|
|
|
in->stream_base_filename = talloc_steal(demuxer, base);
|
|
|
|
}
|
|
|
|
|
2015-05-19 19:36:52 +00:00
|
|
|
static void demux_init_cuesheet(struct demuxer *demuxer)
|
|
|
|
{
|
|
|
|
char *cue = mp_tags_get_str(demuxer->metadata, "cuesheet");
|
|
|
|
if (cue && !demuxer->num_chapters) {
|
|
|
|
struct cue_file *f = mp_parse_cue(bstr0(cue));
|
|
|
|
if (f) {
|
2015-12-17 09:40:31 +00:00
|
|
|
if (mp_check_embedded_cue(f) < 0) {
|
|
|
|
MP_WARN(demuxer, "Embedded cue sheet references more than one file. "
|
|
|
|
"Ignoring it.\n");
|
|
|
|
} else {
|
|
|
|
for (int n = 0; n < f->num_tracks; n++) {
|
|
|
|
struct cue_track *t = &f->tracks[n];
|
|
|
|
int idx = demuxer_add_chapter(demuxer, "", t->start, -1);
|
|
|
|
mp_tags_merge(demuxer->chapters[idx].metadata, t->tags);
|
|
|
|
}
|
2015-05-19 19:36:52 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
talloc_free(f);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-08-26 11:05:14 +00:00
|
|
|
static void demux_maybe_replace_stream(struct demuxer *demuxer)
|
|
|
|
{
|
|
|
|
struct demux_internal *in = demuxer->in;
|
|
|
|
assert(!in->threading && demuxer == in->d_user);
|
|
|
|
|
|
|
|
if (demuxer->fully_read) {
|
|
|
|
MP_VERBOSE(demuxer, "assuming demuxer read all data; closing stream\n");
|
|
|
|
free_stream(demuxer->stream);
|
|
|
|
demuxer->stream = open_memory_stream(NULL, 0); // dummy
|
|
|
|
in->d_thread->stream = demuxer->stream;
|
|
|
|
in->d_buffer->stream = demuxer->stream;
|
|
|
|
|
|
|
|
if (demuxer->desc->control)
|
|
|
|
demuxer->desc->control(in->d_thread, DEMUXER_CTRL_REPLACE_STREAM, NULL);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-11-03 12:55:32 +00:00
|
|
|
static void demux_init_ccs(struct demuxer *demuxer, struct demux_opts *opts)
|
|
|
|
{
|
|
|
|
struct demux_internal *in = demuxer->in;
|
|
|
|
if (!opts->create_ccs)
|
|
|
|
return;
|
|
|
|
pthread_mutex_lock(&in->lock);
|
|
|
|
for (int n = 0; n < in->num_streams; n++) {
|
|
|
|
struct sh_stream *sh = in->streams[n];
|
|
|
|
if (sh->type == STREAM_VIDEO)
|
|
|
|
demuxer_get_cc_track_locked(sh);
|
|
|
|
}
|
|
|
|
pthread_mutex_unlock(&in->lock);
|
|
|
|
}
|
|
|
|
|
2013-12-21 19:24:20 +00:00
|
|
|
static struct demuxer *open_given_type(struct mpv_global *global,
|
|
|
|
struct mp_log *log,
|
2010-11-10 12:37:15 +00:00
|
|
|
const struct demuxer_desc *desc,
|
2013-07-12 19:58:11 +00:00
|
|
|
struct stream *stream,
|
|
|
|
struct demuxer_params *params,
|
|
|
|
enum demux_check check)
|
|
|
|
{
|
2015-10-06 16:18:18 +00:00
|
|
|
if (mp_cancel_test(stream->cancel))
|
|
|
|
return NULL;
|
|
|
|
|
2013-07-12 19:58:11 +00:00
|
|
|
struct demuxer *demuxer = talloc_ptrtype(NULL, demuxer);
|
2016-12-04 22:15:31 +00:00
|
|
|
struct demux_opts *opts = mp_get_config_group(demuxer, global, &demux_conf);
|
2013-07-12 19:58:11 +00:00
|
|
|
*demuxer = (struct demuxer) {
|
|
|
|
.desc = desc,
|
|
|
|
.stream = stream,
|
2014-05-24 12:04:09 +00:00
|
|
|
.seekable = stream->seekable,
|
2013-07-12 19:58:11 +00:00
|
|
|
.filepos = -1,
|
2013-12-21 19:24:20 +00:00
|
|
|
.global = global,
|
|
|
|
.log = mp_log_new(demuxer, log, desc->name),
|
2013-12-21 20:55:41 +00:00
|
|
|
.glog = log,
|
2013-07-12 19:58:11 +00:00
|
|
|
.filename = talloc_strdup(demuxer, stream->url),
|
2016-08-26 10:31:09 +00:00
|
|
|
.is_network = stream->is_network,
|
2016-12-04 22:15:31 +00:00
|
|
|
.access_references = opts->access_references,
|
2014-07-16 20:40:21 +00:00
|
|
|
.events = DEMUX_EVENT_ALL,
|
2017-11-24 12:58:57 +00:00
|
|
|
.duration = -1,
|
2014-07-16 20:40:21 +00:00
|
|
|
};
|
2014-07-18 14:16:05 +00:00
|
|
|
demuxer->seekable = stream->seekable;
|
2017-02-02 17:03:29 +00:00
|
|
|
if (demuxer->stream->underlying && !demuxer->stream->underlying->seekable)
|
2014-07-18 14:16:05 +00:00
|
|
|
demuxer->seekable = false;
|
|
|
|
|
2014-07-16 20:40:21 +00:00
|
|
|
struct demux_internal *in = demuxer->in = talloc_ptrtype(demuxer, in);
|
|
|
|
*in = (struct demux_internal){
|
|
|
|
.log = demuxer->log,
|
|
|
|
.d_thread = talloc(demuxer, struct demuxer),
|
|
|
|
.d_buffer = talloc(demuxer, struct demuxer),
|
|
|
|
.d_user = demuxer,
|
2016-09-06 18:09:56 +00:00
|
|
|
.min_secs = opts->min_secs,
|
|
|
|
.max_bytes = opts->max_bytes,
|
2017-10-21 17:26:33 +00:00
|
|
|
.max_bytes_bw = opts->max_bytes_bw,
|
player: improve instant track switching
When switching tracks, we normally have the problem that data gets lost
due to readahead buffering. (Which in turn is because we're stubborn and
instruct the demuxers to discard data on unselected streams.) The
demuxer layer has a hack that re-reads discarded buffered data if a
stream is enabled mid-stream, so track switching will seem instant.
A somewhat similar problem is when all tracks of an external files were
disabled - when enabling the first track, we have to seek to the target
position.
Handle these with the same mechanism. Pass the "current time" to the
demuxer's stream switch function, and let the demuxer figure out what to
do. The demuxer will issue a refresh seek (if possible) to update the
new stream, or will issue a "normal" seek if there was no active stream
yet.
One case that changes is when a video/audio stream is enabled on an
external file with only a subtitle stream active, and the demuxer does
not support rrefresh seeks. This is a fuzzy case, because subtitles are
sparse, and the demuxer might have skipped large amounts of data. We
used to seek (and send the subtitle decoder some subtitle packets
twice). This case is sort of obscure and insane, and the fix would be
questionable, so we simply don't care.
Should mostly fix #3392.
2016-08-06 13:47:04 +00:00
|
|
|
.initial_state = true,
|
2017-12-24 00:56:09 +00:00
|
|
|
.highest_av_pts = MP_NOPTS_VALUE,
|
2018-01-05 15:41:16 +00:00
|
|
|
.seeking_in_progress = MP_NOPTS_VALUE,
|
|
|
|
.demux_ts = MP_NOPTS_VALUE,
|
2013-07-12 19:58:11 +00:00
|
|
|
};
|
2014-07-16 20:40:21 +00:00
|
|
|
pthread_mutex_init(&in->lock, NULL);
|
|
|
|
pthread_cond_init(&in->wakeup, NULL);
|
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
in->current_range = talloc_ptrtype(in, in->current_range);
|
2017-11-04 22:39:04 +00:00
|
|
|
*in->current_range = (struct demux_cached_range){
|
|
|
|
.seek_start = MP_NOPTS_VALUE,
|
|
|
|
.seek_end = MP_NOPTS_VALUE,
|
|
|
|
};
|
|
|
|
MP_TARRAY_APPEND(in, in->ranges, in->num_ranges, in->current_range);
|
|
|
|
|
2014-07-16 20:40:21 +00:00
|
|
|
*in->d_thread = *demuxer;
|
|
|
|
*in->d_buffer = *demuxer;
|
|
|
|
|
|
|
|
in->d_thread->metadata = talloc_zero(in->d_thread, struct mp_tags);
|
|
|
|
in->d_user->metadata = talloc_zero(in->d_user, struct mp_tags);
|
|
|
|
in->d_buffer->metadata = talloc_zero(in->d_buffer, struct mp_tags);
|
|
|
|
|
2016-02-11 19:54:44 +00:00
|
|
|
mp_dbg(log, "Trying demuxer: %s (force-level: %s)\n",
|
|
|
|
desc->name, d_level(check));
|
2013-07-12 19:58:11 +00:00
|
|
|
|
Rewrite ordered chapters and timeline stuff
This uses a different method to piece segments together. The old
approach basically changes to a new file (with a new start offset) any
time a segment ends. This meant waiting for audio/video end on segment
end, and then changing to the new segment all at once. It had a very
weird impact on the playback core, and some things (like truly gapless
segment transitions, or frame backstepping) just didn't work.
The new approach adds the demux_timeline pseudo-demuxer, which presents
an uniform packet stream from the many segments. This is pretty similar
to how ordered chapters are implemented everywhere else. It also reminds
of the FFmpeg concat pseudo-demuxer.
The "pure" version of this approach doesn't work though. Segments can
actually have different codec configurations (different extradata), and
subtitles are most likely broken too. (Subtitles have multiple corner
cases which break the pure stream-concatenation approach completely.)
To counter this, we do two things:
- Reinit the decoder with each segment. We go as far as allowing
concatenating files with completely different codecs for the sake
of EDL (which also uses the timeline infrastructure). A "lighter"
approach would try to make use of decoder mechanism to update e.g.
the extradata, but that seems fragile.
- Clip decoded data to segment boundaries. This is equivalent to
normal playback core mechanisms like hr-seek, but now the playback
core doesn't need to care about these things.
These two mechanisms are equivalent to what happened in the old
implementation, except they don't happen in the playback core anymore.
In other words, the playback core is completely relieved from timeline
implementation details. (Which honestly is exactly what I'm trying to
do here. I don't think ordered chapter behavior deserves improvement,
even if it's bad - but I want to get it out from the playback core.)
There is code duplication between audio and video decoder common code.
This is awful and could be shareable - but this will happen later.
Note that the audio path has some code to clip audio frames for the
purpose of codec preroll/gapless handling, but it's not shared as
sharing it would cause more pain than it would help.
2016-02-15 20:04:07 +00:00
|
|
|
// not for DVD/BD/DVB in particular
|
|
|
|
if (stream->seekable && (!params || !params->timeline))
|
2014-10-28 14:28:46 +00:00
|
|
|
stream_seek(stream, 0);
|
|
|
|
|
|
|
|
// Peek this much data to avoid that stream_read() run by some demuxers
|
2015-02-27 18:51:14 +00:00
|
|
|
// will flush previous peeked data.
|
2014-10-28 14:28:46 +00:00
|
|
|
stream_peek(stream, STREAM_BUFFER_SIZE);
|
|
|
|
|
2015-02-20 20:21:14 +00:00
|
|
|
in->d_thread->params = params; // temporary during open()
|
2014-07-16 20:40:21 +00:00
|
|
|
int ret = demuxer->desc->open(in->d_thread, check);
|
2013-07-12 19:58:11 +00:00
|
|
|
if (ret >= 0) {
|
2014-07-16 20:40:21 +00:00
|
|
|
in->d_thread->params = NULL;
|
|
|
|
if (in->d_thread->filetype)
|
2014-05-31 20:07:36 +00:00
|
|
|
mp_verbose(log, "Detected file format: %s (%s)\n",
|
2014-07-16 20:40:21 +00:00
|
|
|
in->d_thread->filetype, desc->desc);
|
2010-11-10 13:38:36 +00:00
|
|
|
else
|
2014-05-31 20:07:36 +00:00
|
|
|
mp_verbose(log, "Detected file format: %s\n", desc->desc);
|
2014-10-17 16:18:20 +00:00
|
|
|
if (!in->d_thread->seekable)
|
2014-12-05 22:55:48 +00:00
|
|
|
mp_verbose(log, "Stream is not seekable.\n");
|
2016-09-06 18:09:56 +00:00
|
|
|
if (!in->d_thread->seekable && opts->force_seekable) {
|
2015-07-08 20:04:35 +00:00
|
|
|
mp_warn(log, "Not seekable, but enabling seeking on user request.\n");
|
2014-07-16 20:40:21 +00:00
|
|
|
in->d_thread->seekable = true;
|
2015-01-26 12:46:33 +00:00
|
|
|
in->d_thread->partially_seekable = true;
|
2013-11-03 18:21:47 +00:00
|
|
|
}
|
2015-05-19 19:36:52 +00:00
|
|
|
demux_init_cuesheet(in->d_thread);
|
2014-10-24 13:40:01 +00:00
|
|
|
demux_init_cache(demuxer);
|
2017-11-03 12:55:32 +00:00
|
|
|
demux_init_ccs(demuxer, opts);
|
2014-07-16 20:40:21 +00:00
|
|
|
demux_changed(in->d_thread, DEMUX_EVENT_ALL);
|
|
|
|
demux_update(demuxer);
|
2017-01-19 07:00:19 +00:00
|
|
|
stream_control(demuxer->stream, STREAM_CTRL_SET_READAHEAD,
|
|
|
|
&(int){params ? params->initial_readahead : false});
|
2017-12-10 04:07:36 +00:00
|
|
|
int seekable = opts->seekable_cache;
|
|
|
|
if (demuxer->is_network || stream->caching) {
|
|
|
|
in->min_secs = MPMAX(in->min_secs, opts->min_secs_cache);
|
|
|
|
if (seekable < 0)
|
|
|
|
seekable = 1;
|
|
|
|
}
|
|
|
|
in->seekable_cache = seekable == 1;
|
2016-10-22 15:17:04 +00:00
|
|
|
if (!(params && params->disable_timeline)) {
|
|
|
|
struct timeline *tl = timeline_load(global, log, demuxer);
|
|
|
|
if (tl) {
|
|
|
|
struct demuxer_params params2 = {0};
|
|
|
|
params2.timeline = tl;
|
|
|
|
struct demuxer *sub =
|
|
|
|
open_given_type(global, log, &demuxer_desc_timeline, stream,
|
|
|
|
¶ms2, DEMUX_CHECK_FORCE);
|
2017-02-02 17:38:16 +00:00
|
|
|
if (sub) {
|
|
|
|
demuxer = sub;
|
|
|
|
} else {
|
|
|
|
timeline_destroy(tl);
|
|
|
|
}
|
2016-10-22 15:17:04 +00:00
|
|
|
}
|
Rewrite ordered chapters and timeline stuff
This uses a different method to piece segments together. The old
approach basically changes to a new file (with a new start offset) any
time a segment ends. This meant waiting for audio/video end on segment
end, and then changing to the new segment all at once. It had a very
weird impact on the playback core, and some things (like truly gapless
segment transitions, or frame backstepping) just didn't work.
The new approach adds the demux_timeline pseudo-demuxer, which presents
an uniform packet stream from the many segments. This is pretty similar
to how ordered chapters are implemented everywhere else. It also reminds
of the FFmpeg concat pseudo-demuxer.
The "pure" version of this approach doesn't work though. Segments can
actually have different codec configurations (different extradata), and
subtitles are most likely broken too. (Subtitles have multiple corner
cases which break the pure stream-concatenation approach completely.)
To counter this, we do two things:
- Reinit the decoder with each segment. We go as far as allowing
concatenating files with completely different codecs for the sake
of EDL (which also uses the timeline infrastructure). A "lighter"
approach would try to make use of decoder mechanism to update e.g.
the extradata, but that seems fragile.
- Clip decoded data to segment boundaries. This is equivalent to
normal playback core mechanisms like hr-seek, but now the playback
core doesn't need to care about these things.
These two mechanisms are equivalent to what happened in the old
implementation, except they don't happen in the playback core anymore.
In other words, the playback core is completely relieved from timeline
implementation details. (Which honestly is exactly what I'm trying to
do here. I don't think ordered chapter behavior deserves improvement,
even if it's bad - but I want to get it out from the playback core.)
There is code duplication between audio and video decoder common code.
This is awful and could be shareable - but this will happen later.
Note that the audio path has some code to clip audio frames for the
purpose of codec preroll/gapless handling, but it's not shared as
sharing it would cause more pain than it would help.
2016-02-15 20:04:07 +00:00
|
|
|
}
|
2010-11-10 12:37:15 +00:00
|
|
|
return demuxer;
|
|
|
|
}
|
2013-07-12 19:58:11 +00:00
|
|
|
|
2010-11-10 12:37:15 +00:00
|
|
|
free_demuxer(demuxer);
|
|
|
|
return NULL;
|
|
|
|
}
|
2008-04-12 15:51:08 +00:00
|
|
|
|
2013-07-12 19:58:11 +00:00
|
|
|
static const int d_normal[] = {DEMUX_CHECK_NORMAL, DEMUX_CHECK_UNSAFE, -1};
|
|
|
|
static const int d_request[] = {DEMUX_CHECK_REQUEST, -1};
|
|
|
|
static const int d_force[] = {DEMUX_CHECK_FORCE, -1};
|
|
|
|
|
2015-02-20 20:21:14 +00:00
|
|
|
// params can be NULL
|
|
|
|
struct demuxer *demux_open(struct stream *stream, struct demuxer_params *params,
|
2013-12-21 19:24:20 +00:00
|
|
|
struct mpv_global *global)
|
2010-11-10 12:37:15 +00:00
|
|
|
{
|
2013-07-12 19:58:11 +00:00
|
|
|
const int *check_levels = d_normal;
|
|
|
|
const struct demuxer_desc *check_desc = NULL;
|
2013-12-21 19:24:20 +00:00
|
|
|
struct mp_log *log = mp_log_new(NULL, global->log, "!demux");
|
|
|
|
struct demuxer *demuxer = NULL;
|
2015-02-20 20:21:14 +00:00
|
|
|
char *force_format = params ? params->force_format : NULL;
|
2013-07-12 19:58:11 +00:00
|
|
|
|
|
|
|
if (!force_format)
|
|
|
|
force_format = stream->demuxer;
|
2008-04-12 15:51:08 +00:00
|
|
|
|
2013-07-12 19:58:11 +00:00
|
|
|
if (force_format && force_format[0]) {
|
|
|
|
check_levels = d_request;
|
|
|
|
if (force_format[0] == '+') {
|
|
|
|
force_format += 1;
|
|
|
|
check_levels = d_force;
|
|
|
|
}
|
|
|
|
for (int n = 0; demuxer_list[n]; n++) {
|
|
|
|
if (strcmp(demuxer_list[n]->name, force_format) == 0)
|
|
|
|
check_desc = demuxer_list[n];
|
|
|
|
}
|
|
|
|
if (!check_desc) {
|
2013-12-21 19:24:20 +00:00
|
|
|
mp_err(log, "Demuxer %s does not exist.\n", force_format);
|
|
|
|
goto done;
|
2006-10-19 18:20:12 +00:00
|
|
|
}
|
|
|
|
}
|
2003-01-19 00:21:54 +00:00
|
|
|
|
2013-07-12 19:58:11 +00:00
|
|
|
// Test demuxers from first to last, one pass for each check_levels[] entry
|
|
|
|
for (int pass = 0; check_levels[pass] != -1; pass++) {
|
|
|
|
enum demux_check level = check_levels[pass];
|
2016-02-11 19:54:44 +00:00
|
|
|
mp_verbose(log, "Trying demuxers for level=%s.\n", d_level(level));
|
2013-07-12 19:58:11 +00:00
|
|
|
for (int n = 0; demuxer_list[n]; n++) {
|
|
|
|
const struct demuxer_desc *desc = demuxer_list[n];
|
|
|
|
if (!check_desc || desc == check_desc) {
|
2013-12-21 19:24:20 +00:00
|
|
|
demuxer = open_given_type(global, log, desc, stream, params, level);
|
2013-12-21 20:55:41 +00:00
|
|
|
if (demuxer) {
|
|
|
|
talloc_steal(demuxer, log);
|
|
|
|
log = NULL;
|
2013-12-21 19:24:20 +00:00
|
|
|
goto done;
|
2013-12-21 20:55:41 +00:00
|
|
|
}
|
2013-07-12 19:58:11 +00:00
|
|
|
}
|
2006-10-19 18:20:12 +00:00
|
|
|
}
|
|
|
|
}
|
2001-12-26 16:34:06 +00:00
|
|
|
|
2013-12-21 19:24:20 +00:00
|
|
|
done:
|
|
|
|
talloc_free(log);
|
|
|
|
return demuxer;
|
2001-07-21 22:37:55 +00:00
|
|
|
}
|
2001-08-12 17:28:16 +00:00
|
|
|
|
2015-02-20 20:56:55 +00:00
|
|
|
// Convenience function: open the stream, enable the cache (according to params
|
|
|
|
// and global opts.), open the demuxer.
|
|
|
|
// (use free_demuxer_and_stream() to free the underlying stream too)
|
2016-08-26 11:05:14 +00:00
|
|
|
// Also for some reason may close the opened stream if it's not needed.
|
2015-02-20 20:56:55 +00:00
|
|
|
struct demuxer *demux_open_url(const char *url,
|
|
|
|
struct demuxer_params *params,
|
|
|
|
struct mp_cancel *cancel,
|
|
|
|
struct mpv_global *global)
|
|
|
|
{
|
2015-08-03 23:01:09 +00:00
|
|
|
struct demuxer_params dummy = {0};
|
|
|
|
if (!params)
|
|
|
|
params = &dummy;
|
|
|
|
struct stream *s = stream_create(url, STREAM_READ | params->stream_flags,
|
|
|
|
cancel, global);
|
2015-02-20 20:56:55 +00:00
|
|
|
if (!s)
|
|
|
|
return NULL;
|
2015-08-03 23:01:09 +00:00
|
|
|
if (!params->disable_cache)
|
2016-09-06 18:09:56 +00:00
|
|
|
stream_enable_cache_defaults(&s);
|
2015-02-20 20:56:55 +00:00
|
|
|
struct demuxer *d = demux_open(s, params, global);
|
2016-08-26 11:05:14 +00:00
|
|
|
if (d) {
|
|
|
|
demux_maybe_replace_stream(d);
|
|
|
|
} else {
|
2015-08-03 23:01:09 +00:00
|
|
|
params->demuxer_failed = true;
|
2015-02-20 20:56:55 +00:00
|
|
|
free_stream(s);
|
2015-08-03 23:01:09 +00:00
|
|
|
}
|
2015-02-20 20:56:55 +00:00
|
|
|
return d;
|
|
|
|
}
|
|
|
|
|
2017-10-21 17:26:33 +00:00
|
|
|
// called locked, from user thread only
|
|
|
|
static void clear_reader_state(struct demux_internal *in)
|
2008-06-04 05:10:48 +00:00
|
|
|
{
|
2017-10-21 17:26:33 +00:00
|
|
|
for (int n = 0; n < in->num_streams; n++)
|
|
|
|
ds_clear_reader_state(in->streams[n]->ds);
|
|
|
|
in->warned_queue_overflow = false;
|
|
|
|
in->d_user->filepos = -1; // implicitly synchronized
|
2018-01-17 06:07:15 +00:00
|
|
|
in->blocked = false;
|
2017-11-04 22:39:04 +00:00
|
|
|
assert(in->fw_bytes == 0);
|
2014-07-21 17:27:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// clear the packet queues
|
|
|
|
void demux_flush(demuxer_t *demuxer)
|
|
|
|
{
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
struct demux_internal *in = demuxer->in;
|
|
|
|
assert(demuxer == in->d_user);
|
|
|
|
|
2014-07-21 17:27:24 +00:00
|
|
|
pthread_mutex_lock(&demuxer->in->lock);
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
clear_reader_state(in);
|
|
|
|
for (int n = 0; n < in->num_ranges; n++)
|
|
|
|
clear_cached_range(in, in->ranges[n]);
|
|
|
|
free_empty_cached_ranges(in);
|
2014-07-16 20:40:21 +00:00
|
|
|
pthread_mutex_unlock(&demuxer->in->lock);
|
2008-06-02 10:17:48 +00:00
|
|
|
}
|
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
// Does some (but not all) things for switching to another range.
|
|
|
|
static void switch_current_range(struct demux_internal *in,
|
|
|
|
struct demux_cached_range *range)
|
2017-10-13 22:16:32 +00:00
|
|
|
{
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
struct demux_cached_range *old = in->current_range;
|
|
|
|
assert(old != range);
|
2017-10-21 17:26:33 +00:00
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
set_current_range(in, range);
|
|
|
|
|
|
|
|
// Remove packets which can't be used when seeking back to the range.
|
|
|
|
for (int n = 0; n < in->num_streams; n++) {
|
|
|
|
struct demux_queue *queue = old->streams[n];
|
|
|
|
|
|
|
|
// Remove all packets from head up until including next_prune_target.
|
|
|
|
while (queue->next_prune_target)
|
2017-11-10 10:35:19 +00:00
|
|
|
remove_head_packet(queue);
|
2017-10-21 17:26:33 +00:00
|
|
|
}
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
|
|
|
|
// Exclude weird corner cases that break resuming.
|
|
|
|
for (int n = 0; n < in->num_streams; n++) {
|
|
|
|
struct demux_stream *ds = in->streams[n]->ds;
|
|
|
|
// This is needed to resume or join the range at all.
|
|
|
|
if (ds->selected && !(ds->global_correct_dts || ds->global_correct_pos)) {
|
|
|
|
MP_VERBOSE(in, "discarding old range, due to stream %d: "
|
|
|
|
"correct_dts=%d correct_pos=%d\n", n,
|
|
|
|
ds->global_correct_dts, ds->global_correct_pos);
|
|
|
|
clear_cached_range(in, old);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Set up reading from new range (as well as writing to it).
|
|
|
|
for (int n = 0; n < in->num_streams; n++) {
|
|
|
|
struct demux_stream *ds = in->streams[n]->ds;
|
|
|
|
|
|
|
|
ds->queue = range->streams[n];
|
2017-11-10 09:15:37 +00:00
|
|
|
ds->refreshing = false;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
ds->eof = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// No point in keeping any junk (especially if old current_range is empty).
|
|
|
|
free_empty_cached_ranges(in);
|
2017-10-21 17:26:33 +00:00
|
|
|
}
|
2017-10-13 22:16:32 +00:00
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
static struct demux_packet *find_seek_target(struct demux_queue *queue,
|
2017-10-21 17:26:33 +00:00
|
|
|
double pts, int flags)
|
|
|
|
{
|
2017-11-10 11:17:34 +00:00
|
|
|
struct demux_packet *start = queue->head;
|
|
|
|
for (int n = 0; n < queue->num_index; n++) {
|
|
|
|
if (queue->index[n]->kf_seek_pts > pts)
|
|
|
|
break;
|
|
|
|
start = queue->index[n];
|
|
|
|
}
|
|
|
|
|
2017-10-21 17:26:33 +00:00
|
|
|
struct demux_packet *target = NULL;
|
|
|
|
double target_diff = MP_NOPTS_VALUE;
|
2017-11-10 11:17:34 +00:00
|
|
|
for (struct demux_packet *dp = start; dp; dp = dp->next) {
|
2017-11-04 22:02:25 +00:00
|
|
|
double range_pts = dp->kf_seek_pts;
|
|
|
|
if (!dp->keyframe || range_pts == MP_NOPTS_VALUE)
|
2017-10-21 17:26:33 +00:00
|
|
|
continue;
|
|
|
|
|
2017-10-23 17:05:39 +00:00
|
|
|
double diff = range_pts - pts;
|
demux: fix cached SEEK_FORWARD seeks into end of cached regions/EOF
Although seeking past the cached range will trigger a low level seek, a
seek into the region between cache end and last video key frame would
simply seek to the video key frame. This meant that you could get
"stuck" at the end of the file instead of terminating playback when
trying to seek past the end.
One change is that we fix this by _actually_ allowing SEEK_FORWARD to
seek past the last video keyframe in find_seek_target().
In that case, or otherwise seeking to cache buffer end, it could happen
that we set ds->reader_head=NULL if the seek target is after the current
packet. We allow this, because the end of the cached region is defined
by the existence of "any" packet, not necessarily a key frame. Seeking
there still makes sense, because we know that there is going to be more
packets (or EOF) that satisfy the seek target.
The problem is that just resuming demuxing with reader_head==NULL will
simply return any packets that come its way, even non-keyframe ones.
Some decoders will produce ugly soup in this case. (In practice, this
was not a problem, because seeking at the end of the cached region was
rare before this commit, and also some decoders like h264 will skip
broken frames by default anyway.)
So the other change of this commit is to enable key frame skipping.
As a nasty implementation detail, we use a separate flag, instead of
setting reader_head to the first key frame encounted (reader_head being
NULL can happen after a normal seek or on playback start, and then we
want to mirror the underlying demuxer behavior, for better or worse).
This change is relatively untested, so you get to keep the pieces for
yourself.
2017-10-23 18:09:21 +00:00
|
|
|
if (flags & SEEK_FORWARD) {
|
2017-10-21 17:26:33 +00:00
|
|
|
diff = -diff;
|
demux: fix cached SEEK_FORWARD seeks into end of cached regions/EOF
Although seeking past the cached range will trigger a low level seek, a
seek into the region between cache end and last video key frame would
simply seek to the video key frame. This meant that you could get
"stuck" at the end of the file instead of terminating playback when
trying to seek past the end.
One change is that we fix this by _actually_ allowing SEEK_FORWARD to
seek past the last video keyframe in find_seek_target().
In that case, or otherwise seeking to cache buffer end, it could happen
that we set ds->reader_head=NULL if the seek target is after the current
packet. We allow this, because the end of the cached region is defined
by the existence of "any" packet, not necessarily a key frame. Seeking
there still makes sense, because we know that there is going to be more
packets (or EOF) that satisfy the seek target.
The problem is that just resuming demuxing with reader_head==NULL will
simply return any packets that come its way, even non-keyframe ones.
Some decoders will produce ugly soup in this case. (In practice, this
was not a problem, because seeking at the end of the cached region was
rare before this commit, and also some decoders like h264 will skip
broken frames by default anyway.)
So the other change of this commit is to enable key frame skipping.
As a nasty implementation detail, we use a separate flag, instead of
setting reader_head to the first key frame encounted (reader_head being
NULL can happen after a normal seek or on playback start, and then we
want to mirror the underlying demuxer behavior, for better or worse).
This change is relatively untested, so you get to keep the pieces for
yourself.
2017-10-23 18:09:21 +00:00
|
|
|
if (diff > 0)
|
|
|
|
continue;
|
|
|
|
}
|
2017-11-10 11:11:33 +00:00
|
|
|
if (target) {
|
2017-10-21 17:26:33 +00:00
|
|
|
if (diff <= 0) {
|
|
|
|
if (target_diff <= 0 && diff <= target_diff)
|
|
|
|
continue;
|
|
|
|
} else if (diff >= target_diff)
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
target_diff = diff;
|
2017-11-04 22:02:25 +00:00
|
|
|
target = dp;
|
2017-11-10 11:11:33 +00:00
|
|
|
if (range_pts > pts)
|
|
|
|
break;
|
2017-10-21 17:26:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return target;
|
|
|
|
}
|
|
|
|
|
|
|
|
// must be called locked
|
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 21:28:08 +00:00
|
|
|
static struct demux_cached_range *find_cache_seek_target(struct demux_internal *in,
|
|
|
|
double pts, int flags)
|
2017-10-21 17:26:33 +00:00
|
|
|
{
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
// Note about queued low level seeks: in->seeking can be true here, and it
|
|
|
|
// might come from a previous resume seek to the current range. If we end
|
|
|
|
// up seeking into the current range (i.e. just changing time offset), the
|
|
|
|
// seek needs to continue. Otherwise, we override the queued seek anyway.
|
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 21:28:08 +00:00
|
|
|
if ((flags & SEEK_FACTOR) || !in->seekable_cache)
|
|
|
|
return NULL;
|
2017-10-21 17:26:33 +00:00
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
for (int n = 0; n < in->num_ranges; n++) {
|
|
|
|
struct demux_cached_range *r = in->ranges[n];
|
|
|
|
if (r->seek_start != MP_NOPTS_VALUE) {
|
2018-01-09 21:02:25 +00:00
|
|
|
MP_VERBOSE(in, "cached range %d: %f <-> %f (bof=%d, eof=%d)\n",
|
|
|
|
n, r->seek_start, r->seek_end, r->is_bof, r->is_eof);
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
|
2018-01-09 21:02:25 +00:00
|
|
|
if ((pts >= r->seek_start || r->is_bof) &&
|
|
|
|
(pts <= r->seek_end || r->is_eof))
|
|
|
|
{
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
MP_VERBOSE(in, "...using this range for in-cache seek.\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 21:28:08 +00:00
|
|
|
return r;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2017-10-13 22:16:32 +00: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 21:28:08 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
2017-10-13 22:16:32 +00: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 21:28:08 +00:00
|
|
|
// must be called locked
|
|
|
|
// range must be non-NULL and from find_cache_seek_target() using the same pts
|
|
|
|
// and flags, before any other changes to the cached state
|
|
|
|
static void execute_cache_seek(struct demux_internal *in,
|
|
|
|
struct demux_cached_range *range,
|
|
|
|
double pts, int flags)
|
|
|
|
{
|
2017-10-21 17:26:33 +00:00
|
|
|
// Adjust the seek target to the found video key frames. Otherwise the
|
|
|
|
// video will undershoot the seek target, while audio will be closer to it.
|
|
|
|
// The player frontend will play the additional video without audio, so
|
|
|
|
// you get silent audio for the amount of "undershoot". Adjusting the seek
|
|
|
|
// target will make the audio seek to the video target or before.
|
|
|
|
// (If hr-seeks are used, it's better to skip this, as it would only mean
|
|
|
|
// that more audio data than necessary would have to be decoded.)
|
|
|
|
if (!(flags & SEEK_HR)) {
|
|
|
|
for (int n = 0; n < in->num_streams; n++) {
|
|
|
|
struct demux_stream *ds = in->streams[n]->ds;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
struct demux_queue *queue = range->streams[n];
|
2017-10-21 17:26:33 +00:00
|
|
|
if (ds->selected && ds->type == STREAM_VIDEO) {
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
struct demux_packet *target = find_seek_target(queue, pts, flags);
|
2017-10-21 17:26:33 +00:00
|
|
|
if (target) {
|
2017-11-04 22:02:25 +00:00
|
|
|
double target_pts = target->kf_seek_pts;
|
2017-10-21 17:26:33 +00:00
|
|
|
if (target_pts != MP_NOPTS_VALUE) {
|
|
|
|
MP_VERBOSE(in, "adjust seek target %f -> %f\n",
|
|
|
|
pts, target_pts);
|
|
|
|
// (We assume the find_seek_target() will return the
|
|
|
|
// same target for the video stream.)
|
|
|
|
pts = target_pts;
|
2017-10-23 17:05:39 +00:00
|
|
|
flags &= ~SEEK_FORWARD;
|
2017-10-21 17:26:33 +00:00
|
|
|
}
|
2017-10-13 22:16:32 +00:00
|
|
|
}
|
2017-10-21 17:26:33 +00:00
|
|
|
break;
|
2017-10-13 22:16:32 +00:00
|
|
|
}
|
|
|
|
}
|
2017-10-21 17:26:33 +00:00
|
|
|
}
|
2017-10-13 22:16:32 +00:00
|
|
|
|
2017-10-21 17:26:33 +00:00
|
|
|
for (int n = 0; n < in->num_streams; n++) {
|
|
|
|
struct demux_stream *ds = in->streams[n]->ds;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
struct demux_queue *queue = range->streams[n];
|
2017-10-13 22:16:32 +00:00
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
struct demux_packet *target = find_seek_target(queue, pts, flags);
|
2017-10-21 17:26:33 +00:00
|
|
|
ds->reader_head = target;
|
demux: fix cached SEEK_FORWARD seeks into end of cached regions/EOF
Although seeking past the cached range will trigger a low level seek, a
seek into the region between cache end and last video key frame would
simply seek to the video key frame. This meant that you could get
"stuck" at the end of the file instead of terminating playback when
trying to seek past the end.
One change is that we fix this by _actually_ allowing SEEK_FORWARD to
seek past the last video keyframe in find_seek_target().
In that case, or otherwise seeking to cache buffer end, it could happen
that we set ds->reader_head=NULL if the seek target is after the current
packet. We allow this, because the end of the cached region is defined
by the existence of "any" packet, not necessarily a key frame. Seeking
there still makes sense, because we know that there is going to be more
packets (or EOF) that satisfy the seek target.
The problem is that just resuming demuxing with reader_head==NULL will
simply return any packets that come its way, even non-keyframe ones.
Some decoders will produce ugly soup in this case. (In practice, this
was not a problem, because seeking at the end of the cached region was
rare before this commit, and also some decoders like h264 will skip
broken frames by default anyway.)
So the other change of this commit is to enable key frame skipping.
As a nasty implementation detail, we use a separate flag, instead of
setting reader_head to the first key frame encounted (reader_head being
NULL can happen after a normal seek or on playback start, and then we
want to mirror the underlying demuxer behavior, for better or worse).
This change is relatively untested, so you get to keep the pieces for
yourself.
2017-10-23 18:09:21 +00:00
|
|
|
ds->skip_to_keyframe = !target;
|
2017-11-04 16:43:22 +00:00
|
|
|
if (ds->reader_head)
|
|
|
|
ds->base_ts = PTS_OR_DEF(ds->reader_head->pts, ds->reader_head->dts);
|
2017-10-21 17:26:33 +00:00
|
|
|
|
2017-11-04 22:39:04 +00:00
|
|
|
recompute_buffers(ds);
|
|
|
|
in->fw_bytes += ds->fw_bytes;
|
|
|
|
|
2017-10-21 17:26:33 +00:00
|
|
|
MP_VERBOSE(in, "seeking stream %d (%s) to ",
|
|
|
|
n, stream_type_name(ds->type));
|
2017-10-13 22:16:32 +00:00
|
|
|
|
2017-10-21 17:26:33 +00:00
|
|
|
if (target) {
|
|
|
|
MP_VERBOSE(in, "packet %f/%f\n", target->pts, target->dts);
|
|
|
|
} else {
|
|
|
|
MP_VERBOSE(in, "nothing\n");
|
|
|
|
}
|
2017-10-13 22:16:32 +00:00
|
|
|
}
|
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
// If we seek to another range, we want to seek the low level demuxer to
|
|
|
|
// there as well, because reader and demuxer queue must be the same.
|
|
|
|
if (in->current_range != range) {
|
|
|
|
switch_current_range(in, range);
|
|
|
|
|
|
|
|
in->seeking = true;
|
|
|
|
in->seek_flags = SEEK_HR;
|
|
|
|
in->seek_pts = range->seek_end - 1.0;
|
|
|
|
|
|
|
|
// When new packets are being appended, they could overlap with the old
|
|
|
|
// range due to demuxer seek imprecisions, or because the queue contains
|
|
|
|
// packets past the seek target but before the next seek target. Don't
|
|
|
|
// append them twice, instead skip them until new packets are found.
|
|
|
|
for (int n = 0; n < in->num_streams; n++) {
|
|
|
|
struct demux_stream *ds = in->streams[n]->ds;
|
|
|
|
|
2017-11-10 02:18:45 +00:00
|
|
|
ds->refreshing = ds->selected;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
MP_VERBOSE(in, "resuming demuxer to end of cached range\n");
|
|
|
|
}
|
2017-10-13 22:16:32 +00:00
|
|
|
}
|
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
// Create a new blank ache range, and backup the old one. If the seekable
|
|
|
|
// demuxer cache is disabled, merely reset the current range to a blank state.
|
|
|
|
static void switch_to_fresh_cache_range(struct demux_internal *in)
|
|
|
|
{
|
|
|
|
if (!in->seekable_cache) {
|
|
|
|
clear_cached_range(in, in->current_range);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct demux_cached_range *range = talloc_ptrtype(in, range);
|
|
|
|
*range = (struct demux_cached_range){
|
|
|
|
.seek_start = MP_NOPTS_VALUE,
|
|
|
|
.seek_end = MP_NOPTS_VALUE,
|
|
|
|
};
|
|
|
|
MP_TARRAY_APPEND(in, in->ranges, in->num_ranges, range);
|
|
|
|
add_missing_streams(in, range);
|
|
|
|
|
|
|
|
switch_current_range(in, range);
|
|
|
|
}
|
|
|
|
|
2016-02-28 18:14:23 +00:00
|
|
|
int demux_seek(demuxer_t *demuxer, double seek_pts, int flags)
|
2008-04-12 15:51:08 +00:00
|
|
|
{
|
2014-07-21 17:27:24 +00:00
|
|
|
struct demux_internal *in = demuxer->in;
|
|
|
|
assert(demuxer == in->d_user);
|
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 21:28:08 +00:00
|
|
|
int res = 0;
|
2014-07-21 17:27:24 +00: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 21:28:08 +00:00
|
|
|
pthread_mutex_lock(&in->lock);
|
2012-12-08 12:12:46 +00:00
|
|
|
|
2016-02-28 18:14:23 +00:00
|
|
|
if (seek_pts == MP_NOPTS_VALUE)
|
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 21:28:08 +00:00
|
|
|
goto done;
|
2014-07-16 20:40:21 +00:00
|
|
|
|
2016-02-28 18:14:23 +00:00
|
|
|
MP_VERBOSE(in, "queuing seek to %f%s\n", seek_pts,
|
2015-06-18 20:31:55 +00:00
|
|
|
in->seeking ? " (cascade)" : "");
|
|
|
|
|
2017-10-21 17:26:33 +00:00
|
|
|
if (!(flags & SEEK_FACTOR))
|
|
|
|
seek_pts = MP_ADD_PTS(seek_pts, -in->ts_offset);
|
|
|
|
|
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 21:28:08 +00:00
|
|
|
bool require_cache = flags & SEEK_CACHED;
|
|
|
|
flags &= ~(unsigned)SEEK_CACHED;
|
|
|
|
|
|
|
|
struct demux_cached_range *cache_target =
|
|
|
|
find_cache_seek_target(in, seek_pts, flags);
|
|
|
|
|
|
|
|
if (!cache_target) {
|
|
|
|
if (require_cache) {
|
|
|
|
MP_VERBOSE(demuxer, "Cached seek not possible.\n");
|
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
if (!demuxer->seekable) {
|
|
|
|
MP_WARN(demuxer, "Cannot seek in this file.\n");
|
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
clear_reader_state(in);
|
|
|
|
|
|
|
|
in->eof = false;
|
|
|
|
in->last_eof = false;
|
|
|
|
in->idle = true;
|
|
|
|
in->reading = false;
|
|
|
|
|
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 21:28:08 +00:00
|
|
|
if (cache_target) {
|
|
|
|
execute_cache_seek(in, cache_target, seek_pts, flags);
|
|
|
|
} else {
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
switch_to_fresh_cache_range(in);
|
2017-10-21 17:26:33 +00:00
|
|
|
|
2017-10-13 22:16:32 +00:00
|
|
|
in->seeking = true;
|
|
|
|
in->seek_flags = flags;
|
|
|
|
in->seek_pts = seek_pts;
|
|
|
|
}
|
2001-08-12 17:28:16 +00:00
|
|
|
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
if (!in->threading && in->seeking)
|
|
|
|
execute_seek(in);
|
|
|
|
|
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 21:28:08 +00:00
|
|
|
res = 1;
|
|
|
|
|
|
|
|
done:
|
2014-07-21 17:27:24 +00:00
|
|
|
pthread_cond_signal(&in->wakeup);
|
|
|
|
pthread_mutex_unlock(&in->lock);
|
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 21:28:08 +00:00
|
|
|
return res;
|
2001-11-21 16:14:14 +00:00
|
|
|
}
|
2002-02-20 16:59:25 +00:00
|
|
|
|
2012-08-19 16:01:30 +00:00
|
|
|
struct sh_stream *demuxer_stream_by_demuxer_id(struct demuxer *d,
|
|
|
|
enum stream_type t, int id)
|
2008-04-12 15:51:08 +00:00
|
|
|
{
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
int num = demux_get_num_stream(d);
|
|
|
|
for (int n = 0; n < num; n++) {
|
|
|
|
struct sh_stream *s = demux_get_stream(d, n);
|
2012-08-19 16:01:30 +00:00
|
|
|
if (s->type == t && s->demuxer_id == id)
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
return s;
|
2010-05-22 05:19:23 +00:00
|
|
|
}
|
2012-08-19 16:01:30 +00:00
|
|
|
return NULL;
|
2005-04-03 14:08:28 +00:00
|
|
|
}
|
2006-08-06 18:55:34 +00:00
|
|
|
|
2017-11-10 02:56:24 +00:00
|
|
|
// An obscure mechanism to get stream switching to be executed "faster" (as
|
|
|
|
// perceived by the user), by making the stream return packets from the
|
|
|
|
// current position
|
|
|
|
// On a switch, it seeks back, and then grabs all packets that were
|
|
|
|
// "missing" from the packet queue of the newly selected stream.
|
2017-11-10 09:15:37 +00:00
|
|
|
static void initiate_refresh_seek(struct demux_internal *in,
|
|
|
|
struct demux_stream *stream,
|
|
|
|
double start_ts)
|
2017-11-10 02:56:24 +00:00
|
|
|
{
|
|
|
|
struct demuxer *demux = in->d_thread;
|
|
|
|
bool seekable = demux->desc->seek && demux->seekable &&
|
|
|
|
!demux->partially_seekable;
|
|
|
|
|
|
|
|
bool normal_seek = true;
|
|
|
|
bool refresh_possible = true;
|
|
|
|
for (int n = 0; n < in->num_streams; n++) {
|
|
|
|
struct demux_stream *ds = in->streams[n]->ds;
|
|
|
|
|
|
|
|
if (!ds->selected)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (ds->type == STREAM_VIDEO || ds->type == STREAM_AUDIO)
|
|
|
|
start_ts = MP_PTS_MIN(start_ts, ds->base_ts);
|
|
|
|
|
|
|
|
// If there were no other streams selected, we can use a normal seek.
|
2017-11-10 09:15:37 +00:00
|
|
|
normal_seek &= stream == ds;
|
2017-11-10 02:56:24 +00:00
|
|
|
|
|
|
|
refresh_possible &= ds->queue->correct_dts || ds->queue->correct_pos;
|
|
|
|
}
|
|
|
|
|
2017-11-10 09:15:37 +00:00
|
|
|
if (start_ts == MP_NOPTS_VALUE || !seekable)
|
2017-11-10 02:56:24 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
if (!normal_seek) {
|
|
|
|
if (!refresh_possible) {
|
|
|
|
MP_VERBOSE(in, "can't issue refresh seek\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (int n = 0; n < in->num_streams; n++) {
|
|
|
|
struct demux_stream *ds = in->streams[n]->ds;
|
demux: always discard cached packets on track switches
This fixes weird behavior in the following case:
- open a file
- make sure the max. demuxer forward cache is smaller than the
file's video track
- make sure the max. readahead duration is larger than the file's
duration
- disable the audio track
- seek to the beginning of the file
- once the cache has filled enable the audio track
- a queue overflow warning should appear
(- looking at the seek ranges is also interesting)
The queue overflow warning happens because the packed queue for the
video track will use up the full quota set by --demuxer-max-bytes. When
the audio track is enabled, reading an audio packet would technically
overflow the packet cache by the size of whatever packet is read next.
This means the demuxer signals EOF to the decoder, and once playback has
consumed enough video packets so that audio packets can be read again,
the decoder resumes from EOF. This interacts badly with A/V
synchronization and the whole thing can randomly crap itself until audio
has fully recovered.
We didn't care about this so far, but we want to raise the readahead
duration to something very high, so that the demuxer cache is fully
used. This means this case can be hit quite quickly by switching audio
or subtitle tracks, and is not really an obscure corner case anymore.
Fix this by always losing all cache. Since the cache can't be used
anyway until the newly selected track has been read, this is not much of
a disadvantage. The only thing that could be brought up is that
unselecting the track again could resume operation normally. (Maybe this
would be useful if network died completely without chance of recovery.
Then you could watch the already buffered video anyway by deselecting
the audio track again.) But given the headaches, this seems like the
better solution.
Unfortunately this requires adding new new strange fields and strangely
fragmenting state management functions again. I'm sure whoever works on
this in the future will hate me. Currently it seems like the lesser
evil, and much simpler and robust than the other potential solutions.
In case this needs to be revisited, here is a reminder for readers from
the future what alternative solutions were considered, without those
disadvantages:
A first attempted solution allowed the demuxer to buffer some additional
packets on track switching. This would allow it to read enough data to
feed the decoder at least. But it was still awkward, as it didn't allow
the demuxer to continue prefetching the newly selected track. It also
barely worked, because you could make the forward buffer "over full" by
seeking back with seekable cache enabled, and then it couldn't read
packets anyway.
As alternative solution, we could always demux and cache all tracks,
even if they're deselected. This would also not require a network-level
seek for the "refresh" logic (it's the thing that lets the video decoder
continue as if nothing happened, while actually seeking back in the
stream to get the missing audio packets, in the case of enabling a
previously disabled audio track). But it would also possibly waste
network and memory resources, depending on what the user actually wants.
A second solution would just account the queue sizes for each stream
separately. We could freely fill up the audio packet queue, even if the
video queue is full. Since the demuxer API returns interleaved packets
and doesn't let you predict which packet type comes next, this is not as
simple as it sounds, but it'd probably tie in nicely with the "refresh"
logic.
A third solution would be removing buffered video packets from the end
of the packet queue. Since the "refresh" logic gets these anyway, there
is no reason to keep them if they prevent the audio packet queue from
catching up with the video one. But this would require additional logic,
would interact badly with a bunch of other corner cases. And as far as
the code goes, it's rather complex, because all the logic is written
with FIFO behavior in mind (including the fact that the packet queue is
a singly linked list with no backwards links, making removal from the
end harder).
2017-12-17 20:34:50 +00:00
|
|
|
|
|
|
|
bool correct_pos = ds->queue->correct_pos;
|
|
|
|
bool correct_dts = ds->queue->correct_dts;
|
|
|
|
|
|
|
|
// We need to re-read all packets anyway, so discard the buffered
|
|
|
|
// data. (In theory, we could keep the packets, and be able to use
|
|
|
|
// it for seeking if partially read streams are deselected again,
|
|
|
|
// but this causes other problems like queue overflows when
|
|
|
|
// selecting a new stream.)
|
|
|
|
ds_clear_reader_queue_state(ds);
|
|
|
|
clear_queue(ds->queue);
|
|
|
|
|
2017-11-10 02:56:24 +00:00
|
|
|
// Streams which didn't have any packets yet will return all packets,
|
|
|
|
// other streams return packets only starting from the last position.
|
demux: always discard cached packets on track switches
This fixes weird behavior in the following case:
- open a file
- make sure the max. demuxer forward cache is smaller than the
file's video track
- make sure the max. readahead duration is larger than the file's
duration
- disable the audio track
- seek to the beginning of the file
- once the cache has filled enable the audio track
- a queue overflow warning should appear
(- looking at the seek ranges is also interesting)
The queue overflow warning happens because the packed queue for the
video track will use up the full quota set by --demuxer-max-bytes. When
the audio track is enabled, reading an audio packet would technically
overflow the packet cache by the size of whatever packet is read next.
This means the demuxer signals EOF to the decoder, and once playback has
consumed enough video packets so that audio packets can be read again,
the decoder resumes from EOF. This interacts badly with A/V
synchronization and the whole thing can randomly crap itself until audio
has fully recovered.
We didn't care about this so far, but we want to raise the readahead
duration to something very high, so that the demuxer cache is fully
used. This means this case can be hit quite quickly by switching audio
or subtitle tracks, and is not really an obscure corner case anymore.
Fix this by always losing all cache. Since the cache can't be used
anyway until the newly selected track has been read, this is not much of
a disadvantage. The only thing that could be brought up is that
unselecting the track again could resume operation normally. (Maybe this
would be useful if network died completely without chance of recovery.
Then you could watch the already buffered video anyway by deselecting
the audio track again.) But given the headaches, this seems like the
better solution.
Unfortunately this requires adding new new strange fields and strangely
fragmenting state management functions again. I'm sure whoever works on
this in the future will hate me. Currently it seems like the lesser
evil, and much simpler and robust than the other potential solutions.
In case this needs to be revisited, here is a reminder for readers from
the future what alternative solutions were considered, without those
disadvantages:
A first attempted solution allowed the demuxer to buffer some additional
packets on track switching. This would allow it to read enough data to
feed the decoder at least. But it was still awkward, as it didn't allow
the demuxer to continue prefetching the newly selected track. It also
barely worked, because you could make the forward buffer "over full" by
seeking back with seekable cache enabled, and then it couldn't read
packets anyway.
As alternative solution, we could always demux and cache all tracks,
even if they're deselected. This would also not require a network-level
seek for the "refresh" logic (it's the thing that lets the video decoder
continue as if nothing happened, while actually seeking back in the
stream to get the missing audio packets, in the case of enabling a
previously disabled audio track). But it would also possibly waste
network and memory resources, depending on what the user actually wants.
A second solution would just account the queue sizes for each stream
separately. We could freely fill up the audio packet queue, even if the
video queue is full. Since the demuxer API returns interleaved packets
and doesn't let you predict which packet type comes next, this is not as
simple as it sounds, but it'd probably tie in nicely with the "refresh"
logic.
A third solution would be removing buffered video packets from the end
of the packet queue. Since the "refresh" logic gets these anyway, there
is no reason to keep them if they prevent the audio packet queue from
catching up with the video one. But this would require additional logic,
would interact badly with a bunch of other corner cases. And as far as
the code goes, it's rather complex, because all the logic is written
with FIFO behavior in mind (including the fact that the packet queue is
a singly linked list with no backwards links, making removal from the
end harder).
2017-12-17 20:34:50 +00:00
|
|
|
if (ds->selected && (ds->last_ret_pos != -1 ||
|
|
|
|
ds->last_ret_dts != MP_NOPTS_VALUE))
|
|
|
|
{
|
|
|
|
ds->refreshing = true;
|
|
|
|
ds->queue->correct_dts = correct_dts;
|
|
|
|
ds->queue->correct_pos = correct_pos;
|
|
|
|
ds->queue->last_pos = ds->last_ret_pos;
|
|
|
|
ds->queue->last_dts = ds->last_ret_dts;
|
|
|
|
}
|
|
|
|
|
|
|
|
update_seek_ranges(in->current_range);
|
2017-11-10 02:56:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
start_ts -= 1.0; // small offset to get correct overlap
|
|
|
|
}
|
|
|
|
|
|
|
|
MP_VERBOSE(in, "refresh seek to %f\n", start_ts);
|
|
|
|
in->seeking = true;
|
|
|
|
in->seek_flags = SEEK_HR;
|
|
|
|
in->seek_pts = start_ts;
|
|
|
|
}
|
|
|
|
|
player: improve instant track switching
When switching tracks, we normally have the problem that data gets lost
due to readahead buffering. (Which in turn is because we're stubborn and
instruct the demuxers to discard data on unselected streams.) The
demuxer layer has a hack that re-reads discarded buffered data if a
stream is enabled mid-stream, so track switching will seem instant.
A somewhat similar problem is when all tracks of an external files were
disabled - when enabling the first track, we have to seek to the target
position.
Handle these with the same mechanism. Pass the "current time" to the
demuxer's stream switch function, and let the demuxer figure out what to
do. The demuxer will issue a refresh seek (if possible) to update the
new stream, or will issue a "normal" seek if there was no active stream
yet.
One case that changes is when a video/audio stream is enabled on an
external file with only a subtitle stream active, and the demuxer does
not support rrefresh seeks. This is a fuzzy case, because subtitles are
sparse, and the demuxer might have skipped large amounts of data. We
used to seek (and send the subtitle decoder some subtitle packets
twice). This case is sort of obscure and insane, and the fix would be
questionable, so we simply don't care.
Should mostly fix #3392.
2016-08-06 13:47:04 +00:00
|
|
|
// Set whether the given stream should return packets.
|
|
|
|
// ref_pts is used only if the stream is enabled. Then it serves as approximate
|
|
|
|
// start pts for this stream (in the worst case it is ignored).
|
2013-07-11 17:22:24 +00:00
|
|
|
void demuxer_select_track(struct demuxer *demuxer, struct sh_stream *stream,
|
player: improve instant track switching
When switching tracks, we normally have the problem that data gets lost
due to readahead buffering. (Which in turn is because we're stubborn and
instruct the demuxers to discard data on unselected streams.) The
demuxer layer has a hack that re-reads discarded buffered data if a
stream is enabled mid-stream, so track switching will seem instant.
A somewhat similar problem is when all tracks of an external files were
disabled - when enabling the first track, we have to seek to the target
position.
Handle these with the same mechanism. Pass the "current time" to the
demuxer's stream switch function, and let the demuxer figure out what to
do. The demuxer will issue a refresh seek (if possible) to update the
new stream, or will issue a "normal" seek if there was no active stream
yet.
One case that changes is when a video/audio stream is enabled on an
external file with only a subtitle stream active, and the demuxer does
not support rrefresh seeks. This is a fuzzy case, because subtitles are
sparse, and the demuxer might have skipped large amounts of data. We
used to seek (and send the subtitle decoder some subtitle packets
twice). This case is sort of obscure and insane, and the fix would be
questionable, so we simply don't care.
Should mostly fix #3392.
2016-08-06 13:47:04 +00:00
|
|
|
double ref_pts, bool selected)
|
2013-07-11 17:22:24 +00:00
|
|
|
{
|
demux: hack for instant stream switching
This removes the delay when switching audio tracks in mkv or mp4 files.
Other formats are not enabled, because it's not clear whether the
demuxers fulfill the requirements listed in demux.h. (Many formats
definitely do not with libavformat.)
Background:
The demuxer packet cache buffers a certain amount of packets. This
includes only packets from selected streams. We discard packets from
other streams for various reasons. This introduces a problem: switching
to a different audio track introduces a delay. The delay is as big as
the demuxer packet cache buffer, because while the file was read ahead
to fill the packet buffer, the process of reading packets also discarded
all packets from the previously not selected audio stream. Once the
remaining packet buffer has been played, new audio packets are available
and you hear audio again.
We could probably just not discard packets from unselected streams. But
this would require additional memory and CPU resources, and also it's
hard to tell when packets from unused streams should be discarded (we
don't want to keep them forever; it'd be a memory leak).
We could also issue a player hr-seek to the current playback position,
which would solve the problem in 1 line of code or so. But this can be
rather slow.
So what we do in this commit instead is: we just seek back to the
position where our current packet buffer starts, and start demuxing from
this position again. This way we can get the "past" packets for the
newly selected stream. For streams which were already selected the
packets are simply discarded until the previous position is reached
again.
That latter part is the hard part. We really want to skip packets
exactly until the position where we left off previously, or we will skip
packets or feed packets to the decoder twice. If we assume that the
demuxer is deterministic (returns exactly the same packets after a seek
to a previous position), then we can try to check whether it's the same
packet as the one at the end of the packet buffer. If it is, we know
that the packet after it is where we left off last time.
Unfortunately, this is not very robust, and maybe it can't be made
robust. Currently we use the demux_packet.pos field as unique packet
ID - which works fine in some scenarios, but will break in arbitrary
ways if the basic requirement to the demuxer (as listed in the demux.h
additions) are broken. Thus, this is enabled only for the internal mkv
demuxer and the libavformat mp4 demuxer.
(libavformat mkv does not work, because the packet positions are not
unique. Probably could be fixed upstream, but it's not clear whether
it's a bug or a feature.)
2015-02-13 20:17:17 +00:00
|
|
|
struct demux_internal *in = demuxer->in;
|
2017-11-10 09:15:37 +00:00
|
|
|
struct demux_stream *ds = stream->ds;
|
demux: hack for instant stream switching
This removes the delay when switching audio tracks in mkv or mp4 files.
Other formats are not enabled, because it's not clear whether the
demuxers fulfill the requirements listed in demux.h. (Many formats
definitely do not with libavformat.)
Background:
The demuxer packet cache buffers a certain amount of packets. This
includes only packets from selected streams. We discard packets from
other streams for various reasons. This introduces a problem: switching
to a different audio track introduces a delay. The delay is as big as
the demuxer packet cache buffer, because while the file was read ahead
to fill the packet buffer, the process of reading packets also discarded
all packets from the previously not selected audio stream. Once the
remaining packet buffer has been played, new audio packets are available
and you hear audio again.
We could probably just not discard packets from unselected streams. But
this would require additional memory and CPU resources, and also it's
hard to tell when packets from unused streams should be discarded (we
don't want to keep them forever; it'd be a memory leak).
We could also issue a player hr-seek to the current playback position,
which would solve the problem in 1 line of code or so. But this can be
rather slow.
So what we do in this commit instead is: we just seek back to the
position where our current packet buffer starts, and start demuxing from
this position again. This way we can get the "past" packets for the
newly selected stream. For streams which were already selected the
packets are simply discarded until the previous position is reached
again.
That latter part is the hard part. We really want to skip packets
exactly until the position where we left off previously, or we will skip
packets or feed packets to the decoder twice. If we assume that the
demuxer is deterministic (returns exactly the same packets after a seek
to a previous position), then we can try to check whether it's the same
packet as the one at the end of the packet buffer. If it is, we know
that the packet after it is where we left off last time.
Unfortunately, this is not very robust, and maybe it can't be made
robust. Currently we use the demux_packet.pos field as unique packet
ID - which works fine in some scenarios, but will break in arbitrary
ways if the basic requirement to the demuxer (as listed in the demux.h
additions) are broken. Thus, this is enabled only for the internal mkv
demuxer and the libavformat mp4 demuxer.
(libavformat mkv does not work, because the packet positions are not
unique. Probably could be fixed upstream, but it's not clear whether
it's a bug or a feature.)
2015-02-13 20:17:17 +00:00
|
|
|
pthread_mutex_lock(&in->lock);
|
|
|
|
// don't flush buffers if stream is already selected / unselected
|
2017-11-10 09:15:37 +00:00
|
|
|
if (ds->selected != selected) {
|
demux: fix accounting for seekable ranges on track switches
This fixes missing audio when cycling through audio tracks with anything
that uses nested demuxers, such as demux_timeline, which us used for
EDL, --merge-files, ordered chapters, and youtube-dl pseudo DASH
support. When this bug happened, reenabling an audio track would lead to
silence for the duration of the readahead amount.
The underlying reason is the incorrectly updated buffered range on track
switch. It accidentally included the amount covered by the deselected
stream. But the cause of the observed effect was that demux_timeline
issued a refresh seek to the underlying slave demuxer, which in turn
thought it could do a cache seek, because the seek range still included
everything.
update_stream_selection_state() calls update_seek_ranges() to update the
seek ranges after a track switch. When reenabling the track, ds->eager
was set to false during update_seek_ranges(), which made it think the
stream was sparse, and thus it didn't restrict the current seek range
(making later code think everything was buffered). Fix this by moving
some code, so we first update the ds->eager flag, then the seek ranges.
Also verbose log the low level stream selection calls.
2017-12-10 03:43:25 +00:00
|
|
|
MP_VERBOSE(in, "%sselect track %d\n", selected ? "" : "de", stream->index);
|
2017-11-10 09:15:37 +00:00
|
|
|
ds->selected = selected;
|
|
|
|
update_stream_selection_state(in, ds);
|
2016-01-18 17:21:29 +00:00
|
|
|
in->tracks_switched = true;
|
2017-11-10 09:15:37 +00:00
|
|
|
if (ds->selected && !in->initial_state)
|
|
|
|
initiate_refresh_seek(in, ds, MP_ADD_PTS(ref_pts, -in->ts_offset));
|
2016-01-18 17:21:29 +00:00
|
|
|
if (in->threading) {
|
|
|
|
pthread_cond_signal(&in->wakeup);
|
|
|
|
} else {
|
|
|
|
execute_trackswitch(in);
|
|
|
|
}
|
2013-07-11 17:20:25 +00:00
|
|
|
}
|
demux: hack for instant stream switching
This removes the delay when switching audio tracks in mkv or mp4 files.
Other formats are not enabled, because it's not clear whether the
demuxers fulfill the requirements listed in demux.h. (Many formats
definitely do not with libavformat.)
Background:
The demuxer packet cache buffers a certain amount of packets. This
includes only packets from selected streams. We discard packets from
other streams for various reasons. This introduces a problem: switching
to a different audio track introduces a delay. The delay is as big as
the demuxer packet cache buffer, because while the file was read ahead
to fill the packet buffer, the process of reading packets also discarded
all packets from the previously not selected audio stream. Once the
remaining packet buffer has been played, new audio packets are available
and you hear audio again.
We could probably just not discard packets from unselected streams. But
this would require additional memory and CPU resources, and also it's
hard to tell when packets from unused streams should be discarded (we
don't want to keep them forever; it'd be a memory leak).
We could also issue a player hr-seek to the current playback position,
which would solve the problem in 1 line of code or so. But this can be
rather slow.
So what we do in this commit instead is: we just seek back to the
position where our current packet buffer starts, and start demuxing from
this position again. This way we can get the "past" packets for the
newly selected stream. For streams which were already selected the
packets are simply discarded until the previous position is reached
again.
That latter part is the hard part. We really want to skip packets
exactly until the position where we left off previously, or we will skip
packets or feed packets to the decoder twice. If we assume that the
demuxer is deterministic (returns exactly the same packets after a seek
to a previous position), then we can try to check whether it's the same
packet as the one at the end of the packet buffer. If it is, we know
that the packet after it is where we left off last time.
Unfortunately, this is not very robust, and maybe it can't be made
robust. Currently we use the demux_packet.pos field as unique packet
ID - which works fine in some scenarios, but will break in arbitrary
ways if the basic requirement to the demuxer (as listed in the demux.h
additions) are broken. Thus, this is enabled only for the internal mkv
demuxer and the libavformat mp4 demuxer.
(libavformat mkv does not work, because the packet positions are not
unique. Probably could be fixed upstream, but it's not clear whether
it's a bug or a feature.)
2015-02-13 20:17:17 +00:00
|
|
|
pthread_mutex_unlock(&in->lock);
|
2014-07-16 20:40:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void demux_set_stream_autoselect(struct demuxer *demuxer, bool autoselect)
|
|
|
|
{
|
|
|
|
assert(!demuxer->in->threading); // laziness
|
|
|
|
demuxer->in->autoselect = autoselect;
|
2006-11-16 21:23:06 +00:00
|
|
|
}
|
|
|
|
|
2017-10-21 17:26:33 +00:00
|
|
|
// This is for demuxer implementations only. demuxer_select_track() sets the
|
|
|
|
// logical state, while this function returns the actual state (in case the
|
|
|
|
// demuxer attempts to cache even unselected packets for track switching - this
|
|
|
|
// will potentially be done in the future).
|
2014-07-06 17:02:21 +00:00
|
|
|
bool demux_stream_is_selected(struct sh_stream *stream)
|
2013-04-14 17:19:35 +00:00
|
|
|
{
|
2014-07-16 20:40:21 +00:00
|
|
|
if (!stream)
|
|
|
|
return false;
|
|
|
|
bool r = false;
|
|
|
|
pthread_mutex_lock(&stream->ds->in->lock);
|
|
|
|
r = stream->ds->selected;
|
|
|
|
pthread_mutex_unlock(&stream->ds->in->lock);
|
|
|
|
return r;
|
2013-04-14 17:19:35 +00:00
|
|
|
}
|
|
|
|
|
2015-06-24 12:18:51 +00:00
|
|
|
int demuxer_add_attachment(demuxer_t *demuxer, char *name, char *type,
|
|
|
|
void *data, size_t data_size)
|
2008-04-12 15:51:08 +00:00
|
|
|
{
|
2010-01-26 01:31:31 +00:00
|
|
|
if (!(demuxer->num_attachments % 32))
|
|
|
|
demuxer->attachments = talloc_realloc(demuxer, demuxer->attachments,
|
|
|
|
struct demux_attachment,
|
|
|
|
demuxer->num_attachments + 32);
|
|
|
|
|
2015-06-24 12:18:51 +00:00
|
|
|
struct demux_attachment *att = &demuxer->attachments[demuxer->num_attachments];
|
|
|
|
att->name = talloc_strdup(demuxer->attachments, name);
|
|
|
|
att->type = talloc_strdup(demuxer->attachments, type);
|
|
|
|
att->data = talloc_memdup(demuxer->attachments, data, data_size);
|
|
|
|
att->data_size = data_size;
|
2008-01-12 01:12:36 +00:00
|
|
|
|
2008-04-12 15:51:08 +00:00
|
|
|
return demuxer->num_attachments++;
|
2008-01-12 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
2012-02-26 20:12:53 +00:00
|
|
|
static int chapter_compare(const void *p1, const void *p2)
|
|
|
|
{
|
|
|
|
struct demux_chapter *c1 = (void *)p1;
|
|
|
|
struct demux_chapter *c2 = (void *)p2;
|
|
|
|
|
2014-11-02 16:20:04 +00:00
|
|
|
if (c1->pts > c2->pts)
|
2012-02-26 20:12:53 +00:00
|
|
|
return 1;
|
2014-11-02 16:20:04 +00:00
|
|
|
else if (c1->pts < c2->pts)
|
2012-02-26 20:12:53 +00:00
|
|
|
return -1;
|
2013-04-12 11:20:37 +00:00
|
|
|
return c1->original_index > c2->original_index ? 1 :-1; // never equal
|
2012-02-26 20:12:53 +00:00
|
|
|
}
|
|
|
|
|
2014-07-16 20:40:21 +00:00
|
|
|
static void demuxer_sort_chapters(demuxer_t *demuxer)
|
2012-02-26 20:12:53 +00:00
|
|
|
{
|
|
|
|
qsort(demuxer->chapters, demuxer->num_chapters,
|
|
|
|
sizeof(struct demux_chapter), chapter_compare);
|
|
|
|
}
|
|
|
|
|
2015-06-24 12:18:51 +00:00
|
|
|
int demuxer_add_chapter(demuxer_t *demuxer, char *name,
|
2014-11-02 16:20:04 +00:00
|
|
|
double pts, uint64_t demuxer_id)
|
2008-04-12 15:51:08 +00:00
|
|
|
{
|
2013-04-12 11:38:20 +00:00
|
|
|
struct demux_chapter new = {
|
|
|
|
.original_index = demuxer->num_chapters,
|
2014-11-02 16:20:04 +00:00
|
|
|
.pts = pts,
|
2013-09-08 05:42:05 +00:00
|
|
|
.metadata = talloc_zero(demuxer, struct mp_tags),
|
|
|
|
.demuxer_id = demuxer_id,
|
2013-04-12 11:38:20 +00:00
|
|
|
};
|
2015-06-24 12:18:51 +00:00
|
|
|
mp_tags_set_str(new.metadata, "TITLE", name);
|
2013-04-12 11:38:20 +00:00
|
|
|
MP_TARRAY_APPEND(demuxer, demuxer->chapters, demuxer->num_chapters, new);
|
2014-02-06 12:43:01 +00:00
|
|
|
return demuxer->num_chapters - 1;
|
2013-09-08 05:42:05 +00:00
|
|
|
}
|
|
|
|
|
2017-12-10 04:07:36 +00:00
|
|
|
void demux_disable_cache(demuxer_t *demuxer)
|
|
|
|
{
|
|
|
|
struct demux_internal *in = demuxer->in;
|
|
|
|
assert(demuxer == in->d_user);
|
|
|
|
|
|
|
|
pthread_mutex_lock(&in->lock);
|
|
|
|
if (in->seekable_cache) {
|
|
|
|
MP_VERBOSE(demuxer, "disabling persistent packet cache\n");
|
|
|
|
in->seekable_cache = false;
|
|
|
|
|
|
|
|
// Get rid of potential buffered ranges floating around.
|
|
|
|
free_empty_cached_ranges(in);
|
|
|
|
// Get rid of potential old packets in the current range.
|
|
|
|
prune_old_packets(in);
|
|
|
|
}
|
|
|
|
pthread_mutex_unlock(&in->lock);
|
|
|
|
}
|
|
|
|
|
2018-01-17 06:07:15 +00:00
|
|
|
// Disallow reading any packets and make readers think there is no new data
|
|
|
|
// yet, until a seek is issued.
|
|
|
|
void demux_block_reading(struct demuxer *demuxer, bool block)
|
|
|
|
{
|
|
|
|
struct demux_internal *in = demuxer->in;
|
|
|
|
assert(demuxer == in->d_user);
|
|
|
|
|
|
|
|
pthread_mutex_lock(&in->lock);
|
|
|
|
in->blocked = block;
|
|
|
|
pthread_cond_signal(&in->wakeup);
|
|
|
|
pthread_mutex_unlock(&in->lock);
|
|
|
|
}
|
|
|
|
|
2014-10-24 13:56:45 +00:00
|
|
|
// must be called not locked
|
2014-07-16 20:40:21 +00:00
|
|
|
static void update_cache(struct demux_internal *in)
|
|
|
|
{
|
|
|
|
struct demuxer *demuxer = in->d_thread;
|
|
|
|
struct stream *stream = demuxer->stream;
|
|
|
|
|
2014-10-24 13:56:45 +00:00
|
|
|
// Don't lock while querying the stream.
|
|
|
|
struct mp_tags *stream_metadata = NULL;
|
2016-03-29 09:29:52 +00:00
|
|
|
struct stream_cache_info stream_cache_info = {.size = -1};
|
2014-10-24 13:56:45 +00:00
|
|
|
|
2015-08-17 22:10:54 +00:00
|
|
|
int64_t stream_size = stream_get_size(stream);
|
2014-10-24 13:56:45 +00:00
|
|
|
stream_control(stream, STREAM_CTRL_GET_METADATA, &stream_metadata);
|
2016-03-29 09:29:52 +00:00
|
|
|
stream_control(stream, STREAM_CTRL_GET_CACHE_INFO, &stream_cache_info);
|
2014-10-24 13:56:45 +00:00
|
|
|
|
|
|
|
pthread_mutex_lock(&in->lock);
|
|
|
|
in->stream_size = stream_size;
|
2016-03-29 09:29:52 +00:00
|
|
|
in->stream_cache_info = stream_cache_info;
|
2014-10-24 13:56:45 +00:00
|
|
|
if (stream_metadata) {
|
2014-07-16 20:40:21 +00:00
|
|
|
talloc_free(in->stream_metadata);
|
2014-10-24 13:56:45 +00:00
|
|
|
in->stream_metadata = talloc_steal(in, stream_metadata);
|
2014-07-16 20:40:21 +00:00
|
|
|
in->d_buffer->events |= DEMUX_EVENT_METADATA;
|
|
|
|
}
|
2014-10-24 13:56:45 +00:00
|
|
|
pthread_mutex_unlock(&in->lock);
|
2014-07-16 20:40:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// must be called locked
|
|
|
|
static int cached_stream_control(struct demux_internal *in, int cmd, void *arg)
|
|
|
|
{
|
2014-08-26 22:20:38 +00:00
|
|
|
// If the cache is active, wake up the thread to possibly update cache state.
|
2016-03-29 09:29:52 +00:00
|
|
|
if (in->stream_cache_info.size >= 0) {
|
2014-11-12 20:47:41 +00:00
|
|
|
in->force_cache_update = true;
|
2014-08-26 22:20:38 +00:00
|
|
|
pthread_cond_signal(&in->wakeup);
|
2014-11-12 20:47:41 +00:00
|
|
|
}
|
2014-08-26 22:20:38 +00:00
|
|
|
|
2014-07-16 20:40:21 +00:00
|
|
|
switch (cmd) {
|
2016-03-29 09:29:52 +00:00
|
|
|
case STREAM_CTRL_GET_CACHE_INFO:
|
|
|
|
if (in->stream_cache_info.size < 0)
|
2014-07-16 20:40:21 +00:00
|
|
|
return STREAM_UNSUPPORTED;
|
2016-03-29 09:29:52 +00:00
|
|
|
*(struct stream_cache_info *)arg = in->stream_cache_info;
|
2014-07-16 20:40:21 +00:00
|
|
|
return STREAM_OK;
|
|
|
|
case STREAM_CTRL_GET_SIZE:
|
|
|
|
if (in->stream_size < 0)
|
|
|
|
return STREAM_UNSUPPORTED;
|
|
|
|
*(int64_t *)arg = in->stream_size;
|
|
|
|
return STREAM_OK;
|
2014-10-24 13:40:01 +00:00
|
|
|
case STREAM_CTRL_GET_BASE_FILENAME:
|
|
|
|
if (!in->stream_base_filename)
|
|
|
|
return STREAM_UNSUPPORTED;
|
|
|
|
*(char **)arg = talloc_strdup(NULL, in->stream_base_filename);
|
|
|
|
return STREAM_OK;
|
2014-07-16 20:40:21 +00:00
|
|
|
}
|
|
|
|
return STREAM_ERROR;
|
|
|
|
}
|
|
|
|
|
|
|
|
// must be called locked
|
|
|
|
static int cached_demux_control(struct demux_internal *in, int cmd, void *arg)
|
|
|
|
{
|
|
|
|
switch (cmd) {
|
|
|
|
case DEMUXER_CTRL_STREAM_CTRL: {
|
|
|
|
struct demux_ctrl_stream_ctrl *c = arg;
|
|
|
|
int r = cached_stream_control(in, c->ctrl, c->arg);
|
|
|
|
if (r == STREAM_ERROR)
|
|
|
|
break;
|
|
|
|
c->res = r;
|
2017-06-19 15:54:02 +00:00
|
|
|
return CONTROL_OK;
|
2014-07-16 20:40:21 +00:00
|
|
|
}
|
2014-12-12 00:00:58 +00:00
|
|
|
case DEMUXER_CTRL_GET_BITRATE_STATS: {
|
|
|
|
double *rates = arg;
|
|
|
|
for (int n = 0; n < STREAM_TYPE_COUNT; n++)
|
2015-10-23 12:53:19 +00:00
|
|
|
rates[n] = -1;
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
for (int n = 0; n < in->num_streams; n++) {
|
|
|
|
struct demux_stream *ds = in->streams[n]->ds;
|
2015-10-23 12:53:19 +00:00
|
|
|
if (ds->selected && ds->bitrate >= 0)
|
|
|
|
rates[ds->type] = MPMAX(0, rates[ds->type]) + ds->bitrate;
|
2014-12-12 00:00:58 +00:00
|
|
|
}
|
2017-06-19 15:54:02 +00:00
|
|
|
return CONTROL_OK;
|
2014-12-12 00:00:58 +00: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-26 23:13:20 +00:00
|
|
|
case DEMUXER_CTRL_GET_READER_STATE: {
|
|
|
|
struct demux_ctrl_reader_state *r = arg;
|
|
|
|
*r = (struct demux_ctrl_reader_state){
|
|
|
|
.eof = in->last_eof,
|
2017-10-21 17:26:33 +00:00
|
|
|
.ts_reader = MP_NOPTS_VALUE,
|
2017-11-04 22:02:25 +00:00
|
|
|
.ts_end = MP_NOPTS_VALUE,
|
2014-08-27 20:42:28 +00:00
|
|
|
.ts_duration = -1,
|
2017-11-10 15:43:09 +00:00
|
|
|
.total_bytes = in->total_bytes,
|
|
|
|
.fw_bytes = in->fw_bytes,
|
2018-01-05 15:41:16 +00:00
|
|
|
.seeking = in->seeking_in_progress,
|
|
|
|
.low_level_seeks = in->low_level_seeks,
|
|
|
|
.ts_last = in->demux_ts,
|
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-26 23:13:20 +00:00
|
|
|
};
|
2017-10-25 10:41:22 +00:00
|
|
|
bool any_packets = false;
|
demux: remove weird tripple-buffering for the sh_stream list
The demuxer infrastructure was originally single-threaded. To make it
suitable for multithreading (specifically, demuxing and decoding on
separate threads), some sort of tripple-buffering was introduced. There
are separate "struct demuxer" allocations. The demuxer thread sets the
state on d_thread. If anything changes, the state is copied to d_buffer
(the copy is protected by a lock), and the decoder thread is notified.
Then the decoder thread copies the state from d_buffer to d_user (again
while holding a lock). This avoids the need for locking in the
demuxer/decoder code itself (only demux.c needs an internal, "invisible"
lock.)
Remove the streams/num_streams fields from this tripple-buffering
schema. Move them to the internal struct, and protect them with the
internal lock. Use accessors for read access outside of demux.c.
Other than replacing all field accesses with accessors, this separates
allocating and adding sh_streams. This is needed to avoid race
conditions. Before this change, this was awkwardly handled by first
initializing the sh_stream, and then sending a stream change event. Now
the stream is allocated, then initialized, and then declared as
immutable and added (at which point it becomes visible to the decoder
thread immediately).
This change is useful for PR #2626. And eventually, we should probably
get entirely of the tripple buffering, and this makes a nice first step.
2015-12-23 20:44:53 +00:00
|
|
|
for (int n = 0; n < in->num_streams; n++) {
|
|
|
|
struct demux_stream *ds = in->streams[n]->ds;
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
if (ds->eager && !(!ds->queue->head && ds->eof) && !ds->ignore_eof)
|
2017-10-21 17:26:33 +00:00
|
|
|
{
|
|
|
|
r->underrun |= !ds->reader_head && !ds->eof;
|
|
|
|
r->ts_reader = MP_PTS_MAX(r->ts_reader, ds->base_ts);
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
r->ts_end = MP_PTS_MAX(r->ts_end, ds->queue->last_ts);
|
2017-11-04 22:39:04 +00:00
|
|
|
any_packets |= !!ds->queue->head;
|
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-26 23:13:20 +00:00
|
|
|
}
|
|
|
|
}
|
2014-08-27 20:42:45 +00:00
|
|
|
r->idle = (in->idle && !r->underrun) || r->eof;
|
2014-08-27 20:51:06 +00:00
|
|
|
r->underrun &= !r->idle;
|
2017-10-30 13:26:54 +00:00
|
|
|
r->ts_reader = MP_ADD_PTS(r->ts_reader, in->ts_offset);
|
2017-11-04 22:02:25 +00:00
|
|
|
r->ts_end = MP_ADD_PTS(r->ts_end, in->ts_offset);
|
|
|
|
if (r->ts_reader != MP_NOPTS_VALUE && r->ts_reader <= r->ts_end)
|
|
|
|
r->ts_duration = r->ts_end - r->ts_reader;
|
2017-10-25 13:51:39 +00:00
|
|
|
if (in->seeking || !any_packets)
|
2017-10-23 17:36:20 +00:00
|
|
|
r->ts_duration = 0;
|
2017-11-10 03:35:55 +00:00
|
|
|
for (int n = 0; n < MPMIN(in->num_ranges, MAX_SEEK_RANGES); n++) {
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
struct demux_cached_range *range = in->ranges[n];
|
2017-11-10 03:35:55 +00:00
|
|
|
if (range->seek_start != MP_NOPTS_VALUE) {
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
r->seek_ranges[r->num_seek_ranges++] =
|
|
|
|
(struct demux_seek_range){
|
|
|
|
.start = MP_ADD_PTS(range->seek_start, in->ts_offset),
|
|
|
|
.end = MP_ADD_PTS(range->seek_end, in->ts_offset),
|
|
|
|
};
|
2017-11-04 22:39:04 +00:00
|
|
|
}
|
2017-10-30 13:26:54 +00:00
|
|
|
}
|
2017-06-19 15:54:02 +00:00
|
|
|
return CONTROL_OK;
|
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-26 23:13:20 +00:00
|
|
|
}
|
2014-07-16 20:40:21 +00:00
|
|
|
}
|
2017-06-19 15:54:02 +00:00
|
|
|
return CONTROL_UNKNOWN;
|
2014-07-16 20:40:21 +00:00
|
|
|
}
|
|
|
|
|
2016-03-09 22:55:16 +00:00
|
|
|
struct demux_control_args {
|
|
|
|
struct demuxer *demuxer;
|
|
|
|
int cmd;
|
|
|
|
void *arg;
|
|
|
|
int *r;
|
|
|
|
};
|
|
|
|
|
|
|
|
static void thread_demux_control(void *p)
|
2014-07-16 20:40:21 +00:00
|
|
|
{
|
2016-03-09 22:55:16 +00:00
|
|
|
struct demux_control_args *args = p;
|
|
|
|
struct demuxer *demuxer = args->demuxer;
|
|
|
|
int cmd = args->cmd;
|
|
|
|
void *arg = args->arg;
|
2014-07-16 20:40:21 +00:00
|
|
|
struct demux_internal *in = demuxer->in;
|
2017-06-19 15:54:02 +00:00
|
|
|
int r = CONTROL_UNKNOWN;
|
2016-03-09 22:55:16 +00:00
|
|
|
|
2014-07-16 20:40:21 +00:00
|
|
|
if (cmd == DEMUXER_CTRL_STREAM_CTRL) {
|
|
|
|
struct demux_ctrl_stream_ctrl *c = arg;
|
2014-08-11 13:53:01 +00:00
|
|
|
if (in->threading)
|
|
|
|
MP_VERBOSE(demuxer, "blocking for STREAM_CTRL %d\n", c->ctrl);
|
2014-07-16 20:40:21 +00:00
|
|
|
c->res = stream_control(demuxer->stream, c->ctrl, c->arg);
|
|
|
|
if (c->res != STREAM_UNSUPPORTED)
|
2017-06-19 15:54:02 +00:00
|
|
|
r = CONTROL_OK;
|
2014-07-16 20:40:21 +00:00
|
|
|
}
|
2017-06-19 15:54:02 +00:00
|
|
|
if (r != CONTROL_OK) {
|
2014-08-11 13:53:01 +00:00
|
|
|
if (in->threading)
|
|
|
|
MP_VERBOSE(demuxer, "blocking for DEMUXER_CTRL %d\n", cmd);
|
2014-07-16 20:40:21 +00:00
|
|
|
if (demuxer->desc->control)
|
|
|
|
r = demuxer->desc->control(demuxer->in->d_thread, cmd, arg);
|
|
|
|
}
|
2016-03-09 22:55:16 +00:00
|
|
|
|
|
|
|
*args->r = r;
|
|
|
|
}
|
|
|
|
|
|
|
|
int demux_control(demuxer_t *demuxer, int cmd, void *arg)
|
|
|
|
{
|
|
|
|
struct demux_internal *in = demuxer->in;
|
2017-01-21 16:19:01 +00:00
|
|
|
assert(demuxer == in->d_user);
|
2016-03-09 22:55:16 +00:00
|
|
|
|
|
|
|
if (in->threading) {
|
|
|
|
pthread_mutex_lock(&in->lock);
|
|
|
|
int cr = cached_demux_control(in, cmd, arg);
|
|
|
|
pthread_mutex_unlock(&in->lock);
|
2017-06-19 15:54:02 +00:00
|
|
|
if (cr != CONTROL_UNKNOWN)
|
2016-03-09 22:55:16 +00:00
|
|
|
return cr;
|
|
|
|
}
|
|
|
|
|
|
|
|
int r = 0;
|
|
|
|
struct demux_control_args args = {demuxer, cmd, arg, &r};
|
2016-03-09 23:06:13 +00:00
|
|
|
if (in->threading) {
|
|
|
|
MP_VERBOSE(in, "blocking on demuxer thread\n");
|
|
|
|
pthread_mutex_lock(&in->lock);
|
|
|
|
while (in->run_fn)
|
|
|
|
pthread_cond_wait(&in->wakeup, &in->lock);
|
2017-01-21 16:19:01 +00:00
|
|
|
in->run_fn = thread_demux_control;
|
|
|
|
in->run_fn_arg = &args;
|
2016-03-09 23:06:13 +00:00
|
|
|
pthread_cond_signal(&in->wakeup);
|
|
|
|
while (in->run_fn)
|
|
|
|
pthread_cond_wait(&in->wakeup, &in->lock);
|
|
|
|
pthread_mutex_unlock(&in->lock);
|
|
|
|
} else {
|
2017-01-21 16:19:01 +00:00
|
|
|
thread_demux_control(&args);
|
2016-03-09 23:06:13 +00:00
|
|
|
}
|
2017-01-21 16:19:01 +00:00
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
int demux_stream_control(demuxer_t *demuxer, int ctrl, void *arg)
|
|
|
|
{
|
|
|
|
struct demux_ctrl_stream_ctrl c = {ctrl, arg, STREAM_UNSUPPORTED};
|
|
|
|
demux_control(demuxer, DEMUXER_CTRL_STREAM_CTRL, &c);
|
|
|
|
return c.res;
|
2016-03-09 22:55:16 +00:00
|
|
|
}
|
|
|
|
|
2015-03-09 21:32:04 +00:00
|
|
|
bool demux_cancel_test(struct demuxer *demuxer)
|
|
|
|
{
|
|
|
|
return mp_cancel_test(demuxer->stream->cancel);
|
|
|
|
}
|
|
|
|
|
2014-11-02 16:20:04 +00:00
|
|
|
struct demux_chapter *demux_copy_chapter_data(struct demux_chapter *c, int num)
|
|
|
|
{
|
|
|
|
struct demux_chapter *new = talloc_array(NULL, struct demux_chapter, num);
|
|
|
|
for (int n = 0; n < num; n++) {
|
|
|
|
new[n] = c[n];
|
2015-08-12 09:10:45 +00:00
|
|
|
new[n].metadata = mp_tags_dup(new, new[n].metadata);
|
2014-11-02 16:20:04 +00:00
|
|
|
}
|
|
|
|
return new;
|
|
|
|
}
|