Opened 6 years ago

Last modified 3 weeks ago

#7374 open defect

H.264 decoder is left in broken state after a glitch and switch in input

Reported by: jeeb Owned by:
Priority: normal Component: avcodec
Version: unspecified Keywords: h264
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


Summary of the bug:
After what seems to be a glitch/switch in the input stream (trace_headers notes that there's 12 H.264 packets for which the BSF couldn't be applied to), the H.264 decoder still keeps decoding, but ultimately is left in a state where it seems to drop references even though it wouldn't have to. Additionally, it seems like the stream switches from MBAFF to PAFF after the glitch, although I'm not 100% sure if I'm parsing things correctly to note that.

A cut 10MiB sample is available @

How to reproduce:
You can decode or play the sample with pretty much anything lavc-using. It will be OK at first for a moment, and then have a glitch. Then after that glitch there's seemingly OK content (if you initialize decoding after the glitch, the decoding is OK), but the result is borked for the rest of the clip.

% ffmpeg -v debug -i 2018-08-17-h264_decoder_borks.cut.ts -map 0:v:0 -f null -t 10 -
... decodes fine for a while ...
timestamp discontinuity
[h264 @ 0x3aacbc0] reference count overflow
[h264 @ 0x3aacbc0] decode_slice_header error
[h264 @ 0x3aacbc0] no frame!
[h264 @ 0x3a47080] Reference 2 >= 2
[h264 @ 0x3a47080] error while decoding MB 1 0, bytestream 18674
[h264 @ 0x3bdc740] number of reference frames (0+5) exceeds max (4; probably corrupt input), discarding one
[h264 @ 0x3a218c0] illegal short term buffer state detected
[h264 @ 0x3a218c0] nal_unit_type: 9(AUD), nal_ref_idc: 0
[h264 @ 0x3a218c0] nal_unit_type: 6(SEI), nal_ref_idc: 0
[h264 @ 0x3a218c0] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 3
[h264 @ 0x3a218c0] ct_type:0 pic_struct:1
[h264 @ 0x3a218c0] illegal memory management control operation 17
[h264 @ 0x3a218c0] MBAFF frame? aye
[h264 @ 0x3a218c0] Missing reference picture, default is 65975

And then you will get reference picture count/missing related errors for the rest of the decode.

Change History (6)

comment:1 by Carl Eugen Hoyos, 6 years ago

Not a regression afaict, the following works fine:

$ ffmpeg -skip_initial_bytes 2000000 -i 2018-08-17-h264_decoder_borks.cut.ts -qscale 2 out.avi

comment:2 by Carl Eugen Hoyos, 6 years ago

Works fine with xine;-)

comment:3 by jeeb, 6 years ago

Yes, this is not a regression (at least not a recent one) since I've poked at this with various versions from the last year+ or so.

The problem currently is that this glitch or whatever it is happens relatively often in certain streams (although I was only recently able to capture it as it happened), and the decoder doesn't die hard enough, or re-initialize its state properly - thus leading to artifacts in long-running decoders for the rest of the session. Let's just say that's not optimal. That's the primary reason why I created this ticket.

I tested with VAAPI in mpv, and it bails out at the glitch point and falls back to swdec. Of course the next time the glitch happens, swdec is left in a state that isn't optimal.

in reply to:  3 comment:4 by Carl Eugen Hoyos, 6 years ago

Replying to JEEB:

Yes, this is not a regression (at least not a recent one) since I've poked at this with various versions from the last year+ or so.

Yesterday, I tested various versions from the last decade.

Last edited 6 years ago by Carl Eugen Hoyos (previous) (diff)

comment:5 by Balling, 2 years ago

Status: newopen

Oh, wow!! This is not an issue in nvidia ffplay -vcodec h264_cuvid (this comes from h264 decoder though).

looks like #5533

Last edited 3 weeks ago by Balling (previous) (diff)
Note: See TracTickets for help on using tickets.