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.
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)?
> 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?
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?
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.
>> > 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.
>> > 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.
>> >> > 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
>> >> >> > 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
That's good news. If it can't compile the kernel, I don't trust it.
FFmpeg is quite good at triggering compiler bugs.
>> 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.