summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* player: minor fix/simplification of OSD time/duration handlingwm42017-11-241-0/+1
| | | | | | | | | | Always display the duration as "unknown" if the duration is known. Also fix that at least demux_lavf reported unknown duration as 0 (fix by setting the default to unknown in demux.c). Remove the dumb _u formatter function, and use a different approach to avoiding displaying "unknown" as playback time on playback start (set last_seek_pts for that).
* demux_mkv: remove unnecessary parsing for vp9wm42017-11-171-5/+1
| | | | | | | We can finally get rid of this crap. Depends on a ffmpeg-mpv change. Always worked with Libav (ever since they fixed it properly).
* demux_lavf: always give libavformat the filename when probingwm42017-11-121-1/+1
| | | | | | | | | | | This gives the filename or URL to the libavformat probing logic, which might use the file extension as a "help" to decide which format the file is. This helps with mp3 files that have large id3v2 tags and prevents the idiotic ffmpeg probing logic to think that a mp3 file is amr. (What we really want is knowing whether we _really_ need to feed more data to libavformat to detect the format. And without having to pre-read excessive amounts of data for relatively normal streams.)
* demux_playlist: support .url fileswm42017-11-121-3/+15
| | | | Requested. Not tested due to lack of real samples. Fixes #5107.
* demux: avoid queue overflow warning when joining two rangeswm42017-11-111-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* demux: export demuxer cache sizes in byteswm42017-11-102-0/+4
| | | | | | Plus sort of document them, together with the already existing undocumented fields. (This is mostly for debugging, so use is discouraged.)
* demux: use seekable cache for network by default, bump prefetch limitwm42017-11-101-5/+11
| | | | | | | | The option for enabling it has now an "auto" choice, which is the default, and which will enable it if the media is thought to be via network or if the stream cache is enabled (same logic as --cache-secs). Also bump the --cache-secs default from 10 to 120.
* demux_mkv: fix potential uninitialized variable readwm42017-11-101-2/+3
|
* demux: set default back buffer to some high valuewm42017-11-101-1/+1
| | | | | | | Some back buffer is required to make the immediate forward range seekable. This is because the back buffer limit is strictly enforced. Just set a rather high back buffer by default. It's not use if --demuxer-seekable-cache is disabled, so this is without risk.
* demux: limit number of seek ranges to a static maximumwm42017-11-101-5/+20
| | | | | | | Limit the number of cached ranges to MAX_SEEK_RANGES, which is the same number of maximally exported seek ranges. It makes no sense to keep them, as the user won't see them anyway. Remove the smallest ones to enforce the limit if the number grows too high.
* demux: speed up cache seeking with a coarse indexwm42017-11-101-1/+54
| | | | | | | | | | | Helps a little bit, I guess. But in general, t(h)rashing the cache kills us anyway. This has a fixed number of index entries. Entries are added/removed as packets go through the packet queue. Only keyframes after index_distance seconds are added. If there are too many keyframe packets, the existing index is reduced by half, and index_distance is doubled. This should provide somewhat even spacing between the entries.
* demux: avoid wasting time by stopping packet search as early as possiblewm42017-11-101-1/+3
| | | | | | | | | | The packet queue is sorted, so we can stop the search if we have found a packet, and the next packet in the queue has a higher PTS than the seek PTS (for the sake of SEEK_FORWARD, we still consider the first packet with a higher PTS). Also, as a mostly cosmetic change, but which might be "faster", check target for NULL, instead of target_diff for a magic float value.
* demux: simplify remove_packet() functionwm42017-11-101-26/+12
| | | | Turns out this is only ever used to remove the head element anyway.
* demux: fix failure to join ranges with subtitles in some caseswm42017-11-101-4/+12
| | | | | | Subtitle streams are sparse, and no overlap is required to correctly join two cached ranges. This was not correctly handled iff the two ranges had different subtitle packets close to the join point.
* demux: reverse which range is reused when joining themwm42017-11-101-25/+22
| | | | | Which one to use doesn't really matter, but reusing the first one will probably be slightly more convenient later on.
* demux: fix a race condition with async seekingwm42017-11-101-3/+4
| | | | | | | | | | | demux_add_packet() must completely ignore any packets that are added while a queued seek is not initiated yet. The main issue is that after setting in->seeking==true, the central lock is released, and it can take "a while" until it's reacquired on the demux thread and the seek is actually initiated. During that time, packets could be read and added, that have nothing to do with the new state.
* demux: get rid of an unnecessary fieldwm42017-11-101-15/+13
|
* demux: attempt to accurately reflect seek range with muxed subtitleswm42017-11-101-5/+33
| | | | | | | | | | | | | | | | If subtitles are part of the stream, determining the seekable range becomes harder. Subtitles are sparse, and can have packets in irregular intervals, or even completely lack packets. The usual logic of computing the seek range by the min/max packet timestamps fails. Solve this by making the only assumption we can make: subtitle packets are implicitly demuxed along with other packets. We also assume perfect interleaving for this, but you really can't do anything with sparse packets that makes sense without this assumption. One special case is if we prune sparse packets within the current seekable range. Obviously this should limit the seekable range to after the pruned packet.
* demux: reduce indentation for two functionswm42017-11-101-37/+36
| | | | | Remove the single-exit, that added a huge if statement containing everything, just for some corner case.
* demux: some minor mostly cosmeticswm42017-11-101-13/+15
| | | | | None of these change functionality in any way (although the log level changes obviously change the terminal output).
* demux: simplify a functionwm42017-11-101-21/+19
| | | | | update_stream_selection_state() doesn't need all these arguments. Not sure what I was thinking here.
* demux: change how refreshes on track switching are handledwm42017-11-101-66/+59
| | | | | | Instead of weirdly deciding this on every packet read and having the code far away from where it's actually needed, just run it where it's actually needed.
* demux: get rid of weird backwards loopwm42017-11-101-1/+1
| | | | | | A typical idiom for calling functions that remove something from the array being iterated, but it's not needed here. I have no idea why this was ever done.
* demux: avoid broken readahead when joining rangeswm42017-11-101-4/+5
| | | | | | | | | | Setting ds->refreshing for unselected streams could lead to a nonsensical queue overflow warning, because read_packet() took it as a reason to continue reading. Also add some more information to the queue overflow warning (even if that one doesn't have anything to do with this bug - it was for unselected streams only).
* demux: reduce difference between threaded and non-threaded modewm42017-11-101-27/+35
| | | | | | | | | | | This fixes an endless loop with threading disabled, such as for example when playing a file with an external subtitle file, and seeking to the beginning. Something will set in->seeking, but the seek is never executed, which made demux_read_packet() loop endlessly. (External subtitles will use non-threaded mode for whatever reasons.) Fix this by by making the unthreaded code to execute the worker thread body, which reduces the difference in logic.
* demux: support multiple seekable cached rangeswm42017-11-092-224/+603
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* demux: explicitly discard 0 sized packetswm42017-11-061-1/+1
| | | | | | | libavcodec can't deal with them, because its API doesn't distinguish between 0 sized packets and sending EOF. As such, keeping them doesn't do any good, ever. This actually fixes some obscure mkv sample (see previous commit).
* demux_mkv: allow 0 sized packetswm42017-11-061-1/+1
| | | | | | | | | | Fixes some obscure sample that uses fixed size laces with 0-sized lace size. Some broken shit. (Maybe the decoder wouldn't care about these packets, but the demuxer attempted to resync after these packet reading errors, even though they were perfectly recoverable. But I don't care enough about this.) Sample link: https://samples.ffmpeg.org/Matroska/switzler084d_dl.mkv
* demux: slightly simplify pruningwm42017-11-061-7/+2
| | | | | We can compute the overhead size easily now - no need for awkward incremental updates to cached values on top of it.
* demux_mkv: rewrite packet reading to avoid 1 memcpy()wm42017-11-055-136/+132
| | | | | | | | | | | | | | | | | | | | | | | This directly reads individual mkv sub-packets (block laces) into a dedicated AVBufferRefs, which can be directly used for creating packets without a additional copy of the packet data. This also means we switch parsing of block header fields and lacing metadata to read directly from the stream, instead of a memory buffer. This could have been much easier if libavcodec didn't require padding the packet data with zero bytes. We could just have each packet reference a slice of the block data. But as it is, the only way to get padding without a copy is to read the laces into individually allocated (and padded) memory block, which required a larger rewrite. This probably makes recovering from broken mkv files slightly worse if the transport is unseekable. We just read, and then check if we've overread. But I think that shouldn't be a real concern. No actual measureable performance change. Potential for some regressions, as this is quite intrusive, and touches weird obscure shit like mkv lacing. Still keeping it because I like how it removes some redundant EBML parsing functions.
* demux: refactoring in preparation for multiple seek range supportwm42017-11-041-83/+214
| | | | | | | | | | | This adds a bunch of stuff (mostly unused or redundant) as preparation for supporting multiple seek ranges. Actual support is probably still far away. One change that messes deeper with the actual code is that we account for total buffered bytes instead of just the backwards bytes now. This way, prune_old_packets() doesn't have to iterate over all seek ranges to determine whether something needs pruning.
* demux: improve and optimize cache pruning and seek range determinationwm42017-11-043-85/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | The main purpose of this commit is avoiding any hidden O(n^2) algorithms in the code for pruning the demuxer cache, and for determining the seekable boundaries of the cache. The old code could loop over the whole packet queue on every packet pruned in certain corner cases. There are two ways how to reach the goal: 1) commit a cardinal sin 2) do everything incrementally The cardinal sin is adding an extra field to demux_packet, which caches the determined seekable range for a keyframe range. demux_packet is a rather general data structure and thus shouldn't have any fields that are not inherent to its use, and are only needed as an implementation detail of code using it. But what are you gonna do, sue me? In the future, demux.c might have its own packet struct though. Then the other existing cardinal sin (the "next" field, from MPlayer times) could be removed as well. This commit also changes slightly how the seek end is determined. There is a note on the manpage in case anyone finds the new behavior confusing. It's somewhat cleaner and might be needed for supporting multiple ranges (although that's unclear).
* demux: reduce overhead when searching over keyframe rangeswm42017-11-041-31/+37
| | | | | | | | | | The demuxer cache seeking mechanism looks at keyframe ranges to determine the earlierst PTS of a packet. Instead of looping over all packets twice (once to find the next keyframe, a second time to find the seek PTS), do it in one go. For that basically turn recompute_keyframe_target_pts() into an iteration functionn. Functionality should be unchanged with this commit.
* demux: avoid excessive readahead after cache seekwm42017-11-041-1/+3
| | | | | | | | | | | | The base_ts field is used to guess the decoder position, and when set to NOPTS, it just read ahead arbitrarily. Also demux_add_packet() sets base_ts to the new timestamp when appending a packet, which would also make it readahead by a too large amount. Fix this by setting base_ts after a seek. This assumes that normally, a cached seek target will always have the timestamp set. This is actually not quite clear (as it calls recompute_keyframe_target_pts(), which looks at multiple packets), but maybe it works well enough.
* demux: make pruning more efficient for unseekable demuxer cachewm42017-11-041-19/+24
| | | | | | | | | Don't do any of the extra work related to pruning the backbuffer if demuxer cache seeking is disabled. As a small extra, always prune packets with no timestamps immediately, or queue heads that are not keyframes. (Both of them would be pruned from the backbuffer by the normal logic anyway.)
* demux: on queue overflow wake up reader thread on EOF onlywm42017-11-031-1/+1
| | | | This seems to make more sense.
* demux: don't show queue overflow warning when merely prefetchingwm42017-11-031-6/+7
| | | | | | | | | | | | | If fulfilling --demuxer-readahead-secs requires more memory than allowed by --demuxer-max-bytes, the queue obviously overflows. But the warning is normally only for the case when trying to find the next video or audio packet fails, and decoding can't continue. Use a separate variable for determining whether to prefetch, and if the queue has overflown, skip the message. In fact, skip the EOF setting and waking up the decoder thread as well, because the EOF flag should not be (have been) set in this situation, and waking up the reader thread helps only if the EOF state changed.
* demux: don't allow subtitles to mess up buffered time displaywm42017-11-031-1/+2
| | | | | | | | | | | In a shit show of subtle corner case interactions, making the demuxer cache buffer the entire file can display a small buffered time if subtitles are enabled. The reason is that some subtitle decoders may read in advance infinitely, i.e. they read the entire subtitle stream. Then, since the other streams (audio/video) have logically reached EOF, and the subtitle stream is set to ds->active==true. This will have to be fixed properly later to account buffering for subtitle-only files (another corner case) correctly, but for now this is less annoying.
* demux: add option to create CC tracks eagerlywm42017-11-031-15/+46
| | | | | | | | | | | | We don't hope to auto-detect them at load time, as that would be too much of a pain - even FFmpeg requires fetching and parsing of video packets, and exposes the information only via deprecated API. But there still needs to be a way to select them by default. This is also needed to get the first CC packet at all (without seeking back). This commit also attempts to clean up locking a bit, which is a PITA, but it's better be careful & clean.
* demux_mkv: add V_SNOW tag to mkv_video_tagsNicolas F2017-11-031-0/+1
| | | | | Apparently, and to nobody's surprise, mkv can contain snow. It does so with the V_SNOW tag. We can now play back snow-inside-mkv in mpv.
* Bump libav* API usewm42017-10-301-13/+1
| | | | (Not tested on Windows and OSX.)
* demux: refactor to export seek rangeswm42017-10-302-36/+41
| | | | | | | | | | | | | | | | | | | | Even though only 1 seek range is supported at the time. Other than preparation for possibly future features, the main gain is actually that we finally separate the reporting for the buffering, and the seek ranges. These can be subtly different, so it's good to have a clear separation. This commit also fixes that the ts_reader wasn't rebased to the start time, which could make the player show "???" for buffered cache amount in some .ts files and others (especially at the end, when ts_reader could become higher than ts_max). It also fixes writing the cache-end field in the demuxer-cache-state property: it checked ts_start against NOPTS, which makes no sense. ts_start was never used (except for the bug mentioned above), so get rid of it completely. This also makes it convenient to move the segment check for last_ts to the demux_add_packet() function.
* demux_lavf: return AVERROR_EOF on file endDaniel Kucera2017-10-301-1/+1
| | | | | | | Signed-off-by: Daniel Kucera <daniel.kucera@gmail.com> Signed-off-by: wm4 <wm4@nowhere> Uses different style and different logic from original PR.
* demux_mkv: don't probe start time by defaultwm42017-10-271-1/+0
| | | | | | | It isn't all that reliable, and improving it would make startup slower and require more complexity. There isn't even a good reason to do this (other than semi-broken mkv files), so don't do it. Also see previous commit.
* demux_timeline: don't use segments for DASHwm42017-10-261-1/+1
| | | | | Recent regression. Crashes because it sets the segmented flag, without actually setting the fields required for segmentation.
* demux: better computation of seek start targetwm42017-10-251-8/+24
| | | | | | | | | | | | Avoids that cache seeking is not possible with files that have audio frames with no timestamps (such as avi, sometimes mkv sub-packets from lacing). These would set back_pts (first seekable PTS) to NOPTS, and thus disable cache seeking completely. Instead, prune such packets until we find one with timestamps. One corner case is that the new next good packet might be in the forward cache. In this case we defer dropping until the next time this code is run, and the reader position has possibly moved past the drop point.
* demux: reject cache seeks if parts of the range are unsetwm42017-10-251-2/+3
| | | | | | | | In theory, start/ts_min could be set to NOPTS, in which case "pts < start" for a valid pts would always evaluate to false. Also remove the redundant "in-cache seek is possible.." message, as there's always another message when cache seeks are done.
* demux: fall back to DTS when determining seek targetwm42017-10-251-1/+1
| | | | | Fixes AVI in particular, which abuses DTS for reordered PTS. (It's not really DTS...)
* demux: disallow seeking if there are streams with no timestampswm42017-10-251-3/+7
| | | | | | The seek range computation ignored streams with no timestamps. For things like buffer estimation this is OK and wanted, but the seek range needs to be conservative.
* demux: fix tracking of forward/backward cache sizewm42017-10-251-8/+15
| | | | | | | | | | | | Which parts of the queue are considered forward or backward cache depends on ds->reader_header. The packet at ds->reader_head, as well as all packets following it (via the ->next field) are considered forward. The fw_packs/fw_bytes/bw_bytes must be updated accordingly. This broke in demux_add_packet(), when ds->reader_head was _not_ set on the first packet (or before). This could happen since commit 05