IETF Logo Mail Archive

Re: [httpstreaming] Current Status and Our Goal

"Ali C. Begen (abegen)" <abegen@cisco.com> Wed, 06 October 2010 22:39 UTC

Return-Path: <abegen@cisco.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 B51DF3A715B for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 15:39:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.553
X-Spam-Level:
X-Spam-Status: No, score=-10.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 1e5vI3tmpS93 for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 15:39:33 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 01C173A6D8A for <httpstreaming@ietf.org>; Wed, 6 Oct 2010 15:39:32 -0700 (PDT)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAJ+XrEyrRN+J/2dsb2JhbACiUXGpb5w3hUcEhFGIdw
X-IronPort-AV: E=Sophos;i="4.57,293,1283731200"; d="scan'208";a="283270028"
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 06 Oct 2010 22:40:33 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o96MeXTF028135; Wed, 6 Oct 2010 22:40:33 GMT
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Oct 2010 15:40:33 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 06 Oct 2010 15:40:08 -0700
Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [httpstreaming] Current Status and Our Goal
Thread-Index: ActgCGuD1NnF29rfRjaXK8fG462/2gFlt4PwAAEVLUAAACrh4AAAp4ug
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>
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: Roni Even <Even.roni@huawei.com>, "David A. Bryan" <dbryan@ethernot.org>, Qin Wu <sunseawq@huawei.com>
X-OriginalArrivalTime: 06 Oct 2010 22:40:33.0287 (UTC) FILETIME=[7C7F9170:01CB65A7]
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:39:34 -0000

> -----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

v2.23.0 | Report a Bug | By Email