| Message ID | 1512552463-1733-1-git-send-email-tiejun.peng@foxmail.com |
|---|---|
| State | New |
| Headers | show |
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
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
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.
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
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
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
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
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
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.
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," [...]
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.
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
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.
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
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.
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.
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
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.
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;
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(+)