Thank you for your reply and the interesting links. I wonder why I haven't found them with google. BTW the decoder always buffers 1.5MB of data before decoding. But in the case you are getting the data from a file it cannot be noticed that the buffer is that big. I'll try to change this behavior after I have solved the synchronization issue.
On 2011-01-31 22:33, Marco Ballesio wrote: > 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. You are right the video decoder doesn't declare its latency in a correct way. I found it yesterday while debugging and looking at the code. I think if the latency query is correct the large buffer shouldn't be a problem. > Said so, a few workarounds are possible, the easiest one being an > increase in the bitrate feeding the decoder (not possible in all the > cases though). Increasing the bitrate isn't possible for me. I think the only way for me is to declare the correct latency. Curious that this haven't been done by TI itself. Thanks for your help, Andreas -- DI Andreas Auer aauer1 (at) gmail.com http://about.me/Andreas.Auer ------------------------------------------------------------------------------ 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! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Gstreamer-embedded mailing list Gstreamer-embedded@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
