RE: Client Side Rate Control

See inline for answers...

 

  _____  

From: Mahmoud Hammoud [mailto:[email protected]] 
Sent: Monday, August 04, 2008 9:53 PM
To: Jyotsana Rathore
Cc: [email protected]; Greg Wright
Subject: Re: [Helix-client-dev] Client Side Rate Control

 

Forgot to CC there, my bad. Will you provide me with some answers?

Thanks,

Mahmoud

On Mon, Aug 4, 2008 at 8:14 PM, Jyotsana Rathore <[email protected]> wrote:

Forwarding to helix-client-dev

Please always keep the mailing list in loop.

 

  _____  

From: Mahmoud Hammoud [mailto:[email protected]] 
Sent: Monday, August 04, 2008 2:07 AM
To: Jyotsana Rathore
Subject: Re: [Helix-client-dev] Client Side Rate Control

 

Hi Jyotsana!

 Thanks a lot for your help, that was very valuable to me. 

 Great!

I'm still in need for some further support, so I hope these are not too many
questions for you:

Could you please point me to the part of the code where this "multirate"
delivery is implemented? That is, how does the client inform the server to
switch to a higher/lower bit-rate version of the clip and also, where (in
the code) does the corresponding switch take place at the server? 

 [Jyotsana] Did you look at the RTSPClientProtocol::SetDeliveryBandwidth ()
method in protocol/rtsp/rtspclnt.cpp? Here the rtsp SET_PARAM request is
sent to the server which contains the subscribe & unsubscribe info when the
sure stream switch is decided by the client. 

 As far as the corresponding code for the server, I am not sure. You can
email to server dev-list to get more information. But theoretically, server
maintains a model of the client buffer and uses client feedback reports to
sync this model to the actual client state. If the buffer is below the low
watermark, a downshift will be triggered. So if there is a lower rate
available, it will be shifted to. If the buffer is above the high watermark,
an upshift will be triggered if there is a higher rate available which falls
within the available bandwidth estimate.

Moreover, what is the difference between 3GPP and Helix adaptation? Do these
relate to server or client side rate control? Which preferences should be
set / not set in order to have client side rate adaptation enabled? 

[Jyotsana]  Both of them are server side rate adaptation mechanisms. You can
add the preference ServerSideRateControl=0 this will disable the server side
rate control which will in turn disable both helix adaptation and 3gpp
adaptation. Regarding the difference between the two, the basic ones are
that if you are using RDT transport protocol, helix adaptation (Real
Networks proprietary) will be used and if you are using RTP then 3gpp
adaptation (standardized by 3GPP) will be used. Both use RTSP as control
protocol. Helix adaptaion can be used with both .rm and .3gp formats unlike
3gpp adaptation (only .3gp)

I also posted some questions related to packet reception by the client
sockets, but I'm afraid I wont get a reply from someone anytime soon, so
maybe you can meanwhile provide me with your insight on the matter; here's
my original post:

[Jyotsana]  I'll let others on the list answer these questions for which you
have sent out another email.

1) In HXThreadedSocket::HandleRead( ), which subsequently calls
ReadFrom(&pBuf, &pAddr) in the case of UDP Transport, are the packets being
read from some sort of buffer that holds the "inbound" packets? Here I'm
making reference to the m_inbound.RemoveHead(...) statement; if so, where
does this buffering of packets in this m_inbound structure take place? Are
the packets being somehow buffered in a structure as they get received from
the network interface and then read/played by the client?

 

2) I'm finding this a little confusing: on one hand, the UDP sockets for the
different streams involved in a media session are created with
RTSPClientProtocol::InitSockets( ) (which in turn also calls
CreateUDPSockets(..)) and on the other hand the actual reading/reception of
the packets from the network interface seems to take place in
HXThreadedSocket where the code looks relatively "low-level". Could you
please give me some hints on how these 2 different modules relate to one
another? Just a small summary about how the packets are received and the
"event-driven" playout that then takes place would do..

 

Best Regards,

 

Mahmoud

On Sat, Aug 2, 2008 at 2:21 AM, Jyotsana Rathore <[email protected]> wrote:

Hi Mahmoud,

 

I can try to address some of your questions.

How do the bit-rate at the server, the bit-rate at the client, and the
available connection bandwidth related to one another? I would really
appreciate a short summary on this interaction between server and client
when a rate control procedure is in question

 

Let's assume that you are streaming a 128kbps media file and the bandwidth
available is more than 128kbps. Then because of higher available bandwidth
the server can potentially send data faster than the media rate. This is
what the server does when server-side rate control is enabled. And client
provides feedback, it notifies the server when its buffer is full (in case
of 3gp adaptation FBS=0 is sent in NADU RR report). On receipt of which the
server will slow down i.e. it will basically send data at media rate.

One other aspect of server-side rate adaptation is that if the file is a
multirate (or SureStream) file then the server can switch to a higher bit
rate stream or lower bit rate stream based on its upshift or downshift
watermarks. You can read more about server rate control here:
https://protocol.helixcommunity.org/2006/devdocs/sod-rtsp-adaptation-signali
ng-02.txt

 

But I think you are targeting client side rate adaptation as Greg suggested
previously (because the client will be provided info about the upcoming bad
connection). The client uses SetDeliveryBandwidth to change the speed at
which server sends data depending on the amount of data the client has. You
can look at protocol/rtsp/rtspclnt.cpp

 

Thanks,

Jyotsana

  _____  

From: [email protected]
[mailto:[email protected]] On Behalf Of Mahmoud
Hammoud
Sent: Friday, August 01, 2008 6:53 AM
To: [email protected]
Cc: [email protected]
Subject: [Helix-client-dev] Client Side Rate Control

 

Hi Milko,

 

I've already started this discussion with Greg. I'm hoping you'd be able to
give me some more feedback (I would really appreciate it if you could point
me to specific parts of the code not just the underlying implementation
concepts). Long story short, suppose I have some way to predict bad
connection quality (or even no connection) ahead of time, and I would like
to use this prediction to force the client to buffer data for a certain
amount of time (so as to play from the buffered content once we are in the
undesirable network condition). I got pretty familiar with how rebuffering
is handed by the client so far, but I think Greg suggested that merely
pausing playback and rebuffering would not really do the job because the
server would be sending at the same rate (could you please give me your
opinion on that?) As such, he proposed that I use client side rate control
and ask the server to send at a higher bit-rate (which module is responsible
for issuing such a request?). Here are my main questions to you: what would
happen next? How is the bit-rate used by the client to read the media
content affected? How do the bit-rate at the server, the bit-rate at the
client, and the available connection bandwidth related to one another? I
would really appreciate a short summary on this interaction between server
and client when a rate control procedure is in question.

 

Thank you a lot for your time,

 

Mahmoud Hammoud

_______________________________________________
Helix-client-dev mailing list
[email protected]
http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev