Opened 10 years ago

Closed 23 months ago

Last modified 11 months ago

#3035 closed defect (fixed)

h264 decoder duplicates 8-th frame

Reported by: eugene smirnov Owned by:
Priority: normal Component: avcodec
Version: git-master Keywords: h264
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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

Attachments (2)

log.txt (4.2 KB ) - added by eugene smirnov 10 years ago.
log
0004.h264 (319.8 KB ) - added by eugene smirnov 10 years ago.
avc input

Download all attachments as: .zip

Change History (8)

by eugene smirnov, 10 years ago

Attachment: log.txt added

log

by eugene smirnov, 10 years ago

Attachment: 0004.h264 added

avc input

comment:1 by Carl Eugen Hoyos, 10 years ago

Keywords: h264 added

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

comment:2 by eugene smirnov, 10 years ago

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

in reply to:  2 comment:3 by Balling, 2 years ago

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.

comment:4 by Balling, 2 years ago

Status: newopen

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.

Last edited 2 years ago by Balling (previous) (diff)

comment:5 by Balling, 23 months ago

Resolution: fixed
Status: openclosed

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.

Last edited 11 months ago by Balling (previous) (diff)

comment:6 by Carl Eugen Hoyos, 19 months ago

Version: unspecifiedgit-master

Fixed by Nicolas Gaullier in fad459b5a6461bf2ce2c232d5e251dd486bbdc0d

Note: See TracTickets for help on using tickets.