WebM Exciting New Video Standard with VP8, Vorbis, Matroska

[weasel_]

One maybe stupid question ?
Why VCL for example don`t need to pay roaylity to MPEG-LA and Mozila must ?

[Dark Shikari]

One maybe stupid question ?
Why VCL for example don`t need to pay roaylity to MPEG-LA and Mozila must ?You mean VLC? VLC is based in France, where software patents don't apply (according to EU law).

At least, that's the opinion of Videolan's lawyer, and they've done fine with it for 400 million downloads ;)

[weasel_]

Yes Typo

Tnx DS ;)

[Miraelsol]

Indeed. People who are heavily invested in a particular side of any debate will always twist facts to their advantage. The proper solution is not to complain about the facts being out there, but rather to blame the people doing the twisting.

Merely getting rid of my blog post won't make Steve Jobs like VP8.

I would regard DS as somebody who is "heavily invested in a particular side" of this debate. And he certainly seems to see his as a side.
DS technical evaluation may be ok. Though 'technical', in the context of computer science has no resemblance with its meaning when used in hard sciences. The scope for subjectivity is large. But the comments about patents are a pure FUD excercise.
But for facts this: "WebM is a stupid name"

[Dark Shikari]

But the comments about patents are a pure FUD excercise. So you're saying we should take everything that Google says without any questioning -- that everything they release is free of patents without any proof whatsoever?

Google provided no indemnification. Unlike Sun, they provided no proof. Unlike Xiph, they published no results of any legal investigation. There is absolutely no evidence that anything they said is true. And yet people still insist that they are always right because they are Google.

And now even suggesting they are wrong is FUD.

"It's patent-free" is an extraordinary claim: most multimedia formats are not, and it is well-known that making one is hard. Therefore, I expect evidence to demonstrate that this is in fact the case. In the lack of evidence, I'm going to speculate that it might not be the case.

This is becoming almost as bad as Apple fanboys; people cannot seem to comprehend that the company they love might have made a mistake.

[MfA]

Extra-ordinary claims require extra-ordinary evidence ... but that doesn't mean ordinary claims don't require ordinary evidence. You have provided only circumstantial evidence ... if it were impossible to get anything better I'd say okay, but it isn't ... you can look at the patents ... you can look at the development process of H.26L and see exactly when each feature was introduced.

So when you say intra prediction is close, so it's probably infringing I say that is lazy reasoning and you can do better.

Honestly now, which fact do you think is more relevant to the infringement of VP8 :

- VP8's intra prediction is very similar to H.264

- MVC's intra prediction is very similar to H.264 and MVC's disclosure predates the priority date on all the intra prediction patents by more than a year.

[Dark Shikari]

Extra-ordinary claims require extra-ordinary evidence ... but that doesn't mean ordinary claims don't require ordinary evidence. You have provided only circumstantial evidence ... if it were impossible to get anything better I'd say okay, but it isn't ... you can look at the patents ... you can look at the development process of H.26L and see exactly when each feature was introduced.

So when you say intra prediction is close, so it's probably infringing I say that is lazy reasoning and you can do better.

Honestly now, which fact do you think is more relevant to the infringement of VP8 :

- VP8's intra prediction is very similar to H.264

- MVC's intra prediction is very similar to H.264 and MVC's disclosure predates the priority date on all the intra prediction patents by more than a year.Both are relevant. One is a potential risk factor and one is a mitigating factor. How much each matters is up to lawyers to decide. But that doesn't change the fact that a risk factor does exist and thus we'd like to know Google's justification that such a factor isn't actually a risk.

Keep in mind that the patent system in the US is completely braindead to the point where it is not too crazy to say "things other than patents don't count as prior art". I would love to see this kind of thing get taken to the courts, if only in the hope of current patent rules getting a beating.

[MfA]

Well "we" aren't going to get details out of Google I'm afraid ... you could in theory if you guys offered to push VP8 in an official capacity, but even if they did tell you more you couldn't tell us :/

[McPh1st0]

First Look: H.264 and VP8 Compared (http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/First-Look-H.264-and-VP8-Compared-67266.aspx)

[hajj_3]

the comparisons on the 480p clip in the link in the previous post show that VP8 seems to be rather good in low-motion scenes :) Lets hope that it can be improved so that high-motion scenes aren't blocky. I hope someone releases a plugin for firefox to use window7's built-in h264 decoder, as i'd love to use youtube with h264 instead of flash with firefox.

