[vlc-devel] [RFC PATCH 3/3] decoder: cancel the vout on close

Thomas Guillem thomas at gllm.fr
Thu Nov 19 09:43:11 CET 2015

On Wed, Nov 18, 2015, at 19:29, Rémi Denis-Courmont wrote:
> On Wednesday 18 November 2015 14:32:01 Thomas Guillem wrote:
> > This fixes a deadlock if a decoder module is waiting on decoder_GetPicture /
> > decoder_NewPicture when it's closing.
> I am not aware of any circumstance that would lead to such deadlock.

avcodec with mt and direct rendering: if all pictures from the
decoder_pool are dequeued, next GetPicture/NewPicture call, from
lavc_GetFrame, will block until the Output thread display/release a

The only thing I'm sure is that there is a deadlock in an avcodec thread
in lavc_GetFrame when closing. It's not systematic (I would say 1 time /

That why I did theses patches. But by writing my comments I released
that the video vout is not touched until UnloadDecoder is finished, so
the vout should be still running and able to display/release picture, no

> A decoder, filter or output bug could leak pictures and starve the pool.
> Or 
> the requested pool size could be too small. But that would deadlock much 
> earlier than at exit. Also silently ignoring the problem would have 
> potentially catastrophic effects on memory usage.
> In the past, leaked pictures were assumed to be permanently leaked, and
> then 
> forcefully recycled or destroyed. That worked with libmpeg2. That will
> not 
> work safely with avcodec, or generally with asynchronous or threaded
> decoding 
> though. Decoder plugins need to be fixed or dropped.

I don't think there is a picture leak in avcodec or any decoder module I
worked on.

> -- 
> Rémi Denis-Courmont
> http://www.remlab.net/
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel

More information about the vlc-devel mailing list