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

[Kostya]

On Sat, Sep 06, 2008 at 09:56:16PM +0200, Michael Niedermayer wrote:
> On Sat, Sep 06, 2008 at 08:28:48PM +0300, Kostya wrote:
> > On Sat, Sep 06, 2008 at 06:53:59PM +0200, Michael Niedermayer wrote:
> > > On Sat, Sep 06, 2008 at 04:27:21PM +0300, Kostya wrote:
[...]
> > My main problem is that optimal search takes too much time. And here
> > the tradeoffs begin.
> 
> how much time does it take?

With current code - about 72 seconds to encode 16-second sample, so I
am a bit afraid to try more searches. But I will do that anyway.

> how much quality is lost by not doing it?
> can you please post the code so we can try to improve it.
> 
> I dont want to flame, but the way you seem to be working on this is extreemly
> problematic. It shouldnt be "ooh that too slow lets try something else" it
> should be
> "A takes X seconds and has Y rate distortion curve, B takes U seconds and has
> V rate distortion curve so we take A because its faster while quality
> difference is negligible" or
> "we take A because its better and speed difference is negligible"
> or "we support both and let th user decide by compression_level"
> Basically either you do not test the code at all or you do not post the
> results of your tests.
> Either way that makes it impossible for me to accept anything short of the
> mathematical optimum.
> Or to say it differently I NEED some evidence that your "tradeoffs" are
> reasonable. (and not only evidence, they actually have to be good tradeoffs
> or we will be stuck when the encoder is finished and falls short of the
> expected quality)
> 
> I see 2 ways by which you can write the encoder
> the first is what i suggested, you write a RD optiamal encoder (that
> would be very slow) and we then add "tradeoffs" carefully step by step
> while watching what effect each has on speed and quality/bitrate.

I tried to do that, will continue. Having an optimal encoder is a nice
feature. And it will provide a basis for testing speedup tricks, as you
want.

> the second is you write a encoder any way you like and i just check if
> its within 5% of one of the RD based encoders mentioned in the paper
> if not you can figure out why not.

Probably later. I have to reread that paper anyway.
 
> [...]
> 
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> It is not what we do, but why we do it that matters.



> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel