[Ffmpeg-devel] swscale/img_convert confusion
Mon Oct 2 15:10:40 CEST 2006
> On Thu, 2006-09-28 at 14:49 +1000, Richard Khoury wrote:
>> Based on an un-answered question in:
>> Hello all,
>> I'm writing code that may be compiled against new and old version of
>> the libav* libraries. With the latest SVN versions I've noticed that
>> if a new version of the libraries is configured with --enable-swscaler
>> then the img_convert function is compiled out.
>> How can I write code that can be compiled with both old and new
>> ffmpeg libraries in order to have either img_convert or swscale be
> The idea is that if you are using a version of libav* libraries that
> support swscale, you can use the swscale interface even if you did not
> configure with --enable-swscaler (in such case, libavcodec will
> "emulate" the swscale interface by using img_convert() and
> When swscale integration will be considered stable enough, I will
> increase something in the avcodec version so that user programs (or
> configure scripts) will be able to check if the swscale interface is
> supported or not.
> I hope this makes sense...
> As usual, I'll be very happy to go for a different strategy if someone
> has better proposals :)
How about write a version of img_convert() that calls swscale
appropriately? That way, no-one needs to check anything. This may
sound like bloat, but if it is simple to handle, then the bridge
function costs very little in library size. If it is complicated, then
the library really should provide a bridge.
General comment: There are a number of places where the user has to
write a bunch of code to handle inconsistencies in ffmpeg. (Case in
point: PTS.) It would be good if each "class" in ffmpeg provided strong
interface guarantees, and included the code to handle their own
More information about the ffmpeg-devel