Hacker News Reader

Comment by oneplane | Hacker News Reader

That's not 'noise', that is packets that didn't make it. It's not having a perfect picture vs. no picture, but about data packets either going from A to B or not going from A to B.

Say the HDMI cable is crap and it can only do 100 packets per second, and HDR needs 1000 packets per second, the HDMI chips are going to negotiate a HDMI transfer settings without HDR. Going back further, say the HDMI data path is negotiated to do only basic HDMI, say, DVI-like video. If even that is too much for the cable to handle, say, it constantly drops a few packets, you would get either perfect pixels or missing pixels.

View on HN

HDMI doesn't have packets. It's largely digital VGA. It's very easy to flick individual bits, and the effect is basically the same as analog noise.

The only difference is the threshold.

You are correct. I suppose serial data is more like a clocked stream than packets. Perhaps I was thinking of TDMA instead of TDMS. Flicking bits is easy indeed, which should be mostly mitigated with the requirements on the conductor and shielding.

> very easy to flick individual bits

Is there any error correcting code/protocol in HDMI spec to fix individual bit flips?

No. There's an 8b/10b encoding to balance current but that doesn't help you fix much of anything.

Displayport has packets with a checksum but I don't think there's any resending, only discarding.

hdcp

hdcp uses the DDC AFAIK. The data is scrambled but still RGB.

but wont decode if randomly modified

It's a stream based cipher, so you'll get the same amount of blips as you'd get with normal bit damage. Difference is probably that you can get a whole missing frame as a blip instead of just missing pixels, because the stream key operates on frames instead of single pixels.

You are right. I went back and read hdcp spec. Now I understand my confusion. What I experienced multiple times with hdcp and bad/low quality cable/connection was screen going blank for a short moment. I always assumed it was cryptography itself breaking apart, but the spec requires resetting connection in case of logged TMDS layer errors

" While the receiver may reach a determination sooner, the receiver must determine loss of synchronization at least by the time it has detected 50 consecutive data island packets with ECC errors. The HDCP Receiver must either assert the REAUTH_REQ bit of the RxStatus register or de-assert HDCP_HPD to the upstream transmitter once it determines loss of synchronization. "

Reply on news.ycombinator.com