[Bf-committers] [BF-committers] Updating FFMPEG
peter at schlaile.de
Sun Aug 9 10:42:28 CEST 2009
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
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
But: we should state on every release, what exact version of
ffmpeg-source-tree we used. I don't like hunting Heisenbugs...
More information about the Bf-committers