`-vsync cfr` tends to duplicate the wrong frames

[gdgsdg123]

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

[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

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

[gdgsdg123]

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

[Gyan]

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

[gdgsdg123]

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

[Carl Eugen Hoyos]

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

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

[Carl Eugen Hoyos]

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.

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