Video rendering on Pandaboard/Pandabaord ES is slow

[Emmanuel Deloget]

Hello, 

I installed the near-latest (yesterday) trunk on two systems - one Pandaboard and one Pandaboard ES. Here are the build command lines : 

$ make geexbox-xbmc-omap4-pandaboard_defconfig

$ make

(faced the known make-3.81 issue, copy the correct tarball in the make source directory, et restart make)

Compilation went ok. I noticed that the know problem with gstreamer has been "corrected" by not building gstreamer at all. 

Install went ok (copy boot/* on a VFAT, and the tar.gz content on an ext4 FS on a Sandisk Extreme SD/HC (advertised bandwidth: 30MB/s)). 

Boot went ok (I'm also facing some sound-related issue, but that's not the subject here.)

The problem I'm trying to solve is related to video playback: playing an full HD h.264 video is painfully slow, with around 2 to 4 frames per second. I face a similar issue when I try to play videos that come from the web (I installed the Funny or Die video addon). On web videos at least, I probably hit a fillrate related issue - as playing the video in 640x480 on the pandaboard is acceptable(*).

Has anyone ever seen these symptoms ? I suspect that this is related to the fact that the video rendering is not hw accelerated but instead is decoded to a buffer and later sent to the video subsystem. I might be wrong on that as I have limited time to insestigate the issue. gstreamer might help here (that would require a fix for the omap4/gstreamer). 

Best regards, 

-- Emmanuel Deloget

(*) for unknown reasons, we were able to boot xbmc on 640x480, the image was using approx 1/4 of the screen, and the X screen was using the full HD resolution ; the mouse cursor was able to move all accros the screen.

[Davide Cavalca]

Il 2012-06-13 05:09 Emmanuel Deloget ha scritto:
> Hello,
>
> I installed the near-latest (yesterday) trunk on two systems - one
> Pandaboard and one Pandaboard ES. Here are the build command lines :
>
> $ make geexbox-xbmc-omap4-pandaboard_defconfig
> $ make
>
> (faced the known make-3.81 issue, copy the correct tarball in the
> make
> source directory, et restart make)

What's the known make issue?

> Compilation went ok. I noticed that the know problem with gstreamer
> has been "corrected" by not building gstreamer at all.
> Install went ok (copy boot/* on a VFAT, and the tar.gz content on an
> ext4 FS on a Sandisk Extreme SD/HC (advertised bandwidth: 30MB/s)).

Bandwidth is irrelevant, as SD card access on panda is awfully slow.
I'd recommend using USB if you need fast storage.

> Boot went ok (I'm also facing some sound-related issue, but that's
> not
> the subject here.)
>
> The problem I'm trying to solve is related to video playback: playing
> an full HD h.264 video is painfully slow, with around 2 to 4 frames
> per second. I face a similar issue when I try to play videos that
> come
> from the web (I installed the Funny or Die video addon). On web
> videos
> at least, I probably hit a fillrate related issue - as playing the
> video in 640x480 on the pandaboard is acceptable(*).
>
> Has anyone ever seen these symptoms ? I suspect that this is related
> to the fact that the video rendering is not hw accelerated but
> instead
> is decoded to a buffer and later sent to the video subsystem. I might
> be wrong on that as I have limited time to insestigate the issue.
> gstreamer might help here (that would require a fix for the
> omap4/gstreamer).

You are correct: video is being software decoded, hence slow. Making
the hardware decoding work entails:
- making ducati work (the decoding engine)
- making gst-ducati work (the gstreamer bridge to ducati)
- patching xbmc with the gstreamer patch (which is against a different
xbmc version and needs to be manually adapted)

This is currently a work in progress; all the bits and pieces for this
are available and known to work, it's "just" a matter of finding the
right combination and putting it all together.

> (*) for unknown reasons, we were able to boot xbmc on 640x480, the
> image was using approx 1/4 of the screen, and the X screen was using
> the full HD resolution ; the mouse cursor was able to move all accros
> the screen.

I've seen this as well, it looks like some issue with EDID. Can you try
running xrandr by hand and forcing a resolution?

Davide

[toml...@gmail.com]

Le 14/06/2012 07:02, Davide Cavalca a écrit :
> Il 2012-06-13 05:09 Emmanuel Deloget ha scritto:
>> Hello,
>>
>> I installed the near-latest (yesterday) trunk on two systems - one
>> Pandaboard and one Pandaboard ES. Here are the build command lines :
>>
>> $ make geexbox-xbmc-omap4-pandaboard_defconfig
>> $ make
>>
>> (faced the known make-3.81 issue, copy the correct tarball in the make
>> source directory, et restart make)
>
> What's the known make issue?

if you do a clone (from scratch) then build for example i386 config
then switch to arm,
you've got an error for make , script get doesn't dowload the package
same for kernel

>
>> Compilation went ok. I noticed that the know problem with gstreamer
>> has been "corrected" by not building gstreamer at all.

it's broken

Maybe the right combination is to return to an old kernel know to work
with ducati & co
....

>> (*) for unknown reasons, we were able to boot xbmc on 640x480, the
>> image was using approx 1/4 of the screen, and the X screen was using
>> the full HD resolution ; the mouse cursor was able to move all accros
>> the screen.
>
> I've seen this as well, it looks like some issue with EDID. Can you
> try running xrandr by hand and forcing a resolution?

set fullscreen to true in advancedsettings.xml
>
> Davide
>
Tom

[Nikolay Nikolaev]

Hello

On Thu, Jun 14, 2012 at 9:03 AM, toml...@gmail.com <toml...@gmail.com> wrote:

Le 14/06/2012 07:02, Davide Cavalca a écrit :

Il 2012-06-13 05:09 Emmanuel Deloget ha scritto:

Hello,

I installed the near-latest (yesterday) trunk on two systems - one
Pandaboard and one Pandaboard ES. Here are the build command lines :

$ make geexbox-xbmc-omap4-pandaboard_defconfig
$ make

(faced the known make-3.81 issue, copy the correct tarball in the make
source directory, et restart make)

What's the known make issue?

if you do a  clone (from scratch) then build for example i386 config then switch to arm,
you've got an error for make , script get doesn't dowload the package
same for kernel

I have described the issue before, it's basically this:

Once a file is downloaded, it's "meta" is copied in .stamps/$package/get (look scripts/get for reference)

"cp -p $PACKAGES/$1/meta $STAMP"

Now when the package has a flavor or device specific "meta" this is wrong.

I have proposed a patch which was discarded at the time.

The story for panda is like that:

- we switched to make 3.82, which has known backward compatibility issues

- we applied all the patches we found that can help us overcome this issues

- for XBMC, make 3.82 still causes problems

- Tom added make 3.81 for panda

- once you issue "make geexbox....panda_defconfig" in order to build the kconfig-frontends the "make 3.82" is downlaoded and compiled

- then when "make" starts to build the panda binaries - "script/get" checks that there's already .stamps/make/get and does not download "make 3.81"

- unpack for package 'make' fails since there is now "make 3.81.tar.gz"

- the solution is at this stage to manually download 3.81 sources an put them in sources/make/ or to rm .stamps/make/get

A long term solution is:

- xbmc currently is build with -j2 (enforced)

- for my arm based snowball i build it safely with make 3.82

- I think we can safely remove make 3.81 package from panda's folder

Tom, I removed this thing - will have to push it back 

Davide

Tom

regards, 

Nikolay Nikolaev

[Thomas Genty]

2012/6/14 Nikolay Nikolaev <nickni...@gmail.com>

will redo a build from scratch without 3.81 this afternoon

[Davide Cavalca]

Il 2012-06-13 23:54 Nikolay Nikolaev ha scritto:

> On Thu, Jun 14, 2012 at 9:03 AM, toml...@gmail.com [1]
> <toml...@gmail.com [2]> wrote:
>> Le 14/06/2012 07:02, Davide Cavalca a écrit :
>>> What's the known make issue?
>> if you do a  clone (from scratch) then build for example i386
>> config then switch to arm,
>> you've got an error for make , script get doesn't dowload the
>> package
>> same for kernel
>
> I have described the issue before, it's basically this:
> Once a file is downloaded, it's "meta" is copied in
> .stamps/$package/get (look scripts/get for reference)
> "cp -p $PACKAGES/$1/meta $STAMP"
>
> Now when the package has a flavor or device specific "meta" this is
> wrong.
> I have proposed a patch which was discarded at the time.

Ah, I see what you mean now; yes, this is indeed a bug. Could you
please repost your patch?

> The story for panda is like that:
> - we switched to make 3.82, which has known backward compatibility
> issues
> - we applied all the patches we found that can help us overcome this
> issues
> - for XBMC, make 3.82 still causes problems
> - Tom added make 3.81 for panda
> - once you issue "make geexbox....panda_defconfig" in order to build
> the kconfig-frontends the "make 3.82" is downlaoded and compiled
> - then when "make" starts to build the panda binaries - "script/get"
> checks that there's already .stamps/make/get and does not download
> "make 3.81"
> - unpack for package 'make' fails since there is now "make
> 3.81.tar.gz"
> - the solution is at this stage to manually download 3.81 sources an
> put them in sources/make/ or to rm .stamps/make/get
>
> A long term solution is:
> - xbmc currently is build with -j2 (enforced)
> - for my arm based snowball i build it safely with make 3.82
> - I think we can safely remove make 3.81 package from panda's folder

Agree, we can probably get rid of the make overlay for omap4.

>>> I've seen this as well, it looks like some issue with EDID. Can
>>> you try running xrandr by hand and forcing a resolution?
>>>
>>> set fullscreen to true in advancedsettings.xml
>
> Tom, I removed this thing - will have to push it back 

Are there any side effects to setting fullscreen?

Davide

[Nikolay Nikolaev]

On Fri, Jun 15, 2012 at 6:18 AM, Davide Cavalca <dav...@openbricks.org> wrote:

Il 2012-06-13 23:54 Nikolay Nikolaev ha scritto:

On Thu, Jun 14, 2012 at 9:03 AM, toml...@gmail.com [1]
<toml...@gmail.com [2]> wrote:

Le 14/06/2012 07:02, Davide Cavalca a écrit :

What's the known make issue?

if you do a  clone (from scratch) then build for example i386
config then switch to arm,
you've got an error for make , script get doesn't dowload the
package
same for kernel

I have described the issue before, it's basically this:
Once a file is downloaded, it's "meta" is copied in
.stamps/$package/get (look scripts/get for reference)
"cp -p $PACKAGES/$1/meta $STAMP"

Now when the package has a flavor or device specific "meta" this is
wrong.
I have proposed a patch which was discarded at the time.

Ah, I see what you mean now; yes, this is indeed a bug. Could you please repost your patch?

https://groups.google.com/forum/?hl=en&fromgroups#!topic/openbricks-devel/HTn-b4hW3GI

I agree it's not perfect, but works in simple situations where you have a general package and a platform or machine or flavor.

Determining what the "real meta" is involves parsing all files and identifying which one describes the current file to be downloaded - 

which can be quite complicated.

Anyway I don't think we're currently facing such complex situations so the proposed solution may be useful having in mind that it's not perfect, 

but is better than the current situation.

 

The story for panda is like that:
- we switched to make 3.82, which has known backward compatibility
issues
- we applied all the patches we found that can help us overcome this
issues
- for XBMC, make 3.82 still causes problems
- Tom added make 3.81 for panda
- once you issue "make geexbox....panda_defconfig" in order to build
the kconfig-frontends the "make 3.82" is downlaoded and compiled
- then when "make" starts to build the panda binaries - "script/get"
checks that there's already .stamps/make/get and does not download
"make 3.81"
- unpack for package 'make' fails since there is now "make
3.81.tar.gz"
- the solution is at this stage to manually download 3.81 sources an
put them in sources/make/ or to rm .stamps/make/get

A long term solution is:
- xbmc currently is build with -j2 (enforced)
- for my arm based snowball i build it safely with make 3.82
- I think we can safely remove make 3.81 package from panda's folder

Agree, we can probably get rid of the make overlay for omap4.

Tom is testing this. 

I've seen this as well, it looks like some issue with EDID. Can
you try running xrandr by hand and forcing a resolution?

set fullscreen to true in advancedsettings.xml

Tom, I removed this thing - will have to push it back 

Are there any side effects to setting fullscreen?

I'm sorry - my bad here, I got confused. I meant the "dirty regions " setting. Currently for panda and snowball fullscreen is "false".

It is weird as this makes it show on fullscreen - at least on my snowball.

Davide

regards,

NIkolay Nikolaev

[Emmanuel Deloget]

First, thanks to everyone for the detailed answers. 

On Thursday, June 14, 2012 7:02:30 AM UTC+2, Davide Cavalca wrote:

Il 2012-06-13 05:09 Emmanuel Deloget ha scritto:
> Hello,
>
> I installed the near-latest (yesterday) trunk on two systems - one
> Pandaboard and one Pandaboard ES. Here are the build command lines :
>
> $ make geexbox-xbmc-omap4-pandaboard_defconfig
> $ make
>
> (faced the known make-3.81 issue, copy the correct tarball in the
> make
> source directory, et restart make)

What's the known make issue?

I assumed that was a known problem (I discovered it while reading the 

mailing list before I even tried to compile OpenBricks). Anyway, it seems 

the remaining part of the discussion deals with this subject. 

 

> Compilation went ok. I noticed that the know problem with gstreamer
> has been "corrected" by not building gstreamer at all.
> Install went ok (copy boot/* on a VFAT, and the tar.gz content on an
> ext4 FS on a Sandisk Extreme SD/HC (advertised bandwidth: 30MB/s)).

Bandwidth is irrelevant, as SD card access on panda is awfully slow.
I'd recommend using USB if you need fast storage.

I would love to boot on USB, and I will give it a try (but first, I need to find 

that elusive USB2 hub because I also need to connect a keyboard and a 

mouse. Don't know why, but it has a tendency to disapear for long periods 

of time). 

 

> Boot went ok (I'm also facing some sound-related issue, but that's
> not
> the subject here.)
>
> The problem I'm trying to solve is related to video playback: playing
> an full HD h.264 video is painfully slow, with around 2 to 4 frames
> per second. I face a similar issue when I try to play videos that
> come
> from the web (I installed the Funny or Die video addon). On web
> videos
> at least, I probably hit a fillrate related issue - as playing the
> video in 640x480 on the pandaboard is acceptable(*).
>
> Has anyone ever seen these symptoms ? I suspect that this is related
> to the fact that the video rendering is not hw accelerated but
> instead
> is decoded to a buffer and later sent to the video subsystem. I might
> be wrong on that as I have limited time to insestigate the issue.
> gstreamer might help here (that would require a fix for the
> omap4/gstreamer).

You are correct: video is being software decoded, hence slow. Making
the hardware decoding work entails:
- making ducati work (the decoding engine)
- making gst-ducati work (the gstreamer bridge to ducati)
- patching xbmc with the gstreamer patch (which is against a different
xbmc version and needs to be manually adapted)

I may add that TI gave some new information to Pandabord users in a recent 

thread on the pandaboard mailing list (new ducati and friend update request: 

https://groups.google.com/d/topic/pandaboard/Mo_sc2v9Spw/discussion). 

With the addition of remoteproc/rpmsg in the kernel, the gstreamer support 

underwent some architectural changes that may be easier to track and

support in the long term.

 

This is currently a work in progress; all the bits and pieces for this
are available and known to work, it's "just" a matter of finding the
right combination and putting it all together.

> (*) for unknown reasons, we were able to boot xbmc on 640x480, the
> image was using approx 1/4 of the screen, and the X screen was using
> the full HD resolution ; the mouse cursor was able to move all accros
> the screen.

I've seen this as well, it looks like some issue with EDID. Can you try
running xrandr by hand and forcing a resolution?

WIll try that when I'll find some spare time. 

 

Davide

Thanks for everything to everyone. 

Regards, 

-- Emmanuel