Opened 6 months ago

Closed 6 months 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

Description

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.

Attachments (1)

Frame Dupes (18.5 KB) - added by LordHDL 6 months ago.

Download all attachments as: .zip

Change History (7)

Changed 6 months ago by LordHDL

comment:1 Changed 6 months 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 6 months 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 6 months ago by Cigaes

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

comment:4 Changed 6 months 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 6 months 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 6 months 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.