[Ffmpeg-devel] swscale/img_convert confusion
Tue Oct 3 02:00:07 CEST 2006
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.
More information about the ffmpeg-devel