<div dir="ltr"><br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Ling Shi</b> <span dir="ltr"><<a href="mailto:shil66@gmail.com">shil66@gmail.com</a>></span><br>
Date: Wed, Jul 30, 2008 at 3:00 PM<br>Subject: Discussion on the hardware accelerator solution in GstOpenMAX project.<br>To: <a href="mailto:gstreamer-openmax@lists.sourceforge.net">gstreamer-openmax@lists.sourceforge.net</a><br>
<br><br><div dir="ltr">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.</div>
</div><br></div>