[vlc-devel] [PATCH] decoder: flush the vout before flushing the decoder

Thomas Guillem thomas at gllm.fr
Fri Dec 11 13:34:44 CET 2015

On Wed, Dec 2, 2015, at 23:15, Rémi Denis-Courmont wrote:
> On Wednesday 02 December 2015 10:09:43 Thomas Guillem wrote:
> > Yes, avcodec_flush_buffers() waits for pending get_buffer() to return.
> Then the only possibility is to make get_buffer2() fail using a transient 
> level trigger. That has some implications on how libavcodec would handle 
> get_buffer2() failures, which are not currently explicit and official, if
> at 
> all supported.

I discussed with luca this week-end, if get_buffer2() returns -ENOMEN,
the worker thread will be stopped and won't live loop. With this
behavior, I can use a decoder_AbortPictures to abort avcodec worker

I'll propose a new set of patches.

> But...
> > I'm out of ideas right now, can we discuss it this week-end?
> I still don´t really understand the point of this patch. The exit
> deadlock 
> should be fixed, and the remaining mwait() issue does not affect video
> (and 
> has a separate patch).
> Historically, VLC has lamely recycle still-in-use picture buffers when it
> ran 
> out before exit. If that happened now (post libavcodec "evil plan one"),
> it 
> would lead to crashes. And regardless, if you have a problem with
> libavcodec-
> MT, then vlc-devel is probably not the most appropriate venue, nor will
> the 
> next VideoLAN plenary be.
> (IMHO, libavcodec needs a *proper* thread/asynchronous decoding
> discussion 
> including the key "consumers" such as mpv, VLC and LAV filters, but that
> does 
> not belong on vlc-devel.)
> -- 
> 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