<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>
<META content="MSHTML 6.00.2900.5726" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN
class=515191615-21032009>Hi,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=515191615-21032009></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=515191615-21032009>During last meeting,
I proposed my help to upgrade ffmpeg to version 0.5 now that some kind of stable
release is available. So far I have successfully upgraded ffmpeg in Windows,
building new DLL and changing the source code for the API changes (very few
changes fortunately). </SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=515191615-21032009>I was going to
upgrade in Linux when I stumbled on the inextricable mess in
the Sconscript of the associated codec libraries: x264, xvidcore and
libmp3lame. </SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=515191615-21032009></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=515191615-21032009>During the Windows
upgrade, I decided to upgrade also those codecs just in case some bugs were
fixed in them or in case some API change would make the old library incompatible
with ffmpeg 0.5. While the Windows upgrade was just boring but not difficult,
the Linux upgrade was so difficult that it went far beyond my motivation: the
Sconscript for these libraries are playing the dangerous game of assuming
certain syntax, certain directory structure, certain naming convention in the
makefiles which are not at all preserved in the newer versions of these
packages.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=515191615-21032009>At this moment I've
given up upgrading those libraries and I just hope that ffmpeg 0.5 will be happy
to work with the current versions in extern. Unfortunately I cannot proceed with
the ffmpeg upgrade for the moment because the ffmpeg.org site is
down.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=515191615-21032009></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=515191615-21032009>After this failure
I'm asking 3 questions:</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=515191615-21032009>1) Why can't we work
with external dependencies for these 3 codec libraries?</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=515191615-21032009>2) If it is
not desirable for some reason, why can't we work with pre-built libraries
just like in Windows: have the binaries and the headers in lib/linux2/x264
...</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=515191615-21032009>3) If again it is
not desirable for some reason, why can't Scons just implement the standard build
procedure for these packages: configure/make/make install. Having the Sconscript
running the configure script, then extracting the package parameters from the
makefiles to finally build the packages according to Scons paradigm seems total
madness to me.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=515191615-21032009></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=515191615-21032009>Maybe I'm touching a
sensitive subject here but I wanted to express my
perplexity.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=515191615-21032009></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=515191615-21032009>Regards,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=515191615-21032009>Benoit</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=515191615-21032009></SPAN></FONT> </DIV></BODY></HTML>