[Bf-committers] FFmpeg upgrade, impact on OS and compilation systems

[Benoit Bolsee]

Hi,

I thought I'd come back on this subject once again before commiting the
upgrade.

Thanks to Ken Hughes and Dalai Felinto who have compiled the patch
18080.

The reason of the patch is to give access to capture devices so that the
VideoTexture module can bring live video images into the BGE.
The only modification to Blender is in
source/blender/imbuf/intern/util.c: avdevice_register_all() must be
called in do_init_ffmpeg() so that capture devices can be opened.
This function is declared in ffmpeg/avdevice.h, which is missing in
current ffmpeg version in extern/ffmpeg; that's why upgrade is needed.

However, many OS/compilation systems don't use the ffmpeg source in
extern; they use either binaries in ../lib or system's ffmpeg in /usr
So this tiny update in util.c will only work if ffmpeg is also upgraded
in ../lib or /usr. The following list summaries the (messy) situation:

OS / compilation    ffmpeg used
--------------------------------
darwin/scons        extern
Irix6/scons         ../lib/irix-6.5-mips
Linux2/scons        extern (/usr is there but is commented)
Sunos/scons         /usr/local
Win32-mingw/scons   ../lib/windows/gcc
Win32-vc/scons      ../lib/windows
Unix/cmake          /usr
Win32/cmake         ../lib/windows
All/Makefile        extern
Win32/project       ../lib

>From these os/compilation I tested Linux2/scons and Win32/project and
Dalai tested win32/cmake. 
The builds that use the system ffmpeg should work ok as long as the
system ffmpeg include libavdevice, which should normally be the case.
The builds that use ../lib will need updated binaries. The windows
binaries are already up to date with device support but I checked
../lib/irix-6.5-mips and they don't support libdevice...
When I made the ffmpeg binaries for win32 back in April, I left some
notes on the procedure in ../lib/windows/ffmpeg/Readme.txt. The platform
maintainers might want to read these notes.

The biggest problem with ffmpeg is the include directory model: ffmpeg
51 was using flat model: everything in ffmpeg (ex: #include
<ffmpeg/avformat.h>); ffmpeg 52 and above use a different model: headers
are splitted by library (ex: #include <libavformat/avformat.h>). 

Blender still use the old model as it has to work with older ffmpeg
versions in /usr but it won't work with the newer version. 

When I created the win32 binaries, I fixed that problem by flattering by
hand the #include statements in ffmpeg headers, as explained in
../lib/windows/ffmpeg/Readme.txt. The platform maintainers could do the
same when preparing the new ffmpeg binaries. 

For linux2/scons, I resolved the problem with a small trick as explained
in config/linux2-config.py: both extern/ffmpeg/include and extern/ffmpeg
are added to the include directory list so that Blender finds the file
in /extern/ffmpeg/include while ffmpeg headers find their includes in
/extern/ffmpeg/libav... Makefile is not fixed yet but I can use a
similar trick. I will test Makefile in Linux and update the patch.

Comments from platform maintainers and Peter Schlaile are welcome.

/Benoit