Dolby Vision now possible through MP4 Mux.

[RESET_9999]

yes, I always remove cmv4.0 when it doesnt have L8 but has proper L2 trims.
The bluray Wierd Science Is a good example. It's two times brighter in cmv4.0 because the very strong L2 trims are not used.

[speeddemon]

yes, I always remove cmv4.0 when it doesnt have L8 but has proper L2 trims.
The bluray Wierd Science Is a good example. It's two times brighter in cmv4.0 because the very strong L2 trims are not used.

Would you consider maintaining a list on your DoVi Google Sheet of all these rules you follow? I'm up for writing the first draft for you if you want some help.

[RESET_9999]

Well this is where it gets strange, I think only two times i've seen a cmv4.0 with active L8

[deadchip12]

Thanks so much! Apologies, but I am not yet well-read on the CMV4.0 vs CMV2.9 discussion. Is there a reason one would prefer one versus the other? I'm guessing it is more future-proof, but at this time most hardware doesn't support it? Is there a downside to keeping it?

First, most of the movies are done in CMV4.0 but exported in CMV2.9.

CMV4.0 is backward compatible with cmv2.9. The trim passes (100-600-1000nits) are done in the level 8 for cmv4.0 and level 2 for cmv2.9.
When a device and the rpu are CMV4.0, the L2 trims are ignored because it will use the L8 trims which is the proper behavior.

Now the problem is that most of the CMv4.0 movies only have a 100nits L8 trim pass which is obviously not used in DV playback but they do have proper L2 trims that are ignored on cmv4.0 devices (shield/firestick/appletv/internal tv ). So you get inferior quality on those devices unless you remove the CMV4.0 block. The test files (made with original metadata from the movie Puss in boots) show exactly the problem and I bet this is the reason why we do not see a lot of CMV4.0 movies because the colorist has to do the trim passes two times (L8 + L2).

In my script, you can use 2-6 to export the trims to a text file and verify the raw data. So if you use a CMV4.0 devices, you might want to inspect your movies for cmv4.0 metadata (mostly amazon DV and movie anywhere web-dl ) .

Damn this is becoming more and more complicated day by day.
Any guidelines for the sony x700? What do I need to inspect a movie for before I can watch it without any image degradation?

[RESET_9999]

x700 doesnt support cmv4.0 so it doesnt matter

[RESET_9999]

ok, I'm starting to understand what's going on with the different RPU responses on players in TV-LED and in LLDV. It seems the x700/x800m2 almost completely ignores L1 and always tone map to the TV edid target.

For example in TV-LED, with this L1 maxpq test file, it goes from L1 100 nits to 10 000nits and the content is 3132nits.
https://drive.google.com/file/d/1gctmX1 ... drive_link

On the Shield, C2 internal apps and ATV, it's totally clipped at 100nits L1 and it gets to proper brightness with higher L1 values.
On the x700/x800, at L1 100nits , it's already tone mapped to the TV edid( no clipping, proper brightness) and the higher L1 values barely have any effect because it doesn't have to.

The x700/x800 approach might be safer in case of bad DV metadata (static DV) and guaranteed to never clip but this approach will be less accurate when the colorist decides to modify L1 (blend or copy metadata) because for example if the colorist decides to copy a couple of shots together at 400nits and some of these shots/pixels are brighter (1000+), the x700/x800 would respond differently and always tone map to the edid while the shield and C2 internal apps, it would get tone mapped brighter. So even in TV-LED the player has an impact on the TV RPU processing.


All of this is easy to see and quite obvious with the maxpq test file I posted but then it gets a bit more confusing with the color clipping pattern. (still talking about TV-LED)Using this 0-4000nits pattern with L1 set to 100nits, now the x800/shield and C2 internal player behave exactly the same and clip RED/GREEN at 1000nits while the AppleTV RGB are clipped evenly at 1000nits.
https://drive.google.com/file/d/1oxQq0R ... drive_link

In other words in TV-LED, I believe the x700/x800 might be safer for bad metadata and works properly when it needs to but sometimes less accurate when the colorist starts playing with L1.
BTW, I started measuring all the player with different RPU and pattern(TV-LED measurements coming up tomorrow): https://docs.google.com/spreadsheets/d/ ... 1222148710
I really don't understand how Dolby could have implemented DV so differently in all those devices, not a single one behaves the same and the all cmv2.9 devices that can't do true TV-LED are totally broken when the TV edid is higher than the RPU mastering display.

Also, the x700 and x800m2 behave quite differently in LLDV. Strangely the x800m2 LLDV reacts more to L1 like the cmv4.0 devices but behaves differently than in TV-LED using the same target edid.
https://slow.pics/c/P5BmU0ms

[skull88]

Excellent research and testing sir. I have a strong hunch Dolby doesn't care much more beyond signing contracts and getting the license payments from device makers, and cannot really be heavy-handed on forcing the manufacturers of consumer devices to perfectly implement their DV engine SDK or submit QC reports back or do mandatory training etc. They probably prioritize the professional space, or movie theaters that use their name and audio maybe, like doing QC or working closely with high-end digital projector/atmos audio system/maybe AVR manufacturers? As for DoVi, they basically provide pro tools, training/documentation, engine SDK, and perhaps offer to QC and work together on some top-end displays or high-end professional devices/software for major studios or companies (i.e. Resolve), but otherwise just trust the rest like Apple, Nvidia and Sony to implement and ask questions if they notice any weird issues or hear from customer complaints.

I have a hard time believing Apple or Sony would invest a lot of $$ for QC'ing/testing Dolby Vision specifically, even if they have engineers who care about it, especially if they can see it looks fine on all their products (iPad, macBook, Sony TVs internal player/UHD BD player, etc). I'm curious if recent Sony OLED TVs would perform better and have fewer issues paired w/ Sony UHD BD players? Has Sony been supporting the X700/800 with firmware updates to date? At some point, it could also be a case of mismatch between the DV engine implementation on a TV display being "outdated/older" vs. "latest/newer" compared to the device sending the HDMI signal, so could cause bugs? Maybe latest gen LG UHD BD players have fewer issues with LG OLED TVs? Panasonic UHD BD player with Panasonic OLED TVs etc.? You get the idea. Whereas Nvidia Shield is super outdated device for example and I don't imagine Google or Amazon do much testing/if any of how DoVi plays on all kinds of TVs and setups beyond streaming from their own platforms on some average/trash FireTV display, not to mention Samsung has a lot of market share and don't even support DV whatsoever, lol. Basically, it's a shit show, and likely will remain that way, unless Dolby gets into the hardware game or creates a higher "elite" tier for their logo licensing, forcing super high-tier devices to be perfectly QC'd or tested in-house something.

[RESET_9999]

I dont think the way the x700/x800 works in TV-LED is a bug. It just always target the TV edid and never clip, which isn't really a bad thing.
Dolby also recommends NOT touching L1 too much so as long as the L1 metadata are representative of the content, there shouldn't be any difference between shield , atv and sony bd player in TV-LED with cmv2.9 content.

I wish there was a cmv4.0 device capable of lossless audio. Can't stand the Shield stuttering and redpush.
The ATV can't do object-based lossless audio(only pcm) and cmv4.0 seems broken in plex.

[RESET_9999]

mmm. Interestingly, the Windows Movies and TV app has the same red push bug as the Shield. It also has exactly the same blue banding with the ''Multi'' pattern.

mp4 files that works in windows app: https://drive.google.com/drive/folders/ ... drive_link

and this app can play DV in HDR10. Support mkv/ts/mp4 and lossless audio. Also cmv4.0 and L5 and ST P7.. Now that we have two player on windows capable of dynamic metadata, its very easy to compare two sources.
https://apps.microsoft.com/detail/9P9ZH ... n-ms&gl=MS

[speeddemon]

I think I found a huge bug on the x700/ x800m2 / C2, even worse than the red push or the lack of FEL support
The L1 brightness changes are totally different than the C2 internal plex and the Shield(which have newer DV engine) but L2 looks exactly the same on all the devices.
By different I mean they are much much less noticeable on the x700/ x800m2 . like 400% difference, no exaggeration. Even less noticeable than Windows 10 HDR10 P8 playback lol.

If you take the out-of-sync version of the Spears and Munsil clip, because the trim passes are active with L1 at the same time, you can barely see a difference between all the devices.
But if you strip out the trims by generating new metadata with madVR (just L1), then again a big difference in the L1 brightness changes.
Tried MP4 / TS, and it makes no difference.cmv2.9, cmv4.0, old mp4muxer, new mp4muxer.

maybe the newer DV engine of the C2/shield vs the older one from x700/x800m2 cause the issue?
I guess I have to connect my old C8 to find out...

pattern to reproduce:
quietvoid's rpu test: https://drive.google.com/file/d/1hAv4eJ ... sp=sharing
SM clip out of sync original: https://drive.google.com/file/d/1BxsK7- ... sp=sharing
SM clip out of sync no L2 (madvr): https://drive.google.com/file/d/1CuWlHK ... sp=sharing

########################################################################################################################
EDIT: no issue on the C8 + x700/x800m2 vs internal player, L1 changes as pronounced as on the C2/shield.
so it looks like there's something going on when using a CMv2.9 HDMI device to a CMv4.0 TV... Or maybe just something with my C2, I hope people with C1,CX will do the same test
I guess I just lost fel and lossless audio support

bug confirmed on:
LG C2 + x700 + x800m2
LG G2 + oppo: viewtopic.php?p=124746#p124746
LG C1 + x800m2: viewtopic.php?p=124868#p124868
LG C9 + x700: viewtopic.php?p=124959#p124959
Sony X900H + x800m2 https://www.avsforum.com/threads/offici ... t-61832553


videos showing the L1 issue on LG C2:
https://www.youtube.com/watch?v=TJtwu1bwlug

@RESET_9999 apologies for bringing up a post from so long ago.
Is this still a bug?
Does it impact all LG C9 and newer displays when connected to CMv2.9 native players/devices?
Thanks.

[RESET_9999]

I literally gave my latest update on different rpu responses on players like 3 posts ago...

[speeddemon]

I literally gave my latest update on different rpu responses on players like 3 posts ago...

That's why I went searching for that old post... the correlation wasn't clear to me. I'll re-read though and try to understand. Thanks for all your research; I'm just nowhere near your level of understanding.

I guess the part I'm most confused on still is how this relates to the TV. There was some talk earlier in this thread (after your post I quoted) where people were saying these CMv2.9 playback devices wouldn't work with newer TVs. Is that actually the case or is the TV not part of the equation... for example, I use my Oppo UDP-203 right now to compare against with the LG C9... If I were to swap the C9 out for a G3 would the Oppo be effectively useless?

[azreil24]

Thank you for the great tool, sir. Quick question please. I have an MKV which only had HDR10+ for dynamic metadata, for which I used the other tools to turn into DV8. If I use the MODE.H flow, MODE.1 (as I see that MODE.2 which says HDR10plus to DoVi maker, is tagged as Not Recommended), will it use the correct HDR10+ layer to generate a new DoVi or it will also take in consideration the Profile 8 I had in the MKV also?

LE: My first attempt on this and for some reason it couldn't find the files it generated, although they were there while it was processing prior to this step. Not sure what happened.

Removing L2 trims.
Copyright (c) 2013-2023 Dolby Laboratories, Inc. All Rights Reserved
12/31/2023/15:06:55.502000000 metafier: ERROR Unable to open Metadata file 'E:\DoVi.Scripts\temp.folder77\Basterds_DV.xml'
Generate RPU from XML
Parsing XML metadata...
Error: The system cannot find the file specified. (os error 2)
File not found - Basterds_DV.xml
The system cannot find the file specified.
Error: The system cannot find the file specified. (os error 2)
Error: expected value at line 21 column 35
Error: The system cannot find the file specified. (os error 2)
Parsing RPU file...
Error: The system cannot find the file specified. (os error 2)
Press any key to continue . . .
mkvmerge v81.0 ('Milliontown') 64-bit
Error: The type of file 'E:\DoVi.Scripts\Basterds_Generated.hevc' could not be recognized.

[RESET_9999]

That's why I went searching for that old post... the correlation wasn't clear to me. I'll re-read though and try to understand. Thanks for all your research; I'm just nowhere near your level of understanding.

I guess the part I'm most confused on still is how this relates to the TV. There was some talk earlier in this thread (after your post I quoted) where people were saying these CMv2.9 playback devices wouldn't work with newer TVs. Is that actually the case or is the TV not part of the equation... for example, I use my Oppo UDP-203 right now to compare against with the LG C9... If I were to swap the C9 out for a G3 would the Oppo be effectively useless?

It could just be how the cmv2.9 devices were made(chromecast seem different but cant do tv-led), I think they always target the TV edid regardless of L1. I believe the oppo is the same and the rpu reaction difference I mentioned on my old C8 is most likely because the C2 original DV configuration was broken and brightened everything. When they fixed the C2, my C8 was already sold so I couldn't test that anymore.

[RESET_9999]

Thank you for the great tool, sir. Quick question please. I have an MKV which only had HDR10+ for dynamic metadata, for which I used the other tools to turn into DV8. If I use the MODE.H flow, MODE.1 (as I see that MODE.2 which says HDR10plus to DoVi maker, is tagged as Not Recommended), will it use the correct HDR10+ layer to generate a new DoVi or it will also take in consideration the Profile 8 I had in the MKV also?

LE: My first attempt on this and for some reason it couldn't find the files it generated, although they were there while it was processing prior to this step. Not sure what happened.

Workflow 3-2 is not recommended because the HDR10plus average pq metadata are calculated differently. Dolby latest cmv4.0 algo is very conservative(targets 92nits) while HDR10plus is more representative of the brightness and can have much higher values which could result in unexpected tone mapping when you straight convert HDR10plus to DV. see: https://slow.pics/c/WlGwchoE
L1 avg_pq has none to very little effect on 1000nits RPU though but for 4000nits RPU, it does react to avg a lot.


As for 3-1, when you input a file that contains HDR10plus or DV, the script will use only their original scene cuts and generate new proper dv metadata based on those cuts with the latest Dolby algo.
For your error, you did not provide enough information for me to help you. Post the complete log with echo set to on and mediainfo of your input.