A newer version of this document is available. Customers should click here to go to the newest version.
3.6.3. Frequently Asked Questions (FAQ)
|1.||The RX is receiving encrypted video, but the TX is sending a static video in blue or black colour.||This is due to the unsuccessful TX authentication with external sink. A HDCP-capable repeater must not transmit the video in unencrypted format if the incoming video from the upstream is encrypted. To achieve this, a static video in blue or black colour replaces the outgoing video when the TX HDCP encryption status signal is inactive while the RX HDCP decryption status signal is active.
For the exact guidelines, refer to Security Considerations. However, this behaviour may deter the debugging process when enabling the HDCP design. Below is the method to disable the video blocking in the design example:
|2.||TX HDCP encryption status signal is active but snow picture is displayed at the downstream sink.||This is due to the downstream sink does not decrypt the outgoing encrypted video correctly. Make sure you provide the global constant (LC128) to the TX HDCP IP. The value must be the production value and correct.|
|3.||TX HDCP encryption status signal is unstable or always inactive.||This is due to the unsuccessful TX authentication with downstream sink. To facilitate the debugging process, you can enable the DEBUG_MODE_HDCP parameter in hdcp.c.
Refer to Modifying HDCP Software Parameters on the guidelines.
The following 3a-3c are the possible causes of unsuccessful TX authentication.
|3a.||The software debug log keeps printing this message “HDCP 1.4 is not supported by the downstream (Rx)”.||The message indicates the downstream sink does not support both HDCP 2.3 and HDCP 1.3. Make sure the downstream sink supports HDCP 2.3 or HDCP 1.3.|
|3b.||TX authentication fails halfway.||This is due to any part of the TX authentication such as signature verification, locality check etc can fail. Make sure the downstream sink is using production key but not facsimile key.|
|3c.||The software debug log keeps printing “Re-authentication is required” after the HDCP authentication is completed.||This message indicates the downstream sink has requested re-authentication because the received video was not decrypted correctly. Make sure you provide the global constant (LC128) to the TX HDCP IP. The value must be the production value and the value is correct.|
|4||RX HDCP decryption status signal is inactive although the upstream source has enabled HDCP.||This indicates that the RX HDCP IP has not achieved the authenticated state. By default, the REPEATER_MODE parameter is enabled in the design example. If the REPEATER_MODE is enabled, make sure the TX HDCP IP is authenticated.
When the REPEATER_MODE parameter is enabled, the RX HDCP IP attempts authentication as a repeater if the TX is connected to a HDCP-capable sink. The authentication stops halfway while waiting for the TX HDCP IP to complete the authentication with downstream sink and pass the RECEIVERID_LIST to the RX HDCP IP. Timeout as defined in the HDCP Specification is 2 seconds. If the TX HDCP IP is unable to complete the authentication in this period, the upstream source treats the authentication as fail and initiates re-authentication as specified in the HDCP Specification.
|5||RX HDCP decryption status signal is unstable.||This means the RX HDCP IP has requested re-authentication right after the authenticated state is achieved. This is probably due to the incoming encrypted video is not decrypted correctly by the RX HDCP IP. Make sure the global constant (LC128) provided to the RX HDCP IP core is production value and the value is correct.|
Did you find the information on this page useful?