[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