To reduce latency without affecting user experience, the following optimizations can be carried out:
1. The delay introduced by live broadcast encryption is generally between 5 and 200 ms. Professional and low delay quality live broadcast encryption equipment can be used to reduce the delay.
2. The DRM client decrypts the video with a delay of 2~50ms, which has little impact, and it usually takes 200~700ms to obtain and process a DRM license. The following strategies can be used to avoid the delay:
1)Prefetch the DRM license (issue the license to the DRM Client in advance that the program is start to play).
2)Avoid key change(such as using the same key during the same series of programs).
3)Obtain the license at one time and issue multiple program keys (when obtaining the license of a live program , the keys of other live programs are attached).
4)For on-demand video, the video content for a period of starting time is not encrypted, and the DRM license request is completed during this time.

Terminal devices purchased in the consumer market such as the HUAWEI V75 smart TV, use DRM client production certificate, so the server should use production certificates accordingly. There are two methods as follows:
① Use the Key Gateway Server provided by DTA. The Key Gateway Server is connected with DRM license server( use production certificate) provided by DTA partners, and can provide DRM license services to terminals for testing and evaluation. Testers can use DTA Key Gateway Server in two ways:
Mode 1: inform DTA of the key information and IP white list to configure the key and open the access permission. The key information includes CEK, CEK ID, CID, and the white list includes the terminal IPs.
Mode 2: according to the interface document provided by DTA, realize the connection between the manufacturer's key management service and the DTA Key Gateway Server.
② Order a set of server production certificates from DTA and place them in the DRM server.

After obtaining the license response, the video APP should parse the "status" field in the message. If it is "success", it meets the playback conditions, otherwise it can terminate the playback. The video APP should intercept the exception of provideKeyResponse (the interface for processing license response). If the exception is intercepted, the playback can be terminated.

Video APP can use the following example code (taking Android platform as an example) to determine whether the terminal supports ChinaDRM:
public static boolean checkSupportChinaDRM(){
boolean isSupportCDRM = false;
byte[] sessionId = null;
MediaDrm mediaDrm = null;
String statusString = null;
UUID drmScheme = new UUID(0X3D5E6D359B9A41E8L, 0XB843DD3C6E72C42CL);//ChinaDRM UUID
try {
if (Util.SDK_INT < 18) {
statusString = "Protected content not supported on API levels below 18";
} else if (!MediaDrm.isCryptoSchemeSupported(drmScheme)) {
statusString = "This device does not support the required DRM scheme";
} else {
mediaDrm = new MediaDrm(drmScheme);
sessionId = mediaDrm.openSession();
isSupportCDRM = true;
statusString = "check ChinaDRM ok!";
}
} catch (NotProvisionedException e){
statusString = "drm certifate not found!";
}catch (Exception e) {
Log.i(TAG, "catched Exception:" + e.getMessage());
statusString = "exception:" + e.getMessage();
}
if (mediaDrm != null && sessionId != null) {
mediaDrm.closeSession(sessionId);
}
Log.i(TAG, statusString);

return isSupportCDRM;
}
The Android video app uses MediaDrm. getPropertyString ("securityLevel") to determine the security level of the client. The DRM license server can determine the security level (SW indicates software security level, HW indicates hardware security level, and EH indicates enhanced hardware level) identified by the Common Name field of the DRM client certificate body carried in the license request sent by the DRM client, so as to confirm the security level of the terminal device.

The video APP integrates DRM software level client inside APP itself, and so the video APP should be secured. The DRM security level can reach the software security level at most. The security reinforcement methods for video APP include code confusion, shelling, using the security related capabilities of the operating system (such as anti recording and anti screenshot capabilities), anti root, digital watermarking, and so on.

The video watermark can trace the source of pirated video generated through screen recording, screen capture, shooting, signal acquisition and other methods when playing. It is recommended to use with DRM. Identification information (digital watermark information) can be added in the code stream, video playing layer and other places.

If the terminal has DRM capability, the video application should give priority to the terminal's own security decoder. If the protection security level of the content is hardware level, only the security decoder can be selected. If the terminal does not have DRM capability, the video application will use the software security level DRM client built in the application, and the decoder built in the video application or the normal decoder provided by the terminal. Only by using the security decoder provided by the terminal, the terminal can achieve to prevent screen recording and screen capture (the results of screen recording and screen capture are null and black) by using the SVP(Secure Video Path).

Terminals in the test phase, such as set-top boxes and smart TVs, are recommended to use the development certificate and connect the DRM server with the development certificate. DTA provides DRM server with development certificate, which can be used for debugging and testing of test terminals. Reference to the article(Resource->Client integration test env->User Manual for Client Integration Testing Environment).

The ChinaDRM client supports the CENC standard AES algorithm (generally supporting the cbcs mode algorithm), but it should be noted that the DRM description information format (i.e. pssh format) and DRM license protocol between ChinaDRM and widevine are different. After the video and audio application obtains the PSSH in the widevine stream index file,
Processing method 1: The video and audio applications should generate the ChinaDRM format PSSH by widevine PSSH and then do subsequent processing, such as encapsulating the license request, requesting the ChinaDRM license and processing the license. Note that the base64string code of the keyId resolved from widevine PSSH can be used as the contentId of ChinaDRM.
Processing mode 2: The video and audio application directly transmits widevine PSSH to the ChinaDRM client, the ChinaDRM client encapsulates the license request and the video and audio application sends it to the ChinaDRM license server. After receiving the license request, the ChinaDRM license server obtains widevine PSSH from the contentIDs field in the request, parses the keyId from it and obtains the keyValue from key management server, thereby encapsulating the ChinaDRM license response. The base64string code of the keyId can be used as the contentId of ChinaDRM. Mode 2 relies on the ChinaDRM client to support the parameter of widevine PSSH.
ChinaDRM multiplexes Fairplay encrypted stream (only using CENC cbcs mode encryption) in the same way.