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

[GodzilaAvenger]

Let's say you have a DV P5 3840x1600 Web source and you want to inject the metadata into a HDR10 3840x2160 BluRay. You can demux the RPU from the Web source and convert to P8 without applying any cropping, and then when injecting that RPU set the top and bottom borders to 280 (DDVT usually does that automatically).

What happens if you set the top and bottom borders to 0 instead of 280? My understanding is that those values define the active area where things such as L1 metadata (min, avg, max pq or brightness values) are applied. So if e.g. your min_pq is 30, instead of having that apply only to the image area, it applies to the whole screen, meaning the top and bottom black bars are no longer black, but slightly greyish. In the same way, because e.g. average pq is now applied to the whole screen, you'll end up with an image that is considerably brighter to compensate for the black bars at the top and bottom.

-QfG- and quietvoid feel free to correct me if I'm wrong or missed anything.

[fkid]

Let's say you have a DV P5 3840x1600 Web source and you want to inject the metadata into a HDR10 3840x2160 BluRay. You can demux the RPU from the Web source and convert to P8 without applying any cropping, and then when injecting that RPU set the top and bottom borders to 280 (DDVT usually does that automatically).

What happens if you set the top and bottom borders to 0 instead of 280? My understanding is that those values define the active area where things such as L1 metadata (min, avg, max pq or brightness values) are applied. So if e.g. your min_pq is 30, instead of having that apply only to the image area, it applies to the whole screen, meaning the top and bottom black bars are no longer black, but slightly greyish. In the same way, because e.g. average pq is now applied to the whole screen, you'll end up with an image that is considerably brighter to compensate for the black bars at the top and bottom.

-QfG- and quietvoid feel free to correct me if I'm wrong or missed anything.

That sounds right, and I understand that Hybrid use case. My question applies more to combining DV Profile 5 WEB (convert to Profile 8 and inject) with HDR WEB for the same video (identical frames, source). Do all DV Profile 5 RPUs contain/maintain Level 5 metadata when converted to Profile 8? If so, that must mean the only way Level 5 metadata gets lost/reset to 0 is someone sets -crop flag when demuxing/converting? Basically, some files I have found have dynamic offsets in the RPU if the aspect ratio changes in the film (e.g. Blonde from NF), but others seem to just have 0,0,0,0 for entire runtime set despite the file having top and bottom borders of 278px for example.

TEST UPDATE: I just compared a video with all borders set to 0 in DV metadata but the actual video is uncropped and has black bars of about 278pixels on top and bottom VS. same fixed file with the correct offsets set in the DV Level 5 metadata of 278px top and bottom. To my surprise, I see no difference whatsoever when viewed on LG OLED C2 with Shield Pro 2019 in Plex app. These are normal .mkv files with dvhe.08.06. I totally expected to see the grey black bars and higher brightness as others have mentioned in discussions before.

UPDATE 2: @quietvoid let me know that it's because I am using an HDMI playback device, so Level 5 metadata is ignored in this case. Saves me a lot of time going forward, not having to always check and fix L5 data in encodes. Cheers! I suspect I will have issues if trying to play back on the TV built-in apps, although LG OLED C2 doesn't even play DoVi through an MKV in Plex, so I'll try with my other Hisense model later.

FINAL UPDATE: Sooo, it looks like L5 Metadata is taken into account by my Hisense TV (low end 2022 model), but oddly, it's not noticeable when the L5 offsets are all set to 0,0,0,0 (AKA cropped) but video is uncropped with black bars, or maybe this TV just doesn't output enough nits to show the effect. Either way, it seems far less of a problem and this is more common case when taking DV RPU from one source (cropped) and injecting into another (uncropped). On the other hand, when L5 Active Area is incorrectly set with borders (offsets from uncropped source) and injected into a file that is re-encoded and cropped, the TV actually cuts off parts of the image corresponding to the L5 offsets! It didn't just mess with brightness of the borders, this is much worse! I confirmed this by re-injecting the DV RPU with corrected L5 offsets for the same encoded video file. Here is before vs. after comparison: https://imgsli.com/MTM4Nzgz

This was unexpected and goes to show that a TV can interpret DV metadata in unexpected ways. In conclusion, if you play your files on your TV's internal player (especially Hisense), I recommend always verifying (and if needed, correcting), L5 metadata, even if you are playing back a file that you think is created by a 'reliable' encoder. Or consider getting a dedicated player like Shield Pro 2019 for example to avoid L5 issues altogether. Thanks again @quietvoid, @GodzillaAvenger and @-QfG- for the advice and tools that made this testing easier for me.

[GodzilaAvenger]

As far as I know no L5 data is changed during the conversion process unless the crop is specifically set during demuxing, so whatever L5 you have on P5 will appear on P8.

Dealing with files that have a varying aspect ratio is a bit tricky. I've seen both files where borders change to accomodate different aspect ratios, and those that borders are set to a constant value. I think in the latter ones the black bars are taken into account when computing the rest of the metadata (e.g. min_pq always seems to be 0). In general you have to be cognizant of the aspect ratio on both the source file and the target file (be it Web or BluRay). I recently wanted to add the RPU from a Web source with constant aspect ratio to a BluRay with IMAX scenes. I initially changed the borders for the IMAX scenes but then realized it was a mistake, because the rest of the metadata was calculated based on the fixed aspect ratio part of the image so the borders should correspond to those.

[LV8]

@quietvoid @-QfG- Quick question, I noticed that sometimes if you convert Profile 5 DV RPU to Profile 8, the Level 5 metadata for cropping values is not set or set to all 0. I know the DDVT script tries to catch this by detecting borders and suggesting to match video when injecting RPU, but if I already have some files with 0,0,0,0 set for Level 5 but the video itself has borders (uncropped), will it cause issues when viewing with Shield Pro 2019? I will run a test on my TV later, but just wanted to ask before fixing all of the possible video files I have that could have this issue. It seems that some users around the WEB are not aware of the Level 5 border values when they are injecting WEB-source DV into HDR (i.e. combining Profile 5 DV with HDR video from NF to make a hybrid file), so I thought I'd ask about it. Thank you kindly!

You should always use the correct L5 values as Dolby suggests, but there are a very few devices that actually use it (all HDMI devices don't, so in your case the Nvidia Shield won't care).
The only players that do are mostly internal TV players, such as LG ones.

[von Suppé]

...and those that borders are set to a constant value. I think in the latter ones the black bars are taken into account when computing the rest of the metadata

The thought that black borders would be taken into account does make sense. But it also confuses me. Unless I'm heavily mistaken or missing out on something, the L5 values would dictate the Dolby composer to apply the metadata only in the "active area". Which is the part between the black borders (given L5 values being correct). I mean, what other purpose would L5 values have?

...but then realized it was a mistake, because the rest of the metadata was calculated based on the fixed aspect ratio part of the image so the borders should correspond to those.

How did that mistake manifest in terms of viewing the video? You may remember I edited lots of L5 values for the movie Interstellar to match its varying black borders. Where the RPU came from constant AR video. I find the endresult playing back perfectly, where I experience no odd scenes showing artifacts or weird jumps in colors or brightness.

[hidef_rec]

Pardon the novice question. Just stumbled on this tool & can't wait to try it out. Have a DV profile 5 MKV that I want to convert to a profile 8.

Think my options saved correctly looking at the resulting ini file:
TEMP Folder=D\Temporary
TARGET Folder=I

I have my MKV in D\Temporary, but when I run DDVT_DEMUXER, it says no input file. What am I doing wrong? Thanks.

[GodzilaAvenger]

The thought that black borders would be taken into account does make sense. But it also confuses me. Unless I'm heavily mistaken or missing out on something, the L5 values would dictate the Dolby composer to apply the metadata only in the "active area". Which is the part between the black borders (given L5 values being correct). I mean, what other purpose would L5 values have?

I think what happens is that during the IMAX scenes the image fills up the active area, but in other scenes the active area consists of both the image and part of the black bars, as if it was an IMAX scene. I'm guessing when they produce the metadata they take that into account for the non-IMAX scenes (e.g. min_pq is pretty much always 0). E.g. Thor: Love and Thunder does this and sets the borders to 68 (in Disney+).


How did that mistake manifest in terms of viewing the video? You may remember I edited lots of L5 values for the movie Interstellar to match its varying black borders. Where the RPU came from constant AR video. I find the endresult playing back perfectly, where I experience no odd scenes showing artifacts or weird jumps in colors or brightness.

I did it based on the reasoning above mid creating the custom.json file for Nolan's last two Batmans, so I didn't get a chance to compare them. As mentioned above they don't seem to matter over HDMI so I'm not sure if I even can tell the difference.

[GodzilaAvenger]

Pardon the novice question. Just stumbled on this tool & can't wait to try it out. Have a DV profile 5 MKV that I want to convert to a profile 8.

Think my options saved correctly looking at the resulting ini file:
TEMP Folder=D\Temporary
TARGET Folder=I

I have my MKV in D\Temporary, but when I run DDVT_DEMUXER, it says no input file. What am I doing wrong? Thanks.

The TEMP folder is for storing temporary files created during the operation like e.g. temp.hevc extracted from the mkv during demuxing. You should go to the DDVT folder (where DDVT_DEMUXER is) and run

.\DDVT_DEMUXER 'path\to\file'

[hidef_rec]

Thanks, the process ran, but didn't get a new MKV that was profile 8. Doing something wrong; what I only end up with is a RPU.bin file in the output folder.

Here's the file I'm trying to convert to profile 8, which I believe has a HDR10 base layer. Right now, if my display only supports HDR10, I get pink/green picture.
General
Unique ID : 149613682865022055125766330203027420429 (0x708E8C14C60B5D36B87B68063A4E350D)
Complete name : C:\DDVT\test.mkv
Format : Matroska
Format version : Version 4
File size : 20.2 GiB
Duration : 1 h 35 min
Overall bit rate mode : Variable
Overall bit rate : 30.4 Mb/s
Movie name : Test Video
Encoded date : UTC 2022-01-03 00:13:27
Writing application : mkvmerge v64.0.0 ('Willows') 64-bit
Writing library : libebml v1.4.2 + libmatroska v1.6.4

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5@High
HDR format : Dolby Vision, Version 1.0, dvhe.05.06, BL+RPU
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1 h 35 min
Bit rate : 24.3 Mb/s
Width : 3 840 pixels
Original width : 3 838 pixels
Height : 2 072 pixels
Display aspect ratio : 1.85:1
Original display aspect ratio : 1.85: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.127
Stream size : 16.1 GiB (80%)
Language : English
Default : Yes
Forced : No

Audio
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 : 1 h 35 min
Bit rate mode : Variable
Bit rate : 6 071 kb/s
Maximum bit rate : 5 985 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
Delay relative to video : 40 ms
Stream size : 4.04 GiB (20%)
Title : Dolby ATMOS
Language : English
Default : Yes
Forced : No
Number of dynamic objects : 13
Bed channel count : 1 channel
Bed channel configuration : LFE

[GodzilaAvenger]

You can't convert a Profile 5 (P5) Dolby Vision (DV) mkv file into a Profile 8 (P8) one using DDVT because the Base Layer (BL) of P5 uses a different color space (IPTPQc2) from that of P8 (normal HDR10 or SMPTE 2086). Here's what you can do, if you have a P5 DV mkv and an HDR10 mkv.

1. Use the demuxer tool to extract the RPU (essentially the frame-by-frame metadata containing information about scene brightness and color) from the P5 mkv. Use the option to convert it to P8.1.

2. Use the injector tool to inject the RPU into the HDR10 mkv. Make sure they are in the same folder.

Now you have a P8 mkv. You can watch it on both HDR10-only displays and DV capable one.

[von Suppé]

...but in other scenes the active area consists of both the image and part of the black bars, as if it was an IMAX scene. I'm guessing when they produce the metadata they take that into account for the non-IMAX scenes (e.g. min_pq is pretty much always 0)

This would inspire for testing. As a first, how an image would come out when min-pq is not 0 with an active area that includes these partial black bars. I wonder if there'd be noticable "blackness" differences in them. When I have time, I'll do some.

As mentioned above they don't seem to matter over HDMI...
Sorry, but can you link to where this is said or implied? I must be overlooking.

Right now, if my display only supports HDR10, I get pink/green picture.

The pink/green picture is typical for when DV P5 is played back on non-compliant SW/HW.
P5 HW playback requires a DV capable player because of the proprietary colorspace GodzilaAvenger mentioned. Which makes P5 non backwards compatible - contrary to the likes of P7 and P8.
For playback on pc you can try MPV player. It handles P5 pretty good when you set VO to "gpu-next".

[fkid]

Sorry, but can you link to where this is said or implied? I must be overlooking.

https://forum.doom9.org/showthread.php?p=1979519#post1979519
https://forum.doom9.org/showthread.php?p=1979614#post1979614

I searched long and hard in official documentation and finally found some references to authoring for DV from Dolby and Davinci Resolve docs mentioning keeping min_pq below 0.25 or something like that (as close to 0 as possible) in order for HDMI playback devices not using L5 to not have issues with brightness/blacks, because they require the borders to be included in active area for subtitle display etc. This is why for most situations, the DV authoring is done so that if L5 is not being parsed or missing, then the DV still looks good through HDMI playback for uncropped video. Most of this is rendered moot for streaming services and retail UHD BR discs obviously. This is more of a case for us custom/Plex/tech savvy users and people who actually do their own DV grading and creation etc. In the end, conclusion is that L5 matters for (most) internal playback, as I mentioned in my test case for Hisense TV, but not HDMI playback devices.

[hidef_rec]

Awesome, thanks @GodzilaAvenger

[Fuso]

Hello! I've read the whole topic but I didn't get how to convert Double Layer P7 to Double or Single Layer P8. I was using LG B8 for watching DV through Plex. The method that I was using was one of the first ways (I think) to remux DV. Extract the BL + EL and audio with eac3toGUI and mux it to mp4. I've bought LG C2 and found that these files play as regulard HDR, probably LG updated something software-wise and made it not compatilble with Double Layer DV Profile 7 files.

So is it possible to make this one into something playable on the C2?

General
Complete name : G:\Филми\(2015) [4K] Mission Impossible Rogue Nation - Мисията невъзможна Престъпна нация.mp4
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42 (mp42/dby1/isom)
File size : 44.4 GiB
Duration : 2 h 11 min
Overall bit rate : 48.3 Mb/s
Encoded date : UTC 2021-08-25 06:38:12
Tagged date : UTC 2021-08-25 06:38:12

Video #1
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : hev1
Codec ID/Info : High Efficiency Video Coding
Duration : 2 h 11 min
Bit rate : 42.8 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.215
Stream size : 39.4 GiB (89%)
Default : No
Encoded date : UTC 2021-08-25 06:38:12
Tagged date : UTC 2021-08-25 06:38:12
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color pri : Display P3
Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2
Codec configuration box : hvcC

Video #2
ID : 2
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : Dolby Vision, Version 1.0, dvhe.07.06, EL+RPU, Blu-ray compatible / SMPTE ST 2086, HDR10 compatible
Codec ID : dvhe
Codec ID/Info : High Efficiency Video Coding with Dolby Vision
Duration : 2 h 11 min
Bit rate : 4 836 kb/s
Width : 1 920 pixels
Height : 1 080 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.097
Stream size : 4.44 GiB (10%)
Default : No
Encoded date : UTC 2021-08-25 06:38:12
Tagged date : UTC 2021-08-25 06:38:12
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color pri : Display P3
Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2
Codec configuration box : hvcC+dvcC

Audio
ID : 3
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Format settings : Dolby Surround EX
Codec ID : ac-3
Duration : 2 h 11 min
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)
Compression mode : Lossy
Stream size : 602 MiB (1%)
Language : English
Service kind : Complete Main
Default : No
Encoded date : UTC 2021-08-25 06:38:12
Tagged date : UTC 2021-08-25 06:38:12



When I try to open the file with DDVT it says that is not supporting Double Layer Profile 7

18271

