Encoding 4K HDR 4:2:0 10bit BT.2020

[kolak]

You should be able to stream these files to your TV using some DLNA server. No need to copy them to USB.

[benwaggoner]

I just run through the Dolby Vision white paper (v2) (http://www.dolby.com/us/en/technologies/dolby-vision/dolby-vision-white-paper.pdf). They are mentioning two layers, a base layer + an enhancement layer + metadata (page 11). On the x265 command line options page: "A decoder may chose to drop the enhancement layer and only decode and display the base layer slices."
Yes, when using a backwards-compatible base layer, the base layer will be SDR. Note that there are a lot more profiles since then, with both backwards and non-backwards compatible base layers, and single layer as well.

It can be, that Sony HDR sample has been encoded this way...
It wasn't.

I'm just thinking loudly, maybe I'm wrong and nothing is right.
I think the file just has bad metadata. A quick glance with MediaInfo should be helpful.

[surami]

You should be able to stream these files to your TV using some DLNA server. No need to copy them to USB.

Thanks for the advice.

Yes, when using a backwards-compatible base layer, the base layer will be SDR. Note that there are a lot more profiles since then, with both backwards and non-backwards compatible base layers, and single layer as well.


... and in case Dolby Vision videos, the base layer is HDR10, so you can decode it with simple HDR10 capable TV sets, without Dolby Vision mechanism.

But it can be that there is a case where SDR + enh. nr. 1 = HDR10 + enh. nr. 2 = Dolby Vision, but maybe this is too much data for one disc.


I think the file just has bad metadata. A quick glance with MediaInfo should be helpful.

Yes it can be, James also mentioned this, there is the info. But then how could I watch the goodlooking colorful video too? It should be a video with two layers and maybe the metadata is correct for the enhancement layer.

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
Codec ID : hvc1
Codec ID/Info : High Efficiency Video Coding
Duration : 2mn 7s
Bit rate : 75.6 Mbps
Maximum bit rate : 123 Mbps
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 59.940 (60000/1001) fps
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.152
Stream size : 1.12 GiB (100%)
Encoded date : UTC 2016-02-03 07:59:49
Tagged date : UTC 2016-02-03 08:01:32
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : SMPTE ST 2084
Matrix coefficients : BT.2020 non-constant
Mastering display color primar : R: x=1.000000 y=1.000000, G: x=1.000000 y=1.000000, B: x=1.000000 y=1.000000, White point: x=1.000000 y=1.000000
Mastering display luminance : min: 0.1000 cd/m2, max: 0.5000 cd/m2

[nevcairiel]

Yes it can be, James also mentioned this, there is the info. But then how could I watch the goodlooking colorful video too? It should be a video with two layers and maybe the metadata is correct for the enhancement layer.


Mastering display color primar : R: x=1.000000 y=1.000000, G: x=1.000000 y=1.000000, B: x=1.000000 y=1.000000, White point: x=1.000000 y=1.000000
Mastering display luminance : min: 0.1000 cd/m2, max: 0.5000 cd/m2

What makes you think there actually is two layers?
And this mastering metadata is definitely absolutely wrong.

[surami]

Yes, I saw that mastering metadata too. What makes me think there are two layers is the following, sometimes I can see the colorfull goodlooking video, sometimes the weird white thing + the high fps, it's random when the different cases are happening. I've a GTX 960 in my computer, so what causes I don't know, video card, LAVSplitter, madVR, MPC-HC or two layer video?

[James Freeman]

It's madVR.
Please update to 90.18, no more colorfull goodness with wrong metadata.

[surami]

I tried, white stuff here also and if I update my video card driver to the latest one, then the playback is colorfull, but stutters.

[surami]

I encoded a new experiment file (https://drive.google.com/file/d/0B9p82xjTYmAxZXlBZk90REM4LUE/view?usp=sharing) (183 MB) straight from a Cineform RGBA 12bit MOV. The same video, what I uploaded last year but now this is real 10bit, because I hadn't piped through the Advanced FrameServer (RGB24) + AviSynth+ (BT.709 -> BT.2020 conversion).

In AE, the settings were the same:
sRGB, 32bit composition
+ Lumetri Color; White: -15
+ Compress; Gain: 1, Gamma: 0,9
+ Shadow/Highlight; 10/20
+ Color Balance; Shadow Blue Balance: -10
+ Expand; Gain: 1, Gamma: 0,9
+ Color Profile Converter; In: sRGB, Out: Rec2020 ST.2084, Intent: Perceptual
+ HDR Highlight Compression: 100%
+ Unsharp Mask; Amount: 20, Radius: 50

and the combined ffmpeg + x265 command line (thanks for the chroma position and for the out color matrix):
ffmpeg.exe -nostats -i "input.mov" -strict -1 -vf scale=out_color_matrix=bt2020:out_h_chr_pos=0:out_v_chr_pos=0,format=yuv420p10 -f yuv4mpegpipe - |
x265_10bit.exe - --y4m --uhd-bd --crf 13 --tune grain --colorprim bt2020 --transfer smpte-st-2084 --colormatrix bt2020nc
--master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" --max-cll "1000,400" --output "output.hevc"
pause

and now I used the L-SMASH muxer + the mp4box together:
muxer.exe -i output.hevc?[fps=25] -o output.mp4
mp4box.exe -add output.mp4 -brand isom -new output_final.mp4
del output.mp4
ren output_final.mp4 output.mp4
pause

Till now this is the best what I can do and it looks good on my PC and on my TV too.

[James Freeman]

Looks Good!
Well done.

[surami]

Thanks James.

I just found an interesting LUT application (https://cameramanben.github.io/LUTCalc/) (generating, analysing and previewing) by Ben Turley, maybe it will be usefull for someone, it supports PQ and HLG too.

[pp300]

Is there any tools to calculate maxCLL and maxFALL volume ?

I trying to make a playable HDR video after I greaded in Davinci Resolve, but seems like there isn't any tool to measure them.

Now I just filed in random number, but it seems to effect madVR output siginal.

[surami]

There is a very good post about "HDR, Resolve, and Creative Grading (http://vanhurkman.com/wordpress/?p=3548)" by Alexis Van Hurkman.

[d3rd3vil]

Hoho!

So I've just tested some 4k x264 and 4k x265 stuff with my 970GTX and MPC via DXVA2 (copy-back) and Enhanced Video Renderer and its working. For example that HDR Sony Camp demo runs perfectly fine:
http://demo-uhd3d.com/fiche.php?cat=uhd&id=144

So what exactly should not work? I mean real HDR/Dolby Vision doesnt work thx to HDMI 2.0 (missing a.....) :(
But other 4k 10bit should work?!

Besides the Sony Camp demo is x264 or x265? What kind of stuff could I test?
Cause if it's all working then the only thing missing would be HDR/Dolby Vision for an OLED TV someday ^^

[kolak]

As far as I understand Dolby Vision will work only with TVs which have Dolby chip: Vizio (and I think new LG TVs also will have it). Other manufactures seams to be not that keen to pay Dolby licensing fees:)

[d3rd3vil]

Yeah well so far ^^. I am heading in the OLED direction anyway. But the 970GTX with HDMI 2.0 wont be able to send it, right? 2.0a needed which could be upgraded via software update but that wont happen.

[kolak]

2.0->2.0a will be just a firmware update, so it can be done if Nvidia decides to.

[d3rd3vil]

And Nvidia sure says no thx to GTX 1070/1080 and they want to sell it big time. Or maybe after a few months/years they decide to do it who knows. I doubt it.

[huhn]

i doubt they are going to firmware downgrade to HDMI 2.0a they are already using HDMI 2.0b.

[d3rd3vil]

Yeah well that upgrade talk was about the 970/980 series with 2.0 (no a or b)! The 1070/1080 have 2.0b with everything a man can dream of :)

[huhn]

MAXWELL is HDR ready too.

but we are missing software that can send this info to the GPU and maybe windows 10 and the GPU driver doesn't have the API for this yet.

HDMI 2.0B is NOT a new feature: http://i.imgur.com/02A3RzQ.png

[nevcairiel]

2.0b does not include new features though, its practically 2.0a with a few editorial changes in the specification.
The next big thing will be 2.1 with dynamic HDR metadata support.

[d3rd3vil]

Dolby Vision is already dynamic with 2.0a, isnt it? As todays DV TVs only have 2.0....
I don't want to see that dynamic HDR stuff with 2.1 that would be a desaster for graphicscards, TVs and mediaplayers.

I'd be happy with 4k@60hz and maybe 10bit 4:4:4 via HDMI 2.0 from my 970GTX. Maybe that will work. HDR-DV would be the next step...

[benwaggoner]

Dolby Vision is already dynamic with 2.0a, isnt it? As todays DV TVs only have 2.0

All HDR TVs support 2.0a. That's required to transmit the HDR metadata.

[huhn]

I'd be happy with 4k@60hz and maybe 10bit 4:4:4 via HDMI 2.0 from my 970GTX. Maybe that will work. HDR-DV would be the next step...

HDMI 2.0 is to slow for that. they need a new spec with higher speed to send UHD@60 4:4:4 10 bit.

[kolak]

Yes, HDMI people are bit slow.
DisplayPort is getting good bandwidth.

[d3rd3vil]

What is too slow? HDMI 1.4 is enough for 4k@30hz. HDMI 2.0 should be enough for 4k@60hz and 10 bit because 2.0a is only a software update and that IS enough for 4k@60hz with 10bit and HDR/Dolby Vision.

[huhn]

the bandwidth of HDMI 2.0 is not enough for UHD@60 fps 4:4:4 10 bit

high bit deep for 60 fps is only available with 4:2:2 or 4:2:0.

here are the specs: http://www.hdmi.org/manufacturer/hdmi_2_0/hdmi_2_0_faq.aspx

DP is the real deal.

[benwaggoner]

HDMI 2.0 is to slow for that. they need a new spec with higher speed to send UHD@60 4:4:4 10 bit.
4:4:4 at 3840x2160 would be crazy overkill. 2160p 4:2:0 has all the chroma detail as 1080p 4:4:4, which I don't think I've ever heard suggested is inadequate.

I am having trouble of even thinking of a pathological test pattern that would show visible difference between 4:4:4 and 4:2:0 on UHD without being so close to the screen that the entire image wouldn't be visible at once without physically relocating head position.

[huhn]

4:4:4 at 3840x2160 would be crazy overkill. 2160p 4:2:0 has all the chroma detail as 1080p 4:4:4, which I don't think I've ever heard suggested is inadequate.

I am having trouble of even thinking of a pathological test pattern that would show visible difference between 4:4:4 and 4:2:0 on UHD without being so close to the screen that the entire image wouldn't be visible at once without physically relocating head position.

try this test pattern:
http://madshi.net/madVR/ChromaRes.png

the color is totally changed with chroma subsampling.
no question it is an extreme example.

4:2:0 UHD screen with red text on a black background is just FHD if this looks the same as 4:4:4 than UHD is useless in the first place.

even this image: http://i532.photobucket.com/albums/ee322/Marathongman/LOVERS%20OF%20RED/quote-shout-or-shutup-black-background-red-text.png (the first image i have found on google) displayed unscaled centered on my UHD screen show very visible artifacts. of cause they are amplified by the really bad chroma sup sampling from my nvidia card. but this image doesn't have the fines details too.

[benwaggoner]

try this test pattern:
http://madshi.net/madVR/ChromaRes.png

the color is totally changed with chroma subsampling.
no question it is an extreme example.
And when I output and compress it as 4:2:0, the problems almost entirely go away.

If the example content for problems with subsampling is fixed by subsampling, I'm not sure what the problem is :).

Also, that is 1080p, not UHD. 4:2:0 UHD will have the same chroma detail as that file anyway.

[huhn]

And when I output and compress it as 4:2:0, the problems almost entirely go away.

If the example content for problems with subsampling is fixed by subsampling, I'm not sure what the problem is :).

Also, that is 1080p, not UHD. 4:2:0 UHD will have the same chroma detail as that file anyway.

i know the image isn't UHD. but that doesn't matter if you watch it centered unscaled in a latterbox.

and as you already see without subsampling the image should be pink and only the 4.4:4 should be purple.

[d3rd3vil]

Well ok then. No idea how brutal the difference is then. Gotta test that in the next months with an 4k OLED if 4k@60hz with 10bit and 4:2:2 is good enough or not :)
The 4k testfiles even with HDR are usually in 4:2:2 as far as I know. Maybe its good enough :)

[huhn]

if the chroma test image is used correctly the difference is always visible.

that's why i added this other image. red colored text on a black background is at least realistic could be in a source unlike a 1 to 1 pixel chessboard pattern.

[nevcairiel]

They key point is that video content is originally nearly always 4:2:0, or at best 4:2:2, so a 4:2:2 transmission doesn't lose any information when using it exclusively for video.
Gaming or desktop usage is another thing entirely, but those generally don't benefit from 10-bit (yet) either way.

[benwaggoner]

Well ok then. No idea how brutal the difference is then. Gotta test that in the next months with an 4k OLED if 4k@60hz with 10bit and 4:2:2 is good enough or not :)
The 4k testfiles even with HDR are usually in 4:2:2 as far as I know. Maybe its good enough :)
I am not aware of anyone doing UHD or HDR distribution in anything other than 4:2:0, which is all that is supported by HEVC version 1, and the Main and Main 10 profiles.

[huhn]

the biggest problem for video right now it that we can't send 4:2:0 or 4:2:2 with out converting it. the proper YCbCr - RGB converted source get's butchered by the GPU.

[d3rd3vil]

Ok then 4k@60hz with 4:2:2 is just fine I am good with that :)

[d3rd3vil]

Just tried the Elysium and football clip from here:
http://4ksamples.com/

And THIS doesnt work at all. Not with DXVA or with the CPU power. It is stuttering nonstop. Damn thats what you need a 1070/1080 for, apparently. Anyone who has a card like that and can test these files? :)

[surami]

Stay on topic guys.

[surami]

Any "new" HDR workflow?

[benwaggoner]

Any "new" HDR workflow?
Higher bit depths and sampling are used in the content creation workflows, absolutely. But all the industry UHD and HDR specs are 4:2:0. 4K Blu-ray doesn't support 4:2:2. Most devices don't.

Really, 4:2:2 was invented for interlaced content, so chroma samples wouldn't have to span fields. It wasn't ever intended for, or truly needed for, encoding progressive moving image content. Decent YUV 4:2:0 to RGB 4:4:4 converters make even the worst-case test patterns look a lot better; nearest neighbor with CUE was pretty bad!

Anyway, the ship has left the harbor for consumer formats for 4:2:0. At least we have 10-bit HEVC as pretty much universal for UHD, so we've finally broken the stranglehold of 8-bit.

If we start seeing native 12-bit HEVC for Dolby Vision etcetera someday, that might be an inflection point where going beyond 4:2:0 could happen. But really, color subsampling is behind a lot of other priorities in industry and standards groups.

[groucho86]

Hi everyone,
I posted this question on the Blackmagic forum, but I'm hoping someone on this forum might know more.

I have an OpenEXR sequence rendered out from Resolve (12.5) using their ACES workflow with the P3D60 PQ (1000 nits) ODT.

In Resolve, we're reviewing color simultaneously on the Sony X300 and the LG OLED65G6P and colors match very well.

On Mac OSX 10.9.5, this is my terminal command:

ffmpeg -nostats -start_number 00086400 -framerate 24000/1001 -i "/Volumes/TEST/p3d60/p3d60-%08d.exr" -strict -1 \\
-vf scale=out_color_matrix=bt2020:out_h_chr_pos=0:out_v_chr_pos=0,format=yuv420p10 -f yuv4mpegpipe - | \\
x265 - --y4m --uhd-bd --crf 13 --tune grain --colorprim bt2020 --transfer smpte-st-2084 --colormatrix bt2020nc \\
--master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(16085,16885)L(10000000,1)" --max-cll "1000,400" --output "/Volumes/TEST/hevc/test.hevc"

Terminal output:
ffmpeg version 3.1.3 Copyright (c) 2000-2016 the FFmpeg developers
built with Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
configuration: --prefix=/usr/local/Cellar/ffmpeg/3.1.3 --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-hardcoded-tables \\
--enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-opencl --enable-libx264 --enable-libmp3lame --enable-libxvid \\
--enable-libfreetype --enable-libvorbis --enable-libvpx --enable-libass --enable-ffplay --enable-libfdk-aac --enable-libopus --enable-libx265 \\
--disable-lzma --enable-nonfree --enable-vda
libavutil 55. 28.100 / 55. 28.100
libavcodec 57. 48.101 / 57. 48.101
libavformat 57. 41.100 / 57. 41.100
libavdevice 57. 0.101 / 57. 0.101
libavfilter 6. 47.100 / 6. 47.100
libavresample 3. 0. 0 / 3. 0. 0
libswscale 4. 1.100 / 4. 1.100
libswresample 2. 1.100 / 2. 1.100
libpostproc 54. 0.100 / 54. 0.100
Input #0, image2, from '/Volumes/TEST/p3d60/p3d60-%08d.exr':
Duration: 00:00:02.96, start: 0.000000, bitrate: N/A
Stream #0:0: Video: exr, rgb48le, 1920x1080 [SAR 1:1 DAR 16:9], 23.98 tbr, 23.98 tbn, 23.98 tbc
[yuv4mpegpipe @ 0x7fe351808600] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
[yuv4mpegpipe @ 0x7fe351808600] Warning: generating non standard YUV stream. Mjpegtools will not work.
Output #0, yuv4mpegpipe, to 'pipe:':
Metadata:
encoder : Lavf57.41.100
Stream #0:0: Video: wrapped_avframe, yuv420p10le, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 23.98 fps, 23.98 tbn, 23.98 tbc
Metadata:
encoder : Lavc57.48.101 wrapped_avframe
Stream mapping:
Stream #0:0 -> #0:0 (exr (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
y4m [info]: 1920x1080 fps 24000/1001 i420p10 sar 1:1 unknown frame count
raw [info]: output file: /Volumes/TEST/hdr/hevc/p3d60-regxxxx.hevc
x265 [info]: HEVC encoder version 0.0
x265 [info]: build info [Mac OS X][clang 6.0.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
x265 [warning]: Rc Grain removes qp fluctuations caused by aq/cutree, Disabling aq,cu-tree
x265 [warning]: uhd-bd: Turning on repeat-headers
x265 [warning]: uhd-bd: Turning off open GOP
x265 [warning]: uhd-bd: keyframeMin is always 1
x265 [warning]: uhd-bd: reducing keyframeMax to 24
x265 [warning]: Specifying a decoder level with constant rate factor rate-control requires
x265 [warning]: enabling VBV with vbv-bufsize=160000kb vbv-maxrate=160000kbps. VBV outputs are non-deterministic!
x265 [info]: Main 10 profile, Level-5.1 (High tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: frame threads / pool features : 5 / 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 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 1 / 24 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / on / on
x265 [info]: Rate Control / qCompress : CRF-13.0 / 0.60
x265 [info]: VBV/HRD buffer / max-rate / init : 160000 / 160000 / 0.900
x265 [info]: tools: rd=3 psy-rd=4.00 signhide tmvp strong-intra-smoothing
x265 [info]: tools: lslices=6 deblock

I then create an MP4 with:
mp4box -add test.hevc -new test.mp4

The mp4 gets copied to a thumb drive. When I play it back on the LG, the image appears darker. Oranges are almost red.

I feel there's an incorrect conversion happening, but I don't know if it's being baked in into the hevc or if it's the HDR metadata (SEI info) that is wrong.

Any insight would be much appreciated!

[Jamaika]

Dear user, there is no such features "scale=out_color_matrix=bt2020,format=yuv420p10" on the ffmpeg for 10-bit and higher. FFmpeg always converts to the 8bit BT601 and then is output 10bit BT2020. :(
What was the range in the file "p3d60-%08d.exr"?

[groucho86]

Reading previous post in this thread, I thought recent builds of FFMPEG supported this:

You convert from RGB to YUV - you are not going to "convert" the colorspace, but you need to actually pick one for the RGB->YUV conversion. If your original RGB is BT.2020, then your YUV should also be BT.2020, or weird things might happen.
If you perform a RGB -> YUV conversion, and expect a future YUV -> RGB conversion to look the same as the original, both conversions need to use the same colorspace. And you encode the YUV as BT.2020, then the original conversion should also be BT.2020, should it not?

Note that using bt2020 in -vf scale needs a rather recent ffmpeg, it was added there only mid of april.

In short, the important part is that in a RGB -> YUV -> RGB chain, both conversions use the same colorspace.

What was the range in the file "p3d60-%08d.exr"?
Not sure if you're asking frame range or color space range hehe.
170 frames, and I believe Resolve is working in the P3 color space (within Rec.2020).

[benwaggoner]

Dear user, there is no such features "scale=out_color_matrix=bt2020,format=yuv420p10" on the ffmpeg for 10-bit and higher. FFmpeg always converts to the 8bit BT601 and then is output 10bit BT2020. :(
What was the range in the file "p3d60-%08d.exr"?
Yes, the only way I've been able to use ffmpeg in HDR workflows is to have HDR-10 input (PQ EOTF + Rec 2020 primaries) in the source, and then limit ffmpeg to decoding, scaling, cropping etcetera. No color space conversion or any filters that touch luma or chroma values, because they assume Gamma, not PQ, and will mess things up terribly. So output and input are 2020/PQ but ffmpeg doesn't have any idea of that.

[Jamaika]

Not sure if you're asking frame range or color space range hehe.
Of course, the color range. You should always define.

[groucho86]

Ben, is there anything in my command that doesn't look right to you?

[benwaggoner]

Ben, is there anything in my command that doesn't look right to you?
I've never tried to include the color space in the scaling. It looks like you want SMPTE 2084 "PQ curve" luma, which isn't the same as Rec. 2020 luma.

If your OpenEXR sources are already in HDR-10 space, I'd just leave the color_matrix out since there aren't any color space transforms needed. If it isn't in HDR-10 space, ffmpeg needs to get 2084 support.

[Parabola]

Yes, the only way I've been able to use ffmpeg in HDR workflows is to have HDR-10 input (PQ EOTF + Rec 2020 primaries) in the source, and then limit ffmpeg to decoding, scaling, cropping etcetera. No color space conversion or any filters that touch luma or chroma values, because they assume Gamma, not PQ, and will mess things up terribly. So output and input are 2020/PQ but ffmpeg doesn't have any idea of that.

Hmm, scaling touches luma and chroma values and, worse than assuming gamma, scaling in FFmpeg assumes linear light! For most applications of SDR this is generally accepted as OK. I wonder whether the aliasing and other artifacts of cheap linear scaling are as acceptable for HDR. See http://forum.doom9.org/showthread.php?t=172094

[Maystone]

Apologies if this is a derail but I've attempted to read and re-read this thread many times and am pretty sure this hasn't come up, but why not encode all in ffmpeg? Would it have something to do with the current convo on the shortcomings of ffmpeg and colorspace? Can someone tell me why the below command would not work to produce exactly what the OP wanted? (and yeah first post, ahem)

Input= 16bit 4k HDR10 graded tiffs in rec.2020

ffmpeg -threads 16 -r 24000/1001 -start_number 0085069 -i 'hdr10_targ5_test_3.%07d.tiff' \\
-vf scale=out_color_matrix=bt2020:out_h_chr_pos=0:out_v_chr_pos=0,format=yuv420p10 -c:v libx265 -preset medium \\
-x265-params crf=12:colorprim=bt2020:transfer=smpte-st-2084:colormatrix=bt2020nc:master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)":max-cll="1000,400" -an /output/test.mp4

OUTPUT:
ffmpeg version N-81451-g8a78fc5 Copyright (c) 2000-2016 the FFmpeg developers
built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04.3)
configuration: --enable-libopenjpeg --prefix=/home/CORP/someone/ffmpeg_build \\
--pkg-config-flags=--static --extra-cflags=-I/home/CORP/someone/ffmpeg_build/include \\
--extra-ldflags=-L/home/CORP/someone/ffmpeg_build/lib --bindir=/home/CORP/someone/bin --enable-gpl --disable-libass \\
--enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libvpx \\
--enable-libx264 --enable-libx265 --enable-nonfree
libavutil 55. 29.100 / 55. 29.100
libavcodec 57. 54.100 / 57. 54.100
libavformat 57. 48.100 / 57. 48.100
libavdevice 57. 0.102 / 57. 0.102
libavfilter 6. 54.100 / 6. 54.100
libswscale 4. 1.100 / 4. 1.100
libswresample 2. 1.100 / 2. 1.100
libpostproc 54. 0.100 / 54. 0.100
Input #0, image2, from 'hdr10_targ5_test.%07d.tiff':
Duration: 00:00:01.96, start: 0.000000, bitrate: N/A
Stream #0:0: Video: tiff, rgb48le, 3840x2160, 25 tbr, 25 tbn, 25 tbc
x265 [info]: HEVC encoder version 2.0+16-215eedc9ecc0
x265 [info]: build info [Linux][GCC 4.8.4][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main 10 profile, Level-5 (Main tier)
x265 [info]: Thread pool created using 24 threads
x265 [info]: frame threads / pool features : 5 / wpp(34 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 23 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-12.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 rskip signhide tmvp strong-intra-smoothing
x265 [info]: tools: lslices=8 deblock sao
[mp4 @ 0x3239340] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
Output #0, mp4, to 'test.mp4':
Metadata:
encoder : Lavf57.48.100
Stream #0:0: Video: hevc (libx265) ([35][0][0][0] / 0x0023), yuv420p10le, 3840x2160, q=2-31, 23.98 fps, 24k tbn, 23.98 tbc
Metadata:
encoder : Lavc57.54.100 libx265
Stream mapping:
Stream #0:0 -> #0:0 (tiff (native) -> hevc (libx265))
Press [q] to stop, [?] for help
frame= 49 fps=1.0 q=-0.0 Lsize= 9831kB time=00:00:01.91 bitrate=41977.1kbits/s speed=0.0391x
video:9829kB audio:0kB subtitle:0kB other streams:0kB global headers:1kB muxing overhead: 0.025485%
x265 [info]: frame I: 1, Avg QP:9.14 kb/s: 96922.02
x265 [info]: frame P: 10, Avg QP:9.70 kb/s: 67176.81
x265 [info]: frame B: 38, Avg QP:13.07 kb/s: 30572.90
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 9.1% 0.0% 0.0% 18.2% 72.7%

encoded 49 frames in 49.61s (0.99 fps), 39397.15 kb/s, Avg QP:12.30