thanks cpm for all your work!!! I’m following the development for quite a while this is really impressive!!
and sorry for the question but I cannot find a dummy guide and that’s what I need. Is there one somewhere?
I’m still a bit proud that I’ve managed to install ce and move to emmc, I’m now on the latest nightly and all is perfect.
is there a guide how to install / upgrade or better downgrade to the 4ta version without destroying all my settings and without SD card and dv file and toothpick etc…?
I think I would love to try it out with vs10! or should I wait as a newb until it will be rolled out regularly?
I was clear in what I wrote that it was if you only had one flash drive, and you didn’t want to install the update on the dual boot just in case something goes wrong. So what you just wrote is only relevant in the other situation. I always install stuff on the recovery thumb drive first just to make sure there are no issues before I flash it back onto the dual boot.
Either way guys, thanks for all the help. Everyone’s input is valued. This build is running great. I haven’t had any issues with T4 or T4A. Just installed T4A as an update over T4 and everything works as expected.
There is a DV hybrid remux of that film, and all the Star Wars films (using the native P5->P8 DV from the streaming versions). So it is better to grab those remuxes instead of using VS10 to upscale the HDR.
Similar to Harry Potter films, there are DV hybrids of all of those with native DV taken from the streaming versions.
VS10 HDR → DV best used for content that exist with no hybrid DV. It’s a great approximation, but the official DV from the studio will be better since it has modifications from a professional colorist.
Hybrids are not official in terms of DV in any capacity and there is one big catch with them. Streaming DV is Profile 5, uses proprietary ITP color space, and has no HDR10 fallback, Profile 8 (that is often used in pirated rips and hybrids) on the other hand has HDR10 base layer and uses YCbCr. Two issues arise from these facts: first, one has to convert an RPU from Profile 5 to use in Profile 8 (cause they use different color space) and color and/or luminance errors can arise from this process if one does not use the correct parameters for conversion (and it WILL happen because different streaming platforms have their own quirks in terms of Dolby Vision), and second, in order to create a hybrid, one must get an HDR10 base layer somewhere else (normally that would either be a Blu Ray or HDR10 streaming version) because, like I said, Profile 5 has no HDR10 stream, and that base layer may, and probably was, mastered by a different person to different luminance levels and on a different hardware, which will also lead to color and liminance inaccuracy in those “hybrids”. To make matters worse, aspect ratio and framing doesn’t always match between BD and streaming versions.
TLDR: There is just no way to know how accurate in terms of colours and luminance hybrids are since it involves conversion between colour spaces and different parameters. Use either HDR10, DV Profile 8 of UHD Blu Ray discs if the disc has DV or DV Profile 5 of streaming versions.
This is all well known and hybrids are created accurately all the time. See this list:
Files that don’t pass grade check are just not created. Besides to other point, P7 FEL is played as MEL all the time: Shield Pro/Zidoo/Dune/etc. It’s not as good as FEL, but there is still benefit to the RPU, and it is better than the HDR base layer. Hence there is no downside to P5 → P8 conversion, it basically the same as FEL being played as MEL, which is still far superior than HDR only.
Star Wars/HP, there is no issue here along with many other films.
You’re seriously depriving yourself if you think you should be allergic to hybrid DV.
The irony of all this is you’re commenting on VS10 functionality… on the fly upscale of HDR to DV. If properly made, hybrid DV is far superior to VS10 upscale without question, which none of the tier 1 remux groups have trouble doing (check trash guides tier ranking).
Based on the information I have gleaned (so always happy to be corrected if have a better source) - I think there is an often missed benefit of DV-Std [tv-led]: that it will (with good implementation in the display) go through less conversions.
Example: P5 (IPTPQc2), P7 - BL and FEL (ICtCp)
The player will create IPTPQc2/ICtCp 4:2:2 12 bit (below both are refereed to as
ICtCp for brevity)
For DV-Std [tv-led] the ICtCp 4:2:2 12 bit is transmitted over HDMI “labeled” as RGB 8 bit (this may appear to be completely erroneous as not RGB nor 8 bit - but it takes up exactly the same amount of space [bits] and Dolby seemingly have their reasons, I recall something about compatibility when initially developed), the display will then convert the ICtCp 4:2:2 12 bit to drive it’s display tech.
For DV-LL [player-led] the ICtCp 4:2:2 12 bit is converted to YCbCr 4:2:2 12 bit at the player for transmission (in the typical case), the display will then convert the YCbCr 4:2:2 12 bit to drive it’s display tech.
Yes - Dolby used RGB 8-bit tunnelling as DV arrived before HDMI supported EOTF flagging (I think it was supported over HDMI 1.4b connections)? They didn’t really have much choice initially as there was no way of flagging HDR EOTFs and ICtCp colour space back then?
It makes sense to keep things in ICtCp space up to your display if you can I guess. (TV Led)
Presumably player led/LLDV paths where the ICtCp is converted to YCbCr in the player with information from the display informing this conversion should end up with the same result - though there may be an additional ICtCp->YCbCr->RGB/RGBW process in the path IF displays can otherwise go ICtCp->RGB/RGBW directly otherwise - though I don’t know if they do.
However in all situations it appears the 4:2:0 to 4:2:2 chroma vertical upsampling (whether in ICtCp or YCbCr spaces) is done in the player/source and the HDMI connectivity is 4:2:2?
(For those interested - ICtCp is the colour space that if interpreted as YCbCr looks green and magenta. It’s apparently better at decoupling luminance from chrominance, meaning the chrominance subsampling horizontally and vertically loses less information that the eye is sensitive to than in YCbCr)
This is actually flagged inside of the DV metadata that is embedded into the top rows of the video signal in most tv-led modes.
In one of the older DV documents, it is even acknowledged that not all external devices (avr’s etc) may pass though the extra information HDMI 1.4 supported in infoframes etc. A solution was even purposed that TV’s could have a manual mode to trigger a TV to cause it to look for valid embedded metadata. This would actually avoid all issues with passing through color spaces, EOTF’s, etc, regardless of the HDMI version or supported flagging, as the information is included in the video signal itself.
And then to throw more into the mix of options possible, it is possible to have YCbCr (among others) inside of the tunnel and not just ICtCp.
Despite this, the hdmi captures of the tv-led tunnel show that both an oppo player and CoreELEC do an unnecessary YCbCr->ICtCp color space conversion for profile 8.1 content before transmitting it over the hdmi.
Haven’t really looked enough at the ‘proper’ way of doing DV on CoreELEC with the dovi.ko to comment if that is used.
Without the dovi.ko though, the work I’ve been doing doesn’t convert the color space and keeps it in YCbCr. Simply because nothing aside from adding metadata is being done.
Was wondering a while back if this is connected to the processing of RPU and that algo was only designed to work correctly on ICtCp.
All things for me point to it already being 4:2:2 before HDMI transmission - and as you originally point out 4:2:0 is only allowed for 2160p at higher frequency and only on HDMI 2.0 and above - so not a possibility for correct playback of the vast majority of 4K blu-ray.
The extra conversion alone in theory will lose some quality, but maybe not that detectable with today’s displays with FEL 12 bit. (RPU application at display though is typically clearly superior, so not a simple comparison).
To round things out DV-LL (player-led) in the later DV implementation version can also be in RGB 12bit (or 10 bit), removing the additional conversion in the chain - but needs both device and display with latest version and outside the norm so fingers crossed it goes smoothly!
The unanswered question for me is - is the FEL actually in ICtCp already or made in a way which is helping the composition with the BL YCbCr (as it is proprietary and possibly encoded in another way - so would being 2 extra bits and vertical chroma data to complement the BL).
This may actually be noticeable as the HDMI signal is a 4:2:2 signal. One of the main advantages of ICtCp is that it performs much better (less artifacts, etc) when doing color-subsampling than YCbCr.
If actual ICtCp content (p5) is converted to YCbCr on the device before the HDMI transmission, this then forces the display to do chroma-upsampling in the YCbCr space which will look worse than if the TV was fed ICtCp to chroma-upsample.
So even if the actual color space conversion introduces negligible quality differences, it would force the chroma-upsampling from 4:2:2 to be performed in the inferior YCbCr color space.
Was thinking (on reflection maybe incorrectly) that the RPU was applied before the conversion to RGB and taylored to apply to ICtCp, I guess it is always after? though that means DV-LL must do yet another conversion? YCbCr → ICtCp → RGB (RPU) → YCbCr
Would make sense to me the FEL would prioritise the BL be made in a way that was compatible but when combined with FEL gave the best and closest result to master over the best possible BL. For MEL it would make sense it created the best possible BL. Guess only Dolby could tell us.
Would be great to have some high bitrate (i.e. same as 4K BluRay) in p5 to compare.