x265 HEVC Encoder

[Atak_Snajpera]

Solution is Simple. --ctu 16 for SD , --ctu 32 for HD/FHD and --ctu 64 for UHD.

[Boulder]

I tried encoding one track from a Dolby UHD test disc to see if I can make Dolby Vision work on my TV and to test if it falls back to HDR10 when played in Kodi. I extracted the RPU using the demuxing script here in the forum and fed it to the encoder.

With

c:\x265\x265.exe --input inputfile.avs --input-depth 16 --dither --sar 1:1 --profile main10 --rc-lookahead 40 --min-keyint 5 --keyint 480 --splitrd-skip --colorprim 9 --transfer 16 --colormatrix 9 --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)" --max-cll "1000,355" --frames 3576 --chromaloc 2 --hdr10 --hdr10-opt --repeat-headers --dolby-vision-profile 8.1 --dolby-vision-rpu "rpu.bin" --preset slower --crf 16 --output "dolby_test.hevc"

I got these errors:
Dolby Vision requires VBV settings to enable HRD.
Dolby Vision RPU count is greater than frame count in x265.

Well, I checked and the RPU is ok.

Adding --vbv-bufsize 999999999 --vbv-maxrate 999999999, I got the encode going so the complaint about the RPU file is a bug. The encode ran at Level 8.5

My question is: is VBV really necessary? Trying to add --no-hrd didn't do any good. I was thinking of patching the thing to skip that check if it's not needed. I know that I don't need it for my use and have never set it.

I could encode normally and just inject the RPU afterwards, but it would be easier and less diskspace consuming to do everything in one go.

[Rousseau]

What happened to the "Consecutive B-Frames" stats in the encode log? I just upgraded from Patman's 37 build to JPSDR's 103 build and it's gone. I tried john33's and djatom's binaries with the same result.

[TDS]

Originally Posted by Boulder

I tried encoding one track from a Dolby UHD test disc to see if I can make Dolby Vision work on my TV and to test if it falls back to HDR10 when played in Kodi. I extracted the RPU using the demuxing script here in the forum and fed it to the encoder.

With

c:\x265\x265.exe --input inputfile.avs --input-depth 16 --dither --sar 1:1 --profile main10 --rc-lookahead 40 --min-keyint 5 --keyint 480 --splitrd-skip --colorprim 9 --transfer 16 --colormatrix 9 
--master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)" --max-cll "1000,355" --frames 3576 --chromaloc 2 --hdr10 --hdr10-opt --repeat-headers --dolby-vision-profile 8.1 
--dolby-vision-rpu "rpu.bin" --preset slower --crf 16 --output "dolby_test.hevc"

I got these errors:
Dolby Vision requires VBV settings to enable HRD.
Dolby Vision RPU count is greater than frame count in x265.

Well, I checked and the RPU is ok.

Adding --vbv-bufsize 999999999 --vbv-maxrate 999999999, I got the encode going so the complaint about the RPU file is a bug. The encode ran at Level 8.5

My question is: is VBV really necessary? Trying to add --no-hrd didn't do any good. I was thinking of patching the thing to skip that check if it's not needed. I know that I don't need it for my use and have never set it.

I could encode normally and just inject the RPU afterwards, but it would be easier and less diskspace consuming to do everything in one go.

Don't you have to provide the full path to the rpu.bin ???

[Boulder]

Originally Posted by Rousseau

What happened to the "Consecutive B-Frames" stats in the encode log? I just upgraded from Patman's 37 build to JPSDR's 103 build and it's gone. I tried john33's and djatom's binaries with the same result.

It was lost at a recent commit for some reason.. IIRC quietvoid created a patch to get it back though.

Don't you have to provide the full path to the rpu.bin

Not needed if the file is in the folder where I launch the command line in. The same for "inputfile.avs".

[quietvoid]

Originally Posted by Rousseau

What happened to the "Consecutive B-Frames" stats in the encode log? I just upgraded from Patman's 37 build to JPSDR's 103 build and it's gone. I tried john33's and djatom's binaries with the same result.

As said above, it was removed.
The code can be added back with this commit: https://github.com/quietvoid/x265/co...a35be4377e390e

[benwaggoner]

Originally Posted by Boulder

My question is: is VBV really necessary? Trying to add --no-hrd didn't do any good. I was thinking of patching the thing to skip that check if it's not needed. I know that I don't need it for my use and have never set it.

It seems like VBV is important in your case !

I think it's always a good idea to set VBV to ensure compatibility with a given decoder. Just use --level-idc 5.1 and it will auto set reasonable values broadly compatible with UHD BD, Smart TVs, HW GPU decode, etc. 5.1 has a 40 Mbps peak, which is fine for 2160p24 content.

[jpsdr]

I checked the commit to put back "Consecutive B-Frames" in my moded version, unfortunately, there is big changes, and i don't realy know where and how put the histogram increment count...

[madey83]

Originally Posted by quietvoid

As said above, it was removed.
The code can be added back with this commit: https://github.com/quietvoid/x265/co...a35be4377e390e

Have you checked new updated Patman mode?

https://github.com/Patman86/x265-Mod-by-Patman/releases

[LigH]

New uploads: x265 3.5+103-8f18e3ad3 / x265 3.5+104-47c18bf12 (might be identical, patch counting mistake or different branches?)

[Windows][GCC 13.1.0][32/32XP/64 bit] 8bit+10bit+12bit

[Boulder]

I have a simple question regarding frametypes and chapter marks when using a qpfile. Does a chapter mark need an I-frame or is an i-frame enough? I'm using open GOP so setting 'K' in the qpfile would place i-frames in the encode.

[LigH]

An IDR frame (Intra frame with Decoder Reset) is preferable. When you jump to an intermediate I frame which is not IDR (e.g. to encode a single frame very different from the surrounding video), you will get decoding artifacts from predictions skipping this I frame missing a reference.

[LeXXuz]

Oh darn. Thanks for mentioning that. Now I know why my players always jump a little before or after the specified chapter point. MeGUI sets 'K' as default for keyframes when creating qpfiles. I guess I'll better change those manually to 'I' from now on.

[benwaggoner]

Originally Posted by LeXXuz

Oh darn. Thanks for mentioning that. Now I know why my players always jump a little before or after the specified chapter point. MeGUI sets 'K' as default for keyframes when creating qpfiles. I guess I'll better change those manually to 'I' from now on.

Yeah, only IDR frames are guaranteed to be independently decodable.

[jpsdr]

Hello.
I've made a new build, and also include some new Patman updates.
As usual, check my github.

[Barough]

x265 v3.5+108
https://www.mediafire.com/file/h8dmiufrc8al9oc/

[Barough]

x265 v3.5+109
https://www.mediafire.com/file/ix5f9yr3fes7tpb

[Barough]

x265 v3.5+110
https://www.mediafire.com/file/qbv4h1a20vxwf5i

[sainome]

Originally Posted by Atak_Snajpera

Solution is Simple. --ctu 16 for SD , --ctu 32 for HD/FHD and --ctu 64 for UHD.

Question: If I specify --ctu 16, what should I specify for merange?

[benwaggoner]

Originally Posted by sainome

Question: If I specify --ctu 16, what should I specify for merange?

They are orthogonal values, without much connection between optimum values. I'd stick with the one your --preset gives you unless you want to do a bunch of experimentation.

With --ctu 16 I suppose you could try --merange 41, which is 16 below the typical default of 57. It'd be a little faster, and depending on content might not raise bitrate or harm quality materially.