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

[Robert Krüger]

On Mon, Jul 30, 2012 at 11:43 AM, Peter B. <pb at das-werkstatt.com> wrote:
> Quoting Robert Krüger <krueger at lesspain.de>:
>
>
>> 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.
>
>
> Since it's lossless I could as well reencode.
> However, I agree with you and think that it would be good if remuxing was
> enough, because then this problem could also be solved in case of lossy
> codecs.
>
>
>> 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.
>
>
> Michael's message says it's possible to remux and change the fps. I don't
> know about the current code, but it seems doable already somehow.
>
> I'll go check.
>
>
> Thanks,
> Pb

I checked again with a test case. I made a small mjpeg/mov file named
test-2997.mov with 2997/100 FPS, ffprobe displays

r_frame_rate=2997/100
avg_frame_rate=2997/100

when I do:

ffmpeg -r 30000/1001 -i test-2997.mov -vcodec copy -acodec copy
test-30000-1001-r-input.mov

this, according to docs should ignore the timestamps and interprete it
as 30000/1001, which does not work. Resulting file is displayed in
ffprobe as having:

r_frame_rate=2997/100
avg_frame_rate=2997/100

when I do:

ffmpeg -i test-2997.mov -vcodec copy -acodec copy -r 30000/1001
test-30000-1001-r-output.mov

The resulting file does indeed have 2997/100 as michael said.

when I use this for a little more extreme conforming, e.g. slowing
down 2997/100 to 25 fps, i.e.:

ffmpeg -i test-2997.mov -vcodec copy -acodec copy -r 25 test-25-r-output.mov

I get:

[mov @ 0x101009e00] Application provided invalid, non monotonically
increasing dts to muxer in stream 0: 3 >= 3
av_interleaved_write_frame(): Invalid argument

It would be nice to know what kind of behaviour is expected, because
either the docs are wrong or there are some bugs:

-r

Set frame rate (Hz value, fraction or abbreviation).

As an input option, ignore any timestamps stored in the file and
instead generate timestamps assuming constant frame rate fps.
-> this does not work for remuxing at least not in my case. should I
file a bug report for that or submit a documentation patch stating
that this is not supported when only remuxing?

As an output option, duplicate or drop input frames to achieve
constant output frame rate fps
-> If this is correct, this is not really what someone wants when
conforming to a frame rate. in your case 2997/100 -> 30000/1001 this
is hardly noticable because the error is one frame every 9 1/2 hours
(if I calculated correctly), so practically nothing but conforming 24
-> 25 or similar stuff would yield visible problems.

So the conforming option, i.e. just reinterpreting timestamps is not
available in ffmpeg currently when remuxing AFAICS. That was what I
hacked with my packet-level timestamp manipulation code but that is
IMHO from a user's point of view really what -r should do as an input
option if the docs are supposed to stay that way.

Regards,

Robert