Using image2 duplicates frames even with -r as input option

[LordHDL]

Summary of the bug: Using image2 duplicates frames even with -r as input option
How to reproduce: Use -f image2 to dump a video's frames as images into a folder.

Example

ffmpeg -r 59.77 -i /Users/HDL/Desktop/TradeWin.mov -f image2 ~/Desktop/frames/TradeWinMov/image-%03d.tiff

This will result in 2 duplicate frames. Meanwhile this...

ffmpeg -r 59.77 -i /Users/HDL/Desktop/TradeWin.mov -f nut /dev/null

...does not dupe anything.

Full console output is in the attachment.

[Cigaes]

Since image2 output does not have timestamps, it is forced to CFR by default. Did you try -vsync 0?

Also, -r 59.77 is very suspicious, almost certainly wrong. Where does it come from?

[LordHDL]

The 59.77 comes from recording video on frame arrival as opposed to specifying a fixed rate. I tend to record things on my desktop and using a fixed rate will result in frames simply not being captured. The fluctuations will produce videos with odd rates like that, but every frame is present and accounted for.

Using -vsync 0 did actually prevent frame dupes, although if I don't also use the -r input option I get this message:

[image2 @ 0x7f85ad810000] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 46 >= 46

I'm not sure what that means. Leaving the -r option prevents that message, and both ways seem to prevent dupes.

[Cigaes]

Then indeed, the -r is bogus. You are taking an average and turning it into a constant.

[LordHDL]

So is it not recommended to use -vsync 0 with any rate or FPS options? When I tried using -vf fps=60 I got a different result. Specifically a 60 second clip dumped 3601 frames, and omitting vf fps=60 produced 3612 frames. The former did not report any drops or dupes, but inspecting the frames confirms there were some. The latter didn't appear to drop or dupe anything, but the frame count seems off. 3612/60 (clip duration) = 60.2 (FPS), while 3601/60 = 60.0166666. The frames were obviously wrong with 3601 and yet it was closer to the actual estimated FPS of 60.

This holds true for both image2 and video encoding.

[Cigaes]

First, you need to precisely define what you want to do. Then, and only then, can you start looking how to do it.

And here is not the place, since it is a bug tracker, not a help forum.

[Carl Eugen Hoyos]

I don't know what you are trying to achieve but I believe in this case the input option -r works as expected (it doesn't work for other use-cases).