Dolby Vision now possible through MP4 Mux.

[RESET_9999]

For movies with neither a Dolby Vision track nor HDR10+ metadata to convert, how much of a difference am I likely to notice on an LG C1 between auto-generating shot-by-shot metadata versus just playing it back with static metadata? Is it more likely to make a difference in a brighter room (so Dolby Vision IQ can do its thing) than a fully dark room?

Finally, is there any way to generate shot-by-shot metadata on Linux, or do I have to use the madMeasureHDR.exe program under Windows?

Thanks.

HDR10 with madvr-generated DV is certainly better than just static HDR10. You will notice a difference, especially with bright content.
I dont know about Linux.

[Manixx2020beyound]

I just made a profile 5 doblyvision encode (now-possible) encoded on a pc
This test was made from a hdr10 base layer.
And it works on apple tv
I’ll wait for reset9999 to compare

My p5 are triggering doblyvision on the pc app. This is unbelievable
BE470269-B01B-4DDD-8390-DACFC8FC4F8D.png

[rophel]

@RESET_9999 Thanks for the quick reply!

Another issue (and I've spent time searching the forum via Google so sorry if this has been covered):

When I do WEB-DL only hybrids i.e. both DV and HDR are from WEB-DLs, with most films I get audio that is wildly out of sync. TV shows have no issues, strangely. Source files are MKVs, I use the hybrid maker script, then mux the resulting hevc file with the HDR file's audio and subs using mkvtoolnix gui.

I saw some mention of trying better release groups, but has anyone had any success in resolving this? I am using two files from the same release group and confirm exact same length via jumping to specific frames, etc.

I tried some various things, using TSMuxer to turn the end MKV into a TS seemed to get the audio only a second or so off...while the MKV was WILDLY off. So odd.

[Manixx2020beyound]

Here is a p5 sample for u guys to test
This was encoded using doblyvision encoding engine & h265, RPU is a true P5 even l4 included
Source file spares & munsil m2ts untouched Mel.

Test on Apple TV’s
https://drive.google.com/file/d/1476mVd ... sp=sharing

[NiCE77]

Here is a p5 sample for u guys to test
This was encoded using doblyvision encoding engine & h265, RPU is a true P5 even l4 included
Source file spares & munsil m2ts untouched Mel.

Test on Apple TV’s

https://drive.google.com/file/d/14VpI6o ... p=drivesdk

Thanks, I will try tonight. Maybe you could make a mov file from the recently linked P8.4 L2 test file?

[ragico]

Here is a p5 sample for u guys to test
This was encoded using doblyvision encoding engine & h265, RPU is a true P5 even l4 included
Source file spares & munsil m2ts untouched Mel.

Test on Apple TV’s

https://drive.google.com/file/d/14VpI6o ... p=drivesdk

Thank you. Tested on ATV 4k works perfectly via Infuse but no audio.
Also for a couple of secs woksr on plex app before a message appears on the screen, plex complaining the network speed is too low (it is wired gigabit).

[RESET_9999]

Except that it is not a true P7/P8 to P5 conversion. It is newly generated metadata and all the artistic trims are gone. Basically the same as generating DV from madvr.
In order to get the same DV, the dovi_tool would need to be able to convert RPU to XML (same structure as resolve XML). Then we could import the metadata in resolve and encode it to P5.


Will be useful to convert all my HDR10 patterns to Profile 5 though.

[stn17]

For movies with neither a Dolby Vision track nor HDR10+ metadata to convert, how much of a difference am I likely to notice on an LG C1 between auto-generating shot-by-shot metadata versus just playing it back with static metadata? Is it more likely to make a difference in a brighter room (so Dolby Vision IQ can do its thing) than a fully dark room?

It would heavily depend on a file.

Not everybody fills full static metadata, some are using incorrect metadata that ruins tone mapping for OLED tvs without good DTM (LG)

For example, iTunes, ATV and Disney content (including disks) contains MaxCLL value way above what you can actually see in the actual movie. And if it goes above your TV's maximum brightness it will skew the EOTF target and increase brightness roll off. So 500 nits image will be presented in 350 nits. Warner brothers does the same stupid shit, when their logo is about 900 nits bright and the entire movie is 150-200 nits MaxFALL.

Famously, new Spider-Man has MaxCLL of 10000 nits even though it was graded on Sony OLED with maximum brightness of 1000 nits. It also scales up MaxFALL value so it messess up all the tone mapping in the film. Thankfully most of those fucked up movies come with Dolby Vision.

Now in this particular example, if the movie is only available in HDR10 (like Batman v Superman) MadVR DV would help alot as it will allow your TV work to its best potential and it will exclude that one 10000 nits frame from everything else in the content.

[Manixx2020beyound]

Except that it is not a true P7/P8 to P5 conversion. It is newly generated metadata and all the artistic trims are gone. Basically the same as generating DV from madvr.
In order to get the same DV, the dovi_tool would need to be able to convert RPU to XML (same structure as resolve XML). Then we could import the metadata in resolve and encode it to P5.


Will be useful to convert all my HDR10 patterns to Profile 5 though.

Also a p5 encoded from a master MxF that already has been made with Dolbyvision meta retains all the artistic intent in the conversion to p5 tested that as well.
Yep Rpu to xml would put the icing on the cake..

[RESET_9999]

So @manix converted the "mutli pattern" to profile 5 and as expected, no more colorspace conversion/clipping issues on the Shield. No blue banding as well.

We discovered something else, something quite big. The DV 8.1 MP4 encoded directly from Resolve doesn't have the famous color issue bug on the Shield!!!! what the hell!!!
So it means there is something in quietvoid/yusesope/makemkv DV remuxing that the Shield doesnt like at all... Strange though that only the Shield seem to be affected.

no color issues:
P5 pattern : https://drive.google.com/file/d/1gFrasF ... sp=sharing
P8.1 pattern (DV MP4 straight from resolve) : https://drive.google.com/file/d/1fCjcMH ... sp=sharing

color issues:
P8.1 pattern (dovi_tool XML from resolve) :https://drive.google.com/file/d/1Aq3v03 ... sp=sharing
P8.1 pattern (dovi_tool madvr) : https://drive.google.com/file/d/1NbXM2p ... sp=sharing


We are going to make a P8.1 of Doctor Sleep in resolve, I bet there's no more red push...

[mtotheb]

This has to be one of the biggest news in this thread in a while. Hopefully the difference can be reverse engineered (looks hopeful at @quietvoid). I really thought we’d need to wait for a complete new SoC to maybe one day get DV (at least MEL)+Passthrough Audio in a device to simply stream like the Shield.

[quietvoid]

We discovered something else, something quite big. The DV 8.1 MP4 encoded directly from Resolve doesn't have the famous color issue bug on the Shield!!!! what the hell!!!
So it means there is something in quietvoid/yusesope/makemkv DV remuxing that the Shield doesnt like at all... Strange though that only the Shield seem to be affected.

The encoded files aren't comparable.
Resolve: BT.2020 mastering display, 10000/256 CLL, chroma location center.
Other: DCI-P3 mastering display, 1000/400 CLL, chroma location top-left.

And in the RPU, L6 and L9 are different (Resolve matches BT.2020 primaries, dovi_tool uses DCI-P3 by default).
I doubt L11 makes a difference unless the display supports CM v4.x.
Finally, Resolve doesn't support shot based metadata, so every frame carries "scene_refresh_flag": 1.

Those should obviously be matched first before jumping to conclusions.
MakeMKV shouldn't be doing anything different, as the source isn't modified.

Also, these MP4 files are missing the proper compatibility ID for 8.1.

After that, what you can try:
- Adding a default 100 nits L2 trim
- Copying the L3
- Copying the L4

[RESET_9999]

We discovered something else, something quite big. The DV 8.1 MP4 encoded directly from Resolve doesn't have the famous color issue bug on the Shield!!!! what the hell!!!
So it means there is something in quietvoid/yusesope/makemkv DV remuxing that the Shield doesnt like at all... Strange though that only the Shield seem to be affected.

The encoded files aren't comparable.
Resolve: BT.2020 mastering display, 10000/256 CLL, chroma location center.
Other: DCI-P3 mastering display, 1000/400 CLL, chroma location top-left.

And in the RPU, L6 and L9 are different (Resolve matches BT.2020 primaries, dovi_tool uses DCI-P3 by default).
I doubt L11 makes a difference unless the display supports CM v4.x.
Finally, Resolve doesn't support shot based metadata, so every frame carries "scene_refresh_flag": 1.

Those should obviously be matched first before jumping to conclusions.
MakeMKV shouldn't be doing anything different, as the source isn't modified.

Also, these MP4 files are missing the proper compatibility ID for 8.1.

the spears and munsill pattern is encoded with maxcll/fall 1000/400 but resolve and madvr measure it 10 000nits
Resolve automatically calculated a new maxcll/fall at delivery, same for L6. It defaults to chroma type 1 as well, i dont think we can change that.

I'll match the color primaries for the 2nd clip but i doubt it will make any difference. As for L9 i dont know.

Also, these MP4 files are missing the proper compatibility ID for 8.1.

correct me if i am wrong but I use the first version of the mp4muxer (because the newest one doesnt work) and --dv-bl-compatible-id 1 doesnt work. ( i think it was added later)

[quietvoid]

I'll match the color primaries for the 2nd clip but i doubt it will make any difference. As for L9 i dont know.

L9 needs to be matched too.

correct me if i am wrong but I use the first version of the mp4muxer (because the newest one doesnt work) and --dv-bl-compatible-id 1 doesnt work. ( i think it was added later)

I think the latest version of mp4muxer doesn't work only on LG TV internal player?
So you can use latest version for the Shield, or tsmuxer.

If I can find time I'll try reencoding the pattern with my suggestions.
Maybe this weekend.

[RESET_9999]

If I can find time I'll try reencoding the pattern with my suggestions.

thanks , that would be great because i have no idea how to do L3,L4