Dolby Vision now possible through MP4 Mux.

[RESET_9999]

Hi there , which file is best to test CMV4.0 effect, or show is working? Thanks.

Sent from my SM-F946B using Tapatalk

Yes, all my test files can be found here: https://drive.google.com/drive/u/1/fold ... V0E3VVkhiC
look in the RPU response folder.

PS, I did a new version of my FEL test file.. I managed to remove the buggy reaction with the RPU mapping, and I added some L1 L2 L8 variation and also did a CMV4.0 version.
Works well on the Ugoos:

https://www.youtube.com/watch?v=4QUURfLy5ew

[Kaan_]

Hi RESET_9999,

There is ongoing debate regarding whether to set the color space to BT.709 or BT.2020, or not set it at all.

It seems now there is a way to check things out on the fly: https://discourse.coreelec.org/t/dolby- ... /24273/870

What do you think?

[RESET_9999]

Hi RESET_9999,

There is ongoing debate regarding whether to set the color space to BT.709 or BT.2020, or not set it at all.

It seems now there is a way to check things out on the fly: https://discourse.coreelec.org/t/dolby- ... /24273/870

What do you think?

Hi,
It's been a very long time since I tested this. I first noticed the difference when the Shield was released in 2019 and then later on the Zidoo. I had a C8 back then.
I noticed pretty much the same thing @cpm saw on his E8 here : https://discourse.coreelec.org/t/dolby- ... /24273/884
We can see it too in this old comparison I did on the zidoo forum: https://slow.pics/c/8zWhGixS

Right now I have a C2 and the VRR info does not report any flag with the Ugoos AM6b+, Shield, AppleTV, X800m2. It just says ''RGB 8bit TM DV''
I think you have a C1? and you said that there was no difference so maybe it depends on the TV. FWIW, on my 2023 Hisense u8, the TV osd display ''RGB 8bit rec709'' for all my devices.

IMO, since the majority of the players(including the latest ones: ATV, firestick/cube) do not send any flag, I think it is better to not send any color flag and let the TV handle the signal.
IIRC, on the C8, not signaling any flag was more accurate and matched how it looked using the internal TV app.

On a different note, I noticed some st2084 tracking issues with this pattern but overall it has fewer issues than the Shield/ATV: https://slow.pics/c/xLgSTMc3
I hope it doesnt affect real content playback which I haven't yet compared to my other devices.

pattern: https://drive.google.com/file/d/1OhnEb_ ... drive_link

[Trees]

Has anyone figured out how to convert P5 MKVs to MP4? I've tried an FFMPEG command found here:

Code: Select all

ffmpeg -i "S01E01.mkv" -map 0:v -map 0:a -map 0:s:0 -c:v copy -c:a copy -c:s mov_text -strict unofficial "S01E01.mp4"

That command seems right. Make sure you are using the latest tools.

Code: Select all

ffmpeg -i dv.mkv -map 0 -c copy -c:s mov_text -strict -2 dv.mp4

If that fails, it could be because the file is corrupted.
However, you could still try if other tools can recover it.

Code: Select all

ffmpeg -i dv.mkv -c copy dv.hevc
mp4box -add dv.hevc:dv-profile=5 -new dv.mp4

Code: Select all

ffmpeg -i dv.mkv -c copy dv.hevc
mp4muxer -i dv.hevc --dv-profile 5

The -vbsf hevc_mp4toannexb part is used when demuxing the P5 HEVC stream from a container, I believe.

As for -vbsf hevc_mp4toannexb, not sure if it's needed in mp4.

Thank you for the tip, updating worked. I had no idea it was that outdated!

However, I ran into the next problem; I'm getting subtle brightness flicking and (I'm assuming) IPTPQc2 errors. Every now and then I get a frame of the IPTPQc2 colour space peeking through. Literally slight change in colours every few minutes or so, randomly, it seems, and very very short. Barely noticeable.

Is this a known error / bug or?

Edit: Bonus question; does MP4 only support one subtitle track? I've remuxed numerous files however ffmpeg only seems to be copying over one subtitle track; is the subtitle part of the command incorrect or does MP4 just not support more than one subtitle track?

Edit: I've figured it out. The flickering was the file itself, just a bad quality Web-DL. As for ffmpeg, the correct command to include all subtitles is:

Code: Select all

