DTCP-IP to HLS Stream Conversion for Secure Playback

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current systems for securely streaming copy-protected media content from digital video recorders to mobile devices face challenges in converting DTCP-IP media streams into a format readable by native media players on secondary devices without allowing unauthorized access.

Innovation Solution

The process involves receiving an encrypted DTCP-IP transport stream, chunking it, adding HLS padding bytes, and re-encrypting it to create HLS chunks, which are then loaded onto a media proxy server, along with a DTCP key, to enable playback by a native media player on the secondary device.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If DTCP-IP encryption is used to protect media content during transfer, then content security is improved, but the media stream cannot be directly played by native media players

Engineering Contradiction:
Improvecontent securityVSAvoidmedia player compatibility
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent introduces an intermediary conversion process that translates DTCP-IP encrypted streams into HLS format. The system acts as a mediator between the DTCP-IP source and HLS-compatible players, converting the encryption format while maintaining security through re-encryption of the converted stream.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent changes the encryption parameter from DTCP-IP to HLS encryption format. By transforming the cryptographic parameters and format of the encrypted stream, the system maintains security (through re-encryption) while achieving compatibility with different media players that support HLS format.

Inventive Principle:
Principle #35Parameter changes

2Adaptability or versatility

If full decryption of DTCP-IP stream is performed, then media player compatibility is improved, but content security is compromised

Engineering Contradiction:
Improvemedia player compatibilityVSAvoidcontent security
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The system uses an intermediary conversion process that avoids full decryption exposure. Instead of completely decrypting the DTCP-IP stream, it performs format translation while maintaining encryption, acting as a secure bridge between incompatible formats without exposing clear content.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent converts the limitation of encryption format incompatibility into a benefit by implementing format translation with re-encryption. The original encryption constraint becomes advantageous by enabling secure format conversion rather than requiring complete decryption and re-encryption from scratch.

Inventive Principle:
Principle #22Blessing in disguise (Convert harm into benefit)

3Adaptability or versatility

If format conversion is implemented, then media player compatibility is improved, but system complexity increases

Engineering Contradiction:
Improvemedia player compatibilityVSAvoidconversion system complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements a dedicated format conversion system that handles the complexity of translating between DTCP-IP and HLS formats. This intermediary conversion infrastructure manages the technical complexity centrally, allowing the rest of the system to remain simple while achieving format compatibility.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentEP2954684B1DLNA/DTCP stream conversion for secure media playback
Publication Date: 2021.05.05 ARRIS ENTERPRISES LLC
  • EP2954684B1 patent drawingFigure 1~2
  • EP2954684B1 patent drawingFigure 3
  • EP2954684B1 patent drawingFigure 4

AI summary

A process for converting a DTCP-IP transport stream into HLS format, comprising receiving an encrypted DTCP-IP transport stream comprising DTCP frames at a secondary device from a source device, with each of the plurality of DTCP frames comprising encrypted 16-byte portions, forming chunks from the DTCP frames by grouping encrypted 16-byte portions into a chunk, adding HLS padding bytes to the end of each chunk and encrypting the HLS padding bytes to form an encrypted chunk, loading each of the encrypted chunks and a playlist to a media proxy server at the secondary device, loading a DTCP key onto a security proxy server, and providing the playlist, each of the encrypted chunks, and the DTCP key to a native media player on the secondary device, such that the native media player follows the playlist to decrypt the encrypted chunks using the DTCP key and plays back the chunks.