[whatwg] More YouTube response

[Ian Hickson]

This is a bulk reply to the feedback that resulted from the following blog 
post from YouTube's API team:

   http://apiblog.youtube.com/2010/06/flash-and-html5-tag.html


On Wed, 30 Jun 2010, Tab Atkins Jr. wrote:

> So, for a quick recap, their problems are:
> 
> 1. Standard video format
> 2. Robust video streaming
> 3. Content Protection
> 4. Encapsulation + embedding
> 5. Fullscreen video
> 6. Camera and Microphone access
> 
> The blog itself successfully covers the current responses to 1, 2, 5, 
> and 6.  #3 is a different story; it doesn't appear that anyone in this 
> space is working on that or intends to.  And I'm happy with that.  #4 is 
> kind of silly - flash embedding doesn't protect anyone's private data - 
> the plugin can do plenty of malicious stuff if it wants to. Spreading 
> videos by embedding <script> tags would be equally safe.  I think people 
> just don't realize that fact.  In any case, embedding videos via [iframe 
> should work fine]

Indeed. To reiterate for the record:

> 1. Standard video format

This is up to browser vendors; we have several options. The market will 
likely end up resolving this.

> 2. Robust video streaming

This is at the stage where we should get browser implementation 
experience.

> 3. Content Protection

Fingerprinting is already possible; DRM is mathematically impossible. See 
below for slightly more on this, but this was covered in depth in the 
threads so I won't add much.

> 4. Encapsulation + embedding

Should be possible with existing technologies (a number of people 
discussed this on these threads so I won't reiterate further here).

> 5. Fullscreen video

See recent threads; this will likely be solved in due course via CSSOM 
extensions.

> 6. Camera and Microphone access

This is in early stages, but see the <device> element for ideas here. It's 
currently stalled waiting for people to volunteer to work on protocol-side 
work.


On Wed, 30 Jun 2010, Marques Johansson 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 protection is silly because it is impossible to simultaneously 
prevent someone from accessing data, and allow someone to access it. It's 
_especially_ silly in an open standard implemented by open source 
software, since you can't even rely on the usual obfuscation technique. (I 
haven't responded to any other e-mails on these threads regarding DRM, 
since none got beyond this problem.)


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

Sure, that's already possible.


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

Why can't the server control this already?


On Wed, 30 Jun 2010, Marques Johansson wrote:
> 
> 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.

There is definitely room for more advanced protocols than just straight 
HTTP for media streaming. This is an area where we should start with 
browser experimentation.


On Thu, 1 Jul 2010, Kevin Carle wrote:
>
> One part of (2) [well, debatably part, but related to video streaming] 
> is the lack of visibility into stream behavior. I can't ask the video 
> element questions about dropped frames, bitrate, etc. This is incredibly 
> useful in Flash for getting streaming feedback, and means I really don't 
> know how well the HTML5 player is working for users. The best I can do 
> is waiting/stalled events which is nowhere near as granular.

Exposing this information is one of the features queued up for the next 
version (after we get the subtitles stuff sorted out).

You can see the current list of such feedback here:

   http://www.whatwg.org/issues/#video--new-features-awaiting-stable-implementations

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'