Re: [httpstreaming] Current Status and Our Goal

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

I guess what Qin had in mind is something called "dynamic mode" of HTTP
streaming, wherein there can be just one file containing all alternatives
(i.e. multiple bitrates, resolutions, frame rates, etc.), as what can be
stored in ISO base media file format, but the Media Presentation Description
(MPD, i.e. manifest) describes the content as if it was fragmented,
segmented and stored in multiple files/URLs. Upon receiving a request of a
segment, the server creates the segment on-the-fly. Thus, caches and clients
work as determined by the HTTP streaming spec (e.g. MPEG DASH or 3GPP AHS),
but the server needs enhanced capability (and thus the mode can also be
called server-enhancing mode). However, there seems no need to specify
anything (as a standard) to do this.

BR, YK

> -----Original Message-----
> From: httpstreaming-bounces@ietf.org 
> [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Ali C. 
> Begen (abegen)
> Sent: Friday, October 15, 2010 1:14 AM
> To: Qin Wu; Roni Even; David A. Bryan
> Cc: httpstreaming@ietf.org
> 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.
>  
> ...
> > 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
> _______________________________________________
> httpstreaming mailing list
> httpstreaming@ietf.org
> https://www.ietf.org/mailman/listinfo/httpstreaming
> 