Issue with --dolby-vision-rpu copy behavior in QSVEncC 7.73

[quamt]

Description:
I’ve encountered issues using the --dolby-vision-rpu copy feature in QSVEncC version 7.73 when attempting to copy Dolby Vision RPU metadata. The behaviour does not seem to align with the documentation.

Expected Behavior:
When using --dolby-vision-rpu copy on a Dolby Vision Profile 7 input file:

The output should automatically convert to Dolby Vision Profile 8, as described in version 7.71 using libdovi.
MediaInfo should reflect Dolby Vision Profile 8 information without additional options.

Observed Behavior:
Without specifying --dolby-vision-profile:

The output only includes HDR10 info, not Dolby Vision.
MediaInfo shows:

Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Format profile                           : Main 10@L6@High
HDR format                               : SMPTE ST 2086, HDR10 compatible

Adding --dolby-vision-profile 8.1:

Dolby Vision Profile 8.1 metadata is correctly included.

MediaInfo reflects:

Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Format profile                           : Main 10@L6@High
HDR format                               : Dolby Vision, Version 1.0, Profile 8.1, dvhe.08.06, BL+RPU, no metadata compression, HDR10 compatible / SMPTE ST 2086, Version HDR10, HDR10 compatible

Specifying an invalid profile (e.g., 7):

The output shows:

Dynamic HDR10  copy
dovi profile   (null)
dovi rpu       copy

MediaInfo reflects:

Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Format profile                           : Main 10@L6@High
HDR format                               : Dolby Vision, Version 1.0, Profile 8.1, dvhe.08.06, BL+RPU, no metadata compression, HDR10 compatible / SMPTE ST 2086, Version HDR10, HDR10 compatible

CQP Mode with --dolby-vision-profile 8.1:

Errors with:

Please use Bitrate Mode - CBR/Bitrate Mode - VBR/Bitrate Mode - AVBR/VCM (Video Conference Mode)/Quality VBR bitrate mode for dolby vision output.

However, specifying Profile 7 works without error (even though Profile 7 shouldn’t be valid here).

System Details:
QSVEnc Version: QSVEncC (x64) 7.73 (r3500) by rigaya, Nov 12 2024
OS: Windows 11 x64 (22631) [UTF-8]
CPU Info: 13th Gen Intel Core i5-13600 [4.89GHz] (6P+8E,14C/20T)
GPU Info: Intel Arc A770 Graphics (512EU) 300-2400MHz (32.0.101.6130)
Media SDK: QuickSyncVideo (hardware encoder) FF, 1st GPU(d), API v2.13

Steps to Reproduce:
Use a Dolby Vision Profile 7 input file.

Run QSVEnc with the following commands:

--avhw
--codec hevc
--profile main10
--cqp 34:34:36
--vbv-bufsize 12000
--i-adapt
--b-adapt
--scenario-info archive
--open-gop
--ref 8
--bframes 16
--output-depth 10
--pic-struct
--hevc-gpb
--vpp-deband
--audio-copy
--chapter-copy
--colorrange auto
--colormatrix auto
--colorprim auto
--transfer auto
--chromaloc auto
--max-cll copy
--master-display copy
--audio-copy
--sub-copy
--atc-sei auto
--dhdr10-info copy
--dolby-vision-rpu copy

Check the output file with MediaInfo.
Add --dolby-vision-profile 8.1 and observe changes.

Test with invalid profiles (e.g., --dolby-vision-profile 7) and note the behaviour.

Attempt CQP mode with Profile 8.1 and observe the error.

Request for Guidance:
Is the observed behavior a bug or an intentional change in version 7.73?

If intentional, what is the correct way to copy Dolby Vision RPU while preserving Dolby Vision Profile 8 metadata?

Can support for CQP mode with Dolby Vision Profile 8.1 be clarified or implemented?

Thank you so much for your help.

[rigaya]

Actually, the behaviour you have got without --dolby-vision-profile is as expected.

It is strongly recommended to use both --dolby-vision-rpu and --dolby-vision-profile with proper value for full dolby vision handling.

The --dolby-vision-rpu option and --dolby-vision-profile is a seperate option and the effect and target (where the data is inserted) of these is different, and using only one does not complete the dolby vision handling.

• --dolby-vision-profile

  Adds dolby vision profile information to the container. This seems to trigger dolby vision profile information to show up in mediainfo.

• --dolby-vision-rpu

  Inserts per frame dolby vision rpu metadata to the bitstream. The rpu also includes dolby vision profile information in itself, but is different type of data from the one added by --dolby-vision-profile. It might not trigger mediainfo to show dolby vision profile information.

  The automatic conversion to dolby vision profile 7 to 8 mentioned in QSVEnc 7.71 release note is only about --dolby-vision-rpu, thus it occurs only to this profile information in rpu metadata.

Overall, both --dolby-vision-rpu and --dolby-vision-profile are recommended to get full dolby vision output.

---

However, there seems to be some bugs and place for improvement as you have reported, I'll look forward to fix or improve them.

However, specifying Profile 7 works without error (even though Profile 7 shouldn’t be valid here).

Thank you for reporting this, --dolby-vision-profile 7 should not work, seems to be wrong error handling. I'll have a fix there.

Can support for CQP mode with Dolby Vision Profile 8.1 be clarified or implemented?

I think I'll remove limitation for this.

[quamt]

@rigaya
Thank you for the clarification and for explaining the functionality of --dolby-vision-rpu and --dolby-vision-profile.

Thank you also for looking into it for improvement, including the incorrect handling of --dolby-vision-profile 7 and the CQP mode limitation. I appreciate your dedication to refining the tool.

QSVEncC options list info:
Would it be possible to include a note in the QSVEncC options list or documentation indicating that it’s strongly recommended to use both --dolby-vision-rpu and --dolby-vision-profile together for complete Dolby Vision handling?
This would help avoid confusion for users trying to achieve proper Dolby Vision output without knowing how these options interact.

Thank you once again for your efforts in considering improvements to QSVEncC! Your commitment to enhancing the tool is highly valued by the community.😊

[quamt]

@rigaya

Additional Question:
If I crop the original video and use --dolby-vision-rpu copy, is there anything specific I need to know?
Does QSVEnc handle cropping and ensure the RPU metadata remains appropriately aligned with the cropped video, or do I need to make adjustments to maintain Dolby Vision integrity manually?

[rigaya]

Would it be possible to include a note in the QSVEncC options list or documentation indicating that it’s strongly recommended to use both --dolby-vision-rpu and --dolby-vision-profile together for complete Dolby Vision handling?

I think we already have it on the docs on each paramters that the other option is recommended to be used.

Does QSVEnc handle cropping and ensure the RPU metadata remains appropriately aligned with the cropped video, or do I need to make adjustments to maintain Dolby Vision integrity manually?

--dolby-vision-rpu copy is basically no more than copying other than the profile conversion. Therefore, adjustments for cropping will be needed manually. (extract → edit → import by --dolby-vision-rpu)

[quamt]

@rigaya
Thank you for the information provided.

[rigaya]

I'm quite unsure what adjustments are needed when cropping is done.

If what is needed is --crop in dovi_tool, it might be possible to add option to pass "active area offset" value to libdovi used internally in QSVEnc. (libdovi provides C API dovi_rpu_set_active_area_offsets)

[quamt]

I'm quite unsure what adjustments are needed when cropping is done.

If what is needed is --crop in dovi_tool, it might be possible to add option to pass "active area offset" value to libdovi used internally in QSVEnc. (libdovi provides C API dovi_rpu_set_active_area_offsets)

I found this on the dovi tool github
https://github.com/quietvoid/dovi_tool/issues/281

And here on doom 9
https://forum.doom9.org/showpost.php?p=1951422&postcount=33

[rigaya]

QSVEnc 7.74 will remove limitation of rate control mode, and add option to set active area offsets to 0 for cropping.

[quamt]

QSVEnc 7.74 will remove limitation of rate control mode, and add option to set active area offsets to 0 for cropping.

Thank you very much 😊
I will report back.

[quamt]

@rigaya
I tested it with latest version 7.75 and works fine, the issue are gone and CQP works.

