[FFmpeg-soc] AAC Encoding - Where we stand, what's left

[Kostya]

On Wed, Jul 08, 2009 at 12:25:09PM +0200, Diego Biurrun wrote:
> On Mon, Jul 06, 2009 at 10:38:55PM -0400, Alex Converse wrote:
> > On Mon, Jul 6, 2009 at 9:28 PM, Diego Biurrun<diego at biurrun.de> wrote:
> > > On Mon, Jul 06, 2009 at 09:14:00PM -0400, Alex Converse wrote:
> > >> I'd like to take a minute to discuss the status of the AAC encoder and
> > >> where it is going.
> > >>
> > >> In SoC svn:
> > >> --Lacks multichannel support
> > >> --Lacks SBR
> > >
> > > These are likely low priority.
> > 
> > All the other AAC encoders out there worth their salt support these.
> > It's 2009, SBR is no longer a fringe extension to AAC that major
> > implementations don't support. Microsoft and Apple have both moved to
> > supporting HE-AAC. 14496-3:2009 will include the HE-AAC profile in the
> > main body (not an amendment). SBR is absolutely necessary to be
> > competitive at low bitrates.
> 
> I don't doubt that SBR is good, but getting a functioning basic encoder
> that produces a simple but valid bitstream is more important.  SBR
> support can (and will have to) come after that.

It would be very convenient to get it in decoder first too.
 
> > >> --Maximum frame size enforcement
> > >
> > > Could you try to get this merged next?
> > 
> > It depends on the rate control stuff.
> 
> Then try to get the rate control stuff merged first :)

That's another tricky stuff but we'll get it eventually.

> > >> To be frank, at this point it seems like it might be prudent for me to
> > >> stop working on this
> > >
> > > Uh, why?
> > 
> > Getting faac free (by dropping long forgotten profiles and
> > reimplementing things from spec), seem like less effort than getting
> > FFmpeg to faac quality (running around trying to fix bugs in someone
> > else's codebase). Building on 26.410 v8.0.0 is attractive because it
> > is already better quality than ffmpeg and faac and includes a working
> > SBR implementation which would require tons of work to add to ffmpeg
> > or faac.
> 
> What is "26.410 v8.0.0", where can I find it and how is it licensed?

3GPP TS 26.410 aka AAC encoder floating point code. Guess license by
yourself ;)

[...]
> 
> > I'm not the only one who's wondered if FFmpeg is really the best place
> > to implement a high quality encoder. FFmpeg lacks a VC-1 encoder, an
> > H.264 encoder, and an MP3 encoder. x264 is developed outside of FFmpeg
> > despite sharing some code. Aften and Flake (that PARCOR routine is
> > actually from Flake) are developed outside of FFmpeg and periodically
> > have features backported. AAC itself is older than FFmpeg (not some
> > johnny-come-lately format) and we still lack a working encoder for it.
> 
> Without a doubt, encoders are not FFmpeg's main strength.  That does not
> mean we should not attempt to change this.

Err, have you ever heard of MN-backed MPEG-4 ASP and H.26[1-3] encoders?
Too bad everybody wants that H.264+AAC.

> Not having an encoder or even a decoder for certain formats often has
> historic reasons.  Whenever external libraries of good enough or better
> quality have been available, motivation to write equivalents in FFmpeg
> has been low...

Reminds me of AMR.
 
> Diego
> 
> P.S.: This should really be discussed on ffmpeg-devel...