Is there a simple way to conserve HDR10 through adobe/handbrake?

[LeXXuz]

Originally Posted by Boulder

I believe "0,0" is safer than NULL.

"The first value is the max content light level (or 0 if no maximum is indicated), the second value is the maximum picture average light level (or 0)."

I found that in the docs, too. I would say you are right.

Btw how do you guys handle a video source with dynamic tone mapping?

HDR_Format/String                        : SMPTE ST 2094 App 4, Version 1, HDR10+ Profile A compatible

[nevcairiel]

Originally Posted by Boulder

I believe "0,0" is safer than NULL.

"The first value is the max content light level (or 0 if no maximum is indicated), the second value is the maximum picture average light level (or 0)."

Not indicating values is generally better then indicating "wrong" values.

[Boulder]

Originally Posted by nevcairiel

Not indicating values is generally better then indicating "wrong" values.

I agree with that. Unless the docs or specifications state otherwise, it's safer.

I think that x265 treats "0,0" the same way as leaving the value unspecified. At least it won't write the information in the metadata if you use those zeroes.

[benwaggoner]

Originally Posted by LeXXuz

I found that in the docs, too. I would say you are right.

Btw how do you guys handle a video source with dynamic tone mapping?

HDR_Format/String                        : SMPTE ST 2094 App 4, Version 1, HDR10+ Profile A compatible

You would copy each frame's HDR10+ metadata into the reencoded version of that frame. It's just an SEI message. I'm not sure if there are any tools that can do that simply. Probably mp4box, as it can do pretty much anything with long enough a command line and patient enough trial and error .

But it needs to be done correctly. A four frame offset could lead to some quite strange behavior around edits. Also, it only matters if you have or are planning to have a display device that supports HDR10+. The nubmer of which are growing. But if you skip it, you'll still have a normal HDR-10 file with static metadata.

[LeXXuz]

Damn, I was afraid this might be a lot of work.

So basically we need a tool that reads all metadatas from the source file and copies them over to the encoded file. Therefor the encoded file has to have the very same frame structure as the source, I guess?

I'll pass on these files for now unless there is some kind of automated tool/solution one day.

[Boulder]

Isn't quietvoid's tool suited for HDR10+? Or do you mean adding the metadata without re-encoding?

https://github.com/quietvoid/hdr10plus_parser/releases

[LeXXuz]

Originally Posted by Boulder

Isn't quietvoid's tool suited for HDR10+?

That sounds awesome. I have to check that out.

Originally Posted by Boulder

Or do you mean adding the metadata without re-encoding?

No I meant re-encoding to a smaller filesize and adding back that dynamic metadata of the source video.

[Boulder]

Then that's the thing for you. Get the parsed metadata and feed it to x265, there's a separate parameter for it.

[-QfG-]

Originally Posted by LeXXuz

What do I do when these values are missing in the source video metadata?

Then delete this entries, they will be not written, if they not exist.
Do not set Fake entries how 0,0 or something.

I assume "Display P3" is the P3D65 you mentioned?

Display P3 = P3D65 correct!

Isn't quietvoid's tool suited for HDR10+? Or do you mean adding the metadata without re-encoding?

This is a HDR10+ Metadata parser, who reads the bitstream and save all HDR10+ metadata in a JSON textfile. While encoding you must write this Data into the bitstream.
No chance to implent HDR10+ metadata after Encoding in a HDR10 bitstream.

So basically we need a tool that reads all metadatas from the source file and copies them over to the encoded file. Therefor the encoded file has to have the very same frame structure as the source, I guess?

I have build a tool for me, that reads HDR10 and HDR10+ metadata and write the commands for x265 in a txt file. The Problem is, i must solve the P3 / BT2020 Alghorythm, i use DGindexNV for this,
so this tool works only with a NVideo Geforce GTX 1050 and above.

[BobbyBoberton]

Originally Posted by -QfG-

I Only known 2 different HDR10 metadatas.

BT2020 and P3D65

If you will reencode a HEVC 10-Bit HDR Stream, use following custom strings for x265:

Check in MediaInfo this entry:



BT2020:


P3D65:


You must change the blue and green entries, use the entries you see in MediaInfo of the Stream/file.

The above examples looks so in MediaInfo:



Another thing is, you must use a 10-Bit pipeline! You see it in the encoder Window on the top, there must stand: i420p10!.
I use LSMash for my DNxHR Intermediates, for HEVC Input in Mkv Container i use DGIndesNV or LWLibAv.

I'm using for Encoding StaxRip as Gui and x265 as Encoder. It's faster as FFMPEG.

ok awesome, thank you for that information. I don't see any difference in the "green" text for luminance values between BT2020 and P3 but the G(x,y) parameters are different, so is that what you meant to pay attention to?

All my HDR so far has been in P3 (as far as I am aware) so I have been using the proper G(x,y) values but what would happen if I had a video with the BT2020 master display primaries and used G(13250,34500) instead of G(8500,39850), the max-cll is the same in both of these so I am not sure why you point them out other than to say 'makes sure that this is set'?

EDIT: err i guess the whole G(x,y)B(x,y)R(x,y)WP(x,y) numbers change, but the question at the end still stands, what if I use the GBRWP values for P3 on a BT2020 source? I figure nothing in a non-hdr monitor but what effect to HDR would this have? Would it be terribly off, or just annoying or completely unwatchable? Thanks for any answers.

Also I have been using max-cll=1000,400 but the source files can sometimes be above this like one I current have through mediainfo is

Color primaries : BT.2020 
Transfer characteristics : PQ 
Matrix coefficients : BT.2020 non-constant 
Mastering display color primaries : Display P3 
Mastering display luminance : min: 0.0050 cd/m2, max: 4000 cd/m2 
Maximum Content Light Level : 5847 cd/m2 
Maximum Frame-Average Light Level : 1355 cd/m2

So max-cll would be 5847,1355 if I went by the source material, and luminance would be different as well but I know that there are not many displays that go above 1000 nits so I don't really get these settings, wouldn't this blow out the image in an HDR display to be super bright all the time?

[-QfG-]

Color primaries : BT.2020 
Transfer characteristics : PQ 
Matrix coefficients : BT.2020 non-constant 
Mastering display color primaries : Display P3 
Mastering display luminance : min: 0.0050 cd/m2, max: 4000 cd/m2 
Maximum Content Light Level : 5847 cd/m2 
Maximum Frame-Average Light Level : 1355 cd/m2

The x265 commandline for this:

--hdr --output-depth 10 --hdr-opt --max-cll "5847,1355" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)"

[BobbyBoberton]

Originally Posted by -QfG-

Color primaries : BT.2020 
Transfer characteristics : PQ 
Matrix coefficients : BT.2020 non-constant 
Mastering display color primaries : Display P3 
Mastering display luminance : min: 0.0050 cd/m2, max: 4000 cd/m2 
Maximum Content Light Level : 5847 cd/m2 
Maximum Frame-Average Light Level : 1355 cd/m2

The x265 commandline for this:

--hdr --output-depth 10 --hdr-opt --max-cll "5847,1355" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)"

Thanks but I did say I know that that would be the command, the 5847 cd/m^(2) = 5847 nits and the 'best' consumer HDR displays are 1000 cd/m^(2) or 1000 nits peak brightness so wouldn't having the Frame-Average Light Level = 1355 cd/m^(2) / nits mean that the image is super bright and washed out all the time? I mean that's 100% brightness on average from what I understand about HDR and nits output. I know how to change the command line but i am asking if that make sense to use those settings or does the 1000,400 level make more sense for not professional grade video equipment. (Its "pro-sumer" stuff I have but its not professional grade AV gear).

EDIT: Also, I forgot to ask about why you didn't address the what if I encode a source with P3 master display primaries when it was originally encoded with BT2020 primaries or vice versa? Would this be barely noticeable, very noticeable, dramatically noticeable or produce an indecipherable picture in HDR mode?

Thanks

[Asmodian]

No. You are telling the device what the mastering was, not what it should do when displaying it. You do not change the metadata for your display. The entire reason for metadata is because the file represents colors too bright for your display, you are telling it exactly how bright it represents so your device can figure out the best way to compress it into the range it can actually display.

