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

[quietvoid]

Originally Posted by Lucius Snow

I wonder how a profile 7 can be generated if the color grading softwares themselves deliver 8.X profiles. There might exist a 8.X to 7 converter somewhere, no? Maybe in DEE which costs $500 per year?

The encoded HEVC files you get from software like Resolve is not meant to be used as a deliverable.
Normally you would export a Dolby Vision master with XML metadata.

DEE seems to have a script allowing to encode both bitstreams from the master: https://professionalsupport.dolby.co...language=en_US

Though obviously it's better if you contact Dolby about it, you would have to for DEE anyways.
This is another guide from their documentation: https://professionalsupport.dolby.co...language=en_US

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

Originally Posted by Lucius Snow

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]

Originally Posted by 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?

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]

Originally Posted by 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?

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]

Originally Posted by rco133

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]

Originally Posted by quietvoid

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]

Originally Posted by rco133

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]

Originally Posted by quietvoid

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]

Originally Posted by rco133

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]

Originally Posted by quietvoid

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]

Originally Posted by 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-]

Originally Posted by 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

Really?

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

Originally Posted by -QfG-

Maybe you have () in your filenames?

Yes, indeed that was the culprit. Thank you.