Re: [httpstreaming] Current Status and Our Goal

Marshall Eubanks <tme@americafree.tv> Wed, 06 October 2010 22:49 UTC

Return-Path: <tme@americafree.tv>
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 69D663A7206 for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 15:49:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.516
X-Spam-Level:
X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 DNSjvk1Oyq9v for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 15:49:31 -0700 (PDT)
Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 6B2B23A71FF for <httpstreaming@ietf.org>; Wed, 6 Oct 2010 15:49:31 -0700 (PDT)
Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 07EA68FA9612; Wed, 6 Oct 2010 18:50:32 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Marshall Eubanks <tme@americafree.tv>
In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com>
Date: Wed, 06 Oct 2010 18:50:31 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <B465C6C1-E24A-4555-90B0-FE86AF9647BC@americafree.tv>
References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>
X-Mailer: Apple Mail (2.1081)
Cc: 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 22:49:32 -0000

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
>