| Message ID | 20170326191754.1828-1-michael@niedermayer.cc |
|---|---|
| State | Accepted |
| Commit | d65b59550b4d7eb526bbd407df74f030fad5c00b |
| Headers | show |
Hi, On Sun, Mar 26, 2017 at 3:17 PM, Michael Niedermayer <michael@niedermayer.cc > wrote: > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> > --- > libavcodec/avcodec.h | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h > index af327ff9ad..4f3303366f 100644 > --- a/libavcodec/avcodec.h > +++ b/libavcodec/avcodec.h > @@ -153,7 +153,7 @@ > * Unlike with the old video decoding API, multiple frames might result > from > * a packet. For audio, splitting the input packet into frames by > partially > * decoding packets becomes transparent to the API user. You never need > to > - * feed an AVPacket to the API twice (unless it is rejected with EAGAIN > - then > + * feed an AVPacket to the API twice (unless it is rejected with > AVERROR(EAGAIN) - then > * no data was read from the packet). > * Additionally, sending a flush/draining packet is required only once. > * - avcodec_encode_video2()/avcodec_encode_audio2(): > @@ -169,10 +169,10 @@ > * Some codecs might require using the new API; using the old API will > return > * an error when calling it. All codecs support the new API. > * > - * A codec is not allowed to return EAGAIN for both sending and > receiving. This > + * A codec is not allowed to return AVERROR(EAGAIN) for both sending and > receiving. This > * would be an invalid state, which could put the codec user into an > endless > * loop. The API has no concept of time either: it cannot happen that > trying to > - * do avcodec_send_packet() results in EAGAIN, but a repeated call 1 > second > + * do avcodec_send_packet() results in AVERROR(EAGAIN), but a repeated > call 1 second > * later accepts the packet (with no other receive/flush API calls > involved). > * The API is a strict state machine, and the passage of time is not > supposed > * to influence it. Some timing-dependent behavior might still be deemed > @@ -181,7 +181,7 @@ > * avoided that the current state is "unstable" and can "flip-flop" > between > * the send/receive APIs allowing progress. For example, it's not allowed > that > * the codec randomly decides that it actually wants to consume a packet > now > - * instead of returning a frame, after it just returned EAGAIN on an > + * instead of returning a frame, after it just returned AVERROR(EAGAIN) > on an > * avcodec_send_packet() call. > * @} > */ > -- > 2.11.0 > OK. Ronald
On Sun, Mar 26, 2017 at 05:19:59PM -0400, Ronald S. Bultje wrote: > Hi, > > On Sun, Mar 26, 2017 at 3:17 PM, Michael Niedermayer <michael@niedermayer.cc > > wrote: > > > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> > > --- > > libavcodec/avcodec.h | 8 ++++---- > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h > > index af327ff9ad..4f3303366f 100644 > > --- a/libavcodec/avcodec.h > > +++ b/libavcodec/avcodec.h > > @@ -153,7 +153,7 @@ > > * Unlike with the old video decoding API, multiple frames might result > > from > > * a packet. For audio, splitting the input packet into frames by > > partially > > * decoding packets becomes transparent to the API user. You never need > > to > > - * feed an AVPacket to the API twice (unless it is rejected with EAGAIN > > - then > > + * feed an AVPacket to the API twice (unless it is rejected with > > AVERROR(EAGAIN) - then > > * no data was read from the packet). > > * Additionally, sending a flush/draining packet is required only once. > > * - avcodec_encode_video2()/avcodec_encode_audio2(): > > @@ -169,10 +169,10 @@ > > * Some codecs might require using the new API; using the old API will > > return > > * an error when calling it. All codecs support the new API. > > * > > - * A codec is not allowed to return EAGAIN for both sending and > > receiving. This > > + * A codec is not allowed to return AVERROR(EAGAIN) for both sending and > > receiving. This > > * would be an invalid state, which could put the codec user into an > > endless > > * loop. The API has no concept of time either: it cannot happen that > > trying to > > - * do avcodec_send_packet() results in EAGAIN, but a repeated call 1 > > second > > + * do avcodec_send_packet() results in AVERROR(EAGAIN), but a repeated > > call 1 second > > * later accepts the packet (with no other receive/flush API calls > > involved). > > * The API is a strict state machine, and the passage of time is not > > supposed > > * to influence it. Some timing-dependent behavior might still be deemed > > @@ -181,7 +181,7 @@ > > * avoided that the current state is "unstable" and can "flip-flop" > > between > > * the send/receive APIs allowing progress. For example, it's not allowed > > that > > * the codec randomly decides that it actually wants to consume a packet > > now > > - * instead of returning a frame, after it just returned EAGAIN on an > > + * instead of returning a frame, after it just returned AVERROR(EAGAIN) > > on an > > * avcodec_send_packet() call. > > * @} > > */ > > -- > > 2.11.0 > > > > OK. applied thx [...]
On Sun, 26 Mar 2017 21:17:54 +0200 Michael Niedermayer <michael@niedermayer.cc> wrote: > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> > --- > libavcodec/avcodec.h | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h > index af327ff9ad..4f3303366f 100644 > --- a/libavcodec/avcodec.h > +++ b/libavcodec/avcodec.h > @@ -153,7 +153,7 @@ > * Unlike with the old video decoding API, multiple frames might result from > * a packet. For audio, splitting the input packet into frames by partially > * decoding packets becomes transparent to the API user. You never need to > - * feed an AVPacket to the API twice (unless it is rejected with EAGAIN - then > + * feed an AVPacket to the API twice (unless it is rejected with AVERROR(EAGAIN) - then > * no data was read from the packet). > * Additionally, sending a flush/draining packet is required only once. > * - avcodec_encode_video2()/avcodec_encode_audio2(): > @@ -169,10 +169,10 @@ > * Some codecs might require using the new API; using the old API will return > * an error when calling it. All codecs support the new API. > * > - * A codec is not allowed to return EAGAIN for both sending and receiving. This > + * A codec is not allowed to return AVERROR(EAGAIN) for both sending and receiving. This > * would be an invalid state, which could put the codec user into an endless > * loop. The API has no concept of time either: it cannot happen that trying to > - * do avcodec_send_packet() results in EAGAIN, but a repeated call 1 second > + * do avcodec_send_packet() results in AVERROR(EAGAIN), but a repeated call 1 second > * later accepts the packet (with no other receive/flush API calls involved). > * The API is a strict state machine, and the passage of time is not supposed > * to influence it. Some timing-dependent behavior might still be deemed > @@ -181,7 +181,7 @@ > * avoided that the current state is "unstable" and can "flip-flop" between > * the send/receive APIs allowing progress. For example, it's not allowed that > * the codec randomly decides that it actually wants to consume a packet now > - * instead of returning a frame, after it just returned EAGAIN on an > + * instead of returning a frame, after it just returned AVERROR(EAGAIN) on an > * avcodec_send_packet() call. > * @} > */ The AVERROR() was not in there for readability. The doxygen on the actual functions makes it clear that AVERROR() is needed. (But "thanks" for not waiting for my review.)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h index af327ff9ad..4f3303366f 100644 --- a/libavcodec/avcodec.h +++ b/libavcodec/avcodec.h @@ -153,7 +153,7 @@ * Unlike with the old video decoding API, multiple frames might result from * a packet. For audio, splitting the input packet into frames by partially * decoding packets becomes transparent to the API user. You never need to - * feed an AVPacket to the API twice (unless it is rejected with EAGAIN - then + * feed an AVPacket to the API twice (unless it is rejected with AVERROR(EAGAIN) - then * no data was read from the packet). * Additionally, sending a flush/draining packet is required only once. * - avcodec_encode_video2()/avcodec_encode_audio2(): @@ -169,10 +169,10 @@ * Some codecs might require using the new API; using the old API will return * an error when calling it. All codecs support the new API. * - * A codec is not allowed to return EAGAIN for both sending and receiving. This + * A codec is not allowed to return AVERROR(EAGAIN) for both sending and receiving. This * would be an invalid state, which could put the codec user into an endless * loop. The API has no concept of time either: it cannot happen that trying to - * do avcodec_send_packet() results in EAGAIN, but a repeated call 1 second + * do avcodec_send_packet() results in AVERROR(EAGAIN), but a repeated call 1 second * later accepts the packet (with no other receive/flush API calls involved). * The API is a strict state machine, and the passage of time is not supposed * to influence it. Some timing-dependent behavior might still be deemed @@ -181,7 +181,7 @@ * avoided that the current state is "unstable" and can "flip-flop" between * the send/receive APIs allowing progress. For example, it's not allowed that * the codec randomly decides that it actually wants to consume a packet now - * instead of returning a frame, after it just returned EAGAIN on an + * instead of returning a frame, after it just returned AVERROR(EAGAIN) on an * avcodec_send_packet() call. * @} */
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> --- libavcodec/avcodec.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)