[whatwg] HTML 5 : The Youtube response

[Marques Johansson]

On Wed, Jun 30, 2010 at 2:43 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Wed, Jun 30, 2010 at 11:27 AM, Marques Johansson
> <marques at displague.com> wrote:
>> What is  the problem with #3?  My recent emails on this list concern #3.
>>
>> I know that anything that has been seen or heard can be recorded,
>> replayed, and redistributed by illegitimate parties but that doesn't
>> mean content protection is silly.  Content providers have a right to
>> determine who, how, and when their videos can be accessed.
>>
>> For pay-per-video services I would think a watermark + sue policy for
>> files distributed over HTML5/HTTP could handle content protection as
>> well as any flash based solution.
>
> Indeed, but that can be done without HTML helping in any way.

I agree.  I wasn't suggesting any HTML changes here.

>> For pay-per-minute or pay-per-byte services I believe the HTTP and/or
>> HTML5 specification needs some minor changes to allow the server to
>> dictate the amount of data the UA should attempt to fetch from an open
>> and standard file over an open and standard protocol.
>
> The server can throttle itself by itself.  Any restrictions in the
> markup can be trivially bypassed.

Markup changes can be bypassed, but the server can respond with a
402/403 or 416 if need be.

The problem with throttling alone (yes, the server would be throttling
as well) is that when a user seeks to some point in the video the UA
request will look like "Range: bytes 0-" or "Range: bytes 15000000-".
The server is then expected to keep this connection open (idling or
trickling data) while the user takes a break and plays 5 seconds or 5
minutes of video.

HTTP and HTML don't offer a way for the server to tell the UA to grab
a segment of no more than X bytes (or seconds) and come back later
short of dissecting the video into smaller file segments with unique
path or query URI segments and using a playlist or using MediaFragment
style hash segments and client-side scripting.

HTTP and HTML don't offer a way to force the UA to use Ranges at all.
This can be seen in the current batch of UAs.  They don't request
video files with "Range: 0-" and there is no predefined way for the
server to request that the UA do so.  What I ultimately want to see is
the client requesting every video with a Range containing a start byte
pos and an end byte pos (when required by the server) that does not
exceed some HTML or HTTP size given by the server.  A 416 can be
returned if the UA exceed this size but 416 is not permitted before
the UA starts using Ranges.

It seems easier to add attributes or child elements to the new/draft
HTML5 <video> element than to modify HTTP/1.1 (while maintaining
compatibility) or to create new specs (Apple's playlists,
MediaFragment).

>> The user  is being charged for access to the content in some granular
>> fashion so the ability to constrain fetches would allow these service
>> providers to make sure that first parties have paid for the content
>> they are receiving without sending them and charging them for more
>> content than they wish.
>
> HTML can't help with that without losing openness, which isn't worth
> the benefit.

How does this forfeit openness?  The video would be retrieved with
no-cache headers in limited segments according to some spec defined
HTML5 attribute or spec defined HTTP header. The alternative is a
proprietary or non-HTTP/HTML solution.