x265 HEVC Encoder

[theincognito]

Can someone tell me how to properly use the 2pass options 'analysis-save' and 'analysis-load' ?

....
-> Can someone tell me how to properly use the 2pass options 'analysis-save' and 'analysis-load' ?

Cu Selur

This is what I use and it works perfectly for me:

pass 1:
--analysis-save "E:\Temp\analysis.dat" --analysis-save-reuse-level 10 --analysis-reuse-file "E:\Temp\analysis.dat"

pass 2:
--analysis-load "E:\Temp\analysis.dat" --analysis-load-reuse-level 10 --analysis-reuse-file "E:\Temp\analysis.dat"

[benwaggoner]

...after some tests with Sol Levante, I've got a couple of observations about anime encoding, at least with this pure digital 4K HDR anime.

--tskip offers a big reduction in bitrate and improvement in quality
--rskip 1 works better than --rskip 2

[microchip8]

...after some tests with Sol Levante, I've got a couple of observations about anime encoding, at least with this pure digital 4K HDR anime.

--tskip offers a big reduction in bitrate and improvement in quality
--rskip 1 works better than --rskip 2


I got the reverse for live action. rskip=2 reduces onion artifacts and is faster. Haven't tested tskip

[theincognito]

...after some tests with Sol Levante, I've got a couple of observations about anime encoding, at least with this pure digital 4K HDR anime.

--tskip offers a big reduction in bitrate and improvement in quality
--rskip 1 works better than --rskip 2


Thats cool :) What about SDR?

[Asmodian]

...after some tests with Sol Levante, I've got a couple of observations about anime encoding, at least with this pure digital 4K HDR anime.

--tskip offers a big reduction in bitrate and improvement in quality
--rskip 1 works better than --rskip 2


I did some testing with a few SDR 1080p anime series (the common lower budget contemporary Japanese style) and --tskip allowed a large reduction in bitrate while also improving quality. It is not just 4K HDR, tskip is huge for 1080p anime too! I was using --rskip 1 and didn't test --rskip 2. I was also using --tu-inter 4, --tu-intra 4, and --limit-tu 4, which might help for 1080p more than 4K?

tskip really is amazing and it makes x265 much better for anime than x264. I care more about transparency than size but tskip seems to improve both. A must enable option for anime, IMO.

:thanks:Thank you!

Edit:
An example command line I used targeting playback on a tablet. It runs really well on my new 3950X. :)
vspipe.exe --y4m "Flying Witch - 05.vpy" - | x265.exe --input - --y4m -o "Flying Witch - 05.265" --crf 22 -p 8 -F 1 --pools 32 --lookahead-slices 0 --gop-lookahead 23 --min-keyint 24 --hme --hist-scenecut --fades --selective-sao 2 --tskip --tu-inter 4 --tu-intra 4 --limit-tu 4 --pmode --rect --amp --rc-lookahead 60 --range limited --colorprim 1 --transfer 1 --colormatrix 1
Edit2: --limit-tu 4 is a speedup with a minor quality hit. Testing with it off does not slow down my 3950X very much with minor quality improvements. I think I will leave it off. :o

[benwaggoner]

Thats cool :) What about SDR?
It's been some years since I tested SDR HD anime, but IIRC, tu-inter/intra 4 and tskip made a huge improvement.

[Sagittaire]

Can someone tell me how to properly use the 2pass options 'analysis-save' and 'analysis-load' ?

You have complete test here
https://forum.doom9.org/showthread.php?t=181362

reuse encoding is not here to obtain better quality refinement in multipass mode but for:
- make reencoding at other bitrate from 2pass with other initial bitrate with really higher speed
- make reencoding at other resolution from 2 pass with other initial resolution with really higher speed

be carefull: you have incompatible option like --rd-refine or --hme with reuse encoding

You have really powefull --abr-ladder option too: you can make simulanous encoding (different bitrate and resolution) with same source at really higher speed than successive encoding.

for make reuse you must make:
- first pass (at high speed if you want)
- second pass with --analysis-save analysis.dat --analysis-save-reuse-level 10
- third pass with --analysis-load analysis.dat --analysis-load-reuse-level 10

you can use --refine-intra 4 --refine-inter 3 --refine-mv 3 for best analyse level in third pass, but really lower speed.

you can try that if you want obtain "crf quality like" with the bitrate that you want for exemple:

x265.exe --input hp.yuv --output HP-450-SSIM.265 --input-res 720x304 --output-depth 10 --fps 25 --crf 19.5 --qcomp 0.60 --pass 1 --stats hp.log --preset veryslow --slow-firstpass --no-limit-modes --rd-refine --tune ssim --hevc-aq --qp-adaptation-range 1.0 --bframes 3 --b-adapt 2 --min-keyint 1 --psnr --ssim --analysis-save HP_450_R10-abr1_analysis.dat --analysis-save-reuse-level 10 --refine-ctu-distortion 1

second pass at really high speed but little lower quality
x265.exe --input hp.yuv --output HP-450-SSIM.265 --input-res 720x304 --output-depth 10 --fps 25 --bitrate 450 --qcomp 0.60 --pass 3 --stats hp.log --preset veryslow --no-limit-modes --tune ssim --hevc-aq --qp-adaptation-range 1.0 --bframes 3 --b-adapt 2 --min-keyint 1 --psnr --ssim --analysis-load HP_450_R10-abr1_analysis.dat --analysis-load-reuse-level 10 --refine-ctu-distortion 1

second pass at less high speed but with real "crf like" quality
x265.exe --input hp.yuv --output HP-450-SSIM.265 --input-res 720x304 --output-depth 10 --fps 25 --bitrate 450 --qcomp 0.60 --pass 3 --stats hp.log --preset veryslow --no-limit-modes --tune ssim --hevc-aq --qp-adaptation-range 1.0 --bframes 3 --b-adapt 2 --min-keyint 1 --psnr --ssim --analysis-load HP_450_R10-abr1_analysis.dat --analysis-load-reuse-level 10 --refine-ctu-distortion 1 --refine-intra 4 --refine-inter 3 --refine-mv 3

[theincognito]

I did some testing with a few SDR 1080p anime series (the common lower budget contemporary Japanese style) and --tskip allowed a large reduction in bitrate while also improving quality. It is not just 4K HDR, tskip is huge for 1080p anime too! I was using --rskip 1 and didn't test --rskip 2. I was also using --tu-inter 4, --tu-intra 4, and --limit-tu 4, which might help for 1080p more than 4K?

tskip really is amazing and it makes x265 much better for anime than x264. I care more about transparency than size but tskip seems to improve both. A must enable option for anime, IMO.

:thanks:Thank you!

Edit:
An example command line I used targeting playback on a tablet. It runs really well on my new 3950X. :)
vspipe.exe --y4m "Flying Witch - 05.vpy" - | x265.exe --input - --y4m -o "Flying Witch - 05.265" --crf 22 -p 8 -F 1 --pools 32 --lookahead-slices 0 --gop-lookahead 23 --min-keyint 24 --hme --hist-scenecut --fades --selective-sao 2 --tskip --tu-inter 4 --tu-intra 4 --limit-tu 4 --pmode --rect --amp --rc-lookahead 60 --range limited --colorprim 1 --transfer 1 --colormatrix 1
Edit2: --limit-tu 4 is a speedup with a minor quality hit. Testing with it off does not slow down my 3950X very much with minor quality improvements. I think I will leave it off. :o

It's been some years since I tested SDR HD anime, but IIRC, tu-inter/intra 4 and tskip made a huge improvement.


Thank you :)

[Selur]

@Sagittaire: Thanks for the link and the explanation. :)

[benwaggoner]

I did some testing with a few SDR 1080p anime series (the common lower budget contemporary Japanese style) and --tskip allowed a large reduction in bitrate while also improving quality. It is not just 4K HDR, tskip is huge for 1080p anime too! I was using --rskip 1 and didn't test --rskip 2. I was also using --tu-inter 4, --tu-intra 4, and --limit-tu 4, which might help for 1080p more than 4K?
I'm running a test encode right now to compare a tu of 3 with tskip and tu of 4 without tskip. My intuition is that anime can benefit from tskip at any resolution, because the sharpness of the lines is pretty consistant, and sharp lines on smooth backgrounds is exactly why we want to get very fine blocks (min 4x4 with amp and rect) so we can isolate the sharp lines from the rest of the image and selectively apply tskip. Tskip on a 32x32 block that isn't something weird and regular like a checkerboard is probably going to be worse than a normal block. But a 4x4 with amp gets down to pixel-level alignment.

tskip really is amazing and it makes x265 much better for anime than x264. I care more about transparency than size but tskip seems to improve both. A must enable option for anime, IMO.
Yep. It's big help with motion graphics too. Probably for anything the screen coding extensions would help.

I'd guess videogame footage would probably be better with it too, especially with HUD and games with aliasing.

Edit2: --limit-tu 4 is a speedup with a minor quality hit. Testing with it off does not slow down my 3950X very much with minor quality improvements. I think I will leave it off. :o
Yeah, I only had about a 1% perf change using --limit-tu 4 with the anime test clip. That might be because there just aren't many potential tskip blocks that trigger the early exit in this kind of content. I think the speed gains with --tskip-fast were a lot higher with regular content.

I thought there was somewhere in --log-level 2 that showed how many tskip and cu-lossless blocks were used, but I can't find it now. Am I misremembering?

[jlpsvk]

when encoding 1917 with HDR10+ metadata, encode gets only 171168 frames instead of 171176. when encoding without HDR10+ metadata json, everything is OK. using latest LigH's build (3.4+9).

EDIT: used the same JSON with NVENC and all good... so probably x265 problem???

[fauxreaper]

I was reading x265 source code and I found an interesting comment about merge mode in x265_git/source/encoder/analysis.cpp...

/* Todo: Fix the satd cost estimates. Why is merge being chosen in high motion areas: estimated distortion is too low? */

I think that this can explain why restricting merge usage (lowering max-merge and/or using rskip 2) generates a video with less artifacts.

[Greenhorn]

I was reading x265 source code and I found an interesting comment about merge mode in x265_git/source/encoder/analysis.cpp...

/* Todo: Fix the satd cost estimates. Why is merge being chosen in high motion areas: estimated distortion is too low? */

I think that this can explain why restricting merge usage (lowering max-merge and/or using rskip 2) generates a video with less artifacts.

Do you have a link to where you were browsing this? I'm looking at (https://bitbucket.org/multicoreware/x265_git/src/master/source/encoder/analysis.cpp) right now and not seeing this comment. (Wrong file?)

[fauxreaper]

Do you have a link to where you were browsing this? I'm looking at (https://bitbucket.org/multicoreware/x265_git/src/master/source/encoder/analysis.cpp) right now and not seeing this comment. (Wrong file?)

I think that I saw an old file.

https://bitbucket.org/multicoreware/x265_git/src/8ee74a78e5ef71643047b22078a20e9e450e252c/source/encoder/analysis.cpp

[LeXXuz]

I note from the x265 dev list that an --auto-aq mode is in development. Maybe we'll be able to stop sweating aq-mode someday.

> This patch does the following:
> 1. Automatically decides the AQ Mode for each frame, using its scene
> statistics, such as luma intensity and edge density.
> 2. Add option "--auto-aq" to enable auto detection of AQ Mode per frame.

Any news on this? I use mode 3 for very clean sources and mode 2 for everything else.

Btw are there any new switches that should be added and are not part of the standard presets?

Right now I use preset slower with output-depth 10, aq-mode 3 and a qpfile for more acurate and faster chapter jumps. I usually use CRF16/18 for 1080p SDR.

The very slow preset is way to slow for my needs, even on a Ryzen 9 system.

[Boulder]

I'd also set --rskip 2 and possibly lower the corresponding threshold a bit. --no-sao as you don't do low bitrate encodes.

[106062316]

x265 [info]: HEVC encoder version 3.4+12-geff904199
x265 [info]: build info [Windows][GCC 11.0.0][64 bit] 8bit+10bit+12bit
x265 [info]: (lsmash 2.16.1)
x265 [info]: (libavformat 58.48.100)
x265 [info]: (libavcodec 58.96.100)
x265 [info]: (libavutil 56.55.100)

https://1drv.ms/u/s!Arxq3mixC4xAg0xX9G7_VubNYJhm?e=gJJxt8

[jlpsvk]

really nobody will look into this????

when encoding 1917 with HDR10+ metadata, encode gets only 171168 frames instead of 171176. when encoding without HDR10+ metadata json, everything is OK. using latest LigH's build (3.4+9). tested the same encode with nvencc64 and frames number is correct. this prevents me to use hdr10+ encode for muxing with Dolby Vision EL+RPU...

[LigH]

Possibly best to report this in the x265 developer mailing list. I'll do so.

Please try to provide a small sample with only few frames (I'd suggest ~500 to have more than one GOP) if you can reproduce the issue in this case.

[Boulder]

I just noticed that --limit-tu 0 seems to be a potentially dangerous setting coupled with --rskip 2. I've encoded episodes of 'Chernobyl' and saw that the average bitrate is quite low for 1080p material. I found one scene where the encode looked really ugly and with some testing, I checked that changing from --limit-tu 4 to --limit-tu 0 made it happen. --ctu 32 also fixed the issue.

[microchip8]

I just noticed that --limit-tu 0 seems to be a potentially dangerous setting coupled with --rskip 2. I've encoded episodes of 'Chernobyl' and saw that the average bitrate is quite low for 1080p material. I found one scene where the encode looked really ugly and with some testing, I checked that changing from --limit-tu 4 to --limit-tu 0 made it happen. --ctu 32 also fixed the issue.

I've encoded quite a few flicks since then with limit-tu 0 and rskip 2 and have yet to see some noticable (major) distortions. Maybe your issue is sample specific

[Boulder]

I made some tests to show the issue. The basic x265 settings were "--preset slower --no-sao --aq-mode 1 --aq-strength 1.0 --qcomp 0.7 --crf 20". The source was unaltered, I only cropped the black borders off in the script.

--ctu 64 --limit-tu 4 --rskip 1 : 4730.32 kbps
--ctu 64 --limit-tu 0 --rskip 1 : 4477.60 kbps
--ctu 32 --limit-tu 4 --rskip 1 : 4735.29 kbps
--ctu 32 --limit-tu 0 --rskip 1 : 4733.48 kbps

--ctu 64 --limit-tu 4 --rskip 2 : 4863.81 kbps
--ctu 64 --limit-tu 0 --rskip 2 : 2877.67 kbps
--ctu 32 --limit-tu 4 --rskip 2 : 5090.29 kbps
--ctu 32 --limit-tu 0 --rskip 2 : 5142.87 kbps

I put the original source clip here:

https://drive.google.com/file/d/1nEa9H70d7Ekeue2omnwLDToVK7LaxZ_t/view?usp=sharing

The problem is very visible around the middle of the clip in the scene where the woman on the phone is in the distant background. The noise turns into very ugly shapes there.

I don't know if I should use --ctu 32 also with 1080p sources with --rskip 2 just to be safe. I need to test 1440p as well.

[Boulder]

A similar test with 1440p (2560x1048):

--limit-tu 4 : 6963.05 kbps
--limit-tu 0 : 6825.00 kbps
--limit-tu 4 --ctu 32 : 6905.23 kbps
--limit-tu 0 --ctu 32 : 6906.79 kbps
--limit-tu 4 --rskip 2 : 7563.58 kbps
--limit-tu 0 --rskip 2 : 5934.17 kbps
--limit-tu 4 --ctu 32 --rskip 2 : 7045.77 kbps
--limit-tu 0 --ctu 32 --rskip 2 : 7099.02 kbps

The large difference can also be seen there. I didn't check how the encode looked but probably there would be scenes which would look ugly. This means it's either --limit-tu 4 or --limit-tu 0 --ctu 32 to avoid the issue. I'm just not sure which one is the better choice quality-wise.

[LigH]

New upload: x265 3.4+14-gd419c7152 (https://www.mediafire.com/file/e5nsrl1bue9eld9/x265_3.4+14-gd419c7152.7z/file)

abr-ladder: fix memleak in copyInfo()
Fix cost estimation error for hist-based scenecut
Fix libvmaf integration issues

[Boulder]

I tested the histogram based scenecut detection yesterday quite a lot. I still couldn't get it to detect proper scenecuts -- it would either miss too many, at least one very obvious one, and lowering the threshold would cause it to find scenecuts in quite strange places. My Hot Fuzz testclip triggered scenecuts in scenes where there is some motion blur and then single frames which are just slightly less blurry. Probably the sudden sharp edged text on shirts etc. are enough to tell that it's a scenecut.

If you lower the threshold enough, it will start reducing the number of keyframes which was really strange. In the csv log, you can see that a scenecut is detected but they are often coded as B/b-frames.

[jlpsvk]

New upload: x265 3.4+14-gd419c7152 (https://www.mediafire.com/file/e5nsrl1bue9eld9/x265_3.4+14-gd419c7152.7z/file)

abr-ladder: fix memleak in copyInfo()
Fix cost estimation error for hist-based scenecut
Fix libvmaf integration issues

testing to encode 1917 HDR10+ again (testing with every new build)...

[quietvoid]

I tested the histogram based scenecut detection yesterday quite a lot. I still couldn't get it to detect proper scenecuts -- it would either miss too many, at least one very obvious one, and lowering the threshold would cause it to find scenecuts in quite strange places. My Hot Fuzz testclip triggered scenecuts in scenes where there is some motion blur and then single frames which are just slightly less blurry. Probably the sudden sharp edged text on shirts etc. are enough to tell that it's a scenecut.

If you lower the threshold enough, it will start reducing the number of keyframes which was really strange. In the csv log, you can see that a scenecut is detected but they are often coded as B/b-frames.

I've posted about this before:
So x265 3.4+9, they "fixed" --hist-threshold to avoid false positives. However it seems to do much worse than before (as well as 3.4+7, where they fixed the false positives).
I'm getting less I frames with --hist-threshold 0.005 (default 0.03) than the default scenecut algorithm..

Maybe my sample clip is not colorful enough..
Since then I've just given up on hist-scenecut. As well as scenecut-aware-qp, because they introduced QP changes before scene cuts...

[Boulder]

I've posted about this before

Actually that's why I tested it now, since there was that one patch related to the feature.

Too bad they don't seem to care for the original method anymore, my bug report (https://bitbucket.org/multicoreware/x265/issues/535/scenechange-detection-misses-two-clear) has not had any activity.

[vpupkind]

I've posted about this before:

Since then I've just given up on hist-scenecut. As well as scenecut-aware-qp, because they introduced QP changes before scene cuts...

Have you tried scenecut-aware-qp? Unless you pause at this frame, a human observer is typically unable to notice quality degradation within ~100ms from a strong scene cut.

[Boulder]

Have you tried scenecut-aware-qp? Unless you pause at this frame, a human observer is typically unable to notice quality degradation within ~100ms from a strong scene cut.

Why does that option only work with a multipass encode? You would expect that the lookahead could take care of the work also in CRF mode.

[quietvoid]

Have you tried scenecut-aware-qp? Unless you pause at this frame, a human observer is typically unable to notice quality degradation within ~100ms from a strong scene cut.

I have tried it, it was fine before they changed it.
The quality change AFTER a scene cut is not visible, but the idea of lowering the quality BEFORE (which is what they did) does not sound good to me.
It makes no sense.

Why does that option only work with a multipass encode? You would expect that the lookahead could take care of the work also in CRF mode.

This is another good point, I don't know how these patches get through quality checks.
It used to work just fine for CRF, and they added a condition that makes it multipass exclusive.

[foxyshadis]

This is another good point, I don't know how these patches get through quality checks.
It used to work just fine for CRF, and they added a condition that makes it multipass exclusive.

Since Steve Borho and chen moved on, the main quality check is "does it compile". Almost every submitted patch is immediately committed without discussion now, and reverted later if need be.

[LeXXuz]

Quick question: should SMT/Hyperthreading be enabled on a Ryzen 9 machine or not? With 2x logical cpus I had about 66% average cpu usage and lower fps than with logical cpus = cpus @ 95-100%. Same settings of course.

[Boulder]

HT on works fine. If the CPU usage tends to stay low, it could a parallelization issue like CTU 64 with less than FullHD resolution source.

[Atak_Snajpera]

Quick question: should SMT/Hyperthreading be enabled on a Ryzen 9 machine or not? With 2x logical cpus I had about 66% average cpu usage and lower fps than with logical cpus = cpus @ 95-100%. Same settings of course.

Always on.

[LigH]

HEVC has more dependencies than AVC. More parts of the calculation in x265 need to wait for intermediate results of previous calculations. Not approaching 100% CPU usage is not concerning. You may be able to run two separate encoding jobs (provided you have enough RAM and the cooling can handle the heat).

[LeXXuz]

Thanks for the replies guys.

Yes, I've noticed a temperature drop of about ten degrees with SMT off. But that is of no concern anyway since the cpus are watercooled.

I always use --ctu 32 for 1080p resolutions and below. Frame threads is set to auto. x.265 picks 4 threads on 3900x (12C/24T) and 5 threads on 3950x (16C/32T).

I did an encode with frame threads set to 1 but the file size was just negligible smaller than with the auto setting.

So SMT on it is. Maybe I just do 2 parallel jobs instead. :)

[microchip8]

Thanks for the replies guys.

Yes, I've noticed a temperature drop of about ten degrees with SMT off. But that is of no concern anyway since the cpus are watercooled.

I always use --ctu 32 for 1080p resolutions and below. Frame threads is set to auto. x.265 picks 4 threads on 3900x (12C/24T) and 5 threads on 3950x (16C/32T).

I did an encode with frame threads set to 1 but the file size was just negligible smaller than with the auto setting.

So SMT on it is. Maybe I just do 2 parallel jobs instead. :)

Try with --pmode

[Boulder]

I run my 3900X with two framethreads (-F 2). I don't know if it will increase quality (in theory it should) but the CPU usage difference to -F 4 is around 10% so I consider it more like headroom for doing all the other stuff at the same time. The encoder uses a 24-thread pool, I also assign 24 threads to Avisynth processing. The Avisynth part takes about 20-30% of total CPU time when encoding.

[LeXXuz]

I also assign 24 threads to Avisynth processing. The Avisynth part takes about 20-30% of total CPU time when encoding.

Wait. You mean you set prefetch() to 24 in Avisynth? :eek:
Or are we talking about different things here?

[Boulder]

Wait. You mean you set prefetch() to 24 in Avisynth? :eek:
Or are we talking about different things here?

Yes. Prefetch(24, 24) works best for me as I have a 12c/24t CPU.

[LeXXuz]

Hm. My encodes never gained any speed increase beyond prefetch(4). On the contrary, I had much more ram and cpu utilisization (naturally) but no fps increase. That's why I stayed with just 4.

[Boulder]

Did you increase the maximum cache size? When I switched back to Avisynth+, I noticed that I had to increase it to over 10GB for UHD things, otherwise everything would just stall. I think I now have it at 16GB just in case. Also the new caching method in Avs+ 3.6.1 helped me.

[K.i.N.G]

After a quick test adding these parameters to the encode improved the quality in parts with motion "--rskip 2 --max-merge 2 --rd-refine" with about the same bitrate.
The artifacts are still there but far less (and much less perceptible when playing the video).
I'll see if i can experiment some more with the settings later, maybe it can be improved even more.

Thanks to everyone for the usefull input and suggestions!

Just a quick update:
So, after some more testing I've found that setting --rskip 2 causes a lot of flickering macro blocks.. setting this to 1 (the default) fixed it.
I'm not sure if this reintroduces the original problem i was having of 'smeared' fast motion. I will need to (re)test some more later to see.

[Boulder]

Just a quick update:
So, after some more testing I've found that setting --rskip 2 causes a lot of flickering macro blocks.. setting this to 1 fixed it.
I'm not sure if this reintroduces the original problem i was having of 'smeared' fast motion. I will need to test some more to see.

Could you post the rest of your settings? I've not noticed that issue with --ctu 32 and --limit-tu 0. With --limit-tu 0 --rskip 2, --ctu 32 is a must. The encoder favours merges much more with --rskip 2 which tend to destroy quality if you are not careful.

I have to note that I am not at all confident that the developers always know what they are doing. As mentioned earlier, the true QA people have left the building and unfortunately it shows. I'm also quite disappointed that clear bug reports are not responded at all even if the issues being corrected would benefit also commercial clients.

[K.i.N.G]

Well, it looks like I jumped to conclusions a bit too fast...
appearantly its not completely gone with rskip 1... just a lot less.
So I'll try rskip 0 now...

Could you post the rest of your settings? I've not noticed that issue with --ctu 32 and --limit-tu 0. With --limit-tu 0 --rskip 2, --ctu 32 is a must. The encoder favours merges much more with --rskip 2 which tend to destroy quality if you are not careful.

I have to note that I am not at all confident that the developers always know what they are doing. As mentioned earlier, the true QA people have left the building and unfortunately it shows. I'm also quite disappointed that clear bug reports are not responded at all even if the issues being corrected would benefit also commercial clients.

settings:
x265.exe --crf 18 --preset veryslow --profile main10 --level-idc 4 --output-depth 10 --limit-refs 0 --psy-rdoq 1.5 --rskip-edge-threshold 4 --cu-lossless --subme 6 --merange 64 --max-merge 2 --keyint 480 --no-hdr10 --colorprim bt709 --colormatrix bt709 --transfer bt709 --range limited --deblock -2:-2 --selective-sao 0 --no-sao --high-tier --no-strong-intra-smoothing --rd-refine

Just standard HD (no HDR).

Will try CTU 32 and limit-tu 0 aswell.
*edit: as I'm using the very slow preset as a base limit-tu was already set at 0

[stax76]

Do lavf builds allow passing options to ffmpeg for instance to enable vpy reading, hw decoding or other useful ffmpeg functionality?

[K.i.N.G]

I've not noticed that issue with --ctu 32 and --limit-tu 0. With --limit-tu 0 --rskip 2, --ctu 32 is a must. The encoder favours merges much more with --rskip 2 which tend to destroy quality if you are not careful.

I have to note that I am not at all confident that the developers always know what they are doing. As mentioned earlier, the true QA people have left the building and unfortunately it shows. I'm also quite disappointed that clear bug reports are not responded at all even if the issues being corrected would benefit also commercial clients.

Setting --rskip 2 with --ctu 32 it still caused flickering macroblocks.
Setting --rskip 1 with --ctu 32 seems to have fixed it. I'll have to try with some other problematic sources later to be sure.

setting --rskip 2 wit a low --rskip-edge-threshold also seemed to give better results but I got tired of testing so I just went with rskip 1.


Yes, its very frustrating how easily things just break apart with x265. Quite a lot of issues which I dont seem to remember having encountered with older versions of x265?!


*edit: Nope, nevermind, still not fixed by adding --rskip 1 with --ctu 32, its still there in darker parts... Turning off rskip now...


.

[Boulder]

*edit:[/U][/B] Nope, nevermind, still not fixed by adding --rskip 1 with --ctu 32, its still there in darker parts... Turning off rskip now...
.
rskip off is probably worse. I think that --rskip 2 causes less recursion skips than --rskip 1 so in that sense, totally disabling skips would cause more issues.

You are probably using the default aq-mode (2), which is worse in my opinion. It sometimes caused the ugly floating macroblocks in flat areas, and I cannot stand those so I'd test also --aq-mode 1 to make sure it's not the issue there.

I also suggest removing --no-strong-intra-smoothing, there were some tests showing that the details are retained better that way.

[alex1399]

Does I miss something, the x265 last commit stopped at 73ca1d7 which is on 2020/05/30.