What I have observed is that is takes almost 1 minute for TIViddec2 buffer
processing thread (after it starts receiving data) to invoke the decoder
thread.

Is there any way to optimise this so that the time duration after receiving the
buffer &amp; invoking the decoder thread gets reduced &amp; thus
reducing the overall time required for displaying of video.

What I have observed is that is takes almost 1 minute for TIViddec2 buffer
processing thread (after it starts receiving data) to invoke the decoder
thread.

Is there any way to optimise this so that the time duration after receiving the
buffer &amp; invoking the decoder thread gets reduced &amp; thus
reducing the overall time required for displaying of video.

Please note that you should have filed this tracker in the &quot;TI
GStreamer Development&quot; tracker -- please don't file new trackers in the
ones marked &quot;do-not-use&quot;. I moved it, but it needs some
additional data, like the affected target. Since you're using VGA output, I'm
assuming this is OMAP3.

When playing back video, the TI GStreamer Plugin queries the codec to see how
much encoded data it requires before processing an encoded frame. In the case
of the H.264 decoder, I believe it requires 1.5MB of data for processing,
although a typical encoded frame is only about 40K. I can't offer an
explanation of why the codec requires more input to decode than the size of a
decoded frame. I believe we set the maximum decoded frame size to D1-PAL, in
which case a decoded frame is only ~829K.

I would suspect you are seeing this delay because:
1) You are getting your input over UDP in small packets and
2) The codec is telling us we need to queue up 1.5MB of data before processing
a frame.

It probably takes about 1 minute to transfer 1.5MB of data over udp -- maybe you
can test.

You may want to replace &quot;TIViddec2&quot; with &quot;TIViddec2
displayBuffer=TRUE&quot; in your pipeline if you want to see the data
queuing up. This may help you to confirm this.

One could potentially optimize this in the plugin by parsing H.264 frames and
invoking the codec when we know a complete encoded frame is available. However,
this is not available today, and such an optimization must not interfere with
using other codecs in TIViddec2.