What is happening in this pipeline (rtpbin sending and receiving simultaneously)

[Хазанский Роман]

I'm trying to send video using udp and I want the lowest possible latency.

 

I was given this pipeline as an example; they are supposed to be 'better' than simply sending rtp video. More specifically, they are supposed to decrease latency and remove freezed-frames (and in my experience they do). But I don't understand what exactly is happening here, why video sender is also receiving something from video receiver (on 6005 port) and how does it help.

 

Video sender:

 

gst-launch-1.0 -v rtpbin ntp-sync=false name=rtpbin \
    v4l2src ! videoconvert ! video/x-raw, width=800, height=600, framerate=30/1 ! videoscale ! jpegenc ! rtpjpegpay ! rtpbin.send_rtp_sink_0 \
    rtpbin.send_rtp_src_0 ! udpsink port=6000 host=192.168.26.1 name=vrtpsink \
    rtpbin.send_rtcp_src_0 ! udpsink port=6001 host=192.168.26.1 sync=false async=false name=vrtcpsink \
    udpsrc port=6005 name=vrtpsrc ! rtpbin.recv_rtcp_sink_0

 

Video receiver:

 

gst-launch-1.0 -v rtpbin name=rtpbin buffer-mode=4 ntp-sync=true do-retransmition=false latency=10 drop-on-latency=true \
    udpsrc caps="application/x-rtp,media=video,clock-rate=90000,encoding-name=JPEG,payload=26" port=6000 ! rtpbin.recv_rtp_sink_0 \
    rtpbin. ! rtpjpegdepay ! jpegdec ! autovideosink sync=false \
    udpsrc port=6001 ! rtpbin.recv_rtcp_sink_0 \
    rtpbin.send_rtcp_src_0 ! udpsink port=6005 host=192.168.26.9 sync=false async=false  

 

Can anyone please explain what is happening here and does this 'reverse rtcp' really reduce latency?

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

[Sebastian Dröge-3]

On Mi, 2016-07-06 at 12:48 +0300, Хазанский Роман wrote:
> [...]
> Can anyone please explain what is happening here and does this
> 'reverse rtcp' really reduce latency?

This is using the rtpbin element, which in addition to doing RTCP also
has an rtpjitterbuffer on the receiver side, which is probably the
reason why it works better for you. Doing RTP without rtpjitterbuffer
requires very good network conditions.

RTCP won't reduce latency or solve anything on its own, but it can be
used for various control and statistics. It's not used for anything
meaningful in your pipeline though.


Also in your pipeline, you set buffer-mode=4 ntp-sync=true and
sync=false on the video sink. This does not really make much sense.
What's your goal, what's the bigger picture?

--

Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel