[Live-devel] low latency transmit

[Yu, Bo]

Not sure how live555 task schedule works but usleep(0) will take some time and once the process give up the CPU and there is no guarantee when it will get back CPU.

Bo

From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Tuesday, April 23, 2013 10:09 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] low latency transmit

Can MultiFramedRTPSink::sendPacketIfNecessary() be enhanced safely with the following code ?

No, because it's not correct.  The whole point of the existing code is to delay the sending of the next packet, as appropriate, based on the value of "durationInMicroseconds" that was passed (to "afterGettingFrame()") by the upstream source object.  (Note the calculation of "fNextSendTIme" on lines 321-323.)


I would like to transmit all packets within one video frame as soon as possible instead of scheduling packet one by one ? uSecondsToGo gets 1 usec

Then the upstream source object must have set a non-zero value of "fDurationInMicroseconds" - which is probably not what you wanted.  (Note that if you're streaming from a live input source (as opposed to a file, for example) , then it's OK for it *not* to set "fDurationInMicroseconds", which means that it'll retain its default value of 0.



but cause the schedule to run and actually add a lot of latency between packets.

No.  If you happen to take longer than expected to get back to this code again, then it'll catch up.  That's why we call "gettimeofday()", and compare the result to "fNextSendTime".  If the current time happens to be later than "fNextSendTime", then "uSecondsToGo" will be 0, and scheduler will send the next packet ASAP.

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/20130424/3f81396b/attachment.html>