From patchwork Sun Mar 26 19:17:54 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Niedermayer X-Patchwork-Id: 3109 Delivered-To: ffmpegpatchwork@gmail.com Received: by 10.103.50.79 with SMTP id y76csp928664vsy; Sun, 26 Mar 2017 12:18:10 -0700 (PDT) X-Received: by 10.28.17.208 with SMTP id 199mr6400744wmr.9.1490555890367; Sun, 26 Mar 2017 12:18:10 -0700 (PDT) Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org. [79.124.17.100]) by mx.google.com with ESMTP id d25si4085953wrb.160.2017.03.26.12.18.09; Sun, 26 Mar 2017 12:18:10 -0700 (PDT) Received-SPF: pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) client-ip=79.124.17.100; Authentication-Results: mx.google.com; spf=pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) smtp.mailfrom=ffmpeg-devel-bounces@ffmpeg.org Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 08CA26809DE; Sun, 26 Mar 2017 22:17:45 +0300 (EEST) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from vie01a-dmta-pe01-3.mx.upcmail.net (vie01a-dmta-pe01-3.mx.upcmail.net [62.179.121.156]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 8AAF66809DE for ; Sun, 26 Mar 2017 22:17:38 +0300 (EEST) Received: from [172.31.216.43] (helo=vie01a-pemc-psmtp-pe01) by vie01a-dmta-pe01.mx.upcmail.net with esmtp (Exim 4.88) (envelope-from ) id 1csDfr-0003au-Em for ffmpeg-devel@ffmpeg.org; Sun, 26 Mar 2017 21:17:59 +0200 Received: from localhost ([213.47.41.20]) by vie01a-pemc-psmtp-pe01 with SMTP @ mailcloud.upcmail.net id 0jHv1v00C0S5wYM01jHw3L; Sun, 26 Mar 2017 21:17:56 +0200 X-SourceIP: 213.47.41.20 From: Michael Niedermayer To: FFmpeg development discussions and patches Date: Sun, 26 Mar 2017 21:17:54 +0200 Message-Id: <20170326191754.1828-1-michael@niedermayer.cc> X-Mailer: git-send-email 2.11.0 Subject: [FFmpeg-devel] [PATCH] avcodec/avcodec: Correct and make consistent AVERROR() in comments X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches MIME-Version: 1.0 Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Signed-off-by: Michael Niedermayer --- 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. * @} */