Advice on plugin/pipeline design
Locked
 
|
Hi,
I am developing a multimedia application for an embedded system based on TI's DM6446 platform. The decoding of the audio and video frames will be done using the HW decoders. The platform also includes a hardware resizer, that allows resizing of the video frames in hardware, thereby making the resizing operations pretty quick. I need some advice on the architecture that i should base by application on. Following are the architectures that i have come up with 1. - audio decoder plugins - video decoder plugins - resizer plugin - frame buffer output plugin Here i can build a seperate plugin to do the resizing of video frames. This would conform more with gstreamer's idea that "every element does one thing", providing better reusability. To reduce to number of memcpy's, i could equip the frame buffer plugin with pad allocation capabilities and accordingly add pad_alloc calls in the resizer plugin. The only this is, in this case the frames will always be resized, regardless of whether the frame is going to be displayed or dropped. I am not really sure whether this is that big of a problem considering that the number of frames that could be dropped is very less. 2. - audio decoder plugins - video decoder plugins - frame buffer plugin with resizing capabilities using the hw resizer. Here i can build the frame buffer plugin with the built in capability to resize video frames. In this case i could resize the frame only if it is going to be displayed (i.e. just before it would be displayed on screen). Now in this case i loose the reusability advantage, which i can live with if i am able to achieve smooth video playback with av sync. In this case, I am not sure whether the last minute resizing of the frame would introduce a lot of latency while displaying the frame. Given that it is a hardware resizer i am assuming it would be quick. P.S. I would be employing the pad allocation method in other parts of the pipeline as well, so as to reduce the number of memcpy's going on in the pipeline. Please Advice. Regards ~Sameer ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Advice on plugin/pipeline design
|
|
Hello,
Have you looked at gstreamer.ti.com ? gst_ti has all the elements you need. It support wide varity of TI platforms. (DM6446, DM355, DM365, DM357, DM6467, OMAP3530 and more...). To understand design detail you can watch 25-min of video presentation. https://gstreamer.ti.com/gf/project/gstreamer_ti/wiki/?pagename=OverviewPresentation We do not have pad-allocation method yet (may be you can contribute on project). We use hw accelerated framecopy to copy the data from video decoder -> sink element. Depending on the platform, this hw accelerator may be resizer/dma/vdce/sdma etc... Thanks Brijesh On Sun, Nov 22, 2009 at 4:18 AM, Sameer Naik <[hidden email]> wrote: > Hi, > I am developing a multimedia application for an embedded system based on > TI's DM6446 platform. The decoding of the audio and video frames will be > done using the HW decoders. The platform also includes a hardware resizer, > that allows resizing of the video frames in hardware, thereby making the > resizing operations pretty quick. > > I need some advice on the architecture that i should base by application on. > Following are the architectures that i have come up with > > 1. > - audio decoder plugins > - video decoder plugins > - resizer plugin > - frame buffer output plugin > Here i can build a seperate plugin to do the resizing of video frames. This > would conform more with gstreamer's idea that "every element does one > thing", providing better reusability. To reduce to number of memcpy's, i > could equip the frame buffer plugin with pad allocation capabilities and > accordingly add pad_alloc calls in the resizer plugin. The only this is, in > this case the frames will always be resized, regardless of whether the frame > is going to be displayed or dropped. I am not really sure whether this is > that big of a problem considering that the number of frames that could be > dropped is very less. > > 2. > - audio decoder plugins > - video decoder plugins > - frame buffer plugin with resizing capabilities using the hw resizer. > Here i can build the frame buffer plugin with the built in capability to > resize video frames. In this case i could resize the frame only if it is > going to be displayed (i.e. just before it would be displayed on screen). > Now in this case i loose the reusability advantage, which i can live with if > i am able to achieve smooth video playback with av sync. In this case, I am > not sure whether the last minute resizing of the frame would introduce a lot > of latency while displaying the frame. Given that it is a hardware resizer i > am assuming it would be quick. > > P.S. I would be employing the pad allocation method in other parts of the > pipeline as well, so as to reduce the number of memcpy's going on in the > pipeline. > > Please Advice. > > Regards > ~Sameer > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > > -- Confusion is always the most honest response. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Advice on plugin/pipeline design
|
|
Hello,
I had taken a look at the gstreamer-ti plugins some time back. One of the things that i noticed is threads being spawned from within the decoder plugins, which does not fit well with me. I also noticed quite a lot of bugs in the code, which kept me from using it or hacking on it. Besides i already have most of the functionality implemented and just need to tweak my code/design a bit, hence the mail. Thanks and Regards ~Sameer On Sun, Nov 22, 2009 at 9:27 PM, Brijesh Singh <[hidden email]> wrote: Hello, ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Advice on plugin/pipeline design
|
|
>One of the things that i noticed is threads being spawned from within the decoder
>plugins, which does not fit well with me. Well threads are used for parallelizing ARM and DSP execution to meet the real-time performance on some platforms. But you can remove thread and call decoder directly from the chain() functions. Or use queue element to put the decoder element in different threads. > I also noticed quite a lot of bugs in the code, which kept me from using it or hacking on it. Can you please submit BUGs on gstreamer.ti.com ? Thanks Brijesh On Sun, Nov 22, 2009 at 11:07 AM, Sameer Naik <[hidden email]> wrote: > Hello, > I had taken a look at the gstreamer-ti plugins some time back. One of the > things that i noticed is threads being spawned from within the decoder > plugins, which does not fit well with me. I also noticed quite a lot of bugs > in the code, which kept me from using it or hacking on it. Besides i already > have most of the functionality implemented and just need to tweak my > code/design a bit, hence the mail. > > Thanks and Regards > ~Sameer > > On Sun, Nov 22, 2009 at 9:27 PM, Brijesh Singh <[hidden email]> > wrote: >> >> Hello, >> >> Have you looked at gstreamer.ti.com ? gst_ti has all the elements you >> need. It support wide varity of TI platforms. (DM6446, DM355, DM365, >> DM357, DM6467, OMAP3530 and more...). >> >> To understand design detail you can watch 25-min of video presentation. >> >> >> https://gstreamer.ti.com/gf/project/gstreamer_ti/wiki/?pagename=OverviewPresentation >> >> We do not have pad-allocation method yet (may be you can contribute on >> project). We use hw accelerated framecopy to copy the data from video >> decoder -> sink element. Depending on the platform, this hw >> accelerator may be resizer/dma/vdce/sdma etc... >> >> >> Thanks >> Brijesh >> >> On Sun, Nov 22, 2009 at 4:18 AM, Sameer Naik >> <[hidden email]> wrote: >> > Hi, >> > I am developing a multimedia application for an embedded system based on >> > TI's DM6446 platform. The decoding of the audio and video frames will be >> > done using the HW decoders. The platform also includes a hardware >> > resizer, >> > that allows resizing of the video frames in hardware, thereby making the >> > resizing operations pretty quick. >> > >> > I need some advice on the architecture that i should base by application >> > on. >> > Following are the architectures that i have come up with >> > >> > 1. >> > - audio decoder plugins >> > - video decoder plugins >> > - resizer plugin >> > - frame buffer output plugin >> > Here i can build a seperate plugin to do the resizing of video frames. >> > This >> > would conform more with gstreamer's idea that "every element does one >> > thing", providing better reusability. To reduce to number of memcpy's, i >> > could equip the frame buffer plugin with pad allocation capabilities and >> > accordingly add pad_alloc calls in the resizer plugin. The only this is, >> > in >> > this case the frames will always be resized, regardless of whether the >> > frame >> > is going to be displayed or dropped. I am not really sure whether this >> > is >> > that big of a problem considering that the number of frames that could >> > be >> > dropped is very less. >> > >> > 2. >> > - audio decoder plugins >> > - video decoder plugins >> > - frame buffer plugin with resizing capabilities using the hw resizer. >> > Here i can build the frame buffer plugin with the built in capability to >> > resize video frames. In this case i could resize the frame only if it is >> > going to be displayed (i.e. just before it would be displayed on >> > screen). >> > Now in this case i loose the reusability advantage, which i can live >> > with if >> > i am able to achieve smooth video playback with av sync. In this case, I >> > am >> > not sure whether the last minute resizing of the frame would introduce a >> > lot >> > of latency while displaying the frame. Given that it is a hardware >> > resizer i >> > am assuming it would be quick. >> > >> > P.S. I would be employing the pad allocation method in other parts of >> > the >> > pipeline as well, so as to reduce the number of memcpy's going on in the >> > pipeline. >> > >> > Please Advice. >> > >> > Regards >> > ~Sameer >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> > 30-Day >> > trial. Simplify your report design, integration and deployment - and >> > focus >> > on >> > what you do best, core application coding. Discover what's new with >> > Crystal Reports now. http://p.sf.net/sfu/bobj-july >> > _______________________________________________ >> > gstreamer-devel mailing list >> > [hidden email] >> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel >> > >> > >> >> >> >> -- >> Confusion is always the most honest response. >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day >> trial. Simplify your report design, integration and deployment - and focus >> on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> gstreamer-devel mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > > -- Confusion is always the most honest response. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Advice on plugin/pipeline design
|
|
Sure
On Sun, Nov 22, 2009 at 11:43 PM, Brijesh Singh <[hidden email]> wrote:
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Advice on plugin/pipeline design
|
|
In reply to this post by Sameer Naik
Hello,
Please comment Regards ~Sameer On Sun, Nov 22, 2009 at 3:48 PM, Sameer Naik <[hidden email]> wrote: > Hi, > I am developing a multimedia application for an embedded system based on > TI's DM6446 platform. The decoding of the audio and video frames will be > done using the HW decoders. The platform also includes a hardware resizer, > that allows resizing of the video frames in hardware, thereby making the > resizing operations pretty quick. > > I need some advice on the architecture that i should base by application on. > Following are the architectures that i have come up with > > 1. > - audio decoder plugins > - video decoder plugins > - resizer plugin > - frame buffer output plugin > Here i can build a seperate plugin to do the resizing of video frames. This > would conform more with gstreamer's idea that "every element does one > thing", providing better reusability. To reduce to number of memcpy's, i > could equip the frame buffer plugin with pad allocation capabilities and > accordingly add pad_alloc calls in the resizer plugin. The only this is, in > this case the frames will always be resized, regardless of whether the frame > is going to be displayed or dropped. I am not really sure whether this is > that big of a problem considering that the number of frames that could be > dropped is very less. > > 2. > - audio decoder plugins > - video decoder plugins > - frame buffer plugin with resizing capabilities using the hw resizer. > Here i can build the frame buffer plugin with the built in capability to > resize video frames. In this case i could resize the frame only if it is > going to be displayed (i.e. just before it would be displayed on screen). > Now in this case i loose the reusability advantage, which i can live with if > i am able to achieve smooth video playback with av sync. In this case, I am > not sure whether the last minute resizing of the frame would introduce a lot > of latency while displaying the frame. Given that it is a hardware resizer i > am assuming it would be quick. > > P.S. I would be employing the pad allocation method in other parts of the > pipeline as well, so as to reduce the number of memcpy's going on in the > pipeline. > > Please Advice. > > Regards > ~Sameer > > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Advice on plugin/pipeline design
|
|
In reply to this post by Sameer Naik
Sameer Naik schrieb:
> Hi, > I am developing a multimedia application for an embedded system based on > TI's DM6446 platform. The decoding of the audio and video frames will be > done using the HW decoders. The platform also includes a hardware > resizer, that allows resizing of the video frames in hardware, thereby > making the resizing operations pretty quick. > > I need some advice on the architecture that i should base by application > on. Following are the architectures that i have come up with > > 1. > - audio decoder plugins > - video decoder plugins > - resizer plugin > - frame buffer output plugin > Here i can build a seperate plugin to do the resizing of video frames. > This would conform more with gstreamer's idea that "every element does > one thing", providing better reusability. To reduce to number of > memcpy's, i could equip the frame buffer plugin with pad allocation > capabilities and accordingly add pad_alloc calls in the resizer plugin. > The only this is, in this case the frames will always be resized, > regardless of whether the frame is going to be displayed or dropped. I > am not really sure whether this is that big of a problem considering > that the number of frames that could be dropped is very less. if you don't resize, just pass-through the pad_alloc to the next element. Do the same with the buffers. Then you don't have much overhead. Stefan > > 2. > - audio decoder plugins > - video decoder plugins > - frame buffer plugin with resizing capabilities using the hw resizer. > Here i can build the frame buffer plugin with the built in capability to > resize video frames. In this case i could resize the frame only if it is > going to be displayed (i.e. just before it would be displayed on > screen). Now in this case i loose the reusability advantage, which i can > live with if i am able to achieve smooth video playback with av sync. In > this case, I am not sure whether the last minute resizing of the frame > would introduce a lot of latency while displaying the frame. Given that > it is a hardware resizer i am assuming it would be quick. > > P.S. I would be employing the pad allocation method in other parts of > the pipeline as well, so as to reduce the number of memcpy's going on in > the pipeline. > > Please Advice. > > Regards > ~Sameer > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > > ------------------------------------------------------------------------ > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Advice on plugin/pipeline design
|
|
On Wed, Nov 25, 2009 at 1:32 AM, Stefan Kost <[hidden email]> wrote:
> Sameer Naik schrieb: >> Hi, >> I am developing a multimedia application for an embedded system based on >> TI's DM6446 platform. The decoding of the audio and video frames will be >> done using the HW decoders. The platform also includes a hardware >> resizer, that allows resizing of the video frames in hardware, thereby >> making the resizing operations pretty quick. >> >> I need some advice on the architecture that i should base by application >> on. Following are the architectures that i have come up with >> >> 1. >> - audio decoder plugins >> - video decoder plugins >> - resizer plugin >> - frame buffer output plugin >> Here i can build a seperate plugin to do the resizing of video frames. >> This would conform more with gstreamer's idea that "every element does >> one thing", providing better reusability. To reduce to number of >> memcpy's, i could equip the frame buffer plugin with pad allocation >> capabilities and accordingly add pad_alloc calls in the resizer plugin. >> The only this is, in this case the frames will always be resized, >> regardless of whether the frame is going to be displayed or dropped. I >> am not really sure whether this is that big of a problem considering >> that the number of frames that could be dropped is very less. > > if you don't resize, just pass-through the pad_alloc to the next element. Do the > same with the buffers. Then you don't have much overhead. > pad_alloc request to the peer element. > Stefan > > >> >> 2. >> - audio decoder plugins >> - video decoder plugins >> - frame buffer plugin with resizing capabilities using the hw resizer. >> Here i can build the frame buffer plugin with the built in capability to >> resize video frames. In this case i could resize the frame only if it is >> going to be displayed (i.e. just before it would be displayed on >> screen). Now in this case i loose the reusability advantage, which i can >> live with if i am able to achieve smooth video playback with av sync. In >> this case, I am not sure whether the last minute resizing of the frame >> would introduce a lot of latency while displaying the frame. Given that >> it is a hardware resizer i am assuming it would be quick. >> >> P.S. I would be employing the pad allocation method in other parts of >> the pipeline as well, so as to reduce the number of memcpy's going on in >> the pipeline. >> >> Please Advice. >> >> Regards >> ~Sameer >> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> gstreamer-devel mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |