[FFmpeg-devel] [PATCH] avcodec/avcodec: Correct and make consistent AVERROR() in comments

Michael Niedermayer michael at niedermayer.cc
Mon Mar 27 02:30:06 EEST 2017


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 at niedermayer.cc
> > wrote:
> 
> > Signed-off-by: Michael Niedermayer <michael at 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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"    - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
-------------- 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/20170327/78e47273/attachment.sig>


More information about the ffmpeg-devel mailing list