Re: [httpstreaming] Current Status and Our Goal

Sure but preparing that content for multicast does not happen right away. If you want adaptive streaming style delivery over the web, you will incur delays. And there is wrong with that. 

However, if you are saying they first prepare the content for web delivery and then push it to iptv or cable networks, the delay diff will be less between them, although relative delay wrt OTA will not change much. 

-acbegen

----- Original Message -----
From: Kathy McEwen <kathy@iridescentnetworks.com>
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:47:50 2010
Subject: Re: [httpstreaming] Current Status and Our Goal

Content does not have to be pushed from broadcaster to a source server and then to a CDN to make it out to users devices.  We are working directly with very large national broadcasters in north america and Europe who want to push multicast broadcast real time event content on to the web directly from their sites to users much like they do with content pushed to cable and satellite distribution networks. 

.../Kathy 

Sent from my mobile

On Oct 6, 2010, at 3:40 PM, "Ali C. Begen (abegen)" <abegen@cisco.com> 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. 
> 
> 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