On Wed, 29 Jul 2015 05:12:05 +0200 Reimar Döffinger <reimar.doeffin...@gmx.de> wrote:
> On 29.07.2015, at 05:00, Reimar Döffinger <reimar.doeffin...@gmx.de> wrote: > > On 29.07.2015, at 03:10, Sasi Inguva <is...@google.com> wrote: > >> A little context on why I need this. I use individual stream durations to > >> validate , if the outputs after transcoding have the same stream durations. > >> For this we need to know the stream durations through a quick parse of the > >> header of the file, since demuxing the whole file is too slow. We can have > >> some video files, for example slide show videos etc. , where audio might be > >> of short duration and video very long, so it is not always the case that > >> video and audio of our input will be of the same duration. > > > > If validating a transcode is all it is used for, printing the information > > at the end of the transcode or even making the validation part of FFmpeg > > seems potentially easier/cleaner/more generic. > > Btw please change the commit message to standard format (one line very > > short description, starting with the affected module name followed by > > colon, then empty line, then long description). > > And I forgot: reading the stream durations from a mkv file should not require > demuxing the whole file at all. > Worst case it requires binary search through the seek entries for the last > one still containing the stream and then linear demuxing from there to the > end. If you know the expected durations the binary search path probably > shouldn't even be necessary. > I am also unsure the duration values you calculate in the muxer are correct, > it looks to me like you store the end timestamp. However that is not the > duration if the stream does not start at timestamp 0... One potential use case is retrieving the video duration. The total duration is sometimes very off: there are files with broken subtitle events with very high durations, or with start times past video end. The Matroska file duration includes subtitle track durations, and the subtitle track duration includes the _end_ of the last subtitle event. The seek index doesn't necessarily help in these cases either. It doesn't give you the end of the video, at best it gives you a rough close estimate. Plus you'd have to give up reading cues lazily. I don't know how common such broken files are, but I got relatively often complaints about these cases. The Haali demuxer, which is essentially the standard mkv demuxer on Windows, has explicit hacks to retrieve the video duration by trying to find the last video packet or so. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
