summaryrefslogtreecommitdiffstats
path: root/demux
Commit message (Collapse)AuthorAgeFilesLines
* demux_raw: change license to LGPLwm42017-06-241-8/+7
| | | | | | | | | | | | | | | All relevant authors have agreed. I'm removing the NV12 FourCC, which was added in f910f3d9 by someone who was not contacted for the relicensing. I doubt the remaining code is copyrightable (basically all what remains the fact is that NV12 uses the same amount of space like YV12), but in this case I feel more comfortable removing it. Might contain some trace amounts of "michael"'s copyright, who agrees with LGPL only once the core is relicensed - but with the core already mostly relicensed, I'm changing the license header to LGPL, and only marking this in the "Copyright" file.
* demux_mf, stream_mf: change license to LGPLwm42017-06-241-7/+13
| | | | | | | | | | | | | | | | | | | cehoyos, who did not agree to the relicensing, added bcb5c78ce3. If there was copyright, we consider it gone, because the table changed. It does not map file extension to a FourCC anymore, and codecs.conf is gone. The new mapping is a libavcodec codec name (happens to be the same as the file extension). The same applies to commits 60ecafec, b749836b, 5b3e3be1. None of these authors were contacted. These were before the code was replaced with a table (in d0326807). The parts outside of demux_mf.c were removed a long time ago. Like in the previous comment, we don't think any copyright applies at least to the new code (at least after the FourCC removal). iive authored 0aa37a0d, which is probably still left in some form, and makes demux_mf.c "LGPL 3 or later". stream_avdevice.c (unrelated) has been marked as LGPL before.
* demux_mkv: fix broken initializerwm42017-06-231-1/+1
| | | | | Who says that the first member is an array or whatever? It depends on whatever the matroska.py script generates.
* demux_mkv: Fix warnings.Rudolf Polzer2017-06-231-40/+43
| | | | | | | | | | | - Fix a signed/unsigned comparison involving info.segment_uid.len (doesn't actually warn here, but seems fragile). Code was previously safe though. - Match up all printf format strings with the respective value types, using the *int*_t printf specifiers where necessary, and fixing multiple signed/unsigned differences. Removed some casts that otherwise may have truncated values. - Fix a warning when initializing ebml_info.
* demux_mkv: Fix "max_cll" warning.Rudolf Polzer2017-06-221-1/+2
| | | | | | On some platforms, unsigned long and uint64_t aren't the same type, after all. As this is just a MP_VERBOSE message, risking truncation in some cases seems OK.
* demux_tv.c: add missing copyright headerwm42017-06-211-0/+22
| | | | | The file consists of stream/tv.c contents. Use the copyright header of that file.
* demux: change license to LGPLwm42017-06-202-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | As usual, the history of these files is a bit murky. It starts with the initial commit. (At which some development had already been done, according to the AUTHORS and ChangeLog files at the time, we should be but covered with relicensing agreements, though.) then it goes on with complete lack of modularization, which was cleaned up later (cd68e161). As usual, we don't consider the copyright of the stuff that has been moved out cleanly. There were also contributions to generic code by people who could not be reached or who did not agree to the relicensing, but this was all removed. The only patches that we could not relicense and which were still in the current code in some form are from Dénes Balatoni: 422b0d2a, 32937181. We could not reach him, so commits f34e1a0d and 18905298 remove his additions. It still leaves the demux_control() declaration itself, but we don't consider it copyrightable. It's basically an idiom that existed in MPlayer before that change, applied to the demuxer struct. (We even went as far as making sure to remove all DEMUXER_CTRLs the original author added.) Commit be54f481 might be a bit of a corner case, but this was rewritten, and we consider the old copyright removed long ago.
* demux: get rid of DEMUXER_CTRL_GET_TIME_LENGTHwm42017-06-2011-147/+51
| | | | | | | | | | | | Similar purpose as f34e1a0deea45e. Somehow this is much more natural too, and needs less code. This breaks runtime updates to duration. This could easily be fixed, but no important demuxer does this anyway. Only demux_raw and demux_disc might (the latter for BD/DVD). For the latter it might actually have some importance when changing titles at runtime (I guess?), but guess what, I don't care.
* demux: replace custom return codes with CONTROL_ oneswm42017-06-199-41/+36
| | | | | | | | This is more uniform, and potentially gets rid of some past copyrights. It might be that this subtly changes caching behavior (it seems before this, it synced to the demuxer if the length was unknown, which is not what we want.)
* vd: use ST.2086 / HDR10 MaxCLL in addition to mastering metadataNiklas Haas2017-06-181-1/+6
| | | | | | | | | | | | | MaxCLL is the more authoritative source for the metadata we are interested in. The use of mastering metadata is sort of a hack anyway, since there's no clearly-defined relationship between the mastering peak brightness and the actual content. (Unlike MaxCLL, which is an explicit relationship) Also move the parameter fixing to `fix_image_params` I don't know if the avutil check is strictly necessary but I've included it anyway to be on the safe side.
* video: refactor HDR implementationNiklas Haas2017-06-181-1/+1
| | | | | | | | | | | | | | | List of changes: 1. Kill nom_peak, since it's a pointless non-field that stores nothing of value and is _always_ derived from ref_white anyway. 2. Kill ref_white/--target-brightness, because the only case it really existed for (PQ) actually doesn't need to be this general: According to ITU-R BT.2100, PQ *always* assumes a reference monitor with a white point of 100 cd/m². 3. Improve documentation and comments surrounding this stuff. 4. Clean up some of the code in general. Move stuff where it belongs.
* Drop/move img_fourcc.hwm42017-06-183-25/+11
| | | | | | | | | | | | | | | This file is an leftover from when img_format.h was changed from using the ancient FourCCs (based on Microsoft multimedia conventions) for pixel formats to a simple enum. The remaining cases still inherently used FourCCs for whatever reasons. Instead of worrying about residual copyrights in this file, just move it into code we don't want to relicense (the ancient Linux TV code). We have to fix some other code depending on it. For the most part, we just replace the MP_FOURCC macro with libavutil's MKTAG (although the macro definition is exactly the same). In demux_raw, we drop some pre-defined FourCCs, but it's not like it matters. (Instead of --demuxer-rawvideo-format use --demuxer-rawvideo-mp-format.)
* demux_lavf: change license to LGPL (almost)wm42017-06-161-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Since this demuxer is based on code by michael, this file can become LGPL only once the mpv core becomes LGPL, and this is preparation for it. There were quite a lot of changes for rearranging preferred libavformat vs. internal MPlayer demuxers, codec mappings, and filename extensions, but all this got removed, so some of the relevant authors weren't asked. cehoyos, who disagreed with LGPL, made a few changes in the past (mostly codec mapping and deinterlacing related things), but all of them were removed, mostly due to libavformat API cleanups. adland, who could not be reached, did commit 057916ee65, but it's easy to essentially revert the change (this is what the source changes in this commit do), so we don't need to think about it. Chris Welton, who could not be reached, made a simple change in commit 958c41d9b69. Fortunately, the API changed again, and his changes were removed, so we don't need to think about this either. There is an anonymous contribution in commit 085f35f4b48 - since this did not introduce any original code, and the probe code was heavily rewritten multiple times, I don't consider it relevant.
* demux_lavf: by default probe info for HLS againwm42017-06-121-1/+1
| | | | | | | | | | | | | This switches back the --demuxer-lavf-probe-info default for HLS from "no" to "yes". Apparently the old default caused problems with the FFmpeg MediaCodec wrapper. I'm not sure whether it's due to the extradata (which would not make any sense as MediaCodec takes in Annex B formatted h264 data), or something else. Reportedly, enabling probing fixes it though, so enable it again. Add disparaging comment about Google software/APIs here.
* demux_lavf: disable various other special behavior if hacks disabledwm42017-06-071-1/+2
| | | | | | This affects in particular the heuristic that enables byte seeks in some cases with .ts input. --demuxer-lavf-hacks=no should disable this behavior now.
* 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