[FFmpeg-devel] lame: output buffer too small issue

[Art Clarke]

On Tue, Jan 27, 2009 at 4:48 PM, M?ns Rullg?rd <mans at mansr.com> wrote:
> Finally, I'd prefer that a good number of developers were at least
> somewhat familiar with git before we switch.  I know some of us
> already use it, but I don't know how large a number.

Another reason I'd add is maturity of supplementary tools.  We use a
bunch of tools that wrap and understand SVN as part of our build and
test process, and the fact that FFMPEG also uses FFMPEG allows us to
constantly integrate FFMPEG tip of tree into those tests.  It gives us
the advantage (and frankly the pain) of being able to constantly
integrate FFMPEG into our project, and find bugs quickly.

Over the past year I think this has helped not only us but FFMPEG,
since we've used this to find and fix build errors, bugs and memory
leaks in FFMPEG (see this weekend for an example), and submitted all
fixes.

The reality is that other projects (like continuous build servers)
tend to support svn and cvs today, but support for GIT is lagging
(given the newness of GIT).

If/when FFMPEG moves to git, out continuous build system will break,
and we'll end up doing exactly what we have to do for libx264 (which
uses GIT); we'll peg ourselves to a "stable release", keep telling
ourselves "oh yes, we'll integrate to tip frequently", but in fact
gradually fall behind.  That means FFMPEG will lose the advantage of
having someone be able to find errors in the public API
instantaneously.

A view of this is that it's my problem (it is) and not FFMPEG's, but
my $0.02 (I know, not worth much) is that changing source control
systems on FFMPEG should be viewed at the same way code-checkins are:
if it ain't horribly broken, don't change it because figuring out the
upstream impacts could be hellish.

- Art

-- 
http://www.xuggle.com/
xu?ggle (z?' gl) v. To freely encode, decode, and experience audio and video.

Use Xuggle to get the power of FFMPEG in Java.