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. "