| Hi Mohammad I can think of several reasons for this to occur. - You might be losing the first key frame, and the next one doesn’t show up until 5 seconds later. * Do you see this if you start the receiver first and then the sender? * Does the video start from the beginning after the initial delay? Or is it already started? - It may be a timestamping problem. * Have you tried setting sync=TRUE in the receiver? This will allow the pipeline to drop frames if needed in order to keep up with the stream time, instead of trying to display everything regardless of the lateness. * Have you tried using the jitter buffer? - H264 profile may induce latency * As per the standard, H264 decoders must ensure there is enough data buffered to allow appropriate decoding. Depending on the profile used during the encoding phase, forward and backward predicted frames may required more data to be buffered, hence increasing latency. Some encoders have a “low latency” configuration, in which compression level is reduced in favor of lower latency. * You need to identify if the latency is being accounted to the decoder. In any case, latency is always a hard issue to tackle. At RidgeRun we developed GstShark, a set of open source GStreamer tracers that may help you debug this issue. Please take a look at the Interlatency tracer which may help you identify latency and processing bottlenecks in your pipeline. If the decoder is queueing this data, for example, the tracers should expose this. — Michael Gruner <michael.gruner@xxxxxxxxxxxx> Embedded Linux and GStreamer solutions RidgeRun Engineering Contact Us - http://www.ridgerun.com/#!contact/c3vn
|
_______________________________________________ gstreamer-embedded mailing list gstreamer-embedded@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/gstreamer-embedded
