summaryrefslogtreecommitdiffstats
path: root/demux/demux_mkv.c
Commit message (Collapse)AuthorAgeFilesLines
* debug stuffstream_debug_stuffwm42020-02-121-2/+18
|
* demux: do not make up demuxer_idwm42019-12-031-1/+0
| | | | | | | | | | | | | | | | | | The demuxer_id (exported in as "src-id" property) is supposed to be the native stream ID, as it exists in the file, or -1 if that does not exist (actually any negative value), or if it is unknown. Until now, an ID was made up if it was missing. That seems like strange non-sense, and I can't find the reason why it was done. But it was probably for convenience by the EDL stuff or so. Stop doing this. Fortunately, the src-id property was documented as being unavailable if the ID is not known. Even the code for this was present, it was just inactive until now. Extend input.rst with some explanations. Also fixing 3 other places where negative demuxer_id was ignored or avoided.
* demux_mkv, stream: attempt to improve behavior in unseekable streamswm42019-11-141-2/+2
| | | | | | | | | | | | | | | | | stream_skip() semantics were kind of bad, especially after the recent change to the stream code. Forward stream_skip() calls could still trigger a seek and fail, even if it was supposed to actually skip data. (Maybe the idea that stream_skip() should try to seek is worthless in the first place.) Rename it to stream_seek_skip() (takes absolute position now because I think that's better), and make it always skip if the stream is marked as forward. While we're at it, make EOF detection more robust. I guess s->eof shouldn't exist at all, since it's valid only "sometimes". It should be removed... but not today. A 1-byte stream_read_peek() call is good to get the s->eof flag set to a correct value.
* stream: remove eof getterwm42019-11-071-1/+1
| | | | | | | demux_mkv was the only thing using this, and everything else accessed it directly. No need to keep the indirection wrapper around. (Funny how this getter was in the initial commit of MPlayer.)
* stream: turn into a ring buffer, make size configurablewm42019-11-061-8/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In some corner cases (see #6802), it can be beneficial to use a larger stream buffer size. Use this as argument to rewrite everything for no reason. Turn stream.c itself into a ring buffer, with configurable size. The latter would have been easily achievable with minimal changes, and the ring buffer is the hard part. There is no reason to have a ring buffer at all, except possibly if ffmpeg don't fix their awful mp4 demuxer, and some subtle issues with demux_mkv.c wanting to seek back by small offsets (the latter was handled with small stream_peek() calls, which are unneeded now). In addition, this turns small forward seeks into reads (where data is simply skipped). Before this commit, only stream_skip() did this (which also mean that stream_skip() simply calls stream_seek() now). Replace all stream_peek() calls with something else (usually stream_read_peek()). The function was a problem, because it returned a pointer to the internal buffer, which is now a ring buffer with wrapping. The new function just copies the data into a buffer, and in some cases requires callers to dynamically allocate memory. (The most common case, demux_lavf.c, required a separate buffer allocation anyway due to FFmpeg "idiosyncrasies".) This is the bulk of the demuxer_* changes. I'm not happy with this. There still isn't a good reason why there should be a ring buffer, that is complex, and most of the time just wastes half of the available memory. Maybe another rewrite soon. It also contains bugs; you're an alpha tester now.
* demux_mkv: reduce log level of mkvinfo part to debugwm42019-11-011-61/+58
| | | | | | demux_mkv has lots of logging that shows information about the file. It sort of reminds of mkvinfo output. While this is sometimes interesting, it's too much for verbose mode, and should be in debug log level.
* Replace uses of FFMIN/MAX with MPMIN/MAXwm42019-10-311-1/+1
| | | | And remove libavutil includes where possible.
* demux_mkv: add V_MPEG4/MS/V3 mappingwm42019-10-241-0/+1
| | | | Fixes: #6547
* video, demux: rip out unused spherical metadata codewm42019-10-171-47/+0
| | | | | | This was preparation into something that never happened. Spherical video is a shit idea anyway.
* demux_mkv: better behavior/warnings on partial files/unseekable streamswm42019-10-011-5/+8
| | | | | | | | | | | | | | demux_mkv may seek to the end of the file to read certain headers (which should probably be called "footers", but in theory they are just headers that have been placed at the end of the file unfortunately). This commit changes behavior not to seek if the stream is not marked as seekable. Before this, it only checked whether the stream size was unknown (end negative). In practice it doesn't make much of a difference, since seekable usually equals known stream size. Also improve the wording, and distinguish between actual incomplete files, and unseekable ones.
* demux_mkv: add hacks to avoid a single warningwm42019-09-191-9/+26
| | | | | | | | | | | | | | It prints "Unexpected end of file (no clusters found)" when opening a webm init fragment. The warning is correct, but unwanted in this case. Add tons of kludges to avoid it. (Actually it prints that twice, for audio and video each.) Also, suppress another warning about a seek head entry that points exactly to the end of the file. This is a MATROSKA_ID_CUES, which is harmless, and, very strangely, doesn't point at any cues when you concatenate the init fragment with a media fragment. No idea what that crap is supposed to be.
* demux_mkv: fix subtitle preroll in some caseswm42019-09-191-7/+6
| | | | | | | | | | | | | | | | | | | | | | Subtitle packets with a timestamp before the seek target may overlap with the seek target anyway. This is why this subtitle preroll crap exists: it needs to return packets before the seek target to ensure that the subtitle is displayed at the seek target. This didn't always work. Maybe it's a regression, but it must have been an old one. The breakage is triggered by heuristic that is to prevent excessive queuing of packets in garbage files (this heuristic apparently became immediately necessary when this preroll mechanism was implemented). If a video keyframe packet was found, but no audio packet yet, then subtitle_preroll was set to 0, and since a_skip_to_keyframe was still 0, the subtitle packet was discarded. The dumb thing is that subtitle and video seeking is finished at this point, so the preroll crap should not be applied at all. Fix this by moving the preoll overflow code into the block that handles preroll.
* demux_mkv: don't set keyframe flag for timestamp-less audio frameswm42019-09-191-2/+3
| | | | | | | | | | | | | | | | | | | | | Matroska has this weird concept of "lacing", which are really sub-blocks packed into a larger actual block. They are demuxed as individual packets, because that's what the decoder needs. Basically they're a Matroska hack to reduce per-packet muxing overhead. One problem is that these sub-blocks don't have timestamps. The timestamps need to be created from the "default duration". If this default duration isn't in the file header (or if we drop it when it has a known broken value), the resulting packets won't have a timestamp. This is an usual and weird situation, that may confuse the demuxer layer (and backward playback in particular). Fix this by not setting the keyframe flag for these. This affects only audio packets. Subtitle lacing is explicitly not supported (in theory would at least lack a way to specify durations), and video won't usually use it for real video codecs (not every frame is a "keyframe", timestamp reordering).
* demux, demux_mkv: fix seeking in cache with large codec delaywm42019-09-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In this scenario, the demuxer will output timestamps offset by the codec delay (e.g. negative timestamps at the start; mkv simulates those), and the trimming in the decoder (often libavcodec, but ad_lavc.c in our case) will adjust the timestamps back (e.g. stream actually starts at 0). This offset needs to be taken into account when seeking. This worked in the uncached case. (demux_mkv.c is a bit tricky in that the index is already in the offset space, so it compensates even though the seek call does not reference codec_delay.) But in the cached case, seeks backwards did not seek enough, and forward they seeked too much. Fix this by adding the codec delay to the index search. We need to get "earlier" packets, so e.g. seeking to position 0 really gets the initial packets with negative timestamps. This also adjusts the seek range start. This is also pretty obvious: if the beginning of the file is cached, the seek range should start at 0, not a negative value. We compare 0-based timestamps to it later on. Not sure if this is the best approach. I also could have thought about/checked some corner cases harder. But fuck this shit. Not fixing duration (who cares) or end trimming, which would reduce the seek range and duration (who cares).
* demux_mkv: stop setting per-packet initial padding from codec delaywm42019-09-191-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This is a bad approach, and should be handled by a codec parameter field (in mp_codec_params or AVCodecParameters). It's bad because it's overly complicated, and has potential to break demuxer cache assumptions: packets that were "intended" for seek resuming may suddenly appear in the middle of a stream, when you seek back and play a cached part again. (In general it was fine though, because seek range joining tends to remove the first audio packet of the next range when trying to find an overlap.) demux_mkv.c does not try to export its codec_delay field through the codec parameters mentioned above. In the only case I spotted this element, the codec itself (opus) set this field within libavcodec. And I think that's actually how it should be. On the other hand, a file could in theory set this field via mkv headers if the codec is too stupid to have such a field internally. But I don't really care until I see such a file. The end trimming is still sort of needed (though not sure if anything uses it, other than the opus/mkv test sample I was using). The decoder can't know whether something is the last packet, until it's too late. The codec_delay field is still needed to offset timestamps.
* demux_mkv: fix seeking in broken mjpeg fileswm42019-09-191-1/+3
|
* demux: return packets directly from demuxer instead of using sh_streamwm42019-09-191-14/+38
| | | | | | | Preparation for other potential changes to separate demuxer cache/thread and actual demuxers. Most things are untested, but it seems to work somewhat.
* demux_mkv: add A_MLP to mkv_audio_tagsNicolas F2018-06-221-0/+1
| | | | Fixes #5923
* demux_mkv: adjust log verbosity levelswm42018-04-291-9/+9
| | | | | | | | | With -v -v ("debug" level), which is the default for --log-file, this would log every damn Matroska EBML element and some other uninteresting things, which was very noisy. Adjust the log levels to make them less noisy. Also, change some log calls to MP_ERR for things which are actually errors.
* demux_mkv: fix certain cases of recursive SeekHeadswm42018-04-151-4/+1
| | | | | | | | | | | | | | | Some shittily muxed files (by a certain HandBrake+libavformat combo) contain a SeekHead pointing to a SeekHead at the end of the file, which in turn points to track headers (also at the end of the file). This failed because the demuxer didn't bother to actually read the elements listed by the second SeekHead, so no track headers were read, and playback broke. Somehow commit 6fe75c38 broke this for no reason. It adds a "needed" field, which seems completely pointless and replaced the "parsed" flag in an incomplete way. In particular, the "needed" field was not set when a _recursive_ SeekHead was read, so those elements were not read. Just get rid of the field and use "parsed" instead.
* demux_mkv: add V_AV1 identifier for AV1Jan Ekström2018-04-081-0/+1
| | | | | | | | | | | Quickly tested by a person who had FFmpeg linked with libaom. Seems as simple as the VP9 mappings, where there is no extradata/ initialization data off-band, and just stuff in the packets themselves. Do note that the AV1 video format itself at this point is still not frozen, so what you might produce one day might not be decodable the following day.
* demux_mkv: enable libavcodec parser for eac3wm42018-03-031-1/+1
| | | | | | | | | | | | | | It appears some (or all) mkv files with EAC3 are muxed in a way that breaks FFmpeg's spdifenc. I suspect it's because either dependent substream packets are localted in their own packets, or the reverse. Or possibly this is case where the muxer did not respect packet boundaries at all. Enabling the EAC3 parser seems to fix this anyway, because why waste your precious time on retarded Dolby bullshit technology? (Which idiot came up with this shitty substream garbage?) Observed with dolby_digital_plus_channel_check_lossless-DWEU.mkv. Fixes #5578.
* Revert "demux_mkv: remove remaining GPL code"wm42018-01-311-1/+4
| | | | | | | | This reverts commit b7f90be567c3c19eb3fec30be2b76775296a6ed1. The author agreed to the relicensing now (if that code is affected by the original copyright at all - that was the only line possibly left of it).
* ta: introduce talloc_dup() and use it in some placeswm42018-01-181-3/+2
| | | | | | | It was actually already implemented as ta_dup_ptrtype(), but that seems like a clunky name. Also we still use the talloc_ names throughout the source, and I'd rather use an old name instead of a mixing inconsistent naming conventions.
* demux_mkv: fix x264 hack if video track uses header compressionwm42017-12-301-1/+7
| | | | | | | | | | | | The x264 hack requires reading the first video packet, which in turn we handle with a hack in demux_mkv.c to get the packet without having to add special crap to demux.c. Another useless MKV feature (which they enabled by default at one point and which caused many demuxers to break completely, only to disable it again when it was too late) conflicts with this, because we actually pass a block as packet contents, instead of after "decompression". Fix this by calling demux_mkv_decode().
* demux_mkv: add hack to pass along x264 version to decoderwm42017-12-281-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | This fixes when resuming certain broken h264 files encoded by x264. See FFmpeg commit 840b41b2a643fc8f0617c0370125a19c02c6b586 about the x264 bug itself. Normally, the unregistered user data SEI (that contains the x264 version string) is informational only. But libavcodec uses it to workaround a x264 bug, which was recently fixed in both libavcodec and x264. The fact that both encoder and decoder were buggy is the reason that it was not found earlier, and there are apparently a lot of files around created by the broken decoder. If libavcodec sees the SEI, this bug can be worked around by using the old behavior. If you resume a file with mpv (i.e. seeking when the file loads), libavcodec never sees the first video packet. Consequently it has to assume the file is not broken, and never applies the workaround, resulting in garbage being played. Fix this by always feeding the first video packet to the decoder on init, and then flushing the codec (to avoid that an unwanted image is output). Flushing the codec does not remove info such as the x264 version. We also abuse the fact that the first avcodec_send_packet() always pushes the frame into the decoder (so we don't have to trigger the decoder by requsting an output frame).
* demux_mkv: maintain a small packet read queuewm42017-12-281-22/+39
| | | | | This is less of a mess than the single-item queue in tmp_block, and also might help us in the future.
* demux_mkv: fix off by one errorwm42017-12-231-3/+1
| | | | | | | | | | | | Caused by the relatively recent change to packet parsing. This time it was probably triggered by lace type 0, which reduces the byte length of a 0 sized packet to 3 (timestamp + flag) instead of 4 (lace count for other lace types). The thing about laces is just my guess why it worked for other 0 sized packets, though. Also remove the redundant and now incorrect check below. Fixes #5271.
* 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_mkv: fix potential uninitialized variable readwm42017-11-101-2/+3
|
* 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_mkv: rewrite packet reading to avoid 1 memcpy()wm42017-11-051-87/+101
| | | | | | | | | | | | | | | | | | | | | | | 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_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.
* 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: drop redundant SEEK_BACKWARD flagwm42017-10-231-13/+9
| | | | | | | | | | | | | Seems like most code dealing with this was for setting it in redundant cases. Now SEEK_BACKWARD is redundant, and SEEK_FORWARD is the odd one out. Also fix that SEEK_FORWARD was not correctly unset in try_seek_cache(). In demux_mkv_seek(), make the arbitrary decision that a video stream is not required for the subtitle prefetch logic to be active. We might want subtitles with long duration even with audio only playback, or if the file is used as external subtitle.
* demux_mkv: remove remaining GPL codewm42017-10-101-8/+1
| | | | Fuck this thing.
* demux_mkv: replace deprecated av_copy_packet_side_data()wm42017-10-031-4/+2
| | | | | It's deprecated, and av_packet_copy_props() is nearly equivalent. It's also more widely supported.
* video: add metadata handling for spherical videowm42017-08-211-0/+47
| | | | | | | | | | | | | | This adds handling of spherical video metadata: retrieving it from demux_lavf and demux_mkv, passing it through filters, and adjusting it with vf_format. This does not include support for rendering this type of video. We don't expect we need/want to support the other projection types like cube maps, so we don't include that for now. They can be added later as needed. Also raise the maximum sizes of stringified image params, since they can get really long.
* demux_mkv: avoid an error message in a corner casewm42017-08-081-0/+1
| | | | | | | | If --demuxer-mkv-probe-start-time=no is used, and a seek is triggered on start, then cluster_start will be 0, and the packet reading code will print an error message about not finding valid data. This fixes itself since it invokes the resync code, but it's still pretty ugly. Avoid this by always initializing cluster_start.
* Replace remaining avcodec_close() callswm42017-07-161-5/+1
| | | | | | | | This API isn't deprecated (yet?), but it's still inferior and harder to use than avcodec_free_context(). Leave the call only in 1 case in af_lavcac3enc.c, where we apparently seriously close and reopen the encoder for whatever reason.
* 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: get rid of DEMUXER_CTRL_GET_TIME_LENGTHwm42017-06-201-18/+4
| | | | | | | | | | | | 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-191-3/+3
| | | | | | | | 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.210