HDR10+ General Discussion

[SeeMoreDigital]

As some of you may already know, the first UHD disc's encoded with HDR10+ have been released.

Currently only the newest Panasonic and Samsung devices support this version of 'dynamic' HDR, with the OPPO UDP-20x range of players and its clones to follow.

However, a guy over on the AVS forum has managed to back-up two of the new HDR10+ disc releases (https://www.avsforum.com/forum/39-networking-media-servers-content-streaming/2942740-ripping-uhd-4k-discs-makemkv-instructions-how-50.html#post57269248) but has encountered an interesting issue that requires more analysis, help and feed-back from others.

Long story short, when the (HEVC/HDR10+).m2ts file is accessed/played outside its original UHD disc folder-set, not only is the HDR10+ meta-data/flag lost, the basic HDR10 information is lost too. Meaning no HDR at all. And, re-muxing the HEVC/HDR10+ elementary video stream into the MKV container does not work either :eek:

Can anybody here offer any help?

[nevcairiel]

Which titles use HDR10+? AVSforum didnt seem to say.

[SeeMoreDigital]

Which titles use HDR10+? AVSforum didnt seem to say.Not many...

Here's a link to the current/proposed movies: List of UHDs that contain HDR10+ (https://forum.blu-ray.com/showthread.php?t=300877)


Cheers and thanks for your interest...

[sneaker_ger]

Since HDR10+ wasn't in the original spec, how do they achieve backwards-compability? Or do all UltraHD Blu-Ray players receive firmware updates for it (not that many players exist)? Maybe the movie is stored twice, e.g. one SDR and one HDR10+ version and the remuxing software accesses the SDR one?

[nevcairiel]

Specs evolve over time. They may just have two discs in the package, like some 3D movies. The 3D disc never played on non-3D players, they just had to use the other one.

[foxyshadis]

Since HDR10+ wasn't in the original spec, how do they achieve backwards-compability? Or do all UltraHD Blu-Ray players receive firmware updates for it (not that many players exist)? Maybe the movie is stored twice, e.g. one SDR and one HDR10+ version and the remuxing software accesses the SDR one?

HDR10 is mandatory and basically backwards compatible. In practice, the only thing a non-HDR10+ device will lose is the occasional retina-searing highlight, since the HDR10 average will be set to meet most scenes' needs.

[TomV]

Since HDR10+ wasn't in the original spec, how do they achieve backwards-compability? Or do all UltraHD Blu-Ray players receive firmware updates for it (not that many players exist)? Maybe the movie is stored twice, e.g. one SDR and one HDR10+ version and the remuxing software accesses the SDR one?
HDR10+ is HDR with additional color volume metadata (in SEI messages) to enable the display device to better map the dynamic range of each scene to the display. The encoded video is exactly the same for HDR and HDR10+.

[sneaker_ger]

I see. I wasn't sure what OP meant by "Meaning no HDR at all". Guess he meant the metadata was lost but the encoding is HDR (i.e. you see the washed out colors).

But if all the metadata is simply in SEI messages it would be unusual for muxers to drop them.

[nevcairiel]

I got my hands on one of those discs, and just playing the straight up m2ts file produces proper HDR10 playback. So if ripping to MKV screws that up, then the ripping tool removed something it was not meant to.
I'll peek at the HDR10+ metadata later.

The only odd thing is that the disc claims to be 60GB in size, but the main m2ts is just 22GB, I wonder if something is wrong with the decryption or reading of the disc.
But the movie seems to be all there regardless. Its only 46 minutes (A Beautiful Planet documentary), so maybe the 60GB is just a fluke in being the max size it could be.

[SeeMoreDigital]

I got my hands on one of those discs, and just playing the straight up m2ts file produces proper HDR10 playback...That's interesting. I'll report that back.

So if ripping to MKV screws that up, then the ripping tool removed something it was not meant to.
I'll peek at the HDR10+ metadata later.Did you use MakeMKV to do the back-up to .mkv. If so, I wonder if the loss of the HDR10+ meta-data is due to limitations in their version of their Matroska muxer.

Perhaps, Mosu's Matroska muxer is able to do a better job. I have found this to be the case with regular Blu-ray and UHD disc back-ups!

[nevcairiel]

A MakeMKV MKV file of that disc also preserves the HDR10 charecteristics.

[SeeMoreDigital]

A MakeMKV MKV file of that disc also preserves the HDR10 charecteristics.Really... Does it trigger the HDR10 flag in your hardware player and/or supporting TV?

[nevcairiel]

I don't have such a thing. But my software PC player still reports full HDR just like normal. Hardware playback failure can have a million reasons.
But clearly enough data is preserved to indicate its at least HDR10.

[SeeMoreDigital]

I don't have such a thing. But my software PC player still reports full HDR just like normal. Hardware playback failure can have a million reasons.This is most confusing...

Which HDR10+ disc did you end up purchasing Nev, so I can buy the same one?

In the meantime... Are you able to post a short MKV and/or M2TS sample?

[nevcairiel]

I finally got around to looking at the metadata (well a couple days ago actually), and the .mkv rip from MakeMKV does also contain the HDR10+ SEI metadata. So its all there. If some player cannot play that in HDR10 or HDR10+, then its entirely up to the player.

PS:
I got the A Beautiful Planet documentary, as mentioned above already.

[SeeMoreDigital]

I finally got around to looking at the metadata (well a couple days ago actually), and the .mkv rip from MakeMKV does also contain the HDR10+ SEI metadata. So its all there. If some player cannot play that in HDR10 or HDR10+, then its entirely up to the player.

PS:
I got the A Beautiful Planet documentary, as mentioned above already.Thanks for looking into this, I'll pass the information onto OPPO.

I recently purchased 'A Beautiful Planet' too (via Amazon UK). It's currently on its way from the US of A :eek:

[benwaggoner]

I finally got around to looking at the metadata (well a couple days ago actually), and the .mkv rip from MakeMKV does also contain the HDR10+ SEI metadata. So its all there. If some player cannot play that in HDR10 or HDR10+, then its entirely up to the player.
Anything that doesn't change the video elementary stream should retain HDR10+ metadata.

[SeeMoreDigital]

I wonder if MKV muxer that MakeMKV GUI uses is doing something weird?!

[SeeMoreDigital]

Looks like we're getting a bit closer...

A new AVS forum member, going by the name avsforum2 has just posted the following: -
I have an MKV file and it must carry HDR10+ since when I play it directly on the internal TV player (Panasonic FZ800) it triggers HDR10+ on the TV, when I play the same file on Oppo (beta) it don´t see any HDR information and send out SDR BT.2020 to the TV.

Link: https://www.avsforum.com/forum/149-blu-ray-players/2676801-official-oppo-udp-203-owner-s-thread-869.html#post57398770

[Selur]

Anyone got a link to a HDR-10+ sample file?

[SeeMoreDigital]

Anyone got a link to a HDR-10+ sample file?I've been trying to obtain some official samples for months but without success.

I now hoping some might shake loose after CES...

[hajj_3]

These UHD blurays have HDR10+ on them: https://forum.blu-ray.com/showthread.php?t=300877

You could rip them yourself if you have a specific uhd bluray drive and ripping software. Alternatively you would need to find an uncompressed rip of these online somewhere.

[Selur]

@hajj_3: looking for a legally available sample. (uncompressed and untouched, a remux might not work either)

[hajj_3]

I have managed to cut a 24 second 93MB sample of the uncompressed UHD bluray of Robin Hood, pm me if anyone wants a link to download it. Mediainfo detects it as having HDR10 as i think mediainfo can't detect HDR10+ at the moment. Please note that the low bitrate is because there isn't much movement in some of the scene. The full movie has an average video bitrate of 48.3Mb/s.

Format : Matroska
Format version : Version 4
File size : 92.3 MiB
Duration : 24 s 952 ms
Overall bit rate mode : Variable
Overall bit rate : 31.0 Mb/s
Movie name : Robin Hood Theatrical 4K
Encoded date : UTC 2019-01-12 19:37:28
Writing application : mkvmerge v30.1.0 ('Forever And More') 64-bit
Writing library : libebml v1.3.6 + libmatroska v1.4.9

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Commercial name : HDR10
Format profile : Main 10@L5.1@High
Codec ID : V_MPEGH/ISO/HEVC
Duration : 24 s 942 ms
Bit rate : 23.1 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.116
Stream size : 68.8 MiB (75%)
Writing library : ATEME Titan File 3.8.16 (4.8.16.0)
Default : Yes
Forced : No
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.0050 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 1001 cd/m2
Maximum Frame-Average Light Level : 328 cd/m2

Audio
ID : 2
Format : DTS XLL
Format/Info : Digital Theater Systems
Commercial name : DTS-HD Master Audio
Codec ID : A_DTS
Duration : 24 s 950 ms
Bit rate mode : Variable
Bit rate : 7 888 kb/s
Channel(s) : 8 channels
Channel layout : C L R LFE Lb Rb Lss Rss
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Delay relative to video : 2 ms
Stream size : 23.5 MiB (25%)
Title : DTS:X 7.1
Language : English
Default : Yes
Forced : No

Text #1
ID : 3
Format : PGS
Muxing mode : zlib
Codec ID : S_HDMV/PGS
Codec ID/Info : Picture based subtitle format used on BDs/HD-DVDs
Bit rate : 0 b/s
Count of elements : 0
Stream size : 0.00 Byte (0%)
Title : English (SDH)
Language : English
Default : No
Forced : No

Text #2
ID : 4
Format : PGS
Muxing mode : zlib
Codec ID : S_HDMV/PGS
Codec ID/Info : Picture based subtitle format used on BDs/HD-DVDs
Bit rate : 0 b/s
Count of elements : 0
Stream size : 0.00 Byte (0%)
Title : French
Language : French
Default : No
Forced : No

Text #3
ID : 5
Format : PGS
Muxing mode : zlib
Codec ID : S_HDMV/PGS
Codec ID/Info : Picture based subtitle format used on BDs/HD-DVDs
Bit rate : 0 b/s
Count of elements : 0
Stream size : 0.00 Byte (0%)
Title : Japanese
Language : Japanese
Default : No
Forced : No

Text #4
ID : 6
Format : PGS
Muxing mode : zlib
Codec ID : S_HDMV/PGS
Codec ID/Info : Picture based subtitle format used on BDs/HD-DVDs
Bit rate : 0 b/s
Count of elements : 0
Stream size : 0.00 Byte (0%)
Title : Portuguese (Brazilian)
Language : Portuguese
Default : No
Forced : No

Text #5
ID : 7
Format : PGS
Muxing mode : zlib
Codec ID : S_HDMV/PGS
Codec ID/Info : Picture based subtitle format used on BDs/HD-DVDs
Bit rate : 0 b/s
Count of elements : 0
Stream size : 0.00 Byte (0%)
Title : Spanish (Latin American)
Language : Spanish
Default : No
Forced : No

Menu
00:00:00.000 : en:Difficult Times
00:00:04.379 : en:Hard News

[SeeMoreDigital]

I have managed to cut a 24 second sample of the uncompressed UHD bluray of Robin Hood, pm me if anyone wants a link to download it. Mediainfo detects it as having HDR10 as i think mediainfo can't detect HDR10+ at the moment. Please note that the low bitrate is because there isn't much movement in some of the scene. The full movie has an average video bitrate of 48.3Mb/s.I didn't think that Robin Hood (2018) disc was available until mid Feb. And from what I understand, it should also contain a Dolby Vision meta-data layer.

I'd quite like a link please...

[mini-moose]

I have managed to cut a 24 second 93MB sample of the uncompressed UHD bluray of Robin Hood

Is this not the Robin Hood from 2010? Don't think HDR10+ appeared on UHD discs till end of 2018.

[hajj_3]

Is this not the Robin Hood from 2010? Don't think HDR10+ appeared on UHD discs till end of 2018.

ahhh, it is from 2010. It was released on uhd bluray around 3-4 months ago. My mistake. Crazy that they made a new film with the same name just 8 years later.

[hajj_3]

I have managed to make a 20 second 104MB sample of 'Bad Times at the El Royale' UHD Bluray, which has HDR10+ on, mediainfo detects it as HDR10 but i don't think it that hasn't been updated to detect HDR10+. https://www.blu-ray.com/movies/Bad-Times-at-the-El-Royale-4K-Blu-ray/217590/#Review

PM me if you want a link to the sample to test.

Format : Matroska
Format version : Version 4
File size : 104 MiB
Duration : 20 s 2 ms
Overall bit rate mode : Variable
Overall bit rate : 43.7 Mb/s
Encoded date : UTC 2019-01-13 23:46:55
Writing application : mkvmerge v30.1.0 ('Forever And More') 64-bit
Writing library : libebml v1.3.6 + libmatroska v1.4.9

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Commercial name : HDR10
Format profile : Main 10@L5.1@High
Codec ID : V_MPEGH/ISO/HEVC
Duration : 19 s 979 ms
Bit rate : 36.4 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (23976/1000) FPS
Original frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.183
Stream size : 86.6 MiB (83%)
Writing library : ATEME Titan File 3.9.0 (4.9.0.0)
Language : English
Default : Yes
Forced : No
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.0050 cd/m2, max: 1000 cd/m2

Audio #1
ID : 2
Format : MLP FBA 16-ch
Format/Info : Meridian Lossless Packing FBA with 16-channel presentation
Commercial name : Dolby TrueHD with Dolby Atmos
Codec ID : A_TRUEHD
Duration : 19 s 978 ms
Bit rate mode : Variable
Bit rate : 6 123 kb/s
Maximum bit rate : 8 373 kb/s
Channel(s) : 8 channels
Channel layout : L R C LFE Ls Rs Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 1 200.000 FPS (40 SPF)
Compression mode : Lossless
Stream size : 14.6 MiB (14%)
Language : English
Default : Yes
Forced : No
Number of dynamic objects : 13
Bed channel count : 1 channel
Bed channel configuration : LFE

Audio #2
ID : 3
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : A_AC3
Duration : 20 s 0 ms
Bit rate mode : Constant
Bit rate : 640 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 16 bits
Compression mode : Lossy
Delay relative to video : 2 ms
Stream size : 1.53 MiB (1%)
Language : English
Service kind : Complete Main
Default : No
Forced : No

Audio #3
ID : 4
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : A_AC3
Duration : 20 s 0 ms
Bit rate mode : Constant
Bit rate : 448 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 16 bits
Compression mode : Lossy
Delay relative to video : 2 ms
Stream size : 1.07 MiB (1%)
Language : English
Service kind : Complete Main
Default : No
Forced : No

Text #1
ID : 5
Format : PGS
Muxing mode : zlib
Codec ID : S_HDMV/PGS
Codec ID/Info : Picture based subtitle format used on BDs/HD-DVDs
Duration : 18 s 143 ms
Bit rate : 65.9 kb/s
Count of elements : 15
Stream size : 146 KiB (0%)
Language : frs
Default : Yes
Forced : No

Text #2
ID : 6
Format : PGS
Muxing mode : zlib
Codec ID : S_HDMV/PGS
Codec ID/Info : Picture based subtitle format used on BDs/HD-DVDs
Duration : 6 s 548 ms
Bit rate : 76.1 kb/s
Count of elements : 4
Stream size : 60.8 KiB (0%)
Language : Spanish
Default : No
Forced : No

Text #3
ID : 7
Format : PGS
Muxing mode : zlib
Codec ID : S_HDMV/PGS
Codec ID/Info : Picture based subtitle format used on BDs/HD-DVDs
Duration : 6 s 548 ms
Bit rate : 60.7 kb/s
Count of elements : 4
Stream size : 48.5 KiB (0%)
Language : French
Default : No
Forced : No

Text #4
ID : 8
Format : PGS
Muxing mode : zlib
Codec ID : S_HDMV/PGS
Codec ID/Info : Picture based subtitle format used on BDs/HD-DVDs
Bit rate : 0 b/s
Count of elements : 0
Stream size : 0.00 Byte (0%)
Language : French
Default : No
Forced : No

Menu
00:00:00.000 : :CapÃ*tulo 09

[Selur]

https://patchwork.ffmpeg.org/patch/11674/ -> Nice, seems like someone is working of decoding support for HDR-10+ in ffmpeg. :)

[nevcairiel]

"Decoding" is a bit much. Reading the metadata is trivial. Doing something useful with it, that's the real challenge.

[SeeMoreDigital]

Yesterday I transferred hajj_3's 20 second sample to a USB pen-drive and got very different playback results using my LG television and OPPO.

On my LG television, although it does not support HDR+, the sample played and displayed regular HDR (HDR10). Which is as expected.
But on my OPPO, which does support HDR10+, although the sample played, no flavour of HDR (HDR10) was detected at all by the player and sent to the TV.

I also tried de-muxing the streams and re-muxing them to different containers and got the same results...

[benwaggoner]

"Decoding" is a bit much. Reading the metadata is trivial. Doing something useful with it, that's the real challenge.
Although it is easier to do good tone mapping with HDR10+ metadata than without it, as the tone mapper can "look into the future" and read the metadata for future frames and thus can know how much headroom to leave per-shot.

[quietvoid]

Hi, since HDR10+ titles started coming out I've been working on extracting the metadata from them.
For now the only purpose is to generate JSON files that x265 can use when reencoding these sources.

So I've made a tool which does just that, extracts the metadata and creates a compatible JSON file for x265.
It outputs a .log file with the raw bytes of every SEI message as well as a .json file with metadata formatted for HDR10+ LLC (not legacy).
HDR10+ LLC is what most current titles have been formatted like for now.

The tool is available on GitHub here: https://github.com/quietvoid/hdr10plus_parser
HDR10+ samples are available in the assets folder, they're also used for regression tests.

Hopefully this is useful for anyone wanting to retain HDR10+ after reencode as well as developers who have ideas about reusing the metadata on decode :)

[hajj_3]

Hi, since HDR10+ titles started coming out I've been working on extracting the metadata from them.
For now the only purpose is to generate JSON files that x265 can use when reencoding these sources.

So I've made a tool which does just that, extracts the metadata and creates a compatible JSON file for x265.
It outputs a .log file with the raw bytes of every SEI message as well as a .json file with metadata formatted for HDR10+ LLC (not legacy).
HDR10+ LLC is what most current titles have been formatted like for now.

The tool is available on GitHub here: https://github.com/quietvoid/hdr10plus_parser
HDR10+ samples are available in the assets folder, they're also used for regression tests.

Hopefully this is useful for anyone wanting to retain HDR10+ after reencode as well as developers who have ideas about reusing the metadata on decode :)

Nice, hopefully you can work with the mediainfo developer(s) to add detection support to that. Does Mkvtoolnix use a mediainfo dll or do they do their own detection as that can't detect hdr10+ either. Would love to see those add detection support.

[FranceBB]

Hi, since HDR10+ titles started coming out I've been working on extracting the metadata from them.
For now the only purpose is to generate JSON files that x265 can use when reencoding these sources.

So I've made a tool which does just that, extracts the metadata and creates a compatible JSON file for x265.
It outputs a .log file with the raw bytes of every SEI message as well as a .json file with metadata formatted for HDR10+ LLC (not legacy).
HDR10+ LLC is what most current titles have been formatted like for now.

The tool is available on GitHub here: https://github.com/quietvoid/hdr10plus_parser

This is exactly what I was looking for!
Thank you very much indeed; it really comes in handy. :D

[mini-moose]

So I've made a tool which does just that, extracts the metadata and creates a compatible JSON file for x265.

Very nice! Thanks for this tool.

Would this only work on an elementary stream (.hevc)?

Also, is it needed to use the --dhdr10-opt switch? I noticed your samples didn't use that.

[quietvoid]

Very nice! Thanks for this tool.

Would this only work on an elementary stream (.hevc)?

Also, is it needed to use the --dhdr10-opt switch? I noticed your samples didn't use that.Yes the input has to be raw HEVC.

For the x265 --dhdr10-opt switch, as far as I lnow it breaks the specifications for proper SMPTE 2094-40 metadata. It (doc (https://www.atsc.org/wp-content/uploads/2018/02/S34-301r2-A341-Amendment-2094-40.pdf)) states that every frame should have a SEI message for it.
And all the titles I have tested have the same number of metadata messages as frames, you can verify the number of lines in the .log file created.

However the samples are encoded with only metadata for the first frame, and are only useful to verify the metadata stays the same as the source after reencoding.
So essentially to make sure the bytes are interpreted correctly in the JSON.

[sneaker_ger]

It states that every frame should have a SEI message for it.
What is "it"? Where can I read "it"?

[quietvoid]

What is "it"? Where can I read "it"?https://www.atsc.org/wp-content/uploads/2018/02/S34-301r2-A341-Amendment-2094-40.pdf
Specifically this part:
The syntax and semantics for payload user_data_registered_itu_t_t35() shall be as specified in [ref
to new Annex described below] section [ref to new Annex, Section 1 described below]. Where
present the corresponding NAL unit type shall be set equal to PREFIX_SEI_NUT.
If a 2094-40 metadata message is present, the following constraints shall apply:
• The 2094-40 metadata message shall be associated with every access unit of the bitstream.
If this message is present, it shall only be present once per access unit

[nevcairiel]

To be fair, this is the ATSC broadcast standard, its not the authoritative standard on all 2094-40 usage, and there is no clear indication that for example Blu-ray discs require the same.

[buratino]

hi,

i create json data in DaVinci Resolve for my hdr video.
How to implement the JSON data in the video?

[benwaggoner]

--dhdr10-info <foo>.json

[buratino]

--dhdr10-info <foo>.json

sorry...
I just started to study this topic. what utility should i use?

[benwaggoner]

sorry...
I just started to study this topic. what utility should i use?
That's the syntax for x265.exe. That will inject the JSON into the SEI messages while encoding the video.

[mini-moose]

That's the syntax for x265.exe. That will inject the JSON into the SEI messages while encoding the video.

Do you have definite opinion if this should be used with --dhdr10-opt or not?

[mariner]

Hi, since HDR10+ titles started coming out I've been working on extracting the metadata from them.
For now the only purpose is to generate JSON files that x265 can use when reencoding these sources.

So I've made a tool which does just that, extracts the metadata and creates a compatible JSON file for x265.
It outputs a .log file with the raw bytes of every SEI message as well as a .json file with metadata formatted for HDR10+ LLC (not legacy).
HDR10+ LLC is what most current titles have been formatted like for now.

The tool is available on GitHub here: https://github.com/quietvoid/hdr10plus_parser
HDR10+ samples are available in the assets folder, they're also used for regression tests.

Hopefully this is useful for anyone wanting to retain HDR10+ after reencode as well as developers who have ideas about reusing the metadata on decode :)

Thank you, quietvoid.

[Selur]

okay so far we can:

verify whether a HEVC file contains HDR-10+ dynamic data (using hdr10plus_parser)
extract existing HDR-10+ dynamic data from a file (using hdr10plus_parser + ffmpeg, in case the video isn't available as raw video)
convert to HDR-10+ using x265 and the corresponding dynamic data

tested the above and they all seem to work fine.

Next question is: How to playback such content on a pc?

Cu Selur

Ps.: Thanks to quietvoid for hdr10plus_parser. Really useful! :)

[nevcairiel]

I'm working on making the HDR10+ metadata available to a renderer when decoding with LAV Video, so eg. madVR could then make use of it. madshi has already expressed interest in making use of it. A timeframe for that is however not available.

[Selur]

@nevcairiel: Thanks for the info. Happy to hear someone is working on it. :)

[jlpsvk]

Another question. Can we crop video, while encoding with HDR10+ metadata?

[nevcairiel]

The HDR10+ metadata references areas of the video, so if you scale or crop it (ie. change its size in any way), you would need to update the metadata accordingly.

[quietvoid]

I'm thinking it's all mostly based on luminance.
There's info about every luminance percentile for a frame and a value associated to it.
However I'm not sure what these values refer to, nor what Average Max RGB is about either.

[jlpsvk]

anyone know, how to update those metadata for cropped encode?

[mini-moose]

extract existing HDR-10+ dynamic data from a file (using hdr10plus_parser + ffmpeg, in case the video isn't available as raw video):)

How is it done with ffmpeg? Example would be much appreciated!

[Selur]

to output the data:
ffmpeg -i "E:\Output\HDR-10+.mp4" -vcodec copy -an -sn -vbsf hevc_mp4toannexb -f rawvideo - | hdr10plus_parser.exe -
just to check whether dynamic data is present
ffmpeg -i "E:\Output\HDR-10+.mp4" -vcodec copy -an -sn -vbsf hevc_mp4toannexb -f rawvideo - | hdr10plus_parser.exe - --verify

[benwaggoner]

anyone know, how to update those metadata for cropped encode?
If you cropped out any image data, it would need to be recalculated.

[jlpsvk]

If you cropped out any image data, it would need to be recalculated.

seems like a bad idea to crop and resize then. :) would stick with uncropped. :)

[benwaggoner]

seems like a bad idea to crop and resize then. :) would stick with uncropped. :)
Resizing is a low-pass filter, and can reduce peak brightness significantly if it is from small details like stars.

[nevcairiel]

Cropping alone wouldn't change the primary image information (assuming you only crop black bars). However, the metadata also references spatial windows in the image, which would get displaced if you crop, so those would at the very least need to be re-positioned.
Without proper tool support to do all of this, I would not bother trying to crop yet.

[jlpsvk]

yeah. :) i was meaning cropping, not resizing. :) so hdr10+ encodes without cropping for now. ;)

[kolak]

Resizing is a low-pass filter, and can reduce peak brightness significantly if it is from small details like stars.

Probably every video when measured for peak brightness should actually go through bit of low pass filtering. This is what some tools do (eg. Cortex).
1 pixel with 2K nits doesn't really mean much, does it?

[mini-moose]

to output the data:
ffmpeg -i "E:\Output\HDR-10+.mp4" -vcodec copy -an -sn -vbsf hevc_mp4toannexb -f rawvideo - | hdr10plus_parser.exe -
just to check whether dynamic data is present
ffmpeg -i "E:\Output\HDR-10+.mp4" -vcodec copy -an -sn -vbsf hevc_mp4toannexb -f rawvideo - | hdr10plus_parser.exe - --verify

Thanks!

hevc_mp4toannexb - does it need to be mp4 or can be mkv too?

[halls]

Hi, since HDR10+ titles started coming out I've been working on extracting the metadata from them.
For now the only purpose is to generate JSON files that x265 can use when reencoding these sources.

So I've made a tool which does just that, extracts the metadata and creates a compatible JSON file for x265.
It outputs a .log file with the raw bytes of every SEI message as well as a .json file with metadata formatted for HDR10+ LLC (not legacy).
HDR10+ LLC is what most current titles have been formatted like for now.

The tool is available on GitHub here: https://github.com/quietvoid/hdr10plus_parser
HDR10+ samples are available in the assets folder, they're also used for regression tests.

Hopefully this is useful for anyone wanting to retain HDR10+ after reencode as well as developers who have ideas about reusing the metadata on decode :)


Thank You!

[Selur]

hevc_mp4toannexb - does it need to be mp4 or can be mkv too?
the bitstream filter has nothing to do with the container, thus it doesn't matter whether the input is an mp4/mkv/m2ts/....

[mini-moose]

the bitstream filter has nothing to do with the container, thus it doesn't matter whether the input is an mp4/mkv/m2ts/....

I tried this:
ffmpeg -i "hdr10plus.sample.mkv" -vcodec copy -an -sn -vbsf hevc_mkvtoannexb -f rawvideo - | hdr10plus_parser.exe - --verify

Unknown bitstream filter hevc_mkvtoannexb

and

ffmpeg -i "hdr10plus.sample.mkv" -vcodec copy -an -sn -vbsf hevc_mp4toannexb -f rawvideo - | hdr10plus_parser.exe - --verify

av_interleaved_write_frame(): Invalid argument
Error writing trailer of pipe:: Invalid argument
frame= 1 fps=0.0 q=-1.0 Lsize= 587kB time=00:00:00.00 bitrate=N/A speed=N/A
video:587kB audio:0kB subtitle:0kB other streams:0kB global headers:1kB muxing overhead: 0.000000%
Conversion failed!

works fine with:
hdr10plus_parser.exe hdr10plus.sample_track1_[und].hevc

I'm probably something wrong. I'm not great with this, which is why I asked for an example :)

[sneaker_ger]

av_interleaved_write_frame(): Invalid argument
Error writing trailer of pipe:: Invalid argument
What does the line directly above it say? Maybe hdr10plus_parser aborts once it finds dynamic data while ffmpeg tries to send the whole stream?

[kolak]

ffmpeg -i "hdr10plus.sample.mkv" -vcodec copy -an -sn -vbsf hevc_mp4toannexb -f rawvideo - | hdr10plus_parser.exe - --verify

av_interleaved_write_frame(): Invalid argument
Error writing trailer of pipe:: Invalid argument
frame= 1 fps=0.0 q=-1.0 Lsize= 587kB time=00:00:00.00 bitrate=N/A speed=N/A
video:587kB audio:0kB subtitle:0kB other streams:0kB global headers:1kB muxing overhead: 0.000000%
Conversion failed!


Looks like you simply use it wrongly:

fmpeg -i "input.mkv" -c:v copy -vbsf hevc_mp4toannexb -f hevc - | hdr10plus_parser.exe -

from parser website as an example.

Source container should not matter. You use -vbsf hevc_mp4toannexb always and then -f hevc, not rawvideo. This command just extracts h265 elementary stream from container and passes to parser (without actually creating file). It's just shorter version of 2 stage process where you first create elementary h265 file from your source and then put it through parser.


update:

I just read it properly and rawvideo or hevc does the same in this case.

[quietvoid]

Using --verify does interrupt ffmpeg, but the error would be broken pipe.

[Selur]

When I call:
ffmpeg -i "e:\Output\with HDR-10+.mp4" -vcodec copy -an -sn -vbsf hevc_mp4toannexb -f rawvideo - | hdr10plus_parser.exe - --verify
I get:

Parsing HEVC file for dynamic metadata...
ffmpeg version N-93064-ged20fbcd48 Copyright (c) 2000-2019 the FFmpeg developers
built with gcc 8.2.1 (Rev1, Built by MSYS2 project) 20181214
configuration: --disable-autodetect --enable-amf --enable-bzlib --enable-cuda --enable-cuvid --enable-d3d11va --enable-dxva2 --enable-iconv --enable-lzma --enable-nvenc --enable-zlib --enable-sdl2 --disable-debug --enable-ffnvcodec --enable-nvdec --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libdav1d --enable-fontconfig --enable-libass --enable-libbluray --enable-libfreetype --enable-libmfx --enable-libmysofa --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libwavpack --enable-libwebp --enable-libxml2 --enable-libzimg --enable-libshine --enable-gpl --enable-avisynth --enable-libxvid --enable-libaom --enable-version3 --enable-mbedtls --extra-cflags=-DLIBTWOLAME_STATIC --extra-libs=-lstdc++ --extra-cflags=-DLIBXML_STATIC --extra-libs=-liconv
libavutil 56. 26.100 / 56. 26.100
libavcodec 58. 46.100 / 58. 46.100
libavformat 58. 26.100 / 58. 26.100
libavdevice 58. 6.101 / 58. 6.101
libavfilter 7. 48.100 / 7. 48.100
libswscale 5. 4.100 / 5. 4.100
libswresample 3. 4.100 / 3. 4.100
libpostproc 55. 4.100 / 55. 4.100
[mov,mp4,m4a,3gp,3g2,mj2 @ 000001cae4f52980] st: 0 edit list: 2 Missing key frame while searching for timestamp: 0
[mov,mp4,m4a,3gp,3g2,mj2 @ 000001cae4f52980] st: 0 edit list 2 Cannot find an index entry before timestamp: 0.
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'e:\Output\with HDR-10+.mp4':
Metadata:
major_brand : hev1
minor_version : 0
compatible_brands: iso4hev1
creation_time : 2019-02-03T13:36:13.000000Z
encoder : Hybrid 2019.02.02.1
Duration: 00:00:47.81, start: 0.000000, bitrate: 10657 kb/s
Stream #0:0(und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown), 3840x2160 [SAR 1:1 DAR 16:9], 10410 kb/s, 24 fps, 24 tbr, 24k tbn, 24 tbc (default)
Metadata:
creation_time : 2019-02-03T13:36:13.000000Z
handler_name : 265#video:fps=24:delay=18@GPAC0.7.2-DEV-rev992-g4d4da2b20-ab-suite
Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, 5.1, fltp, 255 kb/s (default)
Metadata:
creation_time : 2019-02-03T13:29:57.000000Z
Output #0, rawvideo, to 'pipe:':
Metadata:
major_brand : hev1
minor_version : 0
compatible_brands: iso4hev1
encoder : Lavf58.26.100
Stream #0:0(und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown), 3840x2160 [SAR 1:1 DAR 16:9], q=2-31, 10410 kb/s, 24 fps, 24 tbr, 24 tbn, 24 tbc (default)
Metadata:
creation_time : 2019-02-03T13:36:13.000000Z
handler_name : 265#video:fps=24:delay=18@GPAC0.7.2-DEV-rev992-g4d4da2b20-ab-suite
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
Dynamic HDR10+ metadata detected.
av_interleaved_write_frame(): Broken pipe
Error writing trailer of pipe:: Broken pipe
frame= 1 fps=0.0 q=-1.0 Lsize= 32kB time=-00:00:00.04 bitrate=N/A speed=N/A
video:98kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
Conversion failed!

The important output here is the:
Dynamic HDR10+ metadata detected.

when calling:
ffmpeg -i "e:\Output\with HDR-10+.mp4" -vcodec copy -an -sn -vbsf hevc_mp4toannexb -f rawvideo - | hdr10plus_parser.exe -
I get:
Parsing HEVC file for dynamic metadata...
ffmpeg version N-93064-ged20fbcd48 Copyright (c) 2000-2019 the FFmpeg developers
built with gcc 8.2.1 (Rev1, Built by MSYS2 project) 20181214
configuration: --disable-autodetect --enable-amf --enable-bzlib --enable-cuda --enable-cuvid --enable-d3d11va --enable-dxva2 --enable-iconv --enable-lzma --enable-nvenc --enable-zlib --enable-sdl2 --disable-debug --enable-ffnvcodec --enable-nvdec --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libdav1d --enable-fontconfig --enable-libass --enable-libbluray --enable-libfreetype --enable-libmfx --enable-libmysofa --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libwavpack --enable-libwebp --enable-libxml2 --enable-libzimg --enable-libshine --enable-gpl --enable-avisynth --enable-libxvid --enable-libaom --enable-version3 --enable-mbedtls --extra-cflags=-DLIBTWOLAME_STATIC --extra-libs=-lstdc++ --extra-cflags=-DLIBXML_STATIC --extra-libs=-liconv
libavutil 56. 26.100 / 56. 26.100
libavcodec 58. 46.100 / 58. 46.100
libavformat 58. 26.100 / 58. 26.100
libavdevice 58. 6.101 / 58. 6.101
libavfilter 7. 48.100 / 7. 48.100
libswscale 5. 4.100 / 5. 4.100
libswresample 3. 4.100 / 3. 4.100
libpostproc 55. 4.100 / 55. 4.100
[mov,mp4,m4a,3gp,3g2,mj2 @ 000001029e292980] st: 0 edit list: 2 Missing key frame while searching for timestamp: 0
[mov,mp4,m4a,3gp,3g2,mj2 @ 000001029e292980] st: 0 edit list 2 Cannot find an index entry before timestamp: 0.
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'e:\Output\with HDR-10+.mp4':
Metadata:
major_brand : hev1
minor_version : 0
compatible_brands: iso4hev1
creation_time : 2019-02-03T13:36:13.000000Z
encoder : Hybrid 2019.02.02.1
Duration: 00:00:47.81, start: 0.000000, bitrate: 10657 kb/s
Stream #0:0(und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown), 3840x2160 [SAR 1:1 DAR 16:9], 10410 kb/s, 24 fps, 24 tbr, 24k tbn, 24 tbc (default)
Metadata:
creation_time : 2019-02-03T13:36:13.000000Z
handler_name : 265#video:fps=24:delay=18@GPAC0.7.2-DEV-rev992-g4d4da2b20-ab-suite
Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, 5.1, fltp, 255 kb/s (default)
Metadata:
creation_time : 2019-02-03T13:29:57.000000Z
Output #0, rawvideo, to 'pipe:':
Metadata:
major_brand : hev1
minor_version : 0
compatible_brands: iso4hev1
encoder : Lavf58.26.100
Stream #0:0(und): Video: hevc (Main 10) (hev1 / 0x31766568), yuv420p10le(tv, bt709/unknown/unknown), 3840x2160 [SAR 1:1 DAR 16:9], q=2-31, 10410 kb/s, 24 fps, 24 tbr, 24 tbn, 24 tbc (default)
Metadata:
creation_time : 2019-02-03T13:36:13.000000Z
handler_name : 265#video:fps=24:delay=18@GPAC0.7.2-DEV-rev992-g4d4da2b20-ab-suite
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
frame= 1146 fps=127 q=-1.0 Lsize= 60682kB time=00:00:47.66 bitrate=10428.8kbits/s speed= 5.3x
video:60682kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%
Done.
Generating HDR10+ metadata JSON file... Done.

If you are not interessted in the ffmpeg output add '-loglevel quiet' and when calling:
ffmpeg -loglevel quiet -i "e:\Output\with HDR-10+.mp4" -vcodec copy -an -sn -vbsf hevc_mp4toannexb -f rawvideo - | hdr10plus_parser.exe - --verify
you would just get:
Parsing HEVC file for dynamic metadata...
Dynamic HDR10+ metadata detected.

Cu Selur

[benwaggoner]

Probably every video when measured for peak brightness should actually go through bit of low pass filtering. This is what some tools do (eg. Cortex).
1 pixel with 2K nits doesn't really mean much, does it?
If you have bright blue stars in 4K RGB, the peak nits can be reduced a fair amount in a conversion to Y'CbCr 1080p. the brightest single pixel could come out with less than half the initial nits in some edge cases. Compression itself could reduce that farther.

The spec for static metadata (MaxFALL and MaxCLL) requires that the calculations be done in RGB, even though HDR content is always delivered in 4:2:0. It could be argued that metadata should be done based on the highest bitrate for the highest resolution encode, since that's the largest actual values you'd get, and more conservative values will allow more aggressive use of a panel's actual abilities.

However, tone mappers could theoretically use knowledge of the intended values to try to reconstruct those values in tone mapping. I don't know if any do it.

This stuff gets quickly complicated, which is why all good HDR tone mappers required the efforts of many PhDs. Clear specs on what the data is supposed to represent are so essential, and often much less obvious that it seems at first glance.

[kolak]

Yes, it's "slightly" bit more complex than it looks like.
Maybe this is why about every HDR tool reports different values for given source :)

[mini-moose]

When I call:
when calling:
ffmpeg -i "e:\Output\with HDR-10+.mp4" -vcodec copy -an -sn -vbsf hevc_mp4toannexb -f rawvideo - | hdr10plus_parser.exe -
I get:

Generating HDR10+ metadata JSON file... Done.


Thanks. Don't know what is wrong but I still get the same results

"D:\hdr10plus_parser\ffmpeg.exe" -i "D:\hdr10plus_parser\hdr10plus.sample.mkv" -vcodec copy -an -sn -vbsf hevc_mp4toannexb -f rawvideo - | "D:\hdr10plus_parser\hdr10plus_parser.exe" -

Gets me:
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
av_interleaved_write_frame(): Invalid argument
Error writing trailer of pipe:: Invalid argument
frame= 1 fps=0.0 q=-1.0 Lsize= 587kB time=00:00:00.00 bitrate=N/A speed=N/A
video:587kB audio:0kB subtitle:0kB other streams:0kB global headers:1kB muxing overhead: 0.000000%
Conversion failed!

with loglevel quite:
"D:\hdr10plus_parser\ffmpeg.exe" -loglevel quiet -i "D:\hdr10plus_parser\hdr10plus.sample.mkv" -vcodec copy -an -sn -vbsf hevc_mp4toannexb -f rawvideo - | "D:\hdr10plus_parser\hdr10plus_parser.exe" -

I get: "Invalid file path."

[kolak]

Errors says: "Invalid file path.", so looks like parser not getting data.

Does this work:
"D:\hdr10plus_parser\ffmpeg.exe" -i "D:\hdr10plus_parser\hdr10plus.sample.mkv" -vcodec copy -an -sn -vbsf hevc_mp4toannexb -f null -

[mini-moose]

Errors says: "Invalid file path.", so looks like parser not getting data.

Does this work:
"D:\hdr10plus_parser\ffmpeg.exe" -i "D:\hdr10plus_parser\hdr10plus.sample.mkv" -vcodec copy -an -sn -vbsf hevc_mp4toannexb -f null -

this gives:
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
frame= 3583 fps=0.0 q=-1.0 Lsize=N/A time=00:02:29.35 bitrate=N/A speed= 170x
video:821419kB audio:0kB subtitle:0kB other streams:0kB global headers:1kB muxing overhead: unknown

[kolak]

It worked fine, so there is some issue with piping part.
Try changing paths- just in case there is a typo etc.

[quietvoid]

Thanks. Don't know what is wrong but I still get the same results

"D:\hdr10plus_parser\ffmpeg.exe" -i "D:\hdr10plus_parser\hdr10plus.sample.mkv" -vcodec copy -an -sn -vbsf hevc_mp4toannexb -f rawvideo - | "D:\hdr10plus_parser\hdr10plus_parser.exe" -

Gets me:
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
av_interleaved_write_frame(): Invalid argument
Error writing trailer of pipe:: Invalid argument
frame= 1 fps=0.0 q=-1.0 Lsize= 587kB time=00:00:00.00 bitrate=N/A speed=N/A
video:587kB audio:0kB subtitle:0kB other streams:0kB global headers:1kB muxing overhead: 0.000000%
Conversion failed!

with loglevel quite:
"D:\hdr10plus_parser\ffmpeg.exe" -loglevel quiet -i "D:\hdr10plus_parser\hdr10plus.sample.mkv" -vcodec copy -an -sn -vbsf hevc_mp4toannexb -f rawvideo - | "D:\hdr10plus_parser\hdr10plus_parser.exe" -

I get: "Invalid file path."Both of the CLIs you quoted work for me.
Can you try updating to the latest release, 0.2.3 please? I've changed the whole input argument handling so maybe the errors get fixed.
Also which version of ffmpeg are you using? I've been testing using the Zeranoe FFmpeg builds.

This is what I tested with just now:
"ffmpeg.exe" -i ".\input.mkv" -vcodec copy -an -sn -vbsf hevc_mp4toannexb -f rawvideo - | ".\hdr10plus_parser.exe" - -o ".\test.json"

[mini-moose]

Both of the CLIs you quoted work for me.
Can you try updating to the latest release, 0.2.3 please? I've changed the whole input argument handling so maybe the errors get fixed.
Also which version of ffmpeg are you using? I've been testing using the Zeranoe FFmpeg builds.

This is what I tested with just now:
"ffmpeg.exe" -i ".\input.mkv" -vcodec copy -an -sn -vbsf hevc_mp4toannexb -f rawvideo - | ".\hdr10plus_parser.exe" - -o ".\test.json"

Using the static x64 build from zeranoe.

Now updated to the new hdr10plus_parser version and things are looking much better!

"D:\hdr10plus_parser\ffmpeg.exe" -i "D:\hdr10plus_parser\hdr10plus.sample.mkv" -vcodec copy -an -sn -vbsf hevc_mp4toannexb -f rawvideo - | "D:\hdr10plus_parser\hdr10plus_parser.exe" - -o "D:\hdr10plus_parser\test.json"


