Bug 61

Package rebuilt with -DRUNTIME_DETECTION

on Fedora 8 x86_64 
[root@kwizatz 8]# rpmlint ffmpeg-libs
ffmpeg-libs.x86_64: W: no-documentation
ffmpeg-libs.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libavutil.so.49.10.0 /lib64/libpthread.so.0
ffmpeg-libs.x86_64: E: shlib-with-non-pic-code /usr/lib64/libavcodec.so.51.71.0
ffmpeg-libs.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libpostproc.so.51.2.0 /lib64/libpthread.so.0
ffmpeg-libs.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libavfilter.so.0.1.0 /lib64/libpthread.so.0
ffmpeg-libs.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libswscale.so.0.6.1 /lib64/libpthread.so.0

This is strange for libavcodec on x86_64, it should be safe to enable -fPIC.

I will try to set-up benchmarks on Fedora 8 x86_64 with:
- current ffmpeg-0.4.9-0.49.20080908.fc8  
- rebuilt with -DRUNTIME_DETECTION
- rebuit with -DRUNTIME_DETECTION and with --cpu=athlon64 (which will enable cmov and fast cmov).

Yes, there's an issue. Upstream is aware of it, but they're reluctant to fix. I'll try to come up with an acceptable patch.

The problem is really serious as I cannot decode multimedia streams on my laptop without having the laptop to warm. whereas once -DRUNTIME_DETECTION is used at build time. It works really better.

Same with h264 HD contents on my X2 AMD 4200+. It is really sharp and smooth with -DRUNTIME_DETECTION and  dirty and with the currents options

Since this affect most mutlimedia packages provided in rpmfusion and the current fix "may" eventually need a rebuild of a newer ffmpeg which will introduce QA testing of the related applications. I would raise this bug as a BLOCKER for rpmfusion launch.

(In reply to comment #3)
> The problem is really serious as I cannot decode multimedia streams on my
> laptop without having the laptop to warm. whereas once -DRUNTIME_DETECTION is
> used at build time. It works really better.
> 
> Same with h264 HD contents on my X2 AMD 4200+. It is really sharp and smooth
> with -DRUNTIME_DETECTION and  dirty and with the currents options
> 
> Since this affect most mutlimedia packages provided in rpmfusion and the
> current fix "may" eventually need a rebuild of a newer ffmpeg which will
> introduce QA testing of the related applications. I would raise this bug as a
> BLOCKER for rpmfusion launch.

I don't consider it a blocker. What you found is an unsupported method, a leftover from the time when the related code was part of MPlayer. FFmpeg never had runtime cpu detection. At best it's a missing feature.

If your laptop is overheating than you have a hardware problem and it has nothing to do with FFmpeg.

> I don't consider it a blocker. What you found is an unsupported method, a
> leftover from the time when the related code was part of MPlayer. FFmpeg never
> had runtime cpu detection. At best it's a missing feature.
So please consider arguing why sse2 cannot be activated on x86 (with the "atlas kind of tweak" you told previously) and x86_64 (which is available for all CPU).

Or if it is not sse2, why others asm optimization (cmov, fastcmov) cannot be enabled on x86_64 ?

> If your laptop is overheating than you have a hardware problem and it has
> nothing to do with FFmpeg.
I'm not willing to receive this last as a serious argument. Please raise your argumentation level.

(In reply to comment #5)
> > I don't consider it a blocker. What you found is an unsupported method, a
> > leftover from the time when the related code was part of MPlayer. FFmpeg never
> > had runtime cpu detection. At best it's a missing feature.
> So please consider arguing why sse2 cannot be activated on x86 (with the "atlas
> kind of tweak" you told previously) and x86_64 (which is available for all
> CPU).
> 
> Or if it is not sse2, why others asm optimization (cmov, fastcmov) cannot be
> enabled on x86_64 ?

I never said asm optimisations cannot be enabled. However, we have to keep in mind that people might want use ffmpeg on low-end machines, too, which might not have SSE or 3DNow (or even MMX). For x86_32, I have an idea how to build sse-enabled (and perhaps 3DNow-enabled) libs and put them in %{_libdir}/sse{,2} and I'm going to implement it. For x86_64 it can all be enabled, of course (well, maybe except 3DNow(Ex), which is present only on amd64).

I've just committed something that should satisfy you. The upside is that i386 packages should really work even on i386 now, while SSE2-enabled CPUs will get a nice speed boost. I'm working on making FFmpeg capable of selecting all optimizations at runtime, but this should suffice for now. Also on ppc, the package should work on PowerPC G3 CPUs, while G4+ users can enjoy AltiVec-enabled versions automagically. The only downside is that the -libs package size is now doubled on i386, ppc and sparc.

I'm not very convinced by the improvements over -DRUNTIME_DETECT
BUT, we have a very hard problem with the current x264-libs not covered by selinux textel_t contexts. This will make the sse2/libx264.so.61 to be disabled by selinux by default

Since we got the last push of packages today for F-10 on the Fedora side, either there is a need to disable the sse2 on libx264 so they will be available in stable, and then to re-introduce it in updates once the selinux-policy-targeted have a appropriate context.
or we need to have the sse/libx264.so.61 fixed for selinux within the package (need to be in stable then).

In the ffmpeg case, the sse2 addtionals contexts have been added in the selinux-policy since it was reported by Rahul, the Nov 5th on selinus ml.

well, that's strange, the context seems here but it wasn't taken into account.

Ok  - So, since the performances request from the original message have been adressed (more or less). I will close this bug as fixed.
But it may remains some room of improvements about CPU optimization from this package or another, or the other side F-11 general performances with the similar ffmpeg package was dramatically improved.