Which format for HDR10 deliverables?

Plays good, triggers HDR flag.

2 steps I could live with, but separate elementary streams mean many more steps actually:

- exporting video from Resolve
- exporting audio from Resolve
- encoding .hevc
- encoding AAC
- muxing to h.265



Piotr

Use this with ffmpeg from my link:

-pix_fmt yuv420p10le -c:v libx265 -preset fast -b:v 50M -x265-params keyint=60:bframes=3:vbv-bufsize=75000:vbv-maxrate=75000:colorprim=bt2020:transfer=smpte-st-2084:colormatrix=bt2020nc:master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,500)" -c:a aac -b:a 192K "output.ts"

and it may work so you may forget about piping.

Works great, Andrew - thank you so much!


Piotr

PS. The "older" ffmpeg build from your download link doesn't support DNxHR which is my format of choice when exporting from Resole, as I can use my cached files (I don't cache to Uncompressed 16bit half-float HDR as even my M.2 drive is too slow and small for that). However, those DNxHR444 cache files are not lossless, so - from the point of view of the highest quality of the final HEVC delivery - perhaps I should export to Uncompressed YUV, anyway - even if that means the cached files cannot be used, and exports will take longer. What do you think?

Few options:
- find latest ffmpeg with 10bit x265
- export to Cineform YUV to save space. You are compressing to 50Mbit, so uncompressed, DNxHR or Cineform makes no difference at all for the final quality. You can use "Use cache for render" which will mean you are converting DNxHR to Cineform which should be fast.
- use this:

ffmpeg_latest -i "DNxHR_source" -pix_fmt yuv420p10le -strict -1 -f yuv4mpegpipe - | ffmpeg_old -i - -vn -i "DNxHR_source" -map 0:0:0:0 -map 1:1:0:1 -pix_fmt yuv420p10le -c:v libx265 -preset fast -b:v 50M -x265-params keyint=60:bframes=3:vbv-bufsize=75000:vbv-maxrate=75000:colorprim=bt2020:transfer=smpte-st-2084:colormatrix=bt2020nc:master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,500)" -c:a aac -b:a 192K -y "out.ts"

You put DNxHR source path in two places assuming it has audio in it ( it will take 1st track).
It uses new ffmpeg to decode DNxHR, pipes yuv data to 2nd instance of ffmpeg, which is the one from my link with x265 10bit support.

Great idea - thanks again

You're also right about the final bitrate making the preceding re-compression irrelevant...

Piotr

Questions:

1. how to get the best of both, i.e. HDR-triggering 10bit h.265 files?

Andrew - with your last proposed, "piping" syntax, you have just made my above wish come true.
Thanks 1000 times

Piotr

Hi Piotr,

Can you share information extracted from mediainfo from your clip HDR?

Somebody called?

Hi Piotr,

Can you share information extracted from mediainfo from your clip HDR?

Color primaries : BT.2020
Transfer characteristics : SMPTE ST 2084
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0500 cd/m2, max: 1000.0000 cd/m2

Exactly the same what you put into command, just made more user friendly to read (divided by some number). Nothing more than P3D65 values.
This is also what Samsung uses in their demo clips.

Thank's

and for Chroma subsampling and Bit depth ?

10bit, 4:2:0.

Thank's

Hi Piotr,

Can you share information extracted from mediainfo from your clip HDR?

Jean-Claude,

Andrew has answered your request much better than I could have - he's the author of the success. I'm really happy how gorgeously those HDR clips - in spite of their very limited bitrate - play back on my Samsung SUHD.

Must say my opinion about this TV is even higher now (and about the HEVC compression quality, as well).

Piotr

PS. Here is the MediaInfo report from one of the HEVC clips.

Code: Select all

General
ID                                       : 1 (0x1)
Complete name                            : D:\My Documents\MoldCAD\camera\encoding HDR H.265 deliverables\ffmpeg OK\garden.ts
Format                                   : MPEG-TS
File size                                : 2.40 GiB
Duration                                 : 6 min 27 s
Overall bit rate mode                    : Variable
Overall bit rate                         : 53.3 Mb/s

Video
ID                                       : 256 (0x100)
Menu ID                                  : 1 (0x1)
Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Format profile                           : Main 10@L5.1@High
Codec ID                                 : 36
Duration                                 : 6 min 27 s
Width                                    : 3 840 pixels
Height                                   : 2 160 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 50.000 FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 10 bits
Writing library                          : x265 1.9+226-6561d8676581:[Windows][GCC 5.3.0][64 bit] 10bit
Encoding settings                        : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=1 / subme=2 / merange=57 / no-rect / no-amp / max-merge=2 / temporal-mvp / no-early-skip / rskip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=60 / min-keyint=6 / scenecut=40 / rc-lookahead=15 / lookahead-slices=8 / bframes=3 / bframe-bias=0 / b-adapt=0 / ref=3 / limit-refs=3 / no-limit-modes / weightp / no-weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=2 / psy-rd=2.00 / rdoq-level=0 / psy-rdoq=0.00 / no-rd-refine / signhide / deblock=0:0 / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=abr / bitrate=50000 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / vbv-maxrate=75000 / vbv-bufsize=75000 / ipratio=1.40 / pbratio=1.30
Color range                              : Limited
Color primaries                          : BT.2020
Transfer characteristics                 : SMPTE ST 2084
Matrix coefficients                      : BT.2020 non-constant
Mastering display color primaries        : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance              : min: 0.0500 cd/m2, max: 1000.0000 cd/m2

Audio
ID                                       : 257 (0x101)
Menu ID                                  : 1 (0x1)
Format                                   : AAC
Format/Info                              : Advanced Audio Codec
Format version                           : Version 4
Format profile                           : LC
Muxing mode                              : ADTS
Codec ID                                 : 15
Duration                                 : 6 min 27 s
Bit rate mode                            : Variable
Channel(s)                               : 2 channels
Channel positions                        : Front: L R
Sampling rate                            : 48.0 kHz
Frame rate                               : 46.875 FPS (1024 spf)
Compression mode                         : Lossy
Delay relative to video                  : -21 ms
Language                                 : English

Menu
ID                                       : 4096 (0x1000)
Menu ID                                  : 1 (0x1)
Duration                                 : 6 min 27 s
List                                     : 256 (0x100) (HEVC) / 257 (0x101) (AAC, English)
Language                                 :  / English
Service name                             : Service01
Service provider                         : FFmpeg
Service type                             : digital television


Manual says that 80Mbit is the max for supported bitrate, but I think 100Mbit will also work. 80mbit probably 100% guaranteed to to smooth playback, this is probably there is some headroom also, same as e.g. with BD players.

You can adjust bitrate by changing from -b:v 50M, to e.g. 75M for 75mbits average bitrate.
You should also change vbv-bufsize=75000:vbv-maxrate=75000 both from 75000 to 100000 to never exceed maximum peaks above 100Mbits.
You can also change preset from fast preset to medium or slow but speed will be lower, but quality will be slightly better.
Once madVR gets HDR metadata over HDMI will be much better and you will be able to play e.g. DNxHR or any other format.
TV internal playback still offers quite good quality, about the same capabilities what UHD BD disc offers (assuming you have nice source and encode it well).

The 75Mbps max (or 50+ Mbps average) bitrate proves to be the sweet spot for casting HEVC to my Samsung, considering I only have 100Mbps Enthernet on my router (This is on the PC end; the TV is connected via N wi-fi, so a bit more headroom there). I'm planning to lower the VESA bracket on the wall behind my desk, so the TV goes lower and is more ergonomic to watch; when the TV is off the wall I'm going to use this opportunity and connect an 1G Ethernet cable (the socket is at the back of the set, unlike all other inputs which are on the "One Connect" break-out box, easily accessible on my desk). Next step will be replacing the router with a 1Gbit one; this way my PC and TV will be connected in the best possible way.

But as Andrew says - documentation states 80 Mbps as the limit, with 100 Mbps working but not guaranteed (for casting with my current LAN speed even this is too high for fluent playback, but I tried 100 Mbps clips from USB HDD and they played back perfectly). So only when I have 1G LAN connection, will I be ready for either casting or playing from USB HDD - great for testing my HEVC deliverables and only copying them to my external USB drive when they are ready.

BTW, when I first saw the outdated USB 2.0 port and read the specs of my Samsung, I thought "what a crappy example of bad design; how can an UHD Premium TV be limited like this?". BUT - after seeing how efficient HEVC can be for the first time last night - I realized this is all very well designed, actually! To those who never saw their UHD (even 50 fps HDR ones) movies played back this way, I can swear the quality is visually indistinguishable from how they look in Resolve projects via Decklink! Well - perhaps with the only difference in chroma sub-sampling; e.g. on saturated color (like red flower close-ups), I can clearly see those darker, horizontal jaggies reminding me it's just 4:2:0. But other than that - the color space and gamma translation from my Resolve project settings of Rec. 2020 / ST. 2084 is perfect.

Finally, the HDR aspect: even though the peak luminance for Samsung SUHD KS-series is rated 1,000 nits, they claim local brightness of smaller areas can go as high as 1,500 nits. Actually this is how I grade in Resolve: generally never exceeding 1,000 nits, I allow super-brights (like direct light sources, specular highlights and alike) to surpass that and reach 1,500 nits. My next experiments - apart from increasing bitrate like Andrew described - will be defining higher levels for Mastering Display Luminance for my ffmpeg encoding. One thing I'm not certain though - is the current "min: 0.0500 cd/m2, max: 1000.0000 cd/m2" value actually clipping anything above 1,000 (i.e. including those few, limited area peaks of up to 1,500 nits), or does it merely define the overall brightness of the entire screen? Is there any additional argument to the Mastering Display part of ffmpeg/x265 command line, actually defining how high those peaks can go?

Piotr

Piotr,


I think you should read the excellent article by Alexis Van Hurkman

http://vanhurkman.com/wordpress/?p=3548

...safe from the ravages of ABL

(Update) In fact, I had just published this article when I had to run over to Best Buy to purchase a video game for a friend who I’ve decided is entirely too productive with their time. While I was there, I had a look at the televisions, and in the course of chatting about all of this (because I can’t stop), associate Mason Marshall pointed out a chart at rtings.com that does the kind of test chart evaluation I mention previously to investigate the peak luminance performance of different displays as they output different percentages of maximum white. The results are, ahem, illuminating. For example, while the Samsung KS9500 outputs a startling 1412 nits when 2% of the picture is at maximum white, peak luminance drops to 924 nits with 25% of the picture at maximum white, and it drops further down to 617 nits with 50 percent of the picture at maximum white. Results of different displays vary widely, so check out their chart. Now, this simple kind of Loading Pattern test isn’t going to account for all the variables that a display’s ABL contends with, but it does show the core principal in action of which colorists need to beware.

Dire as all this may sound, don’t be discouraged. Keep in mind that, at least for now, HDR-strength highlights are meant to be flavoring, not the base of the image. My experience so far has been if you’re judicious with your use of very-bright HDR-strength highlights, you’ll probably be relatively safe from the ravages of ABL, at least so far as the average consumer is concerned. Hopefully as technology improves and brighter output is possible with more efficient energy consumption, these issues will become less of a consideration. For now, however, they are.

and

http://www.rtings.com/tv/tests/picture- ... brightness
Peak Brightness of TVs
Max luminosity and HDR highlights

And
Davinci resolve manual => HDR => EXR.

For example, while the Samsung KS9500 outputs a startling 1412 nits when 2% of the picture is at maximum white, peak luminance drops to 924 nits with 25% of the picture at maximum white, and it drops further down to 617 nits with 50 percent of the picture at maximum white.

Thanks for all the interesting reading, Jean-Claude! Regarding the fragment you posted, it actually is pretty consistent with my own observations. I saw comparisons of KS8000 with KS9500 indicating that - with the screen sizes of 49" vs. 65" respectively - my model might have a little edge here.

Now back to the reading

Piotr

PS. Just some first observations from the first article:

- a large portion about grading for Dolby Vision, HLG and HDR10 is the same text we can find in the Resolve Manual (not a surprise, actually )

- both the Manual and the above mentioned, technical part of this great article stress that in order to retain the peak brightness for HDR master, it's essential to render in "special" formats (in cache-render settings of the Project those with "HDR" suffix). So again Walter - caching to Uncompressed 10bit is not enough - it must be Uncompressed 16bit (half-float) HDR... Or - in the case of compressed formats - DNxHR HQX HDR, as in my case. Obviously, the same stays valid for rendering on export; it must be TIFF, RGB 16-bit or EXR, RBG-half (no compression), or - again in my case - DNxHR HQX 444. Also Andrew - in the light of the above, don't you think that for my deliverables - while my favorite DNxHR 444 format is OK (compressed, but as intended to be dramatically compressed further to HEVC - good enough) - if I were to render my HEVC from uncompressed Resolve exports, your proposed 10-bit Uncompressed YUV is not enough, and EXR (RGB-half) sequence should be used?

- probably the most important recommendation is this:

"It cannot be over-emphasized that HDR grading is not about making everything brighter. Never minding the limitations imposed by the ABL on consumer televisions, just making everything brighter is like doing a music mix where you simply make everything louder. You’re not really taking advantage of the ability to emphasize specific musical details via increased dynamic range, you’re just making individual details harder to hear among all the increased energy bombarding the audience. Maintaining contrast is the key to taking the best advantage of HDR-strength highlights, which will lack punch if you boost all of your midtones too much and neglect the importance and depth of your shadows. HDR images only really look like HDR images when you’re judicious with your highlights."

The conclusion is that even if a typical, consumer HDR display of today - even rated at "just" 1,000 nits - can only output the advertised brightness on small percentage of its screen area, and for a limited time only, it is not a problem at all with proper HDR grading...

Also interesting (and frankly, flattering to myself:)) I found the second article J-C linked to. Here is a table with max brightness of various screen percentages for both sustained and peak luminance; I limited it to only the 49-50" inches TVs as in an editing suite (especially a single-person one), anything larger is impractical (standing on the desktop or hung on the wall just 1.5m from the colorist face). As can bee seen, the Samsung SUHD 40"KS8500 is the best, closely followed by the 49"KS8000 (the model I'm using in my HDR grading).

peak brightness of HDR 49-50 TVs.JPG (133.38 KiB) Viewed 17779 times

I'm very happy I made several right choices (and highly recommend the same to all "amateour HDR colorists"):

- waiting for the 2016 models to arrive; I was tempted by the 2015's "JS" series but even though Samsung was already advertising their JS line as "HDR-ready", clearly their peak luminance was lower than with true "UHD Premium TV"-compliant KS series of 2016

- one could argue that the (more expensive) KS8500 is even better; yes - as far as the max luminance it is, but this is a curved TV and as such not really fit for tight studio environment (especially hanging on the wall and tilted down towards the operator face, like in my case).

Let me repeat my question from a couple of posts back: when rendering in ffmpeg/x265, is it safe to increase the peak value in the Mastering Display Luminance parameter? I'd say it is, as ABL is active on those TVs (I actually can see it in action - when I pause the playback with a very large bright area in the frame, the Samsung will gradually dim down). So it should be safe for the TV itself - but will it help those 2-20% areas achieve say 1,400 nits rather than currently hard-coded 1,000 nits? Sure - you can answer "why don't you just try" - but before I do, I'd like to know some more details on adopting the values for this parameter, as Andrew said the 1,000 nits max being recommended for the KS8000...

Piotr

I don't know what is recommended, but Samsung demo clips use 1000. I've read somewhere (don't know now where) that anything brighter than set here will be clipped. Try with some special test file so you can see difference. Just check what is this 1000 multiplied by for x265 headers to set correct value.

Few options:
- find latest ffmpeg with 10bit x265
- export to Cineform YUV to save space. You are compressing to 50Mbit, so uncompressed, DNxHR or Cineform makes no difference at all for the final quality. You can use "Use cache for render" which will mean you are converting DNxHR to Cineform which should be fast.
- use this:

ffmpeg_latest -i "DNxHR_source" -pix_fmt yuv420p10le -strict -1 -f yuv4mpegpipe - | ffmpeg_old -i - -vn -i "DNxHR_source" -map 0:0:0:0 -map 1:1:0:1 -pix_fmt yuv420p10le -c:v libx265 -preset fast -b:v 50M -x265-params keyint=60:bframes=3:vbv-bufsize=75000:vbv-maxrate=75000:colorprim=bt2020:transfer=smpte-st-2084:colormatrix=bt2020nc:master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,500)" -c:a aac -b:a 192K -y "out.ts"

You put DNxHR source path in two places assuming it has audio in it ( it will take 1st track).
It uses new ffmpeg to decode DNxHR, pipes yuv data to 2nd instance of ffmpeg, which is the one from my link with x265 10bit support.

This can be simplified a bit, so source file is specified only once (assuming it has vide+audio- well if there is no audio it won't be in final file):

ffmpeg_latest -i "DNxHR_source" -pix_fmt yuv420p10le -c:v rawvideo -c:a pcm_s24le -f nut - | ffmpeg_old -i - -c:v libx265 -preset fast -b:v 50M -x265-params keyint=60:bframes=3:vbv-bufsize=75000:vbv-maxrate=75000:colorprim=bt2020:transfer=smpte-st-2084:colormatrix=bt2020nc:master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,500)" -c:a aac -b:a 192K -y "out.ts"

Poitr,

I think now you're the conductor. You have the video sources, you Davinci Resolve grading knows HDR and it is you who has the TV HDR.

Your turn your partition (I have no TV HDR: sorry). But I am tempted to go up to 1000 nits if necessary. Otherwise as in music:
- Adagio the lowest possible
- Aumentando test ~500-768 nits ?
- Altissimo ~ 1000 nits (limit 2%)

After that it should maybe play on the contrast / luma / color? as a "colorist"

This can be simplified a bit, so source file is specified only once (assuming it has vide+audio- well if there is no audio it won't be in final file):

ffmpeg_latest -i "DNxHR_source" -pix_fmt yuv420p10le -c:v rawvideo -c:a pcm_s24le -f nut - | ffmpeg_old -i - -c:v libx265 -preset fast -b:v 50M -x265-params keyint=60:bframes=3:vbv-bufsize=75000:vbv-maxrate=75000:colorprim=bt2020:transfer=smpte-st-2084:colormatrix=bt2020nc:master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,500)" -c:a aac -b:a 192K -y "out.ts"

Dear Andrew,

The above, simplified syntax also works like a charm. But I'd like to try encoding an EXR sequence, so of course my export audio separtely. Questions:

- is WAV the best format to export audio from Resolve?
- is it possible to modify the above syntax to keep it as concise as possible, and still do audio stream and muxing in one go - or are separate ffmpeg runs necessary to encode AAC and mux the two streams?

Thanks,

Piotr

This can be simplified a bit, so source file is specified only once (assuming it has vide+audio- well if there is no audio it won't be in final file):

ffmpeg_latest -i "DNxHR_source" -pix_fmt yuv420p10le -c:v rawvideo -c:a pcm_s24le -f nut - | ffmpeg_old -i - -c:v libx265 -preset fast -b:v 50M -x265-params keyint=60:bframes=3:vbv-bufsize=75000:vbv-maxrate=75000:colorprim=bt2020:transfer=smpte-st-2084:colormatrix=bt2020nc:master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,500)" -c:a aac -b:a 192K -y "out.ts"

Dear Andrew,

The above, simplified syntax also works like a charm. But I'd like to try encoding an EXR sequence, so of course my export audio separtely. Questions:

- is WAV the best format to export audio from Resolve?
- is it possible to modify the above syntax to keep it as concise as possible, and still do audio stream and muxing in one go - or are separate ffmpeg runs necessary to encode AAC and mux the two streams?

Thanks,

Piotr

Don't use EXR's as this will force RGB->YUV conversion which is questionable (it has to go over Rec.2020).
Stay with YUV based format as a source. Is it that slow to export Cineform or DNxHR in case you work with EXRs as cache? I don't think so, just use cached files as a source for the render.

btw...
there is new king on the HDR arena: http://www.hdtvtest.co.uk/news/kd65zd9-201610164372.htm

For those interested.

Latest zeranoe ffmepg builds for Windows come with 8 and 10bit x264 and x265, so not need to look for them anymore or compile yourself.

https://ffmpeg.zeranoe.com/builds/

you just add -pix_fmt yuv420p10le to get 10bit x264/x265.

For those interested.

Latest zeranoe ffmepg builds for Windows come with 8 and 10bit x264 and x265, so not need to look for them anymore or compile yourself.

https://ffmpeg.zeranoe.com/builds/

you just add -pix_fmt yuv420p10le to get 10bit x264/x265.

So for x264 both the 8 and 10 bit library are linked?
Before that was not possible, but if he got that done then that's cool!

For 10 bit I usually pipe the ffmpeg output to x264 10 bit using yuv4mpegpipe but if both 8 and 10 bit are linked then that is a simpler solution.

Yes, it has been changed and now it's supported in ffmpeg also. No need for double compile and executables anymore. Same for x265 and zeranoe builds come with both.

Andrew,

transfer=smpte-st-2084

returns an error with this build (from libx265); has the syntax changed?

Thanks

Piotr

There was some naming change in x265 for st-2084.
It's smpte2084 now.

Thanks Andrzej - now this parameter is accepted, but stilll the output file is 0 byets and ffmpeg stops working. What can be wrong with this syntax:

.\bin\ffmpeg -i "input.mxf" -pix_fmt yuv420p10le -c:v libx265 -preset fast -b:v 50M -x265-params keyint=60:bframes=3:vbv-bufsize=75000:vbv-maxrate=75000:colorprim=bt2020:transfer=smpte2084:colormatrix=bt2020nc:master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,500)" -c:a aac -b:a 192K -y "out.ts"

This is latest ffmpeg build issue I think.
Try downloading some bit older build. You also may want to add new command for hdr optimization:
hdr-opt=1 in x265-params section.

Hmm... the only warning spit in yellow is this:

Stream #0: not enough frames to estimate rate; consider increasing probesize
Guessed Channel Layout for Input Stream #0.1 : mono

Could be the reason? What's the work-around?

Thanks, Andrzej

PS. I'm trying to use this build as - if I understand correctly - its x265 handles 10 bit correctly.

No, there is some build issue. Try bit older build.

The previous build works - thanks Andrew.

Piotr

This is latest ffmpeg build issue I think.
Try downloading some bit older build. You also may want to add new command for hdr optimization:
hdr-opt=1 in x265-params section.

Tried the same (short but very "HDR10-representative") clip with and without the new parameter :hdr-opt=1: in x265-params section. Couldn't see any difference in the output - what is is supposed to do?

Piotr

PS. Oh, and Andrzej - while we're at it - let me ask you the question I was about to for quite some time now: for a person like myself (deeply specialized in something totally different than newer and better implementations of a command-line driven applications like ffmpeg) - is using some UI-based programs like Hybrid the way to go? When I was younger, and my main professionally used CAE system (Moldflow) was still at its infancy over 30 years ago, I was able to use it efficiently using a command line, too! But those days (both for Moldflow and myself are now long gone)... Per analogy, would yo advise a person in my situation to spend a lot of my precious time learning the plethora of ffmpeg command line syntax and options, or is Hybrid a much better solution? Or perhaps you could recommend something better than Hybrid? TIA for sharing your thoughts

Add luma and chroma offsets for HDR/WCG content. Input video should be 10 bit 4:2:0. Applicable for HDR content. It is recommended that AQ-mode be enabled along with this feature. Default disabled.

You not necessarily going to see it easily.

Read this:

http://x265.readthedocs.io/en/default/cli.html

and you won't have to ask.

... Per analogy, would yo advise a person in my situation to spend a lot of my precious time learning the plethora of ffmpeg command line syntax and options, or is Hybrid a much better solution? Or perhaps you could recommend something better than Hybrid? TIA for sharing your thoughts

Hybrid or Handbrake uses exactly the same libraries as ffmpeg, so quality is the same (for the same setting and about the same library version).
It doesn't matter what you learn- do what is easier to you. ffmpeg offers more possibilities, where GUI tools are easier and nicer to use (specially when you do repeated things and rather standard ones). They never expose all ffmpeg possibilities though, but you most likely won't need them.
In your case I would stick with some GUI- you still have to understand x264/5 parameters regardless it's ffmpeg or Hybrid etc. though.

Thanks Andrew, 10 bit works.

Piotr are you using the ts file for streaming?
I personally prefer to render H.264 in an mkv container and use mkvmerge utility to set the meta data and attach a custom fallback LUT.

Piotr,

Test with the ffmpeg-20180209-e752da5-win64-static version
The most recent seem to not know too much to encode in 10 bits (unless I'm wrong) with x265

In latest build x265 10bit is broken. You need earlier one or wait for next daily build.

... Per analogy, would yo advise a person in my situation to spend a lot of my precious time learning the plethora of ffmpeg command line syntax and options, or is Hybrid a much better solution? Or perhaps you could recommend something better than Hybrid? TIA for sharing your thoughts

Hybrid or Handbrake uses exactly the same libraries as ffmpeg, so quality is the same (for the same setting and about the same library version).
It doesn't matter what you learn- do what is easier to you. ffmpeg offers more possibilities, where GUI tools are easier and nicer to use (specially when you do repeated things and rather standard ones). They never expose all ffmpeg possibilities though, but you most likely won't need them.
In your case I would stick with some GUI- you still have to understand x264/5 parameters regardless it's ffmpeg or Hybrid etc. though.

Thanks Andrzej; well - as you say: adopting a GUI isn't going to relieve me from the necessity to understand the meaning of x265 parameters. And I do have my first problem in this area, using the ffmpeg build you linked us to. Basically - with a clip (graded to HDR10) and looking great in Resolve, after I export it in DHxHR 444 in the .mov wrapper and apply the syntax I posted in one of my previous posts in this thread - what I'm getting is a proper 10bit HEVC clip but looking dramatically different, mainly due to vastly over-saturated colors...

So far, when encoding my h.265 final shorts, I've been using some older ffmpeg builds you provided links to at the very start of this old thread, back in the times when I was only beginning my PQ-grading. You probably remember how you helped me use two different ffmpeg builds - one for its DNxHR handling ability (which was new at that time), and piping through to another one with 10-bit hevc support libx265 (which was then an even greater rarity). Even though using 2 ffmpeg builds and the "piping" command syntax was not the most elegant way of encoding my final HEVC files, I stuck to that workflow because of the outstanding fidelity of levels and colors to those of my HDR10 grades when played back from within Resolve... Nevertheless, I was waiting for a new single ffmpeg build which could do both - and the present one from zeranoe has been promising in this regard...

Unfortunately, the colors (and levels as well, to a lesser degree) differ so much from my Resolve exports that before I find the reason, this build is unusable for my purposes. And speaking of the potential reasons for said discrepancy: where do I start to pin-point them?

Piotr

PS, Frankly, I'm not even sure it's the xlib265 encoding which is at fault here as - when I load a h.265 clip back into Resolve - it looks different from how it looks when cast to my Samsung (properly triggering HDR mode), but also from my original grade (before exporting); to make things more complicated the colors are less saturated, and the brightness - lower, than they were in my grade before export

DNxHR444 can be the problem. Ffmpeg may read it as full range.
Use DNxHR HQX or 10bit uncompressed YUV.
If Tv shows it oversaturated maybe it thinks it's Rec.709. Check with mediainfo if headers are correct.
When you import hevc back to Resolve do you manually interpret as Rec.2020 st-2084?

Piping is clever way and has no side effects, but current x265 build should be better.

I tried exporting 10bit uncompressed YUV, with exactly the same results. Here is the mediainfo:

Code: Select all

General
ID                                       : 1 (0x1)
Complete name                            : D:\My Documents\MoldCAD\camera\encoding HDR H.265 deliverables\ffmpeg-20180209-e752da5-win64-static\cineform-hevc.ts
Format                                   : MPEG-TS
File size                                : 42.9 MiB
Duration                                 : 6 s 720 ms
Overall bit rate mode                    : Variable
Overall bit rate                         : 52.4 Mb/s

Video
ID                                       : 256 (0x100)
Menu ID                                  : 1 (0x1)
Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Format profile                           : Main 10@L5@High
Codec ID                                 : 36
Duration                                 : 6 s 760 ms
Width                                    : 3 840 pixels
Height                                   : 2 160 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 25.000 FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 10 bits
Writing library                          : x265 2.6+37-1949157705ce:[Windows][GCC 7.2.0][64 bit] 10bit
Encoding settings                        : cpuid=1173503 / frame-threads=4 / numa-pools=16 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x2160 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=6 / keyint=60 / gop-lookahead=0 / bframes=3 / b-adapt=0 / b-pyramid / bframe-bias=0 / rc-lookahead=15 / lookahead-slices=8 / scenecut=40 / radl=0 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=2 / no-early-skip / rskip / fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=abr / bitrate=50000 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=75000 / vbv-bufsize=75000 / vbv-init=0.9 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=9 / transfer=16 / colormatrix=9 / chromaloc=0 / display-window=0 / master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,500) / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / hdr / no-hdr-opt / no-dhdr10-opt / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-mv-type=0 / copy-pic=1
Color range                              : Limited
Color primaries                          : BT.2020
Transfer characteristics                 : PQ
Matrix coefficients                      : BT.2020 non-constant
Mastering display color primaries        : Display P3
Mastering display luminance              : min: 0.0500 cd/m2, max: 1000 cd/m2

Audio
ID                                       : 257 (0x101)
Menu ID                                  : 1 (0x1)
Format                                   : AAC
Format/Info                              : Advanced Audio Codec
Format version                           : Version 4
Format profile                           : LC
Muxing mode                              : ADTS
Codec ID                                 : 15
Duration                                 : 6 s 656 ms
Bit rate mode                            : Variable
Channel(s)                               : 2 channels
Channel positions                        : Front: L R
Sampling rate                            : 48.0 kHz
Frame rate                               : 46.875 FPS (1024 SPF)
Compression mode                         : Lossy
Delay relative to video                  : -21 ms

Menu
ID                                       : 4096 (0x1000)
Menu ID                                  : 1 (0x1)
Duration                                 : 6 s 720 ms
List                                     : 256 (0x100) (HEVC) / 257 (0x101) (AAC)
Service name                             : Service01
Service provider                         : FFmpeg
Service type                             : digital television


Looks fine.
How this compares to older export visually?
What if you bring both encodes to Resolve (interpreted as HDR or even not) and compare them? They should look the same.

Is this: Mastering display color primaries : Display P3
a new media info feature? (instead do of showing precise coordinates). Does mediainfo report it the same for old encode?
When you garden Resolve do you use Rec.2020 or P3 gamut?
Maybe you need mastering display values for Rec.2020 coordinates, no P3 (which will then let TV go to its limits). Maybe with old encode this mastering info was never actually read properly.

Try removing mastering display option from command.

I always use Rec.2020/ST.2084 on output in my RCM projects.

You might be right - I always wondered why did we input P3 coordinates and not those for 2020... Where to get them from in order to do some testing, do you know?

Piotr


PS. On the other hand, when - for the sake of testing - I changed 2020 for P3 DCI or P3 D65 (my TV covers 96% of that space), the difference in colors where far from as dramatic as with these HEVC files...

Looks fine.
How this compares to older export visually?
What if you bring both encodes to Resolve (interpreted as HDR or even not) and compare them? They should look the same.

They don't. obviously...

Try removing mastering display option from command.

Tried that; no difference at all! The whole master-display isn't used at all

Piotr

Looks fine.
How this compares to older export visually?
What if you bring both encodes to Resolve (interpreted as HDR or even not) and compare them? They should look the same.

They don't. obviously...

Impossible. It's YUV to YUV data without any conversion except compression, so they have to match.
If they don't match it means something is very broken in new ffmpeg.

Load both to Resolve, interpret manually to same color space and put one over another.
Fact that they don't look the sam on Tv is not a proof in this case. To much "other" processing is happening. I'm interested in "pure" YUV values, before any metadata and processing is added on top of this.

I always use Rec.2020/ST.2084 on output in my RCM projects.

You might be right - I always wondered why did we input P3 coordinates and not those for 2020... Where to get them from in order to do some testing, do you know?

Piotr


PS. On the other hand, when - for the sake of testing - I changed 2020 for P3 DCI or P3 D65 (my TV covers 96% of that space), the difference in colors where far from as dramatic as with these HEVC files...

Well- if you use REc.2020 then it will look good only on your TV as you actually grading not to any standard but to your TV (e.g. 96% of P3). If you would be grading to P3 at the end it would give same result (as your TV can't even display this), but technically it would be more correct. In this case TV would have to be set to "expect" P3 and display master setting are added for this purpose. TV should read them, but this seems to bee not the case. It may depend on TV- maybe some read them, maybe some only on HDMI (not from file headers). Ask Samsung This could also explain why you have some mismatch between file preview and HDMI feed from Resolve.

Example for a P3D65 1000-nits monitor, where G(x=0.265, y=0.690), B(x=0.150, y=0.060), R(x=0.680, y=0.320), WP(x=0.3127, y=0.3290), L(max=1000, min=0.0001):

G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)


you have to find on the web Rec.2020 coordinates and then multiply them by 50000.
WP is white point for Rec.2020

L is multiplied by 10000 and depends on your TV capabilities/grading settings (max peak and black level).

Looks fine.
How this compares to older export visually?
What if you bring both encodes to Resolve (interpreted as HDR or even not) and compare them? They should look the same.

They don't. obviously...

Impossible. It's YUV to YUV data without any conversion except compression, so they have to match.
If they don't match it means something is very broken in new ffmpeg.

Load both to Resolve, interpret manually to same color space and put one over another.
Fact that they don't look the sam on Tv is not a proof in this case. To much "other" processing is happening. I'm interested in "pure" YUV values, before any metadata and processing is added on top of this.

Andrew - if you say "impossible" it might mean I didn't get your original question correctly; this is how I understand your question in other wording:

"Older export": I took it you're talking about my older deliverables, i.e. those exported from Resolve in exactly the same way I'm using now, but encoded to HEVC using the "older" ffmpeg builds (the ones I used piping with). As those look perfect (100% the same as my grades before exporting them from Resolve) - and the "new ones" (encoded with the current ffmpeg build) look sick - why are you saying they shouldn't differ when loaded back to Resolve?

Perhaps you mean comparing the exports - not the hevc encodes? Those indeed look the same (why shouldn't they - I didn't change main settings of my Resolve projects). So did I in fact misunderstand you?

Example for a P3D65 1000-nits monitor, where G(x=0.265, y=0.690), B(x=0.150, y=0.060), R(x=0.680, y=0.320), WP(x=0.3127, y=0.3290), L(max=1000, min=0.0001):

G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)


you have to find on the web Rec.2020 coordinates and then multiply them by 50000.
WP is white point for Rec.2020

L is multiplied by 10000 and depends on your TV capabilities/grading settings (max peak and black level).

I will try using the data provided (thanks for them) - but I'm skeptical, as removing the entire "master-display" group didn't change a thing in those sick colors. Meaning the group isn't considered at all by the current ffmpeg xlib265 encoder, no?

Piotr