Patent Description:
Digital signal compression (sometimes referred to as video coding or video encoding) is widely used in many multimedia applications and devices. Digital signal compression using a coder/decoder (codec) allows streaming media, such as audio or video signals to be transmitted over the Internet or stored on compact discs. A number of different standards of digital video compression have emerged, including H. <NUM>; DV; MPEG-<NUM>, MPEG-<NUM>, MPEG-<NUM>, VC1; and AVC (H. These standards, as well as other video compression technologies, seek to efficiently represent a video frame picture by eliminating the spatial and temporal redundancies in the picture and among successive pictures. Through the use of such compression standards, video contents can be carried in highly compressed video bit streams, and thus efficiently stored in disks or transmitted over networks.

MPEG-<NUM> AVC (Advanced Video Coding), also known as H. <NUM>, is a video compression standard that offers significantly greater compression than its predecessors. <NUM> standard is expected to offer up to twice the compression of the earlier MPEG-<NUM> standard. <NUM> standard is also expected to offer improvements in perceptual quality. As a result, more and more video content is being delivered in the form of AVC(H. <NUM>)-coded streams. Two rival DVD formats, the HD-DVD format and the Blu-Ray Disc format support H. <NUM>/AVC High Profile decoding as a mandatory player feature. <NUM>) coding is described in detail in ><NPL>.

Video encoding can be done on a general purpose computer in software or may be done with specialized hardware referred to as a hardware video encoder. Use of a hardware video encoder is regarded as key to achieving high performance video compression with low system resource usage.

A hardware decoder accelerator is a system resource shared by multiple users. Typically, the accelerator has higher than normal process privilege to access user's private memory, system registers and sometimes kernel memory. This makes the accelerator a possible target for security attacks.

Prior art document <CIT> discloses methods and systems for manipulating bitstreams of digital media data compressed according to a compression standard. Also disclosed are representative embodiments of evaluating compliance of an encoded bitstream of digital media data with a compression standard. A conforming bitstream of compressed digital media data is input. One or more of the parameters in the bitstream are selectively altered into parameters that do not conform to the video compression standard. The selective alteration can be performed such that parameters that would make the bitstream non-decodable if altered are bypassed and left unaltered. A non-conforming bitstream that includes the one or more selectively altered parameters is output.

It is within this context that aspects of the present disclosure arise.

The teachings of the present disclosure can be readily understood by considering the following detailed description in conjunction with the accompanying drawings, in which:.

Although the following detailed description contains many specific details for the purposes of illustration, anyone of ordinary skill in the art will appreciate that many variations and alterations to the following details are within the scope of the invention. Accordingly, the exemplary embodiments of the invention described below are set forth without any loss of generality to, and without imposing limitations upon, the claimed invention.

Aspects of the present disclosure are directed to a software security enhancement layer to protect the hardware decoder accelerator from being compromised and minimize the damage if the accelerator is compromised.

In the prior art, hardware decoder accelerators have typically been implemented by individual hardware device vendors. Each hardware vendor defines their own security features according to their product's requirements and implements these security features as part of the hardware. For example, for many personal computer (PC) hardware vendors, the security goal is to protect copyrighted video content. So, most of hardware accelerators have content protection related security features.

Some devices have different security goals. Specifically, for certain game console providers, the security goal may be to protect both video content and system kernel for the game console itself. As a result, we have to enhance the security with an extra software layer.

The need for enhanced security for a hardware decoder may not be apparent to computer security expert. From a computer security expert's point of view, a hardware decoder accelerator only performs video signal processing tasks and it only needs a very simple security protection. However, from a video processing expert's point of view, the hardware decoder accelerator is a programmable device configured to execute instructions embedded in encoded video streams. By carefully designing an input video stream, the decoder accelerator could be instructed to do anything. This includes things that are harmful to the device. Therefore, enhanced security protection is necessary for certain devices that use a hardware decoder accelerator.

According to certain aspects of the present disclosure, enhanced security for a decoder accelerator may be implemented by a software security enhancement layer. By way of example, and not by way of limitation, such a software layer could be implemented as a piece of software in a decoder service daemon, the decoder accelerator kernel driver or inside the accelerator firmware. It could also be implemented as a block of hardware. Some security protections may also be applied in hardware with a hardware video encoder accelerator.

