[FFmpeg-devel] [PATCH] Compute individual stream durations in matroska muxer. Write them as binary tags. Parse the binary tags in matroska demuxer, and write them to AVStream
nfxjfg at googlemail.com
Thu Jul 30 00:27:24 CEST 2015
On Wed, 29 Jul 2015 05:12:05 +0200
Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> On 29.07.2015, at 05:00, Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> > On 29.07.2015, at 03:10, Sasi Inguva <isasi at google.com> wrote:
> >> A little context on why I need this. I use individual stream durations to
> >> validate , if the outputs after transcoding have the same stream durations.
> >> For this we need to know the stream durations through a quick parse of the
> >> header of the file, since demuxing the whole file is too slow. We can have
> >> some video files, for example slide show videos etc. , where audio might be
> >> of short duration and video very long, so it is not always the case that
> >> video and audio of our input will be of the same duration.
> > If validating a transcode is all it is used for, printing the information at the end of the transcode or even making the validation part of FFmpeg seems potentially easier/cleaner/more generic.
> > Btw please change the commit message to standard format (one line very short description, starting with the affected module name followed by colon, then empty line, then long description).
> And I forgot: reading the stream durations from a mkv file should not require demuxing the whole file at all.
> Worst case it requires binary search through the seek entries for the last one still containing the stream and then linear demuxing from there to the end. If you know the expected durations the binary search path probably shouldn't even be necessary.
> I am also unsure the duration values you calculate in the muxer are correct, it looks to me like you store the end timestamp. However that is not the duration if the stream does not start at timestamp 0...
One potential use case is retrieving the video duration. The total
duration is sometimes very off: there are files with broken subtitle
events with very high durations, or with start times past video end.
The Matroska file duration includes subtitle track durations, and the
subtitle track duration includes the _end_ of the last subtitle event.
The seek index doesn't necessarily help in these cases either. It
doesn't give you the end of the video, at best it gives you a rough
close estimate. Plus you'd have to give up reading cues lazily.
I don't know how common such broken files are, but I got relatively
often complaints about these cases. The Haali demuxer, which is
essentially the standard mkv demuxer on Windows, has explicit hacks to
retrieve the video duration by trying to find the last video packet or
More information about the ffmpeg-devel