So, anyone remember WebM? A reader emailed me about a pilot study (in English!) performed by a collaboration between the NPO (the Dutch version of the BBC, basically) and TNO (the largest research institution in The Netherlands, often employed by our government) into the viability of using WebM and associated tools instead of H.264 and associated tools, including the perceived quality of VP8. The outcome of the pilot shouldn’t surprise anyone – the toolchain needs work, WebM itself isn’t there yet, but the future looks bright.
I’m fascinated by the fact that the NPO and TNO are looking into this. Only a short while ago, people were dismissing WebM as a joke, something that would never work – and here we have the NPO, which has a collected market share in The Netherlands of about 35%, looking into the viability of using a WebM-based toolchain both for live-streaming content as well as for the organisation’s video-on-demand service, Uitzending Gemist (lit. “Missed Broadcast”). Both of these now use H264 through either Silverlight or Windows Media Player.
From the onset of reading the study – which is written in English, although clearly not revised by someone with native-level knowledge of English – I already knew viability at this point would be low. WebM isn’t as optimised as H264 just yet, but more importantly, the various tools needed to properly use WebM in an organisation as large as the NPO clearly haven’t been (fully) adapted to WebM either.
The pilot study is fairly detailed, and includes all decoder settings and links to sample videos used. The pilot study is part of a larger effort of our government to make use of open source and open standards-based software and tools as much as possible. The problem with the current H264-based implementation is that Silverlight and WMP are not readily and/or easily available on all platforms (the study lists Windows, Linux, Mac OS X, and mobile devices as targets). On top of that, the study cites that by using something like Silverlight, the NPO is dependent on just a single controlling entity.
I’ll spare the implementation details – the study is free after creating an account, so you can look it up yourself – but the conclusion are most interesting, of course. In order to avoid any discussions about me picking only the positive conclusions, I figured I’d just list them all below.
- At this moment, it is impossible without extra development investments to provide WebM-based video services using open source components that fit the operational requirements of a broadcaster, because of the following issues:
- With respect to encoding speed and maintaining target bit rates, the current
WebM encoder library performs clearly worse than its x264 counterpart.
- The encoding speed is too low for real-time WebM encoding, so live
streaming is not possible.
- FFmpeg does not support the required WebM formatting to enable livestreaming.
- FFmpeg is not able to down mix the multi-channel audio to stereo, which is
needed for the conversion of MXF files to WebM files. The broadcaster uses
programs with multi-channel audio, which are stored in the MXF file format.
- The quality of experience of WebM play out varies within the different
browsers that support WebM. Therefore the QoE requirements of the
broadcaster regarding startup delay and supported functionality are not
- Important video platform functionalities as DRM, audience measurement and
adaptive bit rate streaming are not available for playback of WebM in HTML5-
enabled web browsers. Given the design of HTML5, it is a question whether
DRM and audience measurement can be implemented with a comparable
security and reliability level as proprietary solutions currently offer.
- The fact that Google invests in WebM gives confidence with respect to the
required solutions for all the identified issues. So, WebM can be an alternative
for H.264 in the near future. These facts support this conclusion:
- The subjective panel test showed that the picture quality of WebM is close to
the picture quality of H.264.
- The reachability of WebM based on web browser market share has grown
from 30% in December 2010 to nearly 50% in June 2011 in the Netherlands.
- It is probable that other parties besides Google have patents on WebM. These
patents could obstruct the free and open usage of WebM. Google and MPEG
LA are trying to make this situation transparent.
The only conclusion I take issue with is the last one, about the patent situation. The study specifically cites the claims by the MPEG-LA that 12 companies have stepped forward with patents VP8 might be infringing (still not published, by the way, so zero evidence these alleged patents even exist in the first place). The problem with this is simple.
The patents for H264 are known. On2 has designed VP8 around it, and Google, too, has made sure no known existing patents are being infringed upon. This is why the MPEG-LA had to publicly ask patent holders to come forward – the patents in the existing MPEG-LA patent pools were useless. However, this illustrates something I, and many other with me, have been pointing out for ages now: these supposed unknown patents could affect H264 just as much as they could affect VP8. They are, you know, unknown. Not just to VP8… But also to H264.
All in all though, while the pilot study states WebM in its current state is not ready, the future looks bright. Version 0.9.5-286-g945dad2 of Google’s libvpx was used, but the study notes that the fast pace of development makes it a bit of a moving target at this point – future versions of the VP8 encoder, some of which have already been released, the study notes, have already addressed or are addressing the issues raised in this very pilot.
Give it a few more years (especially for the toolchain to adapt), and WebM is looking like a very viable option for the NPO. This makes me very, very happy.
I don’t know anything significant about Europe or the European market, but I am also pleasantly surprised anyone wanting to do live streaming would take a serious look at webm at this point.
I have to say that I mostly agree with their conclusions. The toolchain still needs work, but its getting there. I don’t know about the bit concerning DRM, audience measure, and adaptive bitrate though…
If someone wants to make a player that wraps webm in DRM with such features that’s their business, but it is not a quality of the codec itself and never will be (to me this is just a tangent on the toolchain issue) – it is also no longer HTML5. Put another way if you want HTML5 video you have to take it as it is so to speak, and while you may be able to graft audience measure and/or adaptive bitrate handling onto things on the backend somehow, DRM in the conventional sense is not possible. If you want DRM you are pretty much stuck with a dedicated player (and thus you are no longer talking about HTML5).
As for the last part…
Change “probable” to “possible” and I think the first sentence is a fair statement. The last sentence though, yikes… MPEG-LA are doing everything but trying to make things transparent. The end result of a protracted hunt-for-the-magic-patent game they are playing may well be more transparency, but that is certainly not what they are trying to do…