gimp-gap ships a copy of ffmpeg

[Reinhard Tartler]

Thibaut Paumard <paumard at users.sourceforge.net> writes:

> Hi,
>
> I am the maintainer of the gimp-gap package (video plugin for the GIMP).

Hi, nice to meet you.

> It ships in its source a copy of two library packages, including ffmpeg.
>
> Those libraries are not built nor used in lenny. I am [1]trying to
> upload a new source package where they have been removed altogether. I
> think you will concur with me that it is important to do so,  especially
> for ffmpeg which is touchy legally-wise.

ffmpeg is GPL, therefore I so no licensing problems.

> [1] http://lists.debian.org/debian-mentors/2009/08/msg00098.html
>
> I am also trying to build the package against ffmpeg-debian, and here I
> need your help.
>
> The package uses functions which are present in the shared object but
> not in the public API: for this reason, I still need to ship
> audioconvert.h and imgconvert.h within gimp-gap.
>
> Worse, the function img_convert() is not present in libavcodec.so
> because ffmpeg is configured with CONFIG_SWSCALE.
>
> Since gimp-gap uses img_convert(), I need to compile this function
> directly in gimp-gap, and therefore to ship those additional files:
> libavcodec/imgconvert.c
> libavcodec/imgconvert_template.c
> libavcodec/dsputil.h
> libavcodec/colorspace.h
> libavutil/bswap.h
> libavutil/intreadwrite.h
>
> In total, shipping 10 files from ffmpeg-debian source is better than
> shipping a complete ffmpeg tarball, but still bad.
>
> So for the questions:
> - I don't get why CONFIG_SWSCALE inhibits building img_convert(). Having
> img_convert() in debian's ffmpeg would solve 80% of my problem.  Any
> hint why it is so?

img_convert() is part of the old, for years (!) deprecated scaler
API. It has been fully replaced by the libswscale API, which partly
overlaps with the old API. For this reason, they are mutually exclusive.

>
> - Any chance functions in audioconvert.h and imgconvert.h might get
> public?

Nope, I've tried (and I think successfully) for lenny, but will for sure
not do that again for squeeze. This was BTW announced on debian-devel
(sorry, no link at hand).

>
> - I believe upstreams shipping ffmpeg is fairly common, is there a more
> or less standard way to deal with that?

Port your package to libswscale, and forget about the old, deprecated
img_convert() API. If you need help, you can ask for help on the
libav-user mailing list.

Sorry if that was not the kind of answer you have hoped for :-(


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4