compute latency in video streaming

[Steve Cookson]

Hi Frank,

Actually, I think your original method was good as it covers all the 
hardware components (eg from the webcam itself and any delay there, to 
the display screen and the 5-10 msecs there too).

The way you describe looks strange at first, because the millisecs are 
often scrambled.  But when you correct for the imperfections in the 
method they become very accurate.

I have just been doing some timing myself using a Dazzle capture card, 
via gstreamer and then displaying on the screen.

At fist my numbers look like this (from a much bigger sample):

T1    T2    (T1 -T2)x1000    Frames
0.851    0.732    119    3.57
0.786    0.658    128    3.84
0.453    0.355      98    2.94
0.550    0.420    130    3.90

The overall average was about 130 msecs.

Then I start to do some calculations.  Put in queue-size=6 (bigger than 
the number of frames delay).

I realise that the reason the milliseconds are confused is because 
s-video is interlaced, so that there will be two numbers 15/16 
milliseconds apart superposed on one another.  So I can calculate what 
the numbers really are.

Sometimes the delay is 2 frames, sometimes five or more.  I take 
everything off the computer that doesn't need to be there.  The 
millisecond clock runs on my smartphone, I played with doing screen 
grabs, but they also use CPU time, so I used a second camera.

I closed down all the background systems that Linux comes with like 
indexing and Akonadi.

After playing around, we got something like this:

(T1 -T2)x1000

103 (3 frames)
130 (4 frames)
133 (4 frames)
105 (3 frames)

And finally on the production system: 76 millisecs.  Time for a beer.

There are also proffessional organisations like RidgeRun, who have some 
nice webpages on latency:

eg 
http://developer.ridgerun.com/wiki/index.php/DM365_LeopardBoard_network_video_streaming_latency_test

It can be done and the time pays off.

Good luck,

Regards

Steve.



On 07/01/15 06:12, frank82 wrote:
> Thank you for the answer. Unfortunately I don't have any clockoverlay element
> in the server side (I have it only on the client PC) and I can not rebuild
> all now. Moreover I was looking for a solution that doesn't add any other
> element in the pipeline because, for what I know, the latency depends also
> on the number of element in the pipeline. Any other idea?
> thanks again for the support.
>
>
>
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble.com/compute-latency-in-video-streaming-tp4670068p4670129.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel