Opened 5 years ago

Closed 5 years 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 5 years ago.

Download all attachments as: .zip

Change History (7)

by LordHDL, 5 years ago

Attachment: Frame Dupes added

comment:1 by Nicolas George, 5 years ago

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 by LordHDL, 5 years ago

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 by Nicolas George, 5 years ago

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

comment:4 by LordHDL, 5 years ago

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 by Nicolas George, 5 years ago

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 by Carl Eugen Hoyos, 5 years ago

Resolution: invalid
Status: newclosed

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.