[Vxl-maintainers] subversion, ffmpeg and vxl

[Ian S. <ian...@st...>]

Amitha,

I'm assuming that

1. The binary would sit alongside a full source version of ffmpeg in v3p 
- which would be compiled and used if possible.
2. vidl2 is successfully proposed and supported for upgrading to core, 
and someone commits to actually moving it, and writing a book chapter 
for it. (Only libraries in core should get their dependencies into v3p - 
to prevent bloating.)
3. There are not lots of other libraries out there that people want to 
use and have similar problems.

In this special case it does seem like adding a BLOB to the repository 
is the least worst idea.

However it is still not currently a good idea because CVS's performance 
with binaries is awful, and repository access is slow enough already.

Perhaps this is the time to upgrade to subversion - we have been using 
at imorphics for over a year now, and are very happy with it.

I would be happy to do the main cvs2svn conversion in a month or two's 
time. I've done two large conversions already and I have lots of script 
lines to clean up permissions, check binary/text flags, test for 
problems, etc. I would need someone else to volunteer to handle the 
dashboard changes, and someone to install scripts on the repository to 
mail vxl-commits, and check that the metadata properties, etc of future 
commits are correct.

Ian.




Amitha Perera wrote:
> Folks,
> 
> I'd like your thoughts on some ffmpeg- related issues.  For the time 
> constrained, a key question below is: can I check in a Windows DLL 
> binary into the CVS source tree?
> 
> We are currently using ffmpeg to read and write videos in vidl2.  It is 
> a incredible library for that purpose, and we should continue to use it. 
>    However, it changes its API, file layout, include paths, etc, quite 
> often.  (And it has no official releases to track.)  Right now, vidl2 
> tries to support multiple versions by having #ifdef's in the code.  With 
> this, it is quite a pain to write a wrapper supporting multiple versions
> of ffmpeg.
> 
> The recent versions of ffmpeg changed the layout of the include paths, 
> so what used to be
>    #include <avformat.h>
> is now
>    #include <avformat/avformat.h>
> Supporting both options, while not increasing the include path length, 
> creates a lot of work.
> 
> Now, all of these issues can be worked around, given enough effort. 
> Instead, I'd like to follow the lead of other projects using ffmpeg, by 
> including a snapshot of ffmpeg in v3p.
> 
> The problem is that ffmpeg will not build with the Visual C compiler. 
> The source code uses a lot of C99isms that are hard to work around, and 
> Visual C does not support C99.  In fact, it is likely that ffmpeg will 
> only build with gcc.
> 
> Now, ffmpeg *can* be built for windows, using MingW and gcc.  The 
> resulting libraries can be used in Visual C projects.  So, one option to 
> build ffmpeg when possible, and to have pre-built binary version for the 
> other cases.
> 
> What do folks think of checking in binary support libraries like this?
> 
> Instead of checking in the binary libraries into the vxl tree, we could 
> make a separate checkout for the vxl-friendly ffmpeg, and this will 
> contain binary libraries.
> 
> What I want is for the ability to update vxl's ffmpeg wrapper relatively 
> easily, and to make sure that the corresponding actual ffmpeg library 
> can be updated just as easily.
> 
> Thoughts?
> 
> Amitha.
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Vxl-maintainers mailing list
> Vxl...@li...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers