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 443538
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[11]: Comment by hornett
by Gusar on Sat 2nd Oct 2010 15:02 UTC 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

RE[12]: Comment by hornett
by Valhalla on Sat 2nd Oct 2010 15:44 in reply to "RE[11]: Comment by hornett"
Valhalla Member since:
2006-01-24

By just skimming over this I wonder why are you not using the BEST quality on both encoders? Instead of picking the 'slower' preset for x264 and 2-Pass Faster VBR Encoding for libvpx. Atleast go for 'veryslow' ('placebo' is pretty much placebo from my own tests) for x264 and 2-Pass Best Quality VBR Encoding for libvpx. Trying to mix and match mid-level presets between encoders is pretty much doomed to fail, only fair comparison is when using them both at their BEST settings.

Reply Parent Score: 2

RE[13]: Comment by hornett
by Gusar on Sat 2nd Oct 2010 16:21 in reply to "RE[12]: Comment by hornett"
Gusar Member since:
2010-07-16

I knew you'll find something wrong with my approach. You know why I used those settings? Cos they're realistic. When I encoded the whole Serenity movie, that's what I used - preset slower. And the "2-Pass Faster VBR Encoding" for libvpx is actually the second slowest available, at least according to that site. Using --best would be akin to using preset placebo with x264.

And the thing is, it wouldn't change the results. Not by much. Both encoders would just be a lot slower, while slightly better. But their massive difference would remain. I can indulge you though, I can make another libvpx encode, using --best, in fact, I've just started such an encode now.
But it doesn't bode well for an encoder to be that much slower, while producing so much worse quality in several parts of a video.

Reply Parent Score: 1