Difference between revisions of "RTSP over UDP"

From ElphelWiki
Jump to: navigation, search
(Other links)
(Notes)
 
(4 intermediate revisions by the same user not shown)
Line 6: Line 6:
 
==Notes==
 
==Notes==
  
* In situations when streaming across middleboxes (switches and other devices) make sure the camera link is the slowest one.
+
* '''In situations when streaming across middleboxes (switches and other devices) make sure the camera link to the closest network device is the slowest one or keep the image size small enough so it does not overflow any middlebox's buffers'''.
 
* Example congestion situatation:
 
* Example congestion situatation:
  ''camera <-- 1000Mbps --> Gigabit switch <-- 100Mbps (PC NIC limited) --> PC''
+
  <font size=2>'''camera''' <-- 1000Mbps --> '''Gigabit switch''' <-- 100Mbps (PC NIC limited) --> '''PC'''</font>
 
  PC might not get all the packets depending on switch's buffers sizes (e.g. for netgear GS105 has 128kB which gets overflowed at image sizes 200+kB)
 
  PC might not get all the packets depending on switch's buffers sizes (e.g. for netgear GS105 has 128kB which gets overflowed at image sizes 200+kB)
 
* Setting link speed examples:
 
* Setting link speed examples:
Line 50: Line 50:
 
==Other links==
 
==Other links==
 
* [https://www.dataexpedition.com/support/notes/tn0021.html Loss, Latency, and Speed] - some general info
 
* [https://www.dataexpedition.com/support/notes/tn0021.html Loss, Latency, and Speed] - some general info
* [https://tools.ietf.org/html/rfc4585 RFC4585] Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)
+
* [https://tools.ietf.org/html/rfc4585 RFC4585]: Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)
* [https://tools.ietf.org/html/rfc6679 RFC6679] Explicit Congestion Notification (ECN) for RTP over UDP
+
* [https://tools.ietf.org/html/rfc6679 RFC6679]: Explicit Congestion Notification (ECN) for RTP over UDP
* [https://tools.ietf.org/html/rfc8087 RFC8087] The Benefits of Using Explicit Congestion Notification (ECN)
+
* [https://tools.ietf.org/html/rfc8087 RFC8087]: The Benefits of Using Explicit Congestion Notification (ECN)
* [https://tools.ietf.org/html/rfc8311 RFC8311] Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation
+
* [https://tools.ietf.org/html/rfc8311 RFC8311]: Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation
  
 
[[Category:393]]
 
[[Category:393]]

Latest revision as of 10:20, 20 March 2019

About

  • 10393 series
  • /usr/bin/str

Notes

  • In situations when streaming across middleboxes (switches and other devices) make sure the camera link to the closest network device is the slowest one or keep the image size small enough so it does not overflow any middlebox's buffers.
  • Example congestion situatation:
camera <-- 1000Mbps --> Gigabit switch <-- 100Mbps (PC NIC limited) --> PC
PC might not get all the packets depending on switch's buffers sizes (e.g. for netgear GS105 has 128kB which gets overflowed at image sizes 200+kB)
  • Setting link speed examples:
ethtool -s eth0 speed 100 duplex half autoneg off
ethtool -s eth0 speed 1000 duplex full autoneg off
  • dump UDP packets log on the camera (tcpdump if installed):
tcpdump -i eth0 -n udp port <someport> -w packets.pcap
  • log network packets on PC:
wireshark works fine
  • live555 is used by vlc and mplayer while gstreamer is standalone
As UDP has no congestion control there might be several workarounds:
1. patch live555 and gstreamer
2. slow down camera link
  • Patching live555 options:
1. Stick close to RFC4585 and RFC6679, also checkout RFC8087 & RFC8311?
2. Make RTCP RR reports sent out by the receiver for every 50 (or any other number) packets received - implement handling this info in the sender (camera)
Implementing 2:
    RTCP.c:
        if (fSource != NULL && fSource->RTPgs() == RTCPgs) {
            // We're receiving RTCP reports that are multiplexed with RTP, so ask the RTP source
            // to give them to us:
            fSource->registerForMultiplexedRTCPPackets(this);
        } else {
            // need to register our RTCP instance here it will be passed to MultiFramedRTPSource.c which receive RTP packets
            // just reused the instance for multiplexed packets
            fSource->registerForMultiplexedRTCPPackets(this);
        }
    MultiFramedRTPSource.c:
        receptionStatsDB().noteIncomingPacket(...)
        // insert after this line something like:
        int pnum = receptionStatsDB().totNumPacketsReceived();
        if ((pnum%50)==0){
            if (fRTCPInstanceForMultiplexedRTCPPackets!=NULL){
                // here fRTCPInstanceForMultiplexedRTCPPackets is just reused
                fRTCPInstanceForMultiplexedRTCPPackets->sendReport();
            }
        }
  • Patching gstreamer:
First, need to find how to make gstreamer send RR reports. Then proceed as with live555.

Other links

  • Loss, Latency, and Speed - some general info
  • RFC4585: Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)
  • RFC6679: Explicit Congestion Notification (ECN) for RTP over UDP
  • RFC8087: The Benefits of Using Explicit Congestion Notification (ECN)
  • RFC8311: Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation