[FFmpeg-user] ffprobe -show_frames and coded_picture_number

Richard H Lee ricardohenrylee at gmail.com
Mon Aug 12 00:04:12 CEST 2013

On 11/08/2013 17:53, Phil Rhodes wrote:
> The other, better alternative would be to resample the audio and time
> the whole playback system to the graphics card's refresh rate

This is actually what I do. Most of the media I acquire is at NTSC
24000/1001 fps, but I play it on a PAL 25 fps monitor. The only way to
get smooth motion is to speed up the frame rate.

If I need to re-encode I pipe the raw video frames through yuvfps to set 
the frame rate or I set the PTS manually with ffmpeg. If I just need to 
change the frame rate without re-encoding, I have use MP4Box, as ffmpeg 
can't use "-vcodec copy" and setpts together. (If anybody knows how to 
do this, let me know.)

> but nobody seems to do that, presumably because resampling audio is
> hard.

And the reason why resampling is hard is because there are no tools out 
there that can resample audio accurately.

I tried every tool, ffmpeg, mencoder, sox, but they all ended up with 
large a/v desync after 10 mins. I think this is due to the rounding off 
of the decimal number I give to the various utilities. The only tool 
that worked was AVISynth, but that is a Windows tool.

(warning, shameless plug)
So I decided to create one myself.

First of all, you dump the audio into a wav file, either using mplayer 
or ffmpeg. Then you work out the factor by which you need to speed up 
the audio as a fraction. E.g. when converting from NTSC (24000/1001 fps) 
to PAL (25 fps), the ratio would be 25/(24000/1001) = 1001/960 . So the 
utility would be called as so:
speed 1001/960 input.wav output.wav

If the frame rate is not exact, which occurs with many media, you can 
work out the average frame rate using ffprobe -show_frames and specify 
the factor as a decimal
speed -f 1.02842655493067542736 1/1 in.wav out.wav

Finally, one can pitch shift the audio down using sox, as by speeding up 
the audio, you also raise the pitch.

I have been using this method for the past year or so on 100's of videos 
and it has worked perfectly every time. The only time it failed was when 
the source file was out of sync.

It would be nice if ffmpeg could have this level of accuracy when 
resampling audio, but I guess that would be a feature request.

[Please bear in mind 'speed' (I never got round to naming it properly) 
is the first proper C project I did, so it going to be pretty rough 
round the edges. It handles 2-channel, 8 or 16 bits per sample, PCM or 
float encoding which should cover 99% of audio out there. There is no 
documentation or licensing. The codebase itself is pretty messy. Also it 
could be a lot more efficient and possibly multi-threaded.]

More information about the ffmpeg-user mailing list