ffmpeg -i "S01E01.mkv" -map 0:v -map 0:a -map 0:s -c:v copy -c:a copy -c:s mov_text -strict unofficial "S01E01.mp4"

[Donpoku]

Hi RESET_9999,

There is ongoing debate regarding whether to set the color space to BT.709 or BT.2020, or not set it at all.

It seems now there is a way to check things out on the fly: https://discourse.coreelec.org/t/dolby- ... /24273/870

What do you think?

Hi,
It's been a very long time since I tested this. I first noticed the difference when the Shield was released in 2019 and then later on the Zidoo. I had a C8 back then.
I noticed pretty much the same thing @cpm saw on his E8 here : https://discourse.coreelec.org/t/dolby- ... /24273/884
We can see it too in this old comparison I did on the zidoo forum: https://slow.pics/c/8zWhGixS

Right now I have a C2 and the VRR info does not report any flag with the Ugoos AM6b+, Shield, AppleTV, X800m2. It just says ''RGB 8bit TM DV''
I think you have a C1? and you said that there was no difference so maybe it depends on the TV. FWIW, on my 2023 Hisense u8, the TV osd display ''RGB 8bit rec709'' for all my devices.

IMO, since the majority of the players(including the latest ones: ATV, firestick/cube) do not send any flag, I think it is better to not send any color flag and let the TV handle the signal.
IIRC, on the C8, not signaling any flag was more accurate and matched how it looked using the internal TV app.

On a different note, I noticed some st2084 tracking issues with this pattern but overall it has fewer issues than the Shield/ATV: https://slow.pics/c/xLgSTMc3
I hope it doesnt affect real content playback which I haven't yet compared to my other devices.

pattern: https://drive.google.com/file/d/1OhnEb_ ... drive_link

Hi buddy What exactly are we looking for with this pattern, Thanks.

Sent from my SM-F946B using Tapatalk

[RESET_9999]

Hi buddy What exactly are we looking for with this pattern, Thanks.

Sent from my SM-F946B using Tapatalk

this pattern is explained here: https://spearsandmunsil.com/portfolio-i ... r-space-3/

here I marked whats wrong with each device: https://slow.pics/c/0njV9U5X

[LV8HD]

(1-1)(3-1) Script is now configured to keep the trims to match Resolve default (can be disabled at lines 48-52 if you prefer the old way)

I'm a bit confused since in your updated video on how to generate Dolby Vision and HDR10+ via Davinci Resolve you explicitly mentioned that L2 trims must be removed in order to achieve the most "natural" and near-creator-intended look possible. What has changed?

[RESET_9999]

I'm a bit confused since in your updated video on how to generate Dolby Vision and HDR10+ via Davinci Resolve you explicitly mentioned that L2 trims must be removed in order to achieve the most "natural" and near-creator-intended look possible. What has changed?

I knew this question would come up haha... I did more test about the trims and it turns out, that all the trims in cmv2.9(100-600-1000) are generated from the manual L8 100nits trim and if no L8 trims were done by the colorist, the cmv2.9 trims are 100% generated.

Here's how to spot generated trims or manual ones:

Generated / automatic trims from cmv4.0 to cmv2.9 conversion will:
1- only use slope, offset and power.
2- will brighten with gamma and power the low nits scene. in the 600nits trims
3- will darken with gamma and power the high nits scene. in the 600nits trims
4- 100nits trims will most of the time have gamma and power values in the negative canceling each other( gamma darkens as much as power brightens) and most of the time offset will be negative too which makes sense because it compresses HDR to SDR range.
5- they will look 80% of the time like in this full comparison: https://slow.pics/c/hcIFEfIM

CMV2.9 rpu:
1- if the avg pq floor is 2.5nits, you know this comes from a 2.9 workflow so you can be sure that the trims is 100% manual
2- if the avg pq floor is 10nits, you know this come from a 4.0 workflow and the 100-600-1000 trims are 100% a conversion from a manual 100nits L8 trim
3- as soon as you see trim saturation gain and chroma weight or ms weight, you know this must come from the colorist as the dolby system cannot generate those.

CMV4.0 rpu:
If there is no active L8 trims, it means the L2 trims are 100% generated. They could be slightly updated with manual L3 mid tone offset which i dont know if it affects the generated trims (most likely it does because it directly affects L3)

