Splitting source to measure latency

[Wolfgang Grandegger]

Hello Nicolas,

I readded the ML to the CC...

Am 29.05.2018 um 15:31 schrieb Nicolas Dufresne:
> Le mardi 29 mai 2018 à 15:11 +0200, Wolfgang Grandegger a écrit :
>> Hello Nicolas,
>>
>> Am 29.05.2018 um 14:14 schrieb Wolfgang Grandegger:
>>> Hello,
>>>
>>> Am 29.05.2018 um 13:12 schrieb Nicolas Dufresne:
>>>> Le mardi 29 mai 2018 à 12:27 +0200, Wolfgang Grandegger a écrit :
>>>>> I want to split the video source to measure the latency between a video
>>>>> generated and displayed on a local and remote display using:
>>>>>
>>>>> # gst-launch-1.0 -v videotestsrc \
>>>>>   ! video/xraw,format=RGBx,width=800,height=600,framerate=30/1 \
>>>>>   ! timeoverlay ! tee name=t \
>>>>>   t. ! queue ! kmssink
>>>>>   t. ! queue ! vaapipostproc ! vaapijpegenc quality=90 \
>>>>>      ! rtpjpegpay ! udpsink host=192.168.0.254 port=50004
>>>>>
>>>>> I'm interested in the latency due to:
>>>>>
>>>>>  vaapipostproc ! vaapijpegenc quality=90 ! rtpjpegpay \
>>>>>  ! udpsink host=192.168.0.254 port=50004
>>>>>
>>>>> Then I take a picture of both, the local and the remote display. I see
>>>>> that the time of the video on the remote side is delayed by more or less
>>>>> exactly *one* second. How does the "tee" deliver the packages to both
>>>>> streams? One by one? Is it possible at all to measure the latency using
>>>>> "tee"? Have I missed something else?
>>>>
>>>> tee is synchronous and single threaded, that's why you need queue
>>>> afterward. Though, it should not introduce a large delay like y uhave
>>>> described. I'd look at your receiver side for delays.
>>>
>>> Thanks for you hint... I'm using VLC on the receiver side using a
>>> default network cache of 1 second. With settings describe in [1] I was
>>> able to reduce the latency below 100ms.
>>
>> Sometimes the time delay between on the picture  is even less than 50ms.
>> Is that realistic? What can I expect? OK, "kmssink" also introduces some
>> latency.
> 
> Display drivers will introduce some latency, but it's variable, because
>  the display refresh is not synchronized with the stream rate. So let's
> assumes 60 fps, which means a bit more then 16ms, times two, kmssink
> and VLC, you already have a plausible variation of 32ms. Then another
> aspect, vlc implement a adaptive jitterbuffer, which mean it will
> increase the delay is there is too much jitter.
> 
> If you try with a gstreamer receiver, you should be able to test even
> lower latency on local network.

That makes sense and does confirm what I measure. The delay between both
times various between 0 and 3x16ms. So far I didn't use GStreamer
because I'm still at Ubuntu 14.04. Will switch to my PC with 16.04.

Thanks,

Wolfgang.