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 :-) -- Integrate and enable ARMv5TE/v6/VFP and NEON optimisations from ffmpeg trunk for armel https://bugs.launchpad.net/bugs/383240 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
