[gst-devel] Advice on plugin/pipeline design

[Stefan Kost]

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