result:
Reading parsed dynamic metadata... Done.
Writing metadata to JSON file... Done.

then:
"D:\hdr10plus_parser\ffmpeg.exe" -loglevel quiet -i "D:\hdr10plus_parser\hdr10plus.sample.mkv" -vcodec copy -an -sn -vbsf hevc_mp4toannexb -f rawvideo - | "D:\hdr10plus_parser\hdr10plus_parser.exe" -
pause

result:
Parsing HEVC file for dynamic metadata...
Dynamic HDR10+ metadata detected.

but without specifying json save path:
"D:\hdr10plus_parser\ffmpeg.exe" -i "D:\hdr10plus_parser\hdr10plus.sample.mkv" -vcodec copy -an -sn -vbsf hevc_mp4toannexb -f rawvideo - | "D:\hdr10plus_parser\hdr10plus_parser.exe" -

result:
Dynamic HDR10+ metadata detected.
av_interleaved_write_frame(): Broken pipe
Error writing trailer of pipe:: Broken pipe
frame= 1 fps=0.0 q=-1.0 Lsize= 32kB time=00:00:00.00 bitrate=N/A speed=N/A
video:587kB audio:0kB subtitle:0kB other streams:0kB global headers:1kB muxing overhead: unknown
Conversion failed!

Thanks!

[Nico8583]

Hi,
I'm trying to extract metadata with ffmpeg input, it seems to work but it's very slow, it is faster to extract HEVC stream then extract metadata from it but it writes a huge file.
Is it normal ffmpeg method is slower than extract then parse ?
Thank you.

[quietvoid]

Hi,
I'm trying to extract metadata with ffmpeg input, it seems to work but it's very slow, it is faster to extract HEVC stream then extract metadata from it but it writes a huge file.
Is it normal ffmpeg method is slower than extract then parse ?
Thank you.

It's single threaded but limited to I/O. It shouldn't be slow, and (probably) depends on your hard drive.
I can get 450 MB/s (1000 fps) parsing an MKV file with ffmpeg on an SSD.

[Nico8583]

It's single threaded but limited to I/O. It shouldn't be slow, and (probably) depends on your hard drive.
I can get 450 MB/s (1000 fps) parsing an MKV file with ffmpeg on an SSD.
Thank you, I get only 2 FPS when I use it (I use copy to video codec, I don't recode it).
Could you give me the ffmpeg version you use and the command line ? Thank you.

[quietvoid]

Thank you, I get only 2 FPS when I use it (I use copy to video codec, I don't recode it).
Could you give me the ffmpeg version you use and the command line ? Thank you.

Zeranoe FFmpeg builds should work, there's an example CLI:
ffmpeg -i "input.mkv" -c:v copy -vbsf hevc_mp4toannexb -f hevc - | hdr10plus_parser.exe -

[Nico8583]

Thank you, I just replaced an old ffmpeg with the newest version and now I get 500 fps instead of 50 fps...

[mini-moose]

double post by mistake. can be deleted.

[mini-moose]

hi quietvoid

I was playing around with a recent hdr10+ disc I got.

The tool dialog added something called "Mastering peak flag enabled":
Parsing HEVC file for dynamic metadata...
[00:02:25] 100%
Reading parsed dynamic metadata... Mastering peak flag enabled
Mastering peak flag enabled
Mastering peak flag enabled
Mastering peak flag enabled
Mastering peak flag enabled
Done.
Writing metadata to JSON file... Done.
the "Mastering peak flag enabled" repeats about 40-50 times.

Then I tried to serve the json to x265 and encode the vid.
Looked at the MediaInfo report and it shows just this:
HDR format : SMPTE ST 2094 App 4, Version 1

On previous encodes I did show up like this:
HDR format : SMPTE ST 2094 App 4, Version 1, HDR10+ Profile A compatible
or
HDR format : SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible
From the little I understand, it appears it can't recognize it as hdr10+

[quietvoid]

hi quietvoid

I was playing around with a recent hdr10+ disc I got.

The tool dialog added something called "Mastering peak flag enabled":
Parsing HEVC file for dynamic metadata...
[00:02:25] 100%
Reading parsed dynamic metadata... Mastering peak flag enabled
Mastering peak flag enabled
Mastering peak flag enabled
Mastering peak flag enabled
Mastering peak flag enabled
Done.
Writing metadata to JSON file... Done.
the "Mastering peak flag enabled" repeats about 40-50 times.

Then I tried to serve the json to x265 and encode the vid.
Looked at the MediaInfo report and it shows just this:
HDR format : SMPTE ST 2094 App 4, Version 1

On previous encodes I did show up like this:
HDR format : SMPTE ST 2094 App 4, Version 1, HDR10+ Profile A compatible
or
HDR format : SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible
From the little I understand, it appears it can't recognize it as hdr10+ Hi, thanks for the feedback.

That part of the metadata was not implemented, I can't remember whether it was in the specs sheet I was using.

If it was, I did note that it was not supposed to be enabled in the version's specs.

So it is possible there is a new version of the spec, where some of these flags are actually being used now.

I had received some feedback regarding a disc failing to parse recently, but I have not had the time to look into it.
Can you share the title? If I remember correctly it was Shaun of the Dead.

Thanks.

Edit: I have done a bit of research and it seems the HDR10+ LLC alliance has published a press release on 2019/09/04.

Released this month is an updated Technical Specification to respond to industry’s request of new device categories and codecs as well as a comprehensive whitepaper to introduce the technology and it’s benefit to new adopters

So there's likely no access for now, even x265 will likely need to update their implementation.

[mini-moose]

I had received some feedback regarding a disc failing to parse recently, but I have not had the time to look into it.
Can you share the title? If I remember correctly it was Shaun of the Dead.

Thanks.

Edit: I have done a bit of research and it seems the HDR10+ LLC alliance has published a press release on 2019/09/04.


I figured out the issue with x265, but like you said, the json made with this new hdr10+ profile may not have all that is required to work properly.

[quietvoid]

I figured out the issue with x265, but like you said, the json made with this new hdr10+ profile may not have all that is required to work properly.Turns out your issue was an edge case. :D

Updated the parser to 0.2.4
Fix edge case when AverageRGB, MaxScl are 0 but not targeted_system_display_maximum_luminance.
Add asserts to avoid invalid data.
Error when the dynamic metadata is from a (possibly) unsupported version.
https://github.com/quietvoid/hdr10plus_parser/releases

[mini-moose]

Turns out your issue was an edge case. :D

Updated the parser to 0.2.4

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

thanks for the update!

Edge case you mean why I couldn't get x265 to identify hd10+ without cutting out the first second?

[quietvoid]

thanks for the update!

Edge case you mean why I couldn't get x265 to identify hd10+ without cutting out the first second?The edge case was present in the first second so the JSON was most likely invalid for the first second.
So now if the parser doesn't error, the metadata should be valid.

[PapitaHD]

Hi all,
First of all let me thank quietvoid for the hdr10+ parser, works great and very easy to use!
My only issue is the same that mini-moose mentioned a few posts back. I'm trying to encode the quite recent American Gangster BD which has hdr10+. I used the parser as advised to get the json file with the metadata, but after encoding the movie, the resulted file doesn't have the hdr10+ flag in mediainfo. It shows: SMPTE ST 2094 App 4.
What can be the issue, maybe the parser needs another update?
Thanks in advance! :)

[quietvoid]

Sorry, I hadn't seen your post.
As far as I'm aware, HDR10+ is a format in conformance with SMPTE ST 2094 App 4.

MediaInfo sometimes includes a HDR10+ profile compatibility, but I have no idea what they mean.
The "HDR10+ profile A/B compatible" flag seems to be lost after reencode sometimes, however the presence of ST2094 App 4 metadata is still detected.
It mostly happens with titles released after the September 4 2019 specifications release.

If anyone has information regarding the HDR10+ profiles, it would be useful.
Otherwise I don't really know what is missing for HDR10+ profiles compatibility.

[mini-moose]

MediaInfo sometimes includes a HDR10+ profile compatibility, but I have no idea what they mean.
The "HDR10+ profile A/B compatible" flag seems to be lost after reencode sometimes, however the presence of ST2094 App 4 metadata is still detected.
It mostly happens with titles released after the September 4 2019 specifications release.

Maybe another edge case like mine had?

[quietvoid]

Well, the metadata gets parsed correctly.
There might be some data missing (in the JSON or after x265's encode) but without the new specifications or an updated example JSON I don't know what the difference would be.

[quietvoid]

Sorry for the double post.
I've tested with the x265 example and it always has HDR10+ Profile B compatible.
Turns out it's not being flagged if there is no BezierCurveData object in the JSON.
So added it (it used to only be added when there is actual data for it), and refactored the code to be more readable. Also improved the JSON to be properly generated.

Fixed the cargo run not working, tested that all the input/output arguments work just like before. Hopefully nothing breaks.

Updated to 0.2.5
https://github.com/quietvoid/hdr10plus_parser/releases

[PapitaHD]

Thanks a lot, it's working perfeclty now!
I encoded The Shining and American Gangster with hdr10+ successfully and I'm gonna test it on Ad Astra as soon as it's out.

[quietvoid]

Further more, I just stumbled across this in the September 2019 White Paper from https://hdr10plus.org/wp-content/uploads/2019/08/HDR10_WhitePaper.pdf
No matter the workflow used, HDR10+ technology can support the full range of HDR standards to 10,000 cd/m2, 8K and BT.2020 color gamut.
Being resolution agnostic, metadata needs to be created only once and can be applied to any target resolution.So it seems there should be no problem with cropping and/or resizing.

[nevcairiel]

So it seems there should be no problem with cropping and/or resizing.

Actually with cropping you would need to adjust the metadata, but resizing should be fine, as long as the relative dimensions and aspect ratio stay the same (but to change that you would probably crop anyway).

[quietvoid]

Actually with cropping you would need to adjust the metadata, but resizing should be fine, as long as the relative dimensions and aspect ratio stay the same (but to change that you would probably crop anyway).

I still think there's nothing relevant to the resolution/aspect ratio in the current version.
The Bezier curve data specifies info for the curve generation only.
The processing windows (which do mention pixel coordinates) are not in this version.
The only thing that might need adjustment is the average/max RGB values if they were calculated with the black bars not accounted for.

Unless I'm missing something..

[nevcairiel]

Oh, I didn't check what might be in there, I only remember from implementing HEVC metadata parsing that it contains the processing windows - on second thought they would probably also need adjustment for scaling, but thats easier since you just have to scale their coordinates.
But even then, resizing the processing windows is trivial, what the Whitepaper refers to would indicate actually having to determine full new metadata, which can be avoided that way.

[jlpsvk]

just a question... shoudn't be then all HDR video encoded without cropping? average CLL and MAX-CLL are calculated with the black bars, if I am right. so without it, it could cause playing somehow different, as with black bars... it's just my quess...

[Selur]

average CLL and MAX-CLL are calculated with the black bars, if I am right. so without it, it could cause playing somehow different, as with black bars... it's just my quess...
not according to:
MaxFALL/MaxCLL metadata is calculated on active picture only. Black mattes are not processed during the calculation.
source: https://www.linkedin.com/pulse/hdr-10-metadata-smpte-st2086-maxfall-maxcll-carlos-carmona

shoudn't be then all HDR video encoded without cropping?
How I see it:
1. Maximum Frame--Average Light Level (MaxFALL) and Maximum Content Light Level (MaxCLL) are maxima and thus should not change if you remove black borders.
2. The dynamic metadata of HDR10+ can change dynamically, based on the minimum, maximum and average luminance and gamut requirements for each scene. Thus resizing, cropping and other frame alternations would need to recalculate those metadata.



Cu Selur

[jlpsvk]

not according to:

source: https://www.linkedin.com/pulse/hdr-10-metadata-smpte-st2086-maxfall-maxcll-carlos-carmona


How I see it:
1. Maximum Frame--Average Light Level (MaxFALL) and Maximum Content Light Level (MaxCLL) are maxima and thus should not change if you remove black borders.
2. The dynamic metadata of HDR10+ can change dynamically, based on the minimum, maximum and average luminance and gamut requirements for each scene. Thus resizing, cropping and other frame alternations would need to recalculate those metadata.



Cu Selur

Thanks for that point of view. :)

[benwaggoner]

not according to:

source: https://www.linkedin.com/pulse/hdr-10-metadata-smpte-st2086-maxfall-maxcll-carlos-carmona


How I see it:
1. Maximum Frame--Average Light Level (MaxFALL) and Maximum Content Light Level (MaxCLL) are maxima and thus should not change if you remove black borders.
Correct that they do not change. This doesn't matter for MaxCLL. But for MaxFALL, everything outside of the active image area must be discarded or else the FALL will be really dragged down but big black rectangles.

2. The dynamic metadata of HDR10+ can change dynamically, based on the minimum, maximum and average luminance and gamut requirements for each scene. Thus resizing, cropping and other frame alternations would need to recalculate those metadata.
Incorrect. The dynamic metadata is calculated on the source, and needs to be identical for any adaptive bitrate streams irrespective of frame size or compression. Otherwise the tone mapper would do weird things when bitrate changes.

[Selur]

Incorrect. The dynamic metadata is calculated on the source, and needs to be identical for any adaptive bitrate streams irrespective of frame size or compression. Otherwise the tone mapper would do weird things when bitrate changes.
Okay, so resizing doesn't matter, but also cropping? (don't really know what how the dynamic data is calculated)

