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-boun...@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@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
