RTPsource : h264/rtp packets not received (update_receiver_stats: probation)
Nicolas Dufresne
nicolas at ndufresne.ca
Tue Mar 19 23:01:08 UTC 2019
Le mar. 19 mars 2019 06 h 26, vk_gst <venkateshkuppan26 at gmail.com> 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
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190319/94c1af01/attachment-0001.html>
More information about the gstreamer-devel
mailing list