[FFmpeg-soc] [soc]: r3744 - aacenc/aacenc.c

[Guillaume POIRIER]

Hello,

On Wed, Sep 17, 2008 at 7:08 AM, Kostya <kostya.shishkov at gmail.com> wrote:
> On Tue, Sep 16, 2008 at 11:01:59PM +0200, Guillaume POIRIER wrote:
>> Hello,
>>
>> On Tue, Sep 16, 2008 at 7:20 PM, Kostya <kostya.shishkov at gmail.com> wrote:
>> >
>> > Now it is slower than before (and M/S detection is not
>> > enabled yet),
>>
>> Your latest figure was 30 times slower than realtime on Core2. How is it now?
>
> maybe 45x slower since I've thrown out incorrect optimizations
>
>> > but stereo stream at ~64kbps is significantly
>> > better now (and I'm almost pleased with it).
>>
>> That rises another question: I thought that current code couldn't do
>> any kind of bitrate control. How can one currently control the quality
>> of the encode currently then? Do you need to pass a bitrate, and the
>> resulting encode with be a CBR, ABR, or VBR encode? Do you pass a
>> quality figure like vorbis uses?
>
> For now I just have hardcoded lambda parameter. By adjusting it one
> can obtain desired bitrate, by not touching it - desired quality.

Is this the hardcoded lambda ?
./aacenc.c:1017:        s->lambda = 5e-7f;

If not, what should I touch to modify the lambda. Also, how do quality
relates to quality in AACenc? If you raise it you lower the encoding
quality?


> I will try to make it follow ABR in the near future.

Outstanding!


> My task now is to create anchor for future practical implementation,
> which will be faster but less optimal. Until then we have CPU cycles
> waster ;)

No problem. I don't care if it takes a lot of time to encode, since
this is done one time only, and I'll subsequently listen a lot to the
generated file.

Guillaume
-- 
One should not give up hope on imbeciles. With a little training, you
can make them into soldiers.
 -- Pierre Desproges