Hello, On Wed, Sep 17, 2008 at 7:08 AM, Kostya <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 _______________________________________________ FFmpeg-soc mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
