[FFmpeg-devel] [PATCH] avcodec/avcodec: Fix text implying single threaded decoding

Michael Niedermayer michael at niedermayer.cc
Tue Apr 18 16:44:38 EEST 2017

On Tue, Apr 18, 2017 at 03:23:14PM +0200, Nicolas George wrote:
> Le nonidi 29 germinal, an CCXXV, Michael Niedermayer a écrit :
> > if you cannot send a new packet before you received the output of
> > the previous
> You have to TRY TO receive the output before you send a new packet. A

This contradicts the documentation: (and would be rather rigid design)

 * Using the API as outlined above is highly recommended. But it is also
 * possible to call functions outside of this rigid schema. For example, you can
 * call avcodec_send_packet() repeatedly without calling
 * avcodec_receive_frame(). In this case, avcodec_send_packet() will succeed
 * until the codec's internal buffer has been filled up (which is typically of
 * size 1 per output frame, after initial input), and then reject input with
 * AVERROR(EAGAIN). Once it starts rejecting input, you have no choice but to
 * read at least some output.

> threaded decoder will just start the work and return EAGAIN.

Thats true but this is not permitted by the text prior to my patch

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. (one might "mathematically" work around this but the result still
wont make sense)

For reference:

@@ -4960,7 +4960,7 @@ int avcodec_decode_subtitle2(AVCodecContext *avctx, AVSubtitle *sub,
  *                  Unlike with older APIs, the packet is always fully consumed,
  *                  and if it contains multiple frames (e.g. some audio codecs),
  *                  will require you to call avcodec_receive_frame() multiple
- *                  times afterwards before you can send a new packet.
+ *                  times afterwards.


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170418/af4c229c/attachment.sig>

More information about the ffmpeg-devel mailing list