[vlc-devel] [PATCH 01/12] decoder: add decoder_OnOutputReady
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
> identical. That is not true with threaded decoding, at least not for
> H.264 and
> We need to dedicated fmt_out to one, the other, or neither, but not both.
> 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
> Nevertheless, I do not see how draining works around those issues in any
> let alone solve them.
> Rémi Denis-Courmont
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel