Doom9's Forum - View Single Post

mandarinka · 8th March 2019, 19:56

I ran a new test of Rav1e on the same source as in this past post last year: https://forum.doom9.org/showpost.php...&postcount=882
(the motivation was a claim that Rav1e supposedly started to beat x264 "at any bitrate" so I thought I could as well repeat my highly specific test - note that this is by no means supposed to be authoritative. Unless you care about this type of content which I do.)

I used the last Rav1e release available at the time, at quality 20 and speed 0, tune psy. There are no other tuning options, so I could not do any tweaks - not my fault, that's the developers' policy. Resulting bitrate was 14526kbps. Encoding speed was 0.005 fps on Ryzen 3 2200G (~1 core used).

My x264 commandline is kind of tuned for this content - I copied what I last used on a similar bluray (but I dropped --qpmax which probably worsens efficiency). Note that three pass was used to get closer to Rav1e's bitrate but due to the short length probably, x264 still undershot (14337 kbps). Using three pass should not give quality boost.
The encoding speed was about 0.05 fps due to extremely placebo settings and 1 thread used (same as Rav1e). You could probably get 0.3 without much if any damage to quality.

Here are images from the encode: http://imgbox.com/g/yrCWrTYtF4
In the dust storm scene that uses higher bitrate than the rest and is at the start of the 910frame clip, Rav1e does well and it seems to be very close - I am not totally convinced it is as good as x264 as I think there are some signs of kinda low-passing the noisy blocks, but I am not completely confident it is worse either, although I am inclined to say x264 is in fact better here.

The rest of the clip has Rav1e clearly deficient despite the large bitrate though. It constantly smoothes the solid/flat areas and generally can't keep the milder grain and texture (which is a flaw). So its psychovisual decisions probably still aren't ready for high quality transparent encoding. This is a general problem with any non x264/x265 encoder probably, even x265 would drop texture detail everywhere before it got aq and psyrdo.

I'm trying to upload the source and streams (not fun to reproduce the Rav1e one hah), but uloz.to seems to fail on me. One thing that I should perhaps note about source - it has its chroma temporally denoised (not luma). In case that particularly matters for rav1e rate control... it only has constant quantizer mode though, afaik.

Commandlines:
rav1e.exe --speed 0 --quantizer 20 --tune Psychovisual n:\test.y4m -o psy-q20-speed0.ivf

x264-2935-64.exe n:\etr-testLL.mkv --qcomp 0.60 --aq-mode 1 --pass 3 --bitrate 14526 --no-mbtree --min-keyint 5 --keyint 240 --b-pyramid normal --deblock 0:0 --psy-rd 1.0:0.0 --aq-strength 0.8 --preset placebo --bframes 9 --direct auto --me tesa --merange 64 --subme 11 --threads 1 --colormatrix bt709 --sar 1/1 --chromaloc 0 --input-range tv --range tv --force-cfr --fps 24000/1001 -o n:\test-etr-x264-10bit-noqpmax.mkv --output-depth 10 --stats n:\noqpm.txt

8th March 2019, 19:56	#1530 \| Link
mandarinka Registered User Join Date: Jan 2007 Posts: 729	Rav1e versus x264 on cel/film anime source I ran a new test of Rav1e on the same source as in this past post last year: https://forum.doom9.org/showpost.php...&postcount=882 (the motivation was a claim that Rav1e supposedly started to beat x264 "at any bitrate" so I thought I could as well repeat my highly specific test - note that this is by no means supposed to be authoritative. Unless you care about this type of content which I do.) I used the last Rav1e release available at the time, at quality 20 and speed 0, tune psy. There are no other tuning options, so I could not do any tweaks - not my fault, that's the developers' policy. Resulting bitrate was 14526kbps. Encoding speed was 0.005 fps on Ryzen 3 2200G (~1 core used). My x264 commandline is kind of tuned for this content - I copied what I last used on a similar bluray (but I dropped --qpmax which probably worsens efficiency). Note that three pass was used to get closer to Rav1e's bitrate but due to the short length probably, x264 still undershot (14337 kbps). Using three pass should not give quality boost. The encoding speed was about 0.05 fps due to extremely placebo settings and 1 thread used (same as Rav1e). You could probably get 0.3 without much if any damage to quality. Here are images from the encode: http://imgbox.com/g/yrCWrTYtF4 In the dust storm scene that uses higher bitrate than the rest and is at the start of the 910frame clip, Rav1e does well and it seems to be very close - I am not totally convinced it is as good as x264 as I think there are some signs of kinda low-passing the noisy blocks, but I am not completely confident it is worse either, although I am inclined to say x264 is in fact better here. The rest of the clip has Rav1e clearly deficient despite the large bitrate though. It constantly smoothes the solid/flat areas and generally can't keep the milder grain and texture (which is a flaw). So its psychovisual decisions probably still aren't ready for high quality transparent encoding. This is a general problem with any non x264/x265 encoder probably, even x265 would drop texture detail everywhere before it got aq and psyrdo. I'm trying to upload the source and streams (not fun to reproduce the Rav1e one hah), but uloz.to seems to fail on me. One thing that I should perhaps note about source - it has its chroma temporally denoised (not luma). In case that particularly matters for rav1e rate control... it only has constant quantizer mode though, afaik. Commandlines: rav1e.exe --speed 0 --quantizer 20 --tune Psychovisual n:\test.y4m -o psy-q20-speed0.ivf x264-2935-64.exe n:\etr-testLL.mkv --qcomp 0.60 --aq-mode 1 --pass 3 --bitrate 14526 --no-mbtree --min-keyint 5 --keyint 240 --b-pyramid normal --deblock 0:0 --psy-rd 1.0:0.0 --aq-strength 0.8 --preset placebo --bframes 9 --direct auto --me tesa --merange 64 --subme 11 --threads 1 --colormatrix bt709 --sar 1/1 --chromaloc 0 --input-range tv --range tv --force-cfr --fps 24000/1001 -o n:\test-etr-x264-10bit-noqpmax.mkv --output-depth 10 --stats n:\noqpm.txt Last edited by mandarinka; 8th March 2019 at 19:59.