I wonder how frequently new builds of VP8 will be released and whether new firefox builds will include the newer versions or if we will have to use the add-on updater in firefox.

[CruNcher]

Im currently in the tweaking stage of some parameters visually and then going todo a full encode :) but what i can say so far is the difference i currently see is so damn small between VP8 with sharpness setting applied and x264 High profile, but the major difference is more in Speed as x264 is by far much much faster achieving those visual results and that with balanced settings not Ultra Power great mega slow ones :)
It will be interesting to see the final difference i plan todo 2 encodes with x264 and compare against VP8 1 ABR and 1 CRF at HD ready res and Web Streaming Bitrate.
Of course using that rest potential of Speed balancing out to the VP8 encoder speed and compare both ultimately @ the same Speed is also coming, the result of that should be clear though as VP8 can't win that @ the same speed should be obvious.

[Atak_Snajpera]

First Look: H.264 and VP8 Compared
Somebody should tell that 'expert' that x264 is the king of h.264 not some mainconcept. Also that guy posted images in GIF format! (8-bit). Another moron who does not know how to test codecs :)

[nurbs]

Speaking of comparisons can someone take a look at this site (http://www.quavlive.com/video_codec_comparison) and tell me if the VP8 settings he used are any good.
I ask because he encodes his x264 files with pretty crappy settings (--subme 1, --bframes 1). They are also possibly CBR if mediainfo can be trusted.

I already commented on that and some other things on the site. My comment doesn't show up yet (I kinda suspect it never will), but I think I already affected some changes. He put his encoding options in a shell script instead of displaying them directly on the site and he decided to prominently display that the H.264 files were encoded in High Profile (cabac=true dct8x8=true) :devil:
He also replaced the JPG screenshots with PNG as I suggested.

edit:
New developments: He uses --subme 6 on park-joy now. He changed the following compared to the earlier file: --trellis 0 --bframes 0 --ref 1 --no-8x8dct. Also partitions are now analyse=0x1:0x111 (which is the default I guess) when they were analyse=0x1:0x133 (all) before. He still says the file is High Profile though. They also switched out the roughly half year old x264 version they used before against one before MB-Tree was commited (core 65).

[Blue_MiSfit]

Yes, the files are silly. --subme 1?? CBR with a half-second VBV buffer?!??! Either this guy is purposely trying to nerf results from x264, or he just has no idea how to configure it.

I send a comment in as well...

:p

[Atak_Snajpera]

Either this guy is purposely trying to nerf results from x264, or he just has no idea how to configure it.
No need to configure anything since default medium settings are ok. That guy intentionally reduced a power of x264!

[lych_necross]

Maybe he reduced x264's power to match that of VP8 (trying to make an apples to apples comparison).

[nurbs]

Well, he did post a main profile file claiming it's high profile. Anyway the park joy clip has been replaced by one encoded with x264s defaults. The sunflower clip still uses subme 1. The settings in the script he posted still don't reflect what he actually used.

[dragsidious]

Yes, the files are silly. --subme 1?? CBR with a half-second VBV buffer?!??! Either this guy is purposely trying to nerf results from x264, or he just has no idea how to configure it.

I send a comment in as well...

:p


If both files are in CBR format then it's a valid comparison at least as far as that setting goes.

[sysKin]

"It's patent-free" is an extraordinary claim: most multimedia formats are not, and it is well-known that making one is hard.

It's a fact we always accepted as "well-known" and I'm sure there are two aspects of this fact:
- that some valid patents indeed exist
- that no interested party is powerful enough to take on patent trolls who don't actually have a valid patent, but can destroy anyone who tries anyway

The entire "patent minefield" is surely more caused by the latter. Simple cost of proving that prior art exists, litigating, or just showing that patent is obvious was too much for anyone.
Until now.

Google is a company who has enough lawyers to identify the former (valid patents) and to fight the latter (trolls). If google released the code, they're basically telling us they're picking this fight. At any point they could decide not to but they did.

So yes, it *does* matter that "suddenly" google says they have a patent-free codec. The very same codec in, say, On2's hands was not as patent-free as it is in google's hands, because google has the resources On2 didn't have. And those resources are what counts in cases like this.

And let's face it, we *want* google to win on this one. Squashing patent trolls is delicious.

[turbojet]

For anyone interested I benchmarked flash, html5 h.264 and webm viewing http://www.youtube.com/watch?v=cRdxXPV9GNQ expanded at 100% zoom

CPU is athlon ii 620 @ 3.4ghz
Flash 10.1 rc5 with hardware acceleration enabled and working with nvidia 9500GT

min avg max cpu usage
html5-chrome-360 5 6 10
flash-chrome-360 2 4 10
flash-firefox-360 2 5 8
flash-opera-360 2 5 8
webm-chrome-360 3 6 12
webm-firefox-360 0 1 6
webm-opera-360 3 8 11

html5-chrome-720 9 12 15
flash-chrome-720 3 5 10
flash-firefox-720 5 7 13
flash-opera-720 5 10 14
webm-chrome-720 9 13 19
webm-firefox-720 1 6 11
webm-opera-720 17 21 28

webm-firefox-360 once video was all buffered used 0% CPU almost all the time. Lots of offloading to GPU?

webm-firefox-720 was smooth as silk on an athlon xp 2600+. Flash 360 was watchable but choppy, flash 720 and html5 were too choppy to watch.

Of the few webm videos I've watched there's a lot of artifacts in the first 10-20 frames after a scene change. But with that issue aside I think webm 360 is noticeably better looking then youtube's 360. 720p webm is competitive with youtube's 720p, with a slight edge to the latter.

Except for youtube 720 and vimeo all other web video (Hulu, CBS, TNT, ESPN, Dailymotion, etc.) I've seen would see a vast improvement with VP8 if the scene change issue is fixed.

[dapperdan]

There's an interesting take on the patent situation regarding WebM here:

http://carlodaffara.conecta.it/?p=420

Makes heavy reference to Dark Shakari's own technical analysis.

[iwod]

It seems VP8 is a lot less CPU intensive compare to H.264 and Flash. However it seems this only applies to Firefox, Must be something wrong in the measurement?

[dapperdan]

It seems VP8 is a lot less CPU intensive compare to H.264 and Flash. However it seems this only applies to Firefox, Must be something wrong in the measurement?

Someone complained to the Opera guys about their CPU usage, and they said it wasn't VP8 it was mostly their own video implementation as they were copying full frame buffers around needlessly with the current implementation.

Firefox has also been doing a lot of work recently to take advantage of the GPU for Theora video (not decode, but scaling etc.) so it would make sense if there special WebM build had that enabled. It's Windows only for now I believe, so a test would be how much CPU they use on Linux or Mac OS X.

[iwod]

There's an interesting take on the patent situation regarding WebM here:

http://carlodaffara.conecta.it/?p=420

Makes heavy reference to Dark Shakari's own technical analysis.

Which doesn't make much sense at all.

1. He mentions VP8 deliberately avoided patents. OK. On the Patents side , it may be find, Dark never 100% assure that they infringe any patents anyway. He only said they are very similar and would causes trouble.

2. Stop the BS about it being a reference encoder. On2 Had MUCH longer time to polish their VP8 encoder then even x264 with less human resources. Their Encoder should be much more polished, which it is not.

3. There isn't a Spec for VP8. As Dark has already said it. Therefore it isn't really a reference encoder either. The two are the same.

We need google to hire some engineer to truly publish a proper spec for VP8. But then Google is working on VP9 already.... so what is the point?

[dapperdan]

Which bit doesn't make sense at all?

For 1 (which I think is the main point of his post) I think he makes a very strong case that DS's review actually demonstrates the exact opposite of what it claims with reference to patent threats. It also adds lots of interesting info about particular design decisions affected by patents which, in the absence of knowledge about the codec patent landscape could lead you to believe they were made by "retarded monkeys".

Regarding 2&3 and without getting into the semantics of what is and what isn't a "reference encoder", the VP8 encoder seems to be very good. Remember flaws in the spec (whether due to stupidity, bugs or patent avoidance) have no bearing on whether the VP8 encoder is a good implementation of that spec. Since it seems to be competitive with various H.264 implementations, which have a better spec to work from, I'd say that it's a good showing. Only time and a few competing implementations will tell how much better it could or should have been. There may not (yet) be a well-written spec but, unless I'm mistaken, only the bitstream/decoder gets specced anyway.

There's a strange tension here where if you insult the encoder then you're effectively saying that there's room for improvement once Google starts pounding on it. I think it's surprisingly good considering the bad press that On2 get, so therefore there's less room for improvement before it hits the limits of the spec, but I certainly expect it to get faster, easier to build, a smaller binary, clearer code and a bunch of other improvements (including some total rewrites done independantly) I just don't expect it to magically turn into anything other than a good contemporary codec.

[hajj_3]

But then Google is working on VP9 already.... so what is the point?

Do you have a link about google working on VP9?

[Mosu]

I'd say ivfenc is an official tool (they use it in the encoding examples on the webm project site!) and that only outputs raw .ivf streams. Getting support for IVF input in mkvtoolnix would in my opinion be a pretty high priority. Right now I can't mux these ivfs into anything so I have to use ivfdec to make raw YUV out of the encoded streams before I can compare them :/

Here's a mkvtoolnix build with support for reading VP8 from and writing them to IVF files: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.4.0-build20100527-255-setup.exe

[smok3]

can i assume that there is no 'quality' based encoding possible with current ivfenc?

[dapperdan]

They've blogged a brief introduction to their Alternate Reference Frame technique:

http://webmproject.blogspot.com/2010/05/inside-webm-technology-vp8-alternate.html

[hajj_3]

Intel mulling WebM hardware acceleration in Atom CE4100 chip: http://www.computerworld.com/s/article/9177437/Intel_eyes_hardware_acceleration_for_Google_s_WebM?source=rss_mobilewireless

[valgor]

can i assume that there is no 'quality' based encoding possible with current ivfenc?

I think this can be done if both quantizers assigned the same values

Usage: ivfenc <options> src_filename dst_filename
...
--min-q=<arg> Minimum (best) quantizer
--max-q=<arg> Maximum (worst) quantizer
...

[creamyhorror]

Well, he did post a main profile file claiming it's high profile. Anyway the park joy clip has been replaced by one encoded with x264s defaults. The sunflower clip still uses subme 1. The settings in the script he posted still don't reflect what he actually used.
The parkjoy and especially the riverbed sequences on that comparison show obvious graphical corruption/artifacting. It's probably weightp incompatibility in the decoder the guy is using. No wonder people were commenting on OSNews about the "artifacts" in the x264 screenshots.

http://imgur.com/lDTLt.png
http://imgur.com/3hAKM.jpg

I dropped a message to the page maintainers about it but I doubt they'll do anything. Especially as I didn't specify what decoder to use instead...

Then the bee/sunflower sequence is done at too high a bitrate to show much difference between the codecs. 720 kbps for 640x360 on such a still sequence...even MPEG-2 would probably look close.

[CruNcher]

Also to get a better Objective result you should lower the inloop deblocker especially when comparing vs x264.

This was done with Sorensons Vp8 implementation (On2 VP8 Core 2.0.0-rc8) and decent inloop settings (@ fastest speed possible 3 Mbit VBR)
http://www.supergenije.com/cruncher/

Best experience with Chrome in the Browser currently (surprise surprise)

[turbojet]

Thanks for the sample, it doesn't have the scene change issue that all youtube webm's I've watched so far have. Which points towards a youtube encoding issue.

Viewing was the same for me in all 3 browsers except for the capability of quirky fullscreen in firefox. CPU wise firefox was using 1%, chrome 10%, Opera 18%.

I noticed some blocks in fullscreen mode but quality wise I'd put it above anything on youtube and almost compares to vimeo hd. Signifigantly better than just about everything else I've seen on the web.

Considering webm is aimed at web I think it should be compared to what youtube is using for x264. The header's stripped from the files I downloaded but my guess is they are using something like --preset ultrafast at abr 2000 kbps (720p) or 750 kbps (360p). Youtube could really use some guidance encoding.

[hajj_3]

Google are fixing quite a few bugs in VP8 at the moment, they have released 2 new builds since VP8 was released and there's alot of bugs logged on their tracker, i'm sure in 1 month the main bugs will be fixed and browsers will include newer builds of VP8 in them which should fix the video glitches and other problems we've been having.

[julius666]

Considering webm is aimed at web I think it should be compared to what youtube is using for x264. The header's stripped from the files I downloaded but my guess is they are using something like --preset ultrafast at abr 2000 kbps (720p) or 750 kbps (360p). Youtube could really use some guidance encoding.

Youtube's encoding settings for x264 are aimed at hardware compatibility and encoding speed. Since VP8 is far slower to encode (at the moment) and hardware-compatibility is non-existent (at the moment), the comparison would be meaningless.

[CruNcher]

Youtube's encoding settings for x264 are aimed at hardware compatibility and encoding speed. Since VP8 is far slower to encode (at the moment) and hardware-compatibility is non-existent (at the moment), the comparison would be meaningless.

Not that heavy as many think yeah the default setting most encoder currently are using are slow with RD but it can be fast without costing to much in Quality. Also you don't have to forget it's missing B-frames which speedup H.264 significantly @ Encoding. Though VP8 is quiet different to setup then most H.264 Encoder, you have to get into that first. But yeah as fast as x264 can be there is still some way to go :D

[turbojet]

Youtube's encoding settings for x264 are aimed at hardware compatibility and encoding speed. Since VP8 is far slower to encode (at the moment) and hardware-compatibility is non-existent (at the moment), the comparison would be meaningless.

You have to compare webm to what H.264 is out there on the web, not to x264's best. It might even be more fair to use an old mainconcept or ateme build at abr bitrates which more closely represents millions of websites' video outside of youtube/vimeo.

As far as speed goes it must be fast enough for youtube as they are encoding most (all?) of their library to webm. Other site's are probably less concerned about speed because of the reduced content.

As far as hardware acceleration, firefox with youtube's 360p webm and cruncher's 720p sample use less resources then mpc-hc dxva does with 720p. It's either a really good implementation of hardware acceleration by mozilla or VP8 is that easy to decode. Either way firefox allows webm to be played on older/slower hardware than flash or html5 H.264 (single core cpu with dxva1 card plays 720p webm smoothly).

I'm not saying H.264 is bad and VP8 is great. If done right H.264 would be great for online video but so much is wrong with it. Very poor encoders used, very poor settings used, current hardware acceleration methods aren't very effective. Then the big one MPEG-LA stating that H.264 will be free on the web for the next 5 years with nothing further into the future. Which seems a lot like what Unisys did with GIF and it all but knocked GIF off the web until the patent ran out. But at least MPEG-LA is giving us early warning signs whereas Unisys surprised everyone.

Frankly, if I'm still encoding in 5 years, hopefully x264 will still be able to be legally obtained. Whether that comes with a surprise (to me) from MPEG-LA that they won't ask for software royalties, x264 fitting the bill MPEG-LA hands them or x264 becomes payware. If youtube gets rid of H.264 it probably more then made up for the $127 million On2 purchase the first day MPEG-LA asks for software royalties.

[Astrophizz]

Poor encoders, poor settings, and ineffective hardware acceleration are the same things VP8 will face so I don't think you can count those against H.264 on the web.

[WonderCsabo]

Somebody knows about an x64 DShow VP8 decoder?

[Leeloo Minaï]

I hope someone will also port VP8 to a VFW codec, the lack of B-frames should make this easier.

[Nic]

There's probably loads of ways to test this easily on windows, but in case anyone finds it useful:

http://nic.dnsalias.com/ivfenc.zip <-- is ivfenc that can take an AviSynth script
http://nic.dnsalias.com/AVSVorbis.zip <-- is aoTuV B5.7 Vorbis Encoder that can take an AVISynth script

And of course:
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.4.0-build20100527-255-setup.exe <-- Mosu's mkvmerge that can mux to WebM
http://code.google.com/p/webm/downloads/detail?name=webmdshow-0.9.7.0-20100526.zip <-- Latest DirectShow filters for playback

Then you can encode with an AVS Script like:
AVISource("YourFile.avi").ConvertToYV12()

AVSVorbis -q -2 in.avs out.ogg
ivfenc --target-bitrate=100 in.avs out.ivf
mkvmerge --timecode-scale 1000000 --disable-lacing out.ivf out.ogg -o out.webm

Very long winded compared to ffmpeg, and probably no use to anyone, but perhaps lets you fiddle a bit more with parameters, etc.

I've been quite impressed by low bitrate VP8, can look very "watchable".

Cheers,
-Nic

ps
if you have trouble with seeking, remove the source filter so that you rely on the splitter filter (which tends to work better).
i.e. regsvr32 /u "C:\Program Files\Common Files\WebM Project\webmdshow\webmsource.dll"

[poisondeathray]

Thanks for compling that Nic :)

