Slashdot Mirror

W have perfectly reasonable alternatives to S3TC.

I thought S3TC used the same concept as Apple Video (RPZA), which shipped as part of QuickTime 1.0 in 1991. Each 4x4 pixel block has two 15- or 16-bit colors and an array of sixteen 2-bit coefficients as to how these colors are mixed to produce the sixteen pixels in the block. What's the inventive step from RPZA to S3TC?

There is no patent-unencumbered video codec worth using.

That might be technically true... Google owns the patents on VP8. But since they've offered an irrevocable perpetual royalty free license to the entire world, it's unencumbered for all reasonable, practical purposes.

When Google open-sourced their hopeless purchase, the extent of the scam became apparent.

VP3 was open-sourced over a decade ago, and no lawsuits ever came out of that. Are you suggesting On2 only RECENTLY started stealing MPEG patents? When exactly? And let's not forget that VP9 was not developed until years after Google acquired On2, and just recently released.

What did Google do? Simple- it used its insane cash reserves to strike behind-the-scenes deals with the patent owners, paying the for right to use those patents in non-disclosure agreements.

All of H.264's patents must be worth many billions of dollars over their lifetime. If Google had paid out anything like that, it would be obvious from stock prices, SEC filings, etc., etc. Instead, Google paid a piddly little amount to MPEG-LA, and it's they who wanted the NDA to save face. MPEG-LA argued for years that they owned patents that covered VP8, yet after years only came up with a very short-list, and still most of that was found laughably irrelevant. H.264 is covered by THOUSANDS of patents, by HUNDREDS of companies. The deal Google entered into only involved 11 of those hundreds of companies, yet that was enough to get MPEG-LA to declare full stop on any harassment of VP8.

The reality:
"This agreement is not an acknowledgment that the licensed techniques read on VP8. The purpose of this agreement is meant to provide further and stronger reassurance to implementors of VP8."

http://www.ietf.org/mail-archi...

In fact, the MPEG-LA's posturing was being investigated by the DoJ as anticompetitive behavior:

http://arstechnica.com/tech-po...

Google NEVER denied its video codec purchase was a rip-off (and a bad one at that) of H264.

Yes they did. They even did so in court, and they unequivocally WON:

http://blog.webmproject.org/20...

1) Google's fake free codec uses insanely more amounts of energy to decode and display video.

This is straightforward to disprove.
An x264 developer said of the first version of libvpx decoding:

"the current implementation appears to be about 16% slower than ffmpeg's H.264 decoder"

http://x264dev.multimedia.cx/a...

But since then, numerous performance improvements have been performed:

http://x264dev.multimedia.cx/a...

2) Google's fake free codec has the tiniest fraction of hardware support than is enjoyed by H264. Every modern device decodes H264 in efficient hardware

Actually, hardware acceleration isn't a big deal. The difference between VDPAU and software decoding of 1080 video on my PC is just a few percentage points. When my phone switches from hardware to software decoding (you can force this with "Mobo Player"), the performance and power difference is very small, and goes almost completely unnoticed. Hardware acceleration mattered a lot when mobile devices ran with 35MHz CPUs, but today, it makes a very tiny difference.

For the same quality, x264 video files are less than HALF the size of videos produced for Google's fake free codec.

Back in 2010 when comparing the just introduced an

There is no patent-unencumbered video codec worth using.

That might be technically true... Google owns the patents on VP8. But since they've offered an irrevocable perpetual royalty free license to the entire world, it's unencumbered for all reasonable, practical purposes.

When Google open-sourced their hopeless purchase, the extent of the scam became apparent.

VP3 was open-sourced over a decade ago, and no lawsuits ever came out of that. Are you suggesting On2 only RECENTLY started stealing MPEG patents? When exactly? And let's not forget that VP9 was not developed until years after Google acquired On2, and just recently released.

What did Google do? Simple- it used its insane cash reserves to strike behind-the-scenes deals with the patent owners, paying the for right to use those patents in non-disclosure agreements.

All of H.264's patents must be worth many billions of dollars over their lifetime. If Google had paid out anything like that, it would be obvious from stock prices, SEC filings, etc., etc. Instead, Google paid a piddly little amount to MPEG-LA, and it's they who wanted the NDA to save face. MPEG-LA argued for years that they owned patents that covered VP8, yet after years only came up with a very short-list, and still most of that was found laughably irrelevant. H.264 is covered by THOUSANDS of patents, by HUNDREDS of companies. The deal Google entered into only involved 11 of those hundreds of companies, yet that was enough to get MPEG-LA to declare full stop on any harassment of VP8.

The reality:
"This agreement is not an acknowledgment that the licensed techniques read on VP8. The purpose of this agreement is meant to provide further and stronger reassurance to implementors of VP8."

http://www.ietf.org/mail-archi...

In fact, the MPEG-LA's posturing was being investigated by the DoJ as anticompetitive behavior:

