Opened 3 weeks ago

Closed 3 weeks ago

#6298 closed defect (invalid)

Using image2 duplicates frames even with -r as input option

Reported by: LordHDL Owned by:
Priority: normal Component: ffmpeg
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


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.


ffmpeg -r 59.77 -i /Users/HDL/Desktop/ -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/ -f nut /dev/null

...does not dupe anything.

Full console output is in the attachment.

Attachments (1)

Frame Dupes (18.5 KB) - added by LordHDL 3 weeks ago.

Download all attachments as: .zip

Change History (7)

Changed 3 weeks ago by LordHDL

comment:1 Changed 3 weeks ago by 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?

comment:2 Changed 3 weeks ago by 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.

comment:3 Changed 3 weeks ago by Cigaes

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

comment:4 Changed 3 weeks ago by 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.

comment:5 Changed 3 weeks ago by 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.

comment:6 Changed 3 weeks ago by cehoyos

  • Resolution set to invalid
  • Status changed from new to closed

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).

Note: See TracTickets for help on using tickets.