Dolby Vision now possible through MP4 Mux.

[RESET_9999]

Also here you can see because the file does end up with codec ID hev1 however it does - it does stutter on iOS devices like me and that Chinese guy were talking about a while back

https://i.imgur.com/RWmfX1m.mp4

I don't know about phone playback and don't have an apple device(never will).
I only tested the ATV with @ragico and he didn't report any stuttering.

IIRC Resolve dv 8.1 mp4 are also HEV1

[staknhalo]

Also here you can see because the file does end up with codec ID hev1 however it does - it does stutter on iOS devices like me and that Chinese guy were talking about a while back

https://i.imgur.com/RWmfX1m.mp4

I don't know about phone playback and don't have an apple device(never will).
I only tested the ATV with @ragico and he didn't report any stuttering.

IIRC Resolve dv 8.1 mp4 are also HEV1

I'll see if I can find someone over on [H] forum or AVSForum with an AppleTV to confirm that unless someone else here does first- just to be sure - stuff happens - maybe the test file at that time was hvc1? maybe they just didn't notice? Maybe it only does happen on phones or tablets? Maybe the Apple TV can just power through SW decode? Maybe one of a hundred other things?

Frustrating - nothings ever easy or simple :/

Edit: And like I said - this is only NF titles - not 4K BR DV or other Web DV titles :/

[RESET_9999]

maybe the test file at that time was hvc1?

no, my script (7-1) always created HEV1 P8 or DVH1 P5 mp4
maybe splitting the file broke something, did you try (7-1) with an untouched P8 mkv that has audio and subs?

For P8 on ATV you have to use infuse. For plex you have to use 'fake' P5(p8).

[staknhalo]

maybe the test file at that time was hvc1?

no, my script (7-1) always created HEV1 P8 or DVH1 P5 mp4
maybe splitting the file broke something, did you try (7-1) with an untouched P8 mkv that has audio and subs?

For P8 on ATV you have to use infuse. For plex you have to use 'fake' P5(p8).

I can't use HEV1 for my setup unfortunately - besides occasionally watching from my iPhone when at the airport/waiting rooms - I share Plex with people that watch from iPhone only (way the world is now sometimes lol)

I wanted to avoid fake P5 files if I could - was fine with P8 only playing back as HDR10 on iOS as long as no stutter - I'll give it a shot just to see

@sw5163 said he noticed this on All Quiet on the Western Front too (another NF title)

I asked quietvoid via DM - maybe NF authors these in HEV1/DVHE originally? And that's somehow why they refuse to work as HVC1? (edit: he said negative on that)

[sw5163]

I forgot to mention one very important info: Apple require the video track fourcc ID to be “dvh1” for Dolby Vision. So you need to change it manually using a Hex editor. (More info: the sample I recommended to you is “dvhe”, which cannot be played by QuickTime/Apple TV app)

The correct codec ID (for profile 8.1) should be "hvc1" in place of "hev1". But be careful, these boxes are not random: they indicate to the decoder how the information for the initialization of the latter is stored within the file. Changing the header with a hex editor isn't always enough!

I also tried to change "dvh1" to "hvc1" of the MBox profile 8.1 sample. The resulting file can be played in QuickTime (contrast still wrong), but cannot be played on my iPad. This is what I could't understand. It should be at least backward compatible with HDR10, like your Terminator sample.

As I said, very often it is not enough to change the header of a box for the file to be played. QuickTime is perhaps smarter and can retrieve the information needed to initialize the decoder. The iPad player may not be capable of it!

I guess Plex is doing something wrong when processing hev1.
Apple can retrieve the information needed to initialize the decoder even if the file is wrongly muxed.
But it requires powerful processor. So on newer iPhone/Mac/ATV playback will not have the black screen/stutter problem.

[staknhalo]

I guess Plex is doing something wrong when processing hev1.

This happens on Windows too with no Plex in the chain, where all my screenshots showing the issue come from. And again only for NF titles - that there shows it's something with these specific titles in particular.

[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.