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

[Guest]

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

[hajj_3]

I'm pretty sure they are just gunna fix the bugs and clean up the code for the next few weeks atleast, hopefully then they will try to improve speed and quality.

[wiak]

I'm pretty sure they are just gunna fix the bugs and clean up the code for the next few weeks atleast, hopefully then they will try to improve speed and quality.
they are doing a rewrite of the crappy current decoder as its said in the code review post

btw dont underestimate google, have you seen how android went from what to wow in around year?

[hajj_3]

yeah android is very nice indeed, its hard to guess how much they can improve VP8 without violating patents, only time will tell i guess. Judging from the issues list on google's bug tracker it seems that there are quite alot of bugs in the current code with new flaws found daily, i'm sure in 2 months time there will be a stable version of VP8 with cleaner code and then they can start improving the speed and quality.

[wiak]

yeah android is very nice indeed, its hard to guess how much they can improve VP8 without violating patents, only time will tell i guess. Judging from the issues list on google's bug tracker it seems that there are quite alot of bugs in the current code with new flaws found daily, i'm sure in 2 months time there will be a stable version of VP8 with cleaner code and then they can start improving the speed and quality.
jup, WebM is in developer preview aka beta, it will impove over time
:stupid:

[hajj_3]

new blog update from google: http://webmproject.blogspot.com/2010/06/vp8-codec-optimization-update.html#more

[Astrophizz]

Hopefully they will open up to making fixes that change the bitstream :/ I'm sure you've seen their statement that they don't want to implement some fixes/improvements because they've already encoded a number of videos...

[IgorC]

Don't know nothing of the level of complexity and realizability as to do a workaround to support both older streams and future clean specification but it looks enough optimal.

[oibaf]

Hopefully they will open up to making fixes that change the bitstream :/ I'm sure you've seen their statement that they don't want to implement some fixes/improvements because they've already encoded a number of videos...

They are planning it soon, see here:
http://review.webmproject.org/#change,56

[hellfred]

looks like google is working on a new decoder
No need to wait for google to finish their decoder #2. FFmpeg already got a (patch for a) native VP8 decoder, which out-performs the (classic) decoder of libvpx! It will be avail in all FFmpeg powered applications very soon (see reply of Mr. FFmpeg aka Michael Niedermayer)...
Announcement of FFmpeg devel list (http://article.gmane.org/gmane.comp.video.ffmpeg.devel/111538)
Patch history (http://github.com/yuvi/ffmpeg/commits/vp8)

[dapperdan]

Hopefully they will open up to making fixes that change the bitstream :/ I'm sure you've seen their statement that they don't want to implement some fixes/improvements because they've already encoded a number of videos...

Could you point me to that statement?

While it was portrayed that way in the x264 developer's write up, if you actually followed the link provided you'll see that they didn't want to implement a fix found within 48 hours of the launch until after the launch so that they had time to do the re-encode.

[Astrophizz]

Hmm, well I know I spotted the email in the mailing list a few weeks back but I can't seem to find it. I think it was in regards to the MV bounds issue From what I've seen with the implementation of a branch for bitstream changes you might be right. Of course this will cause an issue with hardware developers...

Edit: Here it is https://groups.google.com/a/webmproject.org/group/codec-devel/msg/e10111e2f5ba0660
I don't know how waiting made it any easier to resolve but I guess they didn't want to look like fools. That whole thread is interesting. The issue with hardware developers and already encoded streams poses a big issue I think.

[foxyshadis]

I would think hardware developers go into these kinds of arrangements expecting to be thrown under the bus at some point. It always happens that someone implements a broken creator, silently fixes it, and then the reader has to put up with multiple unofficial "extensions" of the spec, the same way that the creators know they'll eventually have to code around bugs & limitations in readers.

[buzzqw]

@Nic

would be possible to add to official ivfenc trunk the avs support sending a patch to webm developers ?

if so we will have a working avs support out of the box

thanks

BHH

[wiak]

@Nic

would be possible to add to official ivfenc trunk the avs support sending a patch to webm developers ?

if so we will have a working avs support out of the box

thanks

BHH
:stupid:
should be simple just add the code to report ;)
http://code.google.com/p/webm/issues/entry

[hajj_3]

great news: http://webmproject.blogspot.com/2010/06/future-of-vp8-bitstream.html

They are accepting improvements to create a VP9, great news:) Can't see it beating x264 anytime soon but if they can make it beat h264 that would be fantastic:)

[Atak_Snajpera]

Can't see it beating x264 anytime soon but if they can make it beat h264 that would be fantastic
x264 is implementation of h.264 standard ;) Also they have to omit any patents.

[wiak]

x264 is implementation of h.264 standard ;) Also they have to omit any patents.
WebM needs a army of lawyers to avoid patents

x264 dont need a army of lawyers, and can basicly just implement without regard

there is a reason why there is no official x264 binaries out, why? they cant redistribute precompiled binaires due to royalties/lisense/patents

hajj_3 old news if you have checked the http://review.webmproject.org site in the last week or so :P

[CruNcher]

http://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/5b841bce1c4e4948#

[Midzuki]

Question:

there is a reason why there is no official x264 binaries out, why? they cant redistribute precompiled binaires due to royalties/lisense/patents

Answer:

The reason there are no official binaries is that I haven't bothered to figure out how to make a .deb or .rpm, and if you're not using a packaging system you can just compile it yourself. It has nothing to do with licensing.

:) :p :D

[Selur]

Looking at ivfenc I wonder is there some overview somewhere which states which min, max and defaults values are set?

[wiak]

Looking at ivfenc I wonder is there some overview somewhere which states which min, max and defaults values are set?
some of them says it at http://www.webmproject.org/tools/encoder-parameters/ , but there are also sample parameters at http://www.webmproject.org/tools/encoder-parameters/

[CruNcher]

Though you shouldn't trust the Encode Parameters Especially the 1 pass examples are wrong :P

[Selur]

Was anyone successful in feeding ivfenc via pipe from mencoder?
I tried:
mencoder -dvd-device "D:\ElephantsDream\VIDEO_TS" dvd://1 -ovc raw -noskip -vc mpeg12 -vf scale,format=i420 -forcedsubsonly -nosound -mc 0 -lavdopts threads=8 -really-quiet -fps 25 -aspect 1.7775:1 -of rawvideo -o - \
| ivfenc --passes=1 --pass=1 --target-bitrate=1500 --width=720 --height=576 --timebase=1/25 --i420 - "D:\Encoding Temp\Title_1_1-8.vp8"
but ivfenc keeps complaining about: Error in piped Y4M input - not recognised as Y4M
(using the ivfenc version from Nic: IVFEnc - VP8 Encoder - Nic's AviSynth Input Mod v1.5 (Jun 7 2010))

Cu Selur

[Gser]

Google adds 'experimental' branch to VP8 source code tree

Google is encouraging developers to work on the next incarnation of its now-open sourced VP8 video codec, acquired from On2 technologies last year in a $124.6 million deal and an integral part of Google's WebM project.

"To maintain codec stability while also allowing for quality and performance improvements in VP8, we have added an experimental branch to the VP8 source tree," said Google codec engineering manager Jim Bankoski.

"The WebM community can use this unstable branch to propose changes to VP8 that will produce the best video codec possible, but without the constraints of a frozen bitstream. At some point in the future, when the experimental branch proves significantly better than the stable branch, we will create a new version of the codec."

Mozilla and Opera have officially put their weight behind the WebM royalty-free format, while Microsoft has said Internet Explorer 9 will support WebM once a user installs VP8. Apple's Steve Jobs has hinted that Safari will stick to H.264 video content.

Various Google partners are currently working on hardware acceleration for VP8, and Bankoski said they are committed to providing the hardware sometime next year.

"Devices that use hardware acceleration for video are a very small percentage of overall web traffic today, but they are a rapidly growing segment of the market and our project must be mindful of these vendors' needs," Bankoski wrote.

[rernst]

At the danger of being redundant - same here.

Was anyone successful in feeding ivfenc via pipe from mencoder?
I tried:
mencoder -dvd-device "D:\ElephantsDream\VIDEO_TS" dvd://1 -ovc raw -noskip -vc mpeg12 -vf scale,format=i420 -forcedsubsonly -nosound -mc 0 -lavdopts threads=8 -really-quiet -fps 25 -aspect 1.7775:1 -of rawvideo -o - \
| ivfenc --passes=1 --pass=1 --target-bitrate=1500 --width=720 --height=576 --timebase=1/25 --i420 - "D:\Encoding Temp\Title_1_1-8.vp8"
but ivfenc keeps complaining about: Error in piped Y4M input - not recognised as Y4M
(using the ivfenc version from Nic: IVFEnc - VP8 Encoder - Nic's AviSynth Input Mod v1.5 (Jun 7 2010))

Cu Selur

[valgor]

Mencoder do not produces yuv4mpeg.
"-of rawvideo" gives you the just raw video stream, without y4m skeleton. and ivfenc tells you this fact.

[Selur]

Thanks, got it working with:
mencoder -dvd-device "D:\ElephantsDream\VIDEO_TS" dvd://1 -ovc raw -noskip -vc mpeg12 -vf scale,format=i420 -forcedsubsonly -nosound -mc 0 -lavdopts threads=8 -really-quiet -fps 25 -aspect 1.7775:1 -of rawvideo -o - | \
ffmpeg -v -10 -threads 8 -r 25 -pix_fmt yuv420p -s 720x576 -f rawvideo -i - -an -r 25 -f yuv4mpegpipe - | \
ivfenc --passes=1 --pass=1 --target-bitrate=1500 --width=720 --height=576 --timebase=1/25 --i420 - "D:\Encoding Temp\Title_1_1-8.vp8"

[rernst]

In that case - why don't you cut mencoder out altogether? ffmpeg has native VP8 support in 0.6 (and it works, I tried it).

[Selur]

This was maily a small test, normally I do some filtering&Co with mencoder (e.g. deinterlacing) but that aside if you can tell me how to open a dvd with ffmpeg I would probably use it more but afaik ffmpeg doesn't support DVD input.
I could drop ivfenc, but first for that I would need some infos how the ivfenc settings match to ffmpeg. (to be frank I will probably stick with infenc since it's easier and faster to compile a new ivfenc build than a ffmpeg, but a ivfcenc->ffmpeg mapping would be interesting)

[rernst]

This from the patch that implements it into ffmpeg:


+{"spatial_rsmpl", "Enable spatial resampling (VP8)", OFFSET(spatial_rsmpl), FF_OPT_TYPE_INT, 0, 0, 1, V|E},
+{"spatial_rsmpl_up", "Spatial resampling up watermark, percentage of target data buffer. (VP8)", OFFSET(spatial_rsmpl_up), FF_OPT_TYPE_INT, 60, 0, 100, V|E},
+{"spatial_rsmpl_down", "Spatial resampling down watermark, percentage of target data buffer. (VP8)", OFFSET(spatial_rsmpl_down), FF_OPT_TYPE_INT, 30, 0, 100, V|E},
+{"vbr_bias", "Two-pass mode CBR/VBR bias, 0-100 (VP8)", OFFSET(vbr_bias), FF_OPT_TYPE_INT, 50, 0, 100, V|E},
+{"lag", "Allow lagged encoding, given as frames (VP8)", OFFSET(lag), FF_OPT_TYPE_INT, 0, 0, INT_MAX, V|E},
+{"sharpness", "[0-7] (VP8)", OFFSET(sharpness), FF_OPT_TYPE_INT, 0, 0, 7, V|E},
+{"altref", "Allow use of alternate reference frame", OFFSET(altref), FF_OPT_TYPE_INT, 0, 0, 1, V|E},
+{"ar_max_frames", "Max frames used in creating alt. ref. [0,25]", OFFSET(ar_max_frames), FF_OPT_TYPE_INT, 0, 0, 25, V|E},
+{"ar_type", "Filter type used in creating alt. ref.", OFFSET(ar_type), FF_OPT_TYPE_INT, 0, 0, INT_MAX, V|E},
+{"ar_strength", "Filter strength used in creating alt. ref. [0,6]", OFFSET(ar_strength), FF_OPT_TYPE_INT, 0, 0, 6, V|E},
+{"mb_static_threshold", "", OFFSET(mb_static_threshold), FF_OPT_TYPE_INT, 800, 0, INT_MAX, V|E},
+{"rc_opt_occupancy", "number of bits which should be kept in the rc buffer during decoding", OFFSET(rc_optimal_buffer_occupancy), FF_OPT_TYPE_INT, DEFAULT, INT_MIN, INT_MAX, V|E},
+{"token_partitions", "Number of sub-streams in bitstream (1,2,4,8).*Used for parallelized decoding.", OFFSET(token_partitions), FF_OPT_TYPE_INT, 1, 1, INT_MAX, V|E},

[CruNcher]

don't they use the --level --cpu-used combined maping anymore ? and is --cpu-used default still 3 ?

[rernst]

Not sure. I don't know whether you read code but should be able to be gleaned from the patch files - but I haven't perused them all.

[ricardo.santos]

In that case - why don't you cut mencoder out altogether? ffmpeg has native VP8 support in 0.6 (and it works, I tried it).

3 reasons:

1- ffmpeg doesnt handle external subs
-sub teste.srt -font "arialbd.ttf" -subcp ISO-8859-15 -subfont-autoscale 2 -subfont-text-scale 4 -subpos 85

2- ffmpeg doesnt respect the bitrate choosen by the user, theres 2 threads here on doom9 about it, did you manage to fix it or get a way for it not to oversize?

3- mencoder has some resizing magic, (-vf scale=480:-10 - i used this when i needed to convert to flv), if i "tell" it that i want the width to be 480 it it will automatically get the height and maintain the aspect ratio

@Selur

can you give an example on to pipe to ivfenc from mencoder with a mp4 or avi file as source?
Ps: just noticed your example uses ffmpeg...so you're piping from mencoder to ffmpeg that then pipes to ivfenc? i guess i'll wait for a "proper" mencoder build with vp8 for windows, i've seen some linux ones while googling.

[rernst]

Well, 1.) isn't really an issue for me but if it is for you, of course. Since I really don't use ffmpeg but mencoder I am not aware of particular bugs. Mind you, I am not the coder or one of the coders, I just compile the stuff from source and occasionally fix a couple of lines... For 3.) I wrote my own frontend so that sort of calculation wasn't an issue as my GUI does it.

As for the MP4 or AVI - I used ffmpeg pure for the whole conversion. Since it uses libvpx for the conversion altogether it should respect bitrate for that just like ivfenc because both hand it off to the same encoder with the same parameters.

I had an email exchange with Reimar (mencoder) and would like to find out why they don't use the webm patch that integrates libvpx into mencoder which would make the whole thing superfluous.

[rernst]

Btw, Reimar came back and said that the VP8 support as patched (CFR) should work in native mencoder (which I so far could not get to work using acodec=libvpx) but he indicated it would be a bug if it didn't so I presume they would accept a bug report against it.

[rernst]

There was a small bug in the ./configure script and now mencoder natively encodes vpx (-ovc lavf -lavcopts vcodec=libvpx). Right now it isn't in svn (at least in the last 20 minutes) so I think you can save yourself the whole piping just by running mencoder as is. If you need a windows binary, let me know.

[Selur]

Nice, will wait until it hits svn before I try it. :)

[ricardo.santos]

If you need a windows binary, let me know.

Altough the comment wasn't directed at me, i'm interested (and a whole lot of mencoder fans outhere) in a windows build, can you share it?

Thanks

[hellfred]

The native VP8 decoder was added (http://git.ffmpeg.org/?p=ffmpeg;a=commit;h=49fb632ffa43a44f2e339362ffaa844eef11fbea) to the FFmpeg codebase.
It is bitexact compared to libvpx unless the bilinear filter feature is used in the clip. The reason for this is that the feature is not covered in the VP8 specifications provided by google. The feature will be added (http://article.gmane.org/gmane.comp.video.ffmpeg.devel/112027) as soon as the specification are extended accordingly.
SMD optimizations to get the decoder even faster are already in review process.

[hajj_3]

WebM/VP8 has been added to MPC-HC now as of build 2071: http://www.xvidvideo.ru/media-player-classic-home-cinema-x86-x64/media-player-classic-homecinema-x86-x64-svn-2071.html

[buzzqw]

i have missed announcing the AutoWebM gui !

http://forum.doom9.org/showthread.php?t=155256

BHH

[rernst]

Altough the comment wasn't directed at me, i'm interested (and a whole lot of mencoder fans outhere) in a windows build, can you share it?

Thanks

I just posted a rush build here (http://24hourloop.com/downloads/cat_view/18-code). I will look at the mentioned outstanding issue as I just was told how to pass the encoding options. You can pass mencoder using -lavcopts o= all ffmpeg options, such as bt=, threads= and what not.

Again, this is experimental and I will have something solid later. I will also add webm support to YAMF in the next couple of days. Personally and for myself I prefer to multiplex into Matroska which plays back fine if you have the Directshow codec installed plus splitter, etc.

I have not tested this under Linux and normally don't post Linux builds as they are much more trivial to produce. VP8 ffmpeg builds here: http://ffmpeg.arrozcru.org/builds/

I don't think the ones at sourceforge support it, yet.

[dott]

Altough the comment wasn't directed at me, i'm interested (and a whole lot of mencoder fans outhere) in a windows build, can you share it?

Thanks

http://oss.netfarm.it/mplayer-win32.php

It has been there for some days

I don't test mencoder yet...

[rernst]

http://oss.netfarm.it/mplayer-win32.php

It has been there for some days

I don't test mencoder yet...
I don't think that build has a working *encoder* yet. There was a bug in the ./configure script which only built the decoder but not the encoder.

[ricardo.santos]

@rernst
can´t download the file

if possible can anyone help me "translate" the following but using vp8 as the encoder, this is what i used for FLV.

mencoder.exe video.avi -o out.flv -af resample=22050:0:0 -sws 9 -vf scale=480:-3 -of lavf -ovc lavc -lavcopts vcodec=flv:vbitrate=400:trell:v4mv:mv0:mbd=2:cbp:aic:cmp=3:subcmp=3 -oac mp3lame -lameopts abr:br=48:mode=3

@dott
theres a reference to vp8 but it doesnt work


Thanks

[rernst]

@rernst
can´t download the file

if possible can anyone help me "translate" the following but using vp8 as the encoder, this is what i used for FLV.



@dott
theres a reference to vp8 but it doesnt work


Thanks

Try again. This is the full build, official although I haven't changed the name.

[littleD]

IE9 Platform release 3 is out and what we've got

<video>
* MP4 H.264 playback support, using hardware or software decoding
* Support for WebM software is not included in this release


So, is webm including planned for next release?

[wiak]

IE9 Platform release 3 is out and what we've got



So, is webm including planned for next release?
they did say it, btw microsoft is horrible slow to release anything, so, and am sure the release 3 is kinda out of date allready

[ricardo.santos]

rernst can you share the script you used to encode with mencoder, ive tried but im unable to select video bitrate, the best i found was this but it tells me vlc doesnt play libv

mencoder.exe 1234.mp4 -o out.mkv -af resample=22050:0:0 -sws 9 -vf scale=480:-3 -of lavf -ovc lavc -lavcopts vcodec=libvpx:0="threads=2" -nosound

[hellfred]

The VP8 decoder of the FFmpeg project recently got some important extensions:

1. Support for the bilinear filter feature missing up to now was added (http://git.ffmpeg.org/?p=ffmpeg;a=commit;h=340674b22b220e41923c51a2f1d1606d14ea2491). Now all test vectors decode without flwas.
2. The first set of SIMD optimizations for the x86 platform (http://git.ffmpeg.org/?p=ffmpeg;a=commit;h=d9295da5f58bec75e1231833224ca5b2222f69ed) wer committed.

Features known to be missing: Upscaling (http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff;h=7ef9d23a121fc6fe343b76a08a15b47fa7ebfe05)
There is some WIP for Altivec SIMD optimizations (http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-June/091562.html).
The main author of the FFmpeg VP8 decoder has refined his statement about the speed of his decoder compared to the on in libvpx:
I meant 40-50% faster than libvpx without any SIMD; with SIMD it's ~2x faster than we are right now. (http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-June/091549.html) So the pure C decoder code is faster than the one in libvp8.

[rernst]

@rernst
can´t download the file

if possible can anyone help me "translate" the following but using vp8 as the encoder, this is what i used for FLV.



@dott
theres a reference to vp8 but it doesnt work


Thanks
First of all vcodec=libvpx. The rest is tinkering.

[rernst]

rernst can you share the script you used to encode with mencoder, ive tried but im unable to select video bitrate, the best i found was this but it tells me vlc doesnt play libv

I used vbitrate. I noticed that only a subset of vpx options is accepted under ="xxx". I have somewhat run into a wall with the mencoder folks which seem hesitant to embrace vpx because they cannot deliver variable bitrate and therefore altref= is not supported. This it seems is the primary reason for vpx's excellent quality.

The main problem I see at the moment that the maintainers of libavcodec for mencoder have removed all of the Google patch in the latest svn I looked at. I don't fully understand that mentality.

I have switched to ffmpeg for that reason (which I will incorporate into YAMF as soon as some other work is done). Unfortunately ffmpeg, as I have found in doing so, has a lot of drawbacks compared to mencoder.

I would expect the MeGUI folk(s) to support vpx pretty soon (at least this looks like the logical choice).

Without mencoder enthusiasm that route looks like a dead end street and I would focus on ffmpeg.

[Selur]

Trying to match the ivfenc options with ffmpeg I came up with this spreadsheet (http://spreadsheets.google.com/ccc?key=0AvWxUS1XGCPAdGNtNW10a2p4c1VwdG1VZk1uMl9MUEE&hl=en) so far. It's free to edit for everyone using the above link, so if anyone wants to and can help to fill it plz do so. :)

Cu Selur

[rernst]

Trying to match the ivfenc options with ffmpeg I came up with this spreadsheet (http://spreadsheets.google.com/ccc?key=0AvWxUS1XGCPAdGNtNW10a2p4c1VwdG1VZk1uMl9MUEE&hl=en) so far. It's free to edit for everyone using the above link, so if anyone wants to and can help to fill it plz do so. :)

Cu Selur
I believe -good and -best are matched by

-level 100 - best
-level 200 - average
-level 300 - fast encoding.

My understanding so far.

[Selur]

I added it to the spreadsheet :)

[iwod]

Is DS now working on FFmpeg Vp8 as well? I read the news on Ars

[Astrophizz]

According to the linked article, yes he's working on the x86 optimizations for the decoder.

[Dark Shikari]

I wrote:

Some of MMX 4 and 6-tap MC (original written by Ronald)
SSE2 4 and 6-tap MC
SSSE3 4 and 6-tap MC
MMX DC-only iDCT (rewritten from Ronald's original)
SSE4 DC-only iDCT
MMX iWHT
MMX, SSE2, and SSSE3 bilinear MC
Two dozen or so MMX/SSE/SSE2/SSSE3 intra prediction functions

Currently only the loopfilter (all 6 types: simple_h, simple_v, normal_inner_h, normal_inner_v, normal_mbedge_h, normal_mbedge_v) is left among "things that are important", and Ronald is doing that.

The linked article fails to mention Ronald for some bizarre reason, which is odd because he's done a huge amount of the work (he's been working on the C code as well).

[hajj_3]

nice work DS, how much faster do you think your optimisations will benefit a user with a fairly new cpu like a core 2? Are these optimisationss just for the decoder or have they been added to the decoder too?

[oibaf]

Is there a plan to port some of the ffmpeg vp8 decoder work to libvpx (it should at least be relicensed under BSD) or is it so much integrated with ffmpeg that it isn't feasible and libvpx should wait for dixie (http://review.webmproject.org/#change,118)? I am thinking of projects using libvpx, e.g. firefox or vp8 dshow filters, that could benefit from the speedups.

[iwod]

I wrote:

Some of MMX 4 and 6-tap MC (original written by Ronald)
SSE2 4 and 6-tap MC
SSSE3 4 and 6-tap MC
MMX DC-only iDCT (rewritten from Ronald's original)
SSE4 DC-only iDCT
MMX iWHT
MMX, SSE2, and SSSE3 bilinear MC
Two dozen or so MMX/SSE/SSE2/SSSE3 intra prediction functions

Currently only the loopfilter (all 6 types: simple_h, simple_v, normal_inner_h, normal_inner_v, normal_mbedge_h, normal_mbedge_v) is left among "things that are important", and Ronald is doing that.

The linked article fails to mention Ronald for some bizarre reason, which is odd because he's done a huge amount of the work (he's been working on the C code as well).

Because No one knows who is Ronald Bultje but everyone knows who is DS.

Is that only decoder you are working on. And not Encoder?

[hajj_3]

WebM V0.9.9 DirectShow filters have just been released.

Changelog:

(1) two-pass VP8 encoding is now fully implemented

(2) makewebm now supports reading and writing GraphEdit (*.grf) files

(3) source filter now uses Cues element, for more efficient seeking

(4) webmmux filter now allows you to specify WritingApp element

(5) VP8 encoder filter now allows you to force a keyframe to be
created immediately

[PatchWorKs]

Is DS now working on FFmpeg Vp8 as well?
Of course, DS is a Google employee !

Suggestion for the encoder (but not just the VP8 one): what about ThinkMeta Fiber Pool (http://www.thinkmeta.de/en/fiberpool_overview.html) "adoption" ?

[Atak_Snajpera]

WebM V0.9.9 DirectShow filters have just been released.
Why do we even need this? Haali Media Splitter + latest FFDshow is not enough for webm???

[clsid]

ffdshow is currently still a little bit slower. But soon it will probably be faster.

[GodofaGap]

Why do we even need this? Haali Media Splitter + latest FFDshow is not enough for webm???
Is it really strange that a company provides a playback solution for a format it assembled itself?

[zafna]

Why do we even need this? Haali Media Splitter + latest FFDshow is not enough for webm???

why not?It also is an option for webm,and,this's not a bad thing:rolleyes:

[Dark Shikari]

Of course, DS is a Google employee !If I was a Google employee, I'd be working on libvpx, not ffmpeg ;)

Is there a plan to port some of the ffmpeg vp8 decoder work to libvpx (it should at least be relicensed under BSD) or is it so much integrated with ffmpeg that it isn't feasible and libvpx should wait for dixie? I am thinking of projects using libvpx, e.g. firefox or vp8 dshow filters, that could benefit from the speedups.No, ffmpeg is LGPL, and libvpx is BSD. I will not release the asm under a more liberal license (at least not without significant compensation), because the express purpose of this project is to take control away from Google and give it back to the free software community.

If everyone uses ffmpeg vp8 because it's faster and better, Google will no longer have control of both the encoder and decoder, and will thus no longer be able to abuse their position as much as they can (and have) now.

[lnatan25]

So, the purpose is noble, but if a "significant compensation" comes, the hell with morals? :rolleyes:

[bob0r]

"significant compensation" only means even better code can be written and the cycle starts all over again! :)

[iwod]

I cant wait for a FFmpeg version of Vp8.......Althought it sounds like it is at least a few years away..........

[Dark Shikari]

So, the purpose is noble, but if a "significant compensation" comes, the hell with morals? :rolleyes:"Significant compensation" could be used to fund other noble endeavors, obviously. :p

[oibaf]

Thanks for the clarification. However, what do you mean with:


If everyone uses ffmpeg vp8 because it's faster and better, Google will no longer have control of both the encoder and decoder, and will thus no longer be able to abuse their position as much as they can (and have) now.

They released very liberal (BSD) code + patent grant that can be used in all free and closed software for free (even ffmpeg could just relicense this code to LGPL and integrate in ffmpeg, but having an independent implementation is nice), why do you think they are abusing their position (just asking, since it's not clear to me :confused:)?

[Dark Shikari]

Thanks for the clarification. However, what do you mean with:



They released very liberal (BSD) code + patent grant that can be used in all free and closed software for free (even ffmpeg could just relicense this code to LGPL and integrate in ffmpeg, but having an independent implementation is nice), why do you think they are abusing their position (just asking, since it's not clear to me :confused:)?In a normal situation with a standardized file format, the spec is the rule. No implementation is privileged. If bugs are found in implementations, you fix the implementations. This makes it fair for anyone to implement a program that abides by the spec, because they know that they will be subject to the same rules as everyone else.

Google has done the complete opposite.

They have already repeatedly deemed that bugs in libvpx are "part of the spec". In many cases, their spec outright contradicted libvpx. Now they've reneged on the entire concept of the spec, renamed it into a "bitstream guide", and stated that everything libvpx does is correct no matter how stupid, how buggy, and how broken.

There is no "fairness" -- they are right and you are wrong. There is no public mechanism, like in a standards organization, for anyone else to have any input. They've attempted to appease people with an "experimental branch" that will never actually matter, much like an H.264+ released today wouldn't matter for years to come, and won't affect anything that they do now.

In this sense, VP8 might as well be a proprietary format. There is no spec, it's controlled entirely by a single megacorporation, compatibility is interoperability with their software and their software alone (including its bugs), and everyone else gets screwed. It's no different from Adobe Flash or Microsoft Word, except perhaps that there are apparently still people out there who will defend them for it.

[EricJ2190]

Is the ffmpeg implementation of VP8 going to follow the spec instead if libvpx?

[Dark Shikari]

Is the ffmpeg implementation of VP8 going to follow the spec instead if libvpx?No, if we followed the spec it would be totally useless -- it wouldn't play anything. We're following libvpx.

The difference is that once it's working, if people use it, Google will no longer be able to change things on a whim, because they don't control ffmpeg.

[GodofaGap]

The difference is that once it's working, if people use it, Google will no longer be able to change things on a whim, because they don't control ffmpeg.
Of course they can, and ffmpeg can then choose to have a non-working VP8 implementation or not.

[Dark Shikari]

Of course they can, and ffmpeg can then choose to have a non-working VP8 implementation or not.If everyone uses ffmpeg's decoder, and Google changes the format, none of Google's new videos will work in anyone's players.

[kieranrk]

If everyone uses ffmpeg's decoder, and Google changes the format, none of Google's new videos will work in anyone's players.

I assume VLC will be the major chunk of "anyone's players".

What I don't understand is why doing this will change Google's attitude since most people will assume the player is broken before the video is.

[Dark Shikari]

I assume VLC will be the major chunk of "anyone's players".

What I don't understand is why doing this will change Google's attitude since most people will assume the player is broken before the video is.It might not work, but it can't hurt to try.

Regardless, the situation before ffmpeg vp8 was that there was only one decoder which Google had full control over. Sure, someone could have forked it, but nobody did. Now, there is another option.

[GodofaGap]

If everyone uses ffmpeg's decoder
This is a rather big if. I'm sure Google is not going to rely solely on ffmpeg for playback of their format.

I also don't see any reason why Google would even want to control the format that way, cause they would have had a much easier job with a closed format. There is also a bigger problem that, if they want other people to use this, they can never break backwards compatibility when the format is released as stable. Otherwise they are just pushing people (especially content providers) back to H264. At some point the cost of re-encoding a whole media library is going to outweigh the cost of royalties.

I really don't think it's the format itself Google is trying to control here.

[Dark Shikari]

This is a rather big if. I'm sure Google is not going to rely solely on ffmpeg for playback of their format.They're relying solely on ffmpeg for Vorbis encoding, despite the fact that the ffmpeg developers themselves have explicitly told them to stop doing so because ffmpeg's Vorbis encoder is a pile of balls.

Also, most consumer tools (VLC, MPC-HC, etc) rely on ffmpeg.I also don't see any reason why Google would even want to control the format that way, cause they would have had a much easier job with a closed format. There is also a bigger problem that, if they want other people to use this, they can never break backwards compatibility when the format is released as stable. Otherwise they are just pushing people (especially content providers) back to H264. At some point the cost of re-encoding a whole media library is going to outweigh the cost of royalties.

I really don't think it's the format itself Google is trying to control here.So why hasn't Google submitted VP8 to a standards organization, like W3C? Well, other than the fact that they themselves aren't sure of the specifics of their own format, besides "this C code appears to decode it correctly".

[GodofaGap]

They're relying solely on ffmpeg for Vorbis encoding, despite the fact that the ffmpeg developers themselves have explicitly told them to stop doing so because ffmpeg's Vorbis encoder is a pile of balls.
I'm not sure what this has to do with relying on ffmpeg for VP8 playback. Or are you suspecting that they will start to constantly change the Vorbis bitstream too?

Also, most consumer tools (VLC, MPC-HC, etc) rely on ffmpeg.
Yes, but if Google *is* going to change the format on every whim then they will provide playback solutions themselves. There is no point in pushing a format no one can play.

So why hasn't Google submitted VP8 to a standards organization, like W3C? Well, other than the fact that they themselves aren't sure of the specifics of their own format, besides "this C code appears to decode it correctly".
There is a piece in the puzzle missing between not bringing a format to a standards organization and constantly pissing everybody off (including content providers) by breaking compatibility of your own format.

[oibaf]

I don't think Google want to keep control of the codec, they said many times that the format is frozen and this is also said in The first in-depth technical analysis of VP8 blog post (http://x264dev.multimedia.cx/?p=377) and on their FAQ (http://www.webmproject.org/about/faq/):

Are VP8 or WebM subject to change?
The VP8 and WebM specifications as released on May 19th, 2010 are final. [...]


The problem is that the specs are not well written and incomplete and independent implementations are useful to validate the real bitstream.

Anyway also ffmpeg decoders/encoders often didn't comply the specs, this is what I get with ffplay 0.5.1 included with latest Ubuntu 10.04 with a theora video:
http://img686.imageshack.us/img686/6079/ffplayffmpegtheora.png

Fortunately VLC uses libtheora rather than libavcodec...:
http://img710.imageshack.us/img710/9601/vlctheora.png

The ffmpeg theora problem should hopefully be fixed with ffmpeg 0.6 released on 2010-06-15.

Maybe Google should hire some more developers with open source experience (theora or ffmpeg developers?) to speed up the process (update the specs and fix/improve the reference library).

[iwod]

They're relying solely on ffmpeg for Vorbis encoding, despite the fact that the ffmpeg developers themselves have explicitly told them to stop doing so because ffmpeg's Vorbis encoder is a pile of balls.

Are they insane? Why use FFmpeg Vobris Encoder? The official one already included the tuning from aoTuV... which is MUCH MUCH better then FFmpeg encoder.....

God we are stuck in the middle of no where. Designing a Hardware Decoder for WebM will be hard. With no Standard what so ever. We are hold back by Stupid Apple usage of Mpeg 4 which is Baseline Profile. I would be happy if they even use Mainline or not High profile... Baseline is painful.

[nurbs]

All the new Apple stuff can play High Profile.

[Leeloo Minaï]

The problem is that the specs are not well written and incomplete and independent implementations are useful to validate the real bitstream.

Anyway also ffmpeg decoders/encoders often didn't comply the specs...

Did you see you are in contradictory with yourself ?
An independent implementation (like FFmpeg) which does not respect the specs (like theora in your example) cannot validate anything...

[dragsidious]

What matters much more to me then any spec is the ability for a decoder to properly decode the video.

Does anybody produce a reference 'lowest common denominator' decoder for WebM/VP8 yet? Does a reference hardware decoder exist?

To me this is what matters. Every time I've seen people try to establish standards and specifications in software.... all that is much less relevant then whether or not it's going to be compatible with what the end user will be using to view the data.

I can't think of a single complex specification were people follow it to the letter: TCP/IP, CSS, HTML, NFS, etc etc. Hell I can think of a few big examples were people followed to closely to the letter of the specification and ended up with extreme compatibility issues. One example of this is the NFSv4 folks that tried to copy Microsoft's file system ACL documentation so slavishly that they ended up with something that was completely incompatible to any existing implementation.

I don't know if having reference hardware and software decoding makes sense exactly, but it does to me. God damn the specification and full speed ahead.

Having a separate GPL/LGPL licensed ffmpeg vp8 encoder is a fantastic idea and I can't think of any better project to do it. In my eyes ffmpeg is just about the king for this sort of thing.

If this can be used as leverage to get a established reference decoder, in hardware and software, then this will go a long long way to making Webm be more acceptable for wider adoption.

If a video is decode-able on the reference decoder and is not on a different one then you know the bug is in the decoder. If a video is playable on a project's specific decoder, but not on the reference then the bug is in the encoder. Otherwise you end up with a strong tendency to say it's the other person's fault that your shit is broke.

[wiak]

If I was a Google employee, I'd be working on libvpx, not ffmpeg ;)

No, ffmpeg is LGPL, and libvpx is BSD. I will not release the asm under a more liberal license (at least not without significant compensation), because the express purpose of this project is to take control away from Google and give it back to the free software community.

If everyone uses ffmpeg vp8 because it's faster and better, Google will no longer have control of both the encoder and decoder, and will thus no longer be able to abuse their position as much as they can (and have) now.
:stupid:
i prefer ffmpeg encoder over ivfenc, why? alot more noob friendly

[CruNcher]

:stupid:
i prefer ffmpeg encoder over ivfenc, why? alot more noob friendly
:spitshismilk:

[Selur]

yup, first time I ever read that some one called ffmpeg "noob friendly" ;)

[stax76]

There is now basic WebM support using ffmpeg in StaxRip.

https://sourceforge.net/projects/staxmedia

[hajj_3]

new build of WebM out (webmdshow-0.9.10.0-20100809): http://webm.googlecode.com/files/webmdshow-0.9.10.0-20100809.zip

[Emp3r0r]

Found this demo video on YouTube encoded in WebM format:

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

Quality looks good to me, however I can't get the video to play full screen with the html5 player.

[sibvic]

Found this demo video on YouTube encoded in WebM format:

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

Quality looks good to me, however I can't get the video to play full screen with the html5 player.

HTML5 forbids full screen play for 3rd-party players (because it's easy to emulate login form/dialog by full screen video+script and steal your password). Browsers should add support of full screen play themselves.

[Emp3r0r]

ah hah, pressing F11 got me really close, just the player controls remained on the screen

[PatchWorKs]

As you probably noticed, MPEG LA’s AVC License Will Not Charge Royalties for Internet Video that is Free to End Users through Life of License (http://www.mpegla.com/main/Pages/Media.aspx).

WebM side effect ? Is their fear rising ?

[wiak]

Found this demo video on YouTube encoded in WebM format:

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

Quality looks good to me, however I can't get the video to play full screen with the html5 player.
you can check my webm/html5 test site at http://s3.nwgat.net/sintel/sintel.html ;)

encoded with FFmpeg & xiph vorbis encoder 1.2

[zafna]

webm is fully free,it never has royalties problem from google,you don't need to pay for anything,all is free

[ricardo.santos]

We can use AVC on the web free of charge when using non copyrighted videos NOW. I doubt commercial companies will change their pricing when they use webm (online video rental).

I think the current situation is more than enough/fair with AVC almost everywhere, if you make a profite you'll have to pay, if you use for personall use (family blog) you don't have to pay.

the concept of ONE video format is great but AVC is already playable in every browser, offers better quality, has fair usage terms.

Transition to webm will take more time than what people think (unless flash player includes webm decoding) and webmasters will have to pay more for hosting as they will have to host 2 versions of the same file.

I'm a newbie but all i see in this is a situation where hardware companies have a opportunity to sell more hardware "webm compatible", i think the format is being "pushed/rushed" to us.

Has anyone solved the ffmpeg bug where ffmpeg doesnt use the bitrate specified by the user?

[Atak_Snajpera]

Transition to webm will take more time than what people think (unless flash player includes webm decoding) and webmasters will have to pay more for hosting as they will have to host 2 versions of the same file.
I think transition will be very smooth and easy. Just install FireFox 4.0 or Chrome and you are ready to go.

[nurbs]

Yeah, 'cause that will magically make every website HTML5 compatible and convert every file on the internet into webm. :rolleyes: There are also plenty of devices where installing either of the browsers not an option. There is definitely going to be a transition period and I doubt H.264 will vanish any time soon.

[Midzuki]

Just install FireFox 4.0 or Chrome and you are ready to go.

Not everybody likes Chrome and/or Firefox. :)

[Sharktooth]

opera likes webm too...
internet exploDer 9 will support it thru a plugin.
so 4 of the most common web browsers (will) support webm almost out of the box.
plus, next nvidia and ati cards (dont know about intel) will support webm hardware decoding...
and remember MPEG-LA can always "change" idea...

[Astrophizz]

Actually the mpegla can't reverse their position without risking legal repercussions. Also Chrome supports both h.264 and webm.

[oibaf]

As you probably noticed, MPEG LA’s AVC License Will Not Charge Royalties for Internet Video that is Free to End Users through Life of License (http://www.mpegla.com/main/Pages/Media.aspx).


There is an interesting article about this here: Hold The Celebrations; H.264 Is Not The Sort Of Free That Matters (http://lwn.net/Articles/402955/):

First, the H.264-format video needs to be created - but that isn't free under this move. Then it needs to be served up for streaming - but that isn't free under this move. There then needs to be support for decoding it in your browser - but adding that isn't free under this move. Finally it needs to be displayed on your screen. [...] The only part of this sequence being left untaxed is the final one. Importantly, they are not offering to leave the addition of support for H.264 decoding in your browser untaxed. In particular, this means the Mozilla Foundation would have to pay to include the technology in Firefox.

[Sharktooth]

can you hear the bells ringing? webm is free in all those aspects.
IMHO webm is the future even if it is not on par with h.264... expecially x264.
in the meanwhile google released a quicktime component for webm. download(s) here: http://code.google.com/p/webm/downloads/list

[iwod]

No Hardware acceleration is a main concern.

[ricardo.santos]

@oibaf

First, the H.264-format video needs to be created - but that isn't free under this move.

My understanding is that for personal/noncommercial use its free, i can use my minidv camcorder and convert to h264 without paying.

Then it needs to be served up for streaming - but that isn't free under this move.

If people use webm they need to pay for hosting the files like we do for mp4 now, theres free storage for both formats.

There then needs to be support for decoding it in your browser - but adding that isn't free under this move.

i can play it in my browser though plash player for free.

[Sharktooth]

No Hardware acceleration is a main concern.
HW acceleration is coming from all the bigs... including nvidia, ati, intel... etc.

[Sharktooth]

@oibaf


My understanding is that for personal/noncommercial use its free, i can use my minidv camcorder and convert to h264 without paying.



If people use webm they need to pay for hosting the files like we do for mp4 now, theres free storage for both formats.



i can play it in my browser though plash player for free.
free for the end user does not mean free...
if one day you want to code a html5 web browser you cant include the h.264 decoder for free...
megui, for example, uses a lot of non-free software and we have to find a solution moving the update server to another country to circumvent patent laws.
there are several aspect of a single problem. so dont jump on the horse just coz someone said it's a winner... it could be a looser as well...

[ricardo.santos]

free to create aswell if im not mistaken as long as it meets some criteria like if the source is not copyrighted or the user makes money out of it.


unless im proven wrong the format is free for end user, free to create/convert/stream under certain circumstances like the ones mentioned above.

why do people say "its not free at all" when its actually not true, it is free if you want to share your holidays videos through your personnal blog.

Of course big (commercial) companies are supporting this, opportunity to sell chips/ processors/players etc etc that are "compatible" or in some way enhance the webm experience, big online commercial companies are also happy with this as they can still charge the same price for their video services (video rentals, cable etc) while using a free format.

Do i belive the user (large majority of internet users) will benefit from this: NO
Will commercial companys benefit: YES


@Sharktooth
I'm keeping an open mind about this, but theres a lot of mp4 bashing for no apparent reason, normal users are being mislead by "mp4 is not free, you cant convert/stream your videos with it"

[Superb]

libvpx v0.9.2 is out (http://code.google.com/p/webm/downloads/list).
2010-09-02 v0.9.2
Enhancements:
Disable frame dropping by default
Improved multithreaded performance
Improved Force Key Frame Behaviour
Increased rate control buffer level precision
Fix bug in 1st pass motion compensation
ivfenc: correct fixed kf interval, --disable-kf
Speed:
Changed above and left context data layout
Rework idct calling structure.
Removed unnecessary MB_MODE_INFO copies
x86: SSSE3 sixtap prediction
Reworked IDCT to include reconstruction (add) step
Swap alt/gold/new/last frame buffer ptrs instead of copying.
Improve SSE2 loopfilter functions
Change bitreader to use a larger window.
Avoid loopfilter reinitialization when possible
Quality:
Normalize quantizer's zero bin and rounding factors
Add trellis quantization.
Make the quantizer exact.
Updates to ARNR filtering algorithm
Fix breakout thresh computation for golden & AltRef frames
Redo the forward 4x4 dct
Improve the accuracy of forward walsh-hadamard transform
Further adjustment of RD behaviour with Q and Zbin.
Build System:
Allow linking of libs built with MinGW to MSVC
Fix target auto-detection on mingw32
Allow --cpu= to work for x86.
configure: pass original arguments through to make dist
Fix builds without runtime CPU detection
msvs: fix install of codec sources
msvs: Change devenv.com command line for better msys support
msvs: Add vs9 targets.
Add x86_64-linux-icc target
Bugs:
Potential crashes on older MinGW builds
Fix two-pass framrate for Y4M input.
Fixed simple loop filter, other crashes on ARM v6
arm: fix missing dependency with --enable-shared
configure: support directories containing .o
Replace pinsrw (SSE) with MMX instructions
apple: include proper mach primatives
Fixed rate control bug with long key frame interval.
Fix DSO link errors on x86-64 when not using a version script
Fixed buffer selection for UV in AltRef filtering

[Sharktooth]

@Sharktooth
I'm keeping an open mind about this, but theres a lot of mp4 bashing for no apparent reason, normal users are being mislead by "mp4 is not free, you cant convert/stream your videos with it"
infact you cant unless you pay for a licensed encoder or someone release a free but still licensed encoder (so who release it have to pay).
you can use x264 coz binaries are build by users and/or hosted in a country where there are non restrictive laws on patents... same for h.264 decoders (like ffmpeg/libavcodec).
so, im sorry but h.264 is NOT free at all.

[nurbs]

I can see the problem here. Your definition of "NOT free at all" is different from other peoples definition. Most people would think "NOT free at all" means there isn't a single case where it's free, while by your definition it means there are many cases where it is free, but also many where it isn't.

[Sharktooth]

exactly. it all depends by local laws on patents.
MPEG-LA just made some content free to distribute on some medium... no more than that.

[LigH]

I wonder why the threads number for ivfenc is recommended (http://www.webmproject.org/tools/encoder-parameters/#6_multi-threaded_encode_and_decode) to "number of real cores - 1". Would that rather mean the "number of additional forks" of the parallelizable encoder routine? Did anyone already test the performance for different core/thread ratios like that was done for x264? (Sorry if I missed that, I rarely read here, and might have searched for the wrong keywords.)

P.S.: It doesn't seem like Nic is going to update his AviSynth enabled ivfenc mod regularly? Please prove me wrong or point me to alternatives. ;)

P.P.S.: I believe ivfenc lies to me. The first pass definitely does not run at 46 fps, rather 4.6 fps ...

[oibaf]

New VP8 Test Vectors Available:
http://webmproject.blogspot.com/2010/09/new-vp8-test-vectors-available.html

[foxyshadis]

So has anyone had a chance to do a real quality comparison between the latest versions and the current x264? (Comparing at same bitrate and same encoding speed.) I'm really quite interested in how much the quality gap has narrowed over the summer.

HW acceleration is coming from all the bigs... including nvidia, ati, intel... etc.

HW acceleration was "coming" for H.264 and VC1 from at least 2004. The first demos weren't until 2005, public releases in early 2006, and they still weren't really bug-free until 2007. Plus you had to buy new hardware - then buy it again when it turned out the first generation wasn't 100% fixable. So color me somewhat unimpressed that it's in the pipeline, even if it's more of a priority now than then.

[PatchWorKs]

HW acceleration was "coming" for H.264 and VC1 from at least 2004. The first demos weren't until 2005, public releases in early 2006, and they still weren't really bug-free until 2007. Plus you had to buy new hardware - then buy it again when it turned out the first generation wasn't 100% fixable. So color me somewhat unimpressed that it's in the pipeline, even if it's more of a priority now than then.

Well, i believe that WebM "supporters" push it more quickly:

http://www.webmproject.org/about/supporters/

[LigH]

@ foxyshadis:

I would like to. If I knew where to get the most recent ivf encoder with AviSynth support. I believe the ifvenc Nic mod version I have (June 2010) has lib 0.9.0, but I read lib 0.9.2 is out... Unfortunately it seems that Nic did not link his ivfenc mod on his website. So I possibly need to use ffmpeg then?

[sibvic]

ffmpeg nightly builds for windows: http://ffmpeg.arrozcru.org/autobuilds/blog/

[MasterNobody]

So has anyone had a chance to do a real quality comparison between the latest versions and the current x264? (Comparing at same bitrate and same encoding speed.) I'm really quite interested in how much the quality gap has narrowed over the summer.
Here is my small testing.

Participants:
VP8 0.9.0.0 (http://webm.googlecode.com/files/vpx-vp8-debug-src-x86-win32mt-vs8-v0.9.0.zip) released at 18.05.2010
VP8 0.9.1.1 (http://webm.googlecode.com/files/vpx-vp8-debug-src-x86-win32mt-vs8-v0.9.1.1.zip) released at 22.06.2010
VP8 0.9.2.0 (http://webm.googlecode.com/files/vpx-vp8-debug-src-x86-win32mt-vs8-v0.9.2.zip) released at 02.09.2010
x264 r900 (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=a9af9425820cfba99ae4b378c33c4fee4e99b2ce) released at 06.07.2008
x264 r1595 (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=c7876580bf822e63f1f77689218bfbbea4f9b9fc) released at 21.05.2010
x264 r1652 (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=4c27afb595ac8e8a621ffc2bf8120f0d43c80384) released at 24.06.2010
x264 r1713 (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=c27666276eb4d63b0c9ee2b9a375feabc27c8f4e) released at 03.09.2010

First sample for testing was park_joy_1080p.y4m (http://media.xiph.org/video/derf/y4m/1080p/park_joy_1080p.y4m) which was encoded at 8000 kbit/s bitrate. But at first sample was converted to raw yuv (so all versions can use one source file) with mencoder (mencoder x:\park_joy_1080p.y4m -ovc raw -of rawvideo -vf format=i420 -o x:\park_joy_1080p.yuv)
bat-file used for encoding:datetime -u +"%%D %%T" >vp8_0900.txt
ivfenc_0900 x:\park_joy_1080p.yuv vp8_0900.ivf -w 1920 -h 1080 --timebase=1/50 --target-bitrate=8000 --good --cpu-used=0 -t 8 -p 2 --end-usage=0 --undershoot-pct=100 --kf-max-dist=250 --drop-frame=0 --resize-allowed=0 --static-thresh=0 --auto-alt-ref=1 --lag-in-frames=16 --profile=0
datetime -u +"%%D %%T" >>vp8_0900.txt

datetime -u +"%%D %%T" >vp8_0911.txt
ivfenc_0911 x:\park_joy_1080p.yuv vp8_0911.ivf -w 1920 -h 1080 --timebase=1/50 --target-bitrate=8000 --good --cpu-used=0 -t 8 -p 2 --end-usage=0 --undershoot-pct=100 --kf-max-dist=250 --drop-frame=0 --resize-allowed=0 --static-thresh=0 --auto-alt-ref=1 --lag-in-frames=16 --profile=0
datetime -u +"%%D %%T" >>vp8_0911.txt

datetime -u +"%%D %%T" >vp8_0920.txt
ivfenc_0920 x:\park_joy_1080p.yuv vp8_0920.ivf -w 1920 -h 1080 --timebase=1/50 --target-bitrate=8000 --good --cpu-used=0 -t 8 -p 2 --end-usage=0 --undershoot-pct=100 --kf-max-dist=250 --drop-frame=0 --resize-allowed=0 --static-thresh=0 --auto-alt-ref=1 --lag-in-frames=16 --profile=0
datetime -u +"%%D %%T" >>vp8_0920.txt

datetime -u +"%%D %%T" >x264_0900.txt
x264_0900.exe -o x264_0900.h264 x:\park_joy_1080p.yuv 1920x1080 --fps 50/1 -B 7700 -p 1 -b 8 --b-pyramid --bime -w -r 16 --mixed-refs -A all --me umh --merange 24 --subme 7 --b-rdo --8x8dct -t 2 --threads auto --thread-input --no-psnr --no-ssim --progress
x264_0900.exe -o x264_0900.h264 x:\park_joy_1080p.yuv 1920x1080 --fps 50/1 -B 7700 -p 2 -b 8 --b-pyramid --bime -w -r 16 --mixed-refs -A all --me umh --merange 24 --subme 7 --b-rdo --8x8dct -t 2 --threads auto --thread-input --no-psnr --no-ssim --progress
datetime -u +"%%D %%T" >>x264_0900.txt

datetime -u +"%%D %%T" >x264_1595.txt
x264_1595.exe -o x264_1595.h264 x:\park_joy_1080p.yuv 1920x1080 --fps 50/1 -B 8000 -p 1 --slow-firstpass --preset veryslow -r 16 --aq-mode 2 --psy-rd 0:0
x264_1595.exe -o x264_1595.h264 x:\park_joy_1080p.yuv 1920x1080 --fps 50/1 -B 8000 -p 2 --preset veryslow -r 16 --aq-mode 2 --psy-rd 0:0
datetime -u +"%%D %%T" >>x264_1595.txt

datetime -u +"%%D %%T" >x264_1652.txt
x264_1652.exe -o x264_1652.h264 x:\park_joy_1080p.yuv 1920x1080 --fps 50/1 -B 8000 -p 1 --slow-firstpass --preset veryslow -r 16 --aq-mode 2 --psy-rd 0:0
x264_1652.exe -o x264_1652.h264 x:\park_joy_1080p.yuv 1920x1080 --fps 50/1 -B 8000 -p 2 --preset veryslow -r 16 --aq-mode 2 --psy-rd 0:0
datetime -u +"%%D %%T" >>x264_1652.txt

datetime -u +"%%D %%T" >x264_1713.txt
x264_1713.exe -o x264_1713.h264 x:\park_joy_1080p.yuv --input-res 1920x1080 --fps 50/1 -B 8000 -p 1 --slow-firstpass --preset veryslow -r 16 --aq-mode 2 --psy-rd 0:0
x264_1713.exe -o x264_1713.h264 x:\park_joy_1080p.yuv --input-res 1920x1080 --fps 50/1 -B 8000 -p 2 --preset veryslow -r 16 --aq-mode 2 --psy-rd 0:0
datetime -u +"%%D %%T" >>x264_1713.txt

datetime -u +"%%D %%T" >x264_1713psy.txt
x264_1713.exe -o x264_1713psy.h264 x:\park_joy_1080p.yuv --input-res 1920x1080 --fps 50/1 -B 8000 -p 1 --slow-firstpass --preset veryslow --tune film -r 16 --aq-mode 2
x264_1713.exe -o x264_1713psy.h264 x:\park_joy_1080p.yuv --input-res 1920x1080 --fps 50/1 -B 8000 -p 2 --preset veryslow --tune film -r 16 --aq-mode 2
datetime -u +"%%D %%T" >>x264_1713psy.txt
Results of encoding were muxed with MKVToolnix: park_joy_samples.rar (http://www.mediafire.com/?7rb9qb6kk554c41)
Average SSIM calculated with Elecard Video Quality Estimator:VP8 0.9.0.0 SSIM_Y: 0.7788, SSIM_U: 0.7851, SSIM_V: 0.7340, SSIM_YUV: 0.7749
VP8 0.9.1.1 SSIM_Y: 0.7815, SSIM_U: 0.7847, SSIM_V: 0.7310, SSIM_YUV: 0.7768
VP8 0.9.2.0 SSIM_Y: 0.7801, SSIM_U: 0.7849, SSIM_V: 0.7323, SSIM_YUV: 0.7758
x264 r900 SSIM_Y: 0.7939, SSIM_U: 0.7903, SSIM_V: 0.7373, SSIM_YUV: 0.7878
x264 r1595 SSIM_Y: 0.8406, SSIM_U: 0.8012, SSIM_V: 0.7606, SSIM_YUV: 0.8287
x264 r1652 SSIM_Y: 0.8403, SSIM_U: 0.8011, SSIM_V: 0.7605, SSIM_YUV: 0.8284
x264 r1713 SSIM_Y: 0.8415, SSIM_U: 0.8011, SSIM_V: 0.7607, SSIM_YUV: 0.8293
x264 r1713p SSIM_Y: 0.8250, SSIM_U: 0.8045, SSIM_V: 0.7725, SSIM_YUV: 0.8177
x264 r1713p = x264 r1713 + psy options

Second sample for encoding was part of BlackPearl DVD (Lossless H.264: BlackPearl.mkv (http://www.mediafire.com/?99gsnf4vbqfypcl)) which was encoded 2000 kbit/s bitrate. But at first sample was converted to raw yuv with avs2yuv.
bat-file used for encoding:
datetime -u +"%%D %%T" >vp8_0900.txt
ivfenc_0900 x:\BlackPearl_720x352.yuv vp8_0900.ivf -w 720 -h 352 --timebase=1001/24000 --target-bitrate=2000 --good --cpu-used=0 -t 8 -p 2 --end-usage=0 --undershoot-pct=100 --kf-max-dist=250 --drop-frame=0 --resize-allowed=0 --static-thresh=0 --auto-alt-ref=1 --lag-in-frames=16 --profile=0
datetime -u +"%%D %%T" >>vp8_0900.txt

datetime -u +"%%D %%T" >vp8_0911.txt
ivfenc_0911 x:\BlackPearl_720x352.yuv vp8_0911.ivf -w 720 -h 352 --timebase=1001/24000 --target-bitrate=2000 --good --cpu-used=0 -t 8 -p 2 --end-usage=0 --undershoot-pct=100 --kf-max-dist=250 --drop-frame=0 --resize-allowed=0 --static-thresh=0 --auto-alt-ref=1 --lag-in-frames=16 --profile=0
datetime -u +"%%D %%T" >>vp8_0911.txt

datetime -u +"%%D %%T" >vp8_0920.txt
ivfenc_0920 x:\BlackPearl_720x352.yuv vp8_0920.ivf -w 720 -h 352 --timebase=1001/24000 --target-bitrate=2000 --good --cpu-used=0 -t 8 -p 2 --end-usage=0 --undershoot-pct=100 --kf-max-dist=250 --drop-frame=0 --resize-allowed=0 --static-thresh=0 --auto-alt-ref=1 --lag-in-frames=16 --profile=0
datetime -u +"%%D %%T" >>vp8_0920.txt

datetime -u +"%%D %%T" >x264_0900.txt
x264_0900.exe -o x264_0900.h264 x:\BlackPearl_720x352.yuv 720x352 --fps 24000/1001 -B 1970 -p 1 -b 8 --b-pyramid --bime -w -r 16 --mixed-refs -A all --me umh --merange 24 --subme 7 --b-rdo --8x8dct -t 2 --threads auto --thread-input --no-psnr --no-ssim --progress
x264_0900.exe -o x264_0900.h264 x:\BlackPearl_720x352.yuv 720x352 --fps 24000/1001 -B 1970 -p 2 -b 8 --b-pyramid --bime -w -r 16 --mixed-refs -A all --me umh --merange 24 --subme 7 --b-rdo --8x8dct -t 2 --threads auto --thread-input --no-psnr --no-ssim --progress
datetime -u +"%%D %%T" >>x264_0900.txt

datetime -u +"%%D %%T" >x264_1595.txt
x264_1595.exe -o x264_1595.h264 x:\BlackPearl_720x352.yuv 720x352 --fps 24000/1001 -B 1990 -p 1 --slow-firstpass --preset veryslow -r 16 --aq-mode 2 --psy-rd 0:0
x264_1595.exe -o x264_1595.h264 x:\BlackPearl_720x352.yuv 720x352 --fps 24000/1001 -B 1990 -p 2 --preset veryslow -r 16 --aq-mode 2 --psy-rd 0:0
datetime -u +"%%D %%T" >>x264_1595.txt

datetime -u +"%%D %%T" >x264_1652.txt
x264_1652.exe -o x264_1652.h264 x:\BlackPearl_720x352.yuv 720x352 --fps 24000/1001 -B 1990 -p 1 --slow-firstpass --preset veryslow -r 16 --aq-mode 2 --psy-rd 0:0
x264_1652.exe -o x264_1652.h264 x:\BlackPearl_720x352.yuv 720x352 --fps 24000/1001 -B 1990 -p 2 --preset veryslow -r 16 --aq-mode 2 --psy-rd 0:0
datetime -u +"%%D %%T" >>x264_1652.txt

datetime -u +"%%D %%T" >x264_1713.txt
x264_1713.exe -o x264_1713.h264 x:\BlackPearl_720x352.yuv --input-res 720x352 --fps 24000/1001 -B 1990 -p 1 --slow-firstpass --preset veryslow -r 16 --aq-mode 2 --psy-rd 0:0
x264_1713.exe -o x264_1713.h264 x:\BlackPearl_720x352.yuv --input-res 720x352 --fps 24000/1001 -B 1990 -p 2 --preset veryslow -r 16 --aq-mode 2 --psy-rd 0:0
datetime -u +"%%D %%T" >>x264_1713.txt

datetime -u +"%%D %%T" >x264_1713psy.txt
x264_1713.exe -o x264_1713psy.h264 x:\BlackPearl_720x352.yuv --input-res 720x352 --fps 24000/1001 -B 1990 -p 1 --slow-firstpass --preset veryslow --tune film -r 16 --aq-mode 2
x264_1713.exe -o x264_1713psy.h264 x:\BlackPearl_720x352.yuv --input-res 720x352 --fps 24000/1001 -B 1990 -p 2 --preset veryslow --tune film -r 16 --aq-mode 2
datetime -u +"%%D %%T" >>x264_1713psy.txt
Results of encoding were muxed with MKVToolnix: BlackPearl_samples.rar (http://www.mediafire.com/?7rb9qb6kk554c41)
Average SSIM calculated with Elecard Video Quality Estimator:
VP8 0.9.0.0 SSIM_Y: 0.9796, SSIM_U: 0.9827, SSIM_V: 0.9759, SSIM_YUV: 0.9796
VP8 0.9.1.1 SSIM_Y: 0.9798, SSIM_U: 0.9827, SSIM_V: 0.9760, SSIM_YUV: 0.9797
VP8 0.9.2.0 SSIM_Y: 0.9797, SSIM_U: 0.9828, SSIM_V: 0.9762, SSIM_YUV: 0.9797
x264 r900 SSIM_Y: 0.9822, SSIM_U: 0.9767, SSIM_V: 0.9687, SSIM_YUV: 0.9803
x264 r1595 SSIM_Y: 0.9858, SSIM_U: 0.9819, SSIM_V: 0.9754, SSIM_YUV: 0.9844
x264 r1652 SSIM_Y: 0.9858, SSIM_U: 0.9818, SSIM_V: 0.9754, SSIM_YUV: 0.9844
x264 r1713 SSIM_Y: 0.9859, SSIM_U: 0.9818, SSIM_V: 0.9753, SSIM_YUV: 0.9845
x264 r1713p SSIM_Y: 0.9828, SSIM_U: 0.9844, SSIM_V: 0.9791, SSIM_YUV: 0.9826
x264 r1713p = x264 r1713 + psy options

P.S. I wouldn't make any conclusions or screenshots, look at the encoded samples yourself.

[LigH]

WebM is not yet exciting.

I tested different ways to create a recode of Blender movies (with a reduced dimension). But trying to get a subjective impression of the possible quality, I already had issues with the playback, even in different players.

I used the following software:

webmdshow-0.9.10.0-20100809
IVFEnc 1.5 (AVS input mod by Nic; 2010-06-07)
ffmpeg-latest-mingw32-static (arrozcru.org; 2010-09-11) - incl. ffplay
some tools used by MeGUI 0.3.5.10: MP4Box (2010-04-10), x264 core:104 r1713 c276662, mkvmerge 4.3.0
AviSynth 2.58
BeHappy 0.2.4.20767 (2009-10-11) with OggEnc v2.87 (libvorbis 1.3.1) and NeroAacEnc 1.1.34.2
mpc-homecinema.1.4.2530_(x86)_msvc2010 (xvidvideo.ru)
ffdshow_rev3567_20100909_icl11 (xvidvideo.ru)
VLC media player 1.1.4

Just for convenience and speedup, I created an internediate AVC file with 1080p resolution via ImageSource because reading single PNGs is already the slowest part. This I used as "good-enough master", scaled down to 640×360 pixels, to feed the AVC and IVF encoders in 2-pass encoding with 700 kbps. Audio was converted from the AC3 audio stream of the AVI version, using BeHappy with NicAudio (DRC activated), normalization to 95% and DPL II + LFE downmix, with quality 2 for OggEnc2 and quality 0.3 for NeroAacEnc, to get similar-sized results.

At home I have only an Athlon X2 3800+ and a GeForce 6800 available, so I used the DGAVCDecDI version of the AviSynth source script, and auto or 2 thread encoding.

(In the office I can use a Phenom-II X4 945 and a GeForce 9600 available, so I may use a DGDecNV version of the AviSynth source script, and auto or 4 thread encoding...)

BBB_0360_700_avc.bat
E:\Programme\MeGUI\tools\x264\x264.exe --pass 1 --bitrate 700 --preset slower --thread-input --output BBB_0360_700.mp4 BBB_0360_DI.avs
E:\Programme\MeGUI\tools\x264\x264.exe --pass 2 --bitrate 700 --preset slower --thread-input --output BBB_0360_700.mp4 BBB_0360_DI.avs
E:\Programme\MeGUI\tools\mp4box\MP4Box.exe BBB_0360_700.mp4 -add BBB.m4a

BBB_0360_700_ivf.bat
E:\Programme\ivfenc\ivfenc.exe --codec=vp8 --passes=2 --pass=1 --fpf=BBB_0360.stats --best --threads=1 --token-parts=1 --end-usage=0 --target-bitrate=700 BBB_0360_DI.avs BBB_0360_700.ivf
E:\Programme\ivfenc\ivfenc.exe --codec=vp8 --passes=2 --pass=2 --fpf=BBB_0360.stats --best --threads=1 --token-parts=1 --end-usage=0 --target-bitrate=700 BBB_0360_DI.avs BBB_0360_700.ivf
E:\Programme\MKVtoolnix\mkvmerge.exe -o BBB_0360_700.webm -w BBB_0360_700.ivf BBB.ogg

BBB_0360_700_ffm.bat
E:\Programme\ffmpeg\bin\ffmpeg.exe -y -i BBB_0360_DI.avs -vb 700k -level 100 -pass 1 -f webm NUL
E:\Programme\ffmpeg\bin\ffmpeg.exe -y -i BBB_0360_DI.avs -i BBB.ogg -acodec copy -vb 700k -level 100 -pass 2 BBB_0360_700_ffm.webm

Overall, the quality was not bad, although artifacts are easily recognisable. No surprise, the appearance of AVC and VP8 artifacts differs - there are scenes where one of both is worse, and it was not always VP8. At least in my opinion.

But the ability to play the results differed a lot:

BBB_0360_700.mp4

Opera 10.62: not displayed
MPC-HC: OK
VLC: OK
ffplay: OK


BBB_0360_700.webm (ifvenc, mkvmerge -w)

Opera 10.62: video and audio play OK, seekable in general (long delays during the ending cast)
MPC-HC (internal Matroska splitter disabled): video plays for ~9 seconds, audio choppy - then a race to the end of the file, replay not possible
MPC-HC (internal Matroska splitter enabled): video and audio play OK, seekable to distinct positions except the ending cast
VLC: video and audio play OK, seekable to distinct positions except the ending cast
ffplay: video and audio play OK, seekable to distinct positions but skips the ending cast


BBB_0360_700_ffm.webm (ffmpeg alone)

Opera 10.62: video plays smooth, audio choppy (~0.4 sec steps), seeking works almost anywhere
MPC-HC (internal Matroska splitter disabled): audio plays smooth, video choppy (~0.4 sec steps), seeking works when pulling the grabber, not when clicking
MPC-HC (internal Matroska splitter enabled): audio plays smooth, video choppy (~0.4 sec steps), seeking works almost anywhere
VLC: video plays smooth, audio choppy (~0.4 sec steps), seeking works almost anywhere
ffplay: video and audio play OK, seekable to distinct positions even during the ending cast


Want to test yourself? -- http://www.ligh.de/WebM/

[Reimar]

E:\Programme\ivfenc\ivfenc.exe --codec=vp8 --passes=2 --pass=1 --fpf=BBB_0360.stats --best --threads=1 --token-parts=1 --end-usage=0 --target-bitrate=700 BBB_0360_DI.avs BBB_0360_700.ivf
E:\Programme\ivfenc\ivfenc.exe --codec=vp8 --passes=2 --pass=2 --fpf=BBB_0360.stats --best --threads=1 --token-parts=1 --end-usage=0 --target-bitrate=700 BBB_0360_DI.avs BBB_0360_700.ivf
E:\Programme\MKVtoolnix\mkvmerge.exe -o BBB_0360_700.webm -w BBB_0360_700.ivf BBB.ogg
MPC-HC (internal Matroska splitter enabled): video and audio play OK, seekable to distinct positions except the ending cast


You did not set --kf-max-dist, thus you will only be able to seek (efficiently) to whatever the encoder detects as scene changes.
While I'd expect it isn't hard to find real issues, and I think ivfenc uses a bad default here, this one is a case of not knowing your tools...

[LigH]

Obviously, yes ... I am possibly too used to relying on sane defaults (x264 is a good example, in contrast).

This is a good hint, I will recreate the files with the suggested option, many thanks!

So there are possibly only two issues left:

a) "usual" multiplexer issues with ffmpeg (like with mp4 too)

b) pro and con internal Matroska splitter of MPC-HC - why the hell is it required at all, is the WebM DS Filter not enough? ... Was my Haali Media Splitter too old?! :o

[Sharktooth]

the ifvenc version plays ok on chrome for linux as well as the x264 version. the webm created by ffmpeg is choppy though...

[LigH]

Not only choppy, also MPC-HC reports dropping lots of frames. Probably a similar issue to the MP4 B-frame multiplexing bug in the ffmpeg multiplexer.

[ricardo.santos]

VP8 VFW Codec released
http://www.optimasc.com/products/vp8vfw/index.html

@Nic
Will you continue updating your ivfenc with avs support version? There's been a new (non avs) version around for a while. I know there's ffmpeg but the bitrate problem (oversizing) has not been solved.

Does anyone know if mencoder will support vp8/webm? I remember someone saying there was some incompatibilities between mencoder and vp8, any news?

[LigH]

Not only a bitrate problem, but also a multiplexer issue in ffmpeg (^ #374).

I am not certain if Nic regularly reads here... :( -- And noone else yet was able to build a working encoder with vpx 0.9.2 + Nic's source patch?

[ricardo.santos]

Not only a bitrate problem, but also a multiplexer issue in ffmpeg (^ #374).
i wasnt aware of the multiplexer issue as i'm using nic's ivfenc version for my encodes/testing because ffmpeg kept oversizing my encodes.

It seems that after the initiall "rush" things are slowing down.

[Reimar]

Does anyone know if mencoder will support vp8/webm? I remember someone saying there was some incompatibilities between mencoder and vp8, any news?

It should be working fine mostly (never tested myself though). Due to their stupid design choice you can't properly use "alternate reference frames", but that should also be the case for the VFW codec and even for FFmpeg to a degree. Unless they decided to go for a sane design by now (sane as in "will work with more than their own encoder implementation and framework").

[Sharktooth]

a sane design is not even possible due to mpeg patents...

[Reimar]

a sane design is not even possible due to mpeg patents...

In this case it's rather that a sane design is possible due to avoiding MPEG patents. Packed B-frames is quite a messy hack, however the same approach would have worked quite fine for alternate keyframes, would not really have been a hack and probably would have worked better for about 99% of use cases (and I doubt it would have been a real issue for the remaining 1%).

[Kurtnoise]

Does anyone have try makewebm app w/ avisynth scripts as input ?

[J_Darnley]

You mean something like ffmpeg?

[Kurtnoise]

Not exactly...makewebm uses directshow filters to encode A/V streams.

http://review.webmproject.org/gitweb?p=webmdshow.git;a=tree

[LigH]

Rather something like the sourcepatch from http://nic.dnsalias.com/ivfenc.zip used with the VPX library 0.9.2 ... I remember 'Selur' tried that but the result didn't work, kept crashing.

[Kurtnoise]

both makewebm & vpxenc (ivfenc's name doesn't exist anymore) use libvpx to encode in VP8. So...

[valgor]

v0.9.5 "Aylesbury" is released
http://code.google.com/p/webm/downloads/list

CHANGELOG since v0.9.2


2010-10-28 v0.9.5 "Aylesbury"
Our first named release, focused on a faster decoder, and a better encoder.

- Upgrading:
This release incorporates backwards-incompatible changes to the
ivfenc and ivfdec tools. These tools are now called vpxenc and vpxdec.

vpxdec
* the -q (quiet) option has been removed, and replaced with
-v (verbose). the output is quiet by default. Use -v to see
the version number of the binary.

* The default behavior is now to write output to a single file
instead of individual frames. The -y option has been removed.
Y4M output is the default.

* For raw I420/YV12 output instead of Y4M, the --i420 or --yv12
options must be specified.

$ ivfdec -o OUTPUT INPUT
$ vpxdec --i420 -o OUTPUT INPUT

* If an output file is not specified, the default is to write
Y4M to stdout. This makes piping more natural.

$ ivfdec -y -o - INPUT | ...
$ vpxdec INPUT | ...

* The output file has additional flexibility for formatting the
filename. It supports escape characters for constructing a
filename from the width, height, and sequence number. This
replaces the -p option. To get the equivalent:

$ ivfdec -p frame INPUT
$ vpxdec --i420 -o frame-%wx%h-%4.i420 INPUT

vpxenc
* The output file must be specified with -o, rather than as the
last argument.

$ ivfenc <options> INPUT OUTPUT
$ vpxenc <options> -o OUTPUT INPUT

* The output defaults to webm. To get IVF output, use the --ivf
option.

$ ivfenc <options> INPUT OUTPUT.ivf
$ vpxenc <options> -o OUTPUT.ivf --ivf INPUT


- Enhancements:
ivfenc and ivfdec have been renamed to vpxenc, vpxdec.
vpxdec supports .webm input
vpxdec writes .y4m by default
vpxenc writes .webm output by default
vpxenc --psnr now shows the average/overall PSNR at the end
ARM platforms now support runtime cpu detection
vpxdec visualizations added for motion vectors, block modes, references
vpxdec now silent by default
vpxdec --progress shows frame-by-frame timing information
vpxenc supports the distinction between --fps and --timebase
NASM is now a supported assembler
configure: enable PIC for shared libs by default
configure: add --enable-small
configure: support for ppc32-linux-gcc
configure: support for sparc-solaris-gcc

- Bugs:
Improve handling of invalid frames
Fix valgrind errors in the NEON loop filters.
Fix loopfilter delta zero transitions
Fix valgrind errors in vp8_sixtap_predict8x4_armv6().
Build fixes for darwin-icc

- Speed:
20-40% (average 28%) improvement in libvpx decoder speed,
including:
Rewrite vp8_short_walsh4x4_sse2()
Optimizations on the loopfilters.
Miscellaneous improvements for Atom
Add 4-tap version of 2nd-pass ARMv6 MC filter.
Improved multithread utilization
Better instruction choices on x86
reorder data to use wider instructions
Update NEON wide idcts
Make block access to frame buffer sequential
Improved subset block search
Bilinear subpixel optimizations for ssse3.
Decrease memory footprint

Encoder speed improvements (percentage gain not measured):
Skip unnecessary search of identical frames
Add SSE2 subtract functions
Improve bounds checking in vp8_diamond_search_sadx4()
Added vp8_fast_quantize_b_sse2

- Quality:
Over 7% overall PSNR improvement (6.3% SSIM) in "best" quality
encoding mode, and up to 60% improvement on very noisy, still
or slow moving source video

Motion compensated temporal filter for Alt-Ref Noise Reduction
Improved use of trellis quantization on 2nd order Y blocks
Tune effect of motion on KF/GF boost in two pass
Allow coefficient optimization for good quality speed 0.
Improved control of active min quantizer for two pass.
Enable ARFs for non-lagged compress

[LigH]

... so someone who understands libvpx could write his very own WebM encoder, instead of "simply" patching the vpxenc source to support VfW input? -- But I would be happy about the second option already.

[Kurtnoise]

you can create fake avis within makeAVI tool from FFdshow to test the last release if you want to...This tool is able to create avi from avs input.

[oibaf]

More info on 0.9.5 release: VP8 Codec SDK "Aylesbury" Release (http://blog.webmproject.org/2010/10/vp8-codec-sdk-aylesbury-release.html).

Some images from the post:
http://1.bp.blogspot.com/_t-XchACWDN0/TMieWyMrIhI/AAAAAAAAADU/9lB0XGyAvuI/s1600/speed.pnghttp://3.bp.blogspot.com/_t-XchACWDN0/TMie_0MtVMI/AAAAAAAAADY/LvwcKNkKcg4/s1600/psnr.pnghttp://1.bp.blogspot.com/_t-XchACWDN0/TMifY2n19iI/AAAAAAAAADc/AFzqutWgMII/s1600/ssim.png

[LigH]

I know makeAVIS ... but it might not help. The help file only mentions Y4M or raw YV12/I420, so not even AVI support. I would have to pipe video from ffmpeg into vpxenc, I fear.

Furthermore, the output of vpxenc is really stupid: Captions are sent to stderr, parameters to stdout. Let's shuffle the deck?!

I have a feeling that Google does not really care about getting it used by amateur video authors.
__

Maybe people will use the VfW codec by Optima SC (http://www.optimasc.com/products/vp8vfw/index.html) once it is updated to libvpx 0.9.5; then they could convert the resulting AVI with mkvmerge. Provided that mkvmerge detects the video source. If it expects raw *.ivf though ... another dead end.

[hajj_3]

i wonder what Dark Shikari's opinion of the 0.9.5 version of VP8 are and if any benefits will be added to the version in FFmpeg

[iwod]

While i love the idea of a No Patents Video Codec that offer decent quality. There are so many things lacking that i think forcing MPEG-LA to lower or get free loyalty would be a easier solution. MPEG - LA and those companies has earned enough on those patents anyway.

No Hardware Acceleration being the worst disadvantage.

[Sharktooth]

HW acceleration for WebM is planned by major companies... including AMD and Nvidia....

[Sirber]

I updated BENCOS with webm support (via ffmpeg). The presets are in fact only playing with the "-level" param.

http://code.google.com/p/bencos/

[zambelli]

While i love the idea of a No Patents Video Codec that offer decent quality
That should really be changed to "patent free until challenged in court". There's no such thing as a patent free DCT-based video codec.

[oibaf]

That should really be changed to "patent free until challenged in court". There's no such thing as a patent free DCT-based video codec.

Until someone files and wins a lawsuit the There's no such thing as a patent free DCT-based video codec is only and nothing more than FUD (http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt).

And until now (6 months after initial open source release of patent free VP8 (May 2010), over 9 years after initial open source release of patent free VP3 (September 2001), now theora and over 10 years after the finalization of the patent free vorbis bitstream) no one filed any lawsuit as promised so that's indeed just FUD. On top of that MPEG-LA and Apple rather then suing Xiph.org and Google (after spreading FUD that they use their patents) on 2010-08-26 they removed the fees for distributing H.264 files (http://www.mpegla.com/Lists/MPEG%20LA%20News%20List/Attachments/231/n-10-08-26.pdf), so one could argue that they really fear VP8 but still didn't/can't sue.

Obliviously nobody can predict what will happen in the future. In the meantime please stop spreading more FUD. Thanks.

[nurbs]

You should read your own link. They didn't remove any fees.

[zambelli]

In the meantime please stop spreading more FUD. Thanks.
It's not FUD. The statistical chance of implementing a DCT-based video codec without infringing any H.264, VC-1, MPEG-4, MPEG-2 and MPEG-1 patents is extremely slim, virtually impossible.

Go check out the following:
http://www.mpegla.com/main/programs/AVC/Pages/PatentList.aspx
http://www.mpegla.com/main/programs/VC1/Pages/PatentList.aspx
http://www.mpegla.com/main/programs/M4V/Pages/PatentList.aspx
http://www.mpegla.com/main/programs/M2/Pages/PatentList.aspx


The H.264 patent list alone is 70 pages long. Pick a dozen random patents from the list, go to http://www.google.com/patents and see what they're about.

Of course we don't know what's going to happen. But "not being sued for X years" is no proof of a technology being "patent free", just like the fact that nobody has ever broken into your home does not mean that your house is secure.

I also hope I don't have to explain to you the difference between Xiph and Google and why some cash-strapped patent holder might be more likely to sue Google than Xiph.

Bottom line: I'm not discouraging anyone from using WebM. It's merely my personal opinion that it's impossible to build a truly patent-free DCT-based video codec due to the extremely high number of patents in what's essentially a very small, niche area of computing technology. It's just the reality of the business.

[jakor]

MPEG-1 patents are already free to infringe. Patent holding time has expired. The same is going to be with MPEG-2 patents really soon.

[Selur]

any one got a link to a windows vpxenc version that does support input via pipe?

the one from vpx-vp8-debug-src-x86-win32mt-vs8-v0.9.5.zip always crashes for me with "Error reading Y4M frame data",...
mencoder "D:\Test\test - clips\test.avi" -ovc raw -noskip -vid 0 -vf scale,format=i420 -forcedsubsonly -noautosub -nosound -mc 0 -lavdopts threads=8 -really-quiet -fps 25 -aspect 1.81818:1 -of rawvideo -o - | ffmpeg -v -10 -threads 8 -r 25 -pix_fmt yuv420p -s 640x352 -f rawvideo -i - -an -r 25 -f yuv4mpegpipe - | vpxenc --codec=vp8 --passes=2 --pass=1 --target-bitrate=1499 --end-usage=0 --fpf="D:\Encoding Temp\test_.stats" --profile=0 --good --cpu-used=3 --bias-pct=70 --minsection-pct=1 --maxsection-pct=10000 --min-q=0 --max-q=63 --lag-in-frames=16 --undershoot-pct=0 --buf-sz=6 --buf-initial-sz=4 --buf-optimal-sz=5 --drop-frame=0 --resize-allowed=0 --kf-min-dist=0 --kf-max-dist=250 --auto-alt-ref=1 --noise-sensitivity=0 --sharpness=0 --static-thresh=0 --token-parts=1 --arnr-maxframes=5 --arnr-strength=3 --threads=16 --width=640 --height=352 --timebase=1/25 --yv12 -o NUL -
(changing --yv12 to --i420 doesn't help either, still crashing)

Cu Selur

Ps.: https://review.webmproject.org/#change,1071 seems to be a known and fixed (in git) problem,...

[Leeloo Minaï]

No news about an official support of avisynth scripts as input ?

[Selur]

http://www.multiupload.com/Z0B7QG8Z8A <- stdin should work with this one (git checkout compiled with gcc for windows)

[Brazil2]

http://www.multiupload.com/Z0B7QG8Z8A <- stdin should work with this one (git checkout compiled with gcc for windows)
Thanks a lot :)

[Emp3r0r]

WebM on Android just announced with Gingerbread 2.3 (http://android-developers.blogspot.com/2010/12/android-23-platform-and-updated-sdk.html) and exclusively on the Nexus S at Best Buy, Happy Holidays!

I can't wait to get this working on my Samsung Galaxy Tab. It has stellar video quality.

[PatchWorKs]

It's not FUD. The statistical chance of implementing a DCT-based video codec without infringing any H.264, VC-1, MPEG-4, MPEG-2 and MPEG-1 patents is extremely slim, virtually impossible.

Remember that On2 codecs has a very long (and patented) history too...
It's also possible that H.264 and others infinges WebM instead !!!

I believe that Google and its competitors stalled as USA vs URSS in "cold war" ages... none would start a fight where all may loose in a Mutually assured destruction (M.A.D.) (http://en.wikipedia.org/wiki/Mutual_assured_destruction).

As Joshua sayd: "A strange game. The only winning move is not to play."

[CruNcher]

Even if their was im not sure if any of the companies involved in MPEG research would ever attack Google, because many of those big players are dependent on some level of it and do business with it and attacking your partner seems not really a good task. Maybe that's also why we only here some harsh words and see strategy fallbacks like the H.264 web license announcements, but no real law usage reaction yet also because they don't lose a lot money yet but gain more on other sides from Google again.
Industries morality thoughts were always different than our average joes one "first comes the money then the rights and laws" Google is one of those companies that exactly is moving in that area and (knows exactly how to play that Game with their "Friends") even if others get angry they mostly do nothing they just let them do what they want, they brag and cry but they do nothing against it even if the rights and laws would be on their side maybe it will go as far that this dependence even will cause some of those "friends" cease to exist @ all or getting acquired in the future ;)

[oibaf]

To promote WebM and other free formats (Ogg/Theora/Vorbis) Google is removing H.264 support from Chrome (http://blog.chromium.org/2011/01/html-video-codec-support-in-chrome.html).
Specifically, we are supporting the WebM (VP8) and Theora video codecs, and will consider adding support for other high-quality open codecs in the future. Though H.264 plays an important role in video, as our goal is to enable open innovation, support for the codec will be removed and our resources directed towards completely open codec technologies.

[montython]

Back in 2007, it was very "exciting" to see the peculiar psnr/ssim distribution of videos encoded with the vp7 encoder. :) If this vp8 encoder of On2 is like vp7 and if Google relies on this, I am sure the future will be very "exciting".

http://forum.doom9.org/showthread.php?t=131481


To be more concrete on the subject, this is a demonstration based on a short sample.

DESCRIPTION:
This is not meant to be a comprehensive codec test, but rather an experiment on psnr volatility. The reference is a 512x288, 20-seconds sample trimmed from a movie trailer. Includes scene cuts, fades.

rv40 encoder: Helix Producer 11 (VBR, 2-pass, high encoder complexity)
vp70 encoder: VP70 VFW Codec - Personal Edition (2-pass, best quality, default settings for the rest)
x264 encoder: x264-r650 cli (2-pass, custom settings)
pass-1 settings:
--subme 1 --partitions "none" --bframes 3
--progress --no-psnr --no-ssim
pass-2 settings:
--ref 5 --bframes 3 --b-pyramid --weightb
--partitions "all" --8x8dct --direct "auto"
--me "umh" --subme 6 --b-rdo --mixed-refs --bime
--progress --no-psnr --no-ssim

For testing purposes, a low bitrate (approximately 265kbps) was chosen. The size of video streams in avi, rmvb and mp4 containers are approximately the same.

Second-pass encoding speeds were exactly the same for x264 and rv40 codecs. Encoding speed of vp70 with the best quality settings was about 2.75 times slower compared to the other two. For the first pass: Encoding times of x264 and vp70 were about the same, rv40 was slightly slower.

RESULTS:
http://i231.photobucket.com/albums/ee166/img_f/psnr.png
http://i231.photobucket.com/albums/ee166/img_f/psnr_ma10.png

It should be evident from the first graph that vp70 and rv40 series exhibit periodic fluctuations, which is a kind of "seasonality" effect. For the vp70 series, the range of fluctuations is larger and the peaks occur at every 8th frame. For rv40, the range is narrower and a common interval for peaks seems to be 4.
In the second graph, 10-period moving average series are used to compensate for the "seasonal" effect. This one should give a better idea of the trends throughout the sample.

For a closer examination of the fluctuation behavior, the last part of the sample (last 100 frames) is a good example: Peaks at every 8th frame (vp70) and peaks at every 4th frame (rv40) should be more clear in this subsample. I have no idea why this is the case, but 4 and 8 seem to be sort of magic numbers for these two codecs.

http://i231.photobucket.com/albums/ee166/img_f/psnr_subsamp.png

For those who are familiar with statistics/econometrics, the following is a rather simple regression analysis.

http://i231.photobucket.com/albums/ee166/img_f/x264.png
http://i231.photobucket.com/albums/ee166/img_f/rv40.png
http://i231.photobucket.com/albums/ee166/img_f/vp70.png

A brief explanation for reading the tables:
"AR" notation is used for auto-regressive terms. In econometrics, AR terms are used to examine periodic effects in a sample. For example, AR(2) term is used to check a periodic effect at every 2 periods. High t-statistic values (hence smaller probability) indicate significant effect. A probability value close to zero (lower than 0.05 for example) is considered to be a signal for the presence of a periodic effect for that term. The coefficient columns in the tables show the magnitude and the direction of the effect.

x264:
There is no number clearly standing out. Up to 6 frames, there seems to be evidence for blended relation.

rv40:
4 (with a large t-statistic) seems to be the magic number here by far. 1, 5 (and also 6) seem to be significant, but not as strong as 8.

vp70:
The extreme case is observed here. Every 8th frame has an important (??) role here. Also there seems to be a weaker effect for AR(1). This is probably due to references between consecutive frames, which is the type of behavior expected from almost all codecs.

[PatchWorKs]

Well certainly WebM will be *the* choice for web video (as the name claims itself) and consumer applications.
For professionals (such as film HD shooting) there will be Dirac...

[LigH]

Are you sure? ... As long as VP8 doesn't really compete with AVC Main Profile, and AVC playback stays free-of-charge, I doubt AVC will disappear out of the web.

[ckmox]

i heard xvp8 will start in march, from this source -> http://news.ycombinator.com/item?id=2093897

[Nintendo Maniac 64]

I swear, the more I see Dark Shikari participating in WebM stuff, the more I think he really IS tsundere for VP8. XD

[smok3]

ok, hopefully apple/MS and the rest of the little guys will hear Mr. Shikari (this time as well) and bundle their browsers with VP8 support, also can i have fullscreen button? thank you :)

p.s. is there a work at google for an old videoperson as well? geting really sick of this job..

[LigH]

So I will once again repeat my request for a vpxenc.exe which is able to use AviSynth scripts as video source. Or an ffmpeg.exe which contains fixed multiplexers.

[sneaker_ger]

MPEG LA Announces Call for Patents Essential to VP8 Video Codec (http://www.mpegla.com/main/pid/vp8/default.aspx)

[iwod]

Well if x264 dev are working on it then i am pretty confident that VP8 will rule the world.

[sneaker_ger]

Web Video Rivalry Sparks U.S. Probe (http://online.wsj.com/article/SB10001424052748703752404576178833590548792.html)

[rernst]

There are literally billions of dollars at stake. They will pull out all the plugs to combat VP8.

"All video codecs are covered by patents".

What is much more an issue here are software patents altogether. Remember when 'Multimedia' was patented?

It's ridiculous and really U.S. centric. Every piece of software is based on another piece of software. To even go there and state anything based on DCT is patented is nonsense.

I hope they will make this a landmark lawsuit that will severely curtail software patents altogether.

[dapperdan]

New version out today.

blog post announcement:

http://blog.webmproject.org/2011/03/vp8-codec-sdk-bali-released.html

codec-devel mailing list announcement post:

https://groups.google.com/a/webmproject.org/group/codec-devel/browse_thread/thread/059f95a8567f1693#

edit: they also had the first proper release of the WebP image format last month:

https://groups.google.com/a/webmproject.org/group/webp-discuss/browse_thread/thread/3a2784f36680f740#

[iwod]

Anyone going to run some test on new build?

[LigH]

Anyone going to try to make a vpxenc.exe with AviSynth support?

[dragsidious]

There are literally billions of dollars at stake. They will pull out all the plugs to combat VP8.

They will certainly try.


It's ridiculous


Yes.


and really U.S. centric.


No.

If you live in some places in Africa or Asia this may be true. But most places not only have binding treaties with the USA on patents, their governments are working directly with the USA to get even stronger ones that are more easily enforced internationally.


Every piece of software is based on another piece of software. To even go there and state anything based on DCT is patented is nonsense.


To violate a patent requires neither a existing product, existing software, or copying. You can come up with a idea 100% on your own, turn it into a product, and then get sued by a lawyer who never programmed a single line of code in his life and has no products that he sells. He just has to control a patent and you lose.


I hope they will make this a landmark lawsuit that will severely curtail software patents altogether.

Don't hold your breath. The current administration is very pro-'intellectual property'. They think that they can use patents to curtail the activities of companies that are competitive with established USA firms.

Which is one of the major things that patents are used for... to stop the small guy from competing. That is why Microsoft, IBM, et al. support patents even though they are the ones that get sued the most. They just past the cost onto their customers and do not have to worry about smaller upstarts competing against them.


Hopefully the Vp8 will succeed and turn video into just another common format. Just a common and easy to use as jpeg, png, gifs, mp3s, and whatever else. That way we can progress and work on more impressive things.

[Astrophizz]

Just a common and easy to use as jpeg, png, gifs, mp3s, and whatever else.

.gifs had licensing issues and .mp3 playback still has to be licensed (why Firefox and Opera don't support it). The .mp3s you see online are in a flash wrapper just like most of the h.264 content.

[IgorC]

It looks like psychovisual optimizations are next thing for VP8.

http://blog.webmproject.org/
In the next release, we plan to further improve the compression rate at the low bitrate range, as well as focus on new features such as two-pass encoding and visual optimization using segmentation maps.


Also new version of Vorbis Aotuv was realesed with improved audio quality.
http://www.geocities.jp/aoyoume/aotuv/

[GoWebM]

"Blueberry," the second release of the H1 VP8 hardware encoder. (http://blog.webmproject.org/2011/05/blueberry-vp8-hardware-encoder-ip.html)

Technical Details of the Blueberry Release:

We reached the aforementioned +0.82 dB PSNR gains by adding the following features to the encoder:

Improved encoding decisions and added more coding options at macroblock level

Enabled multiple motion vectors per macroblock (Split MV mode)

Added preference of “nearest”, “near” and “zero” type macroblocks that are less expensive to code than others

Added support for up to two reference frames in motion search (immediately previous and Golden frame)

Added deblocking filter macroblock mode adaptivity support

Added ¼ pixel precision motion estimation at 1080p resolution (previously supported only up to 720p)

Increased the amount of token probability tracking counters (enables more efficient entropy coding)

In addition, we added support for a programmable segment map, which enables psychovisual quality optimizations and defining region-of-interests. This means we can for example code the foreground objects (i.e. people) with a better quality (smaller quantizer) than the static background. We also added new hooks to the hardware that allows us to improve the quality of the encoder by later firmware upgrades that optmize our cost function algorithms - even after the chip has been manufactured.

:)

[IgorC]

Why is PSNR still the main metrics?
It is well know that it has bad correlation with real visual quality.
Almost no improvement for SSIM.

[GoWebM]

Any Video Converter (http://www.filehippo.com/es/download_any_video_converter/changelog/) Version 3.23 (released on May 11, 2011 ), add WebM as supported input and output video format.

Then:

* Non-commercial WebM Tools (Windows): Miro Video Converter, XMedia Recode, Firefogg, MediaCoder.

* Commercial WebM Tools (No cloud soft.): Bigasoft Total Video Converter, Any Video Converter.

Do you know of others?




Sorry my english:p

[nurbs]

This is also interesting.
In addition, we added support for a programmable segment map, which enables psychovisual quality optimizations and defining region-of-interests. This means we can for example code the foreground objects (i.e. people) with a better quality (smaller quantizer) than the static background.
From that description they do exactly the opposite of what adaptive quantization in x264 and other encoders does. I hope that's just a result of dumbing it down for the general audience and not something they actually want to do.

[IgorC]

Yes, looks like a future VP8 segmentation + bitrate distribution is totally opposite to x264´s mbtree. Although mbtree does good job there are other approachs.
It is a possibility that more optimal way will be smart algorithm in the middle of both.

About optimality of mbtree (http://forum.doom9.org/showthread.php?t=159389)

[ricardo.santos]

Any Video Converter Version 3.23 (released on May 11, 2011 ), add WebM as supported input and output video format.

only 1 pass mode

[GoWebM]

Happy Birthday, WebM!!!

First Anniversary. (http://blog.webmproject.org/2010/05/introducing-webm-open-web-media-project.html)

:)

[CruNcher]

Yeah though i find it bad news that Microsoft bought Skype :(
Skype always drove the VPx for low latency Videoconferencing and im not sure if Microsoft will continue that (actually it would be pretty strange if they would) :( on the other side with websockets nowadays skypes videoconferencing doesn't matter that much anymore.

[mariush]

They'll probably just bundle Silverlight with Skype in the next version, arguing they can auto switch to various bitrate streams on the fly with it or some other crap....

[CruNcher]

@mariush
you shouldn't underestimate with what the guys from Beijing might come up with ;), they worked exactly on this with their Titanium Codec http://research.microsoft.com/en-us/people/yanlu/

[mariush]

I'm not saying multi-bitrate vc1 is bad.. it could be very good. What irks me is that pretty much all technologies end up getting shoved down people's throats, whether they want it or not.

Just today I got a message saying important update available - the only thing was Microsoft Malicious Software whatever it's called.... People have short memory but when Microsoft bought Gecad's IP (rav antivirus) antivirus software makers complained that they'll get out of business and Microsoft said the software will be optional to download from website so it's not a problem. Well, soon it turned to optional software components and now for a long time it's important software update and always checked even if I don't have it installed now.

Now a new thing there in the optional updates is Microsoft Live Essentials... how much time do I have until they'll push it to "important updates" and always checked...
Silverlight is also always checked each week in the optional updates and I have to uncheck it manually just to get the popup stop nagging me.

It's damn annoying and frustrating and makes me lose trust in MS's products so much I don't even care to try these nice technologies they may make.

Imho the technology behind video in skype will change 100% because they have the vc1/h264 hardware decoding in Xbox360 and they'll want to integrate Xbox360 with Skype... and for pc, what better way to implement it than silverlight, which they can just load as a plugin in an embedded html page or something like that. Microsoft is also having patents and is part of the h264/vc1 licensing group so they don't really care that much about royalties...

[zambelli]

Microsoft pays VC-1 and H.264 royalties just like everyone else. In fact, it pays more than most since it ships quite a few decoders (i.e. Windows, Xbox, Zune, Silverlight, etc.).

[Disabled]

In fact, it pays more than most since it ships quite a few decoders...

Thats wrong. H264 royalties are capped at (I guess) 5 Million $, so Microsoft pays less per license then anyone else (unless youre under 100000 shipped units and its free).

[mariush]

Microsoft pays VC-1 and H.264 royalties just like everyone else. In fact, it pays more than most since it ships quite a few decoders (i.e. Windows, Xbox, Zune, Silverlight, etc.).

Of course they pay just like anyone else - well maybe not like everyone else because I'm sure they get a blanket/volume/negociated license.

But being one of the largest companies with patents in the MPEG-LA patent pools, they also get some money back from licensing "at the end of the day".

Just by looking at the list of patents in the patent pool for h264 alone, Microsoft has 4 pages of patents there:
http://www.mpegla.com/main/programs/avc/Documents/avc-att1.pdf

Anyway, this is getting to be a bit off topic...

ps. Judging by the signature in the footer of your post, I think you could at least mention that you work for Microsoft or are involved with them.

[IgorC]

Yeah though i find it bad news that Microsoft bought Skype :(
Skype always drove the VPx for low latency Videoconferencing and im not sure if Microsoft will continue that (actually it would be pretty strange if they would) :( on the other side with websockets nowadays skypes videoconferencing doesn't matter that much anymore.
VP8 and Skype's speech codec (SILK) are both open source. No big threat.

Also, Skype and Xiph have joined their codecs into new open source one with high quality and low delay. Opus.
It's a hybrid codec: SILK (low bitrate) + CELT (high quality MDCT encoder).
It performs very good now.
See the results of the last comparison in my signature.

[cid_xvid]

VP8 and Skype's speech codec (SILK) are both open source. No big threat.

Also, Skype and Xiph have joined their codecs into new open source one with high quality and low delay. Opus.
It's a hybrid codec: SILK (low bitrate) + CELT (high quality MDCT encoder).
It performs very good now.
See the results of the last comparison in my signature.

Skype has been adquired by Microsoft. I am afraid of the future of Opus encoder.

[iwod]

It is interesting that Opus is THAT good while free of patents. And yet we cant say the same for Video Codec.

[IgorC]

It is interesting that Opus is THAT good while free of patents. And yet we cant say the same for Video Codec.

There is very high quality and open source H.264 encoder (x264).While there is no such encoder for AAC standard.

That is one of the reasons why Opus had chance to do well comparing to commercial AAC encoders. Those AAC encoders aren't bad but it's often to see that open source implementations perform generally better.

[IgorC]

VP8 Codec SDK "Cayuga" Released

http://blog.webmproject.org/

Also now VP8 is used in One-to-One Skype calls.

[GoWebM]

Today we're making available "Cayuga," the third named release of the VP8 Codec SDK (libvpx). Note that the VP8 format definition has not changed, only the SDK. You can download the Cayuga libvpx snapshot (version 0.9.7) from the WebM Project Downloads page or clone it from our Git repository.

As promised, for Cayuga we targeted more areas for encoder speed improvements. Using our previous release ("Bali") as a benchmark, we’ve seen the following VP8 encoder improvements on x86 processors.

+11.5% "Best" mode (at speed 0)
+21.5% "Good" mode (at speed 0)
+22.5% "Real-time" mode (at speed 6, a typical speed for videoconferencing applications)

We also compared the encoder performance of "Cayuga" to our first named release ("Aylesbury") release and got the following results:

+35% "Best" mode (at speed 0)
+75% "Good" mode (at speed 0)
+52% "Real-time" mode (at speed 6)

We saw the following improvements on ARM processors:

On ARM Cortex A9 with Neon extensions, real-time encoding of video telephony content is 35% faster than Bali on single core and 48% faster on multi-core.

On the NVIDIA Tegra2 platform, real time encoding is 40% faster than Bali.

For more technical readers, here are some detailed improvements we made in the libvpx Cayuga encoder:

Improved the datarate control in one-pass realtime compression.

Improved one-pass variable bitrate (VBR) visual quality by average ~7% across a large collection of videos.

Improved video conferencing user experience through error concealment, a feature that produces high visual quality frames even under conditions of substantial packet loss.

Improved the ARM v6 and v7 encoders and decoders through greater use of SIMD features and strong use of cache prefetching.

Thanks to everyone who worked on Cayuga, and welcome to our eleven new contributors:

Alok Ahuja
Alexis Ballier
Ronald Bultje
Rafael Ávila de Espíndola
Ralph Giles
Stefan Holmer
Mike Hommey
Taekhyun Kim
Aron Rosenberg
Joshua Bleecher Snyder
Thijs Vermeir

Source: VP8 Codec SDK "Cayuga" Released (http://blog.webmproject.org/2011/08/vp8-codec-sdk-cayuga-released.html)

[Sirber]

Any Video Converter (http://www.filehippo.com/es/download_any_video_converter/changelog/) Version 3.23 (released on May 11, 2011 ), add WebM as supported input and output video format.

Then:

* Non-commercial WebM Tools (Windows): Miro Video Converter, XMedia Recode, Firefogg, MediaCoder.

* Commercial WebM Tools (No cloud soft.): Bigasoft Total Video Converter, Any Video Converter.

Do you know of others?




Sorry my english:p

Bencos ;) using ffmpeg. http://www.detritus.qc.ca

[GoWebM]

Starting today, “Cloudberry”, the third release of the Hantro H1 VP8 hardware encoder, is available at no cost through the WebM Project hardware page. Partners having already signed the online licensing agreement will receive an automatic update.

Moving along with our mission statement - creating the world’s best real-time video encoder - we’re again one step closer to our goal thanks to Cloudberry’s substantial quality gains. In PSNR comparisons, Cloudberry performs on average 1.27 dB better than our initial Anthill release, which we launched less than five months ago. It also beats the previous Blueberry release by 0.45 dB, with comparable increases using the SSIM quality metric.

We’ve also bridged an important milestone: Cloudberry is able to encode high-quality 720p video (video teleconference use cases) at well under 1 Mbps, as shown in the following chart.

https://lh4.googleusercontent.com/vTMcLDKUns64BlXObK05i4Cp9OyI5Z_-JC1lEbUm4k31ui8jMuqCcqF5z1PgbjyAinaQlQzuhxGWHuVnUC0mroVmb7V3KjAXN-tjTldtFEmZ5ENhLFw


The optimized Cloudberry control software is backwards compatible and will also benefit chips with the Blueberry hardware inside them, providing 0.08 dB average PSNR increase without any hardware changes required.

In our next release, we are focusing on further software-based quality improvements especially related to multipass encoding and optimal usage of VP8 Golden frames - both of which will benefit SoCs that use either Blueberry or Cloudberry. On the hardware side, we also have numerous improvements in mind, such as further optimizing the macroblock mode selection. This fourth release is planned to be available at the end of Q3.

The VP8 H1 encoder IP has been licensed already to nearly 40 semiconductor companies through the WebM Project, and more requests are pouring in. For licensing details about the H1, see our hardware page. Our reseller partner Verisilicon also licenses Cloudberry as a part of the multiformat Hantro H1 encoder.


For more technical readers, here is the list of new features in Cloudberry:

- RD-optimized quantization
- Improved intra/inter macroblock mode selection
- Improved inter macroblock RD functions
- Improved intra macroblock mode selection
- More macroblock level coding information returned to software (enables effective multipass optimizations)

The following curves show PSNR quality metrics for a 720p video call, comparing the H1 Cloudberry release to previous H1 releases and to the libvpx Bali software SDK release. As a point of interest, the Cloudberry encoder performs similarly to libvpx’s “-rt -cpu-used=-5” setting, which is equivalent to what a WebRTC based application can achieve on the fastest PCs.

https://lh6.googleusercontent.com/ZjtIeonuPNANtOV3cMei9gKJRCczXkeJf1HOyygyOhRCd22YOdjP6ecmYOAvBK03tilY0hbc1EGJeRWD7vOS4H0X_mmasxLgskmZblNdvWouU6lGguA


Source: Third Generation VP8 Hardware Encoder IP “Cloudberry” Released (http://blog.webmproject.org/2011/08/third-generation-vp8-hardware-encoder.html)

[CruNcher]

Duclair is out :)
http://blog.webmproject.org/2012/01/vp8-codec-sdk-duclair-released.html

[smok3]

Duclair is out :)
http://blog.webmproject.org/2012/01/vp8-codec-sdk-duclair-released.html

trying to compile git, but getting this at ./configure:
http://pastebin.com/NQWuG6v6
any clues?

edit: tarball did compile, does this look right?;
Included encoders:

vp8 - WebM Project VP8 Encoder v0.9.7-p1-62-g2aa4085

How would a best, good, fast cq based ffmpeg command line look like?

[nakTT]

I have tried this WebM to encode my video. Unfortunately at this stage it still lagging (in video quality - my test was at 500kbps) way behind x264. Hope it will progress fast for the better.

[Nintendo Maniac 64]

Am I crazy, or is YouTube's 480p config for WebM BETTER quality than their h.264 one? I used this video as my test case:
http://www.youtube.com/watch?v=vnc-c2SCz_0

Even crazier is that the 480p FLV is 48.7MB while the 480p WebM is 39.7MB! O_o (and apparently the WebM versions even have better audio quality as well)


Also interesting, if you don't have a hardware h.264 decoder, WebM uses less CPU. This is particularly noticable with older PCs, specifically YouTube's 720p WebM files can actually run well on a lowly 2GHz Pentium 4 (that is, assuming you're playing the file in a dedicated media player) while h.264 is a stutter-fest.

[Midzuki]

Am I crazy, or is YouTube's 480p config for WebM BETTER quality than their h.264 one? I used this video as my test case:
http://www.youtube.com/watch?v=vnc-c2SCz_0

Even crazier is that the 480p FLV is 48.7MB while the 480p WebM is 39.7MB! O_o (and apparently the WebM versions even have better audio quality as well)


Also interesting, if you don't have a hardware h.264 decoder, WebM uses less CPU. This is particularly noticable with older PCs, specifically YouTube's 720p WebM files can actually run well on a lowly 2GHz Pentium 4 (that is, assuming you're playing the file in a dedicated media player) while h.264 is a stutter-fest.

That looks and sounds incredibly weird O_o

So I'd like to know if:

1) which VP8 encoder has become faster && more-efficient lately?

2) which VP8 decoder has finally become decently-fast?

Three months ago (IIRC), last time I tried a WebM file from YouTube on my Pentium-4 through Opera 11.50, the playback dropped tons of frames, and the audio sync was simply impossible. :scared:

[Nintendo Maniac 64]

That looks and sounds incredibly weird O_o

What is this "that" you're referring to? Do you mean the video, the post, the WebM having better quality, or something else?

(note that I do not think I can answer your questions - I specialize in audio, and definitely not video)

[dapperdan]

Looks like Google is ready to go public with work on what will become VP9 (or VP8+, it's not clear to me how radical they intend to be):

https://gerrit.chromium.org/gerrit/#change,17840

[vivan]

Even crazier is that the 480p FLV is 48.7MB while the 480p WebM is 39.7MB! O_oconfig for WebM BETTER quality than their h.264 one?quality? I don't think so. http://www.check2pic.ru/compare/12266/

In other cases youtube gives webm higher bitrate. Like this: http://www.youtube.com/watch?v=APyr48GACzc
21.6 MB for 1080p mp4, 13.6 MB for 720p mp4... And 33.0 MB for 720p webm. Lol.

[Midzuki]

What is this "that" you're referring to? Do you mean the video, the post, the WebM having better quality, or something else?

All of the above, including the "something else". :)

[Nintendo Maniac 64]

quality? I don't think so. http://www.check2pic.ru/compare/12266/

In other cases youtube gives webm higher bitrate. Like this: http://www.youtube.com/watch?v=APyr48GACzc
21.6 MB for 1080p mp4, 13.6 MB for 720p mp4... And 33.0 MB for 720p webm. Lol.

I said at 480p. From what it looks like, the situation is reversed, with WebM having better video, audio, AND a smaller filesize. (unless I AM crazy. :P)

Note that, in particular, 480p h.264 uses 'Main' profile rather than 'High'.

EDIT: Take a look at these two images - I can't read Russian, so I can't make a comparison-thingy like you did (note that both images have 200% nearest neighbor applied to make them easier to see):
WebM (http://i.imgur.com/lRsSD.png)
H.264 (http://i.imgur.com/ke1ah.png)

It would seem that it's not as clear-cut as it is for 720p. The HUD, sky, and building on the left looks better on h.264, but the water and track looks better on WebM. The spires in the distance are a toss-up to me.

[Rumbah]

But aren't the .flv ones H263, only the mp4s are H264?

[Nintendo Maniac 64]

No, only 240p uses h.263. All other resolutions use h.264, but only the HD resolutions use 'High' profile, while the 360p and 480p FLV formats use 'Main'. (the 360p MP4 format uses 'Baseline')

Or at least, that's what it was when I last checked around 6 months ago. (about the same time they added 480p WebM)

[poisondeathray]

Both 480p versions look bad overall.

Some frames are better in the h.264 version, some are worse

A single frame doesn't tell the whole story. You could cherrypick and chose if you had an agenda. eg. You might compare a I frame vs. a P frame for example

[Nintendo Maniac 64]

Both 480p versions look bad overall.

F-Zero GX is known to be notoriously hard for video compression due to its extremely high-speed gameplay without using any "softening" post-process effects like bloom lighting and motion blur that many modern games use. This in turn is the exact reason why I like to use it for video quality and performance tests. ;)

A single frame doesn't tell the whole story. You could cherrypick and chose if you had an agenda. eg. You might compare a I frame vs. a P frame for example

That's why I didn't do a single frame comparison originally. However, someone ended up doing one anyway, but with the wrong resolution in question. Therefore I had no choice but to follow up...

[poisondeathray]

Well h.264 has the potential to do a better job.

If this is correct, webm seems gets preferential audio treatment with higher bitrate (vorbis)
http://en.wikipedia.org/wiki/YouTube#Quality_and_codecs

Maybe it's youtube/google's attempt at sabotage , and increasing the relevance of webm? :sly:

[Nintendo Maniac 64]

But my internet bandwidth doesn't have the potential to stream 720p. >_>

As for the audio, at 480p, both audio codecs have the same bitrate, and yet SUPPOSEDLY WebM still had better audio quality.

[poisondeathray]

As for the audio, at 480p, both audio codecs have the same bitrate, and yet SUPPOSEDLY WebM still had better audio quality.

Hmmm, that's not what mediainfo shows

480p h.264

Audio
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 10
Duration : 4mn 19s
Bit rate : 96.7 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 KHz
Compression mode : Lossy
Stream size : 2.99 MiB (6%)



480p webm

udio
ID : 2
Format : Vorbis
Format settings, Floor : 1
Codec ID : A_VORBIS
Duration : 4mn 19s
Bit rate mode : Variable
Bit rate : 128 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Compression mode : Lossy
Stream size : 3.95 MiB (10%)
Language : English



And in case mediainfo is incorrect, demuxed audio filesize

AAC 3.03MB
vorbis 4.00MB

[Nintendo Maniac 64]

Using this as my example video (uploaded only 2 weeks ago):
http://www.youtube.com/watch?v=tel_s-wfsxk

MediaInfo says 129kbps for the 480p FLV and 128kbps for the 480p WebM.

(I have no idea how you did exported that info, so you'll just have to download the videos and see yourself)


EDIT: The FLV's audio by itself in an MKA is 2.25MB while the WebM's is 2.26MB.

[poisondeathray]

Using this as my example video (uploaded only 2 weeks ago):
http://www.youtube.com/watch?v=tel_s-wfsxk

MediaInfo says 129kbps for the 480p FLV and 128kbps for the 480p WebM.

(I have no idea how you did exported that info, so you'll just have to download the videos and see yourself)

Audio bitrate looks to be about the same in this example, but big discrepancy in video bitrate for the 480p versions

WebM 1630kbps
h.264 1182kbps

I don't know what you mean by "export that info", did you mean mediainfo report? use view=>text then copy & paste :)

[Nintendo Maniac 64]

Yes, the video bitrate IS a lot higher for WebM. It would seem they've changed a setting between when that first video I linked to was uploaded, because it has the WebM verson have a SMALLER filesize than the FLV.

But about the audio, from what I've read on the internets, even with the same bitrate the WebM's audio is supposedly higher quality due to the AAC encoder YouTube uses or something.