OSNews

I agree and from what ive read about vp8 "it was designed with arm in mind" "On2 cooperated closely with chip maker ARM on the development of VP8" I'm confused after reading that google will fund ogg/theora/vp3 on the ARM platform whats the point when vp8 is technically superior and already has these features?

Edited 2010-04-13 18:45 UTC

Maybe Google is looking to merge Theora with VP8? Who knows? Since Xiph hasn't been unsuccessful with VP3, maybe they could do wonders with a more modern codec backed by Google and an ironclad patent pledge.

being that theora is based on an earlier codec from on2. google could just drop the code and then theora would be better than h.264 overnight.

VP8 is not the same codec as VP3. If Google were to open source VP8, implementations of it would not be called Theora, but something else.

Google is just funding everything, so whatever happens they will be covered. Look at Chrome: they're improving Flash support and promoting HTML5 at the same time.

Because there are already integer based decoders for both vorbis and theora. i.e. no floating point co-processor is needed to decode them.

Not sure if such a thing exists yet for VP8...

Ars uses the same source.

I can't vouch in any way if their sources are reliable, but I've read NewTeeVee on and off over several years, so at least they're not just some overnight rumour mill.

Goodwill, independence, control over the technical course of a ubiquitous codec. Google needs an open web to serve as many ads as they can. They probably have their reasons if they do what the rumor says.

That's why I asked. It's a rumor until someone from Google says otherwise.

Thats why I gave some reasons they might open source it. It might be worth more open than closed.

So why have they moved closer to Flash in the past few years?

Because in the last years there was no alternative?
Google has to do something, to not loose or simply take market share.

Google definatly has the resources to do this and even smaller companies, like Sun has given a lot of stuff away. Mostly their own, but they still had to pay a lot for development. Oh and open sourcing doesn't really mean giving it away. If Google wants to HTML5 video tags they invest into it and that's what they do, if the rumour is true. Also the Firefox stuff could be true, because Firefox is open source and why not develop something for them so they are more likely to include it (soon)?

However it's just a rumour and we don't know what Google wants, but it wouldn't be the first time they invest into open source

Last, but not least: Would the investment make any sense, if they don't use it or what do you think they are going to use VP8 for?

Edited 2010-04-14 11:06 UTC

So why have they moved closer to Flash in the past few years?

One word? Ubiquity.

Realization: Maybe I should have not used the word open. I should have used low barriers for access.

Edited 2010-04-14 11:11 UTC

First of all, YouTube was always Flash-based, because at the time there was no alternative with the same installed base.

As for their recent decision to bundle Flash with Chrome: the way I see it, Flash is one of the keys to their strategy. If they can get Flash support for VP8, it will be a whole lot easier getting VP8 universally accepted.

Also note that Adobe can only gain by the decision to support VP8. They don't want to be rendered hopelessly irrelevant when H.264 ceases to be the preferred format.

Edited 2010-04-14 18:31 UTC

It benefits them in the long run to not have to use theora on youtube.

Wow, 6 thumbs up for a link to a site that has already been cited 54 times prior on OSNews alone?

http://www.google.com/search?hl=en&q=site%3Awww.osnews.com+http...

Edited 2010-04-13 21:13 UTC

The Interwebs has no memory. This stuff needs to be re-explained in every thread.

many thanks for sharing this link. though I don't understand all the details in video, encoding etc. Still its an excellent article.

as for Google opening up VP8 (still a rumour), it will only benefit all (including Google) I hope and Theora too.

That is a good read. So apparently two big problems with the codec that Google is going to open source is that it's proprietary and they charge fees? I think those problems may well be cleared up quite quickly. I think they have the resources to fix encoder bugs too.

On the quality front, he's basically admitting VP8 is going to beat H.264 which I was skeptical of at first, since the main source for that claim was On2 themselves. Coming from a competitor that's a pretty good review.

Apparently if you take every large computer media company (Adobe, Apple etc.) and a bunch of commercial encoder specialists (e.g. Mainconcept) all competing in the marketplace, working on an ISO spec, chock-full of 900 patents and you put them up against a single beleaguered, also-ran, proprietary codec producer then they will all be beaten (Apple and Adobe) or "nearly" matched (Mainconcept). And that's despite the encoder not (yet) being tuned for psycho-visual optimizations?

