Dolby Vision now possible through MP4 Mux.

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

[RESET_9999]

Ha, if I measure it in resolve instead, now it's closer to yours and almost identical to the original P7. So something is wrong with madvr measurement for this file, somehow. strange stuff...

https://slow.pics/c/GdrYzfzM

[quietvoid]

how did you measure it ?

I use my own script in VapourSynth.