- From: David Singer <singer@apple.com>
- Date: Tue, 4 Aug 2009 15:04:18 -0700
- 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 UTC