BeagleBoard DSP video questions

Hi, all,

We recently announced NthCode Player, software that electronics
companies can embed in their home electronics so consumers can
seamlessly find and play videos and music from their home computers
and the Internet. You can see a sneak peak of it running on a
BeagleBoard near the end of the video below:

http://www.youtube.com/watch?v=5DHu_nEy6Ew

We've been able to use the hardware video overlay and video scaler.
And it worked just as we had hoped.

However, we're having some trouble getting the DSP to work. Here's
what we've done:

   - We have a 128M BeagleBoard B6
   - We're running the screen at 1280x720 (using DSS)
   - We are trying to play a 512x288 mp4 video

   - We patched the Linux Angstrom 2.6.27-omap1 kernel for the DSP
Bridge.
     - We can successfully run the ping, dummy, scale, etc. test
programs
     - But when we try to make OpenMAX work with the DSP we see errors
     - When we start playing, it always fails at CreateNode, which, we
guess, is initialization
     - It either reports 'no memory,' or 'failed to load program'

   - We also tried the DSP Link.
     - We compiled the cmemk, dsplinkk, and lpm_omap3530 kernel
modules for the Linux Angstrom 2.6.27-omap1 kernel
     - We loaded the three modules with the script in codec engine 2.2.1
     - We set the kernel boot args MEM=80M
     - Then we copied the sanity test in the codec engine for evm3530
into the BeagleBoard file system
     - We ran the sanity test
     - We received some strange errors -- the error numbers returned
are not in the header file of the DSP Link.

The errors above aren't the exact text -- it's from the memory of one
of my team members.

So, a few questions:
   - Which of the above two methods we should really be using?
   - Is the DSP *known* to work on BeagleBoard with the right software
'recipe'?
   - Could the issue be the mp4 file we're using for the DSP Bridge?
   - Is it possible that this is because we're driving the output at
720p or should that be unrelated?

Any other hints would be much appreciated.

Regards,

Peter

Hi, all,

We recently announced NthCode Player, software that electronics
companies can embed in their home electronics so consumers can
seamlessly find and play videos and music from their home computers
and the Internet. You can see a sneak peak of it running on a
BeagleBoard near the end of the video below:

http://www.youtube.com/watch?v=5DHu_nEy6Ew

We've been able to use the hardware video overlay and video scaler.
And it worked just as we had hoped.

However, we're having some trouble getting the DSP to work. Here's
what we've done:

- We have a 128M BeagleBoard B6
- We're running the screen at 1280x720 (using DSS)
- We are trying to play a 512x288 mp4 video

- We patched the Linux Angstrom 2.6.27-omap1 kernel for the DSP
Bridge.
- We can successfully run the ping, dummy, scale, etc. test
programs
- But when we try to make OpenMAX work with the DSP we see errors
- When we start playing, it always fails at CreateNode, which, we
guess, is initialization
- It either reports 'no memory,' or 'failed to load program'

<snip/>

So, a few questions:
- Which of the above two methods we should really be using?
- Is the DSP *known* to work on BeagleBoard with the right software
'recipe'?
- Could the issue be the mp4 file we're using for the DSP Bridge?
- Is it possible that this is because we're driving the output at
720p or should that be unrelated?

I haven't tried DSP link, I can only tell you that DSP bridge works fine.

However, the DSP binaries that TI provided in tiopenmax-0.3 are wrong,
they are working on a new version, I'm CC'ing Daniel Diaz who should
know more.

Even after the release of tiopenmax-0.4 I don't think it would be
possible to do 720p with those codecs. There are companies that
provide 720p codecs, but there are no 'trial versions' AFAIK.

Cheers.

Felipe,

Thank you for the reply. If the standard codecs can't do 720p, that's
fine for now. We'd really just like to show that we're able to take
advantage of the OMAP3 DSP using the standard TI drop as a first step
and then start working with other providers to use their codecs for
higher performance video.

Daniel,

If you have any information you can share about when the new
tiopenmax-0.4 drop will be ready, it would be appreciated.

Regards,

Peter

Hello, Peter!

Sorry for the late answer, it's been a crazy week (with more to come).

I hope you are as excited as I am with regards to hardware accelerated decoding on the Beagle! I have been spending some time on that lately and hope to have it out soon.

In the past week I managed to build:
* Kernel + dspbridge module
* Bridge library
* Socket Nodes
* OpenMAX
* Rest of filesystem

I didn't have a test application to verify the dspbridge module + the library, plus OpenMAX were working. I built gst-openmax for the sake of testing, and will check early next week.

Now, that was on an SDP. For the Beagle I was trying to get a recent kernel with the dspbridge module to build, but failed many times. Thanks to Felipec I have now built it and will test over the weekend.

If these tests run fine, I will start building the socket nodes that can be released on a public package soon.

Greetings!

Daniel Díaz
ddiaz@ti.com

Thanks, Daniel.

NthCode Player is gstreamer-based, so we should be able to quickly leverage your work. Looking forward to seeing our stuff taking advantage of the OMAP DSP.

Regards,

Peter

Hi Daniel,

Good to know that tiopemax which supports beagleboard is getting released. While building baseimage.dof , can you please enable SYS_printf support? That would help people like me who has to rely on print statements for DSP side debugging.

Thanks

regards

Jesslyn Abdul Salam

I’m also looking forward to Daniel’s solution (which seems to be eminent). In the meantime, if you happen to be an Angstrom user, you can give gstreamer-ti a try. It doesn’t have support for OpenMAX-IL and uses Link instead of Bridge.

http://www.angstrom-distribution.org/repo/?pkgname=gstreamer-ti
‘opkg update; opkg install gstreamer-ti’

Currently, there is a much stronger push to get Bridge into the kernel mainline and has greater mobile standards support (OpenMAX-IL) whereas Link has been used by a larger number of DSP customers for different purposes.