[clsid]

Any chance of 64-bit compiles for the DirectShow filters?

[Nic]

clsid: Never compiled anything for 64bit and I have no idea about what to do, how it differs or anything. However, try: http://nic.dnsalias.com/WebMx64.zip

[wiak]

Keep in mind that the patent system in the US is completely braindead to the point where it is not too crazy to say "things other than patents don't count as prior art". I would love to see this kind of thing get taken to the courts, if only in the hope of current patent rules getting a beating.
google is counting on that one mate :P
and on a side note, googleplex should move to france
:stupid:

as it stands now, Adobe, Chrome, Firefox and Opera all will support VP8/WebM, and many all ready do

keep in mind the current WebM is a Developer Preview, so basicly a beta or if you follow google, you should name it stable alpha instead :D

nobody wants GIF all over again,
http://en.wikipedia.org/wiki/Graphics_Interchange_Format#Unisys_and_LZW_patent_enforcement

web is built upon open standards HTTP, FTP, HTML
so how do H.264/AVC fit in here?

anyway, i support open codecs/standards, why?, why not!, if not, you wouldn't have the world wide wibble as its today :P

and for you Dark Shikari, keep up the good work on x264 :)

[Astrophizz]

H.264/AVC is an open standard, wiak. It's just not "free".

[wiak]

