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 8:58 PM
> 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: Friday, October 15, 2010 6:49 AM
> Subject: RE: [httpstreaming] Current Status and Our Goal
> 
> 
> 
> 
> > -----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.
> 
> [Qin]: Okay. But If you look at websocket protocol as push model, probably you will find they can be used accelerate browser
> and improve efficiency.

But, in http streaming scenario, the ratio of download/upload (from the client's perspective) is much larger than 1. BTW, if you keep your chunk duration relatively longer, the amount of requests that you will end up sending will be almost nil compared to what you will receive.
 
> > > 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.
> 
> [Qin]: But How, is there any way to do this? or they just wait for rebuffering and then recover by itself.
>
> But, I will just repeat myself. Neither has anything to do with clock synchronization between the server and client.
> 
> [Qin]: Okay.
> 
> The client can choose the buffer duration and the actual playback time.
> 
> [Qin]: Suppose the chunks is not ready in the playout buffer at the client, does it mean that the client just slow down playback
> speed and wait for subsequent chunks is arriving at the playback buffer and then client resume the normal
> playback speed?

Sorry if "playback time" meant the duration of the playback. I rather meant the start time of the playback. So, if a client keeps a larger buffer hoping that it will avoid buffer underruns, this may delay the playback start time. Or, the client can start the playback quickly and build the buffer over time by requesting lower-bitrate chunks.

Whether it paces the presentation speed down or not in order to avoid buffer underruns is something up to the client. Most implementations I have seen simply switch to a lower-bitrate profile well before the buffer is fully drained. So, they don't experience buffer underruns and they don’t need to pace the video presentation speed down.

-acbegen