[FFmpeg-devel] [PATCH 1/5] avformat/flvdec: Check for EOF in AudioPacketTypeMultichannelConfig

[FFmpeg-devel] [PATCH 1/5] avformat/flvdec: Check for EOF in AudioPacketTypeMultichannelConfig

[Michael Niedermayer]

Fixes: Infinite loop
Fixes: 427538726/clusterfuzz-testcase-minimized-ffmpeg_dem_FLV_fuzzer-6582567304495104

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
 libavformat/flvdec.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index ac681954cb7..a4fa0157512 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -1715,6 +1715,9 @@ retry_duration:
 
                 av_log(s, AV_LOG_DEBUG, "Set channel data from MultiChannel info.\n");
 
+                if (avio_feof(s->pb))
+                    return AVERROR_EOF;
+
                 goto next_track;
             }
         } else if (stream_type == FLV_STREAM_TYPE_VIDEO) {
-- 
2.49.0

_______________________________________________
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".

[FFmpeg-devel] [PATCH 2/5] avformat/concatdec: Clip duration in one more case in get_best_effort_duration()

[Michael Niedermayer]

Fixes: signed integer overflow: 40000 - -9223372036854770000 cannot be represented in type 'long'
Fixes: 427262541/clusterfuzz-testcase-minimized-ffmpeg_dem_CONCAT_fuzzer-4831506940100608

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
 libavformat/concatdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index fe65d0c7688..e0c2c872482 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -326,7 +326,7 @@ static int64_t get_best_effort_duration(ConcatFile *file, AVFormatContext *avf)
     if (file->outpoint != AV_NOPTS_VALUE)
         return av_sat_sub64(file->outpoint, file->file_inpoint);
     if (avf->duration > 0)
-        return avf->duration - (file->file_inpoint - file->file_start_time);
+        return av_sat_sub64(avf->duration, file->file_inpoint - file->file_start_time);
     if (file->next_dts != AV_NOPTS_VALUE)
         return file->next_dts - file->file_inpoint;
     return AV_NOPTS_VALUE;
-- 
2.49.0

_______________________________________________
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".

[FFmpeg-devel] [PATCH 3/5] avcodec/h264chroma_template: Replace variable by constant in chroma mc

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
 libavcodec/h264chroma_template.c | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/libavcodec/h264chroma_template.c b/libavcodec/h264chroma_template.c
index b9d24f5a0cd..b20811a71ae 100644
--- a/libavcodec/h264chroma_template.c
+++ b/libavcodec/h264chroma_template.c
@@ -54,7 +54,7 @@ static void FUNCC(OPNAME ## h264_chroma_mc1)(uint8_t *_dst /*align 8*/, const ui
         }\
     } else {\
         for(i=0; i<h; i++){\
-            OP(dst[0], (A*src[0]));\
+            OP(dst[0], (64*src[0]));\
             dst+= stride;\
             src+= stride;\
         }\
@@ -91,8 +91,8 @@ static void FUNCC(OPNAME ## h264_chroma_mc2)(uint8_t *_dst /*align 8*/, const ui
         }\
     } else {\
         for ( i = 0; i < h; i++){\
-            OP(dst[0], A * src[0]);\
-            OP(dst[1], A * src[1]);\
+            OP(dst[0], 64 * src[0]);\
+            OP(dst[1], 64 * src[1]);\
             dst += stride;\
             src += stride;\
         }\
@@ -134,10 +134,10 @@ static void FUNCC(OPNAME ## h264_chroma_mc4)(uint8_t *_dst /*align 8*/, const ui
         }\
     } else {\
         for ( i = 0; i < h; i++){\
-            OP(dst[0], A * src[0]);\
-            OP(dst[1], A * src[1]);\
-            OP(dst[2], A * src[2]);\
-            OP(dst[3], A * src[3]);\
+            OP(dst[0], 64 * src[0]);\
+            OP(dst[1], 64 * src[1]);\
+            OP(dst[2], 64 * src[2]);\
+            OP(dst[3], 64 * src[3]);\
             dst += stride;\
             src += stride;\
         }\
@@ -187,14 +187,14 @@ static void FUNCC(OPNAME ## h264_chroma_mc8)(uint8_t *_dst /*align 8*/, const ui
         }\
     } else {\
         for ( i = 0; i < h; i++){\
-            OP(dst[0], A * src[0]);\
-            OP(dst[1], A * src[1]);\
-            OP(dst[2], A * src[2]);\
-            OP(dst[3], A * src[3]);\
-            OP(dst[4], A * src[4]);\
-            OP(dst[5], A * src[5]);\
-            OP(dst[6], A * src[6]);\
-            OP(dst[7], A * src[7]);\
+            OP(dst[0], 64 * src[0]);\
+            OP(dst[1], 64 * src[1]);\
+            OP(dst[2], 64 * src[2]);\
+            OP(dst[3], 64 * src[3]);\
+            OP(dst[4], 64 * src[4]);\
+            OP(dst[5], 64 * src[5]);\
+            OP(dst[6], 64 * src[6]);\
+            OP(dst[7], 64 * src[7]);\
             dst += stride;\
             src += stride;\
         }\
-- 
2.49.0

_______________________________________________
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".

[FFmpeg-devel] [PATCH 4/5] avcodec/mpegvideo_dec: Fix lowres=3 field select interlaced mpeg4 frame

[Michael Niedermayer]

Fixes: out of array read in the chroma plane
Fixes: 428034092/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_DEC_fuzzer-5582608941776896.test

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
 libavcodec/mpegvideo_dec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mpegvideo_dec.c b/libavcodec/mpegvideo_dec.c
index 4a54f6cd614..85e24c667e3 100644
--- a/libavcodec/mpegvideo_dec.c
+++ b/libavcodec/mpegvideo_dec.c
@@ -557,7 +557,7 @@ static av_always_inline void mpeg_motion_lowres(MpegEncContext *s,
     ptr_cr = ref_picture[2] + uvsrc_y * uvlinesize + uvsrc_x;
 
     if ((unsigned) src_x > FFMAX( h_edge_pos - (!!sx) - 2 * block_s,       0) || uvsrc_y<0 ||
-        (unsigned) src_y > FFMAX((v_edge_pos >> field_based) - (!!sy) - FFMAX(h, hc<<s->chroma_y_shift), 0)) {
+        (unsigned) src_y > FFMAX((v_edge_pos >> field_based) - (!!sy) - FFMAX(h, field_select + hc<<s->chroma_y_shift), 0)) {
         s->vdsp.emulated_edge_mc(s->sc.edge_emu_buffer, ptr_y,
                                  linesize >> field_based, linesize >> field_based,
                                  17, 17 + field_based,
-- 
2.49.0

_______________________________________________
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".

[FFmpeg-devel] [PATCH 5/5] avcodec/osq: Fix 32bit sample overflow

[Michael Niedermayer]

Fixes: signed integer overflow: 2147483565 + 128 cannot be represented in type 'int'
Fixes: 428055715/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6358069900804096

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
 libavcodec/osq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/osq.c b/libavcodec/osq.c
index 76090aa8d07..1d99ab32451 100644
--- a/libavcodec/osq.c
+++ b/libavcodec/osq.c
@@ -390,7 +390,7 @@ static int osq_decode_block(AVCodecContext *avctx, AVFrame *frame)
             int32_t *src = s->decode_buffer[ch] + OFFSET;
 
             for (int n = 0; n < nb_samples; n++)
-                dst[n] = av_clip_uint8(src[n] + 0x80);
+                dst[n] = av_clip_uint8(src[n] + 0x80ll);
         }
         break;
     case AV_SAMPLE_FMT_S16P:
-- 
2.49.0

_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH 1/5] avformat/flvdec: Check for EOF in AudioPacketTypeMultichannelConfig

[Timo Rothenpieler]

On 7/13/2025 3:10 AM, Michael Niedermayer wrote:
> Fixes: Infinite loop
> Fixes: 427538726/clusterfuzz-testcase-minimized-ffmpeg_dem_FLV_fuzzer-6582567304495104
> 
> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> ---
>   libavformat/flvdec.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index ac681954cb7..a4fa0157512 100644
> --- a/libavformat/flvdec.c
> +++ b/libavformat/flvdec.c
> @@ -1715,6 +1715,9 @@ retry_duration:
>   
>                   av_log(s, AV_LOG_DEBUG, "Set channel data from MultiChannel info.\n");
>   
> +                if (avio_feof(s->pb))
> +                    return AVERROR_EOF;
> +
>                   goto next_track;
>               }
>           } else if (stream_type == FLV_STREAM_TYPE_VIDEO) {

I don't think just returning from here is correct.
The goto next_track right after it already checks for EOF.
I do not see how between here and the eof check there there'd be any way 
to infinite loop.

It returns FFERROR_REDO there, which is important to drain queued up 
packages.
The next time a call hits flv_read_packet will then immediately return 
AVERROR_EOF, since it's one of the first things the function checks.

So just throwing in a random AVERROR_EOF there seems incorrect to me, 
and is only hiding an actual issue elsewhere, if there is one.
_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH 4/5] avcodec/mpegvideo_dec: Fix lowres=3 field select interlaced mpeg4 frame

[Andreas Rheinhardt]

Michael Niedermayer:
> Fixes: out of array read in the chroma plane
> Fixes: 428034092/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_DEC_fuzzer-5582608941776896.test
> 
> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> ---
>  libavcodec/mpegvideo_dec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/mpegvideo_dec.c b/libavcodec/mpegvideo_dec.c
> index 4a54f6cd614..85e24c667e3 100644
> --- a/libavcodec/mpegvideo_dec.c
> +++ b/libavcodec/mpegvideo_dec.c
> @@ -557,7 +557,7 @@ static av_always_inline void mpeg_motion_lowres(MpegEncContext *s,
>      ptr_cr = ref_picture[2] + uvsrc_y * uvlinesize + uvsrc_x;
>  
>      if ((unsigned) src_x > FFMAX( h_edge_pos - (!!sx) - 2 * block_s,       0) || uvsrc_y<0 ||
> -        (unsigned) src_y > FFMAX((v_edge_pos >> field_based) - (!!sy) - FFMAX(h, hc<<s->chroma_y_shift), 0)) {
> +        (unsigned) src_y > FFMAX((v_edge_pos >> field_based) - (!!sy) - FFMAX(h, field_select + hc<<s->chroma_y_shift), 0)) {
>          s->vdsp.emulated_edge_mc(s->sc.edge_emu_buffer, ptr_y,
>                                   linesize >> field_based, linesize >> field_based,
>                                   17, 17 + field_based,

Is lowres actually used for mpegvideo-decoders at all (in 2025)?

- Andreas

_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH 5/5] avcodec/osq: Fix 32bit sample overflow

[Andreas Rheinhardt]

Michael Niedermayer:
> Fixes: signed integer overflow: 2147483565 + 128 cannot be represented in type 'int'
> Fixes: 428055715/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6358069900804096
> 
> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> ---
>  libavcodec/osq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/osq.c b/libavcodec/osq.c
> index 76090aa8d07..1d99ab32451 100644
> --- a/libavcodec/osq.c
> +++ b/libavcodec/osq.c
> @@ -390,7 +390,7 @@ static int osq_decode_block(AVCodecContext *avctx, AVFrame *frame)
>              int32_t *src = s->decode_buffer[ch] + OFFSET;
>  
>              for (int n = 0; n < nb_samples; n++)
> -                dst[n] = av_clip_uint8(src[n] + 0x80);
> +                dst[n] = av_clip_uint8(src[n] + 0x80ll);
>          }
>          break;
>      case AV_SAMPLE_FMT_S16P:

Why do you use a 64bit intermediate instead of simply using unsigned
like we do everywhere else?

- Andreas

_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH 3/5] avcodec/h264chroma_template: Replace variable by constant in chroma mc

[Kieran Kunhya via ffmpeg-devel]

On Sun, 13 Jul 2025, 02:11 Michael Niedermayer, <michael@niedermayer.cc>
wrote:

> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> ---
>  libavcodec/h264chroma_template.c | 30 +++++++++++++++---------------
>  1 file changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/libavcodec/h264chroma_template.c
> b/libavcodec/h264chroma_template.c
> index b9d24f5a0cd..b20811a71ae 100644
> --- a/libavcodec/h264chroma_template.c
> +++ b/libavcodec/h264chroma_template.c
> @@ -54,7 +54,7 @@ static void FUNCC(OPNAME ## h264_chroma_mc1)(uint8_t
> *_dst /*align 8*/, const ui
>          }\
>      } else {\
>          for(i=0; i<h; i++){\
> -            OP(dst[0], (A*src[0]));\
> +            OP(dst[0], (64*src[0]));\
>              dst+= stride;\
>              src+= stride;\
>          }\
> @@ -91,8 +91,8 @@ static void FUNCC(OPNAME ## h264_chroma_mc2)(uint8_t
> *_dst /*align 8*/, const ui
>          }\
>      } else {\
>          for ( i = 0; i < h; i++){\
> -            OP(dst[0], A * src[0]);\
> -            OP(dst[1], A * src[1]);\
> +            OP(dst[0], 64 * src[0]);\
> +            OP(dst[1], 64 * src[1]);\
>              dst += stride;\
>              src += stride;\
>          }\
> @@ -134,10 +134,10 @@ static void FUNCC(OPNAME ## h264_chroma_mc4)(uint8_t
> *_dst /*align 8*/, const ui
>          }\
>      } else {\
>          for ( i = 0; i < h; i++){\
> -            OP(dst[0], A * src[0]);\
> -            OP(dst[1], A * src[1]);\
> -            OP(dst[2], A * src[2]);\
> -            OP(dst[3], A * src[3]);\
> +            OP(dst[0], 64 * src[0]);\
> +            OP(dst[1], 64 * src[1]);\
> +            OP(dst[2], 64 * src[2]);\
> +            OP(dst[3], 64 * src[3]);\
>              dst += stride;\
>              src += stride;\
>          }\
> @@ -187,14 +187,14 @@ static void FUNCC(OPNAME ## h264_chroma_mc8)(uint8_t
> *_dst /*align 8*/, const ui
>          }\
>      } else {\
>          for ( i = 0; i < h; i++){\
> -            OP(dst[0], A * src[0]);\
> -            OP(dst[1], A * src[1]);\
> -            OP(dst[2], A * src[2]);\
> -            OP(dst[3], A * src[3]);\
> -            OP(dst[4], A * src[4]);\
> -            OP(dst[5], A * src[5]);\
> -            OP(dst[6], A * src[6]);\
> -            OP(dst[7], A * src[7]);\
> +            OP(dst[0], 64 * src[0]);\
> +            OP(dst[1], 64 * src[1]);\
> +            OP(dst[2], 64 * src[2]);\
> +            OP(dst[3], 64 * src[3]);\
> +            OP(dst[4], 64 * src[4]);\
> +            OP(dst[5], 64 * src[5]);\
> +            OP(dst[6], 64 * src[6]);\
> +            OP(dst[7], 64 * src[7]);\
>              dst += stride;\
>              src += stride;\
>          }\
> --
> 2.49.0
>

Some explanation of what this is for would help.

Kieran

>
_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH 4/5] avcodec/mpegvideo_dec: Fix lowres=3 field select interlaced mpeg4 frame

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1853 bytes --]

On Sun, Jul 13, 2025 at 07:34:50PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: out of array read in the chroma plane
> > Fixes: 428034092/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_DEC_fuzzer-5582608941776896.test
> > 
> > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> > ---
> >  libavcodec/mpegvideo_dec.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/mpegvideo_dec.c b/libavcodec/mpegvideo_dec.c
> > index 4a54f6cd614..85e24c667e3 100644
> > --- a/libavcodec/mpegvideo_dec.c
> > +++ b/libavcodec/mpegvideo_dec.c
> > @@ -557,7 +557,7 @@ static av_always_inline void mpeg_motion_lowres(MpegEncContext *s,
> >      ptr_cr = ref_picture[2] + uvsrc_y * uvlinesize + uvsrc_x;
> >  
> >      if ((unsigned) src_x > FFMAX( h_edge_pos - (!!sx) - 2 * block_s,       0) || uvsrc_y<0 ||
> > -        (unsigned) src_y > FFMAX((v_edge_pos >> field_based) - (!!sy) - FFMAX(h, hc<<s->chroma_y_shift), 0)) {
> > +        (unsigned) src_y > FFMAX((v_edge_pos >> field_based) - (!!sy) - FFMAX(h, field_select + hc<<s->chroma_y_shift), 0)) {
> >          s->vdsp.emulated_edge_mc(s->sc.edge_emu_buffer, ptr_y,
> >                                   linesize >> field_based, linesize >> field_based,
> >                                   17, 17 + field_based,
> 
> Is lowres actually used for mpegvideo-decoders at all (in 2025)?

why not ?

Example: making thumbnails of videos.
If a video can be decoded in 2min instead of 3min that still allows to scan
it sooner for potential thumbnails

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH 5/5] avcodec/osq: Fix 32bit sample overflow

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1610 bytes --]

On Sun, Jul 13, 2025 at 07:37:06PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: signed integer overflow: 2147483565 + 128 cannot be represented in type 'int'
> > Fixes: 428055715/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6358069900804096
> > 
> > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> > ---
> >  libavcodec/osq.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/osq.c b/libavcodec/osq.c
> > index 76090aa8d07..1d99ab32451 100644
> > --- a/libavcodec/osq.c
> > +++ b/libavcodec/osq.c
> > @@ -390,7 +390,7 @@ static int osq_decode_block(AVCodecContext *avctx, AVFrame *frame)
> >              int32_t *src = s->decode_buffer[ch] + OFFSET;
> >  
> >              for (int n = 0; n < nb_samples; n++)
> > -                dst[n] = av_clip_uint8(src[n] + 0x80);
> > +                dst[n] = av_clip_uint8(src[n] + 0x80ll);
> >          }
> >          break;
> >      case AV_SAMPLE_FMT_S16P:
> 
> Why do you use a 64bit intermediate instead of simply using unsigned
> like we do everywhere else?

we can use an unsigned but the intend was to clip obviously
and while the C code uses 64bit the optimized asm should not
need that

Iam happy to change it to unsigned if you prefer

[...]

thx

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH 1/5] avformat/flvdec: Check for EOF in AudioPacketTypeMultichannelConfig

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2347 bytes --]

On Sun, Jul 13, 2025 at 01:42:28PM +0200, Timo Rothenpieler wrote:
> On 7/13/2025 3:10 AM, Michael Niedermayer wrote:
> > Fixes: Infinite loop
> > Fixes: 427538726/clusterfuzz-testcase-minimized-ffmpeg_dem_FLV_fuzzer-6582567304495104
> > 
> > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> > ---
> >   libavformat/flvdec.c | 3 +++
> >   1 file changed, 3 insertions(+)
> > 
> > diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> > index ac681954cb7..a4fa0157512 100644
> > --- a/libavformat/flvdec.c
> > +++ b/libavformat/flvdec.c
> > @@ -1715,6 +1715,9 @@ retry_duration:
> >                   av_log(s, AV_LOG_DEBUG, "Set channel data from MultiChannel info.\n");
> > +                if (avio_feof(s->pb))
> > +                    return AVERROR_EOF;
> > +
> >                   goto next_track;
> >               }
> >           } else if (stream_type == FLV_STREAM_TYPE_VIDEO) {
> 
> I don't think just returning from here is correct.
> The goto next_track right after it already checks for EOF.

> I do not see how between here and the eof check there there'd be any way to
> infinite loop.

avio_skip() with a negative value will reset the EOF flag


> 
> It returns FFERROR_REDO there, which is important to drain queued up
> packages.

I think the state becomes corrupted once it reads into EOF
that is the size accounting goes "oops" as the code keeps running
things that read and keeps accounting for these reads but in reality
nothing is read as its at EOF
and then it seeks back all these "not reads" and thats where it hits the
infinite loop as theres a mismatch what the code thinks it moved forward
and what it actually moved forward.
Thats how it looked to me at least, i have not verified every step of this

ill mail you the testcase, then you can check if my analysis is right
and fix the code in a way that can recover queued packets in such truncated
packet at EOF case.
Also please make sure its not forgotten that whatever fix this gets is backported

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Give a rich man 100$ and he will turn it into 1000$.
Give a poor man 1000$ and he will spend it.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH 1/5] avformat/flvdec: Check for EOF in AudioPacketTypeMultichannelConfig

[Timo Rothenpieler]

On 7/14/2025 9:21 PM, Michael Niedermayer wrote:
> On Sun, Jul 13, 2025 at 01:42:28PM +0200, Timo Rothenpieler wrote:
>> On 7/13/2025 3:10 AM, Michael Niedermayer wrote:
>>> Fixes: Infinite loop
>>> Fixes: 427538726/clusterfuzz-testcase-minimized-ffmpeg_dem_FLV_fuzzer-6582567304495104
>>>
>>> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>>> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
>>> ---
>>>    libavformat/flvdec.c | 3 +++
>>>    1 file changed, 3 insertions(+)
>>>
>>> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
>>> index ac681954cb7..a4fa0157512 100644
>>> --- a/libavformat/flvdec.c
>>> +++ b/libavformat/flvdec.c
>>> @@ -1715,6 +1715,9 @@ retry_duration:
>>>                    av_log(s, AV_LOG_DEBUG, "Set channel data from MultiChannel info.\n");
>>> +                if (avio_feof(s->pb))
>>> +                    return AVERROR_EOF;
>>> +
>>>                    goto next_track;
>>>                }
>>>            } else if (stream_type == FLV_STREAM_TYPE_VIDEO) {
>>
>> I don't think just returning from here is correct.
>> The goto next_track right after it already checks for EOF.
> 
>> I do not see how between here and the eof check there there'd be any way to
>> infinite loop.
> 
> avio_skip() with a negative value will reset the EOF flag
> 
> 
>>
>> It returns FFERROR_REDO there, which is important to drain queued up
>> packages.
> 
> I think the state becomes corrupted once it reads into EOF
> that is the size accounting goes "oops" as the code keeps running
> things that read and keeps accounting for these reads but in reality
> nothing is read as its at EOF
> and then it seeks back all these "not reads" and thats where it hits the
> infinite loop as theres a mismatch what the code thinks it moved forward
> and what it actually moved forward.
> Thats how it looked to me at least, i have not verified every step of this
> 
> ill mail you the testcase, then you can check if my analysis is right
> and fix the code in a way that can recover queued packets in such truncated
> packet at EOF case.
> Also please make sure its not forgotten that whatever fix this gets is backported

Yeah, I can have a look at it.
Probably the size calculation needs fixed then. But as long as the 
function itself ever returns, which it should by the looks of it, the 
size calculation becomes irrelevant since an EOF check is the first 
thing it does.
_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH 1/5] avformat/flvdec: Check for EOF in AudioPacketTypeMultichannelConfig

[Timo Rothenpieler]

[-- Attachment #1: Type: text/plain, Size: 2451 bytes --]

On 7/14/2025 9:21 PM, Michael Niedermayer wrote:
> On Sun, Jul 13, 2025 at 01:42:28PM +0200, Timo Rothenpieler wrote:
>> On 7/13/2025 3:10 AM, Michael Niedermayer wrote:
>>> Fixes: Infinite loop
>>> Fixes: 427538726/clusterfuzz-testcase-minimized-ffmpeg_dem_FLV_fuzzer-6582567304495104
>>>
>>> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>>> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
>>> ---
>>>    libavformat/flvdec.c | 3 +++
>>>    1 file changed, 3 insertions(+)
>>>
>>> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
>>> index ac681954cb7..a4fa0157512 100644
>>> --- a/libavformat/flvdec.c
>>> +++ b/libavformat/flvdec.c
>>> @@ -1715,6 +1715,9 @@ retry_duration:
>>>                    av_log(s, AV_LOG_DEBUG, "Set channel data from MultiChannel info.\n");
>>> +                if (avio_feof(s->pb))
>>> +                    return AVERROR_EOF;
>>> +
>>>                    goto next_track;
>>>                }
>>>            } else if (stream_type == FLV_STREAM_TYPE_VIDEO) {
>>
>> I don't think just returning from here is correct.
>> The goto next_track right after it already checks for EOF.
> 
>> I do not see how between here and the eof check there there'd be any way to
>> infinite loop.
> 
> avio_skip() with a negative value will reset the EOF flag
> 
> 
>>
>> It returns FFERROR_REDO there, which is important to drain queued up
>> packages.
> 
> I think the state becomes corrupted once it reads into EOF
> that is the size accounting goes "oops" as the code keeps running
> things that read and keeps accounting for these reads but in reality
> nothing is read as its at EOF
> and then it seeks back all these "not reads" and thats where it hits the
> infinite loop as theres a mismatch what the code thinks it moved forward
> and what it actually moved forward.
> Thats how it looked to me at least, i have not verified every step of this
> 
> ill mail you the testcase, then you can check if my analysis is right
> and fix the code in a way that can recover queued packets in such truncated
> packet at EOF case.
> Also please make sure its not forgotten that whatever fix this gets is backported
I'm unable to reproduce any infinite loops, even with the sample.
But the code there definitely is sub-optimal, given the seek can go the 
wrong way, and even when going the right way can potentially reset the 
EOF flag.

Proposed patch is attached.

[-- Attachment #2: 0001-avformat-flvdec-don-t-skip-backwards-or-at-EOF.patch --]
[-- Type: text/plain, Size: 1150 bytes --]

From 7ff394e1ecab504a4cb0fda4bd0f25d88ee4f6fe Mon Sep 17 00:00:00 2001
From: Timo Rothenpieler <timo@rothenpieler.org>
Date: Mon, 14 Jul 2025 21:54:35 +0200
Subject: [PATCH] avformat/flvdec: don't skip backwards or at EOF

---
 libavformat/flvdec.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index b90ed34b1c..de5e688822 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -1860,8 +1860,16 @@ retry_duration:
 next_track:
         if (track_size) {
             av_log(s, AV_LOG_WARNING, "Track size mismatch: %d!\n", track_size);
-            avio_skip(s->pb, track_size);
-            size -= track_size;
+            if (!avio_feof(s->pb)) {
+                if (track_size > 0) {
+                    avio_skip(s->pb, track_size);
+                    size -= track_size;
+                } else {
+                    /* We have somehow read more than the track had to offer, leave and re-sync */
+                    ret = FFERROR_REDO;
+                    goto leave;
+                }
+            }
         }
 
         if (!size)
-- 
2.49.0


[-- Attachment #3: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH 1/5] avformat/flvdec: Check for EOF in AudioPacketTypeMultichannelConfig

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 4575 bytes --]

On Mon, Jul 14, 2025 at 10:00:19PM +0200, Timo Rothenpieler wrote:
> On 7/14/2025 9:21 PM, Michael Niedermayer wrote:
> > On Sun, Jul 13, 2025 at 01:42:28PM +0200, Timo Rothenpieler wrote:
> > > On 7/13/2025 3:10 AM, Michael Niedermayer wrote:
> > > > Fixes: Infinite loop
> > > > Fixes: 427538726/clusterfuzz-testcase-minimized-ffmpeg_dem_FLV_fuzzer-6582567304495104
> > > > 
> > > > Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> > > > ---
> > > >    libavformat/flvdec.c | 3 +++
> > > >    1 file changed, 3 insertions(+)
> > > > 
> > > > diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> > > > index ac681954cb7..a4fa0157512 100644
> > > > --- a/libavformat/flvdec.c
> > > > +++ b/libavformat/flvdec.c
> > > > @@ -1715,6 +1715,9 @@ retry_duration:
> > > >                    av_log(s, AV_LOG_DEBUG, "Set channel data from MultiChannel info.\n");
> > > > +                if (avio_feof(s->pb))
> > > > +                    return AVERROR_EOF;
> > > > +
> > > >                    goto next_track;
> > > >                }
> > > >            } else if (stream_type == FLV_STREAM_TYPE_VIDEO) {
> > > 
> > > I don't think just returning from here is correct.
> > > The goto next_track right after it already checks for EOF.
> > 
> > > I do not see how between here and the eof check there there'd be any way to
> > > infinite loop.
> > 
> > avio_skip() with a negative value will reset the EOF flag
> > 
> > 
> > > 
> > > It returns FFERROR_REDO there, which is important to drain queued up
> > > packages.
> > 
> > I think the state becomes corrupted once it reads into EOF
> > that is the size accounting goes "oops" as the code keeps running
> > things that read and keeps accounting for these reads but in reality
> > nothing is read as its at EOF
> > and then it seeks back all these "not reads" and thats where it hits the
> > infinite loop as theres a mismatch what the code thinks it moved forward
> > and what it actually moved forward.
> > Thats how it looked to me at least, i have not verified every step of this
> > 
> > ill mail you the testcase, then you can check if my analysis is right
> > and fix the code in a way that can recover queued packets in such truncated
> > packet at EOF case.
> > Also please make sure its not forgotten that whatever fix this gets is backported
> I'm unable to reproduce any infinite loops, even with the sample.
> But the code there definitely is sub-optimal, given the seek can go the
> wrong way, and even when going the right way can potentially reset the EOF
> flag.
> 
> Proposed patch is attached.

>  flvdec.c |   12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 681dde0e1e99d4e0cee0f4eec92eb3dc229a25d4  0001-avformat-flvdec-don-t-skip-backwards-or-at-EOF.patch
> From 7ff394e1ecab504a4cb0fda4bd0f25d88ee4f6fe Mon Sep 17 00:00:00 2001
> From: Timo Rothenpieler <timo@rothenpieler.org>
> Date: Mon, 14 Jul 2025 21:54:35 +0200
> Subject: [PATCH] avformat/flvdec: don't skip backwards or at EOF
> 
> ---
>  libavformat/flvdec.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index b90ed34b1c..de5e688822 100644
> --- a/libavformat/flvdec.c
> +++ b/libavformat/flvdec.c
> @@ -1860,8 +1860,16 @@ retry_duration:
>  next_track:
>          if (track_size) {
>              av_log(s, AV_LOG_WARNING, "Track size mismatch: %d!\n", track_size);
> -            avio_skip(s->pb, track_size);
> -            size -= track_size;
> +            if (!avio_feof(s->pb)) {
> +                if (track_size > 0) {
> +                    avio_skip(s->pb, track_size);
> +                    size -= track_size;
> +                } else {
> +                    /* We have somehow read more than the track had to offer, leave and re-sync */
> +                    ret = FFERROR_REDO;
> +                    goto leave;
> +                }
> +            }
>          }

i think this is not correct

if a corrupted packet pushes you 1gb forward into EOF you must seek back
and by extension (if that logic is correct) we also can require a seek back
without EOF

I have not deeply analyzed the flv code today, so i may miss something

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH 1/5] avformat/flvdec: Check for EOF in AudioPacketTypeMultichannelConfig

