[gst-devel] Advice on plugin/pipeline design

Sameer Naik sameer.subscriptions at damagehead.com
Sun Nov 22 11:18:35 CET 2009


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20091122/17fd4bab/attachment.htm>


More information about the gstreamer-devel mailing list