Re: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ...

<L.Wood@surrey.ac.uk> Fri, 22 May 2009 06:11 UTC

Return-Path: <L.Wood@surrey.ac.uk>
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89C0D3A6AA0 for <avt@core3.amsl.com>; Thu, 21 May 2009 23:11:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.335
X-Spam-Level:
X-Spam-Status: No, score=-6.335 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 lDHHq7AR55a6 for <avt@core3.amsl.com>; Thu, 21 May 2009 23:11:43 -0700 (PDT)
Received: from mail71.messagelabs.com (mail71.messagelabs.com [193.109.255.131]) by core3.amsl.com (Postfix) with SMTP id B4DE43A68AA for <avt@ietf.org>; Thu, 21 May 2009 23:11:41 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: L.Wood@surrey.ac.uk
X-Msg-Ref: server-7.tower-71.messagelabs.com!1242972779!57784317!1
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: [131.227.102.140]
Received: (qmail 17636 invoked from network); 22 May 2009 06:12:59 -0000
Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-7.tower-71.messagelabs.com with SMTP; 22 May 2009 06:12:59 -0000
Received: from EVS-EC1-NODE4.surrey.ac.uk ([131.227.102.145]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 May 2009 07:12:59 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9DAA4.5A43CAB2"
Date: Fri, 22 May 2009 07:12:58 +0100
Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE7B1032@EVS-EC1-NODE4.surrey.ac.uk>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ...
Thread-Index: AcnaXfKgAq96RYWITYyGIZOb97b6owARZt64
References: <302f570905211446j7317a6f8o3d1e6a0b405a3568@mail.gmail.com>
From: L.Wood@surrey.ac.uk
To: john.lazzaro@gmail.com, avt@ietf.org
X-OriginalArrivalTime: 22 May 2009 06:12:59.0330 (UTC) FILETIME=[5B04C220:01C9DAA4]
Subject: Re: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ...
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 May 2009 06:11:44 -0000

http://tools.ietf.org/id/draft-pantos-http-live-streaming-00.txt

There's a mismatch between the goal in the first sentence of
the introduction:

   This document describes a protocol for transmitting unbounded streams
   of multimedia data over HTTP [RFC2616].

and the focus of this draft on actually being limited to using
M3U files.

For unbounded streams where the length is not known a priori,
I was expecting to see heavy use of HTTP chunking.
That is not the problem that this draft is
trying to solve.

   Each media file URI MUST be preceded by an
   EXTINF tag.  Its format is:

   #EXTINF:<duration>,<title>

   "duration" is an integer that specifies the duration of the media
   file in seconds.  

So it's necessary to know how long a file is before specifying it.
The draft is not really dealing with an unbounded stream of data,
more bringing together separate known resources seamlessly. As John
says, that particular problem has been solved by AJAX.

cheers,

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.uk>



-----Original Message-----
From: avt-bounces@ietf.org on behalf of John Lazzaro
Sent: Thu 2009-05-21 22:46
To: avt@ietf.org
Subject: [AVT] Comments on draft-pantos-http-live-streaming-00.txt ...
 
Hi everyone,

Comments on draft-pantos-http-live-streaming-00.txt below.

What jumped out at me was that this is a late-1990s
approach to a problem ... but its almost 2010 ...

In my view, the I-D is trying to do for audio what the AJAX client code
for Google Maps does for image map tiles. Namely, pre-loading short
media files over HTTP, to drive a user interface that the user
perceives as continuous (and in the Google Maps case,
responsive to user input).

I haven't looked at HTML5 (yet), but I was under the impression
one goal of its audio/video features is to provide the
primitives to make it possible to implement the protocol
described in draft-pantos-http-live-streaming-00.txt using
AJAX techniques.  If the feature set isn't there yet in HTML5
to do that, I think the time spent working on this I-D is better
spent working within the HTML5 process to get the features that
are needed.  It seems to me that AJAX is a more natural way to
implement this sort of "concatenation of pre-downloaded 10-second
files" streaming.

If there is AVT consensus that draft-pantos-http-live-streaming-00.txt's
general approach is acceptable for a work-item, I'll do a second review
of potential technical issues with the protocol itself ...

-- 
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
john [dot] lazzaro [at] gmail [dot] com