WebM Exciting New Video Standard with VP8, Vorbis, Matroska

[Emp3r0r]

WebM is a new open video standard announced by Google at Google IO (day 1 keynote) in May 2010:
http://www.youtube.com/GoogleDevelopers

Video Demo
WebM Demo with Leonardo Dicaprio - Shot with Red Camera (http://www.youtube.com/watch?v=rLxQiI8c1Bs&p=4FFFFF981ECC3263&playnext=1&index=14&html5=True)


More information

WebM Blog (http://webmproject.blogspot.com/)

WebM Project Homepage (http://www.webmproject.org/)

webm-discuss (https://groups.google.com/a/webmproject.org/group/webm-discuss) mailing list
Info

Alternate Reference Frame Explanation (http://webmproject.blogspot.com/2010/05/inside-webm-technology-vp8-alternate.html)


Tools

WebM DirectShow Playback Filters 32bit (http://code.google.com/p/webm/downloads/list) (and other downloads)

WebM DirectShow Playback Filters x64 (http://nic.dnsalias.com/WebMx64.zip)

Haali Media Splitter (http://haali.su/mkv/) now w/ WebM Support

VP8 Encoder that can take AVISynth script - ivfenc (http://nic.dnsalias.com/ivfenc.zip)

aoTuV B5.7 Vorbis Encoder that can take an AVISynth script - avsvorbis (http://nic.dnsalias.com/AVSVorbis.zip)

WebM+ffmpeg Win32 Build (http://micksam7.com/blog/2010/webm-ffmpeg-win32-build/)

Encoder Parameters (http://www.webmproject.org/tools/encoder-parameters/)

MKV Toolnix 4.0.0 w/ WebM Muxing (http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.0.0-setup.exe)


Nightly Builds

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

Firefox http://nightly.mozilla.org/webm/

Opera -stable (http://www.opera.com/download/) -announcement (http://labs.opera.com/news/2010/05/19/)

IE9 -platform preview (http://ie.microsoft.com/testdrive/Default.html)

[Dark Shikari]

The first in-depth technical analysis of VP8 (http://x264dev.multimedia.cx/?p=377)

[Mosu]

mkvtoolnix already supports WebM files as they're basically Matroska: https://www.bunkus.org/blog/2010/05/google-open-sources-vp8-choses-matroska/

[Emp3r0r]

Snippet from article above:
Overall verdict on the VP8 video format

Overall, VP8 appears to be significantly weaker than H.264 compression-wise. The primary weaknesses mentioned above are the lack of proper adaptive quantization, lack of B-frames, lack of an 8×8 transform, and non-adaptive loop filter. With this in mind, I expect VP8 to be more comparable to VC-1 or H.264 Baseline Profile than with H.264. Of course, this is still significantly better than Theora, and in my tests it beats Dirac quite handily as well.

In terms of decoding speed I’m not quite sure; the current implementation appears to be about 16% slower than ffmpeg’s H.264 decoder (and thus probably about 25-35% slower than state-of-the-art decoders like CoreAVC). Of course, this doesn’t necessarily say too much about what a fully optimized implementation will reach, but the current one seems to be reasonably well-optimized and has SIMD assembly code for almost all major DSP functions, so I doubt it will get that much faster.

I would expect, with equally optimized implementations, VP8 and H.264 to be relatively comparable in terms of decoding speed. This, of course, is not really a plus for VP8: H.264 has a great deal of hardware support, while VP8 largely has to rely on software decoders, so being “just as fast” is in many ways not good enough. By comparison, Theora decodes almost 35% faster than H.264 using ffmpeg’s decoder.

They just mentioned in the live video that they will be pushing hardware support.

[the Mad Duke]

The hardware support will be there(hardware support list for WebM: AMD, Nvidia, Qualcomm, Broadcom... ) and Adobe just said that VP8 will be in Flash Player.

[Emp3r0r]

mkvtoolnix already supports WebM files as they're basically Matroska
I don't see any details yet on if WebM support speex (and gasp FLAC). Is it restricted to just vorbis? Any restrictions on bitdepth or samplerate?

[Mosu]

They're _basically_ Matroska but with certain intentional limiations. One of those limitations is that at the moment only Vorbis is supported. However, the project is open to other audio codecs as well -- probably as long as they're free as well (which would mean FLAC or WavPack).

[hajj_3]

No news if Apple will add support or not. Microsoft WILL (http://windowsteamblog.com/windows/b/bloggingwindows/archive/2010/05/19/another-follow-up-on-html5-video-in-ie9.aspx) add WebM to IE9 so hopefully flash for streaming video is pretty much dead as firefox and IE combined have around 85-90% market share! I noticed Intel isn't in the list of companies that is involved in it :( I hope its added to Firefox 3.6.4 or 3.6.5 instead of us having to wait for Firefox 4.0 which will be months.

[the Mad Duke]

I hope its added to Firefox 3.6.4 or 3.6.5 instead of us having to wait for Firefox 4.0 which will be months.


http://www.webmproject.org/users/

[hajj_3]

thats a nightly, that doesn't say if it will be in 3.6.4 or 3.6.5 or not:(

[Keiyakusha]

http://www.webmproject.org/users/

As I understand Firefox builds by that link is an unstable pre-alpha with WebM support. Not something everyone wants to use on everyday basis.

[hajj_3]

correct and i assume its a nightly of 4.0 and not a 3.6.4 nightly. I just want to risk messing up my system by installing it to find out.

[Keiyakusha]

actually all is simple. I just clicked on download link and filename says this is development preview of the 3.7 alpha. I believe it will be installed as separate browser under some codename.
Never heard of 4.0 so far but current 3.7 maybe the same as 4.0 like it was when firefox 3.something was eventually renamed to 3.5.

[hajj_3]

3.7 has been scrapped as the main feature was seperating plugins like flash and silverlight from the browser so flash doesn't keep crashing firefox, this feature will be in firefox 3.6.4 which is out on June 1st (approximately). Firefox 4.0 will add lots of other cool stuff, i'm not sure why they have named this nightly 3.7 as it was decided it was scrapped weeks ago, strange.

[poisondeathray]

wow a bit of a let down, considering all the hype and head-to-head comparisons to h.264 on on2's marketing page

thanks to DS for the preview & in depth analysis

[Emp3r0r]

wow a bit of a let down, considering all the hype and head-to-head comparisons to h.264I disagree. This is huge! With such big partners and adoption, the rate at which the implementations improve will be much faster than theora.

Predictions
2010: Android and ChromeOS get WebM
2011: all major browsers fully support WebM
2011: WebM begins streaming into Android TVs
2011: WebM used in video conferencing
2012: most major content providers support WebM
2012: major political events stream live with WebM
2013: WebM streaming directly to Android electric cars
2014: New standard WebMx improve quality to near AVC levels

[ricardo.santos]

Does anyone have a ffmpeg vp8 patched version?

Sorenson has provided a free web only uploading/encoding page on their site

http://www.sorensonmedia.com/vp8/

[poisondeathray]

I disagree. This is huge! With such big partners and adoption, the rate at which the implementations improve will be much faster than theora.


I'm not disagreeing that it's big news.

I said it was a bit of a let down , because of all the hype - you know golden frames etc.... It was supposed to be significantly better than h.264 a year ago (in terms of quality), not what people are speculating it to be with improvements 5 years from now.

Well I hope it does improve, but DS's article said it's pretty much final spec, and that Google wasn't looking to change the spec . (no b-frames WTF ?!)

[AlekseiV]

I disagree. This is huge! With such big partners and adoption, the rate at which the implementations improve will be much faster than theora.But the "spec" itself is worse than H.264's, so it can never be as good. Also the spec is code.

[Midzuki]

I disagree. This is huge! With such big partners and adoption, the rate at which the implementations improve will be much faster than theora.

However, Dark Shikari has written:

Initially I was intending to go easy on On2 here; I assumed that this encoder was in fact new for VP8 and thus they wouldn’t necessarily have time to make the code high-quality and improve its algorithms. However, as I read through the encoder, it became clear that this was not at all true; there were comments describing bugfixes dating as far back as early 2004. That’s right: this software is even older than x264! I’m guessing that the current VP8 software simply evolved from the original VP7 software. Anyways, this means that I’m not going to go easy on On2; they’ve had (at least) 6 years to work on VP8, and a much larger dev team than x264’s to boot.


Predictions
2010: Android and ChromeOS get WebM
2011: all major browsers fully support WebM
2011: WebM begins streaming into Android TVs
2011: WebM used in video conferencing
2012: most major content providers support WebM
2012: major political events stream live with WebM
2013: WebM streaming directly to Android electric cars
2014: New standard WebMx improve quality to near AVC levels

Just out-of-curiosity,
where did you buy your newest crystal-ball? :)

Mr. DeathRay wrote:

(no b-frames WTF ?!)

VfW explains it all. :D

[colinhunt]

Reading Dark Shikari's technical analysis now, and I get a strong feeling that Google spent a s***load of money on a load of s***.

[sneaker_ger]

So, what do I have to do to play around with it? I downloaded the sample from Dark Shikari's blog and installed the DS filters from google's site but MPC won't play it. The new mmg build refuses it, too.

[Mosu]

So, what do I have to do to play around with it? I downloaded the sample from Dark Shikari's blog and installed the DS filters from google's site but MPC won't play it. The new mmg build refuses it, too.

That's because the vp8.mkv sample is not a Matroska/WebM file despite its file extension (it doesn't start with an EBML signature etc). Maybe it's a raw bitstream. Those are not supported yet by mkvtoolnix, mostly because the official tools only output into Matroska/WebM anyway.

[Keiyakusha]

Works nice for me. However I tried DS encoder. Not sure how to tweak settings in it and on defaults it looks like mpeg1

[colinhunt]

I'd love to hear DS or someone else equally knowledgeable comment on the x264/VP8 comparison video on On2's website, http://www.on2.com/index.php?599.

Oops, I guess this was already covered in the other VP8 thread. My bad.

[Dark Shikari]

That's because the vp8.mkv sample is not a Matroska/WebM file despite its file extension (it doesn't start with an EBML signature etc). Maybe it's a raw bitstream. Those are not supported yet by mkvtoolnix, mostly because the official tools only output into Matroska/WebM anyway.Oops, you're right, it's a raw bitstream, not MKV.

[clsid]

Here is a sample file from Opera:
http://lachy.id.au/lib/media/elephantsdream/Elephants_Dream-720p-Stereo.webm

Unfortunately the audio does not decode properly with CoreVorbis or ffdshow.

Edit: audio works properly with Haali's splitter (new version released today)

[Blue_MiSfit]

I think we may be missing a crucial piece by comparing VP8 to x264. The latter is clearly superior. What if we compare it to Mainconcept SDK or Ateme?

~MiSfit

[STaRGaZeR]

Here is a sample file from Opera:
http://lachy.id.au/lib/media/elephantsdream/Elephants_Dream-720p-Stereo.webm

Unfortunately the audio does not decode properly with CoreVorbis or ffdshow.

Edit: audio works properly with Haali's splitter (new version released today)

What video decoder are you using?

[iwod]

1. WebM is about the worst name you could ever get, Both as a Name and an Extension.

2. VP8 doesn't have a Spec........ ( A Reference Encoder is not a Spec )

3. Vobris and MK is about as good as it gets for Audio and Container.

What we need now is Google to publish / revise / clean the spec. So the communities can implement a decent encoder. As history teaches us, Most of the best Audio Video Decoder comes from Open Source / Community work.....

[CruNcher]

Did somebody allready tested what happens in a low bitrate short gop situation visualy :) i mean that's what they advertised the most with that it stays stable no i-frame pulse effect ?
iwod we gonna see encoder optimizations the implementation of some psy mostly but no big changes to the current bitstream for this stage, but the base for VP9 is here and VP9 will be the first one where much more improvements will go into, the time is to short hardware is being produced for the current spec (code) so no go it is like it is but it's no bad start @ all.

[stax76]

Great news for MKV, I have doubts however in this whole HTML5 thing, appear to be a titanic mess like C++.

[BDX]

http://lists.wikimedia.org/pipermail/wikitech-l/2010-May/047795.html

Any comments?

[MfA]

I've often found near identical algorithms in papers published a decade apart by people who did both obviously do a fair bit of literature research ... there's just so much literature out there and even the mighty google can miss some things. Also corporations, even big ones, do prior art themselves occasionally.

Any way, the big example of patented tech was directional intra prediction right? AFAICS that came from Nokia's MVC coder, when was that first disclosed and what patent number exactly covers it?

I can find Q15-J-19 as disclosure, published in 2000 ... and patent 7289674 with priority dates in 2002. So it does seem Nokia prior arted itself.

I think anyone who wants to make an argument about infringement on the part of VP8 at least has to present patent numbers. Assuming that the patent office looked for prior art is one thing (a very bad assumption, but meh) but just saying "hmm, that's probably patented" is a bit too lazy.

[wiak]

They're _basically_ Matroska but with certain intentional limiations. One of those limitations is that at the moment only Vorbis is supported. However, the project is open to other audio codecs as well -- probably as long as they're free as well (which would mean FLAC or WavPack).
there is a reason for some restrictions, why? webm is made for the web, so it should play regardless of browser, so why add flac when its not needed atm, it will make everything alot more confusing for the average user, if you want flac, use matroska with video or better .flac without video :p

You can call webm container Matroska Web Lite :)

atm, webm is the best bet when it comes to open video, it has a good video codec, a great audio codec compared to mp3 and a open container that is based on matroska, and most matroska splitters and muxers include webm support

Haali just released a updated splitter
mkvtoolnix includes webm muxing
there is also a reference splitter & muxer at webmproject.org

so atm when you put a video online, like on you took in a zoo or something, and you want the best viewers, what do you do?

1. put it out as webm so everyone with Firefox, Chrome, Opera, IE with VP8 dshow filter on both Windows, Linux, OS X can play it natively
2. put it out in h264+aac, and only play it on chrome, safari and internet explorer, and later on pay royalty when MPEG LA changes their mind...
3. wait what?

anyway, webm is a win-win for everyone
h264 will still be the biggest offline codec anyway due to blu-ray/itunes other online stores etc, and good current hardware support

to last, if you want open online video, go webm, if you want offline, just use h264 ;)

[clsid]

What video decoder are you using?The VP8 decoder from the WEBM site. You can find a DirectShow filter set there. Only the decoder is needed.

[Daiz]

Maybe it's a raw bitstream. Those are not supported yet by mkvtoolnix, mostly because the official tools only output into Matroska/WebM anyway.

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 :/

[Mosu]

Getting support for IVF input in mkvtoolnix would in my opinion be a pretty high priority.

I agree, and that's the next feature I'm going to implement. This will have to wait until the weekend or early next week though due to other real life issues.

[Turnpike]

The VP8 decoder from the WEBM site. You can find a DirectShow filter set there. Only the decoder is needed.
The official decoder+latest Haali splitter+MPC work fine on XP.But it seems that I couldn't get the decoder registered on 64bit Win7?

[Keiyakusha]

is there somewhere compiled ivfenc?

[STaRGaZeR]

The VP8 decoder from the WEBM site. You can find a DirectShow filter set there. Only the decoder is needed.

Thanks, I missed the DS filters.

It's only me or everything encoded with this encoder looks like crap?

[NerdWithNoLife]

These patent wars are dissapointing. The people on this forum most certainly can design a codec that outperforms even the hype of the commercial products. Apple, Sorenson, Adobe, etc. win in marketing and legal muscle. x264 wins in actually having a great product.

[clsid]

The official decoder+latest Haali splitter+MPC work fine on XP.But it seems that I couldn't get the decoder registered on 64bit Win7?
You must explicitly run the command prompt as administrator when using regsvr32 on Vista/7.

[weaver4]

I see the comments on how it compares to X264 but I was wondering on how it compares to XviD. I am not really an expert in video but to me XviD@Q=3 is approx equal the quality of X264@Q=22 (single pass of course); but the XviD video filesize is appox 25-35% larger.

So if VP8 video quality equals X264@Q=22 for 10-20% larger filesize I could live with that.

I guess all the decoder boxes out there (Popcornhour, WD TV Live, Seagate Theater, etc) will never play VP8; right?

[Boolsheet]

is there somewhere compiled ivfenc?
There's a "libvpx 0.9.0 visual studio build" here (http://code.google.com/p/webm/downloads/list) with Windows binaries.
Example encoding parameters are on their website (http://www.webmproject.org/tools/encoder-parameters/).

I think VP8 is not all too bad on medium and high bitrates. The crew_4cif test sample on low bitrates shows some problems after the flashes, quality drops really down, but that should be fixable with some encoder improvements I hope.

[Turnpike]

You must explicitly run the command prompt as administrator when using regsvr32 on Vista/7.
Done,thx!But it seems that MPC can't call VP8 decoder in Win7?WMP is ok though.

[stax76]

@Emp3r0r

A thread title starting with 'WebM' might be better.

[Keiyakusha]

There's a "libvpx 0.9.0 visual studio build" here (http://code.google.com/p/webm/downloads/list) with Windows binaries.
Example encoding parameters are on their website (http://www.webmproject.org/tools/encoder-parameters/).

I think VP8 is not all too bad on medium and high bitrates. The crew_4cif test sample on low bitrates shows some problems after the flashes, quality drops really down, but that should be fixable with some encoder improvements I hope.
Ohh thanks! Somehow I overlooked it...

Done,thx!But it seems that MPC can't call VP8 decoder in Win7?WMP is ok though.

Works for me on Win7 32bit

[Turnpike]

Works for me on Win7 32bit
The VP8 decoder doesn't work with MPC-hc x64 version on Win7,but both MPC-hc x86 version and WMP are ok.

[clsid]

The filter is 32-bit so it will obviously not work in MPC x64. It will also not work in Media Center on Vista/7 x64.

[weaver4]

@Emp3r0r

A thread title starting with 'WebM' might be better.

Adding WebM to StaxRip would even be better. ;)

[ricardo.santos]

Here's a windows ffmpeg build with vp8

http://micksam7.com/blog/index.php/?p=743

or you can try the flixwebm free converter altough ive been unable to change audio settings it always produces vorbis at 192k

http://www.wildform.com/products/flix/

Have fun

[stax76]

Adding WebM to StaxRip would even be better.

I just need to add a new encoder, a few tweaks, some updated applications and some new profiles but still it will take time.

Before adding WebM support I have to finish revising the complete UI adding high DPI support. :(

[Midzuki]

My initial (non-)impressions about VP8 :

at the moment, NOT supported outside of the WebM «sub-container» :devil: :) Until Google, or someone else, releases a real CLI encoder/muxer, a stable DirectShow decoder, and (seriously!) a VfW .DLL, I will keep having very-little curiosity about it.

P.S.: I did give a try to "ivfenc.exe". What the heck, it's infinitely slower than the VC-1 DMO encoder. :eek:
Completely unusable for "obsolete" rigs like mine. :mad:

[Schrade]

The first in-depth technical analysis of VP8 (http://x264dev.multimedia.cx/?p=377)

Heh,

Steve Jobs links to your blog post in a response to an E-mail someone sent to him.

http://www.theregister.co.uk/2010/05/20/jobs_on_vp8/

[MfA]

Make no mistake though ... he linked it because it gives his earlier patent arguments a sheen of respectability from an independent source.

Shame that that part of it was entirely build on assumptions (not a patent number to be spotted).

[Lotesdelere]

Here is a sample file from Opera:
http://lachy.id.au/lib/media/elephantsdream/Elephants_Dream-720p-Stereo.webm
Unfortunately the audio does not decode properly with CoreVorbis or ffdshow.
Same here whatever audio decoder is used, I think the problem comes from the "official" DirectShow filters.

However this build of VLC (http://people.videolan.org/~jb/webm/) can play it fine.

[CruNcher]

Yeah that Jason plays his PR game is a pitty :(

[Lotesdelere]

Here's a windows ffmpeg build with vp8
http://micksam7.com/blog/index.php/?p=743
Ah finally something that works, thanks for this link.

I couldn't get the DirectShow encoder to work (crashed with assertion failed) and the command line tools are creating raw streams only that nothing can mux.
What a pity, what a bad start for a new standard (?).


http://i.imgur.com/4AFTe.png

[CruNcher]

Ah finally something that works, thanks for this link.

I couldn't get the DirectShow encoder to work (crashed with assertion failed) and the command line tools are creating raw streams only that nothing can mux.
What a pity, what a bad start for a new standard (?).


http://i.imgur.com/4AFTe.png

Sorry but this Kid stuff doesn't really is the nature of Doom9 (MOD ?)
especially not in the importance of the situation we are facing, something like this doesn't really helps

[neuron2]

Sorry but this Kid stuff doesn't really is the nature of Doom9 (MOD ?)
especially not in the importance of the situation we are facing, something like this doesn't really helps Instead of tossing insults, please explain why this is "kid stuff".

[CruNcher]

http://i.imgur.com/4AFTe.png <- cant you see it yourself this is surely not how things look like in real, it's a sarcastic joke comparison even exaggerated one (using the old Batman for VP8 and the new for H.264 trying to make a point "kid stuff" sorry if it sounds too hard insulting was surely not my point here), something like this is inadequate for the situation and doesn't reflect the visual truth we are currently facing between VP8 and H.264.

[parsifal]

CruNcher, please don't be so uptight! The image was obviously humorous and of the witty kind, mind you...

[Dislikeyou]

From ON2 Website:
http://img295.imageshack.us/img295/1706/lolky.jpg

[CruNcher]

CruNcher, please don't be so uptight! The image was obviously humorous and of the witty kind, mind you...

It's not that i can't lough about such things if they fit but it doesn't fit, and On2s comparison was a very special restricted broadcast use case with a old x264 which neither reflects the current truth anymore though @ that time it did under these very heavily restricted conditions (bitrate very low @ the edge of the resolution and short gop back then only 1 H.264 encoder was able to survive that visually, as it was entirely optimized for such broadcast scenarios) :(

[hajj_3]

We can't trust On2's own screenshots, we need to compare VP8 to Mainconcept's and Ateme's h.264. Its unfair to compare with x264 as that is clearly way better, i'd appreciate screenshot comparisons with mainconcept and ateme's h264 tho.

[weasel_]

CruNcher its just a joke ...
And still its more correct then claims on ON2 site about Vp8>h264

From ON2 Website:
http://img295.imageshack.us/img295/1706/lolky.jpg
hahaahah nice try google :)

[iwod]

I wonder if 110M paid to ON2 is enough to buy out all the patents in AVC.

So we could once and for all end the war...... where best codec win.

VP8 to me is USB - Cheap and Easy, but crap

X264 to be is Firewire, good but expensive....

[CruNcher]

That is a true visual difference @ that time of how things looked @ low bitrate i created these visual x264 results many many times moving @ the edge of bitrate for HD resolutions with restricted settings x264 (H.264) fall apart that way and yes i would have preferred a more blurry but less artifacting result under those very special conditions @ that time but with many improvements that followed x264 Edge is far lower now :)
But whats more interesting comparing both are resolution bitrate factors that are commonly used for Web Encoding, here it gets really interesting especially with future psy optimizations for VP8 :)

And in those cases it doesn't really has to beat x264 @ all but majorly currently VC-1 and Apple Quicktime to have it's niche secured :) what Theora yet couldn't achieve is really near now :)

Also it seems many of you lost what VP8 also means for Linux it's a big step.

Windows = Windows Media Video (VC-1)
OSX = Apple Quicktime (H.264)
Linux = VP8 now and for the future as it's own base :)
Web = We still gonna see many things floating around but VP8 could take a big part of it

[Atak_Snajpera]

we need to compare VP8 to Mainconcept's and Ateme's h.264.
Ateme V2 is almost as good as x264 so VP8 will loose as well :)

[hajj_3]

it looks like a patent pool may be launched to go after VP8 now it seems: http://digitaldaily.allthingsd.com/20100520/googles-royalty-free-webm-video-may-not-be-royalty-free-for-long/

I'm glad that they are taking action now. I really hope that this does go to court so we can decide once and for all the whether it does violate patents and how much google needs to pay the MPEG-LA to licence those patents. Lets hope this is all over and done with within the next 3 months then websites can start adding WebM support without fear of having to pay royalties.

[PatchWorKs]

I believe that the interesting fact is that "Android-based Google TV coming to living rooms this fall (http://arstechnica.com/gadgets/news/2010/05/android-based-google-tv-coming-to-living-rooms-this-fall.ars)" also.

And don't forget that a (cheap) HW implementation have been aleady achieved in EVD: http://en.wikipedia.org/wiki/Enhanced_Versatile_Disc

Last but not least: don't VP8 released *before* h264 ? If so, who could be the patent violator ?

[nurbs]

VP8 was first announced in september 2008 and it wasn't released until this week.

[kosmonaut]

Yeah that Jason plays his PR game is a pitty :(

The last thing Dark needs is help defending himself, but this seems pretty unfair. It was inevitable that many people (myself included) were going to want to hear from him on VP8. His analysis is thorough! You can argue with his conclusions if you want, but the last thing you can call his post is superficial. Interested parties, like Steve Jobs, were going to use what he said for their own purposes, no matter what Dark posted, but at least he put all his cards on the table for anybody to read and decide for themselves.

[Dark Shikari]

The last thing Dark needs is help defending himself, but this seems pretty unfair. It was inevitable that many people (myself included) were going to want to hear from him on VP8. His analysis is thorough! You can argue with his conclusions if you want, but the last thing you can call his post is superficial. Interested parties, like Steve Jobs, were going to use what he said for their own purposes, no matter what Dark posted, but at least he put all his cards on the table for anybody to read and decide for themselves.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.

[MfA]

The last thing Dark needs is help defending himself, but this seems pretty unfair. It was inevitable that many people (myself included) were going to want to hear from him on VP8. His analysis is thorough! You can argue with his conclusions if you want, but the last thing you can call his post is superficial. Interested parties, like Steve Jobs, were going to use what he said for their own purposes, no matter what Dark posted, but at least he put all his cards on the table for anybody to read and decide for themselves.
His cards for the patent side were opinion completely unbiased by any facts. Without looking at actual patents and prior arts it's impossible to guess at the strength of patents or even the likelihood of something being patented.

Would a sane person think it likely that Nokia invalidated it's own intra prediction patents by early disclosure? Not likely ... but to think it impossible is naive. That kind of stuff happens all the time and it seems it happened here.

[Dark Shikari]

Would a sane person think it likely that Nokia invalidated it's own intra prediction patents by early disclosure? Not likely ... but to think it impossible is naive. That kind of stuff happens all the time and it seems it happened here.The whole point is that if we don't know anything, we have to assume the worst. It would be absolutely great if Google released a rationale for why said features don't violate patents.

But they haven't.

Sure, it's possible that there are all kinds of reasons why patents aren't being violated. But until it's demonstrated which one of these reasons is correct, we can't simply blindly assume that there isn't any violation going on.
His cards for the patent side were opinion completely unbiased by any facts. Without looking at actual patents and prior arts it's impossible to guess at the strength of patents or even the likelihood of something being patented.Since when is "VP8 is copying H.264" opinion? You can look at the bloody code if you want. And no matter what the situation, copying creates risk of patent problems. In the messy world of video coding, things are basically patented until proven otherwise, not the other way around.

[CruNcher]

You made conclusions that aren't facts your assumptions in the end might be wrong only because something is similar or shares the same principals doesn't mean it is the same and base for a patent violation, but that's what the conclusion your draw yourself together says and that currently gets used in attacking without any proof @ all in the mass media. Though MPEG seems to be pretty sure what you said has a base else they wouldn't come and higher their sword calling for a license base for VP8. Next we have to see how Google reacts to that , though they are pretty sure the conclusions you made aren't the case, they surely checked that before jumping into the wild (do you really believe they didn't calculated with these attacks ?). So either they gonna disprove you and even then MPEG might stands against it in that case we gonna see only 1 solution a court decision telling us whose right ;)

[Dark Shikari]

You made conclusions that aren't facts your assumptions in the end might be wrong only because something is similar or shares the same principals doesn't mean it is the same and base for a patent violationCan you actually read what I said before writing about it?

I never said there was a patent violation.

I said there might be one. There is a risk of one. It might exist. It's possible. It may or may not be the case. How many different ways do I have to put it before people realize that it's not a foregone conclusion?

[MfA]

We do know something, we know when the MVC decoder spec. was disclosed and what was in it ... and we know the intra prediction patent does not have a priority date within the grace period after that disclosure. That should be enough for any sane person to not make blanket statement concerning the state of patent coverage for intra prediction.

As for Google there is really no advantage to them to show their competition where their patent portfolio is strongest or weakest ... they won't get into details for the same reason why Jobs/MPEG-LA won't publicly disclose any specific parts where the codec infringes. You have to keep your powder dry, the only time Google would be likely to go into details would be during NDA covered meetings.

One blind assumption is no better than the other ...

[CruNcher]

Yes i read it and yes i understand what you wrote above but in the END you madeup a Final conclusion that reads:


Finally, the problem of patents appears to be rearing its ugly head again. VP8 is simply way too similar to H.264: a pithy, if slightly inaccurate, description of VP8 would be “H.264 Baseline Profile with a better entropy coder”. Though I am not a lawyer, I simply cannot believe that they will be able to get away with this, especially in today’s overly litigious day and age. Even VC-1 differed more from H.264 than VP8 does, and even VC-1 didn’t manage to escape the clutches of software patents.

This is a Final conclusion on your side a final statement that says "They wont get away with this Patent Violation"

And this from the Mouth from someone like you is everything mass media waits for to make up a story from. And the Stock Market reacting.

I thought MPEG directly would attack but not in my "darkest dreams" i would have thought that you would be the initial reason that starts this all, and everyone of the other side hops behind searching cover for it :P

[MfA]

Since when is "VP8 is copying H.264" opinion?
That's not the opinion part, though I would argue that for intra prediction they are both copying from MVC.
And no matter what the situation, copying creates risk of patent problems. In the messy world of video coding, things are basically patented until proven otherwise, not the other way around.
Nothing can be proven concerning patent infringement outside a court of law plus 20 years of time. Every single line of code creates risk of patent infringement. Hell, a lot of x264 encoder algorithms aren't part of the patent pool and not invented by the x264 programmers either (trellis to name but one). Can I extend that same reasoning to x264 right down to the any sane person bit?

Before the 20 years is past you have to make educated guesses and you can't do that without looking at the actual patents ... which you have not done.

[valgor]

Here is a the same source as in my Schro vs Theora comparison ( http://forum.doom9.org/showthread.php?p=1380594#post1380594 ) converted to VP8:
http://www.mediafire.com/download.php?klgwnb3wz1z

command line:
ffmpeg -r 24 -s 640x368 -i /tmp/ed640x368.yuv -vcodec libvpx_vp8 -vpre 360p -vb 1M /tmp/ed640x368-pre_360p-1M.webm

As I do not know how to produce VP8 video with constant quality, I just used ffmpeg preset with adjusted bitrate to get a file size similar to Schro and Theora files.

[PatchWorKs]

Can you actually read what I said before writing about it?

I never said there was a patent violation.

I said there might be one. There is a risk of one. It might exist. It's possible. It may or may not be the case. How many different ways do I have to put it before people realize that it's not a foregone conclusion?

Again: but it's also possible that h264 violates On2 patents ?

[Dislikeyou]

Here is a the same source as in my Schro vs Theora comparison ( http://forum.doom9.org/showthread.php?p=1380594#post1380594 ) converted to VP8:
http://www.mediafire.com/download.php?klgwnb3wz1z

command line:
ffmpeg -r 24 -s 640x368 -i /tmp/ed640x368.yuv -vcodec libvpx_vp8 -vpre 360p -vb 1M /tmp/ed640x368-pre_360p-1M.webm

As I do not know how to produce VP8 video with constant quality, I just used ffmpeg preset with adjusted bitrate to get a file size similar to Schro and Theora files.

I have noticed this in your video (But also in some other webm videos i seen today):

http://img180.imageshack.us/img180/2346/scramble.png

It only lasts for 1 sec or so.. i think it is during encoding .. similar problem to h.264 ffmpeg -mt encoding with 8 threads..

[kosmonaut]

Again: but it's also possible that h264 violates On2 patents ?

I think that is very, very unlikely. Astronomically unlikely.

One of the things some people are missing is that skepticism about WebM is not all about pro-H.264 or anti-Google feelings. Much of my concern about VP8 stems from (negative) experience with On2, and my confusion with so many FOSS advocates now accepting On2 marketing material as reliable.

I am a huge Google fan (with an Android phone in my pocket) but I remain very suspicious of anything with On2's fingerprints on it. FWIW.

[PatchWorKs]

...but i'm not talking about code quality, performances, market approach or even customers assistance, i'm talking about patents.

On2 was on the market for years before h264, don't you think they owns "some" patents for video encoding techniques ? (check their history: http://en.wikipedia.org/wiki/On2)

If so, it's possible that now Google owns some "submarine patents" (as someone called for Xiph works) that may put MPEG-LA (or associates) in troubles...

The certain fact is only that (expecially software) patents are bad.

[Dark Shikari]

...but i'm not talking about code quality, performances, market approach or even customers assistance, i'm talking about patents.

On2 was on the market for years before h264, don't you think they owns "some" patents for video encoding techniques ?MPEG-LA existed long before H.264 as well.

It's a bit tricky to get patents on standards without being part of the standardization process, and it usually involves nefarious submarining.

[PatchWorKs]

According to this BusinessWeek page (http://investing.businessweek.com/research/stocks/private/snapshot.asp?privcapId=4458054) MPEG-LA was founded in 1996.

The Duck Corporation (the previous On2 name) operates since 1990...

I believe Google lawyers knows their chickens.

EDIT: early On2 video codecs was http://en.wikipedia.org/wiki/TrueMotion

[Dark Shikari]

According to this BusinessWeek page (http://investing.businessweek.com/research/stocks/private/snapshot.asp?privcapId=4458054) MPEG-LA was founded in 1996.

The Duck Corporation (the previous On2 name) in 1990...

I believe Google lawyers knows their chickens.MPEG-LA is just a group of companies; the companies have been around much longer than the licensing organization itself.

Also, wow, does that bring back memories. "Duck Truemotion"!

[kosmonaut]

According to this BusinessWeek page (http://investing.businessweek.com/research/stocks/private/snapshot.asp?privcapId=4458054) MPEG-LA was founded in 1996.

The Duck Corporation (the previous On2 name) in 1990...

I believe Google lawyers knows their chickens.

You may be right, On2 may in fact have some patents. And I absolutely agree that software patents are evil to begin with.

That said, MPEG-LA may date from 1996, but remember, it is only a patent pool. The individual companies in the pool likely have patents going back much, much earlier than 1996. We are talking about all the heavy hitters here, after all.

According to MPEG-LA (http://www.mpegla.com/), the list of patents in the H.264/AVC patent pool is 56 pages long! MPEG-2's is merely 37 pages long. :rolleyes:

Needless to say, it's likely to be a big mess. :confused:

[PatchWorKs]

Last post for me (i'm going to sleep):
Google backs open codec against patent trolls (http://www.theregister.co.uk/2010/05/20/google_confident_on_vp8_and_patents/)

Today, when The Reg asked if VP8 was vulnerable to patent attack, Google product manager Mike Jazayeri indicated this isn't a big concern for the company.

"We have done a pretty through analysis of VP8 and On2 Technologies prior to the acquisition and since then, and we are very confident with the technology and that's why we're open sourcing," he said.
...
"Developers should be provided with detailed explanations why Google believes that no one adopting WebM will have to fear allegations of patent infringement."

And an interesting 2006 link: On2 Receives Patent for Video Optimization Technology (http://www.geniusdv.com/weblog/archives/on2_receives_patent_for_video_optimization_technology.php) where VP6 and VP7 are clearly called TrueMotion...

I believe we're going to see a "cold war" patent strategy...

[CruNcher]

From ON2 Website:
http://img295.imageshack.us/img295/1706/lolky.jpg

just do --sharpness=6 and you get the same visual result as that x264 build @ low bitrates :)

[video_magic]

That is probably not even the same two frames which are being compared. Look at the positions of some of the people relative to other things and the proportions of them being shown!; I suspect that one of those frames is one or two frame-postions behind the other.

[Keiyakusha]

To be honest both of these images looks like crap to me, equally. But actually left one, which is h264 maybe more pleasant for my eyes, when in motion.

[valgor]

I have noticed this in your video (But also in some other webm videos i seen today):

[...image...]

It only lasts for 1 sec or so.. i think it is during encoding .. similar problem to h.264 ffmpeg -mt encoding with 8 threads..

No, it seems problem with your decoder. I use mplayer and ffplay and I see no bugs. I even decoded this VP8 to png sequence with mplayer. No one image is garbaged.

[valgor]

Here is a the same source as in my Schro vs Theora comparison ( http://forum.doom9.org/showthread.php?p=1380594#post1380594 ) converted to VP8:
http://www.mediafire.com/download.php?klgwnb3wz1z

command line:
ffmpeg -r 24 -s 640x368 -i /tmp/ed640x368.yuv -vcodec libvpx_vp8 -vpre 360p -vb 1M /tmp/ed640x368-pre_360p-1M.webm

As I do not know how to produce VP8 video with constant quality, I just used ffmpeg preset with adjusted bitrate to get a file size similar to Schro and Theora files.

Here is a screenshots tile, you can compare it with Schro, Theora and original source:
http://img20.imageshack.us/img20/3599/vp8k.th.png (http://img20.imageshack.us/i/vp8k.png/)

[dragsidious]

As for Google there is really no advantage to them to show their competition where their patent portfolio is strongest or weakest ... they won't get into details for the same reason why Jobs/MPEG-LA won't publicly disclose any specific parts where the codec infringes. You have to keep your powder dry, the only time Google would be likely to go into details would be during NDA covered meetings.



Pretty much. Google going into details about everything would only serve to make their position weaker.

The thing to remember about law in general, that programmers tend to get really really wrong, is that it's designed to be interpreted. With software and languages definitions are set and languages are exact. The computer will react in a predictable manner to your input. Law stuff is not designed like that; it's ambiguous on purpose.

That is to say that you can have one group of people say that VP8 violates patents and another group say that it does not and both can be absolutely correct in their viewpoints; by all precedent and laws currently on the books. This is why in patent cases you can have a serious of court cases were one court says it's valid and another that says it's invalid. It's maddening.

--------------------------------------

As far as patent-specifics go....

There are several parts to every patent. There are things like the abstract, claims, dependent claims, and that sort of thing.

The only thing that really matters is the main claims of the patent. The abstract is mostly irrelevant except maybe to define some of the terms in the claims and the dependent claims are optional. It's the 'claims' that you have to violate to violate the patent. And you have to violate ALL of the items in the claim. If there are 10 numbered items in a patent claim and you violate 9 of them, but you skip step 5 (or whatever) then your in the clear; you do not violate the patent.

So it's technically possible that Vp8 may copy the items in the H.264 patents almost exactly, but just skip one step or do something a little bit different and then not violate the patent.

This leads to one of the major defenses that OSS has against patents: Publishing Patent Workarounds.

The idea is that you can make going after OSS projects unattractive by finding and publishing work arounds for patents that do get applied against OSS developers. The reasoning being that software is so flexible that often your going to find a way to do a algorithm slightly different and yet maintain compatibility or whatever. Most private software companies would keep these work-arounds secret since it's a advantage to for you to not have to pay patent licensing fees when all your competitors do have to pay fees.

If you are able to discover a work around and they you publish the work around then you could cost a company millions in dollars in licensing fees. With a obvious and published way to work around a patent then nobody would ever want to pay licensing for it. This way you can effectively destroy a patent without having to spend a single day in court.

If this happens enough times then patent holders are not going to want to risk their portfolio going after a low-profit and higher-risk OSS target and instead concentrate on proprietary software companies that are easy to keep quiet through NDAs.

That's the hope anyways.

-----------------------------------------------------

If your curious about how all this works and want details on how to read a patent and fight patents successfully then check out this presentation by 'Tridge'.
http://news.swpat.org/2010/03/transcript-tridgell-patents/

It's has transcripts and also links to mp4 and ogg video files of the speach.

This guy is one of the main developers behind Samba and has actually successfully driven off (or at least dealt with) patent attacks and threats by Microsoft (prior to the whole EU stuff)

[hajj_3]

Just thought i'd let people know VLC 1.1.0 pre-RC with WebM support has just been released: http://people.videolan.org/~jb/webm/ (18.0mb)

.webm files play:)

This is the same as 1.1.0 test 4 i believe, it has the problem with the cursor disappearing when you right click and some other bugs, i'm sure the official RC will have the known bugs fixed though.

[Dislikeyou]

No, it seems problem with your decoder. I use mplayer and ffplay and I see no bugs. I even decoded this VP8 to png sequence with mplayer. No one image is garbaged.

I played this from Opera browser.. i added it to my webpage and played it from the browser.

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

[buzzqw]

in HDC beta (check latest post on HDC thread) i added support for ivfenc (NIC version)

BHH

[clsid]

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.zipI have only tested the decoder (in combo with Haali splitter) and it works. Thanks!

[AgusBohemio]

ffmpeg with webm compiled in DEB package
http://www.megaupload.com/?d=YTSYPOE2

[CruNcher]

http://www.mediafire.com/download.php?lwymozzmtzi <- Vp8
http://www.mediafire.com/download.php?jtdmmqitm52 <- X264

Encoding Speed
VP8 = 12 FPS (--good --cpu-used=5)
x264 = 30 FPS (--subme 2)

The Visual difference is not that big at least the best what i saw so far compared to H.264 the most problematic thing you can see in the Vp8 encode is missing AQ else it does a pretty good job :)

[Emp3r0r]

Anyone seen a x64 direct-show filter floating around?

[poisondeathray]

Anyone seen a x64 direct-show filter floating around?

There's one a few posts up :)

[GodofaGap]

Just thought i'd let people know VLC 1.1.0 pre-RC with WebM support has just been released: http://people.videolan.org/~jb/webm/ (18.0mb)

.webm files play:)

Did this move somewhere else because the link is dead and the 1.1.0 RC has VP8 decoding removed.

[hajj_3]

the RC does have WebM support, i've tried it myself. http://www.videolan.org/vlc/releases/1.1.0-RC.html

The link was deleted as webm was added to the RC build btw.

[julius666]

http://www.mediafire.com/download.php?lwymozzmtzi <- Vp8
http://www.mediafire.com/download.php?jtdmmqitm52 <- X264

Encoding Speed
VP8 = 12 FPS (--good --cpu-used=5)
x264 = 30 FPS (--subme 2)

The Visual difference is not that big at least the best what i saw so far compared to H.264 the most problematic thing you can see in the Vp8 encode is missing AQ else it does a pretty good job :)

--ref 1, --me dia, --subme 2, no psy-rd
Is this a joke? Of course VP8 is almost as good as H264 if you use so bad settings in x264. :rolleyes:

[GodofaGap]

the RC does have WebM support, i've tried it myself. http://www.videolan.org/vlc/releases/1.1.0-RC.html

The link was deleted as webm was added to the RC build btw.
I have downloaded that and it gave me 'VLC does not support VP80.. etc.'

Also

http://forum.videolan.org/viewtopic.php?f=34&t=76798&p=252505&hilit=webm#p252505

many fixes over 1.1.0-pre4, with notably:
- x264 options update for preset/tune
- Translations update
- Multiple Qt and Mac OS X interfaces fixes
- Fixes for H264 decoding with DR, Audio Convertion, DxVA2 decoding
- DVD, flv, MP4, AVI and AVI/ODML demuxing fixes and improvements
- VP8/Webm decoding support <== REMOVED

[CruNcher]

Im not comparing the compression efficiency here im comparing the PSY Visual Difference and that seems not far of some improvements their and in speed and we have a very well Low Bitrate competitor, though most probably it will take some time for these improvements and by then H.265 will be very far into Research and of course by that time VP8 in even that improved state would be no match, so work on the future VP9 should begin as early as possible also.

[julius666]

Im not comparing the compression efficiency here im comparing the PSY Visual Difference and that seems not far of some improvements their and in speed and we have a very well Low Bitrate competitor, though most probably it will take some time for these improvements and by then H.265 will be very far into Research and of course by that time VP8 in even that improved state would be no match, so work on the future VP9 should begin as early as possible also.

Please explain what "PSY Visual Difference" means, I've never heard of it.

[CruNcher]

x264 = 12 FPS
http://www.mediafire.com/download.php?0mmzmmgtnmm

the result doesn't surprise and no PSY RD here not even RD @ all

so all in all the VP8 Encoder needs a lot of improvement and a lot solutions need to be found working in the new VPx way for things that have been found improving H.264 visualy, but all in all VP8 isn't that bad to start with :)

It is the heaviest MPEG competitor @ the moment and the more that work on it the better it will get in the future :)

[julius666]

x264 = 12 FPS
http://www.mediafire.com/download.php?0mmzmmgtnmm

the result doesn't surprise and no PSY RD here not even RD @ all

so all in all the VP8 Encoder needs a lot of improvement and a lot solutions need to be found working in the new VPx way for things that have been found improving H.264 visualy, but all in all VP8 isn't that bad to start with :)

It is the heaviest MPEG competitor @ the moment and the more that work on it the better it will get in the future :)

Oh, now I understand what you want to achieve :)
You want to dumb down H264 near to the VP8 standard and compare that to the VP8 encoder's result, to know how good is the implementation of the VP8 encoder (correct me if I'm wrong). Please make it clearer next time.
My knowledge of VP8 specs is very limited, but --me umh (or esa/tesa, if you want to be precise) and maybe --trellis 2 would be good as well, but better quality. And isn't 3 ref frames (because of that "golden frames" thing) allowed?
(And there are no weighted p-frames in VP8, you should turn that off).

[Brazil2]

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
Thanks for these tools :)
Although I haven't tried much the latest aoTuV yet but I usually prefer to use -q3 which, in my opinion, sounds better with the latest Oggenc2 from Rarewares than with aoTuV.


http://code.google.com/p/webm/downloads/detail?name=webmdshow-0.9.7.0-20100526.zip <-- Latest DirectShow filters for playback
Sorry to sound stupid but I can't find any DLL in this package ?
So I'm still using the ones from v0.9.6.0 (http://code.google.com/p/webm/downloads/detail?name=webmdshow-0.9.6.0-20100524.zip&can=2&q=).


I've been quite impressed by low bitrate VP8, can look very "watchable".
Yes quality is not bad at all but the counterpart is that files are much larger than with x264 at the same bitrate, I guess because of the lack of B-frames.

[Brazil2]

I have downloaded that and it gave me 'VLC does not support VP80.. etc.'
Get the first RC build with VP8/Webm decoding support here:
http://www.megaupload.com/?d=EU2B1PGB

[CruNcher]

Oh, now I understand what you want to achieve :)
You want to dumb down H264 near to the VP8 standard and compare that to the VP8 encoder's result, to know how good is the implementation of the VP8 encoder (correct me if I'm wrong). Please make it clearer next time.
My knowledge of VP8 specs is very limited, but --me umh (or esa/tesa, if you want to be precise) and maybe --trellis 2 would be good as well, but better quality. And isn't 3 ref frames (because of that "golden frames" thing) allowed?
(And there are no weighted p-frames in VP8, you should turn that off).


You want to dumb down H264 near to the VP8 standard and compare that to the VP8 encoder's result <- we have a winner :)
trellis would slow it down a lot more much way under the VP8 Encoder speed :) yep maybe a higher motion search would be better
Yeah but in this case Golden frames should have been off at least i didn't set the switch for them though i dunno yet what @ default the encoder does
Weighted P makes no real difference here it's not used anyways :)

Also Parkrun is a very Psy intense Source with other sources the difference would be much lower :) see my full Music Video Encode in VP8 as Nic said very watchable :)
http://www.supergenije.com/cruncher/

[GodofaGap]

Get the first RC build with VP8/Webm decoding support here:
http://www.megaupload.com/?d=EU2B1PGB
That works! Thanks. :)

[julius666]

Yeah but in this case Golden frames should have been off at least i didn't set the switch for them though i dunno yet what @ default the encoder does

I don't see any option (http://www.webmproject.org/tools/encoder-parameters/) that would turn golden-frames on or off, aren't they always enabled?

And you could use higher subme in x264. The VP8-encoder itself also has RDO (it's turned on automatically when you use lower --cpu-use than 4) which is enabled only at --subme 6 in x264. Then you could use --psy-rd too, that would give a huge quality improvement.

[Nic]

@Brazil2:
You can ABX between AoTuV and standard Vorbis at -q3? That'd be surprising - should be v.hard to tell the difference. I'm sure you won't be able to tell the difference for your video encodes, so I wouldn't worry about it (I'll put out my source code in case anyone does wanna recompile tho)

http://code.google.com/p/webm/downloads/detail?name=webmdshow-0.9.7.0-20100526.zip <--- in there is install_webdmshow.exe - running that will install the DShow filters (the DLLs).


counterpart is that files are much larger than with x264 at the same bitrate, I guess because of the lack of B-frames. bitrate determines size, so I assume you mean quality.

-Nic

@All: Remember when encoding with ivfenc to use -t to set the number of threads (probably to the number of CPUs you have). -t 4 on my Q9650 does make quite a bit of difference to the encoding speed.

[CruNcher]

I don't see any option (http://www.webmproject.org/tools/encoder-parameters/) that would turn golden-frames on or off, aren't they always enabled?

And you could use higher subme in x264. The VP8-encoder itself also has RDO (it's turned on automatically when you use lower --cpu-use than 4) which is enabled only at --subme 6 in x264. Then you could use --psy-rd too, that would give a huge quality improvement.

For x264 i used respectively 2 and 5 :) as 6 and above would slow down more as you said RD comes into play i disabled that for both especially if you go crazy as you said and using it with trellis not to speak of --trellis 2 it would get a lot slower then the VP8 encoder @ --good ;)
Hmm indeed seems Golden Frames are always on only the alternate reference frames aren't

[ricardo.santos]

Hi everyone!

i've been trying Vp8 for a week now but im faced with a problem, im using a ffmpeg vp8 build but i have to encode the audio separately with lamexp because the ffmpeg build doesnt have libvorbis that gives better results than the default vorbis encoder in ffmpeg

i start with :

ffmpeg -i 01.mp4 -b 450k -threads 2 -an -s 480x192 video.webm
ffmpeg -i 01.mp4 -acodec pcm_s16le -vn test.wav
oggenc2.exe --resample 22050 -b 48 test.wav

then mux mkv and ogg it with mkvtoolnix and then "parse" the file with MKCLEAN

mkclean.exe --doctype 4 final.mkv final.webm

everything works fine but ive noticed that medianfo reports video bitrate as 563k and overal bitrate 631k.

So far if i need to achive a certain bitrate i have to setup the bitrate value as half of what it should be, for example to achieve 900k i need to setup the encode with 450k. this way mediainfo reports the correct bitrate.

When setting up an encode with 450k the ffmpeg windows reports the video is being encoded with 450k but the mediainfo reports 900k as video bitrate.

I tried 3 encodes (wmv, theora and x264) and at 900k they all have pretty much the same size, with vp8 at 900k i get a much bigger file, i i setup with 450k i get the same size i get with the other 3 foprmats at 900k.

Can anyone tell me what i'm doing wrong or is it a mediainfo bug?

This is the vp8/ffmpeg build im using:
http://micksam7.com/blog/index.php/?p=743

Thanks

[Dislikeyou]

When setting up an encode with 450k the ffmpeg windows reports the video is being encoded with 450k but the mediainfo reports 900k as video bitrate.

[22:22] <Dark_Shikari> mediainfo is quite often horrifically unreliable
[22:22] <derf> That actually sounds like a framerate doubling problem.
[22:22] <Dark_Shikari> and yeah, that
[22:22] <@jk8> could be related to the timebase=framerate*2 hack
[22:22] <derf> It's a really big coincidence that it would be off by exactly a factor of 2.
[22:23] <derf> Yes, that is what I'm suggesting.
[22:23] <Dark_Shikari> mediainfo iirc is not very accurate for bitrate of VFR videos
[22:23] <Dark_Shikari> I think it doesn't even try.
[22:23] <Dark_Shikari> which could explain that.

[poisondeathray]

I tried 3 encodes (wmv, theora and x264) and at 900k they all have pretty much the same size, with vp8 at 900k i get a much bigger file, i i setup with 450k i get the same size i get with the other 3 foprmats at 900k.


How are you reading the "size" or "bigger file"? Do you mean "bigger file" as in "filesize" as in windows explorer?

filesize = bitrate x running time

if your vp8 encode has a larger filesize (and assuming same running time) , this implies the bitrate is higher than that of the other encodes (disregarding container size differences)

[GodofaGap]

@Brazil2:
You can ABX between AoTuV and standard Vorbis at -q3? That'd be surprising - should be v.hard to tell the difference. I'm sure you won't be able to tell the difference for your video encodes, so I wouldn't worry about it (I'll put out my source code in case anyone does wanna recompile tho)
Moreover, I remember AoTuV b2 was actually merged into libvorbis 1.1 and I think they were planning on continuing updating libvorbis with AoTuV improvements. So even libvorbis is AoTuV. :)

(although it might be behind)

@Nic:
It's a bit much to ask I know, but would you consider adding piped raw yv12 input?

Thanks for the work in any case. :)

[ricardo.santos]

@Dislikeyou
Thanks for the info

[22:22] <derf> It's a really big coincidence that it would be off by exactly a factor of 2.

with 225k mediinfo reports 450, with 450k mediainfo reports 860... just video bitrates...no audio envolved

How are you reading the "size" or "bigger file"? Do you mean "bigger file" as in "filesize" as in windows explorer?

filesize = bitrate x running time

if your vp8 encode has a larger filesize (and assuming same running time) , this implies the bitrate is higher than that of the other encodes (disregarding container size differences)

thats exactly what is happening, the source file is equal for all encodes in the various formats, even if i disregard the mediainfo reports, the filesize "says" the bitrate is not right, i can only think that the bitrate is higher to explain that.

has anyone had similar experiences? If there's a bug somewhere people could be wrongfully judging quality without noticing that the bitrate is twice as much as x264.

i've tried the ivfenc utility by nic and the same problem appears.


wmv, theora, x264 @450k = 2,90 MB

ffmpeg with vp8 results:

vp8 @ 450k = 3,64 MB
vp8 @ 225k = 2,90 MB

i know it doesnt look that much but on a 10min video the difference in filesize is very noticeable

[Nic]

Hmmm, I just tried running (script has 1400 frames at 23.976):
x264 a.avs -B 450 -o a.264 -p 2
ivfenc --target-bitrate=450 a.avs a.ivf -p 2

To do a similar test and the files were almost exactly the same size:
3,299,704 a.264
3,298,996 a.ivf

one pass is less accurate:
3,496,651 a.264
3,371,109 a.ivf

But I certainly don't see the doubling or difference you do. Anyone else having the same issue as Ricardo?

GodofaGap: AoTuV has been updated quite a bit since then :) raw yv12 input? Maybe ;)

