<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=WordSection1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hi John,<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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?<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The general idea is good, I just believe implementing this via 3<sup>rd</sup>
party plugin’s is not the best way forward.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Schalk Neethling<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
whatwg-bounces@lists.whatwg.org [mailto:whatwg-bounces@lists.whatwg.org] <b>On
Behalf Of </b>John Harding<br>
<b>Sent:</b> Friday, July 02, 2010 1:00 AM<br>
<b>To:</b> whatwg@whatwg.org<br>
<b>Cc:</b> Andy Berkheimer<br>
<b>Subject:</b> [whatwg] More YouTube response<o:p></o:p></span></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>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.<o:p></o:p></p>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<div>
<p class=MsoNormal>1. Standard Video Format<o:p></o:p></p>
</div>
</div>
<div>
<p class=MsoNormal>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.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>2. Robust Video Streaming<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>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 <i>extremely </i>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.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>3. Content Protection<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>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. <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>4. Encapsulation and Embedding<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>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.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>5. Fullscreen<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>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:<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>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.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>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. <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>6. Camera and Micrphone access<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>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.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>-John<o:p></o:p></p>
</div>
</div>
</body>
</html>