summaryrefslogtreecommitdiffstats
path: root/demux/demux_mkv.c
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This removes the delay when switching audio tracks in mkv or mp4 files. Other formats are not enabled, because it's not clear whether the demuxers fulfill the requirements listed in demux.h. (Many formats definitely do not with libavformat.) Background: The demuxer packet cache buffers a certain amount of packets. This includes only packets from selected streams. We discard packets from other streams for various reasons. This introduces a problem: switching to a different audio track introduces a delay. The delay is as big as the demuxer packet cache buffer, because while the file was read ahead to fill the packet buffer, the process of reading packets also discarded all packets from the previously not selected audio stream. Once the remaining packet buffer has been played, new audio packets are available and you hear audio again. We could probably just not discard packets from unselected streams. But this would require additional memory and CPU resources, and also it's hard to tell when packets from unused streams should be discarded (we don't want to keep them forever; it'd be a memory leak). We could also issue a player hr-seek to the current playback position, which would solve the problem in 1 line of code or so. But this can be rather slow. So what we do in this commit instead is: we just seek back to the position where our current packet buffer starts, and start demuxing from this position again. This way we can get the "past" packets for the newly selected stream. For streams which were already selected the packets are simply discarded until the previous position is reached again. That latter part is the hard part. We really want to skip packets exactly until the position where we left off previously, or we will skip packets or feed packets to the decoder twice. If we assume that the demuxer is deterministic (returns exactly the same packets after a seek to a previous position), then we can try to check whether it's the same packet as the one at the end of the packet buffer. If it is, we know that the packet after it is where we left off last time. Unfortunately, this is not very robust, and maybe it can't be made robust. Currently we use the demux_packet.pos field as unique packet ID - which works fine in some scenarios, but will break in arbitrary ways if the basic requirement to the demuxer (as listed in the demux.h additions) are broken. Thus, this is enabled only for the internal mkv demuxer and the libavformat mp4 demuxer. (libavformat mkv does not work, because the packet positions are not unique. Probably could be fixed upstream, but it's not clear whether it's a bug or a feature.)
* demux_mkv: return unique file positions for all packetswm42015-02-131-4/+5
| | | | | | | | | | | | | Until now, some packets could return the same file position if they were split off from a Matroska-level packet. This was perfectly fine, because the file position isn't used for anything overly important (it uses it to estimate playback position if no other information is available). The following commit will use the demux_packet.pos field as unique ID (as a simplification), so make the demuxer export more finegrained information. Also, the last_filepos field didn't have to be global, at least not anymore.
* demux_mkv: remove the realmedia fieldwm42015-02-051-25/+21
| | | | | | Granted, this doesn't help much with anything, other than the hate- driven desire to remove or at least reduce anything that has to do with RealMedia.
* demux_mkv: reindent, cosmeticswm42015-02-051-97/+79
| | | | | | | | | | Reindent the whole handle_realaudio() function, and make the surrouding if block return early instead. Also contains some cosmetics to the sipr swapping, which hopefully does not change the semantics, but is untested (the kind of cosmetic changes everyone loves so much). May the person responsible for sipr rot in hell. (It was probably done to obfuscate the codec?)
* demux_mkv: simplify realaudio handlingwm42015-02-051-30/+17
| | | | | | | Staring at the code, it doesn't look like the extra code for "normal" audio is needed. Most of it looks like artifacts from the previous code structure (much of it was added in the initial commit). I couldn't find a sample that uses this code path to fully confirm this, though.
* demux_mkv: remove realvideo-specific aspect ratio handlingwm42015-02-051-17/+5
| | | | | | | | I suppose it could lead to subtle changes in behavior in presence of realvideo files that change aspect radio. With the only sample I had available, the behavior actually improved (azumi.mkv from the MPlayer samples FTP; when starting playback in the middle it used the wrong aspect ratio).
* demux_mkv: use libavcodec parser for realvideowm42015-02-051-68/+4
| | | | | | Appears to work, so we can drop some code. For some really odd reason, the descrambling done on the timestamp requires millisecond units (due to the "algorithm", not the libavcodec API).
* demux_mkv: retrieve timestamps from libavcodec parserwm42015-02-051-3/+16
| | | | | | | | | Fixes vp9 missing timestamps. This requires a brand new libavcodec (the patch for this was just applied to FFmpeg git master). The timestamp mangling is applied to VP9 only. It'd probably work with other codecs, but it's not needed. It could break in various ways, so it has to be explicitly checked for every enabled codec.
* demux_mkv: refactor packet parsingwm42015-02-051-83/+102
| | | | | | | | Makes it somewhat more uniform, and breaks up the awfully deep nesting. This implicitly changes multiple small details, rather than only moving code around. In particular, this computes the packet fields first and parses them afterwards, which is needed for the next commit.
* demux_mkv: use unique IDs for cover art pseudo-trackswm42015-02-011-0/+1
| | | | | | | Might fix behavior with mkv files that use ordered chapters and have cover art tags. In my opinion, this should actually have worked (because cover art pseudo-tracks are strictly appended), but I don't have a sample file to test at hand.
* player: demote matroska ordered chapter scanning messages to VerboseDiogo Franco (Kovensky)2015-01-281-1/+1
| | | | | Causes a lot of terminal spam on large folders and is not actually useful except maybe for debugging.
* demux_mkv: avoid endless loop with broken fileswm42015-01-121-1/+1
| | | | Fixes #1457.
* demux_mkv: improve robustness against broken libavcodec parserswm42015-01-091-2/+2
| | | | | | | | | The VP9 codec parser has a bug: it doesn't set the data/size pointers passed to it. As I understand, it must always do this, and in fact, if it doesn't some libavcodec generic code would be in trouble too. This helps with #1448, but is not the full fix for it. The codec parser must be fixed in libavcodec itself.
* demux_mkv: avoid PTS warning with image attachmentswm42015-01-051-0/+5
| | | | | | | Removes an annoying "No video PTS! Making something up." warning. Mark it as keyframe, which is needed to prevent strange behavior with PNG. Also, don't leak the picture data.
* demux_mkv: enable codec parsing for vfw-muxed files toowm42014-12-311-9/+10
| | | | | | | | | | | | For some codecs, we need to invoke a codec parser (because libavcodec will run into trouble otherwise). This was done based on the Matroska codec field. But this ignores handling of vfw-muxed files, which use a pseudo-codec to signal presence of vfw structures, which we must unmangle to get the real codec. Handle this by rearranging the code. This fixes at least mp3-in-mkv for vfw-muxed files; typically old files.
* demux_mkv: reduce log noisewm42014-12-291-2/+2
| | | | | | | This message can happen a lot for mkv files which index clusters in the seekhead (which is also broken non-sense, but that's a different story). Also remove a duplicate define from matroska.h.
* demux_mkv: use attachment filename as coverart titlewm42014-12-231-0/+1
|
* demux_mkv: support embedded coverartwm42014-12-221-1/+15
| | | | | | | | | | | The code could as well be in demux.c, but it's better to avoid accidental clashes with demux_lavf.c. FFmpeg provides no way yet to map a mime type to a codec, so do it manually. (It _can_ map a mime type to an "input format", but not a codec.) Fixes #1374.
* demux_mkv: support svq3wm42014-12-081-14/+24
| | | | | | | | | | The most awesome codec, not. The actual code for svq3 is actually just the part that checks for MKV_V_QUICKTIME (no other QT-muxed codecs are supported). The rest is minor refactoring, that actually improves the code in general. This is just enough to support the 2 svq3-in-mkv sample files I have.
* demux_mkv: reject 0 TimecodeScalewm42014-12-061-0/+4
| | | | | | | Also reject anything over INT_MAX; no particular reason for this upper bound. Fixes #1317.
* demux_mkv: remove ancient codec mapping leftoverswm42014-11-281-1/+0
| | | | | | | | | | | | | | | | | | | All of this is basically due to how MPlayer's codecs.conf worked. It had a demuxer-interface based an AVI, using FourCCs and data structures found in AVI. FourCCs were used to map streams to decoders. For codecs not supported by AVI, "MPlayer internal" FourCCs were made up. codec_tags.c is there to bridge demuxers written against the old API to the mpv one. By now, only demux_mkv.c needs this (because demux_mkv is the only serious demuxer left - preferably, we should use libavformat for mkv too, but I can't see this happening any time soon, because libavformat _still_ doesn't support segment linking). But the codec tables are full of weird stuff automatically extracted from the old codecs.conf tables. Most of it isn't needed for mkv. Remove all custom tags, readd those used by demux_mkv.c internally (see vinfo and mkv_audio_tag tables). The rest is handled by the tables provided by libavformat, which includes AVI and QT tags.
* demux_mkv: simplify extradata handlingwm42014-11-271-37/+12
| | | | | | | | | It was more complicated than necessary. The behavior changes slightly. Now it might pass through extradata when it didn't before (hopefully harmless), and doesn't fail with an error if extradata is not available, even though it's needed (harmless, will fail either way).
* demux_mkv: cosmeticswm42014-11-271-24/+13
|
* demux_mkv: fix a possible out of bounds accesswm42014-11-271-6/+8
| | | | | | | | | | | | | The if branch has a weak check to test whether the codec_id is the short ID, and handles the long IDs in the else branch. The long IDs are all longer than 12 bytes long, so hardcoding the string offset to get the trailing part of the name makes sense. But the if condition checks for another thing, which could get the else branch run even if the codec_id is short. Fix the bogus control flow and check if the codec_id is long enough. One of these checks could be considered redundant, but include them both for defensive coding.
* demux_mkv: fix scary sign extension issueswm42014-11-211-8/+8
| | | | | | | Expressions involving uint16_t are promoted to int, which then can overflow if the uint16_t values are large enough. Found by Coverity.
* demux_mkv: fix possible real-audio out of bounds accesseswm42014-11-211-1/+7
| | | | | | | Could index static arrays from arbitrary input data without checking for bounds. Found by Coverity.
* demux_mkv: fix uninitialized variablewm42014-11-211-1/+1
| | | | Found by Coverity.
* demux_mkv: haali hack: add last frame duration to video length toowm42014-11-201-2/+3
| | | | | From what I can see, only the blockduration of the packet needs to be added, never the "default duration".
* demux_mkv: add an option for compatibility with Haaliwm42014-11-181-0/+65
| | | | This was requested on IRC.
* demux_mkv: check file type without actually reading datawm42014-11-161-0/+7
| | | | | | | | Do a minimal check on data read with stream_peek(). This could help with probing from unseekable streams in some situations. (We could check the entire EBML and Matroska headers, but probably not worth the trouble. We could also seek back to the start, which demux.c doesn't do, but which would work usually - also not worth the trouble.)
* demux_mkv: adjust subtitle preroll again (2)wm42014-11-151-3/+12
| | | | | | | | | | | | | | Make the changes started in commit c827ae5f more eloborate, and provide an option to control the amount of data read before the seek-target. To achieve this, rewrite the loop that finds the lowest still acceptable target cluster. It is now searched by time instead of file position. The behavior (both with and without preroll option) may be different from before this change, although it shouldn't be worse. The change demux_mkv_read_cues() fixes a bug: when seeking after playing normally, the code would erroneously assume that durations are set. This doesn't happen if the first operation after loading was a seek instead of playback.
* demux_mkv: adjust subtitle preroll againwm42014-11-111-14/+17
| | | | | | | | | | | | | | | Revert commit 24e52f66; even though the old beheavior doesn't make sense (as the commit message assured), it turns out that this works better: typically, it means preroll will start from the previous video key frame (the video CUE index will contain clusters with video key frames only), which often coincides with subtitle changes. Thus the old behavior is actually better. Change the code that uses CueDuration elements. Instead of merely checking whether preroll should be done, find the first cluster that needs to be read to get all subtitle packets. (The intention is to compensate for the enlarged preroll cluster-range due to reverting commit 24e52f66.)
* demux_mkv: fix indentationwm42014-11-051-3/+3
| | | | Meh.
* demux_mkv: for subtitle preroll, consider all clusterswm42014-11-051-5/+3
| | | | | | | | | This considered only index entries that were for the same track ID as the track used for seeking. This doesn't make much sense for preroll; it'll just possibly skip clusters, and select an earlier cluster. One possible negative side-effect is that the preroll might be too tight now, and miss subtitle packets more often.
* demux_mkv: apply subtitle preroll only if needed, based on cue indexwm42014-11-051-0/+16
| | | | | | | | | The demuxer has a hack to seek to the cluster before the target cluster in order to "catch" subtitle lines that start before the seek target, but overlap with the video after the seek target. Avoid this hack if the cue index indicates that there are no overlapping subtitle packets that can be caught by seeking to the previous cluster.
* demux_mkv: read CueRelativePosition/CueDuration elementswm42014-11-051-11/+27
| | | | | | | | Nothing is done with them yet. This is preparation for the following commit. CueRelativePosition isn't even saved anywhere, because I don't intend to use it. (Too messy for no gain.)
* demux_mkv: index all packetswm42014-11-051-4/+2
| | | | | | | | | | | | Instead of indexing only 1 packet per cluster (which is enough for working seeking), add every packet to the index. Since on seek, we go through every single index entry, this probably makes seeking slower. On the other hand, this code is used for files without index only (e.g. incomplete files), so it probably doesn't matter much. Preparation for the following commits.
* demux_mkv: remove minor code duplicationwm42014-11-031-12/+6
|
* demux_mkv: implement audio skipping/trimmingwm42014-11-031-2/+23
| | | | | | | | | | | | | This mechanism was introduced for Opus, and allows correct skipping of "preroll" data, as well as discarding trailing audio if the file's length isn't a multiple of the audio frame size. Not sure how to handle seeking. I don't understand the purpose of the SeekPreRoll element. This was tested with correctness_trimming_nobeeps.opus, remuxed to mka with mkvmerge v7.2.0. It seems to be correct, although the reported file duration is incorrect (maybe a mkvmerge issue).
* player: always use demux_chapterwm42014-11-021-1/+1
| | | | | | | | | Instead of defining a separate data structure in the core. For some odd reason, demux_chapter exported the chapter time in nano-seconds. Change that to the usual timestamps (rename the field to make any code relying on this to fail compilation), and also remove the unused chapter end time.
* demux: move some seek flag sanitation to generic codewm42014-10-291-10/+2
| | | | No reason why only