[vlc-devel] [PATCH] DxVA2: fix compatibility with avcodec frame multithreading

Steve Lhomme robux4 at videolabs.io
Wed Apr 8 07:50:35 CEST 2015

On Tue, Apr 7, 2015 at 5:56 PM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le 2015-04-03 17:48, Steve Lhomme a écrit :
>> There is a race condition when seeking in H264 :(
> I have never seen this in VDPAU with recent libav libavcodec.
> Anyhow undefined behaviour is undefined. You have to fix libavcodec or get a
> working version of it.
>> Sometimes the Release() callback is called with a garbage `opaque`
>> variable, which is supposed to be our vlc_va_surface_t object...
> Are you sure the dxva2 plugin is not freeing surfaces outside of
> AVCodecContext.release_buffer - even though libavcodec is still holding the
> picture?

Yes, that seems to be the case here. After seeking the whole DXVA
decoder is recreated but not the avcodec one. So avcodec continues to
use some buffers while DXVA has released them all. This is only a
problem when frame threading is enabled. There might be a race issue
between the decoding threads not being notified to flush and the
"control" thread that has already moved on to something else.

This behaviour may be specific to Video Acceleration where decoding
buffers are pre-allocated and freed independently of avcodec.

More information about the vlc-devel mailing list