[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]

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.