summaryrefslogtreecommitdiffstats
path: root/demux/demux_mkv.c
Commit message (Collapse)AuthorAgeFilesLines
* demux: move some seek flag sanitation to generic codewm42014-10-291-10/+2
| | | | No reason why only demux_mkv.c should do this.
* demux_mkv: implement percentage seeking with no indexwm42014-10-291-22/+24
| | | | It was implemented only for the case the index exists (pretty useless).
* demux_mkv: export packet file positionwm42014-10-291-0/+1
| | | | | This gives us approximate fallback playback percentage position if the duration is unknown.
* demux_mkv: fix undefined behaviorwm42014-10-131-1/+1
| | | | | | | With some files, the extradata variable can remain uninitialized, but will be used for memory access. CC: @mpv-player/stable (with high priority)
* demux_mkv: don't use default_duration for parsed packetswm42014-09-261-4/+6
| | | | | | | | | Makes it behave slightly better for VP9. This is also the behavior libavformat has. Also while we're at it, don't set duration except for the first packet. Normally we don't use the duration except for subtitles (which are never parsed or "laced"), so this should make no observable difference.
* demux_mkv: get rid of MS structswm42014-09-251-66/+38
| | | | | | | See previous commits. This finally replaces directly reading the file data into a struct with reading them manually. In theory this is more portable (no alignment issues and other things). For the most part, it's nice seeing this gone.
* audio: remove WAVEFORMATEX from internal demuxer APIwm42014-09-251-73/+78
| | | | | Same as with the previous commit. A bit more involved due to how the code is written.
* video: remove BITMAPINFOHEADER from internal demuxer APIwm42014-09-251-10/+7
| | | | | | | | | | MPlayer traditionally did this because it made sense: the most important formats (avi, asf/wmv) used Microsoft formats, and many important decoders (win32 binary codecs) also did. But the world has changed, and I've always wanted to get rid of this thing from the codebase. demux_mkv.c internally still uses it, because, guess what, Matroska has a VfW muxing mode, which uses these data structures natively.
* demux: gracefully handle packet allocation failureswm42014-09-161-1/+9
| | | | Now the packet allocation functions can fail.
* demux_mkv: allow up to 256 MB of extradata to make broken files workwm42014-09-041-1/+1
| | | | | | | | What the flying fuck? Unfortunately, these are already in the wild. CC: @mpv-player/stable
* video: initial Matroska 3D supportwm42014-08-301-0/+12
| | | | | | | | | | | | | | | | | | | | | This inserts an automatic conversion filter if a Matroska file is marked as 3D (StereoMode element). The basic idea is similar to video rotation and colorspace handling: the 3D mode is added as a property to the video params. Depending on this property, a video filter can be inserted. As of this commit, extending mp_image_params is actually completely unnecessary - but the idea is that it will make it easier to integrate with VOs supporting stereo 3D mogrification. Although vo_opengl does support some stereo rendering, it didn't support the mode my sample file used, so I'll leave that part for later. Not that most mappings from Matroska mode to vf_stereo3d mode are probably wrong, and some are missing. Assuming that Matroska modes, and vf_stereo3d in modes, and out modes are all the same might be an oversimplification - we'll see. See issue #1045.
* demux_mkv: eliminate redundant branchshdown2014-08-301-5/+1
| | | | | | In the else branch pict_type is always 3, so pict_type != 3 is always false. (Note that I have no idea of what it was supposed to do and it is just an equivalent of the old behaviour.)
* Move compat/ and bstr/ directory contents somewhere elsewm42014-08-291-1/+1
| | | | | | | | | bstr.c doesn't really deserve its own directory, and compat had just a few files, most of which may as well be in osdep. There isn't really any justification for these extra directories, so get rid of them. The compat/libav.h was empty - just delete it. We changed our approach to API compatibility, and will likely not need it anymore.
* demux: fix timestamp type for seek callswm42014-07-211-1/+1
| | | | | mpv/mplayer2/MPlayer use double for timestamps, but the demuxer API used float.
* demux: minor simplificationwm42014-07-061-2/+2
| | | | Oops, should have been part of commit 37085788.
* demux: minor simplification to internal APIwm42014-07-051-4/+4
| | | | Also some other unrelated minor changes.
* demux_mkv: cosmeticswm42014-07-051-45/+27
|
* demux_mkv: minor improvement to overflow checkwm42014-07-021-2/+3
| | | | CC: @mpv-player/stable
* Audit and replace all ctype.h useswm42014-07-011-1/+0
| | | | | | | | | | | | | | | | Something like "char *s = ...; isdigit(s[0]);" triggers undefined behavior, because char can be signed, and thus s[0] can be a negative value. The is*() functions require unsigned char _or_ EOF. EOF is a special value outside of unsigned char range, thus the argument to the is*() functions can't be a char. This undefined behavior can actually trigger crashes if the implementation of these functions e.g. uses lookup tables, which are then indexed with out-of-range values. Replace all <ctype.h> uses with our own custom mp_is*() functions added with misc/ctype.h. As a bonus, these functions are locale-independent. (Although currently, we _require_ C locale for other reasons.)
* demux_mkv: cosmeticswm42014-06-291-14/+14
|
* demux_mkv: add some overflow checks etc.wm42014-06-291-58/+102
| | | | | | | | | | | Some of these might be security relevant. The RealAudio code was especially bad. I'm not sure if all RealAudio stuff still plays correctly; I didn't have that many samples for testing. Some checks might be unnecessary or overcomplicated compared to the (obfuscated) nature of the code. CC: @mpv-player/stable
* demux_mkv: add S_DVBSUBwm42014-06-171-0/+1
| | | | Probably works; untested.
* options: turn --idx, --forceidx into --indexwm42014-06-131-1/+1
| | | | | | | | | | | | Also clarify the semantics. It seems --idx didn't do anything. Possibly it used to change how the now removed legacy demuxers like demux_avi used to behave. Or maybe it was accidental. --forceidx basically becomes --index=force. It's possible that new index modes will be added in the future, so I'm keeping it extensible, instead of e.g. creating --force-index.
* Add more constwm42014-06-111-3/+3
| | | | | | | While I'm not very fond of "const", it's important for declarations (it decides whether a symbol is emitted in a read-only or read/write section). Fix all these cases, so we have writeable global data only when we really need.
* stream: don't use end_poswm42014-05-241-4/+13
| | | | | | | | | | | | | | | | | | | Stop using it in most places, and prefer STREAM_CTRL_GET_SIZE. The advantage is that always the correct size will be used. There can be no doubt anymore whether the end_pos value is outdated (as it happens often with files that are being downloaded). Some streams still use end_pos. They don't change size, and it's easier to emulate STREAM_CTRL_GET_SIZE using end_pos, instead of adding a STREAM_CTRL_GET_SIZE implementation to these streams. Make sure int64_t is always used for STREAM_CTRL_GET_SIZE (it was uint64_t before). Remove the seek flags mess, and replace them with a seekable flag. Every stream must set it consistently now, and an assertion in stream.c checks this. Don't distinguish between streams that can only be forward or backwards seeked, since we have no such stream types.
* demux_mkv: enable parsing for VP9wm42014-04-261-2/+4
| | | | | | | | | | | | VP9 packets can contain 2 frames in some video packets (from which 1 frame is invisible). Due to a design mismatch between libvpx and the libavcodec vp9 decoder, libvpx can take the "full" packets, but lavc vp9 can not. The consequence is that we have to split the packets if we want to feed them to the lavc codec. This is not entirely correct yet: timestamp handling is missing. --demuxer=lavf and ffmpeg native utilities have the same problem. We can fix this only once the ffmpeg VP9 parser is fixed.
* demux_mkv: enable parsing for mp3wm42014-04-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | For some reason, some files appear to have broken mp3 packets, or at least in a form that libavcodec can't deal with. The audio in the sample file in question could not be decoded using libavcodec. The problematic file had variable packet sizes, and the libavcodec decoder kept printing "mp3: Header missing" for each packet it was fed. Remuxing with mkvmerge fixes the problem. The mp3 data is probably not VBR, and remuxing resulted in fixed-size mp3 frames. So I don't know why the sample file was muxed this way - it might just be incorrect. The sample file had "libmkv 0.6.4" as MuxingApp (although I could not get mkvinfo to print this element, maybe the file uses an incorrect element ID), and "HandBrake 0.9.4" as WritingApp. Note that the libmpg123 decoder does not have any issues with it. It's probably more robust, because libmpg123 was made to decode whole mp3 files, not just single frames. Fixes issue #742.
* Remove some more unneeded version checkswm42014-03-161-15/+0
| | | | | All of these check against things that happened before the latest supported FFmpeg/Libav release.
* demux_mkv: remove weird seeking semantics for audiowm42014-02-091-6/+1
| | | | | | | | | | | | This skipped all audio packets before the first video key frame was found. I'm not really sure why this would be needed; most likely it isn't. So get rid of it. Even if audio packets are returned to the player too soon, the player will sync the audio start to the video start by decoding and discarding audio data. Note that although the removed code was just added in the previous commit, it merely kept the old keeping semantics which demux_mkv always followed. This commit removes these special semantics.
* demux_mkv: improve audio-only seekingwm42014-02-091-5/+8
| | | | | | | | | | | | | | | | v_skip_to_keyframe is set to true while non-keyframe video packets are skipped. Until now, audio packets were also skipped when doing this. I can't see any good reason why this would be done, but for now I want to keep the old logic when audio+video seeks are done. However, for audio-only mode, do proper seeking, which also fixes behavior when trying to seek past the end of the file: playback is terminated properly, instead of starting playback on the start of the last cluster. Note that a_no_timecode_check is used only for audio+video seek. I'm not sure what this is needed for, but it might influence A/V sync after seeking.
* demux: fill metadata directly, instead of using wrapper functionswm42014-02-061-16/+17
| | | | | | Get rid of demux_info_add[_bstr] and demuxer_add_chapter_info. Make demuxer_add_chapter_info return the chapter index for convenience.
* demux_mkv: remove unused fieldwm42014-01-311-4/+0
|
* demux_mkv: nicer edition outputwm42014-01-231-10/+45
| | | | | | | | | | | If there's more than one edition, print the list of editions, including the edition name, whether the edition is selected, whether the edition is default, and the command line option to select the edition. (Similar to stream list.) Move reading the tags to a separate function process_tags(), which is called when all other state is parsed. Otherwise, that tags will be lost if chapters are read after the tags.
* demux_mkv: don't attempt to seek back when indexingwm42014-01-221-8/+0
| | | | | | | | | | | | Pretty worthless. This is called from the seek code, which will reinitialize these anyway. Even if seeking somehow decides to fail, the new values are still valid. One could say a failed seek (if that happens) should jump back to the original position, and thus it would be better to make sure the state is restored. But then demux_mkv_seek needs to do this correctly, including not setting up skipping to the target timestamp. But not bothering with this.
* demux_mkv: fix EOF with concatenated segmentswm42014-01-221-7/+14
| | | | | | | | | Extremely obscure corner case with concatenated segments, in which EOF wasn't recognized correctly, and it tried to demux clusters from the next segment. See [MKV]_Editions,_Linked_Segments,_&_Tracksets.mkv from the CCCP test file collection.
* demux_mkv: remove old track printing codewm42014-01-221-12/+0
| | | | | | This basically used to be part of the user interface, before mpv moved printing the track list to the frontend, and this code was raised to verbose output level.
* demux_mkv: always fail on header reading errorwm42014-01-221-6/+2
| | | | | | | | | | | For some reason, if an error happened when reading headers, it merely stopped reading the headers, and then continued normally. (It looks like the case to exit hard (-2) was mainly used for skipping unwanted ordered chapter segments.) I can't comprehend this. Always exit on error when reading headers. (Maybe some more error tolerance would be good, but I have no test case, and there's some danger of entering endless loops.)
* demux_mkv: avoid seeking when reading headerswm42014-01-221-128/+116
| | | | | | | | | This makes everything more robust, and also somewhat simpler (even if the diffstat isn't very impressive). Instead of recursively following SeekHeads while reading headers, just read the headers until the first cluster, and then possibly use SeekHeads to read the remaining missing headers.
* ebml: remove length parameters from read functionswm42014-01-141-15/+15
| | | | | | | Many ebml_read_* functions have a length int pointer parameter, which returns the number of bytes skipped. Nothing actually needed this (anymore), and code using it was rather hard to understand, so get rid of them.
* demux_mkv: remove unused macroswm42014-01-141-3/+0
|
* demux_mkv: improve robustness by explicitly checking for level 1 elementswm42014-01-141-6/+12
| | | | | | | | | | | | | | | | | | | | Matroska makes it pretty hard to resync correctly on broken files: random data returns "valid" EBML IDs with a high probability, and when trying to skip them it's likely that you skip a random amount of data (instead of considering the element length invalid). Improve upon this by skipping known level 1 elements only. Consider everything else invalid and call the resync code. This might result in annoying behavior when Matroska adds new level 1 elements, although it won't be particularly harmful. Matroska doesn't really allow us to do better (even mkvtoolnix explicitly checks for known level 1 elements). Since we now don't always want to combine EBML element skipping and resyncing, remove ebml_read_skip_or_resync_cluster(), and make ebml_read_skip() more tolerant against skipping broken elements. Also, don't resync when reading sub-elements, and instead do resyncing when reading them results in an error.
* demux_mkv: avoid skipping too much data in corrupted fileswm42014-01-141-7/+10
| | | | | | | | | | Until now, corrupted files were detected if the size of an element (that should be skipped) was larger than the remaining file. This still could skip larger regions of the file itself if the broken size happened to be within the file. Change it so that it's never allowed to skip outside the parent's element.
* demux_mkv: handle TrueHD properlywm42013-12-271-32/+98
| | | | | | | | | Apparently, Matroska packs TrueHD packets in a way lavc doesn't expect. This broke decoding of some files [1] completely. A short look at the libavcodec parser shows that parsing this ourselves would probably be too much work, so make use of the libavcodec parser API. [1] http://www.cccp-project.net/beta/test_files/mzero_truehd_sample.mkv
* demux: mp_msg conversionswm42013-12-211-160/+137
| | | | | | | The TV code pretends to be part of stream/, but it's actually demuxer code too. The audio_in code is shared between the TV code and stream_radio.c, so stream_radio.c needs a small hack until stream.c is converted.
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-2/+2
|
* Move options/config related files from mpvcore/ to options/wm42013-12-171-1/+1
| | | | | | | | | Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
* Replace mp_tmsg, mp_dbg -> mp_msg, remove mp_gtext(), remove set_osd_tmsgwm42013-12-161-14/+14
| | | | | | | | | The tmsg stuff was for the internal gettext() based translation system, which nobody ever attempted to use and thus was removed. mp_gtext() and set_osd_tmsg() were also for this. mp_dbg was once enabled in debug mode only, but since we have log level for enabling debug messages, it seems utterly useless.
* demux_mkv: don't seek outside of the file when finding segmentswm42013-12-141-1/+4
| | | | | | | | The end of the current segment will be the end of the file if there is no next segment. Normally, this didn't matter much, since UNIX files allow seeking past the end of the file. But when opening files from HTTP, this would print confusing error messages. So explicitly check for EOF before trying to read a segment.
* video: add insane hack to work around FFmpeg/Libav insanitywm42013-11-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So, FFmpeg/Libav requires us to figure out video timestamps ourselves (see last 10 commits or so), but the methods it provides for this aren't even sufficient. In particular, everything that uses AVI-style DTS (avi, vfw-muxed mkv, possibly mpeg4-in-ogm) with a codec that has an internal frame delay is broken. In this case, libavcodec will shift the packet- to-image correspondence by the codec delay, meaning that with a delay=1, the first AVFrame.pkt_dts is not 0, but that of the second packet. All timestamps will appear shifted. The start time (e.g. the time displayed when doing "mpv file.avi --pause") will not be exactly 0. (According to Libav developers, this is how it's supposed to work; just that the first DTS values are normally negative with formats that use DTS "properly". Who cares if it doesn't work at all with very common video formats? There's no indication that they'll fix this soon, either. An elegant workaround is missing too.) Add a hack to re-enable the old PTS code for AVI and vfw-muxed MKV. Since these timestamps are not reorderd, we wouldn't need to sort them, but it's less code this way (and possibly more robust, should a demuxer unexpectedly output PTS). The original intention of all the timestamp changes recently was actually to get rid of demuxer-specific hacks and the old timestamp sorting code, but it looks like this didn't work out. Yet another case where trying to replace native MPlayer functionality with FFmpeg/Libav led to disadvantages and bugs. (Note that the old PTS sorting code doesn't and can't handle frame dropping correctly, though.) Bug reports: https://trac.ffmpeg.org/ticket/3178 https://bugzilla.libav.org/show_bug.cgi?id=600
* demux_mkv: fix realvideo timestamp handlingwm42013-11-261-47/+40
| | | | | | | | | | | | | | | | | | | This was broken by the recent commits. Apparently realvideo timestamps are severely mangled, and Matroska _of course_ doesn't have the sane, umangled timestamps, but something unusable. The existing unmangling code in demux_mkv.c didn't output proper timestamps either. Instead, it was something weird that triggered sorting. Without sorting (it was disabled by default recently), you'd get decreasing PTS warnings In order to fix this, steal some code from libavcodec. Basically copy the contents of rv34_parser.c (with some changes), which makes everything magically work. (Maybe it would be better to use the libavcodec parser API, but I don't want to do that just for this. An alternative idea would be refusing to read files that have realvideo tracks, and delegate this to demux_lavf.c, but maybe that's too redical too.) I wish I hadn't notice this...
* video: disable PTS sorting fallback by defaultwm42013-11-251-0/+2
| | | | | | | | | | | | | | | | It appears PTS sorting was useful only for avi files (and VfW-muxed mkv). Maybe it was historically also important for decoders with broken or non-existent PTS reordering (win32 codecs?). But now that we handle demuxers which outputs DTS only correctly, it just seems dead weight. Disable it by default. The --pts-association-mode option is now forced to always use the decoder's PTS value. You can still enable the old default (auto) or force sorting. But we will probably remove this option entirely at some point. Make demux_mkv export timestamps at DTS when it's in VfW mode. This is needed to get correct timestamps with the new default mode. demux_lavf already does that.
* demux: remove gsh field from sh_audio/sh_video/sh_subwm42013-11-231-28/+28
| | | | | | | | | This used to be needed to access the generic stream header from the specific headers, which in turn was needed because the decoders had access only to the specific headers. This is not the case anymore, so this can finally be removed again. Also move the "format" field from the specific headers to sh_stream.
* demux: simplify handling of filepos fieldwm42013-11-161-5/+6
| | | | | | | | | | | | demuxer->filepos contains the byte offset of the last read packet. This is so that the player can estimate the current playback position, if no proper timestamps are available. Simplify it to use demux_packet->pos in the generic demuxer code, instead of bothering every demuxer implementation about it. (Note that this is still a bit incorrect: it relfects the position of the last packet read by the demuxer, not that returned to the user. But that was already broken, and is not that trivial to fix.)
* demux: use talloc for certain stream headerswm42013-11-141-18/+18
| | | | |