> We have an open case with one of our RTSP source vendors where RTP streams > over interleaved TCP seem to be throttled resulting in dropped frames in > situations where the camera increases the frame size. > This does not happen with UDP unicast. > For reference, here's the video explaining the issue to the vendor: > https://dl.dropboxusercontent.com/u/2931731/Bugs/Axis/501898/20150325_101155.mp4 > > The vendor's response suggests it could be a TCP flow control issue
Another possibility is that the server (camera) is also using the “LIVE555 Streaming Media” software - but an old, buggy version that does not implement RTP packet writes to TCP sockets as an atomic action (either written entirely, or not written at all). In this case it’s possible that - under congestion (when the server’s OS socket buffer fills up), partially-written (i.e., corrupted) RTP packets might get transmitted. You should investigate this possibility. (Note that if the server manufacturer uses our libraries, then they are required under the LGPL to upgrade their product - upon request by their customers - to use the latest version of our libraries.) > Is there a specific upper limit to the packet size that liveMedia's > interleaved TCP implementation can handle? The ‘packet size’ field in the TCP framing header is 2-bytes long, so the theoretical maximum is 65535 bytes. However, currently in the code there’s a hardwired limit of 20000 bytes (the size of the buffer used by the RTP source (i.e., reception) implementation). > It’s the BlockSize header. > I didn’t think it was standard, but apparently: > https://tools.ietf.org/html/rfc2326#page-47 > <https://tools.ietf.org/html/rfc2326#page-47> Interesting. I wasn’t aware of this before. > It’s allowed on all requests (bar OPTIONS and TEARDOWN) Although it would seem to make sense only for “SETUP” and “PLAY”… > Maybe it could be pulled from RTSPClient::responseBufferSize automatically? No, that wouldn’t be right - even when streaming over TCP - because incoming RTP/RTCP packets aren’t delivered into the RTSPClient’s buffer. (That buffer’s used only for incoming RTSP responses (or perhaps requests).) I might, however, add a mechanism that will allow the client code to specify that it wants a specific incoming packet size, and then (if this option is set) include a “Blocksize:” header in its requests. Ross Finlayson Live Networks, Inc. http://www.live555.com/
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
