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
fulfilled.- 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…
(sorry for pointing out the technicallities)
I thought WebM is actually a container derived from Matroska, not a codec.
The codecs are: VP8 and Vorbis
So I don’t expect anyone to wrap something around webm, but maybe extend it.
In theory a browser maker, like Microsoft, could make a DRM-encumbered H.264 streaming version of HTML5 and it would fit the spec just fine (when the spec for streaming is done, which currently isn’t even part of HTML5 yet).
DRM in the browser is possible, there is nothing in the spec which “prevents” a vendor from adding it to their browser.
WebM is essentially VP8/Vorbis in a matroska container – the term used to define all three in combination. It isn’t a video codec or an audio codec or a container format, it is the specific combination of all three.
You cannot “extend” webm itself. If you change the codecs or the container it is no longer webm… You could put VP8/Vorbis in a different container of course – that might even be useful for some things – but it is no longer webm anymore…
By “wrapping” I’m not talking about changing webm, I’m talking about using a transport protocol to implement DRM (and other features like adaptive bitrate), something like RTMP that Flash uses or Silverlight’s Smooth Stream…
Yes, it would “fit the spec” – but only in the sense that the spec as it is currently defined simply chooses to not address the issue at all.
What I mean by saying that you can’t do DRM over HTML5 is that there is currently no way to do so in a manner that would work across all browsers claiming to support the spec – because it isn’t part of the spec.
A DRM extension would be the equivalent of adding an additional codec, but worse because it would currently be by definition completely proprietary… I see absolutely no possibility of Microsoft, Google, Apple, and Mozilla getting on the same page in this regard anytime in the foreseeable future so it goes in my not gonna happen bucket.
Microsoft doing it unilaterally? Sure, that could happen – but it would not use webm. Google is the only one of the bunch that might be interested in such a thing AND would use webm – but I don’t see them going there.
I thought WebM was a name for the MKV + VP8 + Vorbis combination… >_<
It’s interesting how WebM and HTML5 point out *by design* that DRM is really an obsolete dinosaur idea which needs to go away.
Technologists and consumers don’t want DRM. But content owners have traditionally demanded the ability to DRM content. If WebM doesn’t support that capability, it ultimately doesn’t matter what technologists and consumers want. Content owners will stick with a different codec.
Let me put it a different way. From a codec point of view, the difference between VP8 and H.264 in regards to DRM is effectively zero – neither codec has any explicit support for DRM.
If you instead want to talk about containers… Again, the difference between say MP4 and MKV is also zero – neither format has built in support for DRM.
All of the existing forms of “real” DRM that I know of (Apple Fairplay, Microsoft’s PIFF format, Adobe RTMPE/S, etc. – not silly obfuscation schemes) primarily accomplish their goal by encrypting the data stream somehow. Fairplay just reuses an existing container (MP4) but it doesn’t actually modify the container format much – they just encrypt the stream data and add some metadata to the headers. Others like PIFF essentially define a new container format and wrap fragments of MP4 or another container inside of it.
My point is there is nothing about Webm that makes it any more or less difficult to apply DRM. Something like PIFF could be created to wrap it, and all things considered mkv is a much more flexible and capable container formant than mp4 so there is no reason to think that a 3rd party couldn’t modify it like Apple did with Fairplay (although unless Google backs it it would no longer be Webm, because of it’s unique status as a standard for both the container AND the codecs).
In short, the issue has nothing at all to do with webm – the road block is the video tag and how the spec defines it. Since the HTML5 spec does not define anything in regard to protocols or codecs, adding DRM is probably trivial. What is NOT trivial is getting the major browser makers to agree on a standard for doing this…
There are talks to get Microsoft PIFF established as a standard for use in DASH adaptive streaming (upcoming MPEG streaming standard loosely based in part on Apples’ HTTP live streaming), but as far as I know, like most MPEG standards, only Microsoft and Apple are involved with it out of the major browser vendors…
DASH is actually pretty good spec, and it _could_ probably support Webm with a little work – but since it is backed by Microsoft and Apple it very likely wont support it, and I have seen no mention of anything other than h.264 in what I have read. Plus Google dropped h.264, so Chrome support for DASH/PIFF will likely end up being a Microsoft plugin just like it is now. Same thing could happen for Firefox if need be.
Long story short, between Apple and Microsoft we could likely see a working DRM system for H.264/HTML5 video that works in most if not all of the major browsers – but I don’t think it would be officially supported by Google, Mozilla, or Opera…
But Webm? I highly doubt it. Unless Google themselves do it no one will bother with applying DRM to Webm. But it is not a technical issue, it is politics and practicality…
I wonder what the BBC will think.
Edited 2011-09-30 22:04 UTC
The same as everyone else which looks at WebM/HTML5: no browser currently supports streaming*, the tooling to produce WebM isn’t ready, no DRM in WebM for those that need it and so on.
Other than sites like YouTube that doesn’t need DRM for most of their content, browser makers, OEM of devices which has hardware acceleration for codecs and so on you should probably just look again in a few years from now.
* now don’t think Youtube and so on use streaming, it is just a file-download.
Could you explain that further? The HTML5/webm version of youtube starts just as quickly as the flash version so it doesn’t need to download the whole video. So what is the difference between downloading part of the video to watch or downloading part of the video to stream?
Well, YouTube, Vimeo just use standard HTTP, no special protocol.
It doesn’t even use HTTP-range-requests like for example the Adobe Reader. Where it requests parts of the file.
When you download a movie-file, the webserver is a little special. Instead of sending you the whole file as fast as it can like a normal webserver would, it sends the first part of the file fast and after that it sends rest of the file slowly. So bandwidth isn’t wasted, if you don’t watch the whole video.
Ohh, it does request parts ofcourse, if you skip ahead and that part wasn’t downloaded yet.
I wonder about / too bad the BBC didn’t try to push their Dirac…
…it has some curious* inner workings, open source, and BBC also tried for it to not be patent-encumbered
(*not the same as better, it’s worse than good H.264 in tests, in measures most interesting to end-users; it doesn’t seem to be so much about the codec – Xvid, a “previous gen” one, does comparably to or even better than some H.264 encoders – more about tuning; then “H.265” / HEVC is coming, seems to have fairly “classic” workings, and it ought to be still much better)
ahh refreshing happy news
Even on a 2Ghz P4 Northwood w/ 384Mb of ram running the VESA driver in Ubuntu 11.04.
Don’t have flash installed in FF7, using the Youtube HTML5 beta https://www.youtube.com/html5 and this search plugin by marinos35 to search specifically for just videos in WebM: http://mycroft.mozdev.org/search-engines.html?name=Youtube+WebM Selection still leaves a little to be desired since Google doesn’t seem to be able to hold u to their claim of encoding all new content in WebM.
I don’t get the worry over people copying the videos though, DRM never stopped anyone from pulling the .flv flash video files, and no amount of DRM short of a completely locked down to the hardware black box can prevent it from happening to WebM.
The difference is that with FLV, you needed some relatively advanced tricks to get the file, whereas with HTML5 it’s all a matter of viewing the source and searching for “<video”, which every user on Earth can do.
Basically, the media industry considers that a broken DRM system is not a problem as long as only geeks can exploit the breach.
Maybe Flash with WebM support would be what they look for.
Edited 2011-10-01 08:37 UTC
Advanced tricks like opening /tmp and pulling the randomly named .flv file out of it?
I know recently they finally moved it elsewhere, but there are plenty of ways to pull the files on any os, Firefox alone has at least 50 addons to pull video, there are also dozens of stand alone apps that will put the files on the desktop.
Either way they still have the video. If they didn’t want anyone to take it they should have never posted it and DMCA’d anyone that did in the endless legal Whack-A-Mole that makes the internet the great.
Even easier. Install FlashGot, begin playing video, right click, “flashgot media.” I’ve yanked TV episodes off of megavideo, etc. this way.
Got a point, I forgot about that /tmp trick
Used FF extensions to get the files myself, but it took me some time to find a good FLV player/converter, that didn’t randomly drop frames without keeping audio and video in sync.
The /tmp trick doesn’t work anymore in recent versions. The file gets deleted as soon as it starts downloading but flash keeps it opened and it stays on the disk even though not on the filesystem. Easily bypassed:
ps aux | grep flash
cd /proc/<pid>/fd
ls -lh
The temporary files with “(deleted)” at the end and filesizes listed show up. Then you can just:
mplayer <nr>
cp <nr> ~/Downloads
Edited 2011-10-03 07:51 UTC
Thanks for this. I had noticed the difference but hadn’t gotten around to finding the workaround yet.
I still can’t figure out why Flash cannot use dynamic memory allocation instead of leaving user-accessible files around the VFS. Guess that’s some kind of extreme “everything is a file” Unix philosophy.
The simplest, most straightforward to achieve compromise between having some caching, plus not letting the memory usage grow beyond what it already is, and code reuse between platforms?
I think you overestimate some things…
(and Flash with WebM probably wouldn’t make much difference to most)
I’ve been uploading WebM (and MP4 – damned broken Linux video editors and pipelines) to YouTube recently, and have my account set to be mostâ€friendly to webm (no ads, allow embed, etc). It appears Google always produces webms, but at the end of the queue of the other formats.
It would be nice if Google didnt reencode WebM files, it increases file size and reduces quality.
For some HD quality, WebM minecraft videos… see /user/aberbeta
Edited 2011-10-03 12:10 UTC
Don’t count on ceasing reencoding, such service probably values more the consistency and predictability it brings; no need to deal with crazy and/or pointless settings and bitrates from some users or software.
“Even on a 2Ghz P4 Northwood” still sounds slightly sad, though (even under VESA)
Browser-integrated decoding still leaves something to be desired, seems nowhere as optimised as, say, that of MPlayer (also when it’s embedded in a browser, to play web videos!)
Thom, I don’t know anything about Dutch patent law, but I thought that you didn’t have software patents over there. If that is correct, then why are patent claims against WebM (or indeed, H.264) an issue in the Netherlands?
Because if WebM does not get populair with builders of hardware and software around the world, how likely is it that people in the Netherlands will have the codec already pre-installed ? Or ‘supported in hardware’ ?
The excerpt of the study in the article says: “nearly 50% in June 2011 in the Netherlands.”
Sure.
How do you install the WebM codec on your iPad again ?
You get what you py for if you buy shitty iOS crap.
And yes, I am a life long Apple/Mac user going all the way to my IIe and II GS all the way up to running my OSx86 box because after years of begging Apple for something between a high end iMac and a MacPro they still haven’t delivered and I’m no longer waiting for them to fill this rather massive gap in their lineup.
That you don’t do so does not help this public broadcasting company, because others do.
Too often reviews, especially here are either too optimistically glowing, denying the real issues with web m currently, or one far too pessimistic dismissing the possibility that anything could ever be as good as h264.
This is still the most in-depth technically accurate article I’ve seen about VP8 so far: http://x264dev.multimedia.cx/archives/377 .
It’s over a year old now, but it explains why VP8 isn’t/wasn’t ready for primetime. The following excerpt summarizes the most gaping flaw:
“The spec consists largely of C code copy-pasted from the VP8 source code — up to and including TODOs, ‘optimizations’, and even C-specific hacks, such as workarounds for the undefined behavior of signed right shift on negative numbers. In many places it is simply outright opaque. Copy-pasted C code is not a spec.”
Surely the spec has been cleaned up, corrected, and in general beefed up to look more like an actual spec by now, has it not? If not, ouch!
The technical stuff from that post is still correct though, as the bitstream format has been frozen since the beginning.