On Mon, Dec 15, 2008 at 6:27 AM, Jean-Michel Pour? <jm at poure.com> wrote: > A friend of mine pointed out this project, which relies on ffmpeg and > provides static binaries to avoid ffmpeg version problems and > dependencies: http://handbrake.f > > According to him, it should be possible to link mlt staticly and provide > a larger binary, but including all latest features and codecs.
As you know by now, you can do this, but for version management of MLT -to- FFmpeg there are a few options: 1.) As is now - try to keep it working with many versions with some caveats. For example, you need to relatively new version to get support for audio formats other than S16LE. 2.) When I make a release, clearly publish the FFmpeg version I was using in final days of testing. 3.) Periodically include a snapshot of the FFmpeg source code. 4.) Add a build option alongside --avformat-svn to retrieve trunk or a specific revision where it defaults to the specific tested rev on a release version. I plan to do #2 in the next release (real soon now). I might get around to #4 next. #3 provides the most insulation, but at the risk of falling behind FFmpeg improvements. However, this issue applies to other packages and where will it end? For example, sox has given me much more version compatibility pain than anything else. And shall I include ffmpeg dependencies such as x264, since a few months ago, FFmpeg started requiring a newer version than many distros have? All of a sudden, this quickly turns into a job similar to that of a distro maintainer, and my time is better spent elsewhere. I tend to let the level of nuisance push me to new measures, and right now it is not so bad for FFmpeg, but the least I can do is #2 to prevent to total ambiguity. -- +-DRD-+
