[FFmpeg-devel] [PATCh] aac parser: Don't write channels, sample rate, and frame size each frame

Alex Converse alex.converse
Tue Mar 2 14:26:25 CET 2010


On Tue, Mar 2, 2010 at 7:33 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Tue, Mar 02, 2010 at 01:07:50PM +0100, Robert Swain wrote:
>> On 02/03/10 11:55, Michael Niedermayer wrote:
>>> On Tue, Mar 02, 2010 at 05:13:15AM -0500, Alex Converse wrote:
>>>> On Tue, Mar 2, 2010 at 5:03 AM, Michael Niedermayer<michaelni at gmx.at>
>>>> wrote:
>>>>> On Mon, Mar 01, 2010 at 08:31:42PM -0500, Alex Converse wrote:
>>>>>> On Mon, Mar 1, 2010 at 8:23 PM, Michael
>>>>>> Niedermayer<michaelni at gmx.at>wrote:
>>>>>>
>>>>>>> On Mon, Mar 01, 2010 at 08:16:48PM -0500, Alex Converse wrote:
>>>>>>>> They are part of the invariant header and shouldn't change each frame
>>>>>>>> anyway. This prevents them from overwriting information provided by
>>>>>>>> backwards compatible extensions.
>>>>>>>
>>>>>>> what you attached does not match the description
>>>>>>>
>>>>>>> besides "shouldn't change" gives me a strange feeling ...
>>>>>>> if we can support it changing it would be a nice "wish/feature
>>>>>>> request"
>>>>>>>
>>>>>>
>>>>>> According to the AAC specification they changing these vales from frame
>>>>>> to
>>>>>> frame is forbidden. They are part of the fixed header.
>>>>>
>>>>> these are written in every spec, it seems not to stop the broadcast
>>>>> crowd
>>>>> from switching channels and such between programs/commercials/...
>>>>>
>>>>> Also if ffmpeg doesnt support X and another application does support X
>>>>> people switch applications instead of reporting bugs. (path of least
>>>>> work ...).
>>>>
>>>> I've found several times that people report bugs for things X does
>>>> that FFmpeg does not. People complained that the sample rate and
>>>> channel count of pure LC streams was wrong because we didn't match
>>>> libfaad2.
>>>
>>> they often do not
>>> how many things can mplayer do that ffplay cannot, how many where
>>> reported to us?
>>> and then there are projects that serve no other purpose than to
>>> workaround issues in ffmpeg. Nothing of this is reported to us
>>> rather one finds it by luck in forum posts or irc that theres
>>> yet another fork hoarding hacky workarounds ...
>>> If these people would instead of hackitis-forkitis report the issues
>>> they have with ffmpeg and work together with us on ffmpeg-dev we would
>>> have
>>> them fixed in no time.
>>> One should fork when one disagrees with us not when one found 3 bugs
>>
>> It seems to me that the whole audio configuration in AAC is a mess of
>> spaghetti. (No offence to Italians - I like spaghetti.) The spec says do it
>> this way and only this is valid. Files occur regularly in the wild that are
>> not valid but that, for example, FAAD supports because it doesn't do what
>> the spec says. However, there are other samples which require things to
>> work how the spec says otherwise their channel order will be wrong. Which
>> should we support?
>
> both of course
>
>
>> Maybe there's some complicated way to identify if a file
>> is valid and if so use the spec method and if not then try the dumb method.
>
> thats the fun part of writing practically useable decoders ;)
> from my extensive experience in mpeg4-asp idiot encoder detection i know
> that in almost all cases one can detect these things somehow.
> either way we have a AVCodecContext->workaround_bugs that specifies and
> allows the user to tune which encoder bug workarounds are applied.
>
>

Patches welcome :)



More information about the ffmpeg-devel mailing list