x265 HEVC Encoder

[James Freeman]

Thanks.

I can't find a intermediate codec that can do 10bit 4:2:2 AND 4K in AVI.
Any suggestion?

[birdie]

Um, do you mean container? Or encoder? The best encoder has always been ffmpeg.

[MeteorRain]

Thanks.

I can't find a intermediate codec that can do 10bit 4:2:2 AND 4K in AVI.
Any suggestion?

Try main422-10 profile.

Also AVI is a tricky choice. Like fit a car with some bicycle tires.

[Magik Mark]

Is it advisable to finish encoding first before using the computer for other applications? Will the quality of the encodes affected if cpu load starts shifting for other apps?


Sent from my iPhone using Tapatalk

[birdie]

Encoding/decoding are a strict mathematical process. In theory, if your CPU/RAM/HDD don't falter during work, the output will always be the same regardless of your workflow. Make sure you run your encoder at the lowest CPU priority of you may experience significant lags.

[James Freeman]

Try main422-10 profile.
Also AVI is a tricky choice. Like fit a car with some bicycle tires.

main422-10 is restricted to 1080p in After Effects, plus the file size is HUGE.

Anyway I found a AVI lossless encoder named Lagarith, it makes the file around 20 times smaller in 4:2:0 8bit, than Uncompressed RGB 8bit.
I can export straight to YV12 (4:2:0) YUY2 (4:2:2) or RGB in any resolution.

Another thing I found that AE dithers down from any higher bit depth, so the 32bit workflow is dithered down to 8bit at export.
My experience with madVR tells my that properly dithered 8bit is indistinguishable from 12bit (as read by i1 Display Pro).

When I encode with x265 I specify --input-depth 10, I guess that a dithered 8bit file inside a 10bit file would be perfectly fine.
Not true 10bit but still smooth as silk.

[Motenai Yoda]

mmm I'm not sure but IIRC 32bit in AE refers to all channel in a RGB behaviour, which is roughtly the same as 8bit in the single channel YUV one.
Also Lagarith is very slow with HD stuff, way better UtVideo or MagicYUV

[James Freeman]

mmm I'm not sure but IIRC 32bit in AE refers to all channel in a RGB behaviour, which is roughtly the same as 8bit in the single channel YUV one.
Also Lagarith is very slow with HD stuff, way better UtVideo or MagicYUV

No, 32bit Floating per channel, there is also 16bit and 8bit.
AE dithers down to 8bit if the workflow is in higher bit depth.

UtVideo, is EXACTLY what I needed, fast and efficient. thank you!

AE will not let me export as 10bit (with any codec that is not from adobe) in AVI no matter what.
Dithered 8bit looks as good as 12bit anyway.

[LigH]

Starting from a crf+preset combo is certainly a good idea. The developers spend some efforts in making presets a good all-purpose set of parameters. But slow presets will cost a lot of time, and even more if your CPU does not support AVX(2).

The "grain" tuning is meant to retain especially strong grain (think of "300"). Test on your own whether or not it is required and good-looking for your material... and expect some bitrate demand.

[dipje]

Thanks.

I can't find a intermediate codec that can do 10bit 4:2:2 AND 4K in AVI.
Any suggestion?

There are threads about questions like that. In .AVI is a problem though. Personally I'm using Vapoursynth and AfterEffects (and other tools) and happily go in and out through things like ProRes, DNXHD, DPX sequences and / or .EXR with PIZ compression.

Can't Cineform do 4K? I know it can do yuv422p10.. (just tested, my After Effects can export Cineform in 4K). Grassvaley HQX also seems to work in 4K alright.

It are both codecs that can be stored in AVI, although I can't think of any program that can interface properly with it. You could try going from Vapoursynth YUV422P10 (V210 fourcc) open it with virtualdub and from there save in one of two formats.

But honestly, there is a reason that all video editing packages seem to prefer Mov for this stuff. Avi is tricky enough already to store modern 8-bit stuff in, let alone 10p, 12p, 12p + alpha or other more 'cinema' style formats.

[James Freeman]

I realized that HEVC main10 output chroma subsampling has to be equal to the input, in raw YUV (uncompressed), so it has to be 10bit 4:2:0 uncompressed first.

If it is Lossless (compressed) I have to push it to HEVC through Avisynth with avs4x265 so only AVI is optional.
I want to export from AE in 10bit 4:2:0 4K (P010), MOV or AVI so that I can encode with HEVC.

Any idea?

[benwaggoner]

There are threads about questions like that. In .AVI is a problem though. Personally I'm using Vapoursynth and AfterEffects (and other tools) and happily go in and out through things like ProRes, DNXHD, DPX sequences and / or .EXR with PIZ compression.

Can't Cineform do 4K? I know it can do yuv422p10.. (just tested, my After Effects can export Cineform in 4K). Grassvaley HQX also seems to work in 4K alright.

It are both codecs that can be stored in AVI, although I can't think of any program that can interface properly with it. You could try going from Vapoursynth YUV422P10 (V210 fourcc) open it with virtualdub and from there save in one of two formats.

But honestly, there is a reason that all video editing packages seem to prefer Mov for this stuff. Avi is tricky enough already to store modern 8-bit stuff in, let alone 10p, 12p, 12p + alpha or other more 'cinema' style formats.
The AVI format itself is fine for this kind of use, and has the advantage of being simpler, unlike QuickTime files which in theory are Turing Complete :). And with the deprecation of QuickTime for Windows with a serious security flaw in the final version, Everyone not on Mac is going to have to use other implementations.

I've had AVI files >200 GB without any issues.

v210 is always good. Cineform absolutely works for UHD. Sometimes the stock DirectShow version doesn't work well, but the BlackMagic codec version does, and is broadly compatible. DNxHR is promising, and doesn't have the locked-down frame rates and frame sizes of DNxHD.

What we're lacking is a good codec that supports all the HDR metadata. The only thing I know of is just using a high-bitrate HEVC. HEVC-Intra with WPP could make a very good mezzanine codec: 10 and 12 bit support, and better efficiency than anything else. With WPP reasonably fast decoding on multicore systems, and with hardware decoders coming it'll be blazing fast. I can certainly get the same quality as ProRes at half the bitrate.

[stax76]

It seems x265 fails on Unicode file names, no problem with x264, QSVEncC, NVEncC or ffmpeg.


------------------------------------------------------------
Encoding video using x265 1.9+140 x64 multi lib 8/10/12 bit
------------------------------------------------------------

@echo off
CHCP 65001
"C:\Program Files (x86)\VapourSynth\core64\vspipe.exe" D:\Пред_temp\Пред.vpy - --y4m | D:\Projekte\GitHub\staxrip\bin\Apps\x265\x265_ml.exe --crf 22 --frames 1301 --y4m --output D:\Пред_temp\Пред_out.hevc -

cmd.exe /C call "D:\Пред_temp\Пред_encode.bat"

Aktive Codepage: 65001.
y4m [info]: 1280x720 fps 30000/1001 i420p8 unknown frame count
x265 [error]: failed to open output file <D:\????_temp\????_out.hevc> for writing
Error: fwrite() call failed when writing frame: 1, plane: 0, line: 11, errno: 22
Output 9 frames in 0.04 seconds (218.50 fps)

------------------------------------------------------------
Error Encoding video using x265 1.9+140 x64 multi lib 8/10/12 bit
------------------------------------------------------------

Encoding video using x265 1.9+140 x64 multi lib 8/10/12 bit failed with exit code: 1 (0x1)

The exit code might be a system error code: STATUS_WAIT_1

The exit code might be a system error code: Unzulässige Funktion.

Aktive Codepage: 65001.
y4m [info]: 1280x720 fps 30000/1001 i420p8 unknown frame count
x265 [error]: failed to open output file <D:\????_temp\????_out.hevc> for writing
Error: fwrite() call failed when writing frame: 1, plane: 0, line: 11, errno: 22
Output 9 frames in 0.04 seconds (218.50 fps)

[f81ccx]

Has anyone been able to get thread pool paramaters to work with ffmpeg?

I've tried passing in x265-params pools=16,16 as well as pools=+,+, but I only ever get a single thread pool instead of the 2 pools that I expect.

Machine:

Intel Xeon E5-2670 x2, Fedora 23. Lastest static build of ffmpeg that includes x265 version 1.9+141-02d79be487d7

Command line:

