[Live-devel] Maximum interleaved RTP packet size

[Deanna Earley]

Ahh, thanks for that. For reference, I guess it's MAX_PACKET_SIZE in MultiFramedRTPSource.cpp, and all the file sinks by default?
I'm not sure why I didn't find that beforehand.
The firmware in this camera uses GStreamer which is one of the big changes they were shouting about.
I don't know what prior versions were, but it didn't identify itself.

--
Deanna Earley | Lead developer | icatchercctv

w: www.icode.co.uk/icatcher<http://www.icode.co.uk/icatcher> | t: 01329 835335 | f: 01329 835338
Registered Office : 71 The Hundred, Romsey, SO51 8BZ. Company Number : 03428325

From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: 15 April 2015 18:33
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Maximum interleaved RTP packet size

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

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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20150416/9b66e4eb/attachment.html>