Client Side Rate Control Revisited
"Mahmoud Hammoud" <[email protected]>
| Newsgroups | gmane.comp.multimedia.helix.devel,gmane.spam.detected |
|---|---|
| Message-ID | <[email protected]> |
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? Thanks a lot, Mahmoud _______________________________________________ Helix-client-dev mailing list [email protected] http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev