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

Baptiste Coudurier baptiste.coudurier
Wed Feb 4 02:05:10 CET 2009


Hi Alex,

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.

You cannot seek in a streamed input (pipe, etc ..)

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org




More information about the ffmpeg-devel mailing list