And assuming it's BSD-licensed they can just adopt it into their products as-is, for free.

Isn't that worrying for H.264 fans?

Edited 2010-04-14 11:00 UTC

Isn't that worrying for H.264 fans?

I'd say very, very worrying. Judging by the monumental backlash against even suggesting "ancient" VP3 Theora as an alternative, VP8 is probably akin a nuclear strike.

If VP3 or VP8 was completely ridiculous as an alternative, H.264 proponents would have laughed very heartily, whished the VP3/VP8 crowd good luck and then turned away to silently work on progressing the roll-out of the H.264 infrastructure. They didn't. They brought pitchforks and torches and started screaming "The Pixels! The Pixels!".

In my book that speaks to the merits of the alternative most of the time.

He isn't basically admitting anything. He said that the early H.264 encoders were crap. However, now that they have matured (especially x264), the file size improvements that were to be gained from using VP8 aren't there anymore. You should re-read the Addendum.

No, he says VP7 beat all early H.264 encoders ("dramatically better" than most of them) in the first half of the decade. That much is plainly stated and based on something like fact rather than supposition.

"VP7 was released in ~2003, around the same time as H.264. It made waves due to being dramatically better than practically all H.264 encoders at the time"

He also makes a prediction:

"Overall, I expect VP8 to be surely better than MPEG-4 ASP (Xvid/DivX) and WMV9/VC-1. It will likely be nearly as good as Mainconcept’s H.264 encoder (one of the best non-x264 encoders)"

and earlier on:

"Adobe’s H.264 encoder in Flash Media Encoder is so utterly awful that it is far worse than ffmpeg’s H.263 or Theora;"

And he's said similar things about Apple's H.264 encoder so I think you'd agree given those statements together that he's saying VP8 is going to beat Apple and Adobe's H.264 encoders, probably by a fair margin.

So it's nearly as good as Mainsoft and not too close to x264 "assuming they still believe that blurring out the entire image is a good idea" (this means tuning for PSNR, and not using psy-optimisations that hurt PSNR but help subjective quality).

So if they dump out what they've got now it's nearly matching the best of the H.264 encoders that don't employ psy-optimisation. What happens if they fix that by changing the encoder? It's caused major gains for both x264 and Theora, all without tweaking the decoders or the specs. If that's what makes the difference between x264 and all of its competitors, why can't a similar magnitude of improvement happen for VP8?

Why doesn't he even consider the potential of this happening given his conclusion:
"If there’s anything to take away from this, it’s that psy optimizations are the single most critical feature of a modern video encoder."

I hope Google (or whoever) look into using these methods to tune their VP8 encoders, but even without them, VP8 is (in the words of a developer of a rival codec) nearly toe-to-toe with the best out of a big field of encoders that companies like Adobe or Apple could embed into their proprietary software.

I'd say its future is looking surprisingly rosy.

Edited 2010-04-14 12:44 UTC

From the original article, Google are said to be almost "partnering" with Mozilla in the venture.

Mozilla is the party who funded Xiph to optimise Theora:
http://blog.mozilla.com/blog/2009/01/26/in-support-of-open-video/
http://arstechnica.com/open-source/news/2009/01/mozilla-contributes...

AFAIK there is no reason why the essential principles of optimisations used at Xiph (funded by Mozilla) to improve Theora (based on VP3) couldn't also be applied to On2's VP8.

If Google are prepared to open VP8, and indeed are partnered by Mozilla in this venture, then it is surely in Mozilla's best interest to contribute these same principles of optimisation to VP8.

Yes, I said early H.264 encoders. Using the term 'first half of the decade' makes it sound as though the decoders are a decade old. Both specs are ~7 years old, so the first half of the decade is less than 2 years of encoder development for H.264. Anyways, did you read his account on why the quality was low?


The x264 developer said he expects VP8 to be better than MPEG-4/Xvid, and probably better than an H.264 encoder that was


Thus explaining why most web companies use x264 for encoding and not other products/projects. The quality of Mainconcept's encoder will not matter if few websites (if any) use it. The comparison is between a Google/On2's VP8 encoder and x264. However, if VP8 is a simplified VP7 (for software/mobile decoders), then I don't expect any of the initially touted benefits (1/2 of H.264 file size).

Edited 2010-04-14 13:26 UTC

So VP7 beat all the H.264 implementations in 2003 because one had been worked on for years, and the others for months. That sounds plausible.

Yet here we are 7 years(!) later and according to an x264 developer there's still one single H.264 encoder implementation (out of how many?) that can convincingly beat the *only* existing VP8 codebase (and VP8 is after all only a simplified VP7).

And that conclusion is provisional on the fact that this single implementation has not adopted the psy techniques that he himself has blogged frequently about, has said is a big factor in the difference between his encoder and other H.264 implementations, and which Theora have adopted in their version of VP3 with large improvements shown. Encoder changes which require little more than them paying attention to what the two highest profile competitors are doing and copying it? No spec breaks, no decoder revisions, no new hardware chips, no ninja-level coding skills.

Is it just me or is that a good review? I know you only want to talk about a single, GPL'd encoder because you think that is the (only) one that shows the true potential of H.264. Why not consider the true potential of VP8 and what it could become when opened up, it certainly seems like it will be good enough, right now, to get the benefit of the doubt.

BTW, I don't know where the 1/2 H.264 bitrate claim comes from, but since there's probably at least two H.264 implementations that could claim that against a carefully chosen list of H.264 competitors, I don't see it being that wild a claim as long as properly qualified. Certainly it could apply if Adobe or Apple include this code in their products, or your average screencasting or video-chat application etc. Not everything revolves around encodes done on servers or by free software enthusiasts.

Edited 2010-04-14 14:43 UTC

Since most H.264 discussions that I've seen so far at Osnews have revolved around HTML5, I'm not going to look at other uses for H.264. The article implies that other companies aren't spending the money required to compete with a free product (x264).

It was a good review ... that is 7 weeks old. It provided insight into the reasons why Flash (and H.264) won't die anytime soon when it comes to web video. VP8 may have potential, but until I see something tangible (e.g. benefits on YouTube), I'm holding off judgement.

I remember reading the 1/2-size somewhere. Can't find it now, but I think it was made when x264 encoders were immature.

It's not pretty much the only one. That's also Microsoft who makes the most used browser - Internet Explorer. Youtube maybe the most viewed video sharing site but IE is 60% of web browsing.

If IE doesn't support youtube, people will switch browsers. youtube + facebook = the internet for most of the people who use it.

YouTube would support IE. All it would require is a plugin for IE. After all, the existing Flash video for YouTube already requires a plugin, so what is the difference from an IE users point of view?

If Google were to switch YouTube to HTML5/VP8, they could do it as soon as they own VP8 if they wanted.

They would have the VP8 codec, they would have the CPU power to run conversions, and they would have a suitable plugin all ready to roll: Google Chrome Frame would do it.

The speculation is that Google and Mozilla would co-operate with this, and both browsers would support HTML5/VP8 as soon as this is announced.

That they have the CPU power to run the conversion is pure speculation.
Youtube now has so much content it is insane. Just do a search for "Guido" and be amazed at how much crap is on YT. Millions and millions of videos. Petabytes and I don't know if Google has the idle CPU power to convert it all in a reasonable time frame.
I guess they would have to have both h264 and VP8 for a long time and only store new videos in VP8 and use idle CPU time to convert. But that is a major task and very costly. It would make sense to wait a few years for CPUs and encoders to improve.

openvideo.dailymotion.com have converted 300,000+ videos to Theora.

http://blog.laptop.org/2009/05/27/dailymotion-supports-open-video/

Google platform:
http://en.wikipedia.org/wiki/Google_platform




100 video conversions for each server would take perhaps an hour (could do this easily if there is GPU assistance), and convert 45 billion video clips in that time.

Edited 2010-04-14 05:25 UTC

Google servers have no GPU. YT has around X00.000.000 videos in different sizes, so my guess that they are approaching the billion soonish or have crossed that already. h264 has to decoded and VP8 encoded. Decoders are fast now, but VP8 encoders are probably still very immature atm.

