Google Opens Up VP8, Launches New Container Format

[smitty3268]

I'm sure the x264 dev is a very talented coder and knows what he's talking about and they do make a wonderful encoder. But still he's an x264 dev, and for me at least there's still the appearance of bias. So I wouldn't take his word as gold on this subject, but rather see an independent analysis of the quality.

Not that it matters though. Google and its partners are probably powerful enough to push this trough, whether you like it or not.

Yeah, I don't think he's purposely trying to shoot down VP8 or anything, but just the fact that he knows his x264 so well and has spent so much time on it is likely to give him a little bit of an unconscious bias.

Anyone who thought VP8 was going to outperform h264 was misled, anyway. That was never realistic. The point was to get something good enough for actual use on the web. The fact that Hulu, for example, already uses VP6 at certain resolutions makes the old "everything besides h264 isn't good enough" argument bunk. If VP8 can just outperform h264 baseline, (and it appears it probably can), then that's good enough for the web. h264 is more important for things like blu-ray where absolute quality matters so much more.

It sounds to me like a lot of the oddities that x264 developer pointed out are probably left out for patent reasons. Someone commented there that it's probably better for On2 to base their work on h264 so they know exactly which patents apply, and then they can work around them one by one by small changes that invalidate each of them. Doing something a little more original, ironically, would leave them more open to submarine patent threats.

[Ex-Cyber]

Was there a reason to rename mkv?

They're not just renaming it, but constraining the spec and giving that subset a new name. The idea apparently is to ensure that if someone (or some piece of software) encounters a WebM file, that immediately implies not just the container format, but also the audio and video codecs. That is, there shouldn't be any such thing as partial or conditional support for WebM files - either you support it or you don't, and if you support it, all WebM files work (given the somewhat fantastic assumption that the spec is 100% complete and unambiguous, but any such issues will probably be worked out among implementers in time). In principle I'm not thrilled with the idea of Yet Another Media Container, but I can see where they're coming from in a practical sense of wanting to get implementers, service providers, and users to sign on. Considering that the whole effort is largely a compromise to begin with, what's one more compromise?

[liam]

Mostly fantastic.

As has already been said, Vorbis/MKV is a great combo. VP8, well, I didn't read the x264 dev post past "VP8 doesn't support B-frames". That is crazy! B-frames, while not always applicable, can be very bandwidth friendly.

[MaestroMaus]

I have only one thing to say: Thanks Google!

[BlackStar]

As has already been said, Vorbis/MKV is a great combo. VP8, well, I didn't read the x264 dev post past "VP8 doesn't support B-frames". That is crazy! B-frames, while not always applicable, can be very bandwidth friendly.

Not to mention patented to hell and back.

[V!NCENT]

The astroturfing had already began yesterday on /. when it wasn't in Phoronix yet. Be cautious of the harch FUD and outright lies.

Microsoft had also joined the WebM pack as they must be hating h.264.

Now it is up to Apple to respond. The battle between WebM and h.264 is going to be fierce!

Hardware accel for V8 is already underway. Mpeg4 and Flash are in some for some extreme competition from HTML5 and WebM.

Some heads are going to roll for sure...

[yotambien]

I believe Phoronix reported it earlier than Slashdot?

Anyway, and unsurprisingly, Greg Maxwell doesn't read the article from DS about WebM under the same light:

This is pretty far off topic, but letting fud sit around is never a good idea.

On Thu, May 20, 2010 at 2:08 AM, Hay (Husky) <huskyr at gmail.com> wrote:
> http://x264dev.multimedia.cx/?p=377
>
> Apparently the codec itself isn't as good as H264, and patent problems
> are still likely. It's better than Theora though.

You should have seen what VP3 was like when it was handed over to
Xiph.Org. The software was horribly buggy, slow, and the quality was
fairly poor (at least compared to the current status).

Jason's comparison isn't unfair but you need to understand it for what
it is? he's comparing a very raw, hardly out of development, set of
tools to his own project? which is the most sophisticated and mature
video encoder in existence. x264 contains a multitude of pure encoder
side techniques which can substantially improve quality and which
could be equally applied to VP8. For an example of the kinds of pure
encoder side improvements available, take a look at the most recent
improvements to Theora:

http://people.xiph.org/~xiphmont/demo/theora/demo9.html

Even given that, VP8's performance compared to _baseline profile_
H.264 is good. Jason describes it as "relatively close to x264?s
Baseline Profile". Baseline profile H.264 is all you can use on the
if you actually want to be compatible with a great many devices,
including the iphone.

There are half research codecs that encode and decode at minutes per
frame and simply blow away all of this stuff. VP8 is more
computationally complex than Theora, but roughly comparable to H.264
baseline. And it compares pretty favourably with H.264 baseline, even
without an encoder that doesn't suck. This is all pretty good news.

On the patent part? Simply being similar to something doesn't imply
patent infringement, Jason is talking out of his rear on that point.
He has no particular expertise with patents, and even fairly little
knowledge of the specific H.264 patents as his project ignores them
entirely. Codec patents are, in general, excruciatingly specific ? it
makes passing the examination much easier and doesn't at all reduce
the patent's ability to cover the intended format because the format
mandates the exact behaviour. This usually makes them easy to avoid.
It's easy to say that VP8 has increased patent exposure compared to
Theora simply by virtue of its extreme newness (while Theora is old
enough to itself be prior art against most of the H.264 pool), but
I'd expect any problems to be in areas _unlike_ H.264 because the
similar areas would have received the most intense scrutiny. ... and
in any case, Google is putting their billion dollar butt on the line?
litigation involving inducement to infringe on top of their own
violation could be enormous in the extreme.

Now, has anybody tried it? I haven't had much success with those Opera or Firefox builds, I always get the Flash version of the videos in youtube.

[monraaf]

Now, has anybody tried it? I haven't had much success with those Opera or Firefox builds, I always get the Flash version of the videos in youtube.

Works fine here with chromium. But it's a bit cumbersome. First you have to go here to enter the HTML5 beta:

http://www.youtube.com/html5

And then you have to append &webm=1 to your search queries.

e.g. http://www.youtube.com/results?search_query=foo&webm=1

IMO quality is just as good/bad as flash. The main thing missing from the player is an option to go full screen.

[yotambien]

Thanks, although I finally found some content to try. For some reason following the steps detailed in the project website doesn't work here.

This is the page I found with a webm video, just in case somebody had the same problems. You can watch it in full-screen.

http://lachy.id.au/log/2010/05/webm

Also, it did only work with the Firefox developer build, the Opera one didn't seem to open it properly. Didn't try Chrome.

Yes, it's very CPU intensive, I hope people start hacking on the implementation to improve it. There are some obvious artifacts, but this means nothing unless compared to another encoding with the same target size.

[monraaf]

Also, it did only work with the Firefox developer build, the Opera one didn't seem to open it properly. Didn't try Chrome.

Yes, it's very CPU intensive,

The Firefox build was also very CPU intensive here. You should try chromium, it's much easier on the CPU.

http://build.chromium.org/buildbot/snapshots/