Debugging mediaplayer corruption issues
koen
Mans wrote the NEON support for mplayer[1], a player to make use of
the omapfb overlays[2] and kernel patches to fix the overlay
driver[3].
The 720p mp4 version of Big Buck Bunny[5] almost plays in realtime at
500MHz with all this. The problem is that I'm seeing image corruption
during playback and I don't know where the problem lays: kernel, gcc,
glibc, ffmpeg, something else...
You can get a kernel, rootfs and static player binary from [4], see
the README on how to set vars in uboot to activate the overlay.
It would be great if we can track down this issue before the LRL demo
next week.
regards,
Koen
[1]
http://git.mansr.com/?p=ffmpeg.mru;a=blob;f=libavcodec/armv4l/simple_idct_neon.S;h=943e04fc2de8b15eb7452518915048b474ed7582;hb=refs/heads/arm-neon
[2] http://git.mansr.com/?p=omapfbplay;a=summary
[3] http://gitweb.openembedded.net/?p=org.openembedded.dev.git;a=commit;h=c7be2f3d0445df58161d089994d301a3491d55ea
[4] http://amethyst.openembedded.net/~koen/beagleboard/overlay/
[5] http://www.bigbuckbunny.org/index.php/download/
koen
http://amethyst.openembedded.net/~koen/beagleboard/beagle-image-corruption.avi
On 10 jul, 14:29, koen <koen.k...@gmail.com> wrote:
> Hi,
>
> Mans wrote the NEON support for mplayer[1], a player to make use of
> the omapfb overlays[2] and kernel patches to fix the overlay
> driver[3].
>
> The 720p mp4 version of Big Buck Bunny[5] almost plays in realtime at
> 500MHz with all this. The problem is that I'm seeing image corruption
> during playback and I don't know where the problem lays: kernel, gcc,
> glibc, ffmpeg, something else...
>
> You can get a kernel, rootfs and static player binary from [4], see
> the README on how to set vars in uboot to activate the overlay.
>
> It would be great if we can track down this issue before the LRL demo
> next week.
>
> regards,
>
> Koen
>
> [2]http://git.mansr.com/?p=omapfbplay;a=summary
> [3]http://gitweb.openembedded.net/?p=org.openembedded.dev.git;a=commit;h...
Måns Rullgård
koen wrote:
>
> Hi,
>
> Mans wrote the NEON support for mplayer[1], a player to make use of
> the omapfb overlays[2] and kernel patches to fix the overlay
> driver[3].
>
> The 720p mp4 version of Big Buck Bunny[5] almost plays in realtime at
> 500MHz with all this. The problem is that I'm seeing image corruption
> during playback and I don't know where the problem lays: kernel, gcc,
> glibc, ffmpeg, something else...
>
> You can get a kernel, rootfs and static player binary from [4], see
> the README on how to set vars in uboot to activate the overlay.
>
> It would be great if we can track down this issue before the LRL demo
> next week.
Do you get the corruption with MPlayer or with my player (or both)?
--
Måns Rullgård
ma...@mansr.com
koen
regards,
Koen
Måns Rullgård
Vladimir Pantelic
> If forgot to mention that it looks like this:
> http://amethyst.openembedded.net/~koen/beagleboard/beagle-image-corruption.avi
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?
Måns Rullgård
Vladimir Pantelic wrote:
>
> koen wrote:
>> If forgot to mention that it looks like this:
>> http://amethyst.openembedded.net/~koen/beagleboard/beagle-image-corruption.avi
>
> 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.
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.
--
Måns Rullgård
ma...@mansr.com
koen
csl2007q3 now.
regards,
Koen
>
> --
> Måns Rullgård
> m...@mansr.com
Vladimir Pantelic
>> 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.
Måns Rullgård
koen wrote:
>
>
>
> On 10 jul, 16:28, Måns Rullgård <m...@mansr.com> wrote:
>> koen wrote:
>>
>> > On 10 jul, 16:22, Måns Rullgård <m...@mansr.com> wrote:
>> >> koen wrote:
>>
>> >> > Hi,
>>
>> >> > Mans wrote the NEON support for mplayer[1], a player to make use of
>> >> > the omapfb overlays[2] and kernel patches to fix the overlay
>> >> > driver[3].
>>
>> >> > The 720p mp4 version of Big Buck Bunny[5] almost plays in realtime at
>> >> > 500MHz with all this. The problem is that I'm seeing image corruption
>> >> > during playback and I don't know where the problem lays: kernel, gcc,
>> >> > glibc, ffmpeg, something else...
>>
>> >> > You can get a kernel, rootfs and static player binary from [4], see
>> >> > the README on how to set vars in uboot to activate the overlay.
>>
>> >> > It would be great if we can track down this issue before the LRL demo
>> >> > next week.
>>
>> >> Do you get the corruption with MPlayer or with my player (or both)?
>>
>> > both
>>
>> 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.
I don't trust gcc 4.3 the slightest bit. I've been using csl2007q3
all along.
--
Måns Rullgård
ma...@mansr.com
Måns Rullgård
Does 2008q1 work properly with NEON? I heard reports it was
somehow broken, and didn't bother testing it myself.
--
Måns Rullgård
ma...@mansr.com
Laurent Desnogues
>
> Does 2008q1 work properly with NEON? I heard reports it was
> somehow broken, and didn't bother testing it myself.
With 2008q1:
- 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.
Laurent
Vladimir Pantelic
to clarify, we just picked one patch from 2008q1 into 2007q3 which fixed -Os.
koen
>
> >> Does 2008q1 work properly with NEON? I heard reports it was
> >> somehow broken, and didn't bother testing it myself.
>
> > With 2008q1:
>
> > - 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.
regards,
Koen
koen
Måns Rullgård
That's good news. If it can't compile the kernel, I don't trust it.
FFmpeg is quite good at triggering compiler bugs.
--
Måns Rullgård
ma...@mansr.com
Syed Mohammed, Khasim
dan...@gmail.com
Sent via BlackBerry from T-Mobile
-----Original Message-----
From: Måns Rullgård <ma...@mansr.com>
Date: Thu, 10 Jul 2008 20:11:18
To: <beagl...@googlegroups.com>
Subject: [beagleboard] Re: Debugging mediaplayer corruption issues
koen
On 10 jul, 21:11, Måns Rullgård <m...@mansr.com> wrote:
also fix the bug with gcc 4.3.1.
Vladimir Pantelic
--- 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
&& !current_function_calls_eh_return
&& 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;
Jason Kridner
On Jul 11, 2:59 am, koen <koen.k...@gmail.com> wrote:
> On 10 jul, 21:11, Måns Rullgård <m...@mansr.com> wrote:
>
>
>
> > koen <koen.k...@gmail.com> writes:
> > > On 10 jul, 17:09, Måns Rullgård <m...@mansr.com> wrote:
> > >> koen wrote:
>
> > >> > On 10 jul, 16:28, Måns Rullgård <m...@mansr.com> wrote:
> > >> >> koen wrote:
>
> > >> >> > On 10 jul, 16:22, Måns Rullgård <m...@mansr.com> wrote:
> > >> >> >> koen wrote:
>
> > >> >> >> > Hi,
>
> > >> >> >> > Mans wrote the NEON support for mplayer[1], a player to make use of
>
> > >> >> >> > The 720p mp4 version of Big Buck Bunny[5] almost plays in realtime at
> > >> >> >> > 500MHz with all this. The problem is that I'm seeing image corruption
> > >> >> >> > during playback and I don't know where the problem lays:kernel, gcc,
> > >> >> >> > glibc, ffmpeg, something else...
>
>
> > >> >> >> > It would be great if we can track down this issue before the LRL demo
> > >> >> >> > next week.
>
> > >> >> >> Do you get the corruption with MPlayer or with my player (or both)?
>
> > >> >> > both
>
> > >> >> OK, next step. How did you build FFmpeg? Which compiler?
>
>
> > >> I don't trust gcc 4.3 the slightest bit. I've been using csl2007q3
> > >> all along.
>
> > > A build with 2007q3 makes it work without image corruption :)
>
>
>
anyone know where the failure is when compiling the kernel with this
toolchain and why we are still using csl2007q3 in Angstrom?
Laurent Desnogues
>
>> This commit:http://git.mansr.com/?p=ffmpeg.mru;a=commitdiff;h=14a339339ad6b9cfd00...
>> also fix the bug with gcc4.3.1.
>>
>
> This only fixes it for FFmpeg and not the kernel, correct? Does
> anyone know where the failure is when compiling the kernel with this
> toolchain and why we are still using csl2007q3 in Angstrom?
My understanding was that it was corrected:
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=5196/1
Koen and Mans probably know more about that.
Laurent
Måns Rullgård
That was a bug in my code. It worked by accident with older gcc
versions.
> 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
git trees.
I haven't tried building with gcc 4.3, so I don't know whether other
bugs are lurking.
--
Måns Rullgård
ma...@mansr.com
Måns Rullgård
I just came across this old commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=02828845dda5ccf921ab2557c6ca17b6e7fc70e2
They say history repeats itself...
--
Måns Rullgård
ma...@mansr.com
Bill Gatliff
>
>> This commit:http://git.mansr.com/?p=ffmpeg.mru;a=commitdiff;h=14a339339ad6b9cfd00...
>> also fix the bug with gcc4.3.1.
>
> This only fixes it for FFmpeg and not the kernel, correct? Does
> anyone know where the failure is when compiling the kernel with this
> toolchain and why we are still using csl2007q3 in Angstrom?
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:
commit 16f719de62809e224e37c320760c3ce59098d862
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.
Signed-off-by: Nicolas Pitre <ni...@marvell.com>
Signed-off-by: Russell King <rmk+k...@arm.linux.org.uk>
diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index b01d5e7..517a4d6 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -112,9 +112,9 @@ extern int kernel_thread(int (*fn)(void *), void *arg,
unsigned long flags);
static inline void prefetch(const void *ptr)
{
__asm__ __volatile__(
- "pld\t%0"
+ "pld\t%a0"
:
- : "o" (*(char *)ptr)
+ : "p" (ptr)
: "cc");
}
b.g.
--
Bill Gatliff
bg...@billgatliff.com