Loïc Minier <[email protected]> writes: > 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
perhaps the kernel shouldn't advertise NEON hwcaps in this case then? > 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. Debian and ubuntu track the FFmpeg 0.5 release. From what I get of this thread of discussion, I believe the arm related changes have been implemented in the trunk branch of ffmpeg after 0.5 was branched of. I'd be against switching back to trunk because of instabilities it would cause in gstreamer0.10-ffmpeg, mplayer and vlc. You could literally feel the rate of bugreports dropping down after these package finally agreed on a common ffmpeg version to use. I'd rather suggest to backport the changes to the 0.5 release branch instead of tracking again ffmpeg trunk. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- 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
