<html><body>
<p>Hi,<br>
<br>
Unfortunately I'm not able to respond to 1).<br>
<br>
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<br>
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<br>
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<br>
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<br>
components and still decide to use non-tunneled if really needed.<br>
<br>
Our submission is currently in a GIT and intended to be integrated in the next package release 0.5.<br>
<br>
BR, bruno<br>
<img src="cid:10__=4EBBFE05DFB8DAE88f9e8a93df938690@nxp.com" width="16" height="16" alt="Inactive hide details for &quot;Ling Shi&quot; &lt;shil66@gmail.com&gt;">&quot;Ling Shi&quot; &lt;shil66@gmail.com&gt;<br>
<br>
<br>

<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td style="background-image:url(cid:20__=4EBBFE05DFB8DAE88f9e8a93df938690@nxp.com); background-repeat: no-repeat; " width="40%">
<ul><b><font size="2">&quot;Ling Shi&quot; &lt;shil66@gmail.com&gt;</font></b><font size="2"> </font><br>
<font size="2">Sent by:</font>
<p><font size="2">gstreamer-openmax-bounces@lists.sourceforge.net</font>
<p><font size="2">2008-07-30 09:00 AM</font></ul>
</td><td width="60%">
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td width="1%" valign="middle"><img src="cid:30__=4EBBFE05DFB8DAE88f9e8a93df938690@nxp.com" border="0" height="1" width="58" alt=""><br>
<div align="right"><font size="2">To</font></div></td><td width="100%"><img src="cid:30__=4EBBFE05DFB8DAE88f9e8a93df938690@nxp.com" border="0" height="1" width="1" alt=""><br>
<font size="2">gstreamer-openmax@lists.sourceforge.net</font></td></tr>

<tr valign="top"><td width="1%" valign="middle"><img src="cid:30__=4EBBFE05DFB8DAE88f9e8a93df938690@nxp.com" border="0" height="1" width="58" alt=""><br>
<div align="right"><font size="2">cc</font></div></td><td width="100%"><img src="cid:30__=4EBBFE05DFB8DAE88f9e8a93df938690@nxp.com" border="0" height="1" width="1" alt=""><br>
</td></tr>

<tr valign="top"><td width="1%" valign="middle"><img src="cid:30__=4EBBFE05DFB8DAE88f9e8a93df938690@nxp.com" border="0" height="1" width="58" alt=""><br>
<div align="right"><font size="2">Subject</font></div></td><td width="100%"><img src="cid:30__=4EBBFE05DFB8DAE88f9e8a93df938690@nxp.com" border="0" height="1" width="1" alt=""><br>
<font size="2">[Gstreamer-openmax] Discussion on the hardware accelerator solution        in GstOpenMAX project.</font></td></tr>
</table>

<table border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td width="58"><img src="cid:30__=4EBBFE05DFB8DAE88f9e8a93df938690@nxp.com" border="0" height="1" width="1" alt=""></td><td width="336"><img src="cid:30__=4EBBFE05DFB8DAE88f9e8a93df938690@nxp.com" border="0" height="1" width="1" alt=""></td></tr>
</table>
</td></tr>
</table>
<br>
<font size="4">Hi, all<br>
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<br>
<br>
  1) OpenMAX is an industry standard<br>
  2) more and more DSP/GPU vendor support OpenMAX<br>
<br>
But, I still have several questions on this project.<br>
1. Does Nokia N8xx serials use GstOpenMAX?<br>
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?<br>
<br>
2. What's GstOpenMAX plan to support DSP/GPU in the future?<br>
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?<br>
<br>
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.<br>
<br>
===Solution 1===<br>
We can design a super omx sink component to cover decoder and render. This is the solution is used by N8xx.<br>
src ! demux ! sink<br>
                         |<br>
                       super omx sink<br>
                         |<br>
                   +--------------------------------------------+<br>
                    |    hardware accelerator                 |<br>
                   +--------------------------------------------+<br>
<br>
===Solution 2===<br>
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.<br>
<br>
src ! demux ! decoder ! post processor ! sink<br>
                            |                     |                  |<br>
                     omx dec          omx pp       omx sink<br>
                            |                     |                  |<br>
                   +--------------------------------------------+<br>
                    |    hardware accelerator                 |<br>
                   +--------------------------------------------+<br>
<br>
It seems solution 2 is more flexible. How about your suggestion on the 2 solutions? Which one is feasible? Do you have other solutions?<br>
<br>
Thank you very much.</font><tt>-------------------------------------------------------------------------<br>
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge<br>
Build the coolest Linux based applications with Moblin SDK &amp; win great prizes<br>
Grand prize is a trip for two to an Open Source event anywhere in the world<br>
</tt><tt><a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/">http://moblin-contest.org/redirect.php?banner_id=100&amp;url=/</a></tt><tt>_______________________________________________<br>
Gstreamer-openmax mailing list<br>
Gstreamer-openmax@lists.sourceforge.net<br>
</tt><tt><a href="https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax">https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax</a></tt><tt><br>
</tt><br>
</body></html>