Every month brings new discoveries in our labs at DPL as products move deeper into High Speed 4K (18Gbps). We get to see more products trying to achieve these new demands, with mixed results.
It’s not that these products are unable to make the bandwidth requirement for the video data under these newer types of formats, but has more to do with how well the remainder of the data is managed. Notice I said “the remainder of the data” because there is much more data to deal with in addition to increased video content.
When people talk about HDMI video transmission, it is generally focused on bandwidth. Although this is a very important part of the interface, it is clearly not the only part that makes Rev 2.0b tick.
This is what we are discovering as new products enter into test. In many cases, products are now coming in before requesting certification because of issues being discovered by manufacturers when used under normal operating conditions within a full system environment during beta testing.
As we’ve all experienced, just because a product can pass an HDMI test does not mean it will always work within varied system environments. Under Rev 2.0b this only gets more complicated.
The illustration above demonstrates the increased data seen on the New DDC bus compared to the Old and how it is now constantly being used by all the additional tasks. In fact, there is so much data that some of it had to be put up on other channels within the HDMI interface. So what kind of data is clogging up the pipe?
In the past, the DDC channel only had to deal with two major tasks: EDID and HDCP. Under Rev 2.0b there is much more.
One is called SCDC, aka Status Control. A portion of these commands check on whether the display can in fact support the 4K requirements. It first pings a response to see if the display can jump into the new scrambling (Terc 4) process. If this comes back as a go, then it is expected the display will start to switch over to the scrambling transmission specified under Rev 2.0b. If not, it reverts back to Rev 1.4b rules.
within the HDMI
interface.
We are finding products that cannot lock onto this mode, thus ending that type of 4K 18Gbps transmission. Some actually turn on and off continually as the source cannot harness a permanent lock on this function.
We have seen a large assortment of reasons why this occurs which, in most cases, can be corrected. Symptoms can range from intermittent video to no video at all yet 4K@30 data seems to operate just fine. Don’t go on the assumption that just because you have 4K@30 you are almost there, when in this case you are far from it.
There is more. Under Rev 2.0b HDMI brings new error correction for the video content. This operation is somewhat straightforward. The display is the flag holder on this.
Should errors occur, the display reports them back to the source. The source then tallies these errors and depending on the source being used has the right to shut down the video until either a hard HotPlug is initiated, a system shutdown is enacted, or a restart by pulling the cable out of the display.
But remember, these can be logical errors and not necessary bit errors. This raises the stakes if no bit errors are detected in test.
Additionally, HDCP has increased dramatically in its communication dynamic, forcing some data to be bumped into other parts of the transmission line. So the DDC bus traffic is pretty intense, requiring an even better data performance over this bus.
Is there more? Of course, so stay tuned as we continue to unearth more dirt and new problems that begin to surface during testing.
