path: root/demux/demux_timeline.c
Commit message (Collapse)AuthorAgeFilesLines
* ytdl_hook, edl: implement pseudo-DASH supportwm42017-02-041-18/+80
| | | | | | | | | We use the metadata provided by youtube-dl to sort-of implement fragmented DASH streaming. This is all a bit hacky, but hopefully a makeshift solution until libavformat has proper mechanisms. (Although in danger of being one of those temporary hacks that become permanent.)
* demux_timeline: move code aroundwm42017-02-041-41/+41
| | | | Cosmetic preparation for later changes.
* player: different way to auto-enable the demuxer cachewm42017-02-021-0/+2
| | | | | | | | | | | | | | | Instead of enabling it only when a stream-cache is enabled, also try to enable it independently from that if the demuxer is marked as is_network. Also add some code to the EDL code, so EDLs containing network streams are automatically cached this way. Extend the OSD info line so that it shows the demuxer cache in this case (more or less). I didn't find where or whether options.rst describes how the demuxer cache is enabled, so no changes there.
* demux_timeline: always signal new segment after a seekwm42016-11-091-3/+1
| | | | | | | | 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.
* demux_timeline: enable refresh seeks in some situationswm42016-08-071-0/+5
| | | | | | | | | | | | | 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.
* player: improve instant track switchingwm42016-08-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* demux_timeline: restore mkv edition switchingwm42016-07-141-0/+3
* demux_timeline: request subtitle prefetching on crossing segmentswm42016-03-251-1/+1
| | | | | | | | | | | 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.)
* demux_timeline: skip decoder reinit when seeking to same segmentwm42016-03-171-5/+3
| | | | | "Normal" seeks, which don't actually switch the segment, do not need to reinit the decoders.
* demux_timeline: set correct seekable flagswm42016-03-031-1/+1
| | | | | | Tricky misleading crap. Fixes #2898.
* demux: remove relative seekingwm42016-02-281-15/+3
| | | | | | | | | | | | | | | | | | | 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.
* demux_timeline: slightly improve reported file formatwm42016-02-251-1/+3
| | | | | Report the underlying demuxer's format. Since there can be many demuxers participating, pick the "main" segment.
* demux_timeline: fix nested timelineswm42016-02-201-1/+1
| | | | | You can e.g. reference ordered chapters or other EDL files in EDLs. There were some bugs left which broke this in some cases.
* demux_timeline: cosmetics: move a functionwm42016-02-161-26/+24
| | | | Gets rid of a forward declaration.
* demux_timeline: disable cache for inactive segmentswm42016-02-161-0/+8
| | | | | | | | 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.
* Rewrite ordered chapters and timeline stuffwm42016-02-151-0/+392
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.