[Bf-committers] [BF-committers] Updating FFMPEG

Peter Schlaile peter at schlaile.de
Sun Aug 9 10:42:28 CEST 2009

Hi folks,

after calming down a bit, I reworked the color conversion patch for latest 
ffmpeg GIT and commited to the list. I also posted the DV workaround.

When both are in ffmpeg upstream, I don't think, we need a seperate copy 
of ffmpeg anymore.

If you want to follow the discussion, take a look here:


> Peter, I was aware that we patch ffmpeg, so why not have the patches
> ffmpeg in ../lib/$OS/ffmpeg?, we have a linux lib dir but its not been
> used for ages.

hmm. Maybe things have changed in the mean time, but I think, on Linux 
those libraries are always very dependent on the glibc-version used to 
compile them.

So you'd have to keep several versions around (or stick to the version, we 
used for the last release.)

I'm also pretty unsure, what to do with libx264 and libxvid. Actually, 
those should also be kept seperate.

What I still do not understand from the discussion on the Debian lists:

I had no problem compiling Blender against latest ffmpeg GIT this morning.
It was just a matter of changing user-config.py and make it point to my 
ffmpeg installation directory.

What problem do we exactly try to solve by removing Blender from extern?

If I got it correctly, the Debian maintainer had problems keeping up with 
the latest version / or the version used in Debian.

But that will happen to *any* program, that uses ffmpeg, since API changes 
can happen any time. (And has nothing to do with the fact, that we include 
a certain version of ffmpeg within our source tree...)

> I'll change my vote for +1 for a patched ffmpeg in lib and add
> ../lib/linux/ffmpeg, the patches can stay in blenders source tree.

if everyone is sure, that you don't have to include all GLIBC-versions, go 
ahead :)

But: we should state on every release, what exact version of 
ffmpeg-source-tree we used. I don't like hunting Heisenbugs...


Peter Schlaile

More information about the Bf-committers mailing list