View Full Version : [DoVi_Scripts] Multi-Function Scripts for Dolby Vision processing and a lot more...
Kuler087
13th January 2026, 22:01
No. You can only import the scene cuts, but not L5.
You can use my Resolve project:
with homemade trims: https://drive.google.com/file/d/1M1t9D3r5JJRYqnMgjNlcPCEx_WfnJmmS/view?usp=drive_link
without trims: https://drive.google.com/file/d/1VrmvolOnhppUH8XxnFA9r9k5_duA6gMC/view?usp=drive_link
dkangel
13th January 2026, 22:03
ok i'll try this tomorrow, thank you for your time
dkangel
14th January 2026, 17:33
i've import your project with my mov file, scene cuts are ok and so L5 changes seems synchro too, i'm analysing for dv and give a try on my tv
but i think it will be ok
prudentavocado
14th January 2026, 23:21
Right, on a 5000-nits TV, there is no advantage to converting HDR10 to Dolby Vision in 3-1(or resolve).
For a native DV Blu-ray rip, some FEL titles do restore a brighter master (https://drive.google.com/drive/u/0/folders/1FS42T95TOSpoy4xtwUBIQmziCe_R_IKe), but that benefit is lost once they are converted to Profile 8. You need a device like the Ugoos Am6B+ to get that brighter DV from FEL playback.
Baking in the FEL properly to get a p8 is still lower on the picture quality scale than a Web p5 (due to the color space), correct?
Kuler087
15th January 2026, 03:08
yes but streaming DV5 has worse hevc compression due to the lower bitrate
prudentavocado
15th January 2026, 05:45
yes but streaming DV5 has worse hevc compression due to the lower bitrate
Damn, so what do you choose? I suppose whatever looks pleasing to the eyes on your display?
I guess p8 remux > p5 > p8 encode
Kuler087
15th January 2026, 14:12
When compressed properly, a P8 encode will be better than streaming DV5.
remux > p8 encode > P5
prudentavocado
16th January 2026, 00:06
When compressed properly, a P8 encode will be better than streaming DV5.
remux > p8 encode > P5
No kidding, does that mean if the p8 encode and p5 are identical bitrate you'd go with the p8?
Thanks in advance.
Kuler087
16th January 2026, 00:41
If the P8 encode comes from the UHD Blu-ray and I compressed it myself, yes.
Streaming compression is subpar. iTunes is DNR garbage, MA has a lot of compression noise and introduces visible artifacts with grain-heavy content, Disney’s and Fandango bitrate is too low, and Amazon’s HEVC compression is horrible.
prudentavocado
18th January 2026, 01:56
If the P8 encode comes from the UHD Blu-ray and I compressed it myself, yes.
Streaming compression is subpar. iTunes is DNR garbage, MA has a lot of compression noise and introduces visible artifacts with grain-heavy content, Disney’s and Fandango bitrate is too low, and Amazon’s HEVC compression is horrible.
Interesting note about MA, everything else I've read about it is exceptional and potentially equal/better than the UHD disks.
en6ads
18th January 2026, 23:16
Damn, so what do you choose? I suppose whatever looks pleasing to the eyes on your display?
I guess p8 remux > p5 > p8 encode
There is one other option: Mode 8-2-6. With DEE you could transcode P7 FEL (12-bit YCbCr) to P5 (10-bit ICtCp, about 11.5-bit YCbCr equivalent).
However with lossless TIFF it takes absolutely ages and massive amounts of disk space. But it retains the 12-bit FEL (almost), and can have the same high encode rate of the UHD.
I have yet to encode a full movie using this method, only 10 minute chunks. But the result is really good. If you have a home server with loads of disk space I can recommend at least trying it.
Kuler087
19th January 2026, 00:54
You can also encode any DV source to P7 (FEL or MEL) with the latest beta(workflow 8-2-7). Add these x265 plugin (https://drive.google.com/drive/folders/1yTGPpiaKRnWg9A0viVd2-d7t9ZmO7P8r?usp=sharing) to your DEE folder. You also need to replace \DoVi_Scripts\tools\DEE\python_scripts\encode_dvmezz_to_dv7.py
::8-2-7 profile 7 encoding mode. (default= no_mapping_with_fel) Choices are: 'no_mapping_with_mel', 'no_mapping_with_fel', 'map_to_1000_nits_with_fel', 'map_to_1000_nits_with_mel', 'map_to_600_nits_with_fel'
set usecase=no_mapping_with_fel
::BL bitrate in 8-2-7 P7 FEL encoding
set BL_rate=25000
::BL buffer in 8-2-7 P7 FEL encoding
set BL_buff=99000
::EL bitrate in 8-2-7 P7 FEL encoding. MEL bitrate / buffer is hardcoded to 500 / 550
set EL_rate=3000
::EL buffer in 8-2-7 P7 FEL encoding. MEL bitrate / buffer is hardcoded to 500 / 550
set EL_buff=5000
prudentavocado
19th January 2026, 02:13
There is one other option: Mode 8-2-6. With DEE you could transcode P7 FEL (12-bit YCbCr) to P5 (10-bit ICtCp, about 11.5-bit YCbCr equivalent).
Hmm, I guess I would have just assumed this is what the streaming services are already doing
Kuler087
19th January 2026, 02:20
Well, streaming services get the 12 or 10 bit mezzanine source from the studios; they don't convert P7 FEL to P5.
Gigabit
22nd January 2026, 20:34
Hi,
Have you considered using http://avisynth.nl/index.php/LSMASHSource when doing the baking via DoViBaker as I believe this supports Intel Quick Sync?
Kuler087
22nd January 2026, 21:08
No sorry man, I'm not really interested in adding a third frame indexer in the encoder workflows.
Gigabit
22nd January 2026, 22:00
No sorry man, I'm not really interested in adding a third frame indexer in the encoder workflows.
Is there a way I can use it manually? Can I edit the script at the end to use it?
Kuler087
22nd January 2026, 22:05
Is there a way I can use it manually? Can I edit the script at the end to use it?
The Script Workflow 8-2 would be complicated to edit manually because it includes a lot of other options, but you can simply follow the dovi_baker instructions, it’s not too complicated.
https://github.com/erazortt/DoViBaker
Gigabit
22nd January 2026, 22:58
The Script Workflow 8-2 would be complicated to edit manually because it includes a lot of other options, but you can simply follow the dovi_baker instructions, it’s not too complicated.
https://github.com/erazortt/DoViBaker
I had a look at your script and it seems to be doing a lot more than DoViBaker so I wondered if you were doing something extra?
I am trying to "bake" a FEL movie ("Saving Private Ryan").
I have the MKV of the source movie. From what I can understand, I need to load this into `dovi_tool` and use:
- extract-rpu to extract the RPU
- demux to output the base layer and enhancement layer as separate files
From what I can see, I then provide these files to `DoViBaker` via an AviSynth/AviSynth+ script:
bl = LWLibavVideoSource("bl.hevc", format="YUV420P10", stream_index=0)
el = LWLibavVideoSource("el.hevc", format="YUV420P10", stream_index=1)
DoViBaker(bl, el, rpu="RPU.bin")
Is that...it?
Kuler087
22nd January 2026, 23:40
yes pretty much. Lsmash and ffms2 can read the rpu from the stream so you only need
bl = LWLibavVideoSource("bl.hevc", format="YUV420P10", stream_index=0)
el = LWLibavVideoSource("el.hevc", format="YUV420P10", stream_index=1)
DoViBaker(bl,el)
but this output will be 16bit RGB PQ. You have to convert it to YUV420P10 bt2020 then feed that script to the encoder.
Gigabit
23rd January 2026, 01:12
yes pretty much. Lsmash and ffms2 can read the rpu from the stream so you only need
bl = LWLibavVideoSource("bl.hevc", format="YUV420P10", stream_index=0)
el = LWLibavVideoSource("el.hevc", format="YUV420P10", stream_index=1)
DoViBaker(bl,el)
but this output will be 16bit RGB PQ. You have to convert it to YUV420P10 bt2020 then feed that script to the encoder.
Thanks mate, how do I do the conversion?
Kuler087
23rd January 2026, 01:20
ConvertBits(10)
ConvertToYUV420(matrix="2020")
Colek
25th January 2026, 10:27
Just a small bug report - if filename contains an exclamation mark, at least in the Mode 1 it will be incorrectly reported as HDR10 only.
Had an issue figuring it out with one of the files, after renaming it, it worked just fine and detected P7.
Kuler087
25th January 2026, 14:07
right input with ! will never work in any workflow because it's used to delimit a variable.
for %%i in (!video_path!) do set filename=%%~ni
for %%i in (!video_path!) do set filepath=%%~di%%~pi
for %%i in (!video_path!) do set fileext=%%~xi
prudentavocado
26th January 2026, 02:21
Bit rate : 23.1 Mb/s
Mastering display luminance : min: 0.0050 cd/m2, max: 4000 cd/m2
Maximum Content Light Level : 305 cd/m2
Maximum Frame-Average Light Le : 10 cd/m2
Bit rate : 18.0 Mb/s
Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 1000 cd/m2
Maximum Frame-Average Light Le : 928 cd/m2
Trying to decide between two P8 proper group encodes (both should be from the UHD blu ray as primary video source), mostly similar but noticed this one difference in the light levels, should I put much stock into these values for P8s?
Kuler087
26th January 2026, 14:16
just measure the video in 6-2 without letterbox and edit it to the right values with workflow 9-9
Enet47
27th January 2026, 14:51
Only found out about this wonderful tool yesterday. It took me a minute to find out then work out how to use it. But I've finally converted my first FEL mkv to DV 8.1 Question: How do I check that it actually worked?
Kuler087
27th January 2026, 14:54
You can do some screenshot comparisons in Workflow 7-2 or 7-1
Enet47
27th January 2026, 16:55
You can do some screenshot comparisons in Workflow 7-2 or 7-1
Thanks. Hopefully my final dumb question. I get that there is a list of FEL files that can't be converted without baking FEL into BL. But does that mean that I can convert the other DV FEL files to 8.1 without loosing FEL?
Kuler087
27th January 2026, 17:05
You always lose FEL when re-encoding to Profile 8. When you bake FEL, you retain all bitrate, grain, brightness, and any differences relative to the BL but the 12bit depth precision is lost forever.
You should always bake FEL when re-encoding, regardless of whether FEL makes a visible difference in that specific title. It does not slow down processing, so there is no reason not to bake it.
Enet47
27th January 2026, 17:40
You always lose FEL when re-encoding to Profile 8. When you bake FEL, you retain all bitrate, grain, brightness, and any differences relative to the BL but the 12bit depth precision is lost forever.
You should always bake FEL when re-encoding, regardless of whether FEL makes a visible difference in that specific title. It does not slow down processing, so there is no reason not to bake it.
Thank you for the clear explanation. I didn't go to sleep trying to get Nvenc to work. Then I realized that it needed be be updated to work with the same command line I use with StaxRip :)
Thanks again for the clear explanation. This now makes a lot more sense. Thank you again for the great application.
Teddy13
29th January 2026, 21:34
I have a question regarding a german capelight disc (Strange Darling) with previously described authoring issues, which I was not aware of. I used makemkv to create the mkv. Since it is only DV MEL I used handbrake for profile 7 to 8 encoding keeping the DV metadata. Now I had a look into the film and there are only odd looking purple and green bands. Just then I saw this movie in your list of discs with authoring issues. My question is, how can I resync the RPU? Can I use Dovi Scripts? Can I do it with the finished handbrake encode or should I do it with the makemkv output? Or do I need to get the .m2ts file first and start all over? Thx
Kuler087
29th January 2026, 21:54
You have to demux/extract the RPU straight from the original M2TS. Then you can convert it and inject it as P8.
Teddy13
29th January 2026, 22:17
Thx for the quick reply. At what point can/do I have to do the reencode then? Before or after reinjection of the RPU P8, or does it not matter?
Kuler087
29th January 2026, 23:11
you can encode with the P8 rpu or inject it after; it doesn't matter
en6ads
31st January 2026, 02:12
I have a question regarding a german capelight disc (Strange Darling) with previously described authoring issues, which I was not aware of. I used makemkv to create the mkv. Since it is only DV MEL I used handbrake for profile 7 to 8 encoding keeping the DV metadata. Now I had a look into the film and there are only odd looking purple and green bands. Just then I saw this movie in your list of discs with authoring issues. My question is, how can I resync the RPU? Can I use Dovi Scripts? Can I do it with the finished handbrake encode or should I do it with the makemkv output? Or do I need to get the .m2ts file first and start all over? Thx
Please don't use Handbrake to encode a P8.1 from a P7 MEL.
Instead use DoviScripts to create a new mkv file that injects a converted p8 rpu into the P7 base layer without needing to reencode the base layer.
If you know for sure it's MEL, then workflow 4-1.
To check the mkv file first, use workflow 1, then 7.
With a fast SSD this takes about 5 - 7 minutes.
rollmayonnaise
31st January 2026, 09:28
Are there plans to add support for exporting the DV 100-nit trim as screenshots when using Dolby Vision Profile 5? At the moment, with workflow 7-2 and tonemapping option 3, DV P5 screenshots render with a green/purple tint.
Kuler087
31st January 2026, 15:24
Try the latest beta; it should work now. There was a typo.
https://drive.google.com/file/d/128gq8aDUTKA_aT7SQsM9dkjA1EP1sosR/view?usp=sharing
TR-9970X
1st February 2026, 00:58
Try the latest beta; it should work now. There was a typo.
https://drive.google.com/file/d/128gq8aDUTKA_aT7SQsM9dkjA1EP1sosR/view?usp=sharing
Hi kuler,
It's good that are always improving this great app you've created, but I'd just like to say that every time a new beta comes along, the users that have edited the previous release to suit their needs, have to go thru the whole process again :(
Would it be possible just to provide the actual changes, and the user could then just copy that into the appropriate line of the previous version ??
And if needed (for continuity), even the build number could be changed.
I know that could also create issues, but it's an option.
Just a thought.
Regards.
Kuler087
1st February 2026, 01:18
I understand, but the beta versions only introduce new features. There’s no reason to always update to the latest beta, especially if you’ve made your own changes to the script. The beta releases rarely include bug fixes (except for new features), and I haven’t had any bugs to fix for many releases, so you're not missing much by not using the latest beta.
As for the version number, the last modified date is displayed every time you launch the script.
TR-9970X
1st February 2026, 01:27
I understand, but the beta versions only introduce new features. There’s no reason to always update to the latest beta, especially if you’ve made your own changes to the script. The beta releases rarely include bug fixes (except for new features), and I haven’t had any bugs to fix for many releases, so you're not missing much by not using the latest beta.
As for the version number, the last modified date is displayed every time you launch the script.
Fair enough.
So the possible new features aren't simply a line or 2 of text, then ??
Is there a way to just release the new features ??
Kuler087
1st February 2026, 01:41
Is there a way to just release the new features ??
possible yes, but that would just increase my workload, and I already have enough to do(outside DS).
When there's a new feature I like, I always share it here in the forum, so unless you want one of those, there's no reason to update to the latest beta every time I make a change.
So the possible new features aren't simply a line or 2 of text, then ??
No, the current beta has many changes in different workflows:
- (7-2) Can now export SDR screenshots from Dolby Vision trim pass (L8 or L2)
- (8-2-7) NEW Workflow: Can now re-encode and keep P7 FEL/MEL with proper nal units for both layers (requires DEE with x265 plugins)
- (4-1) P7 to P8 will now attempt to detect FEL expanded brightness.
- (1) (EDITOR) The script will now attempt to detect if FEL expands the brightness
- (2-7) (BATCH INFO) The script will now attempt to detect if FEL expands the brightness
- (7-1) (7-2) Added trims metadata to OSD. Default = NO (line )
- (1) (EDITOR) Can now quickly ''info'' more inputs instead of exiting the script.
- (7-4)(7-5) Removed the limitation that restricted the script from processing CMv4.0, RPUs with L8 trims at 300, 600, 1000, or 2000 nits. These fellback to cmv2.9 before. Files in the tool folder to be updated/replaced:
- (8-2-8) Added a mode that can estimate bitrate from CRF encoding/settings
- (8-2-8) Bugfix: regression in previous version: workflow didn't work
- (8-2-4) Bugfix: regression in previous version: fix raised black
TR-9970X
1st February 2026, 03:22
possible yes, but that would just increase my workload, and I already have enough to do(outside DS).
When there's a new feature I like, I always share it here in the forum, so unless you want one of those, there's no reason to update to the latest beta every time I make a change.
No, the current beta has many changes in different workflows:
Understood, just thought I'd ask, that's all.
Answered & explained thoroughly, as always :)
Rootdown4594
1st February 2026, 15:05
Please don't use Handbrake to encode a P8.1 from a P7 MEL.
Instead use DoviScripts to create a new mkv file that injects a converted p8 rpu into the P7 base layer without needing to reencode the base layer.
If you know for sure it's MEL, then workflow 4-1.
To check the mkv file first, use workflow 1, then 7.
With a fast SSD this takes about 5 - 7 minutes.
Why do this for MEL instead of using handbrake?
Woodrowspoo81
2nd February 2026, 00:42
What's the best way using Dovi_Scripts to triple an rpu.bin? I really need a proper .json with script to triple rpu yet interleaving the metadata evenly throughout. Any help would be appreciated.
prudentavocado
2nd February 2026, 00:56
Can anyone point me to instructions on how to convert a 8.6 video to 8.1? Or is this not possible? Tried searching this thread but didn't find anything promising.
8.6 giving me fits on Jellyfin via the LG app.
Kuler087
2nd February 2026, 01:51
What's the best way using Dovi_Scripts to triple an rpu.bin? I really need a proper .json with script to triple rpu yet interleaving the metadata evenly throughout. Any help would be appreciated.
The script cannot do that. There might be a way with one of the DEE tools, but I don't know.
Kuler087
2nd February 2026, 01:53
Can anyone point me to instructions on how to convert a 8.6 video to 8.1? Or is this not possible? Tried searching this thread but didn't find anything promising.
8.6 giving me fits on Jellyfin via the LG app.
8.6?
Maybe you meant 7.6 to 8.1?
workflow 4-1 can do that.
prudentavocado
2nd February 2026, 04:31
8.6?
Maybe you meant 7.6 to 8.1?
workflow 4-1 can do that.
I wish, but no, sadly I have a 8.6 file and would like to convert to 8.1.
Any ideas on if plausible or not?
rollmayonnaise
2nd February 2026, 09:42
Thank you for the beta update. DV P5 tonemapped screenshots look great!
May I ask, how have you implemented the FEL brightness expansion detection? Do you rely on metadata alone, only on actual luminance measurements or both? I understand that most FEL titles that expand brightness are ones where the HDR10 BL is tonemapped to 1000 nits and the FEL restores the 4000 nits master. But does FEL brightness expansion happen only when mapping was applied?
I see that you usually show the DV L1 plot in your comparisons to put in evidence that FEL restores the original brightness but what about titles where the DV L1 is a bit "weird". For example, Jack Reacher (2012). For that title, it looks like the DV L1 MaxCLL is capped to 900 nits which is less than the maximum MaxCLL (1454 nits) of the HDR10 BL measured with madVR. In that case, comparing both values would lead to a verdict of no brightness expansion, right? Yet, the screenshot comparison clearly shows a brightness difference which I take this to mean that the actual peak luminance of BL+FEL is higher than maximum MaxCLL of BL and therefore of the maximum DV L1 MaxCLL as well.
Also, for Nosferatu (2024), you mention that FEL expands brightness. So, is this the case here of the HDR10 BL being tonemapped to 600 or 1000 nits? If so, which one? And why is there even a difference between BL and BL+FEL since the movie is so dark?
And on a related note, why does FEL sometimes darken the image, by that I mean, if there is no mapping, what would lead to the residual layer causing darkening? Is it due to a manual adjustment of the BL?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.