RTPsource : h264/rtp packets not received (update_receiver_stats: probation)

[sk_gst]

I have the following setup:
the client & server connected via LTE to a local server with separate IP
address for UDP streaming.
client= 192.168.5.x
server = 192.168.5.y

I am trying to stream video from server to client using GStreamer.
(short names used below in pipelines)

server = imxv4l2src ! imxh264enc ! h264parse ! rtph264pay ! rtpbin.send_rtp
! udpsink 192.168.5.x port=5001

client = udpsrc port=5001 ! rtpbin.recv_rtp ! rtph264depay ! h264parse !
avdec_h264 ! autovideosink

However, at the client side I receive the following errors:

pipeline0 from <enum GST_STATE_NULL of type Gst.State> to <enum
GST_STATE_READY of type Gst.State>
state change msg =  GstMessageStateChanged
pipeline0 from <enum GST_STATE_NULL of type Gst.State> to <enum
GST_STATE_READY of type Gst.State>
state change msg =  GstMessageStateChanged
pipeline0 from <enum GST_STATE_READY of type Gst.State> to <enum
GST_STATE_PAUSED of type Gst.State>
state change msg =  GstMessageStateChanged
pipeline0 from <enum GST_STATE_READY of type Gst.State> to <enum
GST_STATE_PAUSED of type Gst.State>
state change msg =  GstMessageStateChanged
0:00:00.825717967  4088      0x25dc2d0 WARN               rtpsource
rtpsource.c:1184:update_receiver_stats: probation: seqnr 49703 != expected
49554
0:00:00.977509125  4088      0x25dc2d0 WARN               rtpsource
rtpsource.c:1184:update_receiver_stats: probation: seqnr 49890 != expected
49704
0:00:01.127490025  4088      0x25dc2d0 WARN               rtpsource
rtpsource.c:1184:update_receiver_stats: probation: seqnr 50040 != expected
49891
0:00:01.371342426  4088      0x25dc2d0 WARN               rtpsource
rtpsource.c:1184:update_receiver_stats: probation: seqnr 50310 != expected
50041
0:00:02.181474240  4088      0x25dc2d0 WARN               rtpsource
rtpsource.c:1184:update_receiver_stats: probation: seqnr 51011 != expected
50311
0:00:03.655496030  4088      0x25dc2d0 WARN               rtpsource
rtpsource.c:1184:update_receiver_stats: probation: seqnr 51810 != expected
51012
0:00:03.807527304  4088      0x25dc2d0 WARN               rtpsource
rtpsource.c:1184:update_receiver_stats: probation: seqnr 51930 != expected
51811
0:00:03.867335896  4088      0x25dc2d0 WARN               rtpsource
rtpsource.c:1184:update_receiver_stats: probation: seqnr 51989 != expected
51931
0:00:04.291383138  4088      0x25dc2d0 WARN               rtpsource
rtpsource.c:1184:update_receiver_stats: probation: seqnr 52357 != expected
51990


1. The same application works, when I use a WiFi adhoc connection between the
client-server devices.
2. With the same setup of LTE and a local server between client and server device,  another application which uses only UDP based communication to send continuous 20 bytes of sensor data  to client device works fine.

I believe the packets are getting lost as I am using LTE and a local server.
Hence the client pipeline never goes into PLAYING state.  And this is the
reason why Gstreamer is unable to display the video. I suspect the element `rtpbin`. The ping latency
between client-server is between 120-140 ms.  

Can anyone point out some hints, that might help.

Regards



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[e-mail]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le mar. 19 mars 2019 06 h 26, vk_gst <[hidden email]> a écrit :

I have the following setup:
the client & server connected via LTE to a local server with separate IP
address for UDP streaming.
client= 192.168.5.x
server = 192.168.5.y

I am trying to stream video from server to client using GStreamer.
(short names used below in pipelines)

server = imxv4l2src ! imxh264enc ! h264parse ! rtph264pay ! rtpbin.send_rtp
! udpsink 192.168.5.x port=5001

I don't see any bitrate configuration on the encoder and the udpsink. Maybe transmission is too bursty?

client = udpsrc port=5001 ! rtpbin.recv_rtp ! rtph264depay ! h264parse !
avdec_h264 ! autovideosink

Maybe you need to increase the socket buffer size ?

However, at the client side I receive the following errors:

pipeline0 from <enum GST_STATE_NULL of type Gst.State> to <enum
GST_STATE_READY of type Gst.State>
state change msg =  GstMessageStateChanged
pipeline0 from <enum GST_STATE_NULL of type Gst.State> to <enum
GST_STATE_READY of type Gst.State>
state change msg =  GstMessageStateChanged
pipeline0 from <enum GST_STATE_READY of type Gst.State> to <enum
GST_STATE_PAUSED of type Gst.State>
state change msg =  GstMessageStateChanged
pipeline0 from <enum GST_STATE_READY of type Gst.State> to <enum
GST_STATE_PAUSED of type Gst.State>
state change msg =  GstMessageStateChanged
0:00:00.825717967  4088      0x25dc2d0 WARN               rtpsource
rtpsource.c:1184:update_receiver_stats: probation: seqnr 49703 != expected
49554
0:00:00.977509125  4088      0x25dc2d0 WARN               rtpsource
rtpsource.c:1184:update_receiver_stats: probation: seqnr 49890 != expected
49704
0:00:01.127490025  4088      0x25dc2d0 WARN               rtpsource
rtpsource.c:1184:update_receiver_stats: probation: seqnr 50040 != expected
49891
0:00:01.371342426  4088      0x25dc2d0 WARN               rtpsource
rtpsource.c:1184:update_receiver_stats: probation: seqnr 50310 != expected
50041
0:00:02.181474240  4088      0x25dc2d0 WARN               rtpsource
rtpsource.c:1184:update_receiver_stats: probation: seqnr 51011 != expected
50311
0:00:03.655496030  4088      0x25dc2d0 WARN               rtpsource
rtpsource.c:1184:update_receiver_stats: probation: seqnr 51810 != expected
51012
0:00:03.807527304  4088      0x25dc2d0 WARN               rtpsource
rtpsource.c:1184:update_receiver_stats: probation: seqnr 51930 != expected
51811
0:00:03.867335896  4088      0x25dc2d0 WARN               rtpsource
rtpsource.c:1184:update_receiver_stats: probation: seqnr 51989 != expected
51931
0:00:04.291383138  4088      0x25dc2d0 WARN               rtpsource
rtpsource.c:1184:update_receiver_stats: probation: seqnr 52357 != expected
51990


The same application works, when I use a WiFi adhoc connection between the
client-server devices. Another applicatiion which uses UDP based
communication to send continuous 20 bytes of sensor data  to client device
over LTE works fine as well.

I believe the packets are getting lost as I am using LTE and a local server.
Hence the client pipeline never goes into PLAYING state. And this is the
reason why Gstreamer is unable to display the video. The ping latency
between client-server is between 120-140 ms. 

Can anyone point out some hints, that might help.

Regards



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
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

[sk_gst]

Hi,

Thanks for the hint.

The bitrate on encoder and 'udpsink' was set to 1000 Kbps. Additionally, I
tried varying the buffer size of 'udpsrc' on client pipeline to 50K - 100k as per  UDP_src
<https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good/html/gst-plugins-good-plugins-udpsrc.html#GstUDPSrc--buffer-size> 
.

With the above changes there was no change in the behavior. I used wireshark
to analyse the server and client device. Here is the output I receive at the
server device:

server = 192.168.5.222, client = 192.168.5.221 and I am using port 5001 at
udpsink for video.


   8 1.921299652      0.0.0.0 → 255.255.255.255 UDP 107 4712 → 4711 Len=65
    9 1.921429997      0.0.0.0 → 255.255.255.255 UDP 99 4712 → 4711 Len=57
   10 1.942681993 192.168.5.222 → 192.168.5.221 UDP 56 50833 → 5001 Len=14
   11 2.054841859 192.168.5.222 → 192.168.5.221 UDP 63 50833 → 5001 Len=21
   12 2.058376191 192.168.5.221 → 192.168.5.222 ICMP 84 Destination
unreachable (Port unreachable)
   13 2.169254947 192.168.5.221 → 192.168.5.222 ICMP 91 Destination
unreachable (Port unreachable)
   14 2.222870320 192.168.5.222 → 192.168.5.221 UDP 58 50833 → 5001 Len=16
   15 2.246495208 192.168.5.21 → 192.168.5.255 UDP 774 51437 → 7000 Len=732
   16 2.349279536 192.168.5.221 → 192.168.5.222 ICMP 86 Destination
unreachable (Port unreachable)
   17 2.350906356 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
Len=1400
   18 2.351536082 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
Len=1400
   19 2.352102802 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
Len=1400
   20 2.352645519 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
Len=1400
   21 2.353190237 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
Len=1400
   22 2.353721287 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
Len=1400
   23 2.354265005 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
Len=1400
   24 2.354827391 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
Len=1400
   25 2.355372109 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
Len=1400
   26 2.355926161 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
Len=1400
   27 2.356489547 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
Len=1400
   28 2.357056267 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
Len=1400
   29 2.357675659 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
Len=1400
   30 2.358255047 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
Len=1400
   31 2.358807432 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
Len=1400
   32 2.359473161 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
Len=1400


After this, there are no video packets sent to port 5001 from the server
device (192.168.5.222). However the server regularly sends rtcp sender
report (on port 5002) to the client device. eg:

836 159.050823685 192.168.5.222 192.168.5.221 UDP 102 40336 → 5002 Len=60
866 164.816046582 192.168.5.222 192.168.5.221 UDP 102 40336 → 5002 Len=60
882 168.335318185 192.168.5.222 192.168.5.221 UDP 102 40336 → 5002 Len=60

What could be the reason that only sender reports are being sent by the
server device and no rtp video packets. What I understand is that the error
'Port Unreachable' can be due to the client application not able to handle
the received data.

Can anyone point out where I am going wrong?

Regards.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[e-mail]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Marc Leeman]

Typically, RTP data should be send on even ports, while the RTCP
packet is sent to the port + 1 (RFC 3550)

I would also recommend muxing sps/pps in your output (rph264pay
config-interval=1)

If you do not hook up the ports correctly, RTCP will not help (since
RTCP is bidirectional on the same socket, it is not trivial to do
unless you use the 3-port non-standard example in the rtpbin
documentation).

I do not understand you you are getting sender reports from your
gstreamer sender device since you are not sending out RTCP.

You would see more if you dump the network information to pcap and
inspect it with wireshark.

You'll have to change the UDP detected format to RTP to see the RTP
packet information in a clean way.

You can see if the RTP packets are lost on the network or for some
other reason. If you bitstream is only 1 Mbps, GStreamer should be
able to handle it. If it is higher, you need to specify higher kernel
buffers with sysctl

sysctl -w net.core.wmem_max = 4194304
sysctl -w net.core.wmem_default = 4194304
sysctl -w net.core.rmem_max = 4194304
sysctl -w net.core.rmem_default = 4194304


On Wed, 20 Mar 2019 at 11:27, vk_gst <[hidden email]> wrote:

>
> Hi,
>
> Thanks for the hint.
>
> The bitrate on encoder and 'udpsink' was set to 1000 Kbps. Additionally, I
> tried varying the buffer size of 'udpsrc' to 50K - 100k as per  UDP_src
> <https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good/html/gst-plugins-good-plugins-udpsrc.html#GstUDPSrc--buffer-size>
> .
>
> With the above changes there was no change in the behavior. I used wireshark
> to analyse the server and client device. Here is the output I receive at the
> server device:
>
> server = 192.168.5.222, client = 192.168.5.221 and I am using port 5001 at
> udpsink for video.
>
>
>    8 1.921299652      0.0.0.0 → 255.255.255.255 UDP 107 4712 → 4711 Len=65
>     9 1.921429997      0.0.0.0 → 255.255.255.255 UDP 99 4712 → 4711 Len=57
>    10 1.942681993 192.168.5.222 → 192.168.5.221 UDP 56 50833 → 5001 Len=14
>    11 2.054841859 192.168.5.222 → 192.168.5.221 UDP 63 50833 → 5001 Len=21
>    12 2.058376191 192.168.5.221 → 192.168.5.222 ICMP 84 Destination
> unreachable (Port unreachable)
>    13 2.169254947 192.168.5.221 → 192.168.5.222 ICMP 91 Destination
> unreachable (Port unreachable)
>    14 2.222870320 192.168.5.222 → 192.168.5.221 UDP 58 50833 → 5001 Len=16
>    15 2.246495208 192.168.5.21 → 192.168.5.255 UDP 774 51437 → 7000 Len=732
>    16 2.349279536 192.168.5.221 → 192.168.5.222 ICMP 86 Destination
> unreachable (Port unreachable)
>    17 2.350906356 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
> Len=1400
>    18 2.351536082 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
> Len=1400
>    19 2.352102802 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
> Len=1400
>    20 2.352645519 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
> Len=1400
>    21 2.353190237 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
> Len=1400
>    22 2.353721287 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
> Len=1400
>    23 2.354265005 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
> Len=1400
>    24 2.354827391 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
> Len=1400
>    25 2.355372109 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
> Len=1400
>    26 2.355926161 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
> Len=1400
>    27 2.356489547 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
> Len=1400
>    28 2.357056267 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
> Len=1400
>    29 2.357675659 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
> Len=1400
>    30 2.358255047 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
> Len=1400
>    31 2.358807432 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
> Len=1400
>    32 2.359473161 192.168.5.222 → 192.168.5.221 UDP 1442 50833 → 5001
> Len=1400
>
>
> After this, there are no video packets sent to port 5001 from the server
> device (192.168.5.222). However the server regularly sends rtcp sender
> report (on port 5002) to the client device. eg:
>
> 836     159.050823685   192.168.5.222   192.168.5.221   UDP     102     40336 → 5002 Len=60
> 866     164.816046582   192.168.5.222   192.168.5.221   UDP     102     40336 → 5002 Len=60
> 882     168.335318185   192.168.5.222   192.168.5.221   UDP     102     40336 → 5002 Len=60
>
> What could be the reason that only sender reports are being sent by the
> server device and no rtp video packets. What I understand is that the error
> 'Port Unreachable' can be due to the client application not able to handle
> the received data.
>
> Can anyone point out where I am going wrong?
>
> Regards.
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> 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

[sk_gst]

Hi,

For simplicity I did not mention the complete pipeline I use. The actual
pipelines uses the 3 ports at sender and receiver just like in the
documentation of the element 'rtpbin'. I did not follow the convention of
using even and odd ports and the current setting looks like this: (however I
will correct this with the convention now)

Sender  : 5001 - RTP send,      5002 - RTCP send,  5005 - RTCP receive
Receiver: 5001 - RTP receive,   5002 - RTCP recv,   5005 - RTCP send

So the sender and receiver reports are available on 5002 and 5005
accordingly.

I did not understand the following : "I do not understand you you are
getting sender reports from your Gstreamer sender device since you are not sending out RTCP. "  Could you please let me know what you mean here?

I would test the system again with your suggested hints and update
accordingly.


Regards.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[e-mail]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel