Re: [httpstreaming] Current Status and Our Goal

[Qin Wu <[e-mail]>]

----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[e-mail]>
To: "Qin Wu" <[e-mail]>om>; "Roni Even" <[e-mail]>om>; "David A. Bryan" <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, October 15, 2010 1:14 PM
Subject: RE: [httpstreaming] Current Status and Our Goal


> But, in http streaming scenario, the ratio of download/upload (from the client's perspective) is much larger than 1. BTW, if
> you keep your chunk duration relatively longer, the amount of requests that you will end up sending will be almost nil
> compared to what you will receive.
> 
> [Qin]: No, I just compare pull and push with the same chunk duration.

You can choose whatever chunk size you wanna use. Does not matter. The fact remains the same. Unless someone uses chunks of a few hundreds of ms, it won't matter.

 [Qin]: Suppose 10 chunks is available at the server side, in the pull model, the client need to send at least 10 requests and receive 10 responses.
          in the push model, the client may only need to send one request and then receive 10 responses.
          comparing with pull, push model save 9 requests.
          also if you look at websocket, push has more lightweight header than pull.
          However as you said:
          "
          if  you keep your chunk duration relatively longer, the amount of requests that you will end up sending will be almost nil
         compared to what you will receive.
          "
          based on your understanding, suppose still 10chunks is avaible at the server side,  in the pull model, the client send 10 request to fetch them and 
          may receive thousands of response. Is it what you said here?
...
> Sorry if "playback time" meant the duration of the playback. I rather meant the start time of the playback. So, if a client
> keeps a larger buffer hoping that it will avoid buffer underruns, this may delay the playback start time.
> 
> [Qin]: Right. So we need to choose approporiate buffer size to seek balance between buffer underflow and startup time
> delay. The buffer size can be changed at any time.

It is not up to me or you. Any implementation (depending on the device, scenario, network type, etc.) can choose any size for the buffer.

[Qin]: I think it is one issue pertain to Buffer management. Since RTP can handle this smoothly, why not HTTP streaming?
 
> Or, the client can start the playback quickly and build the buffer over time by requesting lower-bitrate chunks.
> 
> [Qin]: I think the presumption is the server should prepare multiple streams of the same content with different bitrates. the
> server may have a big load if the content is live contents.

It is not the server who prepares the content. Not necessarily and not often. So, serving the same content at different bitrates does not pose any extra load on the server (except where the caching comes into play).

[Qin]: Yes, it does not matter whether streaming component is collocated with web server or separated.
 
> Whether it paces the presentation speed down or not in order to avoid buffer underruns is something up to the client. Most
> implementations I have seen simply switch to a lower-bitrate profile well before the buffer is fully drained. So, they don't
> experience buffer underruns and they don’t need to pace the video presentation speed down.
> 
> [Qin]: I don't doubt giving more control to client has its advantages. But I think giving some control to the server also has its
> advantage. e.g.,  you may not need to prepare multiple stream of the same content with different bitrate.

Well, AFAICT the method in which people (including me) are interested in is this so-called multi-bitrate streaming, which implies the same content being encoded at multiple bitrates.

[Qin]: I am interested too. But I suspect there are other ways to decrease such overhead. e.g., trancoding may be best choice for live content.

> the server control the transmission rate based on the network condition and client requirements.

How would this work if you have only one bitrate on the server? Is your approach as follows:

Rather than offering the same content encoded at multiple bitrates and serving them based on what the client wants, you wanna serve the content encoded at a single bitrate and by manipulating the transmission rate on the server (based on server's knowledge of network and client), you "adaptively" send it. Is that the scenario you have in mind?

[Qin]: Personally that is what I am trying to look for. a single birate for live content may change at time which can be realized by transcoding.

-acbegen