Invention relates to apparatus and methods for preparing data for encrypted transmission.
Encryption technology enables the secure transmission of data streams such as digital video data and multimedia content. Using a conditional access business model, some service providers, such as subscription cable companies, may encrypt or scramble copyrighted content, transmit that content to a subscriber and then enable the subscriber to decrypt or unscramble the received content. However, once encrypted, it may be difficult for the subscription cable company to perform additional processing on the data stream. For example, when operating on an encrypted data stream, altering a bit rate to support full bandwidth utilization and/or splicing content streams may require additional decryption and re-encryption steps, thereby introducing added expense and delay.
What is needed is an efficient way to prepare data for secure transport over a network while flexibly supporting the ability to perform additional processing on the data stream. In some cases it would be useful for the method and system to support high throughput, provide good security and operate with compressed and/or uncompressed data.
The present invention provides apparatus and methods for preparing data for encrypted transmission. According to the current invention, a data bitstream may be processed to create side information. For example, when the data bitstream is a video feed comprised of video segments, the side information may describe one or more of the following features: the video block segment layout, video block segment offset information, video block segment length data, video block length, video block segment bit rate, video block segment usage value, video block segment compression statistics, video block segment look-ahead packet schedule information, video block segment timestamps, indexing metadata and content management metadata. After extracting, generating and/or acquiring the side data, some or all of the data bitstream may be encrypted. The encrypted data bitstream and the side data may then be combined to create a combined data bitstream, ready for transmission. Subsequently, the combined data bitstream may be transmitted over a network. By processing a data bitstream to extract metadata about the bitstream before encrypting the data, some processing done after encryption may be executed without requiring costly de-encryption/re-encryption steps. In some cases, the side information may comprise metadata related to the content of the data bitstream, extracted or calculated parameters and/or information that may be used in subsequent processing steps.
In some examples according to the current invention, the data bitstream may be received as an uncompressed, partially or completely encoded and/or compressed bitstream. The bitstream may represent video, audio, image or other data types. A received bitstream may be transcoded to another compression format and/or the data bitstream may be compressed prior to encryption. Furthermore, in some examples, the combined data bitstream may be partially or completely encoded and/or compressed after encryption in preparation for transmission.
In some examples according to the current invention, a combined data bitstream may comprise multiple bitstreams, each at a different bit rate. In some cases, subsequent processing such as splicing, bit rate switching and/or statistical multiplexing (or statmuxing) may be executed without requiring decryption of the combined data bitstreams based, in part, on inspecting the contents of the side data.
a, b and c illustrate examples of video block structures associated with a transrated video bitstream.
According to an example of the current invention as illustrated in
Look-ahead packet schedule information may include key statistics for video blocks that occurs ‘ahead’ in time of the current video block. A look-ahead window may be one or more blocks of video data packets. In some cases, look-ahead information may be used by additional following steps to determine which of the video segment is to be used for the multiplexing in order to result in better bandwidth efficiency.
In some cases, some or all of the side data may be generated, calculated and/or retrieved from other sources. In some cases, the side data may be content related; for example, where the data bitstream may represent a movie, the side data may comprise information such as the list of actors, which may or may not be extracted from the data bitstream. In some cases, the side data may be extracted and/or calculated. For example, the side data may comprise metadata related to indexing for VCR (Video Cassette Recorder) controls and content management which may be generated, calculated and/or retrieved. In other examples according to the current invention, the format of the bitstream may be another format such as, but not limited to: MPEG-1, MPEG-2, MPEG-4, H.264, Real, Quicktime and Microsoft Windows Media format. Depending on the nature of the data bitstream and/or the format, the analyzer may access, calculate, and/or generate different or additional side data.
In this example, the separator 24 has access to the output of the analyzer 22 and performs segmentation of the data bitstream. Specifically, in this example, the separator 24 performs segmentation of a compressed video bitstream into video segments for the purpose of facilitating subsequent processing steps such as, but not limited to, bit rate switching, splicing, digital video splicing, stream switching, digital advertisement insertion, fast-forward, fast-rewind and statistical multiplexing/remultiplexing. In this example, the separator 24 segments the data bitstream into video segments so that they may be treated as self-contained data units in such a way that subsequent processes may be individually process the video segments to create video segments of different bit rates.
However, in other examples according to the current invention, different segmentation may be executed and/or different subsequent processing steps may be applied. In this example using a compressed video bitstream, the separator 24 may extract the elementary payload from the input bitstream and partition the resulting payload into separate data units. For example, the elementary stream (ES) payload may be partitioned along coded pictures and/or group of coded pictures (GOP) boundaries, thereby creating partitions or segments of frames such as video segments (video segment). Each video segment may represent a collection of video coded pictures that may be processed as a unit in subsequent stages. Depending on the processing capability and requirement, video segments may be a GOP or simply a coded picture of I (intra coded), P (forward predicted) or B (bi-directional) type. In some cases, separator 24 may be configurable. For example, a separator 24 may be configured to produce video segments of a particular size; in some cases, it may be useful to configure a video segment size based in part on the granularity required by a downstream bit rate switch. In some cases, the separator 24 may analyze the bit rate characteristics of one or more video segments. For example, the separator 24 may determine the size of a video segment, timing information such as PCR/PTS/DTS related to a segment and/or bit rate information.
In this example a transprocessor 26 may access the output of the separator 24 and optionally perform subsequent processing. In some cases, the video segment output of the separator 24 may have a low bit rate and the transprocessor 26 may be configured to direct the output of the separator to the formatter 28 without altering the bit rate. In other examples, transprocessor 26 may provide a single Constant Bit Rate (CBR) output at a configured bit rate that may be higher or lower than the bit rate of the separator 24 output. However, in other examples, a transprocessor 26 may perform bit rate reduction. In this example, the video segments generated by the separator 24 were compressed, so the bit rate reduction is a transrating process. However, in other examples according to the current invention, the video segments generated by the transprocessor 26 may or may not be compressed or encoded. In some cases, the bit rate reduction may be a re-quantization process if the video segment is of compressed format.
In one embodiment, the formatter 28 may receive an input bit stream and format the input bit stream into one or more transport packets. For example, the separator 24 and the transprocessor 26 may output MPEG-2 elementary stream packets. The formatter 28 may configure the MPEG-2 elementary stream packets into an MPEG-2 transport stream packet structure.
In example 5b, video block 571 comprises multiple video block headers 591, 601, 611, 621 and 631 and a set of corresponding video segments 592, 602, 612, 622 and 632, each video segment at a different bit rate. In this example, each video segment has a corresponding video block header. In example 5c, video blocks 572, 573, 574, 575 and 576 each comprise a single video block header and a single video segment. In other examples, a formatter may format a video block into transport packets such that a single video header is represented in one or more packets and formatted with one or more packetized video segments wherein each video segment is at the same bit rate. Note that in some cases, a single video block header may be packetized into multiple packets; for example, large video block headers may be broken up into multiple packets. However, in some cases, multiple smaller video block headers may be packetized into the same packet.
In this example, the output of the staging processor 20 is provided to an encryptor 40. In this example, the encryptor 40 is a selective encryptor which selectively encrypts only the video data packets, creating an encrypted data bitstream, and does not encrypt packets holding metadata or side data. This strategy may be useful for preparing copyrightable data for secure transmission. Furthermore, information in the unencrypted metadata packets may be used to assist in some later stage processing on the encrypted data bitstream without requiring decryption. For example, metadata describing coded picture types (I, P or B type) may be maintained in unencrypted side data packets enabling the identification of coded picture types associated with packets in the encrypted data bitstream without requiring decryption of the encrypted data bitstream. However, in some examples according to the current invention, some or all of the data packets may be encrypted. In another example according to the current invention, some or all of the packets holding metadata or side data may be encrypted. In this example, the encryptor 40 scrambles the video data packets so that the resulting data can not be decoded and displayed without proper authentication process. The current invention may be used with a variety of available security and/or encryption schemes.
In this example, the combiner 60 combines partially or completely encrypted data packets with partially or completely encrypted or unencrypted side information packets into a single data packet stream. In this example, the combiner 60 combines the encrypted packets output by the encryptor 40 with the side data packets, aligning the unencrypted video block header packets with encrypted video segment packets.
The current invention may also be used in conjunction with later stage processing such as statistical remultiplexing, switching, digital bitstream splicing. These processes may also benefit from selective encryption. For example, statistical remultiplexing processes may make use of the packets holding side information and/or metadata to determine statistical multiplexing schedules. For example, some packets may hold video header fields. Some video header data fields may be used to determine the bit rate allocations for statistical multiplexing with requiring the decryption and re-encryption of the encrypted video data segments. In some cases, substantial computational savings may be achieved and exposure of copyrighted content may be minimized. However, even in examples where side data such as video header data fields are partially or completely encrypted, savings may be realized because only the side data packets would require decryption and re-encryption.
The examples of the current invention described above may be variously implemented in hardware, software and/or firmware. In some cases, systems according to the current invention may be distributed. In some cases, the flow of data through the current invention has been described as “input” to a particular module or “output” from a module. Other examples according to the current invention may operate using buffers or storage areas. In some cases, the data may not necessarily be “input” or “output”, but rather data in a buffer or storage area may be accessed, altered, copied and/or moved by various modules.
Foregoing descriptions of specific embodiments of the invention have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Modifications and variations are possible in light of the above teaching.
The embodiments were chosen and described in order to explain the principles and the application of the invention, thereby enabling others skilled in the art to utilize the invention in its various embodiments and modifications according to the particular purpose contemplated. The scope of the invention is intended to be defined by the claims appended hereto and their equivalents.
This application claims the benefit under 35 U.S.C. § 119(e) of U.S. Provisional Patent Application No. 60/553,933 filed on Mar. 16, 2004, entitled “Methods for Transmitting Pre-Encrypted Data,” which is incorporated by reference herein in its entirety. This application also relates to U.S. patent application Ser. No. 10/633,111 filed on Aug. 1, 2003, entitled “Statistical Remultiplexing of Compressed Video Segments”, which is incorporated by reference herein in its entirety.
Number | Date | Country | |
---|---|---|---|
60553933 | Mar 2004 | US |