Waiting for the HDR10 switch in HEVC export to work...

You can't use bsf filter for this (not supported yet). You need to add it during main encode.
I used x265 binaries, not ffmpeg. Not sure if official ffmpe has been compiled with hdr10+ option. You need special setting during compile to have it included.
With x265 you just simply add --dhdr10-info and point to json file.

--dhdr10-info seems to be included in the ffmpeg builds and probably has been for a while, it's been in x265 since version 2.4.

Anyway, try this (it works if your syntax is perfect):

ffmpeg -i input -c:v libx265 -x265-params --transfer=16:--dhdr10-info=timeline.json:--fps=59.94:--input-csp=2: -b:v 15000k output

syntax is very picky, spaces and no spaces, caps and lower case, colons all critical!! So I've added a few extra x265 parameters for examples and clarity. I'm not an authority on this, but it's difficult enough with these command line compilers to not have to be stacking them to get your audio and other features muxed together. They all have similar syntax structures but just different enough to cause loss of patience. And then there is the matter of HDR10 metadata that's included in the Resolve output but not read by x265...has to all be re-included.

Now that said...I have NO IDEA how to proceed with HDR10+ dynamic metadata. I've worked with all the controls, but I can't fly the airplane. What tone mapping goes with what, on the advanced settings of the render settings, in the project settings, tone mapping preview of the color page. Are we even supposed to include the static metadata when we're attaching the JSON file? As Piotr mentions, there is precious little info in the Resolve documentation. It's almost as if BMD started by designing in all the controls they wanted to have without necessarily know how they are to be used.

It's funny, 3 days ago I did not even know Resolve exported HEVC until I stumbled over it and spilled my milk. I went to the doom9 and they were talking about it there with the same questions but had not figured how to -bsf_hevc_metadata to put in the metadata without re-encoding. So I got that working and came over here and saw you and Piotr were a month ahead with the same exact solution! It's a solution no one likes but it is hardly bad, the Nvidia hardware encoder is extremely fast. And I'm frankly not sure the BMD is to blame about the metadata not working. Could be Nvidia's fault.

But this has been helpful. The thing about it, I honestly don't feel the need for HDR10+ except for this; we can already grade scene by scene or frame by frame if we want to, and with 16 bit Sony raw there is infinite control and no concern for going out of range, so why would we grade with metadata? And the only answer I can come up with, is that you could do one color grade, and then go back and grade the metadata for each device that has a smaller color volume than the one you are working in. Is it a fool's errand? Because in a way we probably aren't going to have to deal with these sub compliant HDR devices forever. /rant_off

Hi Tom - nice to see you here

Likewise dear friend!

It's plain simple command.

Having little to no experience with the command line (for very good reason), I have to disagree.

It's not working, and I haven't the skills to troubleshoot. That's why I'm wanting BMD to make this work correctly.

Meaning MP4 exports with HDR on will trigger any brand of TV or projector into the proper mode.

Can only mean one thing, GAME OVER Jim Simon

Hmm...if you can use Resolve you can run this command

Yes, I can run it fine.

The problem is that it doesn't work. Troubleshooting command line software is not quite the same skill set as using a GUI-based NLE.

Can only mean one thing, GAME OVER Jim Simon

Well...delayed is more accurate. But that's OK. I still don't have my new P4K's yet. (C'mon BMD, ramp up that production.)

The call here is for BMD to correct the issue with Resolve, thus obviating the need for command line tools.

You can't use bsf filter for this (not supported yet). You need to add it during main encode.
I used x265 binaries, not ffmpeg. Not sure if official ffmpe has been compiled with hdr10+ option. You need special setting during compile to have it included.
With x265 you just simply add --dhdr10-info and point to json file.

--dhdr10-info seems to be included in the ffmpeg builds and probably has been for a while, it's been in x265 since version 2.4.

Anyway, try this (it works if your syntax is perfect):

ffmpeg -i input -c:v libx265 -x265-params --transfer=16:--dhdr10-info=timeline.json:--fps=59.94:--input-csp=2: -b:v 15000k output

syntax is very picky, spaces and no spaces, caps and lower case, colons all critical!! So I've added a few extra x265 parameters for examples and clarity. I'm not an authority on this, but it's difficult enough with these command line compilers to not have to be stacking them to get your audio and other features muxed together. They all have similar syntax structures but just different enough to cause loss of patience. And then there is the matter of HDR10 metadata that's included in the Resolve output but not read by x265...has to all be re-included. They should be present in HDR10+ files as well.

Now that said...I have NO IDEA how to proceed with HDR10+ dynamic metadata. I've worked with all the controls, but I can't fly the airplane. What tone mapping goes with what, on the advanced settings of the render settings, in the project settings, tone mapping preview of the color page. Are we even supposed to include the static metadata when we're attaching the JSON file? As Piotr mentions, there is precious little info in the Resolve documentation. It's almost as if BMD started by designing in all the controls they wanted to have without necessarily know how they are to be used.

It's funny, 3 days ago I did not even know Resolve exported HEVC until I stumbled over it and spilled my milk. I went to the doom9 and they were talking about it there with the same questions but had not figured how to -bsf_hevc_metadata to put in the metadata without re-encoding. So I got that working and came over here and saw you and Piotr were a month ahead with the same exact solution! It's a solution no one likes but it is hardly bad, the Nvidia hardware encoder is extremely fast. And I'm frankly not sure the BMD is to blame about the metadata not working. Could be Nvidia's fault.

This command:
ffmpeg -i input -c:v libx265 -x265-params --transfer=16:--dhdr10-info=timeline.json:--fps=59.94:--input-csp=2: -b:v 15000k output

is for encoding and inserting HDR10+ metadata (not static one). Static metadata is color transform, mastering display info, MaxFall etc. They are global, although should be repeated in specific places (eg every I frame). If TV is HDR10 then it will use them, if HDR10+ then it will use them+ dynamic info from json.

Other command is just for fixing missing color transfer, color matrix etc. info in existing h265 files. Those are 2 very different things. Bitstream filter (-bsf) works on hex level and it doesn't touch actual video.
It's nice that ffmpeg now includes those AVC/H265 related bitstream filters, although this is just 1st version and what is supported is still bit limited. For example you can't add display mastering info or HDR10+ metadata. Maybe it will be added at some point. There are other tools which do this, but they are not free.
I would still advise to use x265 for generating HDR files, as those bitstream operations may not always give perfect results (depending how original h265 file was crested). There are certain rules where those headers should be present in h265 stream (eg on every I frame etc). x265 has it now properly implemented.

HDR10+ metadata is generated by tool which can do it- like Resolve. Once you have it then you insert it to h265 file during transcoding. Resolve HDR10+ json file seems to be compatible with x265, so it can be used directly. Of course you need to do it for final timeline and never touch in point during transcoding, as otherwise it all will be de-synced. You don't need to worry about any tone mapping etc- TV does it for you based on HDR10+ standard. This is the whole point of it. It works similar way as DV- it adjusts picture based on metadata and TV capabilities on per scene basis. At least this is how I understand it. This is why HDR10+ needs TV with "HDR10+ chipset" and one with DV support with "DV chipset". In reality processing is most likely done by TV's main chipset. Manufactures just license and add math which is behind each standard. If you come up with better tone mapping etc. then you may forget about DV or HDR10+ and stick to your version

Andrew, all of what you said is correct. I was unable to find an ffmpeg build that for x265 had the --dhdr10-info (HDR10+ option) enabled, so as you said, I had to do it through x265 which worked...HDR10+ is live! Yay!!

The only HDR10+ source that would work for me as an input for x265 was 420 yuv raw, which meant re-formatting the 422 uncompressed yuv exported by Resolve. For that step I had to use ffmpeg. But no complaints, the result looks super good.

I've got all the HDR parameters now, transfer, matrix, colorprim, display mastering, and the json file.

x265 binaries support limited input.
You can always pipe data from ffmpeg to x265. This is how most people do.
Something like this:
ffmpeg -i input.mov -pix_fmt yuv420p10le -strict -1 -f yuv4mpegpipe - | x265 --y4m - -o output.265
Ffmpeg decodes source and passes as raw frames to h265. Y4m is a raw format with tiny header which passes frame rate, frame size etc. info.

update: added strict -1 which is required for 10bit pipe

ffmpeg -i input.mov -pix_fmt yuv420p10le -f yuv4mpegpipe - | x265 --y4m - -o output.265

Ah, much better, I think I've just about got it.

Just one question: Will the above pipe make the call to an external x265 binary, or only an internal call to libx265?

ffmpeg -i input.mov -pix_fmt yuv420p10le -f yuv4mpegpipe - | x265 --y4m - -o output.265

Ah, much better, I think I've just about got it.

Just one question: Will the above pipe make the call to an external x265 binary, or only an internal call to libx265?

Hello,

I think so. The pipe means that one transmits data from one executable to another.

