WebM Exciting New Video Standard with VP8, Vorbis, Matroska

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

Originally Posted by 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

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-izmenen...omecinema.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]

Originally Posted by foxyshadis

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]

Originally Posted by iwod

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]

Originally Posted by iwod

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]

Originally Posted by 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.

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]

Originally Posted by 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.

jup, WebM is in developer preview aka beta, it will impove over time

[hajj_3]

new blog update from google: http://webmproject.blogspot.com/2010...date.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]

Originally Posted by 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...

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

[hellfred]

Originally Posted by wiak

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
Patch history

[dapperdan]

Originally Posted by 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...

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.