http://arstechnica.com/tech-po...

Google NEVER denied its video codec purchase was a rip-off (and a bad one at that) of H264.

Yes they did. They even did so in court, and they unequivocally WON:

http://blog.webmproject.org/20...

1) Google's fake free codec uses insanely more amounts of energy to decode and display video.

This is straightforward to disprove.
An x264 developer said of the first version of libvpx decoding:

"the current implementation appears to be about 16% slower than ffmpeg's H.264 decoder"

http://x264dev.multimedia.cx/a...

But since then, numerous performance improvements have been performed:

http://x264dev.multimedia.cx/a...

2) Google's fake free codec has the tiniest fraction of hardware support than is enjoyed by H264. Every modern device decodes H264 in efficient hardware

Actually, hardware acceleration isn't a big deal. The difference between VDPAU and software decoding of 1080 video on my PC is just a few percentage points. When my phone switches from hardware to software decoding (you can force this with "Mobo Player"), the performance and power difference is very small, and goes almost completely unnoticed. Hardware acceleration mattered a lot when mobile devices ran with 35MHz CPUs, but today, it makes a very tiny difference.

For the same quality, x264 video files are less than HALF the size of videos produced for Google's fake free codec.

Back in 2010 when comparing the just introduced an

They have decoding support, but at least as recently as Google Summer of Code 2013 they don't have hardware encoding support. That seems to be the fault of the ffmpeg project though, encoding was added to the VA API in June 2009. Lack of interest?

A member of the x264 team really doesn't like WebP because its quality isn't good enough.

Ogg Opus (open, royalty-free, not patent-encumbered audio) beats the pants off of HE-AAC (which, in turn, is superior to everything else at pretty much every level).

Wow! So much wrong in just a single sentence...

Opus is an IETF developed codec, based on CELT from Xiph.org, and Silk from Skype/Microsoft.

Ah, I thought Opus was under Xiph's Ogg umbrella. Xiph certainly hosts the new CELT+Silk project called Opus. Ogg is (afaict) the only container used by Opus (.opus is an Ogg file container). Noting those things, if you can refer to Vorbis as "Ogg Vorbis" then why can't you refer to Opus as "Ogg Opus?" I knew this was informal (though it is somewhat common) and did it mostly to concisely demonstrate its connections to Xiph (which most people know as "the ogg [vorbis] guys").

HE-AAC certainly isn't "superior" at "every level". It excels at very low bitrate encoding that sounds SOMEWHAT like the original. As you start increasing the bitrate (eg 96k), low-complexity AAC easily surpasses HE-AAC. And as you go to higher bitrates still (eg. 160k), temporal domain codecs can outperform any frequency-domain codecs, so Musepack will beat the pants of AAC, and even Opus.

You again caught me generalizing. Perhaps I was mistaken, but I thought AAC encoders capable of HE-AAC would automatically select which AAC codec to use based on the compression level and this is what I was referring to. I also should have said "roughly equal or better than" rather than "superior to" in that statement.

Regarding Musepack (MPC), that is an obscure format that was generally on par with Vorbis back in the day (but Vorbis has been improved a few times since then while Musepack has not). I'm gauging most of the surviving "next-gen mp3" codecs as largely equivalent at the 128+kbps level these days (though my personal preference, biased in part towards Freedom (and Linux compatibility), is for vorbis).

We don't seem to be getting quality listening tests for higher bitrates any more. Everybody is obsessed with super-low bitrate (so much so that they don't even try to find an mp3 baseline by which to state things are roughly equivalent to). I found a 64 kbps comparison which shows Opus narrowly beating Apple's HE-AAC for the lead. I'd love to see a thorough and up-to-date comparison of the major contenders at the 96, 128, and 160 kbps levels that also includes the lossless version as a baseline.

Still, low bitrate lossy audio quality is important, so Opus is a good choice for streaming audio and video. That's why Google chose it for their latest revision of WebM, along with their new VP9 codec that they claim outperforms HEVC.

That's odd, since WebM uses Matroska,which doesn't yet support Opus (though that's in the works). We'll see if Google can successfully make MPEG-LA obsolete. For that, we'd also have to compare VP9 to H.265 (Google noted VP9 was ~7% behind h.265 in Q4 2011) or perhaps wait for Daala or some Dirac-like wavelet codec to come out of left field (though wavelet compression has large hurdles, it is closer to how our eyes actually see).

I seriously doubt the MPEG / MPEG-LA organizations, and their members, will consider using a patent-free audio codec along with their heavily patent-encumbered video codec. Their business model is patents, and they'll chose an expensive and inferior option over a free one, any day. I'd expect HE-AACv2 to be the best you can count on for the foreseeable future.

Agreed. Hopefully that won't stop Xiph and Google from stealing the show.

VP8 was just poorly designed. One of the x264 developers did some decent coverage on why this is the case on a technical level:

http://x264dev.multimedia.cx/archives/category/vp8

What, precisely, is your evidence for h263-4-5 or whatever being the best?

The impression I get from article 377 is that the VP8 feature set, the toolbox that the format gives to encoder implementations, is comparable to that of H.264 baseline profile. The main and high profiles of H.264 give encoders such as x264 more ways to squeeze more detail into fewer bits.

A blog post from "Diary of an X.264 developer" http://x264dev.multimedia.cx/archives/377 looked at VP8 and noted a number of probable infringements. The killer argument, though, was this:

The spec consists largely of C code copy-pasted from the VP8 source code -- up to and including TODOs, âoeoptimizationsâ, 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.

So while I don't like Microsoft's business practices or Nokia's for that matter, the idea that VP8 is patent-free seems rather optimistic.

VP8 was already designed to work around patent restricions

Anyone who follows codecs will know that VP8 is extremely similar to H.264 baseline, enough that patent infringement is an almost certainty. As much as we wish that wasn't true, it is. Their "work around" was to give identical technologies different names and put their fingers into their ears screaming "LA LA LA LA LA" denying any patent infringement. When they realized this wasn't going to work, Google finally licensed the patents from MPEG LA.

The more interesting (though not entirely surprising) bit from this news is that MPEG LA might not actually own all the patents required for H.264 to work.

As evil as DRM is, the proposal is technically more "in scope" than video codecs.
The reason why the video codec is considered out of scope is because there is no "best" choice and there is room for improvement (see : h.265, VP9). As for the "proprietary, controlled, patented standard", I believe you mean h.264 aka MPEG4-AVC. Well, sure, it is not free but technically, it is the best for now, plus it has very good hardware support. And we are not certain that WebM is really patent-free considering how close it is to h.264 in some areas. (more info : http://x264dev.multimedia.cx/archives/377).
On the other hand, the proposed mechanism for DRM is much more abstract. It is just an entry point for the decoder to request a key. Nowhere a specific algorithm is mentioned. And the way to actually protect the content is totally out of scope.

As the article states, duck.com was acquired when Google purchased On2 Technologies, previously known as The Duck Corporation. Duck made video codecs for Sega Saturn games, among others. On2 was finally acquired by Google for their VP8 video codec, which became part of the WebM video standard. No conspiracy here.

Libav is a fork of ffmpeg, even if its developers, who are former ffmpeg develeopers, claim otherwise.

Libav proponents argue that theirs is the better fork.

Others say the opposite.

Trying to decide which fork to use, I read these two accounts and concluded that both(!) were saying "stick with ffmpeg". If you are interested in the issue, read these two references and decide for yourself.

I was talking about things like Libre-Office

So I did a little digging. It looks like the first WYSIWYG functionality in personal computer appeared with the Apple Lisa in 1983, and WYSIWYG quickly made its way into the GUI releases of Word and WordPerfect around 1985. Still, this is 1985 we're talking about. You're lamenting the lack of consumer-oriented open-source desktop applications back at a time when any commercial enterprise trying to build and sell such a product was taking a huge risk. The reason Microsoft's mission statement was "a computer on every desktop" wasn't because the hardware was already there! Even Scott Adams mocked Microsoft for their motto in his 1995 book "The Dilbert Principle"; the concept was still seen as far-fetched even then.

KPlayer, KMPlayer, Kaffeine, Dragon Player.

Incidentally, VLC was just one example - there are plenty of others like I listed above, and then Totem and MPlayer.

Reference as many different projects as you like, they sit on the shoulders of the same group of people who've gone to monumental efforts collecting samples, reverse engineering, documenting and reimplementing a massive variety of codecs. It doesn't matter what skin you put on the thing when the hardest part is the compression and decompression of undocumented multimedia formats.

GNUCash is admittedly there, but I doubt that they're so much into working w/ institutions like banks or brokerages than in just being a personal finance manager, which I guess is fine. However, I was thinking not so much about tax software, but rather, something like QuickBooks, which has nothing like it in Linux or BSD environments.

This is exactly what I thought you meant.

I agree that those monumental efforts would not have been easy. However, my argument in my previous post has been that instead of spinning a gazillion different Linux and somewhat fewer BSD distros, people would have done better in pooling their efforts towards making liberated applicaitons software.

Open source and free software isn't powered by some top-down, collaborative idea saying "hey, we need to all work together to do $x", it's powered by a bunch of people doing what interests them, for the reasons they're interested. There's no one, two or even three people who could say "everybody, pull in this direction" and get more than a few hundred people rallying behind them, and certainly not more than for a very limited period of time.

Also, look at the reason the various distros exist. They're iterative technological improvements on previous packaging methodologies (Slackware in response to linux-from-scratch, RPMs in response to Slackware's tarballs, Apt in response to pre-yum RPMs, Portage in response to unoptimized and inflexible binary distributions), philosophical differences (Debian's DFSG as opposed to RH's more lenient policies, Ubuntu's pragmatism vs Debian's strict policies), role/niche-specific distros (FreeNAS, pfSense, netbook-targeted) or political (such as how OpenBSD split off from NetBSD because some of the core devs didn't get along with Theo, and he didn't want to jump through hoops to get work done. (If I read the historical conversations right))

The core distros seem to continue on inertia and contributions from derivatives. Derivatives come and go as they experiment with basing themselves on different software...such as Mint's using Debian to build a rolling-release system.

This is how competition, invention and improvement work; you have to allow for things to break into many overlapping pieces if you want to see which ones work, which ones don't, and which ones beat the pants off of everything that came before.

I expect we're going to have to agree to disagree on this, because all of the solid intellectual reference on this is based in command economies vs free markets, an

Here's a link to a MPlayer YouTube script which also allows playing on the fly. It uses youtube-dl as a helper to fetch the exact video location URL from which MPlayer starts buffering.

Now we just need a Firefox/Chrome extension to make a nicely clickable button which passes the browser URL to the script. One problematic thing here too is that while MPlayer can seek, it does seem to not know the length of the video, so I don't know the current position.

Sounds like FUD to me.

Well that sounds like "head in the sand" to me. From someone qualified who has analyzed the code in detail:

Finally, the problem of patents appears to be rearing its ugly head again. VP8 is simply way too similar to H.264: a pithy, if slightly inaccurate, description of VP8 would be “H.264 Baseline Profile with a better entropy coder”. Even VC-1 differed more from H.264 than VP8 does, and even VC-1 didn’t manage to escape the clutches of software patents. It’s quite possible that VP8 has no patent issues, but until we get some hard evidence that VP8 is safe, I would be cautious. Since Google is not indemnifying users of VP8 from patent lawsuits, this is even more of a potential problem. Most importantly, Google has not released any justifications for why the various parts of VP8 do not violate patents, as Sun did with their OMS standard: such information would certainly cut down on speculation and make it more clear what their position actually is.

If google was confident they were in the clear, they wouldn't be stuffing clauses in the license to the effect of "if this code infringes, you're on your own!".

> Try this one instead:
> http://x264dev.multimedia.cx/archives/377 ... full disclosure: authored by a competitor!

The risk from submarine patents for H.264 is exactly the same as VP8.

No it's not. There are huge amount of companies, both big and small, using H.264. If there ever comes a problem with non-MPEG-LA member, I have a much smaller change of being directed alone. And even if I am, there are so much at play with H.264 that I'm sure to get help with it. You can't say the same for VP8. Hell, even Google isn't trusting VP8 enough to put it in HTML5 video draft.

As far as "subjective" quality issues go, this article sums it up good:

VP8, as a spec, should be a bit better than H.264 Baseline Profile and VC-1. It's not even close to competitive with H.264 Main or High Profile. If Google is willing to revise the spec, this can probably be improved.

VP8, as an encoder, is somewhere between Xvid and Microsoft's VC-1 in terms of visual quality. This can definitely be improved a lot.

VP8, as a decoder, decodes even slower than ffmpeg's H.264. This probably can't be improved that much; VP8 as a whole is similar in complexity to H.264.

With regard to patents, VP8 copies too much from H.264 for comfort, no matter whose word is behind the claim of being patent-free. This doesn't mean that it's sure to be covered by patents, but until Google can give us evidence as to why it isn't, I would be cautious.

VP8 is definitely better compression-wise than Theora and Dirac, so if its claim to being patent-free does stand up, it's a big upgrade with regard to patent-free video formats.

VP8 is not ready for prime-time; the spec is a pile of copy-pasted C code and the encoder's interface is lacking in features and buggy. They aren't even ready to finalize the bitstream format, let alone switch the world over to VP8.

With the lack of a real spec, the VP8 software basically is the specâ"and with the spec being âoefinalâ, any bugs are now set in stone. Such bugs have already been found and Google has rejected fixes.

Google made the right decision to pick Matroska and Vorbis for its HTML5 video proposal.

[quote]Support: here is a performance comparison of the latest iteration of the WebM encoder hardware, showing also previous versions and a h.264 encoder for comparison.

http://blog.webmproject.org/2011/11/time-of-dragonflies.html%5B/quote%5D

I hope you realize that the comparison you linked to compares ENCODER quality between two decoders (H264 and WebM) made by the same company? It says nothing about the abilities of WebM as a codec.

Try this one instead:
http://x264dev.multimedia.cx/archives/377

I suppose it can become very close with a good encoder but according to http://x264dev.multimedia.cx/archives/377, h264 has the advantage.
Being written by a x264 developer, this article is probably biased but his arguments look valid.

Let me just say this :

Finally, the problem of patents appears to be rearing its ugly head again. VP8 is simply way too similar to H.264: a pithy, if slightly inaccurate, description of VP8 would be “H.264 Baseline Profile with a better entropy coder”. Even VC-1 differed more from H.264 than VP8 does, and even VC-1 didn’t manage to escape the clutches of software patents. It’s quite possible that VP8 has no patent issues, but until we get some hard evidence that VP8 is safe, I would be cautious. Since Google is not indemnifying users of VP8 from patent lawsuits, this is even more of a potential problem. Most importantly, Google has not released any justifications for why the various parts of VP8 do not violate patents, as Sun did with their OMS standard: such information would certainly cut down on speculation and make it more clear what their position actually is.

Read the article (there's about a page's worth of text in there about patents, including specific processes. It convincingly tears the notion that VP8 is independant from h264 to shreds), this guy's done a lot of research into this :

http://x264dev.multimedia.cx/archives/377

Normally this situation is pretty cut and dry. Unfortunately, the problem here is that H.264 is substantially better technology than WebM, it's not clear that WebM is not trampling on MPEG-LA patents, Google is not indemnifying WebM users against it, and Ogg Theora is noticeably worse than WebM.

I am obviously in favor of eliminating software patents, and thereby eliminating the problem of patent trolls like MPEG-LA. I am also obviously in favor of open standards. But this is not like most software where we can just round up some of the gang and knock out a new better thing in a few weeks. There are not a lot of people who can design a modern, performant, high-quality video codec, open source or no (notably, both Google and Xiph have managed to do a shitty job). To do so within our legal constraints really might be asking too much.

Since it looks like we don't get to live in the world we want to live in, we have to ask ourselves which of the worlds we can have we would like. I don't relish the idea of having inferior technology foisted on me any more than the idea of closed standards. But it's looking like we're going to have to pick one, and I don't think when it comes down to it I'd rather have the inferior technology.

Objection. The correct sentence here is "who is surprised that MPEG-LA claims that WebM steps all over patents controlled by MPEG-LA".

Others have already predicted VP8 would run into patent issues.

Anyone who knows even the least bit about video codec technology can tell you that it's virtually impossible to design an advanced video codec that does not infringe on any video coding patents, which isn't surprising if you consider the technology involved is decidedly non-trivial, and took over 3 decades to develop. H264 is currently the most advanced standard for video coding, but it didn't materialize out of thin air either: it simply builds on the concepts you'll see in MPEG 1, 2, 4 and so forth.

The only codec I can imagine that does not violate any H624 patents would either be incredibly crappy, or downright revolutionary. I know for a fact that VP8 is not the latter.

It's too late for that. The egos in both organizations are entrenched now, merging would be very difficult.

This is the same problem, unfortunately, as the ffmpeg vs. libav fork problem (which recently has led to odd lawsuit threats).

Looks like they're planning to add alpha channels and XMP metadata, as well as a bunch of other more-or-less useful features, like 3d support.
http://www.youtube.com/watch?v=30_AIEhar-I#t=29m10s

I think the SSIM advantage is adequately documented with the study linked to in TFA, though in the end what it comes down to is visual comparison. The earlier encoder was accused of overoptimising for PSNR, to the detriment of the overall image quality. Hopefully they can get some more heavy-duty psychovisual optimisations applied to both the video and still image encoders for further improvements.

Utter rubbish.

http://www.osnews.com/permalink?470666

tl;dr "Google hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer implementations of this specification"

IOW: Anyone may use, anyone may implement, full permission is granted irrevocably and in perpetuity (as long as you don't sue Google).

Specification is documented and submitted to the ITEF.

An independent implementation is here:
http://x264dev.multimedia.cx/archives/499

Your claim "H.264 is far more open than WebM" couldn't be more wrong if you tried for millennia to make it more incorrect.

A lot of current smartphones and tablets use a system-on-chip similar to the OMAP on the BeagleBoard, with a programmable digital signal processor. With a programmable DSP, hardware acceleration is a matter of rewriting the transforms to use the intrinsics of the DSP. The infamous article 377, which analyzed VP8 and showed it to be in effect baseline AVC with the patented parts scraped off, demonstrated that a DSP-aware decoder for VP8 shouldn't be any harder than a DSP-aware decoder for AVC. So did you mean this in the sense of "VP8 cannot be accelerated on a mobile SOC", or "VP8 is not yet accelerated in the mobile firmware versions deployed as of Sunday, February 13, 2011"?

Maybe he meant it in the sense of VP8 isn't ever going to cause a mobile phone device manufacturer to develop, test and deploy an update to their firmware to support a new codec, when you can barely find a handful of phones that even get regular OS updates. Samsung, Motorola, Sony, etc do such a poor job of supporting newer Android releases from Google, I'm sure we'll find their existing phones will be updated REAL soon to support Google's favorite new video format.

Or did you think the same manufacturers who also make Win7 phones were going to do it?

Or did you think Apple was going to do it?

Nokia: Switching to Windows Phone 7. There goes that!

So I guess you mean HP or RIM? PS: I doubt that's going to happen either.

It's not that it "cannot be accelerated" as you state, nor is it that it "is not yet accelerated in the mobile firmware versions deployed as of...." as you stated. It's that "it ain't going to happen".

Something that sucks the living hell out of a battery, that has ZERO hardware acceleration on mobile

A lot of current smartphones and tablets use a system-on-chip similar to the OMAP on the BeagleBoard, with a programmable digital signal processor. With a programmable DSP, hardware acceleration is a matter of rewriting the transforms to use the intrinsics of the DSP. The infamous article 377, which analyzed VP8 and showed it to be in effect baseline AVC with the patented parts scraped off, demonstrated that a DSP-aware decoder for VP8 shouldn't be any harder than a DSP-aware decoder for AVC. So did you mean this in the sense of "VP8 cannot be accelerated on a mobile SOC", or "VP8 is not yet accelerated in the mobile firmware versions deployed as of Sunday, February 13, 2011"?

No, Google sent a bunch of C code in an email. In its current form it is not very useful for somebody who wishes to implement their own version of the codec. It is really not explained at all in the way that an actual specification is expected to be.

http://x264dev.multimedia.cx/archives/377 explains this all, but I am sure you know all this already.

The WebM patent pool is not just FUD. One of x.264's developers wrote a technical analysis of WebM and determined that WebM was similar enough to H.264 to step on its patents.

That would be the "fear" part of FUD. FUD = Fear, Uncertainty, Doubt. The fear can be real and justifiable and still meet that definition, you illiterate fuck who needs obvious things explained.

Try, yes, but they didn't do a very good job.

The WebM patent pool is not just FUD. One of x.264's developers wrote a technical analysis of WebM and determined that WebM was similar enough to H.264 to step on its patents.

IETF also has items like RFC1149: A Standard for the Transmission of IP Datagrams on Avian Carriers

In other words, there is no filter; it seems anyone can submit anything to the IETF. My main concern over the WebM "specification" is best summarized by by the great analysis at http://x264dev.multimedia.cx/archives/377:

But first, a comment on the spec itself.

AAAAAAAGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!

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. I may have complained about the H.264 spec being overly verbose, but at least it's precise. The VP8 spec, by comparison, is imprecise, unclear, and overly short, leaving many portions of the format very vaguely explained. Some parts even explicitly refuse to fully explain a particular feature, pointing to highly-optimized, nigh-impossible-to-understand reference code for an explanation. There's no way in hell anyone could write a decoder solely with this spec alone.

In other words, there is no real spec that could stand up to ISO-type scrutiny, ignoring all politics. They are attempting to make standard a specific implementation, with all its current quirks and flaws, and from what I've read it is now set in stone; even though they are posting an RFC (request for comments) they will not be changing the spec to address the known flaws.

How is this good for anybody but Google?

Update: spatial intra prediction apparently dates back to Nokia’s MVC H.26L proposal, from around ~2000. It’s possible that Google believes that this is sufficient prior art to invalidate existing patents — which is not at all unreasonable!

MPEG-LA has pledged to "never" charge for serving "free of charge" content over the web right now. That doesn't mean they're not going to charge for it in the future, they revisit the question over and over.

Ok, that's wrong, and despite multiple accounts of being corrected, people here keep perpetuating this myth. They're not going to revisit it. The decision is final.

But the question comes down to what constitutes as "free view" over the web? If you look at major hits such as RayWilliamJohnson, people like that "profit" off of making videos on the internet. He's got t-shirt deals that now have his stuff being sold in Hot Topic stores across the country. He's a pretty big Youtube phenomenon as a result of videos being posted on the internet "for free".

MPEG LA's defines non-free view as "AVC video sold to end users for a fee on a title or subscription basis". So it's very simple: can you view the entire video without being required to purchase it? It's free. If you need to buy it/rent it/subscribe for it, it's not free. Having ads or merchandise or other indirect profit models around or over or in the video is irrelevant.

You're right that everything "costs money" and some things have direct and indirect costs. The difference is that to ensure the internet remains open and competitive for everyone, we need to make sure that as much driving force behind the technology standards used by the vast majority of it are for the public good.

Right, and who gets to decide what is good here?

1) A wide consortium of companies working together on creating H.264, academia, guided by respected standards organisations: ISO, IEC, Apple, DAEWOO, Dolby Labs, France Telecom, Fraunhofer, Fujitsu, Hitachi, Philips, LG, Microsoft, Panasonic, Bosch, Samsung, Sharp, Siemens, Sony, Ericsson, Columbia University, Toshiba and more...

2) Google. Which bought some small company making codecs.

