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

<br></div><div><div>1. Standard Video Format</div></div><div>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.</div>

<div><br></div><div>2. Robust Video Streaming</div><div>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.</div>

<div><br></div><div>3. Content Protection</div><div>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.  </div>

<div><br></div><div>4. Encapsulation and Embedding</div><div>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.</div>

<div><br></div><div>5. Fullscreen</div><div>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:</div>

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

<div>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.  </div><div><br></div><div>6. Camera and Micrphone access</div>

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

<div><br></div><div>-John</div>