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

[Diego Biurrun]

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.

> >> --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 :)

> >> 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?

> >> Dsputil is awesome but developing this encoder inside ffmpeg is
> >> constricting to say the least.
> >
> > Why?  Elaborate..
> 
> Well, our source control is one major paradigm shift behind (and the
> use of svn:externals definitely damages makes using the git mirror
> more painful and branches aren't even exposed on the git mirror but
> we've discussed this a thousand times and I don't see any chance of it
> changing in the near future).

How does libswscale affect your work on AAC?

> This is especially painful because
> essentially I'm playing in someone else's sandbox here.

Just get your own sandbox..

> 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.

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...

Diego

P.S.: This should really be discussed on ffmpeg-devel...