On Wed, 29 Jul 2015 22:41:49 +0200 Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> On Wed, Jul 29, 2015 at 8:15 PM, Sasi Inguva <is...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
