Debugging mediaplayer corruption issues

1195 views
Skip to first unread message

koen

unread,
Jul 10, 2008, 8:29:20 AM7/10/08
to Beagle Board
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



[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

unread,
Jul 10, 2008, 8:46:49 AM7/10/08
to Beagle Board
If forgot to mention that it looks like this:
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
>
> [1]http://git.mansr.com/?p=ffmpeg.mru;a=blob;f=libavcodec/armv4l/simple_...
> [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

unread,
Jul 10, 2008, 10:22:51 AM7/10/08
to beagl...@googlegroups.com

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

unread,
Jul 10, 2008, 10:25:05 AM7/10/08
to Beagle Board
both

regards,

Koen

Måns Rullgård

unread,
Jul 10, 2008, 10:28:34 AM7/10/08
to beagl...@googlegroups.com

OK, next step. How did you build FFmpeg? Which compiler?

--
Måns Rullgård
ma...@mansr.com

Vladimir Pantelic

unread,
Jul 10, 2008, 10:32:46 AM7/10/08
to beagl...@googlegroups.com
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.

ffmpeg has a regression test that compares output bitstreams vs "known good", did you run that on the platform?

Måns Rullgård

unread,
Jul 10, 2008, 10:40:36 AM7/10/08
to beagl...@googlegroups.com

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

unread,
Jul 10, 2008, 10:50:41 AM7/10/08
to Beagle Board
Built with OE, gcc 4.3.1, I'm doing a build from scratch with
csl2007q3 now.

regards,

Koen



>
> --
> Måns Rullgård
> m...@mansr.com

Vladimir Pantelic

unread,
Jul 10, 2008, 11:07:57 AM7/10/08
to beagl...@googlegroups.com
koen wrote:

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

unread,
Jul 10, 2008, 11:09:22 AM7/10/08
to beagl...@googlegroups.com

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

unread,
Jul 10, 2008, 11:15:19 AM7/10/08
to beagl...@googlegroups.com

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

unread,
Jul 10, 2008, 11:24:50 AM7/10/08
to beagl...@googlegroups.com
On Thu, Jul 10, 2008 at 5:15 PM, Måns Rullgård <ma...@mansr.com> wrote:
>
> 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

unread,
Jul 10, 2008, 11:41:09 AM7/10/08
to beagl...@googlegroups.com

to clarify, we just picked one patch from 2008q1 into 2007q3 which fixed -Os.


koen

unread,
Jul 10, 2008, 11:56:25 AM7/10/08
to Beagle Board


On 10 jul, 17:41, Vladimir Pantelic <p...@nt.tu-darmstadt.de> wrote:
> Laurent Desnogues wrote:
> > On Thu, Jul 10, 2008 at 5:15 PM, Måns Rullgård <m...@mansr.com> wrote:
>
> >> 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.

Is that patch public?

regards,

Koen

koen

unread,
Jul 10, 2008, 2:41:52 PM7/10/08
to Beagle Board
A build with 2007q3 makes it work without image corruption :)

> --
> Måns Rullgård
> m...@mansr.com

Måns Rullgård

unread,
Jul 10, 2008, 3:11:18 PM7/10/08
to beagl...@googlegroups.com
koen <koen...@gmail.com> writes:

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

unread,
Jul 10, 2008, 10:17:04 PM7/10/08
to beagl...@googlegroups.com
Great job, congrats all...

dan...@gmail.com

unread,
Jul 11, 2008, 12:42:36 AM7/11/08
to beagl...@googlegroups.com
0
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

unread,
Jul 11, 2008, 3:59:53 AM7/11/08
to Beagle Board


On 10 jul, 21:11, Måns Rullgård <m...@mansr.com> wrote:
This commit: http://git.mansr.com/?p=ffmpeg.mru;a=commitdiff;h=14a339339ad6b9cfd00da21557c9c5d17cc6a372
also fix the bug with gcc 4.3.1.

Vladimir Pantelic

unread,
Jul 11, 2008, 9:17:20 AM7/11/08
to beagl...@googlegroups.com

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

unread,
Sep 5, 2008, 3:47:10 PM9/5/08
to Beagle Board


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 omapfb overlays[2] andkernelpatches 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 akernel, 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, gcc4.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.
>
> > > A build with 2007q3 makes it work without image corruption :)
>
> > That's good news.  If it can'tcompilethekernel, I don't trust it.
> > FFmpeg is quite good at triggering compiler bugs.
>
> 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?

Laurent Desnogues

unread,
Sep 5, 2008, 4:11:15 PM9/5/08
to beagl...@googlegroups.com
On Fri, Sep 5, 2008 at 9:47 PM, Jason Kridner <jkri...@gmail.com> wrote:
>
>> 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

unread,
Sep 5, 2008, 4:15:46 PM9/5/08
to beagl...@googlegroups.com
Jason Kridner <jkri...@gmail.com> writes:

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

unread,
Sep 5, 2008, 4:23:44 PM9/5/08
to beagl...@googlegroups.com
"Laurent Desnogues" <laurent....@gmail.com> writes:

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

unread,
Sep 5, 2008, 3:57:34 PM9/5/08
to beagl...@googlegroups.com
Jason Kridner wrote:
>
>> 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

Reply all
Reply to author
Forward
0 new messages