On Wednesday 30 April 2008, Diego Biurrun wrote: [...]

...

...

The bug must be elsewhere. Where is mpeg2_mc_iwmmxt declared? And why is it declared on your machine?

This code refers to 'mpeg2_mc_iwmmxt' symbol, which is defined in 'motion_comp_iwmmxt.c' when HAVE_IWMMXT macro is enabled.

So either the code which refers to 'mpeg2_mc_iwmmxt' in 'motion_comp.c' should be hidden under conditional compilation too, or something more cluttered should be introduced.

Well, having one more look, turns out that now neither MPEG2_ACCEL_ARM nor MPEG2_ACCEL_ARM_IWMMXT flags get ever set in 'accel' variable, so these optimizations can not be activated. Looks like a lot has changed since I looked at this code last time.

This sounds more as if the HAVE_IWMMXT ifdef should be removed from motion_comp_iwmmxt.c. mpeg2_mc_init works fine on other platforms.

I suspect that some optimizations are not set on ARM. Please try the attached patch.

Naturally it does not help, because libmpeg2 tries to link with more iwmmx related symbols from libavcodec in this case: libmpeg2/motion_comp_iwmmxt.o:(.data+0x0): undefined reference to `put_pixels16_iwmmxt' libmpeg2/motion_comp_iwmmxt.o:(.data+0x4): undefined reference to `put_pixels16_x2_iwmmxt' libmpeg2/motion_comp_iwmmxt.o:(.data+0x8): undefined reference to `put_pixels16_y2_iwmmxt' libmpeg2/motion_comp_iwmmxt.o:(.data+0xc): undefined reference to `put_pixels16_xy2_iwmmxt' libmpeg2/motion_comp_iwmmxt.o:(.data+0x10): undefined reference to `put_pixels8_iwmmxt' libmpeg2/motion_comp_iwmmxt.o:(.data+0x14): undefined reference to `put_pixels8_x2_iwmmxt' libmpeg2/motion_comp_iwmmxt.o:(.data+0x18): undefined reference to `put_pixels8_y2_iwmmxt' libmpeg2/motion_comp_iwmmxt.o:(.data+0x1c): undefined reference to `put_pixels8_xy2_iwmmxt' libmpeg2/motion_comp_iwmmxt.o:(.data+0x20): undefined reference to `avg_pixels16_iwmmxt' libmpeg2/motion_comp_iwmmxt.o:(.data+0x24): undefined reference to `avg_pixels16_x2_iwmmxt' libmpeg2/motion_comp_iwmmxt.o:(.data+0x28): undefined reference to `avg_pixels16_y2_iwmmxt' libmpeg2/motion_comp_iwmmxt.o:(.data+0x2c): undefined reference to `avg_pixels16_xy2_iwmmxt' libmpeg2/motion_comp_iwmmxt.o:(.data+0x30): undefined reference to `avg_pixels8_iwmmxt' libmpeg2/motion_comp_iwmmxt.o:(.data+0x34): undefined reference to `avg_pixels8_x2_iwmmxt' libmpeg2/motion_comp_iwmmxt.o:(.data+0x38): undefined reference to `avg_pixels8_y2_iwmmxt' libmpeg2/motion_comp_iwmmxt.o:(.data+0x3c): undefined reference to `avg_pixels8_xy2_iwmmxt' There is one important thing to note. These iwmmxt optimized functions from libavcodec are implemented as inline assemby. And gnu assembler refuses to compile code which uses instructions not supported by the processor currently selected with -mcpu/-march option. Actually this feature is now used for cpu capabilities detection in MPlayer/FFmpeg configure: ============ Checking for iWMMXt (Intel XScale SIMD instructions) ============ int main(void) { __asm__ __volatile__ ("wunpckelub wr6, wr4"); } cc -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4 -pipe -ffast-math -fomit-frame-pointer -o /var/tmp/mplayer-conf-4392-23942 /var/tmp/mplayer-conf-10073-23942.c /var/tmp/mplayer-conf-10073-23942.c: In function `main': /var/tmp/mplayer-conf-10073-23942.c:3: warning: control reaches end of non-void function {standard input}: Assembler messages: {standard input}:14: Error: selected processor does not support `wunpckelub wr6,wr4' Result is: no ============================================================================== So iwmmxt inline assembly will just fail co compile. If you are still want to go this route (linking all the functions optimized for various cpu instruction set extensions and selecting them at runtime), you can try one of the following options: 1) Insert the following line into the beginning of 'dsputil_iwmmxt.c' and 'mpegvideo_iwmmxt.c' source files (this requires a patch for FFmpeg): asm (".arch iwmmxt\n"); 2) Try to pass '-mcpu=all' to gnu assebler via '-Xassembler' or '-Wa,' gcc options and hope that it works. But anyway, wouldn't it be better to reconsider my original trivial two lines patch as a fix for this compilation breakage? Or you are not looking for an easy way? ;)

Also, isn't libavcodec faster for MPEG-1/2 decoding on ARM?

They have more or less similar performance, but libavcodec clearly wins for me at the moment because it supports more features (framedropping and lowres decoding). Actually I'm not that much interested in libmpeg2. PS. The part of patch which reenables optimization bits in 'accel' looks ok. -- Best regards, Siarhei Siamashka