From: Andreas A. <a....@zy...> - 2011-01-31 08:30:22
|
Hello, I hope someone can help me. I have an IGEPv2 board with an OMAP3530 cpu. Currently, I'm trying to stream an H264 rtp stream to the board decode it on the board with the DSP and show the decoded video on the screen. The problem is that the video output with the TIDmaiVideoSink does not sync correctly. The problem is that the decoder buffers quite long (about 30 seconds). So, the first decoded frame is displayed with a delay of 30 seconds. And therefore the base class "GstBaseSink" wants to regain the past 30 seconds and plays the decoded frames as fast es possible. 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. Cheers, Andreas -- DI Andreas Auer aauer1 (at) gmail.com http://about.me/Andreas.Auer |
From: Marco B. <gib...@gm...> - 2011-01-31 21:33:44
|
Hi, 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. Some pointers: http://gstreamer-devel.966125.n4.nabble.com/Video-and-Audio-sync-problem-td2322769.html http://gstreamer-devel.966125.n4.nabble.com/long-pauses-during-rtsp-playback-td2997863.html http://gstreamer-devel.966125.n4.nabble.com/long-pauses-when-viewing-RTSP-stream-td3001831.html http://gstreamer-devel.966125.n4.nabble.com/Help-on-execution-speed-and-optimization-in-gst-launch-td3005694.html ... and this (which is suspiciously similar to your issue) http://gstreamer-devel.966125.n4.nabble.com/Help-on-execution-speed-and-optimization-in-gst-launch-td3005694.html 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 cases though). On Mon, Jan 31, 2011 at 10:28 AM, Andreas Auer <a....@zy...> wrote: ..snip.. > 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)? Regards > > Cheers, > 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 > Gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > |
From: Andreas A. <a....@zy...> - 2011-02-01 07:32:01
|
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 |
From: Sjoerd S. <sj...@lu...> - 2011-02-01 23:13:08
|
On Mon, 2011-01-31 at 23:33 +0200, Marco Ballesio wrote: > 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)? Fwiw, i've used gst-dsp on my IGEPv2 boards and it works quite well and doesn't seem to have any of the latency issue that people seem to encounter with the TI elements. -- Sjoerd Simons <sj...@lu...> |
From: Andreas A. <a....@zy...> - 2011-02-04 09:02:50
|
Thanks for your reply. Do you have a tutorial which shows how I can get gst-dsp running on my IGEPv2 board?? I already have compiled the sources from "git://github.com/felipec/gst-dsp.git". Do I need to load the bridgedriver kernel module to use gst-dsp?? Which kernel version do you use? Is it one of the kernels which are available at the GIT repository of IGEP?? Thanks, Andreas On 2011-02-01 23:55, Sjoerd Simons wrote: > On Mon, 2011-01-31 at 23:33 +0200, Marco Ballesio wrote: >> 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)? > > Fwiw, i've used gst-dsp on my IGEPv2 boards and it works quite well and > doesn't seem to have any of the latency issue that people seem to > encounter with the TI elements. > |