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