Re: [httpstreaming] Current Status and Our Goal

Kathy McEwen <kathy@iridescentnetworks.com> Wed, 06 October 2010 23:47 UTC

Return-Path: <kathy@iridescentnetworks.com>
X-Original-To: httpstreaming@core3.amsl.com
Delivered-To: httpstreaming@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4B793A7237 for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 16:47:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level:
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6A18O5hpyft for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 16:47:38 -0700 (PDT)
Received: from smtp107-mob.biz.mail.gq1.yahoo.com (smtp107-mob.biz.mail.gq1.yahoo.com [98.136.185.198]) by core3.amsl.com (Postfix) with SMTP id 301453A6EA0 for <httpstreaming@ietf.org>; Wed, 6 Oct 2010 16:47:38 -0700 (PDT)
Received: (qmail 91360 invoked from network); 6 Oct 2010 23:48:36 -0000
Received: from [10.77.158.135] (kathy@166.205.137.87 with xymcookie) by smtp107-mob.biz.mail.gq1.yahoo.com with SMTP; 06 Oct 2010 16:48:35 -0700 PDT
X-Yahoo-SMTP: 0oTc.aiswBATml9UvnuZnOzzTXTzZTa6NV7Bbr9Wm3OL
X-YMail-OSG: VpkhRg8VM1nmPOqOPMrb6p6AA4DoO3miBKZN6Lu5ziAL2nD oh5lY__lIHpJVPl1GAHteLGjdcxy2jFCBdaNy0.u92kkmvf9Cjss_oQQEVKn zXiVAjpoYP6bD3oTEtjYYOKEs1NX11WzYIapsE0jENzsymfxSRBrjVdWgV_. whL35tCGc.KxbBi9JFT6jxn8mammCrgKC4xsiiGMCjrqcD4humiHaAg4e4Ee 7.J6v14GUGFfkklONPHazWg8RtThG5QC7ggErEck69ljUNCbMo6Bqb1ERbnn yvbxceWVNHbAiqA5ZdauvHg--
X-Yahoo-Newman-Property: ymail-3
References: <04CAD96D4C5A3D48B1919248A8FE0D540B8AA1A4@xmb-sjc-215.amer.cisco.com>
Mime-Version: 1.0 (iPhone Mail 8B117)
In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540B8AA1A4@xmb-sjc-215.amer.cisco.com>
X-Apple-Yahoo-Original-Message-Folder: Inbox
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <C968BE22-93C9-4BB1-AB93-15AE1D861A8F@iridescentnetworks.com>
X-Mailer: iPhone Mail (8B117)
From: Kathy McEwen <kathy@iridescentnetworks.com>
X-Apple-Yahoo-Replied-Msgid: 1_331895_ALTHjkQAAXnYTK0HwgS9QHA3fYA
Date: Wed, 06 Oct 2010 16:47:58 -0700
To: "Ali C. Begen (abegen)" <abegen@cisco.com>
Cc: "<httpstreaming@ietf.org>" <httpstreaming@ietf.org>
Subject: Re: [httpstreaming] Current Status and Our Goal
X-BeenThere: httpstreaming@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming>
List-Post: <mailto:httpstreaming@ietf.org>
List-Help: <mailto:httpstreaming-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Oct 2010 23:47:39 -0000

There are ways to reduce and eliminate the delays to set up the multicast as well.  Adaptive streaming over the web does not preclude improvements to multicast efficiencies.  Rather, a co operative implementation of adaptive streaming and highly efficient multicasting is perhaps the needed secret sauce... To be made not so secret thru open industry standardization.

.../Kathy

Sent from my mobile

On Oct 6, 2010, at 4:35 PM, "Ali C. Begen (abegen)" <abegen@cisco.com> wrote:

> 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