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

Alexy galahad
Wed Jul 18 07:24:04 CEST 2007


 Thank you for the explanatory mail.

> 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.

 I doubted this too, the output buffer memory that i am giving is aligned to
32 bytes just to be sure. I have tried with arm4l configuration, but even
with that there is no change in the output (its still all zeroes). If i
disable optimizations while configuring ffmpeg (with --disable-opts), the
output has 0xffff thrown in once in a while in between a chunk of zeroes.

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.

 You are right, the ARM11 that i use does support hardware floating point,
it was my mistake. Sorry. But i dont think the libm that i use supports it
(i read on sourceforgery that they do not plan to support hardware fp's in
their libm's) the /proc/cpuinfo is given below. And yes, i am using

> 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.

 I will try these. Thank  you.

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.

Ok, i will check this out too.

Thank you for all the help guys..



1) my /proc/cpuinfo

Processor       : TI OMAP2430 (ARM1136JF-S) rev 5 (v6l)
BogoMIPS        : 219.54
Features        : swp half thumb fastmult vfp edsp java
CPU implementer : 0x41
CPU architecture: 6TEJ
CPU variant     : 0x0
CPU part        : 0xb36
CPU revision    : 5
Cache type      : write-back
Cache clean     : cp15 c7 ops
Cache lockdown  : format C
Cache format    : Harvard
I size          : 32768
I assoc         : 4
I line length   : 32
I sets          : 256
D size          : 32768
D assoc         : 4
D line length   : 32
D sets          : 256

Hardware        : OMAP24xx 2430SDP
Revision        : 24300124
Serial          : 0000000000000000

More information about the ffmpeg-devel mailing list