[ricardo.santos]

will try a 2 pass with ffmpeg and ivfenc

[ricardo.santos]

Source: 1 min avi file

ivfenc @450k, 2 pass= 3,23 MB
x264 @450k, 2 pass= 3,21 MB
ffmpeg/vp8 @450k, 2 pass= 4,22 MB
ffmpeg/vp8 @225k, 2 pass= 3,30 MB


video converted with @225k

General
Complete name : C:\video.webm
Format : Matroska
File size : 3.30 MiB
Duration : 1mn 0s
Overall bit rate : 462 Kbps
Writing application : Lavf52.64.0
Writing library : Lavf52.64.0

Video
ID : 1
Format : V_VP8
Codec ID : V_VP8
Bit rate : 453 Kbps


it seems the 2 pass solved the ivfenc problem, so im guessing its an ffmpeg related problem? Can anyone share how you're doing the 2 pass conversion with ffmpeg?

[Dislikeyou]

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


Your version crash when using --timebase=<arg>

[Leeloo Minaï]

The problem is related to ffmpeg, i tried the webm build posted in this thread and it seems it does not respect at all targeted video bitrate...

Nic's ivfenc is far more reliable.

[Nic]

Dislikeyou: Probably, but why would you want to use a timebase different to the one that's coming in via Avisynth? That's likely to cause issues. Change the framerate in AviSynth if you want something different.

EDIT: Actually it's a problem with how I went from C -> C++ for ivfenc. D'oh! So crashes on the parsing of the timebase. I've fixed it, will test sometime tomorrow and upload a new version.

[Sagittaire]

One2tech say "VP8 on par with H264 (x264) for PSNR" ... and it's not the case in my test.

Actualy at maximum quality (with One2Tech setting) VP8 is not on par with x264 for visual quality in medium quality encoding in my test (q20-25 meduim quality encoding).

WebM encoder is really complete implementation for VP8?

[iwod]

One2tech say "

WebM encoder is really complete implementation for VP8?

Well, there is only one encoder, one implementation of VP8, that is WebM. Dont expect there will be any others.

[CruNcher]

http://www.mediafire.com/download.php?dxzkjtmqjnj <- another test Vp8 had a hard time on this one as the source is very noisy Broadcast Mpeg-2 not like the RED ONE before

[Nic]

No real difference, but http://nic.dnsalias.com/ivfenc.zip (v1.3)

Updated to latest git version (with added .avs support)
Doesn't crash when you ctrl+c to quit early now
--timebase= doesn't do anything, but doesn't crash it now
ARCH_X86 isn't set in vpx_encoder.c which means FLOATING_POINT_INIT/RESTORE isn't getting called (bug in the git repo code?)
Defaulted threads to 4 - just runs faster that way, why wouldn't you want it :)