As shown in <FIG>, a computer system <NUM> may include a central processor unit (CPU) <NUM>, an integrated hardware video decoder accelerator <NUM>, and one or more programmable modules <NUM>. The accelerator <NUM> is configured to decode coded video streams. These coded video streams may follow video coding standards, such as H. <NUM>, MPEG2, MPEG4 and VCI. The CPU <NUM> controls the hardware decoder accelerator <NUM> through some system registers <NUM>. Both the CPU <NUM> and the accelerator <NUM> share a common system memory <NUM>. Optionally, the hardware decoder accelerator <NUM> may also be programmable. Part of the decoder functionality could be implemented in software, which may be implemented as instructions <NUM> stored in the memory <NUM>. Augmenting a hardware accelerator's capabilities with software can make the accelerator more flexible. However, it also creates more opportunity for hackers to attack the accelerator <NUM>. This is significant since currently almost all hardware decoder accelerators on the market are programmable. To prevent this, the instructions <NUM> may include a software security layer <NUM>, which may be configured as discussed below.

The instructions <NUM> may be implemented in a software stack that includes user software, system software and hardware layers. <FIG> shows an example of a typical software stack <NUM> that may operate on top of the hardware accelerator <NUM> indicating possible locations within the stack for the security layer <NUM>. As shown in <FIG>, one or more user applications <NUM> may call functions in a user land library <NUM> to submit decoding tasks to a kernel driver <NUM>. The user applications <NUM> and land library <NUM> are in the part of a software stack referred to as "user software". The kernel driver <NUM> is part of the operating system software. The kernel driver <NUM> operates the hardware accelerator <NUM> via the system registers <NUM>.

According to aspects of the present disclosure the security enhancement layer <NUM> could be an extra module in the hardware layer (e.g., in firmware) or in the kernel driver <NUM>. Alternatively, the security enhancement layer could be an extra piece of system software above the kernel driver <NUM>.

As shown in <FIG>, a user application only can access memory buffers <NUM> in a user memory space within the system memory <NUM>. Sometimes, the hardware accelerator <NUM> cannot access the user's memory space. In this case, the operating system software could map or copy the user's data buffers <NUM> in system memory for the hardware accelerator <NUM>.

To understand how the security enhancement layer <NUM> might work, it is useful to understand how the hardware accelerator <NUM> works and how it is vulnerable to hackers and other security threats. Typically, the procedure to decode a picture with a hardware accelerator may be summarized as follows.

A user application stores an input video stream in a memory buffer in the user's memory space. Later, the operating system software will open the user memory buffer for the hardware accelerator <NUM> to access or the operating system copies the user memory buffer to a hardware accelerator visible memory space. Sometimes, this hardware accelerator visible memory space is the kernel memory space.

The user application <NUM> creates a decoding task by calling functions in the user land library <NUM>. The control parameters of a video decoding task depend on the actual hardware accelerator <NUM> and the operating system. For example, Microsoft DXVA defines how a user application uses a hardware accelerator on Windows PCs.

The kernel driver <NUM> writes a user request into system registers. The hardware decoder accelerator <NUM> receives a decoding command and decodes a portion of the input video stream. The decoding result is stored in a user visible memory buffer <NUM>. The hardware accelerator <NUM> notifies the kernel driver <NUM> that a task is finished via system registers <NUM>. The user application <NUM> receives decoding done notification from the kernel driver <NUM> and the decoder output data from the hardware accelerator <NUM>.

To accomplish the task above, the hardware decoder accelerator <NUM> has certain privileges. For example, the hardware decoder accelerator may be able to read and/or write video decoding buffers of all users. For some systems, the decoder may have access to kernel memory space. The hardware decoder accelerator may also be able to read and/or write some system registers. In addition for some systems, if the hardware accelerator <NUM> is programmable, the program instructions and data are stored in the kernel memory space.

