h264 DXVA2 decoding regression on Intel GPUs

[johsmi]

Summary of the bug:
h264 DXVA2 decoding regression on Intel GPUs caused by commit: ​http://git.videolan.org/?p=ffmpeg.git;a=commit;h=9e5ef1c5c37208326c59d642e2dc7afd3f10b09b

This was first noticed as a green start on some h264 streams in Kodi Helix. See ticket ​http://trac.xbmc.org/ticket/15498 for additional history.

How to reproduce:

ffmpeg -v repeat+debug -hwaccel dxva2 -threads 1 -i green_start.mkv green_start.avi

Using this sample clip: ​https://www.dropbox.com/s/5rr66ptquuju5zz/green_start.mkv?dl=0

[Hendrik]

Its more likely that before this change it would just skip those frames entirely, while now it tries to decode them (and fails). This isn't technically a regression.

I can only recommend you to fill fresh empty frames black when allocating them for DXVA2, that way you start with a black screen, and not a green screen, if decoding for some reason fails (like on badly cut streams like this one).

[johsmi]

Replying to heleppkes:

Its more likely that before this change it would just skip those frames entirely, while now it tries to decode them (and fails). This isn't technically a regression.

The difference is not just from skipping a few initial frames before the change. I've extracted all frames using this command line:

ffmpeg -hwaccel dxva2 -threads 1 -i green_start.mkv frames-%3d.ppm

206 frames are generated both before and after applying that change. I have also confirmed that the frames are identical after the initial bad frames (fc /B confirms no differences for a particular frame nr starting from frame 16).

I've compared data before and after that change in some detail and one thing that does happen is that after the change, the first frame to decode has:
ctx_pic->pp.CurrPic=4 and ctx_pic->pp.RefFrameList = 03 02 01 00 FF...

This ends up in the DXVA2 picture decoding parameter buffer and the call to IDirectXVideoDecoder_Execute fails.

Before the change, the first frame has:
ctx_pic->pp.CurrPic=0 and ctx_pic->pp.RefFrameList = FF FF FF FF FF...

That call to IDirectXVideoDecoder_Execute succeeds.

[Balling]

Does not happen anymore. Same size on all decoders.

[h264 @ 00000202a46014c0] Increasing reorder buffer to 2

-c:v h264_cuvid is affected still though. It decodes 206 frames but is not bitperfect (THOSE ERRORS are off-by-one!! WTF! only in some first frames) compared to -hwaccel cuda -hwaccel d3d11va and -hwaccel dxva2

But it appears that first frame is not green either. So...