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

[Robert Swain]

2009/7/7 Alex Converse <alex.converse at gmail.com>:
> 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:

[...]

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

Menno Bakker (now works for Nero and probably has knowledge of their
encoder but is the main/only FAA* maintainer) said that the 3GPP model
is better than that in FAAC. Could we not take the ideas from the 3GPP
spec/implementation and implement them in FFmpeg to reach some sort of
base line?

>>> 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). This is especially painful because
> essentially I'm playing in someone else's sandbox here.

I guess this is a problem to keep sync with HEAD but I can't say that
I've ever really found it to be a major issue. The way I think about
it is that if history is desired for encoder quality/performance
tuning, then acceptance of a bitstream compatible encoder into trunk
is a priority so that it can then be developed without having to keep
some branch in sync with head and so that changes can be committed
incremenetally. If that is not acceptable, then forgoing history
should be because keeping things in sync with trunk is a pain. Mostly
I think actually having good code is far more important than having
all its history and that having history is favoured as long as the
effort required to retain it is not unreasonable. Maybe keeping notes
of significant developments in some text file is a tradeoff.

> The concepts of trying to minimize the diff vs HEAD outside of the
> core encoder files to ease merging and a variety of things that need
> to be done are diametrically opposed. A variety of codec specific
> options are needed (see previous). Splitting out the windowing and
> psymodel code to make a fake encoder to tune the psymodel is intrusive
> OR leads to lots of duplication. either way it's pretty nasty and
> requires big adjustments to both the AAC encoder and decoder.
>
> If I'm the only one working on this, implementing it outside of
> libavcodec allows me to make the changes I feel are necessary without
> having to justify them to anyone else.

I think this is one of the reasons x264 remains outside libavcodec -
because its developers feel that integrating it with libavcodec would
restrict their freedom to develop it.

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

For h.264 and MP3 we have x264 and LAME which are both absolutely very
good encoders respectively. I see no reason to implement our own h.264
and/or MP3 encoders as a consequence and would rather support these
libraries well within FFmpeg. VC-1 should probably be funded if anyone
is interested in VC-1 encoding unless there's some compelling reason
to do it for non-commercial purposes. An AAC encoder is very welcome
in FFmpeg because there is no good, competitive, free, open source
encoder available.

Regards,
Rob