Re: Client Side Rate Control Revisited
"Mahmoud Hammoud" <[email protected]>
| Newsgroups | gmane.comp.multimedia.helix.devel,gmane.spam.detected |
|---|---|
| Message-ID | <[email protected]> |
Thanks Greg. And does it matter where I issue this SDB request? That is, right now I am doing this in rtspclnt.cpp as part of UpdateStatistics() where (for testing purposes) I am just checking if the bandwidth goes below a certain threshold and then calling SetDeliveryBandwidth(). I am asking this because I observed that the calls to SetDeliveryBandwidth() are mostly done in hxsm.cpp i.e. in a context more closely related to the actual media source(s) than rtspclnt.cpp. Is this relevant to worry about? Thanks again! Mahmoud On Wed, Aug 13, 2008 at 6:20 PM, Greg Wright <[email protected]> wrote: > Mahmoud Hammoud wrote: > >> Greg, All, >> I'm working on the client side rate control problem based on a prediction >> of bad/no connection; as was earlier suggested, I managed to use >> RTSPClientProtocol::SetDeliveryBandwidth in order to tell the server to send >> at a desired (faster) bit rate on demand. My question is the following: >> In the code I read something about "thin streaming", and namely that the >> highest value that the pipe can support would be the aggregate bandwidth of >> the sources. And indeed, after leaving fast start, the client tells the >> server to send at the aggregate bandwidth of the sources (also using >> SetDeliveryBandwidth), which implies that we are streaming "thin" and that >> any subsequent SetDeliveryBandwidth requests would be useless because the >> server will never send faster than the aggregate rate. Is this correct? How >> do I disable thin streaming, so that the highest supported bit rate is the >> actual bandwidth of the connection? What factor in general decides that we >> stream thin or not? >> > > the server should always honor the SDB message unless server side > rate control is in use. That is how I understand it anyway. > > --greg. > > Thanks a lot, >> Mahmoud >> > > _______________________________________________ Helix-client-dev mailing list [email protected] http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev