Linked by Thom Holwerda on Thu 30th Sep 2010 23:04 UTC
Google A few months ago, Google open sourced the VP8 video codec as part of the WebM video project, to create a truly Free/free unencumbered video format for the web as an answer to the non-Free/free patent-encumbered H264 format. Today, Google launched a new image format for the web, WebP, which aims to significantly reduce the file size of photos and images on the web.
Thread beginning with comment 443483
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[9]: Comment by hornett
by Gusar on Sat 2nd Oct 2010 00:44 UTC in reply to "RE[8]: Comment by hornett"
Gusar
Member since:
2010-07-16

Also, webm not being as good as h264 doesn't make 'completely blow', that's just the fanboy in you talking.

No, the fact that it completely blows makes it completely blow. A blurry mess, devoid of any details. That you need to resort to name-calling only confirms me saying that you are the one with a bias.

I know that vp8 is royalty free and I know the web needs such a codec. The problem is that libvpx is *not* good enough. If Google was smart, they'd hire Dark Shikari to work on a high quality vp8 encoder. It's not the format that blows, it's libvpx, the currently only publicly available encoder for that format.

Reply Parent Score: 1

RE[10]: Comment by hornett
by Valhalla on Sat 2nd Oct 2010 01:59 in reply to "RE[9]: Comment by hornett"
Valhalla Member since:
2006-01-24

No, the fact that it completely blows makes it completely blow.

How was that 'fact' established? By you when you encoded your favourite Firefly episode and cried out, "dude, this completely blows"? Really...


The problem is that libvpx is *not* good enough.

Again, says you.


If Google was smart, they'd hire Dark Shikari to work on a high quality vp8 encoder.

I doubt that would be smart, due to having implemented h264 patented techniques into x264 he would likely be 'tainted' by that code (should anything he added to vp8 be similar to patented h264 techniques it's not as if he could ever feign ignorance). And it's very doubtful that he has any clue himself as to what is or isn't patented in the h264 specs since by his own admission he doesn't give a crap about software patents. I'm sure Google would love being able to say that aswell but with all their money and competitors they're a prime target for patent litigation.

Reply Parent Score: 3

RE[11]: Comment by hornett
by Gusar on Sat 2nd Oct 2010 09:49 in reply to "RE[10]: Comment by hornett"
Gusar Member since:
2010-07-16

The fact can be established by everyone doing a test. Have you done one? Two pass encodes targeting the same bitrate, one with x264, one with libvpx. Then compare the videos. As another commenter said, go ahead, disprove me.
I don't have videos from my test anymore, so I'm running a new one. Once it's done, I'll edit this post, adding commandlines used and a few screenshots.

What you write about 'tainting' is nonsense. If there's techniques in vp8 that are covered by h264 patents, they're already there, whether DS touches the code or not.

Reply Parent Score: 1

RE[11]: Comment by hornett
by Gusar on Sat 2nd Oct 2010 15:02 in reply to "RE[10]: Comment by hornett"
Gusar Member since:
2010-07-16

Alright, here we go. The source is Serenity, chapter 3, PAL DVD. The video has 7623 frames and is 5:04.88 long. Avisynth script is simple, it just crops away the black borders:
MPEG2Source("VTS_01_1.d2v")
crop(0,76,720,432)

Encoding is done on a 32bit Linux installation on a Core i3-530 processor, using the performance CPU governor (which means the proc is running at a constant 2.93 GHz). The encoder versions, commandlines and encoding times (I ommited user and sys time, they're not important IMO):

x264 core:106 r1732 b20059a

$ time wine avs2yuv VTS_01_1.avs -o - | x264 --pass 1 --stats 1pass_x264.log --bitrate 1050 --preset slower --tune film --bframes 5 --sar 64:45 --demuxer y4m -o /dev/null - && time wine avs2yuv VTS_01_1.avs -o - | x264 --pass 2 --stats 1pass_x264.log --bitrate 1050 --preset slower --tune film --bframes 5 --sar 64:45 --demuxer y4m -o video.264 -

encoded 7623 frames, 69.22 fps, 1031.23 kb/s
real 1m50.370s
encoded 7623 frames, 13.50 fps, 1050.72 kb/s
real 9m25.097s

WebM Project VP8 Encoder v0.9.2-75-gf143a81
$ time wine avs2yuv VTS_01_1.avs -o - | ivfenc -w 720 -h 432 --passes=2 --pass=1 --fpf=1pass_vp8.log -t 4 --good --cpu-used=1 --target-bitrate=1050 --end-usage=0 --auto-alt-ref=1 --timebase=1000/25000 -v --minsection-pct=5 --maxsection-pct=800 --lag-in-frames=16 --kf-min-dist=0 --kf-max-dist=250 --token-parts=2 --static-thresh=0 --min-q=0 --max-q=60 - /dev/null && time wine avs2yuv VTS_01_1.avs -o - | ivfenc -w 720 -h 432 --passes=2 --pass=2 --fpf=1pass_vp8.log -t 4 --good --cpu-used=1 --target-bitrate=1050 --end-usage=0 --auto-alt-ref=1 --timebase=1000/25000 -v --minsection-pct=5 --maxsection-pct=800 --lag-in-frames=16 --kf-min-dist=0 --kf-max-dist=250 --token-parts=2 --static-thresh=0 --min-q=0 --max-q=60 - video.ivf

Pass 1/2 frame 7623/7624 975872B 1024b/f 25603b/s 84996 ms (89.69 fps)
real 1m49.125s
Pass 2/2 frame 7623/8130 40026495B 42006b/f 1050150b/s 1083929 ms (7.03 fps)
real 18m31.322s

theora-ptalarbvorm SVN revision 17478
$ time wine avs2yuv VTS_01_1.avs -o - | encoder_example --first-pass 1pass_theora.log -V 1050 -k 250 -s 64 -S 45 -o /dev/null - && time wine avs2yuv VTS_01_1.avs -o - | encoder_example --second-pass 1pass_theora.log -V 1050 -k 250 -s 64 -S 45 -o video.ogg -

Scanning first pass....
0:05:04.88 audio: 0kbps video: 0kbps
real 3m33.261s
Compressing....
0:05:04.92 audio: 0kbps video: 1052kbps
real 3m28.738s

In case you're wondering about the vp8 settings, they're from here: http://www.webmproject.org/tools/encoder-parameters/ - "2-Pass Faster VBR Encoding"
Also note how x264 is acutally quite a bit faster than libvpx. It didn't used to be the case, v0.9.1 took about 10 minutes at the same settings, so the encoder got slower.

Now of course, the meat of this test - the screenshots:
http://www.imagebam.com/gallery/ylkht70jtcgkkzvu7lccsidsfo9yx1ww/
For each of the five screenshots, the order is: original, x264, libvpx, theora-ptalarbvorm

In the first shot libvpx does very well actually, only theora really stands out. The third one though, libvpx completely fails, even theora manages a bit better. The fifth is almost transparent, except with theora. So there are moments livpx does well. Unfortunately there are other moments where it totally fails.

Reply Parent Score: 1