[speedy]

Do we have any data on how accurate the HDR10+ to DoVi P8.1 conversion is?

What of the following would typically be more accurate and why?
1. Demux HDR10+, convert to DVp8.1 RPU and inject P8.1 RPU back into original ST2094 file.
2. Demux DVp5 RPU and inject into an ST2094 version that was likely mastered separately.
3. Demux DVp5 RPU and inject into an ST2086 version that was possibly mastered by the same colorist as the DVp5 version.

The HDR10+ tone mapping curve isn't mapped to Dolby Vision.
Only the frame brightness analysis is copied to the RPU.
Also, is this still the case?
Would demuxing the DVp5 RPU and injecting it into a ST2094 and/or ST2086 file ensure the tone mapping curve and frame brightness analysis are both preserved?

[Chilly]

Hi! I'm starting to study the topic of DV and I want to ask a couple of questions. Sorry for maybe stupid questions...

1. Please explain to me if Injector shows [NOT MATCH WITH RPU/VIDEO] is this normal? Will the output file be ok? The video has a borders of 278/278, while the RPU has a borders of 276/277. DDVT automatically saves borders 278/278.

2. I found BDRemux with DV P8 on the Internet, in MediaInfo displays information "ID in the original source m : 4113 (0x1011)" and "Original source medium : Blu-ray". Why is this information removed from my file after using DDVT? In the file from the Internet, the line "HDR format: Dolby Vision, Version 1.0, dvhe.08.06, BL + RPU, Blu-ray compatible / SMPTE ST 2086, HDR10 compatible" indicates exactly "Blu-ray compatible", while in my file after using DDVT, this information changes to "HDR10 compatible". What is the reason? Is it possible to keep the original information?

I'm from another country, so I'm sorry if I wrote something incomprehensibly ))

[DiscoD]

Love your tool use it almost daily,
attempting to convert hdr10+ to DV 8.1 to inject into an encode but im getting an error when its trying to create the RPU from the hdr10+ data
"error: expected ident at line 3 column 13"
added images below, i can say according to the source the HDR10+ data is pulled from an Amazon Rip.
https://i.ibb.co/PgP2bNn/error.png (https://ibb.co/PgP2bNn) https://i.ibb.co/NpyS64n/first.png (https://ibb.co/NpyS64n)

[GodzilaAvenger]

Do we have any data on how accurate the HDR10+ to DoVi P8.1 conversion is?

What of the following would typically be more accurate and why?
1. Demux HDR10+, convert to DVp8.1 RPU and inject P8.1 RPU back into original ST2094 file.
2. Demux DVp5 RPU and inject into an ST2094 version that was likely mastered separately.
3. Demux DVp5 RPU and inject into an ST2086 version that was possibly mastered by the same colorist as the DVp5 version.

You could try the three methods you mentioned and see if you notice any difference in the outcome. My guess is that they shouldn't differ much. Here's why: both HDR10+ and DV replace the static metadata of HDR10 (that tells your display how to best interpret the underlying video stream) with dynamic (i.e. scene-by-scene) metadata. In other words HDR10+ is ST 2084 with dynamic metadata (backwards compatible with HDR10), whereas HDR10 is ST 2084 with static metadata. Therefore, the base video stream in 2 and 3 would very likely be the same, and injecting a P8.1 RPU into each would yield a similar result during playback on a DV display. The difference is that 2 would also trigger HDR10+ on a compatible display, but 3 wouldn't.

I think converting between DV profiles (here P5 to P8.1) preserves the metadata (both tone mapping and brightness analysis), but as quietvoid said you'll only keep the brightness analysis during conversion from HDR10+ to P8.1, so 2 and 3 may give you a slightly better result than 1. I think it's generally better to use a native DV RPU than one obtained through conversion from HDR10+.

[GodzilaAvenger]

Hi! I'm starting to study the topic of DV and I want to ask a couple of questions. Sorry for maybe stupid questions...

1. Please explain to me if Injector shows [NOT MATCH WITH RPU/VIDEO] is this normal? Will the output file be ok? The video has a borders of 278/278, while the RPU has a borders of 276/277. DDVT automatically saves borders 278/278.

2. I found BDRemux with DV P8 on the Internet, in MediaInfo displays information "ID in the original source m : 4113 (0x1011)" and "Original source medium : Blu-ray". Why is this information removed from my file after using DDVT? In the file from the Internet, the line "HDR format: Dolby Vision, Version 1.0, dvhe.08.06, BL + RPU, Blu-ray compatible / SMPTE ST 2086, HDR10 compatible" indicates exactly "Blu-ray compatible", while in my file after using DDVT, this information changes to "HDR10 compatible". What is the reason? Is it possible to keep the original information?

I'm from another country, so I'm sorry if I wrote something incomprehensibly ))

1. That's ok. It's just warning you that the borders of the active area (where the image is) detected by DDVT is different from what is in the RPU. You can choose to keep the original borders, let DDVT change them, or manually set them altogether. Word of caution though, sometimes DDVT is off by 1 or 2 pixels when detecting borders, so you may want to manually verify the borders you get.

2. How exactly are you using DDVT? "dvhe.08.06, BL + RPU, Blu-ray compatible" is odd, I've seen both "dvhe.07.06, BL+EL+RPU, Blu-ray compatible" and "dvhe.08.06, BL+RPU, HDR10 compatible", but not what you said.

