[FFmpeg-devel] lavf/mp3dec: fix mp3 file probe fail

Submitted by tiejun.peng on Dec. 6, 2017, 9:27 a.m.

Details

Message ID 1512552463-1733-1-git-send-email-tiejun.peng@foxmail.com
State New
Headers show

Commit Message

tiejun.peng Dec. 6, 2017, 9:27 a.m.
fix #6895: https://trac.ffmpeg.org/ticket/6895
stream:https://trac.ffmpeg.org/attachment/ticket/6895/music_mp3

Signed-off-by: tiejun.peng <tiejun.peng@foxmail.com>
---
 libavformat/mp3dec.c | 4 ++++
 1 file changed, 4 insertions(+)

Comments

Carl Eugen Hoyos Dec. 6, 2017, 4 p.m.
2017-12-06 10:27 GMT+01:00 tiejun.peng <tiejun.peng@foxmail.com>:
> fix #6895: https://trac.ffmpeg.org/ticket/6895

The patch breaks issue3327-libc-2.17.so

> stream:https://trac.ffmpeg.org/attachment/ticket/6895/music_mp3

Which player does something useful with this file?

I am not saying there can't be an issue, but not detecting
severely broken files does not sound necessarily wrong
to me.

Carl Eugen
tiejun.peng Dec. 7, 2017, 9:32 a.m.
Playback of the mp3 file sounds very good with VLC media player 2.2.2 Weatherwax (revision 2.2.2-0-g6259d80)


Tiejun Peng

------------------ Original ------------------
From:  "Carl Eugen Hoyos";<ceffmpeg@gmail.com>;

Send time: Thursday, Dec 7, 2017 0:00 AM
To: "FFmpeg development discussions and patches"<ffmpeg-devel@ffmpeg.org>; 

Subject:  Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: fix mp3 file probe fail



2017-12-06 10:27 GMT+01:00 tiejun.peng <tiejun.peng@foxmail.com>:
> fix #6895: https://trac.ffmpeg.org/ticket/6895


The patch breaks issue3327-libc-2.17.so

> stream:https://trac.ffmpeg.org/attachment/ticket/6895/music_mp3


Which player does something useful with this file?

I am not saying there can't be an issue, but not detecting
severely broken files does not sound necessarily wrong
to me.

Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
wm4 Dec. 7, 2017, 1:16 p.m.
On Wed,  6 Dec 2017 17:27:43 +0800
"tiejun.peng" <tiejun.peng@foxmail.com> wrote:

> fix #6895: https://trac.ffmpeg.org/ticket/6895
> stream:https://trac.ffmpeg.org/attachment/ticket/6895/music_mp3
> 
> Signed-off-by: tiejun.peng <tiejun.peng@foxmail.com>
> ---
>  libavformat/mp3dec.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> index a76fe32..286eb68 100644
> --- a/libavformat/mp3dec.c
> +++ b/libavformat/mp3dec.c
> @@ -73,6 +73,7 @@ static int mp3_read_probe(AVProbeData *p)
>      int frames, ret;
>      uint32_t header;
>      const uint8_t *buf, *buf0, *buf2, *end;
> +    int match_size = 0;
>  
>      buf0 = p->buf;
>      end = p->buf + p->buf_size - sizeof(uint32_t);
> @@ -92,6 +93,7 @@ static int mp3_read_probe(AVProbeData *p)
>              if (ret != 0)
>                  break;
>              buf2 += h.frame_size;
> +            match_size += h.frame_size;
>          }
>          max_frames = FFMAX(max_frames, frames);
>          if(buf == buf0) {
> @@ -104,6 +106,8 @@ static int mp3_read_probe(AVProbeData *p)
>      // issues with MPEG-files!
>      if   (first_frames>=7) return AVPROBE_SCORE_EXTENSION + 1;
>      else if(max_frames>200)return AVPROBE_SCORE_EXTENSION;
> +    // over 50% of probe size is valid
> +    else if (p->buf_size > 10000 && match_size > (p->buf_size/2)) return AVPROBE_SCORE_EXTENSION;
>      else if(max_frames>=4 && max_frames >= p->buf_size/10000) return AVPROBE_SCORE_EXTENSION / 2;
>      else if(ff_id3v2_match(buf0, ID3v2_DEFAULT_MAGIC) && 2*ff_id3v2_tag_len(buf0) >= p->buf_size)
>                             return p->buf_size < PROBE_BUF_MAX ? AVPROBE_SCORE_EXTENSION / 4 : AVPROBE_SCORE_EXTENSION - 2;

That doesn't necessarily affect whether this patch should be applied,
but: I think this mp4 probe should really be cleaned up. It's one of
the most complex probe functions, and it doesn't even work correctly.
It still detects some ELF files as mp3 (or mp1/2), for example.
tiejun.peng Dec. 8, 2017, 4:13 p.m.
can this commit  be merged into master?
------------------ Original ------------------
From:  "Tiejun.Peng";<tiejun.peng@foxmail.com>;

Send time: Thursday, Dec 7, 2017 5:32 PM
To: "FFmpeg development discussions and patches"<ffmpeg-devel@ffmpeg.org>; 

Subject:  Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: fix mp3 file probe fail



Playback of the mp3 file sounds very good with VLC media player 2.2.2 Weatherwax (revision 2.2.2-0-g6259d80)


Tiejun Peng

------------------ Original ------------------
From:  "Carl Eugen Hoyos";<ceffmpeg@gmail.com>;

Send time: Thursday, Dec 7, 2017 0:00 AM
To: "FFmpeg development discussions and patches"<ffmpeg-devel@ffmpeg.org>; 

Subject:  Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: fix mp3 file probe fail



2017-12-06 10:27 GMT+01:00 tiejun.peng <tiejun.peng@foxmail.com>:
> fix #6895: https://trac.ffmpeg.org/ticket/6895


The patch breaks issue3327-libc-2.17.so

> stream:https://trac.ffmpeg.org/attachment/ticket/6895/music_mp3


Which player does something useful with this file?

I am not saying there can't be an issue, but not detecting
severely broken files does not sound necessarily wrong
to me.

Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Carl Eugen Hoyos Dec. 8, 2017, 4:21 p.m.
2017-12-08 17:13 GMT+01:00 Tiejun.Peng <tiejun.peng@foxmail.com>:
> can this commit  be merged into master?

Given that it would introduce a regression, I guess not.

More important though: I cannot reproduce successful
playback with vlc - can you provide the output file that
vlc produces for you?

Please do not top-post here, Carl Eugen
tiejun.peng Dec. 8, 2017, 5:20 p.m.
sorry , i can't  produce the output file of  pcm with vlc .
below link  is the vlc record file, maybe it is useful for you. i try to play it with ffmpeg is ok.

https://trac.ffmpeg.org/attachment/ticket/6895/vlc-record-2017-12-09-01h02m32s-music_mp3-.mp3




------------------ Original ------------------
From:  "Carl Eugen Hoyos";<ceffmpeg@gmail.com>;

Send time: Saturday, Dec 9, 2017 0:21 AM
To: "FFmpeg development discussions and patches"<ffmpeg-devel@ffmpeg.org>; 

Subject:  Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: fix mp3 file probe fail



2017-12-08 17:13 GMT+01:00 Tiejun.Peng <tiejun.peng@foxmail.com>:
> can this commit  be merged into master?


Given that it would introduce a regression, I guess not.

More important though: I cannot reproduce successful
playback with vlc - can you provide the output file that
vlc produces for you?

Please do not top-post here, Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
tiejun.peng Dec. 8, 2017, 5:45 p.m.
i agree with you. too much  experience value in condition of Judgement  like this:
"else if(max_frames>=4 && max_frames >= p->buf_size/10000)".
 why  it is the value ? it is hard to known. 
maybe  the work of cleaned up  need a few days, so i just  repair of the probe.


------------------ Original ------------------
From:  "wm4";<nfxjfg@googlemail.com>;

Send time: Thursday, Dec 7, 2017 9:16 PM
To: "ffmpeg-devel"<ffmpeg-devel@ffmpeg.org>; 

Subject:  Re: [FFmpeg-devel] [PATCH] lavf/mp3dec: fix mp3 file probe fail



On Wed,  6 Dec 2017 17:27:43 +0800
"tiejun.peng" <tiejun.peng@foxmail.com> wrote:

> fix #6895: https://trac.ffmpeg.org/ticket/6895

> stream:https://trac.ffmpeg.org/attachment/ticket/6895/music_mp3

> 

> Signed-off-by: tiejun.peng <tiejun.peng@foxmail.com>

> ---

>  libavformat/mp3dec.c | 4 ++++

>  1 file changed, 4 insertions(+)

> 

> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c

> index a76fe32..286eb68 100644

> --- a/libavformat/mp3dec.c

> +++ b/libavformat/mp3dec.c

> @@ -73,6 +73,7 @@ static int mp3_read_probe(AVProbeData *p)

>      int frames, ret;

>      uint32_t header;

>      const uint8_t *buf, *buf0, *buf2, *end;

> +    int match_size = 0;

>  

>      buf0 = p->buf;

>      end = p->buf + p->buf_size - sizeof(uint32_t);

> @@ -92,6 +93,7 @@ static int mp3_read_probe(AVProbeData *p)

>              if (ret != 0)

>                  break;

>              buf2 += h.frame_size;

> +            match_size += h.frame_size;

>          }

>          max_frames = FFMAX(max_frames, frames);

>          if(buf == buf0) {

> @@ -104,6 +106,8 @@ static int mp3_read_probe(AVProbeData *p)

>      // issues with MPEG-files!

>      if   (first_frames>=7) return AVPROBE_SCORE_EXTENSION + 1;

>      else if(max_frames>200)return AVPROBE_SCORE_EXTENSION;

> +    // over 50% of probe size is valid

> +    else if (p->buf_size > 10000 && match_size > (p->buf_size/2)) return AVPROBE_SCORE_EXTENSION;

>      else if(max_frames>=4 && max_frames >= p->buf_size/10000) return AVPROBE_SCORE_EXTENSION / 2;

>      else if(ff_id3v2_match(buf0, ID3v2_DEFAULT_MAGIC) && 2*ff_id3v2_tag_len(buf0) >= p->buf_size)

>                             return p->buf_size < PROBE_BUF_MAX ? AVPROBE_SCORE_EXTENSION / 4 : AVPROBE_SCORE_EXTENSION - 2;


That doesn't necessarily affect whether this patch should be applied,
but: I think this mp4 probe should really be cleaned up. It's one of
the most complex probe functions, and it doesn't even work correctly.
It still detects some ELF files as mp3 (or mp1/2), for example.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Carl Eugen Hoyos Dec. 8, 2017, 5:51 p.m.
2017-12-08 18:45 GMT+01:00 Tiejun.Peng <tiejun.peng@foxmail.com>:
> i agree with you. too much  experience value in condition of Judgement  like this:
> "else if(max_frames>=4 && max_frames >= p->buf_size/10000)".
>  why  it is the value ? it is hard to known.
> maybe  the work of cleaned up  need a few days, so i just  repair of the probe.

Please be careful:
As you already know, this probe function is the result of many
user reports, many tests and turning many knobs. You cannot
"repair" it (easily).

If you know of any false positives of the current probe function,
please report them!

Carl Eugen
wm4 Dec. 11, 2017, 10:43 a.m.
On Fri, 8 Dec 2017 18:51:52 +0100
Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:

> 2017-12-08 18:45 GMT+01:00 Tiejun.Peng <tiejun.peng@foxmail.com>:
> > i agree with you. too much  experience value in condition of Judgement  like this:
> > "else if(max_frames>=4 && max_frames >= p->buf_size/10000)".
> >  why  it is the value ? it is hard to known.
> > maybe  the work of cleaned up  need a few days, so i just  repair of the probe.  
> 
> Please be careful:
> As you already know, this probe function is the result of many
> user reports, many tests and turning many knobs. You cannot
> "repair" it (easily).
> 
> If you know of any false positives of the current probe function,
> please report them!

It plays ELF files as mp3.

You've been ignoring this issue, though.

This probe function is really pretty bad.
Michael Niedermayer Dec. 11, 2017, 9:56 p.m.
On Mon, Dec 11, 2017 at 11:43:30AM +0100, wm4 wrote:
> On Fri, 8 Dec 2017 18:51:52 +0100
> Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> 
> > 2017-12-08 18:45 GMT+01:00 Tiejun.Peng <tiejun.peng@foxmail.com>:
> > > i agree with you. too much  experience value in condition of Judgement  like this:
> > > "else if(max_frames>=4 && max_frames >= p->buf_size/10000)".
> > >  why  it is the value ? it is hard to known.
> > > maybe  the work of cleaned up  need a few days, so i just  repair of the probe.  
> > 
> > Please be careful:
> > As you already know, this probe function is the result of many
> > user reports, many tests and turning many knobs. You cannot
> > "repair" it (easily).
> > 
> > If you know of any false positives of the current probe function,
> > please report them!
> 
> It plays ELF files as mp3.
> 
> You've been ignoring this issue, though.
> 
> This probe function is really pretty bad.

The probe code determines the most likely format from the set of
supported formats.
We do not support playing excutable files (that makes no sense), thus
these do not get detected.

Is there a usecase where detecting not just the most likely multimedia
format but detecting that a file is not any multimedia format
makes sense ?

Also if a format is detected with a low score the user is informed about
this via "Format %s detected only with low score of %d,"


[...]
wm4 Dec. 12, 2017, 7:38 a.m.
On Mon, 11 Dec 2017 22:56:24 +0100
Michael Niedermayer <michael@niedermayer.cc> wrote:

> On Mon, Dec 11, 2017 at 11:43:30AM +0100, wm4 wrote:
> > On Fri, 8 Dec 2017 18:51:52 +0100
> > Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> >   
> > > 2017-12-08 18:45 GMT+01:00 Tiejun.Peng <tiejun.peng@foxmail.com>:  
> > > > i agree with you. too much  experience value in condition of Judgement  like this:
> > > > "else if(max_frames>=4 && max_frames >= p->buf_size/10000)".
> > > >  why  it is the value ? it is hard to known.
> > > > maybe  the work of cleaned up  need a few days, so i just  repair of the probe.    
> > > 
> > > Please be careful:
> > > As you already know, this probe function is the result of many
> > > user reports, many tests and turning many knobs. You cannot
> > > "repair" it (easily).
> > > 
> > > If you know of any false positives of the current probe function,
> > > please report them!  
> > 
> > It plays ELF files as mp3.
> > 
> > You've been ignoring this issue, though.
> > 
> > This probe function is really pretty bad.  
> 
> The probe code determines the most likely format from the set of
> supported formats.
> We do not support playing excutable files (that makes no sense), thus
> these do not get detected.
> 
> Is there a usecase where detecting not just the most likely multimedia
> format but detecting that a file is not any multimedia format
> makes sense ?

Not playing noise and looking like a huge fuckup of a media application
when opening a bunch of files that might include unknown file types?
Lots of software is using this to detect whether something is a media
file in the first place, too.

> Also if a format is detected with a low score the user is informed about
> this via "Format %s detected only with low score of %d,"

Doesn't help much if legitimate files get a low probe score. AFAIK in
my case this happened mostly because of large ID3v2 tags, which
restricted or even removed any useful media data from the probe buffer.
An API to detect id3 tags (and their size to skip them) would probably
be nice for this.
Carl Eugen Hoyos Dec. 12, 2017, 8:56 p.m.
2017-12-11 11:43 GMT+01:00 wm4 <nfxjfg@googlemail.com>:

> You've been ignoring this issue, though.

Please stop using this mailing list for your insults.

Carl Eugen
Paul B Mahol Dec. 12, 2017, 9:12 p.m.
On 12/12/17, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> 2017-12-11 11:43 GMT+01:00 wm4 <nfxjfg@googlemail.com>:
>
>> You've been ignoring this issue, though.
>
> Please stop using this mailing list for your insults.

Nobody insulted you, perhaps you should be really insulted anyway.
Carl Eugen Hoyos Dec. 12, 2017, 9:13 p.m.
2017-12-12 22:12 GMT+01:00 Paul B Mahol <onemda@gmail.com>:
> On 12/12/17, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>> 2017-12-11 11:43 GMT+01:00 wm4 <nfxjfg@googlemail.com>:
>>
>>> You've been ignoring this issue, though.
>>
>> Please stop using this mailing list for your insults.
>
> Nobody insulted you

I am not sure if he only wanted to insult me...

Carl Eugen
wm4 Dec. 12, 2017, 9:26 p.m.
On Tue, 12 Dec 2017 22:13:30 +0100
Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:

> 2017-12-12 22:12 GMT+01:00 Paul B Mahol <onemda@gmail.com>:
> > On 12/12/17, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:  
> >> 2017-12-11 11:43 GMT+01:00 wm4 <nfxjfg@googlemail.com>:
> >>  
> >>> You've been ignoring this issue, though.  
> >>
> >> Please stop using this mailing list for your insults.  
> >
> > Nobody insulted you  
> 
> I am not sure if he only wanted to insult me...

While I wouldn't mind commenting upon your unpleasant personality in
colorful ways, it's true that you've known about this ELF issue for a
very long time, but haven't ever fixed it.
James Almer Dec. 12, 2017, 9:28 p.m.
On 12/12/2017 4:38 AM, wm4 wrote:
> On Mon, 11 Dec 2017 22:56:24 +0100
> Michael Niedermayer <michael@niedermayer.cc> wrote:
> 
>> On Mon, Dec 11, 2017 at 11:43:30AM +0100, wm4 wrote:
>>> On Fri, 8 Dec 2017 18:51:52 +0100
>>> Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>   
>>>> 2017-12-08 18:45 GMT+01:00 Tiejun.Peng <tiejun.peng@foxmail.com>:  
>>>>> i agree with you. too much  experience value in condition of Judgement  like this:
>>>>> "else if(max_frames>=4 && max_frames >= p->buf_size/10000)".
>>>>>  why  it is the value ? it is hard to known.
>>>>> maybe  the work of cleaned up  need a few days, so i just  repair of the probe.    
>>>>
>>>> Please be careful:
>>>> As you already know, this probe function is the result of many
>>>> user reports, many tests and turning many knobs. You cannot
>>>> "repair" it (easily).
>>>>
>>>> If you know of any false positives of the current probe function,
>>>> please report them!  
>>>
>>> It plays ELF files as mp3.
>>>
>>> You've been ignoring this issue, though.
>>>
>>> This probe function is really pretty bad.  
>>
>> The probe code determines the most likely format from the set of
>> supported formats.
>> We do not support playing excutable files (that makes no sense), thus
>> these do not get detected.
>>
>> Is there a usecase where detecting not just the most likely multimedia
>> format but detecting that a file is not any multimedia format
>> makes sense ?
> 
> Not playing noise and looking like a huge fuckup of a media application
> when opening a bunch of files that might include unknown file types?
> Lots of software is using this to detect whether something is a media
> file in the first place, too.
> 
>> Also if a format is detected with a low score the user is informed about
>> this via "Format %s detected only with low score of %d,"
> 
> Doesn't help much if legitimate files get a low probe score. AFAIK in
> my case this happened mostly because of large ID3v2 tags, which
> restricted or even removed any useful media data from the probe buffer.
> An API to detect id3 tags (and their size to skip them) would probably
> be nice for this.

ID3v2 tags are handled in avformat_open_input(), unlike APE tags. If
it's not currently being skipped before filling the probe buffers, it
could perhaps be implemented.
Carl Eugen Hoyos Dec. 12, 2017, 9:28 p.m.
2017-12-12 22:26 GMT+01:00 wm4 <nfxjfg@googlemail.com>:
> On Tue, 12 Dec 2017 22:13:30 +0100
> Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>
>> 2017-12-12 22:12 GMT+01:00 Paul B Mahol <onemda@gmail.com>:
>> > On 12/12/17, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>> >> 2017-12-11 11:43 GMT+01:00 wm4 <nfxjfg@googlemail.com>:
>> >>
>> >>> You've been ignoring this issue, though.
>> >>
>> >> Please stop using this mailing list for your insults.
>> >
>> > Nobody insulted you
>>
>> I am not sure if he only wanted to insult me...
>
> While I wouldn't mind commenting upon your unpleasant personality in
> colorful ways, it's true that you've known about this ELF issue for a
> very long time, but haven't ever fixed it.

I am 100% sure you don't want to spread lies here but may I
remind you of my first email above where I explain that
applying this patch would introduce the issue that was fixed
because of your report?

And while here: Please share the sample that triggers the
amr bug - you seem to have forgotten that you are responsible
for the issue.

Carl Eugen
wm4 Dec. 12, 2017, 9:45 p.m.
On Tue, 12 Dec 2017 18:28:28 -0300
James Almer <jamrial@gmail.com> wrote:

> On 12/12/2017 4:38 AM, wm4 wrote:
> > On Mon, 11 Dec 2017 22:56:24 +0100
> > Michael Niedermayer <michael@niedermayer.cc> wrote:
> >   
> >> On Mon, Dec 11, 2017 at 11:43:30AM +0100, wm4 wrote:  
> >>> On Fri, 8 Dec 2017 18:51:52 +0100
> >>> Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> >>>     
> >>>> 2017-12-08 18:45 GMT+01:00 Tiejun.Peng <tiejun.peng@foxmail.com>:    
> >>>>> i agree with you. too much  experience value in condition of Judgement  like this:
> >>>>> "else if(max_frames>=4 && max_frames >= p->buf_size/10000)".
> >>>>>  why  it is the value ? it is hard to known.
> >>>>> maybe  the work of cleaned up  need a few days, so i just  repair of the probe.      
> >>>>
> >>>> Please be careful:
> >>>> As you already know, this probe function is the result of many
> >>>> user reports, many tests and turning many knobs. You cannot
> >>>> "repair" it (easily).
> >>>>
> >>>> If you know of any false positives of the current probe function,
> >>>> please report them!    
> >>>
> >>> It plays ELF files as mp3.
> >>>
> >>> You've been ignoring this issue, though.
> >>>
> >>> This probe function is really pretty bad.    
> >>
> >> The probe code determines the most likely format from the set of
> >> supported formats.
> >> We do not support playing excutable files (that makes no sense), thus
> >> these do not get detected.
> >>
> >> Is there a usecase where detecting not just the most likely multimedia
> >> format but detecting that a file is not any multimedia format
> >> makes sense ?  
> > 
> > Not playing noise and looking like a huge fuckup of a media application
> > when opening a bunch of files that might include unknown file types?
> > Lots of software is using this to detect whether something is a media
> > file in the first place, too.
> >   
> >> Also if a format is detected with a low score the user is informed about
> >> this via "Format %s detected only with low score of %d,"  
> > 
> > Doesn't help much if legitimate files get a low probe score. AFAIK in
> > my case this happened mostly because of large ID3v2 tags, which
> > restricted or even removed any useful media data from the probe buffer.
> > An API to detect id3 tags (and their size to skip them) would probably
> > be nice for this.  
> 
> ID3v2 tags are handled in avformat_open_input(), unlike APE tags. If
> it's not currently being skipped before filling the probe buffers, it
> could perhaps be implemented.

It doesn't look like even avformat_open_input() skips the id3v2. But
av_probe_input_format*() does. Unfortunately, it uses it only to play
weird games with the probe score, which makes this sort of useless for
API users (and for ffmpeg CLI itself this isn't ideal either). If the
API user assumes that a low probe score always means it has to give the
prober more data, and a given file is something semi-broken that simply
always returns a low score, the API user will be made to read tons of
data into memory for no reason.

That's something I'd like to avoid, and the easiest way is to limit the
probe buffer to something relatively small. But id3v2s can be quite big
(embedded high res cover art), so that's where it becomes a problem
wrt. mp3 in particular.

Patch hide | download patch | download mbox

diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index a76fe32..286eb68 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -73,6 +73,7 @@  static int mp3_read_probe(AVProbeData *p)
     int frames, ret;
     uint32_t header;
     const uint8_t *buf, *buf0, *buf2, *end;
+    int match_size = 0;
 
     buf0 = p->buf;
     end = p->buf + p->buf_size - sizeof(uint32_t);
@@ -92,6 +93,7 @@  static int mp3_read_probe(AVProbeData *p)
             if (ret != 0)
                 break;
             buf2 += h.frame_size;
+            match_size += h.frame_size;
         }
         max_frames = FFMAX(max_frames, frames);
         if(buf == buf0) {
@@ -104,6 +106,8 @@  static int mp3_read_probe(AVProbeData *p)
     // issues with MPEG-files!
     if   (first_frames>=7) return AVPROBE_SCORE_EXTENSION + 1;
     else if(max_frames>200)return AVPROBE_SCORE_EXTENSION;
+    // over 50% of probe size is valid
+    else if (p->buf_size > 10000 && match_size > (p->buf_size/2)) return AVPROBE_SCORE_EXTENSION;
     else if(max_frames>=4 && max_frames >= p->buf_size/10000) return AVPROBE_SCORE_EXTENSION / 2;
     else if(ff_id3v2_match(buf0, ID3v2_DEFAULT_MAGIC) && 2*ff_id3v2_tag_len(buf0) >= p->buf_size)
                            return p->buf_size < PROBE_BUF_MAX ? AVPROBE_SCORE_EXTENSION / 4 : AVPROBE_SCORE_EXTENSION - 2;