And yet, the automatic assumption is Google has singlehandedly pulled a rabbit out of their hat, because all some people need to know is that it's "free", and may any other annoying details and facts be ignored.

On one side, we have H.264 designed with the feedback of a wide consortium of experts, companies and respected standardization organisations, and very clear and apt licensing rules.

On the other side, Google and their technically inferior, buggy H.264 clone with an untold number of IP violations. But don't take just my word for it.

In layman's terms, we call what the MPEG-LA doing as a "bait and switch".

The above clarifications renders this remark baseless. The problem in this debate is some people prefer to arm themselves with an ideology fueled narrative and a set of outdated or outright wrong talking points about supposed "bait and switch" threats and preserving "freedom", and don't bother to even check what they're talking about.

by russryan
              Also, http://x264dev.multimedia.cx/archives/377 for a VP8 tear down.

"Overall, VP8 appears to be significantly weaker than H.264 compression-wise. The primary weaknesses mentioned above are the lack of proper adaptive quantization, lack of B-frames, lack of an 8×8 transform, and non-adaptive loop filter. With this in mind, I expect VP8 to be more comparable to VC-1 or H.264 Baseline Profile than with H.264."

Ouch. You're a brave man to publish that on /.

Also, http://x264dev.multimedia.cx/archives/377 for a VP8 tear down.

I prefer that as my video playback of choice. I don't want want the sub par solution.

I think if WebM and H.264 were technically indistinguishable, but WebM were an open format and patent-free, it would certainly be better than H.264. But they are not technically indistinguishable. Let me bring up some crucial points from Jason Garrett-Glaser's excellent analysis of WebM as a technology:

• WebM's "specification" is laden with C code from Google's "reference implementation." It's not trying to be a standard in the sense of, here's the definition and some implementations, it's trying to be a standard in the sense of, everybody uses the same open-source implementation.
• WebM is technically inferior to H.264. Jason points out that only in the lowest quality profile does it come close to matching H.264. However, to avoid certain obvious patents, they make the codec worse than it had to be. They also failed to optimize it for embedded devices.
• WebM tries very hard to avoid H.264's patents, but is so similar in many places that it is hard to tell whether or not they have successfully avoided them.

If both were open and free, H.264 has technical merit over WebM, and that would be everyone's choice. However, I don't feel that just because there is a licensing fee involved with H.264, the technical merits just disappear. I also think WebM's legal situation is much less settled than people assume. If I were MPEG-LA, I would certainly be spending a lot of time and money determining all the ways I could argue that WebM infringes on my patents, and wait as long as reasonable to bring it to court in the hopes of getting the maximum in damages out of Google. People seem to have forgotten than Google is not indemnifying users of WebM. This means that if WebM is legally found to be infringing, all users of WebM could be liable, not just Google! This situation is far worse than with H.264, where the device manufacturer or software provider is the only one who can be on the hook. Google has essentially passed the legal buck.

