[Live-devel] Maximum interleaved RTP packet size

[Marcin]

Axis always used Gstreamer libs since its MPEG4 models. Later they 
integrated it in it's "monolith" streaming service inside camera.
Marcin

W dniu 2015-04-16 o 09:59, Deanna Earley pisze:
>
> 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 *| **icatcher**cctv*
>
> **
>
> 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/
>
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel

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