Powered by Google-Search & Google-Books Chinese Standards Shop Database: 169759 (Oct 25, 2020)
HOME   Quotation   Tax   Examples Standard-List   Contact-Us   View-Cart
  

GYT277-2019

Chinese Standard: 'GYT277-2019'
Standard IDContents [version]USDSTEP2[PDF] delivered inStandard Title (Description)StatusRelated Standard
GY/T 277-2019English1559 Add to Cart Days<=10 Technical specification of digital rights management for video audio content distribution Valid GY/T 277-2019
GY/T 277-2019Chinese45 Add to Cart <=1-day [PDF from Chinese Authority, or Standard Committee, or Publishing House]  

   

BASIC DATA
Standard ID GY/T 277-2019 (GY/T277-2019)
Description (Translated English) (Video and audio content distribution digital rights management technical specifications)
Sector / Industry Radio, Film & TV Industry Standard (Recommended)
Word Count Estimation 77,797
Date of Issue 2019-07-05
Date of Implementation 2019-07-05
Older Standard (superseded by this standard) GY/T 277-2014
Regulation (derived from) Natural Resources Department Announcement No. 7 of 2019

C.4 Interface Call Process ... 56
Appendix D (Normative Appendix) DRM Client Operating Environment Interface ... 57
D.1 Constant definition ... 57
D.2 Data Structure Definition ... 60
D.3 Interface Definition ... 61
Foreword
This standard was drafted in accordance with the rules given in GB/T 1.1-2009.
This standard replaces GY/T 277-2014 "Technical Specifications for Internet TV Digital Rights Management". Compared with GY/T 277-2014,
The technical changes are as follows.
-Revised scope (see Chapter 1, Chapter 1 of the.2014 edition);
-Revised normative references (see Chapter 2, Chapter 2 of the.2014 edition);
-Revised terms and definitions, changed DRM agent to DRM client (see Chapter 3, Chapter 3 of the.2014 edition);
-Revised the overview (see Chapter 5.1, Chapter 5 of the.2014 edition);
-Revised the logical architecture (see Chapter 5.2, Chapter 5 of the.2014 edition);
-Added content authorization (see 5.3);
-Added key management (see 5.4);
-The security mechanism has been modified (see 5.5, 9.2 in the.2014 version);
--Modified the trust model (see 5.6,.2014 version 9.1);
-Added content encryption method (see 6.2);
-Modified the content packaging format (see Chapter 6.3, Chapter 6 of the.2014 edition);
-Revised license structure (see 7.1,.2014 version 7.1);
-The license code has been modified (see 7.2,.2014 version 7.2);
-Revised license acquisition agreement (see Chapter 8, Chapter 8 of the.2014 edition);
-Added DRM server (see Chapter 9);
-Added DRM client (see Chapter 10);
-Added digital certificate format, online certificate authentication protocol and certificate revocation list format (see Appendix A);
--Modified the cryptographic algorithm (see Appendix B, Appendix A of the.2014 edition);
-Added DRM client functional interface (see Appendix C);
-Added DRM client runtime environment interface (see Appendix D);
-Removed the description of adding support for ChinaDRM in the streaming media based on the HLS protocol (see Appendix B of the.2014 edition).
This standard is under the jurisdiction of the National Radio, Film and Television Standardization Technical Committee (SAC/TC 239).
This standard was drafted. State Administration of Radio and Television, Academy of Radio and Television Science, China Central Radio and Television Station, Shenzhen Hisilicon
Co., Ltd., Intel (China) Co., Ltd., Beijing Jiangnan Tianan Technology Co., Ltd., Beijing Digital Taihe Technology Co., Ltd.,
Beijing Yongxin Shibo Digital TV Technology Co., Ltd., Beijing Digital Video Technology Co., Ltd., Irdeto Technology (Beijing) Co., Ltd.,
Shanghai Guomao Digital Technology Co., Ltd., Huashu Digital TV Media Group Co., Ltd., Guangdong South New Media Co., Ltd., China Communications
Media University, Beijing ATV Information Technology Co., Ltd., BesTV Network TV Technology Development Co., Ltd., Hunan Happy Sunshine Interactive Entertainment
Music Media Co., Ltd., Beijing iQiyi Technology Co., Ltd., Alibaba (China) Co., Ltd., Liaoning Radio and Television Station, Shanghai Culture
Radio and Television Group Co., Ltd., Beijing Radio and Television Station.
The main drafters of this standard. Ding Wenhua, Guo Peiyu, Pan Xiaofei, Wang Lei, Tian Zhong, Liang Zhijian, Wu Di, Mei Xuelian, Zhao Yunhui, Zhao
The patent holder has assured the publisher of this document that he is willing to work with any applicant on reasonable and non-discriminatory terms and conditions,
Negotiating patent licenses. The patent holder's statement has been filed with the issuing agency of this document, and relevant information can be obtained through the following link
Ways to get.
Patent Owner Contact Address Contact Postcode Phone Email
Radio and television science
Institute
Revival of Xicheng District, Beijing
2 Menwai Avenue
Meng Xiangkun 100866 010-86098010 mengxiangkun@abs.ac.cn
Please note that in addition to the above patents, some content of this document may still involve patents. The issuer of this document is not responsible for identifying these patents
Responsibility.
Technical specifications for digital rights management of video and audio content distribution
1 Scope
This standard specifies the logical architecture, technical mechanism, content encryption, license format, and license for digital rights management of video and audio content distribution.
Certificate acquisition agreement, and related technical requirements of DRM server and DRM client.
This standard applies to the copyright protection of digital TV, IPTV, Internet TV and other video and audio content distribution processes.
2 Normative references
The following documents are essential for the application of this document. For dated references, only the dated version applies to this document.
For undated references, the latest version (including all amendments) applies to this document.
GB/T 17964-2008 Information security technology block cipher algorithm working mode
GB/T 20518-2018 Information Security Technology Public Key Infrastructure Digital Certificate Format
GB/T 32097-2016 Information Security Technology SM4 Block Cipher Algorithm
GB/T 32905-2016 Information Security Technology SM3 Password Hash Algorithm
GB/T 32918.2-2016 Information Security Technology SM2 Elliptic Curve Public Key Key Algorithm Part 2. Digital Signature Algorithm
GB/T 32918.4-2016 Information Security Technology SM2 Elliptic Curve Public Key Key Algorithm Part 4. Public Key Encryption Algorithm
GB/T 36322-2018 Information Security Technology Cryptographic Equipment Application Interface Specification
GY/T 257.1-2012 Advanced Audio and Video Coding and Decoding for Radio and Television Part 1. Video
GY/T 299.1-2016 High-efficiency audio and video coding Part 1. Video
ISO 14496-12..2015 Information technology. Audio and video object coding. Part 12. ISO Basic Media File Format (Information
technology-Coding of audio-visual objects-Part 12. ISO base media file format)
ISO 23001-7..2016 Information Technology MPEG System Technology Part 7. ISO Basic Media File Format File General Encryption
(Information technology-MPEG systems technologies-Part 7. Common encryption in ISO base
media file format files)
ISO 23009-4..2013 Information technology. HTTP-based dynamic adaptive streaming (DASH). Part 4. Segment encryption and authentication
(Information technology-Dynamic adaptive streaming over HTTP (DASH)-Part 4. Segment
encryption and authentication)
IETF RFC 2045 Multi-Target Internet Mail Extensions Part 1. Internet Message Body Format (Multipurpose
internet mail extensions-Part 1. Format of internet message bodies)
IETF RFC 2104 HMAC. Keyed-Hashing for Message
Authentication)
IETF RFC 2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol-OCSP (X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol-OCSP)
IETF RFC 3279 Internet X.509 Public Key Infrastructure Certificates and Certificate Revocation List Algorithms and Identification (Algorithms and
Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile)
IETF RFC 3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List (CRL) Profile)
ECMA 404 The JSON data interchange format
3 terms and definitions
The following terms and definitions apply to this document.
3.1
Content provider
A functional entity that owns digital media content and provides digital media content with copyright information.
3.2
License
Description of control information such as digital media content access rights, usage rules and keys.
3.3
Device
An entity that consumes content with a DRM client installed.
3.4
DRM client
A trusted entity in the device that enforces permissions and restrictions related to DRM content.
3.5
DRM server DRM server
An entity that provides license services to DRM clients.
3.6
DRM content
Digital media content managed with DRM technology.
3.7
Ciphertext
Encrypted information.
3.8
Encryption
In order to generate ciphertext, that is, the information content of hidden data, the data is (reversibly) transformed by a cryptographic algorithm.
3.9
Decryption
The reverse process corresponding to the encryption process. That is, the ciphertext data is inversely transformed by a cryptographic algorithm.
3.10
Key
A sequence of symbols that controls cryptographic transformation operations such as encryption, decryption, calculation of cryptographic check functions, signature generation, or signature verification.
3.11
Digital signature
Some data attached to the data unit, or a cryptographic transformation made to the data unit, used to verify the authenticity of the source of digital information
And data integrity.
4 Acronyms
The following abbreviations apply to this document.
CA Certification Authority
CBC Cipher Block Chain
CEI Content Encryption Information
CEK Content Encryption Key
CENC Common Encryption
ChinaDRM China Digital Rights Management
CRL Certification Revocation List
DASH Dynamic Adaptive Streaming over HTTP
Distinguished Encoding Rules of DER ASN.1
DRM Digital Rights Management
HLS HTTP Live Streaming Protocol
HMAC Hashed Message Authentication Code
HTTP Hyper Text Transport Protocol
ISO International Organization for Standardization
IV Initialization Vector
JSON JS Object Notation
MPD Media Presentation Description
NAL Network Abstract Layer
OCSP Online Certificate Status Protocol
PKI Public Key Infrastructure
PMT Program Mapping Table
SEI Supplemental Enhancement Information
TS Transport Stream
URI Uniform Resource Identifier
URL Uniform Resource Locator
UTC Coordinated Universal Time
UUID Universally Unique Identifier
uimsbf unsigned integer, most significant bit first
5 Architecture
5.1 Overview
This standard defines the end-to-end logical architecture of digital rights management for video and audio content distribution based on cryptographic technology, PKI technology and authorization technology,
Content authorization, key management, security mechanisms, and trust models. Adopt the logical architecture, technical mechanism, basic format and protocol defined in this standard,
Can build an end-to-end digital rights management system for video and audio content distribution.
5.2 Logical architecture
Digital rights management system for digital distribution of video and audio content is logically divided into two parts, a DRM server and a DRM client, as shown in Figure 1.
The DRM server system includes core modules such as content encryption, key management, key gateway, and content authorization. Content encryption module uses content plus
The secret key (CEK) encrypts and protects the video and audio content; the key management module is responsible for synchronizing the key to the secret after receiving the content encryption key
Key gateway; the key gateway module secretly stores the content encryption key after receiving the synchronized key, and receives the secret from the content authorization module
Key query; the content authorization module receives the request from the DRM client and will send the license containing the content encryption key and key usage rules securely.
To a legitimate DRM client. After the DRM client receives the license, it decrypts the content encryption key reasonably in accordance with the key usage rules and uses
The content encryption key decrypts the content for playback.
Each module of the DRM server, DRM client, etc. establish a trust relationship based on PKI technology, and based on this trust relationship, secure each other.
Communication.
Content encryption
Key management key gateway content authorization
Protected content
license
Protected CEK
Rules of use
Certificate management
Client application
DRM Client
Live/on-demand
CEK
CEK
DR
M service
CR
OC
SP
DRM server DRM client
CEK
DRM Client
certificate
Figure 1 Digital rights management logic architecture for video and audio content distribution
5.3 Content authorization
The audio and video content distribution digital rights management system implements the content authorization and authorization based on the mechanism of associating hierarchical keys with key usage rules.
Logically, the keys can be divided into multiple levels according to the order of their encryption protection. The key that encrypts the current key is called the superior key. At every level
Keys have corresponding key usage rules, and the current key can only be decrypted under the conditions specified by the superior key usage rules; each key
There may also be multiple key usage rules. Keys can only be used if they meet all their usage rules. Key and key usage
The mechanism of rule association is shown in Figure 2.
Key1
Key2
...
KeyRules1
KeyRules2
...
KeyN KeyRulesN
Figure 2 Key and key usage rule association mechanism
Key usage rules generally include start time, deadline time, time period, number of times, cumulative time period, output rules, client security
Level, etc. Different types of keys may also include special key usage rules.
The start time indicates that the key is not allowed to be used until a certain time.
The deadline indicates that the key is allowed to be used before a certain time.
The time period indicates that the key is allowed to be used for a certain period of time after the first use.
The number of times indicates the number of times the key was used. One successful decryption using the key counts as one. If the key is used to decrypt digital media,
The body content key defaults to 1 successful decryption and playback count, that is, the DRM client completes 1 content decryption and exits securely.
The cumulative time period is the accumulation of the client player's time from playing to stopping.
Interval, this key is no longer allowed to be used; cumulative time periods are generally used for preview scenes, such as a movie with a duration of 90 minutes, cumulative playback is allowed
After playing for 10 minutes, the user can choose to play the content anywhere in the movie, but the total cannot exceed 10 minutes.
The output rules specify whether the decoded content data is allowed to be output to other devices after the content is decrypted using the content encryption key, and
Allowable output range and method. Without output rules, the output method is not limited.
The client security level requirement indicates that only DRM clients with a specific security level can access the content when using the content encryption key to decrypt the content.
Decryption playback, client security level requirements are divided into software security level, hardware security level, enhanced hardware security level, client security
The level requirement is stored in the DRM client certificate. Only the security level in the DRM client certificate is equal to or higher than that specified in the key usage rules.
When the security level of the client is required, the content encryption key can be used to decrypt and play or output the content.
If there is no corresponding key usage rule, it means that there are no restrictions on the use of the key.
Video and audio content distribution digital rights management systems may contain multiple types of keys, such as content encryption keys, device keys, sessions
Key, message verification code key.
a) Content encryption key
A content encryption key is a key that encrypts digital media content; a content may have multiple content encryption keys. Content encryption
The key usage rules of the key include. start time, deadline time, time period, number of times, cumulative time period, output rules, customers
Security level requirements.
b) session key
The session key is a temporary key generated when the client applies for a license. This key is used to encrypt and protect the content encryption key.
c) Message verification code key
The message captcha key is a temporary key that generates a message captcha to protect the integrity of the license.
d) device key
The device key refers to the key pair of the DRM client. The device key should be an asymmetric key. The data encrypted by the device public key is only
A DRM client can decrypt it.
The DRM server uses the content encryption key to encrypt digital media content, and the content encryption key and other content-related keys (such as
Key, message verification code key, etc.) are encrypted with hierarchical key encryption method and packaged with the key usage rules corresponding to each key
The content authorization license is sent to the DRM client, and the DRM client uses the key in accordance with the usage rules of the key at each level in the hierarchical key system to implement
Decrypted playback of digital media content. The content authorization mechanism of the digital rights management system for video and audio content distribution is shown in Figure 3.
Protected content
Protected CEK usage rules
license
CEK
protected
Session key
Rules of use
Content information
DRM Client
Public key
is authorized
Object
digital signature
content
Figure 3 Content authorization mechanism
5.4 Key Management
Video and audio content distribution digital rights management system DRM server and DRM client have their own asymmetric key pairs
Code algorithm for license acquisition. The DRM server uses a symmetric cryptographic algorithm to encrypt the content.
The certificate can be sent to the DRM client. The key management mechanism of digital rights management system for video and audio content distribution is shown in Figure 4.
DRM Client
Private key
License acquisition
DRM Client
Public key
Session key
Content key
Content content
encrypt and decode
encrypt and decode
encrypt and decode
DRM client DRM server
license
Figure 4 Key management mechanism
The DRM server and DRM client certificates contain their own public keys. The DRM server and DRM client securely protect their own private certificates.
key.
Video and audio content is encrypted using a symmetric cryptographic algorithm; the DRM server generates a session key, and uses the session key to encrypt the content encryption key;
The DRM server uses the DRM client public key to encrypt the session key. If the content encryption key needs to be synchronized to the key gateway, the key gateway public is used.
Key encryption; the DRM server encapsulates the encrypted session key and encrypted content encryption key in a license and sends it to the DRM client;
It can be proved that the integrity of the license is guaranteed by the message verification code.
After receiving the license, the DRM client uses the private key of the DRM client to decrypt the session key, and then uses the decrypted session key to decrypt the content
Encryption key. After the DRM client decrypts the content encryption key, it uses the content encryption key to decrypt the content to achieve content decoding and playback.
5.5 Security Mechanism
The digital rights management security mechanism for video and audio content distribution specified in this standard is as follows.
a) Data confidentiality
Data confidentiality should be protected by encryption. Sensitive data includes at least protected content and content encryption keys.
b) identification
Identity authentication shall be implemented by verifying the validity of the digital certificate of the other party between the DRM client and the DRM server.
c) data integrity
Data integrity testing shall be verified by the digital signature of the protocol message and the message verification code on the license.
5.6 Trust Model
The trust model of AV rights digital rights management system is based on the PKI system. Core components of DRM server in DRM system, DRM customers
The parties have applied to the certification center to obtain a digital certificate as a credential for their identity. The trust relationship between them is based on the
Effectiveness. If the DRM client's certificate is validated by the DRM server, the DRM server trusts the DRM client.
Digital certificates are the basis for establishing a trust system in DRM systems. The DRM client needs to be associated with a digital certificate. Each DRM client should
Carry at least one digital certificate. Each DRM client must have a unique identifier, this unique identifier should be in the appropriate field of the digital certificate
Loading.
Video and audio content distribution digital rights management system trust chain includes root CA certificate, DRM service terminal CA certificate, DRM client sub CA certificate,
DRM server certificate, DRM client certificate, and OCSP server certificate. The security trust mechanism is shown in Figure 5.
DRM Client
Child CA
DRM service terminal
CA
Root CA
DRM service terminal
CA
DRM Client
Child CA
DRM server certificate
DRM client certificate
OCSP server
certificate
Figure 5 Security and trust mechanism
After the trust chain is established, the DRM server securely stores the DRM server certificate and private key, the OCSP server certificate, and the DRM service terminal CA.
Certificate, root CA certificate; DRM client securely stores DRM client certificate and private key, DRM client sub CA certificate, root CA certificate.
The DRM server judges the validity of the DRM client certificate based on the DRM client certificate CRL list, and the DRM client judges based on the OCSP response
The validity of the DRM server certificate.
This standard specifies digital certificate formats, online certificate authentication protocols, and certificate revocation in digital rights management systems for the distribution of video and audio content.
The format of the list is shown in Appendix A.
6 Content encryption
6.1 Overview
This chapter specifies content encryption methods and encrypted content packaging formats for digital rights management systems for the distribution of video and audio content. The encrypted content should
Contains information necessary for content identification and obtaining a license. According to different application scenarios, different encrypted content packaging formats need to be defined.
6.2 Content encryption method
6.2.1 Overview
Video and audio content distribution digital rights management system encrypts the basic stream of video content and adds
The content encryption information CEI is used to indicate how subsequent videos are encrypted. The CEI includes the encryption identifier, the current content encryption key identifier,
The next content encryption key identifier and the initial vector corresponding to the current content encryption key. Before the next CEI appears, all
The video data is encrypted in accordance with the methods specified in 6.2.2 to 6.2.4. The data to be encrypted in each video frame uses the initial data in the current CEI.
Starting vector. The CEI data syntax format is shown in Table 1.
Table 1 CEI data syntax format
Grammar
CEI_DATA () {
encryption_flag 1
next_key_id_flag 1
reserved 5
if (encryption_flag == 1) {
current_key_id 128
if (next_key_id_flag == 1) {
next_key_id 128
IV_length 8
IV IV_length8
encryption_flag. Identifies whether the video data after this extended data is encrypted.
next_key_id_flag. Identifies whether the CEI data contains the next key identifier.
current_key_id. Identifies the key identifier used for subsequent video encryption.
next_key_id. Identifies the next key identifier that will be used for video encryption; this way, the terminal can advance to
The server applies for this key.
IV_length. Initial vector length of the encryption algorithm.
IV. Initial vector of the encryption algorithm.
6.2.2 Advanced Audio and Video Encoding and Decoding and Efficient Audio and Video Encoding and Decoding for Radio and Television
In the video stream formats specified by GY/T 257.1-2012 and GY/T 299.1-2016, CEI data is placed in sequence_header
After extension_data. The following is described in the syntax format in GY/T 299.1-2016. The CEI data storage location is as follows.
extension_data (i) {
while (next_bits (32) == extension_start_code) {
extension_start_code
if (i == 0) {/ * after the sequence header * /
if (next_bits (4) == '1101')/* CEI * /
CEI ()
The CEI syntax is shown in Table 2.
Table 2 CEI syntax
Grammar bit description
CEI () {
extension_id 4 '1101'
reserved 4
CEI_DATA () see table 1
GY/T 299.1-2016 stipulates that the encryption of video coded content contains CEI data in extension_and_user_data (0)
Extended information, which encrypts the strips in each frame of data. After encryption, only the header information of the first stripe is retained. Each frame in the same video sequence
The initial encryption uses the same initial vector, that is, the initial vector included in the CEI extension information in the video sequence. GY/T 299.1-2016
The specified video encoding content encryption syntax is as follows.
video_sequence {
do {
sequence_header ()
extension_and_user_data (0)
do {
if (next_bits (32) == intra_picture_start_code) {
intra_picture_header ()
else
inter_picture_header ()
extension_and_user_data (1)
picture_data () // Retain the first slice () header, the rest is encrypted.
} while (next_bits (32) == inter_picture_start_code || next_bits (32) == intra_picture_start_code)
} while (next_bits (32) = video_sequence_end_code
if (next_bits (32) == video_sequence_end_code)
video_sequence_end_code
if (next_bits (32) == video_edit_code)
video_edit_code
Figure 6 shows the encryption and packaging of advanced audio and video codecs and high-efficiency audio and video codecs.
extension_start_code () CEI_DATA
video_sequence_datavideo_sequence_start_code (B0)
video_sequence video_sequence video_sequence ...
sequence_header () extension_and_user_data (0) intra_picture_data inter_picture_data ...
intra_picture_start_code () extension_id extension_and_user_data (1) slice data
encrypted_picture_data ()
... slice () slice_start_code ()
Figure 6 Schematic diagram of content encryption package
Content encryption is divided into full encryption mode and partial encryption mode.
Full encryption mode refers to encrypting the data part of the stripe, and the last part less than or equal to 16 bytes is not encrypted. The encryption algorithm uses
SM4 algorithm, the encryption mode is CBC mode, the syntax is as follows.
Encrypted_slice_data ()
while (bytes_remaining ()> 16)
protected_block // 16 bytes * n
unencrypted_trailer // 1-16 bytes
Partial encryption mode is to encrypt 10% of the data of the stripe, that is, after encrypting a 16-byte block, the next 9 16-byte blocks are not encrypted.
Finally, the data of 16 bytes or less is not encrypted. The encryption algorithm is SM4, and the encryption mode is CBC. The syntax is as follows.
Encrypted_slice_data ()
while (bytes_remaining ()> 0)
if (bytes_remaining ()> 16) {
protected_block // 16 bytes
unencrypted_trailer //// MIN (144, bytes_remaining ()) bytes
6.2.3 H.264
For H.264 encoded video content, this standard stipulates that the CEI extended information is included in the SEI information of NAL unit type 6.
NAL units with a nal-unit-type of 1 or 5 are encrypted. Other NAL units are not encrypted. User-data_unregistered in SEI
Used to contain CEI information. user_data_payload_byte indicates CEI information; UUID is a fixed value.
70c1db9f-66ae-4127-bfc0-bb1981694b66.
H.264-encoded video content encryption is divided into full encryption mode and partial encryption mode. Full encryption mode refers to the data part of the stripe
For encryption, the last part of 16 bytes or less is not encrypted. The encryption algorithm is SM4. The encryption mode is CBC. The syntax is
as follows.
Encrypted_NAL_Unit ()
NAL_unit_type_byte // 1 byte
unencrypted_leader // 31 bytes
while (bytes_remaining ()> 16) {
protected_block // 16 bytes
unencrypted_trailer // 1-16 bytes
Partial encryption mode is to encrypt 10% of the data of the stripe, that is, after encrypting a 16-byte block, the next 9 16-byte blocks are not encrypted.
Finally, the data of 16 bytes or less is not encrypted. The encryption algorithm is SM4, and the encryption mode is CBC. The syntax is as follows.
Encrypted_NAL_Unit ()
NAL_unit_type_byte // 1 byte
unencrypted_leader // 31 bytes
while (bytes_remaining ()> 0) {
if (bytes_remaining ()> 16) {
encrypted_block // 16 bytes
unencrypted_block // MIN (144, bytes_remaining ()) bytes
6.2.4 H.265
For H.265 encoded format video content, the SEI information of NAL unit type 39 contains CEI extension information.
Data of nal-unit-type 0-31 is encrypted, other NAL units are not encrypted. User-data_unregistered in SEI is used to contain
CEI information. The CEI information is specified in user_data_payload_byte; UUID is a fixed value.
70c1db9f-66ae-4127-bfc0-bb1981694b66.
H.265 encoded video content encryption is divided into two types. full encryption mode and partial encryption mode. Full encryption mode refers to the data part of the stripe
The encryption is divided into parts, and the part of 16 bytes or less is not encrypted. The encryption algorithm is SM4, and the encryption mode is CBC.
The method is as follows.
Encrypted_NAL_Unit ()
NAL_unit_type_byte // 1 byte
unencrypted_leader // 64 bytes
while (bytes_remaining ()> 16) {
protected_block // 16 bytes
unencrypted_trailer // 1-16 bytes
Partial encryption mode is to encrypt 10% of the data in the stripe.
Encryption, the final data less than or equal to 16 bytes is not encrypted. The encryption algorithm is SM4. The encryption mode is CBC.
under.
Encrypted_NAL_Unit ()
NAL_unit_type_byte // 1 byte
unencrypted_leader // 64 bytes
while (bytes_remaining ()> 0) {
if (bytes_remaining ()> 16) {
encrypted_block // 16 bytes
unencrypted_block // MIN (144, bytes_remaining ()) bytes
6.2.5 Preventing Ambiguity of Start Codes
This article stipulates that CEI_DATA and encrypted encoded data need to be converted in order to prevent ambiguous start codes. The conversion rules are as follows.
00 00 00 replaced by 00 00 03 00
00 00 01 replaced by 00 00 03 01
00 00 02 for 00 00 03 02
00 00 03 for 00 00 03 03
Before decryption, CEI_DATA and units with encryption processing should be restored and decrypted accordingly. which is...
Related standard:   GY/T 321-2019  GY/T 322.1-2019
   
 
Privacy   ···   Product Quality   ···   About Us   ···   Refund Policy   ···   Fair Trading   ···   Quick Response
Field Test Asia Limited | Taxed in Singapore: 201302277C | Copyright 2012-2020