On Mon, Aug 11, 2025 at 08:04:02PM +0800, Zhao Zhili wrote:
> 
> 
> > On Aug 11, 2025, at 18:51, Michael Niedermayer <michael@niedermayer.cc> wrote:
> > 
> > On Mon, Aug 11, 2025 at 11:37:55AM +0300, quink wrote:
> >> PR #20212 opened by quink
> >> URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20212
> >> Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20212.patch
> >> 
> >> A set of files begins with the following byte sequence.
> >> 
> >> 00000000  4c 41 4d 45 33 2e 31 30  30 aa aa aa aa aa aa aa  |LAME3.100.......|
> >> 00000010  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
> >> *
> >> 
> >> It seems they are encoded with lame, but missing header bytes at the
> >> beginning.
> >> 
> >> Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
> >> 
> >> 
> >> From e24f7b8d0fbc4295b3dfc9832d7b552086f45ff0 Mon Sep 17 00:00:00 2001
> >> From: Zhao Zhili <zhilizhao@tencent.com>
> >> Date: Mon, 11 Aug 2025 15:23:36 +0800
> >> Subject: [PATCH] avformat/mp3dec: Workaround mp3 detection failure
> >> 
> >> A set of files begins with the following byte sequence.
> >> 
> >> 00000000  4c 41 4d 45 33 2e 31 30  30 aa aa aa aa aa aa aa  |LAME3.100.......|
> >> 00000010  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
> >> *
> >> 
> >> It seems they are encoded with lame, but missing header bytes at the
> >> beginning.
> >> 
> >> Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
> >> ---
> >> libavformat/mp3dec.c | 7 +++++--
> >> 1 file changed, 5 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> >> index 31eeb68ebb..fd692a9c76 100644
> >> --- a/libavformat/mp3dec.c
> >> +++ b/libavformat/mp3dec.c
> >> @@ -121,8 +121,11 @@ static int mp3_read_probe(const AVProbeData *p)
> >>     // issues with MPEG-files!
> >>     if   (first_frames>=7) return AVPROBE_SCORE_EXTENSION + 1;
> >>     else if (max_frames>200 && p->buf_size < 2*max_framesizes)return AVPROBE_SCORE_EXTENSION;
> >> -    else if (max_frames>=4 && p->buf_size < 2*max_framesizes) return AVPROBE_SCORE_EXTENSION / 2;
> >> -    else if (ff_id3v2_match(buf0, ID3v2_DEFAULT_MAGIC) && 2*ff_id3v2_tag_len(buf0) >= p->buf_size)
> >> +    else if (max_frames>=4 && p->buf_size < 2*max_framesizes) {
> >> +        if (!memcmp(p->buf, "LAME3.100", sizeof("LAME3.100") - 1))
> >> +            return AVPROBE_SCORE_EXTENSION - 2;
> >> +        return AVPROBE_SCORE_EXTENSION / 2;
> >> +    } else if (ff_id3v2_match(buf0, ID3v2_DEFAULT_MAGIC) && 2*ff_id3v2_tag_len(buf0) >= p->buf_size)
> > 
> > why is this needed ?
> > 
> > Naively i would expect that the probe code would detect a mp3 stream like this
> > based on max_frames
> > why does that fail ?
> > as what is teh stream detected instead ?
> > maybe whatever detects it, is wrong instead and can be improved by not missdetecting it
> 
> probe just report invalid data:
> 
> Probing mp3 score:25 size:2048
> Probing h263 score:25 size:4096
> Probing mp3 score:25 size:4096
> Probing h263 score:25 size:8192
> Probing mp3 score:25 size:8192
> Probing h263 score:25 size:16384
> Probing mp3 score:25 size:16384
> Probing h263 score:25 size:20160
> Probing mp3 score:25 size:20160
> Probing h263 score:25 size:20160
> Probing mp3 score:25 size:20160
> [AVIOContext @ 0x127f04ac0] Statistics: 20160 bytes read, 0 seeks
> 
> 3ac558a6ebf467b42e4a42be3014c6c5.mp3: Invalid data found when processing input
> 
> These files are only 1 to 2 seconds contains a single English word. I think the size of file
> is one of the reason of failed to detect.

they are valid h263 ?

if not, can teh h263 probe test be improved so they are not detected as h263?

thx

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

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu