RE: Client Side Rate Control

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

 

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? 

 

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:

 

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