Linked by Thom Holwerda on Fri 30th Sep 2011 20:19 UTC
Multimedia, AV 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.
Order by: Score:
Interesting
by galvanash on Fri 30th Sep 2011 20:42 UTC
galvanash
Member since:
2006-01-25

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

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.


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

Reply Score: 8

RE: Interesting
by Lennie on Fri 30th Sep 2011 21:28 UTC in reply to "Interesting"
Lennie Member since:
2007-09-22

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

Reply Score: 5

RE[2]: Interesting
by galvanash on Fri 30th Sep 2011 22:22 UTC in reply to "RE: Interesting"
galvanash Member since:
2006-01-25

I thought WebM is actually a container derived from Matroska, not a codec.


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.

So I don't expect anyone to wrap something around webm, but maybe extend it.


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

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)


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.

Reply Score: 6

RE[2]: Interesting
by Neolander on Sat 1st Oct 2011 08:28 UTC in reply to "RE: Interesting"
Neolander Member since:
2010-03-08

I thought WebM was a name for the MKV + VP8 + Vorbis combination... >_<

Reply Score: 1

RE: Interesting
by shmerl on Sun 2nd Oct 2011 17:00 UTC in reply to "Interesting"
shmerl Member since:
2010-06-08

It's interesting how WebM and HTML5 point out *by design* that DRM is really an obsolete dinosaur idea which needs to go away.

Reply Score: 2

RE[2]: Interesting
by tomcat on Mon 3rd Oct 2011 16:10 UTC in reply to "RE: Interesting"
tomcat Member since:
2006-01-06

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.

Reply Score: 3

RE[3]: Interesting
by galvanash on Mon 3rd Oct 2011 17:33 UTC in reply to "RE[2]: Interesting"
galvanash Member since:
2006-01-25

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

Reply Score: 2

BBC
by lucas_maximus on Fri 30th Sep 2011 22:04 UTC
lucas_maximus
Member since:
2009-08-18

I wonder what the BBC will think.

Edited 2011-09-30 22:04 UTC

Reply Score: 2

RE: BBC
by Lennie on Sat 1st Oct 2011 08:35 UTC in reply to "BBC"
Lennie Member since:
2007-09-22

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.

Reply Score: 3

RE[2]: BBC
by Fergy on Sat 1st Oct 2011 19:28 UTC in reply to "RE: BBC"
Fergy Member since:
2006-04-10

* 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?

Reply Score: 2

RE[3]: BBC
by Lennie on Sun 2nd Oct 2011 00:34 UTC in reply to "RE[2]: BBC"
Lennie Member since:
2007-09-22

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.

Reply Score: 2

RE: BBC
by zima on Fri 7th Oct 2011 03:22 UTC in reply to "BBC"
zima Member since:
2005-07-06

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)

Reply Score: 2

Comment by andih
by andih on Fri 30th Sep 2011 22:56 UTC
andih
Member since:
2010-03-27

ahh refreshing happy news ;)

Reply Score: 1

Already works good here
by Kivada on Sat 1st Oct 2011 06:06 UTC
Kivada
Member since:
2010-07-07

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.

Reply Score: 3

RE: Already works good here
by Neolander on Sat 1st Oct 2011 08:31 UTC in reply to "Already works good here"
Neolander Member since:
2010-03-08

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

Reply Score: 1

RE[2]: Already works good here
by Kivada on Sat 1st Oct 2011 14:03 UTC in reply to "RE: Already works good here"
Kivada Member since:
2010-07-07

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.


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.

Reply Score: 3

RE[3]: Already works good here
by tidux on Sat 1st Oct 2011 15:33 UTC in reply to "RE[2]: Already works good here"
tidux Member since:
2011-08-13

Even easier. Install FlashGot, begin playing video, right click, "flashgot media." I've yanked TV episodes off of megavideo, etc. this way.

Reply Score: 1

RE[3]: Already works good here
by Neolander on Sun 2nd Oct 2011 19:39 UTC in reply to "RE[2]: Already works good here"
Neolander Member since:
2010-03-08

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.

Reply Score: 1

RE[4]: Already works good here
by cheemosabe on Mon 3rd Oct 2011 07:47 UTC in reply to "RE[3]: Already works good here"
cheemosabe Member since:
2009-11-29

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

Reply Score: 2

RE[5]: Already works good here
by sorpigal on Mon 3rd Oct 2011 12:08 UTC in reply to "RE[4]: Already works good here"
sorpigal Member since:
2005-11-02

Thanks for this. I had noticed the difference but hadn't gotten around to finding the workaround yet.

Reply Score: 2

RE[5]: Already works good here
by Neolander on Mon 3rd Oct 2011 16:54 UTC in reply to "RE[4]: Already works good here"
Neolander Member since:
2010-03-08

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.

Reply Score: 1

RE[6]: Already works good here
by zima on Fri 7th Oct 2011 04:30 UTC in reply to "RE[5]: Already works good here"
zima Member since:
2005-07-06

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?

Reply Score: 2

RE[2]: Already works good here
by zima on Fri 7th Oct 2011 04:03 UTC in reply to "RE: Already works good here"
zima Member since:
2005-07-06

viewing the source and searching for "video", which every user on Earth can do

I think you overestimate some things...

(and Flash with WebM probably wouldn't make much difference to most)

Reply Score: 2

RE: Already works good here
by Beta on Mon 3rd Oct 2011 12:08 UTC in reply to "Already works good here"
Beta Member since:
2005-07-06

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’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

Reply Score: 2

RE[2]: Already works good here
by zima on Fri 7th Oct 2011 04:25 UTC in reply to "RE: Already works good here"
zima Member since:
2005-07-06

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.

Reply Score: 2

RE: Already works good here
by zima on Fri 7th Oct 2011 04:36 UTC in reply to "Already works good here"
zima Member since:
2005-07-06

"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!)

Reply Score: 2

software patents in the Netherlands?
by ozonehole on Sat 1st Oct 2011 06:20 UTC
ozonehole
Member since:
2006-01-07

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?

Reply Score: 3

Lennie Member since:
2007-09-22

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' ?

Reply Score: 2

anda_skoa Member since:
2005-07-07

how likely is it that people in the Netherlands will have the codec already pre-installed ?


The excerpt of the study in the article says: "nearly 50% in June 2011 in the Netherlands."

Reply Score: 2

Lennie Member since:
2007-09-22

Sure.

How do you install the WebM codec on your iPad again ?

Reply Score: 2

Kivada Member since:
2010-07-07

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.

Reply Score: 2

Lennie Member since:
2007-09-22

That you don't do so does not help this public broadcasting company, because others do.

Reply Score: 2

Bill Shooter of Bul
Member since:
2006-07-14

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.

Reply Score: 3

For an In-depth read on VP8
by boxy on Mon 3rd Oct 2011 15:06 UTC
boxy
Member since:
2011-06-20

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

Reply Score: 1

RE: For an In-depth read on VP8
by Gusar on Mon 3rd Oct 2011 17:22 UTC in reply to "For an In-depth read on VP8"
Gusar Member since:
2010-07-16

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.

Reply Score: 1