Splitting source to measure latency

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Splitting source to measure latency

Wolfgang Grandegger
Hello,

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?

Wolfgang.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Splitting source to measure latency

James Cameron
On Tue, May 29, 2018 at 12:27:00PM +0200, Wolfgang Grandegger wrote:

> Hello,
>
> 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?

I'm only new here, but does your exactly one second change if you
give each queue a max-size-time other than the default of one second?

Could you examine current-level-time of each queue?

--
James Cameron
http://quozl.netrek.org/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Splitting source to measure latency

Nicolas Dufresne-5
In reply to this post by Wolfgang Grandegger
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.

Nicolas
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Splitting source to measure latency

Wolfgang Grandegger
In reply to this post by James Cameron
Hello,

Am 29.05.2018 um 12:43 schrieb James Cameron:

> On Tue, May 29, 2018 at 12:27:00PM +0200, Wolfgang Grandegger wrote:
>> Hello,
>>
>> 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?
>
> I'm only new here, but does your exactly one second change if you
> give each queue a max-size-time other than the default of one second?
>
> Could you examine current-level-time of each queue?

Setting "max-size-time" to 0 didn't help. My problem was on the receiver
side, as pointed out by Nicolas. With VLC settings from [1] I was able
to reduce the latency below 100ms.

[1] https://www.slac.stanford.edu/grp/cd/soft/unix/VLC-setup.html

Wolfgang.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Splitting source to measure latency

Wolfgang Grandegger
In reply to this post by Nicolas Dufresne-5
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.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel