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

[Blue_MiSfit]

Right, DEE can make any current flavor of DoVi, HDR10, and SDR from a DoVi master (Typically J2K or ProRes) - provided you're cool with having it do tone mapping in some of those cases e.g. SDR :)

[Lucius Snow]

Thanks for your feedback.

I'm trying to encode to HEVC sample using this command line:

ffmpeg.exe -probesize 100MB -i "E:\test.mov" -an -r 25 -pix_fmt yuv420p10le -f yuv4mpegpipe -strict -1 - | "x265.exe" --y4m - --dither --preset medium --level 6.1 --preset veryslow --no-high-tier --profile main10 --bitrate 80000 --vbv-maxrate 100000 --vbv-bufsize 60000 --deblock -1:-1 --hdr-opt --hrd --aud --min-luma 64 --max-luma 940 --range limited --videoformat component --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --dolby-vision-profile 8.1 --dolby-vision-rpu E:\test.bin --master-display "G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,500)" --max-cll "3279,223" --overscan show --no-open-gop --min-keyint 1 --keyint 25 --repeat-headers --rd 3 -o "E:\test.hevc"

The RPU was generated from the XML (Profile 8.1) coming from DaVinci by this command :

dovi_tool generate --xml E:\test.xml -o E:\test.bi

At the end of the encoding, I get several errors "Dolby Vision RPU not found for POC XXXX". What does it mean?

EDIT: A new test from another video sample worked without any error. The guilty was probably my source.

[quietvoid]

I get several errors "Dolby Vision RPU not found for POC XXXX". What does it mean?

It means the video and the metadata are not the same frame count, so probably that the video being encoded has less frames.

[GodzilaAvenger]

Talking about Profile 7, I've always converted the RPU of my BluRay re-encods to Profile 8.1 and then added them to the stream. Would it work (i.e. trigger DV on the player) if I just inject the original Profile 7? Does it matter if the Profile 7 is MEL or FEL?

[quietvoid]

Talking about Profile 7, I've always converted the RPU of my BluRay re-encods to Profile 8.1 and then added them to the stream. Would it work (i.e. trigger DV on the player) if I just inject the original Profile 7? Does it matter if the Profile 7 is MEL or FEL?

It would probably trigger Dolby Vision on your display but the EL will probably not be aligned.
There's no point in keeping the original MEL, it's equivalent to profile 8.

For FEL, the processing probably wouldn't work correctly on a reencoded base layer and it might lead to incorrect rendered image.
The only correct method is to process the FEL before reencoding (see https://github.com/erazortt/DoViBaker), and use a profile 8 RPU with the mapping metadata removed.

[GodzilaAvenger]

Thanks!

DoViBaker is interesting, from what I could gather it seems to process the BL and FEL to get the original 12-bit stream, then use the RPU to tonemap it back down to a 10-bit stream. Is that correct?

[quietvoid]

Thanks!

DoViBaker is interesting, from what I could gather it seems to process the BL and FEL to get the original 12-bit stream, then use the RPU to tonemap it back down to a 10-bit stream. Is that correct?

I've never used it but it should output 16 bit, which you can convert back to 10 bit and encode.
I don't think it does anything else with the RPU.

[rco133]

Hi.

Got a question regarding dovi_tool.

dovi_tool.exe -c -m 2 mux -b encoded_bl.h265 -d -e demuxed_el -o output_with_dv.265

Should that not give the same output file as this:

dovi_tool.exe -m 2 -c extract-rpu demuxed_el
dovi_tool.exe inject-rpu --rpu-in RPU.bin --input encoded_bl.h265

Should the two command lines not do the same thing?

Except the first one doesn't extract the RPU file.

Or am I misunderstanding something?

When I do a binary compare of the two files, they are not identical at all.

Thanks in advance.

rco133

[quietvoid]

Hi.
Should the two command lines not do the same thing?
Except the first one doesn't extract the RPU file.

Or am I misunderstanding something?

When I do a binary compare of the two files, they are not identical at all.
Totally normal, the RPU is smaller than the EL.
While the EL also contains RPU, it's a regular HEVC bitstream otherwise.

[rco133]

Totally normal, the RPU is smaller than the EL.
While the EL also contains RPU, it's a regular HEVC bitstream otherwise.

Ok.

The EL is a lot bigger than the RPU. But shouldn't the first command ignore the EL video, and just mux in the RPU into the bl since I am using the -d switch?

The file size of the two resulting files are exactly the same down to the byte. But when I do a "fc /B file1 file2" it lists a ton of differences between the two files.

I thought that using -d in the mux command line, would do the same as extracting the RPU from the EL and injecting it into the bl.

So I guess my quation really is, why does using the -d switch in the mux command, not give the same result as extracting the RPU and injecting the RPU into the bl?

In both cases I am using -m 2 to convert to Profile 8.

rco133

[quietvoid]

So I guess my quation really is, why does using the -d switch in the mux command, not give the same result as extracting the RPU and injecting the RPU into the bl?
mux with --discard works, since you said the files are the exact same size.
The difference is that extracting the RPU reorders according to the source video file, while muxing the EL directly doesn't reorder anything.

Now it should only make a difference if the BL you reinject into is different from the source.
In your first post you said that the RPU is injected into a reencoded video, so everything seems to work as expected.

When you mux the original EL, the RPU is going to be out of order with the reencoded video.

[rco133]

mux with --discard works, since you said the files are the exact same size.
The difference is that extracting the RPU reorders according to the source video file, while muxing the EL directly doesn't reorder anything.

Now it should only make a difference if the BL you reinject into is different from the source.
In your first post you said that the RPU is injected into a reencoded video, so everything seems to work as expected.

When you mux the original EL, the RPU is going to be out of order with the reencoded video.

Yes, I am working with an encoded BL in both cases, and the EL has just been demuxed using dgdemux.

Both output files say they contain:

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

So i guess even though they are not binary identical, they both should play back fine?

The only difference between the two output files is that one is made with the mux -d command line, and the other file is made by extracting the RPU manually and then injection it manually. In both cases the BL (input file) is the same encoded BL.

Just want to be sure that I am not messing something up, by using the mux -d line, since that saves me from actually extracting the RPU.

rco133

[quietvoid]

The only difference between the two output files is that one is made with the mux -d command line, and the other file is made by extracting the RPU manually and then injection it manually. In both cases the BL (input file) is the same encoded BL.

Just want to be sure that I am not messing something up, by using the mux -d line, since that saves me from actually extracting the RPU.You are messing something up by using the original EL with mux.
The metadata will most definitely be in the wrong order, so playback will show noticeable brightness changes.

You should be extracting the RPU and encoding with x265/ffmpeg directly with --dolby-vision-rpu, that way you don't need to inject.

[rco133]

You are messing something up by using the original EL with mux.
The metadata will most definitely be in the wrong order, so playback will show noticeable brightness changes.

You should be extracting the RPU and encoding with x265/ffmpeg directly with --dolby-vision-rpu, that way you don't need to inject.

Ok.

I don't understand that, and that is why I am asking, and really appreciate your expertise on this matter.

I thought that when using the RPU only, I could mux or inject it into the original BL or the encoded BL without problems.

I convert the RPU from Profile 7 to Profile 8 and then use just the RPU. I am not using the rest of the EL. Just the RPU.

That way I thought that all would be good. But maybe that is not the case?

rco133

[rco133]

Ok.

I don't understand that, and that is why I am asking, and really appreciate your expertise on this matter.

I thought that when using the RPU only, I could mux or inject it into the original BL or the encoded BL without problems.

I convert the RPU from Profile 7 to Profile 8 and then use just the RPU. I am not using the rest of the EL. Just the RPU.

That way I thought that all would be good. But maybe that is not the case?

rco133


What if I do the following:

dovi_tool.exe -m 2 -c extract-rpu -i demuxed_EL.h265 -o RPU.bin

After this I should have a profile 8 RPU with no crop.

dovi_tool.exe inject-rpu -i x265_encoded_BL.h265 -r RPU.bin -o output_wit_dv.h265

Will that work, or will there still be issues if I do that?

rco133

[-QfG-]

-v0.49
*INJECTOR-Support for HDR10+ JSON Data delaying.
*Updated hdr10plus_tool to v1.4.0.
*Updated dovi_tool to v1.5.7.

[von Suppé]

Thanks for the update, -QfG-.
Has an old bug sneaked in? The injector doesn't work when there is spaces in the path name

[-QfG-]

Thanks for the update, -QfG-.
Has an old bug sneaked in? The injector doesn't work when there is spaces in the path name

Really? :angry:

No changes in functions lines, only reworked menu and adding the new feature in the hdr10+ area.
Maybe you have () in your filenames? I tested succesfully with a spaced foldername.

[von Suppé]

Maybe you have () in your filenames?
Yes, indeed that was the culprit. Thank you.

[von Suppé]

FYI I had a mkv with videostream having ID 2 and audiostream having ID 1. The file plays fine, but the injector doesn't work with this. During demux stage, the TEMP folder seems to be filled with the audiostream, instead of video. After which the script ends within seconds; the resulting "injected hevc" ending up 0 in size.

Manually demuxing first and using video elementary stream of course solves this. Or using a remux where video is "on top".
I haven't seen much of such muxed mkv's but I reckon they'd be within matroska specification. Maybe the script can use improved videostream detection?

[karbre]

I'm thinking about editing out a section (a company logo which does not belong to the movie) of a FEL UHD BD Remux done with MakeMKV. Unfortunately, the edit is not along keyframes (in that case it would be a simple MKVToolnix job).

I thought of the following procedure to edit out the section and keep a valid FEL file (I know FEL MKV playback is not yet supported.)

1. Demux file into BL, EL and RPU with DDVT Tool.
2. Edit out the section from the BL with TMPGEnc MPEG Smart Renderer 6 (only minimal reencode, if at all (in case the to-be-removed section is at the end of the file, then sometimes no encoding at all is needed)).
3. Perform the exact same smart render operation on the EL (probably losing the RPU here).
4. Edit the RPU accordingly with dovi_tool editor (remove same frames as in the video tracks).
5. Re-inject edited RPU into edited EL (HOW?).
6. Re-inject combined EL+RPU into edited BL (HOW?).

Is this approach possible? If yes, what are the correct commands for steps 5 and 6?

[-QfG-]

Step5: Rename EL.hevc to ELisBL.hevc and copy the RPU.bin file in the same directory. Start INJECTOR and mux the RPU into this stream.
Step6: Rename the final stream from above to EL.hevc and copy this stream near the BL.hevc. Start INJECTOR and mux the EL Layer with included RPU into the BL.hevc Stream.

[karbre]

Great, thanks for the feedback!

[MoonKnight]

Hey guys,

a quick question, do we need to set the borders for the RPU when muxing an EL.hevc (FEL) with the BL ?

Because I see that the RPU inside the EL.hevc has this :


{
"Level5": {
"active_area_left_offset": 0,
"active_area_right_offset": 0,
"active_area_top_offset": 0,
"active_area_bottom_offset": 0
}

it seems to be like this by defaut so better to not mess with it, right ? It's only RPU 8.1 that needs to have borders correctly set ?

[von Suppé]

To my knowledge, borders always have to be set correctly. Values being 0 would mean video has no black borders.
Why does "it seems to be like this by default" to you?

[MoonKnight]

To my knowledge, borders always have to be set correctly. Values being 0 would mean video has no black borders.
Why does "it seems to be like this by default" to you?

because it's the RPU that I extracted from a retail 4K Bluray with a FEL Layer

I looked inside the RPU, and borders are not set,

[von Suppé]

Then the video should have no black borders. Of course you can check this, to see if RPU is correct with the values.

[-QfG-]

-v0.50
*Works now correct with all symbols in filenames.
*Updated mkvtoolnix to v 71.1.1.0.

[rushuna86]

First time posting here, so sorry if this has been answered somewhere else? For BD Remux FEL MKV. BL+EL+RPU to make this into a FEL BDMV to play on Oppo Clone. Are these steps accurate?

1. Using Demuxer Strip BL + EL into 2 streams.
2. eac3to audio stream to get back core.
3. TSmuxer BL+EL+audio and mux.

RPU gets discarded for this right?

[-QfG-]

Right. You need only eac3to for TrueHD Atmos tracks, because you need a thd+ac3 track. RPU is included in the EL Layer, so you have a valid P7 Double Layer m2ts with tsmuxer. The OPPO or his clone will playback this file with FEL, if the DV Layer is FEL. Also you can create an ISO file, the OPPO will playback FEL DV, too.

[rushuna86]

Right. You need only eac3to for TrueHD Atmos tracks, because you need a thd+ac3 track. RPU is included in the EL Layer, so you have a valid P7 Double Layer m2ts with tsmuxer. The OPPO or his clone will playback this file with FEL, if the DV Layer is FEL. Also you can create an ISO file, the OPPO will playback FEL DV, too.

Thank you for answering and thank you for making this fantastic tool.

[fkid]

-v0.50
*Works now correct with all symbols in filenames.
*Updated mkvtoolnix to v 71.1.1.0.

Thank you so much for continuing to support these scripts. No longer have to move files or rename in any cases.

Unrelated question, but just want clarification and couldn't find clear answer online. If Level 6 metadata is "incorrect" or inconsistent between DV RPU and HDR base file, but reasonable, does it matter if the HDR file it is injected to already has the MaxCLL/FALL? For example, I have a WEB-source converted Profile 5 to Profile 8 DV RPU, and it shows Level 6 as this:

"Level6": {
"max_display_mastering_luminance": 4000,
"min_display_mastering_luminance": 50,
"max_content_light_level": 0,
"max_frame_average_light_level": 0

And the original HDR file I inject it into shows in MediaInfo:

Mastering display luminance : min: 0.0010 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 1000 cd/m2
Maximum Frame-Average Light Level : 410 cd/m2

If I already injected, and noticed later, do I have to go back and demux the DV RPU, adjust the Level 6 numbers to match and re-inject? Or does it not really matter if the source video already has these numbers? @quietvoid, do you know when the Level 6 metadata gets used/parsed as it is stored in the DV layer, if it is only really meant for HDR fallback, where the DV Level 6s presumably are ignored anyway by the TV/video player? It doesn't really explain it in the Dolby documentation either, other than to say "L6 metadata is required for HDR10 content and includes two numbers namely, MAXCLL and MAXFALL. These values are not normally calculated as part of the Dolby Vision analysis and will usually have to be calculated separately" (https://professionalsupport.dolby.com/s/article/Dolby-Vision-Metadata-Levels?language=en_US). Is this meant for pro workflows only or industry implementation, whereas most of us use .mkv or .mp4 containers and the HDR metadata is already present? It's a little confusing, no?

Ultimately, I am just wondering if I have to go back and fix a bunch of previous files I have where the Level 6 in the DV doesn't match the underlying HDR file MDL/MaxCLL/MaxFALL?

@-QfG-, should the script maybe default to always match Level 6 metadata with the source video file to avoid these inconsistencies? Or at least show the Level 6 metadata on screen DV RPU vs. HDR file when about to inject DV RPU? This way, user has chance to decide if to match/change in case it's not same as HDR source video? Why not always match to HDR source?

Thank you kindly!!

[quietvoid]

Ultimately, I am just wondering if I have to go back and fix a bunch of previous files I have where the Level 6 in the DV doesn't match the underlying HDR file MDL/MaxCLL/MaxFALL?
It doesn't really matter. I haven't found a case where the L6 metadata is used.

[fkid]

It doesn't really matter. I haven't found a case where the L6 metadata is used.

Thank you so much for quick reply!

[-QfG-]

should the script maybe default to always match Level 6 metadata with the source video file to avoid these inconsistencies?

No, L6 Metadata will be untouched in Standard settings. in few cases i have RPUs with abstract L6 Metadata and the tool will not inject this RPUs. Only for this cases i have implant this feature.

[fkid]

No, L6 Metadata will be untouched in Standard settings. in few cases i have RPUs with abstract L6 Metadata and the tool will not inject this RPUs. Only for this cases i have implant this feature.

Makes sense, given quietvoid's confirmation too. FYI, I noticed small bugs in latest DDVT_INJECTOR.cmd,

1st bug with FPS:

"!MEDIAINFOpath!" --output=Video;%%FRAMERATE%% "%~1">"%TEMP%\Info.txt"

should be

"!MEDIAINFOpath!" --output=Video;%%FrameRate%% "%~1">"%TEMP%\Info.txt"

Otherwise, it shows FPS as "n.a." as it is now, not sure if it impacts actual injection process, but confirmed this was working in previous version and when I modify that line, it works again.

2nd bug with borders matching: No longer showing Borders = lines for VIDEO INPUT/RPU INPUT sections. Tested file with v0.49 beta working and v0.50 not showing at all.

P.S. I am guessing you already know this but with video files with changing AR, such as Tenet (IMAX scenes), the automatic border detection is flawed, as it uses largest borders found, when it should be set to 0,0,0,0 in final injection and needs manual override sometimes. Just something I noticed.

Cheers. :)

[-QfG-]

"!MEDIAINFOpath!" --output=Video;%%FRAMERATE%% "%~1">"%TEMP%\Info.txt"

will fix this soon...

EDIT :

v0.50-FIXED Online. Fixed some major bugs in the injector script. THX for response!

[fkid]

will fix this soon...

EDIT :

v0.50-FIXED Online. Fixed some major bugs in the injector script. THX for response!

Thank you!!

[DoomFan]

I'm still having an issue with DDVT_INJECTOR.cmd. Seems to have started about a month ago when a big Windows 11 update came out. It's been an issue on every version from 47 to 50-Fixed.

When I run DDVT_INJECTOR.cmd I get an error that says Missing input file! File does not exist! *filepath* but the file is 100% there. I've even renamed it to something simple, in case "." or "-" in the filename was an issue.

Then after I click "OK" on that error, the DDVT_INJECTOR.cmd window says:

Analysing Video Borders. Please wait ...
The system cannot find the file C:\Users\me\AppData\Local\Temp\Crop.txt.
Analysing failed.

Analysing DV RPU.bin. Please wait ...

Something's not right. I've been using this tool without issue for months. Within the last month or so it keeps failing, on every version I try. Any ideas?

[zzreel]

Tool's been working for everything I throw at it except this one specific file.. I'm trying to extract RPU (version 8) and the file itself has a real working DV but the tool gives me this error:

Warning: Unexpected RPU NALU found for frame 15898. Discarding.

It shows that per each frame, completing the extract process with a 0kb RPU file.

Reordering metadata... thread 'main' panicked at 'Missing frame/slices for metadata! Decoded index 224929', src\dovi\general_read_write.rs:311:21

Is there something special about this file or something? The DV was already taken from another source for this file, thence dv hybrid, but I was able to extract others like it without issue.
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : Dolby Vision, Version 1.0, dvhe.08.06, BL+RPU, HDR10 compatible / SMPTE ST 2086, HDR10 compatible
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2 h 36 min
Bit rate : 37.0 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.186
Stream size : 40.4 GiB (89%)
Title : DV HYBRID
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.0000 cd/m2, max: 1000 cd/m2

[quietvoid]

Sounds like the file was possibly injected in twice before the tool ignored existing RPU NALUs.

[zzreel]

Sounds like the file was possibly injected in twice before the tool ignored existing RPU NALUs.

Interesting. Any way I could still extract it?

[quietvoid]

I'm not sure, the current workaround is best-effort when it comes to invalid/duplicate RPUs.
If you can reproduce the error with a smaller sample (which you can share), then I can look into it.

[bitspyer]

How does DDVT get the Border-Info for Movie and RPU?
Does the rpu Binary has Border-Info in its Meta-Data?

Or get DDVT this Information with DetectBorder.exe ?

The Reason for my Question is, I have a Source, with mixed IMax and normal Widescreen Content, which means, the Borders has diffrent sizes....

Will DDVT change the crop Bars or leave DDVT the RPU Crop untouched?

Thnx 4 answers....

18250

The shown Bordes are for Widescreen Content, 68px Top / Bottom will be the correct Bordes for the IMAX Content.

[GodzilaAvenger]

This was discussed a while ago in this thread, so take a look a few pages back. The short answer is that no, DDVT on its own does not automatically change the L5 metadata (frame borders) per frame, and it usually only detects the largest aspect ratio (smallest borders). You can put a custom.json file next to the RPU.bin file to tell DDVT injector what borders to use for which frames.

[von Suppé]

Does the rpu Binary has Border-Info in its Meta-Data?

Yes. Like GodzilaAvenger said, it's in RPU's so-called L5 metadata.

In case of varying borders, I don't know what to think of detecting them. I may be dead wrong (please anyone correct me if so), but I imagine DDVT parses an amount of frames at the beginning. Both for video and RPU data, my guess. BTW even if all L5 would match the varying borders, it isn't always so that DDVT would show the same values. When I drop a certain movie, of which I know RPU is 100% correct, the border values for video differs from those of RPU. I guess this is because video shows almost all black frames at the beginning.

Main question is if L5 values match the actual border sizes of the video, at any point. In other words, do you trust the RPU. Should you have extracted it from the same source where BL comes from, chances are it's ok. If you like, you can check for yourself by comparing L5 values to the actually displayed borders of several cherry-picked frames. FYI if you drop RPU on DDVT_FRAMEINFO, you can check values for any frame number you put in.
Once you know RPU is ok you obviously want to [LEAVE UNTOUCHED] whilst injecting. Actually, for such videos I'd never change L5, because ALL frames would end up with the same value.

Should RPU values not match video, there's several things you can do. For a proper job, you have to edit the RPU the way GodzilaAvenger mentioned.
If that be too much, you can try setting L5 to the value of the smallest border. Or, set all to zero (crop). It depends a bit on how your player behaves on black when it's part of the active area. Chances are that you'll experience some "grey" issues.

[LazyNcoder]

Hello guys,
Today I bumped into a hybrid DV/HDR+ video which had the combination of DV and HDR+ metadata from two different sources.
The author stated that he/she has edited the L6 metadata of the DV to match the HDR+

it's like:
blah.blah.DV.mkv
blah.blah.HDR.mkv
and
blah.blah.hybrid.DV.HDR.mkv

I extracted the DV and HDR+ metadata from the original different sources and used both of them in x265.exe to re-encode it with given MAXCLL/MAXFALL options. But the DV metadata from the final .hevc file was untouched, same as source(obviously).

Now I want to ask, if the L6 editing part is required and how to do that. How can I get the correct MAXCLL/MAXFALL and add it to the DV to use it when I want to include both DV and HDR in my encode.
OR can I just extract the metadata of the different DV and HDR+ and use them without editing in my encode, without editing the L6 metadata.

Thanks

[GodzilaAvenger]

As quietvoid mentioned previously (Post #434) those L6 values don't seem to be used anywhere, and I've seen them be set to 0 in a lot of my BluRays so I don't have any reason to think otherwise. I'd say don't waste your time on L6 because it will likely won't matter in the end.

[bitspyer]

Thnx for the answers.
In the meantime I got myself the answer too. I used dovi_tool to get the JSON from RPU and saw the diffrent borders for the IMAX Frames.

[fkid]

@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!