[FFmpeg-devel] AAC decoder round 9

Robert Swain robert.swain
Thu Aug 21 10:08:33 CEST 2008

2008/8/21 madshi <dear at madshi.net>:
> Robert Swain schrieb:
>> They were previously OKed. I have committed everything I want to
>> commit to trunk, from SoC now and enabled the AAC decoder. I will post
>> a news article on ffmpeg.org shortly with the additions since the last
>> one.
>> I'd like to extend my sincere gratitude to Michael for all his
>> reviewing efforts and his perfectionism, to Kostya for all the
>> assistance and suggestions he's given me and to anyone else who...
>> helped made this possible. Hehehe. :) Thank you very much. If we were
>> in closer proximity I would suggest we have a partay. ;)
>> Of course, it doesn't end here. I will add myself as the maintainer of
>> the AAC decoder files. I intend to fix bugs, continue clean up of bits
>> that remain to be tended to that were not of immediate priority and to
>> add SBR and PS support.
>> Best regards,
>> Rob
> Congrats!  :-)
> I've a few questions, if you don't mind:
> (1) How exact is the AAC decoder specification? In other words: Can there
> be a difference in audio quality between different decoders (other than
> bugs,
> of course)? Would you say that using your new libav decoder should
> deliver similar quality to e.g. Nero's AAC decoder?

The quality can differ for floating point implementations and I will
be looking into various conformance requirements soon. There may be
some areas where we don't conform because the specification has a
significantly poor design decision that we feel we wish to override,
such as the strange windowing allowed in AAC. For the most part, it
should be conforming.

> (2) Does AAC have a native bitdepth? Or is it similar to AC3/DTS where
> the decoder basically outputs floating point? In the latter case: Which
> bitdepth output variations does the decoder support? I'm sorry, I'm a
> bit out of the loop on where libav stands now in terms of audio bitdepth.
> A while ago floating point output was not possible with many decoders.
> Maybe that has changed in the meanwhile?

There is work going on to allow various audio sample formats. AAC
decodes to float as AC3, etc. but only supports s16le output at the
moment. It would be easy enough to add 32-bit float output though I

> (3) Missing SBR and PS support probably means that the decoder can't
> decode some AAC files? Will it abort processing in that case? Or will it
> decode with lower quality? (I think I'd prefer aborting.)

I'd prefer a single notification and not aborting if possible. I'm not
sure what will happen with PS but I suspect in this case it may abort.
In the SBR case it should depend on the way SBR is signalled. Some SBR
files are designed to be playable on non-SBR-capable decoders, just
decoding the LC part. Other files are intended to not play on
non-SBR-capable decoders.

> (4) Which format does the decoder expect/support? With ADIF/ADTS
> headers? Or just the raw data without any headers or something else?

I think ADIF has been deprecated for a long time but we're supposed to
support encoding and such files are still around. Raw stream data with
no headers is the correct data format for the decoder if you're just
pushing data at it through the APIs I think.


More information about the ffmpeg-devel mailing list