[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