Re: [httpstreaming] Push Vs Pull Re: Current Status and Our Goal

[Thomas Stockhammer <[e-mail]>]

>>>> 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. 
>>> 
>>> [Qin]; for the live content consuming with thousands of consumers viewing at the same time, in my opinion, it may be a successful propsotion.
>> 
>> [T] Adaptation for each of the thousands of users!?  [\T]
>> 
>> [Qin]: The scenario we are talking about is more and more people watching one popuar global event at the same time, e.g., world cup finals, US president election, Olympic games.
> 
> 
> [T] 
> Exactly! And therefore individual server side adaptation is worst ... 
> To maintain a 1-1 relationship between the client and the server breaks scalability. 
> Just offer a couple of bitrate choices and the millions of clients will pick the one that suits them. Clients are extremely intelligent and capable nowadays. 
> Network-initiated individual QoS control is not a subject in HTTP streaming. 
> [\T] 
> 
> [Qin]: It seems you talk about server based solution in your vision which I can't follow. In my understanding, client based solution more fit for recorded content consuming than live content consuming.
> The big problem of current existing client based solution can not well satisfy real time streaming requirements during live content consuming.


[T]
If I summarize your proposition from the above e-mails, this is what it says:
"[Qin:] 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. 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. This is a successful propsotion for the live content consuming with thousands of consumers viewing at the same time"

This is server-controlled: "... by manipulating the transmission rate on the server ..." And in my opinion this is no successful proposition.

The only problem in live that may exist is end-to-end latency. 
[\T]

---
Dr. Thomas Stockhammer (CEO) || [e-mail] || phone [phone] || cell [phone] || http://www.nomor-research.com
Nomor Research GmbH  -  Sitz der Gesellschaft: München - Registergericht: München, HRB 165856 – Umsatzsteuer-ID: DE238047637 - Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.