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