[vlc-devel] [PATCH 01/12] decoder: add decoder_OnOutputReady

Thomas Guillem thomas at gllm.fr
Tue Sep 8 16:41:15 CEST 2015



On Tue, Sep 1, 2015, at 21:56, Rémi Denis-Courmont wrote:
> On Tuesday 01 September 2015 21:37:45 Thomas Guillem wrote:
> > > They are supposed to be callable from any thread. libavcodec uses both
> > > from other threads. Of course the decoder is responsible for ensuring
> > > sane ordering and updating the output format adequately. That's
> > > unavoidable and your draining approach won't change anything in that
> > > respect.
> > 
> > OK, I didn't know that these functions were callable from any thread. I
> > was mislead by my first and too complicated version of my async decoder.
> > I'll try with the "decoder_QueuePicture" way.
> 
> Oh, there are issues with threaded decoding. I know at least two:
> 
> 1) There is confusion about fmt_out being the format of following buffer 
> allocations, or the format of following output buffers. It assumes both
> are 
> identical. That is not true with threaded decoding, at least not for
> H.264 and 
> H.265.
> 
> We need to dedicated fmt_out to one, the other, or neither, but not both.
> (My 
> personal preference would be neither, as it is unambiguous, but it is
> also the 
> most disruptive to the code base.)

I have some questions about fmt_out change. If it changes a new vout is
created, right ? In that case,  what happen to the previous vout and the
pictures attached to it ? Are they displayed with the previous vout or
are they dropped ?

> 
> 2) The rules for changing fmt_in when a packetizer is used are under-
> specified. This is bad especially in threaded case as the decoder threads 
> might access fmt_in asynchronously (such that fmt_in should be
> read-only).
> 
> Nevertheless, I do not see how draining works around those issues in any
> way, 
> let alone solve them.
> 
> -- 
> 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