summaryrefslogtreecommitdiffstats
path: root/sub/sd_ass.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2013-07-16 22:59:55 +0200
committerwm4 <wm4@nowhere>2013-07-16 22:59:55 +0200
commit77a00e444f06675b4cfc1d75852aee76f7cbefad (patch)
tree1fda271e8a6e87750fed4b8b1df5fddc8562266b /sub/sd_ass.c
parent66a9eb570d8ab086ecd29c244dc99c5c6b85cd03 (diff)
downloadmpv-77a00e444f06675b4cfc1d75852aee76f7cbefad.tar.bz2
mpv-77a00e444f06675b4cfc1d75852aee76f7cbefad.tar.xz
demux_mkv: ignore DefaultDuration in some cases
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.)
Diffstat (limited to 'sub/sd_ass.c')
0 files changed, 0 insertions, 0 deletions