[FFmpeg-soc] AAC Encoding - Where we stand, what's left
diego at biurrun.de
Wed Jul 8 12:25:09 CEST 2009
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...
P.S.: This should really be discussed on ffmpeg-devel...
More information about the FFmpeg-soc