Interesting. Any idea if that's a new option (I've never noticed it before)? My only concern would be that it would break on some other version of ffmpeg.

Good point, I've actually first observed the error with FFMPEG v2.6, then updated to v2.8.1, where I've validated the proposed solution.

I could double check on other versions, what is the lowest supported, or which versions should I cover?

On my CentOS6 machine, I see that the -r option is available and is documented to force a frame rate. Here is the version info:

$ ffmpeg -version
FFmpeg version 0.6.5, Copyright (c) 2000-2010 the FFmpeg developers
  built on Jan 29 2012 17:52:15 with gcc 4.4.5 20110214 (Red Hat 4.4.5-6)

And with FFmpeg version 0.5.2, Copyright (c) 2000-2009 Fabrice Bellard, et al
of RHEL 5

ffmpeg -h
-r rate             set frame rate (Hz value, fraction or abbreviation)

Was wanting to double check when -r became an option for input. However, it looks like this feature has been in for almost 10 years: https://ffmpeg.org/pipermail/ffmpeg-devel/2005-August/000524.html

So, minus the pep8 issue, I'm 👍 on the change.

As an aside, I really wish there were a better way to do this than to constantly tinker with the ffmpeg command line incantation.

It's also in the RHEL 5 man page (ffmpeg 0.5.2)

Is a similar fix needed for the pipe based writer?

Looking at the pipe-based writer, I think it's already covered; the rate is set before the -i pipe:. (I'm not sure how the output rate was working in that case--maybe it just defaulted to the input rate?)

@dopplershift See #4416 😉

@auneri Thanks!

@tacaswell, @dopplershift, here is another one that has cost me hours of frustration. It is fixing a big bug, so I would like to backport it. In fact, from my reading of the avconv and ffmpeg docs (it applies to both), the second '-r' option is at best superfluous; the critical thing is to have the '-r' option specified before the '-i' option. Any '-r' option after the '-i' serves to drop or duplicate frames in an attempt to match the rate of the input.

👍 on backporting.

Backported to v2.x as c0c65e3.

I am failing to see this change (or any change that addresses this issue) in master or 2.x, am I missing something?

Good catch. This is very puzzling. Some changes--not just this one--seem to have gone missing. I suspect something went wrong in all the backwards and forwards between v2.x and master. Or maybe I simply fouled it up myself. I will try to track it down.

I'm the culprit. Somehow, not long after merging this, I got mixed up and removed the wrong '-r'--and even left a comment in its place. I will fix it now.

OK, it should be fixed in v2.x and master now. Thanks for catching that, @auneri.