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

[Wenbo Zhu <[e-mail]>]

On Mon, Oct 18, 2010 at 1:13 AM, Qin Wu <[e-mail]> wrote:
> ----- Original Message -----
> From: "Thomas Stockhammer" <[e-mail]>
> To: "Qin Wu" <[e-mail]>
> Cc: "Ali C. Begen (abegen)" <[e-mail]>om>; "Roni Even" <[e-mail]>om>; "David A. Bryan" <[e-mail]>rg>; <[e-mail]>
> Sent: Monday, October 18, 2010 3:58 PM
> Subject: Re: [httpstreaming] Push Vs Pull Re: Current Status and Our Goal
>
>
>>>> 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.

I'd suggest we focus on the unique challenges that HTTP brings, i.e.
as a transport protocol, such as it enforces strict client-server RPC
and has to live with intermediaries such as proxy. Discussions on
specific client, network, or server designs in the general context of
media streaming over Internet, IMO, are mostly irrelevant.

- Wenbo

>
> ---
> 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.
>
>
>
> _______________________________________________
> httpstreaming mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/httpstreaming
>