CN101980238B - Method for encrypting RM/RMVB file - Google Patents
Method for encrypting RM/RMVB file Download PDFInfo
- Publication number
- CN101980238B CN101980238B CN2010105414541A CN201010541454A CN101980238B CN 101980238 B CN101980238 B CN 101980238B CN 2010105414541 A CN2010105414541 A CN 2010105414541A CN 201010541454 A CN201010541454 A CN 201010541454A CN 101980238 B CN101980238 B CN 101980238B
- Authority
- CN
- China
- Prior art keywords
- data
- content
- file
- header
- index
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Storage Device Security (AREA)
Abstract
The invention relates to the technology of encryption, in particular to a method for encrypting an RM/RMVB file. The invention discloses the method for encrypting the RM/RMVB file and solves the problems that a player cannot identify the RM/RMVB file normally but only play after decrypting the file completely, much time is taken and much storage space is occupied because the RM/RMVB file is not encrypted after performing analytical processing in the prior art. The main point of the technical scheme comprises the following steps of: a, analyzing the contents of a section header and embedding DRM information; b, analyzing the contents of a data section and encrypting audio data selectively; and c, analyzing and modifying the contents of an index data section. The method is suitable for encrypting the RM/RMVB file.
Description
Technical field
The present invention relates to encryption technology, relate to a kind of encryption method specifically the RM/RMVB file.
Background technology
RM/RMVB is a kind of file of the RealMedia File form based on RealNetwork company, can make the different compression ratio according to the various network transfer rate, carries out audio, video data on the network of low rate and transmits thereby be implemented in.This file volume is little, and video quality is high, and the user can spend the less time after network download, to play.Because these advantages of himself have become the file layout that the most extensively exists, also are present main flow Internet video forms.Simultaneously because digital piracy is serious day by day, the protection of digital content become presses for.DRM (digital copyright management) is through digital content being encrypted and additional service regeulations are protected digital content.Encryption method in the conventional art to the RM/RMVB file; File is not carried out encrypting after the dissection process again; But whole file is carried out whole, whole encryption, and so just having destroyed original form of file and structure, player possibly can't normally be discerned.In use, can only encrypt file all be downloaded and all could play after the deciphering, can not be used for online playing and real-time VOD, need the long time of cost, take more storage space, and the file security after the deciphering can't ensure.
Summary of the invention
Technical matters to be solved by this invention is: propose a kind of encryption method to the RM/RMVB file; Solve in the conventional art and the RM/RMVB file is not carried out encrypting after the dissection process again; Cause player normally to discern; Can only all play after the deciphering file, the many problems of storage space are grown, taken to spended time again.
The present invention solves the problems of the technologies described above the technical scheme that is adopted: a kind of encryption method to the RM/RMVB file may further comprise the steps:
A. the section header content is resolved, and embed DRM information;
B. the data section content is resolved, and to the audio, video data selective encryption;
C. index data joint content is resolved and revised.
Further: step a comprises:
A1. resolution file section header content judges whether this document is the file of RealMedia type, if execution in step a2 then, otherwise disregard;
A2. search Content Description Header data, and read its content, find the copyright part, the DRM data are write among the copyright, and revise copyright_len according to its content;
A3. search Properties Header data, and read its content, find index_offset and data_offset, revise index_offset and data_offset according to the length of the DRM data that write among the step a2 according to its content;
A4. search Media Properties Header data, and read its content, find stream_name according to its content, and the corresponding stream_number of record.
Further, step b comprises:
B1. resolution file data section content is searched Data Packet data, and reads its content, finds stream_number according to its content;
B2. the stream_number among the stream_name among the integrating step a4, stream_number and the step bl confirms that these Data Packet data are voice data or video data;
B3. as required the corresponding AES of file data joint content choice is encrypted.
Further, step c comprises:
C1. resolve index joint content, search Index Chunk data, and read its content, find Index ChunkHeader and Index Record according to its content;
C2. the next_index_header value among the Index Chunk Header is revised;
C3. the offset value among the Index Record is revised.
Further, among the step b3, select only voice data to be encrypted or only video data is encrypted or audio, video data is all encrypted.
Further, among the step b3, be that part is encrypted to the cipher mode of voice data or video data or audio, video data.
The invention has the beneficial effects as follows: after the RM/RMVB file is resolved; Select audio, video data to encrypt; Do not change except that audio, video data and any fileinfo the encryption identification, file layout can correctly be discerned by player, can realize playing while deciphering; And do not influence fast forwarding and fast rewinding or drag playing function, make things convenient for the user.
Embodiment
Below in conjunction with embodiment the present invention is done further description.
The invention discloses a kind of encryption method to the RM/RMVB file; Solve in the conventional art and the RM/RMVB file is not carried out encrypting after the dissection process again; Cause player normally to discern, can only all play after the deciphering file again, the many problems of storage space are grown, taken to spended time.With respect to conventional art, its improvement is: changed and in the conventional art RM/RMVB file has not been resolved the mode of directly all encrypting, but it is resolved earlier; Again audio, video data is partly encrypted; Do not change except that audio, video data and any fileinfo the encryption identification, file layout can correctly be discerned by player, can realize playing while deciphering; And do not influence fast forwarding and fast rewinding or drag playing function, make things convenient for the user.
Embodiment:
For a complete RM/RMVB file; Should comprise: Header Section (section header content), Data Section (data section content), three parts of Index Section (index data joint content); Therefore; The encryption method to the RM/RMVB file in this example comprises three big steps: one. Header Section is resolved, and embed DRM information; Two. Data Section is resolved, and to the audio, video data selective encryption; Three. Index Section is resolved and revises.Set forth respectively in the face of these three steps down:
One. Header Section is resolved, and embed DRM information:
Header Section is positioned at the reference position of file; Store the most information of RM/RMVB file, included identification datas such as RealMedia File Header, Properties Header, Media Properties Header, Content DescriptionHeader.
1. begin to resolve from file header, judge whether this document is the file of RealMedia type, judges promptly whether preceding 4 byte datas of file header are " .RMF ".If then carry out subsequent treatment; Otherwise, disregard.
RealMedia File Header, in the file initial place, the file of each RealMedia form all must begin with this identification data, and data structure is as shown in table 1:
| Title | Size (byte) | Explanation |
| object_id | 4 | The sign of RealMedia File is fixed as " .RMF " |
| size | 4 | RealMedia File Header comprises the size of data |
| object_version | 2 | The version of RealMedia File Header object |
| file_version | 4 | The version of RealMedia File |
| hum_header | 4 | The sign number that comprises among the Header Section |
The data structure of table 1:RealMedia File Header
2. search Content Description Header, it is designated: " CONT ", according to length mark size, read its content then immediately following the back, find the copyright part, the DRM data are write among the copyright, and revise copyright_len.
The data structure of Content Description Header is as shown in table 2:
| Title | Size (byte) | Explanation |
| object_id | 4 | The sign of Content Description is fixed as " CONT " |
| size | 4 | Content Description Header comprises the size of data |
| object_version | 2 | The version of Content Description object |
| title_len | 1 | The length of file title data |
| title | title_len | The content of file title |
| author_len | 1 | The length of paper writer data |
| author | author_len | The content of paper writer |
| copyright_len | 2 | The length of file copyright data |
| copyright | copyright_len | The content of file copyright |
| comment_len | 2 | The length of related commentary data |
| comment | comment_len | The content of related commentary |
The data structure of table 2:Content Description Header
3. search Properties Header, it is designated: " PROP ", and then according to length mark size immediately following the back; Read its content; Find index_offset and data_offset,, revise index_offset and data_offset according to the DRM data length that the front writes.
The data structure of Properties Header is as shown in table 3:
| Title | Size (byte) | Explanation |
| object_id | 4 | The sign of Properties Header is fixed as " PROP " |
| size | 4 | Properties Header comprises the size of data |
| object_version | 2 | The version of Properties Header object |
| max_bit_rate | 4 | The Maximum Bit Rate of file |
| avg_bit_rate | 4 | The mean bit rate of file |
| max_packet_size | 4 | The size of the maximum packet of file |
| avg_packet_size | 4 | The size that file packet is average |
| num_packets | 4 | The quantity of the packet that file comprises |
| duration | 4 | The time that file continues |
| preroll | 4 | Playback needs the time of preparatory buffer memory |
| index_offset | 4 | Index Section position hereof |
| data_offset | 4 | Data Section position hereof |
| num_streams | 2 | The number of Media Properties Header |
| flag | 2 | The sign of file-related information |
The data structure of table 3:Properties Header
4. search Media Properties Header; It is designated: " MDPR ", according to length mark size, read its content then immediately following the back; Find stream_name; Distinguish audio frequency or video according to stream_name, and write down corresponding stream_number, when encrypting, need use stream_number.Have a plurality of MediaProperties Header in the file, need all to resolve the stream_number of essential record audio/video data.
The data structure of Media Properties Header is as shown in table 4:
| Title | Size (byte) | Explanation |
| object_id | 4 | The sign of Media Properties Header is fixed as " PROP " |
| size | 4 | Media Properties Header comprises the size of data |
| object_version | 2 | The version of Media Properties Header object |
| stream_number | 2 | The numbering of stream |
| max_bit_rate | 4 | The Maximum Bit Rate of stream |
| avg_bit_rate | 4 | The mean bit rate of stream |
| max_packet_size | 4 | The size of the maximum packet that stream comprises |
| avg_packet_size | 4 | The size that the packet that stream comprises is average |
| start_time | 4 | |
| preroll | 4 | |
| duration | 4 | The time that stream continues |
| stream_name_size | 1 | The length of stream_name content |
| stream_name | stream_name_size | The content of stream_name |
| mime_type_size | 1 | |
| mime_type | mime_type_size | |
| type_specific_len | 4 | |
| type_specific | type_specific_len |
The data structure of table 4:Media Properties Header
Two. Data Section is resolved, and to the audio, video data selective encryption:
The audio, video data that includes whole file among the Data Section be made up of a plurality of Data Chunk, and each DataChunk is made up of a Data Chunk Header and a plurality of Data Packet.
Contain the value that this Data Chunk kind of sign contains data packet quantity: num_packet among the Data Chunk Header, need carry out encryption to the data packet that is comprised according to this value.Data Chunk Header data structure is as shown in table 5:
| Title | Size (byte) | Explanation |
| object_id | 4 | The sign of Data Chunk Header is fixed as " DATA " |
| size | 4 | Data Chunk comprises the size of data |
| object_version | 2 | The version of Data Chunk Header object |
| num_packet | 4 | The quantity that contains data_packet among this Data Chunk |
| next_data_header | 4 | The position of next Data Chunk Header |
The data structure of table 5:Data Chunk Header
Data Chunk Header is the Data Packet of num_packet quantity at the back, includes audio, video data.The data structure of DataPacket is as shown in table 6:
The data structure of table 6:Data Packet
After the completion of the data parsing among the Data Packet; According to the stream_name and the stream_number that before in Media Properties Header resolves, had obtained; The stream_number that contrast obtains here; Confirm that these data still are video data for audio frequency data; Adopt corresponding AES to encrypt (preceding 16 bytes among the data are not encrypted, and are convenient to the relevant information that player can be discerned audio frequency and video) to data then, then do not handle for the data of other types.
Here, can select only audio frequency data or video data to be encrypted, or audio frequency and video data encrypt as required; Can also as required data all be encrypted, or encryption section data only.Cipher mode can be selected flexibly, and corresponding mode of encrypting is deciphered and got final product when terminal deciphering.Above-mentioned parsing and processing procedure will repeat, and finish dealing with up to whole DataPacket.
Three. Index Section is resolved and revises:
Comprising the positional information of Data Packet in whole file among the Index Section, is that player carries out fast forwarding and fast rewinding and drags the significant data that needs when playing in playing process.Index Section is made up of a plurality of Index Chunk, and each Iata Chunk is made up of an Index Chunk Header and a plurality of Index Record.
Contain the value that indicates this Index Chunk content size: size among the Index Chunk Header, need carry out correcting process to the Index Record that is comprised according to this value.In the process because of the front, the data of DRM have been embedded hereof, so will revise to the next_index_header value among the Index Chunk Header.
Index Chunk Header data structure is as shown in table 7:
The data structure of table 7:Index Chunk Header
Index Chunk Header is a plurality of Index Record at the back, and size is the size among the Index Chunk Header.In the process because of the front, the data of DRM have been embedded hereof, so will revise to the offset value among each Index Record.
Index Record data structure is as shown in table 8:
The data structure of table 8:Index Record
Above-mentioned parsing and processing procedure will repeat, and finish dealing with up to whole Index Section.
If embedded DRM information in the file, and the related data among the Index Section is not done corresponding correction here, then can influence in the playing process fast forwarding and fast rewinding or drag broadcast.So the processing here is very important, bring considerable influence otherwise can play to file.
Above method is applicable to the encryption of the file of RM/RMVB form based on audio frequency and video data packet; And encapsulated DRM information hereof, other corresponding data in the file have been revised, guaranteed the integrality and the correctness of this part of source to greatest extent; Player can be discerned; And can resolve and decipher according to corresponding rule, realize while deciphering broadcast and fast forwarding and fast rewinding, drag broadcast etc., reach the purpose of protection digital publishing rights.
Claims (3)
1. encryption method to the RM/RMVB file is characterized in that: may further comprise the steps:
A. the section header content is resolved, and embeds DRM information:
A1. resolution file section header content judges whether this document is the file of RealMedia type, if execution in step a2 then, otherwise disregard;
A2. search Content Description Header data, and read its content, find copyright, the DRM data are write among the copyright, and revise copyright_len according to its content;
A3. search Properties Header data, and read its content, find index_offset and data_offset, revise index_offset and data_offset according to the length of the DRM data that write among the step a2 according to its content;
A4. search Media Properties Header data, and read its content, find stream_name according to its content, and the corresponding stream_number of record;
B. the data section content is resolved, and to the audio, video data selective encryption:
B1. resolution file data section content is searched Data Packet data, and reads its content, finds stream_number according to its content;
B2. the stream_number among the stream_name among the integrating step a4, stream_number and the step b1 confirms that these Data Packet data are voice data or video data;
B3. as required the corresponding AES of file data joint content choice is encrypted;
C. index data joint content is resolved and is revised:
C1. resolve index joint content, search Index Chunk data, and read its content, find Index Chunk Header and Index Record according to its content;
C2. the next_index_header value among the Index Chunk Header is revised;
C3. the offset value among the Index Record is revised.
2. a kind of encryption method to the RM/RMVB file as claimed in claim 1 is characterized in that: among the step b3, select only voice data to be encrypted or only video data is encrypted or audio, video data is all encrypted.
3. according to claim 1 or claim 2 a kind of encryption method to the RM/RMVB file is characterized in that: among the step b3, be that part is encrypted to the cipher mode of voice data or video data or audio, video data.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2010105414541A CN101980238B (en) | 2010-11-12 | 2010-11-12 | Method for encrypting RM/RMVB file |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2010105414541A CN101980238B (en) | 2010-11-12 | 2010-11-12 | Method for encrypting RM/RMVB file |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101980238A CN101980238A (en) | 2011-02-23 |
| CN101980238B true CN101980238B (en) | 2012-06-27 |
Family
ID=43600740
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN2010105414541A Active CN101980238B (en) | 2010-11-12 | 2010-11-12 | Method for encrypting RM/RMVB file |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101980238B (en) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102567690A (en) * | 2011-12-27 | 2012-07-11 | 四川长虹电器股份有限公司 | Method for encrypting flash video (FLV) file |
| CN103218547B (en) * | 2013-04-09 | 2015-12-23 | 四三九九网络股份有限公司 | SWF files in batch encryption method and device |
| CN103207958B (en) * | 2013-04-09 | 2015-11-18 | 四三九九网络股份有限公司 | The SWF files in batch encryption method of AS3.0 script exploitation and device |
| CN105635149A (en) * | 2015-12-30 | 2016-06-01 | 深圳Tcl数字技术有限公司 | Streaming media encryption method, device and system |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7912994B2 (en) * | 2006-01-27 | 2011-03-22 | Apple Inc. | Reducing connection time for mass storage class peripheral by internally prefetching file data into local cache in response to connection to host |
| CN101222624A (en) * | 2007-12-07 | 2008-07-16 | 四川长虹电器股份有限公司 | Multimedia data encryption method based on AVI format |
| CN101184223A (en) * | 2007-12-07 | 2008-05-21 | 四川长虹电器股份有限公司 | Method for encrypting WMA/WMV/ASF/ASX files |
-
2010
- 2010-11-12 CN CN2010105414541A patent/CN101980238B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN101980238A (en) | 2011-02-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5523513B2 (en) | Content distribution for multiple digital rights management | |
| US20120114118A1 (en) | Key rotation in live adaptive streaming | |
| CN101361057B (en) | Method and apparatus for importing a transport stream | |
| CN101258750A (en) | Method and apparatus for encrypting/decrypting multimedia content to allow random access | |
| JP5557897B2 (en) | Digital media content protection system and method | |
| US20100100742A1 (en) | Transport Stream Watermarking | |
| EP2518934A1 (en) | Method and terminal equipment for applying digital rights management | |
| US8719947B2 (en) | Protection of audio or video data in a playback device | |
| CN100481933C (en) | A method for encryption of MP4 multi-media data content | |
| CN102567690A (en) | Method for encrypting flash video (FLV) file | |
| CN102761779A (en) | Conditional access module and system thereof, and apparatus and method for sending encrypted data to the conditional access module | |
| CN101980238B (en) | Method for encrypting RM/RMVB file | |
| CN105611319B (en) | A kind of method that video content is anti-tamper | |
| CN106096334A (en) | The encryption method of hypermedia data and encryption device, decryption method and deciphering device | |
| EP3360331B1 (en) | Mpeg transport frame synchronization | |
| CN104255008A (en) | Enabling delivery of protected content using unprotected delivery services | |
| US10284529B2 (en) | Information processing apparatus and information processing method | |
| US20160156968A1 (en) | File generating method and file generating apparatus | |
| CN109660866A (en) | A kind of decryption of video method based on H5 | |
| CN107318045A (en) | The method and device of playing video data stream | |
| KR100840200B1 (en) | Apparatus and method of packaging/unpackaging h.264 movie file streamed or downloaded | |
| KR100596382B1 (en) | Apparatus for protecting digital content and method therefor | |
| CN101169953B (en) | MP3 content encryption method | |
| US8352732B2 (en) | Transmission method for conditional access content | |
| CN114039959A (en) | TS stream transmission method and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant |