[gst-devel] Advice on plugin/pipeline design

[Brijesh Singh]

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
<sameer.subscriptions at damagehead.com> 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
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>



-- 
Confusion is always the most honest response.