[FFmpeg-user] Forcing ffmpeg to detect duration reliably

Tracey Jaquith tracey at archive.org
Fri Mar 1 23:31:03 CET 2013


On Mar 1, 2013, at 7:56 AM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:

> tracey jaquith <tracey <at> archive.org> writes:
> 
>> I use this for our archives when I get an estimated duration 
>> that seems wrong.  Much faster than the "ffmpeg -i
>> input -f null -", though I'm sure there may be some pros/cons.
>> 
>> It uses "ffprobe" to "count video packets" and their durations, 
>> finally printing a total #seconds.
>> 
>> ffprobe -select_streams v  -show_packets -print_format compact 
>> *mpg  2>/dev/null | egrep -o
>> 'duration_time=[^ ]+'|cut -f2 -d= | perl -ne 'chop; $n+=$_; 
>> print (int($n*10)/10)."\n" if (eof());'
>> 1800
> 
> Does this also work if the stream contains timestamp 
> discontinuities?

Good point!  I'm not entirely sure, but in practice it's proven to be an *excellent* backup/alternate for when estimated duration is clearly wrong (for whatever/various reasons).  I use a sanity double check for if we get a bitrate that is way too low for video, or way to high (something exceeding the theoretical blu-ray disc transfer limit, say), when computing the "ffmpeg -i" parsed duration compared to #bytes of the entire video.

So I guess, getting back to your question with respect to discontinuities,  my technique could be off by a bit -- if there were certain discontinuities like, what, say, multiple packets with the same timestamp?  packets out of order shouldn't matter, since it's a straight-up addition of each packet's duration.   If someone were trimming "extra" video packets on ends to the shorter audio track (when they differ), then you'd get a slightly unexpected duration printed, too.  Trying to think of other scenarios…  do you have any others that come to mind?  Anything/file you'd like me to try against?

Thanks, tireless Carl!  8-)
-tracey







More information about the ffmpeg-user mailing list