libvpx 1.4.0 Brings Faster VP9 Encode/Decode

[Gusar]

Xvid looks a bit darker than the others.

Oops. I took that snapshot with mplayer2, because it did a better job seeking in a raw m4v stream, while the others were done with mpv. mplayer2 is screwy, its snapshots look different from how they should be. Will keep that in mind for the next test.

It might be fun to strip off the _[codecId].png tags and play "guess the video codec" for the same bit-rate.

Yeah, that might be fun.

But on the other hand, when I post these, it's so that I can later point to the test whenever someone claims that vpx is supposedly better than h264, and for this reason it's better that the pics are properly labelled.

I find it really interesting that all the pics look the same to you. I doubt you'll feel the same in the next test - Serenity chapter 3 is a dark scene that bad encoders very noticeably destroy. An example from a few years ago, note the bolts around the door:
x264: http://www.imagebam.com/image/f5c3bf100322922
vp8: http://www.imagebam.com/image/09d080100322923

vp8 has gotten a lot better since then, so the difference will not be so drastic now.

[OneTimeShot]

I find it really interesting that all the pics look the same to you. I doubt you'll feel the same in the next test

Yeah that one is noticeably better for x264. Do you have a feel for "XX% higher bit rate for the same picture quality"?

I mentally classify video in these chunks:
- MPEG1 "look! a moving picture"
- MPEG2 "basically the same thing - 320x240 DVD"
- MPEG4 "pirated stuff"
- H264 "1080p Bluray"
- H265 "hi-res/4k"

I've always assumed that switching MPEG4 -> Theora, H264 -> VP8 and H265 -> VP9 were basically between 10% and 20% bigger files for the same quality.

[Ansla]

LOL - I've opened them all in different tabs to switch between them, and I really can't tell which one looks better than another. They all just look like slightly-too-compressed images to me. Honest!

Indeed, I only opened the original and it looks horible. Having so many encoding artifacts in the sorce can not possible lead to a good output. Encoding tests should only be made when using an uncompressed source. That basically means Big Buck Bunny and friends.

[Gusar]

Encoding tests should only be made when using an uncompressed source.

Encoding tests should be done on videos people will actually encode. Which means DVDs and Blu-rays, and camera recordings. Clean sources such as Big Buck Bunny are the exception, not the norm.

Anyway, did the Serenity test today...

Encoder settings: http://pastebin.ca/2968939
Encoder speed: http://pastebin.ca/2968940

Sample pictures (in each set, the order is: original, theora, vp8, vp9, x264, x265, xvid):

http://www.imagebam.com/gallery/mi8nde2rfmk17itz72n185tsk6uhcsoy/

x264 is both fast and produces the highest quality. x265 isn't there yet, the years of tuning x264 for now beat the modern tech x265 has at its disposal. Once x265 matures more, this will very likely change. vp8 and vp9 are what they are, not up to x264 quality, but vp8 is at least really fast.

And again for the critics of my choice of video: And an encoder should do well on all videos, including dark scenes such as this one. You may think of this as testing an extreme, if you want. But such an extreme is more common than academic exercises such as Big Buck Bunny.

[Ansla]

Encoding tests should be done on videos people will actually encode. Which means DVDs and Blu-rays, and camera recordings. Clean sources such as Big Buck Bunny are the exception, not the norm.

If you want to compare pure codec quality (like lets say what codec should your next smart phone use to encode your home videos) then you need RAW video files, there is no other way.

For measuring the "satisfaction of the average pirate", then Bluray is the way to go. And transcoding will always favor the codec that is most similar to the original one.

[Gusar]

If you want to compare pure codec quality (like lets say what codec should your next smart phone use to encode your home videos) then you need RAW video files, there is no other way.

If you want to play academics, you can do so. I want to see what the codecs currently available can do with with real-world(tm) videos.

For measuring the "satisfaction of the average pirate", then Bluray is the way to go

Not sure where pirates enter into this, they won't be encoding anything. And more than just Blu-ray exists and will be thrown at encoders, so why are you limiting yourself to just that?

And transcoding will always favor the codec that is most similar to the original one.

All of these codecs are DCT-based, with block-based motion compensation, so while you're correct, no codec is favored over another based on this.

Also, DVDs are high-bitrate (for their resolution) and as such don't exhibit heavy codec artifacts, so you can't claim codec A won over codec B because it could better deal with mpeg2-style artifacts. All encoders in the comparison stand on their merits and their merits alone.

[stqn]

x264 is both fast and produces the highest quality. x265 isn't there yet

I’m surprised by this conclusion. Looking at your settings I see you’ve used --preset slow for x265 and --preset slower for x264. There is nothing better than slow available for x265? Also I’d have used --preset veryslow to get the best quality.

[Gusar]

Looking at your settings I see you’ve used --preset slow for x265 and --preset slower for x264.

First, the profiles are not directly mappable. Second, x265 is already helluva slow, using a more aggressive setting would slow it down even more. Third, I did the same with vpx - weaker settings with vp9 compared to vp8, but despite that vp9 produced better quality (too bad vp9 is pretty much unusably slow). Fourth, to give it a chance, I did an additional encode with --preset slower and --tune grain, in an attempt to preserve more detail - it was ridiculously slow (22.x fps in the first pass, only 5.3x fps in the second pass) and the quality was only marginally better, it was still noticeably worse than x264.

Bottom line: In the third example pic, x264 is the only one that preserved both the bolts around the door and the belt on Mal's back. Despite having better tech at its disposal and taking a lot more time to do its job, x265 can't yet deliver the quality of x264. Years of tuning apparently trumps technical features. Like I said, I expect x265 to get better as it matures (vp8 was total crap a few years ago, both speed- and quality-wise; now it's really fast and ok quality), but it's not there yet.

[smitty3268]

Like I said, I expect x265 to get better as it matures (vp8 was total crap a few years ago, both speed- and quality-wise; now it's really fast and ok quality), but it's not there yet.

I'm not sure why you expect x265 to mature over time due to having better technology, but don't extend the same logic to VP9 since it also has better tech than h264.

To me, the VP9 and h265 images look very similar to one another. The x264 is still probably slightly closer to the original, though it was close enough that i don't think it's a major difference.

[Guest]

Yeah that one is noticeably better for x264. Do you have a feel for "XX% higher bit rate for the same picture quality"?

I mentally classify video in these chunks:
- MPEG1 "look! a moving picture"
- MPEG2 "basically the same thing - 320x240 DVD"
- MPEG4 "pirated stuff"
- H264 "1080p Bluray"
- H265 "hi-res/4k"

I've always assumed that switching MPEG4 -> Theora, H264 -> VP8 and H265 -> VP9 were basically between 10% and 20% bigger files for the same quality.

You do realize that MPEG4 and H264 can be the same thing? The problem lies in version of the standard, mpeg4 can quote/unquote "family" of standards, while H264 is video codec standard (also having various versions and iterations, though there is a preset called "baseline" that is defacto the "standard").
Same goes for everything else, there are tons of standards of various names, versions and presets implemented by various programs, on CPU or directly within the hardware.

Reminds me of:


But it's way more complicated, for example, I can write baseline encoder/decoder for JPEG (rather JFIF) in few days, but if I was to implement the whole standard I would be bogged for months, sifting trough incredible number of things that nobody really uses. Getting anything done right or compare two things "correctly" is downright impossible.

What is the main thing good about H264 standard and what allowed it to catch on is the relative ease of hardware implementation, this allowed it to be prevalent in cameras (the thing you used to shoot photoes with before smartphones happened :-))