[gst-devel] Advice on plugin/pipeline design

Sameer Naik sameer.subscriptions at damagehead.com
Wed Nov 25 06:58:49 CET 2009


On Wed, Nov 25, 2009 at 1:32 AM, Stefan Kost <ensonic at hora-obscura.de> 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.
>
Thats right, when resizing is not required i will just forward the
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
>> gstreamer-devel at lists.sourceforge.net
>> 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
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>




More information about the gstreamer-devel mailing list