[FFmpeg-devel] [PATCH] libx264: support for BUILD >= 63

Måns Rullgård mans
Tue Sep 16 10:24:40 CEST 2008

Stefano Sabatini <stefano.sabatini-lala at poste.it> writes:

> On date Monday 2008-09-15 15:07:14 -0400, Daniel G. Taylor encoded:
>> On Mon, 2008-09-15 at 22:55 +0400, Andrew Savchenko wrote:
>> > Hi,
>> Hey,
>> > On Monday 15 September 2008 22:41, Daniel G. Taylor wrote:
>> > [...]
>> > > The patch looks okay but it mandates that ffmpeg requires the
>> > > newer libx264 from this point on, so maybe a library version
>> > > check is in order? What's the normal ffmpeg policy on this?
>> > 
>> > Perhaps, it is to projects using ffmeg? At least mplayer do version 
>> > check for x264 in configure script.
>> I think I have to agree with Baptiste here because there is no API
>> change in libav* and if you are calling ffmpeg as an external program
>> there is no change either. This shouldn't affect you at all, and you
>> should be checking the libav* versions if you are using them anyway. A
>> change there implies potential breakage.
>> That said if you'd like to it's a simple #if X264_BUILD < 64 check to
>> add to the file.
> While ifdeffery in libx264.c doesn't look like a good idea due to the
> libx264 API instability, I think we could at least provide a check in
> the configure script to disable libx264 if the detected version isn't
> valid, looks nicer towards the user.

It's always been expected that uses should have a recent version of
libraries they build FFmpeg against.  Testing every little thing would
become such a chore.

> And while we're at it we could assert(X264_BUILD == x264_build()) in
> the init code (assuming that function is implemented).

It a little harsh with assert(), wouldn't you say?  In fact, this
shouldn't be needed at all, assuming libx264 uses correct shared
library versioning.

M?ns Rullg?rd
mans at mansr.com

More information about the ffmpeg-devel mailing list