Pass over HDR10+ and Dolby Vision information?

[quietvoid]

Hey, I'm lost now. What dual-track mkv do you mean that MakeMKV is supporting? Don't tell me it's the non-working dual-track I created earlier with mkvtoolnix?

Yea that one. :)

[von Suppé]

Wow, never thought of that one :D
After import in MakeMKV, this is the log:

- -
MakeMKV v1.16.5 win(x64-release) started
Debug logging enabled, log will be saved as C:\Users\*****/MakeMKV_log.txt
Opening files on harddrive at F:/TEST/DoVi recode/mkvtoolnix/dualtrack.mkv
Hack: Found secondary video stream with RPU, assuming DV EL
Hack: Attaching DV data from second video track to first one and discarding second video track
DEBUG: Code 458759 at U<hG.C@S9^8eLY`6$OjL:213137229
Operation successfully completed
- -

Should I be worried about the bold part?

When I import the ISO that is muxed together with the exact same streams as in the dual-track mkv, MakeMKV log does not show any of the two lines beginning with "Hack: ..."
The first line I can understand of course. But TBH, without the second one I feel more comfortable.

[quietvoid]

It just means that the second track isn't added, because it was merged with the first one.
It's probably just a warning specifically for MKV input.

[shroomM]

It should be possible to do 8 to MEL now, using the git main branch.
I'll update this with a link to binaries soon.

See here for binaries: https://github.com/quietvoid/dovi_tool/actions/runs/1435034743

Wow, that was fast, thank you!

I successfully converted a 8.1 RPU to 7 RPU, injected that into my dummy MEL, muxed to Bluray folder with tsMuxer and played it back on an Oppo 203 clone.

The video plays for a while, Dolby Vision is triggered (LG C9 TV), but I think I need to tweak my MEL and check if all the frames are exactly the same type - it seems as if i'm getting some decoding errors on playback after a while. Maybe I'm missing something when creating the MEL.

[shroomM]

OK, I think i figured out what was wrong - I was using the demux command on a BL+RPU HEVC stream, which seems to produce a corrupted BL.hevc.

I'm currently struggling with one thing - I believe I need to strip RPU from my BL, but as far as I understand this is not currently possible with the dovi_tool, right?

Maybe I'm off here, but if my source is 8.1 BL+RPU and I want to convert that to 7 BL and EL+RPU, I need to strip the RPU from the BL, no?

[quietvoid]

OK, I think i figured out what was wrong - I was using the demux command on a BL+RPU HEVC stream, which seems to produce a corrupted BL.hevc.

I'm currently struggling with one thing - I believe I need to strip RPU from my BL, but as far as I understand this is not currently possible with the dovi_tool, right?

Maybe I'm off here, but if my source is 8.1 BL+RPU and I want to convert that to 7 BL and EL+RPU, I need to strip the RPU from the BL, no?

demux shouldn't be producing a corrupted stream regardless of BL+RPU or BL+EL+RPU.
It removes both 62/63 type NALUs, resulting in a HDR10 only file.

It should be doing what you're looking for.

If you can reproduce corruption where demux is at fault, then I'd need a sample file.
The only corruptions I've come across so far was when using ffmpeg to demux the initial file.

[shroomM]

demux shouldn't be producing a corrupted stream regardless of BL+RPU or BL+EL+RPU.
It removes both 62/63 type NALUs, resulting in a HDR10 only file.

It should be doing what you're looking for.

If you can reproduce corruption where demux is at fault, then I'd need a sample file.
The only corruptions I've come across so far was when using ffmpeg to demux the initial file.

OK, good to know, thank you! I remember reading a post of yours about potential ffmpeg problems before, yes.

I will start from the beginning and see if I can pinpoint and reproduce the corruption and let you know if I can produce a sample for you.

[shroomM]

It was ffmpeg.

My source is Profile 8.1 in an MKV.

Using ffmpeg to extract and pipe the video to dovi_tool produces corrupted BL. Using mkvextract to get the video and feed that into dovi_tool fixes all the problems.

I'll try to produce a sample and submit a bug to ffmpeg.

Thanks for all the pointers!

[von Suppé]

I have done some re-encodings and metadata handling and am rather familiar now with the workflow. Having limited knowledge about every x265 parameter, generally I use --uhd-bd to be safe for HW players, together with --crf for quality settings.
I want to try some encodings outside of the uhd-bd compatibility. Are there specific parameters or settings to keep an eye on, in the context of adding HDR10+ and/or DoVi metadata?

[Boulder]

Depends on the HW player. I'd expect some SoC solution not worrying too much about anything as long as it can decode the HEVC video stream in hardware. To be on the safe side, you could set the VBV settings based on the level.

[von Suppé]

To be on the safe side, you could set the VBV settings based on the level.
Thanks Boulder. I wonder if I could unknowingly set too high a buffer or maxrate, specifically in regard to the second videostream, in case of Dolby Vision with FEL. Next to RPU metadata it holds differential videodata that a DV capable player can "add to" the 10bit baselayer in order to get full 12 bit colordepth. FEL bitrates are generally between 5 and 8 Mb/s. I wonder by setting vbv params high (too high) I'd possibly introduce buffering issues in the playback device.

[EDIT] @quietvoid: Are there constrictions to how the input is written in the "dovi_tool demux file.hevc" code?

Always using *.hevc - I experience seemingly erratic behaviour on acceptance of inputs other than "file.hevc" (which always works). As in no output.

[benwaggoner]

Depends on the HW player. I'd expect some SoC solution not worrying too much about anything as long as it can decode the HEVC video stream in hardware. To be on the safe side, you could set the VBV settings based on the level.
Yeah, unless you are trying to make an actual UHD Blu-ray disc itself, using Main Tier and an appropriate level should be more than sufficient.

[quietvoid]

Always using *.hevc - I experience seemingly erratic behaviour on acceptance of inputs other than "file.hevc" (which always works). As in no output.

There should be an error if the file doesn't end in .hevc/h265/265.

[von Suppé]

There should be an error if the file doesn't end in .hevc/h265/265.
No errors, I always use .hevc files. It's the name itself it seems. I wonder if it has restriction as in word-length or such.

Example: With gMKVExtract I demux a 1 track dual layer mkv. The resulting videostream I rename to gmkvextract.hevc.
Putting that in the demux command and running it, the commandwindow immediately closes again and doesn't yield any output. Renaming the stream to file.hevc and adjusting the commandline, the commandwindows stays working and it does result in BL and EL.
Note that in the workfolder I only have your dovi_tool.exe, the .cmd file and the concerning .hevc file of course. Has it something to do with Windows 7 64 bit maybe?

[quietvoid]

It might be because of the mkv in the name, but I thought I fixed that.

[von Suppé]

It might be because of the mkv in the name, but I thought I fixed that.

Hey, I think that's it. Tried 3 times with mkv in it. No dice. Glad you found it.
No worries, I know what to look out for now.
Thank you.

[quietvoid]

It should be fixed in 1.2.1.
Turns out I only fixed it in the HDR10+ tool.

[von Suppé]

It should be fixed in 1.2.1.
It is, works like a charm. Thanks for the fix :)

[shodan5000]

Would anyone happen to know if a GUI for dovi_tool is being worked on? I've tried to learn the CLI method and simply can't figure it out. A GUI for the hdr10plus_tool was created and that helped immensely.

[von Suppé]

A GUI for the hdr10plus_tool was created and that helped immensely.
I didn't know this. Could you provide a link on where to download?

[shodan5000]

I didn't know this. Could you provide a link on where to download?
https://github.com/jlw4049/HDR10Plus-Tool-Gui/releases

[von Suppé]

Thanks for the link.
I don't understand how to inject with this GUI. Could you tell me?

[shodan5000]

Thanks for the link.
I don't understand how to inject with this GUI. Could you tell me?
Open the application "HDR10PlusParser" and use the user interface to select your HDR10+ video file. Let it run through its process and it will have created a JSON file within the same folder/directory as the video file. The JSON file is what you will select to "inject" in a capable encoder. I use StaxRip personally. Jump over to the StaxRip thread for further details on its particular process of using the JSON file if that is the software you use or want to try.

[von Suppé]

Ah, I should have said that extracting isn't the problem, but I couldn't figure out how to inject with that same GUI.
I am quite accustomed to use cli with very basic scripts now. It's not so hard to get the gist of it.

[von Suppé]

@quietvoid: I came across your post about remuxing HDR10+ to HDR10 here: https://forum.doom9.org/showthread.php?p=1932777#post1932777 which removes HDR10+ metadata, leaving HDR10.

I really feel this options belongs to your HDR10+ tool. If it's possible, is it weird/bold to ask you for implementing it?

[kolak]

If TV doesn't do HDR10+ then it will simply skip it, so what is the point removing it ?

[Nico8583]

If the TV does HDR10+ and DoVi, it seems to have an issue with some TV so perhaps the reason ?!

[von Suppé]

If TV doesn't do HDR10+ then it will simply skip it, so what is the point removing it ?
For me ATM, educational reasons. Additionally, it may come in handy for people having certain player's Dolby Vision issues when both HDR10+ metadata and RPU are present.
Regardless of Dolby Vision, also - as described in the thread I linked - to be able to solve other playback issues of HDR10+ content.

[quietvoid]

@quietvoid: I came across your post about remuxing HDR10+ to HDR10 here: https://forum.doom9.org/showthread.php?p=1932777#post1932777 which removes HDR10+ metadata, leaving HDR10.

I really feel this options belongs to your HDR10+ tool. If it's possible, is it weird/bold to ask you for implementing it?

To be honest it doesn't need an implementation in hdr10plus_tool.
You can just use any of demux/convert in dovi_tool with the new --drop-hdr10plus flag.
It doesn't matter if the video has Dolby Vision or not.

It's not in a release yet, though.


If TV doesn't do HDR10+ then it will simply skip it, so what is the point removing it ?

In a perfect world that would be the case. But some devices still cause problems.

[kolak]

If the TV does HDR10+ and DoVi, it seems to have an issue with some TV so perhaps the reason ?!

Ok. Did not think about it this way.
Understand that for testing etc. it may be useful.

[von Suppé]

You can just use any of demux/convert in dovi_tool with the new --drop-hdr10plus flag.
It doesn't matter if the video has Dolby Vision or not.

It's not in a release yet, though.
Great! I'll be patient. Thanks a bunch.

[Sosok]

Good afternoon, please tell me how to edit the rpu.bin (dolby vision) file to add it to the encoder when making a rip. The source file is 3840x2160, and the final one will be 3840x1608.

[shodan5000]

Good afternoon, please tell me how to edit the rpu.bin (dolby vision) file to add it to the encoder when making a rip. The source file is 3840x2160, and the final one will be 3840x1608.

Best of luck getting an answer around here.

[von Suppé]

One can of course take effort to read this thread: https://forum.doom9.org/showthread.php?p=1951093#post1951093

[cool advertise]

An x265 encode, encoded as both dolby vision profile 8.1, and as hdr10+, will play as dolby vision in supported devices, otherwhise as hdr10+ if supported, otherwhise as hdr10 if this is only supported?
And what is the best compatible container for tvs (through usb hard drive), for a file like that (dv 8.1 + hdr10+), mkv or mp4?
For example the LG oled c15 will read it in mp4 as dolby vision?

[benwaggoner]

An x265 encode, encoded as both dolby vision profile 8.1, and as hdr10+, will play as dolby vision in supported devices, otherwhise as hdr10+ if supported, otherwhise as hdr10 if this is only supported?
In theory it should work, but I'm not aware of any real-world testing of this configuration.

And what is the best compatible container for tvs (through usb hard drive), for a file like that (dv 8.1 + hdr10+), mkv or mp4?
For example the LG oled c15 will read it in mp4 as dolby vision?
Always .mp4 for maximum compatibility. The consumer electronics industry generally thinks of .mkv as a hobbyist/piracy thing that's under-documented and somewhat fraught to implement. Conversely, they have battle-tested, security-hardened, fuzz-tested .mp4 demuxers for a couple of decades now.

Given how many security breaches have come from media stack exploits in the last decade, the default is generally to implement the minimum number of features possible in order to reduce surface area available for hacking.

[kolak]

Ffmpeg got some updates regarding DOVI.

[Boulder]

Ffmpeg got some updates regarding DOVI.

Does that mean that applications like Kodi on SoC devices might be able to output DoVi content at some point, or are there still some things like licensing in the way?

[rwill]

Does that mean that applications like Kodi on SoC devices might be able to output DoVi content at some point, or are there still some things like licensing in the way?

I see a bigger problem in certification.

[Balling]

I see a bigger problem in certification.

Who cares. Mpv works already.

[Selur]

Who cares.
Everybody that isn't a mpv fanboy,...

[Balling]

Everybody that isn't a mpv fanboy,...

What else? VLC is very buggy even in 601 vs 709 matrix, no one except mpv supports color managmnet of PAL and SMPTE C primaries. Only mpc-hc support color managment with icc besides mpv, and last only mpv can output PQ swapchain with Dolby Vision. Only mpv supports bt.2020-cl matrix, only mpv supports ICtCp... Etc. It still does not support superwhite though.

Mpv uses only nvidia decoder of YCbCr by default, which is correct compared to Intel's.

[Selur]

You are aware that this is the video encoding forum, right?

[Balling]

You are aware that this is the video encoding forum, right?

We are far from encoding reshaped content...

[LazyNcoder]

I've got one question about the -c option in dovi tool.

How does that work? I mean, sometimes I'm not certain about the exact amount of the letter box, so I maybe leave 2px or 4px up and down.
Does this mess up the encode? I mean, I rather encode in 3120x1616 or 3120x1608 rather than 3120x1606 3120x1604
Does this ruin it? if so, Is there any ways to fix it?

Thanks

[von Suppé]

-c zeroes L5 metadata. You use it when you have video without black borders being part of it. Should you have a few px left after recoding, you have to set L5 to those values. -QfG-'s scripts can help with this.
See https://forum.doom9.org/showthread.php?t=183479
Depending on your playback equipment, there is a chance that these small black bars will display differently than the black areas that are created to make it fullscreen.

May I ask why you use 3120 width?

[LazyNcoder]

-c zeroes L5 metadata. You use it when you have video without black borders being part of it. Should you have a few px left after recoding, you have to set L5 to those values. -QfG-'s scripts can help with this.
See https://forum.doom9.org/showthread.php?t=183479
Depending on your playback equipment, there is a chance that these small black bars will display differently than the black areas that are created to make it fullscreen.

Thank you very much. Is there any way to see from what pixel the DV metadata is being applied when it's fullscreen? so I can crop the image very precisely.


May I ask why you use 3120 width?
This is embrassing. I meant 3840. didn't noticed it and copy/pasted it multiple times :D

[von Suppé]

I think RPU is applied in the so-called 'active area', which I would wildly guess to be the videoresolution minus the L5 offset values. But I can be horribly wrong here; RPU carries a lot of data of which I don't know their meaning. Maybe more knowledgable people want to step in.

Anyways, if I wanna crop very precisely, I load a screenshot in an image editor. Using rectangular selection tool and zoom function, it's easy to determine the black bar sizes with one-pixel-precision.

[kolak]

As far as I know Dolby processing should be always applied to active area only, so in case of aspect ratios different to UHD frame (so anything like 2.35 etc.) always require specifying crop/active area or whatever is needed by given tool to work on active area only.
Same applies to mastering when you create Dolby masters with XML metadata.

[ShortKatz]

For Dolby Vision, same principle: https://github.com/quietvoid/dovi_tool#extract-rpu
Feed to x265 with: https://x265.readthedocs.io/en/master/cli.html#cmdoption-dolby-vision-rpu
Also have to specify the profile.

May I ask a question to this. I now extracted the RPU using
ffmpeg -i input.mkv -c:v copy -vbsf hevc_mp4toannexb -f hevc - | dovi_tool extract-rpu - -o RPU.bin
This worked nicely and gave me a 90MB file.
But how do I get the RPU into my encoded video?

First, I have tried it in HandBrake directly (which would be the perfect way). I've added
vbv-bufsize=160000:vbv-maxrate=160000:dolby-vision-profile=8.1:dolby-vision-rpu=/Filepath/RPU.bin
as additional options. But this did not work because of:
encx265: unknown option 'dolby-vision-rpu'

Then I've tried to first encode the video with HandBrake and then inject the RPU back into the final video with:
ffmpeg -i video.m4v -c:v copy -c:a copy -vbsf hevc_mp4toannexb -f hevc - | dovi_tool inject-rpu -i - --rpu-in /Filepath/RPU.bin -o final.mp4
But this did not work because of:
Error: RpuInjector: Must be a raw HEVC bitstream file