[osg-users] Problem compiling latest trunk, ffmpeg problem

J.P. Delport jpdelport at csir.co.za
Mon Mar 2 05:26:19 PST 2009


Hi,

Robert Osfield wrote:
> Hi J.P,
> 
> On Mon, Mar 2, 2009 at 12:34 PM, J.P. Delport <jpdelport at csir.co.za> wrote:
>> The one I compiled with LGPL only, has the sws functions in libavcodec.so.
>>
>> nm ./libavcodec/libavcodec.so | grep sws
>> 0008c1b0 T sws_freeContext
>> 0008d1f0 T sws_getCachedContext
>> 0008d0f0 T sws_getContext
>> 0008caf0 T sws_scale
> 
> I just updated my ffmpeg to latest in svn and it defines the above
> methods, but doesn't declare them in the headers.

Yes, it seems they still want you to use swscale.h (which is LGPL), but 
it seems it is not installed by the build process.

> 
>> This is going to depend a lot on what the repositories compile by default. I
>> know the debian ones from http://www.debian-multimedia.org/ has swscaler
>> compiled in by default. So has the ubuntu packages if I remember correctly.
>> A guy here that uses gentoo does not have swscale, but has the lgpl version.
>>
>> To cover everything we would need to check:
>> if (img_resample available) {
>>        use it (Tanguys code)
>>        do not link to swscale
>> } else {
>>        use swscale
>>        if (swscale in libavcodec) {
>>                do not link to swscale
>>        } else {
>>                link to swscale
>>        }
>> }
> 
> Ack... a pretty horrible matrix to test/build against.

Welcome to the wonderful world of ffmpeg :)

After working with it for a while, I do understand the suggestion made 
at one point to just include a copy of their code in one's own repository.

> 
>> One gotcha, we need the swscale header to be installed even in libswscale is
>> not installed. The header is LGPL tho.
> 
> I tried to compile ffmpeg with libswscale but it wouldn't build it
> without it --enable-gpl, and without this when I do an install the
> libswscale headers are not installed.  I could copy the header across
> by hand but this really isn't a viable solution for end users of the
> OSG.

Yes, I'm not sure how to work around this. It seems to be a problem with 
their build system. I'm not sure how the distros that distrib the lgpl 
versions cope with this. Maybe they add the file manually?

> 
> I guess we could declare the missing functions on the OSG side - if
> the ffmpeg has these functions built into it, this is rather asking
> for a build break though.

Yes, I don't think this would be a good option.

> 
> I'm tempted to just go implement the conversion colour conversion
> ourselves, 

The colour conversion just cries for a shader yes :), but beware that 
even though there are a few normal cases e.g. yuv420 -> rgb, there are a 
myriad of other less used cases.

 > and provide a simple CPU based conversion that is
 > relatively inefficient but at least works on all ffmpeg versions

Would you restrict "all versions" to all distributed (packaged by 
distro) versions?

I'm not sure how many people would compile ffmpeg themselves?

jp

> 
> Robert.
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their support.




More information about the osg-users mailing list