[DoVi_Scripts] Multi-Function Scripts for Dolby Vision processing and a lot more...

[Kuler087]

Yes workflow 3-2.
It's not recommended because it's of inferior quality to workflow 3-1

[MwenDavo]

Yes workflow 3-2.
It's not recommended because it's of inferior quality to workflow 3-1

Thanks for the response. Out of curiosity, why is 3-2 better than 3-1?
AFAIK, HDR10+ to DoVi can only carry the L1 metadata as that's the only thing they have in common, and so there is no way to generate the trims. Is the 3-2 workflow doing something to fill that gap?

[en6ads]

Hi All,

I have a few AM6b+ but when I heard FEL is working in CoreElec NO 5.15 kernel I decided to get an AM9 Pro.

I got it set up tonight and gotta say it's good. I tried some of your L5 and positive lift test files and they all worked as expected. This is using the latest nightly. I watched (again) about 30 mins for Friday Night at Freddy's 2 CM4.0 restored, and it didn't glitch or drop frames (that I could see). More testing to come.

I know it's still early stages, but it's good to know if AM6b+ ceases production, that the AM9 Pro could become a worthy successor.

What we need now is for AVDVPlus's enhancements and player process information to make it over to NO 5.15 kernel builds.

[Kuler087]

Thanks for the response. Out of curiosity, why is 3-2 better than 3-1?
AFAIK, HDR10+ to DoVi can only carry the L1 metadata as that's the only thing they have in common, and so there is no way to generate the trims. Is the 3-2 workflow doing something to fill that gap?

Sorry, maybe it's because of my weak English, but I said that 3-1 is better.

3-1 is better because it uses the official Dolby algorithm, which calculates min, max, and average differently than HDR10+. Also, I noticed that HDR10+ scene cuts are often inconsistent, and metadata can even change in the middle of a scene.
see:
https://drive.google.com/file/d/1PiiK4WVgXr2LTorJ6Ci2BWgJadNFZTVA/view?usp=drive_link

[Kuler087]

Hi All,

I have a few AM6b+ but when I heard FEL is working in CoreElec NO 5.15 kernel I decided to get an AM9 Pro.

I got it set up tonight and gotta say it's good. I tried some of your L5 and positive lift test files and they all worked as expected. This is using the latest nightly. I watched (again) about 30 mins for Friday Night at Freddy's 2 CM4.0 restored, and it didn't glitch or drop frames (that I could see). More testing to come.

I know it's still early stages, but it's good to know if AM6b+ ceases production, that the AM9 Pro could become a worthy successor.

What we need now is for AVDVPlus's enhancements and player process information to make it over to NO 5.15 kernel builds.

The biggest news here, in my opinion, is that CMv4.0 is now working in LLDV on HDR10-only displays and projector setups.
For my own TV-LED configuration, I don’t see much benefit, so I’ll keep using AVDVPlus or the Pannal builds (i like his latest 12bit pipeline addition).

[en6ads]

or the Pannal builds (i like his latest 12bit pipeline addition).

Have you observed any reduction in color banding with his 12-bit dither?

I have not tried it, just stayed with AVDVPlus builds so far for the AM6.

[Kuler087]

Have you observed any reduction in color banding with his 12-bit dither?

I have not tried it, just stayed with AVDVPlus builds so far for the AM6.

No but I still think it makes sense to keep the whole pipeline in 12bit for FEL

[daffie]

The biggest news here, in my opinion, is that CMv4.0 is now working in LLDV on HDR10-only displays and projector setups.
For my own TV-LED configuration, I don’t see much benefit, so I’ll keep using AVDVPlus or the Pannal builds (i like his latest 12bit pipeline addition).

Not to mention the awesome HDMI hardware vsync which is now 100% accurate. A huge milestone from panni.
I would not go back to avdvplus at this time. T4 is awesome for Display Led users.

[SamuriHL]

I may have to try it. DV is somewhat improved on the latest G6 firmware. It still needs work and HDR10 is still better at the moment but it's no longer completely broken so I have player led enabled again. I really need to calibrate this thing though. I use PM4K so I suspect it'll be a good fit with T4.

[Kuler087]

With the T4 build’s new 12-bit pipeline option, I have a Python script that can toggle it on and off on the fly, and I don’t see any visible difference. Still, I want it regardless, because right now all the CE builds perform an unnecessary 12-bit → 10-bit → 12-bit conversion in FEL Dolby Vision.

On a related subject, I upconverted the Rotating Gradients Banding test file to 12bit FEL DV, and to my surprise, it performs better than Profile 8.
https://mega.nz/folder/FG1X1DCK#rf7riUbSuhGF4gd8N0FyIg

[SamuriHL]

I just installed it and watching Dune Part One. We SHOULDN'T see a difference with the 12-bit pipeline. The idea is that it doesn't introduce any issues in the pipeline, as you pointed out with the unnecessary conversions.

I'll take a look at the rotating gradients banding. That's interesting.

I found Vincent's comment that the Dolby Vision engine isn't making full use of the Gen 3 chip (yet?) in the G6 interesting. If they can get the DV pipeline to match the quality of HDR10 then this display will absolutely ROCK.

[Kuler087]

We SHOULDN'T see a difference with the 12-bit pipeline
I was hoping for better gradients handling.


I found Vincent's comment that the Dolby Vision engine isn't making full use of the Gen 3 chip (yet?) in the G6 interesting. If they can get the DV pipeline to match the quality of HDR10 then this display will absolutely ROCK.
I have a feeling the DV closed-source engine will restrain it from using that 13bit processing and will remain inferior to HDR10.

[SamuriHL]

I was hoping for better gradients handling.


That's fair.


I have a feeling the DV closed-source engine will restrain it from using that 13bit processing and will remain inferior to HDR10.

I SERIOUSLY hope not. I'm hoping LG uses its status with Dolby to maybe get them to enhance the DV engine on this display. You may be right, though, which would really suck. Though I can't complain about HDR10 on this display. I could always use player led.

[rollmayonnaise]

I have been comparing a few CMv4.0 releases in my collection against their remastered SDR Blu-rays, mainly to see whether the Blu-rays appear to use a separate manual SDR grade or the Dolby Vision trim pass.

For example, The Pink Panther (1963) appears to have received what looks like a manual SDR grade for the Blu-ray. By contrast, the following titles seem to be derived from the Dolby Vision trim pass:


Airport (1970) — Kino Lorber
Shane (1953) — Kino Lorber
The African Queen (1951) — Vintage Classics / Studio Canal


What I found odd is that, when using DoVi_Scripts workflow 7-2, the DV trim screenshots for all three titles show a very slight green hue compared with the SDR Blu-rays. It is very subtle at first, but once your eyes adjust to it, the tint becomes noticeable across the comparison shots.

Screenshot comparisons:


