[Live-devel] RTSPServer - RTSPClient latency

[Simon Schampijer]

On Thu, 2004-07-22 at 20:45, Ross Finlayson wrote:

Thanks for the help :)
Sorry for the delay - we did a lot of tests the last days. 
And also changed our structure from a unicast demand structure
(RtspServer,RtspClient) to a Rtp,Rtcp Multicast structure.

> >Running the RTSPClient and RTSPServer on one machine adds latency
> >of ~200ms. Our application needs realtime performance.
> >Should we change the Recordering Threshhold time
> 
> No - that parameter has an effect only when arriving network packets are 
> out of order.  Normally, that doesn't happen.
Ok.
> 
> >  or the
> >socketInputBufferSize in the RTSPClient?
> 
> No - that parameter affects the size of the OS's input socket buffer, but 
> shouldn't affect its latency (if it's empty).
Ok.
> >What is the buffering strategy used by live.com library - is there an
> >extra packet buffering in reception or emission and where could we find
> >them.
> 
> No, there's no 'extra' buffering anywhere.
Ok - After some tests (calculating the time between putting data into
RTP packets (doGetNextFrame()) and sending them (sendto) is in the range
of useconds) -> So we think the dalay isn't introduced by live.com. 
> 
> One thing you should ensure, however, is that you're setting 
> "fDurationInMicroseconds" correctly in your "JackSource::doGetNextFrame()" 
> implementation.  That variable tells the RTP transmitting code how long to 
> delay - after sending a packet - before asking for more data.  If you are 
> reading from a 'live' input source - 
Yes we got a life input source -> so we did the following :
After making a RTP packet we watch in the ringbuffer between
Jack and Live.com if there is enough data to fill another RTP
Packet - if this is the case we set the fDurationInMicroseconds to 0. 
Otherwise we calculate the fDurationInMicroseconds.(like shown in
live.com)

Best Regards
Simon Schampijer