summaryrefslogtreecommitdiffstats
path: root/demux/demux_mkv.c
Commit message (Collapse)AuthorAgeFilesLines
* demux_mkv: adjust subtitle preroll defaultswm42015-12-271-3/+13
| | | | | | | | | | | | | | | | | Always preroll by default if the cue (index) information indicates overlapping subtitles. Increase the amount of maximum data it will skip to get such subtitles to 10 seconds. Since the index information can reliably tell whether reading earlier is needed, the maximum should be rarely actually used, thus we can set it high. On the other hand, the "old" prerolling mechanism always has to skip the maximum amount of data; thus the method using the index gets its own option to control the maximum amount of data to skip. (As more and more files With newer mkvtoolnix versions are muxed, and with this new and hopefully sane default established, these options can probably be removed in the future.)
* demux: remove weird tripple-buffering for the sh_stream listwm42015-12-231-14/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The demuxer infrastructure was originally single-threaded. To make it suitable for multithreading (specifically, demuxing and decoding on separate threads), some sort of tripple-buffering was introduced. There are separate "struct demuxer" allocations. The demuxer thread sets the state on d_thread. If anything changes, the state is copied to d_buffer (the copy is protected by a lock), and the decoder thread is notified. Then the decoder thread copies the state from d_buffer to d_user (again while holding a lock). This avoids the need for locking in the demuxer/decoder code itself (only demux.c needs an internal, "invisible" lock.) Remove the streams/num_streams fields from this tripple-buffering schema. Move them to the internal struct, and protect them with the internal lock. Use accessors for read access outside of demux.c. Other than replacing all field accesses with accessors, this separates allocating and adding sh_streams. This is needed to avoid race conditions. Before this change, this was awkwardly handled by first initializing the sh_stream, and then sending a stream change event. Now the stream is allocated, then initialized, and then declared as immutable and added (at which point it becomes visible to the decoder thread immediately). This change is useful for PR #2626. And eventually, we should probably get entirely of the tripple buffering, and this makes a nice first step.
* video: switch from using display aspect to sample aspectwm42015-12-191-4/+9
| | | | | | | | | | | | | | | | MPlayer traditionally always used the display aspect ratio, e.g. 16:9, while FFmpeg uses the sample (aka pixel) aspect ratio. Both have a bunch of advantages and disadvantages. Actually, it seems using sample aspect ratio is generally nicer. The main reason for the change is making mpv closer to how FFmpeg works in order to make life easier. It's also nice that everything uses integer fractions instead of floats now (except --video-aspect option/property). Note that there is at least 1 user-visible change: vf_dsize now does not set the display size, only the display aspect ratio. This is because the image_params d_w/d_h fields did not just set the display aspect, but also the size (except in encoding mode).
* demux_mkv: fix incremental indexing with single-keyframe fileswm42015-11-171-2/+1
| | | | | | | | | | | | This is another regression of the recently added start time probing. If a seek is executed after opening the file (but before reading any packets), the first block is discarded instead of indexed. If there are no other keyframes in the file, seeking will fail completely. Fix it by seeking to the cluster start if there aren't any index entries yet. This will read the skipped packet again. Fixes #2498.
* demux_mkv: remove --demuxer-mkv-fix-timestampswm42015-11-071-17/+1
| | | | | | | | While it seemed like a pretty good idea at first, it's just a dead end and works only in the simplest cases. While it may or may not help slightly with audio sync mode, the display-sync mode already compensates this in a better way. The main issue is that timestamps at this layer are not in order, so it can look at single timestamps only.
* demux_mkv: dump mixing/writing app fields in verbose logwm42015-11-061-0/+4
|
* demux_mkv: fix cluster skip with duration probingwm42015-10-271-6/+7
| | | | The start time probing essentially broke it.
* demux_mkv: fix duration probing for files with non-0 start timewm42015-10-261-1/+1
| | | | | When using --demuxer-mkv-probe-video-duration=full and the file did not start at timestamp 0, the reported duration was still wrong.
* demux_mkv: probe start timewm42015-10-161-10/+43
| | | | | | | | | | | | | | | | | MKV files can very well start with timestamps other than 0. While mpv has support for such files in general, and demux_lavf enables this feature, demux_mkv didn't export a start time. Implement this by simply reading the first cluster timestamp. This in turn is done by reading 1 block. While we don't need the block for this prupose at all, it's the easiest way to get the cluster timestamp read correctly without code duplication. In theory this could be wrong, and a packet could start at a much later time, but in practice this won't happen. This commit also adds an option to disable this feature. It's not documented because nobody should use it. (But I happen to have a need for this.)
* demux_mkv: do not return subtitle packets that end before seek targetwm42015-10-121-2/+6
| | | | | | This affects the subtitle preroll mode during seeking. It could matter somewhat with insane files with ten-thousands of subtitle events, which now seem to pop up, and will avoid packet queue overflow.
* demux_mkv: discard broken indexwm42015-08-261-4/+17
| | | | | | | | | | | | | | | | Add a simplistic heuristic for detecting broken indexes. This includes indexes with very few elements (apparently libavformat sometimes writes such indexes, or used to), and indexes with broken timestamps. The latter was apparently produced by very old HandBrake versions: | + Muxing application: libmkv 0.6.1.2 | + Writing application: HandBrake 0.9.1 These broken files seem to be common enough that libavformat added a workaround for them in 2008 (and maybe again in 2015). Apparently all timestamps are multiplied with the file's tc_scale twice, and FFmpeg attempts to fix them. We should throw away the whole thing.
* demux_mkv: don't read index twicewm42015-08-261-1/+1
| | | | | | Actually, this never happened, because there's logic for ignoring duplicate header elements (which includes the seek index). This is mostly for robustness and readability.
* stream: provide a stream_get_size() convenience functionwm42015-08-181-11/+5
| | | | | And use it everywhere, instead of retrieving the size manually. Slight simplification.
* demux_mkv: disable timestamp fixup code againwm42015-08-101-1/+1
| | | | | | | | | | | | This doesn't work too well if sections of the file change to a different framerate. It lowers our chances to guess the correct FPS in the display sync code. For normal playback, this (probably) doesn't help that much anyway, except that the "estimated-vf-fps" property will regress in the simplest mkv case. This will be fixed with the next commit. The now disabled code will probably be removed; it's not useful anymore.
* demux_mkv: remove unnecessary codewm42015-07-201-4/+0
| | | | This did nothing. It's a leftover from ancient times.
* demux_mkv: parse FLAC channel layoutswm42015-07-201-0/+67
| | | | | | | | | | | | | | | | | | Handle a relatively recently introduced hack, that allows FLAC audio to have arbitrary channel layouts, instead of just the predefined fixed ones. This is actually supported by FFmpeg, but since the demuxer (instead of the decoder) handles this in FFmpeg, we need to add special- code to our mkv demuxer. (The way FFmpeg does this seems a bit backwards, since now every demuxer for a format that can handle FLAC needs to contain this logic as well.) The FLAC hack is relatively terrible: we need to parse the FLAC headers, look for a VorbisComment, parse the VorbisComment, and then retrieve the magic WAVEFORMATEXTENSIBLE_CHANNEL_MASK entry. But the hack is officially endorsed, as the official FLAC tools use it. (Although I couldn't find a trace of it in the format specification. Should I be surprised?)
* demux_mkv: improve video duration detection heuristicwm42015-07-091-16/+29
| | | | | | | | | | | Extend the --demuxer-mkv-probe-video-duration behavior to work with files that are partial and are missing an index. Do this by finding a cluster 10MB before the end of the file, and if that fails, just read the entire file. This is actually pretty trivial to do and requires only 5 lines of code. Also add a mode that always reads the entire file to estimate the video duration.
* demux_mkv: disable ordered chapters if ChapterTimeEnd is missingwm42015-06-281-2/+11
| | | | | | | | | | | | | If the EditionFlagOrdered is set, chapters without ChapterTimeEnd make no sense. Ordered chapters will play the chapters in the order they appear, but will play the ranges the chapters cover. So if the end time is missing, the range is incomplete and it's not clear what should be played. If you assume the start of the next chapter as end time, the ordered flag will have no observable effect, so that's not a useful assumption. This fixes playback of a file which (apparently) had the EditionFlagOrdered set accidentally, with normal chapters.
* demux: export forced flagwm42015-06-271-0/+7
| | | | | | At least Matroska files have a "forced" flag (in addition to the "default" flag). Export this flag. Treat it almost like the default flag, but with slightly higher priority.
* demux_mkv: ignore deprecated FrameRate, do not assume PALwm42015-06-271-8/+2
| | | | | | | | | | | The "FrameRate" element is probably deprecated (it's greyed out in the "spec", and described as "Informational only" in bold). Normally files use DefaultDuration. In fact, the FrameRate field was preferred over DefaultDuration for determining framerate if present. Do not do this and rely on DefaultDuration only. Also, if no framerate is set, do not assume PAL (25 FPS). Such a fallback makes little sense and will cause more problems than it solves.
* demux_mkv: remove some ASCII art log messageswm42015-06-271-8/+4
| | | | | Some of the ASCII art makes sense (like the lines starting with "|"), but these do not make any sense to me and just look annoying.
* demux_mkv: use arrays for codec lookup tableswm42015-06-261-18/+11
| | | | No need to define extra types.
* demux_mkv: minor simplificationwm42015-06-261-3/+1
|
* demux: get rid of some bstr thingswm42015-06-241-2/+3
| | | | | Change the demuxer_add_attachment() and demuxer_add_chapter() signatures to take char* instead of bstr, and everything which depends on it.
* demux_mkv: don't use byte stringswm42015-06-241-29/+28
| | | | | | Use char* for strings instead of bstr (data ptr + length pair). Matroska actually (probably) allows "padding" strings with \0 bytes, so using normal C strings instead of byte strings is more appropriate.
* demux_mkv: share some duplicated codewm42015-06-211-16/+17
| | | | | As a side effect, video tracks now actually export some fields (language, default flag) to the player.
* demux: merge extradata fieldswm42015-06-211-7/+6
| | | | | | | MPlayer traditionally had completely separate sh_ structs for audio/video/subs, without a good way to share fields. This meant that fields shared across all these headers had to be duplicated. This commit deduplicates essentially the last remaining duplicated fields.
* demux_mkv: minor audio extradata cleanupwm42015-06-211-27/+24
| | | | | | Always use the already existing extradata[_len] variable, instead of the awkward switch between manually changed extradata and falling back to passing through extradata at the end.
* demux: rename sh_stream.format to sh_stream.codec_tagwm42015-06-211-4/+4
| | | | | Why not. "format" sounds too misleading for the actual importance and meaning of this field.
* demux_mkv: do not reset bits_per_coded_sample if not neededwm42015-06-191-7/+0
|
* demux_mkv: do not set block_align for codecs which do not need itwm42015-06-191-7/+0
| | | | | These decoders do not reference it. I suspect this was originally done for the sake for MPlayer's vfw/dshow wrappers.
* demux_mkv: do not set bitrate fields for codecs which do not need itwm42015-06-191-7/+0
| | | | | | The only decoders I could find and which (possibly) require this field are codecs which can be used via VfW only, and realaudio sipr. For VfW we still passthrough this field.
* demux_mkv: stricter realaudio extradata handlingwm42015-06-191-11/+13
| | | | | | Verify memory accesses and such. The behavior should be equivalent. (RealAudio causes pain for everyone even in its grave.)
* demux_mkv: separate generic and non-VfW audio codec handling partswm42015-06-191-89/+84
| | | | | | | | | | | | | | | | | | | Native Matroska codec support has to map the Matroska codec IDs to libavcodec ones, and also has to undo codec-specific Matroska strangeness, such as restoring AAC extradata and realaudio handling. The VfW codec support doesn't need it, because AVI maps well enough to libavcodec conventions (possibly because AVI was a dominant codec when libavcodec was created). But there's still some need for generic codec handling, such as enabling parsers and messing with various codec parameters. Separate these two, and move the parts which are guaranteed not to be needed by VfW to the if-else tree that handles the VfW case ("A_MS/ACM"), making the cases exclusive. (This should probably be done more radically, since it's very unlikely that we should or have to mess with the VfW parameters at all - they should just be passed through to the decoder.)
* demux_mkv: remove indirection through defineswm42015-06-191-58/+58
| | | | | This is actually more readable. Most of the defines are used only once, so using a symbol instead of the direct string only obfuscated it.
* demux_mkv: remove FourCCs from audio codec handlingwm42015-06-191-92/+73
| | | | | | | | | | | | | | | | | | | | | | This removes the last traces of the old MPlayer FourCC-based codec mapping code. Forcing all codec IDs through a FourCC table and then back to codec names was confusing at best, so this is a nice cleanup. Handling of PCM (non-VfW case) is redone to some degree. Handling of AC3 is moved below realaudio handling, since "A_REAL/DNET" is apparently AC3, and we must not skip realaudio-specific handling. (It seems unlikely that anything would actually break, but on the other hand I don't have any A_REAL/DNET samples for testing.) Instead of explicitly matching all the specific AAC codec names, just match them all as prefix. Some codecs don't need special handling other than their mapping entries, so they fall away (like Vorbis and Opus). The prores check in mkv_parse_and_add_packet() is not strictly related to this, but is done for consistency with the wavpack check above.
* demux_mkv: always copy video extradatawm42015-06-131-16/+14
| | | | | | The existing code avoided doing this for some codecs. I see no point in this, and it seems the original reason this exists was due to some cleanup in 2007. libavformat doesn't do this. So just drop it.
* demux_mkv: fix mpeg2 mappingwm42015-06-131-1/+1
| | | | | | | | It's well possible that we've always ended up invoking the AV_CODEC_ID_MPEG1VIDEO codec, but it's hard to tell. Mangling everything through FourCCs (and then back) makes it hard to analyze. Also, libavformat's Matroska demuxer uses AV_CODEC_ID_MPEG2VIDEO here, so it should be quite safe to do anyway.
* demux_mkv: remove FourCCs from video codec handlingwm42015-06-131-26/+27
| | | | | | | | | | | | | | | | | | | Inherited from MPlayer times, we used FourCCs to identify video codecs. This was later changed to libavcodec codec names (which made life a whole lot simpler). But demux_mkv still uses FourCCs a lot. Change this for video. It's pretty simple, because some preparation was done in the past. We just have to replace some "internal" FourCCs with different handling. One potentially complicated issue is that there is no natural way to set the sh->format (AVCodecContext.codec_tag) field anymore. Most decoders do not need it, though mjpeg is an exception. Note that the AVI compatibility code still requires codec mappings, but these are provided by FFmpeg. Also, the audio code is not changed. For the MKV_V_MPEG2 -> mpeg1video thing see next commit.
* demux_mkv: remove a level of indentationwm42015-06-131-53/+52
| | | | | Replace an else block with a nested if with just "else if". No functional or other changes.
* demux_mkv: remove ms_compat codewm42015-06-131-11/+5
| | | | Reduces the mess slightly.
* demux_mkv: limit timestamp fixing to 1ms maxwm42015-04-231-1/+1
| | | | | And also fix the description. It didn't actually reflect what the code did.
* demux_mkv: attempt to fix rounded timestampswm42015-04-231-1/+18
| | | | | There is some potential for breakage. If it happens, this might have to be disabled by default.
* demux_mkv: move global options to the demuxerwm42015-04-231-8/+38
| | | | | | | The options don't change, but they're now declared and used privately by demux_mkv.c. This also brings with it a minor refactor of the subpreroll seek handling - merge the code from playloop.c into demux_mkv.c. The change in demux.c is pretty much equivalent as well.
* demux_mkv: better seeking after video endwm42015-04-231-15/+7
| | | | | | | | | | | | | | | | | This change allows forward seeking even if there are no more video keyframes in forward direction. This helps with files that e.g. encode cover art as a single video frame (within a _real_ video stream - ffmpeg seems to like to produce such files). Seeking backwards will still jump to the nearest video frame, so this improvement has limited use. The old code didn't do this because of the logic the min_diff variable followed. Instead of somehow using the timestamp of the last packet read for min_diff, use the first index entry for it. This actually makes it fall back to the first/last index entry as the (removed) comment claims. Note that last_pts is basically random at this point (because the demuxer can be far ahead of playback position), so this didn't make sense in the first place.
* Update license headersMarcin Kurczewski2015-04-131-5/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* demux_mkv: check for playback abortswm42015-03-091-0/+2
| | | | | | | | | Check async abort notification. libavformat already do something equivalent. Before this commit, the demuxer could enter resync mode (and print silly warning messages) when the stream stopped returning data because of an abort.
* demux_mkv: actually skip elements out of reachwm42015-03-061-1/+2
| | | | | This is missing from the previous commit. Not that harmful, but also slightly un-nice since even a failed seek will reset the cache.
* demux_mkv: fix issues with unseekable streamswm42015-03-061-14/+16
| | | | | | | | | | | | | | | A user reported a webm stream that couldn't be played. The issue was that this stream 1. was on an unseekable HTTP connection, and 2. had a SeekHead element (wtf?). The code reading the SeekHead marked the element as unreadable too early: although you can't seek in the stream, reading the header elements after the SeekHead read them anyway. Marking them as unreadable only after the normal header reading fixes this. (The way the failing stream was setup was pretty retarded: inserting these SeekHead elements makes absolutely no sense for a stream that cannot be seeked.) Fixes #1656.
* buid: readd -Wparentheseswm42015-03-021-2/+2
| | | | | | | | | This warning wasn't overly helpful in the past, and warned against perfectly fine code. But at least with recent gcc versions, this is the warning that complains about assignments in if expressions (why???), so we want to enable it. Also change all the code this warning complains about for no reason.
* demux_mkv: minor refactor for deferred cue readingwm42015-02-251-45/+41
| | | | | | Should behave about the same, but reduces code some duplication with seeking and reading a header element pointed to by a SeekHead. It also makes behavior with incomplete files slightly better.
* demux_mkv: don't spam too many warnings with partial fileswm42015-02-251-14/+15
| | | | | Limit it to a single message. It often printed more than that, and in some cases (old files with "cluster" index), spammed a lot.
* video: remove redundant codec parameterswm42015-02-241-2/+0
| | | | | | | Remove coded_width and coded_height. This was originally added in commit fd7dde40, when BITMAPINFOHEADER was killed. The separate fields became redundant in commit e68f4be1. Remove them (nothing passed to the decoders actually changes with _this_ commit).
* demux, matroska: remove demuxer type fieldwm42015-02-171-1/+0
| | | | | | | | | | | | | The Matroska timeline code was the only thing which still used the demuxer.type field. This field explicitly identifies a demuxer implementation. The purpose of the Matroska timeline code was to reject files that are not Matroska. But it already forces the Matroska format, meaning loading will explicitly only use the Matroska demuxer. If the demuxer can't open the file, no other demuxer will be tried, and thus checking the field is redundant. The change in demux_mkv_timeline.c removes the if condition, and unindents the if body.
* matroska: make timeline code independent of MPContextwm42015-02-171-1/+2
|
* demux: hack for instant stream switchingwm42015-02-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |