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

RE[14]: Comment by hornett
by smitty on Sat 2nd Oct 2010 19:31 in reply to "RE[13]: Comment by hornett"
smitty Member since:
2005-10-13

How the heck did this turn into another x264 vs VP8 argument? I thought this was supposed to be about JPEG and WebP.

Reply Parent Score: 2

RE[15]: Comment by hornett
by Gusar on Sun 3rd Oct 2010 12:09 in reply to "RE[14]: Comment by hornett"
Gusar Member since:
2010-07-16

WebP *is* VP8. It's the same libvpx creating the video I posted and WebP images. But ok, you want an images comparison? Here you go:

To create the jpeg, I used GIMP and saved the original with a quality of 30. Why that low? So you can easily see the difference to the original. For webp I used 'webpconv -quality 51', so the filesize was approximately the same - 38415 bytes for jpeg, 38826 bytes for webp.
Then I converted the webp image to png, for easy viewing in the browser.

Original: http://www.imagebam.com/image/c5ce0e100464038
Jpeg: http://www.imagebam.com/image/4b0505100464040
WebP converted to png: http://www.imagebam.com/image/4ae1f4100464043

WebP, before converting to png: http://www.sendspace.com/file/2nnbc9

The background is annoyingly blocky on the jpeg, at quality 30, that's no surprise. But look at the cat. Looks very ok in the jpeg, looks like quite a blur in webp.

Reply Parent Score: 1

RE[14]: Comment by hornett
by Valhalla on Sun 3rd Oct 2010 19:40 in reply to "RE[13]: Comment by hornett"
Valhalla Member since:
2006-01-24

I knew you'll find something wrong with my approach.

Well, obviously if you are going to compare the best quality between two encoders you will use the highest quality setting for both encoders. Anything else is pointless since there's no way of knowing how one mid-level setting corresponds to a mid-level setting on another encoder, but best is best.

You know why I used those settings? Cos they're realistic.

Sorry, you don't get to define what is realistic settings. Depending on available processing power and or target quality practically any setting can be realistic. This is why there's a ton of presets available for most encoders, otherwise all we would need is one called realistic.


Using --best would be akin to using preset placebo with x264.

Bullshit conclusion, like the name implies, x264's 'placebo' preset is aptly named as such because it really makes no perceptually visual difference, only takes more time to encode. Libvpx's BEST setting is named 'BEST', not placebo. The fact that libvpx does not have a 'placebo' preset (like tons of other encoders don't have one either) only means that not every encoder sees it fit to add such a setting (and I can't blame them).


And the thing is, it wouldn't change the results. Not by much. Both encoders would just be a lot slower, while slightly better.

I'd put no stock in tests by someone who claims to know the results beforehand. Objective? I don't think so.

Reply Parent Score: 2

RE[15]: Comment by hornett
by Gusar on Sun 3rd Oct 2010 21:41 in reply to "RE[14]: Comment by hornett"
Gusar Member since:
2010-07-16

I'd put no stock in tests by someone who claims to know the results beforehand. Objective? I don't think so.

Yes, I claim to know the results beforehand. But I'm not pulling stuff out of thin air, I have the two encodes I already did, so I'm making an educated estimation based on those.
libvpx loses to x264 heavily when both use their second slowest setting. You think this will change if I use the slowest setting for both? Of course not.

But well, I already did a libvpx encode with --best. It took 32 minutes. I'll now do an x264 encode with preset veryslow, then come back here with the results. And when they'll be exactly like I said they would be based on my educated estimation, what will you say then? What will you find then to attack me?

Reply Parent Score: 1

RE[15]: Comment by hornett
by Gusar on Sun 3rd Oct 2010 23:14 in reply to "RE[14]: Comment by hornett"
Gusar Member since:
2010-07-16

Ok, here we go:
libvpx

$ time wine avs2yuv VTS_01_1.avs -o - | ivfenc -w 720 -h 432 --passes=2 --pass=1 --fpf=1pass_vp8_best.log -t 4 --best --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_best.log -t 4 --best --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_best.ivf

Pass 1/2 frame 7623/7624 975872B 1024b/f 25603b/s 90886 ms (83.87 fps)
real 1m55.022s
Pass 2/2 frame 7623/8137 40024996B 42004b/f 1050111b/s 1920373 ms (3.97 fps)
real 32m46.961s

x264
time wine avs2yuv VTS_01_1.avs -o - | x264 --pass 1 --stats 1pass_x264_veryslow.log --bitrate 1050 --preset veryslow --tune film --sar 64:45 --demuxer y4m -o /dev/null - && time wine avs2yuv VTS_01_1.avs -o - | x264 --pass 2 --stats 1pass_x264_veryslow.log --bitrate 1050 --preset veryslow --tune film --sar 64:45 --demuxer y4m -o video_veryslow.264 -

encoded 7623 frames, 44.03 fps, 1031.17 kb/s
real 2m56.913s
encoded 7623 frames, 7.37 fps, 1050.69 kb/s
real 17m14.997s

Well interesting, x264 at veryslow was faster than libvpx at --good.
And now the screenshots, only two this time, but they should be enough to validate my claim:
x264_2_veryslow: http://www.imagebam.com/image/e3ab5d100545286
libvpx2_best: http://www.imagebam.com/image/64a4fb100545289

x264_3_veryslow: http://www.imagebam.com/image/963456100545290
libvpx3_best: http://www.imagebam.com/image/61d057100545293


As you can see if you compare to the previous encodes, not much has changed except it took longer to encode. The huge difference between x264 and libvpx remains. *Exactly* as I said.

Reply Parent Score: 1

RE[14]: Comment by hornett
by Neolander on Sun 3rd Oct 2010 20:14 in reply to "RE[13]: Comment by hornett"
Neolander Member since:
2010-03-08

I knew you'll find something wrong with my approach. You know why I used those settings? Cos they're realistic.

Wrong. At constant filesize, all presets are just as realistic. Depending on the circumstances, people will take their pick and choose their quality preset according to some little tests used to estimate the quality/encode time ratio of each preset.

Edited 2010-10-03 20:14 UTC

Reply Parent Score: 2

RE[15]: Comment by hornett
by Gusar on Sun 3rd Oct 2010 21:35 in reply to "RE[14]: Comment by hornett"
Gusar Member since:
2010-07-16

What I meant by "realistic" is a setting one would use to encode their videos. Would you use the slowest encoder setting on a Core i3 processor? I wouldn't. It would take too long.
libvpx with --best took 32 minutes on the sample clip, more than 3x as slow as the x264 encode with preset slower. I would not use this setting to encode full movies, or further, full seasons of a tv show. And we'll see if the increase in encoding time is worth it, once I take a look at the result. My guess: it isn't. Stay tuned for results, which I'll post in the other comment, once the x264 encode finishes.

Edited 2010-10-03 21:48 UTC

Reply Parent Score: 1