The probability of successfully connecting any of the Macintosh devices in SFO-152 Commons to the ATEM production switcher through the Crestron DM switch is about 30%. HDCP negotiations fail with different probability when the machines are power cycled vs when they are restarted from the Apple menu. When HDCP negotiation fails there is no indication on the output of the DM Switch. The switch needs to operate reliably to be at all useful.
I think we need a Crestron engineer on site to provide a permanent fix.
The switch appears to be disallowing connection of HDCP enabled sources to non-authorized destinations regardless of the status of the HDCP encryption assertion. When non-protected content appears on a HDCP enabled device output, that content must be routed to both HDCP authorized destinations and HDCP non-authorized destinations. HDCP non-authorized destinations should only be disallowed when HDCP protection (encryption) is asserted. This is a critical problem for which we need an immediate fix.
Is this issue only with the ATEM switcher? We've seen the DM matrix reliably allow HDCP support enable/disable to the Vidyo codec with no issues. There could be an issue with the BlackMagic devices not passing HDCP. As for the non-protected content from a Mac, it is our understanding that the Mac applies protection to the digital video output whether or not the content is protected, requiring the input card on the matrix to be properly adjusted for HDCP support in order to show on protected outputs. I'm not sure it reports whether the content itself is protected, only that there is HDCP protection. We'll research this a bit more.
The ATEM is an SDI device. By definition SDI devices can't authenticate with HDCP. There is a difference between HDCP-authenticated and HDCP-enabled. The Crestron switch appears not to recognize this difference. We need to route non HDCP-authenticated content from HDCP-enabled sources to the ATEM. The Extron XTP switches have no problem doing this with Apple devices. We need the same capability in the DM. And we need an indicator to tell us when we are attempting to feed an HDCP-authenticated signal into a non-authenticating input. Extron does this by displaying a green screen.
I've just done some quick research and need to do a little more, but I can tell already what is possible as far as HDCP by input on the DM matrix. We can indicate when a source is HDCP-enabled on the input source (I have to look further into how to tell if it's HDCP-authenticated - you may be right about the DM not being able to tell the difference, but I will confirm). There is feedback available to tell when HDCP has disabled video, but I don't know that we can force a screen color like Extron does (I will research this as well), although it looks like we can at least add an indicator to the iPad's Crestron interface to tell when this has occurred. Until now, we have only included HDCP support enable/disable ("Movie Mode") for applicable sources in the iPad's User mode - we should try to find a way to squeeze some of these into the advanced routing page as well (although that page is getting a bit crowded - we may have to work together to come up with an acceptable layout for this). We should probably schedule a visit for John, Jason and myself for next week at a time when you can be there to help reproduce the issues and sign off on the necessary interface changes. Okay with you, Richard?
The routing page is already extremely crowded. ...and we have more things we need to control. At the rate we're going to wind up with a 3-iPad control surface (2 for routing 1 for audio). The right answer is to get our HTML control, so we have enough screen real estate to see what's going on. What's the status of real a real HTML interface to the DM? (Not a web clone of the iPad).
I think we just need to make sure that HDCP is completely disabled with the exception of movie mode. The Minis in particular seem to get into a state where they are only sending encrypted signals, regardless of content, and it takes a significant amount of messing around to get them working. This is a non-issue on the Extrons: We set "HDCP Authorized" to "Off" on the inputs, and the problem goes away. Our 'movie mode' enables it, with the understanding that we won't be able to route to certain devices in movie mode. However the DM is handling things, we end up unable to get signal from the minis to the ATEM without a non-deterministic number of reboots or reconfigs.
The Extrons are actually doing HDCP key management, and dealing with each output independently. I suspect Crestron didn't license the key technology and is just trying to manage things with the HDCP enabled signal alone. If so that's really bad and I can't see a recovery strategy. ...hope I'm wrong about that!
John, Aaron Can you send me a link to a protocol document that describes how to interact with the DM? At a minimum, I need the following commands: 1 - Read the model number of the switch 2 - Read the number of inputs on the switch 3 - Read the number of outputs on the switch 4 - Make a follow tie from input x to output y 5 - Make a video-only tie from input x to output y 6 - Make an audio-only tie from input x to output y 7 - Clear a tie between input x and output y 8 - Read the HDCP enabled status of input x 9 - Set the HDCP enabled status of input x 10 - Clear the HDCP enbled status of input x 11 - Read the HDCP authorized status of input x 12 - Read the HDCP content flags of the signal on input x
Short answer: yes, I can help you with this. Long answer: Crestron either doesn't have a published document for this or won't share it with us. I'll dig out all the commands via console and send them to you in a spreadsheet via email - today or as soon as I can find a test unit to connect to and gather commands.
HDCP control was added to the iPad control, but not on the routing page.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.