Patent Application
20060184790
A media center typically removes encryption from a protected transport stream carrying media content to demultiplex the transport stream (TS) into elementary streams (ESs) for subsequent re-encryption, and delivery to a media subscriber (consumers, clients, etc.) over a network connection. Such decryption and re-encryption operations by the media center may compromise security because decrypted content is vulnerable to piracy and other security breaches. “Media content,” is synonymous with “content,” and “media signals,” which may include one or more of video, audio content, pictures, animations, text, etc.
Media subscribers, such as set-top boxes (STBs), digital media receivers (DMRs), and personal computers (PCs), typically receive protected media content from a media center, or content source. Protected media content includes encrypted audio/video data transmitted over a network connection, or downloaded from a storage medium. To process the encrypted media content (e.g., for indexing), a media subscriber typically needs to remove the media content protection (i.e., decrypt the media content). Such decryption operations typically consume substantial device resources and reduce device performance, and as a result, can compromise device responsiveness and functionality.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
In view of the above, protecting elementary stream media content is described. In one aspect, Media Access Units (MAUs) of ES content are identified. Each MAU includes one or more data segments representing a single video or audio frame. Encryption boundaries are selected for each MAU. The encryption boundaries are based on one or more data segments associated with the respective MAU. Portions of each MAU are encrypted based on corresponding encryption boundaries. Each MAU is mapped to a MAU Payload Format. The MAU Payload Format allows a media consumer to process each ES associated with the ES content independent of any different ES. The MAU Payload Format also allows a media consumer to process each MAU in an ES independent of any other MAU.
The detailed description is described with reference to the accompanying figures.
Overview
Systems and methods to protect ES content by selecting encryption boundaries based on media content specific properties are described. More particularly, the systems and methods encrypt (e.g., using MPEG-2, etc.) portions of a Media Access Unit (MAU) of an ES. Each MAU is a single video or audio frame (elementary stream frame) and associated headers. A MAU includes one or more data segments. Each data segment is a contiguous section of a MAU to which a same set of content encryption parameters apply. A data segment is either completely encrypted or completely in the clear (i.e., unencrypted). The ESs may not have originated from a TS. However, these ES protection operations are compatible with common scrambling operations applied to a TS stream.
If a TS contains protected ES content, the TS is demultiplexed into ESs while preserving existing encryption (i.e., the TS is not decrypted). The ESs are mapped to a MAU payload format (MPF) to encapsulate MAUs of an ES into a transport protocol (e.g., Real-Time Transport Protocol (RTP)) for subsequent communication to media consumers, such as PCs and set-top boxes. Mapping each MAU to the MPF provides a media consumer with enough information to process (e.g., demultiplex, index, store, etc.) each ES independently of any other ES, and process each MAU independently of any other MAU. These techniques are in contrast to conventional systems, which do not protect ES content by applying encryption to MAU portions composed of one or more data segments.
These and other aspects of the systems and methods to protect ES content are now described in greater detail with reference to
Exemplary Apparatus
For purposes of discussion, and although not required, protecting ES content is described in the general context of computer-executable instructions being executed by a computing device such as a personal computer. Program modules generally include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. While the systems and methods are described in the foregoing context, acts and operations described hereinafter may also be implemented in hardware.
By way of example and not limitation, computer-readable media 106 includes program modules 108 and program data 110. Program modules 108 include, for example, ES protection module 112, protected ES content mapping module 114, and other program modules 116 (e.g., an operating system). ES protection module 112 protects ES content by selecting encryption boundaries based on media content specific properties. More particularly, ES protection module 112 encrypts (e.g., using MPEG-2, etc.) ES content 118 to generate protected ES content 120. To this end, ES protection module 112 applies encryption to portions (i.e., data segments) of Media Access Units (MAUs) that comprise the ES. In one implementation, the encryption operations are Advanced Encryption Standard (AES) in Counter Mode. Each MAU is a single video or audio frame (elementary stream frame), which is subsequently associated with headers (e.g., start codes and padding bits). Each MAU includes one or more data segments. Each data segment is a contiguous section of a MAU to which ES protection module 112 applies a same set of content encryption parameters. ES protection module 112 either completely encrypts the data segment, or leaves the data segment completely in the clear. The ESs may not have originated from a TS. However, these ES protection operations are compatible with common scrambling operations applied to a TS stream (e.g., see “other data” 122).
Protected ES content mapping module 114 (“mapping module 114”) maps protected ES content 120 to a MAU payload format (MPF) for encapsulation into transport packets 124. The MPF allows portions of a MAU to pass unencrypted (left in the clear). The MPF also provides enough information to allow a media consumer, such as a personal computer or a set-top box (e.g., see
In one embodiment, ES content (e.g., ES content 118) does not originate in a media content transport stream. In another embodiment, for example, as described below in reference to
Exemplary System
Media Center 204 is a centrally located computing device that may be coupled to content source 202 directly or via network 206, for example, using Transmission Control Protocol/Internet Protocol (TCP/IP) or other standard communication protocols. Examples of network 206 include IP networks, cable television (CATV) networks and direct broadcast satellite (DBS) networks. Media center 204 includes demultiplexing and mapping module 212. Although shown as a single computer-program module, module 212 may be implemented with an arbitrary number of computer-program modules. Demultiplexing operations of program module 212 demultiplex the TS into respective ESs, without decrypting encrypted portions of the TS.
Mapping operations of program module 212 map the demultiplexed protected ES content to the MPF, as per the described operations of protected ES content mapping module 114 of
Media Center 204 communicates the encapsulated protected ES content over a network 206 to one or more subscribers 208, wherein PC 214 and/or STB 216 receive the media content. Media content processed and rendered on PC 214 may be displayed on a monitor associated with PC 214; and media signals processed and rendered on STB 216 may be displayed on television (TV) 218 or similar display device. In one implementation, TV 218 has the capabilities of STB 216 integrated therein.
In one implementation, ES content is carried by a transport stream. In this scenario, TS scrambling module 210 of content source 202, analyzes the transport stream for common scrambling. In particular, the transport stream is analyzed in view of data requirements for at least one process to which the transport stream may be subjected after being encrypted. If the determination is made based upon a statistical model corresponding to one or more of the processes, threshold data requirements may be determined for the particular process that has the most extensive (i.e., threshold) data requirements. This analysis is performed to determine which portions of the transport stream are to pass unencrypted.
The common scrambling analysis may incorporate acknowledgements that any packet within the transport stream that contains any header information is to pass unencrypted. A description of such packets and header information is provided below with reference to
Referring to TABLE 1, the amount of data to be left in the clear in this implementation corresponds, to the length of the Stream Mark plus the Maximum Data Payload Length. Notice, that the clear section may start prior to the Stream Mark and end after the combined length of the Stream Mark and a maximum data payload length, as long as the combined length does not exceed, for example, the length of two consecutive TS packet payloads. For example, a Transmitter (e.g., content source 202 of
It is also possible to have some amount of data from a previous MAU left in the clear, in case the Stream Mark appears near the beginning of the current MAU. In one implementation, this is allowed when the length of the clear section does not exceed 368 bytes.
Since any portion of a transport stream may pass unencrypted, further alternate embodiments may contemplate frame headers and PES headers having common scrambling applied thereto if the data contained therein is not used for processing the transport stream without descrambling.
Referring to
Accordingly, a TAG packet is a single TS packet with a Key Identifier (KID) that is inserted in front of each protected PES unit. In this implementation, the TAG packet is used to retrieve a matching Digital Rights Management (DRM) license when the content is delivered to a media consumer. The content protection layer includes an AES 128 bit key in Counter Mode, where the following requirements apply: The 128 bit counter is divided in two 64 bit fields: The base_counter (MSB) and the minor_counter (LSB). The base_counter and minor_counter are equivalent to the data segment ID and block ID described above. A TAG packet may provide identification for the encryption algorithm utilized on the encrypted portion of the transport stream, provide data needed for an authorized decryptor to deduce a decryption key, and identify those portions of the transport stream that pass unencrypted or encrypted. A TAG packet may include further data identifying which portions of the encrypted stream are used for respective processes (demultiplexing or indexing for trick modes or thumbnail extraction). Further still, a TAG packet is inserted in compliance with the multiplexed transport stream.
A TAG packet may be generated in correspondence with all encrypted portions of a transport stream. Alternatively, encryption method packets may be generated in correspondence with individual packets or bytes of encrypted PES payload data. Thus, a TAG packet may be generated in correspondence with each PES header in a transport stream, in correspondence with a predetermined number of PES headers in a transport stream, or in correspondence with a predetermined pattern of packets that pass unencrypted for other processes.
After the Replace AES Key event occurs, a transmitter immediately stops scrambling all PIDs until it resynchronizes with each PES component. This transition guarantees that all PIDs from the same program are scrambled with the same key. When defining the scr status, the transmitter sets, for each received TS packet, the scr state variable to “no” if any of the following conditions apply:
Further, embodiments do not require that a TAG packet be inserted into the transport stream. Since a TAG packet is not needed until a point of decryption, a TAG packet may be transmitted to a processor in-band or out-of-band (e.g., by a private table), as long as it is received by the processor by the point of decryption. In addition, a TAG packet may be transmitted to a content usage license that is then transmitted in-band or out-of-band to a processor.
Protected ES is mapped to the MPF such that sections of a MAU in a commonly scrambled transport stream are left in the clear. This mapping allows for a media consumer to process each MAU independently. In one implementation, a transmitter such as content source 202 implements these mapping operations.
Syntax of a conventional RTP header is defined in RFC-3550 and shown in
The MPF Header is followed by a “payload”. The payload includes a complete MAU, or a fragment thereof. The payload may contain a partial MAU, allowing large MAUs to be fragmented across multiple payloads in multiple transport packets. The first payload may be followed by additional pairs of MPF Headers and payloads, as permitted by the size of the transport packet.
The first section of the MPF Header, which is called “Packet Specific Info” in
The third section, called “MAU Timing”, provides information about various timestamps associated with the MAU in the payload. For example, this section specifies how the presentation time of the MAU is determined. This section also includes extension mechanisms allowing additional information to be included in the MPF Header.
Referring to
In the simplest possible case, a transport packet contains a single, complete, MAU. In this case, it is possible to include all of the header fields. However, fields which are not needed may be omitted. Each of the three sections of the MPF Header has a bit field which indicates which, if any, of the fields in the section are present.
For example, the “Offset” field, which specifies the byte offset to the end of the current payload, is not needed when the packet contains a single payload, because the length of the payload can be inferred by the size of the transport packet. The “OP” bit in “Bit Field 2” indicates if the “Offset” field is present. If all of the bits in “Bit Field 3” are zero, then the “Bit Field 3” itself can be omitted, and this is indicated by setting the “B3P” bit in “Bit Field 2” to zero.
It is possible to combine multiple payloads in a single transport packet. This is referred to as “grouping”. The “Offset” field indicates the use of “grouping”. If the “Offset” field is present, another MPF Header and another payload may follow after the end of the current payload. The “Offset” field specifies the number of bytes to the end of the current payload, counted from the end of the “Offset” field itself. To determine if another MPF Header follows the end of the current payload, implementations need to consider not only the value of the “Offset” field but also the size of the transport packet, and the size of the RTP padding area, if any in the case RTP is used as the transport protocol.
A single MAU can be split into multiple payloads. This is referred to as “fragmentation”. The primary use for fragmentation is when a MAU is larger than what can fit within a single transport packet. The “F” field in “Bit Field 2” indicates if a payload contains a complete MAU or a fragment thereof.
The fields in the “MAU Timing” section should only be specified in the MPF Header for the payload which contains the first fragment of a MAU. The only exception to this is if the “Extension” field in the “MAU Timing” section contains an extension which is different for different fragments of the same MAU. When a MAU is fragmented, the bits “S”, “D1” and “D2” in “Bit Field 2” are only significant in the MPF Header for the payload which contains the first fragment. Therefore, receivers (media consumers) ignore these bits if the value of the “F” field is 0 or 2.
In this implementation, a MAU is not fragmented unless the MAU is too large to fit in a single transport packet. In this implementation, a fragment of one MAU is not combined with another MAU, or a fragment of another MAU, in a single transport packet. However, receivers may still handle these cases. An example of this is shown in
The second transport packet starts with an MPF Header which omits the “MAU Timing” field, because the “MAU Timing” field for MAU 2 had already been specified in the first transport packet. The “Offset” field in the “MAU Properties” section is used to find the start of the Payload Format Header for MAU 3. This allows the client to decode MAU 3 even if the previous transport packet was lost. Similarly, the figure shows how MAU 4 is fragmented across the second and third transport packets. However, MAU 4 is so big that no additional MAUs can be inserted in the third transport packet. In this example, MAU 4 is continued in a fourth transport packet, which is not shown. In situations like this, the third transport packet's Payload Format Header does not need to include the “Offset” field, and it may be possible to omit the entire “MAU Properties” section. The remaining part of the MPF Header then only includes of the “Packet Specific Info section”, and it can be as small as a single byte.
If a MAU is fragmented into multiple payloads, the payloads are usually carried in separate transport packets. However, this MPF also allows multiple payloads for the same MAU to be carried within a single transport packet.
If a payload in the transport packet contains a fragment of a MAU, this is indicated by the “F” field in “Bit Field 2”.
In addition to the usual RTP sampling clock and wallclock, the MPF provides several additional timestamps and notions of time, which are now described. The RTP header has a single timestamp, which specifies the time at which the data in the packet was sampled. This timestamp is sometimes called the sampling clock. It is useful to note that the RTP timestamps of packets belonging to different media streams cannot be compared. The reason is that the sampling clock may run at different frequencies for different media streams. For example, the sampling clock of an audio stream may run at 44100 Hz, while the sampling clock of a video stream may run at 90000 Hz. Furthermore, RFC-3550 specifies that the value for the initial RTP timestamp should be chosen randomly. In effect, each media stream has its own timeline. In this document, each such timeline is referred to as a “media timeline”.
RTP allows the timelines for the different media streams to be synchronized to the timeline of a reference clock, called the “wallclock”. RTP senders allow the receiver to perform this synchronization by transmitting a mapping between the sampling clock and the wallclock in the RTCP Sender Report packet. A different RTCP Sender Report has to be sent for each media stream, because the media streams may use different sampling clocks.
The mappings are updated and transmitted again at some interval to allow the receiver to correct for possible drift between the wallclock and the sampling clocks. Clock drift may still be a problem if the sender's wallclock drifts in relation to the receiver's wallclock. The two clocks could be synchronized using the NTP protocol, for example, but the RTP specification does not specify a particular synchronization method. Please note that the wallclock originates from the encoder. If the RTP sender and the encoder are separate entities, the wallclock is typically unrelated to any physical clock at the sender.
This MPF uses a third timeline, called the Normal Play Time (NPT) timeline. The NPT timeline is useful primarily when RTP is used to transmit a media “presentation”. Timestamps from the NPT timeline commonly start at 0 at the beginning of the presentation. NPT timestamps are particularly useful when transmitting a pre-recorded presentation, because the timestamps can assist the receiver with specifying a position to seek within the presentation. This assumes the existence of some mechanism for the receiver to communicate the new position to the RTP sender.
Since RTP was designed for multi-media conferencing applications, the RTP specification does not discuss the NPT timeline. However, other protocols which are built on top of RTP, such as RTSP (a control protocol for video on-demand applications) include the concept of the NPT timeline. In RTSP, the control protocol provides a mapping between the NPT timeline and the media timeline for each media stream.
The MPF defines a mechanism for specifying the NPT timeline timestamp associated with a MAU. However, when practical, an out-of-band mapping between the media timeline and the NPT timeline, such as the one defined by RTSP, may be preferable, since it reduces the overhead of the MPF Header.
All RTP-compliant systems handle the wrap around of timestamps. At the typical clock frequency of 90000 Hz, the RTP timestamp will wrap around approximately every 13 hours. But since the RTP specification says that a random offset should be added to the sampling clock, a receiver may experience the first wrap around in significantly less than 13 hours. The wrapping around of the RTP timestamp is usually handled by using modular arithmetic. When modular arithmetic is used, timestamps are usually compared by subtracting one timestamp from another and observing if the result is positive or negative.
In the MPF, each MAU has a “Decode Time” and a “Presentation Time.” The decode time is the time by which the MAU should be delivered to the receiver's decoder, and the presentation time is the time at which the MAU should be presented (displayed or played) by the receiver. Both times belong to the media timeline. Since the delays in the network and in the decoder are not typically known to the RTP sender, the receiver does not use the absolute values of a decode timestamp or a presentation timestamp. The receiver considers only the relative difference between a pair of decode timestamps or a pair of presentation timestamps.
In some cases, such as when a video codec produces bi-directional video frames, MAUs may be decoded in a different order from which they will be presented. In this implementation, the RTP sender transmits the MAUs in the order they should be decoded.
The “Timestamp” field in the RTP header maps to the presentation time of the first MAU in the transport packet. Since the transport packets are transmitted in decode order, the presentation time timestamps of consecutive MAUs may not be monotonically non-decreasing.
The MPF Header includes an optional “Decode Time” field, which is used to specify the decode time of the MAU in the payload. The MPF Header also includes a “Presentation Time” field which is used to specify the presentation time of the MAU, when the transport packet contains more than one MAU. When only a single MAU is included in the transport packet, the “Presentation Time” field because the “Timestamp” field serves as a replacement for that field in the first MAU in the packet. In this implementation, both the “Decode Time” and the “Presentation Time” fields are expressed using the same clock resolution as the “Timestamp” field.
The term “trick play” refers to the receiver rendering the media presentation at a non-real time rate. Examples of trick play include fast forwarding and rewinding of the presentation. If the RTP sender is transmitting in trick play mode, the decode timestamp and presentation timestamp for each MAU should increment at the real-time rate. This allows the decoder to decode the MAUs without knowing that trick play is used. The “Decode Time” and “Presentation Time” fields in the MPF Header are unaffected by trick play, the “NPT” field, if present, is not. For example, if a media presentation is being rewound, the “Presentation Time” timestamp fields of MAUs will be increasing, while the value of the “NPT” field will be decreasing.
The “NPT” field in the MPF Header specifies the position in the Normal Play Time timeline where the MAU belongs. If the “NPT” field is not present, a receiver can calculate the normal playtime of the MAU from the presentation time, provided that a mapping between the two timelines is available. Various approaches for establishing this mapping are discussed below. Since the RTP sender adds a random offset to the timestamps in the media timeline, the presentation time timestamp is not used as a direct replacement for the NPT timestamp. Even if this random offset is known to the receiver, the wrap around of the media timeline timestamps can be a problem.
A possible solution to these problems is for the sender to use an out-of-band mechanism to provide a mapping between the Normal Play Time timeline and the media timeline. This mapping could be provided only once at the beginning of the transmission or repeatedly as needed. Additionally, if trick play is possible, the sender communicates the trick play rate. For example, if the presentation is being rewound, the trick play rate is negative. The receiver uses the trick play rate to generate NPT timestamps that decrease as the presentation time increases.
If the mapping is provided only once at the beginning of the transmission, the receiver establishes a mapping between the Normal Play Time timeline and the wallclock timeline. This is usually possible as soon as an appropriate RTCP Sender Report packet is received. It is preferable to calculate the NPT timestamp for each MAU based on the MAU's wallclock time because timestamps from the media timeline may drift against the wallclock timeline.
The RTSP protocol is an example of a control protocol which provides a mapping between the Normal Play Time timeline and the media timeline at the beginning of the transmission. Another solution, which may provide a suitable trade-off between complexity and overhead, is to include the “NPT” field only on sync-point MAUs. The “NPT” field is used to establish a mapping between the normal play time timeline and the presentation or wallclock timelines. For non-sync point MAUs, the receiver calculates the NPT timestamp using the previously established mapping. When trick play is used, the sender would include the “NPT” field for every MAU.
The “Send Time” field in the MPF Header specifies the transmission time of the transport packet. This can be useful when a sequence of transport packets is transferred from one server to second server. Only the first server needs to compute a transmission schedule for the packets. The second server will forward the transport packets to other clients based on the value of the “Send Time” field. It is not required to include the “Send Time” field when forwarding transport packets to a client. However, clients can use the “Send Time” field to detect network congestion by comparing the difference between the values of the “Send Time” fields in a series of packets against the difference in packet arrival times. The “Send Time” field uses the same units as the media timeline.
The “Correspondence” field provides a mapping between the wallclock timeline and the current media timeline. When RTP is the transfer protocol, then this is the same mapping provided in RTCP Sender Reports. Including the mapping in the transport packet is more efficient than transmitting a separate RTCP packet. This allows the sender to reduce the frequency of RTCP Sender Reports and still transmit the mapping as frequently as desired.
The RTP header is followed by a MPF Header. The only exception is a transport packet that only includes padding. In that case, the MPF Header is not present. If a transport packet contains data from multiple MAUs, the MPF Header appears in front of each MAU and in front of each fragmented (partial) MAU. Thus, transport packets using this Payload Format may contain one or more MPF Headers. The layout of the MPF Header is shown in
After the first data payload, another MPF Header may appear, followed by another data payload. The process of adding another MPF Header after a data payload may be repeated multiple times. Each MPF Header which follows the first data payload with the “Bit Field 2” field.
The following describes the layout of the field “Bit Field 1”.
When “Bit Field 1” is present, “Bit Field 2” is optional. The “B2P” bit in “Bit Field 1” determines if “Bit Field 2” is present. The default value for all bits in “Bit Field 2” is 0. “Fragmentation” field (F) indicates if the data payload includes of a partial MAU. One or more such payloads is combined to reconstruct a complete MAU. The “F” field also indicates if the payload contains the first or last fragment of the MAU. The “S”, “D1” and “D2” bits (below) are only valid when the value of the “F” field is 0 or 3. TABLE 2 shows exemplary meanings of the F field value.
“Offset Present” bit (OP): If this bit is 1, the 16 bit “Offset” field is inserted directly after “Bit Field 2”. The “Offset” field is used to find the end of the current payload. Another MPF Header, starting with “Bit Field 2” may follow the end of the current payload. If the “Offset Present” bit is 0, the “Offset” field is absent; when MPF is used with RTP, the current payload extends to the end of the transport packet or to the start of the RTP padding area if the “Padding” bit in the RTP header is 1.
“Sync Point” bit (S): This bit is set to 1 when the MAU is a sync-point MAU. “Discontinuity” bit (D1): This bit is set to 1 to indicate that one or more MAUs are missing, even though the sequence number of the transport packets (e.g., RTP sequence number, if RTP is used) does not indicate a “gap”. “Droppable” bit (D2): If this bit is 1, and it is necessary to drop some MAUs, this MAU can be dropped with less negative impact than MAUs that have the D2 bit set to 0. “Encryption” bit (E): This bit is set to 1 to indicate that the payload contains encrypted data. The bit should be set to 0 if the payload does not contain encrypted data. “Bit Field 3 Present” (B3P) bit: If this bit is 1, the 1 byte “Bit Field 3” field is inserted after the “Length” field. “Offset”: A 16 bit field which specifies the offset, in bytes, to the end of the current payload, counted from the first byte following the “Offset” field. In other words, the value of the “Offset” field is the size of the “MAU Timing” section, if any, plus the size of the current payload.
The value of the “B3P” bit in “Bit Field 2” determines if “Bit Field 3” is present. The default value for all bits in “Bit Field 3” is 0.
“Extension Present” bit (X): If this bit is 1, a variable size “Extension” field is inserted after the “NPT” field. “Decode Time”: A 32 bit field. This field specifies the decode time of the MAU. When RTP is used, this field specifies the decode time of the MAU using the same time units that are used for the “Timestamp” field in the RTP header. “Presentation Time”: A 32 bit field. This field specifies the presentation time of the MAU. “NPT” field: A 64 bit timestamp. The NPT field specifies the position in the Normal Play Time timeline to which the MAU belongs.
“Extension Type”: A 7 bit field which is used to identify the contents of the “Extension Data” field. In addition, the values 0 and 127 are reserved for future use. “Extension Length”: An 8 bit number giving the size, in bytes of the “Extension Data” field that appears directly following this field. “Extension Data”: Variable length field. The size of this field is given by the “Extension Length” field.
The fields in the “Extension” field have the following values when the Initialization Vector extension is used.
The fields in the “Extension” field have the following values when the Key ID extension is used.
The Key ID extension remains effective until replaced by a different Key ID extension. Therefore, the extension is only used when a payload requires the use of a decryption key that is different from the decryption key of the previous payload. However, if the previous payload was contained in a transport packet which was lost, the receiver may be unaware of that a change of decryption key is necessary. If a payload is decrypted with the wrong key, and this situation is not detected, it can lead to undesirable rendering artifacts.
One approach to reduce severity of this problem is to specify the Key ID extension for the first payload of every MAU which is a sync-point. This is a good solution if it is known that a lost MAU will force the receiver to discard all MAUs until it receives the next sync-point MAU. A more conservative solution is to specify the Key ID extension for the first payload in each multiple-payload transport packet. This solution is robust against packet loss, since the interdependent payloads are all contained within a single transport packet.
When MPEG video headers are present, they precede the subsequent frame. Specifically:
MAUs may be fragmented across multiple transport packets for different reasons. For example, a MAU may be fragmented when transport packet size restrictions exist and when there are differences in encryption parameters for specific portions of the MAU. When RTP Header Fields are interpreted, the “Timestamp” field in the RTP header is set to the PTS of the sample with an accuracy of 90 kHz, and the “Payload Type” (PT) field is set according to out-of-band negotiation mechanisms (for example, using SDP). With respect to the MPF, the packet specification information section, the presence of the “Send Time” field is optional, the presence of the “Correspondence” field is optional, and the “Bit Field 2 Present” bit (B2P) is set in case the payload contains a portion of a MAU which is encrypted, or a fragment of a MAU which is encrypted.
In view of the above, the MPF allows for a single MAU to be encrypted according to different encryption parameters. That includes the ability to have fragments of a single MAU which are encrypted while others may be left in the clear. In such cases, a MAU may be fragmented into multiple payloads, each with different encryption parameters. For example, a MAU or a fragment of a MAU which is encrypted has values and fields set according to the following criteria:
The MAU Properties section is interpreted as follows:
The MAU Timing section is interpreted as follows:
Referring to
At block 1420, the procedure 1400 maps protected ESs to the MAU Payload Format (MPF). Mapping each MAU to the MPF provides a media consumer that receives transport packets encapsulating the mapped ESs with enough information to allow the media consumer to process each ES independently of any other ES, and process each MAU independently of any other MAU. At block 1430, the procedure 1400 encapsulates the ESs mapped to the MPF into a transport protocol. In one implementation, the transport protocol is the Real-Time Transport Protocol (RTP). At block 1440, the procedure 1400 communicates transport packets based on the transport protocol to a media consumer for processing. Such processing, which includes decryption, allows the media consumer to experience the payload data contained in the transport packets.
Although protecting ES content has been described in language specific to structural features and/or methodological operations or actions, it is understood that the implementations defined in the appended claims are not limited to the specific features or actions described. Rather, the specific features and operations are disclosed as exemplary forms of implementing the claimed subject matter.
This patent application is a continuation-in-part of U.S. patent application Ser. No. 10/811,030, titled “Common Scrambling”, filed on Mar. 26, 2004, commonly owned hereby, and incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10811030 | Mar 2004 | US |
| Child | 11202828 | Aug 2005 | US |
