[Live-devel] Bandwith determination using Receiver Report.

[Ross Finlayson]

>I am using receiver report timestamps to estimate the bandwith utilization
>for my application. But the source from which the RTPSink is reading is
>slow, hence time difference in consecutive reports also includes waiting
>delay. Because of this idle time the reported bandwith is much
>less than what is actually used. Any suggestion to estimate the delay when
>RTPSink is waiting?

Saumya ,

I'm not sure I totally understand the problem.  Presumably you are using 
some combination of the RTCP RR's "fraction lost", "cumulative number of 
packets lost" and "extended highest sequence number received" fields to 
compute how much data the receiver has been receiving, and using the times 
that each successive RR was received to help compute the bandwidth.  The 
first set of information (the information that was in the RR) is going to 
be accurate, so are you worrying about the fact that the 'reception time' 
for each incoming RR packet might not be accurate - e.g., if the RR packet 
had been buffered in the OS for a while, due to your server's delay in 
reading from your blocking source?

If that's the case, then you may want to consider changing your data source 
class so that reads from it happen asynchrononously (i.e., in a 
non-blocking fashion), rather than synchronously.  (In particular, if you 
are using "ByteStreamFileSource"[*] for your data source, then you will 
need to use a different source class (that you would write) instead.)

Another possibility, of course, is not to use RTCP RR information at all, 
but instead to just use "RTCPSink::octetCount()" - the byte count of 
outgoing data that's maintained by the server application itself.  This is 
always accurate.  (However, this won't measure packet loss.)

         Ross Finlayson
         LIVE.COM
         <http://www.live.com/>

[*] At some point I will probably change the implementation of 
"ByteStreamFileSource" so that it reads from its source file 
asynchronously, rather than synchronously.  (This should help servers 
perform better when streaming to multiple, concurrent 
clients.)  Unfortunately, though, I won't be able to do that for the 
Windows implementation, because Windows - unlike Unix - doesn't let you 
call "select()" on file descriptors (only network sockets).