[gst-devel] Advice on plugin/pipeline design

[Sameer Naik]

Hello,
Please comment

Regards
~Sameer

On Sun, Nov 22, 2009 at 3:48 PM, 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
>
>