[Ffmpeg-devel] Cross-compiling, OS X, and design questions

[Augie Fackler]

Hello everyone,

     My name is Augie Fackler. Some friends (Graham Booker and Chris  
Forsythe) and I are working to make a new QuickTime codec for OS X  
called Perian. It is based on ffmpeg and will be distributed as a  
Universal (fat) Binary.

     Unfortunately we have run into a few problems. As ffmpeg is  
something you folks have more experience with, we wanted to ask a few  
questions before making assumptions about design/implementation  
decisions.

     So without further ado, here are the questions we had:

#1 - The build system doesn't use GCC's built-in checking of  
endianness. Myself and the others assisting me in my endevours were  
wondering if there was a good reason for this, as we couldn't see one  
that was apparent. The more we worked on this codec, the more  
problems we had working around this. As of now, it is the most  
difficult problem that we need to resolve.

#2 - --cross-prefix is problematic when it comes to the naming  
conventions of available compilers. It assumes the layout of the  
cross compilers will be that of GCC's crosscompiler system, which  
isn't always the case. Darwin has {ar|ranlib|ld|etc} that know how to  
make binaries for the nonnative architecture of the machine, meaning  
that only the compiler needs to be changed in order to cross-compile  
binaries.

All of that said, we realize that this isn't the norm on Linux. where  
for instance compiling for arm-linux is done with the arm-linux-gcc,  
so that is what ffmpeg seems to be expecting. This seems to be the  
same with other tools.

This could be solved by a flag that tells configure that cross- 
compiling is being used without having to specify a prefix. One could  
then specify extra CFLAGS for use when cross-compiling that would  
allow for extra configuration. This would be very useful on a per- 
target basis as with the -arch flag on darwin.

#3 - We tried manually specifying the set of compiler options to  
cross-compile, but the fact that building a non-native binary  
produces a non-running executable causes the endianness check to  
fail. This also causes everything else to fail, resulting in a binary  
that assumes that the system is little- endian target system with no  
available vector processing (MMX, AltiVec, etc), and no utility  
functions such as lrintf(3).

Currently, we have been able to work around this issue by creating  
pre-made config.h and config.mak files for each architecture. By  
replacing these respective files after configure runs, the resulting  
binary can run successfully on each respective architecture. This,  
combined with use of lipo(1) as described by Apple's documents, has  
allowed us to successfully deploy the component on both Intel and PPC  
Macs with a single binary.

This system can easily break with minor updates to ffmpeg's svn (as  
we just saw with revision 5486). Unfortunately we cannot justify the  
current solution, as it is a maintenance nightmare on our end at least.

We would definitely love to work with the maintainers of ffmpeg in  
order to assist in resolving some/all of these issues. ffmpegX, VLC,  
and HandBrake are all OS X applications that would hopefully benefit  
from such a resolution to these (and other) difficulties on the Mac  
platform with ffmpeg.

Cheers,
Augie Fackler

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20060620/52dfb70b/attachment.pgp>