Re: [httpstreaming] Current Status and Our Goal

[Qin Wu <[e-mail]>]

Hi,:
----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[e-mail]>
To: "Qin Wu" <[e-mail]>om>; "Roni Even" <[e-mail]>om>; "David A. Bryan" <[e-mail]>
Cc: <[e-mail]>
Sent: Sunday, October 10, 2010 12:46 AM
Subject: RE: [httpstreaming] Current Status and Our Goal




> -----Original Message-----
> From: Qin Wu [mailto:[e-mail]]
> Sent: Friday, October 08, 2010 4:16 PM
> To: Ali C. Begen (abegen); Roni Even; David A. Bryan
> Cc: [e-mail]
> Subject: Re: [httpstreaming] Current Status and Our Goal
> 
> > also a need for video synchronization to start rendering.
> 
> Synchronization among the viewers you mean? That could be a concern but seriously, since client implementations will
> differ, network capacities will differ, i.e., pretty much everything will differ for different clients, I don't think there is a
> solution to this. Better said, I don't think there is a problem.
> 
> [Qin] I think Synchronization between the server and the client is one issue we may look at. Since the server has buffer for
> encoding, the client has a buffer for playout, we definitely need one streaming media synchronization mechanism which may
> help reduce delay.

Sorry, I don’t get this. Server or someone else advertises what is available to the client and client fetches whatever it wants (and is available). Why is there a need for synchronization here?

[Qin]: We may look at two different  use cases: push model and pull model
In the pull model, you are right. The client  control the timing of fetching the chunks by driving the HTTP request. It only request it needs and can handle. However  client based pull is characterized
as polling for new data each time and is not efficient way to deliver the real time streaming contents.
In the push model, the client does not know when the conents is available at the server. For the client will not send request for each chunks. the client clock is easy to asynchronize with encoder clock.