6 ms·

> it's either going to make it or it isn't This isn't _strictly_ true - I've seen basically the equivalent of noise in a HDMI picture (white dots all over the

> it's either going to make it or it isn't This isn't _strictly_ true - I've seen basically the equivalent of noise in a HDMI picture (white dots all over the picture), and eventually tracked it back to a faulty HDMI cable. I did replace it with the cheapest (<£5) HDMI cable I could find though, so there is that.

oneplane 8y ago
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.
- Dylan16807 8y ago
  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.
  - rasz 8y ago
    hdcp
    - oneplane 8y ago
      hdcp uses the DDC AFAIK. The data is scrambled but still RGB.
      - rasz 8y ago
        but wont decode if randomly modified
        oneplane 8y ago
        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.
        rasz 8y ago
        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. "
  - oneplane 8y ago
    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.
  - ttflee 8y ago
    > very easy to flick individual bits Is there any error correcting code/protocol in HDMI spec to fix individual bit flips?
    - Dylan16807 8y ago
      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.

oneplane 8y ago

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.

Dylan16807 8y ago
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.
- rasz 8y ago
  hdcp
  - oneplane 8y ago
    hdcp uses the DDC AFAIK. The data is scrambled but still RGB.
    - rasz 8y ago
      but wont decode if randomly modified
      - oneplane 8y ago
        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.
        rasz 8y ago
        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. "
- oneplane 8y ago
  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.
- ttflee 8y ago
  > very easy to flick individual bits Is there any error correcting code/protocol in HDMI spec to fix individual bit flips?
  - Dylan16807 8y ago
    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.