Tweet
We are finally seeing true 4K 18Gbps content arriving, with in-field infrastructures not being able to support it.
Facebook Twitter Google+ Pinterest LinkedIn
We shouldn't be surprised when reports start flowing in with 4K UHD issues.
Jeff Boccaccio · May 19, 2016
We shouldn't be surprised when reports start flowing in with 4K UHD issues. We all saw this coming.
HDMI Rev 2.0 was touted as the new 4K@60Hz “high-end” resolution. Well it was 4K@60Hz, but the color was reduced dramatically to keep the bandwidth under the 10.2Gbps introduced in Rev 1.3 almost 10 years ago. Of course, every company that made HDMI products boasted it could handle “4K@60” … only the big Rev 2.0 change to higher bandwidth was not to become real hardware until almost two years later.
Meanwhile, digital content protection (DCP) created a new content protection scheme to “better protect” the material being played on our improved systems. Only problem, the first run of displays that supported 4K@60 came with or without HDCP 2.2, which can affect 4K@60 reproduction.
So to recap, Rev 2.0 was announced in September 2013. By the end of that year product was being touted as 4K@60. Not until mid-2015 do we start seeing true 4K@60 High Bandwidth product including HDR (high dynamic range). Now we have consumers thinking they bought max 4K, when they may not have. And we are finally seeing true 4K 18Gbps content arriving, with in-field infrastructures not being able to support it. This is almost a carbon copy of what happened under Rev 1.3.
In Rev 1.3 the bandwidth jumped from 5Gbps to 10Gbps, while most integrators and manufacturers were still playing in a 5Gbps sandbox. It worked, for a bit. Now, we are already getting calls due to the latest jump and seeing some equipment with dodgy interoperability.
One display we’ve been working with was claimed to be 4K UHD (18Gbps). After DPL’s testing process and interoperability evaluation, something didn’t look right. The numbers didn’t make sense, so we took out one of our analyzers. Well, it was not 18Gbps; it was a little less than 9! After talking to the manufacturer we find out that in the bowels of the remote’s options menu there is a switch allowing the display to go to true 18Gbps 4K — except it was factory set to off! Integrators don’t need such surprises.
Next, let’s go back to DCP, which decided to add on a few goodies to HDCP 2.2. Take, for example, some additional timing constraints. One is used as a new function called Locality — locality of what, you might say. They introduced it to effectively “ping” the length of your transmission line so they can tell how long it is. If it’s too long, they shut you off. Even crazier, the ping is set for 20ms (.02 seconds). This may sound small, but in our world it’s like covering a thousand miles. Just one more potential hiccup.
This basic instruction of the HDCP handshake eventsneeded to deliver 4K gives an idea of the encryption complexity. (Image provided by DPL Labs.)
What else is there? Shown the figure above is a basic HDCP instruction of events that takes place to get your system to run with 4K. Although this is a simplistic sample, it does demonstrate the amount of complexity there is to the encryption process (much more sophisticated than this).
On this same bus that carries the HDCP and EDID data is a new addition instruction called Status and Control. Here lies the instruction for each sink (display) to follow depending on resolution and encryption. If you are playing true 4K@60 UHD content some additional data has to be shared with the sink. In this case it is scrambling and TMDS clock frequency.
Now, should the user flip between one type of resolution to another, not only does EDID have to do its thing but the TMDS clock frequency changes to a quarter of the data rate rather than the one-tenth it was in Rev 1.4. At the same time, the TMDS scrambling has to be changed. It is also recommended to lower the clock output to reduce emissions.
That’s a lot of variables. We’ll keep updating our testing, and leave the phone lines open.
Facebook Twitter Google+ Pinterest LinkedIn
We shouldn't be surprised when reports start flowing in with 4K UHD issues.
Jeff Boccaccio · May 19, 2016
We shouldn't be surprised when reports start flowing in with 4K UHD issues. We all saw this coming.
HDMI Rev 2.0 was touted as the new 4K@60Hz “high-end” resolution. Well it was 4K@60Hz, but the color was reduced dramatically to keep the bandwidth under the 10.2Gbps introduced in Rev 1.3 almost 10 years ago. Of course, every company that made HDMI products boasted it could handle “4K@60” … only the big Rev 2.0 change to higher bandwidth was not to become real hardware until almost two years later.
Meanwhile, digital content protection (DCP) created a new content protection scheme to “better protect” the material being played on our improved systems. Only problem, the first run of displays that supported 4K@60 came with or without HDCP 2.2, which can affect 4K@60 reproduction.
So to recap, Rev 2.0 was announced in September 2013. By the end of that year product was being touted as 4K@60. Not until mid-2015 do we start seeing true 4K@60 High Bandwidth product including HDR (high dynamic range). Now we have consumers thinking they bought max 4K, when they may not have. And we are finally seeing true 4K 18Gbps content arriving, with in-field infrastructures not being able to support it. This is almost a carbon copy of what happened under Rev 1.3.
In Rev 1.3 the bandwidth jumped from 5Gbps to 10Gbps, while most integrators and manufacturers were still playing in a 5Gbps sandbox. It worked, for a bit. Now, we are already getting calls due to the latest jump and seeing some equipment with dodgy interoperability.
One display we’ve been working with was claimed to be 4K UHD (18Gbps). After DPL’s testing process and interoperability evaluation, something didn’t look right. The numbers didn’t make sense, so we took out one of our analyzers. Well, it was not 18Gbps; it was a little less than 9! After talking to the manufacturer we find out that in the bowels of the remote’s options menu there is a switch allowing the display to go to true 18Gbps 4K — except it was factory set to off! Integrators don’t need such surprises.
Next, let’s go back to DCP, which decided to add on a few goodies to HDCP 2.2. Take, for example, some additional timing constraints. One is used as a new function called Locality — locality of what, you might say. They introduced it to effectively “ping” the length of your transmission line so they can tell how long it is. If it’s too long, they shut you off. Even crazier, the ping is set for 20ms (.02 seconds). This may sound small, but in our world it’s like covering a thousand miles. Just one more potential hiccup.
This basic instruction of the HDCP handshake eventsneeded to deliver 4K gives an idea of the encryption complexity. (Image provided by DPL Labs.)
What else is there? Shown the figure above is a basic HDCP instruction of events that takes place to get your system to run with 4K. Although this is a simplistic sample, it does demonstrate the amount of complexity there is to the encryption process (much more sophisticated than this).
On this same bus that carries the HDCP and EDID data is a new addition instruction called Status and Control. Here lies the instruction for each sink (display) to follow depending on resolution and encryption. If you are playing true 4K@60 UHD content some additional data has to be shared with the sink. In this case it is scrambling and TMDS clock frequency.
Now, should the user flip between one type of resolution to another, not only does EDID have to do its thing but the TMDS clock frequency changes to a quarter of the data rate rather than the one-tenth it was in Rev 1.4. At the same time, the TMDS scrambling has to be changed. It is also recommended to lower the clock output to reduce emissions.
That’s a lot of variables. We’ll keep updating our testing, and leave the phone lines open.