Subject: Re: iPhone streaming Internet-Draft posted

From: David Singer <[email-masked]>
Date: Tue, 4 Aug 2009 15:04:18 -0700

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.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 5 Aug 2009 09:27:18 -0700

On 04/08/2009, at 3:04 PM, David Singer wrote:

[ on CDNs]

> less rearchitecting to supply arbitrary ranges of an infinitely- 
> growing resource out to the edge.

That makes sense; I had been thinking more about the recorded  
broadcast use case, not live. Although in practice most streams won't  
be really infinite (and indeed archiving may be useful in *some*  
cases), it is a limitation for ranges.

In theory, one could define a new, time-based range unit to address  
this, but I can understand why you'd be reluctant to do so, as it  
would take non-trivial work on the server.

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

True. However, you've go a big iPhone-shaped hammer; I'd encourage you  
to use it -- if not here, perhaps elsewhere -- to push the limits a bit.

[ On IPR]

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

Thanks.

--
Mark Nottingham     http://www.mnot.net/