Side note: Since you said you found the BDRemux on the Internet, I hope you know that piracy is not ok, you should only use DDVT to add/modify metadata of the content you already own.

[GodzilaAvenger]

Love your tool use it almost daily,
attempting to convert hdr10+ to DV 8.1 to inject into an encode but im getting an error when its trying to create the RPU from the hdr10+ data
"error: expected ident at line 3 column 13"
added images below, i can say according to the source the HDR10+ data is pulled from an Amazon Rip.

Open the .json file in a text editor and see what's wrong with line 3. Probably a space or indent or something is missing/extra.

[Chilly]

1. That's ok. It's just warning you that the borders of the active area (where the image is) detected by DDVT is different from what is in the RPU. You can choose to keep the original borders, let DDVT change them, or manually set them altogether. Word of caution though, sometimes DDVT is off by 1 or 2 pixels when detecting borders, so you may want to manually verify the borders you get.

2. How exactly are you using DDVT? "dvhe.08.06, BL + RPU, Blu-ray compatible" is odd, I've seen both "dvhe.07.06, BL+EL+RPU, Blu-ray compatible" and "dvhe.08.06, BL+RPU, HDR10 compatible", but not what you said.

Side note: Since you said you found the BDRemux on the Internet, I hope you know that piracy is not ok, you should only use DDVT to add/modify metadata of the content you already own.

I don't do piracy. I have several Blu-rays that I want to save to my PC. So I decided to read this topic.

I created my BDRemux DV P7 with MakeMKV. Then I changed DV P7 to DV P8 using DDVT and compare my result with someone else's. Found differences:
1) the lines "ID in the original source m : 4113 (0x1011)" and "Original source medium : Blu-ray" are missing
2) line in my BDRemux: "HDR format: Dolby Vision, Version 1.0, dvhe.08.06, BL + RPU, HDR10 compatible / SMPTE ST 2086, HDR10 compatible"; line in someone else's BDRemux: "HDR format: Dolby Vision, Version 1.0, dvhe.08.06, BL + RPU, Blu-ray compatible / SMPTE ST 2086, HDR10 compatible".

Therefore, I had a question, why do I not have these lines (point 1) and why is the information in the line different (point 2)?

Thanks for answers!

[von Suppé]

I wouldn't worry too much about the lines you mention. They are metadata written on container level by the muxing application. There are several mkv muxing tools, authored by different people. Where sometimes metadata is blindly copied or wrong metadata can be written.

FYI what makes a DV mkv (or any other DV file for that matter) "bluray compatible" isn't written in stone or specs, but depends on interpretation. Often a file is considered to be bluray compatible, if it contains everything (as for video, at least) that's also on disc. Dolby Vision on UHDBD is Profile 7. Which specific specs mandate two layers: a HEVC 10-bit HDR encoded baselayer (BL) and an enhancement layer (EL). Where El carries RPU.
P7-mkv carries these exact same layers. Where in this respect, like GodzilaAvenger already said, "dvhe.08.06, BL + RPU, Blu-ray compatible" is odd. This line already says it: P8 is single-layer ("BL+RPU"). Having no EL, RPU is interleaved in BL. There are other reasons why P8 may not be compliant. BL may have been cropped. Or recoded with encoding parameters beyond UHDBD specs.

The above should be read as is, and not be confused with the following. On many forums it's said that DV P8 is equivalent to "Dolby Vision MEL". Which can raise an eyebrow.
The enhancement layer is either MEL or FEL. FEL means "full enhancement layer", which carries RPU and differential 10-to-12 bit videodata.
A "minimum enhancement layer" (MEL) only carries RPU. Consequently, when you extract RPU from a MEL, convert it to P8 and inject it in BL, the file actually contains all video- and metadata that is on disc. As such, it's said to be "equivalent" to DV MEL.

[GodzilaAvenger]

I don't do piracy. I have several Blu-rays that I want to save to my PC. So I decided to read this topic.

I created my BDRemux DV P7 with MakeMKV. Then I changed DV P7 to DV P8 using DDVT and compare my result with someone else's. Found differences:
1) the lines "ID in the original source m : 4113 (0x1011)" and "Original source medium : Blu-ray" are missing
2) line in my BDRemux: "HDR format: Dolby Vision, Version 1.0, dvhe.08.06, BL + RPU, HDR10 compatible / SMPTE ST 2086, HDR10 compatible"; line in someone else's BDRemux: "HDR format: Dolby Vision, Version 1.0, dvhe.08.06, BL + RPU, Blu-ray compatible / SMPTE ST 2086, HDR10 compatible".

Therefore, I had a question, why do I not have these lines (point 1) and why is the information in the line different (point 2)?

Thanks for answers!

Thanks for clarifying!

1) Since those tags are merely informational, my best guess is that DDVT just simply discards them, much like MKVToolNix did a few years ago (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2774).

2) Is there any difference between the files during playback? As far as I can tell MediaInfo is interpreting dv_bl_signal_compatibility_id (https://professional.dolby.com/siteassets/content-creation/dolby-vision-for-content-creators/dolby_vision_bitstreams_within_the_iso_base_media_file_format_dec2017.pdf) for that last part, so it is possible that either DDVT or the software used for that BDRemux are setting the wrong value for that field. Not sure if it really matters during playback though.

[Chilly]

I wouldn't worry too much about the lines you mention. They are metadata written on container level by the muxing application. There are several mkv muxing tools, authored by different people. Where sometimes metadata is blindly copied or wrong metadata can be written.

FYI what makes a DV mkv (or any other DV file for that matter) "bluray compatible" isn't written in stone or specs, but depends on interpretation. Often a file is considered to be bluray compatible, if it contains everything (as for video, at least) that's also on disc. Dolby Vision on UHDBD is Profile 7. Which specific specs mandate two layers: a HEVC 10-bit HDR encoded baselayer (BL) and an enhancement layer (EL). Where El carries RPU.
P7-mkv carries these exact same layers. Where in this respect, like GodzilaAvenger already said, "dvhe.08.06, BL + RPU, Blu-ray compatible" is odd. This line already says it: P8 is single-layer ("BL+RPU"). Having no EL, RPU is interleaved in BL. There are other reasons why P8 may not be compliant. BL may have been cropped. Or recoded with encoding parameters beyond UHDBD specs.

The above should be read as is, and not be confused with the following. On many forums it's said that DV P8 is equivalent to "Dolby Vision MEL". Which can raise an eyebrow.
The enhancement layer is either MEL or FEL. FEL means "full enhancement layer", which carries RPU and differential 10-to-12 bit videodata.
A "minimum enhancement layer" (MEL) only carries RPU. Consequently, when you extract RPU from a MEL, convert it to P8 and inject it in BL, the file actually contains all video- and metadata that is on disc. As such, it's said to be "equivalent" to DV MEL.

Thanks for clarifying!

1) Since those tags are merely informational, my best guess is that DDVT just simply discards them, much like MKVToolNix did a few years ago (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2774).

2) Is there any difference between the files during playback? As far as I can tell MediaInfo is interpreting dv_bl_signal_compatibility_id (https://professional.dolby.com/siteassets/content-creation/dolby-vision-for-content-creators/dolby_vision_bitstreams_within_the_iso_base_media_file_format_dec2017.pdf) for that last part, so it is possible that either DDVT or the software used for that BDRemux are setting the wrong value for that field. Not sure if it really matters during playback though.

Thank you very much for your explanations! Yes, I understand that this does not affect playback in any way. I'm just a perfectionist and when I saw the differences in the metadata of my file and some popular "pirate", I thought that I was doing something wrong :)

[-QfG-]

About cropping:

1. There are any Retail Untouched RPUs without cropping informations. The tool says in this case :NO CROPPING INFORMATIONS FOUND. You can leave this RPUs untouched, but it is recommended to set the valid Borders.
I think, that no cropping informations in the RPU is the same how 0 entries. But i have no proof for this statement.

2. IMAX Format: You can do 3 Things:


Set all borders to 0 (this is the way that i use)
Set all borders to the lowest entry (Example: IMAX Scenes Borders 42/42, Normal Scenes Borders 272,272 -> set Borders to 42/42
For Freaks xd - Create a custom.json file and set all borders manually for IMAX / Normal frames. Good Luck :) In this case, don't forget to turn off border manipulation via the tool himself.


3. BORDERLESS VIDEO: If the video is cropped or full 16:9 without Black Bars, set all boreder entries to 0!

In my Tests i have no problems with RPUs with borders entries of 0 with cropped content. BUT ! I have trouble with RPUs with Border entries other than 0 by cropped (borderless) content!

In all cases it is recommended to set the correct borders in the RPU for maximal compatibility with the hardware players.

[hidef_rec]

Awesome tool, big thanks to you @-QfG-. Trying to do my first merge of a DV file w/a HDR10+ file to end up with a combi one. Before I start below w/the injector tool to inject the RPU into the HDR10+ mkv, how/where do I set borders to zero? This is borderless video. Thanks.

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

Filename = [myvideohdr10plus.mkv]
Video Info = [Resolution = 3840x1634] [Codec = HEVC-10Bit-YUV-4:2:0] [Frames = 154104] [FPS = 23.976]
HDR Info = [SMPTE ST 2094 App 4, Version 1, HDR10+ Profile A compatible]
Borders = [LEFT=0 px], [TOP=0 px], [RIGHT=0 px], [BOTTOM=0 px] [NOT MATCH WITH RPU]

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

Filename = [RPU.bin]
RPU Info = [DV Profile = 8] [CM Version = 2.9] [Frames = 154104]
Borders = [BORDERS NOT SET IN RPU]

== FILE OUTPUT =========================================================================================================

Filename = [myvideohdr10plus_[BL+RPU]]
RPU Info = [DV Profile = 8] [CM Version = 2.9] [Frames = 154104]
Borders = [LEFT=0 px], [TOP=0 px], [RIGHT=0 px], [BOTTOM=0 px]
Delay = [0 FRAMES]

== MENU ================================================================================================================

1. DELAY : [0 FRAMES]
2. Match L6 Metadata : [NO]* *Change L6 Metadata to match with Video.
3. Remove HDR10+ : [NO]
4. MUX STREAM IN MKV : [NO]
6. EDIT ACTIVE AREA* *Setting Crop Values. DISCARD set Borders to [LEAVE UNTOUCHED].

S. START

Change Settings and press [S] to start Injecting
Select a Letter 1,2,3,4,6,[S]tart


Out of curiosity, is it (or will it at some point be) possible to convert DV to HDR10+?

[GodzilaAvenger]

Per what you've shown, DDVT will automatically set the borders to 0. You can edit the borders by pressing 6 and entering the Edit Active Area screen, where you can modify individual borders.

[hidef_rec]

Thanks for confirming what I was suspecting. Resulting file plays fine via Shield TV & Zidoo Z9X.

[MrDover]

I am trying to use DDVT_DEMUXER and it says:
"'findstr' is not recognized as an internal file or external command, operable program or batch file"
multiple times in place of where the 1, 2 and 5 options should be in the DUMUXER.

Options 3 and 4 still show normally and I am able to Save RPU and convert RPU but I can not use any of the other options.

Has any one else experienced this or know of a way to fix this? I have tried 2 separate versions (v0.50-fixed and v0.45) and both do the same

[GodzilaAvenger]

Mine works fine. Can you post a screenshot?

[MrDover]

Mine works fine. Can you post a screenshot?

https://ibb.co/vQ5vKqg

Image Link: https://ibb.co/vQ5vKqg

[MrDover]

https://ibb.co/vQ5vKqg

link: https://ibb.co/vQ5vKqg

[GodzilaAvenger]

It's a bit odd since the menu itself doesn't use 'findstr' per se, though one of the submenus does (you can open DDVT_DEMUXER in a text editor to see the code). Try this (https://stackoverflow.com/questions/10244181/findstr-is-not-recognized-as-an-internal-or-external-command) and see if it fixes the problem.

[Chilly]

Please tell me who used DDVT_MKVTOMP4, these MP4 files with DVP8 will play on DV capable TV?

And yet, after converting MKV to MP4, audio and subtitles are designated as "SoundHandler" and "SubtitleHandler" in Media Player Classic. Correct (other) titles are displayed in MediaInfo. How can this be fixed?

[MrDover]

It's a bit odd since the menu itself doesn't use 'findstr' per se, though one of the submenus does (you can open DDVT_DEMUXER in a text editor to see the code). Try this (https://stackoverflow.com/questions/10244181/findstr-is-not-recognized-as-an-internal-or-external-command) and see if it fixes the problem.

This seemed to work great thank you very much. I didn’t think to google that error as I thought it was maybe just a bug with the tool rather than something with my own computer

[V_Amoleo]

I've been using this set of tools to convert HDR10+ to Dolby Vision with great success but I've now come across two titles where I'm struggling.

I have a UK three UHD Blu-ray collection of Shaun of the Dead, Hot Fuzz and The World's End. Shaun of the Dead converted from HDR10+ to Dolby Vision no problem at all. But I've tried the other two and they both create broken Dolby Vision versions (messed up colours, brightness all over the place).

I noticed that Shaun of the Dead, after conversion is labelled in MediaInfo as "Dolby Vision, Version 1.0, dvhe.08.06, BL+RPU, HDR10 compatible / SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible" but Hot Fuzz and The World's End are labelled as "Dolby Vision, Version 1.0, dvhe.07.06, BL+EL+RPU, Blu-ray compatible / SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible"

I'm pretty sure I used these settings for all three:
DDVT DEMUXER
Save HDR BL: No, Default.
Save HDR10+ Metadata: No, Default.
Skip HDR10+ Validation: No, Default.
Remove HDR10+ Metadata from BL: No, Default.
Convert HDR10+ Metadata to DV: Yes, Default.
Content Mapping Version: 4.0.

DDVT INJECTOR
Delay: 0 Frames, Default.
Match L6 Metadata: No, Default.
Remove HDR10+: No, Default.
Mux Stream in MKV: Yes.
Edit Active Area: Left = 0, Top = 264, Right = 0, Bottom = 264. Automatically detected as the RPU didn't match the video.

Any ideas?

[von Suppé]

Injecting HDR10+ metadata has stopped working in the DDVT_INJECTOR.cmd. Pressing S for Start doesn't seem to launch anything. Injecting HDR10+ with hdr10plus_tool.exe cmd works.
RPU injecting goes properly with the script. Can you have a look please?

[GodzilaAvenger]

I have a UK three UHD Blu-ray collection of Shaun of the Dead, Hot Fuzz and The World's End. Shaun of the Dead converted from HDR10+ to Dolby Vision no problem at all. But I've tried the other two and they both create broken Dolby Vision versions (messed up colours, brightness all over the place).

I noticed that Shaun of the Dead, after conversion is labelled in MediaInfo as "Dolby Vision, Version 1.0, dvhe.08.06, BL+RPU, HDR10 compatible / SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible" but Hot Fuzz and The World's End are labelled as "Dolby Vision, Version 1.0, dvhe.07.06, BL+EL+RPU, Blu-ray compatible / SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible"

Any ideas?

It's odd that you're getting a Profile 7 RPU, as far as I know you should be getting a Profile 8 one like Shaun of the Dead. You could use the FRAMEINFO tool on the RPUs of Hot Fuzz and Shaun of the Dead to get all the frame info in a .json file and then compare them and the two hdr10plus.json files to see if you can spot the difference. Apart from that, maybe try CM2.9, and also check your workflow to ensure you're not accidentally injecting the wrong RPU.

Injecting HDR10+ metadata has stopped working in the DDVT_INJECTOR.cmd. Pressing S for Start doesn't seem to launch anything. Injecting HDR10+ with hdr10plus_tool.exe cmd works.
RPU injecting goes properly with the script. Can you have a look please?

I tried the HDR10+ injector tool yesterday and it was working fine. Were you able to figure out what the problem was?

On that note, I don't think HDR10+ injection needs video border analysis, so maybe it can be skipped in future versions of the tool.

[von Suppé]

I tried the HDR10+ injector tool yesterday and it was working fine. Were you able to figure out what the problem was?

Maybe. That is, tried with version 0.48c beta and injecting HDR10+ goes well. I reckon this version uses an older "hdr10plus_tool.exe" but I highly doubt if that makes the difference. Because latest hdr10plus_tool.exe works when run with cli.

Tried again on latest QfG version. Very short path, no weird characters in path & names. Still no dice. I think it's a bug in the script.
Or can I be unaware of usage change? Videosource is "video.hevc". HDR10+ metadata is "HDR10Plus.json".
Still works with 0.48c. Note I am on Windows 7.

[GodzilaAvenger]

Maybe. That is, tried with version 0.48c beta and injecting HDR10+ goes well. I reckon this version uses an older "hdr10plus_tool.exe" but I highly doubt if that makes the difference. Because latest hdr10plus_tool.exe works when run with cli.

Tried again on latest QfG version. Very short path, no weird characters in path & names. Still no dice. I think it's a bug in the script.
Or can I be unaware of usage change? Videosource is "video.hevc". HDR10+ metadata is "HDR10Plus.json".
Still works with 0.48c. Note I am on Windows 7.

I think I figured out what the problem is. Injecting into .mp4 and .mkv works fine, but not into .hevc because of a bug. For a temporary fix, replace this line
CHOICE /C 1S /N /M "Select a Letter 1,[S]tart"
(should be line 433) with this line
CHOICE /C 1WS /N /M "Select a Letter 1,[S]tart"

Another, perhaps better fix would be to replace (line 436, without changing line 433)
if "%ERRORLEVEL%"=="2" (
if "%MUXINMP4%"=="NO" set "MUXINMP4=YES"
if "%MUXINMP4%"=="YES" set "MUXINMP4=NO"
if "%MUXINMKV%"=="NO" set "MUXINMKV=YES"
if "%MUXINMKV%"=="YES" set "MUXINMKV=NO"
)
with
if "%ERRORLEVEL%"=="2" (
if "!RAW_FILE!"=="TRUE" (
goto HDR10P_BEGIN
) else (
if "%MUXINMP4%"=="NO" set "MUXINMP4=YES"
if "%MUXINMP4%"=="YES" set "MUXINMP4=NO"
if "%MUXINMKV%"=="NO" set "MUXINMKV=YES"
if "%MUXINMKV%"=="YES" set "MUXINMKV=NO"
)
)
I think this bug was introduced when the HDR10+ delay functionality was added.

[von Suppé]

I think I figured out what the problem is. Injecting into .mp4 and .mkv works fine, but not into .hevc because of a bug. For a temporary fix, replace...

Your suggested script adjustment works like a charm.

:thanks: for the bug hunt, GA.

[-QfG-]

-v0.51 Online
*Updated dovi_tool to v2.0.1.
*Updated hdr10plus_tool to v1.5.2.
*Updated mkvtoolnix to v 73.0.0.0.
*Bugfix in Injector script for HDR10+ injecting (thx "von Suppé" for finding and "GodzilaAvenger" for fixing).

[PoeBear]

Is there any faster way to get an RPU from an m2ts? With DGDecNV, I index the HDR10 and Dolby Vision layers from a disc dump's m2ts, so nothing I manipulate in AviSynth is a raw HEVC. But to get an RPU I have to demux the EL HEVC, to then be able to extract the RPU? If there's no faster/direct way, is it possible to demux/extract from a m2t2 all within DDVT?

[-QfG-]

I know no way to demux the RPU without extracting the RAW stream from container.

[von Suppé]

HDR10+ injecting in hevc stream works again in version 0.51.

Thanks for the update @-QfG-

[V_Amoleo]

It's odd that you're getting a Profile 7 RPU, as far as I know you should be getting a Profile 8 one like Shaun of the Dead. You could use the FRAMEINFO tool on the RPUs of Hot Fuzz and Shaun of the Dead to get all the frame info in a .json file and then compare them and the two hdr10plus.json files to see if you can spot the difference. Apart from that, maybe try CM2.9, and also check your workflow to ensure you're not accidentally injecting the wrong RPU.


Thanks for this. I'll take a look at the FRAMEINFO tool.

I'd already tried CM2.9 unfortunately and I did double check it was the correct RPU I was using. Neither of those worked.

Update: Just tried with the latest version (0.5.1 vs 0.5.0) and it's converted fine. One of the tool updates must have fixed it.

[MoonKnight]

Hey guys, thanks to all the best that help noobs like us here, thank you really much for all the hard work around HDR10+/DOLBY VISION, you guys deserve the best.

Anyway, Anyone to help me fix my commandline with dovi_tool ?

dovi_tool generate -j RPU.json -o RPU_from_json.bin

gives me this error :

Reading generate config file...
Error: unknown variant `dovi_profile`, expected `V29` or `V40` at line 1 column 16

====

my RPU is cmv2.9 , how can I fix this ? conversion from json to .bin does not want to work...

[quietvoid]

It's not exactly clear what you're trying to do, but going from an exported JSON (using dovi_tool export) back to a .bin is not supported.

[MoonKnight]

It's not exactly clear what you're trying to do, but going from an exported JSON (using dovi_tool export) back to a .bin is not supported.

oh ok, my bad then, I thought the conversion was supported

and yes I used export

[ckbro]

It appears that when I crop the RPU, either during demux or injection, to match sed crops video stream the video stream will slightly speed up and become desynced from the audio track after injection. Any idea what could be going on here?