[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