summaryrefslogtreecommitdiffstats
path: root/demux/demux_mkv.c
Commit message (Collapse)AuthorAgeFilesLines
* demux_mkv: print chapter timestamp with constant lengthKacper Michajłow10 days1-2/+2
|
* demux_mkv: add BCP 47 language tags supportKacper Michajłow10 days1-1/+4
| | | | | | | | | | Section 12 of Matroska Media Container Format Specifications says: If a BCP 47 Language Element and an ISO 639-2 Language Element are used within the same Parent Element, then the ISO 639-2 Language Element MUST be ignored and precedence given to the BCP 47 Language Element. Fixes: #8144
* demux_mkv: don't warn if yaw/pitch projection is set to 0Kacper Michajłow12 days1-2/+20
| | | | This case will work fine, even if those are explicitly set.
* demux_mkv: remove not needed v_projection_pose_roll_setKacper Michajłow12 days1-3/+1
|
* demux_mkv: corrected direction of ProjectionPoseRoll rotationls-203712 days1-1/+1
| | | | | See: ietf-wg-cellar/matroska-specification#822 Fixes: #13830
* demux_mkv: support V_FFV1 tagvaladaptive2024-03-251-0/+1
| | | | | FFmpeg encodes FFV1 with the V_MS/VFW/FOURCC tag, but GStreamer's matroskamux uses the V_FFV1 tag, so we need to recognize it.
* demux_mkv: don't return null bstr with size specifiedKacper Michajłow2024-02-151-0/+6
| | | | | | Such bstr object are not valid. Also reject empty blocks. Found by fuzzing.
* demux_mkv: error if needed compression settings were not foundKacper Michajłow2024-02-151-0/+4
| | | | | | | Mode 3 is header stripping and we need ContentCompSettings to reconstruct the data. Found by fuzzing.
* demux_mkv: fix memory leak on invalid blocksKacper Michajłow2024-02-151-4/+6
| | | | | | | It is possible to have data with empty block that contains additions. In which case the block would not be added and the additions would leak. Found by fuzzing.
* demux_mkv: add tags for A_MPEG/L1(mp1) audio1nsane0002024-02-101-1/+2
|
* demux_mkv: set only image flag and ignore still_imageKacper Michajłow2024-02-081-4/+2
| | | | Also check if stream is already image to avoid probing.
* demux_mkv: increase probing size for still imageKacper Michajłow2024-02-081-1/+1
| | | | | | | Some files, especially with quite a few audio tracks have video blocks further away, which made them false detected as still images. Fixes: 26a5146
* demux_mkv: detect images by reading blocks and timecodesDudemanguy2024-02-011-0/+36
| | | | | | | | | | | 4709a94aec5b16534b1d6b0d6738caeaf692e9c9 along with some related commits added a way to detect image codecs embedded into mkv streams that weren't tagged with attached picture (arguably a broken file anyways, but maybe not the worst thing to workaround). Unfortunately, this has some false positives particularly with mjpeg playback. So, as usual, revert and rewrite. Instead, we can probe the file and count blocks in the stream. If the video stream has only 1 block and 1 timecode, then assume it's a still image.
* Revert "demux_mkv: check if the video codec is an image"Dudemanguy2024-02-011-4/+0
| | | | This reverts commit 4709a94aec5b16534b1d6b0d6738caeaf692e9c9.
* csputils: replace mp_colorspace with pl_color_spaceKacper Michajłow2024-01-221-9/+12
|
* demux_mkv: add HDMV Text subtitles to subtitle codec listDudemanguy2023-12-161-0/+1
| | | | | Such subtitles will not actually work since FFmpeg doesn't yet have a decoder for them, but this prevents some error message spam at least.
* demux_mkv: check that subtitle type is set before accessing itDudemanguy2023-12-161-1/+1
| | | | | | | | Fixes crashes in case of unknown subtitle track being found, as the original ARIB caption logic added in 0da0acdae8e729eecfb2498ac11cb86a7fe3360d did not attempt to take into mention tracks with unknown type. Fixes #13106
* ALL: use pl_hdr_metadata and nuke sig_peakKacper Michajłow2023-11-051-3/+0
| | | | | | | | This commit replaces all uses of sig_peak and maps all HDR metadata. Form notable changes mixed usage of maxCLL and max_luma is resolved and not always max_luma is used which makes vo_gpu and vo_gpu_next behave the same way.
* demux_mkv: parse mastering metadataKacper Michajłow2023-11-051-5/+47
|
* demux_mkv: check if the video codec is an imageDudemanguy2023-10-231-0/+4
| | | | | | Add a simple helper to codec_tags to check if the codec name matches one of the images. If so, then we set still_image and image in the stream as true (slightly different semanatics).
* Revert "demux_mkv: PAR should be calculated after applying crop"Kacper Michajłow2023-10-211-10/+7
| | | | | | | | | | | Matroska spec says that DisplayWidth and DisplayHeight should be applied after cropping, but this doesn't adhere to the real files which does not follow this rule. Revert the change and we can re-evaluate if someone complains with spec compliant files. See: https://datatracker.ietf.org/doc/draft-ietf-cellar-matroska/ This reverts commit f8db02b59db08f1013dfb9411bd04c6a80dc72ff.
* demux_mkv: don't set codec crop rect when there is no cropDudemanguy2023-10-211-14/+16
| | | | | | | | | | | | Unfortunately there are files out there with broken tags where the width/height doesn't match the actual width/height of the file. That means the cropping logic which normally should be a no-op resulting in (0, 0, w, h) ends up being a crop which is probably not wanted by the user. Workaround this by simply keeping the entire crop rect as 0 when there is no container cropping. All zeros is internally treated the same as (0, 0, w, h) and avoids bad container data messing up the width or height of the window. Also simplify the logic a bit and get rid of some superflorous bools that had no real use. Fixes #12680.
* demux_mkv: PAR should be calculated after applying cropKacper Michajłow2023-10-201-10/+10
| | | | DisplayWidth/DisplayHeight applies to the video frame after cropping (PixelCrop* Elements).
* demuxer: remove several mp_read_option_raw callsDudemanguy2023-09-221-7/+7
| | | | | | | With the previous commit, we can just access option values directly now and avoid a lot of complication. Note that the mp_read_option_raw call for edition requires calling mp_get_config_group since that option needs to live in MPOpts.
* demux_mkv: support ProjectionPoseRoll elementKacper Michajłow2023-09-171-0/+23
|
* demux_mkv: support PixelCrop* elementsKacper Michajłow2023-09-171-0/+29
| | | | Fixes #6017
* demux_mkv: add missing space to log msgsfan52023-07-261-1/+1
|
* demux_mkv: support ARIB captionsrcombs2023-03-141-0/+38
|
* options: transition options from OPT_FLAG to OPT_BOOLChristoph Heinrich2023-02-211-3/+3
| | | | | | c78482045444c488bb7948305d583a55d17cd236 introduced a bool option type as a replacement for the flag type, but didn't actually transition and remove the flag type because it would have been too much mundane work.
* demux_mkv: add AVS2 and AVS3 to tag listNicolas F2022-10-211-0/+2
| | | | | | | Add support for playing back AVS2 and AVS3 video streams inside mkv containers if ffmpeg was compiled with avs2/avs3 support. Fixes: #10695
* osdep: rename MP_UNREACHABLENiklas Haas2021-11-031-1/+1
| | | | | It was pointed out on IRC that the name is misleading, since the actual semantics of the macro is to assert first.
* osdep: add MP_UNREACHABLENiklas Haas2021-11-031-1/+1
| | | | | | | | | This seems to work on gcc, clang and mingw as-is, but I made it conditional on __GNUC__ just in case, even though I can't figure out which compilers we care about that don't export this define. Also replace all instances of assert(0) in the code by MP_UNREACHABLE(), which is a strict improvement.
* player: add track-list/N/image sub-propertyGuido Cella2021-10-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | This exposes whether a video track is detected as an image, which is useful for profile conditions, property expansion and lavfi-complex. The lavf demuxer sets image to true when the existing check detects an image. When the lavf demuxer fails, the mf one guesses if the file is an image by its extension, so sh->image is set to true when the mf demuxer succeds and there's only one file. The mkv demuxer just sets image to true for any attached picture. The timeline demuxer just copies the value of image from source to destination. This sets image to true for attached pictures, standalone images and images added with !new_stream in EDL playlists, but it is imperfect since you could concatenate multiple images in an EDL playlist (which should be done with the mf demuxer anyway). This is good enough anyway since the comment of the modified function already says it is "Imperfect and arbitrary".
* Revert "player: add track-list/N/image sub-property"Jan Ekström2021-10-021-1/+0
| | | | | | | | Unfortunately, this functionality in large part based on a struct member that was made private in FFmpeg/FFmpeg@7489f632815c98ad58c3db71d1a5239b5dae266c in May. Unfortunately, this was not noticed during review. This reverts commit 0862664ac952d21fef531a8923a58ae575268fc5.
* player: add track-list/N/image sub-propertyGuido Cella2021-10-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This exposes whether a video track is detected as an image. This is useful for profile conditions, property expansion and lavfi-complex, and is more accurate than any detection even Lua scripts can perform, since they can't differentiate between images and videos without container-fps and audio and with duration 1 (which is the duration set by the mf demuxer with the default --mf-fps=1). The lavf demuxer image check is moved to where the number of frames is available for comparison, and is modified to check the number of frames and duration instead of the video codec. This doesn't misdetect videos in a codec commonly used for images (e.g. mjpeg) as images, and can detect images in a codec commonly used for videos (e.g. 1-frame gifs). pix files are also now detected as images, while before they weren't since the condition was checking if the AVInputFormat name ends with _pipe, and alias_pix doesn't. Both nb_frames and codec_info_nb_frames are checked because nb_frames is 0 for some video codecs (hevc, av1, vc1, mpeg1video, vp9 if forcing --demuxer=lavf), and codec_info_nb_frames is 1 for others (mpeg, mpeg4, wmv3). The duration is checked as well because for some uncommon codecs and containers found in FFMpeg's FATE suite, libavformat returns nb_frames = 0 and codec_info_nb_frames = 1. For some of them it even returns duration = 0, so they are blacklisted in order to never be considered images. The extra codecs that would have to be blacklisted without checking the duration are AV_CODEC_ID_4XM, AV_CODEC_ID_BINKVIDEO, AV_CODEC_ID_DSICINVIDEO, AV_CODEC_ID_ESCAPE130, AV_CODEC_ID_MMVIDEO, AV_CODEC_ID_NUV, AV_CODEC_ID_RL2, AV_CODEC_ID_SMACKVIDEO and AV_CODEC_ID_XAN_WC3, while the containers are film-cpk, ivf and ogg. The lower limit for duration is 10 because that's the duration of 1-frame gifs. Streams with codec_info_nb_frames 0 are not considered images because vp9 and av1 have nb_frames = 0 and codec_info_nb_frames = 0, and we can't rely on just the duration to detect them because they could be livestreams without an initial duration, and actually even if we could for these codecs libavformat returns huge negative durations like -9223372036854775808. Some more images in the FATE suite that are really frames cut from a video in an uncommon codec and container, like cine/bayer_gbrg8.cine, could be detected by allowing codec_info_nb_frames = 0, but then any present and future video codec with nb_frames = 0 and codec_info_nb_frames = 0 would need to be added to the blacklist. Some even have duration > 10, so to detect these images the duration check would have to be removed, and all the previously mentioned extra codecs and containers would have to be added added to the blacklists, which means that images that use them (if they exist anywhere) will never be detected. These FATE images aren't detected as such by mediainfo either anyway, nor can a Lua script reliably detect them as images since they have container-fps and duration > 0 and != 1, and you probably will never see files like them anywhere else. For attached pictures the lavf demuxer always set image to true, which is necessary because they have duration > 10. There is a minor change in behavior for which audio with attached pictures now has mf-fps as container-fps instead of unavailable, but this makes it consistent with external cover art, which was already being assigned mf-fps. When the lavf demuxer fails, the mf one guesses if the file is an image by its extension, so sh->image is set to true when the mf demuxer succeds and there's only one file. Even if you add a video's file type to --mf-type and open it with the mf protocol, only the first frame is used, so setting image to true is still accurate. When converting an image to the extensions listed in demux/demux_mf.c, tga and pam files are currently the only ones detected by the mf demuxer rather than lavf. Actually they are detected with the image2 format, but it is blacklisted; see d0fee0ac33a. The mkv demuxer just sets image to true for any attached picture. The timeline demuxer just copies the value of image from source to destination. This sets image to true for attached pictures, standalone images and images added with !new_stream in EDL playlists, but it is imperfect since you could concatenate multiple images in an EDL playlist (which should be done with the mf demuxer anyway). This is good enough anyway since the comment of the modified function already says it is "Imperfect and arbitrary".
* demux_mkv: enable AVCodec parser timestamp usage for parsed audioDan Oscarsson2021-09-211-0/+4
| | | | | | | | | Without this, cases where the parser cannot return data right away will end up utilizing the following fed packet's timestamps. This will in turn cause an unnecessary offset in the audio stream timestamps. An example of such buffered parser in libavcodec is the EAC3 one.
* demux_mkv: add png intra supportwm42020-04-161-0/+1
| | | | | | | Evil, non-standard shit. Sample file and script: https://github.com/mpv-player/random-stuff/tree/master/matroska/png
* demux_mkv: concatenate multiple tagswm42020-04-131-2/+8
| | | | | | | | | | | Instead of just picking the last tag that was encountered. The order of the tags still depends on the file order. This is probably wrong, and we should respect TargetTypeValue. But despite staring at the spec, I have no idea what the hell this should do, so fuck that. Fixes: #7604
* demux_mkv: fix another integer/float conversion warningwm42020-03-181-1/+2
| | | | This code could assign INT64_MAX+1 (as double) to int64_t.
* options: change option macros and all option declarationswm42020-03-181-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change all OPT_* macros such that they don't define the entire m_option initializer, and instead expand only to a part of it, which sets certain fields. This requires changing almost every option declaration, because they all use these macros. A declaration now always starts with {"name", ... followed by designated initializers only (possibly wrapped in macros). The OPT_* macros now initialize the .offset and .type fields only, sometimes also .priv and others. I think this change makes the option macros less tricky. The old code had to stuff everything into macro arguments (and attempted to allow setting arbitrary fields by letting the user pass designated initializers in the vararg parts). Some of this was made messy due to C99 and C11 not allowing 0-sized varargs with ',' removal. It's also possible that this change is pointless, other than cosmetic preferences. Not too happy about some things. For example, the OPT_CHOICE() indentation I applied looks a bit ugly. Much of this change was done with regex search&replace, but some places required manual editing. In particular, code in "obscure" areas (which I didn't include in compilation) might be broken now. In wayland_common.c the author of some option declarations confused the flags parameter with the default value (though the default value was also properly set below). I fixed this with this change.
* options: change how option range min/max is handledwm42020-03-131-4/+5
| | | | | | | | | | | | | | | | | Before this commit, option declarations used M_OPT_MIN/M_OPT_MAX (and some other identifiers based on these) to signal whether an option had min/max values. Remove these flags, and make it use a range implicitly on the condition if min<max is true. This requires care in all cases when only M_OPT_MIN or M_OPT_MAX were set (instead of both). Generally, the commit replaces all these instances with using DBL_MAX/DBL_MIN for the "unset" part of the range. This also happens to fix some cases where you could pass over-large values to integer options, which were silently truncated, but now cause an error. This commit has some higher potential for regressions.
* demux_mkv: document probe-start-time option and enable it by defaultwm42020-02-271-1/+2
| | | | | | | | | | | | This is useful with live streams, and it's not much worse than the h264 first packet hack, which reads some data anyway. For some reason, the option wasn't even documented, so do that. In addition, print the start time even if it's negative. That should not be possible, but for some reason, the field is an int64_t copied from an uint64_t so... whatever. Keeping the logging slightly more straight forward is better anyway.
* 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
| | | | | | | |