From patchwork Wed Feb 15 07:53:18 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: wm4 X-Patchwork-Id: 2552 Delivered-To: ffmpegpatchwork@gmail.com Received: by 10.103.89.21 with SMTP id n21csp1839440vsb; Tue, 14 Feb 2017 23:53:22 -0800 (PST) X-Received: by 10.223.147.1 with SMTP id 1mr27752038wro.60.1487145202452; Tue, 14 Feb 2017 23:53:22 -0800 (PST) Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org. [79.124.17.100]) by mx.google.com with ESMTP id q1si6746649wmg.47.2017.02.14.23.53.21; Tue, 14 Feb 2017 23:53:22 -0800 (PST) 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; dkim=neutral (body hash did not verify) header.i=@googlemail.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; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 3986B68925B; Wed, 15 Feb 2017 09:53:13 +0200 (EET) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from mail-wm0-f65.google.com (mail-wm0-f65.google.com [74.125.82.65]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id C7087680ABB for ; Wed, 15 Feb 2017 09:53:06 +0200 (EET) Received: by mail-wm0-f65.google.com with SMTP id v77so6814496wmv.0 for ; Tue, 14 Feb 2017 23:53:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=9QFteQr9Y/P4/uooD/oiSKufp1bvOnnWwkR/UtjmnrE=; b=XXDRe1xmF+fXl8wOB4KKwqIu1kUtC145ob3K5ULykqF2Cp8rDiS09B4IT2KN1G+nqz sqErqM2/y62TCuH28KZFALpHz9o41QekbkcESl41nBhR5/ITdWcyKYp1dB6hvGvijE9/ s8kUxx4iPIBxCIfGm4JwF36e0Lk528+r9Piozhv37BsZYqt8jidkQKQljFVjvuPfPbpX PfcF5LAMuF7MXQIL+gqf8YaNJz0YPpsIJoRExRwjUXa1cGtqUAcPRYmIA4pqmNodxxb4 XxpNoEs5JwZIM4vK8sfcfLwde39k1f3tfJk6eUGxZq3YMItyAekws6yhSCEv1F527I0A WXvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=9QFteQr9Y/P4/uooD/oiSKufp1bvOnnWwkR/UtjmnrE=; b=W72RIcDGpKoOoOhAqfMgk0oGbF06+GE4JcNAARA6BDZdAPr+52qXHLura4m1EfFSSg kxBY3ssB0Ew/smIX3PgzeXu1nlD9QFPy1btGWvbaLAsddCKCSuB8G6mzfARqys5x0NGF eGQt4NX5lqR6SumRLzmUz/hu6vuG+PtO/X9cChQElb/BagNDpS0kbC8tfpnyu65y8wma eL3f6em24CIw7MFCuIPTReXbQbnoS7hj/TqstqwzzL2w8GeJI+AuNuXddCZ/7B9MWK9B HZNiB/Mewxk6GRNnSkQmQ1HYykFHM0ux+T46RuBOrrqSm8Vqfio5w8EHQys1VzX0yrpl +g2w== X-Gm-Message-State: AMke39lQqC1bomf/2n0KWcTN3Yd8cj3ZoOBmoswGYr7f2rDdt26fng4JbCzAv0C/5+UNbw== X-Received: by 10.28.155.5 with SMTP id d5mr7073144wme.85.1487145192142; Tue, 14 Feb 2017 23:53:12 -0800 (PST) Received: from localhost.localdomain (p4FF0242F.dip0.t-ipconnect.de. [79.240.36.47]) by smtp.googlemail.com with ESMTPSA id g81sm4266737wmf.16.2017.02.14.23.53.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 23:53:11 -0800 (PST) From: wm4 To: ffmpeg-devel@ffmpeg.org Date: Wed, 15 Feb 2017 08:53:18 +0100 Message-Id: <20170215075318.28498-1-nfxjfg@googlemail.com> X-Mailer: git-send-email 2.11.0 Subject: [FFmpeg-devel] [PATCH] lavc: consider an error during decoder draining as EOF 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 Cc: wm4 MIME-Version: 1.0 Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" There is no reason that draining couldn't return an error or two. But some decoders don't handle this very well, and might always return an error. This can lead to API users getting into an infinite loop and burning CPU, because no progress is made and EOF is never returned. In fact, ffmpeg.c contains a hack against such a case. It is removed with this patch. This particular error case seems to have been fixed since the hack was added, though. This might lose frames if decoding returns errors during draining. --- ffmpeg.c | 6 ------ libavcodec/utils.c | 6 +++--- 2 files changed, 3 insertions(+), 9 deletions(-) diff --git a/ffmpeg.c b/ffmpeg.c index 06570c0dd0..bd54e66f08 100644 --- a/ffmpeg.c +++ b/ffmpeg.c @@ -2529,12 +2529,6 @@ static int process_input_packet(InputStream *ist, const AVPacket *pkt, int no_eo ist->file_index, ist->st->index, av_err2str(ret)); if (exit_on_error) exit_program(1); - // Decoding might not terminate if we're draining the decoder, and - // the decoder keeps returning an error. - // This should probably be considered a libavcodec issue. - // Sample: fate-vsynth1-dnxhd-720p-hr-lb - if (!pkt) - eof_reached = 1; break; } diff --git a/libavcodec/utils.c b/libavcodec/utils.c index f4085bf7a7..0a72dd684d 100644 --- a/libavcodec/utils.c +++ b/libavcodec/utils.c @@ -2807,12 +2807,12 @@ static int do_decode(AVCodecContext *avctx, AVPacket *pkt) if (ret == AVERROR(EAGAIN)) ret = pkt->size; - if (ret < 0) - return ret; - if (avctx->internal->draining && !got_frame) avctx->internal->draining_done = 1; + if (ret < 0) + return ret; + if (ret >= pkt->size) { av_packet_unref(avctx->internal->buffer_pkt); } else {