[Gstreamer-openmax] Discussion on the hardware accelerator solution in GstOpenMAX project.

Bruno Smets bruno.smets at nxp.com
Wed Jul 30 01:01:38 PDT 2008


Hi,

Unfortunately I'm not able to respond to 1).

Regarding question 2), NXP Semiconductors has extended the GstOpenMAX to
support tunneled communication close to your solution 2. The GstOmx
elements will look if their neighbour element
is also a GstOmx element and if so, it tries to setup a tunneled
communication between 2 OMX components. By this the PAD links are used only
as a virtual connection and the data is
flowing in the OMX-IL layer. If the neighbour element is a regular Gst
element, then we setup a non-tunneled communication from OMX viewpoint and
as such the data comes back from
the underlying OMX component to Gst level and flows over the PAD link.
Further an application (gst-launch or bins) can overrule the default
tunneled communication between 2 OMX
components and still decide to use non-tunneled if really needed.

Our submission is currently in a GIT and intended to be integrated in the
next package release 0.5.

BR, bruno


                                                                           
                                                                           
                                                                           
                                                                        To 
                                       gstreamer-openmax at lists.sourceforge 
                                       .net                                
     "Ling Shi"                                                         cc 
     <shil66 at gmail.com>                                                    
     Sent by:                                                      Subject 
                                       [Gstreamer-openmax] Discussion on   
     gstreamer-openmax-bounces         the hardware accelerator solution   
     @lists.sourceforge.net            in GstOpenMAX project.              
                                                                           
                                                                           
     2008-07-30 09:00 AM                                                   
                                                                           
                                                                           
                                                                           




Hi, all
I'm in a research project to port gstreamer into embedded system. Now, we
encounter the issue on how to integrate hardware accelerators (DSP/GPU)
into gst. After evaluating different solution, we think GstOpenMAX project
may be the best one for us, because

  1) OpenMAX is an industry standard
  2) more and more DSP/GPU vendor support OpenMAX

But, I still have several questions on this project.
1. Does Nokia N8xx serials use GstOpenMAX?
I know Nokia engineers lead this project. I also know N8xx serials use
gstreamer as default playback engine, and it uses TI OMAP 2420, which has
DSP. Can anyone tell me if N8xx use GstOpenMAX? If no, does N8xx plan to
use it in the future?

2. What's GstOpenMAX plan to support DSP/GPU in the future?
I review several plugins in GstOpenMAX and find current design can only
support none-tunnel communication.  It's not the best solution in hardware,
because of bad performance. So, we plan to improve it by adding tunneled or
proprietary communication. Do you have such plan? If yes, can we involve in
design?

In addition, most accelerators work as a decoder and a render. It means,
the encoded data sent to it will directly be decoded and rendered, and will
not be retrieved back again. How the gst or omx organize its pipeline in
this situation? We are evaluating two solutions.

===Solution 1===
We can design a super omx sink component to cover decoder and render. This
is the solution is used by N8xx.
src ! demux ! sink
                         |
                       super omx sink
                         |
                   +--------------------------------------------+
                    |    hardware accelerator                 |
                   +--------------------------------------------+

===Solution 2===
We can separate omx decoder, omx post processer, and omx sink elements. We
enhance decoder, post processor, and sink plugin in GstOpenMAX. If
GstOpenMAX plugin found its neighborhood are GstOpenMAX plugin, it will try
to establish tunneled communication or proprietary communication firstly.
It means, although we have 3 OMX plugin in gst pipeline, there is no data
in gst pad and omx port. The last two gst/omx plugin only provide control
function, but not support process data flow. Of cause, If the connection is
failed, it will use none-tunnel communication.

src ! demux ! decoder ! post processor ! sink
                            |                     |                  |
                     omx dec          omx pp       omx sink
                            |                     |                  |
                   +--------------------------------------------+
                    |    hardware accelerator                 |
                   +--------------------------------------------+

It seems solution 2 is more flexible. How about your suggestion on the 2
solutions? Which one is feasible? Do you have other solutions?

Thank you very much.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Gstreamer-openmax mailing list
Gstreamer-openmax at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-openmax/attachments/20080730/5ff2158e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-openmax/attachments/20080730/5ff2158e/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic03557.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-openmax/attachments/20080730/5ff2158e/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-openmax/attachments/20080730/5ff2158e/attachment-0002.gif>


More information about the Gstreamer-openmax mailing list