A better compromise between medium and slow preset

[alex.brown111@hotmail.com]

Hi,

I have tried different test by changing the presets and after a deep analisys I have ended to this conclusion:

1) Slow vs Slower: there is not too much difference in term of quality.
2) Medium vs Slow: there is a remarkable quality difference but need much more encoding time.

My 8 TB disk is full (I have ripped many blu ray and DVD) so I like to save space.

Actually I use this command:

ffmpeg.exe -vsync 1 -i "input.mkv" -y -c:v libx265 -crf 21 -pix_fmt yuv420p10le -preset slow "output.mkv"

and I' am satisfied about the quality that is very closed the original and I save 4/5 times the space.

Unfortunatenly I have a slow CPU with 4 core Intel I5 6600T and I get 0.23x.

I ask if there a way to get a better compromise between slow and medium preset.

Thank you !

[tonemapped]

Hi,

I have tried different test by changing the presets and after a deep analisys I have ended to this conclusion:

1) Slow vs Slower: there is not too much difference in term of quality.
2) Medium vs Slow: there is a remarkable quality difference but need much more encoding time.

My 8 TB disk is full (I have ripped many blu ray and DVD) so I like to save space.

Actually I use this command:

ffmpeg.exe -vsync 1 -i "input.mkv" -y -c:v libx265 -crf 21 -pix_fmt yuv420p10le -preset slow "output.mkv"

and I' am satisfied about the quality that is very closed the original and I save 4/5 times the space.

Unfortunatenly I have a slow CPU with 4 core Intel I5 6600T and I get 0.23x.

I ask if there a way to get a better compromise between slow and medium preset.

Thank you !

It depends on the content. For content with very little grain/noise, I find medium can be used where ~45m of content takes ~2h of encoding time with reasonable quality. This is done with a 4C/4T Xeon E3-1220v5 @ 3.3GHz (it's my 4U storage box with 230TB).

It's usually on 24/7, but it's currently powered down due to the heatwave in the UK (34°C indoors in my apartment) so can't post a log. I will do so once it's back on. From memory, the main changes I made were: 10-bit for all content (as it drastically helps with banding), no-sao, deblock = -3/-3, UMH, --me=umh, and I think psy-rd 2.20 and psy-rdoq 2.40.

Check out this post (http://forum.doom9.net/showthread.php?p=1947760#post1947760)where I made multiple comparisons for some guidance, if you like.

[Boulder]

Between medium and slow, there's basically only options that cause that quality jump like a higher rd-level and subme. I can only think of trying out --no-rect. Oh, and add --no-sao if you care about the details..

[Atlantis]

With x265 I always use Medium and never Slow. Not only it's way too slow, if I remember correctly, at the same CRF, Medium looks better than Slow!

For example a 1080p CRF 22 to my shock looked better in Medium quality than in the Slow quality.

Not to mention encoding a 4K video takes 2 days to encode in Medium. I am not going to try it in Slow!

[Blue_MiSfit]

Slow is quite likely larger than medium in this case, though ;)

[Atlantis]

I just remember I was completely shocked that you put extra time for encoding in Slow and the result is not better than Medium. Maybe it was size too, but I don't remember exactly. One day I will do the test again.

[RanmaCanada]

Honestly the best way to get any appreciable increase in your speed is to upgrade your machine. A 4 core Skylake based system is sadly not fast enough. I personally went from an E5-2670 (1.8 FPS) to a Ryzen 7-2700 (2.97 FPS) then to a Ryzen 7-5800x (5.67 FPS) and each time my speed almost doubled according to the benchmark thread. https://forum.doom9.org/showthread.php?t=174393&page=4

[alex.brown111@hotmail.com]

With x265 I always use Medium and never Slow. Not only it's way too slow, if I remember correctly, at the same CRF, Medium looks better than Slow!

For example a 1080p CRF 22 to my shock looked better in Medium quality than in the Slow quality.

Not to mention encoding a 4K video takes 2 days to encode in Medium. I am not going to try it in Slow!

I have uploaded my last tests in this folder (videos and screenshots):

https://drive.google.com/drive/folders/1vxhvhkxzRwCr0TN1Mn_fLhv9dnGe6vAl?usp=sharing

ffmpeg.exe -vsync 1 -i "title_t00_ori_60_sec.mkv" -y -c:v libx265 -crf 21 -pix_fmt yuv420p10le -map 0:0 -preset fast -c:s copy -x265-params "no-rect=1:no-sao=1:nr-intra=100:nr-inter=250" -metadata:s:v:0 Language="rom" -t 60 "title_t00_Libx265_60_sec_fast_no_audio_nr_custom.mkv"

I have created 3 videos that the only difference is the preset (fast, medium and slow).

With my surprise the fast preset seem perform better results compared to the others.

With my eyes I see the fast preset with less noise, less space and similar details.

If my impressions are true, I don't see reasons why use medium or slow.

Please leave your feedback.

Thanks

[Sharc]

I have created 3 videos that the only difference is the preset (fast, medium and slow).

With my surprise the fast preset seem perform better results compared to the others.

With my eyes I see the fast preset with less noise, less space and similar details.

If my impressions are true, I don't see reasons why use medium or slow.

Please leave your feedback.
No way.

Fast:
- many stars are not even visible
- low contrast details are blurred
Medium:
- more stars become visible
- low contrast areas have more details
Slow:
- few more stars become visible
- more details in low contrast areas

Secondly, comparisons should be based on equal file size rather than for same CRF.

[Atlantis]

Thank you for the tests. So it reconfirms my belief. Slow gets larger file size for the same CRF.

I thought using slow and spending extra time was to compress better, getting smaller sizes!

What is the reason and idea behind getting larger size with slow?

[Boulder]

In x264, using the same CRF usually only meant better compression efficiency when going to the slower presets. In x265, they are not linked nearly as much. That's why the filesize can easily get bigger. Comparison should be done in 2-pass mode -- I'd find the slowest preset/settings combination I could live with, find the CRF level that is transparent when watching live video normally, check the average bitrate of that encode and use it in 2-pass to compare the different presets.

[Sharc]

You can't predict the filesize with CRF encoding.
Slower settings will generally replicate the original better. If the original is noisy or grainy, slower settings will better replicate the noise/grain which may in turn increase the file size.
x264 and x265 do not behave the same btw. in this regard.

[alex.brown111@hotmail.com]

No way.

Fast:
- many stars are not even visible
- low contrast details are blurred
Medium:
- more stars become visible
- low contrast areas have more details
Slow:
- few more stars become visible
- more details in low contrast areas

Secondly, comparisons should be based on equal file size rather than for same CRF.

Thank you for your review, I will check better.

About the parts where there are not the stars (where the noise is visible) do your prefear the noise at the place of details or vice versa ?

[Atlantis]

I just watched the 3 videos and without a doubt the slow version has better quality than the fast. I didn't even need to look too close or bother myself too much. When you look at Data's yellow uniform all the grains are gone in the fast preset.

I think medium is a great compromise, it's between the two and keeps a lot of the details.

[Sharc]

Thank you for your review, I will check better.

About the parts where there are not the stars (where the noise is visible) do your prefear the noise at the place of details or vice versa ?
That's a matter of personal preference. Noise suppression will always suppress real details as well. If I want to suppress the noise/grain it is better to do this by filtering rather than compromising the encoder settings.

[Atlantis]

Indeed I always keep the same settings and if the source has too much noise and the result gets too big, I use filters to reduce noise. I never change or increase my CRF to reduce noise or files size for example.

I use RemoveGrain and FFT3DFilter to do that.

[tonemapped]

I have uploaded my last tests in this folder (videos and screenshots):

https://drive.google.com/drive/folders/1vxhvhkxzRwCr0TN1Mn_fLhv9dnGe6vAl?usp=sharing

ffmpeg.exe -vsync 1 -i "title_t00_ori_60_sec.mkv" -y -c:v libx265 -crf 21 -pix_fmt yuv420p10le -map 0:0 -preset fast -c:s copy -x265-params "no-rect=1:no-sao=1:nr-intra=100:nr-inter=250" -metadata:s:v:0 Language="rom" -t 60 "title_t00_Libx265_60_sec_fast_no_audio_nr_custom.mkv"

I have created 3 videos that the only difference is the preset (fast, medium and slow).

With my surprise the fast preset seem perform better results compared to the others.

With my eyes I see the fast preset with less noise, less space and similar details.

If my impressions are true, I don't see reasons why use medium or slow.

Please leave your feedback.

Thanks

After comparing on a 4K 50" TV from 2 metres away, medium is perfectly reasonable if it produces a good size:quality ratio. Slow doesn't look much worse. Fast looks noticeably worse and has terrible strobing.

[microchip8]

I find the built-in presets to be flawed. That's why I always use my own settings. Crispy sharp, no banding, no blocking, noise preservation, etc

[Boulder]

I find the built-in presets to be flawed. That's why I always use my own settings. Crispy sharp, no banding, no blocking, noise preservation, etc

I very much agree. The presets were just thrown together very early and not really developed any further even if things around them changed. The only bigger change was when veryslow became the new slower etc.

[Atlantis]

So please share your settings so we could compare it to medium.

[tonemapped]

So please share your settings so we could compare it to medium.

+1 would be very interested

[alex.brown111@hotmail.com]

I find the built-in presets to be flawed. That's why I always use my own settings. Crispy sharp, no banding, no blocking, noise preservation, etc

Happy to re-upload a new video with your setting, so we can compare: quality, speed and size.

Please let me known.

[Atlantis]

It's exactly what I was going to ask you do alex, since you have the original file. :)

[Gravitator]

Twitching stars around the ship is treated with --rskip 0 (at the cost of a drop in encoding speed).

[alex.brown111@hotmail.com]

It's exactly what I was going to ask you do alex, since you have the original file. :)

I have uploaded other 2 files in the some folder:
https://drive.google.com/drive/folders/1vxhvhkxzRwCr0TN1Mn_fLhv9dnGe6vAl?usp=sharing

1) title_t00_Libx265_60_sec_fast_no_audio_nr_custom_crf_18.mkv
ffmpeg.exe -vsync 1 -i "title_t00_ori_60_sec_no_audio.mkv" -y -c:v libx265 -crf 18 -pix_fmt yuv420p10le -map 0:0 -preset fast -c:s copy -x265-params "no-rect=1:no-sao=1:nr-intra=100:nr-inter=250" -metadata:s:v:0 Language="rom" -t 60 "title_t00_Libx265_60_sec_fast_no_audio_nr_custom_crf_18.mkv"

2) title_t00_Libx265_60_sec_Atlantis_crf_24.mkv

ffmpeg.exe -vsync 1 -i "title_t00_ori_60_sec_no_audio.mkv" -y -c:v libx265 -crf 24 -pix_fmt yuv420p10le -map 0:0 -c:s copy -x265-params "ref=4:star:subme=4:bframes=8:rd=4:rd-refine=0:qcomp=0.65:fades=1:strong-intra-smoothing=1:ctu=32:qg-size=32:sao=0:selective-sao=0:cu-lossless=0:cutree=1:tu-inter-depth=3:tu-intra-depth=3:max-merge=2:rskip=2:rskip-edge-threshold=2:rc-lookahead=80:aq-mode=2:aq-strength=1.0:rdoq-level=1:psy-rd=4.0:psy-rdoq=15.0:limit-modes=0:limit-refs=3:limit-tu=4:deblock=-4,-4:weightb=1:weightp=1:rect=0:amp=0:wpp=1:pmode=0:pme=0:b-intra=1:b-adapt=2:b-pyramid=1:tskip=1:tskip-fast=0:fast-intra=0:early-skip=0:splitrd-skip=0:min-keyint=24:keyint=240:transfer=bt709:colorprim=bt709:colormatrix=bt709:crf-min=10:no-sao=1" -metadata:s:v:0 Language="rom" -t 60 "title_t00_Libx265_60_sec_Atlantis_crf_24.mkv

I have added "no-sao=1" becouse it is a bit slow.

Can be interested if can we compare these 2 files with medium preset that actually seem the best compromise.

"title_t00_Libx265_60_sec_Atlantis_crf_24" it is a bit slow, but not too much.

Please leave your feedback.

[benwaggoner]

Twitching stars around the ship is treated with --rskip 0 (at the cost of a drop in encoding speed).
Have you tried --rskip 2? In theory it should be able to deliver similar improvements without the speed hit.

[alex.brown111@hotmail.com]

Have you tried --rskip 2? In theory it should be able to deliver similar improvements without the speed hit.

Done I have uploaded:
https://drive.google.com/drive/folde...Al?usp=sharing


title_t00_Libx265_60_sec_fast_no_audio_nr_custom_crf_18_rskip_2.mkv
ffmpeg.exe -vsync 1 -i "title_t00_ori_60_sec_no_audio.mkv" -y -c:v libx265 -crf 18 -pix_fmt yuv420p10le -map 0:0 -preset fast -c:s copy -x265-params "no-rect=1:no-sao=1:nr-intra=100:nr-inter=250:rskip=2" -metadata:s:v:0 Language="rom" -t 60 "title_t00_Libx265_60_sec_fast_no_audio_nr_custom_crf_18_rskip_2.mkv"

and I confirm there is no speed drop.

Please leave your comments.

[Gravitator]

Have you tried --rskip 2? In theory it should be able to deliver similar improvements without the speed hit.
It turns out degeneration.
Download example > x265_rskip0_vs_rskip2 (https://files.videohelp.com/u/227452/x265_rskip0_vs_rskip2.rar)

[tonemapped]

Have you tried --rskip 2? In theory it should be able to deliver similar improvements without the speed hit.

Are you aware of a detailed write-up of how rskip actually works? I've 'read the docs' and searched the forums without much success. It's an intriguing feature.

[benwaggoner]

Are you aware of a detailed write-up of how rskip actually works? I've 'read the docs' and searched the forums without much success. It's an intriguing feature.
I don't know much beyond what's here https://x265.readthedocs.io/en/master/cli.html#cmdoption-rskip

--rskip 2 sounds promising for addressing some of the older --rskip issues, perhaps with some tuning of --rskip-edge-threshold.

But I've not validated that myself.

[tonemapped]

I don't know much beyond what's here https://x265.readthedocs.io/en/master/cli.html#cmdoption-rskip

--rskip 2 sounds promising for addressing some of the older --rskip issues, perhaps with some tuning of --rskip-edge-threshold.

But I've not validated that myself.

That's the documentation I've read. Thank you for the additional information.

[alex.brown111@hotmail.com]

I have created a new folder here
https://drive.google.com/drive/folders/11OHwI1zrYw8dxxDUTvkNdQnsc0-W5qca?usp=sharing

and redone all tests and compare:

1) libx264 medium preset crf 23
ffmpeg.exe -vsync 1 -i "title_t00_ori_200_sec_no_audio.mkv" -y -c:v libx264 -crf 23 -pix_fmt yuv420p10le -map 0:0 -preset medium -c:s copy -vf vaguedenoiser -metadata:s:v:0 Language="rom" -t 200 "title_t00_Libx264_200_sec_medium_no_audio_custom_nr_vague_crf_23_speed_test.mkv"

2) libx265 medium preset crf 21
ffmpeg.exe -vsync 1 -i "title_t00_ori_200_sec_no_audio.mkv" -y -c:v libx265 -crf 21 -pix_fmt yuv420p10le -map 0:0 -preset medium -c:s copy -x265-params "no-rect=1:no-sao=1" -metadata:s:v:0 Language="rom" -t 200 "title_t00_Libx265_60_sec_medium_no_audio_custom_crf_speed_test.mkv"

3) Libx265 with custom setting (atlantis) crf 24
ffmpeg.exe -vsync 1 -i "title_t00_ori_200_sec_no_audio.mkv" -y -c:v libx265 -crf 24 -pix_fmt yuv420p10le -map 0:0 -c:s copy -x265-params "ref=4:star:subme=4:bframes=8:rd=4:rd-refine=0:qcomp=0.65:fades=1:strong-intra-smoothing=1:ctu=32:qg-size=32:sao=0:selective-sao=0:cu-lossless=0:cutree=1:tu-inter-depth=3:tu-intra-depth=3:max-merge=2:rskip=2:rskip-edge-threshold=2:rc-lookahead=80:aq-mode=2:aq-strength=1.0:rdoq-level=1:psy-rd=4.0:psy-rdoq=15.0:limit-modes=0:limit-refs=3:limit-tu=4:deblock=-4,-4:weightb=1:weightp=1:rect=0:amp=0:wpp=1:pmode=0:pme=0:b-intra=1:b-adapt=2:b-pyramid=1:tskip=1:tskip-fast=0:fast-intra=0:early-skip=0:splitrd-skip=0:min-keyint=24:keyint=240:transfer=bt709:colorprim=bt709:colormatrix=bt709:crf-min=10:no-sao=1" -metadata:s:v:0 Language="rom" -t 200 "title_t00_Libx265_60_sec_Atlantis_crf_24_speed_test.mkv"


all of this with and without noise reduction vaguedenoiser that seem the best. All files (with vaguedenoiser) are similar size.

In total there are 7 files.

Here the speed comparation with my machine (that is slow)

1) libx264 medium = 0.5x , with vaguedenoiser = 0.41x
2) libx265 medium = 0.37x , with vaguedenoiser = 0.31x
3) libx265 custom setting = 0.27 , with vaguedenoiser = 0.22x

This time I have checked all files and there is no stars drop. This becouse this noise reduction work better.

My first impression about libx264 seem too much blurry and I don't like it.

About vaguedenoiser apart the speed drop, remove the noise without pay the price in details that seem the some (this is my impression).

The question can be use default setting or this custom setting.

Please leave your comments,

[Sharc]

.... All files are similar size...
Really? ... 68,70,92,121.... MB are similar size?

[alex.brown111@hotmail.com]

Really? ... 68,70,92,121.... MB are similar size?

Sorry I have now corrected the message:


All files (with vaguedenoiser) are similar size.

66, 69, 72 MB.

for the rest the size are different but this is normal becouse libx264 is the double size of libx265.

Thank you for noted it.

[Sharc]

The best regarding details retention is the unfiltered x265 crf24 94MB file IMO.
Strength of denoising versus details and acceptable file size is a matter of personal taste. I find the denoised x265 crf24 72MB a good compromise.

[Gravitator]

--rskip 2 sounds promising for addressing some of the older --rskip issues, perhaps with some tuning of --rskip-edge-threshold.

But I've not validated that myself.

Right! Solve the old problem with low ecoding speed by lowering the ecoding quality (for the sake of real-time streaming).

[Gravitator]

Another demonstration of regression from activation --rskip 2
Downlod > StarKiller (https://files.videohelp.com/u/227452/StarKiller.rar)

ffmpeg -i c:\space_6s.mkv -f yuv4mpegpipe - | x265 --y4m - --preset medium --output-depth 10 --profile main10 --crf 32 --rskip 0 --qg-size 64 --hme --hme-search hex,hex,hex -o c:\rskip0.mkv
ffmpeg -i c:\space_6s.mkv -f yuv4mpegpipe - | x265 --y4m - --preset medium --output-depth 10 --profile main10 --crf 31 --rskip 2 --qg-size 64 --hme --hme-search hex,hex,hex -o c:\rskip2.mkv

[microchip8]

Another demonstration of regression from activation --rskip 2
Downlod > StarKiller (https://files.videohelp.com/u/227452/StarKiller.rar)

ffmpeg -i c:\space_6s.mkv -f yuv4mpegpipe - | x265 --y4m - --preset medium --output-depth 10 --profile main10 --crf 32 --rskip 0 --qg-size 64 --hme --hme-search hex,hex,hex -o c:\rskip0.mkv
ffmpeg -i c:\space_6s.mkv -f yuv4mpegpipe - | x265 --y4m - --preset medium --output-depth 10 --profile main10 --crf 31 --rskip 2 --qg-size 64 --hme --hme-search hex,hex,hex -o c:\rskip2.mkv

rskip 2 should be used with ctu of 32. Anything above and you get problems

I've been using rskip 2 with ctu 32 for many encodes with no issues at all

[Gravitator]

rskip 2 should be used with ctu of 32. Anything above and you get problems

I've been using rskip 2 with ctu 32 for many encodes with no issues at all
Nothing has changed.
ffmpeg -i с:\space_6s.mkv -f yuv4mpegpipe - | x265 --y4m - --preset medium --output-depth 10 --profile main10 --crf 31 --rskip 2 --ctu 32 --hme --hme-search hex,hex,hex -o с:\rskip2-ctu32.mkv
Download the test sample > StarKiller (https://files.videohelp.com/u/227452/StarKiller.rar)

[microchip8]

Nothing has changed.
ffmpeg -i с:\space_6s.mkv -f yuv4mpegpipe - | x265 --y4m - --preset medium --output-depth 10 --profile main10 --crf 31 --rskip 2 --ctu 32 --hme --hme-search hex,hex,hex -o с:\rskip2-ctu32.mkv
Download the test sample > StarKiller (https://files.videohelp.com/u/227452/StarKiller.rar)

I fail to spot the problem in your test sample. What am I looking at for?

[Sharc]

--ctu32 in addition to --rskip 2 may bring some stars back, but other stars and details disappear. Artefacts are ugly in both cases. The compression of about 1/8 is simply too much IMO, but one could argue that the results are amazingly good for this high compression.

[microchip8]

--ctu32 in addition to --rskip 2 may bring some stars back, but other stars and details disappear. Artefacts are ugly in both cases. The compression of about 1/8 is simply too much IMO, but one could argue that the results are amazingly good for this high compression.

You can add rskip-edge-threshold 2 or, in my use case, 1. Slows down encoding a bit at good gains. The default of 5 is too high, IMO

[benwaggoner]

--ctu32 in addition to --rskip 2 may bring some stars back, but other stars and details disappear. Artefacts are ugly in both cases. The compression of about 1/8 is simply too much IMO, but one could argue that the results are amazingly good for this high compression.
I expect that --ctu 32 only helps because with the default --tu-intra/inter-depth, it allows for smaller texture units.

To directly allow for the minimum size TU's:

--tu-intra-depth 4 --tu-inter-depth 4

To reduce the perf hit

--limit-tu 4

Stars can also be helped by --amp and --rect, which also have a speed penalty, which can be mitigated somewhat by --limit-modes. With minimum tu size and amp/rect being used, x265 can tweak things down to almost an individual pixel.

Of course, by that point we're more finding something between slower and veryslow, not a middle ground between medium and slow.

--tskip --tskip-fast may also help with stars. A dot in a flat block isn't well-suited to a frequency transform.

[Gravitator]

I fail to spot the problem in your test sample. What am I looking at for?
Twitching of the stars near the ship (dragging them along).

--tu-intra-depth 4 --tu-inter-depth 4
--tskip --tskip-fast may also help with stars. A dot in a flat block isn't well-suited to a frequency transform.
Now the picture is much better! For --rskip 2, the --tu-intra-depth 4 --tu-inter-depth 4 parameter is now strongly recommended at its maximum values! :)
ffmpeg -i z:\space_6s.mkv -f yuv4mpegpipe - | x265 --y4m - --preset medium --output-depth 10 --profile main10 --crf 32.6 --rskip 0 --tskip --ctu 32 --hme --hme-search hex,hex,hex --tu-intra-depth 4 --tu-inter-depth 4 -o z:\R0.mkv
encoded 149 frames in 51.70s (2.88 fps), 1034.93 kb/s, Avg QP:36.79
ffmpeg -i z:\space_6s.mkv -f yuv4mpegpipe - | x265 --y4m - --preset medium --output-depth 10 --profile main10 --crf 31.3 --rskip 2 --rskip-edge-threshold 1 --tskip --ctu 32 --hme --hme-search hex,hex,hex --tu-intra-depth 4 --tu-inter-depth 4 -o z:\R2.mkv

encoded 149 frames in 37.91s (3.93 fps), 1039.52 kb/s, Avg QP:35.73

[Boulder]

rskip 2 should be used with ctu of 32. Anything above and you get problems
That should apply only to the CTU 64 & limit-tu 0 combination. I've not seen any issues at 1080p with CTU 64 and limit-tu 4. For lower resolutions I always set CTU to 32.

[Gravitator]

That should apply only to the CTU 64 & limit-tu 0 combination. I've not seen any issues at 1080p with CTU 64 and limit-tu 4. For lower resolutions I always set CTU to 32.
Checking on my sample-1080p gives a negative conclusion...
ffmpeg -i c:\space_6s.mkv -f yuv4mpegpipe - | x265 --y4m - --preset medium --output-depth 10 --profile main10 --crf 31.8 --rskip 2 --rskip-edge-threshold 1 --tskip --ctu 32 --hme --hme-search hex,hex,hex --tu-intra-depth 4 --tu-inter-depth 4 -o c:\r2_ctu32.mkv
encoded 149 frames in 33.42s (4.46 fps), 1003.17 kb/s, Avg QP:35.93 >Small artifacts near the ship.
ffmpeg -i c:\space_6s.mkv -f yuv4mpegpipe - | x265 --y4m - --preset medium --output-depth 10 --profile main10 --crf 31.2 --rskip 2 --rskip-edge-threshold 1 --tskip --ctu 64 --hme --hme-search hex,hex,hex --tu-intra-depth 4 --tu-inter-depth 4 -o c:\r2_ctu64.mkv
encoded 149 frames in 33.28s (4.48 fps), 1008.97 kb/s, Avg QP:35.50 > More noticeable artifacts near the ship and large chunks of the image disappear towards the end of the video.

[microchip8]

Have you tried using a better motion estimation for HME instead of hex? I personally use umh,umh,star

[Boulder]

Checking on my sample-1080p gives a negative conclusion...
ffmpeg -i c:\space_6s.mkv -f yuv4mpegpipe - | x265 --y4m - --preset medium --output-depth 10 --profile main10 --crf 31.8 --rskip 2 --rskip-edge-threshold 1 --tskip --ctu 32 --hme --hme-search hex,hex,hex --tu-intra-depth 4 --tu-inter-depth 4 -o c:\r2_ctu32.mkv
encoded 149 frames in 33.42s (4.46 fps), 1003.17 kb/s, Avg QP:35.93 >Small artifacts near the ship.
ffmpeg -i c:\space_6s.mkv -f yuv4mpegpipe - | x265 --y4m - --preset medium --output-depth 10 --profile main10 --crf 31.2 --rskip 2 --rskip-edge-threshold 1 --tskip --ctu 64 --hme --hme-search hex,hex,hex --tu-intra-depth 4 --tu-inter-depth 4 -o c:\r2_ctu64.mkv
encoded 149 frames in 33.28s (4.48 fps), 1008.97 kb/s, Avg QP:35.50 > More noticeable artifacts near the ship and large chunks of the image disappear towards the end of the video.

That CRF value is simply so much out of my range so no guarantees :D I use 18-19 for 1080p (SDR).

Have you tried using a better motion estimation for HME instead of hex? I personally use umh,umh,star
I also think that umh,umh,star is the fastest one. I couldn't find a reason why but so it seemed at least in my tests.

[Gravitator]

Have you tried using a better motion estimation for HME instead of hex? I personally use umh,umh,star
Preferably star,star,star (smoother lines) :cool:
------
I am looking for x265 maximum setting to get closer to the quality of AOM.
Download the encoded sample > AOM (https://files.videohelp.com/u/227452/AOM.rar)

[Boulder]

Just a thought: would --rdpenalty 1 help here to push for smaller TUs?