Slashdot Mirror

You simply are proving my point that Google is in a position to assert itself in the market.

I don't see how. None of the software I use on any platform comes directly from Google. The software I use has chosen to use some open source components that Google has released. And when it comes to WebM specifically, they could chose to get behind ffmpeg's independent implementation if they felt like it:

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

They are not doing this for the sake of open source or open standards. They are doing it for the sake of making more money

You seem to be suggesting that supporting open source and open standards is incompatible with or somehow contrary to making money. It isn't. Red Hat does it. Google does it. Many companies do it because it works.

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.

Sorry, but an x264 developer is not a lawyer. Citing him as an "expert" on whether or not WebM infringes patents is frankly rather silly.

This serves two strategic purposes for Google. First, it advances a codec that's de facto controlled by Google at the expense of a codec that is a legitimate open standard controlled by a multi-vendor governance process managed by reputable international standards bodies. ("Open source" != "open standard".) And second, it will slow the transition to HTML5 and away from Flash by creating more confusion about which codec to use for HTML5 video, which benefits Google by hurting Apple (since Apple doesn't want to support Flash), but also sucks for users.

It is, in other words, a thoroughly nasty bit of work. It's not quite as bad as selling consumers down the river to Verizon on 'net neutrality, but it's close. And if Google is actually successful in making WebM, not H.264, the standard codec for web video, they're literally going to render hundreds of billions of dollars worth of tablets, smartphones, set-top boxes, etc. with H.264 hardware support obsolete.

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

So basically he claim that if it can run Amiga Bratwurst in 1080 there's not need to upgrade the hardware because hey, it's 1080p?

Omg the graphics! http://www.mobygames.com/game/amiga/bratwurst/screenshots/gameShotId,192350/ ;D

(Actually it's very fun, zooming in and out as you approach each other.
Amiga Roketz looked better but played worse.
And then there was Gravity Force of course.)

Have they managed to improve the quality of the VP8 codec? Last time I saw a comparison, VP8 was way behind H.264.

And don't even give me that crap about "it's free, it doesn't have to be as good" or "it's only a web codec so who cares". If there's a number of big companies supporting the project and they plan on making WebM some kind of industry standard, anything less than state of the art is unacceptable. We'll be using this for years to come, so doing it right is in everyone's best interest.

ffmpeg was already a lot's of faster than the original sdk : http://x264dev.multimedia.cx/archives/499

They may have managed to increase performance, but the real question is have they increased the actual output quality (without having to tweak the crap out of it):
http://x264dev.multimedia.cx/archives/377

Also, I thought we've determined that PSNR is NOT a very good measure on the quality of a codec...

Even for massively parallelizable problems like video compression, once you exceed a certain number of nodes doing the work, the time spent assembling the final data actually exceeds the performance win achieved by adding additional processing nodes.

Clearly you don't work on any of the h.265 proposals. When it takes almost an hour per frame to encode, the number of nodes where assembly time exceeds time savings is astronomical ;)

That's actually a pretty good point. However, those stats came from this benchmark test, which has a good explanation of how those results came to be.

I wouldn't quote Jan Ozer. See comments 69 and 70 at http://x264dev.multimedia.cx/?p=292 (a x264 developer's blog). Choice quote: "We talked about that on IRC, both with x264 and Theora people: all considered it one of the worst articles they had ever seen."

Jan Ozer routinely qualifies everything he does with words to the effect of "I'm not a technical person". StreamingMedia.com bills him as a "video codec expert" but it's rather clear that he isn't.

Hey guys, before assuming MPEG LA has patents and is therefore evil, have you actually checked the license terms?

The licensing is really quite cheap. At low quantities, the licensing per codec is only $0.20. You really only should need one of these per computer, and there is no particular reason why every piece of video software get for free should need to have its dedicated codec.

Pay per view is the lower of 2% and $0.02 per view.

