Dutch Public Broadcasting Company Investigates WebM Viability

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.


  1. 2011-09-30 8:42 pm
    • 2011-09-30 9:28 pm
      • 2011-09-30 10:22 pm
      • 2011-10-01 8:28 am
    • 2011-10-02 5:00 pm
      • 2011-10-03 4:10 pm
        • 2011-10-03 5:33 pm
  2. 2011-09-30 10:04 pm
    • 2011-10-01 8:35 am
      • 2011-10-01 7:28 pm
        • 2011-10-02 12:34 am
    • 2011-10-07 3:22 am
  3. 2011-09-30 10:56 pm
  4. 2011-10-01 6:06 am
    • 2011-10-01 8:31 am
      • 2011-10-01 2:03 pm
        • 2011-10-01 3:33 pm
        • 2011-10-02 7:39 pm
          • 2011-10-03 7:47 am
          • 2011-10-03 12:08 pm
          • 2011-10-03 4:54 pm
          • 2011-10-07 4:30 am
      • 2011-10-07 4:03 am
    • 2011-10-03 12:08 pm
      • 2011-10-07 4:25 am
    • 2011-10-07 4:36 am
  5. 2011-10-01 6:20 am
    • 2011-10-01 8:38 am
      • 2011-10-01 1:53 pm
        • 2011-10-01 1:54 pm
          • 2011-10-01 2:14 pm
          • 2011-10-01 2:36 pm
  6. 2011-10-01 7:00 pm
  7. 2011-10-03 3:06 pm
    • 2011-10-03 5:22 pm