Airport (1970): SDR Blu-ray vs DV trim comparison (https://slow.pics/c/V5YQFN8f)
Shane (1953): SDR Blu-ray vs DV trim comparison (https://slow.pics/c/e0EqjGz4)
The African Queen (1951): SDR Blu-ray vs DV trim comparison (https://slow.pics/c/zk3bPMri)


I also compared the new SDR Blu-rays against the Dolby Vision 100-nit trims in DaVinci Resolve using the XML files. In Resolve, using my M4 iPad Pro in Reference Mode as a clean video feed, I do not see the same green hue in the DV trim. The only real difference I notice is slightly finer grain from the 4K source.

That makes me wonder whether the green hue is being introduced somewhere in DoVi_Scripts workflow 7-2, rather than being present in the actual HDR10 encode. Could this be related to gamut mapping, or to another step in the workflow?

[Kuler087]

These are not Resolve vs 7-2 comp...
All I see here is better grain due to 4k vs 1080p compression.

https://i.ibb.co/G3P7pzkK/firefox-XWOo3l2-Dgf.gif

and you should look at the comps like this:
https://i.ibb.co/8QY2WdF/firefox-n-Su-Ld8d-FKG.png

[rollmayonnaise]

Yes those are not Resolve vs 7-2 comp, they're New SDR Blu-ray vs 7-2 comp. I'll try exporting a Resolve screenshot so that the grain and compression is consistent. In the GIF you attached, I see a green hue for the 7-2 version. I have asked someone else with a different display to confirm this impression to make sure I wasn't imagining it and they did so. I know it's subtle though but to me it's there.

And regarding the way the comps are displayed, you're right. I left them that way because the 1080p Blu-ray screenshots end up windowboxed otherwise, and I haven't yet looked into the proper way to manually upscale them to avoid that.

[rollmayonnaise]

Do you know how to properly export a Dolby Vision tone-mapped screenshot in Resolve?

What I did was grab a still, then right-click and choose:


Export With Dolby Vision Tone Mapping
100-nit, BT.709, BT.1886, Full (HOME)


However, the exported image looks different from what I see inside Resolve. In Resolve, the SDR Blu-ray and the HDR Blu-ray (with Tone Mapping Preview enabled) look similar.

Here is the result I got:

7-2 DV tone-mapped screenshot vs Resolve Dolby Vision tone-mapped still export vs SDR Blu-ray (https://slow.pics/c/zMDKmkPt)

[Kuler087]

https://www.youtube.com/watch?v=lM56zLpKDQ8

[rollmayonnaise]

Here it is:

7-2 DV tone-mapped screenshot vs screenshot from Resolve Dolby Vision tone-mapped video export vs SDR Blu-ray (https://slow.pics/c/JAWextEX)

I could not figure out why the stills were not exporting properly, so I exported a short DV 100-nit SDR Rec.709 video clip instead and extracted the screenshot directly from that.

I still see the green hue, especially in the whites, when comparing the Resolve export to the 7-2 version. I also find it helpful to zoom out and view the whole frame for certain shots, as the difference becomes a bit more noticeable that way.

[Keemy]

When it comes to injecting HDR10+ from AMZN VOD a lot of times they have a completely different aspect ratio compared to itunes and the UHD with the image looking slightly stretched. Borders are not taken into account for HDR10+ so by that logic I'm assuming these are safe to inject if the grades are a perfect match? Also does a grade mismatch that only occurs during the end credit etc disallow injecting? The rest of the movie matches else wise.

[Kuler087]

Here it is:

7-2 DV tone-mapped screenshot vs screenshot from Resolve Dolby Vision tone-mapped video export vs SDR Blu-ray (https://slow.pics/c/JAWextEX)

I could not figure out why the stills were not exporting properly, so I exported a short DV 100-nit SDR Rec.709 video clip instead and extracted the screenshot directly from that.

I still see the green hue, especially in the whites, when comparing the Resolve export to the 7-2 version. I also find it helpful to zoom out and view the whole frame for certain shots, as the difference becomes a bit more noticeable that way.

I dont know, try updating your ffmpeg or avisynth+.

you could try the latest beta too, I changed something in that workflow a few days ago regarding another issue.

[Kuler087]

When it comes to injecting HDR10+ from AMZN VOD a lot of times they have a completely different aspect ratio compared to itunes and the UHD with the image looking slightly stretched. Borders are not taken into account for HDR10+ so by that logic I'm assuming these are safe to inject if the grades are a perfect match? Also does a grade mismatch that only occurs during the end credit etc disallow injecting? The rest of the movie matches else wise.

I dont know much about HDR10+ but Amazon is known for messing up the original aspect ratio, so since the metadata are created from the mezzanine or the master file, it shouldn't matter... End credits also don’t matter as long as the rest of the video has the same brightness.

[Keemy]

Appreciate the quick response.

[RRAH]

Hello Kuler087, I have a question regarding how to handle DV UHD discs.

DV CMv2.9 -> mastered with CMv2.9 -> Brightness is outside the TV range -> Keep CMv2.9 for L2 trims

DV CMv2.9 -> mastered with CMv2.9 -> Brightness is within the TV range -> Generate CMv4.0

DV CMv2.9 -> mastered with CMv4.0 -> Brightness is outside the TV range -> No WEB RPU with CMv4.0 available -> Keep CMv2.9 for L2 trims

DV CMv2.9 -> mastered with CMv4.0 -> Brightness is outside the TV range -> WEB RPU with CMv4.0 available -> Restore CMv4.0

DV CMv2.9 -> mastered with CMv4.0 -> Brightness is within the TV range -> No WEB RPU with CMv4.0 available -> Append CMv4.0

DV CMv2.9 -> mastered with CMv4.0 -> Brightness is within the TV range -> WEB RPU with CMv4.0 available -> Restore CMv4.0

Is this correct?

Thanks in advance.

[Kuler087]

Yes, and you can use workflow 7-4 to compare metadata/tonemapping and see exactly what's happening.

[en6ads]

That's a great reference cheat-sheet, thank you.

I would add though, I have come across movies that do have Level 2 but they are just horizontal 2048. Last one I came across was The Last Emperor (1987) - 2160p Theatrical Turbine Germany 2023.

For that one I did Append.


Hello Kuler087, I have a question regarding how to handle DV UHD discs.

DV CMv2.9 -> mastered with CMv2.9 -> Brightness is outside the TV range -> Keep CMv2.9 for L2 trims

DV CMv2.9 -> mastered with CMv2.9 -> Brightness is within the TV range -> Generate CMv4.0

DV CMv2.9 -> mastered with CMv4.0 -> Brightness is outside the TV range -> No WEB RPU with CMv4.0 available -> Keep CMv2.9 for L2 trims

DV CMv2.9 -> mastered with CMv4.0 -> Brightness is outside the TV range -> WEB RPU with CMv4.0 available -> Restore CMv4.0

DV CMv2.9 -> mastered with CMv4.0 -> Brightness is within the TV range -> No WEB RPU with CMv4.0 available -> Append CMv4.0

DV CMv2.9 -> mastered with CMv4.0 -> Brightness is within the TV range -> WEB RPU with CMv4.0 available -> Restore CMv4.0

Is this correct?

Thanks in advance.

[rollmayonnaise]

Hello Kuler087, I have a question regarding how to handle DV UHD discs.

DV CMv2.9 -> mastered with CMv2.9 -> Brightness is outside the TV range -> Keep CMv2.9 for L2 trims

DV CMv2.9 -> mastered with CMv2.9 -> Brightness is within the TV range -> Generate CMv4.0

DV CMv2.9 -> mastered with CMv4.0 -> Brightness is outside the TV range -> No WEB RPU with CMv4.0 available -> Keep CMv2.9 for L2 trims

DV CMv2.9 -> mastered with CMv4.0 -> Brightness is outside the TV range -> WEB RPU with CMv4.0 available -> Restore CMv4.0

DV CMv2.9 -> mastered with CMv4.0 -> Brightness is within the TV range -> No WEB RPU with CMv4.0 available -> Append CMv4.0

DV CMv2.9 -> mastered with CMv4.0 -> Brightness is within the TV range -> WEB RPU with CMv4.0 available -> Restore CMv4.0

Is this correct?

Thanks in advance.

Can someone explain again why CMv4.0 is useful at all if brightness is within the TV range? Do the CMv2.9 bugs affect the image even when the brightness is within the TV range? I thought it would essentially just be untonemapped HDR10 in that case.

[Kuler087]

yes, cmv2.9 has black crush issues, and the ones with 4000mdl dims the image even if the content is within the TV's capabilities. Even on my 2400nits G5.

https://docs.google.com/spreadsheets/d/15i0a84uiBtWiHZ5CXZZ7wygLFXwYOd84/edit?gid=1289366200#gid=1289366200
https://drive.google.com/drive/folders/1g5I-z_sJmVu-SAIPNiiSlcdMiy2ka0mf

[rollmayonnaise]

yes, cmv2.9 has black crush issues, and the ones with 4000mdl dims the image even if the content is within the TV's capabilities. Even on my 2400nits G5.

https://docs.google.com/spreadsheets/d/15i0a84uiBtWiHZ5CXZZ7wygLFXwYOd84/edit?gid=1289366200#gid=1289366200
https://drive.google.com/drive/folders/1g5I-z_sJmVu-SAIPNiiSlcdMiy2ka0mf

Ah, I see.

If the HDR10 and DV modes on the LG were equivalent, I assume appending, when the brightness is within the TV's range, would only really be needed for DV FEL or DV P5 content, since you could otherwise just watch it in HDR10. But I understand that HDR10 has issues on LG TVs.

This may be completely unrelated, but I'm curious: do you know why MA DV P5 releases usually have two shots in CMv4.0 for CMv2.9 RPUs? Is there any chance they're doing something that achieves the same effect as the append function on the Ugoos, or am I just wildly overthinking this and misunderstanding how it works?

[Kuler087]

The old MA releases are just misauthored.

[rollmayonnaise]

The old MA releases are just misauthored.

Would this cause any issue for playback of the MA DV P5 files themselves?

Also, on the matter of whether or not to generate CMv4.0. It seems like the Blade Runner - The Final Cut DV P5 on Apple was updated (I think MA and Vudu never had the issue from what I've read online). I measured using madVR and it looks like it matches the 4K UHD (at least it's very different from the older DV P5 you measured). Visually, it looks good too. The L1 is identical, I suppose something went wrong only in the final encoding part and that didn't affect the L1/L2 values?

Here are the madVR, L1 and L2 plots (https://slow.pics/c/KyUb8FRa).

I guess it's not worth it for those trims?

[Kuler087]

Would this cause any issue for playback of the MA DV P5 files themselves?


L2 trims would probably be ignored

I guess it's not worth it for those trims?
right

[en6ads]

On a related subject, I upconverted the Rotating Gradients Banding test file to 12bit FEL DV, and to my surprise, it performs better than Profile 8.
https://mega.nz/folder/FG1X1DCK#rf7riUbSuhGF4gd8N0FyIg

Thanks for sharing this. Sorry I missed it earlier.

Does it perform better only with p3i full 12-bit VPP, or any of the CE builds that drop FEL precision down to 10-bit?

I have yet to install T4_dev. Been holding out for stable (any day now). But am willing to try it if FEL can look better.

[Kuler087]

the 12bit pipeline from the pannal build makes absolutely no difference.

You can use these scripts to change it on the fly:

ON:

import requests
import json

# --- Kodi Connection Details ---
KODI_IP = "192.168.2.26" # Replace with your Kodi device's IP address
KODI_PORT = "8080" # Default port is usually 8080
USERNAME = "username" # Replace with your Kodi web interface username
PASSWORD = "password" # Replace with your Kodi web interface password

# The JSON-RPC endpoint URL
URL = f"http://{KODI_IP}:{KODI_PORT}/jsonrpc"

def set_kodi_setting(setting_id, new_value):
"""
Sets a specific setting in Kodi via JSON-RPC.

:param setting_id: The string ID of the setting (e.g., "audiooutput.guisoundmode")
:param new_value: The new value for the setting (boolean, integer, string, etc.)
"""

# Construct the JSON-RPC payload
payload = {
"jsonrpc": "2.0",
"method": "Settings.SetSettingValue",
"params": {
"setting": setting_id,
"value": new_value
},
"id": 1
}

# Send the POST request to Kodi
try:
response = requests.post(
URL,
json=payload,
auth=(USERNAME, PASSWORD),
headers={"Content-Type": "application/json"}
)
response.raise_for_status() # Raise an exception for bad HTTP status codes

data = response.json()

# Check if Kodi returned a successful result
if "result" in data and data["result"] == True:
print(f"Success: Setting '{setting_id}' has been updated to '{new_value}'.")
elif "error" in data:
print(f"Error from Kodi API: {data['error']['message']}")
else:
print(f"Unexpected response: {data}")

except requests.exceptions.RequestException as e:
print(f"Connection failed. Please check your IP, port, and network. Error: {e}")

# --- Example Usage ---
if __name__ == "__main__":
# Example 1: Set a boolean value (e.g., enable/disable an option)
# Enable "Show hidden files and directories"
set_kodi_setting("coreelec.amlogic.prefer.12bit", True)



OFF:

import requests
import json

# --- Kodi Connection Details ---
KODI_IP = "192.168.2.26" # Replace with your Kodi device's IP address
KODI_PORT = "8080" # Default port is usually 8080
USERNAME = "username" # Replace with your Kodi web interface username
PASSWORD = "password" # Replace with your Kodi web interface password

# The JSON-RPC endpoint URL
URL = f"http://{KODI_IP}:{KODI_PORT}/jsonrpc"

def set_kodi_setting(setting_id, new_value):
"""
Sets a specific setting in Kodi via JSON-RPC.

:param setting_id: The string ID of the setting (e.g., "audiooutput.guisoundmode")
:param new_value: The new value for the setting (boolean, integer, string, etc.)
"""

# Construct the JSON-RPC payload
payload = {
"jsonrpc": "2.0",
"method": "Settings.SetSettingValue",
"params": {
"setting": setting_id,
"value": new_value
},
"id": 1
}

# Send the POST request to Kodi
try:
response = requests.post(
URL,
json=payload,
auth=(USERNAME, PASSWORD),
headers={"Content-Type": "application/json"}
)
response.raise_for_status() # Raise an exception for bad HTTP status codes

data = response.json()

# Check if Kodi returned a successful result
if "result" in data and data["result"] == True:
print(f"Success: Setting '{setting_id}' has been updated to '{new_value}'.")
elif "error" in data:
print(f"Error from Kodi API: {data['error']['message']}")
else:
print(f"Unexpected response: {data}")

except requests.exceptions.RequestException as e:
print(f"Connection failed. Please check your IP, port, and network. Error: {e}")

# --- Example Usage ---
if __name__ == "__main__":
# Example 1: Set a boolean value (e.g., enable/disable an option)
# Enable "Show hidden files and directories"
set_kodi_setting("coreelec.amlogic.prefer.12bit", False)

[ac777103]

Minor observation on 3-1, with latest beta. If I generate a .bin file first with 6-2 and the .mkv and .bin filenames end with "(year)", 3-1 renames the mkv to remove the final ")" before measuring the letterbox but does not do that to the matching .bin file if present. Hence 3-1 will repeat the madvr measuring step already performed by 6-2. Easy workaround (and best practice) is to exclude "(...)" from filenames until all processing complete, but thought I'd flag that the safey renaming of the mkv isn't being applied to the bin filename.

[Kuler087]

I'll look into it

[Kuler087]

Thanks for sharing the detailed beta changes. After downloading all the necessary files, I still had to correct what seems (from the code around it) like a small error on line 10380 of "DoVi_Scripts_MKV.bat". It looks like it should be ".avs." instead of ".mov."

Also, would you consider adding a workflow for generating comparison videos (similar to workflow 7-5) from two different sources, for example a DV P5 WEB-DL and an HDR remux? I am particularly interested in comparing cases where the WEB-DL grade appears brighter. For instance, I recently got a DV P5 WEB-DL of Rope (1948) that seems brighter according to madVR, especially compared to your HDR remux plot in your YouTube comparison.

Screenshots are not very practical for me since I cannot easily connect my PC to a proper HDR display. A video file would make it much easier to compare accurately and consistently on the appropriate device.

Have you tried the latest beta workflow 7-6?

Minor observation on 3-1, with latest beta. If I generate a .bin file first with 6-2 and the .mkv and .bin filenames end with "(year)", 3-1 renames the mkv to remove the final ")" before measuring the letterbox but does not do that to the matching .bin file if present. Hence 3-1 will repeat the madvr measuring step already performed by 6-2. Easy workaround (and best practice) is to exclude "(...)" from filenames until all processing complete, but thought I'd flag that the safey renaming of the mkv isn't being applied to the bin filename.

should work now

[solidservo]

can this script convert TrueHD Atmos to EAC3 JOC?

[Kuler087]

Yes, workflow 8-1-3, but you must have the Dolby Encoding Engine (DEE) software.

[en6ads]

Yes, workflow 8-1-3, but you must have the Dolby Encoding Engine (DEE) software.

I think you also need TrueHDD in the tools folder as well: https://github.com/truehdd/truehdd

Please correct me if this is no longer necessary.

[Kuler087]

It's included in the tool pack I share.

[rollmayonnaise]

Have you tried the latest beta workflow 7-6?


I get the following error comparing a 4K Blu-ray HDR file and DV P5 WEB file.


H:\>"F:\dovi\DoVi.Scripts\tools\x265.exe" --crf 10 --preset slow --aq-mode 1 --profile main10 --level-idc 5.1 --output-depth 10 --range limited --hdr10 --colorprim bt2020 --colormatrix bt2020nc --transfer smpte2084 --hdr10-opt --repeat-headers --hrd --aud --deblock -1:-1 --max-luma 1023 --no-sao --no-strong-intra-smoothing --chromaloc 2 --vbv-maxrate 160000 --vbv-bufsize 160000 --sar 1 --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50)" --max-cll "1000,400" --input "H:\tempy\temp.folder76\script.avs" --output "H:\tempy\temp.folder76\encoded.hevc"
avs+ [INFO]: AviSynth+ 3.7.5 (r4289, 3.7, x86_64)
avs+ [FLAW]: Error loading file: Script error: syntax error
(H:\tempy\temp.folder76\script.avs, line 55, column 85)
x265 [FLAW]: unable to open input file <H:\tempy\temp.folder76\script.avs>

H:\>echo off
mkvmerge v91.0 ('Signs') 64-bit
Error: The file 'H:\tempy\temp.folder76\encoded.hevc' could not be opened for reading: open file error.
Press any key to continue . . .

[rollmayonnaise]

EDIT: Line 19287 of DoVi_Scripts_MKV.bat:
if /i "%screenshot_OSD%"=="YES" if not "!delay!"=="" echo .Subtitle("Frame: !adjust_frame%%i! of %FrameCount2%" ^+ " - Picture type: " ^+ Chr(FFPICT_TYPE^),, size=40, align=7, x=40, y=50, text_color=%osdcolor%^)\ >> "%TEMP%script.avs"

instead of

if /i "%screenshot_OSD%"=="YES" if not "!delay!"=="" echo .Subtitle("Frame: !adjust_frame%%i! of %FrameCount2%" ^+ " - Picture type: " ^+ Chr(FFPICT_TYPE^), size=40, align=7, x=40, y=50, text_color=%osdcolor%^)\ >> "%TEMP%script.avs"

---

Ran the script.avs through ChatGPT and it detected double commas for all v2frames. + Chr(FFPICT_TYPE),, size=40 instead of + Chr(FFPICT_TYPE), size=40.


v1frame9 = video1.trim(9000,9000).Loop(24)\
.Subtitle("a ", size=40, align=7, x=40, y=15, text_color=$5A5A5A)\
.Subtitle("Frame: 9000 of 128721" + " - Picture type: " + Chr(FFPICT_TYPE), size=40, align=7, x=40, y=50, text_color=$5A5A5A)\
.Subtitle("Max: 492its, Avg: 53nits, MDL: min: 0.0050 cd/m2, max: 1000 cd/m2", size=40, align=7, x=40, y=85, text_color=$5A5A5A)\
v1frame10 = video1.trim(10000,10000).Loop(24)\
.Subtitle("a ", size=40, align=7, x=40, y=15, text_color=$5A5A5A)\
.Subtitle("Frame: 10000 of 128721" + " - Picture type: " + Chr(FFPICT_TYPE), size=40, align=7, x=40, y=50, text_color=$5A5A5A)\
.Subtitle("Max: 417its, Avg: 52nits, MDL: min: 0.0050 cd/m2, max: 1000 cd/m2", size=40, align=7, x=40, y=85, text_color=$5A5A5A)\
v2frame1 = video2.trim(976,976).Loop(24)\
.Subtitle("b ", size=40, align=7, x=40, y=15, text_color=$5A5A5A)\
.Subtitle("Frame: 976 of 128534" + " - Picture type: " + Chr(FFPICT_TYPE),, size=40, align=7, x=40, y=50, text_color=$5A5A5A)\
.Subtitle("Max: 392its, Avg: 3nits, MDL: min: 0.0050 cd/m2, max: 4000 cd/m2", size=40, align=7, x=40, y=85, text_color=$5A5A5A)\
v2frame2 = video2.trim(1976,1976).Loop(24)\
.Subtitle("b ", size=40, align=7, x=40, y=15, text_color=$5A5A5A)\
.Subtitle("Frame: 1976 of 128534" + " - Picture type: " + Chr(FFPICT_TYPE),, size=40, align=7, x=40, y=50, text_color=$5A5A5A)\
.Subtitle("Max: 0its, Avg: 0nits, MDL: min: 0.0050 cd/m2, max: 4000 cd/m2", size=40, align=7, x=40, y=85, text_color=$5A5A5A)\

[Kuler087]

So does it work without the typo?

[rollmayonnaise]

So does it work without the typo?

Yes, tested a few files and seems to work great, thanks! I'm currently using this to confirm P8 hybrids when the madVR plots seem slightly different but not enough to be sure it's a trim pass and not too little to think it's the same grade. I've checked Lucy (2014) for example, and I'm fairly certain the 4K Blu-ray is a trim pass (an additional indicator is the MDL mismatch).

[Kuler087]

Thanks, I'll release the next stable soon then.

[Kuler087]

3.1.2 released
https://github.com/R3S3t9999/DoVi_Scripts/releases

[en6ads]

3.1.2 released
https://github.com/R3S3t9999/DoVi_Scripts/releases

Awesome achievement, thank you.

[rollmayonnaise]

Thanks for this new release. I am very grateful for workflow 7-6.

On another note, I don't know if I'm hallucinating but I'm seeing the green tint again in one of your latest DV trim SDR comparison.
The one for The Good The Bad And The Ugly (1966): https://slow.pics/c/bq4BrNmQ
Or maybe it's just a coincidence and it's from the grade itself?

[Kuler087]

Or maybe it's just a coincidence and it's from the grade itself?
i dont know but i many more comparisons or personal SDR encode without issues...
you could always ask Dolby: https://professionalsupport.dolby.com/s/dolby-vision-post-production-forum?language=en_US

[Kuler087]

https://professionalsupport.dolby.com/s/question/0D5QQ00002KEbkm0AD/2022-tvs-chroma-weight-metadata-doesnt-work?language=en_US

FYI, I reported the Chroma Weight bug affecting 2022+ TVs to Dolby.
The last time I reported an issue(positive lift), I made it obvious that I was using third-party tools, and they never responded. This time, I approached it differently, and they did respond, so hopefully the bug is fixable rather than something baked into the newer SoC hardware.

[SamuriHL]

Sweet! That would be awesome.

[wyup]

I've just updated to latest 3.1.2 version and new files in tools folder. For a while, when doing 6-2 plotting, I get a LavFilterSource error. I have stable 0.81 installed on my system, and recently extracted libs in tools folder. How can I mend this?

LAV Splitter Source not found.
Reading generate config file...

[Kuler087]

Is this with or without cropping? Cropping can be tricky. I have two PCs with the same software and NVIDIA graphics cards, but I can only get cropping to work on one of them and can't figure out why. The workaround is to use ProRes, which is much faster anyway if you have a good CPU.

Have you tried re-installing lavfilters?
Also, you could try the latest nightly (https://files.1f0.de/lavf/nightly/LAVFilters-0.81.0-27.exe).

[wyup]

I've just pinpointed the issue: apparently 6-2 Plotter demands x86 LavFilters library. I had only installed x64.
With x86, it executed properly, except for a small python error in madvr_parser.py (one of the recent new files in the tools folder):
Traceback (most recent call last):
File "C:\hdr\tools\madvr_parser.py", line 161, in <module>
main()
~~~~^^
File "C:\hdr\tools\madvr_parser.py", line 157, in main
plot_maxcll_interactive(frames, title=plot_title, out_html=args.interactive_out)
~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\hdr\tools\madvr_parser.py", line 93, in plot_maxcll_interactive
import plotly.graph_objects as go
ModuleNotFoundError: No module named 'plotly'

[Kuler087]

pip install plotly

[x264N00b]

Thanks for this nice tool and all the hard work.
Is there a possibility to choose a different resize filter, when using 8-2 with the downscale option? Default is spline36.

[Kuler087]

it's in the screenshot settings
line 133
set upscale_algo=Spline36

[x264N00b]

Thanks, works ;)

[Kuler087]

Latest Beta (https://drive.google.com/file/d/128gq8aDUTKA_aT7SQsM9dkjA1EP1sosR/view?usp=drive_link), added a new frame-by-frame HDR plot method (SMITH-ZINK) in 6-2. Faster and includes an accurate auto letterbox detection for movies with variable AR, but values are calculated differently than madvr, and I personally prefer madvr.
example: https://slow.pics/c/0Zv5dLCI?canvas-mode=fit-width

Also added frame-by-frame plotting from madvr in 6-2, which is now the new default:
example: https://slow.pics/c/WWnJ4Bo3


New folder and files to put in the tool folder: https://drive.google.com/drive/folders/1CKLmJhbh0gbItC7auSHhFbwAYsJNp1Ml?usp=drive_link
see lines 346-356:

:: HDR measurement mode. Default = MADVR (MADVR or SMITHZINK) / SMITHZINK support auto letterbox detection and CPU processing.
set mode_62=MADVR
:: Frame by Frame(FBF) or Shot by Shot(FBF) plotting. Default=SBS (SBS or FBF) / Valid for MADVR mode only. SMITHZINK can only do frame by frame.
set SBS_FBF_62=FBF
::Force cpu processing when mode_62=SMITHZINK (default = NO) / madvr mode doesnt support cpu processing
set forceCPU_62_SMITHZINK=NO
:: choose if you want 6-2 SDR plot downscale the input to speed up the process. This option will work only if crop.prores62=YES and when you opt to crop (default = NO) Valid for MADVR mode only.
set downscaleHDRmeasure=NO
:: choose if you want 6-2 to convert to prores when you opt to crop. This may be faster depending on your CPU (default = NO) Valid for MADVR mode only.
set crop.prores62=NO
:: enable additionnal interactive frame by frame plot in 6-2 (default = YES) Valid for MADVR mode only.
set Interactive_plot_62=YES

[Hellboy.]

Hello Kuler087

1.What is the more accurate method for the screenshot?
HDR= 1 > SDR_DV_Trim_Pass= 3 > SDR_Libplacebo= 0
2.Is the SDR_DV_Trim_Pass pretty accurate?
3.I found a bug with "SDR_DV_Trim_Pass= 3". When there are multiple inputs only the screenshot of the last input are created.
I was using 3 inputs and it seems that input 2 overwrite input 1, and then input 3 overwrite input 2.
The same thing happens with "SDR_DV_Trim_Pass" when I use "Both= 2".
For "HDR= 1" and "SDR_Libplacebo= 0" work correctly.

[Kuler087]

1- DV trim, even if the input is just HDR10.
2- nothing is more accurate than it
3- strange, I do comps with 3 inputs all the time. Just did that yesterday in my latest YouTube video about The Day of the Dead. What are your 3 input formats?
4- I'll check it out but when i did it, it was working.

[Hellboy.]

Timecop US 4K BD
Timecop FRA 4K BD
Timecop GER 4K BD
All 3 remuxes in mkv, without audios, subtitles and chapters.
I am using DoVi Scripts v3.1.2
I don't used "auto mode" for the frames.
I change this setting to "set DEL_temp=NO"

[Kuler087]

ha ok, I never compare multiple HDR sources in SDR because I dont see the point. But I see the issue I introduced in the latest stable and the latest beta (https://drive.google.com/file/d/128gq8aDUTKA_aT7SQsM9dkjA1EP1sosR/view?usp=drive_link) should fix it.

This version requires many new files/folder and Python libraries. This version has new audio analysis options (6-8) and image comparisons viewer capabilities (similar to the slowpics website )

new python libraries to install: pip install pyyaml librosa scipy soundfile
new files/folder to put in the tools folder: https://drive.google.com/drive/folders/1CKLmJhbh0gbItC7auSHhFbwAYsJNp1Ml?usp=drive_link

[Hellboy.]

Worked. Thanks.
Someone asked for this, but hope you can find an easy way to add the frame type to the "SDR_DV_Trim_Pass" screenshots.

[Kuler087]

FYI: if you update your MPV folder with this new version, workflow 7-7-1 now supports HDR12(FEL decoding) + dynamic tone mapping using libplacebo/MPV

https://github.com/zhongfly/mpv-winbuild/releases

libplacebo can also make use of the DV Level 1 dynamic metadata, but it only reads the brightness data and performs tone mapping with its own internal algorithm. It's not using the Dolby Vision tone-mapping engine, so it is not LLDV, but it still means we can now get 12-bit HDR + the increased bitrate from the EL with dynamic tone mapping using the pre-calculated brightness metadata.

https://i.ibb.co/8D9Zt8dt/Windows-Terminal-O7wy-RVv-HTG.gif

[Kuler087]

https://youtu.be/Beqwqw2--ZA
Looks like CMV4+ is coming soon in Resolve. We'll be able to mix shot-by-shot and frame-by-frame analysis within the same project, and there will also be an easily accessible toggle for the analysis tuning selection.
Also, it looks like they're finally moving away from the stupid mastering display luminance (MDL) for how trim interpolation works. From what it sounds like, we'll be able to match the MDL to the actual peak brightness of the grade. I see trims raising the brightness above the actual HDR master way too often just because the mastering display luminance (MDL) is set to 4000 nits. These new changes sound promising.

[SamuriHL]

That does sound nice. Sweet!

[dkangel]

hello
i have this message this i update from 3.1.2 beta to 3.1.2
i'm trying to go from p7 mel to p8

CHOICES: (default=X - check another file)
Check_New_File=X L5=5 L6=6 L9=9 Resync=R or D SceneCut_Edit=F Source_PQ=Q Remove_CMV4=4
PLOT=P Extract=E Check_Sync=S Metafier=M Transfer_Levels=T P7_to_P8=7 Remover=V No.DV.TM=N
--------------------------------------------------------------------------------------------------
7

Do you want to convert the audio to DDP? (default= n )

--> YES= y
--> NO= n

tsMuxeR version git-7f8667d. github.com/justdan96/tsMuxer
For streams inside MKV container need track parameter.
Appuyez sur une touche pour continuer...

any ideas ?

thank you

[Kuler087]

Yes, it's a regression I introduced in the latest version. Get the beta.

also, don't forget to add the new files required for it:
https://drive.google.com/drive/folders/1CKLmJhbh0gbItC7auSHhFbwAYsJNp1Ml?usp=sharing

[dkangel]

Yes, it's a regression I introduced in the latest version. Get the beta.

also, don't forget to add the new files required for it:
https://drive.google.com/drive/folders/1CKLmJhbh0gbItC7auSHhFbwAYsJNp1Ml?usp=sharing

working now, thank you

[coykoi88]

Does the Workflow 5.B (DoVi MP4 Batch Muxer) have a limit for how many audio tracks are combined into the MP4 file? I have a case where I set the scripts to extract all audio and all subtitles. I did this when converting the DV Profile 7 MKV file to a DV Profile 8 MKV file (all audio tracks and subs transferred). However when I use the Dovi_Scripts_MP4.bat script, it stops at audio track #10. Each language has either 3 or 2 tracks, so there ends up being like 14 tracks, and cuts off the last 4 or so tracks including the one I want.

It sounds like you can only request one audio track or all of them. Is there any way to request two different tracks maybe using 3 letter language IDs or just the index number of the audio track?

[Kuler087]

Yes, the MP4 and TS versions are limited to 15 audio tracks and 38 subtitle tracks because I have to specify each track individually when muxing with those tools. I wish they had an option to automatically mux all tracks, like mkvmerge does.
I could increase the track limit, but for now, unless you really need all of them, it's best to use an MKV that already contains only the audio and subtitle tracks you want.

[coykoi88]

Thanks. I guess I can't easily remove audio tracks from an MKV file? I can probably just re-rip the disc with MakeMKV and unselect the extra languages.

[daffie]

Thanks. I guess I can't easily remove audio tracks from an MKV file? I can probably just re-rip the disc with MakeMKV and unselect the extra languages.

MKVtoolnix

[Kuler087]

3.1.3 Released (https://github.com/R3S3t9999/DoVi_Scripts/releases)

- (6-2) NEW calculation mode using SMITH-ZINK frame-by-frame method. Doesnt work with P5/HLG/Prores inputs. see line 302 (default = MADVR)
- (6-2) Can now plot data frame by frame or shot by shot. see line 304 (default = FBF)
- (6-2) Added an option to bake FEL (see line 314) (default=NO)
- (6-2) Added an option to detect letterbox in batch mode. see line 318 (default=NO)
- (6-7) Can now also plot the audio bitrate
- (6-8) Can now plot the Atmos metadata as well as other audio analysis options(spectrogram(slow)). see lines 400-405...
- (7-1)(7-2) Can now automatically build the comparison in HTML similar to slowpics for offline previewing.
- (7-7-1) Now supports FEL decoding and playback with dynamic tone mapping from L1. (You must update your MPV folder.)
- (1) Editor: Improved readability
- (4-1) Bugfix: regression in 3.1.2

[dkangel]

workflow 6-2 are very differents from madvr to smith-zink

https://i.postimg.cc/YS3zrhXf/Capture-d-ecran-2026-07-22-210215.png (https://postimg.cc/mcPHV2Wt)

https://i.postimg.cc/C1xHzStq/Capture-d-ecran-2026-07-22-210224.png (https://postimg.cc/GB6sfwbL)

[Kuler087]

Yes, I know, and Madvr is the default because it matches Dolby Vision L1 more closely.

[dkangel]

i will continue to use madvr :)

[Keemy]

When a remux or WEB-DL that's 16:9 with black bars doesn't have a crop set in the RPU, what are the side effects of this during playback. Is it raised blacks or grey black bars? For cropped encodes that have the RPU incorrectly set the over-crop is easily visible as soon as playback starts so hoping to identify the reverse for this.

[Kuler087]

Black bars will be raised only if the trim metadata contains a positive lift greater than 0.025, which is very rare. Even in the few movies that do have a significant positive lift, the value is never high enough to be noticeable.
So, in other words, setting L5 to 0 for everything is the safest option and will almost never(99.9%) introduce visual defects, whereas setting L5 to incorrect values (>0) can cause visual issues (overcrop).

see: https://drive.google.com/drive/u/1/folders/1LbuwBDZj5x3i1bdbAntsZlr5CiYJ9KKj

[Keemy]

Thank you. Another follow-up, does utilizing DV from web (standard aspect ratio) to inject into a UHD that has IMAX aspect ratio the correct method? The image data for those scenes don't exist in web so I assume tonemapping will be incorrect .e.g Dunkirk, Interstellar. RPU can be cropped for black bars but I don't think the reverse effect is the same if the RPU gets "extended".

[Kuler087]

The studios use the same metadata for both IMAX and non-IMAX releases all the time. The metadata from an IMAX master with proper per-shot blanking is not very different from the metadata generated with fixed blanking.
As long as the pixel measurements (6-2) from both sources, using the same cropping, are close enough, everything will work fine.

[Keemy]

Okay that leads me to my final 2 questions, I promise though the answer to one of them is obvious from your previous responses. Are you able to inject an IMAX rpu with the L5 adjusted to a single crop into a standard aspect ratio video.e.g an IMAX rpu from dsnp into a HDR file from MA assuming grades and measurements are checked and verified before hand. The final question can P7 from a UHD source be converted to P8 and injected into web or is it limited to P5 only. I appreciate you taking the time to answer these.

[Kuler087]

Are you able to inject an IMAX rpu with the L5 adjusted to a single crop into a standard aspect ratio video.e.g an IMAX rpu from dsnp into a HDR file from MA assuming grades and measurements are checked and verified before hand
yes

can P7 from a UHD source be converted to P8 and injected into web or is it limited to P5 only.

as long as both sources are close enough in 6-2. If FEL expands brightness, then the other video must match that brightness.

[Keemy]

The studios use the same metadata for both IMAX and non-IMAX releases all the time. The metadata from an IMAX master with proper per-shot blanking is not very different from the metadata generated with fixed blanking.
As long as the pixel measurements (6-2) from both sources, using the same cropping, are close enough, everything will work fine.

When measuring the IMAX file do you leave out the top and bottom crop you would normally do for a non-max video or do you still need to crop them. I'm thinking no because of the variable changing aspect ratio?

[Kuler087]

I measure/crop the IMAX source in 6-2 at the same aspect ratio as the non-IMAX source.

[DaMacFunkin]

If you donate is there a link to access the RPU files please?

[Kuler087]

yes i send you an email. see the pinned comment in the resolve tutorial: https://youtu.be/FVSh3oGqfXY

[Cmptr]

If I transcode a bdremux that is Dolby Vision Profile 7, using ffmpeg libx265, setting all the correct colors and transfers. Use the hdr10 and hdr10-opt and cropping the black bars... (Not manually specifying master display, cll or any of that) Would I use the dovi_scripts to extract the RPU out of the original bdremux, then inject it with dovi_scripts after the transclde is done? Is that the correct way to do it? Or does it need to be done during the transcode to actually modify the bitstream during transcoding?

Is there no way to keep keep the original profile be 7 or whatnot, without converting it to 8 or 8.1?

[Kuler087]

Yes, but why not just use workflow 8-2-1 in dovi_scripts? Everything is automated, and the FEL will be correctly baked into the video, which FFmpeg cannot do on its own.


Is there no way to keep keep the original profile be 7 or whatnot, without converting it to 8 or 8.1?

Workflow 8-2-7

[Cmptr]

Does profile 7 need to be trancoded? Or can it just be copied directly?

[Kuler087]

DS has three main encoding workflows for DV HDR. (assuming you have DEE)

1- Workflow 8-2-1 converts the Profile 7 RPU to Profile 8 and encodes the video with x265.exe. The new RPU is injected on the fly during the encoding process.
2- Workflow 8-2-7 converts the P7 RPU to XML and creates a new lossless mezzanine file. The Dolby Encoding Engine (DEE) then uses the XML and mezzanine file to encode a new Profile 7 FEL (or MEL, if preferred) video with the HDR10 base layer. This workflow is generally a waste of time because DEE only supports bitrate-based encoding (single-pass or two-pass), whereas Workflow 8-2-1 supports CRF encoding.

3- Workflow 8-2-6 also converts the P7 RPU to XML and creates a new lossless mezzanine file. DEE then uses these two files to encode a new Profile 5 DV video. Unlike Workflow 8-2-7, this mode supports CRF encoding.

[Cmptr]

Ahh, so ultimately the FEL or MEL will be Lossy? I'm assuming the end file with ultimately be larger as well compared to if profile 8 is used?

[Cmptr]

A lot of devices just drop the FEL/MEL... Even plex. So would there technically be any difference if I were to keep profile 7, or convert it to profile 8?

[Kuler087]

The devices that drop FEL will play DV incorrectly for a lot of movies (https://drive.google.com/drive/u/0/folders/1FS42T95TOSpoy4xtwUBIQmziCe_R_IKe), so yeah it's better to use P8 and bake FEL into the HDR10 layer. (workflow 8-2-1)

[Cmptr]

I'm finding that there is a device called Am9 Pro that with custom firmware, you can actually take advantage if the FEL. But using Jelyfin. Not Plex.

Last I tried Jelyfin, I was not able to play back a HEVC 10bit dv stream however. I was also using the LG App, whereas now I just purchased a Nvidia Shield. Haven't tried jelyfin yet on it. The Shield is nice, though I have noticed some things.

I personally dont like how you cant use CRF with profile 7, and it bothers my OCD that is just uses bitrate....

[Kuler087]

The shield is far from being nice and has color issues in DV (https://drive.google.com/drive/folders/1uaHVLriou0RFuS8DWtVmxYs1tumPl0F3?usp=drive_link). It also drops or duplicates frames every 45 minutes (as usual with nvidia).
If you want the best media player, (https://docs.google.com/spreadsheets/d/15i0a84uiBtWiHZ5CXZZ7wygLFXwYOd84/edit?gid=845372636#gid=845372636) get a Ugoos running CoreELEC, which also ''supports'' Plex. There isn't a better media player available, and there likely never will be.

[Cmptr]

The shield is far from being nice and has color issues in DV (https://drive.google.com/drive/folders/1uaHVLriou0RFuS8DWtVmxYs1tumPl0F3?usp=drive_link). It also drops or duplicates frames every 45 minutes (as usual with nvidia).
If you want the best media player, (https://docs.google.com/spreadsheets/d/15i0a84uiBtWiHZ5CXZZ7wygLFXwYOd84/edit?gid=845372636#gid=845372636) get a Ugoos running CoreELEC, which also ''supports'' Plex. There isn't a better media player available, and there likely never will be.

Thats what I was reading. It supports FEL but only using Jelyfin to my knowledge. I did notice that the colors are washed out abd frames were dropping on the shield.

Have you tried playback with FEL using Jelyfin?

Is the Ugoos laggy at all like how tv apps are?

[Kuler087]

Ugoos AM6B+ is very fast, much faster than the shield. It has accurate colors and never drop frames. User interface is fully customizable and not bloated like the shield.
Jellyfin, plex, usb, smb, it doesnt matter, as these are just the server for your movies. The ugoos supports FEL or any DV format, no matter the source.

There is no better player, period. If you're serious about quality, this is the player to get.

https://i.ibb.co/GQt9rb3p/2025-10-12-11-39-01.jpg

[Cmptr]

I know its just a server, but I thought that plex will drop the fel even if using direct play? Only thing I dont like is that it doesn't support Netflix 4k HDR, unless there is actually a working way that I havent found.

[Kuler087]

Plex doesn't actually play the file, the Ugoos does. Plex is only used to access and organize your movie library, so it doesn't matter.
As for streaming services like Netflix, just use your TV's built-in apps.

[Cmptr]

So would converting mel to P8, would that be better compared to just streaming thr movie with Mel to plex on my LG? Better quality? And does it have to be trancoded, or could it just be extracted, converted and injected back in?

[Kuler087]

P8 is the same quality as MEL P7.
No transcoding, workflow 4-1.

[Cmptr]

If I keep the video MEL P7, will it be dropped compared to if I convert it to P8? If yes, converting it to P8 would technically yield better quality, no?

[Kuler087]

If you're talking about LG apps, last time I checked, PLEX will not play P7 as DV, but the Kodi app (https://kodi.wiki/view/HOW-TO:Install_Kodi_for_webOS) can play P7(as P8) which is the same as using doviscripts workflow 4-1

[Cmptr]

So in that case, it would be better to convert P7 to P8 so it doesnt fall back to HDR10, and actually show it in DV using Plex on my LG?

[Kuler087]

if you want to use plex, yes.

[Keemy]

There have been a few times when streamers completely messed up the scenecuts in the RPU. Are there any foolproof methods to figure out and generate the correct ones if no other official sources exist?

[Kuler087]

I don't know, but in that case, the metadata were probably generated with the wrong scene cuts, and rearranging them will probably mess things up.

[Kuler087]

New functions to test before the next stable...

7-3 now has 3 modes: IMAGE, VIDEO, GAMUT. See line 137 default: set mode.73=IMAGE

IMAGE: same as before; exports heatmap and gamut images. Gamut process sped up (2.5X)
VIDEO: exports a heatmap video with waveform. Same as I did in this video: https://youtu.be/2gYLKEACKqw?t=249
GAMUT: Plots the whole movie gamut coverage.

latest BETA (https://drive.google.com/file/d/128gq8aDUTKA_aT7SQsM9dkjA1EP1sosR/view?usp=drive_link)
New files to add/replace in the tools folder (https://drive.google.com/drive/folders/18ycF-Y9UfVCeUWf85bseMhc21KcK8NoD?usp=drive_link)

New daily updated master list for HDR brightness (https://docs.google.com/spreadsheets/d/15i0a84uiBtWiHZ5CXZZ7wygLFXwYOd84/edit?gid=1940673964#gid=1940673964)
New daily updated list for gamut coverage (https://docs.google.com/spreadsheets/d/15i0a84uiBtWiHZ5CXZZ7wygLFXwYOd84/edit?gid=1353161154#gid=1353161154)


https://i.imgur.com/KwbgplP.png

[lemaireus]

Until version 3.1.1, Dolby Atmos encoding used to work seamlessly and that changed after I updated to 3.1.3. Now the Dolby Atmos track is decoded just fine, and then the command prompt window simply disappears. The encoding never begins. Yes, the dee.exe is exactly where it should be (line 510: =%~dp0tools\DEE\dee.exe).

I went back from 3.1.3 to 3.1.1 and there was no problem whatsoever in encoding the Atmos track. Can this be fixed or should I simply stick to 3.1.1?

[Kuler087]

I guess your path or filename contains ()

Fixed in latest beta (https://drive.google.com/file/d/128gq8aDUTKA_aT7SQsM9dkjA1EP1sosR/view?usp=drive_link)... dont forget to add the new files i shared just before your post.

[lemaireus]

I guess your path or filename contains ()

Thank you, Kuler, those brackets () indeed were the problem and the Atmos encoding in v 3.1.3 worked exactly as it should have once I removed them.

I'll hold off on the beta DoVi_Scripts_MKV and wait for the final release for now because I use DoVi_Scripts_TS as the latter provides the .ec3 file extension that works better for me and saves me the bother of changing file extensions after each Atmos and/or 7.1 encode. (I've added the new files that you shared to the 'tools' folder, though.)

Many, many heartfelt thanks for making Atmos encoding available. To my knowledge, you were the first one to offer 7.1 and thereafter the first to offer Atmos. Much gratitude.

[Kuler087]

You just have to rename the beta file to TS. There is no difference between the TS MKV or MP4 scripts.

[lemaireus]

You just have to rename the beta file to TS. There is no difference between the TS MKV or MP4 scripts.

Thank you, I shall use the beta version then.

[Cmptr]

Why is max-luma set to 1023? What if the video source is brighter?

[Kuler087]

This value is not in nits but in 10bit.

12bit = 4095 = 10 000nits
10bit = 1023 = 10 000nits

[Kontrarian]

I can't do 6-2 now.
Any idea?


Drag and drop folder with files or a single file and press enter...
D:\DoVi_Scripts\movie.mkv

* Cropping helps with MaxFALL accuracy but the process is a lot slower...

Do you want to exclude the letterbox? (default=n)

--> YES= y
--> NO= n



Processing... "D:\DoVi_Scripts\movie.mkv"

LAV Splitter Source not found.
Sorting data...
File not found: D:\DoVi_Scripts\movie.mkv.measurements
Error: The system cannot find the file specified. (os error 2)
Done...
Parsing RPU file...
Error: The system cannot find the file specified. (os error 2)
Error: The system cannot find the file specified. (os error 2)
Error: The system cannot find the file specified. (os error 2)
Parsing RPU file...
Error: The system cannot find the file specified. (os error 2)

Calculating MaxCLL/FALL threshold...
Error loading JSON: [Errno 2] No such file or directory: 'D:\\DoVi_Scripts\\temp.folder81\\RPU.json'
Done.

Traceback (most recent call last):
File "D:\DoVi_Scripts\tools\maxcll.shot.finder.py", line 40, in <module>
extreme_line = find_extreme_value(input_file, mode)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\DoVi_Scripts\tools\maxcll.shot.finder.py", line 17, in find_extreme_value
with open(file_path, 'r') as file:
^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: 'D:\\DoVi_Scripts\\temp.folder81\\data.raw\\.max.pq.txt'
Traceback (most recent call last):
File "D:\DoVi_Scripts\tools\maxcll.shot.finder.py", line 40, in <module>
extreme_line = find_extreme_value(input_file, mode)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\DoVi_Scripts\tools\maxcll.shot.finder.py", line 17, in find_extreme_value
with open(file_path, 'r') as file:
^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: 'D:\\DoVi_Scripts\\temp.folder81\\data.raw\\.avg.pq.txt'
convert: unable to open image 'D:\DoVi_Scripts\temp.folder81\movie_HDR10_plot.png': No such file or directory @ error/blob.c/OpenBlob/3569.
convert: no images defined `D:\DoVi_Scripts\movie.HDR_plot.png' @ error/convert.c/ConvertImageCommand/3342.
Traceback (most recent call last):
File "D:\DoVi_Scripts\tools\madvr_parser.py", line 161, in <module>
main()
File "D:\DoVi_Scripts\tools\madvr_parser.py", line 144, in main
frames = parse_maxcll_frames(args.input)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\DoVi_Scripts\tools\madvr_parser.py", line 28, in parse_maxcll_frames
with open(path, "rb") as f:
^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: 'D:\\DoVi_Scripts\\movie.mkv.measurements'
Deleting TEMP folder...


Start time: 17:37:04.06
End time: 17:37:29.12
Time taken: 0:00:25

The script has been completed, press a key to measure HDR again...
Press any key to continue . . .

[Kuler087]

Looks like lavfilters is not installed.

[Kontrarian]

I have no idea how LAV got uninstalled on my computer, I've done 6-2 more times than I can remember, but installing it again fixed the issue.

Thank you!

[Kontrarian]

@Kuler087 I am wondering what you may have done for Terminator: Dark Fate (2019) if you have it.
I didn't see a generated RPU in your folder.
It's CMv2.9 FEL.

Here's the PLOT:
https://i.ibb.co/BmTsRMw/Terminator-Dark-Fate-2019-UHD-Blu-Ray-2160p-True-HD-Atmos-7-1-DV-HEVC-REMUX-Fra-Me-STo-R-RPU-Do-Vi-L.png



Oh, and worth noting, the credits on this movie wreak havoc on the CMv4.0 append feature.
I'm talking to the devs to see what they think is going on there.
The L2 trims there are probably being ignored and it's causing the screen to blank out completely between names.

Here's the L2 plot for that if you are curious:
https://i.ibb.co/yBpPmrht/Terminator-Dark-Fate-2019-CREDIT-SAMPLE-Do-Vi-L2-100nits-PLOT.png


If you don't have that movie already and want to see the CMv4.0 append issue I have a sample on my Dropbox here: https://www.dropbox.com/scl/fo/xz8uszh354pkz3mv9jmu0/AD-nE_sLqiCKPgI231SaYlk?rlkey=seklcwfqwogpdxlght03b29y2&st=c3dyqfpx&dl=0

[Kuler087]

I haven't processed this movie yet, and I usually upgrade(resolve) them to 4.0 when I plan to watch them. I'm not sure how the Ugoos append function could break anything (picture-related)...

FYI, this is the only movie I know of with a 1000-nit MDL that still expands brightness through FEL.

https://i.imgur.com/4yAIVdt.gif

[Kontrarian]

If you want to check out how the CMv4.0 append messes with this movie you can check out the sample I made.

It completely blanks out the black between names in the beginning of the credits.
Usually the L5 area is pure black and the credits background is slightly elevated, but once a name fades out and before the next name is displayed it blacks out the entire screen like a full screen L5 mask.
It doesn't matter what you do to L5 settings, the only thing that changes this behavior is turning the append feature on and off.
SMART and ALWAYS both blank out between names.
You need to be watching in a completely dark environment to see it.
It's trivial and I don't really care too much about it but I have informed the devs just incase it is a simple fix and/or it effects other things.

Link to dropbox: https://www.dropbox.com/scl/fo/xz8uszh354pkz3mv9jmu0/AD-nE_sLqiCKPgI231SaYlk?rlkey=seklcwfqwogpdxlght03b29y2&st=y4u3mf4u&dl=0

[Kuler087]

what if you just add the cmv4.0 with dovi_scripts workflow 1

[Kontrarian]

If I use DS and generate CMv4.0 then it doesn't do it whether the append option is on or off.
If I use DS and "UPGRADE" to CMv4.0 then it always does it whether the append option is on or off.
So upgrading the RPU to CMv4.0 essentially bakes the issue in.

[Kuler087]

Then the only reason I can see is the avg_pq, since in true CMv4.0 the floor is 10 nits, while in 2.9 the floor is 2.5 nits. So this mismatch might be causing the issue, but it’s still surprising. I’ll check it out.

[Marco22IM]

Hi, when doing Workflow 6-3, I get these errors at the end. How can I resolve them? Thanks!

https://i.imgur.com/wxPfZfe.png

[Kuler087]

Your tool folder is missing some files:
https://drive.google.com/drive/folders/18ycF-Y9UfVCeUWf85bseMhc21KcK8NoD?usp=drive_link

[Marco22IM]

Thanks! Today I did a Workflow 8-2-1. Is it possible to compare the converted file with the original Profile 7 using screenshots, to see what details I "lost"? I used CRF 15 and the Medium preset.

[Kuler087]

Of course, Workflow 7-2.

[Marco22IM]

Of course, Workflow 7-2.

So I understood correctly, thanks! Here's the comparison of Workflow 8-2-1 with CRF 15 and the Medium preset. What do you think? The Slow preset would have taken too long... https://slow.pics/c/Dm5hozLx

MediaInfo bitrate:
Profile 7: 64.2 Mb/s
Profile 8.1: 34.3 Mb/s

What should I have done to maintain the same bitrate with the Medium preset? Should I have used a different CRF? This is my first Workflow 8-2-1. My TV is a Sony Bravia 8 II 65", and I think doing this workflow is necessary to take advantage of the TV's capabilities instead of just watching it in HDR10, although the famous DV scan lines sometimes make me regret watching in DV. :angry:

[Kuler087]

Lower your CRF value if you want more bitrate, but yeah, quality really starts with the slow preset, and slower is even better. (Veryslow is a bit overkill for the time it takes, until CPUs get more powerful)

[Cmptr]

Lets say I have a 8bit 1080p avc sdr video, and I encode it to 10bit hevc sdr. If I have a 10bit 2160p hevc dv of the same video, could I ultimately make that 1080p video, be dv by inserting the metadata from the 10bit 2160p hevc video?

[Kuler087]

No, HDR is something that is graded. You can't transform something to HDR just with metadata.

[Gatorman3385]

8-2-4. When downscaling DV with variable L5, is the blanking kept or stuck to a single value?

[Kuler087]

L5 should be kept.

[Gatorman3385]

Interesting. I'm getting black bars throughout the entire encode. I'll run it again to confirm.

RPU_FEL.bin

Summary:
Frames: 190021
Profile: 7 (FEL)
DM version: 2 (CM v4.0)
Scene/shot count: 2313
RPU mastering display: 0.0001/1000 nits
RPU content light level (L1): MaxCLL: 450.89 nits, MaxFALL: 215.23 nits
L6 metadata
Mastering display: 0.0001/1000 nits. MaxCLL: 412 nits, MaxFALL: 7 nits
Mastering display: 0.0001/1000 nits. MaxCLL: 385 nits, MaxFALL: 311 nits
Mastering display: 0.0001/1000 nits. MaxCLL: 290 nits, MaxFALL: 30 nits
Mastering display: 0.0001/1000 nits. MaxCLL: 416 nits, MaxFALL: 344 nits
L5 offsets: top=0..275, bottom=0..275, left=0, right=0
L2 trims: 100 nits, 600 nits, 1000 nits
L8 trims: 100 nits
L9 MDP: DCI-P3 D65


P8.RPU.bin

Summary:
Frames: 190021
Profile: 8
DM version: 2 (CM v4.0)
Scene/shot count: 2313
RPU mastering display: 0.0001/1000 nits
RPU content light level (L1): MaxCLL: 450.89 nits, MaxFALL: 215.23 nits
L6 metadata
Mastering display: 0.0001/1000 nits. MaxCLL: 412 nits, MaxFALL: 7 nits
Mastering display: 0.0001/1000 nits. MaxCLL: 385 nits, MaxFALL: 311 nits
Mastering display: 0.0001/1000 nits. MaxCLL: 290 nits, MaxFALL: 30 nits
Mastering display: 0.0001/1000 nits. MaxCLL: 416 nits, MaxFALL: 344 nits
L5 offsets: top=137, bottom=137, left=0, right=0
L2 trims: 100 nits, 600 nits, 1000 nits
L8 trims: 100 nits
L9 MDP: DCI-P3 D65


crop.json

{
"mode": 2,
"active_area": {
"crop": false,
"presets": [
{
"id": 0,
"left": 0,
"right": 0,
"top": 137,
"bottom": 137
}
],
"edits": {
"all": 0
}
}
}

[Kuler087]

I'll check it out later

[matbezlima]

When using 8-2-4 flow to convert a 2160p remux video to 1080p SDR x264 using the 100 nits trim pass, can I replicate all the encoding settings I use in Handbrake's Super HQ 1080p option? Can I crop black cars? Can I set Tune to Grain, Level to 4.1, and so on? If I'm being confusing, I might later take a screenshot of the settings I use. Also, what CRF would recommend to not create any visible compression artifacts in the aforementioned conversion from 2160p Remux to 1080p x264, especially if the source is VERY grainy? My experiences have pointed to CRF 12, but what do you think?

[Kuler087]

If you use the slower or veryslow preset, it should already be close to perfection, but you can tweak the settings as much as you want. And yes, you can crop. CRF-12 will be extremely high quality/bitrate.

One thing though: CMV2.9 with trims (original or converted from L8 to L2) can actually have worse quality than CMV4.0 with L1 alone. CMV2.9 can clip whites and colors, especially red.
example: https://slow.pics/c/4zXce5YH
Kind of hilarious since all Blu-ray players are stuck with 2.9 forever. I'd say don't use DV on disc. The Ugoos CMV4.0 upgrade is a great feature, and hopefully the audio sync issues that came with the 4.0 upgrade will be fixed soon.

[matbezlima]

If you use the slower or veryslow preset, it should already be close to perfection, but you can tweak the settings as much as you want. And yes, you can crop. CRF-12 will be extremely high quality/bitrate.

One thing though: CMV2.9 with trims (original or converted from L8 to L2) can actually have worse quality than CMV4.0 with L1 alone. CMV2.9 can clip whites and colors, especially red.
example: https://slow.pics/c/4zXce5YH
Kind of hilarious since all Blu-ray players are stuck with 2.9 forever. I'd say don't use DV on disc. The Ugoos CMV4.0 upgrade is a great feature, and hopefully the audio sync issues that came with the 4.0 upgrade will be fixed soon.

Thanks for your reply. Now, I only have one two more questions: first, can I do in DoVi_Scripts all the setting choices in the following Handbrake image? Including settings such as Encoder Tune, Encoder Profile, Encoder Level, and Advanced Options? If yes, how?

https://i.ibb.co/ns2fWF02/Sem-t-tulo.png

Second, could you please do a comparison between Chinatown screenshots from the original cmv2.9 trims and generated cmv4.0? There seems to be a lot of work on that film's 100 nits trim, which is also original and not downconverted from cmv4.0. So, I would love a comparison and to know which caps do you think look better in the case of Chinatown.

https://i.ibb.co/gLkVr6GZ/Screenshot-20260821-114954.png

[Kuler087]

Including settings such as Encoder Tune, Encoder Profile, Encoder Level, and Advanced Options? If yes, how?

Open the .bat file in Notepad++ and add or remove any settings in the x264 command here.

https://i.imgur.com/IBWFaQr.png

Second, could you please do a comparison between Chinatown screenshots from the original cmv2.9 trims and generated cmv4.0? There seems to be a lot of work on that film's 100 nits trim, which is also original and not downconverted from cmv4.0. So, I would love a comparison and to know which caps do you think look better in the case of Chinatown.
I don't have this movie, but it's almost certain that CMV4.0 L1 will be better than CMV2.9 manual trims, at least regarding Luma and Chroma clipping.
CMV2.9 is just completely broken. I don't use it anymore for my HDR-to-SDR conversions or TV-LED DV playback.

[matbezlima]

Thanks for your reply!

I shared a graph of the 100 nits Chinatown trim, from your Chinatown video.

[Kuler087]

I dont have this movie anymore. You can easily do the comparison in workflow 7-2.
You can configure the script to ignore the original trim.
line 107
set ignoreDV_72=YES

[matbezlima]

I dont have this movie anymore. You can easily do the comparison in workflow 7-2.
You can configure the script to ignore the original trim.
line 107
set ignoreDV_72=YES

Okay, thanks!

[matbezlima]

Do you still have the link to that screenshots' comparison between ones tonemapped with the Level 2 100 nits trim and those tonemapped with the Level 8 100 nits trim? I remember them looking identical, aside from better highlights and less clipping in the latter.

[Kuler087]

I dont know what comparison you are talking about but you can easily make one with any of the cmv4.0 movies.

[matbezlima]

I dont know what comparison you are talking about but you can easily make one with any of the cmv4.0 movies.

It's a comparison you shared to me in a comments' section of a video, but I struggle to remember which video.

[matbezlima]

I dont know what comparison you are talking about but you can easily make one with any of the cmv4.0 movies.

I have now found the screenshot comparison I was thinking about:

https://slow.pics/c/zyTrlct6

[Kuler087]

Yeah, and it shows the chroma/luma clipping I was talking about.

[matbezlima]

Yeah, and it shows the chroma/luma clipping I was talking about.

True. That said, I don't think the cmv2.9 caps here are bad at all. The highlightst clipping is there, but it's far from horrendous. And otherwise, both sets of caps seem to be idêntica. And regarding color clipping, I assume that a film with minimal WCG would barely suffer from it.

[Kuler087]

Yes, but this movie isn’t very bright (400–600 nits). I hate any form of clipping, so it’s a no-go for me. No CMV 2.9 is allowed on my Ugoos/G5 or for the HDR-to-SDR conversions I do for my friends and family’s Plex shares.

FYI, this is with TV-LED DV.

https://i.imgur.com/zZtcpp5.gif https://i.imgur.com/JyWi8Q2.gif

[matbezlima]

I can only imagine how horrendous those light-cannon UHDs would look if tonemapped to SDR using cmv2.9.

Since you hate any clipping, I assume that there must be cases in which you prefer to use the generated Dolby Vision cmv4.0 metadata over the original cmv4.0 metadata taken from streaming (or from the disc, since there are UHDs with cmv4.0). I'm thinking about how the whites in Paramount's 2022 remastered blu-rays of The Godfather trilogy can look harsh, and I assume that those discs were derived from the Level 8 100 nits trim from the original cmv4.0 metadata, not from the downconverted Level 2 100 nits trim from the cmv2.9 metadata in the disc. I guess that my point is that there are likely plenty of cases in which you don't find the 100 nits trim tonemapping ideal even in cmv4.0 metadata.

[Kuler087]

I assume that there must be cases in which you prefer to use the generated Dolby Vision cmv4.0 metadata over the original cmv4.0 metadata taken from streaming
Unless it has static metadata, the original cmv4.0 is fine.
I have restored retail cmv4.0 for the Godfather 1&2 discs.

[matbezlima]

Unless it has static metadata, the original cmv4.0 is fine.
I have restored retail cmv4.0 for the Godfather 1&2 discs.

Great!

[matbezlima]

I have made now a comparison between Chinatown caps taken with with the 100 nits trim (the film was mastered in cmv2.9) and caps taken with generated Dolby Vision metadata cmv4.0. I didn't actually notice any highlight clipping. What was blatant to see, though, was the significantly raised black levels in the caps made with the 100 nits trim! The entire image looks less saturated and more washed out really. I guess that the colorist attempted to retain as much shadow detail and highlight detail as possible, and the more washed-out look was an inevitable compromise due to the inherent tonemapping limitations of the cmv2.9 algorithm. Does my guess make sense?

One more question: are the caps made with Generated Dolby Vision cmv4.0 metadata using Analysis Tuning 1?

[Kuler087]

Yes, the 100-nit trim has a big positive lift (offset metadata) for all the shots.
FYI, this metadata is ignored on all the hdmi players except the ones with CoreELEC.

are the caps made with Generated Dolby Vision cmv4.0 metadata using Analysis Tuning 1?
the default is tuning 1 yes but you can change it. see line line 105:

:: analysis tunning to use for DV trim pass SDR tone mapping when input is HDR10 (Default= 1) 0 = Old legacy mode, 1= Most Highlight Detail/Most Mapping, 2= More Highlight Detail/More Mapping, 3= Balanced, 4= Less Highlight Detail/Less Mapping, 5= Least Highlight Detail/Least Mapping
set Tunning_SDR_Screenshots=1

[matbezlima]

Thanks for your replies!

[Kuler087]

FYI, this is with TV-LED DV.

https://i.imgur.com/zZtcpp5.gif https://i.imgur.com/JyWi8Q2.gif

So I have more info about this TV-LED CMV 2.9 clipping issue. It seems it was introduced in 2022 TVs. Someone with a C1 and C4 confirmed that the clipping is not present on his C1, but it is on the C4.

Amazing how incompetent Dolby is...

btw this clipping is also quite obvious in LLDV 2.9.

This is with an 800 nits EDID (C2):
https://slow.pics/c/OWVuIpd5

So, a big quality upgrade is coming up in R10 with cmv4.0 support for those who use LLDV on HDR10/SDR displays.

[Kuler087]

Interesting. I'm getting black bars throughout the entire encode. I'll run it again to confirm.


Should be fixed in the latest beta (https://drive.google.com/file/d/128gq8aDUTKA_aT7SQsM9dkjA1EP1sosR/view?usp=drive_link) , thanks