W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

Re: iPhone streaming Internet-Draft posted

From: David Singer <singer@apple.com>
Date: Tue, 4 Aug 2009 15:04:18 -0700
Message-Id: <p06240802c69e600c7cfe@[17.202.35.52]>
To: HTTP Working Group <ietf-http-wg@w3.org>
Cc: http-live-streaming-review <http-live-streaming-review@group.apple.com>

On Jul 30, 2009, at 12:26 AM, Mark Nottingham wrote:
>On 30/07/2009, at 1:27 AM, David Singer wrote:
>>>The analogy that comes immediately to mind is PDFs; the approach 
>>>you're taking is roughly equivalent to Adobe saying that PDF files 
>>>should be split into a URI-per-page and then putting an index file 
>>>on the site to link to each page.
>>
>>This approach doesn't work with CDNs, who don't support adding 
>>custom headers to HTTP responses and cannot cache a single 
>>infinitely-growing resource which is being supplied to them in real 
>>time (i.e. a live video stream).

>I assure you that they can and will find ways to address it if an 
>approach like this is implemented widely; caching proxies generally 
>already support range requests (and combining ranges) out of the 
>box. Have you engaged with any to discuss this with them?

We have. They were not receptive to supporting custom headers, much 
less rearchitecting to supply arbitrary ranges of an 
infinitely-growing resource out to the edge.

>>On top of that, the client would depend on a single connection to a 
>>single server for the life of the presentation, which prevents 
>>load-balancing and makes failover considerably more difficult.
>
>Nothing says that you have to make range requests on a single connection.
>
>>The playlist approach has a few other advantages. Using a playlist 
>>of segments gives the client enough information to switch between 
>>streams of different quality dynamically. It also allows the 
>>content provider to express a range of time in which a client may 
>>seek.
>
>It would be extremely simple to add this information elsewhere; 
>either in the format itself, or in headers.

Getting something like this "implemented widely" enough to drive all 
these changes is a chicken-and-egg problem that we are not out to 
solve. We've had enough trouble getting people to support 
content-range requests for progressive downloads, and that's been in 
the standard for years.

>>>2) Apple has disclosed IPR 
>>><https://datatracker.ietf.org/ipr/1142/> for this draft.
>>>
>>>My layman's reading is that anyone who wants to host a stream 
>>>using this technique requires a written license from you, 
>>>including the possibility of paying a fee, once your patents are 
>>>granted.
>>>
>>>Is there anything else we should know about this? As it is, (and 
>>>only speaking as an implementer), this just gives me more 
>>>motivation to use other techniques.
>>
>>I'm not qualified to speak to the legal implications of the IPR 
>>disclosure. Note that we offered the QuickTime file format to ISO 
>>(for MPEG-4) under the same terms.  Send me direct email and I'll 
>>try to work with you to clarify this status.
>
>Thanks, but I think it'd be better if Apple made a public statement 
>about it, otherwise people will have the same concerns.

Yes, we'll keep you updated on our public statements.


-- 
David Singer
Multimedia Standards, Apple Inc.
Received on Tuesday, 4 August 2009 22:05:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:08 GMT