Re: [httpstreaming] Current Status and Our Goal

["Ali C. Begen (abegen)" <[e-mail]>]

> -----Original Message-----
> From: Qin Wu [mailto:[e-mail]]
> Sent: Monday, October 11, 2010 5:15 AM
> To: Ali C. Begen (abegen); Roni Even; David A. Bryan
> Cc: [e-mail]
> Subject: Re: [httpstreaming] Current Status and Our Goal
> 
> Hi,:
> ----- Original Message -----
> From: "Ali C. Begen (abegen)" <[e-mail]>
> To: "Qin Wu" <[e-mail]>; "Roni Even" <[e-mail]>; "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.

By polling I suppose you mean sending HTTP requests. Well, that is pretty much implied by using HTTP, which is a request-response protocol and this makes HTTP as stateless as possible. And IMO sending individual requests offer more advantages than disadvantages.

> 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.

Well the server can push the content (in a push model) but it still is dependent on the client implementation to determine what to do with that content. One implementation, if it wants, can start playing it 10 hours later for all we care. I still don't get what you are trying to do here.

-acbegen