summaryrefslogtreecommitdiffstats
path: root/demux/demux_mkv.c
Commit message (Collapse)AuthorAgeFilesLines
* Fix some -Wshadow warningswm42013-07-231-8/+7
| | | | | | In general, this warning can hint to actual bugs. We don't enable it yet, because it would conflict with some unmerged code, and we should check with clang too (this commit was done by testing with gcc).
* demux_mkv: fix realaudio timestampswm42013-07-201-2/+2
| | | | | | | This fixes the sample RA_missing_timestamps.mkv. Pretty funny how this code got it almost right, but not quite, so it was broken all these years. And then, after everyone stopped caring, someone comes and fixes it. (By the way, I know absolutely nothing about realaudio.)
* demux_mkv: ignore DefaultDuration in some caseswm42013-07-161-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes playback of the sample linked by FFmpeg ticket 2508. The fix follows ffmpeg commit 6158a3b (although it's not exactly the same). The problem here is that the file contains an apparently non-sense DefaultDuration value. DefaultDuration for audio tracks is used to derive PTS values for packets with no timestamps, like they can happen with frames inside a laced block. So the first packet of a SimpleBlock will have a correct PTS, while the PTS values of the following packets are calculated using DefaultDuration, and thus are broken. This leads to seemingly ok playback, but broken A/V sync. Not using the DefaultDuration value will leave the PTS values of these packets unset, and the audio decoder can derive them from the output instead. The fix more or less uses a heuristic to detect the broken case: if the sample rate is 8 KHz (Matroska default, can assume unset), and the codec is AC3 (as the broken file did), don't use it. I'm not sure why this should be done only for AC3, maybe the muxing application (mkvmerge v4.9.1) has known issues with AC3. AC3 also doesn't support 8 KHz as sample rate natively. (By the way, I'm not sure why we should honor the DefaultDuration at all for audio. It doesn't seem to be needed. You can't seek to these frames, and decoders should always be able to produce perfect PTS values by adding the duration of the decoded audio to the first PTS.)
* demux_mkv: never force output sample ratewm42013-07-161-17/+10
| | | | | | | | | | | | | | Matroska has an output sample rate (OutputSamplingFrequency), which in theory should be forced instead of whatever the decoder outputs. But it appears no software (other than mplayer2 and mpv until now) actually respects this. Even worse, there were broken files around, which played correctly with (in theory) broken software, but not mplayer2/mpv. Hacks were added to our code to play these files correctly, but they didn't catch all cases. Simplify this by doing what everyone else does, and always use the decoder's sample rate instead. In particular, we try to handle all sample rate issues like libavformat's Matroska demuxer does.
* demux_mkv: remove weird i_bps calculation codewm42013-07-121-20/+0
| | | | Useless, as i_bps isn't really used for anything anymore.
* demux: make claiming accurate seek the defaultwm42013-07-121-2/+0
| | | | Enables hr-seek for raw audio/video demuxers.
* demux: assume correct-pts mode by defaultwm42013-07-121-2/+0
| | | | | | | | All demuxers make a reasonable effort to set packet timestamps, and thus support correct-pts mode. This commit also implicitly switches demux_rawvideo to correct-pts mode. We still allow demuxers to disable correct-pts mode in theory.
* demux: remove useless author/comment fieldswm42013-07-121-4/+1
| | | | Same deal as with previous commit.
* demux: rewrite probing and demuxer initializationwm42013-07-121-3/+2
| | | | | | | | | | | | | | Get rid of the strange and messy reliance on DEMUXER_TYPE_ constants. Instead of having two open functions for the demuxer callbacks (which somehow are both optional, but you can also decide to implement both...), just have one function. This function takes a parameter that tells the demuxer how strictly it should check for the file headers. This is a nice simplification and allows more flexibility. Remove the file extension code. This literally did nothing (anymore). Change demux_lavf so that we check our other builtin demuxers first before libavformat tries to guess by file extension.
* demux: change signature of open functions, cleanupswm42013-07-111-17/+16
| | | | Preparation for redoing the open functions.
* stheader: minor cleanupwm42013-07-111-1/+1
| | | | | | | Move codec_tags.h include to demux_mkv.c, because this is the only file which still uses it. Move new_sh_stream() to demux.h, because this is more proper.
* video: eliminate frametime variablewm42013-07-111-1/+0
|
* core: don't access demux_stream outside of demux.c, make it privatewm42013-07-111-5/+5
| | | | | | | | | | | | | | | | | | | Generally remove all accesses to demux_stream from all the code, except inside of demux.c. Make it completely private to demux.c. This simplifies the code because it removes an extra concept. In demux.c it is reduced to a simple packet queue. There were other uses of demux_stream, but they were removed or are removed with this commit. Remove the extra "ds" argument to demux fill_buffer callback. It was used by demux_avi and the TV pseudo-demuxer only. Remove usage of d_video->last_pts from the no-correct-pts code. This field contains the last PTS retrieved after a packet that is not NOPTS. We can easily get this value manually because we read the packets ourselves. Reuse sh_video->last_pts to store the packet PTS values. It was used only by the correct-pts code before, and like d_video->last_pts, it is reset on seek. The behavior should be exactly the same.
* demux: remove separate arrays for audio/video/sub streams, simplifywm42013-07-081-5/+3
| | | | | | | | | | | | These separate arrays were used by the old demuxers and are not needed anymore. We can simplify track switching as well. One interesting thing is that stream/tv.c (which is a demuxer) won't respect --no-audio anymore. It will probably work as expected, but it will still open an audio device etc. - this is because track selection is now always done with the runtime track switching mechanism. Maybe the TV code could be updated to do proper runtime switching, but I can't test this stuff.
* Remove old demuxerswm42013-07-071-1/+2
| | | | | | | | | | Delete demux_avi, demux_asf, demux_mpg, demux_ts. libavformat does better than them (except in rare corner cases), and the demuxers have a bad influence on the rest of the code. Often they don't output proper packets, and require additional audio and video parsing. Most work only in --no-correct-pts mode. Remove them to facilitate further cleanups.
* demux_mkv: pass extradata for opuswm42013-07-011-0/+1
| | | | Fixes playing 5.1 opus audio tracks.
* demux_mkv: clang: fix -Wunused-functionStefano Pigozzi2013-05-301-0/+2
| | | | This was introduced with c0db930d.
* demux_mkv: replace awkward goto by function callwm42013-05-301-39/+43
| | | | Requires reindenting a large code block to minimize random control flow.
* demux_mkv: make sure wavpacks works with older libavcodec versionswm42013-05-301-0/+15
| | | | | | | | The new wavpack packet format (see previous commit) doesn't work with older libavcodec versions, so disable the new code in this case. The version numbers are only approximate, since the libavcodec version wasn't bumped with the wavpack change, but it's close enough.
* demux_mkv: fix wavpack in mkvwm42013-05-301-0/+92
| | | | | | | | | | | | | | | Libav introduced a silent API breakage by changing what wavpack packets the libavcodec decoder accepts. Originally the libavcodec codec accepted Matroska-style wavpack packets. Libav commit 9b6f47c removed this capability from the libavcodec code, and added code to libavformat's Matroska demuxer to "rearrange" wavpack packets. Since demux_mkv still sent Matroska-style packets, playback failed. Fix this by "rearranging" packets in demux_mkv as well by copying libavformat's code. (The best kind of fix.) Tested with [CCCP]_Mega_Lossless_Audio_Test.mkv, as well as with a sample generated by mkvmerge.
* demux_mkv: defer reading of seek index until first seekwm42013-05-231-3/+42
| | | | | | | | | | | | | | | | | | | | | | Playing Youtube videos often requires an additional seek to the end of the file. This flushes the stream cache. The reason for the seek is reading the cues (seek index). This poses the question why Google is muxing its files in such a way, since nothing in Matroska mandates that cues are located at the end of the file, but we want to handle this situation better anyway. The seek index is not needed for normal playback, only for seeking. This commit changes header parsing such that the index is not read on initialization in order to avoid the additional stream-level seek. Instead, read the index on the first demuxer-level seek, when the seek index is actually needed. If the cues are at the beginning of the file, they are read immediately as part of the normal header reading process. This commit changes behavior only if cues are outside of the header (i.e. not in the area between EBML header and clusters), and linked by a SeekHead. Other level 1 elements linked by the SeekHead might still cause seeks to the end of the file, although that seems to be rare.
* demux_mkv: use a single flag to indicate whether cues have been readwm42013-05-231-1/+3
| | | | | | | | | | | | Before this commit, the demuxer would in theory accept multiple cues elements (and append its contents to the index in the order as encountered during reading). According to the Matroska specification, there can be only one cues element in the segment, so this seems like an overcomplication. Change it so that redundant elements are ignored, like with all other unique header elements. This makes implementing deferred reading of the cues element easier.
* demux_mkv: support dirac in mkvwm42013-05-211-0/+1
| | | | | | | | | | | | | | Nobody uses this, and this is an absolute waste of time. Even the user who reported this turned out to have produced a sample manually. Sample produced with: wget http://diracvideo.org/download/test-streams/raw/vts/vts.LD-8Mb.drc mkvmerge -o dirac.mkv vts.LD-8Mb.drc mkvmerge writes a sort of broken aspect ratio. libavformat interprets it as 1:1 PAR, while demux_mkv thinks this is a 1:1 DAR. Maybe libavformat is more correct here.
* Silence some compiler warningswm42013-05-211-1/+1
| | | | None of these were actual issues.
* demux_mkv: export Matroska title element as metadatawm42013-05-151-0/+3
|
* Merge branch 'audio_changes'wm42013-05-121-3/+3
|\ | | | | | | | | Conflicts: audio/out/ao_lavc.c
| * core: use channel map on demuxer level toowm42013-05-121-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This helps passing the channel layout correctly from decoder to audio filter chain. (Because that part "reuses" the demuxer level codec parameters, which is very disgusting.) Note that ffmpeg stuff already passed the channel layout via mp_copy_lav_codec_headers(). So other than easier dealing with the demuxer/decoder parameters mess, there's no real advantage to doing this. Make the --channels option accept a channel map. Since simple numbers map to standard layouts with the given number of channels, this is downwards compatible. Likewise for demux_rawaudio.
* | Fix some cppcheck / scan-build warningswm42013-05-061-0/+2
| | | | | | | | | | | | | | | | These were found by the cppcheck and scan-build static analyzers. Most of these aren't interesting (the 2 previous commits fix some interesting cases found by these analyzers), and they don't nearly fix all warnings. (Most of the unfixed warnings are spam, things MPlayer never cared about, or false positives.)
* | demux_mkv: fix segfault issue playing back VC1 in a mkvBin Jin2013-04-271-1/+1
| | | | | | | | This bug was introduced in commit 06eee1b.
* | demux_mkv: cosmeticswm42013-04-241-4/+3
| |
* | demux_mkv: fix out of range comparisonwm42013-04-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | This check was always false: if (num == EBML_UINT_INVALID) Fix it by using the proper type for the num variable. This case actually doesn't really matter, and this is just for hiding the warning and for being 100% correct.
* | demux_mkv: always set track->codec_id to a stringwm42013-04-201-1/+3
| | | | | | | | | | Otherwise audio/video/sub track handling code would dereference the NULL pointer.
* | demux_mkv: always add subtitle trackswm42013-04-201-26/+26
| | | | | | | | Even if the codec is unknown.
* | sub, demux: identify subtitle types with the codec namewm42013-04-201-16/+21
| | | | | | | | | | | | | | | | | | Get rid of the 1-char subtitle type field. Use sh_stream->codec instead just like audio and video do. Use codec names as defined by libavcodec for simplicity, even if they're somewhat verbose and annoying. Note that ffmpeg might switch to "ass" as codec name for ASS, so we don't bother with the current silly "ssa" name.
* | demux_mkv: introduce new_demux_packet_from() and use itwm42013-04-201-9/+6
| |
* | demux_mkv: simplify use of demuxer APIwm42013-04-201-106/+62
| | | | | | | | | | | | | | mkv_track_t now references sh_stream directly, instead of using an ID. Also remove all accesses to demux_stream (demuxer->video etc.). Remove some slave-mode things on the way, like "ID_SID_..." messages.
* | demux_mkv: code cleanupeng2013-04-201-20/+23
| | | | | | | | | | | | Cleanup based on results from cppcheck-1.59 Reduce the scope of several variables Replace 2 calloc/realloc calls with a single malloc
* | demux_mkv: use new way of track switchingwm42013-04-201-45/+0
| | | | | | | | | | | | Since demux_mkv queries the demuxer state when reading packets, track switching is completely passive. Cycling etc. is done by the frontend. As result, all track switching code can be removed.
* | demux_mkv: remove pointless video track selectionwm42013-04-201-37/+0
| | | | | | | | Possibly once needed, now it's just redundant code.
* | demux_mkv: support vp9wm42013-04-201-0/+1
| | | | | | | | Note that ffmpeg doesn't provide a decoder by default yet.
* | core: matroska: support concatenated segmentswm42013-04-201-10/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Matroska files can contain multiple segments, which are literally further Matroska files appended to the main file. They can be referenced by segment linking. While this is an extraordinarily useless and dumb feature, we support it for the hell of it. This is implemented by adding a further demuxer parameter for skipping segments. When scanning for linked segments, each file is opened multiple times, until there are no further segments found. Each segment will have a separate demuxer instance (with a separate file handle etc.). It appears the Matroska spec. has an even worse feature for segments: live streaming can completely reconfigure the stream by starting a new segment. We won't add support for it, because there are 0 people on this earth who think Matroska life streaming is a good idea. (As opposed to serving Matroska/WebM files via HTTP.)
* | demux_mkv: don't terminate if there are no clusterswm42013-04-201-2/+3
| | | | | | | | | | | | Matroska segment linking allows abusing Matroska files as playlists without any actual video/audio/sub data, making files without any clusters still useful for the frontend.
* | demux_mkv: simplify handle_block() logic a bitwm42013-04-201-11/+8
| |
* | demux_mkv: verify laces separately, and in all caseswm42013-04-201-4/+10
| |
* | demux_mkv: get rid of the duplicated lace case labelswm42013-04-201-9/+4
| | | | | | | | | | Also change the extracting of the lace type bitfield from flags to make it more apparent that the value range is 0-3.
* | demux_mkv: there can be 256 laceswm42013-04-201-6/+5
| | | | | | | | | | The lace number is stored with an offset of 1, so the maximum number of laces is 255+1=256.
* | demux_mkv: check block malloc() resultwm42013-04-201-0/+2
| |
* | demux_mkv: use a bounded buffer for block datawm42013-04-201-108/+105
| | | | | | | | Should help avoiding out-of-bounds reads.
* | demux_mkv: static allocation for lace sizes bufferwm42013-04-201-12/+8
| | | | | | | | | | | | | | | | Avoid messy memory management and error handling. remove tmp_lace_buffer non-sense Not sure how my mind got 8k, or how this made sense at all.
* | demux_mkv: remove redundant checkwm42013-04-201-39/+37
| |
* | demux_mkv: fix seeking with index generationwm42013-04-201-45/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Relative seeks backwards didn't work too well with incomplete files, or other files that are missing the seek index. The problem was that the on-the-fly seek index generation simply added cluster positions as seek entries. While this is perfectly fine, the seek code had no information about the location of video key frames. For example, a 5 second long cluster can have only 1 video key frame, which is located 4 seconds into the cluster. Seeking backwards by one second while still located in the same cluster would select this cluster as seek target again. Decoding would resume with the key frame, giving the impression that seeking is "stuck" at this frame. Make the generated index aware of key frame and track information, so that video can always be seeked in an idea way. This also uses the normal block parsing code for indexing the clusters, instead of the suspicious looking special code. (This code didn't parse the Matroska elements correctly, but was fine for files with normal structure. Files with corrupted clusters or clusters formatted for streaming were not handled properly.) Skipping is now quite a bit slower (takes about twice as long as before), but it removes the special cased skipping code, and it's still much faster (at least twice as fast) than libavformat. It needs to do more I/O (no more skipping entire clusters, all data is read), and has more CPU usage (more data needs to be parsed).
* | demux_mkv: move Block header parsing codewm42013-04-201-34/+43
| | | | | | | | | | | | Move parts of the Block element parsing to read_block(). This way read_block() can return block time and track information in struct block_info.
* | demux_mkv: split reading blocks and reading packetswm42013-04-201-37/+47
| | | | | | | | | | |