Based on what the x264 developer diary says, VP8 is a blatant ripoff of H.264 anyway, so I'm a bit dissapointed that Google was tricked into supporting this for WebM. I would have much rather supported an entirely new format that made use of new ideas, rather than something that steals original work and gives it enough tweaks to make it questionably legal.

Seriously, guys, this is what patents are for. H.264 is an excellent format, quite efficient to implement in hardware. The guys who designed it deserve to get paid something, even if much of the complexity is in the codec - as the x264 blog says, there is only so much you can do with a bad format.

Developing a good codec is very complex, and that's before trying to dodge patent landmines.
For a deeper understanding of how things stack up with h.264 and VP8, it helps to get the perspective of a ffmpeg/x.264 developer.
It's a very detailed technical analysis.

Probably not. x264 has a number of innate visual advantages to compressing video that were previously mpeg compressed. VP8 generally seems to win on raw uncompressed video in the races I've seen.

Then you've been fooled. The study you're referring to used videos pre-compressed with other MPEG standards, and the VP8 guys claimed that that biased it toward other MPEG-like codecs. They said VP8 got better with an uncompressed source.

VP8 got better. On a single test. A single test is not conclusive for anything but that single test. Note that, even for that single test, it still didn't beat H.264 -- it merely got better.

What we know (not assume), is that the core of VP8 is almost identical to the H.264 Baseline profile. VP8 is an MPEG-like codec! It's got a few small tweaks, some that help and some that don't. The features that would give it an obvious advantage or disadvantage on pre-compressed video are identical.

3. Making invalid comparisons using objective metrics. I explained this earlier in the linked blog post, but in short, if you’re going to measure PSNR, make sure all the encoders are optimized for PSNR. Equally, if you’re going to leave the encoder optimized for visual quality, don’t measure PSNR — post screenshots instead. Same with SSIM or any other objective metric. Furthermore, don’t blindly do metric comparisons — always at least look at the output as a sanity test. Finally, do not claim that PSNR is particularly representative of visual quality, because it isn’t.

How to spot it: Encoders with psy optimizations, such as x264 or Theora 1.2, do considerably worse than expected in PSNR tests, but look much better in visual comparisons.

4. Lying with graphs. Using misleading scales on graphs is a great way to make the differences between encoders seem larger or smaller than they actually are. A common mistake is to scale SSIM linearly: in fact, 0.99 is about twice as good as 0.98, not 1% better. One solution for this is to use db to compare SSIM values.

VP8 and H.264 and other MPEG codecs use basically the same transform so their statements of bias against VP8 ring untrue

An x264 developer may have said it, but that doesn't make it true. He contradicts himself often enough, anyhow...

Yes, the macroblock size is the same, however, that's just about it... VPx codecs use rather different quantizer matrices, never use B-frames, store motion vectors differently, and in general just have a very different and unusual encoding method. There are many ways in which it is different, and more to the point, far more different from H.264 than H.264 is from MPEG-2... Of course it can be over-stated, but it's very, very real.

And BTW, what the hell is a "transform"? If you're going to pretend to be knowledgeable about a subject, you could at least have the decency to use precise terminology, so I can more efficiently ridicule you... If you're talking about the "T" in DCT, then I've got bad news for you. While nearly all lossy codecs are indeed using DCT, that's about as relevant as saying all vehicles burn fuel.

I'll see your x264 developer quote, and raise you one ffmpeg/Adobe Flash developer quote: http://multimedia.cx/eggs/dct-pr/

While he's talking about Theora, all points apply directly to VPx. Highly relevant quotes below:

"Theora is rather different than most video codecs, in just about every way you can name"

"As for the idea that most DCT-based codecs are all fundamentally the same, ironically, you can't even count on that with Theora- its DCT is different than the one found in MPEG-1/2/4, H.263, and JPEG (which all use the same DCT)."

But you can ignore him if you like. He's just the guy who actually wrote the VP3 and Theora decoders for FFmpeg, and has reverse engineered numerous other codecs, so I'm sure he doesn't have a clue... You know, unlike a vocal x264 developer...

And just to push further off topic, DCT isn't all that good, anyhow. The default in FFmpeg encoding isn't DCT, but SAD (Sum of Absolute Differences). SAD happens to be much faster, and more importantly, doesn't leave strangely colorful 16x16 blocks (usually green, but often red or other colors) as artifacts in low-bitrate encodings, which then have to be masked, wasting bits which could be better used elsewhere.

One of the professors who was part of doing this test even confirmed that the VP8 developers statement was untrue and misleading.

Facts aren't determined by popular opinion... And 2 people isn't much of a vote, anyhow.

While looking at encoder comparisons, keep in mind this post from a x264 developer about cheating on encoder comparisons. I'm not saying that these guys are cheating, just things to look out for.

Free browsers are able to support H.264 without problems as long as they don't distribute the decoder themselves. Since most modern operating systems come with an H.264 decoder and you can easily install one on older ones (e.g. the Divx7 decoder on WinXP) there is no problem in supporting the format for the majority of the users as long as they use the system framework instead of decoding directly. Mozilla made a lot of weak excuses for not using system codecs and at the same time they had no problem implementing a gstreamer backend for Fennec so that H.264 could be played back on their mobile browser using the system's codec framework.
They even went so low as posting a Theora encoded video and a bigger H.264 encoded file on their site to show that Theora is actually better than H.264. The comparison was bunk of course. Upon closer examination it turned out that the H.264 file had been stuffed with hint tracks doubling its filesize. They also used Apple's H.264 encoder which is one of the worst when it comes to quality.

A x264 developer blogged about problems with both HTML5 and Flash video some months ago.

But those x264 devs have some vested interest in H264. They invested a great deal of their time into x264 and they don't seem to want anything other to succeed.

By analysing their analyses I concluded that they do not research outside of x264 improvements. They criticise, their critique is valid, and that's all. They do not offer ways for other codecs to overcome their points of cencern.

My favorite example is here: "Wavelets don’t seem to code visual energy effectively." Okay, looks he's right. But what steps should Dirac and Snow developers do to overcome that?

I understand that it is not their direct responsibility - to help others do their job. But they demonstrate such high level of curiositylessness in other approaches so that I conclude that they do not want others to succeed.

VP8 has already been dissected and determined to be a bad video codec that likely steps on several H.264 patents. Note that Google isn't providing any legal protection for using this codec.

You can blame the lack of hardware support if you want, but it won't change the fact that VP8 is crap as a codec and likely steps on H.264 patents.

The Wii is more than an "overclocked GameCube with a Bluetooth receiver." It has a motion-based controller, which did make it state of the art.

VP8 doesn't even hold up against H.264.

I accidentally left out the link dissecting the VP8 codec and determining it to be bad:

http://x264dev.multimedia.cx/?p=377

VP8 shares a lot of features with H.264's Baseline profile. I'd expect a lot of code to be sharable between them.

From what this article say, really none

Exactly, see the VP8 technical analysis by Dark Shikari

The very example the OP refers to (DCT) is telling:

H.264 uses an extremely simplified “DCT” which is so un-DCT-like that it often referred to as the HCT (H.264 Cosine Transform) instead. This simplified transform [...] can be implemented entirely with adds, subtracts, and right shifts by 1.
VP8 uses an extremely, needlessly accurate version[..]

The analysis on the x264 blog concluded that VP8 most closely resembles H.264 baseline, and the comparison shows that H.264 baseline encoded with x264 lies somewhere between Theora and H.264 Main.

There is certainly some chicken-and-egg concern(though this might be obviated by the fact that Google has a massive arsenal of web videos, and a browser, and mozilla could probably also be counted on).

As for costs, it wouldn't surprise me if the format was designed(in part) to keep those low. Remember the analysis linked to here a few days ago? The punchline was, in essence "very much like h.264, except in a few specific ways that are largely worse". Now, assuming that the On2 people aren't complete morons(which would also imply that their new Google overlords are complete suckers), why would they create a codec like that?

Well, h.264 is the best supported(in terms of software, and embedded hardware decoders) of modern video formats. It is also considered to be quite good, the product of research by a large number of people and entities. However, it is patent encumbered. Therefore, you would expect a rational competitor to do the following: Copy h.264 as closely as possible in all unpatented respects, or respects where patents can be worked around. Nobody is giving you any extra credit for re-inventing the wheel, and (unless you have particular reasons to believe the contrary) trying to do so would likely result in a worse wheel. Where the spec is simply too patent encumbered, implement the least-worst replacement for that bit that isn't encumbered.

Based on that technical analysis, it strikes me as extremely likely that this is more or less what On2 did. Do a patent search, presumably focusing on the MPEG-LA pool, and any other likely suspects. For any parts of h.264 too heavily covered to engineer around the patents, make the smallest legally tenable compromise.

Since the vast majority is extremely similar to h.264, this will likely make adding hardware support cheaper, since most of the dedicated decoder logic and/or embedded DSP firmware can be shared between h.264 and WebM, with small additions to cover the differences.

> However, mp3 is not free...yet. Some of these patents are set to expire on their 20 year time frame in a couple of years it would seem.

Yes, the next MP3 patent expires this Sunday. The longest patent seems to expire in 2018 but that appears to be MPEG-2 LSF and only required for low sample rate MP3s. So the next furthest date looks like April 2017 but it may be worth double checking the dates on those around 2014/2015.

http://wiki.multimedia.cx/index.php?title=MP3_Patents

On top of that, the frames are then compressed into GIFs as opposed to the lossless PNG and then uploaded with a .jpg extension. This guy is clueless.

Furthermore, in a video comparison, is audio even included in the file and, even worse, why is the audio encoded differently? This throws some doubt on fairness of the result since the filesize of the overall files are very close but the audio portions of the file likely take up different amounts of space.

Finally, why is VP8 thrown in the "WebM" container (which is just MKV) and the H.264 video thrown in the mp4 container?

http://x264dev.multimedia.cx/?p=292

The encoder of course is a huge difference, but in this case, even the h.264 format is superior to VP8. There's an interesting and often referred to article that compares the specification directly: http://x264dev.multimedia.cx/?p=377.

That guy didn't even use a proper h.264 encoder and proper h.264 settings. He used JPEG to store the resulting images. His "comparison" is borderline worthless. If you want to read a real comparison between the codecs, check out http://x264dev.multimedia.cx/?p=377.

The comparison seems to use sorenson squeeze (based on MainConcept if I am not mistaken).
I don't believe it can mach x264's capabilities and speed.

Using x264 for comparison would be much fairer.

The comparison is done by Jan Ozer. He's billed as a "video codec expert" but I don't think he has the technical expertise to, for example, make use of x264. His previous H.264 versus Theora comparison wasn't very impressive either. The x264 developers described Ozer's Theora versus H.264 comparison as "one of the worst articles they had ever seen".

The analysis over at Dark Shikari's blog was conclusive in saying that VP8 is basically a poor mans H.264, borrowing bits of H.264s specifications and ultimately not quite as smart, so the comparison points in the article aren't that surprising. The quality point is moot however anyway, since it's pretty obvious that VP8 uses so much from H.264 that it's very likely of falling victim to the patent pool.

From the link given in the summary:

in my tests it beats Dirac quite handily as well.

Let's get the patents that MPEG-LA claims might affect VP8 out in the open.

The last article linked to an analysis of VP8 that pointed out its striking similarity to H.264 Baseline. So I guess you can start with the H.264 patent list on mpegla.com. Removing these patented parts would turn it into Theora, which is closer to DivX (MPEG-4 Part 2).

> They specifically state that those comparison shots aren't even at the same bitrate. Useless comparison.
I'd like to politely suggest you learn to read. They stated that bitrate is identical.

Look at the files on http://x264dev.multimedia.cx/?p=377:

vp8.mkv - 17479998 Byte (actually a raw stream, not mkv)
x264.mkv - 17111109 Byte
x264baseline.mkv - 17213488 Byte
ptalabvorm.ogv - 16909836 Byte
dirac.mkv - 17439049 Byte
vc1.mkv - 17436535 Byte
xvid.avi - 17616424 Byte

As you can see the filesizes and thus bitrates are pretty close. Actually, VP8 even had slightly more bitrate in this comparison.

>>>You, sir, obviously dont have a clue what you are talking about

Perhaps not but this guy DOES know what he's talking about, and he agrees with me - VP8 isn't as good quality as MPEG4: http://x264dev.multimedia.cx/?p=377 As for my error, just go back to my previous post and replace "Flash" with "Sorenson Spark" if you're so picky. :-) It doesn't alter my opinion.

But is it really patent free?

From reading this analysis it doesn't seem like it is to me.

http://x264dev.multimedia.cx/?p=377

They don't seem that impressed. It is less robust than H.264, in some places seems to outright copy it. Google is offering no patent indemnification (from the article: "this is a patent time-bomb waiting to happen.")

They give it credit for being the best open source format out there, but they fault it generally in every other category.

Google says it holds certain patents on the VP8 video codec that is part of WebM but there's no assurance that Google's patents are the only patents required. What about patents that third parties could assert? While it appears to be a nice gesture if a major player releases software on open source terms, it's imperative to perform a well-documented patent clearance.

Developers should be provided with detailed explanations why Google believes that no one adopting WebM will have to fear allegations of patent infringement. Otherwise those developers might be exposed to considerable risk. It wouldn't be possible to check on millions of different patents but at the very least I think Google should look at the patents held by the MPEG LA pool as well as patents held by some well-known 'trolls' and explain why those aren't infringed. Programmers have a right to get that information so they can make an informed decision for themselves whether to take that risk or not.

It's not unreasonable to ask Google to perform a well-documented patent clearance because they certainly have the resources in place while most open source developers don't.

The situation surrounding Android shows that Google might opt to stand on the sidelines if those adopting its open source technologies -- such as HTC -- are sued by patent holders. I can't find any promise on the WebM website that Google would come to the aid of third parties adopting the technology, so Google should at least help everyone to assess the risk.

We all know Steve Jobs' recent email in which he said a patent pool was being assembled to go after open source codecs. So the patent question is really a critical one. Also, this in-depth analysis by an X.264 developer shows that VP8 and H.264 are so similar that the risk of patent infringement could be substantial.

I have previously called for this kind of patent clearance, in connection with the open source Theora codec as well as with VP8, here on slashdot as well as on my blog, such as in this post.

Analysis can be found here. Comparison pictures to other codecs are included.

A first in depth analysis of VP8 for those interested. It also includes screenshots comparing it with other formats.

Basically every codec supports variable bitrate and the buffering problem is codec independent. This article among other things talks about missing features in HTML5.

On buffering:

1. Missing features. Developers who haven’t worked with Flash often underestimate its capabilities and assume that displaying video is as simple as displaying images. But there are many things that are useful to control. Flash lets you tell the client how long to buffer before playing a stream (critical for reliable playback of any live video). It provides signalling back to the server of packet loss rates, so that the server can throttle bandwidth accordingly.

It'd be easier to fight h264 if anything nearly as good wasn't likely covered by patents.
Flash, Google, VP8, and the future of internet video

Are you serious? http://x264dev.multimedia.cx/?p=102 In particular, http://x264dev.multimedia.cx/wp-content/uploads/2009/08/quality_chart1.png No contest, Theora gets whooped. So do most h264 implementations, compared to x264 for that matter, which is probably why most companies these days are moving towards that encoder implementation.

Are you serious? http://x264dev.multimedia.cx/?p=102 In particular, http://x264dev.multimedia.cx/wp-content/uploads/2009/08/quality_chart1.png No contest, Theora gets whooped. So do most h264 implementations, compared to x264 for that matter, which is probably why most companies these days are moving towards that encoder implementation.

Flash, Google, VP8, and the future of internet video.

JPEG2000 never took off because it has problems with it's wavelet compression, details just blur out. Have a read: http://x264dev.multimedia.cx/?p=317

http://upload.wikimedia.org/wikipedia/commons/5/51/JPEG_JFIF_and_2000_Comparison.png

Good read from....

http://x264dev.multimedia.cx/?p=292

VP8 solves the compression problem: while still probably not as good as x264 (see the Addendum at the end for more details on this prediction), the gap is far smaller than with Theora, enough so that compression is far less of an issue. But it also brings up a host of new problems.

1. A few years ago, Microsoft re-released the proprietary WMV9 as the open VC-1, which they claimed to be royalty-free. Only months later, dozens of companies had come out of the woodwork claiming patents on VC-1. Within a year, a VC-1 licensing company was set up, and the “patent-free” was no more. Any assumption that VP8 is completely free of patents is likely a bit premature. Even if this does not immediately happen, many companies will not want to blindly include VP8 decoders in their software until they are confident that it isn’t infringing. Theora has been around for 6 years and there are still many companies (notably Nokia and Apple) who still refuse to include it! Of course this attitude may seem absurd, but one must understand who one is marketing to. One cannot get rid of businesspeople scared of patents by ignoring them.

2. VP8 is proprietary, and thus even if opened, would still have many of the problems of a proprietary format. There may be bugs in the format that were never uncovered because only one implementation was ever written (see RealVideo for an atrocious example of this). There will be only one implementation for quite some time; Theora has been around for 6 years now and there’s still only one encoder. Lack of competing implementations breeds complacency and stagnates progress. And given the quality of On2’s source releases in the past, I don’t have much hope for the actual source code of VP8; it will likely have to be completely rewritten to get a top-quality free software implementation.

3. It does nothing to solve the problems of hardware compatibility: most mobile devices uses ASICs for video decoding, most of which probably cannot be easily repurposed for VP8. This might be less of a problem if they’re targeting software implementations though; while it would eat more battery and be limited to mobile devices with powerful CPUs, it would not be unreasonable to play back VP8 on a fast ARM chip (see the Addendum for more on this).

The big advantage of VP8 is that it solves a problem that is unsolvable for Theora: Theora is forever crippled by its outdated technology and weak feature set. With state-of-the-art RD and psy optimization, as in x264, Theora can likely become competitive with Xvid or even maybe WMV9, but probably not x264. The only way to fix this would be a “Theora 2, and attempting to ensure Theora’s “patent-free” status while adding new features would be extraordinarily difficult in today’s software patent environment. VP8, on the other hand, offers an immediate jump to what is hopefully an H.264-comparable level of compression.

But now for the big question: why would Google want to open VP8, and if they did, how would they do it? Google probably doesn’t pay a cent in license fees for Youtube; H.264 is free until at least 2016 for internet distribution and encoder fees only apply if you have more than 100,000 encoding servers. The cost of the license fees for Chrome are minimal (a few million dollars a year, capped). But despite that, there are actually some very good reasons.

1. Control. Google may view the control of other companies over H.264 as a threat: even though H.264 is licensed under RAND terms (Reasonable and Non-Discriminatory, they legally cannot be anti-competitive), there are many reasons for Google to want more control. If they push VP8, they not only compete with Flash via HTML5, but they also prevent Flash from playing their video streams. As it is unlikely (for the reasons mentioned at the start of the article) that Adobe will im

http://x264dev.multimedia.cx/?p=292 list some missing feature a html5 :
- buffering control
- signalling back to server
- Quality of implementations