Therefore, if a hardware decoder accelerator is compromised by a hacker, the hacker could, steal video content from other decoder applications. For example, a hacker could make an illegal copy of a Blu-ray disk. Furthermore, a hacker may take advantage of a compromised decoder accelerator to steal system secrets, such as encryption keys, by reading system registers. Furthermore, in extreme cases, a compromised hardware decoder accelerator could compromise the system kernel allowing a hacker to take over the whole system <NUM>.

The system <NUM> may be configured to minimize the damage if the hardware decoder accelerator <NUM> is compromised. One possible configuration of the system would be as follows.

Limited by design, not all the hardware accelerators could meet the recommendations above. For example, most of hardware accelerators integrated in PC graphic card can access more registers than necessary and there is no way to put a constraint on that. So, it is necessary to implement an extra protection layer to make it difficult to hack a hardware accelerator.

Before proceeding to describe how the security software <NUM> may protect the hardware decoder accelerator against malicious attack, it is useful to understand how video pictures are encoded. By way of example, and not by way of limitation, as shown in <FIG>, a single picture <NUM> (e.g., a digital video frame) may be broken down into one or more sections. As used herein, the term "section" can refer to a group of one or more pixels within the picture <NUM>. A section can range from a single pixel within the picture, up to the whole picture. Non-limiting examples of sections include slices <NUM>, macroblocks <NUM>, sub-macroblocks <NUM>, blocks <NUM> and individual pixels <NUM>. As illustrated in <FIG>, each slice <NUM> contains one or more rows of macroblocks <NUM> or portions of one or more such rows. The number of macroblocks in a row depends on the size of the macroblocks and the size and resolution of the picture <NUM>. For example, if each macroblock contains sixteen by sixteen pixels then the number of macroblocks in each row may be determined by dividing the width of the picture <NUM> (in pixels) by sixteen. Each macroblock <NUM> may be broken down into a number of sub-macroblocks <NUM>. Each sub-macroblock <NUM> may be broken down into a number of blocks <NUM> and each block may contain a number of pixels <NUM>. By way of example, and without limitation of the invention, in a common video coding scheme, each macroblock <NUM> may be broken down into four sub-macroblocks <NUM>. Each sub-macroblock may be broken down into four blocks <NUM> and each block may contain a four by four arrangement of sixteen pixels <NUM>.

It is noted that each picture may be either a frame or a field. A frame refers to a complete image. A field is a portion of an image used for to facilitate displaying the image on certain types of display devices. Generally, the pixels in an image are arranged in rows. To facilitate display an image may sometimes be split by putting alternate rows of pixels into two different fields. The rows of pixels in the two fields can then be interlaced to form the complete image. For some display devices, such as cathode ray tube (CRT) displays, the two fields may simply be displayed one after the other in rapid succession. The afterglow of the phosphors or other light emitting elements used to illuminate the pixels in the display combined with the persistence of vision results in the two fields being perceived as a continuous image. For certain display devices, such as liquid crystal displays, it may be necessary to interlace the two fields into a single picture before being displayed. Streaming data representing encoded images typically includes information indicating whether the image is a field or a frame. Such information may be included in a header to the image.

<FIG> illustrates an example of a possible process flow in a method <NUM> for decoding of streaming data <NUM> that may be used in conjunction with aspects of the present disclosure. This particular example shows the process flow for video decoding, e.g., using the AVC (H. <NUM>) standard. The coded streaming data <NUM> may initially be stored in a buffer. Where coded streaming data <NUM> (e.g., a video data bitstream) has been transferred over a network, e.g., the Internet, the data <NUM> may initially undergo a process referred to as network abstraction layer (NAL) decoding, indicated at <NUM>. NAL decoding may remove from the data <NUM> information added to assist in transmitting the data. Such information, referred to as a "network wrapper" may identify the data <NUM> as video data or indicate a beginning or end of a bitstream, bits for alignment of data, and/or metadata about the video data itself.

In addition, by way of example, the network wrapper may include information about the data <NUM> including, e.g., resolution, picture display format, color palette transform matrix for displaying the data, information on the number of bits in each picture, slice or macroblock, as well as information used in lower level decoding, e.g., data indicating the beginning or ending of a slice. This information may be used to determine the number of macroblocks to pass to each of the task groups in a single section. Due to its complexity, NAL decoding is typically done on a picture and slice level. The smallest NAL buffer used for NAL decoding is usually slice sized.

In some embodiments, after NAL decoding at <NUM>, the remaining decoding illustrated in <FIG> may be implemented in three different thread groups or task groups referred to herein as video coded layer (VCL) decoding <NUM>, motion vector (MV) reconstruction <NUM> and picture reconstruction <NUM>. The picture reconstruction task group <NUM> may include pixel prediction and reconstruction <NUM> and post processing <NUM>. In some embodiments of the present invention, these tasks groups may be chosen based on data dependencies such that each task group may complete its processing of all the macroblocks in a picture (e.g., frame or field) or section before the macroblocks are sent to the next task group for subsequent processing.

Certain coding standards may use a form of data compression that involves transformation of the pixel information from a spatial domain to a frequency domain. One such transform, among others, is known as a discrete cosine transform (DCT). The decoding process for such compressed data involves the inverse transformation from the frequency domain back to the spatial domain. In the case of data compressed using DCT, the inverse process is known as inverse discrete cosine transformation (IDCT). The transformed data is sometimes quantized to reduce the number of bits used to represent numbers in the discrete transformed data. For example, numbers <NUM>, <NUM>, <NUM> may all be mapped to <NUM> and numbers <NUM>, <NUM>, <NUM> may all be mapped to <NUM>. To decompress the data a process known as inverse quantization (IQ) is used before performing the inverse transform from the frequency domain to the spatial domain. The data dependencies for the VCL IQ/IDCT decoding process <NUM> are typically at the macroblock level for macroblocks within the same slice. Consequently results produced by the VCL decoding process <NUM> may be buffered at the macroblock level.

VCL decoding <NUM> often includes a process referred to as Entropy Decoding <NUM>, which is used to decode the VCL syntax. Many codecs, such as AVC(H. <NUM>), use a layer of encoding referred to as entropy encoding. Entropy encoding is a coding scheme that assigns codes to signals so as to match code lengths with the probabilities of the signals. Typically, entropy encoders are used to compress data by replacing symbols represented by equal-length codes with symbols represented by codes proportional to the negative logarithm of the probability.

<NUM>) supports two entropy encoding schemes, Context Adaptive Variable Length Coding (CAVLC) and Context Adaptive Binary Arithmetic Coding (CABAC). Since CABAC tends to offer about <NUM>% more compression than CAVLC, CABAC is favored by many video encoders in generating AVC(H. <NUM>) bitstreams. Decoding the entropy layer of AVC(H. <NUM>)-coded data streams can be computationally intensive and may present challenges for devices that decode AVC(H. <NUM>)-coded bitstreams using general purpose microprocessors. For this reason, many systems uses a hardware decoder accelerator.

In addition to Entropy Decoding <NUM>, the VCL decoding process <NUM> may involve inverse quantization (IQ) and/or inverse discrete cosine transformation (IDCT) as indicated at <NUM>. These processes may decode the headers <NUM> and data from macroblocks. The decoded headers <NUM> may be used to assist in VCL decoding of neighboring macroblocks.

VCL decoding <NUM> may be implemented at a macroblock level data dependency frequency. Specifically, different macroblocks within the same slice may undergo VCL decoding in parallel and the results may be sent to the motion vector reconstruction task group <NUM> for further processing.

Subsequently, all macroblocks in the picture or section may undergo motion vector reconstruction <NUM>. The MV reconstruction process <NUM> may involve motion vector reconstruction <NUM> using headers from a given macroblock <NUM> and/or co-located macroblock headers <NUM>. A motion vector describes apparent motion within a picture. Such motion vectors allow reconstruction of a picture (or portion thereof) based on knowledge of the pixels of a prior picture and the relative motion of those pixels from picture to picture. Once the motion vector has been recovered pixels may be reconstructed at <NUM> using a process based on residual pixels from the VCL decoding process <NUM> and motion vectors from the MV reconstruction process <NUM>. The data dependency frequency (and level of parallelism) for the MV depends on whether the MV reconstruction process <NUM> involves co-located macroblocks from other pictures. For MV reconstruction not involving co-located MB headers from other pictures the MV reconstruction process <NUM> may be implemented in parallel at the slice level or picture level. For MV reconstruction involving co-located MB headers the data dependency frequency is at the picture level and the MV reconstruction process <NUM> may be implemented with parallelism at the slice level.

