[rbultje@localhost ffmpeg]$ grep -r RUNTIME_CPUDETECT .
./libavutil/common.h:#if __CPU__ >= 686 && !defined(RUNTIME_CPUDETECT)
./libavcodec/libpostproc/postprocess.c:#if !defined (HAVE_MMX) || defined
(RUNTIME_CPUDETECT)
./libavcodec/libpostproc/postprocess.c:#if (defined (HAVE_MMX) && !defined
(HAVE_3DNOW) && !defined (HAVE_MMX2)) || defined (RUNTIME_CPUDETECT)
./libavcodec/libpostproc/postprocess.c:#if defined (HAVE_MMX2) || defined
(RUNTIME_CPUDETECT)
./libavcodec/libpostproc/postprocess.c:#if (defined (HAVE_3DNOW) && !defined
(HAVE_MMX2)) || defined (RUNTIME_CPUDETECT)
./libavcodec/libpostproc/postprocess.c:#ifdef RUNTIME_CPUDETECT
./libavcodec/libpostproc/postprocess.c:#else //RUNTIME_CPUDETECT
./libavcodec/libpostproc/postprocess.c:#endif //!RUNTIME_CPUDETECT

It's only used in libpostproc and in libavutil/common.h for a 3-byte-at-once
assignment. Although useful, I seriously doubt this does what it should do. I
know, for sure, that ffmpeg does mmx CPU detection itself.

Please correct me if I'm wrong, but this seems pretty useful in 
libavcodec/libpostproc/postprocess.c:
#ifdef RUNTIME_CPUDETECT
#if defined(ARCH_X86) || defined(ARCH_X86_64)
...
#else
#ifdef ARCH_POWERPC
#ifdef HAVE_ALTIVEC
        if(c->cpuCaps & PP_CPU_CAPS_ALTIVEC)
                postProcess_altivec(src, srcStride, dst, dstStride, width,
height, QPs, QPStride, isColor, c);
        else
#endif
#endif
                postProcess_C(src, srcStride, dst, dstStride, width, height,
QPs, QPStride, isColor, c);
#endif
#else //RUNTIME_CPUDETECT
#ifdef HAVE_MMX2
...
#elif defined (HAVE_ALTIVEC)
        postProcess_altivec(src, srcStride, dst, dstStride, width, height, QPs,
QPStride, isColor, c);
...
#endif //!RUNTIME_CPUDETECT

I understand that as:
- if you build with HAVE_ALTIVEC, then Altivec will be used if run on PPC
- if you build with HAVE_ALTIVEC and RUNTIME_CPUDETECT, then Altivec will be
used if available

I agree that RUNTIME_CPUDETECT is not widely used, but it seems quite useful for
precisely for Altivec.

Bye,

Agreed, for libpp. For ffmpeg, it won't help. :-(.

Is this still a bug?

Andy, the flag would be useful for a part of ffmpeg, but does not cover all usages of CPU-specific assembly.  Details follow.


In general, building gst-ffmpeg on a CPU might create binaries that require a CPU with at least the same capacities, but this is often undesired for distribution (where buildd machines are fast CPUs but you want the binaries to run on all machines supported for that arch and that dist).

The libpostproc part is #ifdef'd so that by default libpp will be optimized at build-time, the suggested flag moves the optimization to runtime.  Other parts than libpp are not #ifdef and are unconditionally build time optimized.

This is especially a problem under PPC.

Now I initially opened this bug because I thought -DRUNTIME_CPUDETECT was enough for the whole of ffmpeg, and thought it would make more sense for it to be the default.  Since the autotools-ization of gst-ffmpeg is written by GStreamer, this was discussed here.  However, my assumption turned out to be false, and this could be considered a ffmpeg bug for the ffmpeg project to deal with first.

I'll let you decide whether this bug should stay open as a reminder that gst-ffmpeg does not generate portable PPC binaries by default, nor can be configured to do so.

Cheers,

Is this still a bug?

This is related to postproc which no longer exists.