Difference between revisions of "RTSP over UDP"
From ElphelWiki
(→Other links) |
|||
Line 49: | Line 49: | ||
==Other links== | ==Other links== | ||
− | * [https://www.dataexpedition.com/support/notes/tn0021.html Loss, Latency, and Speed] | + | * [https://www.dataexpedition.com/support/notes/tn0021.html Loss, Latency, and Speed] - some general info |
− | * [https://tools.ietf.org/html/rfc4585 RFC4585 | + | * [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 | + | * [https://tools.ietf.org/html/rfc6679 RFC6679] Explicit Congestion Notification (ECN) for RTP over UDP |
− | * [https://tools.ietf.org/html/rfc8087 RFC8087 | + | * [https://tools.ietf.org/html/rfc8087 RFC8087] The Benefits of Using Explicit Congestion Notification (ECN) |
− | * [https://tools.ietf.org/html/rfc8311 RFC8311 | + | * [https://tools.ietf.org/html/rfc8311 RFC8311] Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation |
[[Category:393]] | [[Category:393]] |
Revision as of 10:14, 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 is the slowest one.
- 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