Difference between revisions of "RTSP over UDP"
From ElphelWiki
(Created page with "==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 on...") |
(→Notes) |
||
(8 intermediate revisions by the same user not shown) | |||
Line 8: | Line 8: | ||
* 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 is the slowest one. | ||
* 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 15: | Line 15: | ||
* dump UDP packets log on the camera (tcpdump if installed): | * dump UDP packets log on the camera (tcpdump if installed): | ||
tcpdump -i eth0 -n udp port <someport> -w packets.pcap | 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 | * live555 is used by vlc and mplayer while gstreamer is standalone | ||
As UDP has no congestion control there might be several workarounds: | As UDP has no congestion control there might be several workarounds: | ||
Line 21: | Line 23: | ||
* Patching live555 options: | * Patching live555 options: | ||
1. Stick close to [https://tools.ietf.org/html/rfc4585 RFC4585] and [https://tools.ietf.org/html/rfc6679 RFC6679], also checkout [https://tools.ietf.org/html/rfc8087 RFC8087] & [https://tools.ietf.org/html/rfc8311 RFC8311]? | 1. Stick close to [https://tools.ietf.org/html/rfc4585 RFC4585] and [https://tools.ietf.org/html/rfc6679 RFC6679], also checkout [https://tools.ietf.org/html/rfc8087 RFC8087] & [https://tools.ietf.org/html/rfc8311 RFC8311]? | ||
− | 2. | + | 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: | Implementing 2: | ||
<font size=2>'''RTCP.c:''' | <font size=2>'''RTCP.c:''' | ||
Line 41: | Line 43: | ||
'''// here fRTCPInstanceForMultiplexedRTCPPackets is just reused''' | '''// here fRTCPInstanceForMultiplexedRTCPPackets is just reused''' | ||
fRTCPInstanceForMultiplexedRTCPPackets->sendReport(); | fRTCPInstanceForMultiplexedRTCPPackets->sendReport(); | ||
− | + | } | |
− | + | }</font> | |
+ | * Patching gstreamer: | ||
+ | First, need to find how to make gstreamer send RR reports. Then proceed as with live555. | ||
==Other links== | ==Other links== | ||
+ | * [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/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/rfc8311 RFC8311]: Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation | ||
[[Category:393]] | [[Category:393]] |
Revision as of 10:17, 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