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

[Robert Swain]

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? 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.

I'm mostly referring to the syntax element id to channel order mapping 
but how to handle HE AAC sample rates seems to be a bit of a mess as 
well, mostly because FAAD ignores the spec for these things and files 
exist that work with FAAD that aren't spec compliant. It's crap.

Regards,
Rob