OSNews

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

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)

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

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.

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.