@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. @wm4: 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 http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/matroskaenc.c;h=2d0d5f6bb1b4ae4f737419cb11379ccb13ad18f0;hb=refs/heads/master#l1445 On Wed, Jul 29, 2015 at 1:31 AM, wm4 <nfx...@googlemail.com> wrote: > On Tue, 28 Jul 2015 12:39:59 -0700 > Sasi Inguva <is...@google.com> wrote: > > > Signed-off-by: Sasi Inguva <is...@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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