P3 is very not the same as BT.2020, encoding a BT.2020 source and lying to the display that it is P3 will make it very washed out. The same is true in reverse, P3 content flagged as BT.2020 will be very over saturated. Very noticeable but a decipherable picture.

[BobbyBoberton]

Originally Posted by Asmodian

No. You are telling the device what the mastering was, not what it should do when displaying it. You do not change the metadata for your display. The entire reason for metadata is because the file represents colors too bright for your display, you are telling it exactly how bright it represents so your device can figure out the best way to compress it into the range it can actually display.

P3 is very not the same as BT.2020, encoding a BT.2020 source and lying to the display that it is P3 will make it very washed out. The same is true in reverse, P3 content flagged as BT.2020 will be very over saturated. Very noticeable but a decipherable picture.

Oh wow yeah that does make perfect sense, just means I will have to do some re-encoding of material as I was keeping a constant max-cll=1000,400 on my HDR encodes even when they were not the source values. I don't current have an HDR monitor to try this stuff out on besides a Samsung Note10+ phone so when I play the video files I have 'wrongly "HDRd" on it they don't seem weird but I am not 100% that it is picking up the HDR data to begin with. Thats why I can't wait to get a HDR10/HDR10+/Dolby Vision compatible TV/Monitor for downstairs and I don't want all my hard work encoding to look terrible, it'll take a bit of time but I can redo the damage pretty quick, maybe a week or two and I should be ok.

EDIT: Also, due to some sloppy batch controlling I accidently encoded a set of 1080p SDR files as HDR ones. I know that this wont effect playback on SDR device but what effect will this have on an HDR monitor? Will the video look 'wrong' due to that extra HDR data? Also is that "HDR metadata" the "global tags" that are found in MKVtoolNiX? If so can I just strip the global tags from the files without having to re-encode the entire file? This would save me a ton of time if possible.

EDIT2: Also this only works for HDR10 static metadata right? As others were discussing above you would need a HDR10+ parser to 'map the dynamic HDR10+ metadata' and then use that file with the appropriate options to intake the HDR10+ metadata (I have seen these options on the x265 options page I just don't remember the specific command off the top of my head). Is that all correct?

Thank you!

[benwaggoner]

Originally Posted by BobbyBoberton

Thanks but I did say I know that that would be the command, the 5847 cd/m^(2) = 5847 nits and the 'best' consumer HDR displays are 1000 cd/m^(2) or 1000 nits peak brightness so wouldn't having the Frame-Average Light Level = 1355 cd/m^(2) / nits mean that the image is super bright and washed out all the time?

Higher-end LCD HDR TVs have done well above 1000 nits for a few years now, and some can hit >2000 today. Although that's for highlights. Not many can do >1000 nits as an average light level due to power/heat limitations. Also, that's verging on being a tanning bed more than a TV. Even 500 nits FALL can be BLINDING.

I mean that's 100% brightness on average from what I understand about HDR and nits output. I know how to change the command line but i am asking if that make sense to use those settings or does the 1000,400 level make more sense for not professional grade video equipment. (Its "pro-sumer" stuff I have but its not professional grade AV gear).

If the content really gets that bright, it's probably good to stick to the real values. Although I wouldn't expect FALL >1000 having much practical impact.

EDIT: Also, I forgot to ask about why you didn't address the what if I encode a source with P3 master display primaries when it was originally encoded with BT2020 primaries or vice versa? Would this be barely noticeable, very noticeable, dramatically noticeable or produce an indecipherable picture in HDR mode?

Most HDR content uses the P3 subset of 2020 primaries. The code values will produce very different results depending on what the primaries are set to. If the mastering display was P3, that doesn't impact anything. What matters is what primaries were used, which almost certainly were 2020.

[BobbyBoberton]

Originally Posted by benwaggoner

Higher-end LCD HDR TVs have done well above 1000 nits for a few years now, and some can hit >2000 today. Although that's for highlights. Not many can do >1000 nits as an average light level due to power/heat limitations. Also, that's verging on being a tanning bed more than a TV. Even 500 nits FALL can be BLINDING.


If the content really gets that bright, it's probably good to stick to the real values. Although I wouldn't expect FALL >1000 having much practical impact.


Most HDR content uses the P3 subset of 2020 primaries. The code values will produce very different results depending on what the primaries are set to. If the mastering display was P3, that doesn't impact anything. What matters is what primaries were used, which almost certainly were 2020.

Yeah some of the source material I am working with has a CLL=10,000 and FALL=2427 which sounds crazy to me especially considering the actual video is quite dark but maybe that's why? IDK.

Thanks for the answers.

[BobbyBoberton]

I asked above but it was kind of hidden,

I wasn't paying attention to a batch encode of videos that were 10-bit SDR (BT.709) source and I mistakenly left the HDR settings by mistake so now these "SDR" videos have HDR metadata (HDR10, not HDR10+), is there a way to remove this data without re-encoding the files completely like in MKVToolNiX after I encode a video with HDR it will have "global tags", is this the HDR metadata? Or is there some other way or do I just have to re-encode so that it displays properly on an HDR monitor?



Also, to confirm I asked the people over at the handbrake official forums and handbrake IS NOT a 100% 10-bit pipeline/workflow. ALL input is seen as 8-bit SDR even if its 10-bit HDR, it can encode that 8-bit YUV420p stream into a 10-bit YUV420p10le stream but there is no chance of the extra info from the original source making it through, so as others have said, if you are working with 10-bit source material then make sure your entire pipeline/workflow is 10-bit!!

[BobbyBoberton]

Originally Posted by Helg1980

Try Cine Encoder (there is a Linux-only version.)

I can deal with Linux only, that isn't that huge of a deal and I have been planning on doing a Win 10/Gentoo Linux dual boot on my new system but my real question is how would this help exactly?

According to the site it says that it was built to preserve HDR signals, the last question I asked was how to remove HDR from a source that was SDR and had a HDR10 static metadata stuck to it by mistake (not paying attention to the script).

If this was in response to the OP then yeah, it may be worth a look for sure.

Thanks!

[ReciprocalUniverse]

Originally Posted by benwaggoner

Master Display paramaters themselves can change when a different mastering monitor is used. There was pretty much just the one Sony model for the early years of HDR, but we're seeing some more options now.

That said, I'm not aware of any displays doing anything with the mastering display metadata. MaxCLL is the most used.

From the command line run dxdiag and you can poll the actual mastering monitor coefficients in use from the display card.

[BobbyBoberton]

I know this is kind of out of the blue but I am trying to get staxrip set up and I don't see where I am going wrong, I set up a template, I import a source, set a destination, set all the variables for x265 and mkv container, the only AVS filter checked is 'source' and that is set to FFVideoSource (DXVA2 accel, but tried without it as well), gets the same error:

x265 M-3.4+6-g73f96ff39-gcc11.0.0 Patman

"C:\Program Files\StaxRip-x64-2.1.3.0-stable\Apps\Encoders\ffmpeg\ffmpeg.exe" -threads 1 -hwaccel dxva2 -i "D:\Videos\TOS 2160p HDR.mkv" -f yuv4mpegpipe -strict -1 -loglevel fatal -hide_banner - | "C:\Program Files\StaxRip-x64-2.1.3.0-stable\Apps\Encoders\x265\x265.exe" --crf 19 --output-depth 10 --hevc-aq --aq-mode 3 --me star --max-merge 4 --fades --frame-threads 3 --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)" --hdr10 --colorprim bt2020 --colormatrix bt2020nc --transfer smpte2084 --range limited --max-cll "10000,1992" --hdr10-opt --repeat-headers --hrd --aud --input-depth 10 --deblock -2:-3 --frames 64297 --y4m --output "D:\Videos\TOS 2160p HDR_temp\TOS.Atmos.5.1.mkv_out.hevc" -

x265 [error]: unable to open input file <->

technically gives me error code 0x1 but says that its meaning is pretty vague.

Any help? Its like its not putting output to SDOUT

If I just take that code and run it in CLI I get a similar error saying x265.exe cannot open the input stream so whats going on? it should grab the y4m stream from FFmpeg and then output a .hevc file that is then muxed together by the other utilities in staxrip (probably mkvmerge).