patch: Set forceSendToSucceed for RTP over TCP framingHeader
Chris Hiszpanski
chris.hiszpanski at verkada.com
Fri Mar 7 16:37:30 PST 2025
Hello,
I would like to propose the following change:
diff --git a/liveMedia/RTPInterface.cpp b/liveMedia/RTPInterface.cpp
index 997615e..a97dbb0 100644
--- a/liveMedia/RTPInterface.cpp
+++ b/liveMedia/RTPInterface.cpp
@@ -357,7 +357,7 @@ Boolean RTPInterface::sendRTPorRTCPPacketOverTCP(u_int8_t* packet, unsigned pack
framingHeader[1] = streamChannelId;
framingHeader[2] = (u_int8_t) ((packetSize&0xFF00)>>8);
framingHeader[3] = (u_int8_t) (packetSize&0xFF);
- if (!sendDataOverTCP(socketNum, tlsState, framingHeader, 4, False)) break;
+ if (!sendDataOverTCP(socketNum, tlsState, framingHeader, 4, True)) break;
if (!sendDataOverTCP(socketNum, tlsState, packet, packetSize, True)) break;
#ifdef DEBUG_SEND
Essentially, when sending RTP over TCP, require that the framing header succeed.
As currently implemented, should send() of the 4-byte framingHeader return -EAGAIN, a gap in RTP sequence occurs, with dropped media data. I assume the implementation as-is was designed to prioritize realtimeness over completeness. However, I'd argue RTP over UDP already fulfills this role, and losing portions of the an H.26x IDR makes the media effectively unusable anyhow, particularly where with TCP "guaranteed delivery" is commonly expected.
More concerningly, I've observed that -EAGAIN errno is returned when sending the header, even though there appears to be adequate transmit capacity -- iproute2/ss shows an empty or near empty send-q, never exceeding 100KB when polled at 1Hz; /proc/sys/net/ipv4/tcp_mem and /proc/sys/net/ipv4/tcp_wmem are set to tens of MB of buffer capacity; live555 (sender) is only serving two instances of a H.264 3Mbps stream (96 frame IPPP GoP; IDR ~50x larger than P); iperf3 test between the sender/received (on same LAN) shows 80-90Mbps of throughput (100Mbps NIC).
Chris
More information about the live-devel
mailing list