Comment 5 for bug 383240

Loïc Minier <email address hidden> 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