Yes, pipe just passes decoded raw video frames trough memory to another up. All done through chunks- when chunk is processed by 2nd app it's then cleared from memory and process keeps going. Simple and powerful in the same time.

One app passes and initialises another app. In this cases ffmpeg passes to x265. Typically "-" mean pipe. FFmpeg has it on output and x265 on input.
You have to be careful as sometime because of piping errors from first app are lost, so you just got an error but don't know what it's.

Just for windows User:
If we look at the command line
"ffmpeg -i input.mov -pix_fmt yuv420p10le -f yuv4mpegpipe - | x265 --y4m - -o output.265"

(1) For FFMPEG the last '-' is a pipe for FFMPEG before '|' but for MS-DOS it takes a (2) '|' (alt + 124) for MS-DOS to know it's a pipe between 2 executable.

Do not forget the two pipes.

Edit:
What I would like and have already asked (v15 list wishes ):
That Davinci Resolve.exe gets to make as Frame Server (like a pipe) to another executable or an OFX or solution on delivery......

Ok I dream again

Big dream

Piping is working perfectly. Back later with more details, have to run to appointment.

Tom

Edit:
What I would like and have already asked (v15 list wishes ):
That Davinci Resolve.exe gets to make as Frame Server (like a pipe) to another executable or an OFX or solution on delivery......

Ok I dream again

I had this thought too, frameserver like AVISynth.

One quick but important detail before I run.. use -strict -1 or else y4m will want to interpret the input as 8-bit 420.

I thought new ffmpeg had y4m updated and not complained about this anymore.
FFmpeg will fail without strict -1 no?

One could try Hybrid (by selur) - it's a GUI for ffmpeg and other line-based AV programs, for inserting HDR metadata

I thought new ffmpeg had y4m updated and not complained about this anymore.
FFmpeg will fail without strict -1 no?

I said y4m "will want to interpret the input as 8 bit 420" because it said it was designed for 8 bit 420 and would fail the output unless you heeded it's warning and used the -strict -1. Soft encouragement to change -pix_fmt yuv420p is what I meant. But the pipe works perfectly and I have you to thank for pointing that out to me, with some good help from others too.

Here is what I ended up with for now:

Code: Select all

ffmpeg -i source.mov -pix_fmt yuv420p10le -strict -1 -f yuv4mpegpipe - | x265 --y4m - --preset medium --crf 20.4 --range limited --colorprim bt2020 --transfer 16 --colormatrix bt2020c --sar 1:1 --hdr-opt --dhdr10-info timeline.json --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" --max-cll "1419,520" --output target.265

Good news - a project with HDR10+ enabled, and even without tone analysis, can now in DR 16 export properly HDR10-flagged files which, played back on Windows secondary monitor, properly switch it to true HDR10 mode.

This is an early finding, and needs some more testing - but it looks BMD have listened

Piotr

Yes, metadata is now present in private h265 headers ( I tested on Mac).There is still no mastering display info though.

Yes, metadata is now present in private h265 headers ( I tested on Mac).There is still no mastering display info though.

Yeah, the mastering display part is a mystery to me. In Scratch, when setting up a 2020/PQ project, the HDR mastering metadata "table" is created with only maxLum (e.g. 1,000 nits) filled up; the MaxCLL and MaxFall fields are both zeros initially. However, on the Render page you can let Scratch analyze the program and fill those missing values up automatically in the HDR metadata table. And yes - I can see the difference on the reference monitor when playing with those values!

So dropping those aspects of the target screen completely is something I don't understand in Resolve. On the other hand - if you remember our first HDR10 encodings with ffmpeg/x265, done on various formats clips exported from Resolve (was it still the 12.5?) - we also scratched our heads because the mastering-display part of the ffmpeg command line didn't have any noticeable impact on the rendered HEVC files...

Piotr

It's all new and maybe TVs are getting firmware updates and changing their behaviour.
You need to analyse footage to know these values so this is why Scratch behaves this way.
No idea why Resolve still doesn't have similar features as most good HDR apps do.

It's all new and maybe TVs are getting firmware updates and changing their behaviour.
You need to analyse footage to know these values so this is why Scratch behaves this way.
No idea why Resolve still doesn't have similar features as most good HDR apps do.

Yes, but what's the most mysterious to me is the fact that you can see it influence the image in Scratch, but (myself at least) never noticed a difference in the ffmpge HEVC encodings; in fact I started to drop the mastering-display part of the command line completely...

Piotr

Maybe it's because your old values were wrong?
How did you get them in the past? Were they correct values based on analysis of particular file?