Content-type: multipart/alternative; Boundary="1__=4EBBFE05DFB8DAE88f9e8a93df938690918c4EBBFE05DFB8DAE8" --1__=4EBBFE05DFB8DAE88f9e8a93df938690918c4EBBFE05DFB8DAE8 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Hi, Unfortunately I'm not able to respond to 1). Regarding question 2), NXP Semiconductors has extended the GstOpenMAX t= o 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 t= he next package release 0.5. BR, bruno = = = = To gstreamer-openmax@lists.sourcefo= rge .net = "Ling Shi" = cc = Sent by: Subj= ect [Gstreamer-openmax] Discussion o= n gstreamer-openmax-bounces the hardware accelerator solutio= n @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 proj= ect 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 h= as DSP. Can anyone tell me if N8xx use GstOpenMAX? If no, does N8xx plan t= o 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 hardw= are, because of bad performance. So, we plan to improve it by adding tunnele= d or proprietary communication. Do you have such plan? If yes, can we involv= e 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 i= n this situation? We are evaluating two solutions. =3D=3D=3DSolution 1=3D=3D=3D We can design a super omx sink component to cover decoder and render. T= his is the solution is used by N8xx. src ! demux ! sink | super omx sink | +--------------------------------------------+ | hardware accelerator | +--------------------------------------------+ =3D=3D=3DSolution 2=3D=3D=3D 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 firstl= y. It means, although we have 3 OMX plugin in gst pipeline, there is no da= ta in gst pad and omx port. The last two gst/omx plugin only provide contr= ol function, but not support process data flow. Of cause, If the connectio= n 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 w= orld http://moblin-contest.org/redirect.php?banner_id=3D100&url=3D/ _______________________________________________ Gstreamer-openmax mailing list Gstreamer-openmax@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax = --1__=4EBBFE05DFB8DAE88f9e8a93df938690918c4EBBFE05DFB8DAE8 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Hi,

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

Regarding question 2), NXP Semiconductors has extended the GstOpenMAX t= o support tunneled communication close to your solution 2. The GstOmx e= lements will look if their neighbour element
is also a GstOmx element and if so, it tries to setup a tunneled commun= ication between 2 OMX components. By this the PAD links are used only a= s 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 tu= nneled 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 t= he next package release 0.5.

BR, bruno
3D"Inactive"Ling Shi" <shil66@gmail.com&g= t;


=
    "Ling Shi" <shil66@gmail.com>
    Sent by:

    gstreamer-openmax-bounces@lists.sourceforge.net

    2008-07-30 09:00 AM

=
3D""
To
3D""
gstreamer-openmax@lists.sourceforge.net
3D""
cc
3D""
3D""
Subject
3D""
[Gstreamer-openmax] Discussion on the hardware acceler= ator solution in GstOpenMAX project.
=3D""3D""<= /td>

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/G= PU) 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 h= as DSP. Can anyone tell me if N8xx use GstOpenMAX? If no, does N8xx pla= n 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 hard= ware, because of bad performance. So, we plan to improve it by adding t= unneled or proprietary communication. Do you have such plan? If yes, ca= n 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, an= d will not be retrieved back again. How the gst or omx organize its pip= eline in this situation? We are evaluating two solutions.

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

=3D=3D=3DSolution 2=3D=3D=3D
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 f= irstly. 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 pr= ovide 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
| | |<= br> omx dec omx pp omx sink
| | |<= br> +--------------------------------------------+
| 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 chal= lenge
Build the coolest Linux based applications with Moblin SDK & win gr= eat prizes
Grand prize is a trip for two to an Open Source event anywhere in the w= orld
http://moblin-contest.org/redirect.php?banner_id=3D100&= ;url=3D/_______________________________________________ Gstreamer-openmax mailing list
Gstreamer-openmax@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gstreamer-ope= nmax

= --1__=4EBBFE05DFB8DAE88f9e8a93df938690918c4EBBFE05DFB8DAE8--