-Nic

[nurbs]

WebM encoder is really complete implementation for VP8?
It's the only implementation there is, but there is still stuff that is missing in the encoder like psy-optimizations and adaptive quantization and there may be some remaining bugs (that aren't in the bitstream spec and therefore can be fixed). If that works like in x264 that would lower PSNR of course. Also according to discussions in the webm development mailing list AQ will come with a relatively high overhead, up to 2 bits per macroblock. That would be 60 kbit/s on a 640x480@25p video in the worst case.

One2tech say "VP8 on par with H264 (x264) for PSNR"
That, along with the claim I've repeatedly read that VP8 will be up to 50% more efficient than H.264, is called marketing (AKA lies).

Updated to latest git version (with added .avs support)
Nice :-)

Defaulted cpu to 16
What does that mean? Is that --cpu-used? In that case wouldn't that mean very low quality?

edit:
All the threads on the webm discussion boards (http://www.webmproject.org/about/discuss/) are suddenly gone. :confused:

[Nic]

@nurbs: Do you know, I think you might be right (i.e I'm an idiot) - the description just seemed to mean how much cpu was used (and with it at 16 the CPU would reach near 100% which seemed better). But looking thru the code, setting the CPU high does affect the quality. Think I'll revert that change.

[CruNcher]

You could make it ffmpeg default of 3 :)
and those that don't want RD should use 4 or 5
Though this thinking of On2 compared to subme faster encode = lower number = less quality makes sense as faster encode = higher number = less quality
and --deadline reversed lower number = faster speed upto 0 which changes to infinite time (--best) and 1 being realtime (--rt)

[hajj_3]

Mkvtoolnix 4.0.0 has just been released with WebM support :)

http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.0.0-setup.exe

changelog: http://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog

Still no support in the latest MPC-HC builds :( I wonder when they will add support.

[nurbs]

MPC-HC uses ffmpeg for decoding IIRC, so whenever VP8 is merged there the player will support it.

[ricardo.santos]

Been trying ffmpeg and ivfenc at same bitrates, just for "fun" nothing "pro", you can watch 4 examples @:

http://ricardouk.com/videos

Altough ivfenc produces "clear" images it has more macroblocks than ffmpeg, to me it looks like ffmpeg tries to reduce macroblocks by "undefining" the video.

Still videos converted with Ivfenc look great, with ffmpeg taking advantage on "faster" videos.

[clsid]

MPC-HC uses ffmpeg for decoding IIRC, so whenever VP8 is merged there the player will support it.
It only uses a small subset of ffmpeg.

Playing webm files with MPC is already possible with the WebM DirectShow filters, or Haali Spitter plus just the VP8 decoder.

[Gromozeka]

Nic
you can add pipe? :)

ffmpeg -i 1.avs -f yuv4mpegpipe - | ivfenc - out.ivf --yv12 -t -p 1 --best --cpu-used=0 --target-bitrate=400 --end-usage=0 -v \
--minsection-pct=5 --maxsection-pct=800 --kf-min-dist=0 --kf-max-dist=360 --token-parts=2 --static-thresh=0 --min-q=0 --max-q=63\

[CruNcher]

Hmm Nic STRG+C crashes with --cpu-used= 1,2 and 6 <- very strange behavior :D

doesn't happen with the first build

starts with the 1.2 build :D the crash is in avifil32.dll

[Nic]

Can't reproduce - but up'd a new version handling it a different way (http://nic.dnsalias.com/ivfenc.zip) :)

[CruNcher]

Can't reproduce - but up'd a new version handling it a different way (http://nic.dnsalias.com/ivfenc.zip) :)

fixed :)

PS: How about making --drop-frame=0 default :)

[Ulf]

MediaInfo reports a frame rate that is twice the true framerate for a 'webm' file (muxed with Mkvtoolnix 4.0.0). MPC plays the file OK.

If I extract the 'ivf' and 'ogg' files (using mkvextract.exe) and remux them with mkvmerge, MediaInfo reports the true frame rate but MPC plays the file at half frame rate.

Does anyone have a clue whats going wrong?:confused:

[ricardo.santos]

i noticed that but the videos play fine and i know the true frame rate, could be a mediainfo bug, webm is a "new" format.

[Dislikeyou]

Im no expert but i think it reports double frame rate cause ivf encoded movies has doubled frames.. i mean if u extract the same movie to png u will notice that frame 1 and 2 are different.. but frame 3 and 4 are same and 5 and 6 are same and so on until the end.. it basically duplicates the frames.. so frame 250 in original movie will be frame 500 in the ivf encoded movie.. so i dont know if it is mediainfo bug or not

[wiak]

remember people some of the comparisons use "default" encoding settings, so most codecs will look bad, there are many settings you can tweak in both VP8 and x264 ;)

[Nic]

http://nic.dnsalias.com/ivfenc.zip

Has the default of 0 for --drop-frame (was 70)
If input parameter is - then can take a piped Y4M source.
e.g. ffmpeg -i file.mpg -f yuv4mpegpipe - | ivfenc - out.ivf
(for Gromozeka)

Think I've had enough now :) - mod'd src included in the zip (changes are marked with "// Nick")

-Nic

[Koti]

Thank you :)

[Gromozeka]

http://nic.dnsalias.com/ivfenc.zip

Has the default of 0 for --drop-frame (was 70)
If input parameter is - then can take a piped Y4M source.
e.g. ffmpeg -i file.mpg -f yuv4mpegpipe - | ivfenc - out.ivf
(for Gromozeka)

Think I've had enough now :) - mod'd src included in the zip (changes are marked with "// Nick")

-Nic

wow, thanks Nic
This work for avi with ffmpeg
ffmpeg -i %1 -threads 2 -acodec libmp3lame -vol 384 -ar 48000 -ac 2 -ab 128k -aq 3 -y audio.mp3 -f yuv4mpegpipe -\
| ivfenc - video.ivf -t 2 -p 1 --good --target-bitrate=800
ffmpeg -i video.ivf -vcodec copy -i audio.mp3 -acodec copy -y %1_out.avi
del video.ivf
del audio.mp3
he eat other source (sorry my english)

[Selur]

thanks for the 64bit compile of the decoder&splitter filter :)

[ricardo.santos]

is there a way to pipe mencoder to ivfenc without using mkfifo and cygwin?

Mencoder handles subs natively, ffmpeg doesnt, been trying to find mencoder binaries with vp8 but so far i only found linux ones.

Anyone managed to get hold of one? Can you share it?

[wiak]

here is some encodes by IVFEnc 0.9.0 - VP8 Encoder - Nic's AviSynth Input Mod v1.5 (Jun 7 2010)
so you can judge for you self

Browser:
http://s3.nwgat.net/sintel/sintel.html (HTML5 <Video>)

Chrome 6.0.422
http://www.google.com/chrome/eula.html?extra=devchannel
Opera 10.54 Build 21868
http://labs.opera.com/news/2010/05/19/
Firefox Minefield 3.7a4
http://nightly.mozilla.org/webm/

Direct:
http://s3.nwgat.net/sintel/sintel_trailer_1080p_vp8_vorbis.webm (VP8 6Mbps Vorbis 160kbps)
http://s3.nwgat.net/sintel/sintel_trailer_720p_vp8_vorbis.webm (VP8 3Mbps Vorbis 160kbps)
http://s3.nwgat.net/sintel/sintel_trailer_480p_vp8_vorbis.webm (VP8 1.5Mbps Vorbis 160kbps)

2 Pass from encoder parameters page at http://www.webmproject.org/tools/encoder-parameters/#2-pass_faster_vbr_encoding
ivfenc sintel_trailer_2k_720p24.y4m 720p.output_vp8.ivf \ --i420 -p 2 -t 4 \ --best --target-bitrate=3000 --end-usage=0 \ --auto-alt-ref=1 -v \ --minsection-pct=5 --maxsection-pct=800 \ --lag-in-frames=16 --kf-min-dist=0 --kf-max-dist=360 \ --token-parts=2 --static-thresh=0 --drop-frame=0 \ --min-q=0 --max-q=60 --threads=4

sources:
http://media.xiph.org/video/derf/y4m/720p/sintel_trailer_2k_720p24.y4m
http://media.xiph.org/sintel/sintel_trailer-audio.flac
http://durian.blender.org/

[wiak]

http://nic.dnsalias.com/ivfenc.zip

Has the default of 0 for --drop-frame (was 70)
If input parameter is - then can take a piped Y4M source.
e.g. ffmpeg -i file.mpg -f yuv4mpegpipe - | ivfenc - out.ivf
(for Gromozeka)

Think I've had enough now :) - mod'd src included in the zip (changes are marked with "// Nick")

-Nic
hey nice, you should put your new stuff on your index.html page, much easier to find than going thru 100 posts :p

[hajj_3]

WebM v0.9.8.1 installer and sourcecode are out now: http://code.google.com/p/webm/downloads/list

Changelog:

*Fixed bug when webmmux filter not connected to file writer.
*VP8 encoder filter now has a preview pin.
*VP8 encoder filter now supports FORMAT_VideoInfo2.
*VP8 encoder filter now allows you to set config on-the-fly, while
graph is running.
*VP8 encoder filter added support for spatial and temporal resampling config.

[wiak]

WebM v0.9.8.1 installer and sourcecode are out now: http://code.google.com/p/webm/downloads/list

Changelog:

*Fixed bug when webmmux filter not connected to file writer.
*VP8 encoder filter now has a preview pin.
*VP8 encoder filter now supports FORMAT_VideoInfo2.
*VP8 encoder filter now allows you to set config on-the-fly, while
graph is running.
*VP8 encoder filter added support for spatial and temporal resampling config.
thats the dshow encoder, IVFEnc commandline encoder allready has support for many more things and is more useful, and has proper documentation on webmproject.org


Minefield(Firefox 3.7a5pre, soon 4.0) nightly builds now have WebM decoding support. You don't have to use the old 3.7a4 WebM build anymore.

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
nope you still have to use webm build

[wiak]

It works fine here with the latest 20100609 nightly build. html5test.com also confirms WebM support and I've viewed WebM videos on Youtube just fine.

http://img38.imageshack.us/img38/1624/webml.png

http://img823.imageshack.us/img823/163/mfwebm.png

http://blog.pearce.org.nz/2010/06/webm-has-landed-on-firefox-nightlies.html

hmm
can you test http://s3.nwgat.net/sintel/sintel.html ? opera, chrome and vp8 dshow filter plays it
this is what i get from Chrome 6.0.227
http://img.techpowerup.org/100609/Capture055.png

[Atak_Snajpera]

Direct:
http://s3.nwgat.net/sintel/sintel_tr...p8_vorbis.webm (VP8 6Mbps Vorbis 160kbps)
http://s3.nwgat.net/sintel/sintel_tr...p8_vorbis.webm (VP8 3Mbps Vorbis 160kbps)
http://s3.nwgat.net/sintel/sintel_tr...p8_vorbis.webm (VP8 1.5Mbps Vorbis 160kbps)
http://img816.imageshack.us/img816/2617/72767529.png
48fps???? It looks that we have a serious bug here in v0.9.8.1 decoder.

[EricJ2190]

MediaInfo for me has always reported double the actual framerate for VP8, so I don't think it is the new decoder.

[wiak]

MediaInfo for me has always reported double the actual framerate for VP8, so I don't think it is the new decoder.
its more of a splitter or decoder issse as the encoder got the right input framerate
btw mine types on amazon s3 is a bitch hehe ;)
the video now works in firefoxy!

[Atak_Snajpera]

If you import .webm via AviSynth (DirectShowSource) then you get true fps*2 and true framecount*2. Duration is correct but rest is wrong.

UPDATE: remuxing with MKVToolnix 4.0 and setting correct FPS solves this problem. It seams that this problem must be related to broken matroska muxer!

[wiak]

http://img.techpowerup.org/100610/Capture056.png
mpc-hc plays it right, atleast at 24fps even when decoder reports its 48fps ;)
using haali splitter, mpc-hc x64, vp8 dshow decoder

[Atak_Snajpera]

mpc-hc plays it right, atleast at 24fps even when decoder reports its 48fps
It must be 24fps not some stupid 48fps!!! This is a obvious bug.

[wiak]

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.

vp8 is bleeding edge new, x264 has been in development for around 6 years and is the most advanced and technicly advanced codec.. and they basicly had full reign on what metods they could use, vp8 is alot diffrent when it comes to methods and they also had to evade patents when making it

people should realy compare x264 from around 5 years ago to a few weeks old VP8

btw, the single simple reason you see bad quality on files are the encoder settings, if you use 1-Pass Fast VBR Encoding it looks like XviD, if you use high quality 2-pass it will look like h264
http://www.webmproject.org/tools/encoder-parameters/#10_sample_command_lines

same goes for any codec

[Midzuki]

vp8 is bleeding edge new, x264 has been in development for around 6 years and is the most advanced and technicly advanced codec..

OTOH, Dark Shikari has written:

Initially I was intending to go easy on On2 here; I assumed that this encoder was in fact new for VP8 and thus they wouldn’t necessarily have time to make the code high-quality and improve its algorithms. However, as I read through the encoder, it became clear that this was not at all true; there were comments describing bugfixes dating as far back as early 2004. That’s right: this software is even older than x264! I’m guessing that the current VP8 software simply evolved from the original VP7 software. Anyways, this means that I’m not going to go easy on On2; they’ve had (at least) 6 years to work on VP8, and a much larger dev team than x264’s to boot.

Now, just my "stupid" opinion: to me, the whole "WebM thing" is 99.9% hype and 0.1% something practical, interesting, or useful. And if, someday, it happens to rival Adobe's Flash, I will set my web browser to block every "WebM stuff" as well.

:)

[wiak]

OTOH, Dark Shikari has written:

Initially I was intending to go easy on On2 here; I assumed that this encoder was in fact new for VP8 and thus they wouldn’t necessarily have time to make the code high-quality and improve its algorithms. However, as I read through the encoder, it became clear that this was not at all true; there were comments describing bugfixes dating as far back as early 2004. That’s right: this software is even older than x264! I’m guessing that the current VP8 software simply evolved from the original VP7 software. Anyways, this means that I’m not going to go easy on On2; they’ve had (at least) 6 years to work on VP8, and a much larger dev team than x264’s to boot.

Now, just my "stupid" opinion: to me, the whole "WebM thing" is 99.9% hype and 0.1% something practical, interesting, or useful. And if, someday, it happens to rival Adobe's Flash, I will set my web browser to block every "WebM stuff" as well.

:)
the first video codec flash used was a On2 Codec named VP6, some years before it started to use h264

btw do you support vorbis and matroska?
if so, you might change your view a little, when google announced webm, they gave a huge boost to both vorbis and matroska as they are part of the offical webm spec

that is supported by well over 40 software and hardware companys including amd, nvidia, qualcomm, arm, broadcom, even intel has hinted they would support it :p

so basicly both the PC and mobile markets support webm

you should also remember you are quoting the opposite side
much like if a microsoft employee said something about google product

[Midzuki]

the first video codec flash used was a On2 Codec named VP6, some years before it started to use h264

Wrong. "Everything" began with the Sorenson codec.

btw do you support vorbis and matroska?
if so, you might change your view a little, when google announced webm, they gave a huge boost to both vorbis and matroska as they are part of the offical webm spec

that is supported by well over 40 software and hardware companys including amd, nvidia, qualcomm, arm, broadcom, even intel has hinted they would support it :p

so basicly both the PC and mobile markets support webm

One thing at a time, please. :)
In my book at least,
to support Vorbis and Matroska
is different from
accepting the WebM subcontainer + the VP8 codec.
And just as a side note, one of the big mistakes of the Vorbis development was the insistence on the "symbiosis" with the Ogg container. IF the Vorbis codec itself supported a (less-efficient) constant-frame-size mode, then Vorbis audio could be easily and properly muxed into AVI files :devil: :D, which surely would help to make Vorbis much more popular than it has ever managed to be.

you should also remember you are quoting the opposite side
much like if a microsoft employee said something about google product

Not really. You misunderstood what I wrote.

[Atak_Snajpera]

Now, just my "stupid" opinion: to me, the whole "WebM thing" is 99.9% hype and 0.1% something practical, interesting, or useful. And if, someday, it happens to rival Adobe's Flash, I will set my web browser to block every "WebM stuff" as well.

If WebM stays free then it will replace flv/mp4 (h264/aac) very fast in future. Nobody likes to pay extra (youtube or tv stations).

then Vorbis audio could be easily and properly muxed into AVI files
Who cares about ancient avi container?? Vast majority of HD content is stored in MKV.

[MasterNobody]

you should also remember you are quoting the opposite side
much like if a microsoft employee said something about google product
OK. I will quote VP8 source code :) :
vp8/encoder/rdopt.c (http://review.webmproject.org/gitweb?p=libvpx.git;a=blob;f=vp8/encoder/rdopt.c;h=a6bd8e86dce0312e7b6259c4460d1a8cb503b2de;hb=00d566eae1591078ecbadcaf67e30b2778c06b4e#l1118)
// FIX TO Rd error outrange bug PGW 9 june 2004
vp8/common/boolcoder.h (http://review.webmproject.org/gitweb?p=libvpx.git;a=blob;f=vp8/common/boolcoder.h;h=66f67c2843420668e4c11855298fcb143103766b;hb=00d566eae1591078ecbadcaf67e30b2778c06b4e#l15)
vp8/common/x86/boolcoder.cxx (http://review.webmproject.org/gitweb?p=libvpx.git;a=blob;f=vp8/common/x86/boolcoder.cxx;h=cd9c495bfc36cbe71d313f31860b1d0347ba61b5;hb=00d566eae1591078ecbadcaf67e30b2778c06b4e#l13)
/* Arithmetic bool coder with largish probability range.
Timothy S Murphy 6 August 2004 */
vp8/encoder/treewriter.h (http://review.webmproject.org/gitweb?p=libvpx.git;a=blob;f=vp8/encoder/treewriter.h;h=075df50caa3935a350d5706e12dab764e28f772e;hb=00d566eae1591078ecbadcaf67e30b2778c06b4e#l15)
/* Trees map alphabets into huffman-like codes suitable for an arithmetic
bit coder. Timothy S Murphy 11 October 2004 */

[Midzuki]

If WebM stays free then it will replace flv/mp4 (h264/aac) very fast in future. Nobody likes to pay extra (youtube or tv stations).

OK.

Who cares about ancient avi container?? Vast majority of HD content is stored in MKV.

I meant: Vorbis (probably) would have become a very-popular audio format IF it could be duly-supported in the AVI container since "sometime before the year 2000". Nothing at all to do with "Hi-Def content in MKV".

P.S.: I thought that I was writing in English.
But probably I've been wrong since my very first post on the Doom9 forums.

:( :( :(

[julius666]

they gave a huge boost to both vorbis and matroska as they are part of the offical webm spec

that is supported by well over 40 software and hardware companys including amd, nvidia, qualcomm, arm, broadcom, even intel has hinted they would support it :p


No. They created a new container based on matroska (with a very stupid name). This new container is the well-supported one, not matroska. That means, webm is a very powerful competitor of matroska, and if "wins", then say bye-bye to the features not represented in it (like soft-linking, ordered chapters, etc).

The support of Vorbis is nice though (not that there is any other real opensource alternative).

And - i have to say based on my tests - the quality of VP8 is far acceptable. Not good, but acceptable (at least for web, and with best possible encoding settings).

So webm isn't a clearly good or bad thing. But the hype around it is surely too big.

[Atak_Snajpera]

They created a new container based on matroska (with a very stupid name).
I would rather say new extension not new container.

That means, webm is a very powerful competitor of matroska, and if "wins", then say bye-bye to the features not represented in it (like soft-linking, ordered chapters, etc).
.webm (vp8/vorbis) is like .flv (vp6/mp3). It will be mainly used for internet content not for storing your movie colection on hdd.

[nurbs]

Isn't webm a subset, not an extension? What happens if you feed a mkv to a webm splitter and vice versa?

[Atak_Snajpera]

All i can say that even old mkvmerge can open new .webm format ;)
http://img130.imageshack.us/img130/714/41914912.png

What happens if you feed a mkv to a webm splitter and vice versa?
offical webm splitter will only recognize vp8 and vorbis because nothing else is allowed in web matroska specification.

[nurbs]

A subset then. I hope device manufacturers include a full matroska splitter in future devices and not just webm. Were chapters and subtitles really too much to ask for?

[julius666]

I would rather say new extension not new container.

At initial release, WebM supports a subset of the Matroska specification. http://www.webmproject.org/code/specs/container/ :)

.webm (vp8/vorbis) is like .flv (vp6/mp3). It will be mainly used for internet content not for storing your movie colection on hdd.

Yeah, it will be so probably. But we will see.

And has anyone got any clue, why they didn't allowed subtitles (.srt at least)? It could come handy on the web too, for example youtube has subtitles itself. :confused:

[ricardo.santos]

And has anyone got any clue, why they didn't allowed subtitles (.srt at least)? It could come handy on the web too, for example youtube has subtitles itself. :confused:

http://forum.doom9.org/showthread.php?p=1396575#post1396575

[IgorC]

http://www.hydrogenaudio.org/forums/index.php?showtopic=76272

http://www.hydrogenaudio.org/forums/index.php?showtopic=74345&st=0

+40-50% speed boost for the same quality.

[foxyshadis]

vp8 is bleeding edge new, x264 has been in development for around 6 years and is the most advanced and technicly advanced codec.. and they basicly had full reign on what metods they could use, vp8 is alot diffrent when it comes to methods and they also had to evade patents when making it

people should realy compare x264 from around 5 years ago to a few weeks old VP8

No thank you; I'm encoding video now, not five years ago, and I'm unwilling to pull punches because it's young. x264 didn't deserve that consideration 6 years ago when it barely competed with xvid and divx 5 (the gold standards), but by 5 years ago it was already better at any speed or size. AVC/h.264 already had the backing of major companies and wasn't going to need to be re-encoded later, unlike VP7 or Quicktime's later proprietary codecs. Plus VP3/4/5/6/7/8 has actually had almost ten years of development - the real problem was that On2's programmers just weren't very good at building maintainable software, and piled hack upon hack for years to get things working. Theora was a mess, the leaked VP6.2 was a mess, WebM is a mess, all of them were dedicated to maximizing PSNR above visual quality, and all shared so much similar code that it looks like no one ever stopped to go back and totally rewrite old code with lessons learned. I wonder if it was too much programmer churn over the years or just a cultural flaw at the company.

As far as I'm concerned it's a premature announcement intended to create a great deal of FUD while Google works on VP9 (or VP8.1) due to the very real flaws of VP8, and vendors who implement it now without a seamless upgrade path to a coming VP9 are going to be burned. It's a very IBM/Microsoft/Oracle move, and cements in my mind how willing Google is to use their tactics against them. I won't abandon them, of course, but I'm simply wary and won't be buying into the WebM hype until it's a lot more than just hype.

Of course, for actual cutting edge development beyond x264's eventual plateau, go look at JCTVC's TMuC (Test Model under Consideration). Weird name, amazing performance on low bitrates, if you can wait 10-40 minutes per frame.

[raeltheimperialaerosolkid]

Sorry for the newbie question but I was wondering if this codec has some chance to be integrated in meGUI. Despite of its performance I would really give it a try in some personal test feeding it with avisynth.

[nurbs]

As with most open source projects the question is if anyone wants to write support for it. If the current developers don't want to write it or consider it low priority you'll have to wait until they do or until somebody submits a patch adding support.

Also if you want to try it just download the encoder Nic posted on page 11 of this thread and try it out. Command lines aren't hard.

[CruNcher]

No thank you; I'm encoding video now, not five years ago, and I'm unwilling to pull punches because it's young. x264 didn't deserve that consideration 6 years ago when it barely competed with xvid and divx 5 (the gold standards), but by 5 years ago it was already better at any speed or size. AVC/h.264 already had the backing of major companies and wasn't going to need to be re-encoded later, unlike VP7 or Quicktime's later proprietary codecs. Plus VP3/4/5/6/7/8 has actually had almost ten years of development - the real problem was that On2's programmers just weren't very good at building maintainable software, and piled hack upon hack for years to get things working. Theora was a mess, the leaked VP6.2 was a mess, WebM is a mess, all of them were dedicated to maximizing PSNR above visual quality, and all shared so much similar code that it looks like no one ever stopped to go back and totally rewrite old code with lessons learned. I wonder if it was too much programmer churn over the years or just a cultural flaw at the company.

As far as I'm concerned it's a premature announcement intended to create a great deal of FUD while Google works on VP9 (or VP8.1) due to the very real flaws of VP8, and vendors who implement it now without a seamless upgrade path to a coming VP9 are going to be burned. It's a very IBM/Microsoft/Oracle move, and cements in my mind how willing Google is to use their tactics against them. I won't abandon them, of course, but I'm simply wary and won't be buying into the WebM hype until it's a lot more than just hype.

Of course, for actual cutting edge development beyond x264's eventual plateau, go look at JCTVC's TMuC (Test Model under Consideration). Weird name, amazing performance on low bitrates, if you can wait 10-40 minutes per frame.

Thats not the truth it rather depends from what side you view it but in the early days X264 was roughly be able to beat XviD on the Visual side of things. First big advances came with Haalis AQ work and later Dark_Shikari enhancing all this which then became VAQ and even bring it up to PSY-RD which was a long process that all started with a Avisynth filter idea as you know and later became VAQ and PSY-RD.

True is that the On2 guys as you said where not really interested in these things though that's not 100% true either as some in the team are, else there wouldn't be the Sharpness setting --sharpness= which is a very simple thing the same effect as you would manually set --deadzones-inter/intra in x264 but it is a step into the right thinking that PSNR isn't everything of some On2 guys, hopefully that's gonna mature now in the heads of On2 Devs when new ones gonna bring it forward on the list :).

And sorry your attitude how you downplay this is crazy but On2 can't be really compared they had so much more problems to face then any of the X264 developers they had to be very careful in how they implement things and had to always be trying to find similar quality solutions, working under these conditions is something entirely different then how the X264 guys worked (unrestricted) they got their Base from MPEG (mother) and had no limits in what they do that is a completely different base to begin with (also they had no decision in anything concerning the bitstream that they know would have with VP9 hopefully).
And in those regards On2 did a great Job never the less if they succeed with it we gonna see sooner then later but the base to work with isn't that bad as many would like it to be and im very confident concentrating on 2 major things now AQ/Speed and VP8 could get much more attractive then it already is (to a bigger audience).
But wee need also a competitor against H.265 and that will be VP9 which will be a new start hopefully with better base spec to begin with rather then code of 5 years of work (if MPEG by then doesn't have patent attacked it down and failed). For MPEG Vp8 currently is like a Virus and they gonna try to defeat that fast, if they can't they have to rethink their current situation both is a good thing so i don't worry im outright happy with it and even if we just see WMV disappearing from the WEB slowly it would be a big win already :).

[nurbs]

And sorry your attitude how you downplay this is crazy but On2 can't be really compared they had so much more problems to face then any of the X264 developers they had to be very careful in how they implement things and had to always be trying to find similar quality solutions, working under these conditions is something entirely different then how the X264 guys worked (unrestricted) they got their Base from MPEG (mother) and had no limits in what they do that is a completely different base to begin with.

Thats saying that it's okay that On2's VP8 implementation is bad because they didn't have much leeway with the standard due to software patents which is nonsense, since the two aren't dependent on each other.

[CruNcher]

Ehh Nurbs Video Processing isn't easy it's a patent field and sure the pressure from that it's letting you become very careful especially being a big company that tries to be competitive here, and this carefulness slows down everything and searching workarounds is like finding entirely new things that didn't exist before or workarounds that are similar in the end result that's heavy pressure and almost impossible without mistakes in such a company environment with deadlines and a huge PR machine.

[julius666]

Thats not the truth it rather depends from what side you view it but in the early days X264 was roughly be able to beat XviD on the Visual side of things. First big advances came with Haalis AQ work and later Dark_Shikari enhancing all this which then became VAQ and even bring it up to PSY-RD which was a long process that all started with a Avisynth filter idea as you know and later became VAQ and PSY-RD.

Yeah, too bad that On2's software is older than x264. Some parts of the code were written in 2004.

[CruNcher]

And ? if it's a extension of VPx that is normal don't you think surely you wouldn't write everything from scratch, anyways just lets wait and see what happens in the future and not look bad @ the past that is over and not very useful @ all ;)
I know VPx since VP3 now back in the days DivX started their Project Moyo and SBC was the most popular and VP3 was very promising back then already :) and i saw the results now in Motion of VP8 i find it very acceptable for a Next Generation Codec compared for example vs other H.264 incarnations like Real which is slowly fading away from the market.
Sure it can't beat X264 if you go maximum complexity with it but if you stay @ the level of VP8 complexity it doesn't do that bad Visually without RD (X264 looses PSY-RD but still has VAQ so still always wins currently also in being faster so could easily go 1 quality up also), there are definitely still problems even in the ABR RC and many more problems like inloop failing @ manual constant quality encoding, but all in all these look like very small problems that are fixable over time and will improve it visually a bit, Encoding speed improvements are also one of the most importants to be able to say @ the same level with X264 @ the same complexity, i see already many people are shocked by the default speed the encoder is producing and the quality differences each option can cause though as the setting up is rather more complex and in the other way also not then what you are used from a H.264 encoder it seems normal, personally i wouldn't have chosen these crazy slow defaults before releasing it but that's my personal view :)

[foxyshadis]

That's why I said VP8 is FUD. It's a way to push something out there that's better than MPEG-2 and Theora, but still half-baked and not nearly fully optimized. It's pushed out now to great fanfare purely to keep people questioning their decisions, and regardless of the actual quality of the codec they have to keep the debate going. They were doing it with Theora right up until they bought On2, so even less reason to stop now. In a few months, maybe a year, it'll hold its own.

I didn't say On2 was a bad company or that it's not good to have format competition. I just said their work was a mess and it'll be a while before Google can fix it. Look at the absolute flurry of activity going on around the code right now, there is major plumbing work going on in the git, and it's going to come out of this a better codec, and what they learn will go into their real killer codec, VP9.

[Atak_Snajpera]

They have still few years for improvements in code ;)

[julius666]

And ? if it's a extension of VPx that is normal don't you think surely you wouldn't write everything from scratch, anyways just lets wait and see what happens in the future and not look bad @ the past that is over and not very useful @ all ;)
I know VPx since VP3 now back in the days DivX started their Project Moyo and SBC was the most popular and VP3 was very promising back then already :) and i saw the results now in Motion of VP8 i find it very acceptable for a Next Generation Codec compared for example vs other H.264 incarnations like Real which is slowly fading away from the market.
Sure it can't beat X264 if you go maximum complexity with it but if you stay @ the level of VP8 complexity it doesn't do that bad Visually without RD (X264 looses PSY-RD but still has VAQ so still always wins currently also in being faster so could easily go 1 quality up also), there are definitely still problems even in the ABR RC and many more problems like inloop failing @ manual constant quality encoding, but all in all these look like very small problems that are fixable over time and will improve it visually a bit, Encoding speed improvements are also one of the most importants to be able to say @ the same level with X264 @ the same complexity, i see already many people are shocked by the default speed the encoder is producing and the quality differences each option can cause though as the setting up is rather more complex and in the other way also not then what you are used from a H.264 encoder it seems normal, personally i wouldn't have chosen these crazy slow defaults before releasing it but that's my personal view :)

I didn't say that VP8 is bad - well, actually i did a test with elephants dream as source with best settings and the quality was surprisingly good! - I just said that don't compare VP8 to the old x264, On2 had the time to make a proper encoder and specification too.

And no offense, but please use full stops at the end of your sentences and linebreaks because your comments are hard to read.

[hajj_3]

WebM support has just been added as of build 2029 of MPC-HC according to the changelog: http://www.xvidvideo.ru/logi-izmeneniy/log-izmeneniy-media-player-classic-homecinema.html

[littleD]

Actually only file extension was added to file association, not format itself. That how i understand that.

[clsid]

Correct. External filters are still required for .webm playback.

[iwod]

Of course, for actual cutting edge development beyond x264's eventual plateau, go look at JCTVC's TMuC (Test Model under Consideration). Weird name, amazing performance on low bitrates, if you can wait 10-40 minutes per frame.

Well, The Best it can do right now is Same Quality @ Half Bit Rate. While that sounds Good on paper, we are simply scaling Video Resolution too quickly. Next Gen Video Codec has to deal with UHD ( 4K ). Which means even Half the Bitrate would still be larger then a 2K H.264 File.

[nm]

Well, The Best it can do right now is Same Quality @ Half Bit Rate. While that sounds Good on paper, we are simply scaling Video Resolution too quickly. Next Gen Video Codec has to deal with UHD ( 4K ). Which means even Half the Bitrate would still be larger then a 2K H.264 File.

That's about the same tradeoff as HD H.264 compared to SD MPEG-2. Remember that storage capacity and network bandwidths are also increasing at a steady pace.

[foxyshadis]

Well, The Best it can do right now is Same Quality @ Half Bit Rate. While that sounds Good on paper, we are simply scaling Video Resolution too quickly. Next Gen Video Codec has to deal with UHD ( 4K ). Which means even Half the Bitrate would still be larger then a 2K H.264 File.

I'm not convinced at all about that. H.264's biggest weakness in HD is the maximum of 8x8 transform, but it does well enough. A normal film scanned at 4K will make even the grain and dirt look large and soft, no longer noise at all. In IMAX films, you'd finally be able to find the grain, and some digital films will have substantially more detail at 4K then 2K - like Avatar or 300 - but most films hit their real resolution limits somewhere between SD and HD. You can keep scanning it in higher resolution but you won't get any more content, just waste space currently, like copying a VHS to Bluray. The new proposals have up to a 64x64 transform, and at least one halves resolution on the smoothest areas, specifically to handle 4K. Efficiently coding large areas of very little detail also prevents some banding and blocking problems in low-res areas.

The results showed that while it does less than 2x as well as JVT at SD (where 4x4 and 8x8 are most useful and H.264 is fine), it does better at HD than SD, and about the same with 4K (though only two 4K samples were used). The transform size is no longer a limiting factor.

[wiak]

looks like google is working on a new decoder
http://review.webmproject.org/#change,118
dixie: initial interface

The "dixie" project will be a rewrite of much of the VP8 decoder core.
Some of the goals are:

* Increase speed by paying more attention to data locality and
cache layout, and by eliminating redundant work in general.

* A different approach to multithreading, to treat all threads as
equal and working on larger work units than a single MB.

* Expose more of the bitstream to the application, essentially
creating a vp8 parser utility. This could be useful for analyzing
the complexity of a stream, to help set conformance points.

* If the above goals are met successfully, replace the reference
decoder.

For those interested in the etymology of the term "dixie:"
decoder2 -> dx2 -> dxii -> dixie