Do you get the corruption with MPlayer or with my player (or both)?
OK, next step. How did you build FFmpeg? Which compiler?
looking at the video, I would say the corruption is at a macroblock level, so I would say the decoding is not OK.
You can see some "trails" of broken content moving with the motion, so reference frames are getting corrupted.
ffmpeg has a regression test that compares output bitstreams vs "known good", did you run that on the platform?
Since the corruption is mostly confined to areas with motion, I would
suspect the motion compensation related functions.
> ffmpeg has a regression test that compares output bitstreams vs "known good",
> did you run that on the platform?
Even if someone did have the patience to run the regression tests on ARM,
they would fail due to some subtle differences somewhere, resulting in
harmless +-1 differences in the output frames.
The odd thing is, the code works perfectly on my Beagle.
>> OK, next step. How did you build FFmpeg? Which compiler?
> Built with OE, gcc 4.3.1, I'm doing a build from scratch with
> csl2007q3 now.
just a side note, 2007q3 has a bug with -Os on the OMAP3, 2008q1 fixes this.
I don't trust gcc 4.3 the slightest bit. I've been using csl2007q3
Does 2008q1 work properly with NEON? I heard reports it was
somehow broken, and didn't bother testing it myself.
- Vectorization + NEON is broken
- building static binaries with cortex-a8 flag (or any ARMv7a core) is broken
- some armv6 compilations end in ICE.
This looks too bad to even consider using it.
to clarify, we just picked one patch from 2008q1 into 2007q3 which fixed -Os.
--- arm-2007q3-51-arm-uclinuxeabi/gcc-4.2/gcc/config/arm/arm.c 2007-09-27 17:51:00.000000000 +0200
+++ arm-2008q1-152-arm-uclinuxeabi/gcc-4.2/gcc/config/arm/arm.c 2008-04-18 03:44:35.000000000 +0200
@@ -11591,7 +11647,8 @@
&& count != 0
&& bit_count(saved_regs_mask) * 4 == count
- && !IS_INTERRUPT (func_type))
+ && !IS_INTERRUPT (func_type)
+ && !cfun->tail_call_emit)
unsigned long mask;
mask = (1 << (arm_size_return_regs() / 4)) - 1;
My understanding was that it was corrected:
Koen and Mans probably know more about that.
That was a bug in my code. It worked by accident with older gcc
> anyone know where the failure is when compiling the kernel with this
> toolchain and why we are still using csl2007q3 in Angstrom?
If built with gcc 4.3, the kernel used to crash early during boot, as
discussed in http://thread.gmane.org/gmane.linux.ports.arm.general/10760
This was fixed in 2.6.27-rc4, so it's included in recent linux-omap
I haven't tried building with gcc 4.3, so I don't know whether other
bugs are lurking.
I just came across this old commit:
They say history repeats itself...
There was a recent patch to the -rc kernel.org git repo that made 4.3 suddenly
work for me and EABI targets. I think it was this one:
Author: Nicolas Pitre <ni...@cam.org>
Date: Tue Aug 12 22:10:59 2008 +0100
[ARM] 5196/1: fix inline asm constraints for preload
With gcc 4.3 and later, a pointer that has already been dereferenced is
assumed not to be null since it should have caused a segmentation fault
otherwise, hence any subsequent test against NULL is optimized away.
Current inline asm constraint used in the implementation of prefetch()
makes gcc believe that the pointer is dereferenced even though the PLD
instruction does not load any data and does not cause a segmentation
fault on null pointers, which causes all sorts of interesting results
when reaching the end of a linked lists for example.
Let's use a better constraint to properly represent the actual usage of
the pointer value.
Problem reported by Chris Steel.
diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index b01d5e7..517a4d6 100644
@@ -112,9 +112,9 @@ extern int kernel_thread(int (*fn)(void *), void *arg,
unsigned long flags);
static inline void prefetch(const void *ptr)
- : "o" (*(char *)ptr)
+ : "p" (ptr)