Dolby Vision now possible through MP4 Mux.

[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

[deadchip12]

Are the Oppo 203 (now discontinued and sold online for nearly $1000), the Sony x700 and the Sony x800m2 the only bluray players on the planet that are capable of playing all types of dolby vision file? If so that's pretty crazy.

[RESET_9999]

So I have one more question

I'm not an encoder expert but FEL will increase the bitrate for sure and you can try to match the buffer to your handbrake settings.
the script: vbv-maxrate=160000 / vbv-bufsize=160000
your cli: vbv-maxrate=25600 / vbv-bufsize=25600

PS: FF RW is most likely be buggy with the mp4 container using your handbrake settings though. TVs don't like open GOP encodes

Are the Oppo 203 (now discontinued and sold online for nearly $1000), the Sony x700 and the Sony x800m2 the only bluray players on the planet that are capable of playing all types of dolby vision file? If so that's pretty crazy.

pretty much but I just found something concerning about our beloved x700/x800 with low nits real content Five.Nights.at.Freddys.2023 : https://slow.pics/c/R0A9O244
according to the original brightness and metadata plot(L1 L2), only the Shield makes sense here.

[darrrkmanxxx]

Hey guys, it's been a long time I've visited this thread. About a year ago I've decided to leave/mux everything to profile 8 in mkv as this has the most compatibility on my Philips TV 65OLED934 (2019). There were times where Plex would let me play single-layer profile 7, but plex patched that out a while ago.
For all of the characteristics the Philips Android TV is very similar to the Sony Bravia A8H from the sheet.
However, I've recently tried to watch some content on an LG G3 and noticed that it wouldn't play DV Profile 8 in mkv, this is the command I've used to mux the content to mp4:

Code: Select all

ffmpeg -i input.mkv -map 0 -c copy -strict unofficial -c:s mov_text output.mp4

[deadchip12]

pretty much but I just found something concerning about our beloved x700/x800 with low nits real content Five.Nights.at.Freddys.2023 : https://slow.pics/c/R0A9O244
according to the original brightness and metadata plot(L1 L2), only the Shield makes sense here.

Sorry could you explain what the screenshot indicates?
And do the current issues with the x700/x800 only happen with dolby vision files but not dolby vision discs?

[RESET_9999]

Sorry could you explain what the screenshot indicates?
And do the current issues with the x700/x800 only happen with dolby vision files but not dolby vision discs?

Reference: original HDR frame is 92 nits , Edid is LG C2 (896nits). L2 trims is a positive lift (brighten), L1 is 100nits

x700 L1 + L2 original is 82nits (darker than HDR10, doesn't make sense)
x700 L1 only is 66nits (much darker than HDR10, doesn't make sense)
ATV L1 + L2 original is 93nits (trims bring the brightness to the original level)
ATV L1 only is 76nits (darker than HDR10, doesn't make sense)
Shield L1 + L2 original is 114nits (expected brightness for this type of L2 lift)
Shield L1 only is 94nits (same as original brightness. expected for a 100nits L1 on a 896nits TV)

Only the Shield seems logical here.

plots (shot is around frame 1200 IIRC)

[HotFudge]

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

When will 1.9.8.6 be released? Github latest version is 1.9.8.5

Cheers

[RESET_9999]

When will 1.9.8.6 be released? Github latest version is 1.9.8.5
Cheers

idk, I haven't made enough changes yet.

- Added PGS/SUP to srt (auto OCR) (line 80 default = NO)
- Added an option to compare SDR in an HDR container for workflow 7-2 (line 132 default=NO)
- Added an option to force mp4box_2 (line 16 default=NO)
- Tools: Subtitle.edit must be added in the tools folder. (only needed if line 80 = YES)
- Tools: mkvtoolnix files must be updated to the latest version.

[RESET_9999]

Windows Movies and TV app support Level 5 surprisingly (and also cmv4.0). Only HDMI device to support L5 so far.

[crosis]

When will 1.9.8.6 be released? Github latest version is 1.9.8.5
Cheers

idk, I haven't made enough changes yet.

- Added PGS/SUP to srt (auto OCR) (line 80 default = NO)
- Added an option to compare SDR in an HDR container for workflow 7-2 (line 132 default=NO)
- Added an option to force mp4box_2 (line 16 default=NO)
- Tools: Subtitle.edit must be added in the tools folder. (only needed if line 80 = YES)
- Tools: mkvtoolnix files must be updated to the latest version.

I wanted to thank you for the help with your script. I have adjusted the encoder settings and arrived at bitrates very close to what I was getting in Handbrake. On the next update, would you be able to add an option in your workflow to choose a subtitle track to burn into the video? I always burn any forced subtitles so that I don't need to mess with OCR-ing and organizing multiple subtitle files. I am currently looking into AVISynth plugin "SupTitle" to manually add to the avs script before it kicks it over to X265.