Re: 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. 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-signaling-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