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

[Michael Niedermayer]

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.


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

Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- 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/20100302/3d38d0b8/attachment.pgp>