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