Opened 4 years ago

Last modified 4 years ago

#4127 new defect

h264 DXVA2 decoding regression on Intel GPUs

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

Description

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

Change History (3)

comment:1 follow-up: Changed 4 years ago by 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.

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

comment:2 Changed 4 years ago by cehoyos

  • Component changed from undetermined to avcodec
  • Keywords h264 regression added

comment:3 in reply to: ↑ 1 Changed 4 years ago by 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.

Note: See TracTickets for help on using tickets.