[Timo Rothenpieler]

On 7/15/2025 12:01 AM, Michael Niedermayer wrote:
> On Mon, Jul 14, 2025 at 10:00:19PM +0200, Timo Rothenpieler wrote:
>> On 7/14/2025 9:21 PM, Michael Niedermayer wrote:
>>> On Sun, Jul 13, 2025 at 01:42:28PM +0200, Timo Rothenpieler wrote:
>>>> On 7/13/2025 3:10 AM, Michael Niedermayer wrote:
>>>>> Fixes: Infinite loop
>>>>> Fixes: 427538726/clusterfuzz-testcase-minimized-ffmpeg_dem_FLV_fuzzer-6582567304495104
>>>>>
>>>>> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>>>>> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
>>>>> ---
>>>>>     libavformat/flvdec.c | 3 +++
>>>>>     1 file changed, 3 insertions(+)
>>>>>
>>>>> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
>>>>> index ac681954cb7..a4fa0157512 100644
>>>>> --- a/libavformat/flvdec.c
>>>>> +++ b/libavformat/flvdec.c
>>>>> @@ -1715,6 +1715,9 @@ retry_duration:
>>>>>                     av_log(s, AV_LOG_DEBUG, "Set channel data from MultiChannel info.\n");
>>>>> +                if (avio_feof(s->pb))
>>>>> +                    return AVERROR_EOF;
>>>>> +
>>>>>                     goto next_track;
>>>>>                 }
>>>>>             } else if (stream_type == FLV_STREAM_TYPE_VIDEO) {
>>>>
>>>> I don't think just returning from here is correct.
>>>> The goto next_track right after it already checks for EOF.
>>>
>>>> I do not see how between here and the eof check there there'd be any way to
>>>> infinite loop.
>>>
>>> avio_skip() with a negative value will reset the EOF flag
>>>
>>>
>>>>
>>>> It returns FFERROR_REDO there, which is important to drain queued up
>>>> packages.
>>>
>>> I think the state becomes corrupted once it reads into EOF
>>> that is the size accounting goes "oops" as the code keeps running
>>> things that read and keeps accounting for these reads but in reality
>>> nothing is read as its at EOF
>>> and then it seeks back all these "not reads" and thats where it hits the
>>> infinite loop as theres a mismatch what the code thinks it moved forward
>>> and what it actually moved forward.
>>> Thats how it looked to me at least, i have not verified every step of this
>>>
>>> ill mail you the testcase, then you can check if my analysis is right
>>> and fix the code in a way that can recover queued packets in such truncated
>>> packet at EOF case.
>>> Also please make sure its not forgotten that whatever fix this gets is backported
>> I'm unable to reproduce any infinite loops, even with the sample.
>> But the code there definitely is sub-optimal, given the seek can go the
>> wrong way, and even when going the right way can potentially reset the EOF
>> flag.
>>
>> Proposed patch is attached.
> 
>>   flvdec.c |   12 ++++++++++--
>>   1 file changed, 10 insertions(+), 2 deletions(-)
>> 681dde0e1e99d4e0cee0f4eec92eb3dc229a25d4  0001-avformat-flvdec-don-t-skip-backwards-or-at-EOF.patch
>>  From 7ff394e1ecab504a4cb0fda4bd0f25d88ee4f6fe Mon Sep 17 00:00:00 2001
>> From: Timo Rothenpieler <timo@rothenpieler.org>
>> Date: Mon, 14 Jul 2025 21:54:35 +0200
>> Subject: [PATCH] avformat/flvdec: don't skip backwards or at EOF
>>
>> ---
>>   libavformat/flvdec.c | 12 ++++++++++--
>>   1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
>> index b90ed34b1c..de5e688822 100644
>> --- a/libavformat/flvdec.c
>> +++ b/libavformat/flvdec.c
>> @@ -1860,8 +1860,16 @@ retry_duration:
>>   next_track:
>>           if (track_size) {
>>               av_log(s, AV_LOG_WARNING, "Track size mismatch: %d!\n", track_size);
>> -            avio_skip(s->pb, track_size);
>> -            size -= track_size;
>> +            if (!avio_feof(s->pb)) {
>> +                if (track_size > 0) {
>> +                    avio_skip(s->pb, track_size);
>> +                    size -= track_size;
>> +                } else {
>> +                    /* We have somehow read more than the track had to offer, leave and re-sync */
>> +                    ret = FFERROR_REDO;
>> +                    goto leave;
>> +                }
>> +            }
>>           }
> 
> i think this is not correct
> 
> if a corrupted packet pushes you 1gb forward into EOF you must seek back
> and by extension (if that logic is correct) we also can require a seek back
> without EOF

If a corrupt package makes this avio_skip skip gigabytes ahead, reading 
will just EOF anyway a few lines down (or continue and try to re-sync 
from there, if the file is big enough).

The main problem here is that avio_skip, which just calls avio_seek 
internally, can reset the EOF state.
So the main thing to guard against here is seeking backwards, since that 
can lead to an infinite loop if it seeks back just right and ends up at 
the same corrupted spot.

So this change makes sure that if the file is already EOF, no 
seeking/skipping is done, and additionally, even if not EOF, it'll only 
ever skip forward, which would instantly lead to an EOF if far enough.

If a backwards seek has been calculated, it'll now also immediately 
abort parsing, since that can only mean that garbage was read.
So it leaves and either aborts or tries to re-sync.

> I have not deeply analyzed the flv code today, so i may miss something
> 
> thx
> 
> [...]
> 
> 
> _______________________________________________
> 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".

_______________________________________________
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".