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 A258740261 for ; Sat, 18 Jun 2022 21:58:31 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id D6C4968B5B5; Sun, 19 Jun 2022 00:58:28 +0300 (EEST) Received: from iq.passwd.hu (iq.passwd.hu [217.27.212.140]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9E7E268B321 for ; Sun, 19 Jun 2022 00:58:22 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by iq.passwd.hu (Postfix) with ESMTP id E772CE7389 for ; Sat, 18 Jun 2022 23:58:22 +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 4l_CyyRbzEhR for ; Sat, 18 Jun 2022 23:58:17 +0200 (CEST) Received: from iq (iq [217.27.212.140]) by iq.passwd.hu (Postfix) with ESMTPS id A2068E723A for ; Sat, 18 Jun 2022 23:58:17 +0200 (CEST) Date: Sat, 18 Jun 2022 23:58:17 +0200 (CEST) From: Marton Balint To: FFmpeg development discussions and patches In-Reply-To: <20220618163044.GZ396728@pb2> Message-ID: References: <20220208202353.19554-1-michael@niedermayer.cc> <83406d0-fb76-b7ba-c19a-194f6bc6a69e@passwd.hu> <20220618163044.GZ396728@pb2> 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 Sat, 18 Jun 2022, Michael Niedermayer wrote: > On Fri, Jun 17, 2022 at 09:53:13PM +0200, Marton Balint wrote: >> >> >> 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. > > yes thats why i waited so many month before i applied it > some patchsets i forget but this i kept pushing away > >> >> 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)? > > In the context of this problem the idea is to give the user an opertunity > to do something else in a single threaded environment or error out if > its taking too long not produingh anything > > >> >> 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. > > IIRC the problem was that the demuxer produced 0 sized packets and alot of them > for a file only a few hundread bytes large. AFAIK a demuxer is not supposed to generate 0-sized packets. Or do you think otherwise? E.g. a simple patch like this seems the better approach: --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -8677,8 +8677,12 @@ static int mov_read_packet(AVFormatContext *s, AVPacket *pkt) if (st->codecpar->codec_id == AV_CODEC_ID_EIA_608 && sample->size > 8) ret = get_eia608_packet(sc->pb, pkt, sample->size); - else + else if (sample->size > 0) { ret = av_get_packet(sc->pb, pkt, sample->size); + } else { + av_log(mov->fc, AV_LOG_ERROR, "Invalid sample size, corrupt index?\n"); + return AVERROR_INVALIDDATA; + } if (ret < 0) { if (should_retry(sc->pb, ret)) { mov_current_sample_dec(sc); Regards, 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".