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

[von Suppé]

I wonder if cropping RPU has something to do with the the A/V sync issue. Can be wrong, but it sounds like container timestamps and/or default duration header not being properly written during (mkv) mux.
You can do a manual mux with proper FPS-value forced set in MTX-GUI/mkvmerge to confirm.

[Gabu]

I need to inject DV to a HDR10 file to make a hybrid.

Could you guys tell me how in steps, please?

[Gabu]

Moreover, I want to make a hybrid that isn't a UHD remux, but a web based file.

Is the only way to make the inject work converting the profile 5 to 8? Even both files are profiles 5? I tried making an inject but it didn't work; it was green on my TV.

[von Suppé]

If you mean green/purple colors, that's typical for when P5 colorspace isn't supported. Which is proprietary to Dolby. Are you sure your player can handle it?

[Gabu]

If you mean green/purple colors, that's typical for when P5 colorspace isn't supported. Which is proprietary to Dolby. Are you sure your player can handle it?

Yeah, I use a Nvidia Shield on a LG CX. The issue probably was that I was trying to leave the profile 5 as is. I learn now that you cannot have hybrids unless you convert to profile 8.

I know, I know I can't have everything handed to me, but does anyone have a tutorial? There's hybrids I wanna make for myself with copies I legally own.

I got close the other day, but it still didn't work just right..

I assume this hybriding method works the same for web dl hybrids and Blu ray hybrids?

[GodzilaAvenger]

To make a hybrid your base layer should not be Profile 5, since it uses a different color space that is not HDR10 compatible. If you have a base layer that is HDR10 compatible (e.g. from a BluRay) you can demux the RPU from a web source, convert it to Profile 8.1, and inject it into the base layer.

[Fuso]

Is there a way to mux DV profile 8 that will work on both newer and older LG OLEDs, and also non-DV compatible tvs, like Samsung? I have LG C2, LG B8, Samsung AU9000. Currently when I mux a MKV profile 8 to MP4 with DDVT_MKVTOMP4 the result is DV playback on the LG C2 and HDR playback on both LG B8 and Samsung AU9000. The file plays on all of the tvs, but the problem is that is not triggering DV on the LG B8. The internal media players are different - B8 can play Proflie 7 mp4, but the C2 plays them in regular HDR. I was trying different methods with other tools and I think the main difference comes from the Coded ID:

LG C2 - DV
LG B8 - HDR
Samsung AU9000 - HDR
HDR format : Dolby Vision, Version 1.0, dvhe.08.06, BL+RPU, HDR10 compatible / SMPTE ST 2086, HDR10 compatible
Codec ID : hev1


LG C2 - DV
LG B8 - DV
Samsung AU9000 - can't play
HDR format : Dolby Vision, Version 1.0, dvhe.08.06, BL+RPU, HDR10 compatible / SMPTE ST 2086, HDR10 compatible
Codec ID : dvhe


LG C2 - DV
LG B8 - DV
Samsung AU9000 - purple and green picture
HDR format : Dolby Vision, Version 1.0, dvhe.05.06, BL+RPU
Codec ID : hev1


LG C2 - DV
LG B8 - DV
Samsung AU9000 - can't play
HDR format : Dolby Vision, Version 1.0, dvhe.05.06, BL+RPU
Codec ID : dvhe


The thing that bugs me is when P5 is set to hev1 the B8 plays them in DV, not in purple and green base layer colors. But when P8 is set to hev1 the B8 then plays the base HDR layer.

[-QfG-]

The Samsung support no DV. But in your case, the movies must fallback in the HDR mode (Profile 8). Profile 5 you can't watch. If you have trouble with the fallback feature, simple remove the DV RPU from the stream (REMOVER Script).

[Fuso]

I know that Samsung don't support DV and that Profile 5 can't be played on it. The thing that bugs me is why the B8 can't play Profile 8 in mp4 container when the Codec ID is hev1. I don't want to strip the DV metadata, I want a file that will play like this:

LG C2 - DV
LG B8 - DV
Samsung AU9000 - HDR

but... I don't think it's possible.

[Dragon1981]

I know that Samsung don't support DV and that Profile 5 can't be played on it. The thing that bugs me is why the B8 can't play Profile 8 in mp4 container when the Codec ID is hev1. I don't want to strip the DV metadata, I want a file that will play like this:

LG C2 - DV
LG B8 - DV
Samsung AU9000 - HDR

but... I don't think it's possible.

I am looking to get exactly same for my iPhone 12 videos shot in HLG (Dolby Vision).
I normally use Davinci Resolve Studio to get Dolby Vision profile 5.

[speedy]

Is this tool using the older Mode 5 or the new Mode 2?

Conversion modes
-m, --mode Sets the mode for RPU processing.
Default (no mode) - Copies the RPU untouched.
0 - Parses the RPU, rewrites it untouched.
1 - Converts the RPU to be MEL compatible.
2 - Converts the RPU to be profile 8.1 compatible.
Removes luma/chroma mapping for profile 7 FEL.
3 - Converts profile 5 to 8.1.
4 - Converts to profile 8.4.
5 - Converts to profile 8.1, preserving mapping.
Old mode 2.
Source: https://github.com/quietvoid/dovi_tool#conversion-modes

Also, is it possible to remove luma/chroma mapping for files that were previously converted to Profile 8.1 from Profile 7 FEL with Mode 5 (old Mode 2)? If so, how would I accomplish this?

I've noticed that Profile 7 FEL files that were converted to Profile 8.1 with Mode 5 (old Mode 2) fallback to HDR in the Infuse 7.5 betas (current 7.5.4370). I don't have access to all the original FELs (deleted to save space), but I have converted a few that I kept around with the new Mode 2 (removing luma/chroma mapping) and these seem to register as DoVi in Infuse 7.5.4370.

[GodzilaAvenger]

Looking at the demuxer code, it uses Mode 2 (-m 2) for conversion to P8.1, so whenever dovi_tool was updated with the new modes so was DDVT.

Have you tried feeding it a P8.1 RPU that was created with the old Mode 2 to see if it creates one that registers as DV in Infuse?

[-QfG-]

Here a little text from quietvoid itself:

Hey, I'm going to be changing dovi_tool's mode 2 to also do "remove_mapping" by default, for profile 7 FEL only.
By doing so I'll also be adding a new mode 5 for the old behaviour.

The problem with current mode 2 is that everyone's been using it but not necessarily along with remove_mapping.

I've also made it FEL only but AFAIK profile 7 MEL does not have any of the mapping metadata, so it should be the same.
The only cases where the profile 8.1 would be wrong is if someone did a FEL -> MEL -> 8.1 conversion.

I was just wondering if this is a change that would impact your DDVT script at all.
I don't think your scripts currently use `remove_mapping`, so this would impact all mode 2 conversions.

Thanks!

I understand it so, if you convert a P5 file into P8, you don't have Luma/Chroma Mapping inside. Only by converting P7 FEL to P8 you have the Luma/Chroma Mapping inside. But you don't need this, so Mode 2 erased this metadata from the RPU. If you use Mode 2 for P7 MEL or P5 it is the same how the old Mode 2 (new Mode 5).

I've noticed that Profile 7 FEL files that were converted to Profile 8.1 with Mode 5 (old Mode 2) fallback to HDR in the Infuse 7.5 betas (current 7.5.4370). I don't have access to all the original FELs (deleted to save space), but I have converted a few that I kept around with the new Mode 2 (removing luma/chroma mapping) and these seem to register as DoVi in Infuse 7.5.4370.

The infuse Player supports DV, so i think the new Mode 2 is correct and the old Mode 2 (without -remove_mapping switch) not. You can convert the old releases with the new mode 2, i think they will be correctly tagged as DV files.

-v0.52 Online
*Updated dovi_tool to v2.0.3.
*Updated hdr10plus_tool to v1.6.

[MiloGNR]

Hi. First post on this forum for me :)

I was wondering if someone could explain me how the "Removing Dolby Vision / HDR10+" process works. Recently I have found out that I need to use this tool to remove Dolby Vision from movies that have both Dolby Vision and HDR10+, because my Chromecast won't play said movie in HDR10+.

My poor knowledge on the matter is that Dolby Vision / HDR10+ are layers that go "below" the HDR layer of the file. So, I guess that when I use DDTV_REMOVER, the Dolby Vision layer gets removed from the MKV?
What I want to understand is if some kind of re-encoding to the movie is being done behind the scenes, or if it's just "disassembling" the MKV, removing the Dolby Vision layer and "reconstructing" the MKV again.
How does it work? Am I loosing quality by doing this? I would like to just remove the Dolby Vision layer and keep the HDR10+ one without touching the movie itself or reencoding (as I understand, they are different layers?).
Is this possible? Is there another method to achieve what I need to do?

Thanks!! :)

[GodzilaAvenger]

As far as I know DDVT_REMOVER only removes the DV Enhancement Layer, it won't touch or re-encode the HDR10 Base Layer or the HDR10+ metadata. Long way of saying DDVT does exactly what you need.

[Irek_Ismaren]

Hello,

First I'd like to say thank you so much for this tool. I've been having a lot of fun going back through my ripped blu-ray collection and adding Dolby Vision to all my personal encodes.
I do have a couple questions concerning cropping.
Can I always just set the option to crop in the demuxer to [YES]?
Will this affect sources that are perhaps already cropped or don't have black bars at all?

Also... Can you inject an uncropped RPU into a cropped encode?
I've done several where I've cropped the video but didn't crop the RPU. I didn't notice any issues upon playback but was wondering if I needed to go back and redo them.

[GodzilaAvenger]

Hi,

You may want to look at this discussion we had (https://forum.doom9.org/showthread.php?p=1979519#post1979519) a while back in this thread.

[Irek_Ismaren]

Thanks GodzilaAvenger,

That helps tremendously!

Sorry I didn't look back far enough. I've read most of this thread up until about 6 months ago, then forgot where I left off.

[zomorf]

Hi Guys,

Not sure anyone having issues with lockups? I'm running under Windows 10 was using 0.47a I think but just updated over the weekend... Demuxing seems OK but on a few attempts it's locking my system trying to inject the RPU...

At present trying tv shows web-dl DV to inject into HDR web-dl...

[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 (https://github.com/quietvoid/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]

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]

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]

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.

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]

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]

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.

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]

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

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.

[GodzilaAvenger]

Hi,

With this custom.json file you are only applying the edits to the first 40 frames.

If the film's aspect ratio does not change you don't need a custom.json file, delete it and just use the INJECTOR script with the RPU and set the borders in the DDVT interface.

[GHOSTWRiTAZ]

Hi GodzilaAvenger,
Thank you for the swift reply.

Unfortunately I already tried that, the results are the same :(

Below the settings that I used:

Step 1:
https://thumbs4.imagebam.com/92/2d/cd/MEKVCKN_t.png (https://www.imagebam.com/view/MEKVCKN)

Step 2:
https://thumbs4.imagebam.com/4d/b3/ce/MEKVCN6_t.png (https://www.imagebam.com/view/MEKVCN6)

Step 3:
https://thumbs4.imagebam.com/d4/4c/9d/MEKVCQK_t.png (https://www.imagebam.com/view/MEKVCQK)

Step 4:
https://thumbs4.imagebam.com/f7/b1/17/MEKVCR8_t.png (https://www.imagebam.com/view/MEKVCR8)

Result remains the same 3840x1600 pixels (cropped/same as source without cinematic black bars/borders)
https://thumbs4.imagebam.com/a1/0e/66/MEKVCTL_t.jpg (https://www.imagebam.com/view/MEKVCTL)

What I wish to achieve is 3840x2160 pixels (aspect ratio remains the same but cinematic black bars/borders are added during the DDVT Injector process)
https://thumbs4.imagebam.com/c6/71/6b/MEKVCVF_t.jpg (https://www.imagebam.com/view/MEKVCVF)

Again any help on the matter is greatly appreciated. Thanks

[GodzilaAvenger]

Ok, got it. DDVT can't letterbox a cropped .mkv file (add top and bottom black bars). It is only meant for handling dynamic metadata (Dolby Vision/HDR10+). If your .mkv file is 3840x1600, you should set the borders in the RPU to 0, as it originally was.

If you want to letterbox a video you need to use FFmpeg. For instance, see this (https://video.stackexchange.com/questions/25960/ffmpeg-how-can-i-add-black-bars-to-top-and-bottom-of-my-video) and this (https://stackoverflow.com/questions/61703587/proper-way-to-letterbox-with-ffmpeg) on how to do it. If you do this and get a 3840x2160 .mkv, then you have to adjust the RPU borders as well (set top and bottom to 280).

[GHOSTWRiTAZ]

Ok, got it. DDVT can't letterbox a cropped .mkv file (add top and bottom black bars). It is only meant for handling dynamic metadata (Dolby Vision/HDR10+). If your .mkv file is 3840x1600, you should set the borders in the RPU to 0, as it originally was.

If you want to letterbox a video you need to use FFmpeg. For instance, see this (https://video.stackexchange.com/questions/25960/ffmpeg-how-can-i-add-black-bars-to-top-and-bottom-of-my-video) and this (https://stackoverflow.com/questions/61703587/proper-way-to-letterbox-with-ffmpeg) on how to do it. If you do this and get a 3840x2160 .mkv, then you have to adjust the RPU borders as well (set top and bottom to 280).

Hi GodzilaAvenger,

I was under the assumption that it actually was possible, so I misunderstood/misread post #281 (https://forum.doom9.org/showpost.php?p=1972998&postcount=281) and #297 (https://forum.doom9.org/showpost.php?p=1973230&postcount=297)

Meaning what I want to achieve is simply not possible without ffmpeg processing if the source is cropped 3840x1600 I will have to transcode it using ffmpeg filter to 3840x2160 pixels, which may result in loss of quality. Thanks for clarifying

[GodzilaAvenger]

I highly doubt letterboxing using FFmpeg would result in loss of quality. Even if it did, the loss would be imperceptible.

[guest]

As the title suggests ???

[-QfG-]

-v0.54
*NEW New Script included (DDVT_Hybrid) for fast creating DV Profile 8.1 Hybrid Releases.
*INJECTOR-Function to change correctly the video framerate. Also included in HYBRID Script.
*Updated mkvtoolnix to v 76.0.0.0.

- SCRIPT <DDVT_HYBRID.cmd>

DESCRIPTION:
------------
Simple quick script to create a DV Profile 8 Hybrid Release. Only add HDR
and DV File (No RAW file Support, only MKV/MP4 Container) set the options
and Go. Completely simplified and the fastest script to Build P 8.1 Files.
Also you can Input only a HDR10+ file without DV Input file and you create
a Profile 8.1 DV file based on the HDR10+ Metadata.

USAGE:
------
DDVT_HYBRID

[guest]

I have just asked this question on the x265 thread

https://forum.doom9.org/showthread.php?p=1987516#post1987516

Does this make any sense to anyone here ??

Is there still and option to remove the HDR10 metadata ?? I could only see how to remove the DV metadata.

[von Suppé]

As TDS described in your linked thread, removing HDR metadata can render a device to not play the baselayer correctly. May I ask why you want to remove HDR metadata when video is HDR encoded?

[guest]

As TDS described in your linked thread, removing HDR metadata can render a device to not play the baselayer correctly. May I ask why you want to remove HDR metadata when video is HDR encoded?

TBH, I don't know if I need to be removing it, it's just that I am trying to figure out how to encode Dolby Vision, seems that most are Hybrid's.

Go here:- https://forum.doom9.org/showthread.php?p=1987477#post1987477 to see what I have been trying.

The difference between HDR Hybrid & and DV seems to be this :-

Dolby Vision, Version 1.0, dvhe.08.06, BL+RPU, HDR10 compatible / SMPTE ST 2086, HDR10 compatible

and

Dolby Vision, Version 1.0, dvhe.08.06

[SeeMoreDigital]

Is there still and option to remove the HDR10 metadata ?? I could only see how to remove the DV metadata...May I ask why you want to remove HDR metadata when video is HDR encoded?
If nothing else it would make an interesting addition for the completists!