Correct that they do not change. This doesn't matter for MaxCLL. But for MaxFALL, everything outside of the active image area must be discarded or else the FALL will be really dragged down but big black rectangles.
As I understood it MaxCLL and MaxFALL both should only be calculated by taking the active picture into account so, cropping should not change anything for both of them,....

[benwaggoner]

Okay, so resizing doesn't matter, but also cropping? (don't really know what how the dynamic data is calculated)
Well, resizing matters. It just is ignored per spec. It yields some weird things, like calculating the metadata on an 8K master would yield higher values than on a 4K master for an HDR UHD Blu-ray. It doesn't seem right that the metadata should be determined by the master, but instead by the highest frame size that will be delivered.

As I understood it MaxCLL and MaxFALL both should only be calculated by taking the active picture into account so, cropping should not change anything for both of them,....
Well, black bars won't impact MaxCLL. But yes, MaxFALL should only be on active picture area. Which can yield some strange results; a movie than is 2.4:1 except for credits would theoretically have a much lower MaxFALL than one where everything is 2.4:1, since "active image" would be 16:9 if any is 16:9.

HDR10+ is way more useful than just having static MaxFALL and MaxCLL values for a whole title.

[blublub]

I have about 10 HDR movies and I cropped all of them. I haven't noticed anything weird and I look at pictures all day long in my job and usually spot imperfection before my friends do, so I guess cropping is fine

[jlpsvk]

I have about 10 HDR movies and I cropped all of them. I haven't noticed anything weird and I look at pictures all day long in my job and usually spot imperfection before my friends do, so I guess cropping is fine

cropping HDR10 is OK, cropping HDR10+ not.

[Variant]

I’ve read through this thread and have a question about discs that contain both HDR10+ and Dolby Vision. Is there some means of removing HDR10+ metadata entirely from a full disc backup while leaving Dolby Vision information intact for discs that offer both HDR formats?

An Oppo defaults to HDR10+ over Dolby Vision when the display supports both HDR10+ and DV. I am curious to see if it’s possible to simply remove the HDR10+ metadata/flags, so it would play DV.

[benwaggoner]

I’ve read through this thread and have a question about discs that contain both HDR10+ and Dolby Vision. Is there some means of removing HDR10+ metadata entirely from a full disc backup while leaving Dolby Vision information intact for discs that offer both HDR formats?

An Oppo defaults to HDR10+ over Dolby Vision when the display supports both HDR10+ and DV. I am curious to see if it’s possible to simply remove the HDR10+ metadata/flags, so it would play DV.
HDR10+ is a SMPTE 2094 SEI message, while DV is in NAL units. So if you have a tool that can strip specific types of SEI messages, that should do it.

I've not heard of anyone actually ever doing this, though.

[jlpsvk]

HDR10+ is a SMPTE 2094 SEI message, while DV is in NAL units. So if you have a tool that can strip specific types of SEI messages, that should do it.

I've not heard of anyone actually ever doing this, though.

yeah... for now the only way is to make lossless re-encode without dhdr10 metadata and mux to mp4 with DoVi layer.

[Selur]

