Ok. Didn't know of mkvmerge till now. I have no inclination towards binary/string tags. I can write them as string tags with mkvmerge formatting. I just thought parsing binary data directly is better than parsing a string. But I guess using string tag will be more useful when parsing mkv from other tools.
If the universality of this change is a problem, then I can hide it behind a flag, disabled by default. On Wed, Jul 29, 2015 at 2:18 PM, Hendrik Leppkes <h.lepp...@gmail.com> wrote: > On Wed, Jul 29, 2015 at 11:14 PM, Jerome Martinez <jer...@mediaarea.net> > wrote: > > Le 29/07/2015 22:41, Hendrik Leppkes a écrit : > >> > >> 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. > > > > > > > > Lot of people wish to have duration per stream in order to check that the > > transcoding did not change the duration of each stream (each stream may > have > > different duration) or to get some more precise information about the > file > > they receive (for example, some people want to reject files which do not > > have the same video and audio duration). > > > > I, as the developer of a tool which read such kind of metadata, am often > > asked to provide such information per stream for Matroska/WebM files, > from > > different users, unfortunately I can not provide specific use case, I can > > only say it is a common request. > > > > But such request is usually binded with more metadata: data rate, count > of > > bytes and count of frames. FLV (OP talked about FLV) metadata usually > > permits to get bit rate per stream (which is the most requested metadata > on > > my side, which is not possible to get without additional metadata in > > Matroska when there is e.g. AVC and DTS-HD, 2 streams with variable > > bitrate). > > Additionally, mkvmerge already add such metadata since a couple of > versions, > > I guess it is also due to a request from different users. > > > > That said, I don't like, as the developer of a tool which will read such > > added metadata, to have different methods for embedding such metadata. > > Why not using the same method and values (BPS, DURATION, > NUMBER_OF_FRAMES, > > NUMBER_OF_BYTES, _STATISTICS_WRITING_APP, _STATISTICS_WRITING_DATE_UTC > tags, > > non binary) as mkvmerge in order to have something which could be useful > > more generically? > > > > I agree, if anything it should write values compatible to mkvmerge, if > mkvmerge already writes similar things. > > - Hendrik > _______________________________________________ > 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
