[FFmpeg-user] Why Does ffprobe Report an Incorrect Number of Frames?

John G skeeve99 at yahoo.com.au
Thu May 8 14:45:53 CEST 2014



> From: Tom Evans <tevans.uk at googlemail.com>

[...]
> ffprobe is a probe command, and so it inspects a small amount of the

> file and guesses how many frames there are. 

Well, that explains THAT, then...

> If you want to know
> precisely how many frames there are in a VFR file, use
>
>   ffprobe -select_streams v -count_frames -show_entries
> stream=nb_read_frames input.ext
>
> to determine the number of frames.

...in the case of this 'sample.avi', this value is 1619 - the old familiar 'incorrect' value.

> This command:

>
>   ffmpeg -i sample.avi -c:v mpeg4 -q:v 2.0    new.mpg
>
> is converting your VFR video to CFR. If you do as Carl suggested, and
> insert the option "-vsync 0" (and probably "-an", to disable audio),
> then ffmpeg will still create a CFR video (MPEG2 is always CFR), but
> with exactly one output frame for every input frame.
>
> You will then see that there are not 6999 frames in the source.

Again, it returns the 1619 value.

What makes this all the more confusing is that some derivatives of mplayer (SMPlayer, KMPlayer) report the 6999 frame count figure (and is why I'm having these troubles in the first place).

Without really knowing the best way to keep track of where certain events happen in the videos I'm working with, I have loaded a video into KMPlayer and have done a screen capture at a particular point.  The capture image has a name which includes the frame number... and it's THAT number I'm trying to 'dereference' to a time position in the video in order to automatically regenerate the screen capture files (with different attributes, like a mirrored image, different saturation, etc).

With 20-20 hindsight(!), it might have been better to bookmark the positions in the video and then I could seek to the bookmarked time in the file, which seems to be a more reliable way of getting to a particular frame (*maybe*) -- using the ffmpeg -ss parameter on both input (coarse seeking) and output (fine seeking).


-John


More information about the ffmpeg-user mailing list