Of the tons of rpu I checked so far, I think I saw active L8 600nits trims only 3 times. Therefore 99.9% of the movies (cmv2.9 or 4.0 with trims), are generated from a 100nits trims manual job.


Slope(gamma) (green line)= value under 2048 = darken over 2048= brighten
offset (lift) (blue line)= value under 2048 = darken over 2048= brighten
power(gain) (green line)= value under 2048 = brighten over 2048= darken
chroma weight affects only the highly saturated highlights. value under 2048 = darken over 2048= brighten
saturation gain controls the whole image saturation. This is the trim that can make DV colors look quite different than HDR10...
ms weight works like madvr highlights recovery, it increases or decreases details in highlights.

Lift/Gamma/Gain: These controls function similarly to the Y-only Lift, Gamma, and Gain master
wheels of the Color Wheels palette, to let you trim the overall contrast levels of the image. The
Dolby Best Practices Guide recommends to limit positive Lift to no more than 0.025, and mostly
restrict yourself to using Gamma and Gain if necessary to lighten the image.
— Saturation Gain: Lets you trim the saturation of the most highly saturated areas within a scene.
Lesser saturated values will be less affected.
— Chroma Weight: Darkens saturated parts of the image to preserve colorfulness in areas of
the image that are clipped by smaller gamuts that don’t have enough headroom for saturation
in the highlights.
— Tone Detail: Lets you preserve contrast detail in the highlights that might otherwise be lost when
the highlights are mapped to lower dynamic ranges, usually due to clipping. Increasing Tone
Detail Weight increases the amount of highlight detail that’s preserved. When used, can have the
effect of sharpening highlight detail.

You can use Gamma to elevate the blacks/shadows as required and use the Gain trim control to restore any highlights that may have been elevated or clipped.

For example, if a program were graded relative to a 4000 nit display, along with a single 100 nit
BT.709 trim pass, then a Dolby Vision-compatible television with 750 nit peak output will reference
the 100 nit trim pass metadata in order to come up with the best way of “splitting the difference” to
output the signal correctly. On the other hand, were the colorist to do three trim passes, the first
at 100 nits, -cond at 600 nits, and a third at 1000 nits, then a 750 nit-capable Dolby Vision television
would be able to use the 600 and 1000 nit trim metadata to output more accurately scaled color
volume and HDR-strength highlights, relative to the colorist’s adjustments, that take better advantage
of the 750 nit output of that television.

[Donpoku]

Hi buddy What exactly are we looking for with this pattern, Thanks.

Sent from my SM-F946B using Tapatalk

this pattern is explained here: https://spearsandmunsil.com/portfolio-i ... r-space-3/

here I marked whats wrong with each device: https://slow.pics/c/0njV9U5X

Thank you, so st should be white almost invisible, right?

Sent from my SM-F946B using Tapatalk

[RESET_9999]

Thank you, so st should be white almost invisible, right?

right, paler is better and it should be at least the same as the other tv-led devices.

[Donpoku]

Thank you, so st should be white almost invisible, right?

right, paler is better and it should be at least the same as the other tv-led devices.

Thanks again. Btw, how do I test for true TV-LED-i know am6b+ android is lldv just want to see difference.

Sent from my SM-F946B using Tapatalk

[RESET_9999]

Thanks again. Btw, how do I test for true TV-LED-i know am6b+ android is lldv just want to see difference.
Sent from my SM-F946B using Tapatalk

I think the Plex and Kodi app support DV with the original Ugoos firmware. It won't be true tv-led but it should be interesting to test if it's the same.
AFAIK the only way to test true tv-led is with a capture card.

[bbeny123]

here I marked whats wrong with each device: https://slow.pics/c/0njV9U5X

I tested the same pattern on my Sony A95L and the results are quite different:
Ugoos (CoreELEC V21 - latest nightly 0330) and x800m2 seem to track ST2084 the same.
In contrast, the internal application is completely broken

Sorry for quality of photos

x800m2:


Ugoos:



Internal:

[RESET_9999]

I guess this depends on the TV. Your colorspace conversion also looks wrong /different than mine.

I'm on 20.5 latest nightly btw

[RESET_9999]

x800m2 seem to track ST2084 the same.

are you sure though? From your pics it looks like there is a difference: https://slow.pics/c/SqFAiJKa

perhaps your room is too bright to see it? My pictures were taken in a pitch-black room without any light and my DSLR camera (not phone) settings are locked.