The living room worked yesterday. Today a streaming box feeds a soundbar, the soundbar feeds the television, and the television shows a black rectangle where a movie should be. The app's own menu draws fine. Audio sometimes keeps playing. Swapping in a new cable changes nothing, and neither does the second new cable bought because the first one seemed defective.
The usual advice is to call this a "handshake problem" and try things in a random order until something sticks. That phrase hides the useful detail. HDCP 2.x does not have one handshake with one pass-or-fail outcome. It has a sequence of checks, and three of them carry hard numeric ceilings written into the published specifications. Each ceiling fails with a different fingerprint. Learning which fingerprint you are looking at turns a night of cable swapping into one targeted change.
What the Protocol Measures at Each Stage
HDCP 2.x runs in stages. First comes authentication and key exchange, where the transmitter verifies that the device downstream holds a valid certificate. Then comes a locality check, where the transmitter measures how long a challenge takes to come back. Then session key exchange. Then, if the device downstream identified itself as a repeater rather than a final display, the repeater has to report everything sitting below it before the link is allowed to carry protected video.
The word "repeater" is where consumer hardware surprises people. An AV receiver is a repeater. A soundbar with HDMI passthrough is a repeater. An HDMI switch, a splitter, a matrix, a capture-passthrough box, and many powered extenders are repeaters. Each one is a device that receives protected content and re-transmits it, so each one has to authenticate upstream and authenticate downstream, and each one adds its own latency and its own reporting delay to the chain.
That is why the failure so often appears the day someone adds a box. The picture quality did not change. The number of participants in a timed protocol did. This is the same shape of problem covered in The Cable Is Not the Fault, where a Windows update, not the wire, left USB audio devices reporting Code 10. A cable that carries a menu at 1080p will carry a movie at 1080p. When the menu appears and the movie does not, the wire has already proven it can move pixels.
Ceiling One: Twenty Milliseconds on HDMI, Seven Milliseconds Elsewhere
The locality check exists so that a protected stream cannot be relayed to a distant device across a network. The transmitter sends a challenge, starts a watchdog timer, and requires the response back before that timer expires. Digital Content Protection LLC publishes the numbers in two separate documents, and the two numbers are not the same.
The interface-independent baseline sets the watchdog at 7 ms. The corresponding text in Digital Content Protection LLC's HDCP Interface Independent Adaptation Specification Revision 2.3 instructs the transmitter to set its watchdog timer to 7 ms, and says the locality check fails if that timer expires before the response message arrives. An IEEE 1722 working group contribution discussing the same adaptation states the requirement in one line: "The HDCP Transmitter enforces locality on the content by requiring that the Round Trip Time (RTT) between a pair of messages is not more than 7 ms."
Over HDMI the budget is larger. Digital Content Protection LLC's HDCP 2.3 on HDMI Specification sets the same watchdog at 20 ms, and the matching compliance test for HDCP 2.3 over HDMI checks the response against a 20 ms timeout at the transmitter. The HDMI document's 20 ms allowance is roughly triple the interface-independent figure.
Twenty milliseconds sounds generous until something in the path has to buffer, re-clock, or re-serialize the control channel. Long passive runs, cheap active cables, wall-plate extenders, and category-cable extender pairs can insert delay into exactly the channel being timed. The characteristic fingerprint is clean: the source drives the display directly with no trouble, and fails the moment a specific middle device is inserted, at every resolution, immediately, with no partial picture.
Ceiling Two: Three Seconds to Report the Room
The second ceiling is the one that explains an old piece of home-theater folklore: turn the television on first, then the receiver, then the source. That advice circulates without a reason attached. The reason is a three-second watchdog.
After the transmitter finishes session key exchange with a device that declared itself a repeater, it starts a timer and waits for that repeater to send up a list of the receiver IDs of everything below it. The interface-independent specification states the consequence plainly: "If the RepeaterAuth_Send_ReceiverID_List message is not received by the HDCP Transmitter within a maximum-permitted time of three seconds after transmitting SKE_Send_Eks message, authentication of the HDCP Repeater fails." Three seconds is 3,000 milliseconds, the third bar in the chart above. The compliance test suite for HDCP 2.3 over HDMI exercises the same three-second timeout directly.
Here is why the ordering advice works. A soundbar cannot report what is below it until it has itself authenticated the television below it. If the television is still switching inputs, still finishing a firmware check, or still waking its HDMI receiver block, the soundbar's downstream authentication is not finished when the streaming box's three seconds run out. The streaming box then fails its own authentication and stops encrypting, which the viewer experiences as a black screen. Powering the display first removes the delay from the middle of the budget.
The fingerprint for this ceiling is timing-shaped rather than topology-shaped. The chain is fine once everything has been on for a minute. It goes black at cold start, at input changes, after the display returns from standby, or when a set-top box wakes from deep sleep. Many devices retry, so a common version of this symptom is several seconds of black followed by a normal picture, repeated at every source change.
Ceiling Three: Thirty-One Devices and Four Levels
The third ceiling is structural rather than timed. Each repeater has to tally what sits below it and hand two counts upstream: how many devices in total, and how many levels deep the cascade runs. The interface-independent specification fixes both: "HDCP Repeaters must be capable of supporting DEVICE_COUNT values of up to 31 and DEPTH values of up to 4." Exceeding the device count produces the error the specification names MAX_DEVS_EXCEEDED, described in the same document as the error raised when a repeater's computed device count exceeds 31. Exceeding four levels of cascade produces the parallel condition the specification labels MAX_CASCADE_EXCEEDED.
A typical household will not approach 31 devices. That limit bites in conference rooms, sports bars, and retail walls fed from a matrix. The depth ceiling is the one an ordinary living room can reach, because four is a smaller number than it looks once every passthrough box counts as a level. A streaming box into an HDMI switch, into an AV receiver, into a soundbar, into a second switch behind the television already sits at four. Add a powered splitter feeding a second room and the count goes past the ceiling.
Unlike the timing ceilings, this one is deterministic. It fails the same way on each attempt, immediately, regardless of warm-up or power order, and it keeps failing until a level is removed from the chain. Collapsing a level usually means running audio over eARC from the television instead of chaining the soundbar in the video path, or retiring a switch that exists only because the receiver ran out of inputs.
Matching the Symptom to the Ceiling
The three ceilings produce three different patterns, and the pattern is usually visible before any test equipment comes out. A locality failure is tied to a place in the chain. A receiver-ID-list failure is tied to a moment in time. A depth failure is tied to a count. If a symptom moves when you change the power-on order, it is not the depth ceiling. If a symptom moves when you remove a specific box but not when you change the order, it is not the watchdog.
There is a fourth pattern worth separating out, because it is the one people mistake for HDCP most often: bandwidth. Sparkles, intermittent dropouts, or a picture that holds at 4K60 and collapses at 4K120 point at the physical link rather than the content protection layer. HDMI Licensing Administrator's HDMI Cables: Different Cable Types lists the tested classes, including High Speed at up to 10.2 Gbps, Premium High Speed certified for 4K at up to 18 Gbps, and Ultra High Speed applicable to configurations up to 48 Gbps supporting 8K at 60 and 4K at 120. A content-protection failure is binary and immediate. A bandwidth shortfall degrades.
A Test Order That Separates the Three
Work from the outside in, and change one variable per test. Connect the source straight to the display, bypassing everything, and play the protected title that fails. If that works, the source and display are both capable and the problem lives in the middle. If that also fails, the version question comes first, before any timing theory.
Second, reinsert one middle device at a time and note which insertion breaks it. An insertion that breaks the link instantly and consistently points at locality or at depth, and the two are told apart by count: if you are at four passthrough boxes or fewer, suspect locality in that specific device.
Third, test the power-on order deliberately. Display on and settled, then each repeater from the display end back toward the source, then the source last. If the picture returns under that order and fails under the reverse, you have identified the three-second budget rather than anything structural.
Fourth, check versions against published specifications rather than product listings. Apple's Apple TV 4K (3rd generation) Tech Specs lists HDMI 2.1 and notes that protected playback "Requires HDCP when playing protected content and compatible TV or receiver." On a Windows PC the operating system exposes the link state to applications through the output protection interface described in Microsoft's OPM_GET_CONNECTED_HDCP_DEVICE_INFORMATION reference, which returns the connected device's key selection vector and whether that device is a repeater. That second field is the one worth noting, because it confirms in software what the rack looks like in hardware.
Fifth, check firmware on every repeater in the path before replacing hardware. Handshake behavior at these boundaries is implementation-sensitive, and receiver and soundbar makers have shipped corrections for it. Reading the device's own reported identity before rebuilding the chain is the same discipline as in Check the Second Hex Digit Before Rebuilding a MAC Filter: the identifier already on screen often answers the question that a rebuild was going to ask.
What to Give Vendor Support
Support scripts start at the cable because the cable is cheap to rule out. You can skip several steps by opening with the discriminating facts rather than the symptom. State the full chain in order, source to display, with model numbers. State which insertion breaks it. State whether power-on order changes the outcome. State the count of passthrough devices. State the exact format that fails and the nearest format that works.
That set of five facts maps directly onto the ceilings above, and it tells an escalation engineer which of them you have already excluded. It also protects you from the most expensive wrong turn, which is replacing a display over a fault that lives in a switch two boxes upstream.
When This Doesn’t Apply
These numbers describe HDCP 2.x. Older equipment in the path may be running HDCP 1.4, so a chain mixing generations will not behave as a single model predicts. If any device in the path tops out at HDCP 1.4, the protected 4K stream is typically refused or downgraded at the source regardless of timing.
The ceilings are also specification requirements rather than a description of how every shipping product behaves. A device may enforce a tighter margin than the published figure, may retry where another device gives up, or may carry a firmware defect that fails authentication for reasons unrelated to any ceiling here. Compliance testing checks the published values; it does not make every implementation identical.
Several common failures look like HDCP and are not. A display set to the wrong HDMI input, an eARC path that carries audio while the video path is broken, a streaming app enforcing its own device policy, an account or regional restriction on a specific title, and a graphics driver that has dropped its protected path after an update all produce black or downgraded video. If the same title fails on a completely different display in a different room, the chain in front of you is probably not the variable.
Finally, the depth and device counts describe what a repeater reports, not what a room contains. Passive splitters, fixed-function adapters, and simple cable couplers do not authenticate, so they do not add a level. Counting every object between source and display will overstate the depth and send you chasing a ceiling you are nowhere near.
The Short Version
When a chain shows menus but refuses protected video, three published numbers do most of the diagnostic work. Twenty milliseconds is the round-trip budget for the locality check over HDMI, against 7 ms for the interface-independent baseline, and it is defeated by whatever sits in the middle. Three seconds, or 3,000 milliseconds, is how long a transmitter waits for a repeater to report what is below it, which is why power-on order matters. Four levels of repeaters and 31 devices are the structural ceilings, and four is the one a living room can reach. Identify which fingerprint you have before buying anything, because the cable has usually already proven itself.
Comments
Post a Comment