WebM Exciting New Video Standard with VP8, Vorbis, Matroska

[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