Dolby Vision now possible through MP4 Mux.

[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.

[crosis]

What would you recommend as the best way to Mux it to MP4 without losing quality? I know each time you re-encode a video, you lose a little quality. I suppose leaving the quality at CRF-15 in the script then doing my normal Handbrake process wouldn't lose me any noticeable quality. Or would I be able to just use the dovi-baker portion of the script then drop the resulting files into Handbrake? Sorry for all the questions. While I've been running my Plex server and encoding movies for several years, I've never delved quite this deeply into it.

[RESET_9999]

MP4 is just a container, it doesnt change the quality. You can mux to mp4 via CLI or if you're not familiar with CLI, you could mux it to MKV with audio and then run it into the mp4 version of the script in workflow 5.
Or if you don't care about subtitles (you can use external srt though), mux it to TS with "X:\DoVi_Scripts\tools\tsMuxerGUI.exe"
LG TVs play TS DV files just fine, that's the container I use on my C2.

[crosis]

OK, I always knew changing containers shouldn't change the stream but every utility I've looked at for changing to MP4 always seems to want to re-encode the stream. I'll look into the processes you mentioned. I used MKV until the DolbyVision implementation in Handbrake and it was much easier to manipulate with MKVToolnix available. I switched to mp4 for DV because it worked on my C1 and A2s, I have a bunch of family and friends who use my Plex server, and it seems to be the most compatible container. I also have some family who are hard of hearing so subtitles are a must but I have to use external srt because Handbrake will only embed SSA subs which are pretty much useless. I think just using your script in place of handbrake then muxing to mp4 will be my best option so I'll just have to take a look at that and give it a shot.

[crosis]

Any idea what could cause this? Other people have had this issue with avs2pipemod but no one seems to have an answer as to why or how to fix it. I'm going to try a few things. I only have an OS drive and network attached storage. This was on my datadhare coming from my TrueNAS. I know it's not recommended but I'm going to try it on my OS drive to see if I get the same error.

UPDATE: I fixed the issue. Turned out the version of AVISynth linked on the homepage is super old. You have to grab it from GitHub to get a compatible version.

[crosis]

So I have one more question as I don't know the CLI well enough to figure out what is wrong here. All I changed in your script was the CRF setting to 22, the output is about 10GB to 12GB for a 2.5 hr movie. These same movies using my settings from Handbrake with a CRF of 22 ends up at about 3.5GB to 4.5GB and I can't really see any discernable difference. Using the info below, can you tell me what is different that is causing such a huge change in bit-rate and what I can change to get a closer output? As I have family using my server remotely and I have relatively slow upload speed, I try to keep files smaller to keep from buffering. In a worst-case scenario, I guess I can encode with Dovi_Scripts to a very low CRF number to keep as much quality as possible, then re-encode in Handbrake using my normal settings but that will make my encodes take days.

If the settings below are too much to go through, would it be possible to use the commands your script does to get a FEL-baked video file before it goes into x265 that I can then put through Handbrake? Or is this not possible because X265 in combination with AVISynth is what is baking the FEL in?
I have tried running the command below on the files the 8-6-1 workflow created and it just keeps filling the file up until space runs out. If this does work using a variation on what I've tried, you can disregard all the settings I pasted below and just give me that command:
avs2pipemod64.exe -y4mp script.avs > output.hevc




Encoding Log settings image Left is Handbrake log, Right is active encode using Dovi_Scripts:


Here is what mediaInfo shows for the encoder settings for a file from DoviScripts and one from HandBrake (Not the same file so frame counts are different). I unfortunately can't get the command that Handbrake passed to x265 anywhere that I can find. I have no idea what here is default vs things that need entered into the CLI.

HandBrake
cpuid=1111039 / frame-threads=3 / numa-pools=12 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x2076 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / repeat-headers / annexb / aud / no-eob / no-eos / hrd / info / hash=0 / temporal-layers=0 / open-gop / min-keyint=24 / keyint=240 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=25 / lookahead-slices=4 / scenecut=40 / no-hist-scenecut / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=4 / selective-sao=4 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=22.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=25600 / vbv-bufsize=25600 / vbv-init=0.9 / min-vbv-fullness=50.0 / max-vbv-fullness=80.0 / crf-max=0.0 / crf-min=0.0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=9 / transfer=16 / colormatrix=9 / chromaloc=1 / chromaloc-top=2 / chromaloc-bottom=2 / display-window=0 / master-display=G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,1) / cll=1000,206 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / hdr10 / hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass / no-mcstf / no-sbrc

DoviScripts
cpuid=1111039 / frame-threads=3 / numa-pools=12 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x1608 / interlace=0 / total-frames=243552 / level-idc=51 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / repeat-headers / annexb / aud / no-eob / no-eos / hrd / info / hash=0 / temporal-layers=0 / no-open-gop / min-keyint=23 / keyint=250 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=25 / lookahead-slices=4 / scenecut=40 / no-hist-scenecut / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=-3:-3 / no-sao / no-sao-non-deblock / rd=4 / selective-sao=0 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=22.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=160000 / vbv-bufsize=160000 / vbv-init=0.9 / min-vbv-fullness=50.0 / max-vbv-fullness=80.0 / crf-max=0.0 / crf-min=0.0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=9 / transfer=16 / colormatrix=9 / chromaloc=1 / chromaloc-top=2 / chromaloc-bottom=2 / display-window=0 / master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1) / cll=1483,102 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / hdr10 / hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass / no-mcstf / no-sbrc