Actually, there was a lot of work done on the electrical design of the new player. I've asked our hardware lead if he'd like to provide some specifics, and I'll post a follow-up if so. It's the sort of thing that will be sort of in the weeds for most consumers, which is why there aren't a bunch of marketing bullet points about it, but it was taken seriously.
I debated whether to reply to this, but I feel that there's enough here that could be confusing to readers that I have to respond. However, I do
not want to derail this thread with an off-topic digression, so I'm going to address the points raised, but if there's further discussion, let's please have it on a separate thread.
Okay, diving in, with help from some of my colleagues who are more knowledgeable than I am about this stuff:
Surge said: "The best image quality with HDR content is not using tone mapping at all - i.e., using a display that can display HDR."
Within the realm of consumer HDR, this statement doesn't really make sense.
SMPTE ST 2084 is the luminance standard that underlies all consumer HDR formats. It can represent values from 0.0001 nits up to 10,000 nits. There is no display on the market that can reproduce that range of brightness. That's because unlike SDR and previous transmission standards, ST 2084 was intentionally designed to
exceed the capabilities of modern displays, so that you could represent video in a way that more closely approximates how light exists scientifically, and allow displays to do the best that they can to reproduce that idealized representation. That way, better displays will display a picture that is increasingly close to physical reality and director intent. Contrast this with what used to happen with earlier formats where better displays just tended to produce a more vivid/colorful/bright, but unrealistic (from a scientific standpoint) image.
That process of mapping from the idealized world of ST 2084 to what the display can actually do is called
tone mapping. So, tone mapping is inherently part of the design of consumer HDR, and will be (for the foreseeable future), a critical part of any display, no matter how much you pay. You certainly can move the tone mapping out of the display and into an external processor like a Radiance Pro, but tone mapping is going to happen, always.
To the contrary, Dolby Vision brings a number of benefits to the table for real HDR on actual HDR displays.
First of all, tone mapping isn't an exact science. Since the underlying assumption in ST 2084 is that the signal cannot be exactly represented by the display, there are different approaches you could take in producing the displayed result. What Dolby Vision provides is a whole toolchain that extends from the content creator to the final tone mapping that happens in the display, including passing along metadata for each frame to help the display map the original source to what the display is capable of rendering in a way that preserves the director's intent.
There are other solutions to tone mapping that don't require this end-to-end flow and the extra metadata, and they can produce good results, but Dolby Vision gives greater control to the director and colorist to produce the desired result at the point of display.
Second, moving beyond the question of tone mapping, let's talk about color. The CE industry generally defines "HDR" as PQ (ST 2084) on top of the BT.2020 colorspace. PQ defines the luminance range, and BT.2020 defines the color area. Combined they form the
color volume, a.k.a. the range of colors and intensities that can be represented. In order to display a picture digitally, we need a coordinate system to pinpoint a color/intensity within this volume. Typically, we use YUV (YCbCr) coordinates to quantize images digitally in the CE space.
The "10" in "HDR10" and "HDR10+" means that those formats are using 10 bits per component to represent those points in the color volume. This is a bit of a bummer, because YUV isn't a very uniform coordinate system from a perceptual perspective.
i.e., some increments in coordinates lead to a larger perceivable change than others. It turns out that you really need 12 bits per component in YUV before the step from one arbitrary increment to the next becomes imperceptible to the average viewer. It's these perceptible steps that cause visible artifacts such as color banding in large areas of color, like the sky.
Here's where Dolby Vision comes into play. Dolby Vision Profile 5, which is what Strato V uses, employs the ICtCp coordinate system instead of YUV to represent those points within the volume. ICtCp is designed to be more perceptually uniform than YUV. In other words, coordinate increments that would've had a really small perceptual increment now make larger increments, but in exchange, coordinate increments that would've had a large perceptual increment will now have a smaller perceptual increment.
Crucially, this shifting of the coordinate system makes it such that all coordinate increments fall below the threshold of perceptibility for a typical human observer using only 10 bits of precision.
Why use 10 bits and switch to ICtCp instead of using YUV at 12 bits? Basically, because there aren't any hardware decoders available that do HEVC at 12 bits per component. So switching to ICtCp provides superior results while still fitting within the capabilities of existing HEVC hardware.
Displays, however, still use YUV, and modern ones that do Dolby Vision can accept 12-bit YUV. So after decoding, Strato V's system-on-chip converts 10-bit ICtCp, in hardware, to 12-bit YUV. The result is that you see better color with reduced visual artifacts. We've been really impressed by how great the Dolby Vision content looks on our reference displays as we've been producing the Dolby Vision versions of movies for Strato V.
[It perhaps bears mention at this point that this is one of the key differences between Dolby Vision Profile 5 and Profile 7, which is what is used on 4K Blu-ray discs. They are both seeking to solve the same problem -- how to get 12 bits of YUV precision out of a hardware decoder that has 10 bits of precision. Profile 7 takes advantage of the fact that the Blu-ray spec effectively necessitated the presence of a second, lower-resolution AVC decoder that could be run in parallel with the main decoder to support things like picture-in-picture. Profile 7 uses that second decoder to decode an "enhancement layer", which is then combined with the decoded 10-bit YUV main signal by a Dolby-designed block on the chip to produce a 12-bit YUV output signal. This clever solution allows for the main 10-bit "base layer" to be backward compatible with systems that don't support Dolby Vision, but outside of chips that are specifically designed for Blu-ray players, it makes more sense to accomplish the same task using a single stream and a single decoder. This is why, as mentioned earlier in this thread, SoC vendors don't produce chips that have the necessary hardware support for Profile 7.]
Third and finally, because of its greater perceptual uniformity, ICtCp as used in Dolby Vision Profile 5 has benefits from a compressibility standpoint. Video compressors are often designed with the assumption that all signal values are equal when making their visual error estimates and decisions during lossy compression. ICtCp better aligns with these assumptions, so the compressor is more likely to make a good decision in terms of what details of the picture it can compress away without affecting the visual perception of the quality.
Okay, well, this is a lot longer than I really wanted it to be. I hope that I've accurately communicated what my colleagues have helped me to understand, and I hope that it will prove useful.
Yeah, I'm fortunate to have a Terra Prime SSD at home to test with, and I have 10Gb fiber Internet. I regularly see ~2.3Gbps download speed, which is essentially as fast as that port can go when you factor in network overhead.
