[vlc-devel] [PATCH] avcodec: only disable frame threading if DXVA2 is likely to be used

Steve Lhomme robux4 at videolabs.io
Thu Apr 2 13:48:45 CEST 2015


On Thu, Apr 2, 2015 at 8:53 AM, Steve Lhomme <robux4 at videolabs.io> wrote:
> On Wed, Apr 1, 2015 at 3:01 PM, Steve Lhomme <robux4 at videolabs.io> wrote:
>> Never mind, I've had the buffer lock issue with a HEVC sample. So
>> avcodec still can't pick the right threading module by itself. Or
>> we're not handling the buffers the way it wants...

The fix for that crash is in ffmpeg already.
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=786032cad8ecabe577d9cff0356da6e9e9488a2d

Our get_format() was recreating a new DXVA2 instance and their HEVC
code was using some buffers allocated and released by the previous
instance.

It seems that HEVC works with 8 buffers, compared to 22 for H264. Is
this something we can assume ? Given HEVC will be used for 4K, we
don't want to allocate too many buffers we will never use. DXVA2
doesn't tell how many buffers are needed per decoder instance nor
avcodec. So we need to guess right.

> I think it's worth putting my efforts in solving this. Because
> pre-detecting that DXVA2 could be use will never work, as Remi
> mentioned. The codec can always change in the middle of the stream.

The original problem was green fields when decoding on Intel HD
Graphics 4000. I will try samples with frame threading enabled and see
if it still happens.

There are definitely artefacts when we reduce the amount of buffers
available for the decoder. It may be related.

> And because we pretty much always disable frame threading on windows
> we have a big performance drop in 2.2.0.

If DXVA2 doesn't fail anymore with avcodec frame threading we may
remove the hack completely.



More information about the vlc-devel mailing list