Re: [httpstreaming] Current Status and Our Goal

[Qin Wu <[e-mail]>]

No, we are talking about difference between pull model and push model and their advantage, disavantages.
The model specified in 3GPP is just client based pull model which gives client the whole control to handle playout.
Another model we need to look at is push model. The technolgoies related to this model  are server push technology, websocket protcol. 
The difference between them is:
pull model is client based solution, rely on existing web infrastructure including cache behavior, require nothing from network. 

push model network based solution, network should be enhanced to provide better transport and satisfy better QOE.

Also I would like to point out what 3GPP is doing for this pull model is just standardizing manifest component, which is similar
to Apple's draft-pantos-http-live-streaming-04 and specify how these component work in the pull model.

However in the push model, this component is not neccessary. 
Also in the push model, the cache may be enhanced as pointed out by Wenbo Zhu.

Regards!
-Qin
----- Original Message ----- 
From: "Ye-Kui Wang" <[e-mail]>
To: "'Ali C. Begen (abegen)'" <[e-mail]>; "'Qin Wu'" <[e-mail]>; "'Roni Even'" <[e-mail]>; "'David A. Bryan'" <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, October 15, 2010 3:32 PM
Subject: 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: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Ali C. 
>> Begen (abegen)
>> Sent: Friday, October 15, 2010 1:14 AM
>> To: Qin Wu; Roni Even; David A. Bryan
>> Cc: [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/httpstreaming
>> 
> 
>