evaluate latency for RTP streaming

[snowmania]

Hello,

 

I’m trying to evaluate the latency for a simple pipeline: H264 encoding and transmission via RTP/UDP

My pipeline is:

gst-launch-1.0 -v v4l2src device=/dev/video0 ! 'video/x-raw, format=(string)I420, width=(int)640, height=(int)480' ! omxh264enc bitrate=1000000 control-rate=2 ! h264parse ! rtph264pay ! udpsink host=X.X.X.X port=9078

 

I read about this post on stackoverflow

https://stackoverflow.com/questions/23869562/how-can-i-quantitatively-measure-gstreamer-h264-latency-between-source-and-displ

And the latency clock project seems interesting.

 

However, before trying it out I’d like to make sure there’s not a more simple solution (I’m not looking for latency of encoding but that of network)

 

I’m monitoring the traffic via Wireshark on the receiver side.

So I can easily access the timestamp of the rtp packet and compare it to the timestamps when it was received.

 

Assuming my 2 computers (sender and receiver) are roughly on the same clock, is there a way to set the timestamp on the receiver to the time the packet is issued?

I saw one option for rtph264 is to set timestamps-offset but not sure how to use that (as far as gst-inspect can tell timestamps is only readable for rtph264pay).

 

Any help is appreciated!

Claire

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le mercredi 10 octobre 2018 à 10:41 +0000, Claire Mantel a écrit :

> Hello,
>  
> I’m trying to evaluate the latency for a simple pipeline: H264
> encoding and transmission via RTP/UDP
> My pipeline is:
> gst-launch-1.0 -v v4l2src device=/dev/video0 ! 'video/x-raw,
> format=(string)I420, width=(int)640, height=(int)480' ! omxh264enc
> bitrate=1000000 control-rate=2 ! h264parse ! rtph264pay ! udpsink
> host=X.X.X.X port=9078
>  
> I read about this post on stackoverflow
>

https://stackoverflow.com/questions/23869562/how-can-i-quantitatively-measure-gstreamer-h264-latency-between-source-and-displ
> And the latency clock project seems interesting.
>  
> However, before trying it out I’d like to make sure there’s not a
> more simple solution (I’m not looking for latency of encoding but
> that of network)

Will's solution is a very reliable light to light method to measure
latency. I don't think you'll find anything more accurate then this.
Though, it includes capture, encoder, network, decoder and render
latency.

>  
> I’m monitoring the traffic via Wireshark on the receiver side.
> So I can easily access the timestamp of the rtp packet and compare it
> to the timestamps when it was received.
>  
> Assuming my 2 computers (sender and receiver) are roughly on the same
> clock, is there a way to set the timestamp on the receiver to the
> time the packet is issued?
> I saw one option for rtph264 is to set timestamps-offset but not sure
> how to use that (as far as gst-inspect can tell timestamps is only
> readable for rtph264pay).

You need a bit more then "roughly" the same clock. You need both sender
and receiver to share the same base time for this approach. Latency
would be best measure using RTCP feedback. I don't know much of the
details though.

>  
> Any help is appreciated!
> Claire
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel