www.makemkv.com

Posted: **Sat Dec 23, 2023 4:06 am**

Has anyone figured out why CM_Analyze gets so slow sometimes?

Posted: **Sat Dec 23, 2023 2:06 pm**

RESET_9999 wrote: Tue Oct 10, 2023 11:15 am btw, I got a response from Dolby about the Cm_analyze.exe slow performance:

Our Professional Tools make use of Apple’s ProRes decoding library and we have identified performance bugs, including lack of GPU accelerated decoding on Windows and Linux, and a severe performance hit when running on some AMD chips, including their high-performance scalable EPYC chips.

Unfortunately, we are dependent on Apple updating their ProRes libraries to get this fixed.
Until we get an update from Apple, the only recommendation we can offer is to use JPEG2000 which has full GPU decoding support.

I'm sorry I can't give you any better news.
Let me know if there's anything else we can support with.

Thanks,

Michael

Posted: **Sun Dec 24, 2023 5:10 am**

Recently I have encountered more freezing on my x700 than ever before. Looks like a problem between my 4TB external HDD and the bluray player. A lot of the times folders inside the hdd won't show up at all and turning off the player then will make it freeze (black screen - unable to reboot until I unplug and replug the power adapter). Playing a video (regardless of whether it is in 4k or 1080p, HDR or SDR) and exiting it midway will make the player freeze as well. Very frustrating. Any ideas why?

Posted: **Tue Dec 26, 2023 9:01 pm**

I everyone,

I downloaded DDVT TOOL but I’m having a hard time understanding how DV works. I hope someone can help me understand better.

For exemple I have a HDR remux and I would like to inject a DV layer from another source (same number of frames, but the DV source is cropped), do I have to add the base layer and the rpu or just the rpu ? Is there a specific order ?

If I understand correctly DV is based on frame number, if I want to convert a movie from 23,976 to 24 fps do I have to edit something ?

Thanks,

Amaury

Posted: **Wed Dec 27, 2023 2:30 pm**

Amaury,

That's another tool with its own dedicated thread over at doom9, so I recommend visit there: https://forum.doom9.org/showthread.php?t=183479
As for DoVi_Scripts, which is mostly discussed here, you should read all of the information first in the readme on github and try it first, then ask any remaining questions.

Posted: **Wed Dec 27, 2023 7:09 pm**

RESET_9999 wrote: Tue Mar 07, 2023 10:39 pm 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.

@RESET is this still true?

Posted: **Wed Dec 27, 2023 10:14 pm**

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.

Posted: **Thu Dec 28, 2023 1:01 am**

RESET_9999 wrote: Wed Dec 27, 2023 10:14 pm 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.

Posted: **Thu Dec 28, 2023 1:46 am**

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

Posted: **Thu Dec 28, 2023 3:47 am**

RESET_9999 wrote: Tue Mar 07, 2023 10:39 pm
jayper wrote: Tue Mar 07, 2023 9:54 pm 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?

Posted: **Thu Dec 28, 2023 4:02 am**

x700 doesnt support cmv4.0 so it doesnt matter

Posted: **Fri Dec 29, 2023 5:45 pm**

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

Posted: **Fri Dec 29, 2023 8:56 pm**

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.

Posted: **Fri Dec 29, 2023 10:16 pm**

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.

Posted: **Sat Dec 30, 2023 5:36 pm**

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

www.makemkv.com

Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.

Re: Dolby Vision now possible through MP4 Mux.