[gmane.comp.video.ffmpeg.devel] [PATCH] dynload for libfaac

[Reinhard Tartler]

On Di, Mar 02, 2010 at 17:18:33 (CET), Mark Shuttleworth wrote:

> On 02/03/10 12:13, Reinhard Tartler wrote:
>> On Di, Mar 02, 2010 at 09:40:10 (CET), Mark Shuttleworth wrote:
>>
>>   
>>> Do they build independently of one another? I.e. does libfaac know about
>>> ffmpeg at all? 
>>>     
>> no. libfaac is built completely independently of ffmpeg, and does not
>> reference or otherwise use libavcodec.
>>
>> libfaac provides a very slim API consisting of only 6 functions. the
>> file libavcodec/libfaac.c wraps these 6 functions in a way that the rest
>> of the ffmpeg infrastructure can use it.
>>
>> Moreover, upstream is working on an independent aac implementation, with
>> slow progress.
>>
>>   
>>> And can the patched version of ffmpeg build and run without libfaac at
>>> all?
>>>     
>> yes, only the header faac.h is required at build time. ( Although I
>> imagine it can be stripped down to a minimum.) At runtime, libavcodec is
>> fully useable without faac, but can use its additional functionality
>> (encoding to aac) if libfaac.so is found.
>>   
>
> It sounds to me like there is no derivative work relationship between
> the problematic piece, and ffmpeg. Is that true?

In general yes.

In jaunty, we did link statically against libfaac, which makes the
package unusable without libfaac. This is reflected by a hard
dependency. The proposed patch would circumwent that by detecting it at
runtime, rather than at compile time. However, so far it has only been
proposed, and is being blocked upstream for precisly this
disagreement. We could carry it as local patch in the ubuntu package,
though.

> We have a good relationship with SFLC, we could approach them ourselves
> and ask them to review the situation. But I'd be happier to do that if
> we were confident that we're on the right side of the facts.

I also have a good relationship with ffmpeg upstream (in fact, I
recently joined them for helping out with release management), but this
particular disagreement did make me raise concerns about the libfaac
package in general and the libavcodec-unstripped-51 package in jaunty in
particular.

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