[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

wm4 nfxjfg at googlemail.com
Wed Jul 29 23:02:24 CEST 2015

On Wed, 29 Jul 2015 22:41:49 +0200
Hendrik Leppkes <h.leppkes at gmail.com> wrote:

> On Wed, Jul 29, 2015 at 8:15 PM, Sasi Inguva <isasi at google.com> wrote:
> > @Reimar:
> > True about the stream duration being wrong if stream timestamp does not
> > start at 0 . I just duplicated the logic to compute the total duration. In
> > which case, the total duration as it is computed now, is also wrong.
> > Printing the durations out in the logs, and then parsing the logs to get
> > the stream durations would require a big architectural change on my side.
> > It would be far more convenient if I could get the stream durations from
> > AVStream object.
> >
> > FFmpeg does write one seek entry for every cluster in the end of the file.
> > I could possibly seek to  all the cluster seek entries, then try to find
> > the last cluster for each track. But in the worst case, even this would
> >  translate to demuxing of whole file because, suppose the audio is small
> > enough to totally fit in one cluster , but the start of the cluster is a
> > video packet to make sure that I have got the end of the audio stream I
> > have to parse the whole cluster. Also it seems very complicated logic to
> > determine the durations.
> >
> >
> Still writing metadata to every single mkv muxed with ffmpeg to fix
> your specific use-case seems rather terrible.
> We shouldn't be writing extra metadata to serve one special use-case,
> just so you can avoid a bit of code shuffling on your end.
> If you can clarify how this could be useful genericall, we might
> consider it differently.

I was assuming this patch just writes a subset of the tags modern
mkvmerge versions write. While mkvmerge also writes "DURATION" tags for
each track, it actually uses a formatted string (like
"00:24:24.200000000"), not a binary element.

So it's not clear whether this is sane.

More information about the ffmpeg-devel mailing list