Google may be posturing itself as saving us all from H.264 licensing fees, but they are simultaneously trying to lock us into an "open" specification that they have sole control over. I expect that before this battle is over, they will have spent more than H.264's licensing fees on litigation with MPEG-LA, defending WebM's high degree of similarity to H.264. Google is depending on our short attention spans white-washing them from all guilt for making this situation a bigger legal morass than it has to be. Let's not forget.

Add to that, VP8 is very similar to H.264 and other codecs.

Which is exactly why WebM is a patent mess.

As I understand the responses to http://x264dev.multimedia.cx/archives/377 on various web sites, the differences between H.264 baseline and VP8 are precisely in those points where H.264 is patented.

No. Expert opinion is that WebM infringes on numerous patents in the H.264 pool, and will need a licensing pool of its own to be set up, just like Microsoft's VC-1 did. So the patents are a wash. This is Google manipulating the market entirely for selfish advantage here, and it's all the worse because they're pretending otherwise. And it's going to be really frustrating watching people fall for it.

First of all, Jason Garrett-Glaser (aka Dark Shikari) does not make a single specific claim of patent infringement in the article you cite. He merely claims that there is a probability of infringement without any legal background in patent law to support it.

Secondly, some people have suggested that VP8 was designed not to infringe on H.264. The idea is that VP8 is essentially H.264 with all the patented bits deliberately replaced or removed. Dark Shikari's description of his own implementation of VP8, ffvp9, seems to support this theory. If this is the case, WebM infringes on none of the MPEG-LA patents, while any patent outside their portfolio would represent an equal threat to both codecs. In fact, since VP8 uses some older techniques for which patents have already expired, it's entirely possible that it's safer than H.264.