The results of motion vector reconstruction <NUM> are sent to the picture reconstruction task group <NUM>, which may be parallelized on a picture frequency level. Within the picture reconstruction task group <NUM> all macroblocks in the picture or section may undergo pixel prediction and reconstruction <NUM> in conjunction with de-blocking <NUM>. The pixel prediction and reconstruction task <NUM> and the de-blocking task <NUM> may be parallelized to enhance the efficiency of decoding. These tasks may be parallelized within the picture reconstruction task group <NUM> at a macroblock level based on data dependencies. For example, pixel prediction and reconstruction <NUM> may be performed on one macroblock and followed by de-blocking <NUM>. Reference pixels from the decoded picture obtained by de-blocking <NUM> may be used in pixel prediction and reconstruction <NUM> on subsequent macroblocks. Pixel prediction and reconstruction <NUM> produces decoded sections <NUM> (e.g. decoded blocks or macroblocks) that include neighbor pixels which may be used as inputs to the pixel prediction and reconstruction process <NUM> for a subsequent macroblock. The data dependencies for pixel prediction and reconstruction <NUM> allow for a certain degree of parallel processing at the macroblock level for macroblocks in the same slice.

The post processing task group <NUM> may include a de-blocking filter <NUM> that is applied to blocks in the decoded section <NUM> to improve visual quality and prediction performance by smoothing the sharp edges which can form between blocks when block coding techniques are used. The de-blocking filter <NUM> may be used to improve the appearance of the resulting de-blocked sections <NUM>.

The decoded section <NUM> or de-blocked sections <NUM> may provide neighboring pixels for use in de-blocking a neighboring macroblock. In addition, decoded sections <NUM> including sections from a currently decoding picture may provide reference pixels for pixel prediction and reconstruction <NUM> for subsequent macroblocks. It is during this stage that pixels from within the current picture may optionally be used for pixel prediction within that same current picture as described above, independent of whether the picture (or subsections thereof) is inter-coded or intra-coded. De-blocking <NUM> may be parallelized on a macroblock level for macroblocks in the same picture.

The decoded sections <NUM> produced before post processing <NUM> and the post-processed sections <NUM> may be stored in the same buffer, e.g., the output picture buffer depending on the particular codec involved. It is noted that de-blocking is a post processing filter in H. <NUM> uses pre-de-blocking macroblock as reference for neighboring macroblocks intra prediction and post-de-blocking macroblocks for future picture macroblocks inter prediction. Because both pre- and post-de-blocking pixels are used for prediction, the decoder or encoder has to buffer both pre-de-blocking macroblocks and post-de-blocking macroblocks. For most low cost consumer applications, pre-de-blocked pictures and post-de-blocked pictures share the same buffer to reduce memory usage. For standards that pre-date H. <NUM>, such as MPEG2 or MPEG4 except MPEG4 part <NUM>, (note: H. <NUM> is also called MPEG4 part <NUM>), only pre-post-processing macroblocks (e.g., pre-de-blocking macroblocks) are used as reference for other macroblock prediction. In such codecs, a pre-filtered picture may not share the same buffer with a post filtered picture.

Thus, for H. <NUM>, after pixel decoding, the decoded section <NUM> is saved in the output picture buffer. Later, the post processed sections <NUM> replace the decoded sections <NUM> in the output picture buffer. <NUM> cases, the decoder only saves decoded sections <NUM> in the output picture buffer. The post processing is done at display time and the post processing output may not share the same buffer as the decoder output picture buffer.