And it is not like Google can stop all operation to do a conversion. It is quite save to assume that Googles servers are running pretty maxed out most of the time.

And 450.000 x 100 is 45 billion? .. OK

Edit: I would guess that if they wanted to convert they would first write a special encoder that takes the best quality h264 and then en-/transcodes that into VP8 in different VP8 sizes. If Google could use the computation that is already in h264 that would speed up things a lot. But such a special encoder has to be written first.

As I said, this is a multi-year process because of many factors, everybody who thinks otherwise is delusional IMO.

Edited 2010-04-14 06:10 UTC

450,000 x 100 = 45,000,000 45 million. Oops, sorry.

That is for 100 conversions per hour per server, a little less than two a minute, or a background task, if you will.

To get to convert 45 billion video clips in the background, it would take 1000 hours (if 450,000 servers is accurate). Unlike people, servers run for 24 hours a day, so we are talking, what, 45 days?

A billion video clips per day? Seriously, it won't take all that long, given the compute grunt that Google has.

PS: Google bought On2, and On2 have the VP8 codec source code. So Google has the codec source code, the rights (copyrights and patents) to it, it has the major video hosting site on the web, it has a huge audience for that site, it has the video clips, it has the compute power to convert them, it apparently has a partner in Mozilla, and it has a huge self-interest in not being dependent on the whims of MPEG LA for permission to run a vital part of its business.

Google will not succeed in freeing themselves from being beholden to MPEG LA unless they open source VP8, join with Mozilla, put an open VP8 decoder in Google Chrome, Firefox and Google Chrome Frame (and probably Opera as well), and host VP8 videos on Youtube.

It is all do-able.

Why wouldn't Google do it?

Edited 2010-04-14 07:04 UTC

