0

I'm trying to send and receive video stream with delay as low as possible. For sending I use gstreamer on linux:

gst-launch-1.0 -v rtpbin ntp-sync=false name=rtpbin \
    v4l2src do-timestamp=true ! jpegenc ! rtpjpegpay ! rtpbin.send_rtp_sink_0 \
    rtpbin.send_rtp_src_0 ! udpsink port=2000 host=192.168.1.10 name=vrtpsink \
    rtpbin.send_rtcp_src_0 ! udpsink port=2001 host=192.168.1.10 sync=false async=false name=vrtcpsink \
    udpsrc port=2005 name=vrtpsrc ! rtpbin.recv_rtcp_sink_0

this pipeline sends video to port 2000 and uses ports 2001 and 2005 for some 'magical' rtcp synchronization.

If I use gstreamer on linux as a receiver, it works great; I get delays below 400 ms.

However, I'm struggling to get the same performance when receiving on windows. What did I try:

  • VLC. Doesn't seem to support rtcp at all.
  • gstreamer for windows. Seems to work strange, producing huge delays or even slideshows instead of video; rtcp doesn't seem to work.
  • ffmpeg. Opens rtcp port but it doesn't affect anything at all. Delay with -nobuffer option is about 1000 ms.

Do I have any options left? Any kind of library or sdk?

Amomum
  • 6,217
  • 8
  • 34
  • 62
  • Just a few comments: as per the standard, if video is on 2000, only 2001 should be used for RTCP. Also, VLC uses live555 which does support RTCP. What makes you think that it doesn't. In my experience over the last couple of years, VLC is just not very good at playing content with low delay. Also, you don't seem to be streaming audio so proper synchronisation doesn't seem necessary anyway. The only 'magical' thing RTCP does in that case is map RTP timestamps to NTP timestamps. – Ralf Jun 28 '16 at 15:07
  • You are correct, I posted receiver script, not the sender. I will update my answer now. – Amomum Jun 28 '16 at 15:19
  • @Ralf right, now question is correct. Video rtp is sent to 2000 and rtcp is sent to 2001. However, sender is also _receiving_ something in 2005 port (and I'm not sure if that is per standart). For testing VLC and ffmpeg I used the same sdp-file and ffmpeg opened rtcp port (I saw no discarded packets in wireshark) while VLC didn't. May be I did something wrong. I'm not sure why exactly rtcp between to gstreamer produces lower delay, that is just from experimenting. If there is some other trick - please, share! – Amomum Jun 28 '16 at 15:27
  • No idea what the 2005 port is being used for. However in any case I think it's unlikely RTCP has anything to do with the lower delay you're seeing. The delay before rendering is typically a result of the jitter buffer used by the application. ffmpeg usually works relatively well. Have you tried ffmpeg on linux? – Ralf Jun 28 '16 at 20:54
  • @Ralf I presumed that lower delay was the result of some kind 'smart dropping' of frames on the sender side when receiver was overflowing and rtcp was used for that. That kind of reason for delay is more likely to be seen on wireless connection with unstable bandwidth (on wired connection vlc can be tweaked to produce satisfactory results). Ffmpeg on linux produced the same kind of delay as on windows, more or less. – Amomum Jun 28 '16 at 22:00

0 Answers0