[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

Sasi Inguva isasi at google.com
Wed Jul 29 20:15:37 CEST 2015

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.

Yes. It writes tags by default. But tags are written in the header at the
start of the file, as far as I can see

On Wed, Jul 29, 2015 at 1:31 AM, wm4 <nfxjfg at googlemail.com> wrote:

> On Tue, 28 Jul 2015 12:39:59 -0700
> Sasi Inguva <isasi at google.com> wrote:
> > Signed-off-by: Sasi Inguva <isasi at google.com>
> > ---
> >  libavformat/matroska.h       |  1 +
> >  libavformat/matroskadec.c    | 21 +++++++++++++-
> >  libavformat/matroskaenc.c    | 66
> ++++++++++++++++++++++++++++++++++++++------
> >  tests/fate/wavpack.mak       |  4 +--
> >  tests/ref/acodec/tta         |  4 +--
> >  tests/ref/fate/binsub-mksenc |  2 +-
> >  tests/ref/lavf/mkv           |  8 +++---
> >  tests/ref/seek/lavf-mkv      | 44 ++++++++++++++---------------
> >  8 files changed, 109 insertions(+), 41 deletions(-)
> >
> Am I right with these assumptions:
> - this will write tags by default, while it didn't before this patch
> - the tags are written to the end of the stream (and not close to the
>   start of it)
> If so, this will require a seek to the end of the file when loading
> it, while this could be avoided before. It breaks fast loading of
> network streams. I'm not really fond of this.
> (I know, mkvmerge commits similar sins.)
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

More information about the ffmpeg-devel mailing list