From BBC to YouTube
It’s been suggested to me, on the back of my post yesterday on BBC and HTML5 video, that I go back and have a look at what YouTube said on the subject back in June.
The YouTube post isn’t nearly as incendiary as Erik Huggers’, but they do raise some points which are worth examining (especially in light of some recent news). The constraints upon YouTube are a little different to the BBC — YouTube has a large body of unchanging content which is growing over time, whereas iPlayer not only adds new content but also expires older content on a regular basis — this means that rolling out new codecs or containers is significantly more of a logistical challenge for YouTube than it is for the BBC with iPlayer.
Standard Video Format
This has been a bugbear since the earliest days of HTML5 video and will continue to be for a while yet. Even so, there’s a question: do you want to target everybody with a browser which understands the HTML5 video element, or is a significant subset good enough? Is serving H.264+AAC in MP4 containers for all of the existing videos which exist in this format and only looking at things like WebM for new content good enough, or does everything have to be the same?
[It’s worth noting that lots of videos on YouTube — those from commercial partners — aren’t available as MP4-over-HTTP at all, which is why iOS devices and the Apple TV (and presumably others) can’t play 4oD content on YouTube, for example.]
This is one big area where YouTube has it harder than most, simply because of the vast body of existing content which you would ideally go back and transcode.
One thing I didn’t cover in yesterday’s post related to this — and my comments regarding fallbacks and feature/codec detection are particularly relevant to this issue — is the announcement from the MPEG LA that AVC (that is, H.264) will remain royalty-free forever for “Internet video that is free to end-users”. I haven’t looked in detail at the announcement yet, where I suspect the devil lies, and I very much suspect that this won’t change Mozilla’s stance all that much. At the same time, I’m not convinced that Mozilla will continue to make life difficult for its users who do want to watch video in this format in perpetuity. I’d be surprised if some sort of plugin mechanism didn’t arise which allows for third-party codec support.
Robust video streaming
YouTube is correct here, and it’s something that was pointed out to me yesterday too — the HTML5 standard itself doesn’t include a decent streaming mechanism. On the other hand, though, Apple’s approach is a open specification (and has been since day one), and is one for which a range of tools exist. Another option is, of course, RTSP, which has been curiously neglected by browsers supporting HTML5 video (even desktop Safari, which defers to QuickTime — itself supporting RTSP — for playback doesn’t do RTSP in the context of HTML5 video).
There also needs to be an event model so that supporting JavaScript can have the same sort of control and introspection afforded to ActionScript, rather than necessarily relying on the UA to do it right (this could be especially useful in conjunction with WebSockets, of course).
Erik Huggers would have got a decidedly different reaction if his post had announced that the BBC was exploring (or even proposing) solutions in this area, rather than pitching vague criticisms. As an organisation, the BBC hasn’t been particularly active (and by that I mean “not at all”) in even describing its needs to those writing the specifications, let alone getting involved in ensuring that they’re properly met. Hopefully the newly-created role of Senior Technologist for Internet Standards will change that moving forward.
Google has a role here too, of course, as both a browser vendor and a content provider it’s in a position to see both sides of the coin.
Content Protection
I don’t know what I can say here which I haven’t said before (and most recently yesterday). There’s a fundamental incompatibility between “content protection” and any kind of open system.
Encapsulation + Embedding
Again, more of a concern for YouTube than for iPlayer, this one. There are ways around it. Many sites accomplish embedding by way of JavaScript lumps rather than the embed and object elements directly. Some specialised markup and content management systems do have specific “YouTube” tags or buttons which avoid the copying/pasting of markup (and keep users of the system from embedding arbitrary stuff), but I think this is a bit of a red herring — content management systems, forums and the like would catch up eventually; there’s no reason to prevent Flash streaming just because HTML5-based video is available, and in all honesty (speaking personally), I’d look get video on youtube.com working right first before getting hung on the embedding side of things — there’s nothing to say it all has to be tackled simultaneously.
Luke Blaney also points out that YouTube updated their embedding code a little while ago to use iframes (and so allowing for HTML5 video embedding).
Fullscreen Video
This is a fair point, especially in the context of overlaid content (such as subtitles or hypergraphics). I can think of a few ways that it could be sorted out sanely, though I haven’t looked deeply at the discussions which have been ongoing. Again, it’s worth stressing that Google (and the BBC, who would undoubtedly have similar issues) should be actively contributing in this area.
Camera and Microphone access
Well. Yes. This isn’t really an HTML5 video thing at all — this is a “why we still use Flash at all” justification, which isn’t really the same thing.
The key — with all of this — is pragmatism. Nobody sane wants content providers to serve just HTML5 video in anything but the longest term — instead, they want things to work, even where Flash is not available or performs badly. It doesn’t have to be a great stand-off.
