Opened 10 months ago

Last modified 4 months ago

#8063 reopened defect

`-vsync cfr` tends to duplicate the wrong frames

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

Description

With a VFR input, -vsync cfr may alter the playback experience by duplicating the wrong frames. (appeared to be... exactly 1 frame later)


Simple illustration of the problem:
(each number represents a frame of unique content)

-vsync vfr (expressed in CFR manner):

1 1 2 2 3

-vsync cfr:

1 2 2 3 3


Note:
The above happened in MP4, MKV container, failed to reproduce (seemed working correctly) in AVI container. (tested x264, and appeared to be codec dependent... as with magicyuv it happens in AVI also, and more severe: broken frames (part of the duplicated frames have incorrect color))

Attachments (1)

123.avi (24.1 KB) - added by gdgsdg123 6 months ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 10 months ago by cehoyos

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

Changed 6 months ago by gdgsdg123

comment:2 Changed 6 months ago by gdgsdg123

Replying to gdgsdg123:

...failed to reproduce (seemed working correctly) in AVI container.

Managed to reproduce it in AVI container:

ffmpeg -i "123.avi" -vsync cfr "cfr.avi"



Frame information of 123.avi:

Frame Number Presentation Timestamp Duration Content
1 0 2 1
2 2 2 2
3 4 N/A 3


Expected frame information of cfr.avi:

Frame Number Presentation Timestamp Duration Content
1 0 1 1
2 1 1 2
3 2 1 2
4 3 1 3
5 4 N/A 3

comment:3 follow-up: Changed 6 months ago by Gyan

vsync takes effect before encoding and muxing so choice of encoder and muxer is irrelevant - one caveat being that if vsync is not specified by the user ffmpeg will set it as per muxer flags.

comment:4 in reply to: ↑ 3 Changed 5 months ago by gdgsdg123

  • Resolution needs_more_info deleted
  • Status changed from closed to reopened

Replying to Gyan:

one caveat being that if vsync is not specified by the user ffmpeg will set it as per muxer flags.

In another word: always explicitly set the preferred vsync method, unless you want FFmpeg to choose one randomly for you...

comment:5 Changed 5 months ago by Gyan

It's not random. It's chosen as per muxer flags which are fixed in code and rarely changed.

comment:6 Changed 5 months ago by gdgsdg123

But random enough for unconscious users to be considered random...

comment:7 follow-up: Changed 4 months ago by cehoyos

  • Component changed from undetermined to ffmpeg
  • Keywords fps added

While the description is highly misleading, I believe that a (minor) issue can be reproduced with the sample file.

comment:8 in reply to: ↑ 7 ; follow-up: Changed 4 months ago by gdgsdg123

Replying to cehoyos:

...the description is highly misleading.

How?..


Replying to cehoyos:

...a (minor) issue can be reproduced with the sample file.

The issue is first observed in (and experimented with) production clips.

I specifically made the "123.avi" to demonstrate things better.

Last edited 4 months ago by gdgsdg123 (previous) (diff)

comment:9 in reply to: ↑ 8 ; follow-up: Changed 4 months ago by cehoyos

Replying to gdgsdg123:

Replying to cehoyos:

...a (minor) issue can be reproduced with the sample file.

The issue is first observed in (and experimented with) production clips.

Feel free to provide such clips.

comment:10 in reply to: ↑ 9 Changed 4 months ago by gdgsdg123

Replying to cehoyos:

Feel free to provide such clips.

I have already... If you had the interest to download:
https://www.youtube.com/playlist?list=PLXvoB-d-4W1kKvr3CA20DrcU1HzTXibAX (check the descriptions)

Note: See TracTickets for help on using tickets.