On Wed, Jul 8, 2009 at 6:25 AM, Diego Biurrun<di...@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<di...@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@mplayerhq.hu > https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc > _______________________________________________ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
