[Live-devel] Live555 limiting network traffic?

[Wiser, Tyson]

Ross,

Thank you very much for your response.  Removing MPEG2TransportStreamFramer from the chain seemed to do the trick.  Thanks for your great work.

Tyson

From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Saturday, December 10, 2011 5:49 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Live555 limiting network traffic?

Is there anything in BasicUDPSink (which is created by OnDemandServerMediaSubsession for raw UDP transfer), MPEG2TransportStreamFramer, or ByteStreamFileSource that could somehow be limiting the rate at which the UDP packets are sent under any circumstances?

Yes.  "BasicUDPSink" (and its RTP equivalent) delays after sending each packet, depending upon the "duration" (specifically, "fDurationInMicroseconds") parameter that has been set for the chunk of data that it has just received.  If, however, this duration parameter is zero (its default value), then "BasicUDPSink" - after sending out each packet - immediately asks for new data from its upstream object.

This "duration" parameter is important when you're streaming from a pre-recorded file, because otherwise the file data would be streamed as fast as possible, which is not what you want.  (When you're streaming from a file, you want to stream it out at its 'natural rate'.)  For Transport Stream data, the "MPEG2TransportStreamFramer" object is used to parse the Tranport Stream data to estimate the "duration" of each chunk of data that gets passed to the "BasicUDPSink" (or an equivalent RTP sink).

However, because you're streaming from a live input source, you don't need to compute this "duration" parameter.  Instead, you can just send out data as soon as it's generated  This means that you don't need a "MPEG2TransportStreamFramer"; you can therefore omit this in your implementation of the "createNewStreamSource()" virtual function (in your "OnDemandServerMediaSubsession" subclass).

Instead, you should set the (normally optional) "preferredFrameSize" parameter to "ByteStreamFileSource::createNew()", to ensure that you read properly-sized chunks of data (a multiple of the 188-byte Transport 'packet' size) each time.  (It's likely that your receivers care about this.)  I suggest setting this parameter to 7*188 (==1316), to ensure that your outgoing UDP packets (probably) won't get fragmented in the network.

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/20111213/e263cd01/attachment.html>