So if you have a tool that can strip specific types of SEI messages, that should do it.
Never tried it, but it should be possible with FFmpegs Bitstream filter (https://ffmpeg.org/ffmpeg-bitstream-filters.html) and 'remove_types'.

Cu Selur

[SeeMoreDigital]

So if you have a tool that can strip specific types of SEI messages, that should do it.

I've not heard of anyone actually ever doing this, though.Never tried it, but it should be possible with FFmpegs Bitstream filter (https://ffmpeg.org/ffmpeg-bitstream-filters.html) and 'remove_types'.Back in the days when MPEG-2 video ruled the world, shh created a tool called ReStream (v0.9.0). It's a shame nobody got around to creating a similar type of tool for h264 and now h265 elementary video streams...

[imhh11]

should we use both --hdr10-opt and --dhdr10-opt for HDR10+ encoding or should we just use --dhdr10-opt ?

[hellgauss]

not according to:

source: https://www.linkedin.com/pulse/hdr-10-metadata-smpte-st2086-maxfall-maxcll-carlos-carmona


How I see it:
1. Maximum Frame--Average Light Level (MaxFALL) and Maximum Content Light Level (MaxCLL) are maxima and thus should not change if you remove black borders.
2. The dynamic metadata of HDR10+ can change dynamically, based on the minimum, maximum and average luminance and gamut requirements for each scene. Thus resizing, cropping and other frame alternations would need to recalculate those metadata.

Cu Selur

This seems strange. How the "active area" informations for maxfall is detected on the source and put into the output? There is some info in the source that should be handled? There is some information that should be put into the output stream?

How the player detects the active area?

Furthermore, a question on hdr10+ : in a rip, I found a parameter "AverageRGB" in the .json file. Does it check the "active area" informations as maxfall does?

As for the information I have, I think that hdr streams should not be re-encoded. Available references and guides are not clear.

[benwaggoner]

should we use both --hdr10-opt and --dhdr10-opt for HDR10+ encoding or should we just use --dhdr10-opt ?
They do different things; use both.

--hdr10-opt adjusts adaptive quantization to provide better compression efficiency using PQ in SMPTE 2100 content. Works equally well for classic HDR-10 and with HDR10+.

--dhdr10-opt reduces SEI overhead by only putting the HDR10+ dynamic metadata in only the IDR and frames where the values have changed. It saves a few bits and can help performance in the client's tonemapper.

[Blue_MiSfit]

HDR10+ is way more useful than just having static MaxFALL and MaxCLL values for a whole title.

Really?

I'm surprised by this. I haven't actually had any experience with it, but the dynamic metadata only seems useful (to me) when dealing with content mastered to very high light levels that exceed the capabilities of a given display. For example, content mastered to a 2000 nit peak being displayed on a ~700 nit display (like an LG OLED for example). In this case, only the brightest specular highlights would likely exceed 700 nits. Based on that, I could see having precise tone mapping metadata defined being helpful to improve highlight detail, but that's about it.

Is your experience different?

Everything I've read said its a very small improvement on HDR10, and that going to full fat Dolby Vision (e.g. Profile 5) is a much bigger improvement. I do have a lot of experience with that and am generally more sold on Dolby Vision as a solution for OTT in general, given the dynamic shaping into 10 bit IPT during encoding and 16 bit RGB reconstruction in the TV, plus Dolby having more control over the TV processing (versus often terrible processing rife with unnecessary format conversions that would otherwise engage).

[benwaggoner]

Really?

I'm surprised by this. I haven't actually had any experience with it, but the dynamic metadata only seems useful (to me) when dealing with content mastered to very high light levels that exceed the capabilities of a given display. For example, content mastered to a 2000 nit peak being displayed on a ~700 nit display (like an LG OLED for example). In this case, only the brightest specular highlights would likely exceed 700 nits. Based on that, I could see having precise tone mapping metadata defined being helpful to improve highlight detail, but that's about it.
HDR10+ specifies the metadata, not how the tone mapper will use that information, so its behavior will be less predictible than Dolby Vision, where Dolby provides the tone mapper and certification as well.

There are two ways static metadata can be used - on-device player and over HDMI. Over HDMI is more limited as you don't get much lookahead - maybe you get the metadata one frame ahead. When it's in-player the bitstream itself stores the metdata in the clear, and it can be extracted from the whole GOP in advance, or even from future GOPs. That allows the tone mapper to know how much headroom it needs to leave for future variability. Take, for example, your 700 nit display playing content with a MaxCLL of 2000. Using just static metadata, it might have 700 nits map to 600 nits, and then save 600-700 as a rolloff region so you don't get a big flat white blob on highlights. But if the tonemapper knows that the whole shot doesn't have anything above 600, it can go all the way up to 700 for that shot.

Also, it's not just about luminance but also chrominance. Because of how RGB color volumes work, the higher the peak brightness that can be played, the more saturated colors can be farther from the luma midpoint. And plenty of cheaper HDR displays can't do P3 all the way up past 1000 nits. Those displays also need headroom for chroma, so maybe it'll only go up to 90% of saturation most of the time in case there's some stuff up against the master-display color volume. If the tonemapper knows what the most saturated colors in a given shot are, it can go right up to the maximum the display can show without leaving any headroom. This can be a big deal, since limited chroma gets into tradeoffs of reducing saturation (better) or shifting hue (worse).

Everything I've read said its a very small improvement on HDR10, and that going to full fat Dolby Vision (e.g. Profile 5) is a much bigger improvement. I do have a lot of experience with that and am generally more sold on Dolby Vision as a solution for OTT in general, given the dynamic shaping into 10 bit IPT during encoding and 16 bit RGB reconstruction in the TV, plus Dolby having more control over the TV processing (versus often terrible processing rife with unnecessary format conversions that would otherwise engage).
This is really going to depend on content, display, and tonemapper. Dolby Vision is going to be more reliably decent. But equally good HDR10+ and Dolby Vision tonemappers should produce pretty similar quality results.

One other advantage of HDR10+ is it has lower complexity than DoVi. DoVi Profile 5 requires constructing a new intermediate frame based on the non-backwards compatible base layer, the dynamic metadata, and display characteristics. While that can be done with HDR10+, it's also possible to just decode the HDR10 base layer and then use the tonemapper for everything else. Which is why some devices might only be able to do DoVi Profile 3 to 24p, Profile 5 to 30p, and HDR10+ to 60p.

This can also save power on mobile devices.

HDR10+ can save power/compute relative to HDR10 original flavor, because the decoded frame doesn't need to be analyzed to determine its luma and chroma ranges; that can be just read from the metadata.

[Blue_MiSfit]

Great info, thanks for sharing. I do see how HDR10+ vs HDR10 can be significantly better when dealing with tone mapping. You brought up some interesting points regarding HDR10+ vs Dolby Vision.

I do have one question though:

some devices might only be able to do
DoVi Profile 3 to 24p, Profile 5 to 30p, and HDR10+ to 60p.


Just a sanity check, on the above you meant level 3 / 5 etc, not profile, right? Profile 3 isn't a thing, but levels 3 and 5 both make sense in the context of DoVi Profile 5.

https://www.dolby.com/us/en/technologies/dolby-vision/dolby-vision-profiles-levels.pdf

Are you aware of any DoVi supporting devices that are Profile 5 compatible that are not at least Level 5 compliant (4k @ 30 fps)

Your note about power consumption is quite interesting. I wonder how a mobile device with good DoVi support (like a current iOS device) would fare with DoVi vs HDR10. If only Apple supported HDR10+ :)

I also got the sense that DoVi would do a better job than HDR10 / HDR10+ when below the tone mapping curve, due to the higher quality offered by their reconstructed frame, at least theoretically. In practice the wildly different shaped IPT frame required some special tuning on our side to avoid additional banding relative to an HDR10 reference!

[benwaggoner]

Just a sanity check, on the above you meant level 3 / 5 etc, not profile, right? Profile 3 isn't a thing, but levels 3 and 5 both make sense in the context of DoVi Profile 5.

https://www.dolby.com/us/en/technologies/dolby-vision/dolby-vision-profiles-levels.pdf
Profile 3 was the original HEVC 8-bit base layer + 8-bit enhancement layer profile that no one uses anymore.

Are you aware of any DoVi supporting devices that are Profile 5 compatible that are not at least Level 5 compliant (4k @ 30 fps)
No, they can all do 30p at least. There are some devices that can only do Profile 3 up to 24p, Profile 5 to 30p, and HDR10 to 60p.

Your note about power consumption is quite interesting. I wonder how a mobile device with good DoVi support (like a current iOS device) would fare with DoVi vs HDR10. If only Apple supported HDR10+ :)
Apple writes their own DoVi stack; the only vendor I know of who doesn't use Dolby's. So I'm not sure how their model works. Apple can do some deeper hardware integration that is generally feasible on Android without a lot of work from the OEM.

I also got the sense that DoVi would do a better job than HDR10 / HDR10+ when below the tone mapping curve, due to the higher quality offered by their reconstructed frame, at least theoretically. In practice the wildly different shaped IPT frame required some special tuning on our side to avoid additional banding relative to an HDR10 reference!
In theory, yes. Although I don't know how many systems really follow the best practices to render into a 12-bit intermediate space prior to tone mapping. Given how few devices have a truly >8-bit display controller and panel, some dithering is pretty much always in play that would keep the 12-bit from being really that much better. But there is so much weird handwaving in the bitstream-to-glass process in real devices.

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.

[Blue_MiSfit]

Profile 3 was the original HEVC 8-bit base layer + 8-bit enhancement layer profile that no one uses anymore.


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


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.


That would indeed be the real deal. As long as all the optional display processing features stay in that half-float space and don't do any conversions!

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....

[SeeMoreDigital]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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. :thanks: Saves me a ton of work trying to figure it out each time. And thanks be to Don, of course, for adding it.

[Ripmann]

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]

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.