On Tue, 12 Dec 2017 18:28:28 -0300 James Almer <jamr...@gmail.com> wrote:
> On 12/12/2017 4:38 AM, wm4 wrote: > > On Mon, 11 Dec 2017 22:56:24 +0100 > > Michael Niedermayer <mich...@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 <ceffm...@gmail.com> wrote: > >>> > >>>> 2017-12-08 18:45 GMT+01:00 Tiejun.Peng <tiejun.p...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