ffmpeg -i source.mov -c:v libx265 -preset veryslow -x265-params crf=20:pools=16,16 test.mkv


Output:
x265 [info]: HEVC encoder version 1.9+141-02d79be487d7
x265 [info]: build info [Linux][GCC 5.3.1][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main 4:2:2 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: frame threads / pool features : 6 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut : 24 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-20.0 / 0.60
x265 [info]: tools: rect amp limit-modes rd=6 psy-rd=2.00 rdoq=2 psy-rdoq=1.00
x265 [info]: tools: signhide tmvp b-intra strong-intra-smoothing deblock sao

[LigH]

Welcome to doom9...

So you have only one single physical CPU? I believe thread pools are meant to support the physical separation of multi-socket systems, but may require explicit NUMA support, depending on the OS.

[Ma]

Has anyone been able to get thread pool paramaters to work with ffmpeg?
[...]
Intel Xeon E5-2670 x2, Fedora 23. Lastest static build of ffmpeg that includes x265 version 1.9+141-02d79be487d7

For Linux you should compile x265 with ENABLE_LIBNUMA (it is ON by default).

[f81ccx]

Welcome to doom9...

So you have only one single physical CPU? I believe thread pools are meant to support the physical separation of multi-socket systems, but may require explicit NUMA support, depending on the OS.

My system is a Dual Xeon E5-2670.

I'll have a go at building ffmpeg from scratch, making sure libnuma is included.

[Ma]

It seems x265 fails on Unicode file names, no problem with x264, QSVEncC, NVEncC or ffmpeg.

Yes, it fails. You can try attached patch for output file.

[stax76]

Do you by chance have a 8/10/12 bit multilib build?

[Ma]

Do you by chance have a 8/10/12 bit multilib build?

www.msystem.waw.pl/x265/utf16_output.7z

It is only output file fixed (remains: input y4m + yuv and stat file).

[stax76]

www.msystem.waw.pl/x265/utf16_output.7z

It is only output file fixed (remains: input y4m + yuv and stat file).

works great, thanks!

[Magik Mark]

I have a single Xeon 2695v3 CPU. May I ask which among the x265 build is best for my CPU? Is it the ICC build? GCC 5.3 / 6? AVX2?

Thanks

[x265_Project]

I have a single Xeon 2695v3 CPU. May I ask which among the x265 build is best for my CPU? Is it the ICC build? GCC 5.3 / 6? AVX2?

Thanks
x265 has over a thousand kernels that have been hand-optimized with the latest SIMD instruction sets (SSE2, SSE3, SSE4, AVX, AVX2). Your compiler won't change these kernels one bit. For the rest of the code, there are very minor differences in performance due to different compilers (ICC vs GCC).

[Ma]

I've made extended version of Unicode patch for Windows -- now output file works and stat file(s). Console info is also fixed including error messages, example:
i:\vs\x265\ma\XP>x265 --pass 1 --bitrate 4500 --stat Łojezu_Łotr-jeden?.stat /speed/720p50_parkrun_ter.y4m -o W_żółtych_płomieni
ach_liści.hevc
y4m [info]: 1280x720 fps 50/1 i420p8 sar 1:1 frames 0 - 503 of 504
raw [info]: output file: W_żółtych_płomieniach_liści.hevc
x265 [info]: HEVC encoder version 1.9+147-19cced21060f
x265 [info]: build info [Windows][GCC 6.1.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: frame threads / pool features : 2 / wpp(12 rows)
x265 [error]: can't open stats file Łojezu_Łotr-jeden?.stat.temp
x265 [error]: failed to open encoder


Sample multilib build (WinXP compatible, 64-bit and 32-bit + patch):
www.msystem.waw.pl/x265/utf16_output-stat.7z

If there will be no errors, tomorrow I will send this patch to devel-list.

[stax76]

@MA

The first was perfect, this one encodes but the console output looks wrong:

https://i.imgur.com/DUOqiXY.png

My code works for all other tools:


Overloads Sub Encode(passName As String, batchCode As String)
batchCode = "@echo off" + BR + "CHCP 65001" + BR + batchCode
Dim batchPath = p.TempDir + p.TargetFile.Base + "_encode.bat"
File.WriteAllText(batchPath, batchCode, New UTF8Encoding(False)) 'UTF8 without BOM

Using proc As New Proc
proc.Init(passName)
proc.Encoding = Encoding.UTF8
proc.File = "cmd.exe"
proc.Arguments = "/C call """ + batchPath + """"
proc.Start()
End Using
End Sub

[Ma]

@stax76
Thanks for info! I've changed output mode for stderr from _O_U16TEXT to _O_U8TEXT. New test build (only 64-bit + patch):
www.msystem.waw.pl/x265/utf16_output-stat2.7z

[stax76]

@Ma

Thanks for the test build, I tested various things without noticing any problem!

[pingfr]

The true power of the Open Source. :)

[x265_Project]

The true power of the Open Source. :)

It's unbeatable. Thanks guys. :)

[Ma]

Patch which allows Unicode filenames in Windows (for now output file and stat files) has been sent
https://patches.videolan.org/patch/13109/

Next we can fix input files.
------------------------
GCC on old mingw-w64 not works with this code. First workaround is:
diff -r 00ea3784bd36 source/common/common.cpp
--- a/source/common/common.cpp Thu Apr 28 09:59:30 2016 +0200
+++ b/source/common/common.cpp Fri Apr 29 03:12:31 2016 +0200
@@ -185,7 +185,7 @@
MultiByteToWideChar(CP_UTF8, 0, buffer, -1, buf_utf16, sizeof(buf_utf16)/sizeof(wchar_t));
fflush(stderr);
int oldmode = _setmode(_fileno(stderr), _O_U8TEXT);
- fwprintf(stderr, L"%ls", buf_utf16); // WARNING: due to bug in msvcrt.dll fputws doesn't work in mingw/gcc
+ fwprintf_s(stderr, L"%ls", buf_utf16); // WARNING: due to bug in msvcrt.dll fputws doesn't work in mingw/gcc
fflush(stderr);
_setmode(_fileno(stderr), oldmode);
}Under investigation...

[Ma]

Could someone with WinXP test this 32-bit version of x265:
www.msystem.waw.pl/x265/32bit-xp.zip

I've tested on Win7 64bit and Vista 32bit -- works. I don't have WinXP.
It should work and should be line "raw [info]:"
y4m [info]: 1280x720 fps 50/1 i420p8 sar 1:1 frames 0 - 503 of 504
raw [info]: output file: Żółć.hevc
x265 [info]: HEVC encoder version 1.9+150-00ea3784bd36
x265 [info]: build info [Windows][GCC 5.3.0][32 bit] 8bit

This is due a bug in old mingw-w64 (v4 for example) in function fwprintf, so we can try fwprintf_s instead.
-------------------
Finally I give up with mingw-w64 (for ver. 3 I can't write working code), so it is easier switch to Windows API. If someone wants to try new code:
hg import --no-commit https://patches.videolan.org/patch/13138/raw/

[pie]

Could someone with WinXP test this 32-bit version of x265:
www.msystem.waw.pl/x265/32bit-xp.zip



Doesn't work:
http://i.imgur.com/v4bLZpq.png

[Ma]

Doesn't work:
http://i.imgur.com/v4bLZpq.png

Thanks!

I've prepared new samples compiled with patch
https://patches.videolan.org/patch/13138/
Could you test this on WinXP (on 99% should work, both compiled by GCC 4.8.3 and GCC 5.3):
www.msystem.waw.pl/x265/32bit-xp2.zip

[pie]

Thanks!
Could you test this on WinXP (on 99% should work, both compiled by GCC 4.8.3 and GCC 5.3):
www.msystem.waw.pl/x265/32bit-xp2.zip


Both versions seem to work.

raw [info]: output file: Zólc.hevc

[Ma]

Both versions seem to work.

raw [info]: output file: Zólc.hevc

Thanks! So we should make a fix to mingw-w64 code (but this may take a long while). For now it is better to apply 13138 patch.
---------------
After investigation -- mingw-w64 code looks OK, x265 v1.9+150 code looks OK, the bug is in msvcrt.dll. Almost all mingw-w64 stdio code is written with use of fputwc/fputc functions from msvcrt.dll. fputwc function from msvcrt.dll doesn't work with _O_U8TEXT mode (works only with _O_U16TEXT mode). If you build x265 v1.9+150 by mingw-w64/gcc linked to msvcrt.dll, there will be no "raw [info]" line in console. If you link to msvcr110.dll instead of msvcrt.dll, all is working (without any changes in x265 code nor mingw-w64 code). Example www.msystem.waw.pl/x265/gcc483-xp.7z -- x265n.exe is linked to msvcr110.dll and works OK without any patches.

[James Freeman]

I realized that HEVC main10 output chroma subsampling has to be equal to the input, in raw YUV (uncompressed), so it has to be 10bit 4:2:0 uncompressed first.

If it is Lossless (compressed) I have to push it to HEVC through Avisynth with avs4x265 so only AVI is optional.
I want to export from AE in 10bit 4:2:0 4K (P010), MOV or AVI so that I can encode with HEVC.

Any idea?

Bump this.

Any idea how I can push a EXR sequence (individual file fer frame) to x265?
I tried everything in after effects but can't generate a 10bit 4:2:0 4K MOV or AVI file for x265 Main10.

Any suggestion to go from After Effects workflow to 10bit 4:2:0 4K is much appreciated.

[James Freeman]

Okay, Ihave managed to maintain a 10bit 4K workflow from start to finish.

First I export to PNG image sequence in 16bit (smallest file format compared to TIFF, DPX, EXR).
Next I use ffmpeg PNG image sequence to Y4M raw in yuv420p10, 16bit RGB full range PNG converted and dithered down to 10bit YUV 4:2:0 Limited range by ffmpeg with 1:1 color accuracy.
8 seconds Y4M (192 frames) = 4GB !!

Anyone knows a better way to keep a 4:2:0 10bit 4K workflow in a smaller footprint?
For test patterns it is pointless to use more than 1 fps, so the Y4M is proportionally smaller since it is uncompressed.

For anyone interested, here are my steps:
ffmpeg.exe -framerate 24 -i "E:\Sequence\img-%%05d.png" -strict -1 -pix_fmt yuv420p10 -vf colormatrix=bt601:bt709 "E:\x265\RAW.Y4M"

x265.exe --input-depth 10 --uhd-bd --preset slow --crf 18 --colorprim bt2020 --transfer smpte-st-2084 --colormatrix bt2020nc --master-display "G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,1)" --max-cll "0,0" --output "E:\x265\output.hevc" "E:\x265\RAW.y4m"

mp4box.exe -add E:\X265\output.hevc -new E:\X265\output.mp4

[LigH]

I guess ffmpeg could read image sequences and pipe Y4M. But no guarantees, and no idea about quirks how to manage the color depths.

[James Freeman]

What do you mean "no guarantee" and "quirks how to manage the color depths"?
Can you be more specific?

[LigH]

I cannot guarantee that ffmpeg can handle 16 bit per component PNG.

If it can, I don't know which command line options are required to convert to 10 bit per component YUV 4:2:0.

But it should be worth discovering if it works, and how.

[sneaker_ger]

Piping is simple. Replace ffmpeg output and x264 input file name with a "-", signal both to use y4m (since they don't have a file name they cannot guess from the file extension) and write the commands in a single line connect with a pipe symbol "|".
ffmpeg.exe -framerate 24 -i "E:\Sequence\img-%%05d.png" -strict -1 -pix_fmt yuv420p10 -f YUV4MPEGPIPE - | x265.exe --input-depth 10 --uhd-bd --preset slow --crf 18 --colorprim bt2020 --transfer smpte-st-2084 --colormatrix bt2020nc --master-display "G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,1)" --max-cll "0,0" --output "E:\x265\output.hevc" - --y4m

The color thing might indeed not be trivial at all. PNG is RGB not YUV.

[James Freeman]

It definitely works and the conversion from 16bit RGB Full range to 10bit YUV 4:2:0 Limited range is flawless.
The Y4M 10bit is properly dithered by ffmpeg and not simply truncated.
A smooth 16bit grey ramp looks absolutely identical after the conversion.

But if you find flaws, this will be informative to us all.

[James Freeman]

Piping is simple. Replace ffmpeg output and x264 input file name with a "-", signal both to use y4m (since they don't have a file name they cannot guess from the file extension) and write the commands in a single line connect with a pipe symbol "|".
ffmpeg.exe -framerate 24 -i "E:\Sequence\img-%%05d.png" -strict -1 -pix_fmt yuv420p10 -f YUV4MPEGPIPE - | x265.exe --input-depth 10 --uhd-bd --preset slow --crf 18 --colorprim bt2020 --transfer smpte-st-2084 --colormatrix bt2020nc --master-display "G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,1)" --max-cll "0,0" --output "E:\x265\output.hevc" - --y4m

The color thing might indeed not be trivial at all. PNG is RGB not YUV.

You mean I don't have to create a HUGE y4m file before going to x265?
Why that is absolutely PERFECT!

I'm off to try it.

[sneaker_ger]

It definitely works and the conversion from 16bit RGB Full range to 10bit YUV 4:2:0 Limited range is flawless.
The Y4M 10bit is properly dithered by ffmpeg and not simply truncated.
But we are not just talking about range and dithering. You want bt.2020. You want HDR. You want non-mpeg2-chroma position. I highly doubt this is achieved with your simple ffmpeg command.

[James Freeman]

The PNG images are already in 2020 and HDR, they are exported from After Effects with Color space and range conversion with official Rec.2020 ST.2084 (PQ) profiles and edited with 1000 nit in mind.
Think of the PNG files as though I just graded a movie on a Rec.2020 ST.2084 monitor.

I don't know about chroma position but it looks right to me on default settings.

EDIT:
The pipe works perfectly, you saved me a lot of effort, thank you!

[Jamaika]

mp4box.exe -add E:\X265\output.hevc -new E:\X265\output.mp4
Correct entry:;)
mp4box.exe -new -info -add E:\X265\output.h265:mpeg4:noedit:trailing:xps_inband E:\X265\output.mp4
or
mkvmerge.exe --ui-language en --fourcc 0:HEVC --cues 0:iframes "E:\X265\output.h265" --track-order 0:0 --disable-track-statistics-tags --output "E:\X265\output.mkv"

[James Freeman]

I had to add "-vf colormatrix=bt601:bt709" to ffmpeg so the RGB -> YUV color conversion will be correct.
Now it looks and measures 1:1 to the RGB.

EDIT Important!
The "-vf colormatrix=bt601:bt709" should be changed to "-vf scale=out_color_matrix=bt709" because the colormatrix command is only 8bit and it dithers down to 8bit.
While the scale=out_color_matrix=bt709 command bypasses any conversion while retains correct chroma values between RGB to YUV conversion.

[sneaker_ger]

mkvmerge.exe --ui-language en --fourcc 0:HEVC --cues 0:iframes "E:\X265\output.h265" --track-order 0:0 --disable-track-statistics-tags --output "E:\X265\output.mkv"
Don't give people funny ideas on how to use mkvmerge. A simple "mkvmerge -o output.mkv input.hevc" is totally fine. I hope your mp4box example is better, I don't know enough about mp4box to judge it.

[James Freeman]

Okay I run a single batch file that does everything in one click:
ffmpeg.exe -framerate 24 -i "E:\x265\Sequence\%%05d.png" -strict -1 -pix_fmt yuv420p10 -vf colormatrix=bt601:bt709 -f YUV4MPEGPIPE - | x265.exe --input-depth 10 --uhd-bd --preset slow --crf 18 --colorprim bt2020 --transfer smpte-st-2084 --colormatrix bt2020nc --master-display "G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,1)" --max-cll "0,0" --output "E:\x265\output.hevc" - --y4m
mp4box.exe -add E:\X265\output.hevc -new E:\X265\output.mp4
pause
Thanks sneaker_ger.

EDIT Important!
The "-vf colormatrix=bt601:bt709" should be changed to "-vf scale=out_color_matrix=bt709" because the colormatrix command is only 8bit and it dithers down to 8bit.
While the scale=out_color_matrix=bt709 command bypasses any conversion while retains correct chroma values between RGB to YUV conversion.

[surami]

James, please write your post into to the 4K HDR encoding topic too and post the example files.

Ps.: As I have time I will try this with Cineform RGBA 12bit files (instead of pngs), I read somewhere that ffmpeg supports them already... but if somebody knows more please say something.