summaryrefslogtreecommitdiffstats
path: root/demux/demux_mkv.c
Commit message (Collapse)AuthorAgeFilesLines
* matroska: prevent uids from being dereferenced when NULLBen Boeckel2013-09-271-5/+5
| | | | | | The old code prevented it since uids being NULL makes a 0 talloc length. Now that we're iterating over a specific length, NULL can be dereferenced.
* matroska: fix uninitialized memory accesses with ordered chaptersBen Boeckel2013-09-261-1/+1
| | | | | | | There is uninitialized memory access if the actual size isn't passed along. In the worst case, this can cause a source to be loaded against the uninitialized memory, causing a false count of found versus required sources, preventing the "Failed to find ordered chapter part" message.
* demux_mkv: don't add too many subtitle packets during seekingwm42013-09-161-14/+19
| | | | | | | | | | | | | | | | | | | | | In insane files with a very huge number of subtitle events, and if the --demuxer-mkv-subtitle-preroll option is given, seeking can still overflow the packet queue. Normally, the subtitle_preroll variable specifies the maximum number of packets that can be added. But once this number is reached, the normal seeking behavior is enabled, which will add all subtitle packets with the right timestamps to the packet queue. At this point the next video keyframe can still be quite far away, with enough subtitle packets on the way to overflow the packet queue. Fix this by always setting an upper limit of subtitle packets read during seeking. This should provide additional robustness even if the preroll option is not used. This means that even with normal seeking, at most 500 subtitle packets are demuxed. Packets after that are discarded. One slightly questionable aspect of this commit is that subtitle_preroll is never reset in audio-only mode, but that is probably ok.
* demux: keep title chapter tag in uppercasewm42013-09-081-1/+1
| | | | | | | This is generally more uniform. Do the same for the file global title in demux_mkv.c, although that is not strictly related to chapters.
* demux_mkv: support V_PRORESwm42013-09-081-0/+9
| | | | | | | Why not... Code for demangling Matroska-style prores video packets inspired by libavformat's Matroska demuxer.
* demux: retrieve per-chapter metadatawm42013-09-081-4/+15
| | | | | | | | | | Retrieve per-chapter metadata, but don't do much with it. We just make the metadata of the _current_ chapter available as chapter-metadata property. Returning the full chapter list with metadata would be no problem, except that the property interface isn't really good with structured data, so it's not available for now. Not sure if it's worth it, but it was requested via github issue #201.
* demux_mkv: don't overflow packet queue when doing sub-prerollwm42013-09-081-4/+13
| | | | | | | | | | | | | | Consider the cluster used for prerolling contains an insane amount of subtitle packets. Then the demuxer packet queue would be full of subtitle packets, and demux.c would refuse to read any further packets - including video and audio packets, resulting in EOF. Since everything involving Matroska and subtitles is 100% insane, this can actually happen. Fix this by putting a limit on the number of subtitle packets read by preroll, and throw away any further packets if the limit is exceeded. If this happens, the preroll mechanism will stop working, but the player's operation is unaffected otherwise.
* sub: add webvtt-in-webm supportwm42013-08-241-0/+2
| | | | | | | | | | | | | | The way this was added to FFmpeg is less than ideal, because it requires text parsing in the Matroska demuxer. But in order to use the FFmpeg webvtt-to-ass converter, we still have to mimic this in some way. We do this by putting the parsing into sd_lavc_conv.c, before the subtitle packet is passed to libavcodec. At least this keeps the ugliness out of unrelated code. There is some change that FFmpeg will fix their design eventually. Instead of rewriting the parsing code, we simply borrow it from FFmpeg's Matroska demuxer.
* demux: remove unused audio_delay parameter from demux_seek()wm42013-08-221-2/+1
| | | | Used to be needed by demux_avi.
* options: replace --edition=-1 with --edition=autowm42013-08-211-2/+3
| | | | | | Originally, the objective of this commit was changing --edition to be 1-based, but this was cancelled. I'm still leaving the change to demux_mkv.c though, which is now only of cosmetic nature.
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-061-3/+3
| | | | Followup commit. Fixes all the files references.
* 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
| |