[whatwg] More YouTube response

Glad to see my post spurred some good discussion - I'll try to address topic
by topic below, but one of the great points made is that some of the
functionality YouTube needs from browsers probably doesn't belong in the
HTML5 spec (e.g. streaming, content protection).  I'm happy to take those
discussions elsewhere if this forum is inappropriate, but it seems like it
would likely be the same group of people, just on a different mailing list.

1. Standard Video Format
Yes, this has been debated a lot, and I generally agree that leaving it out
of the spec was the best way forward for the spec.  Shane Fagan pointed out
that Flash supports multiple different codecs, which is true, but every
version since Flash 7 has supported Sorenson Spark video and MP3 audio.  I
don't think anyone is suggesting that browsers shouldn't support multiple
codecs, but having a consistent baseline is important.  On the current path,
a content provider knows that by offering H.264 and WebM, they can reach all
HTML5-capable browsers.  This honestly is a reasonable state for YouTube
right now - we use H.264 in cases outside the <video> tag as well, but it
would be nice to converge on a single baseline format at some point in the
future.

2. Robust Video Streaming
Andy Berkheimer on our team has been putting some thought into this, so I'll
defer to him for more specific proposals.  For an app like YouTube, it
is *extremely
*useful to have fine-grained control over how the browser fetches media from
the server.  Whether the details belong in the HTML5 spec or not depends on
the preferred design - something similar to Flash 10.1's appendBytes()
mechanism would affect the <video> tag interface, for example, while a
transport protocol could be completely separate.

3. Content Protection
Some of the discussion here seems to have conflated application-controlled
video delivery with content protection, but in an ideal world, the two are
independent.  The basic requirements around content protection that we get
from content owners basically consist of encrypting the content and limiting
the decryption to a "verified" and authorized client - the realm of
traditional DRM.  Rather than ask browsers to get into the DRM business,
what I think would work best is having a means for 3rd party DRM providers
to supply browser plug-ins which implement the <video> tag for protected
content - not all that different than selecting a pluggable codec.

4. Encapsulation and Embedding
As several people pointed out (and which I tried to get at in my post), this
is really an ecosystem issue rather than a change needed in the spec or in
browsers.  I suspect it's going to take some time, but the flexibility of
embedding content via <iframe> will be a big step forward.

5. Fullscreen
Maciej actually covered YouTube's requirements pretty well.  I'd add that
it's not just controls that are important for us to maintain: we have a lot
of additional content that needs to display with and sometimes on top of the
video - our interactive annotations, captions, and ads most notably.
 Maciej's proposal also looks fairly reasonable, though some thoughts on it:
When limiting keyboard input, I'd suggest devices w/ onscreen keyboards
simply disable the keyboard.  Applications that work well with touch
interfaces generally provide gesture alternatives for the limited set of
keys that would be available.  Alternately, devices could limit the keyboard
to the set of allowed keys.
Keyboard restrictions are better than not having fullscreen support, though
they do limit functionality - it would prevent us from supporting search in
fullscreen mode, for example.

6. Camera and Micrphone access
As pointed out, this is not strictly an issue for <video> tag, though
certainly related especially for local preview.  I have not been closely
following the work on the <device> element, though that seems to be where
this is headed.

-John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100701/8153d8e5/attachment.htm>

Received on Thursday, 1 July 2010 15:59:37 UTC