[FFmpeg-devel] [PATCH] avcodec/avcodec: Fix text implying single threaded decoding
wm4
nfxjfg at googlemail.com
Wed Apr 19 04:13:52 EEST 2017
On Tue, 18 Apr 2017 16:01:48 +0200
Michael Niedermayer <michael at niedermayer.cc> wrote:
> On Tue, Apr 18, 2017 at 03:47:29PM +0200, Nicolas George wrote:
> > Le nonidi 29 germinal, an CCXXV, Michael Niedermayer a écrit :
> > > This contradicts the documentation: (and would be rather rigid design)
> >
> > Possible. But it has nothing to do with threading.
> >
> > > > threaded decoder will just start the work and return EAGAIN.
> > > Thats true but this is not permitted by the text prior to my patch
> >
> > Yes it is.
> >
>
> > > The requiement to call avcodec_receive_frame() multiple times implies
> > > it does not return EAGAIN because you would not call it again if it
> > > did.
> >
> > No, you would not call it again, you would first have to feed it another
> > packet. Still no problem at this level.
>
> Iam not sure you did read the text the patch changes
>
> "... require you to call avcodec_receive_frame() multiple
> times afterwards before you can send a new packet"
>
> this just isnt true
> if a decoder returns EAGAIN you would not call it multiple times
>
The decoder is free to do whatever it pleases. It _could_ force the API
user to "receive" multiple frames immediately, or it could buffer
multiple packets/frames internally and make the user "receive" them at
a later point.
The whole point of the API is to make this data flow more flexible. The
whole point about the sentence your patch changes is that you do not
somehow feed parts of the previous packet to new "send" invocations,
like the old audio decode API did.
Feel free to improve the docs (they surely are not perfect), but I
don't think your patch does. It seems to sort of miss the point.
More information about the ffmpeg-devel
mailing list