[FFmpeg-user] How can I remux a video from 2997/100 to 30000/1001 fps?

[Robert Krüger]

On Thu, Jul 26, 2012 at 12:59 PM, Peter B. <pb at das-werkstatt.com> wrote:
> I just ran into a really weird issue with "born digital" video material:
>
> I've tried to transcode a FFv1/PCM lossless file (720x576 @29.970fps) to a
> DVD conform MPEG, but mencoder threw the following error message:
>
> "MPEG1/2 does not support 2997/100 fps"
>
> If I tell mencoder to use "-ofps 30000/1001" everything works fine.
>
>
> Now, my question is:
> Can I use ffmpeg to "clean" my original file to have the fps stored
> "correctly"?
>
> I've tried this:
> "$ ffmpeg -i input.avi -r 30000/1001 -acodec copy -vcodec copy output.avi"
>
> but the resulting file still had the "wrong" fps (2997/100).
>
>
> Thank you very much in advance,
> Pb
>

If you wouldn't just remux but reencode (which you don't want, I know)
you could use the setpts filter to do the job but AKAIK filters do not
work for remuxing by design and I do not know of a similar mechanism
for remuxing (something like a packet filter). The current docs could
also be interpreted in such a way that the "-r" option _before_ the
input should do the job but it doesn't.

>From docs: "As an input option, ignore any timestamps stored in the
file and instead generate timestamps assuming constant frame rate
fps."

but a quick glimpse at the code doesn't look as if it is used in the
remuxing case. In fact, I have a simple example with a mov file I
generated with 2997/100 for which it does not work even if I recode
the video stream, which is kind of strange. I had once hacked a
command line option that manipulated the video package timestamps by a
factor before handing them over to the decoder (I think) and that did
work for that use case. however, I doubt that was a clean solution and
would be accepted as a patch. The clean solution should probably be to
make the "-r" option before the input work as documented for the
remuxing case. However, I don't know if there are any hidden traps in
that for certain formats (e.g. problems due to inconsistencies between
timestamps in the bitstream and the container). Maybe someone could
comment, if that should be postet as a bug report. Then I will do
that.