Dolby Vision now possible through MP4 Mux.

[isabido]

Yes makemkv does ST-DL but also mkvtoolnix which was updated recently to do that.
original iso/m2ts are always DTDL

I used your fabulous script with the options:

4) MODE.7= DoVi Profile 7 Input (MKV/BDMV)
1) MODE.1= Bluray Disc to Single-Layer P8 or Single-Track P7
2) Workflow.2= Dual-Track Dual-Layer Profile 7 to Dual-Layer Single-Track

You can see the result in https://pastebin.pl/view/0997bf81

Is the result of this script the same as doing it with MakeMKV?
How can I verify that the file is an STDL?

Thanks!!

[HotFudge]

yes but you must have the HDR10 BL. You cant transform a P5 file to P8 without it(without re-encoding).

Cheers mate

[RESET_9999]

You can see the result in https://pastebin.pl/view/0997bf81

Is the result of this script the same as doing it with MakeMKV?
How can I verify that the file is an STDL?

Thanks!!

Yes but for now my script will be much slower than makemkv because I use the dovi_tool which cannot mux directly to MKV obviously.
In the next version, it will be as fast as makemkv because the script will use mkvtoolnix directly.
But unless you want to encode DDP audio, you don't need my script for that and you should just use mkvtoolnix directly with the mpls file.

[isabido]

You can see the result in https://pastebin.pl/view/0997bf81

Is the result of this script the same as doing it with MakeMKV?
How can I verify that the file is an STDL?

Thanks!!

Yes but for now my script will be much slower than makemkv because I use the dovi_tool which cannot mux directly to MKV obviously.
In the next version, it will be as fast as makemkv because the script will use mkvtoolnix directly.
But unless you want to encode DDP audio, you don't need my script for that and you should just use mkvtoolnix directly with the mpls file.

Thanks for the recommendation, in this case it is easier for me to use makeMKV because I can even eliminate the audio tracks/subtitles that do not interest me.

Even so, your scripts are very interesting to convert to P8.

Even so, I insist, how could I identify if a file is in STDL or DTDL?

[HotFudge]

yes but you must have the HDR10 BL. You cant transform a P5 file to P8 without it(without re-encoding).

Hello

is workflow 1 then 1 good for converting a P7 MEL like Alita to P8.


Cheers

[RESET_9999]

Even so, I insist, how could I identify if a file is in STDL or DTDL?

DT as the name says, will have two videos tracks (2160p +1080p)

yes but you must have the HDR10 BL. You cant transform a P5 file to P8 without it(without re-encoding).

is workflow 1 then 1 good for converting a P7 MEL like Alita to P8.

workflow 4-2 for P7 mkv rip input
workflow 4-1-1 for BDMV disc input

[HotFudge]

yes but you must have the HDR10 BL. You cant transform a P5 file to P8 without it(without re-encoding).

is workflow 1 then 1 good for converting a P7 MEL like Alita to P8.

workflow 4-2 for P7 mkv rip input
workflow 4-1-1 for BDMV disc input
[/quote]

Cheers buddy !

[jayper]

Just got the new AppleTV. Anyone using Infuse? Noticed that cm4.0 files fallback to HDR10, going to update a few to cm2.9, but wondering if anyone has any idea of proper cm4.0 support coming?

Also, what settings do I need to update to ensure I get the correct Dolby Vision behavior? Should the Vision settings be limited or Auto?

Thanks

[RESET_9999]

Hi mate, I don't if you still read this thread...
I think I know what's going on with the old LLDV sony TVs. They have a wrong Edid brightness over 1000nits and Dolby vision is designed to ignore the L2 trims when the edid is higher than the rpu mastering display.
For example, this is the edid of the Sony A1 (2017):

Vendor-Specific Video Data Block (Dolby), OUI 00-D0-46:
Version: 2 (12 bytes)
Supports YUV422 12 bit
DM Version: 3.x
Backlt Min Luma: 100 cd/m^2
Interface: Low-Latency
Supports 10b 12b 444: Not supported
Target Min PQ v2: 0 (0.00000000 cd/m^2)
Target Max PQ v2: 3225 (1387 cd/m^2)

This TV, according to rtings can do only 800nits so that edid doesn't make sense and its the reason why L2 is ignored and L1 is applied inaccurately..
see: https://www.youtube.com/watch?v=29ed65Aq5K0

Solution:
Change the edid to 800nits.
EDID: https://mega.nz/folder/JfdhkIZR#ES6Ba86_fsYI_roF0g0bUQ

Ok more info about this. It seems that this is another LLDV bug because I just tried a 1600nits edid (sony A95) in TV-LED and the trims are working with the 1000nits rpu test file.
This bug(l2 ignored) also affects the devices (chromecast/ firetv) that do fake TV-LED. Also present on the latest ATV in LLDV.