At least some portions of the decoding process <NUM> may be implemented on the hardware decoder <NUM>. It is possible for a hacker to insert malicious code or data into the coded streaming data <NUM> that is received by the system <NUM>. Such malicious code or data may be used to attack the system through unauthorized use of the hardware decoder <NUM>. The hardware decoder accelerator security layer <NUM> can be configured to protect the hardware decoder <NUM> against such malicious attack.

To protect the hardware accelerator <NUM>, the interface of the user applications <NUM> and the accelerator <NUM> must carry enough memory access information. If a user application <NUM> submits a request to the hardware decoder accelerator <NUM> the request must carry the addresses of all user buffers <NUM> accessed by the decoder <NUM>. It also must carry all the necessary information to calculate the memory usage of the hardware accelerator <NUM>. Some examples of such buffers used by a hardware accelerator <NUM> for different coding standards are listed in Table I below.

For existing video coding standards, these buffer size related information are coded in the video stream above macroblock level. Table II shows how the buffer size information is coded in the stream for different video standards.

After receiving a user request, the decoder protection layer <NUM> may calculate the necessary size of each buffer and verify if all memory within the range is valid. For better security, the user request message and all buffers in Table II, except video stream buffer and decoded pixel buffer, should be protected from any user process access once a task is submitted. Otherwise, a hacker would have a chance to replace a valid request with an invalid request, after the request is verified or, a hacker could change the content in these data buffers while the accelerator is processing these buffers.

Some examples of possible methods to protect these buffers against malicious use include, but are not limited to:.

Typically, the decoded pixel buffer is "write only" for the accelerator <NUM>. It is therefore usually not necessary to protect this buffer. In general, it may be impractical to protect the video stream buffer for a number of reasons. First, the size of this buffer may be very big and it may not be practical to copy all the data in this buffer into another memory space. Second, the user application may still be working on the bitstream buffer for other pictures. The coded picture size is not predictable. It is hard to align the picture boundary with memory page boundary. Consequently, it may not be practical to lock certain pages in the buffer from user access.

When the hardware accelerator <NUM> decodes coded streams at higher than macroblock level, the protection layer <NUM> could reject any input bitstreams for which the buffer size related parameters coded in the stream <NUM> mismatch these parameters in the user's request. This protects the hardware decoder accelerator <NUM> from buffer overflow attacks.

For all video coding standards, in each coded slice, the slice header carries information indicating the start position of the slice. In certain implementations the decoder protection layer <NUM> may check if the slice position is within the current picture boundary. If it is determined that a slice is not within the current picture boundary, this slice should be discarded since it might contain malicious code or data.

Furthermore, for each coded macroblock, the protection layer <NUM> may check if a current macroblock is within the current picture boundary, if the current macroblock is not within the current picture boundary, the protection layer <NUM> may discard this macroblock.

In the case of H. <NUM>, MPEG4 or VC1 stream decoding, for each macroblock, the protection layer <NUM> may check if a referred co-located reference macroblock header is with the reference macroblock header buffer. If it is not within the reference macroblock header buffer, this macroblock should be discarded.

In the case of MPEG2 stream decoding, the protection layer <NUM> should check if the motion vector is within the reference picture boundary. If it is not within the reference picture boundary, this macroblock should be discarded.

It is noted that because it is difficult to protect the input stream buffer as discussed above, for all bitstream checks above, the data value should be checked when the data is used. Otherwise, hacker will have a chance to alter the bitstream content between the time that the accelerator verifies the data and the time that the accelerator uses it.

Not all the hardware has capability to lock certain buffers from user process access. For example, if a user application can access a macroblock intermediate data buffer, a hacker can alter the content in the buffer to instruct the accelerator to read system secret information as reference motion vectors or reference pixels. Therefore, depending on the content of the macroblock intermediate data buffer and reference macroblock header buffer, extra protection should be added for certain memory access operations. The following are some examples of suggested best practices that can implement these extra protections,.

Aspects of the present disclosure include systems configured to implement hardware decoder accelerator security layer of the various types described above. By way of example, and not by way of limitation, <FIG> illustrates a block diagram of a computer system <NUM> that may be used to implement video coding according to aspects of the present disclosure. The system <NUM> generally may include a main processor module <NUM>, a memory <NUM> and a hardware decoder <NUM>. The processor module <NUM> may include one or more processor cores, e.g., single core, dual core, quad core, processor-coprocessor, Cell processor, architectures, and the like.

