summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* demux_mkv: remove incorrect commentwm42017-06-031-1/+0
| | | | | | | | | | | In the previous commit, I claimed that this GUID stuff was a libavformat extension, but that seems to be completely wrong. (LATM might be an extension of some kind, though.) I don't know what Microsoft calls this GUID "suffix" though. It's generally used to wrap wav format tags and video FourCCs as GUIDs. I guess you could grep Microsoft headers for it to find its name, or something.
* demux_mkv: support FFmpeg A_MS/ACM extensionswm42017-06-032-9/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | Indeed, FFmpeg found a way to maximize the misery around VfW/AVI-style muxing. It appears it can mux a number of random codecs by using random format tags. To make this even more stranger, it has a probably custom GUID for signaling them, although for unknown reasons this is done only "sometimes" (judging from FFmpeg's riffenc.c). Whatever, it's not too hard to support it. Also apparently fix the incorrect interpretation of extended formats - there's absolutely no reason to assume they're always PCM. Instead, check for the correct GUIDs. Also while we're at it, move the channel mask handling also to codec_tag.c, so all WAVEFORMATEXTENSIBLE handling is in one place. (With the normal wav header handling strangely still in demux_mkv.c.) The case I was looking at (aac_latm muxing) decodes now. While I'm not entirely sure about its correctness (libavformat has a weird special-case for SBR), it certainly doesn't try to play it as PCM, which is much of an improvement. The extradata mess in the demux_mkv.c A_MS/ACM code path is unfortunate and ugly, but has less impact than refactoring all the code to make this specific case nicer. Did I mention yet that I hate VfW-style mkv muxing?
* demux_mkv: vp9 alpha, second trywm42017-05-301-1/+4
| | | | | The parser is used to split superframes, and the decoder didn't like when the blockadditional was duplicated on the second split packet.
* demux_mkv: fix alpha with vp9 + libvpxwm42017-05-301-0/+3
| | | | | The blockadditional side data gets lost because vp9 has to go through the parser.
* demux_raw: drop "mp-rawvideo" usewm42017-05-201-2/+17
| | | | | | This is an old pseudo codec to pass through the pixel format. Setup a suitable AVCodecParameter directly instead, so the "rawvideo" codec can be used.
* demux_mkv: read headers at the end of the file sorted by positionwm42017-05-151-6/+30
| | | | | | | | | | | | | Try to read header elements stored at the end of the file in the order of their position. (It would be nicer if mkv simply told us a range of elements to parse, but it doesn't do that.) This can potentially reduce seek elements, although I didn't check if any real files trigger this. The real contribution by this change is that it does not defer reading the CUE index if we need to seek to the end of the file anyway. This can actually avoid 2 seeks when opening a file and --start is used, and the file has other headers elements at the end of the file (like tags).
* demux/stheader: change license to LGPLwm42017-05-101-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | All authors of the current code have agreed. For most of its life, MPlayer used Microsoft structs like WAVEFORMATEX to describe media content. It appears these were copied from wine in 61c5a99851e. Copyright is unclear, but mpv completely removed use of these structs anyway. (demux_mkv.c still contains code to read these fields from a byte stream, but the struct is fully gone.) 42f97b2b820: cehoyos (who probably didn't agree with LGPL) applied a patch by someone who agreed. It's unknown whether cehoyos modified the patch (and thus his copyright would apply), but the changed code was removed anyway. (The code was first moved somewhere else, then removed.) efd53eed614: the patch author was not asked. Although the mkv_sh_sub_t struct was later moved to stheader.h, the added field was removed without replacement. f6878753fbd: nick, who could not be reached, added an include guard, but the guard was changed several times later, and it's probably not copyrightable anyway. afb0fd5ea17: the same nick adds a field that was later replaced and finally removed again in 8cd6b20571.
* demux/packet: change license to LGPLwm42017-04-212-14/+15
| | | | | | | All contributors have agreed. In 3a43f13fcec1, someone who potentially disagreed reverted a commit by someone else (restoring the original state). This shouldn't matter for Copyright, and all of the affected code was rewritten/removed anyway.
* ebml, matroska.h: change license to LGPLwm42017-04-213-21/+21
| | | | | These are covered by the analysis in commit e7e6aa3d64d8773 too (although there are no potential problems).
* demux_mkv: mention non-LGPL codewm42017-04-211-0/+2
|
* demux_mkv: change license to LGPLwm42017-04-211-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most contributors have agreed. This claims it's based on gstreamer code, but this was LGPL at the time (and still is). Contributors whose code was removed were not accounted for. There are still some potentially problematic cases: 06eee1b67 is potentially the most problematic case. Most of these changes are gone due to mpv not using BITMAPINFOHEADER anymore. Some of the other changes are rather trivial. If someone contests this and claims that copyrightable changes are left, the original change can simply be reverted. 62bfae140 has only 2 lines left: a "char *name;" struct field, and a line that prints a message. All other code was removed. The parsing code in particular was made declarative, which replaced reading this element explicitly (and other elements, see 1b22101c77e). I'm putting the log message under HAVE_GPL, but I don't think the declaration is copyrightable, or the mere concept of reading this element. Redoing the other 2 lines of code would result in the same program text. d41e860ba was applied by someone who (potentially) disagreed. The patch itself is from someone who did agree, though. It's unknown whether the applier changed the patch. But it seems unlikely, and the change was mostly rewritten. 50a86fcc3 all demux_mkv changes were reverted (old stdout slave mode) 3a406e94d same 2e40bfa13 the old MPlayer subtitle code was completely removed 316bb1d44 completely removed in 1cf4802c1d 87f93d9d7 same 11bfc6780 relative seeks were removed in 92ba630796 be54f4813 the corresponding demux_mkv code was removed in 5dabaaf093 efd53eed6 all internal vobsub handling is now in FFmpeg d7f693a20 removed in f3db4b0b937 e8a1b3713 removed in 522ee6b7831 cfb890259 removed, see 6b1374b203 for analysis c80808b5a same
* codec_tags: minor simplificationwm42017-04-181-14/+10
| | | | At least this doesn't duplicate the libavcodec PCM codec names.
* codec_tags: remove some more leftoverswm42017-04-181-5/+0
| | | | | I think these became redundant some time ago, and would only matter if someone put QT tags into WAVEFORMATEX headers using mkv avi muxing.
* demux: estimate total packet size, deprecate packet number limitswm42017-04-143-4/+32
| | | | | | | It's all explained in the DOCS changes. Although this option was always kind of obscure and pointless. Until it is removed, the only reason for setting it would be to raise the static default limit, so change its default to INT_MAX so that it does nothing by default.
* 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 wh