Re: [httpstreaming] Current Status and Our Goal

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

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

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

-acbegen