[vlc-devel] [PATCH 2/2] avcodec: va: wait indefinitely until a surface is available
thomas at gllm.fr
Fri Jul 10 08:46:45 CEST 2020
On Thu, Jul 9, 2020, at 17:24, Steve Lhomme wrote:
> 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.
I also tested this patch set, trying to reproduce the problems we encountered in VLC 3.0, could not reproduce a deadlock.
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel