[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
picture.
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 /
10).
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