MKV : No or bad duration displayed
3 samples no duration (0:00) : http://streams.videolan.org/issues/12724/Test_mkv_h264_mp4a_1024x576_2500Kbps_29,97fps.mkv http://streams.videolan.org/issues/12724/Test_mkv_h264_mp4a_1280x720_4000Kbps_29,97fps.mkv http://streams.videolan.org/issues/12724/Test_mkv_h264_mp4a_1920x1080_1500Kbps_29,97fps.mkv
1 sample bad duration (259:40:52) http://streams.videolan.org/issues/12724/Test_mkv_mpgv_DTS_1920x1080_800Kbps_23,97fps.mkv
Activity
assigned to @typx
added Component::Demuxers: MKV label
changed milestone to %Bugs paradize
With local files it's possible to seek to the last Cluster and look for the last timecode. I think in the past we used to do that. I have to look at the code if it's still handled.
When streaming over protocols like HTTP it would be too "expensive" to seek in the same URL just to get that info. But we may already do it to read the
Cueswhich should be located just after the last Cluster.changed milestone to %3.0.0
commit 16b3d6a4 Author: Steve Lhomme robux4@gmail.com Date: Mon Feb 23 11:02:26 2015 +0100
MKV: find the duration in the last Cluster when it's not in the Info header Only on fast seeking sources Close [#12724](https://code.videolan.org/videolan/vlc/-/issues/12724) Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>Original author: robux4@gmail.com
added Status::fixed label
This fix is for the first 3 samples.
The last sample (bad duration) is just reporting what is written in the file. This is not the actual duration of that segment (1 minute). It is tricky to determine if the value written by the muxer is incorrect. For the other files it was just missing.
It starts at a huge timecode and doesn't end far from that. But it's totally possible to have a file that starts at a huge timecode (an MPEG DASH chunk for example). It's also possible that a file lasts for 10 days with a small size, with a frame every hour for example.
So I'm not sure there's a proper solution for this file.
changed milestone to %3.0 FF
