Re: [httpstreaming] Current Status and Our Goal

I was referring to latecy wrt real time. That is what Roni was talking about from what I can tell. 

As for the startup delay, nobody is saying the opposite. But tricks to make it faster are secret sauce to each implementation. And in unicast (as opposed to multicast), there more available tools at our disposal. 

-acbegen

----- Original Message -----
From: Marshall Eubanks <tme@americafree.tv>
To: Ali C. Begen (abegen)
Cc: Roni Even <Even.roni@huawei.com>; David A. Bryan <dbryan@ethernot.org>; Qin Wu <sunseawq@huawei.com>; httpstreaming@ietf.org <httpstreaming@ietf.org>
Sent: Wed Oct 06 15:50:31 2010
Subject: Re: [httpstreaming] Current Status and Our Goal

On Oct 6, 2010, at 6:40 PM, Ali C. Begen (abegen) wrote:

> 
> 
>> -----Original Message-----
>> From: Roni Even [mailto:Even.roni@huawei.com]
>> Sent: Thursday, October 07, 2010 6:26 AM
>> To: Ali C. Begen (abegen); 'David A. Bryan'; 'Qin Wu'
>> Cc: httpstreaming@ietf.org
>> Subject: RE: [httpstreaming] Current Status and Our Goal
>> 
>> Ali,
>> It is not the same as multicast but is still a problem for live streaming
>> when buffering is used on the server that  may delay the data and there is
> 
> Sure, http streaming or streaming over another protocol will always be delayed. The content generation, pushing it to the source servers and CDN and then getting them to the clients plus the playout buffers will add up a delay of 20-30 seconds compared to regular over-the-air broadcast. 
> 

Are you talking about start times, or latency behind real time ? If it takes you a minimum of 20 seconds to start your video, you might as well not
bother from a business standpoint, IMHO.

Even small differences in video start times are viewed as a powerful competitive advantage in this
business, and so there is going to be a strong push to shorten start times.

Regards
Marshall

> I don't think there is much we can do about this, especially in the IETF.
> 
>> 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.
> 
>> For pre-recorded video this may be due to distance between synchronization
>> points and the size of a chunk sent.
> 
> Those things are all implementation specific IMO, they are not protocol issues.
> 
> -acbegen
> 
>> Roni Even
>> 
>>> -----Original Message-----
>>> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]
>>> Sent: Thursday, October 07, 2010 12:15 AM
>>> To: Roni Even; David A. Bryan; Qin Wu
>>> Cc: httpstreaming@ietf.org
>>> Subject: RE: [httpstreaming] Current Status and Our Goal
>>> 
>>>> 2. Address the startup issue, we have worked in AVT on fast
>>> channel/content
>>>> change and I think this is relevant also in this case.
>>> 
>>> Are you assuming a multicast environment for http streaming? Ow, the
>>> startup issue is not an issue in unicast connections.
>>> 
>>> -acbegen
> 
> _______________________________________________
> httpstreaming mailing list
> httpstreaming@ietf.org
> https://www.ietf.org/mailman/listinfo/httpstreaming
> 