AV1, VP9, x265, x264 low bitrate comparison

[sneaker_ger]

x264 and x265 have --ipratio and --pbratio to set qp ratio between IP and PB. By default 1.4 and 1.3.

[Tommy Carrot]

Originally Posted by sneaker_ger

x264 and x265 have --ipratio and --pbratio to set qp ratio between IP and PB. By default 1.4 and 1.3.

Yep, the problem with VP9 and probably with AV1 is that the golden frames are boosted way more than that. The quality fluctuation in x264 and x265 is not really noticeable, while i can't say that about vp9. Daala had the same problem in the later iterations, so using its rate control will not fix this issue.

[IgorC]

Originally Posted by karasu

They look terrible indeed, but who talked about ripping blu-ray? In this case I wanted to see the visual degradation. Beside, there are fare worse quality in production everywhere on the Web.

Also, current encoding speed is also a problem IMO.

Interesting test. Wow, I didn't expect VP9 would that better than x265 at low bitrates.

It would be great to see how they perform at Youtube bitrate ~1.5-2 Mbps 1080p or Netflix's ~2-4 Mbps 1080p.

[karasu]

I updated the page with links to actual video files. AV1 is kinda useless as it can only be decoded by aomdec. Can someone tell whatI messed up by muxing the x264 flux to mp4 ? (ffmpeg -i x264.x264 -c:v copy -movflags +faststart x264.mp4) The video is stuttering in the browser (VLC playback is fine).

Also I added frame 260, where I believe x265 does a better job to keep details behind the smoke.

http://video.1ko.ch/codec-comparison/

[sneaker_ger]

ffmpeg is not writing the ctts atom for re-ordering. Use mp4box or l-smash muxer.

[karasu]

Originally Posted by sneaker_ger

ffmpeg is not writing the ctts atom for re-ordering. Use mp4box or l-smash muxer.

Thanks, the file has been replaced.

[colinhunt]

I thought it might be fun to resurrect this thread a bit, and to see how codecs have improved since karasu created the comparison. I re-created his source and used either the same or equivalent cmdlines to encode new x265 and vp9 files, then ran some 3ssim comparisons.

(post-re-doing karasu's encodes)

So, yeah, I'm a dumbass. Nevcairiel spotted a problem with the earlier metric graphs. The problem was that I used karasu's VP9 and x265 encodes that he had made from his source file. I did not have his source file so I created one from the same Tears of Steel PNGs, using the same method, and thinking that of course the result is an identical source.y4m. Well, nope.

I tried to find the exact same encoder exes karasu used and did find vp9 v1.6.1 and x265 v2.3, although not exactly the same build numbers. I'm re-encoding "old-vp9" and "old-x265" files from my source file.

Here's the 3ssim metric for x265 v2.3 and x265 v2.7 versus source:



Average score (dotted line) is a little bit higher for v2.7.

Here's the 3ssim for VP9 1.6.1 and VP 1.7.0 versus source:



1.7.0 has a very slightly higher average score.

And here's the VP 1.7.0 and x265 v2.7 versus source 3ssim graph:



VP9 has a higher average score than x265 in this metric.

[nevcairiel]

It seems curious that old-VP9 and old-x265 have basically the same shape and practically identical values in the graph, only extremely minor differences. That seems somewhat unlikely, considering the "new" graphs look quite a bit different.

[colinhunt]

Originally Posted by nevcairiel

It seems curious that old-VP9 and old-x265 have basically the same shape and practically identical values in the graph, only extremely minor differences. That seems somewhat unlikely, considering the "new" graphs look quite a bit different.

Yup, I done goofed. Thanks for pointing it out!

[colinhunt]

Here's an interesting one. 2-pass 545kbps VP9 1.7.0 versus 233kbps 1-pass xvc. The outcome's not in doubt for one second, but xvc puts up a good fight between frames 200 and 300.

[Asmodian]

That is interesting, that section is also where x265 does noticeably better than VP9. I wonder if it is simply a difference in bit rate distribution.

[colinhunt]

I re-encoded the xvc sample with qp33 instead of qp40, resulting in a bitrate of 587 kbps. Still single pass, still using speed-mode 2 (i.e. Fast):



xvc got a higher average score than vp9 in this metric, although with a slightly higher bitrate than vp9 encode.

[colinhunt]

The 587kbps xvc encode looks pretty good, all things considered, so I piped it from xvc decoder to ffmpeg and encoded the output in lossless h.264.

190 MB / 94 Mbps, take a peek: https://drive.google.com/open?id=1Lg...fi9uYqLnYQ9Aw8