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

[GodzilaAvenger]

It seems to be working fine for me, though I'm on Windows 11. Can you provide more detail about the freezing? What step causes your system to freeze?

[HD MOVIE SOURCE]

Just wondering. If I encode something in HDR10 with no available metadata, could I use this program to trigger Dolby Vision with static metadata? So something could play in Dolby Vision with no metadata?

Can you add your own metadata?

I'm new to this, apologies if it's a nooby question.

[GodzilaAvenger]

I'm not sure if you can trigger DV with static metadata, but you could use dovi_tool (which is the backbone of DDVT) to generate a binary RPU (i.e. metadata) and then use DDVT to inject it into your file. If you only have the static metadata you can set metadata values to be the same across all shots (or frames), though I'm not sure if there would be much (if any) improvement over HDR10.

[ntropy]

Could there be a checkbox to do a test injection -- ie, a portion of the first few minutes of an injection to see how it looks? My most recent injection applied delay of -7 frames on a 138317 frame mkv with "mux stream in mkv" set to yes and because I'm seeing a brightness timing issue on the transitions I'd like to try -6 or -8 frames just to see if it's better but am getting a bit impatient with the time and hard drive space it takes just to see if something will play with stable DV. Impatient because I've already done +14 and -14 frame passes before ditching MCP-HC and using VirtualDub2 to read the frame differences. What would be ideal if there was a preview mode to test these things in. In this case the 2nd last frame of the Pixar logo lamp appears in the demuxed source at frame 138252 and in the injection target at 138245, so I thought -7 would work. But I'm 12 minutes into watching the result and there are still (smaller but) noticeable brightness shifts around some (not all) transitions. So I'm getting closer on this third try. And maybe this is as close as I'll ever get and perfection is not attainable with my TV? Maybe it is working but my LG B7 isn't fast enough to keep up with injected MKVs on Plex on a Shield Pro? Maybe my LG B7 can only display stable DV from full ISOs played on the M9702 player?

[Arkana]

Hello, I have hundreds of DV video that need double checked for possibly wrong crop values. Some of them have correct values but many of them are wrong. Is there anything I can do to fix this and saving the time?

[GodzilaAvenger]

Originally Posted by ntropy

Could there be a checkbox to do a test injection -- ie, a portion of the first few minutes of an injection to see how it looks? My most recent injection applied delay of -7 frames on a 138317 frame mkv with "mux stream in mkv" set to yes and because I'm seeing a brightness timing issue on the transitions I'd like to try -6 or -8 frames just to see if it's better but am getting a bit impatient with the time and hard drive space it takes just to see if something will play with stable DV. Impatient because I've already done +14 and -14 frame passes before ditching MCP-HC and using VirtualDub2 to read the frame differences. What would be ideal if there was a preview mode to test these things in. In this case the 2nd last frame of the Pixar logo lamp appears in the demuxed source at frame 138252 and in the injection target at 138245, so I thought -7 would work. But I'm 12 minutes into watching the result and there are still (smaller but) noticeable brightness shifts around some (not all) transitions. So I'm getting closer on this third try. And maybe this is as close as I'll ever get and perfection is not attainable with my TV? Maybe it is working but my LG B7 isn't fast enough to keep up with injected MKVs on Plex on a Shield Pro? Maybe my LG B7 can only display stable DV from full ISOs played on the M9702 player?

Instead of this process of repeated trial and error, you can use the FRAMEINFO tool with the RPU and enter ALL to get a list of the scene cuts (list of the starting frame of new scenes). Then, use a software like DJV to see how much delay you need to apply to the RPU to align the RPU scene cuts with the video. If you use DJV the starting frame is 1 whereas in DDVT it's 0 so keep that in mind.

[ntropy]

Originally Posted by GodzilaAvenger

