Dolby Vision now possible through MP4 Mux.

[sw5163]

No I mean Plex causes stutter on Apple when processing hev1/dvhe

[staknhalo]

No I mean Plex causes stutter on Apple when processing hev1/dvhe

Ah, gotcha. Yes, maybe also Apple walls whatever off from 3rd party apps and only has accesses to needed libraries/resources with their native apps? Would be very Apple to do. Or Plex devs just need to fix you think? Would also be very Plex devs thing to need to do lol.

OK - for NF titles only for some reason - yes it seems only fake p5 will work

Fake p5 works on iOS as DVH1 or DVHE (thought DVHE should never work on iOS - even if just Plex on iOS as assumed above - as HEV1 doesn't and both those are the SW based playback IIRC)

Making a native p8 with the 'forced' DVH1 flag

Code: Select all

mp4box -add video.hevc:dvp=f8.1 -add audio.aac:lang=eng -new p8.m4v

causes weird random blankouts on playback - on both Windows and Plex iOS

Video will start playing fine, no stutter, thought I figured it out, but then goes all black (sound keeps playing) and then video will come back eventually - this was on iOS, on Windows video just starts out all black to begin with sound still playing - that one is odd - anyone got a guess?

Making a native p8 with forced DVHE flag (because fake p5 DVHE works)

Code: Select all

mp4box -add video.hevc:dvp=f8.1:xps_inband -add audio.aac:lang=eng -new p8.m4v

creates stutters on Plex iOS like I assumed - so that's a no go

I would like to avoid fake p5 just because who knows what will happen with future devices, feels wrong to keep files mislabeled (especially not just in file name let's say, but in the metadata!!), but if ONLY NF titles need this I guess that's an acceptable compromise

Still, why is it only NF titles?

Edit: Also, the fake p5 DVHE files do have a very very slight stutter on Plex iOS - but very much less so than HDR10/P8/P7 HEV1 or DVHE - to the point I didn't notice at first but also to a point where would be acceptable to watch (unlike HEV1)

Double Edit: Infuse plays HDR10 HEV1 fine on iOS so must be a Plex issue (playback of HEV1 that is, but still doesn't explain why only NF titles won't play right in HVC1) - this way I can keep files labeled/structured correctly according to what they are

[RESET_9999]

Big blockbuster like Avatar but they do some lazy static DV grade .... SMH
and HDR10plus is better here...

[comorla45]

So.. Will it be better to make own DV from HDR10+ source with your tools instead of watching original DV master, I guess?

[RESET_9999]

yes it will be more dynamic but this HDR grade is not very bright so the dynamic part is less important.

[comorla45]

I tried to use the tool but the final plot I get from converting HDR10+ to DV is cut at 10 nits:




My workflow was:
DoVi_Scripts_1.7.7_MKV.bat -> Mode.H -> Mode.1 -> Source MKV is Avatar.The.Way.of.Water.2022.2160p.WEB-DL.x265.10bit.HDR10Plus.DDP5.1.Atmos-CM

Code: Select all

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5@High
HDR format : Dolby Vision, Version 1.0, dvhe.08.06, BL+RPU, HDR10 compatible / SMPTE ST 2094 App 4, Version 1, HDR10+ Profile A compatible
Codec ID : V_MPEGH/ISO/HEVC
Duration : 3 h 12 min
Bit rate : 24.3 Mb/s
Width : 3 840 pixels
Height : 2 072 pixels
Display aspect ratio : 1.85:1
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.127
Stream size : 32.6 GiB (97%)
Language : English
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : BT.2020
Mastering display luminance : min: 0.0050 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 412 cd/m2
Maximum Frame-Average Light Level : 201 cd/m2

The source file already include DV but I was thinking that script will ditch the original DV and replace it with metadata generated from HDR10+ (and it was converting HDR10+ looking at the console window).

[RESET_9999]

Yes, DV has an average_pq floor of 10nits for CM v4.0 and 2.5nits for CM v2.9. Min max_pq will always be 100nits as well.
Dolby average algo seem to have some rules while HDR10plus is more dynamic in that regard.

[comorla45]

So, can we say that conversion HDR10+ into DV is worse for scenes with low-brightness mastering? If we had like HDR10+ House of the Dragon with the famous 1 nit beach scene, then conversion would brighten it up to 10 nits?

[RESET_9999]

I don't know, I never really tested how average_pq reacts on my TV. I planned to do a pattern one day.

high values of average pq also works very differently in DV. Dolby algo seems to have some rules that target 92nits max(roughly something like if 50% of the pixels of below 100nits, max avg will be 92nits) while HDR10plus (and madvr generated) are more a real representation of the actual brightness.

[Mrmorrison]

Good day everyone.

I just wanted to inform you that my Sony Bravia A8H TV, combined with Kodi or Plex or any other application that can use exoplayer, can play any type of Dolby Vision, except for FEL (FEL TS= plays HDR - FEL MKV = plays in SDR) .

P7 MEL (MKV and TS/MTS)
P8 (MKV and TS/MTS)
P5 (MKV and TS/MTS)

Everything reproduced correctly in WIFI.

I imagine this is the case for other recent Bravia models as well.

I also own x800m2 and GCwGtv and I can say that Chromecast (with same settings) reproduces a brighter dolby vision than x800m2 and Sony Bravia.
On Bravia my most used setting is Dolby Vision Dark (90%) but on x800m2 this setting is too dark so I have to use Dolby Vision Bright.

Bravia DV Bright= x800m2 DV Dark

Maybe you can add this information to your spreadsheet

[RESET_9999]

I also own x800m2 and GCwGtv and I can say that Chromecast (with same settings) reproduces a brighter dolby vision than x800m2 and Sony Bravia.

Hi, thank you for the info, I wish the C2 supported DV MKV as well

IMO the Chromecast is not accurate and over track. I've compared it to the shield, x800m2 and C2 plex a while ago.
see: https://slow.pics/c/pEEQBJJD

[aboulfad]

Hello,

Is test pattern RPU.p8.1.L1.L2_cmv29.mp4 meant to include cmv4, what is the reason ? It would not display in DoVi nor respond to any RPU changes (fallback to HDR10). Only by removing the cmv4 frames that it worked on ATV21/22 -> Infuse 7.5/Auto -> LG E7. Thanks.

dovi_tool info -s -i RPU.p8.1.L1.L2_cmv29.bin
Parsing RPU file...

Summary:
Frames: 1680
Profile: 8
DM version: 1 + 2 (CM 2.9 and 4.0)
v2.9 count: 1680
v4.0 count: 72

[sw5163]

ATV21/22 -> Infuse 7.5/Auto -> LG E7.

Infuse will not play DV file with cmv4 in it since cmv4 seems to have over saturation problem on Mac.
https://community.firecore.com/t/dolby- ... /19713/351
But looks fine on iOS devices and Atv, no idea what's going on here.

[aboulfad]

Thanks @sw5163 , my main question is about the reason to include some cmv4 metadata in that test pattern labelled with cmv29. Is it to check a device DoVi’s implementation’s for handling of both metadata versions ?

The test pattern does not play as DoVi nor respond to the changes in RPU metadata. Infuse plays it as HDR and it is possible and likely the presence of cmv4 causes problems for the P8 to P5 « processing ».

[quietvoid]

Thanks @sw5163 , my main question is about the reason to include some cmv4 metadata in that test pattern labelled with cmv29.

It most likely was a mistake.