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

[Alex Converse]

On Wed, Jul 8, 2009 at 6:25 AM, Diego Biurrun<diego at biurrun.de> 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.
>
>> >> --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?
>

As I'm starting to screw around in shared code, being able to run
regressions is nice.

>> 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...
> _______________________________________________
> FFmpeg-soc mailing list
> FFmpeg-soc at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
>