No. Expert opinion is that WebM infringes on numerous patents in the H.264 pool, and will need a licensing pool of its own to be set up, just like Microsoft's VC-1 did. So the patents are a wash. This is Google manipulating the market entirely for selfish advantage here, and it's all the worse because they're pretending otherwise. And it's going to be really frustrating watching people fall for it.

First of all, Jason Garrett-Glaser (aka Dark Shikari) does not make a single specific claim of patent infringement in the article you cite. He merely claims that there is a probability of infringement without any legal background in patent law to support it.

Secondly, some people have suggested that VP8 was designed not to infringe on H.264. The idea is that VP8 is essentially H.264 with all the patented bits deliberately replaced or removed. Dark Shikari's description of his own implementation of VP8, ffvp9, seems to support this theory. If this is the case, WebM infringes on none of the MPEG-LA patents, while any patent outside their portfolio would represent an equal threat to both codecs. In fact, since VP8 uses some older techniques for which patents have already expired, it's entirely possible that it's safer than H.264.

You are both wrong. The most resource-intensive parts of a video codecs are handled by DSP's that are very specific to the codecs they support. While some parts of WebM will translate to current hardware just fine, some parts of the standard have been found not to translate to it at all. Just read this to educate yourself on the subject before assuming hardware WebM support will be a matter of a simple firmware update:

http://x264dev.multimedia.cx/archives/377

Why would it "probably" be as patent encumbered as h.264?

Dark Shikari, a developer of x264, made an extensive analysis of WebM / VP8. Here is his summary regarding patents and VP8 (for details read the blog):

Finally, the problem of patents appears to be rearing its ugly head again. VP8 is simply way too similar to H.264: a pithy, if slightly inaccurate, description of VP8 would be “H.264 Baseline Profile with a better entropy coder”. Even VC-1 differed more from H.264 than VP8 does, and even VC-1 didn’t manage to escape the clutches of software patents. It’s quite possible that VP8 has no patent issues, but until we get some hard evidence that VP8 is safe, I would be cautious. Since Google is not indemnifying users of VP8 from patent lawsuits, this is even more of a potential problem. Most importantly, Google has not released any justifications for why the various parts of VP8 do not violate patents, as Sun did with their OMS standard: such information would certainly cut down on speculation and make it more clear what their position actually is.

Why would it "probably" be as patent encumbered as h.264? Google claims no patents at least, so that would in this case be if it's too similar in some regard to MPEG LA patents.

In an earlier slashdot discussion znu writes:

"But wait!", the OSS fans are saying. "Isn't Google really standing up for freedom and justice, because H.264 requires evil patent licensing?"

No. Expert opinion is that WebM infringes on numerous patents in the H.264 pool, and will need a licensing pool of its own to be set up, just like Microsoft's VC-1 did. So the patents are a wash. This is Google manipulating the market entirely for selfish advantage here, and it's all the worse because they're pretending otherwise. And it's going to be really frustrating watching people fall for it.

it's more or less as good as h.264

Nope. A shame, but at least it's better than Theora.

Yup, there is very little evidence other than Google's claims that WebM is really patent-free.

There was a VERY good analysis of WebM from one of the x264 developers (admittedly there could be bias there, but my opinion was that it was high on technical content but low on bias.) - http://x264dev.multimedia.cx/archives/377

There was at least one component of WebM that the x264 developer felt WAS patent-encumbered. However there is a potential for a prior art challenge on that one.

The WebM/VP8 spec is apparently AWFUL. Almost as bad as, if not worse than, Microsoft's OOXML spec.

Google's motivation is obviously to try to establish an open source, free (as in speech) codec as the web standard for video.

Then Google picked the wrong codec to buy/push. WebM is likely to be just as patent-encumbered as h.264, since large parts of the VP8 spec were poorly ripped from h.264's spec, or are at least similar enough to be covered by many of the same patents.

A good examination on a technical level (including some thoughts on the likeliness of patent-encumbrance) can be seen here. He's admittedly a tad biased by being one of x264's lead developers, but he's also one of the authors of ffvp8, and it's an interesting read.

Of particular worry is the flawed nature of the VP8 spec; the reference implementation *is* the spec, bugs and all. Google didn't allow for any time to try to correct/improve the spec before declaring it final, so now we're all stuck with .

Will people please stop citing an x264 developer's rant as an "expert opinion" on the video quality or patent risks of WebM?

Could we please stay on the arguments and not argue about the person presenting them? The article The first in-depth technical analysis of VP8 presents several arguments why WebM could be affected by patents held by MPEGLA. Personally I don't care if these arguments were made by an x264 developer, the pope or Jeffrey Dahmer. I am only interested in the facts.

You are free to disagree with the arguments presented in that article. Even better when you can present some reasonabel doubts or even some qualified counter arguments. But please don't argue ad hominem.

No, it's not. I've seen both in action, and they're perceptually identical. I see this argument a lot, and the people who make it are simply pulling it out of their ass.

http://x264dev.multimedia.cx/archives/377 Take a look at the images at the end. There is a very distinct blockyness in the v8 images compared to that of H.264. Every v8 video i've seen is inferior to it's H.264 counterpart. Now if you want to argue that the difference is pretty small in the long run, I'd agree. But as it stands now, H.264 is superior.