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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
