Dolby Vision now possible through MP4 Mux.

[RESET_9999]

Thank you for the deep explanation. So in your script, I should change "Choose if you want to remove the 600 and 1000nits L2 trim pass" to "YES", right?

If you have access to the Dolby Metafier, yes. If you don't, you can set the script to just overwrite all the trims. This is how the script is set by default.

::choose if you want to overwrite L2 trims to 2048(no effect) for the XML to RPU conversion (YES or NO default = YES).
set drop.L2=YES
::Choose if you want to remove the 600 and 1000nits L2 trim pass. in other words, do you want to keep the L2 100nits trim (only valid for 1-1 and xml input) (require the dolby metafier and this option override: ''set drop.L2=YES'') (default=NO)
set rem_600_1000=NO

You’re right, I’ve mixed it up with "L1 low contrast

The L1 problem with the x800m2/x700 seem to be with low nits contents (under 1000nits). It's almost like the player knows the content is within the TV capabilities and decides to ignore L1 while the other devices(shield c2 internal,firestick) just apply the L1 metadata regardless of the content brightness.

L2 offset 0.75" problem

That is actually a much bigger problem. I did more tests about it and it turns out, any value over 2048 for trim offset has no effect in TV-LED mode on X700 x800m2 and Shield and most likely all the true TV-LED devices
If you force LLDV, then it's working properly.

This a bigger problem than the LLDV bug because Trim offset is used a lot more often in movies than Trim Chroma weight (lldv issue). By default the Dolby algo does not touch to Chroma Weight, it has to come from the colorist but Trim offset on the other hand, it's calculated automatically by the algo. FYI, values over 2048 make the image brighter. Trim offset test file: https://drive.google.com/file/d/1JrU6JX ... drive_link
difference with quietvoid L2 test file: https://www.avsforum.com/threads/pictur ... t-62609139


Example of movie with active trim offset with positive lift:

[TheEqualizer]

first, you have to find the frame difference between the two videos. Personally, I use MPC-BE and find the same frame for both videos, press ''control-g'' and calculate the frame number difference. You can navigate frame by frame with ''control left/right arrow'' when the video is paused.

then the framecount of both rpu and hdr10 video must match. so you calculate how many frames you have to remove or add at the end of the rpu. (include the frame you added or removed from the start of the rpu) ... just math at this point.

EDIT: it is no more needed to calculate the framecount since the latest update. You only need to calculate the frame difference so the rpu is in sync with the bluray remux.

Good afternoon, I want to clarify once and for all for myself, in cases where dv has fewer frames than hdr, for example
hdr=185248
dv=185200
.json will look like (please write here an example with numbers)
Conversely, when DV has more frames than HDR, for example
HDR=185200
DV=185248
.json will look like (please write an example with numbers here). Thank you in advance!

[RESET_9999]

why do you want to manually create JSON for that when the dovi_tool will do it for you?
anyway, you have all the json examples on the dovi tool github

https://github.com/quietvoid/dovi_tool/ ... r_examples

[TheEqualizer]

why do you want to manually create JSON for that when the dovi_tool will do it for you?
anyway, you have all the json examples on the dovi tool github

https://github.com/quietvoid/dovi_tool/ ... r_examples

I don't want to do everything by hand! I was in this github directory, but due to not knowing English and using a translator, maybe I misunderstood somewhere. How dovi_tools do everything for me? Clarify please! When introducing rpu into hdr at the final stage, I see a warning about a different number of frames, respectively, I understand that you need to manually align them, if you remove the extra ones it’s easier and clearer, then adding the missing ones is not very clear the whole process, that’s why I asked for an example json file code with specific figures for clarity. If I'm doing something wrong, explain again the procedure, maybe the script can do it all and there is no need for manual adjustment

[RESET_9999]

If your sources are already in sync, you dont have to worry about the framecount mismatch at the end and the dovi_tool will duplicate or remove the right amount of frames automatically.
If your sources are not in sync, you have to find the frame difference and then input the difference in the script (1-1).
You cant calculate the frame difference just by looking at the frame count of both sources.

[TheEqualizer]

If your sources are already in sync, you dont have to worry about the framecount mismatch at the end and the dovi_tool will duplicate or remove the right amount of frames automatically.
If your sources are not in sync, you have to find the frame difference and then input the difference in the script (1-1).
You cant calculate the frame difference just by looking at the frame count of both sources.

Thanks, it's much clearer now

[hjkl1234]

it looks like your path to the tool ''jq.exe'' is not right or missing.

here's the folder for all the tools:
https://drive.google.com/file/d/1qavvq_ ... sp=sharing

Could you reupload the tools? I've been searching everywhere but I couldn't find the Tools and I tried to install all the necessary files from the tools_readme.txt but some of them were missing and I don't know how exactly some repos needed to be in the folder.

Would be great if you can send it to me.