H.264/AVC is an open standard, wiak. It's just not "free".soo thats basicly the opposite of world wild wibble

who cares if VP8 is a little worse than H.264 it aint far away, and H.264/AVC wont go away anyway, its primary used for paid content like blu-ray/itunes etc

the web realy needs WebM, why? who wants to pay MPEG LA alot of monkeys...
http://donraja.files.wordpress.com/2009/06/monkeys.jpg

using H.264 on the web for web video is kinda giving way to much power to MPEG LA to say pay up or get sued, it has happend before with GIF, and the whole web got together and made PNG as replacement, VP8 is more like that, just that google is doing it preemptive

if you like the web now, you should support WebM, just as PNG did before it

[turbojet]

Poor encoders, poor settings, and ineffective hardware acceleration are the same things VP8 will face so I don't think you can count those against H.264 on the web.

I'm not saying you are wrong but it's way too early to make these claims and here's my thoughts on these 3 issues.

Poor encoders. Closed encoders with commercial licensing is the main problem I see with H.264. Google is a huge supporter of FOSS and they could require sources with VP8 which would prevent most poor encoders as well as companies making a bunch of money from poor encoders. It's unknown what sites using commercial licensed H.264 encoders currently will do when/if they decide to switch to VP8.

Poor settings. Google's history is mainly simple, intuitive software that works like users expect it to. If they apply the same goal to their VP8 encoder there won't be many settings (there isn't many currently) which will all but eliminate the poor settings issue. Knowledgeable people working with the source would hopefully prevent bad algorithms from being used. However google doesn't have a great history of listening to outside suggestions.

Hardware acceleration. Firefox has already offloaded more off the cpu with webm in it's first public release then adobe has done with H.264 in years. Since firefox is FOSS if other browser companies and flash want to get some ideas from how mozilla is doing it they can legally. Currently flash 10.1 and html5 browsers claiming H.264 hardware acceleration aren't using significantly fewer resources then webm browsers that have no hardware acceleration.

[Astrophizz]

@wiak I was merely correcting a common misconception.

Poor encoders. Closed encoders with commercial licensing is the main problem I see with H.264. Google is a huge supporter of FOSS and they could require sources with VP8 which would prevent most poor encoders as well as companies making a bunch of money from poor encoders. It's unknown what sites using commercial licensed H.264 encoders currently will do when/if they decide to switch to VP8.
If VP8 becomes economically attractive I believe that companies will produce their own VP8 encoders. In which case the same issue that exists with H.264 and poor encoders could very well arise with VP8. I'm probably misreading it but are you suggesting that Google would somehow mandate that only their encoder be used for VP8 content? How would that make for an open internet?

Poor settings. Google's history is mainly simple, intuitive software that works like users expect it to. If they apply the same goal to their VP8 encoder there won't be many settings (there isn't many currently) which will all but eliminate the poor settings issue. Knowledgeable people working with the source would hopefully prevent bad algorithms from being used. However google doesn't have a great history of listening to outside suggestions.
x264 is very popular for internet content and has relatively simple settings yet people still use poor settings with it (including Google, in my opinion). They may have reasons for these settings but they would have to make the same sacrifices with VP8.

Hardware acceleration. Firefox has already offloaded more off the cpu with webm in it's first public release then adobe has done with H.264 in years. Since firefox is FOSS if other browser companies and flash want to get some ideas from how mozilla is doing it they can legally. Currently flash 10.1 and html5 browsers claiming H.264 hardware acceleration aren't using significantly fewer resources then webm browsers that have no hardware acceleration.
Firefox could do the same with H.264 if they included it, there would be nothing to prevent it. Your argument there is based upon flash and not H.264 in and of itself.