From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 6717643044 for ; Fri, 17 Jun 2022 19:53:24 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 87D9068B8E0; Fri, 17 Jun 2022 22:53:21 +0300 (EEST) Received: from iq.passwd.hu (iq.passwd.hu [217.27.212.140]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 2F62B68A5B3 for ; Fri, 17 Jun 2022 22:53:15 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by iq.passwd.hu (Postfix) with ESMTP id 4291DE7358 for ; Fri, 17 Jun 2022 21:53:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at passwd.hu Received: from iq.passwd.hu ([127.0.0.1]) by localhost (iq.passwd.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHRDwEux7eUV for ; Fri, 17 Jun 2022 21:53:13 +0200 (CEST) Received: from iq (iq [217.27.212.140]) by iq.passwd.hu (Postfix) with ESMTPS id 643EBE7209 for ; Fri, 17 Jun 2022 21:53:13 +0200 (CEST) Date: Fri, 17 Jun 2022 21:53:13 +0200 (CEST) From: Marton Balint To: FFmpeg development discussions and patches In-Reply-To: <20220208202353.19554-1-michael@niedermayer.cc> Message-ID: <83406d0-fb76-b7ba-c19a-194f6bc6a69e@passwd.hu> References: <20220208202353.19554-1-michael@niedermayer.cc> MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 1/2] avformat/demux: Make read_frame_internal() return AVERREOR(EAGAIN) on stuck empty input parser X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 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 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Tue, 8 Feb 2022, Michael Niedermayer wrote: > Fixes: read_frame_internal() which does not return even though both demuxer and parser do return > Fixes: 43717/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-5206008287330304 > > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/demux.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/libavformat/demux.c b/libavformat/demux.c > index ec34b65288..dd42d32710 100644 > --- a/libavformat/demux.c > +++ b/libavformat/demux.c > @@ -1222,11 +1222,15 @@ static int read_frame_internal(AVFormatContext *s, AVPacket *pkt) > FFFormatContext *const si = ffformatcontext(s); > int ret, got_packet = 0; > AVDictionary *metadata = NULL; > + int empty = 0; > > while (!got_packet && !si->parse_queue.head) { > AVStream *st; > FFStream *sti; > > + if (empty > 1) > + return AVERROR(EAGAIN); > + > /* read next packet */ > ret = ff_read_packet(s, pkt); > if (ret < 0) { > @@ -1317,6 +1321,8 @@ static int read_frame_internal(AVFormatContext *s, AVPacket *pkt) > } > got_packet = 1; > } else if (st->discard < AVDISCARD_ALL) { > + if (pkt->size == 0) > + empty ++; > if ((ret = parse_packet(s, pkt, pkt->stream_index, 0)) < 0) > return ret; > st->codecpar->sample_rate = sti->avctx->sample_rate; > -- > 2.17.1 Sorry, just noticed this patchset, and it is very hackish. For starters the meaning of AVERROR(EAGAIN) for av_read_frame()/read_frame_internal() is not very well defined. Should the user retry immediately? Should the user sleep() sometime and the retry? Can the user expect that a loop of av_read_frame() will eventually return something different than AVERROR(EAGAIN)? I am not sure I understand the original issue entirely, but it looks that instead of fixing the component which returns infinite amount of zero sized packets you implemented a check that makes the user get an EAGAIN() on the second zero-sized packet. And this helps the user how? Instead of a busy CPU loop in the library he either gets a busy CPU loop in its application or a non-busy CPU loop in its application (if he sleeps() on EAGAIN). Is there a file which causes this? Can't the underlying components be fixed instead? Thanks, Marton _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".