[whatwg] More YouTube response

[Schalk Neethling]

Hi John,

 

Many good responses and I agree with most but, "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", I am not so sure. Is
one of the reasons for tags such as <video> not to move away from third
party plugin's and have this baked into the UA instead?

 

The general idea is good, I just believe implementing this via 3rd party
plugin's is not the best way forward.

 

Schalk Neethling

 

From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of John Harding
Sent: Friday, July 02, 2010 1:00 AM
To: whatwg at whatwg.org
Cc: Andy Berkheimer
Subject: [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/20100705/19e73402/attachment-0002.htm>