Re: [httpstreaming] Current Status and Our Goal

["Ali C. Begen (abegen)" <[e-mail]>]

> -----Original Message-----
> From: Qin Wu [mailto:[e-mail]]
> Sent: Friday, October 15, 2010 3:14 AM
> To: Ali C. Begen (abegen); Roni Even; David A. Bryan
> Cc: [e-mail]
> Subject: Re: [httpstreaming] Current Status and Our Goal
> 
> ----- Original Message -----
> From: "Ali C. Begen (abegen)" <[e-mail]>
> To: "Qin Wu" <[e-mail]>; "Roni Even" <[e-mail]>; "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?

You missed my point. The size of the 10 request messages you sent in the example above is not much compared to the size of the 10 chunks you receive. And if the chunk duration gets larger, the difference will be even bigger.

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

Sorry I am not following. RTP does not deal with this. Maybe you are referring to RTSP streaming and then buffer duration is again something chosen by the client not the protocol.
 
> > 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.

If you are saying a server doing transcoding for adaptation scales better than an http server serving client requests for different chunks, then I think you should make your arguments clear enough in the problem statement draft and see whether others think. To me, it is a losing proposition. 

-acbegen