quietvoid / dovi_tool Goto Github PK

Hi, I'd like to "remux" profile 7 FEL mkv to profile 7 MEL mkv or to profile 8 mkv. Is it possible to achieve this?

I know this tool lets me demux BL and EL+RPU into two separate hevc files or extract RPU as a separate file. However, I am not sure what to do with those files next. I am aware the dolby mp4muxer can be used to combine BL and EL files and mux them to mp4 but I'd like to avoid this step if possible.

Basically, my goal is to produce another mkv which will have the original FEL converted to MEL or dropped completely.

Hi!

With the latest version (1.4.1), I get this error (with 'The Power of the Dog' 4K DV from Netflix, if you need I can share the RPU):

Parsing RPU file...
Error parsing frame 183402: CM v2.9: dm_alignment_zero_bit != 0
Error: Number of valid RPUs different from total: expected 185341 got 183402

If I extract the RPU intact, I can use the info command without getting an error.
But if I convert it with mode 3 (this process is done without errors), the info command gives me that error. And if I try to use the inject-rpu command with this RPU converted with mode 3, the same error also occurs.

It makes me think that the problem must be after the film is finished, specifically in the dubbing credits. Maybe during that part DV metadata is incomplete or the metadata there is fake, or something like that, I don't know.

I think about it for this reason:
When converting the RPU with mode 3, the process indicates that the RPU contains 185341 frames:

EditConfig {
    mode: 3,
    convert_to_cmv4: false,
    remove_mapping: false,
    active_area: None,
    remove: None,
    duplicate: None,
    min_pq: None,
    max_pq: None,
    level6: None,
    level11: None,
}
Parsing RPU file...
Converting with mode 3...
Final metadata length: 185341
Writing RPU file...

But if I try to see the information of that last frame with the info command, the process indicates that there are only 183402 valid frames:

Parsing RPU file...
Error parsing frame 183402: CM v2.9: dm_alignment_zero_bit != 0
Error: Number of valid RPUs different from total: expected 185341 got 183402

I have tried to see the information of those frames with the info command (from RPU intact, as the info command fails with RPU converted with mode 3), and I have observed that up to frame 183401 (included) contains the cmv29_metadata block, but from frame 183402 (included) to the end the cmv29_metadata block does not exist.

So I thought to remove those last frames that don't contain the cmv29_metadata block, I have tried to edit the RPU with this json:

{
	"mode": 3,
	"remove": [
		"183402-185340"
	]
}

And it seems that now everything is correct. In this RPU converted with mode 3 I can now use the info command without errors.

Although I have already managed to solve it this way, I open this Issue to see if a simpler way to solve these types of cases could be implemented.
For example, I have thought that the inject-rpu command might be able to check if all the frames contained in the HEVC file are valid in the RPU file, instead of simply giving an error. This way you avoid editing the RPU (just in case none of the HEVC frames is an invalid frame in the RPU).

Thanks and regards!

The issue may be that it can't be done and I just misunderstood, but:

1. I used the most recent binary of the hdr10 tool to export the hdr10+
2. I used the most recent dovi_tool binary to convert the json into an RPU
3. I injected the RPU back into the original file
4. Looked at the media info for the file and I see HDR10+ listed, not DV

Commands run:
ffmpeg -i hdr10plus_movie.mkv -map 0:v:0 -c copy -vbsf hevc_mp4toannexb -f hevc - | hdr10plus_tool extract -o hdr10plus_metadata.json -

ffmpeg -i hdr10plus_movie.mkv -c:v copy -vbsf hevc_mp4toannexb -f hevc hdr10plus_movie.hvec

dovi_tool generate -j assets/generator_example.json --hdr10plus-json hdr10plus_metadata.json -o RPU_from_hdr10plus.bin

dovi_tool inject-rpu -i hdr10plus_movie.hvec --rpu-in RPU_from_hdr10plus.bin -o injected_output.hevc

So, am I doing something wrong or just wrong about the expected result?

Thanks for your time and a million thanks for your tools!

Hey man. Tool has been working great so far. Was trying to do Transformers DV today and getting this new error which I've not seen before:

thread 'main' panicked at 'index out of bounds: the len is 1 but the index is 1', src/dovi/rpu/vdr_rpu_data.rs:154:37
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
av_interleaved_write_frame(): Broken pipe
Error writing trailer of pipe:: Broken pipe

What do you think might be the problem?

The current parsing is very inefficient, it always copies the data around.
There is ongoing work in a branch, to use nom and avoid copying data as much as possible.

The error occurs here:

Backtrace:

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `39322`,
 right: `65535`', src\dovi\rpu\vdr_dm_data.rs:182:13
stack backtrace:
   0: std::panicking::begin_panic_handler
             at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\/library\std\src\panicking.rs:515
   1: core::panicking::panic_fmt
             at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\/library\core\src\panicking.rs:92
   2: core::fmt::Arguments::new_v1
             at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\/library\core\src\fmt\mod.rs:338
   3: core::panicking::assert_failed_inner
             at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\/library\core\src\panicking.rs:160
   4: core::panicking::assert_failed<u16,u16>
             at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\library\core\src\panicking.rs:117
   5: dovi_tool::dovi::rpu::vdr_dm_data::VdrDmData::validate
             at C:\Users\phoenix\Projects\dovi_tool\src\dovi\rpu\vdr_dm_data.rs:182
   6: dovi_tool::dovi::rpu::rpu_data::DoviRpu::validate
             at C:\Users\phoenix\Projects\dovi_tool\src\dovi\rpu\rpu_data.rs:242
   7: dovi_tool::dovi::io::DoviReader::write_nals
             at C:\Users\phoenix\Projects\dovi_tool\src\dovi\io.rs:262
   8: dovi_tool::dovi::io::DoviReader::read_write_from_io
             at C:\Users\phoenix\Projects\dovi_tool\src\dovi\io.rs:177
   9: dovi_tool::dovi::rpu_extractor::RpuExtractor::extract_rpu_from_el
             at C:\Users\phoenix\Projects\dovi_tool\src\dovi\rpu_extractor.rs:64
  10: dovi_tool::dovi::rpu_extractor::RpuExtractor::process_input
             at C:\Users\phoenix\Projects\dovi_tool\src\dovi\rpu_extractor.rs:56
  11: dovi_tool::dovi::rpu_extractor::RpuExtractor::extract_rpu
             at C:\Users\phoenix\Projects\dovi_tool\src\dovi\rpu_extractor.rs:45
  12: dovi_tool::main
             at C:\Users\phoenix\Projects\dovi_tool\src\main.rs:72
  13: core::ops::function::FnOnce::call_once<fn(),tuple<>>
             at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\library\core\src\ops\function.rs:227

This is using dovi_tool compiled at e689da6

The error only occurred at the very end of the extraction process (the progress bar stated 100%)

When I inject an RPU into a HEVC file, if I extract the RPU from the resulting injected HEVC, I get an identical RPU file (same MD5) as the original RPU.

Recently I had to inject an RPU into a HEVC file that was 1 frame longer than the RPU, so I had to use the editor to edit the RPU and duplicate the last frame of the RPU to obtain the same length as the video.

And, as I mentioned above, if I extract the RPU from this injected video I get the same MD5 as the modified RPU that I edited (with 1 more frame). So everything is perfect.

But the new version 0.4.0 has just been published, which automates this process in these types of situations. That is, different lengths of RPU and video.

So I have decided to test version 0.4.0 with that same video that I mentioned above that I used recently (video with 1 frame more than the RPU), so dovi_tool v0.4.0 is supposed to get the last frame of the RPU and simply copy it again below, that is, duplicate the last frame, in order to obtain the same length of the video.

That is, the dovi_tool v0.4.0 should now automatically do exactly the same process that I did manually days ago. And the RPU of the injected video should be identical to the RPU edited by me with the last duplicated frame.

But it's not like that. The resulting RPU edited automatically by the dovi_tool v0.4.0 is different from the RPU edited manually by me. Shouldn't they both be identical?

I have thought that the RPU would be completely identical and only the new last frame would change... But no.

I have reviewed several random frames with the info argument, and all of them have changed compared to their original RPU.
Specifically, I have seen that the vast majority of 'addr' data is altered during this process.

Why is all this data from all frames altered instead of all frames remaining completely intact and just duplicating the last frame?

Thanks and regards!

Hi again,

I've attempted to extract Dovi data from an STDL hevc file this time, unlike with my last attempt of extracting directly from the EL which I wasn't aware wasn't supported - apologies.

However, unfortunately I've received the exact same error as before :/

Workflow :
Demux source m2ts to BL.hevc and EL.hevc using ffmpeg -i "K:\00234.m2ts" -map 0:0 -vcodec copy "K:\BL.hevc" -map 0:1 -vcodec copy "K:\EL.hevc"

Mux to STDL hevc using Yusescopes tool (v0.0.4_BETA_TEST_FEL_TO_MEL_PLUS_UHDBD_TO_81__PLUS_SKIP_HDR10plus__PLUS_EXPERIM_MUXER_17102020) default mode

Attempt extraction(& Conversion) of Dovi data using Dovi_Tool Ver 0.3.5
dovi_tool -m 1 extract-rpu "K:\BL_FEL_RPU.hevc" --rpu-out "K:\RPUMEL.bin"

Errors out with "thread 'main' panicked at 'Range 7..13 out of bounds: 8', C:\Users\runneradmin.cargo\registry\src\github.com-1ecc6299db9ec823\bitvec-0.20.2\src\slice\api.rs:2651:1"

Please let me know if my workflow is botched.
Thanks.

If anyone is interested in this, I'm missing XML file samples that contain L10 or L11 metadata.

Has the --crop parameter another variables?? When to use it??? only add --crop when the rpu metadata will be used with cropped encode??? and what about resized encode???

Hi. :) Me again. :)

Is it possible to determine which frames have different activa area offsets? from-to? it would be useful when we have "IMAX" movies, where some scenes are 16:9 and some 2.35:1...

or would it be OK, to export to JSON, edit offsets in some editor and then convert back to RPU???

Hello,

when I convert from profile 5 to 8 it works fine but when I look at the result afterwards it gives me brightness peaks 1 second after each scene change

Hi!

When with the info command you try to see the information of a frame greater than the number of frames that the RPU contains, this error occurs:

Parsing RPU file...
Error: info: invalid frame number (out of range)

Perhaps it would be useful for the user that, in addition to notifying this error, the number of available frames is also notified.
For example, something like this:

Parsing RPU file...
Error: info: invalid frame number (out of range)
Metadata length: 123456

Thanks and regards!

For example, it could be useful to create generic metadata (for example ST2086, level 6 metadata).
Perhaps min/max/avg PQ values as well..

Error:

>dist ./dovi_tool extract-rpu img_5858.hevc   
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /Users/runner/.cargo/registry/  
src/github.com-1ecc6299db9ec823/bitvec_helpers-0.1.0/src/bitvec_reader.rs:21:44

This is the hevc file I extracted out of an iPhone 12 DoVi encoded file (8.4 I believe).

The .hevc file was extracted out of the .mov container with ffmpeg -i ~/Pictures/IMG_5858.MOV -c:v copy -vbsf hevc_mp4toannexb -f hevc img_5858.hevc

Apologies in advance if this is the wrong place to post this question. If you have a preferred alternative I will happily repost there.

I have a single track dual layer profile 7 Dolby Vision file (produced by MakeMKV from a UHD Blu-Ray) which I would like to convert into a profile 5 Dolby Vision file for playback on an Apple TV 4K (which officially supports only profile 5 DV files).

1. Is this theoretically possible?
2. Can dovi_tool currently do this? (If so, how?)

Caveat: I am aware an RPU can be extracted and used to transcode into profile 5 DV with x265, I am currently more interested in the possibility of converting without transcoding.

Many thanks for your help

Can this tool be used to inject dolby vision from the bluray/remux to an x265 hdr10 encode ?

If yes, please explain a little how?

Hello,

I discovered this wonderful new tool and I wanted to give it a try and encode a Dolby Vision UHD Bluray in x265.

• First, I use MakeMKV to rip my Dolby Vision 4K Bluray so I have a mkv file which shows "Dolby Vision, Version 1.0, dvhe.07.06, BL+EL+RPU, Blu-ray compatible / SMPTE ST 2086, HDR10 compatible" in mediainfo.

• I extract the hevc file from this mkv and I use this command to create RPU.bin : dovi_tool -m 2 extract-rpu myvideo.hevc (because I want a profile 8.1)

• I open the mkv file in staxrip and I encode in x265 with these parameters : --dolby-vision-profile 8.1 --dolby-vision-rpu "path to RPU.bin"

• I mux the resulted hevc file with tsmuxerR and I have a .ts file which shows "Dolby Vision, Version 1.0, dvhe.08.06, BL+RPU, HDR10 compatible / SMPTE ST 2086, HDR10 compatible" in Mediainfo

Everything looks good, I tested my .ts file on my TV (via Plex/Shield) and it displays Dolby Vision logo. The image is really great but sometimes (mainly in black screens with just a white text or something in the middle), the screen becomes green just before the cutscene (it's really fast but we can definitely see it). Of course it's not the case if I play the source mkv (so it doesn't come from the source). I tested on different TV/devices (even with a mp4 container) and the problem remains.

Is something wrong in my encoding chain or is there a bug somewhere ? I already tested to encode with profile 5 (I lose HDR compatibility in this case so I don't want that), I also tried to extract rpu.bin untouched (mode 0) and I encoded with profile 8.1 : In this case there is no green frames but the colors are also not so good so I think it's not the good thing to do...

In the inject-rpu documentation, the example has --rpu-in argument, but it doesn't work and you need to use --rpu_in.

I think the ideal would be to change the argument to --rpu-in, instead of updating the documentation with --rpu_in, since all other arguments are also - and not _ (--rpu-out, extract-rpu).

Thanks and regards!

Are there any "crop" or "black bars signaling" tags in DoVi metadata??? Because when I encode video (using BIN directly with x265), in HDR10/HDR10+ file plays OK, but with DoVi (Plex on Android TV, Kodi on Adroid TV and also internal media player), file is playing perfectly, trigerring Dolby Vision, but, it runs like cropped again... na dimensions change, but as DoVi meta tells to TV to crop part of played picture. When I encode same movie with same BIN file uncropped, everything is 100% OK.

If so... is there possibility to remove the by me so called "crop flag"?

Following up from the previous issue thread, here's the overall goal. I'm trying to upload a bunch of content I have to Wikimedia Commons but that requires royalty-free encoded videos. I can do the HEVC>VP9 while maintaining BT.2020 (pending tone-curve conversion if needed), but the frame-level dynamic metadata gets lost in the process.

The thing is that iPhone12, while being DoVi encoded video, is HLG and so it seems like the metadata conversion from DoVi RPU to HDR10+ JSON should be possible 'easily' enough...

I'm not sure if it's in-scope for dovi_tool to do this, but since you also are the creator of the amazing hdr10plus_parser, I thought I'd go to you first to ask how to connect these two standards.

Looking through the extracted frame info from a DoVi RPU and a sample of the HDR10+ json from Tears of Steel, I don't think it's just a matter of reformatting the json... or is it?

Thanks for you help!

After successfully parsing RPU (8.1 Profile) from the source, I try to inject it then to my encode, but get an error "Thread main panicked at Number of frames of input and RPU file are different!, src/dovi/rpu_injector.rs:140:17".
The problem is that both source and encode has same number of frames, I checked it. But the error still exists.
I tried Dovi 0.3.2 and 0.3.1

Hello, I have a question now. Can this tool convert Dobly MXF into H265 files? If so, what should I do?

When I'm using the -j p5_to_p81.json parameter, the resulting RPU file is same as the source.
I'm upload the sample: https://drive.google.com/file/d/1IiHhj0QOwo3kXCCd1P9VnEl7I43AjY5Y/view?usp=sharing
Thanks for your work!

If the extracted RPU file size is smaller than 25.5M, all the complete information can be saved normally.
However, the RPU files saved by some film will be relatively large, exceeding 25.5M, so the final RPU file obtained is only 25.5M.

I used <Raiders of the Lost Ark 1981> and <Indiana Jones and the Temple of Doom 1984> to test , and I can only save 25.5M RPU file at most, which probably stores more than 70,000 frames of information. Some other movies are no problem, because the final RPU file saved does not reach 25.5M.
The test environment is Windows 10, using CMD to run dovi_tool -m 2 extract-rpu video.hevc to extract the RPU information.
Is there a problem with my environment?

I've ran into an issue trying to extract(& convert to MEL) the dovi data from both the above movies.
I use the following command to pipe from ffmpeg to dovi_tool version 0.3.5. Both are FEL movies.

ffmpeg -i "K:\00234.m2ts" -map 0:1 -c:v copy -an -vbsf hevc_mp4toannexb -f hevc - | dovi_tool -m 1 extract-rpu - --rpu-out "K:\RPUMEL.bin"

I get the following error :
thread 'main' panicked at 'Range 7..13 out of bounds: 8', C:\Users\runneradmin.cargo\registry\src\github.com-1ecc6299db9ec823\bitvec-0.20.2\src\slice\api.rs:2651:1
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

Exact sources used :
The.Fate.of.the.Furious.2017.2160p.BluRay.HEVC.DTS-X.7.1-HDRINVASION
The.Hitmans.Bodyguard.2017.2160p.BluRay.HEVC.TrueHD.7.1.Atmos-TERMiNAL

Thanks in advance

Hi!

Currently the RPU editor supports editing of the min_pq and max_pq values.
Would it be possible to implement new values to edit in the RPU Editor?

I mean these specifically:
max_display_mastering_luminance
min_display_mastering_luminance
max_content_light_level
max_frame_average_light_level

This is because sometimes I have had a HDR video (from UHD) and a DV video (from WEB).
The UHD video contains those 4 values, and the RPU extracted from the WEB video contains the max_display_mastering_luminance and min_display_mastering_luminance values with exactly the same values as the UHD video, but the max_content_light_level and max_frame_average_light_level values are set to 0... And, as I mentioned before, in the UHD those 2 values were set with a value that is not 0.

So, I have thought that if it is set to 0 it is equivalent to not being set, correct?

And in that case, I suppose it would be appropriate and advisable to replace the 0 RPU values with the HDR video values.
So you can take advantage of those values that are available thanks to the other video.

This is correct? Or is it not appropriate?
I guess it is correct since the other 2 values match exactly in both video sources.

Thanks and regards!

This issue may be not related to dovi_tool itself. But I wonder how to correctly crop, resize and transcode the DoVi video.
When I mux cropped&resized&transcoded BL+RPU.hevc (profile 8.1) to the container (MKV or MP4). The height of the video is automatically changed to a number that mod 8.
For example, The original height is 1038. After demuxing, alghough the "HDR format" is expected to be Dolby vision and HDR10 compatible, the "Height" changed to 1040 and size of the whole file also grows by about 600MB. （By MakeMKV）
I currently only knows to use MakeMKV, tsMuxer or mp4muxer to add the Dolby Vision information to the HEVC codestream.

Sorry, this isn't an "issue" but more me being new to run it. I downloaded everything and when I click to run the exe it just gives me the little blue circle and then doesn't do anything. I tried to run some of the commands via the command line, but it tells me that dovi_tool does not exist. Am I missing some installer or something?

I have a question about crop.

The option -c / --crop what it does is find Level5 and, if it is present, readjust the active area offsets to 0, correct?

I have noticed that if you crop an RPU without Level5, the edit does nothing, it remains intact.
However, if the RPU contains Level5, the edit does work and sets the active area offsets to 0.

My Doubt is:
With cropped videos, what is more recommended?
Is it better that the RPU has Level5 with active area offsets at 0 or that Level5 does not exist directly?
Or are they both exactly the same and is it indifferent?

I ask since, for example, cropped WEB-DL RPUs usually come without Level5. And when editing it and injecting it into another HEVC (UHD for example) Level5 will still not exist even if the "crop" option is used.

However, if the RPU comes from UHD for example, it does contain Level5 and when editing it and using the "crop" option, the active area offsets will be set to 0 instead of removing Level5.

So, is one of the two options more recommended?
Or is the result identical in both cases?

And, in the second case, wouldn't the ideal be that cropping would always eliminate Level5 in all cases?
So the RPU would be more optimized, with a smaller size.

Thanks and regards!

Hello,

when using 1.3.0 stable, converting a DoVi 4.0 XML to a RPU bin file using --generate , the thread hans at "generate metadata" forever even when using a XML file with only one single shot. Using a 13" M1 MacBook Pro with Montery 12.0.1.

A DoVi 2.9 XML works fine though.

To verify: compare the generated RPU without a mode against the RPU using --mode 0.
The result should always be identical.

This seems to break MakeMKV.

hi,

is it possible to:

1. convert DV profile 5 to DV profile 8.1
2. convert DV profile 5 to HDR10+ json file to be able to encode like HDR10+

Ripped Indiana Jones Collection 4K to HDD (tested with LOST ARK and TEMPLE OF DOOM) with MakeMKV backup function, then demuxed m2ts into BL + EL with FFMPEG. Encoded BL with the help of RipBot264 into a 22 GB HDR10 BL. Then tried to do a MUX_AND_CONVERT_TO_MEL with the encoeded BL and the original EL. Does not work - BL_ANALYIS increases with rapid speed until 100% is reached. That time EL_ANALYSIS shows 4,2% and stops the moment BL reaches 100%. Been waiting now for 2 more hours without any further progress. Tested the original BL and EL, which worked without any problems. Any ideas?

Hi,
I just found this tool a few days ago and it looks very promising.
I try to understand the workflow but I'm stuck at the point on how to merge the RPU back into an MKV file.
Could you give me a hint?

Sorry if this doesn't belong here!

Commands

• info

  Prints the parsed RPU data as JSON for a specific frame.
  Frame indices start at 0.

  • Example to get metadata for frame 123: dovi_tool info -i RPU.bin -f 124

This should look like this:
Example to get metadata for frame 124: dovi_tool info -i RPU.bin -f 123

Thanks and regards!

Currently, the shots are overwritten by those created with only L1 metadata.
It should technically be replacing the metadata blocks (probably excluding L1?) by those in the JSON.

Then comes the question, how do we define a default list of blocks for all shots?

i can't extract metadata from transofrmers uhd bd (2007)

thread 'main' panicked at 'index out of bounds: the len is 1 but the index is 1', src\dovi\rpu\vdr_rpu_data.rs:154:37 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

The process is pretty slow and there's no feedback.
Noticeable with full length videos (150k frames and more).

Sample: BT2111.U4K_DVp5.DolbyVision.zip

HDR Format                         : Dolby Vision, Version 1.0, dvhe.05.06, BL+RPU

Wrong Color:

Using dolby vision extension:

Is there a tool can do this convert?

I have video, which has active area offset 276 top, 277 bottom, so i want to edit RPU to 0 top, 1 bottom, and encode with 276 top and 276 bottom crop... that way is should be pixel perfect. :)

the question is if it's possible to edit all frames by default, when no specifiyng edits... because right now i need to find number of RPU's first. :( it would be much simpler, if edits would be done to all frames by default. :)

Delete

i have dovi metadata without active area offsets (no active area section at all) and I want to add ones... is this possible with editor? activearea.json (edited to my needs) does not add them..

Hi!

With the latest version (1.3.1), I get this error when using mode 3 (converts profile 5 to 8):
thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', dolby_vision\src\rpu\rpu_data_mapping.rs:236:46

This does not happen with the previous version.

Thanks and regards!

Sorry in the first place for asking again for DV and encoding. I invested time learning about DV and encoding as I have not the space for all my UHDs non-reencoded. But there are some questions in my mind.

My current workflow:

1. Export UHD with MakeMKV
2. Encode hevc with ffmpeg from exported mkv
3. Export RPU as profile 7 with dovi_tool from untouched hevc
4. Inject RPU into encoded hevc
5. Mux everything together into a mkv again with MKVToolNix

When I am playing the mkv with my Shield everything works fine. But everybody is talking about encoded profile 5 or 8.1, do I discard anything from the metadata or I am the only one who wants encoded profile 7 DV?
Second question, can I crop the BL and inject the untouched RPU later? On my Shield it works fine again, but if I am muxing it into a ts file with tsMuxer and watch it on my LG webos directly the file is cropped twice and looks like the video has suddenly a resolution of 3840x804.

Thank you for your tool and your time!

Hey there,

Could you add an output parameter for the Extract RPU like the tool has already in the Inject RPU Use Case?
As example:
dovi_tool.exe -m 3 extract-rpu dv.hevc -o Test.bin

Hi! Is there any way to convert from Dolby Vision Profile 8 to Profile 7 MEL currently? I didn't find a way to do this.