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