[Ffmpeg-devel] swscale/img_convert confusion

[Fred Rothganger]

> On Thu, 2006-09-28 at 14:49 +1000, Richard Khoury wrote:
>   
>> Based on an un-answered question in:                                    
>> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-July/013262.html
>>
>> 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
>> used?
>>     
> 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
> img_resample()).
>
> 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 
variability internally.

-- Fred