No, you’re misunderstanding the purpose of this software. It is intended for real-time streaming of media data - i.e., transmitting the media at its natural rate, regardless of the capacity of the underlying network. It uses RTP (which stands for “Real-time Transport Protocol”) - a datagram-based protocol. This means that data packets can get lost, and necessarily *will* get lost if the media’s natural data rate exceeds the capacity of the network.
If, however, you want to transfer media with guaranteed no data loss - regardless of the capacity of the underlying network - then you should use some other protocol, e.g., HTTP (which runs over TCP or QUIC - protocols that guarantee reliable data delivery). While it is true that the RTSP protocol contains a mechanism for the optional encapsulation of RTP media packets inside the RTSP (TCP) control stream, this is something that should be used *only if* you know that you have a firewall - between the sender and receiver - that blocks UDP packets. Otherwise, you should use the (much more efficient) regular RTP-over-UDP. In particular: > As currently implemented, should send() of the 4-byte framingHeader return > -EAGAIN, a gap in RTP sequence occurs, with dropped media data. Yes, this is exactly as intended (see above). It will not be changed. > I assume the implementation as-is was designed to prioritize realtimeness > over completeness. The software doesn’t ‘prioritize’ realtimeness; it *delivers* realtimeness. It’s not intended to guarantee ‘completeness’ at all. > 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 If you are exceeding the capacity of your network, then this doesn’t necessarily manifest itself as a full queue at the sender end. The congestion might be occurring downstream on the network (or perhaps at the receiver) Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
