HDR10+ General Discussion

[SeeMoreDigital]

Originally Posted by benwaggoner

The future really would be a 12-bit base layer with dynamic metadata going into a half-float integrated processing unit that directly renders to panel color volume.

....And 12-bit OLED panels

[benwaggoner]

Originally Posted by Blue_MiSfit

I see. Yikes. I love how it's not even in the Dolby Vision documentation anymore!

It was a clever solution back in 2014, before >8-bit decoders became common. Plus it was a relatively little overhead on top of a backwards-compatible SDR stream, so well suited to channel/capacity limited delivery mechanisms like cable/sat/broadcast and optical disc.

I wonder what it would take to have a truly high end rendering + processing pipeline on a TV a-la MadVR. I've heard that MadVR is going commercial and making hardware, which is kind of fascinating....

It would take a whole lot of unprecedented collaboration between the display panel vendor and the SoC/OS signal processing chain. Which is surprisingly hard, even when both are in the same company.

[Fitik]

Hello,
have a question.
If source is HDR10+ and i dont specify --dhdr10-info with x265, do I get correct HDR10 video?
In other words, difference between HDR10+ and HDR10 is only SEI metadata and result playback is the same whether they are not present or player can not use them?
Thanks a lot.

[benwaggoner]

Originally Posted by Fitik

Hello,
have a question.
If source is HDR10+ and i dont specify --dhdr10-info with x265, do I get correct HDR10 video?
In other words, difference between HDR10+ and HDR10 is only SEI metadata and result playback is the same whether they are not present or player can not use them?
Thanks a lot.

For a non-HDR10+ capable player, you'll see no difference with or without the metadata. With a capable player, you'll get an improvement with the metadata.

[Ts9001]

I hope this is correct thread for my question. I have issues with parsing hdr10+ metadata from some mkv files using ffmpeg+hdr10plus_parser.

