Comment 4 for bug 383240

I think there are various different things here:
- ffmpeg has a mechanism to do multiple passes (multiple builds) and produce multiple shared libs which can be loaded by glibc's hwcaps-based selection mechanism automatically
- ffmpeg has grown some runtime detection of the feature (instead of build time selection / autodetection on the buildd)
- NEON was broken in hardware on imx51 TO1 which is all hardware which was around for jaunty

What we want:
i) karmic should use the latest ffmpeg
ii) the latest ffmpeg should use NEON automatically at runtime
iii) we want to backport key stuff to some PPA to show the NEON stuff based on jaunty (as it's impractical to play with karmic as it's still quite unstable)
iv) keep the Debian and Ubuntu packaging as identical as possible

I guess i) will happen as ffmpeg updates over the karmic cycle.

ii) and iv) are a bit tricky: are all SIMD features properly runtime detected in the latest ffmpeg? or is there still value in glibc-hwcaps-selected libs? which ARM configure flags can we safely turn on in the main armel build so that it's compatible with the Debian armel architecture expectations?
I think we want to enable everything which is fully runtime detected in the main armel build, then if anything else NEON remains we can consider building the special NEON pass to have an even more optimized library.

iii) should probably be discussed somewhere else I guess, but will happen after the karmic version works anyway :-)