Re: [httpstreaming] Current Status and Our Goal

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

> -----Original Message-----
> From: Qin Wu [mailto:[e-mail]]
> Sent: Thursday, October 14, 2010 2:21 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: Tuesday, October 12, 2010 8:09 AM
> Subject: RE: [httpstreaming] Current Status and Our Goal
> 
> > -----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.
> 
> [Qin]: Suppose ten chunks are available at the server, the client in pull model MUST send ten requests to fetch all the chunks
> and server should answer with ten response with each chunk.
> however in the push model, I think the client only need to initiate one request and then the server control ten chunks delivery
> and push ten chunks to the client one by one.
>  Isn't the push model more efficient than pull model from transport perspective?

Depends. Just because in the push model there are less request messages, it does not mean it is more efficient. That would be a bad definition for efficiency. The pull model brings many advantages that the push model cannot offer (at the same flexibility). I am not saying one is better than the other, but your scope for determining efficiency is rather limited.
 
> > 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.
> 
> [Qin]: In the push model, the server didn't know the client capability to consume streaming data, i.e., the server didn't know
> how fast the client process live streaming. If the encoding rate at the server is faster than comsuing rate at the client, the
> buffer will overflow. If the encoding rate at the server is slower than comsuing rate at the client, the buffer will underflow.

For both on-demand and live streaming, the encoding rate is supposed to be equal to consumption rate (which sounds to me as the rate the decoder is consuming). What you are referring to as buffer overflow or underflow is related to streaming or transmission rate. On the long-term average, all these need to be equal anyway. But, I will just repeat myself. Neither has anything to do with clock synchronization between the server and client. The client can choose the buffer duration and the actual playback time.

-acbegen