[DDVT Tool] Dolby Vision RPU Demuxing / Injecting / Editing.

[GZZ]

Originally Posted by halls

Hi!

Yes, i tried.

.JSON file is to big.....

But Thank You!

There are other free pages, just use Google and search on "Json to XML converter" and then try them all out.

[cool advertise]

Originally Posted by -QfG-

This is a Dolby Vision Tool, not a HDR10+ Tool. . I will look to add HDR10+ Injector support on the next Update.

I know how to inject or extract HDR10+ metadata, but if you include in a future version also the extraction of HDR10+ metadata in the demuxer the tool would become a complete dolby vision and HDR10+ management tool.
Only if you want to of course.

[shodan5000]

Originally Posted by cool advertise

I know how to inject or extract HDR10+ metadata, but if you include in a future version also the extraction of HDR10+ metadata in the demuxer the tool would become a complete dolby vision and HDR10+ management tool.
Only if you want to of course.

You might also be interested in HDR-Multi-Tool-Gui if HDR10+ is important to you. It does Dolby as well.

https://github.com/jlw4049/HDR-Multi-Tool-Gui

[-QfG-]

-v0.36
*HDR10+ Demuxing / Injecting Support.

[cool advertise]

Originally Posted by -QfG-

-v0.36
*HDR10+ Demuxing / Injecting Support.

Thank you, very good work.
I don't want to be wrong, but shouldn't it be possible to edit the active area while demuxing?

[-QfG-]

Originally Posted by cool advertise

Thank you, very good work.
I don't want to be wrong, but shouldn't it be possible to edit the active area while demuxing?

You need the resolution of the target video, i think in the injector is the better solution.

[quietvoid]

All static edits that don't require modifying a specific frame can technically be done, but it's not implemented in dovi_tool currently.
So, you can't edit anything other than doing mode/crop right now.

[von Suppé]

Originally Posted by -QfG-

-v0.36
*HDR10+ Demuxing / Injecting Support.

Cool!

A big to both quietvoid and -QfC- for continually improving tools and scripts. Highly appreciated!

[-QfG-]

-v0.37
*Updated dovi_tool.exe to v1.4.6.
*Added DDVT_FRAMEINFO.cmd.

[-QfG-]

@quietvoid

I have seen that in any RPU.bin's CM29 Metadata not Level5 specified.
Is that the same if i set Active Area to 0,0,0,0?

For example:

"cmv29_metadata": {
"num_ext_blocks": 3,
"ext_metadata_blocks": [
{
"Level1": {
"min_pq": 12,
"max_pq": 2105,
"avg_pq": 819
}
},
{
"Level2": {
"target_max_pq": 2081,
"trim_slope": 2048,
"trim_offset": 2048,
"trim_power": 2048,
"trim_chroma_weight": 2048,
"trim_saturation_gain": 2048,
"ms_weight": 2048
}
},
{
"Level6": {
"max_display_mastering_luminance": 4000,
"min_display_mastering_luminance": 50,
"max_content_light_level": 444,
"max_frame_average_light_level": 393
}
}
]
}
},
"rpu_data_crc32": 1251925187
}

[von Suppé]

As quietvoid's standalone dovi_tool accepts elementary streams only, I am quite surprised to find out they aren't supported in your scripts, -QfC-. Do you have plans for it?

[quietvoid]

Originally Posted by -QfG-

I have seen that in any RPU.bin's CM29 Metadata not Level5 specified.
Is that the same if i set Active Area to 0,0,0,0?

Probably, but Dolby recommends that L5 should always be present to avoid issues.

[-QfG-]

Originally Posted by von Suppé

As quietvoid's standalone dovi_tool accepts elementary streams only, I am quite surprised to find out they aren't supported in your scripts, -QfC-. Do you have plans for it?

INJECTOR handles RAW Streams, in the next Update i will add DEMUXER RAW Stream support. Also i'm working on an AutoCrop Function.

Probably, but Dolby recommends that L5 should always be present to avoid issues.

Thanks. I'm wondering, because that was in an official Profile 5 RPU.

[-QfG-]

-v037a
*Added AutoDetect Borders in AA Editor (works only with containers).
*Added Profile 8 to Profile 7 Conversion.

[cool advertise]

Originally Posted by -QfG-

-v037a
*Added AutoDetect Borders in AA Editor (works only with containers).
*Added Profile 8 to Profile 7 Conversion.

Hi, version 0.37a has a problem, in the demuxer, opening a file with dolby vision profile 7, option 4 (Convert RPU), shows only Profile 8 and it is not possible to change it as in previous versions ( Leave untouched).

[-QfG-]

-v0.37a - FIXED
*Fixed troubleshooting with profile switch in Profile 7 options.

Thx for the response.

[cool advertise]

If I want to crop a video with source resolution 3840x2160p in dolby vision 8.1, and the letterboxes bars are above 277 px and below 277 px, can I use the -c command of dovi_tool (or the crop RPU option of the -QfG- tool) with avisynth+ and crop like this?
crop(0, 276, 0, -276)
to be compatible with the height (divisible by 2) rule (mod 2) of avisynth?
Without resizing and with a final resolution of the re-encoded video of
3840x1608p
?
Is this correct?

[-QfG-]

Yes. Simply use the Crop RPU Function of the DEMUXER or use the Active Area Editor in INJECTOR and set all entries to 0.

-v0.37b
*Minor Bugfixes
*Updated mkvtoolnix to v 65.0.0.0

[cool advertise]

Originally Posted by -QfG-

Yes. Simply use the Crop RPU Function of the DEMUXER or use the Active Area Editor in INJECTOR and set all entries to 0.

-v0.37b
*Minor Bugfixes
*Updated mkvtoolnix to v 65.0.0.0

Thanks for the answer, ffmpeg 64bit is up to version 5.00 while 32bit is not.

[von Suppé]

Originally Posted by cool advertise

the letterboxes bars are above 277 px and below 277 px
crop(0, 276, 0, -276)

Thinking about this example, it does raise some questions about RPU's usage with under- and overcropped video.

Undercropping your video (containing 277px black bars) with 276px would leave 2 black lines. As such, shouldn't you better set TOP and BOTTOM crop values both to "1" in -QfC- injector? Using --crop switch would set all offsets to zero. No intention to being pedant here, but I wouldn't know how precise these values need to be and what the chances are of introducing artefacts.

On te opposite side, when overcropping video (even slightly), I also wonder whether (cropped) RPU can get corrupted .
Imagine your same video, but cropping with 280 instead, leaving 3840x1600, which is widely used. Extract RPU with --crop switch: great, no offsets.
But what about this "active area"? I don't know exactly how further this is used in DV's metadata. But I can imagine cropped RPU being left incompatible because of "shrunk active area" as invoked by the overcrop.