[vlc-devel] [PATCH 2/2] avcodec: va: wait indefinitely until a surface is available

Steve Lhomme robux4 at ycbcr.xyz
Thu Jul 9 17:24:25 CEST 2020

On 2020-07-09 16:31, Rémi Denis-Courmont wrote:
> Le jeudi 9 juillet 2020, 12:56:30 EEST Steve Lhomme a écrit :
>> If there's no surface available the decoder should wait for one to be
>> available, not get an error and not try to decode anymore. When pictures
>> (and thus surfaces) were coming from the display a picture_pool_Wait() was
>> used, so in the normal case we should do something similar.
> In theory, yes. In practice, unfortunately, dubious.
>> The infinite looping shouldn't be an issue as on Flush or Close the decoder
>> will release all the past pictures/surfaces. So there will be new surfaces
>> available for past calls.
> It will still deadlock if one of the following is true:
> - the loop is running on the main decoder thread, and thus will block flushing/
> closing, or

I just tried with --avcodec-threads=1 and it works fine. The calls are 
done in the DecodeBlock() thread. Seeking works, even while paused.

> - the picture pool is too small even for the "few" allocations after flush, in
> particular if there is shortage of memory on the GPU.

If you mean the picture pool and not the surface pool, ie the dummy 
pictures where surfaces are attached, I don't think the size matters. 
The surfaces will be flushed eventually and thus the pictures they are 
attached to. If one works, the other one works too.

> Not sure it's really safe yet.

I can't guarantee 100% either, but looking at our code, the lavc codec, 
the MPV code and doing the worst tests I can think of, I think it's correct.

More information about the vlc-devel mailing list