[FFmpeg-devel] [RFC] AAC Encoder, now more optimal

[Robert Swain]

2008/9/5 M?ns Rullg?rd <mans at mansr.com>:
>
> Robert Swain wrote:
>> 2008/9/5 Kostya <kostya.shishkov at gmail.com>:
>>> After some time (I'd like to have more free time to spend on it though),
>>> I want to expose my new AAC encoder.
>>>
>>> It is slower than realtime since it uses search for optimal quantizers
>>> for given quality.
>>>
>>> Known weak points:
>>> * no bitrate management (it uses fixed quality for now)
>>> * no M/S detection
>>> * quantization is not optimal yet
>>>
>>> I haven't implemented those because it will slow encoder even more, so
>>> debug session will include an hour rest (and in case of M/S detection
>>> I don't know how to implement it) - 16sec sample coding takes 42 secs
>>> on my PPC G4-1.42GHz and 39 secs on Core2 1.8MHz.
>>>
>>> Any comments, suggestions, speedup tricks are extremely welcomed
>>> (especially the latter).
>>
>> Obviously this is in the process of being improved. I'm not sure what
>> a reasonable target for encoding speed is for AAC but I'm fairly sure
>> something around 10-20x realtime is achievable with Nero's encoder.
>
> The PS3 AAC encoder is much faster than realtime, and the quality seems
> OK too.

CELL power! ;)

>> Less than realtime audio encoding is... unusual. :) Still, if it was
>> the best quality AAC encoder around, that would bring it some
>> redemption.
>
> There's certainly no harm in having the option of a slow, high-quality
> mode.  However, a reasonably fast, decent-quality mode is essential.

Definitely agreed. Some form of speed/quality tradeoff is always good to have.

> A constant (or restricted) bitrate mode is probably desirable too.

Maybe commercially but otherwise - why?

Rob