Thank you for the new version Ross. Can I confirm that this shouldn't interact with the file sink buffer sizes as they effectively receive decoded and depacketised frames? // "bufferSize" should be at least as large as the largest expected // input frame.
They have a default value of 20,000, and playCommon passes 100,000 (unless told otherwise) Kind regards -- 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-boun...@ns.live555.com] On Behalf Of Ross Finlayson Sent: 15 April 2015 22:26 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Maximum interleaved RTP packet size 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. FYI, I've just released a new version (2015.04.15) of the "LIVE555 Streaming Media" code that adds a variable u_int16_t RTSPClient::desiredMaxIncomingPacketSize; If - after creating your "RTSPClient" object - you set this field to some value >0, then a corresponding "Blocksize:" header will be included with each outgoing "SETUP" request. (I didn't added to "PLAY", because that would have complicated the code unnecessarily.) I hope this works for you. 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