The memory <NUM> may be in the form of an integrated circuit, e.g., RAM, DRAM, ROM, and the like. The memory may also be a main memory that is accessible by all of the processor cores in the processor module <NUM>. In some embodiments, the processor module <NUM> may have local memories associated with one or more processor cores or one or more coprocessors. A software coder program <NUM> may be stored in the main memory <NUM> in the form of processor readable instructions that can be executed on the processor module <NUM>. The coder program <NUM> may be configured to decode a picture into compressed signal data in conjunction with the hardware decoder accelerator <NUM>, e.g., as described above. A hardware decoder accelerator security layer 503A may also be stored in the memory <NUM> and executed on the processor module <NUM>. The security layer 503A is configured to implement additional security for the hardware coder accelerator, as discussed above. The coder program <NUM> and hardware decoder accelerator security layer 503A may be written in any suitable processor readable language, e.g., C, C++, JAVA, Assembly, MATLAB, FORTRAN and a number of other languages.

Input or output data <NUM> may be stored in memory <NUM>. During execution of the coder program <NUM> and/or security layer 503A, portions of program code and/or data <NUM> may be loaded into the memory <NUM> or the local stores of processor cores for processing the processor <NUM>. By way of example, and not by way of limitation, the input data <NUM> may include video pictures, or sections thereof, before encoding or decoding or at intermediate stages of encoding or decoding. In the case of encoding, the data <NUM> may include buffered portions of streaming data, e.g., unencoded video pictures or portions thereof. In the case of decoding, the data <NUM> may include input data in the form of un-decoded sections, sections that have been decoded, but not post-processed and sections that have been decoded and post-processed. Such input data may include data packets containing data representing one or more coded sections of one or more digital pictures. By way of example, and not by way of limitation, such data packets may include a set of transform coefficients and a partial set of prediction parameters. These various sections may be stored in one or more buffers. In particular, decoded and/or post processed sections may be stored in an output picture buffer implemented in the memory <NUM>.

The system <NUM> may also include well-known support functions <NUM>, such as input/output (I/O) elements <NUM>, power supplies (P/S) <NUM>, a clock (CLK) <NUM> and cache <NUM>. The apparatus <NUM> may optionally include a mass storage device <NUM> such as a disk drive, CD-ROM drive, tape drive, or the like to store programs and/or data. The device <NUM> may also optionally include a display unit <NUM> and user interface unit <NUM> to facilitate interaction between the apparatus <NUM> and a user. The display unit <NUM> may be in the form of a cathode ray tube (CRT) or flat panel screen that displays text, numerals, graphical symbols or images. The user interface <NUM> may include a keyboard, mouse, joystick, light pen, or other device that may be used in conjunction with a graphical user interface (GUI). The apparatus <NUM> may also include a network interface <NUM> to enable the device to communicate with other devices over a network <NUM>, such as the internet. The system <NUM> may receive one or more frames of encoded streaming data (e.g., one or more encoded video frames) from other devices connected to the network <NUM> via the network interface <NUM>. These components may be implemented in hardware, software, or firmware, or some combination of two or more of these.

Aspects of the present disclosure provide additional protection against malicious attack on the system <NUM> through use of the hardware decoder accelerator security layer 503A.

Claim 1:
A method, comprising:
receiving one or more frames of encoded digital streaming data in a system (<NUM>) having a processor module (<NUM>), a memory (<NUM>) and a hardware decoder accelerator (<NUM>);
decoding the one or more frames of encoded digital streaming data using the hardware decoder accelerator; and
using a software security layer (<NUM>, 503A) to protect the system against exploitation of the hardware decoder accelerator by malicious data embedded in the one or more frames of encoded digital streaming data, wherein the software security layer performs a data value check on data within the one or more frames when the data is used by the hardware decoder accelerator,
the method being characterised in that:
the software security layer is implemented in firmware of the system, or in a kernel driver in system software of the system, or in a software layer above a kernel driver in system software of the system.