[speeddemon]

Thanks, but I found this comment: https://github.com/erazortt/DoViBaker/i ... 1259843741
So the result will not be good if we inject the RPU because double processing. But then I don't really understand what this tool is for?

Reinjecting the *original* RPU is wrong. When converted to profile 8.1 it is fine.
As long as you don't tonemap using the trims in DoViBaker.

DoViBaker uses the mapping metadata and NLQ metadata to reconstruct the FEL image.
All this metadata is removed by profile 8.1 conversion (for FEL).

Would it be possible to have a version of DoVi_Scripts someday that uses DoViBaker and dovi_tool to reconstruct the FEL image and output a correct P8.1 file?
@quietvoid & @RESET_9999 have either of you considered teaming up with erazortt to do this?
Thanks!

[quietvoid]

Would it be possible to have a version of DoVi_Scripts someday that uses DoViBaker and dovi_tool to reconstruct the FEL image and output a correct P8.1 file?
@quietvoid & @RESET_9999 have either of you considered teaming up with erazortt to do this?
Thanks!

The output wouldn't be easily playable if it sticks to lossless encoding, as the files would be huge.
And there are too many variables when reencoding lossy, so it's probably not worth it.

[RESET_9999]

The output wouldn't be easily playable if it sticks to lossless encoding, as the files would be huge.
And there are too many variables when reencoding lossy, so it's probably not worth it.

What did you use to convert the 16-bit RGB to YUV 10-bit without messing up the colors in the Rise of Gru P8(fel baked)sample?
Anything I tried in ffmpeg, I got a slight color shift compared to your sample: https://slow.pics/c/TiRTLS4F

I get quite different brightness reading as well: https://slow.pics/c/XQ7krMSf

[quietvoid]

What did you use to convert the 16-bit RGB to YUV 10-bit without messing up the colors in the Rise of Gru P8(fel baked)sample?
Anything I tried in ffmpeg, I got a slight color shift compared to your sample: https://slow.pics/c/TiRTLS4F

I get quite different brightness reading as well: https://slow.pics/c/XQ7krMSf

I didn't use DoViBaker, but you're supposed to specify 2020ncl for the target matrix when converting to YUV.

[danbez]

What did you use to convert the 16-bit RGB to YUV 10-bit without messing up the colors in the Rise of Gru P8(fel baked)sample?
Anything I tried in ffmpeg, I got a slight color shift compared to your sample: https://slow.pics/c/TiRTLS4F

I get quite different brightness reading as well: https://slow.pics/c/XQ7krMSf

I didn't use DoViBaker, but you're supposed to specify 2020ncl for the target matrix when converting to YUV.

I did a few DoViBaker conversions just to test the results. I used the command line below:
ffmpeg -i "example.avs" -x265-params "crf=14:hdr10-opt=1:chromaloc=2:range=limited:output-depth=10:profile=main10:level-idc=5.1:colorprim=bt2020:colormatrix=bt2020nc:transfer=smpte2084:hdr10=1:max-cll=0,0:master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" "out10.hevc"

While I liked the results, I'm happy to get feedback on what can be improved.

[RESET_9999]

I use this cli...

%ffmpeg_path% -i "%filepath%%filename%.avs" -preset %preset% -x265-params crf=%crf%:repeat-headers=1:sar=1:hrd=1:hdr10-opt=1:aud=1:open-gop=0:hdr10=1:sao=0:rect=0:cutree=0:deblock=-3-3:strong-intra-smoothing=0:chromaloc=2:aq-mode=2:colorprim=bt2020:colormatrix=bt2020nc:transfer=smpte2084:vbv-maxrate=160000:vbv-bufsize=160000:max-luma=1023:max-cll=%maxcll_path%,%maxfall_path%:master-display=%MDP%WP(15635,16450)L(%max_pq%0000,%min_pq%) -pix_fmt yuv420p10le -y "%output_path%%filename%_HDR10.hevc"

What i dont understand is the hdr measurement difference. The avg_pq of "quietvoid sample is quite different than the original P7 rpu while the one created by this cmd is almost the same as the original.

[quietvoid]

What i dont understand is the hdr measurement difference. The avg_pq of "quietvoid sample is quite different than the original P7 rpu while the one created by this cmd is almost the same as the original.

Your measurements are off somehow. This is what I get from measuring my profile 8.1 encode: https://0x0.st/HQ26.png
And with the same scenes as original: https://0x0.st/HQ2l.png

[RESET_9999]

Your measurements are off somehow. This is what I get from measuring my profile 8.1 encode: https://0x0.st/HQ26.png
And with the same scenes as original: https://0x0.st/HQ2l.png

that is strange. I used madvr...
I figured out the color shift though. It needed ConvertToYUV420(matrix="2020") in the avs script. And now madvr read the avg_pq just like your original p8 sample

how did you measure it ?