Apparently that can be done by using multiple "source" elements inside the "video" element. (See near the bottom of http://diveintohtml5.org/video.html)

A fair amount of mobile hardware (phones) have short lives. The fact that there is dedicated hardware in these devices isn't as constraining as one would first think.

If one simply uses a more general-purpose GPU, the video/graphics hardware can be programmed for any codec via languages such as GLSL and GPGPU. Hardware as low-spec as netbooks, smartbooks, internet tablets and "pads" all support a general-purpose GPU.

Apparently GPU shaders are terrible at video decoding; that's why we have PureVideo and such. Unfortunately, neither approach is helpful with a new codec.

Source?

GPU shaders are possibly not efficient at decoding H.264/avc, which is very complex and demanding of computational grunt, but Theora at least is considerably easier, and possibly the same is true of VP8.

My source for backup:
http://en.wikipedia.org/wiki/Theora#Playback_performance


By metioning only dedicated decoder chips and very low resource devices (iPods and similar devices with limited computing power), this text actually avoids mentioning the possibility of a GLSL or GPGPU based decoder in any device with a little more resources (i.e. a GPU), such as netbooks, smartbooks, tablets and "pads".

However, the text does mention that Theora is less demanding of resources to decode, and it also says that for small screen resolutions (i.e. iPods and similar devices with limited computing power), dedicated decoing hardware may not be necessary at all.

There are a bunch of different steps to video decoding, and they all run with varying levels of suitability on shaders. Parts can't be run on shaders at all, others run mediocre, and some run very well.

In practice, the first type end up getting run on the CPU while the rest run in shaders, and it ends up being a lot better than running everything on the CPU. But there's still a significant bit there that can't be shoved over to the GPU, and the general purpose shaders tend to be a lot more power hungry than a small fixed function video decoder, which makes the specialized hardware very nice to have.

Read again. That doesn't say anything about GPU.

And as smitty said, there's stuff you just can't do practically on shaders. Basically the idea with GPGPU is that you have loads and loads of threads. If you can't multi-thread some part of the decoder by massive amounts, it gets VERY slow. For one, I've never heard of any video format use an entropy coding that would run well on shaders. Of course I could be wrong here. (There might be dedicated hardware for some entropy coding on modern GPUs, but that's another story and depends on the video format.)

True, but all GPUs have either PureVideo or AVIVO.

As I said, PureVideo and AVIVO don't help you with a new codec like VP8. So if you can't decode VP8 with PureVideo and you can't decode it with shaders, then you're going to be stuck using the CPU.

You mean DirectCompute, CUDA or OpenCL. GLSHL is a shader language and GPGPU is just the concept of using GPU for doing computations.

We don't need those because we already have DXVA, VDPAU and XvBA - a set of APIs that allows hardware to do video decoding.

You mean DirectCompute, CUDA or OpenCL. GLSHL is a shader language and GPGPU is just the concept of using GPU for doing computations. We don't need those because we already have DXVA, VDPAU and XvBA - a set of APIs that allows hardware to do video decoding. "

The hardware decoding within GPUs that is accessed via DXVA, VDPAU and XvBA is limited to specific codec(s), and encumbered by DRM. This is the antithesis of what is required for the open access web. It is a requirement that web standards be at least royalty-free for anyone to use and implement, if not patent free.

Therefore, for web video decoding, graphics hardware support (at least for existing video cards) will have to be added via either GLSL or GPGPU.

http://en.wikipedia.org/wiki/GLSL
http://en.wikipedia.org/wiki/Gpgpu

The only viable candidate codec at this time is Theora, but this very thread is speculation that this may soon change, and Google may also make VP8 a viable alternative candidate meeting the requirements.

The applications for GPGPU are listed here:
http://en.wikipedia.org/wiki/Gpgpu#Applications
They include the following:


My bold.

Note that GPGPU can be applied to accelerate both the decoding and the encoding processes.

PS: AFAIK, CAVLC/CABAC are used only by H264.AVC.

PPS: AFAIK, there is already a GPU shader Theora decoder written in GLSL as a Google SoC project.

Edited 2010-04-14 02:57 UTC

How can you even misunderstand your own source you linked couple of posts earlier?

From:
http://en.wikipedia.org/wiki/Theora#Playback_performance
"There is an open source VHDL code base for a hardware Theora decoder in development.[54] It began as a 2006 Google Summer of Code project, and it has been developed on both the Nios II and LEON processors."

That has nothing to do with GLSL.

How can you even misunderstand your own source you linked couple of posts earlier? From: http://en.wikipedia.org/wiki/Theora#Playback_performance "There is an open source VHDL code base for a hardware Theora decoder in development.[54] It began as a 2006 Google Summer of Code project, and it has been developed on both the Nios II and LEON processors." That has nothing to do with GLSL. "

Agreed. AFAIK there is a GPU shader Theora decoder written in GLSL as one Google SoC project, and there is also an open source VHDL code base for a hardware Theora decoder in development.

The hardware design is called leon3:
http://people.xiph.org/~j/bzr/theora-fpga/leon3/

The GLSL (GPU shader based design), which AFAIK was also a GSoC project, has absolutely nothing to do with the leon3 VHDL hardware decoder design. They are entirely different things.

You are quite correct.

Which could be as late as 2022
http://www.zdnetasia.com/html-5-may-not-be-finalized-before-2022-62...

The thing with the w3c is that its not a standards body, its a consortium of companies with competing interests, so it moves even SLOWER then a standards body. It usually takes about 15-20 years for them to get a recommendation out the door.

That being said, browser support tends to happen WAY before that, and once there is support from most of the vendors, devs start using it.

Then why let w3c decide how HTML 5 will be like? Why not ISO?

ISO ratifies specifications, you still need the commitee to come up with the specification. Submitting to ISO would be great, cause then we would have standards, not just consortium recommendations, but the real problem is actually building the spec. And the problem there is the amount of conflicting interests involved. There are a lot of politics, and a lot of sabotaging going on.

Now, you could say "Why not get a neutral third party to make the spec, submit it to ISO, and don't let the vendors be part of the process at all?" That would be great, but historically, even WITH the vendors having a say, it is still really hard to get them to all implement things the same way. And that aside, the people who decide the way things are done and who is listened to is the vendors, and they like it this way.

Assuming you're not just trolling with that regularly debunked talking point, the HTML5 spec will be published in the next year or so. The 2022 date is when they expect two independent implementations to cover the whole spec interoperably.

That may seem a long time, but it's a lot nearer than never, which is when that's going to happen for HTML 4.

So a spec is not a recommendation. They build out the spec, then they build out tests, then they argue about tests, then they wait for at least to implementers to agree with the tests, and pass them.

CSS 2.1 took about a decade to go from spec to a recommendation.

It is not required for Apple and Microsoft to implement vp8. All that would be needed is for Youtube to implement VP8, and for YouTube to provide a link to install a plugin for HTML5/VP8 video for IE users.

Apple can go jump.

Edited 2010-04-14 00:16 UTC

But they would still need to have h264 available for the iPhone, iPad & Windows Phone 7, Windows Mobile 6 and Kin phones & Nokia phones and phones from other companies. Almost all of these smart phones can already play h.264. Before they can switch completely, they would need to convince a lot of companies.

Also, remember, all these companies have already paid the fees for h.264. Moving to something new isn't going to save them any money, and none of these companies are going to do extra work unless it benefits them somehow.

Edited 2010-04-14 15:55 UTC

That's my take too. They are defending against MPEG LA's "monopoly" over HD codecs and keep their VP8 codec as a trump card.

Flash is included with Chrome so that it can be updated silently (like Chrome itself) and to improve the user experience. I applaud that. You can always download the version without Flash included if you so desire.

If they were serious about open source codecs they would have had a plan to dump Flash from the moment they purchased YouTube.

However Google has moved closer to Flash since their purchase and they also clearly support H.264.

If Google convinces Adobe to support VP8 in Flash then it's game over, within a year VP8 support will be over 100% (meaning many users will be able to receive it natively in HTML5, via Flash, via Silverlight pluggable codecs, via Java, via Chrome Frame plugin etc.)

You might think this sounds crazy but Adobe Flash already supports VP6 and had an licence option on using VP7. It also seemed a bit crazy to me that Adobe started supporting H.264 and didn't even force you to put it in their FLV container and instead let you use the exact same file that you can serve to HTML5 or let people download.

What difference is there to supporting a royalty bearing standard that's included in all new desktops and phones, and supporting a royalty-free codec with the weight of Google behind it, from Adobe's point of view. Either way they've not got lock-in via the codec itself, but this makes them more useful for real world deployments.

They'll also get a viable BSD-encoder for free, where currently Adobe's H.264 encoder is a joke and so Adobe is only part of the workflow.

Game over for who? Flash? What makes you think content providers want to distribute a pure video format? Ever notice the ads on Flash videos? Hulu has already stated that they aren't interested in HTML5 because there is no content protection.

I'm all for HTML5 video but I also know that major media providers use Flash for more reasons than video.

Google however could end Flash dominance by requiring an alternative plugin for YouTube but that plugin would have to be technically superior to Flash and not just in video quality but also in functionality that sites like Hulu require. Otherwise the other major sites would just stick with Flash.

If anything they will open source VP8 as a way of seeding an alternative and to appease critics. If they really cared about open source codecs then they would not have been so adamant about using H.264 in HTML5.

Why not allow Theora to be the default codec in HTML5 since it doesn't prevent sites like Hulu from using plugins with any codec that they want? Especially since Flash is already a de facto standard and uses H.264. This is the question that Theora advocates need to ask Google.

Google haven't been adamant about using H.264 in HTML5. Google's initial YouTube experiments with HTML5 have used H.264 becuase that was what YouTube has, but this is only an experiment. A trial run. Google have said a number of times that this experiment does not mean that they will necessarily use h.264 with HTML5 ongoing, or even that they will use HTML5 at all.



What makes you think web video "content providers" are one and the same as "big media"?

The majority of web video is contributed by individuals, who have no interest at all in DRM. A lot of this video is taken by digital cameras or smartphones belonging to said individuals. Individuals cannot afford h.264 licenses, for what amounts to a hobby.

http://videoonwikipedia.org/

http://openvideoalliance.org/


Edited 2010-04-15 03:15 UTC

You seem to have missed my point.

Flash doesn't "do H.264", it does H.263, VP6 & H.264. It could very easily start doing VP8, either because Google asked (or paid) them to do so, or just because it suddenly becomes popular and customers demand it.

So all the benefits of Flash that you outline could be combined with the benefits of a "pure" video codec like VP8.

I think this would mostly be a good thing for Adobe, but big business decision making is weird. Maybe they think they need to "focus" and bet the farm on H.264. Maybe they'll consider it a way to hit back at Apple. Either way I guess we'll find out in due time.

(And if they do support VP8 it will be "game over" in regards to the question: what is the best codec for the web?)

Edited 2010-04-15 10:44 UTC

Also, funny that you should mention Hulu, as they currently use On2 VP6 delivered via Flash. From their FAQ:

http://www.hulu.com/about/media_faq

What is the quality at which videos will be streamed on Hulu?
Hulu videos are streamed as Flash video files (FLV files). These files are encoded using the On2 Flash VP6 codec that is supported on Flash Player 8.0 and above (which is installed on more than 98% of computers in the U.S.).

Hulu currently supports four different streams including 480kbps, 700kbps, 1,000kbps (an H.264 encode that is not on On2 VP6) and 2.5Mbps.

Edited 2010-04-15 15:15 UTC

chrome has ogg and theora support already... what the issue is, is that theora isn't good enough for youtube, and VP8 is one of the best codecs out there.

I don't know... I prefer the ON2 blurry version, personally. Encoding artifacts look cheap, to me they look like stretched bitmaps, low-res images pretending they got high-res just because they were scaled up. Blur has a somewhat more honest feeling : it removes the incoherent and poor information, only the real information remains.

It's the same as MP3 : low bitrate sounds fine until I hear that horrible garbled background noise or some cymbals looking like they went through a blender. In noisy environments, I simply can't make a difference between mp3 64k and MP3 128k using modern encoders, because environment noise won't allow me to perceive that audio horror, and the rest is fine.

But as you said, it's a matter of perception. Maybe some people prefer not to have the background noise cut in MP3s... I prefer having the audio/video equivalent of a sketch : keep the useful info, throw the rest out through the windows. Isn't it the whole point of audio/video compression ?

Edited 2010-04-14 16:47 UTC

In fact, I prefer blur myself too, but it could be because I have seen so much video artifacts they immediately shout "LOW QUALITY!" at me.
People who really matter, the end-users, might be different. Not to mention loads of video encoding people who have said they prefer the non-blurred one.

But I wouldn't go as far as saying only displaying real information matters. For example, take movie grain. It's just noise and if the encoder is smart enough to "remix" that noise by making something that looks very similar, but is a lot easier to compress, it's all good, even though the "real" information is lost.

Same goes for lots of noisy textures that are seen on high resolution videos. It's a lot better to make a high-frequency texture into something that kind of looks similar than to blur it out altogether even if it would give better PSNR, this is why psy opts are turned off for metrics tests.

For example, look at the trees in the On2 video. (And btw, I don't think x264 should keyframe-pulsate like that normally...)


Speaking of MP3, psy opts are the reason Vorbis beat MP3.

Edited 2010-04-14 17:10 UTC

That's right. Remixing artifacts into grain-like noise would certainly lead to much better-looking videos that blurring them along with part of the underlying details that somehow managed to survive the low-quality encoding.
Another option I'd like to see is improving level of detail in regions of high interest at the expense of completely destroying regions of low interest that I don't care about. I think that modern codecs already try to do this to some extent, but I'm a codec customer, not a codec specialist, so I can't tell . Is it what you call psy opts ?


Actually, even DivX doesn't do that anymore at usual bitrates, last time I down... err... checked some divx movies that I encoded myself from the original DVD.


Well, don't remember ever managing to make poor-quality vorbis files, but I've been using FLAC for too much time to tell. Why use lossy compression in portable music players when you have a small collection of music like me and an insanely large storage space in modern music players ?

Edited 2010-04-14 20:21 UTC

That may very well be the case. Adoption of alternative video formats (like VP8/Theora) won't increase until they are supported by Flash.

Edited 2010-04-14 22:23 UTC

And wouldn't that be a nice reward when you think about their relation with Google and Adobe?