summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* demux_lavf: disable half-working mp4 edit list support in libavcodecwm42017-04-071-1/+5
| | | | | Instead, enable the "old" code, which uses this for gapless info (audio padding/trailing) only.
* demux_cue: include io.h for Windows UTF-8 filesystem functionswm42017-04-041-0/+2
|
* demux_lavf: get total duration from per-track durations as fallbackwm42017-03-011-2/+19
| | | | | | | | | Apparently fixes youtube mp4 streams if avformat_find_stream_info() is not called. Keeping audio/video track and other track durations separate is for the sake of embedded subtitle streams, where we want to include the duration of overlong subtitle streams (I think).
* demux_lavf: skip avformat_find_stream_info() for some formatswm42017-02-231-5/+17
| | | | | | | | Includes hls, mp4, mkv by default. This also avoids stupid things like decoding at least 1 video frame per stream in the demuxer. This also add --demuxer-lavf-probe-info to give finer control over what happens.
* Use AV_INPUT_BUFFER_PADDING_SIZE instead of deprecated onewang-bin2017-02-082-2/+2
| | | | Signed-off-by: wm4 <wm4@nowhere>
* demux_edl: fix behavior with no init segment providedwm42017-02-051-0/+6
| | | | Not that we use it...
* demux_timeline: more silencingwm42017-02-041-1/+1
|
* demux: try not to read packets when cancelledwm42017-02-041-1/+3
| | | | | | Essentially, this will make it abort sooner. Especially with DASH it might avoid confusing error messages, although exact behavior depends on timing.
* ytdl_hook, edl: implement pseudo-DASH supportwm42017-02-046-64/+227
| | | | | | | | | 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-023-6/+11
| | | | | | | | | | | | | | | 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.
* stream: get rid of streamtype enumwm42017-02-027-19/+38
| | | | | | | | | Because it's kind of dumb. (But not sure if it was worth the trouble.) For stream_file.c, we add new explicit fields. The rest are rather special uses and can be killed by comparing the stream impl. name. The changes to DVD/BD/CD/TV are entirely untested.
* stream: better method signal caching, rename weird uncached_stream fieldwm42017-02-021-3/+2
| | | | | | | | "uncached_stream" is a pretty bad name. It could be mistaken for a boolean, and then its meaning would be inverted. Rename it. Also add a "caching" field, which signals that the stream is a cache or reads from a cache. This is easier to understand and more flexible.
* demux_tv: free the correct field instead of creating dangling pointerwm42017-02-021-1/+1
| | | | | | This could potentially have caused fun crashes if the --tv-channels option was used, and something more advanced than tv:// was used to open it. (This code is still untested.)
* demux_mkv: passthrough BlockAdditions for libvpx alphawm42017-01-313-1/+48
| | | | | Dumb but simple thing. Requires the FFmpeg libvpx decoder wrapper, as its native decoder doesn't support alpha.
* demux_mkv: any reference makes a frame not a keyframewm42017-01-311-2/+1
| | | | | | | | | | | | | Fixes seeking with: https://bugs.chromium.org/p/chromium/issues/detail?id=497889 Haali also ignores the element's contents, and interprets its presence as the block not being a keyframe. FFmpeg is going to have an equivalent change. I don't know yet whether the affected sample is valid - a reference timestamp of 0 doesn't make too much sense to me.
* cue: accept lower-case cue commandswm42017-01-241-1/+1
| | | | | | | | | | Some files appear to use them. In the sample I've seen, one field was "Performer" instead of "PERFORMER". This change is slightly risky, because it increases the chance of misdetecting other formats as cue files. Fixes #4057.
* build: replace some FFmpeg API checks with version checkswm42017-01-241-1/+1
| | | | | | The FFmpeg versions we support all have the APIs we were checking for. Only Libav missed them. Simplify this by explicitly checking for FFmpeg in the code, instead of trying to detect the presence of the API.
* player: remove --stream-capture option/propertywm42017-01-212-29/+13
| | | | | | | | | | | | | | | This was excessively useless, and I want my time back that was needed to explain users why they don't want to use it. It captured the byte stream only, and even for types of streams it was designed for (like transport streams), it was rather questionable. As part of the removal, un-inline demux_run_on_thread() (which has only 1 call-site now), and sort of reimplement --stream-dump to write the data directly instead of using the removed capture code. (--stream-dump is also very useless, and I struggled coming up with an explanation for it in the manpage.)
* player: actually let cache readahead after opening demuxer for prefetchwm42017-01-192-1/+3
| | | | | | | | | | | Disabling cache readahead by default until at least 1 track is selected is mainly for external files and such, where you don't want them to use up resources until they're actually used. It doesn't make sense to disable the cache for the demuxer opened for prefetch. Also, it's fine to let it do that for the main file too (doing or not doing it is of little consequence). That saves us from having to distinguish them.
* player: change aspects of cover art handlingwm42017-01-101-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | Cover art handling is a disgusting hack that causes a mess in all components. And this will stay this way. This is the Xth time I've changed cover art handling, and that will probably also continue. But change the code such that cover art is injected into the demux packet stream, instead of having an explicit special case it in the decoder glue code. (This is somewhat more similar to the cover art hack in libavformat.) To avoid that the over art picture is decoded again on each seek, we need some additional "caching" in player/video.c. Decoding it after each seek would work as well, but since cover art pictures can be pretty huge, it's probably ok to invest some lines of code into caching it. One weird thing is that the cover art packet will remain queued after seeks, but that is probably not an issue. In exchange, we can drop the dec_video.c code, which is pretty convenient for one of the following commits. This code duplicates a bunch of lower-level decode calls and does icky messing with this weird state stuff, so I'm glad it goes away.
* demux: rename a functionwm42017-01-101-3/+7
| | | | Also extend the comment on it.
* demux: uninline ds_get_packets()wm42017-01-101-27/+22
| | | | | | It has only 1 caller, and is too far appart within the file. I think it used to have multiple callers, but now it just doesn't make any sense to keep it separate anymore.
* demux_mkv: ebml: turn an int shift into int64wm42017-01-091-1/+1
| | | | | | | | | This was probably the intention all along. But I honestly have no idea what this code even does. Due to what ebml_read_vlen_int() is used for, this is unlikely to have mattered anyway as it rarely/never reads huge values. Which is probably why this has worked for over a decade.
* demux_mkv: trust keyframe flags for TrueHDwm42016-12-201-1/+2
| | | | | | | | | | TrueHD is a fucked up audio codec with extremely small frame sizes. Some of these frames start with full headers, which are usually marked as keyframes, and from which decoding can be started (or at least that's what you'd expect). So for such tracks we should probably trust the keyframe flags. Doesn't really improve seek behavior, though.
* demux_mkv: fix seeking in some broken fileswm42016-12-191-1/+16
| | | | | | | | | | | | | | | | | | | | | | Some files have audio tracks with packets that do not have a keyframe flag set at all. I don't think there's any audio codec which actually needs keyframe flags, so always assume an audio packet is a keyframe (which, in Matroska terminology, means it can start decoding from that packet). The file in question had these set: | + Multiplexing application: Lavf57.56.100 at 313 | + Writing application: Lavf57.56.100 at 329 Garbage produced by garbage... There are other such files produced by mkvmerge, though. It's not perfectly sure whether these have been produced by FFmpeg as well (mkvmerge often trusts the information in the source file, even if it's wrong - so other samples could have been remuxed from FFmpeg). Fixes #3920.
* Remove compatibility thingswm42016-12-072-28/+2
| | | | | | Possible with bumped FFmpeg/Libav. These are just the simple cases.
* demux, stream: add option to prevent opening referenced fileswm42016-12-049-3/+39
| | | | Quite irresponsibly hacked together. Sue me.
* demux_lavf: blacklist ffm (ffserver)wm42016-12-041-0/+2
|
* demux_mkv: distinguish mp2 and mp3wm42016-11-231-2/+4
| | | | | demux_mkv.c has returned mp3 for mp2 since the initial commit. Normally not a problem.
* 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: expose demuxer colorimetry metadata to playerNiklas Haas2016-11-082-0/+3
| | | | | | Implementation-wise, the values from the demuxer/codec header are merged with the values from the decoder such that the former are used only where the latter are unknown (0/auto).
* demux_mkv: parse colorimetry metadataNiklas Haas2016-11-081-0/+39
| | | | | | | | | Matroska actually has lots of colorimetry metadata that video tracks can use, including mastering metadata (HDR signal peak) etc. This commit adds the EBML definitions and parses the most basic fields. Note that nothing uses these fields yet, this commit is just adding the necessary parsing and infrastructure.
* demux: improve buffer estimation in a corner casewm42016-11-011-3/+4
| | | | | | | | | | | | | This deals with the estimation of buffered packets, which is used mostly for display, but also things like pausing on low buffer levels. If a stream is fully EOF (no more packets), we don't want to include it in the total buffer amount. This also means we should make ds->eof less flaky and more stable, so don't reset it in ds_get_packets() (this function reset ds->eof just to retrigger a packet read attempt - we can have this slightly simpler). This somewhat fixes buffering display when e.g. issuing a refresh seek after re-enabling audio/video when playing with subtitles only.
* demux_mkv: fix ordered chapter sources with ordered editionsUoti Urpala2016-10-222-13/+18
| | | | | | | | | | | | | | | | | | | | | | | | Commit f72a900892 (and others) added support for ordered editions that recursively refer to other ordered editions. However, this recursion code incorrectly activated if the source files had ordered chapters even if the main file only wanted to use them as raw video, resulting in broken timeline info overall. Ordered chapters can specify a ChapterSegmentEditionUID value if they want to use a specific edition from a source file. Otherwise the source is supposed to be used as a raw video file. The code checked demuxer->matroska_data.num_ordered_chapters for an opened source file to see whether it was using a recursive ordered edition, but demux_mkv could enable a default ordered edition for the file using the normal playback rules even if the main file had not specified any ChapterSegmentEditionUID. Thus this incorrectly enabled recursion if a source file had a default edition using ordered chapters. Check demuxer->matroska_data.uid.edition instead, and ensure it's never set if a file is opened without ChapterSegmentEditionUID. Also fix what seems like a memory leak in demux_mkv.c. Signed-off-by: wm4 <wm4@nowhere>
* demux_mkv: don't recursively resolve timeline for opened reference fileswm42016-10-223-10/+14
| | | | Instead, resolve all references and so on in the top-level timeline.
* demux: don't try to refresh unselected streamswm42016-10-211-1/+1
| | | | | This could cause nonsensical queue overflow warnings, but was otherwise probably harmless.
* demux_lavf: set title on hearing and visual impaired tracksAman Gupta2016-10-201-0/+4
|
* demux_lavf: don't accidentally enable edit list crap on Libavwm42016-10-181-1/+2
| | | | You really don't get a break from all the multiple bullshit.
* demux_lavf: "support" mov edit lists and log errors if usedwm42016-10-181-0/+4
| | | | | | | | | | | | | | | | | | | | | | | FFmpeg recently got "support" for mov edit lists. This is a terrible hack that will fail completely at least with some decoders (in particular wrappers for hardware decoding might be affected). As such it makes no point to pretend they are supported, even if we assume that the "intended" functionality works, that there are no implementation bugs (good luck with all that messy code added to the already huge mov demuxer), and that it covers enough of the mov edit list feature to be of value. So log an error if the FFmpeg code for mov edit lists appears to be active - AV_PKT_FLAG_DISCARD is used only for "clipping" edit list segments on non-key frame boundaries. In the first place, FFmpeg committed this only because Google wanted it in, and patch review did not even pick up obvious issues. (Just look how there was no lavc version bump when AV_PKT_FLAG_DISCARD was added.) We still pass the new packet flag to the decoders (av_common.c change), which means we "support" FFmpeg's edit list code now. (Until it breaks due to FFmpeg not caring about all the details.)
* player: fix instant subtitle refresh on track switcheswm42016-09-241-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | When switching a subtitle track, the subtitle wasn't necessarily updated, especially when playback was paused. Some awfully subtle and complex interactions here. First off (and not so subtle), the subtitle decoder will read packets only on explicit update_subtitles() calls, which, if video is active, is called only when a new video frame is shown. (A simply video frame redraw doesn't trigger this.) So call it explicitly. But only if playback is "initialized", i.e. not when it does initial track selection and decoder init, during which no packets should be read. The second issue is that the demuxer thread simply will not read new packets just because a track was switched, especially if playback is paused. That's fine, but if a refresh seek is to be done, it really should do this. So if there's either 1. a refresh seek requested, or 2. a refresh seek ongoing, then read more packets. Note that it's entirely possible that we overflow the packet queue with this in unpredicated weird corner cases, but the queue limit will still be enforced, so this shouldn't make the situation worse.
* stream, demux, config: remove some dead/unneeded option-related codewm42016-09-091-1/+0
| | | | | | | | | | This has all been made unnecessary recently. The change not to copy the global option struct in particular can be made because now nothing accesses the global options anymore in the demux and stream layers. Some code that was accidentally added/changed in commit 5e30e7a0 is also removed, because it was simply committed accidentally, and was never used.
* tv: remove weird option parsing stuffwm42016-09-091-6/+14
| | | | Mostly untested.
* demux: do not access global optionswm42016-09-067-66/+137
| | | | | | | | | | | | | | | | | Don't access MPOpts directly, and always use the new m_config.h functions for accessing them in a thread-safe way. The goal is eventually removing the mpv_global.opts field, and the demuxer/stream-layer specific hack that copies MPOpts to deal with thread-safety issues. This moves around a lot of options. For one, we often change the physical storage location of options to make them more localized, but these changes are not user-visible (or should not be). For shared options on the other hand it's better to do messy direct access, which is worrying as in that somehow renaming an option or changing its type would break code reading them manually, without causing a compilation error.
* input, demux_tv: remove some older option access methodswm42016-09-061-2/+2
|
* demux_mkv: don't crash if --ordered-chapters-files failswm42016-09-061-1/+1
| | | | It just crashed.
* demux: close underlying stream if it's fully read anywaywm42016-08-263-3/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is for text subtitles. libavformat currently always reads text subtitles completely on init. This means the underlying stream is useless and will consume resources for various reasons (network connection, file handles, cache memory). Take care of this by closing the underlying stream if we think the demuxer has read everything. Since libavformat doesn't export whether it did (or whether it may access the stream again in the future), we rely on a whitelist. Also, instead of setting the stream to NULL or so, set it to an empty dummy stream. This way we don't have to litter the code with NULL checks. demux_lavf.c needs extra changes, because it tries to do clever things for the sake of subtitle charset conversion. The main reason we keep the demuxer etc. open is because we fell for libavformat being so generic, and we tried to remove corresponding special-cases in the higher-level player code. Some of this is forced due to ass/srt mkv/mp4 demuxing being very similar to external text files. In the future it might be better to do this in a more straight-forward way, such as reading text subtitles into libass and then discarding the demuxer entirely, but for aforementioned reasons this could be more of a mess than the solution introduced by this commit. Probably fixes #3456.
* player: don't directly access demuxer->streamwm42016-08-262-0/+3
| | | | | | | | | | Cleaner and makes it easier to change the underlying stream. mp_property_stream_capture() still directly accesses it directly via demux_run_on_thread(). This is evil, but still somewhat sane and is not getting into the way here. Not sure if I got all field accesses.
* demux: demote packet queue overflow to a warningwm42016-08-221-3/+3
| | | | | | | | | It doesn't necessarily have to mean anything bad. We're still too lazy to provide any more detailed information (e.g. whether this happened to likely bad interleaving, excessive amount of packets like with some ASS subs, or that the readahead user option is limitted by the packet queue size).
* demux: change fps field to doublewm42016-08-191-1/+1
| | | | Because why not.
* video/audio: always provide "proper" timestamps to libavcodecwm42016-08-194-0/+11
| | | | | | | | | | | | | | | | | | | Instead of passing through double float timestamps opaquely, pass real timestamps. Do so by always setting a valid timebase on the AVCodecContext for audio and video decoding. Specifically try not to round timestamps to a too coarse timebase, which could round off small adjustments to timestamps (such as for start time rebasing or demux_timeline). If the timebase is considered too coarse, make it finer. This gets rid of the need to do this specifically for some hardware decoding wrapper. The old method of passing through double timestamps was also a bit questionable. While libavcodec is not supposed to interpret timestamps at all if no timebase is provided, it was needlessly tricky. Also, it actually does compare them with AV_NOPTS_VALUE. This change will probably also reduce confusion in the future.
* demux_lavf: don't report start time for oggwm42016-08-181-2/+6
| | | | | Better with ogg shoutcast streams. These have PTS resets on each playlist item, so the PTS would usually reset to some negative value.
* demux: fix undefined behavior with ogg metadata updatewm42016-08-161-1/+1
| | | | | | | | | | When an ogg track upodates metadata, we have to perform a complicated runtime update due to the demux.c architecture. A detail was broken and an array was allocated with the previous number of streams, which usually led to invalid memory write accesses at least on the first update. See github commit comment on commit b9ba9a89.
* demux: minor cleanup to replaygain error handlingwm42016-08-131-12/+9
| | | | | | | If the PEAK tag is invalid, return an error. Make the error signalling conventions more uniform by strictly returning a negative value on error, and treating >=0 as success.
* demux: make ALBUM replaygain tags optionalwm42016-08-131-3/+7
| | | | IF they're missing, use the TRACK ones instead. See #3405.
* audio: log replaygain values in af_volume instead demuxerwm42016-08-131-6/+1
|