Instead of this process of repeated trial and error, you can use the FRAMEINFO tool with the RPU and enter ALL to get a list of the scene cuts (list of the starting frame of new scenes). Then, use a software like DJV to see how much delay you need to apply to the RPU to align the RPU scene cuts with the video. If you use DJV the starting frame is 1 whereas in DDVT it's 0 so keep that in mind.

I tried FRAMEINFO and it created a .json file but scrolling through the file I didn't see any frame ranges (like 0-100 or 101-2000) under each "header" key so I assumed that each header was representing 1 frame each and not representing the scene cuts I had hoped to find using the FRAMEINFO tool. There were a lot of of "header" keys, more than VSCode could enumerate on a Find query. I think it stopped at 19999, which seems like more like apporoaching a frame count than a scene count. I deleted the .json so I can't check now. I'll make another one but this is such a slow process.

[GodzilaAvenger]

When you use FRAMEINFO and enter ALL it generates two files, one has the frame-by-frame DV metadata info (usually 1GB or more in size). The other (I think named [all scene cuts].json or something similar) is just a list of numbers, i.e. starting frame of each scene. You should use this latter file.

[ntropy]

Originally Posted by GodzilaAvenger

Instead of this process of repeated trial and error, you can use the FRAMEINFO tool with the RPU and enter ALL to get a list of the scene cuts (list of the starting frame of new scenes). Then, use a software like DJV to see how much delay you need to apply to the RPU to align the RPU scene cuts with the video. If you use DJV the starting frame is 1 whereas in DDVT it's 0 so keep that in mind.

Originally Posted by GodzilaAvenger

When you use FRAMEINFO and enter ALL it generates two files, one has the frame-by-frame DV metadata info (usually 1GB or more in size). The other (I think named [all scene cuts].json or something similar) is just a list of numbers, i.e. starting frame of each scene. You should use this latter file.

I see. Looking at the RPU_[All Scene Cuts].json numbers on a different .mkv hybrid, the frames appear to be happening in the right places when I compare on VirtualDub2 (which starts on frame 0).

But here are two frame numbers which appear in the right place for the *start* of two scenes, but the playback has brightening artifacts on the outgoing and incoming frame of each cut.

5843 - starting frame of close up of actor
5864 - starting frame of medium wide shot of car

I've created a video only mkv of the first 5 minutes of the movie with MKVToolNix and I'll try applying a 1 frame positive delay on that.

Update: created both 1 frame positive and 1 frame negative delay mkvs of first 5 minute.

A) Original full length mkv still had brightness shifts at most cuts, but they seemed less severe now.

B) Five minute video only mkv (no injection applied) had milder brightness shifts on fewer cuts.

C) Five minute video only mkv with positive delay injection looked the same as B.

D) Five minute video only mkv with negative delay injection looked the worse and the brightness shifts looked dark instead of light at the cuts.

If the scene changes are happening on the correct frames, could the culprit be the HDMI cables connecting the Shield Pro -> Denon AVR -> LG B7? When Shield Pro DV mkv brightness shifts happened in the past on other mkvs, I swapped M9702 player HDMI cable with the Shield Pro cable without seeing any improvement, but maybe that was an mkv with bad scene change RPU. Or maybe the Shield Pro is more sensitive to HDMI cable quality than the M9702. I dunno. Or maybe this combo of AVR + TV can't lock reliably onto the Shield Pro's DV mkv playback as it can onto M9702 DV ISO playback.




Interesting that the RPU was pulled from the MKV and the Borders don't match.

 == VIDEO INPUT =========================================================================================================


Borders    = [LEFT=128 px], [TOP=0 px], [RIGHT=128 px], [BOTTOM=0 px] [NOT MATCH WITH RPU]

 == RPU INPUT ===========================================================================================================

Filename   = [RPU.bin]
RPU Info   = [DV Profile = 8] [CM Version = 2.9] [Frames = 7199]
Borders    = [LEFT=126 px], [TOP=0 px], [RIGHT=126 px], [BOTTOM=0 px] [NOT MATCH WITH VIDEO]

[GodzilaAvenger]

Is B) just the HDR10 file? If so, the brightness shifts may be coming from the base layer and not the DV layer.

Aliging scene cuts with the RPU is necessary but may not be sufficient. If you want to make sure the problem is not coming from the RPU you can look at the RPU_[All Frame Info].json file for that frame range. Specifically, for those frames look at the min_pq, avg_pq, and max_pq values, AKA the L1 metadata (if you want to know more Google "Dolby Vision Metadata Levels") that define scene brightness. They should be identical for all frames of each scene. If they are not, then you may have a faulty RPU and that explains the brightness shifts. If they are, the problem is likely from something other than the RPU.

DDVT is sometimes a few pixels off when detecting borders, so it's not always reliable. I have a 4K monitor so I use the Screen Ruler of PowerToys on Windows to get the borders.

[ntropy]

Originally Posted by GodzilaAvenger

Is B) just the HDR10 file? If so, the brightness shifts may be coming from the base layer and not the DV layer.

Aliging scene cuts with the RPU is necessary but may not be sufficient. If you want to make sure the problem is not coming from the RPU you can look at the RPU_[All Frame Info].json file for that frame range. Specifically, for those frames look at the min_pq, avg_pq, and max_pq values, AKA the L1 metadata (if you want to know more Google "Dolby Vision Metadata Levels") that define scene brightness. They should be identical for all frames of each scene. If they are not, then you may have a faulty RPU and that explains the brightness shifts. If they are, the problem is likely from something other than the RPU.

DDVT is sometimes a few pixels off when detecting borders, so it's not always reliable. I have a 4K monitor so I use the Screen Ruler of PowerToys on Windows to get the borders.

B) is DV and when I tried playing using my B7's internal player it defaulted to HDR10 and there were no brightness jumps on the cuts so the HDR10 is fine.

The cut I'm examining is 5909 listed in [All Scene Cuts].json


So at the 5909th instance of "Level1" (and 5908th, 5907th) in [All Frames Info].json we have:

          {
            "Level1": {
              "min_pq": 2,
              "max_pq": 3311,
              "avg_pq": 1674
            }

At 5910th (and 5911th, 5912th) we have:

          {
            "Level1": {
              "min_pq": 12,
              "max_pq": 2817,
              "avg_pq": 1636
            }

So it looks like the RPU is fine?

[GodzilaAvenger]

No, the RPU seems faulty. The frame numbers listed in RPU_[All Scene Cuts].json are the starting frame numbers of each scene, which you can double check by looking at the scene_refresh_flag value (it should be 1 for frame 5909). In other words the pq values should be the same for frames 5909, 5910, 5911 etc. since they belong to the same scene, but different from 5908, 5907, etc.

I'm not sure how to fix this but the only tool that may help you is dovi_tool, which you can find in the tools folder of DDVT. You could make changes to the RPU_[All Frame Info].json file and generate a new RPU binary using it. Alternatively, you could use dovi_tool's editor functionality. You may also want to look at a different source for the RPU.

[ntropy]

Originally Posted by GodzilaAvenger

No, the RPU seems faulty. The frame numbers listed in RPU_[All Scene Cuts].json are the starting frame numbers of each scene, which you can double check by looking at the scene_refresh_flag value (it should be 1 for frame 5909). In other words the pq values should be the same for frames 5909, 5910, 5911 etc. since they belong to the same scene, but different from 5908, 5907, etc.

I'm not sure how to fix this but the only tool that may help you is dovi_tool, which you can find in the tools folder of DDVT. You could make changes to the RPU_[All Frame Info].json file and generate a new RPU binary using it. Alternatively, you could use dovi_tool's editor functionality. You may also want to look at a different source for the RPU.

The 5910th instance of "scene_refresh_flag" is:

      "scene_refresh_flag": 1,

Which I think means it is working, because the 1st instance of "scene_refresh_flag" would be frame 0 -- you have to subtract 1, right? So the 5910th instance in the document is frame 5909. This would be much more straighforward if they put the frame number in the .json.

[GodzilaAvenger]

Yeah, right. I thought it was frame 5910. In that case the RPU seems fine to me. The problem is likely coming from your setup then.

[-QfG-]

-v0.53 Online.
*Updated FFMPEG to N-110509-g722ff74055-20230506
*Updated MP4Box to 2.2-rev0-gab012bbfb
*Updated mkvtoolnix to v 75.0.0.0.

[von Suppé]

Thanks for the new release

[Amateur]

I got this error when trying to create an RPU. "Please wait. Extracting the Video Layer ...
Exporting HEVC Video - Size 3840x2160
[IsoMedia] Track #1 fail to fetch sample 45927 / 151622: Invalid IsoMedia File== | (23/100)
Done." The whole file can play just fine so I don't know why there is an error.

Originally Posted by GodzilaAvenger

You can also set negative delay. If, for example, frame 8 of the RPU corresponds to frame 0 of BluRay, set a -8 delay, which tells DDVT to remove the first 8 frames of the RPU.

Edit: same as what -QfG- said!

To piggy back onto this, I just want to make sure I'm understanding it correctly.

HDR frame 2525 = DV frame 2527
So for the delay I would set it to -2?

[hidef_rec]

Originally Posted by -QfG-

-v0.53 Online.
*Updated FFMPEG to N-110509-g722ff74055-20230506
*Updated MP4Box to 2.2-rev0-gab012bbfb
*Updated mkvtoolnix to v 75.0.0.0.

Thank you @-QfG-, your tool is invaluable. I use it at least weekly, if not more.

[GodzilaAvenger]

Originally Posted by Amateur

To piggy back onto this, I just want to make sure I'm understanding it correctly.

HDR frame 2525 = DV frame 2527
So for the delay I would set it to -2?

Yes...

[GHOSTWRiTAZ]

Hi all,
Thanks for this amazing batch scripts of DDVT Tools, much appreciated!

I do have question regarding the correct setting to add borders.

I'm using DDVT_DEMUXER.cmd to extract the RPU.bin from the video file.
Below the video details, the main goal is to add borders from source video resolution 3840 x 1600 pixels to 3840 x 2160 pixels, meaning I will have to add 280x pixels top and bottom for proper playback otherwise the cropped borders of resolution 1600 pixels will cause dark grey borders on top and bottom due to DV stream enabled.

Video
ID                                       : 1
Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Format profile                           : Main 10@L5@Main
HDR format                               : Dolby Vision, Version 1.0, dvhe.08.06, BL+RPU, HDR10 compatible / SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible
Codec ID                                 : V_MPEGH/ISO/HEVC
Duration                                 : 2 h 3 min
Bit rate                                 : 14.7 Mb/s
Width                                    : 3 840 pixels
Height                                   : 1 600 pixels
Display aspect ratio                     : 2.40:1
Frame rate mode                          : Constant
Frame rate                               : 23.976 (24000/1001) FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 10 bits
Bits/(Pixel*Frame)                       : 0.100
Stream size                              : 12.7 GiB (95%)
Language                                 : English (US)
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.0001 cd/m2, max: 1000 cd/m2
Maximum Content Light Level              : 1000 cd/m2
Maximum Frame-Average Light Level        : 142 cd/m2

for custom.json I'm using the following code:

{
  "mode": 0,
  "active_area": {
    "crop": true,
    "presets": [
      {
        "id": 0,
        "left": 0,
        "right": 0,
        "top": 280,
        "bottom": 280
      }
    ],
    "edits": {
      "0-40": 0
    }
  }
}

The custom.json file is located in the same folder as the video.mkv and RPU.bin

after the DDVT_INJECTOR.cmd process I'm still getting the same results 3840x1600 ?

Am I missing some steps here or what am I doing wrong. Any help on the matter is greatly appreciated. Thanks.