[FFmpeg-devel] [PATCH] [ISSUE 793] Fix mp3 identification regressions

[Michael Niedermayer]

On Tue, Feb 03, 2009 at 07:57:23PM -0500, Alex Converse wrote:
> On Sat, Jan 31, 2009 at 5:26 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Fri, Jan 30, 2009 at 08:01:25PM -0500, Alex Converse wrote:
> >> On Fri, Jan 30, 2009 at 4:46 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> > On Thu, Jan 29, 2009 at 12:31:52PM -0500, Alex Converse wrote:
> >> >> On Thu, Jan 29, 2009 at 12:28 PM, Alex Converse <alex.converse at gmail.com>wrote:
> >> >>
> >> >> > Right now MP3 files with ID3v2 tags bigger than 2MB no longer identify as
> >> >> > MP3. This patch makes the mp3 probe return 1 on files with id3v2 tags where
> >> >> > mp3 was not identified to make these files identiy as MP3 on the last probe
> >> >> > pass. A more elegant solution would be for the probes to be able to request
> >> >> > seeking, however it seems that that would piss all over the API. I know
> >> >> > Michael had suggested a return value to request more data in general but in
> >> >> > theory ID3v2 can grow over 256 MB and I'm nto sure we'd want to sent that
> >> >> > much information to the probe.
> >> >> >
> >> >>
> >> >> I suppose it might be helpful if I actually attach the patch.
> >> >
> >> > iam not against this patch id just like to make sure you understand that
> >> > it will not be nearly as reliably as you might think, other codecs also
> >> > make wild guesses and return 1 on random data on occasion
> >> >
> >>
> >> I see what you are saying here. The old code used to give us
> >> AVPROBE_SCORE_MAX/2+1 on all files that had id3v2 tags. Do you think
> >> return AVPROBE_SCORE_MAX/4-1 would be appropriate for any file with an
> >> id3v2 tag?
> >
> > its probably better than 1, still best would be to fix the probe API to
> > allow formats to request more data.
> >
> 
> I agree that there needs to be a structural change to the probe API
> but I don't think requesting more data is the answer. Two megabytes is
> a lot of data. I think it needs to be allowed to request a seek.

i do not plan to approve seeking in the probe code, the complexity
outweights the gain, that is a gain entirely hypothetical and just
in the form of a few hundread milliseconds for uncommon and arguably
broken files.

seeking is slow, reading data linearly is fast, having even just 10
demuxers asking for seeking will cost 10 times as much as 1 demuxer
having 10 demuxers ask for 2mb will not cost more than 1.
yes you can implement a cache but thats heading even further in the
direction of disproportionate complexity for the gain ...

also the max probe size can be configured by the user so she always
has the choice of avoiding the delay in exchange of more flaky probing.


If you want a more generic fix that can handle gigabytes of id3 tags
infront of more than mp3, the obvious choice would be to run probe
(no seek style) then open the file with the most likely correct demuxer
and if that fails straight, try the next likely demuxer.
this also would need zero changes in demuxers themselfs

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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090204/8f681ab8/attachment.pgp>