rigaya
Issue: Dolby Vision Profile Handling in NVEnc Encoding
I've observed some inconsistencies in how Dolby Vision (DV) profiles are handled in NVEnc:
When setting the DV profile to 8.1, the DV metadata is copied without conversion and retains its original profile (e.g., 7.6). It’s unclear if an internal conversion is supposed to occur, but the profile parameter suggests that it should. When the output extension is set to .hevc and then placed into a container, the DV profile remains as 7.6, matching the original input. However, when the output is directly set to a container format like .mkv, the profile appears as 8.1 in the container, but not in the actual encoded file. This suggests that the profile 8.1 is only applied at the container level, not within the encoded video stream itself. If the container format is changed, the profile metadata (e.g., 8.1) is lost. I’m not sure if this behavior has always been present or if it's a recent change, but it may lead to issues with profile consistency when changing containers.
For my understanding, Dolby Vision profiles are container side information under dvcC. Therefore, I think --dolby-vision-profile setting only makes sense when writing to a container, and it is expected that raw HEVC files does not have Dolby Vision (DV) profiles.
For example, I've tested with input file below.
Dolby Vision, Version 1.0, Profile 7.6, dvhe.07.06, BL+EL+RPU, no metadata compression, Blu-ray compatible / SMPTE ST 2086, Version HDR10, HDR10 compatible
When writing to mp4 (or mkv), --dolby-vision-profile 8.1 is written to the container by the muxer.
NVEncC64.exe -i input.mkv -o test.mp4 -c hevc --output-depth 10 --dolby-vision-profile 8.1 --dolby-vision-rpu copy --colormatrix auto --colorprim auto --transfer auto --colorrange auto --master-display copy --max-cll copy
You can see raw HEVC files does not have dovi profile (this is expected).
NVEncC64.exe -i input.mkv -o test.hevc -c hevc --output-depth 10 --dolby-vision-profile 8.1 --dolby-vision-rpu copy --colormatrix auto --colorprim auto --transfer auto --colorrange auto --master-display copy --max-cll copy
Now when muxing this to mp4, I've got profile 8.1. mp4box.exe -add F:\temp\test.hevc -new F:\temp\test_mp4box.mp4
When the output extension is set to .hevc and then placed into a container, the DV profile remains as 7.6
This is actually weird. Would you please let me know the procedure you've followed?
I don't know how muxers obtains this dovi profile, but it should be based on following requirements.
| DOVI Profile | colormatrix | colorprim | transfer | colorrange | EL |
|---|---|---|---|---|---|
| 8.1 | bt2020nc | bt2020 | smpte2084 | tv | none |
| 8.2 | bt709 | bt709 | bt709 | tv | none |
| 8.4 | bt2020nc | bt2020 | arib-std-b67 | tv | none |
It is expected to not get dovi profile 7, as profile 7 requires to contain EL(Enhanced Layer), and EL is dropped after encoding by NVEncC. (On the otherhand, profile 8 should not contain EL).
When copying the DV using the --dolby-vision-rpu copy mode, the raw HEVC file contains a Profile 7.6, even though it’s not visible when viewed with MediaInfo. However, when the file is placed into an MKV container using MKVToolNix, the profile information becomes visible. This suggests that the output file does indeed contain a Profile 7.6 in the video stream, and when using --dolby-vision-profile 8.1, this new profile does not replace the 7.6 but is instead only recorded in the container.
On the other hand, using dovi-tool converts the Profile 7.6 to 8.1 and writes it directly into the video stream. My additional question is whether it’s possible for the encoder to internally convert the 7.6 profile (or any other present profile in the input video) to the profile chosen by the user using --dolby-vision-profile. The function to copy the original profile from the input video works perfectly, but if I want to convert it to 8.1, I currently have to extract the RPU, convert it with dovi-tool, and then reinsert it into the raw HEVC file.
The dovi profile written in rpu metadata is untouched. --dolby-vision-rpu copy is just copying RPU metadata as the option says, and does not not support edit/converting the rpu metadata.
You will need to use dovi_tool when conversion is required.
I would have to modify my script to first export the RPU and convert it and then add the path to the encoder parameter 😭
From NVEnc 7.70, dolby vision profile 7 in rpu will be converted using libdovi, which might improve the problem mentioned in this issue.
I'll close the issue, as the behavior about the problem mentioned should have been fixed in NVEnc 7.70.