Suspect it depends on the export workflow - but I agree - assuming that the RPUs for a DV Profile 5 ICtCp (abbreviated) will deliver the same result with an HDR10 (or in reality the PQ10 element of it as the HDR10 static metadata will be discarded) export is making a lot of assumptions.
I suspect itās possible, but unlikely : https://professionalsupport.dolby.com/s/article/Color-Primaries-inside-a-Dolby-Vision-XML?language=en_US
Dolby donāt seem to mention any āunusualā standards here - and this is the kind of sidecar XML that presumably is supplied to OTT providers like Netflix, Apple TV+, Disney + when they receive J2K or similar masters to then encode? (I think OTT providers want a single delivery - hence the move to IMF that allows multiple versions with different text elements to be delivered in a single file)
Was just about to jump in and say that this indeed a terrible idea.
In terms of the āsceneā, which we donāt support, they have chosen to try and bodge Profile 8 to give some form of a compatibility layer.
Profile 5 is the most efficient (in terms of storage and space) and itās where we need a fallback layer, or rather, need to generate one of the fly. Itās also legitimately used by streaming services, so we have a genuine use case to support it.
Itās the opposite of that I think Sam.
The compatibility layer is fine (thatās usually untouched) - itās the bodged add-on DV RPUs that are the mistake if you have a DV player. If you have a DV player youāre potentially better off stripping out the DV-stuff and keeping just the HDR10 (or PQ10 if the static metadata has gone - if your display bothers to use it anyway)
If your source is a UHD BD with an MEL rather than an FEL - then itās likely the RPUs will make some sense with the HDR10 base layer, but if youāre boding in DV RPUs from a DV encode into a separate HDR10 stream from an OTT streamer - then thatās a recipe for goodness knows what.
It could be that ācustom primariesā actually refers to the shaping that they do to the IPT chroma channels. Or else thereās a secret thatās implied somewhere in those XMLs when they specify a profile 5 encode.
If you have an HDR10 layer, thereās no need to do any conversion, or generate a fake profile, I donāt disagree.
For DV Profile 5 ā thatās why we need to generate one. If there was a fallback layer we wouldnāt do so.
Not sure I understand what you mean by āfallback layerā in this context? Do you mean separate video stream rather than a layer? i.e. an mkv file with two separate, independent video streams in it, like an HDR10/PQ10 YCbCr stream and then a DV Profile 5 ICtCp stream ? Does anyone actually do this rather than just have two files?
Yes - though the Rec 2020 primaries are so wide - Iām struggling to think why theyād specify different ones and go through the pain of having to handle another tone mapping stage (though I guess the EOTF and primary tone mapping is combined anyway - so primary tone-mapping vs mapping isnāt separate ) ?
I guess DV Profile 5 stuff could have a narrower gamut (so only needs mapping not tone mapping into Rec 2020 space - though EOTF tone mapping could be combined?) to concentrate bit depth on content that is actually present?
See https://www.reddit.com/r/Piracy/comments/15ily4a/hbo_rips_dolby_vision_5_vs_8/
P8 has a fallback layer, HDR10, but itās compromised of ripping RPU from P5 which is pretty terrible.
Keep in mind that not everything in that thread is accurate.
You will know that Dolby Vision has two decoding stages - the Composer and the Display Mapper. For Profile 5 the IPT channels are āshapedā in order to make best use of the bandwidth - the result being equivalent, it is claimed, to 11.5 bits per channel. The Composer unshapes these curious encodings - I wouldnāt call that tone mapping and I donāt think Dolby do. IPT gets decoded to LMS and the (custom per the RPU) EOTF applied then LMS is converted to RGB which is where BT2020 primaries come in.
Yes, thatās pretty much as I understand it.
For those that want to test this out:
Note: This will not work on Vero 4K / 4K +
- Login via the command line
- Run the following command to add the staging repository:
echo 'deb http://apt.osmc.tv bullseye-devel main' | sudo tee /etc/apt/sources.list.d/osmc-devel.list - Run the following commands to update:
sudo apt-get update && sudo apt-get dist-upgrade && reboot - Your system should have have received the update.
I also recommend you remove /etc/apt/sources.list.d/osmc-devel.list after updating.
This will deactivate the staging repository. You can do so with the following command:
sudo rm /etc/apt/sources.list.d/osmc-devel.list.
Please note that we will automatically disable this update channel after 14 days on your device in case you forget to do so to ensure that your system reverts to the stable update channel.
Cheers
Sam
As noted above, DONāT TRY THIS ON VERO 4K/4K+. You will likely brick it.
Shoot ā hadnāt even thought someone might try that. I will update the original posts
Iām not sure Iād call that a āFallbackā layer - it IS the video layer?
Thereās no Dolby Enhancement Layer in that scenario (as is the case with some UHD BDs) - so all that is added to the HDR10 compatibility layer in the āDVā is the RPUs carrying the metadata ? These may mangle the HDR10 in a way that is sub-optimal - but the HDR10 layer is still carrying pretty much the entire video payload (so isnāt what Iād call a fallback layer - itās used whatever format is being played)
The only fallback is - I guess - the HDR10/10+ metadata that is also carried in that stream along with the video?
(Iāve not looked at UHD BDs close enough to work out if retaining the UHD BD DV RPUs - ditching the minimal or full enhancement layers - and just retaining the HDR10/10+ core video payload still delivers a consistently improved experience closer to the DV result via conventional decoding.)
I was trying to work out if it was a narrower gamut - or just more optimised content (and with a more optimised EOTF?) carried in the subsampled channels (as the Profile 5 stuff still uses 4:2:0 10-bit HEVC for carriage - just with different components in the high and low bandwidth channels)
By using metadata (in the RPUs) you can optimise your shot-by-shot (frame-by-frame?) content carriage, in encodes that donāt have to be compatible with anything else, to deploy your 10-bit depth dynamically to where the content is most needy I guess?
(ISTR that DV also uses 1-1024 rather than 64-940 level space - so that frees up a bit more range too?)
Indeed, thereās an HDR10 layer and an RPU
But where HDR10 has been ācreatedā to make a Profile 8 video, itās not very good and based on many presumptions.
Ah - are you suggesting a scenario where the HDR10 layer isnāt an original stream encoded by the original content creator, and is somehow converted from a DV profile 5 stream?
Iād assumed this Profile 8 scenario was just a case of sourcing a regular HDR10 stream and a profile 5 DV stream from the original content creator, and combining the RPUs from the latter with the perfectly acceptable video from the former ?
Correct ā and thatās what the pirate scene are doing when making these Profile 8 rips.
If thereās an original HDR10 layer, the DV isnāt needed at all and necessary fallbacks already occur.
Gotcha.
According to Wikipedia, ITP is capable of encoding more than the BT2020 gamut. ICtCp - Wikipedia
Nobody ever talks about āprimariesā for the ITP colourspace although I suppose it would be possible to calculate them.
All channels use 0-1023 quantisation range then the (un)shaping reduces the values to fit inside a gamut that can be displayed. So the gamut needed for each scene can be specified to the full 10 bits.
The shaping coefficients change for each scene, sometimes also within a scene and sometimes with every frame. Fades seem to be handled by changing the shaping rather than the video values for example so thereās a new RPU for every frame.
1 Like