[FFmpeg-devel] Issue with ffmpeg mp3 decoder on ARM11

[Siarhei Siamashka]

On Tuesday 17 July 2007 10:27, Alexy wrote:

>  Thank you for the help. I checked the file you mentioned,
> ALT_BITSTREAM_READER was already enabled (maybe because i had tried
> building ffmpeg with arch=<blank> )

Normally A32_BITSTREAM_READER is used on ARM. If you enforced some 
nonstandard configuration, also beware of various possible bugs which may be 
caused by it. For example, many ARM devices require strict alignment and
unaligned memory accesses will cause various bugs (the result of memory
read/write operation may differ from what you expect). Though ARM11 supports
unaligned memory access in hardware, it may be disabled. At least it is
disabled on Nokia N800 (which uses OMAP2420) in current version of its
firmware. So be sure to check all the configure options or just try a standard
default configuration first.

> Some more things i could find out.
>
> 1) The input to the MP3 decoder is matching on arm and on linux.
>
> 2) I am using the gcc 3.3.2 compiler, but the libs on the filesystems are
> built using 3.4.4. When i configure ffmpeg with the 3.4.4 libs,
> config.errtalks about the libraries using hardware fp. As far as i
> could know ARM does
> not have hardware fp. Could this be a problem? Detailed log is given below.

ARM11 may have hardware floating point support. Try to check /proc/cpuinfo
on your device as M?ns suggested, if it lists 'vfp', you have hardware
floating point supported. I suspect that the possibility of your OMAP2430 
(I guess it from some paths in your compiler output) having hardware
floating point supported is very high.

[...]

> The gcc tool chain -v gives this output

[...]

>ld: ERROR:
> /usr/local/arm/3.3.2/lib/gcc-lib/arm-linux/3.3.2/../../../../arm-linux/lib/
>crtn.o uses hardware FP, whereas /tmp/ffmpeg-conf-25060-14931-18692 uses
> software FP
> File format not recognized: failed to merge target specific data of file
> /usr/local/arm/3.3.2/lib/gcc-lib/arm-linux/3.3.2/../../../../arm-linux/lib/
>crtn.o collect2: ld returned 1 exit status
> C compiler test failed.

Though ffmp3 is a fixed point decoder, it contains a bit of floating point
math in performance non-critical parts of code (mostly initialization). If
floating point support is broken in your compiler, it may have caused the
bugs you are seeing. You can try to compile a few simple test programs 
using floating point math to check if your compiler generates binaries that
can be executed and work properly on your device. If some simple 
examples break, you should try to fix that first before doing further
experiments with ffmpeg.

By the way, you may want to also check libmad as alternative fixed point mp3
decoder, it is even a bit faster than ffmp3 on ARM right now.