I want to ask:
What are the limitations of --dolby-vision-profile ?
For example when the input is profile 5 it wont convert to any other profile?
Test file https://kodi.wiki/view/Samples Dolby Vision Mystery Box (Profile 5)

Mediainfo original input file:
HDR format : Dolby Vision, Version 1.0, Profile 5, dvhe.05.09, BL+RPU, no metadata compression

cmd shows:

Dynamic HDR10  copy
dovi profile   8.1
dovi rpu       copy

Mediinfo output file:
HDR format : Dolby Vision, Version 1.0, Profile 5, dvhe.05.09, BL+RPU, no metadata compression

Why I'm asking is because on the dovi page its mentioned that it converts profile 5 to 8.1.
I wanted to clarify.

[quamt]

@rigaya

I noticed one more thing.

When the following settings are used:

--dolby-vision-rpu copy
--dolby-vision-profile 8.1
--dolby-vision-rpu-prm crop=true

The file gets processed even if there is no RPU file in the source. As a result, the output contains Dolby Vision metadata.

Would it be possible to implement a check to handle this scenario?

[rigaya]

In any cases I recommend to use --dolby-vision-profile copy, because QSVEnc really does not do any conversion in most cases (except when input is dolby vision profile 7).

dovi page its mentioned that it converts profile 5 to 8.1.

Actually not. QSVEnc have not implemented profile conversion.

Please think that only simple stuff is implemented. As written previously, --dolby-vision-profile only adds specified dolby vision profile information to the container. This does not do any conversion.

The confusion is that the rpu side also has dolby vision profile information, and the mismatch between mediainfo output and the log is caused by the mismatch between container side information and rpu information.

In any case, it is considered as user's responsibility to use --dolby-vision-profile and --dolby-vision-rpu together, and to specify them consistently so it matches the other (there will be no check).

As I think this is difficult, the most preferred and expected usage is to simply use --dolby-vision-profile copy along with --dolby-vision-rpu copy. I don't really recommend using --dolby-vision-profile with values other than "copy" anymore, it is old values when I initially didn't know how to get the dolby vision profile values from the input file and had to set them manually.

Would it be possible to implement a check to handle this scenario?

No, --dolby-vision-profile is an option to add dolby vision profile information to the container separate from --dolby-vision-rpu. Therefore, it should add dolby vision profile information when set with a specified value. It needs to be consistent with other options like --colormatrix, it will overwrite the value of the input file, and it will set the value even if the input file does not have --colormatrix value.

As I also think this might not be expected, what I recommend here is also --dolby-vision-profile copy here. The output will not have dolby vision information when the input does not have it.

[quamt]

In any cases I recommend to use --dolby-vision-profile copy, because QSVEnc really does not do any conversion in most cases (except when input is dolby vision profile 7).

dovi page its mentioned that it converts profile 5 to 8.1.

Actually not. QSVEnc have not implemented profile conversion.

Please think that only simple stuff is implemented. As written previously, --dolby-vision-profile only adds specified dolby vision profile information to the container. This does not do any conversion.

The confusion is that the rpu side also has dolby vision profile information, and the mismatch between mediainfo output and the log is caused by the mismatch between container side information and rpu information.

In any case, it is considered as user's responsibility to use --dolby-vision-profile and --dolby-vision-rpu together, and to specify them consistently so it matches the other (there will be no check).

As I think this is difficult, the most preferred and expected usage is to simply use --dolby-vision-profile copy along with --dolby-vision-rpu copy. I don't really recommend using --dolby-vision-profile with values other than "copy" anymore, it is old values when I initially didn't know how to get the dolby vision profile values from the input file and had to set them manually.

Would it be possible to implement a check to handle this scenario?

No, --dolby-vision-profile is an option to add dolby vision profile information to the container separate from --dolby-vision-rpu. Therefore, it should add dolby vision profile information when set with a specified value. It needs to be consistent with other options like --colormatrix, it will overwrite the value of the input file, and it will set the value even if the input file does not have --colormatrix value.

As I also think this might not be expected, what I recommend here is also --dolby-vision-profile copy here. The output will not have dolby vision information when the input does not have it.

Thank you very much for the information.
I will close this issue as all has been solved and answered.