[FFmpeg-devel] [PATCH 1/2] avformat/demux: Make read_frame_internal() return AVERREOR(EAGAIN) on stuck empty input parser

[Marton Balint]

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 <michael at niedermayer.cc>
> ---
> 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