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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.