Log in

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


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 [41] 42

Kuler087
12th May 2026, 23:25
Yes workflow 3-2.
It's not recommended because it's of inferior quality to workflow 3-1

MwenDavo
13th May 2026, 00:04
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
13th May 2026, 01:01
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
13th May 2026, 01:15
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
13th May 2026, 01:17
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
13th May 2026, 21:01
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
13th May 2026, 21:09
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
14th May 2026, 10:30
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
15th May 2026, 23:35
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
15th May 2026, 23:55
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
16th May 2026, 01:04
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
16th May 2026, 01:37
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
16th May 2026, 01:49
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
16th May 2026, 02:45
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
16th May 2026, 03:01
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
16th May 2026, 03:15
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
16th May 2026, 04:12
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
16th May 2026, 04:40
https://www.youtube.com/watch?v=lM56zLpKDQ8

rollmayonnaise
16th May 2026, 05:24
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
16th May 2026, 13:14
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
16th May 2026, 13:27
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
16th May 2026, 13:30
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
16th May 2026, 14:03
Appreciate the quick response.

RRAH
16th May 2026, 15:28
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
16th May 2026, 16:58
Yes, and you can use workflow 7-4 to compare metadata/tonemapping and see exactly what's happening.

en6ads
16th May 2026, 18:47
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
18th May 2026, 00:44
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
18th May 2026, 01:00
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
18th May 2026, 04:08
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
18th May 2026, 13:20
The old MA releases are just misauthored.

rollmayonnaise
19th May 2026, 02:10
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
19th May 2026, 03:28
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
20th May 2026, 19:06
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
20th May 2026, 19:16
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
25th May 2026, 08:26
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
25th May 2026, 11:48
I'll look into it

Kuler087
25th May 2026, 21:47
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
29th May 2026, 09:32
can this script convert TrueHD Atmos to EAC3 JOC?

Kuler087
29th May 2026, 11:57
Yes, workflow 8-1-3, but you must have the Dolby Encoding Engine (DEE) software.

en6ads
29th May 2026, 21:53
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
29th May 2026, 22:49
It's included in the tool pack I share.

rollmayonnaise
30th May 2026, 21:50
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
30th May 2026, 22:03
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
31st May 2026, 00:07
So does it work without the typo?

rollmayonnaise
31st May 2026, 00:44
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
31st May 2026, 01:20
Thanks, I'll release the next stable soon then.

Kuler087
31st May 2026, 02:32
3.1.2 released
https://github.com/R3S3t9999/DoVi_Scripts/releases

en6ads
1st June 2026, 00:52
3.1.2 released
https://github.com/R3S3t9999/DoVi_Scripts/releases

Awesome achievement, thank you.

rollmayonnaise
1st June 2026, 21:17
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
1st June 2026, 22:34
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