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