h264 decoder duplicates 8-th frame

[eugene smirnov]

Summary of the bug:
How to reproduce:

% ffmpeg -i 0004.h264 1.yuv
ffmpeg version N-56930-gee3d03b
built on windows

In decodmpressed YUV stream, frame 8 looks duplicate of frame 7 while reference tools like ldecod, and tektronix do not duplicate it. Also i've checked ffmpeg from very old 0.6 branch and it also didnt duplicate that frame

[eugene smirnov]

log

[eugene smirnov]

avc input

[Carl Eugen Hoyos]

If you want to avoid the duplication use -vsync 0
The h264 timestamp issue is known, there are several other tickets covering this problem.

[eugene smirnov]

Thanks, -vsync 0 seems resolved that issue, only note that anexb stream doesnt contain any timestamps, except is frame rate code in SPS header

[Balling]

Replying to eugene smirnov:

Thanks, -vsync 0 seems resolved that issue, only note that anexb stream doesnt contain any timestamps, except is frame rate code in SPS header

This is false. Annex B has timing SEI now.

[Balling]

It prints a lot of

[h264 @ 000001ee9e5ec9c0] no picture

and a lot of

cur_dts is invalid st:0 (0) [init:1 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)

-vsync passthrough not longer appears to change the hash of yuv file. So...

Please verify.

Frames 6, 7, 8, 9, 10 all look different.

[Balling]

Comparing with JM 19.0

ldecod.exe -p InputFile=0004.h264 -p OutputFile=oldtown_ref.yuv

​https://github.com/sjilss/h264_qdct_ptc/commit/d10376624227d7c55327ca2bca59ccff8bb43995

we can say the decoder is bitperfect (md5 of the 1.yuv is C90157A2A0D2C073F190CA9DDF4506D4). It was fixed somewhere between 4a11a6f4ccc7c56ccc82adf0c3ab4054d4c22d1e and HEAD of master. Who cares where...

md5 of broken decode with old ffmpeg was A0A2580FD0EA30B6827690CA366ACF70.

md5 of old ffmpeg with -vsync 0 was also C90157A2A0D2C073F190CA9DDF4506D4.

-vsync passthrough (vsync 0 was deprecated) now prints also C90157A2A0D2C073F190CA9DDF4506D4.

It was decoding two more frames than correctly now 1644 vs 1642.

I will also point out that -vsync 0 makes the same vfrdet result as now for any vsync.

[Carl Eugen Hoyos]

Fixed by Nicolas Gaullier in fad459b5a6461bf2ce2c232d5e251dd486bbdc0d