[gst-embedded] Syncing in TIDmaiVideoSink
gibrovacco at gmail.com
Mon Jan 31 13:33:37 PST 2011
this question is periodically coming to GStreamer mailing lists (I
guess it depends on the Moon phases ;) ).
I must admit I never had access to any hw using TIDmaiVideoSink but it
appears I've got lots of experience on the subject :D.
... and this (which is suspiciously similar to your issue)
In short, it is the decoder which uses -under some conditions- a
fixed-size buffer for storing encoded data, this meaning that, in case
of low resolutions, frame rates and -especially- bitrates it will take
a few seconds before the video decoder emits anything. I just wonder
if/why the element is not properly declaring its latency.
Said so, a few workarounds are possible, the easiest one being an
increase in the bitrate feeding the decoder (not possible in all the
On Mon, Jan 31, 2011 at 10:28 AM, Andreas Auer <a.auer at zydacron.com> wrote:
> Does anybody know if there is a patch for this problem? Why does the
> GstBaseSink believe the frames are too late. IMHO the GstBaseSink
> shouldn't take the latency of the upstream elements into account.
yes, if the upstream elements declare a proper latency. It's possibly
a bug for the decoder element, not maintained by this community
afaik.. have you considered / tried using gst-dsp instead (I don't
know whether it runs on your particular hw)?
> DI Andreas Auer aauer1 (at) gmail.com
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> Gstreamer-embedded mailing list
> Gstreamer-embedded at lists.sourceforge.net
More information about the Gstreamer-embedded