[Ffmpeg-devel] swscale/img_convert confusion

[Richard Khoury]

 In the year 2006, of the Month of October, on the  2th day, Fred Rothganger wrote:
>    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.
> 
This was the solution I had in mind. If img_convert() can be set up to
wrap swscale when configured in, then the interface will remain the
same and I'll be able to compile my program against pre-swscale and
post-swscale versions of libav* libraries. The most important thing
for me is that I can't guarantee if the user of my code will have an
ffmpeg version compiled with swscale or not, and I need to make my
software compatible in both cases.

>    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.
> 
I've been using the ffmpeg libraries since 0.4.8 and the lack of a
strong/consistant interface is what is the most annoying aspect of
using this otherwise brilliant library. I can understand the need for
a library to require an API change every so often, but I think that
getting rid of img_convert() in this case is completely unnecessary.

Thanks for both your replies, Luca and Fred.

RichieK.