Debugging mediaplayer corruption issues

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/

If forgot to mention that it looks like this:
http://amethyst.openembedded.net/~koen/beagleboard/beagle-image-corruption.avi

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

regards,

Koen

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

koen wrote:

If forgot to mention that it looks like this:
Openembedded-Hotels, Villen, Unterkünfte in Leipzig

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?

Vladimir Pantelic wrote:

koen wrote:

If forgot to mention that it looks like this:
Openembedded-Hotels, Villen, Unterkünfte in Leipzig

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.

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

regards,

Koen

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.

koen wrote:

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

Vladimir Pantelic wrote:

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.

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

Laurent Desnogues wrote:

Is that patch public?

regards,

Koen

koen wrote:

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

A build with 2007q3 makes it work without image corruption :slight_smile:

koen <koen.kooi@gmail.com> writes:

Great job, congrats all…

0

koen <koen.k...@gmail.com> writes:
>> koen wrote:

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

> A build with 2007q3 makes it work without image corruption :slight_smile:

That's good news. If it can't compile the kernel, 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=14a339339ad6b9cfd00da21557c9c5d17cc6a372
also fix the bug with gcc 4.3.1.

regards,

Koen

koen wrote:

Laurent Desnogues 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?

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