Commit Graph

13 Commits

Author SHA1 Message Date
wm4 b787a4121a demux_timeline: always signal new segment after a seek
This is needed to put the decoders into the correct state. In
particular, decoders will not initialize the current segment without
this flag. The intention of not setting the flag for seeks within the
segments were to avoid costly decoder reinits, but it seems this is
better handled explicitly in the decoder wrappers.
2016-11-09 16:44:06 +01:00
wm4 39ae261cc5 demux_timeline: enable refresh seeks in some situations
Play a trick to make the packet pos field monotonically increasing over
segment boundaries if the source demuxers return monotonically
increasing pos values. This allows the demuxer to uniquely identify
packets with the pos field, and can do refresh seeks using that.

Normally, the packet pos field is used as a fallback for determining the
playback position if the demuxer returns no proper duration. But
demux_timeline.c always will, and the packet pos fields usually make no
sense in relation to the returned file size anyway if the timeline
source demuxers originate from separate streams.
2016-08-07 13:53:34 +02:00
wm4 d41f0a54b0 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 15:47:04 +02:00
wm4 6e45e1de77 demux_timeline: restore mkv edition switching 2016-07-14 18:26:58 +02:00
wm4 dafafc90de demux_timeline: request subtitle prefetching on crossing segments
SEEK_HR is interpreted by demux_mkv.c, and enables subtitle preroll by
prefetching additional subtitle pakcets which might overlap with the
seek destination. This should make the case work when segment boundaries
fall into the middle of subtitle events.

This still usually leaves a flicker of at least 1 frame on start,
because dec_sub.c does not ensure that enough subtitles are read before
rendering after a segment switch. (Probably a WONTFIX.)
2016-03-25 17:27:02 +01:00
wm4 fd57503890 demux_timeline: skip decoder reinit when seeking to same segment
"Normal" seeks, which don't actually switch the segment, do not need to
reinit the decoders.
2016-03-17 21:32:41 +01:00
wm4 a6f8a6977e demux_timeline: set correct seekable flags
Tricky misleading crap.

Fixes #2898.
2016-03-03 15:31:44 +01:00
wm4 92ba630796 demux: remove relative seeking
Ever since a change in mplayer2 or so, relative seeks were translated to
absolute seeks before sending them to the demuxer in most cases. The
only exception in current mpv is DVD seeking.

Remove the SEEK_ABSOLUTE flag; it's not the implied default. SEEK_FACTOR
is kept, because it's sometimes slightly useful for seeking in things
like transport streams. (And maybe mkv files without duration set?)

DVD seeking is terrible because DVD and libdvdnav are terrible, but
mostly because libdvdnav is terrible. libdvdnav does not expose seeking
with seek tables. (Although I know xbmc/kodi use an undocumented API
that is not declared in the headers by dladdr()ing it - I think the
function is dvdnav_jump_to_sector_by_time().) With the current mpv
policy if not giving a shit about DVD, just revert our half-working seek
hacks and always use dvdnav_time_search(). Relative seeking might get
stuck sometimes; in this case --hr-seek=always is recommended.
2016-02-28 19:28:34 +01:00
wm4 08dbaf1dcc demux_timeline: slightly improve reported file format
Report the underlying demuxer's format. Since there can be many demuxers
participating, pick the "main" segment.
2016-02-25 22:49:50 +01:00
wm4 297fdcc095 demux_timeline: fix nested timelines
You can e.g. reference ordered chapters or other EDL files in EDLs.
There were some bugs left which broke this in some cases.
2016-02-20 16:22:15 +01:00
wm4 ce0b99314b demux_timeline: cosmetics: move a function
Gets rid of a forward declaration.
2016-02-16 21:06:02 +01:00
wm4 3c3cd0c540 demux_timeline: disable cache for inactive segments
This is achieved indirectly by deslecting all streams for the non-
current segment (and if the segment doesn't share the demuxer with the
currently active one).

Restores functionality added with commit 46bcdb70.
2016-02-16 21:05:18 +01:00
wm4 0af5335383 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 21:04:07 +01:00