#4127: h264 DXVA2 decoding regression on Intel GPUs -------------------------------------+------------------------------------- Reporter: johsmi | Owner: Type: defect | Status: new Priority: normal | Component: Version: git-master | undetermined Keywords: | Resolution: Blocking: | Blocked By: Analyzed by developer: 0 | Reproduced by developer: 0 -------------------------------------+------------------------------------- Comment (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). -- Ticket URL: <https://trac.ffmpeg.org/ticket/4127#comment:1> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

#4127: h264 DXVA2 decoding regression on Intel GPUs -------------------------------------+------------------------------------- Reporter: johsmi | Owner: Type: defect | Status: new Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: h264 | Blocked By: regression | Reproduced by developer: 0 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by johsmi): Replying to [comment:1 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. -- Ticket URL: <https://trac.ffmpeg.org/ticket/4127#comment:3> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker