x265 HEVC Encoder

[LigH]

Note: Multicoreware asks to refresh x265 clone

Originally Posted by Aruna Matheswaran

We had to recently strip a commit that got pushed into Release_3.5 branch due to some unavoidable reasons. Hence, we request all those who auto-update x265 to refresh your git repos so that we'll be on the same page.

E.g. in media-autobuild suite, you would remove the build/x265_git-git directory before running the suite again.

PS: Well, m-ab-s does not aim for the Release_3.5 branch. Would have to be the HEAD if.

[Barough]

x265 v3.5_RC1+2-f3f27198 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/Release_3.5

[PoeBear]

Originally Posted by FranceBB

Chroma bleeding is actually really weird, it shouldn't really happen and I think I know why it's happening to you!
Your input is an AVS Script from what I see, which handles 4:2:0 Type 1 but not 4:2:0 Type2!
So, the chroma location is wrong, hence the "bleeding".

Can you try with:

ffmpeg.exe -i "AVS Script.avs" -vf scale=out_color_matrix=bt2020nc:out_h_chr_pos=0:out_v_chr_pos=0 -pix_fmt yuv420p16le -strict -1 -an -f yuv4mpegpipe - | x265.exe --y4m - --dither

followed by the rest of your x265 command line? This should solve the chroma bleeding problem.

Finally got around to trying this, after tracking down some 32-bit ffmpeg builds (the 64-bit builds try to load 64-bit AviSynth+ and 64-bit plugins, threw me for a loop momentarily)

But it's drastically altering the colors when running the same exact x265 commands

Here's a comparison between the normal avs2yuv pipe I was using, and then your ffmpeg pipe from above:


Here they are tonemapped for better comparison of the changes:


Here were the commands ran, I just used one of my recent tests so I could do a comparison

avs2yuv.exe "Script.avs" - | "x265.exe" -D 10 --crf 10.5 --profile main10 --level-idc 5.1 --high-tier --preset placebo --input-depth 16 --cu-lossless 
--pmode --bframes 16 --qg-size 32 --frame-threads 4 --ref 6 --limit-refs 1 --merange 57 --no-amp --tskip --tskip-fast --limit-modes --no-open-gop --hrd
 --cbqpoffs -0 --crqpoffs -1 --no-cutree --deblock -2:-2 --psy-rd 2.50 --psy-rdoq 1.00 --qcomp .6 --aq-mode 2 --aq-strength 1.0 --ipratio 1.3 --pbratio 1.2
 --vbv-bufsize 160000 --vbv-maxrate 160000 --aud --hdr10 --hdr10-opt --range limited --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc
 --master-display G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50) --max-cll 602,187 --chromaloc 2 --repeat-headers
 --output "pmode-sao-tskip-r1-test.hevc" --frames 3000 --y4m -

ffmpeg.exe -i "Script.avs" -vf scale=out_color_matrix=bt2020nc:out_h_chr_pos=0:out_v_chr_pos=0 -pix_fmt yuv420p16le -strict -1 -an -f yuv4mpegpipe - | x265.exe
 --y4m - --dither --output-depth 10 --crf 10.5 --profile main10 --level-idc 5.1 --high-tier --preset placebo --input-depth 16 --cu-lossless --pmode --bframes 16
 --qg-size 32 --frame-threads 4 --ref 6 --limit-refs 1 --merange 57 --no-amp --tskip --tskip-fast --limit-modes --no-open-gop --hrd --cbqpoffs -0 --crqpoffs -1
 --no-cutree --deblock -2:-2 --psy-rd 2.50 --psy-rdoq 1.00 --qcomp .6 --aq-mode 2 --aq-strength 1.0 --ipratio 1.3 --pbratio 1.2 --vbv-bufsize 160000
 --vbv-maxrate 160000 --aud --hdr10 --hdr10-opt --range limited --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc
 --master-display G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50) --max-cll 602,187 --chromaloc 2 --repeat-headers
 --output "pmode-sao-tskip-r1-testFF.hevc" --frames 3000

Originally Posted by FranceBB

True, but the thing is that he was using chromaloc 2 in x265 but his input (the AVS Script output) wasn't, so it was just wrong. Either he specifies the normal 4:2:0 or he converts it to type2 and specifies chromaloc 2. That's what I meant

My input is just the raw video track from the UHD (which is chromaloc 2 per the UHD Blu-ray spec) indexed with DGDecNV. Is there a limitation with the way AviSynth+ outputs?

Script.avs:

DGSource("UHD.dgi")
Crop(0,276,-0,-276)
z_Spline36Resize(1920,804)

[benwaggoner]

I suspect you need to specify PQ as well as 2020 in ffmpeg somehow, if it supports it yet.

You want the whole SMPTE Rec.2100 package.

[_kermit]

currently I use this to encode:

ffmpeg.exe -i abc.mkv -pix_fmt yuv420p -f yuv4mpegpipe -| x265.exe -o output

But this doesn't use all my new 12 cores to a 100%, maybe half.
How can I improve this?

[microchip8]

Originally Posted by _kermit

currently I use this to encode:

ffmpeg.exe -i abc.mkv -pix_fmt yuv420p -f yuv4mpegpipe -| x265.exe -o output

But this doesn't use all my new 12 cores to a 100%, maybe half.
How can I improve this?

Have you tried passing --pmode to x265?

[stax76]

But this doesn't use all my new 12 cores to a 100%, maybe half.
How can I improve this?

Split into chunks maybe.

https://github.com/staxrip/staxrip/w...chunk-encoding

[_kermit]

Originally Posted by microchip8

Have you tried passing --pmode to x265?

no, haven't tried anything.
The question came up when using fastflix, which utilized almost 100% with UHD. I don't think it's related to UHD, just that it does it differently.

like this (1080p):
"C:/Users/admin/AppData/Roaming/FFmpeg/bin/ffmpeg.exe" -y -to 6492.7 -i "abc.mkv" -metadata title="abc" -max_muxing_queue_size 1024 -filter_complex "[0:0]crop=1920:800:0:140[v]" -map "[v]" -c:v libx265 -pix_fmt yuv420p10le -x265-params "aq-mode=2:repeat-headers=0:strong-intra-smoothing=1:bframes=4:b-adapt=2:frame-threads=0:hdr10_opt=0:hdr10=0" -crf 20 -preset medium -map_metadata -1 -map_chapters 0 "abc.mkv"

it's not piping but using libx265 (?), but how do I use that?

[benwaggoner]

Originally Posted by _kermit

no, haven't tried anything.
The question came up when using fastflix, which utilized almost 100% with UHD. I don't think it's related to UHD, just that it does it differently.

Being UHD is actually pretty substantial. There's a lot of frame-size proportional parallelism in x265, so bigger frames use more cores. Wavefront Parallel Processing is the most obvious one, where you extra parallelism out of each 64 pixels of frame height.

[_kermit]

Originally Posted by benwaggoner

Being UHD is actually pretty substantial. There's a lot of frame-size proportional parallelism in x265, so bigger frames use more cores. Wavefront Parallel Processing is the most obvious one, where you extra parallelism out of each 64 pixels of frame height.

ok, I guess I have to check with 1080p and fastflix first, or vice versa.

EDIT:

Indeed, 1080p is also not using all CPU power as UHD does.
Adding --pmode to fastflix doesn't change that.
I'm actually not that much concerned. If it's easy to do fine, otherwise never mind

But, any suggestions for 1080p CPU usage?

thanks.

[charliebaby]

@_kermit ? video test 2pass =
https://i.goopics.net/bem88.png

[MeteorRain]

Originally Posted by _kermit

But, any suggestions for 1080p CPU usage?

If you don't mind slightly lower efficiency you can try --ctu 32. That essentially half the row size, doubling the number of rows.