[Live-devel] Bandwith determination using Receiver Report.

[Saumya Chandra]

>
> 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?

Yeah, more like the data corresponding to the RR packet is not
available due to slow source and was written to RTPSink with some delay.

fread(fTo, 1, fMaxSize, fFid)

>
> 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.)

So, are you saying that fFid should be set to non-blocking? In case data
is not available it will result in EAGAIN error! Also, how would that
change information in the RR packets.

> 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.)

yes, that might be a problem. Assuming packet loss number can be ignored
and (RTPSink::OctetCount() returns total number of packets sent till now),
how can you estimate time in which it was actively sending packets.

Thanks,
Saumya.

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