Dolby Vision now possible through MP4 Mux.

[HotFudge]

No because when you bake FEL, it usually increases the brightness over 1000nits and if you keep the original MDL/maxcll, it will be clipped in HDR10 because the TV will use the 1000nits tone mapping curve with a higher roll-off point.

All of this depends on how the TV handles static tone mapping in HDR10 though but generally speaking, it's better to use the same MDL as DV.

Thanks for insight

If one watches the baked FEL encode on a non DV capable TV. Will using the maxcll and maxfall from the RPU be still correct?

[RESET_9999]

yes that's what I just said.
The HDR10 metadata doesn't matter for DV TV and FYI, Samsung TVs ignore maxcll, they only use MDL

[RESET_9999]

@RESET

You got that picture of the greyscale 10%?

sorry, the 5-10% grayscales are too dim. My camera cannot capture it... I have to raise ISO, which introduces noise that masks the issue.


EDIT: actually what I'm seeing is exactly like in this video:
https://youtu.be/czIxtnAh36w?si=--UggVf0iEz5VP7u&t=350

For what it's worth I've been watching movies in DV on my 83" G5 for a few weeks now and have not been able to see the dithering effect in any content in the darkest of scenes from my seating distance of 10' away. And believe me I looked.

FYI, the dithering lines are totally visible in real content (dark scenes) and they look horrible at 8-10ft. Check this out, when she closes the door and turns around.
https://mega.nz/folder/YXl32CTT#xvx028tSnyHhmbwqB2AdhA

Not visible on the C2 on this same scene but the C2 also has those moving/falling lines on the 5-10% grayscale.
https://drive.google.com/drive/folders/ ... drive_link

[foxbat]

Is it normal for the DV P5 version of a given stream to be around 30% larger than the equivalent HDR10 version?
For example:
Andor.S02E04.2160p.DSNP.WEB-DL.DDPA5.1.DV.HEVC-PlayWEB.mkv: 6431381983
Andor.S02E04.2160p.DSNP.WEB-DL.DDPA5.1.HDR.HEVC-PlayWEB.mkv: 4305241410

I also notice that the hybrid P8 files people are posting are around the same size as the HDR10 versions. Is something being lost from the P5 files during that conversion?

[RESET_9999]

DV was just encoded at a higher bitrate. 15mb/s vs 11mb/s
Get the higher bitrate version, P5 basically like FEL DV anyway. So yeah, there is a loss in the P5 to P8 conversion.

[kazuma]

how is the DV performance of jellyfin? is it incorrectly?

[foxbat]

how is the DV performance of jellyfin? is it incorrectly?

As long as you're not transcoding it's the same as playing direct from network

[staknhalo]

Is it normal for the DV P5 version of a given stream to be around 30% larger than the equivalent HDR10 version?
For example:
Andor.S02E04.2160p.DSNP.WEB-DL.DDPA5.1.DV.HEVC-PlayWEB.mkv: 6431381983
Andor.S02E04.2160p.DSNP.WEB-DL.DDPA5.1.HDR.HEVC-PlayWEB.mkv: 4305241410

I also notice that the hybrid P8 files people are posting are around the same size as the HDR10 versions. Is something being lost from the P5 files during that conversion?

Yes DV5 versions of titles are always/almost always encoded at higher bitrates than HDR10 versions of some files from what I've seen - I imagine it's 'spec' or 'guidelines' by Dolby for DV certification/redistribution 'can't be below/must be at certain bitrate/threshold' in order to show 'how DV is the best' - Lord knows the streamers would love to reduce bitrate/transmission costs/storage/etc as much as they can get away with.

[kazuma]

how is the DV performance of jellyfin? is it incorrectly?

As long as you're not transcoding it's the same as playing direct from network

i want to know if the profile playback is correctly of the DV metadata?

[foxbat]

i want to know if the profile playback is correctly of the DV metadata?

That's going to depend on the device you're playing it on. On an Ugoos AM6B Plus running CPM build of CoreELEC with the Jellyfin Kodi addin, DV playback is correct.

[bbeny123]

@RESET_9999, I have questions regarding HDR to Dolby Vision conversion and proxy encoding.

1. cm_analyze vs. Resolve for DV conversion: which produces better (more accurate) RPU?

I've generated RPU XML files using both DaVinci Resolve (following your tutorial) and cm_analyze, and noticed differences in the Level 1 metadata. The ColorEncoding sections also differ significantly:

Resolve output:

Code: Select all

<ColorEncoding>
  <Primaries>
    <Red>0.68 0.32</Red>
    <Green>0.265 0.69</Green>
    <Blue>0.15 0.06</Blue>
  </Primaries>
  <ColorSpace>rgb</ColorSpace>
  <SignalRange>computer</SignalRange>
</ColorEncoding>

cm_analyze output:

Code: Select all

<ColorEncoding>
  <Primaries>
    <Red>0.708 0.292</Red>
    <Green>0.17 0.797</Green>
    <Blue>0.131 0.046</Blue>
  </Primaries>
  <ColorSpace>ycbcr_bt2020</ColorSpace>
  <SignalRange>video</SignalRange>
</ColorEncoding>

L1_Resolve-L3.png (176.52 KiB) Viewed 2139 times

Based on this and the plots below, which RPU would you consider more accurate or "better"? I've included XMLs for reference.

2. Can ProRes Profile 1 or 2 (Apple HW) be used as a proxy instead of Profile 3 with q=4 (SW)?

From my tests, Profile 2 (Apple HW) seems to have higher fidelity to the original source than Profile 3 with q=4 (SW). Even Profile 1 (Apple HW) performs surprisingly well and is quite close.

Does the profile number carry any real-world implication beyond bitrate?
Would Profile 1 (Apple HW) be good enough for proxy use, or would you still recommend suffering through Profile 2's higher bitrate and file size?

Here are some PSNR results and encoding stats:

Code: Select all

Profile     | Encoder                | PSNR (avg) | PSNR (min) | Size    | Bitrate
------------|------------------------|------------|------------|---------|---------
P3 Q4       | SW: prores_ks          | 58.95      | 56.69      | 27.4 GB | 196 Mb/s
P1          | SW: prores_ks          | 58.96      | 53.15      | 34.3 GB | 246 Mb/s
P2 (Apple)  | HW: prores_videotoolbox| 62.82      | 58.26      | 48.8 GB | 350 Mb/s
P1 (Apple)  | HW: prores_videotoolbox| 59.05      | 55.45      | 28.9 GB | 207 Mb/s

Encoding commands:

Code: Select all

- P3 (Q4): ffmpeg -i test.mkv -c:v prores_ks -profile:v 3 -vendor apl0 -qscale:v 4 -color_primaries bt2020 -color_trc smpte2084 -colorspace bt2020nc -pix_fmt yuv422p10le test_p3-q4.mov
- P1 (QX): ffmpeg -i test.mkv -c:v prores_ks -profile:v 1 -vendor apl0 -color_primaries bt2020 -color_trc smpte2084 -colorspace bt2020nc -pix_fmt yuv422p10le test_p1-qx.mov
- P2 (HW): ffmpeg -i test.mkv -c:v prores_videotoolbox -profile:v 2 -color_primaries bt2020 -color_trc smpte2084 -colorspace bt2020nc test_p2-hw.mov
- P1 (HW): ffmpeg -i test.mkv -c:v prores_videotoolbox -profile:v 1 -color_primaries bt2020 -color_trc smpte2084 -colorspace bt2020nc test_p1-hw.mov

PSNR commands:

Code: Select all

- P3 (Q4): ffmpeg -r 24000/1001 -i test.mkv -r 24000/1001 -i test_p3-q4.mov -lavfi psnr="stats_file=test_p3-q4.log" -f null -
- P1 (QX): ffmpeg -r 24000/1001 -i test.mkv -r 24000/1001 -i test_p1-qx.mov -lavfi psnr="stats_file=test_p1-qx.log" -f null -
- P2 (HW): ffmpeg -r 24000/1001 -i test.mkv -r 24000/1001 -i test_p2-hw.mov -lavfi psnr="stats_file=test_p2-hw.log" -f null -
- P1 (HW): ffmpeg -r 24000/1001 -i test.mkv -r 24000/1001 -i test_p1-hw.mov -lavfi psnr="stats_file=test_p1-hw.log" -f null -

PSNR results:

Code: Select all

- P3 (Q4): PSNR y:57.830199 u:61.702542 v:64.312729 average:58.951441 min:56.685113 max:inf
- P1 (QX): PSNR y:57.672183 u:62.738864 v:65.896872 average:58.958489 min:53.148347 max:inf
- P2 (HW): PSNR y:62.149857 u:63.255604 v:66.544010 average:62.822763 min:58.255157 max:inf
- P1 (HW): PSNR y:57.895307 u:61.791684 v:65.122727 average:59.052011 min:55.453200 max:inf

Would love to hear your take on both these questions.
Thanks in advance!

[RESET_9999]

I dont think the difference is big enough to have a noticeable difference in playback but if I had to guess, I would say CM might be more accurate because other things can interfere in resolve.
FYI, I did new and better test file for L1 and it seems that the average_pq has no effect at all in cmv4.0, not even high values way above my TV ABL. DV dims the image only when L1 max_pq reaches your TV target.
In cmv2.9, a 150nits max/avg_pq dims the image even on my 2500nits G5, which doesn't make much sense since the TV can do 2500 peak / 400nits full field, and this is exactly why the generated L2 trims brightens the image so much in 2.9. see: https://docs.google.com/spreadsheets/d/ ... 1289366200
So I'm no longer watching 2.9 retail movies. CMv4.0 for everything!


As for the XML header primaries, unless you encode in DEE, it doesn't matter.
As for the ProRes profile, as long as the brightness and colors remain the same, I don't think it matters much.

PS: The CM warning msg are gone in the latest version. It also fixed my Windows 11 crashes.

[coopzr]

FYI, I did new and better test file for L1

Is it these files last modified 8th May 2025?

So I'm no longer watching 2.9 retail movies. CMv4.0 for everything!

I've only just started avoiding cmv2.9 with a 4000 nits MDL due to the broken behaviour on my LG C4.

Are you saying there is more broken behaviour at other MDL's?

[RESET_9999]

Is it these files last modified 8th May 2025?

yes

I've only just started avoiding cmv2.9 with a 4000 nits MDL due to the broken behaviour on my LG C4.

Are you saying there is more broken behaviour at other MDL's?

1000 mdl doesn't dim too early like 4000mdl but it is slightly crushed.

[foxbat]

So I'm no longer watching 2.9 retail movies. CMv4.0 for everything!

I apologize if I have missed some developments, but, are we now able to convert retail CMv2.9 to CMv4.0? If so how involved is that process?