Vendor-Specific Video Data Block (Dolby), OUI 00-D0-46:
Version: 2 (12 bytes)
DM Version: 4.x
Backlt Min Luma: 100 cd/m^2
Interface: Standard + Low-Latency
Supports 10b 12b 444: Not supported
Target Min PQ v2: 0 (0.00000000 cd/m^2)
Target Max PQ v2: 3290 (1604 cd/m^2)
Unique Rx, Ry: 0.70703125, 0.29296875
Unique Gx, Gy: 0.17187500, 0.79687500
Unique Bx, By: 0.13281250, 0.04687500

IMO it makes a lot more sense that the trims always work regardless of the edid but it also means that any brighter tv (1000+) will be wrong when using the firetv, chromecast, zidoo or any device that cant do true TV-LED when the RPU is 1000nits with trims.

[crosis]

It was a happy discovery a few days ago when I updated Handbrake and saw my next rip pop up as DV in Plex. So, I've just started re-ripping all my UHD rips to get everything to DV p8 in my Plex library. Took me a few days to figure outy I needed MP4s for my LG TVs to trigger DV. The one thing I'm trying to figure out now, as I am having information overload learning the basics of DolbyVision is:

Now that Handbrake is able to convert a p7 file to p8, is it baking in the EL or is that something I need to do myself prior to encoding and compressing?

I'm hoping it is baking it in because the tutorial to do it is pretty difficult to find in this nearly 700 page thread LOL. To that end, in the case that it is not baking it in, can someone point me in the direction of the easiest and most up to date tutorial for that process? Preferably a scripted process as I've heard that one is available, made by one of you gurus. Also, As it stands I've only re-encoded 8 movies that I don't believe require the FEL to display properly so I don't think I'll need to re-encode them if it is going to be a process external to Handbrake. Though here are the ones I've done in case anyone can tell me otherwise:

1.) Alita Battle Angel (2019)
2.) AquaMan (2019)
3.) Black Panther (2018)
4.) Bullet Train (2022)
5.) Despicable Me 3 (2017)
6.) DragonBall Super Super Hero (2023)
7.) Dungeons and Dragons (2023)
8.) The Flash (2023)

[RESET_9999]

Preferably a scripted process as I've heard that one is available

No idea about handbrake but the script in my signature can bake FEL to P8. Workflow 8-6-1 but it requires an nvidia GPU.
it can also encode P5 to P8, HLG to HDR10 or P8 to P8

[crosis]

Thank you for that info Reset_9999. I have an RTX 4070 TI so the GPU is definitely not an issue. I have posted the question in the Handbrake forums as to whether it is baking the FEL. I also referenced your scripts to them to see if they can add the functionality in the case that it is not already doing it.

Just to be sure I don't waste my time encoding videos multiple times, I also wanted to ask if there is any reason to bake the FEL on all movies or is it only going to make a difference on movies listed in this sheet?
https://docs.google.com/spreadsheets/d/ ... =427220017

If it's only the movies in the sheet, that's a relief because I only have about 10 of the movies on there.

Thanks again for any info on this!

[skull88]

Thank you for that info Reset_9999. I have an RTX 4070 TI so the GPU is definitely not an issue. I have posted the question in the Handbrake forums as to whether it is baking the FEL. I also referenced your scripts to them to see if they can add the functionality in the case that it is not already doing it.

Just to be sure I don't waste my time encoding videos multiple times, I also wanted to ask if there is any reason to bake the FEL on all movies or is it only going to make a difference on movies listed in this sheet?
https://docs.google.com/spreadsheets/d/ ... =427220017

If it's only the movies in the sheet, that's a relief because I only have about 10 of the movies on there.

Thanks again for any info on this!

FEL basically always does something, whether it's fixing up details/grain/edges/compression artifacts or as noted on the spreadsheet, changing brightness of the image. It is debatable if you'd be able to notice the former in motion and if it's worth the extra encoding time, but obviously, you should bake in if it's the latter, with brightness changes. Your call.

[crosis]

Well, my current process is to rip using MakeMKV, then I encode the file to MP4 using Handbrake with pretty much automatic settings on CRF 22-24 targeting a roughly 3.5GB/hr max size for the movie. Can I just use Reset_9999's script in place of Handbrake for the same functionality until I get an answer from them on whether they are also baking it in? I haven't messed with the individual command switches, I've always just let Handbrake do it's thing and it's worked so far. My settings are pictured below:

[RESET_9999]

by default, the script uses CRF-15 at slow preset with some custom CLI.
You can edit the x265_HDR_settings.bat (tools folder) and change it to your CRF 22-24 and it should produce a similar file size to your current handbrake workflow.

PS: The encoding scripts dont mux to mp4/mkv/ts though. you'll get an encoded HEVC DV file that you have to mux manually.