First, when I run the verification I get this which looks promising:
←[34mParsing HEVC file for dynamic metadata... ←[0m
←[34mDynamic HDR10+ metadata detected.←[0m

But then when I start the parsing it stops at some point and I get this:
←[34mParsing HEVC file for dynamic metadata... ←[0m
frame=193656 fps=864 q=-1.0 Lsize=36697460kB time=02:14:37.02 bitrate=37219.8kbits/s speed= 36x
video:36697460kB audio:0kB subtitle:0kB other streams:0kB global headers:1kB muxing overhead: 0.000000%
←[34mReading parsed dynamic metadata... ←[0mthread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Parse("not enough data: expected 12 bits got 2 bits")', src/hdr10plus/parser.rs:233:71
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I have to say that with my limited understanding on these things I have no idea what is the issue here. Well, it says something about "not enough data" but what does that mean? Is there anything I can do to get the HDR10+ metadata out of these file?

This is the command line I'm using:

ffmpeg -i input.mkv -c:v copy -vbsf hevc_mp4toannexb -f hevc - | hdr10plus_parser -o metadata.json -

[foxyshadis]

Originally Posted by Ts9001

I have to say that with my limited understanding on these things I have no idea what is the issue here. Well, it says something about "not enough data" but what does that mean? Is there anything I can do to get the HDR10+ metadata out of these file?

This is the command line I'm using:

ffmpeg -i input.mkv -c:v copy -vbsf hevc_mp4toannexb -f hevc - | hdr10plus_parser -o metadata.json -

Yep, that was a major bug, it was fixed a couple of weeks ago so you just need to get the new version: https://github.com/quietvoid/hdr10plus_parser/issues/26

[Ts9001]

Originally Posted by foxyshadis

Yep, that was a major bug, it was fixed a couple of weeks ago so you just need to get the new version: https://github.com/quietvoid/hdr10plus_parser/issues/26

Thanks, that fixed the issue.

Then I would have another issue in regards to HDR10+ metadata. When I try to encode one file using FastFlix it immediately stops and the following lines can be seen in the log. If I encode the same file without the HDR10+ metadata then it works. What could be wrong with the metadata?

INFO x265 [error]: Unable to open tone-map file.
INFO [libx265 @ 0000020444ccdec0] Cannot open libx265 encoder.
INFO Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
INFO Conversion failed!
INFO
INFO
WARNING Error during conversion

[quietvoid]

Maybe the libx265 version you're using wasn't compiled with the HDR10+ option?

[ghostshadow]

FastFlix supports using generated or extracted JSON HDR10+ Metadata with HEVC encodes via x265. However that is highly dependant on a FFmpeg version that has been compiled with x265 that has HDR10+ support. BtbN's Windows FFmpeg builds have this support as of 10/23/2020 and may require a manual upgrade.

[zweifingerjoe]

Is there any document or specification publicly available that describes how hdr10+ metadata is mapped to the json file? There is a link in x265's manual but it doesn't work anymore.

[quietvoid]

There are example files in the x265 repo: https://bitbucket.org/multicoreware/x265_git/downloads

Not all the fields are used in the x265 code, however.

[zweifingerjoe]

thanks

[telemO]

Hello quietvoid,
and thanks again for your amazing work in developping this metadata parsing tools.

I've seen that you've recently updated the HDR10+ parsing tool with the similar principle than for the dovi one : does it have a "crop" option as well to be activated? Or as it should only concern the "active area", according to the official documentation, it is no problem to transcode with cropped bars?

[asarian]

Originally Posted by benwaggoner

Anything that doesn't change the video elementary stream should retain HDR10+ metadata.

I understand I'm replying to an older post, but the issue is still relevant to me, as I plan to denoise some UHD material, and don't want to lose metadata while running x265. Are there specific options I need to use to retain HDR data? Or will x265 default to keeping the metadata itself?

Thanks.

[benwaggoner]

Originally Posted by asarian

I understand I'm replying to an older post, but the issue is still relevant to me, as I plan to denoise some UHD material, and don't want to lose metadata while running x265. Are there specific options I need to use to retain HDR data? Or will x265 default to keeping the metadata itself?

x265 doesn't support passthrough itself, although some tools that incorporate it presumably do so.

You'll need manually set the metadata to the same as the source if using standard x265.exe.

[asarian]

Originally Posted by benwaggoner

x265 doesn't support passthrough itself, although some tools that incorporate it presumably do so.

You'll need manually set the metadata to the same as the source if using standard x265.exe.

Thx.

Speaking of which, seems DGindexNV already tags a line to its .dgi files, like

X265_CL --colorprim 9 --transfer 16 --colormatrix 9 --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)" --max-cll "10000,724" --frames 181104 --chromaloc 2

Is that what I think it is, a courtesy to show ppl how to preserve the correct color info?! Not sure what the X265_CL stands for (Command Line?), but it really looks interesting.

[Boulder]

Originally Posted by asarian

Thx.

Speaking of which, seems DGindexNV already tags a line to its .dgi files, like

X265_CL --colorprim 9 --transfer 16 --colormatrix 9 --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)" --max-cll "10000,724" --frames 181104 --chromaloc 2

Is that what I think it is, a courtesy to show ppl how to preserve the correct color info?! Not sure what the X265_CL stands for (Command Line?), but it really looks interesting.

Yes, that's something you put directly in your x265 command line to preserve those properties from the source. Don kindly added this feature upon my request, it saves a nice amount of time when you don't have to find out and type the info manually.

[asarian]

Originally Posted by Boulder

Yes, that's something you put directly in your x265 command line to preserve those properties from the source. Don kindly added this feature upon my request, it saves a nice amount of time when you don't have to find out and type the info manually.

Well, thank you kindly for that request. Saves me a ton of work trying to figure it out each time. And thanks be to Don, of course, for adding it.

[Ripmann]

Originally Posted by jlpsvk

cropping HDR10 is OK, cropping HDR10+ not.

Is this still valid in today? No new tools since early 2020 that can work around the HDR10+ crop problem?

[benwaggoner]

Originally Posted by Ripmann

Is this still valid in today? No new tools since early 2020 that can work around the HDR10+ crop problem?

Not that I know of. HDR10+ is largely used in professional encoding from a mezzanine, so reencode-with-crop isn't a scenario that the professional tools consider.