WO2005046058A1

WO2005046058A1 - Method and apparatus for encoding and decoding digital data

Info

Publication number: WO2005046058A1
Application number: PCT/AU2004/001533
Authority: WO
Inventors: Darren Butler; Subramanian Sridharan
Original assignee: University of Queensland UQ; Queensland University of Technology QUT
Current assignee: University of Queensland UQ; Queensland University of Technology QUT
Priority date: 2003-11-07
Filing date: 2004-11-04
Publication date: 2005-05-19
Anticipated expiration: 2006-05-07

Abstract

The present invention relates to a method and apparatus for the distribution of digital data and in particular method and apparatus for packaging and distributing compressed digital data in the form of Audio and/or Video (A/V) content. The digital data is compressed in accordance with a chosen compression algorithm (33, 38), while at least one cooperating decompressor is complied from source code into an intermediate code (32, 36) format capsule the decompressor capsule is then combined with the compressed digital data (34, 39) to produce encoded content for distribution in a bit stream.

Description

TITLE

METHOD AND APPARATUS FOR ENCODING AND DECODING DIGITAL DATA BACKGROUND OF THE INVENTION

Field of the Invention

The present invention relates to a method and apparatus for the distribution of digital data. In particular, although not exclusively, the present invention relates to a method and apparatus for packaging and distributing compressed digital data in the form of Audio and/or Video (A/V) content.

Discussion of the Background Art

Often the distributors of digital data, particularly AΛ content, fail to consider the rapidly evolving nature of today's player technologies. Add to this the fact that new player technologies are not always readily backwards compatible or platform independent, and this ultimately results in compatibility problems between new and old player versions. Therefore, the choice of player technology becomes critical for the distributor, as playback quality is weighed against the drive to reach the largest possible audience.

A typical solution to the problem associated with new versions of players used in internet-based distribution systems, is to provide regular updates of decoder software, which a subscriber is able to download and install on their player system. However, codecs must be provided for all target platforms and the complexity involved often restricts the distributor to only one or two codecs. This is in itself is problematic as currently no one codec provides optimal playback of all available AΛ/ data formats.

One solution to the problem of backwards compatibility, which is utilised by Microsoft Windows Media Player, is to provide an automatic detection scheme. Media Player senses which codec is required to decompress the AΛ content. If the codec is unavailable, Media Player then attempts to automatically download the required codec. However, this solution is once again platform dependent and is limited to Microsoft's own codecs. A further limitation imposed on this solution is the problem of identifying the required codec. Microsoft's solution to this is to use a Four Character Code (FOURCC), to label the data format of a compressed bit-stream. Furthermore, to ensure that the codes are unique, each new FOURCC must be registered with Microsoft before it can be used. Although this technique has proven quite successful in practice, it does not natively support different versions of the same codec resulting in a proliferation of codes. For example, DIV3, DIV4, DIV5 and DIVX all refer different versions of the DivX implementation of the Simple Profile of the MPEG-4 standard. This trend of using different codes for different major versions of a codec is quite common, but fails to account for different minor versions. Essentially, whenever a change is made that is not backwards compatible, a new FOURCC must be registered and the superseded codec must be retained indefinitely.

For stand-alone or non internet-based players such as DVD players, portable digital media players or the like, updating the system to accommodate changing standards and formats is not readily possible. For example, most DVD players and media do not always utilise the latest and most advanced codec technologies. This in itself limits the player lifespan and has the potential to limit media storage capacity. Currently all DVDs are compressed according to the MPEG-2 standard, which allows storage of 4.7 GB of AΛ/ content on a single-sided, single layer DVD. This is in contrast to MPEG-4 simple profile, which allows the same amount of content to be stored within 1.36GB or on two standard CDs.

The breaking of DVD encryption and the development of these new codec technologies has been the cause of some concern for DVD manufacturers, since specific DVD media and authoring hardware are no longer required to produce unauthorised copies. A PC running the MPEG-4 simple profile codec coupled with CD writing equipment is sufficient to reproduce large quantities of unauthorised DVDs or the like. Indeed the increase in the trade of illegal reproductions has prompted many manufacturers to invest heavily in copy protection technologies and other counter measures to prevent the widespread practice of copying or "ripping". This in itself is costly and can also lead to player compatibility problems and, in some instances, prevent authorised users from playing the material on their older players.

Clearly, it would be advantageous if a system for distributing AΛ/ content could be provided, that is platform and version independent, which is not readily reverse engineered and maintains the level of seamless playback to which subscribers have become accustomed.

SUMMARY OF THE INVENTION

Disclosure of the Invention

Accordingly, in one broad aspect of the present invention there is provided a method of encoding digital data for bit stream distribution, said method including the steps of: compressing the digital data in accordance with a chosen compression algorithm; compiling at least one cooperating decompressor from source code into an intermediate code format capsule; and combining the compiled decompressor capsule and the compressed digital data to produce encoded content for distribution in a bit stream. In another aspect of the present invention there is provided a method of encoding AΛ/ content including the steps of: compressing AΛ/ content in accordance with a chosen compressor; compiling at least one decompressor from source code into an intermediate code format; and combining the intermediate code format and the compressed AΛ/ content to produce encoded content.

In another broad aspect of the present invention there is provided a method of decoding digital data distributed as a bit stream, said method including the steps of: extracting compressed digital data and at least one decompressor from the bit stream, wherein said at least one decompressor is contained in an intermediate code format capsule; translating the intermediate code format of the at least one decompressor to the native code format of the host system; and decompressing the digital data utilising the native code format of the said at least one decompressor, into a useful data format.

In a further aspect of the present invention, there is provided a method of decoding AΛ/ content including the steps of: extracting compressed AΛ/ content and at least one decompressor from a bit stream, wherein the extracted at least one decompressor is in an intermediate code format; translating the intermediate code format of the at least one decompressor into the native code format of the host system; and decompressing the AΛ/ content utilising the native code format of said at least one decompressor, into a playable data format.

In yet another aspect of the present invention there is provided a method for distributing AΛ/ content including the steps of: compressing AΛ/ content in accordance with a chosen compressor; compiling at least one decompressor from source code into an intermediate code format; combining the intermediate code format and the compressed AΛ/ content; transporting the combined AΛ/ and intermediate code format to a remote site; extracting the compressed AΛ/ content and at least one decompressor at the remote site, wherein the extracted at least one decompressor is in an intermediate code format; translating the intermediate code format of the at least one decompressor into the native code format of the host system; and decompressing the AΛ/ content utilising the native code format of said at least one decompressor, into a playable data format. In a still further aspect of the present invention there is provided an apparatus for encoding AΛ/ content including: at least one processor, wherein the at least one processor is loaded with program instructions adapted to: • compress AΛ/ content in accordance with a chosen compression algorithm; • compile at least one decompressor from source code into an intermediate code format; and • combine the compressed AΛ/ content and the intermediate code format.

In yet another aspect of the present invention there is provided an apparatus for decoding AΛ/ content including: at least one processor, wherein the at least one processor is loaded with program instructions adapted to: • extract compressed AΛ/ content and at least one decompressor from a bit stream, wherein the extracted at least one decompressor is in an intermediate code format; • translate the intermediate code format of the at least one decompressor to a native code format suited to said at least one processor; and • decompress the AΛ/ content in accordance with the native code format of the at least one decompressor, into a playable data format.

In still a further aspect of the present invention there is provided a system for distributing AΛ/ content, the system including: a first processor, wherein the first processor is loaded with program instructions adapted to: • compress AΛ/ content in accordance with a chosen compression algorithm; • compile at least one decompressor from source code into an intermediate code format; and • combine the compressed AΛ/ content and the intermediate code format; at least one distribution channel for transporting the combined intermediate code format and AΛ/ content in a bit stream to a remote site; and a second processor at the remote site, wherein the second processor is loaded with program instructions adapted to: • extract compressed AΛ/ content and at least one decompressor from the bit stream, wherein said at least one decompressor is in an intermediate code format; • translate the intermediate code format of said at least one decompressor to a native code format suited to said second processor; and • decompress the AΛ/ content utilising the native code format of the at least one decompressor, into a playable data format.

In a further aspect of the present invention there is provided a computer readable medium bearing instructions for the implementation for at least one of the methods defined above.

Preferably the compressor and decompressor employ at least one of MPEG-1 , MPEG-2, MPEG-4, MHEG, H.261 , H.263, H.264, or any other suitable AΛ/ compression and decompression algorithms.

The intermediate code format may take the form of a Register Transfer Language (RTL) (which targets a theoretical machine with an infinite number of registers), D- Code (as used by Queensland University of Technology's Modula series of compilers) or Architecture Neutral Development format (ANDF) Intermediate code or any other suitable intermediate representation.

The distribution channel may include retail or wholesale channels. The distribution channel may employ signals sent over a communications network such as the Internet, LAN, WAN, Ethernet, ATM, PSTN, POTS or any other suitable network topology. Alternatively, the distribution channel may be physical media in the form of optical, magnetic or electronic storage media, such as DVD's, CDs, Zip disk(s), USB flash cards or any other suitable storage media. Preferably, the combined bit stream includes suitable counter measures such as full encryption, registration codes or other such security mechanisms. This may include the use of such security measures as changing the encryption key or completely changing the encoding by transporting an updated decompressor to the receiver.

Suitably, local processor type is detected prior to translation of intermediate code into a native code format for local execution of the decompression algorithm.

Additional security measures may also be employed during the decoding process of the combined bit stream on an end user's system, such as having the player ensure that the decompressor is valid before using it.

Preferably, the player utilises an application programming interface (API) which allows the selection of the appropriate decompressor for a desired bit rate.

Each audio and video channel may be compressed separately allowing the best available codec technologies to be utilised for each channel. Alternatively, the audio channels and video channels may be merged and compressed as a single audio and video data streams.

One advantage of embodiments of the present invention is that the problem of backwards compatibility associated with different player versions is substantially eliminated. This is because the correct decompressor is always contained in a transmitted bit-stream. In fact, there is no requirement, other than for informational purposes, for the decompressor to be identifiable and hence, the prior art uniquely identified encoding systems, such as FOURCC, are superfluous.

Another advantage is that new codecs can be utilised as soon as they are developed. They do not need to be separately or explicitly distributed because they will be automatically provided to users when they access any content compressed by the new codecs. Still a further advantage is that the lifetime of a player utilising the present invention is governed by its hardware alone. It is totally independent of advances in compression and decompression technologies.

A further advantage of embodiments of the present system is that it allows companies to develop and deploy proprietary codecs that do not conform to any standards but will still be guaranteed interoperability.

Yet a further advantage of the invention is that the burden of installing and maintaining codecs, for the purposes viewing compressed AΛ/ content, is entirely eradicated.

Another advantage of the present invention is that different decompressor can be utilised for different target bit-rates and upon selecting a desired bit-rate, the user will be provided with the required decompressor.

Still a further advantage is that in addition to changing the decryption key, the security of an encrypted communications channel can be enhanced by completely changing its encoding. It is highly unlikely that the encryption could be broken in the time it takes to transmit the new decompressor and it is near impossible to reconstruct the original information without the decompressor.

Further advantages and features of the present invention will be made more apparent in the following discussion of the preferred embodiments.

BRIEF DETAILS OF THE DRAWINGS

In order that this invention may be more readily understood and put into practical effect, reference will now be made to the accompanying drawings which illustrate the preferred embodiments of the invention, and wherein: FIG. 1 is a schematic block diagram of the systems of the prior art; FIG. 2 is a schematic block diagram illustrating the principle of an intermediate code format employed by compilers; FIG. 3 is a schematic block diagram of the encapsulation process of one embodiment of the present invention; FIG. 4 is a schematic block diagram of the decoding process of one embodiment of the present invention; FIG. 5 is a schematic block diagram of the Architecture Neutral Distribution format; FIG. 6 is a schematic block diagram representing two possible implementations of the present invention; and FIG. 7 is a diagram of a GUI of one embodiment of the present invention.

DESCRIPTION OF EMBODIMENTS OF THE INVENTION

Under an existing distribution model for AΛ/ content 10, as shown in FIG. 1 , users are responsible for installing and configuring decompression software required prior to viewing compressed content. The video and audio components are separately compressed, and multiplexed into a single bit stream, stored intermediately (e.g. a file) 11 and then transported to an end user's system either on a physical media or via a communications network.

The bit stream is then demultiplexed into the constituent audio and video streams after transportation. The user's system then reads the FOURCC to verify which decompressor version to use. The system then retrieves the appropriate decompressor from a library of stored decompressors. The constituent streams are then decompressed using the relevant decompressor 12. As discussed above, these current systems are prone to the problems of platform dependency and codec versioning.

By contrast, the present invention embeds the required decompressors in a bit stream so that they may be transparently provided to users when they access the content. In implementing this type of distribution model, it is not sufficient to insert the decompressor into the bit stream in a native code format (i.e. binary), as the client's operating platform is not known beforehand. Nor is it desirable to send the decompressor in source form, for compilation on the client's platform, as this would also reveal proprietary functional aspects of the decompressor and leave it vulnerable to copying. Furthermore, any requirement for the end user to compile the decompressor every time AΛ/ content is to be played is extremely inefficient.

To avoid the problems associated with various player versions and inefficient resource utilisation, the present embodiment employs an intermediate code format. The use of an intermediate code format has until now been limited to compiler design. Typically compilers are split into two parts, a front-end and a back-end. The front-end verifies that the code is syntactically and semantically correct and applies any platform independent optimisations. Conversely, the back-end is responsible for applying platform dependent optimisations and generating the final machine code for execution. Communication between the two compiler ends is enabled by the intermediate code format (20) as depicted in FIG. 2. The front-end compiles the source code to the intermediate code format and the back-end translates the intermediate code format into the machine code for the target platform. Alternatively, in cases utilising interpreters such as Java and .NET, the intermediate code format is interpreted directly and never explicitly reaches the level of machine code.

Segmenting the compiler into platform independent and platform dependent parts has other benefits. Compilers for completely different programming languages can target exactly the same intermediate code format and hence utilise exactly the same back-end as is also shown in FIG. 2. Consequently, when a new compiler is being developed, the back-end may already exist for some, if not all, of the target platforms. Therefore, only the front-end needs to be developed and since the front-end is platform independent, developing it once, develops it for all platforms. The use of intermediate formats can also aid in porting compiler front-ends to new platforms. This is done by firstly compiling the front-end to an intermediate code format on one platform. Then, it can be shipped to the new platform and translated to a native code format using the existing back-end. It just so happens that this is precisely the behaviour that is required for Encapsulated Decompression (ENCDEC). With reference to FIG. 3, there is illustrated the encoding process of one embodiment of the present invention. In the illustrated example the video and audio streams are compressed separately. Firstly, the content creator must choose the appropriate compressor(s) and decompressor(s) for each data stream 30, 35. The video and audio stream compressors are then compiled into their native code format 31 , 37 on the creator's system. The video and audio streams are then compressed into compressed native code format 33, 38.

The required decompressor(s) for each stream are compiled to an intermediate code format 32, 36. The intermediate code format is then encapsulated within the compressed video and audio streams (34 and 39 respectively). The two streams are then multiplexed into a mutiplexed compressed video/audio stream 40 for transport.

In this particular example, the Architecture Neutral Development Format (ANDF) is the intermediate code format of choice. The concept of ANDF is illustrated in FIG. 5. The ANDF concept is similar to the idea of dividing a compiler into a platform independent front-end and a platform dependent back-end. That is, given N compilers and M machines, you need only N front-ends (ANDF producers) and M back-ends (ANDF installers) as opposed to N X M full compilers. However, unlike other intermediate formats, ANDF does not involve a virtual machine implementation. Instead, it abstracts programming language constructs, such as procedures, data structures and loops. These abstractions were designed to represent the variants that are found in different programming languages and, at least theoretically, ANDF intermediate code producers can be developed for any programming language.

The primary advantage of ANDF is that it allows an architecture neutral description of an application and this description is sufficient for installing the application on any compliant computer or processor. However, this is not the only reason for utilising ANDF in this embodiment, other benefits include:

1. Developing applications that run on multiple platforms and porting existing applications to other platforms is much less expensive. 2. Given that an application has been extensively tested on one platform, then only rudimentary testing is probably necessary on the other target platforms. Ideally, no additional testing would be required at all.

3. Software developers can utilise a programming language for which there is an ANDF producer regardless of whether the producer runs on the targeted platforms.

4. The task of maintaining applications for new operating systems and hardware releases is much easier as it is only the installers that truly need to be maintained.

ANDF maintains its programming language abstractions in a tree-like structure. It uses a symbolic representation of memory, which allows the installers to choose the storage layout that is most suitable for their architecture. Furthermore, other than the program description, only information which is useful for optimisations is retained. Any details that could be used to reverse engineer the application, such as variable and procedure names, are discarded. Finally, in order to distribute ANDF intermediate code format, it is flattened into a compactly encoded bit-stream.

The example of FIG. 5 shows several ANDF producers 51 each utilising a different high-level language 50, which is transformed into the ANDF intermediate code format 52. The format is then distributed to variety of installers 53 each of which utilise a different platform.

In the case of the present embodiment, the TenDRA producer 51a was chosen as the ANDF producer. TenDRA is an open source C/C++ compiler and checker, and was developed by the Open Software Systems Group (OSSG) of the UK's Defence Research Agency (DRA). TenDRA compiles C/C++ source files into what are known as ANDF capsules, which can be merged into a single capsule for distribution. This distribution capsule can describe an entire application, but for the present invention it has been modified to describe a decompressor. While the concept of encapsulating the decompressor into the bit stream is theoretically sound, in practice, there are many functions that simply cannot or should not be included in the bit-stream. Primarily, this is because these functions are either platform dependent or unsafe. Examples of such functions are the POSIX memory management functions, malloc, calloc, and free. Although these functions are common, they are only guaranteed to exist if the target machine's operating system is POSIX compliant. Furthermore, allowing decompressors to call these types of functions directly is extremely unwise, as it would allow them to allocate memory uncontrollably and free other memory that they did not control.

To avoid such situations the present embodiment of the ENCDEC player provides a standardised list of safe functions. Furthermore, the ENCDEC player is responsible for ensuring that these are the only system functions that the decompressors are able to invoke. The current standardised list of safe system functions for the present embodiment is contained in Appendix A.

The process for playing an ENCDEC bit-stream of the present embodiment is shown in FIG. 4. Firstly, the user's system must demultiplex the audio and video bit-streams 41 and extract the respective decompressors in their intermediate code format 42, 43. In this case, the ENCDEC player is essentially a modified ANDF installer. After extracting the intermediate code format decompressors 42, 43, the ANDF tree is then reconstructed and adapted for the target platform. Finally, the system translates the intermediate code format to a native code format to build each decompressor. Once each decompressor is translated to native code format 44, 45 the content is then decompressed into the appropriate playable data format 46, 47 for viewing and/or listening. It is to be appreciated that the player software could be distributed to a client's system via a network or on a computer readable medium such as a CD ROM adapted for specific target platforms.

The architecture of the target machine will be known upon receipt of the data stream by the user's system at which time, it is also possible for platform dependent optimisations to be applied. TenDRA's TDF interface utilises tokenisation, which produces an architecture specific TDF representation of the application, which can be translated into machine code on the target system by the appropriate TDF installer. However, care must be taken to minimise the amount of time that is required to perform the translation. Too many optimisations will likely cause too much of a delay without appreciably improving the performance of the decompressor, but too few optimisations could result in too many dropped frames for example.

Once the decompressor has been successfully translated and linked, it must then be loaded by the player, for use in the decompression of the audio stream 46 and video stream 47. The mechanism for doing this is heavily dependent on the operating system software of the user's system. However, a common requirement is that the functions that are provided by the decompressor must already be known. Therefore, all decompressors are required to implement a standardised interface. In addition to decompressing frames, by invoking functions from the interface, ENCDEC players are able to initialise, release and control the decompressor. Details of typical functions for the decompressor interface are given in Appendix B.

As encapsulated decompression transparently provides users with the code to decompress an AΛ/ bit-stream by simply embedding or encapsulating the decompressor within the bit stream, without taking major precautions, it is conceivable that additional and potentially destructive code could also be hidden within the stream. Then, simply by playing a movie, a user could unknowingly open their computer to an attack by "hackers" or other, so called, "cyber-vandals".

The designers of some programming languages, such as, Java, are also especially conscious of these security issues. As such, these types of languages are typically formulated such that risky constructs, like pointer arithmetic and explicit jumps, are not possible.

As previously discussed the present embodiment prohibits the decompressors from invoking any system functions other than those listed in the standardised list of safe functions. Without this restriction, mischievous or "Trojan" decompressors could easily exploit system functions. For example, they could interfere with the computer's hard-drive or open communications sockets. In addition to this prohibition, the concept of strict support for safety within a programming language such as that used in Java offers a greater level of security. Hence, the applicant is presently developing a Domain Specific Language (DSL) specifically for authoring decompressors to provide additional security. However, the fact that the programming language prohibits a particular operation does not imply that the operation cannot be present inside the bit-stream.

Even given the above security measures, it is still quite possible that a hacker could bypass the compiler and cause generation of intermediate code directly. Java combats this threat by verifying that the code is safe before executing it. Likewise, an ENCDEC player should ensure that the decompressor is valid before using it. However, the applicant believes that this may entail further modification of ANDF and as such is the subject of the applicant's ongoing research.

FIG. 6 schematically represents two (2) possible implementations of the present invention. A data stream 62 may be provided to a host system 60 via either physical media such as optical discs 61a in the form of a DVD or a CD ROM, or via an I/O port 61b coupled to a communications channel (not shown). The host system may be exemplified by either a dedicated optical disc player such as suited for coupling to an audio-visual system 60a or a personal computer system 60b having a modem coupled to the Internet, respectively. The data stream 62 is (as described above) composed of two main components, compressed data 62a and an encapsulated decompressor 62b. The decompressor is stored within the data stream in an intermediate code format, which is then extracted 63 and translated to a native code format 64 of the host system 60.

In the case of the optical disc player, as soon as a disc is inserted and played, the intermediate code for its decompressor will be loaded. For more efficient access, the decompressor may be located at a standard position on every disc, and for robustness, it may be located at many positions. Once loaded, the player's digital signal processor (DSP) will translate the intermediate code into machine instructions using compiler functionality stored in its Read Only Memory (ROM). In the case of the personal computer system 60b implementation, the translation of the decompressor intermediate code is undertaken by compiler functionality provided through the host central processing unit (CPU) of the personal computer. Accordingly, the native code decompressor 64 is able to execute reliably without any legacy problems or version issues when loaded into the specific CPU for which the code has been generated.

For both implementations, once the decompressor is in the native code format, it is used to decompress 65 the compressed data 62a portion of the data stream 62 to produce a playable data stream 66. This playable data stream is then loaded by the player hardware/software 67, the player then reconstructs the full version of the digital content 68 which is then displayed 69 to the consumer or end user.

From the end user's perspective all that is seen of the extraction and compilation of the AΛ/ content in accordance with the invention is a front end Graphical User Interface (GUI). An example of one possible configuration for the GUI 70 is depicted in FIG 7. This GUI provides a suitable interface for use with PC-based media players. It should be appreciated that the GUI could take the form of animated menus such as those used for DVD or other optical disc players.

Once the user activates the play button 71 , the user is presented with a seamless playback of the AΛ/ content in the play area 72 and is oblivious that this action initiates the above discussed extraction and compilation process. The GUI also provides the user with additional controls such as forward (track skip), and reverse 73. These allow the user to navigate through the AΛ/ content based on a temporal basis, as indicated by timeline 74. As with other PC-based players the GUI in this particular embodiment is also provided with the standard file and view menus 75 allowing the user to toggle the viewing modes and to select the desired file to load and play.

It is to be understood that the above embodiments have been provided only by way of exemplification of this invention, and that further modifications and improvements thereto, as would be apparent to persons skilled in the relevant art, are deemed to fall within the broad scope and ambit of the present invention set put in the claims that follow.

Appendix

Encapsulated Decompression: System Functions

A.1 Type Declarations

A.1.1 Basic Types Boolean = {False, True} integer = Z Natural = N Character = ['0'...'9' |'A'...'Z' I 'a'...'z'] Address c Integer

A.1.2 Fixed Size Types intδ = [-128...127] intlβ = [-32768.-32767] int32 = [-2147483648...2147483647] uintδ = [0...255] uintlβ = [0...65535] uint32 = [0...4294967295]

A.1.3 Record Types YpCbCr = RECORD Yp: POINTER TO uintδ; YpStride: int32; Cb: POINTER TO uintδ; CbStride: int32; Cr: POINTER TO uintδ; CrStride: int32; xSi ze : i nt32 ; ysi ze : i nt32 ; END YpCbCr ;

A.2 Memory Management

A.2.1 MEM Create PROCEDURE ME „Create( nBytes: Natural): ADDRESS; Description: This function allocates a contiguous block of memory for use by the decompressor. This is the only way in which decompressors can obtain memory for their use. Pre-conditions: • nBytes is the number of bytes of contiguous memory to allocate. Post-conditions: • True Returns: • If an appropriately sized block of memory was successfully allocated then a reference to it is returned. Alternatively, if allocation failed, then 0 is returned.

A.2.2 MEM_Destroy PROCEDURE MEM_Destroy( mem : Address) ; Description: This function will return memory that was previously allocated using MEM_Create to the system. It ensures that the block of memory is valid before attempting to release it to avoid corrupting the heap. Pre-conditions: • mem references a valid memory block to release. Post-conditions: • The resources associated with mem have been released.

A.2.2 MEMjCopy PROCEDURE MEM_Copy( dst : Address ; src : Address ; nBytes : ui nt32) ; Description: This function will copy a number of bytes from one memory location to another. The size of the memory blocks will be verified before copying to ensure that no foreign memory can be overwritten. Pre-conditions: • dst references the destination memory location. • src references the source memory location. • nBytes is the number of bytes of memory to copy. Post-conditions: • nBytes of memory have been copied from src to dst.

A.2.4 MEM Set PROCEDURE E _Set( mem: Address; val : uintδ; nBytes: uint32);

Description: This function can be used to initialise every byte of a block of contiguous memory to a given value. The size of the memory block will be verified to ensure that no foreign memory can be overwritten. Pre-conditions: • mem is the memory block to initialise. • val is the byte value with which to initialise mem. • nBytes is the number of bytes of mem to initialise. Post-conditions: • The first nBytes of mem have been set to val.

Appendix

Encapsulated Decompression: Decompressor Interface

B.1 DEC Connect PROCEDURE DEC_Connect( xsi ze : ui nt32 ; ysi ze : ui nt32) : ui ntδ ; Description: This function connects to the decompressor and prepares it for decoding. It must be called before any other function in the interface. Pre-conditions: • xSize, ySize are the desired dimensions of the decoded frames. Post-conditions: • True Returns: • If the decoder was successfully initialised then 1 is returned. Alternatively, if initialisation failed, then 0 is returned.

B.2 DEC Release PROCEDURE DEC_Rel ease () ; Description: This function will release any resources that the decompressor has previously acquired. Once it has been called, DEC_Connect must be called to re-initialise the decompressor. Pre-conditions: • True Post-conditions: • The decoder and its resources have been released. B.3 DEC Control PROCEDURE DEC_Control ( opti on : i nt32 ; param : Address) : ui ntδ ; Description: This function will be used to change the decompressor options. However, at present, no options have been standardised. Pre-conditions: • option is the decompressor option that is being changed. • param is the option specific parameter. Post-conditions: • If possible, the decompressor option has been changed. Returns: • If the decompressor option was changed successfully then 1 is returned. Alternatively, if it was not possible to change the decompressor option then 0 is returned.

B.4 DEC Decode PROCEDURE DEC_Decode ( encFrame : Address ; encBytes : ui nt32 ; decFrame : POINTER TO YpCbCr ; decFl ags : ui nt32) ; Description: Assuming that the decompressor has been initialised successfully by invoking DEC_Connect then this function can be used to decompress encoded frames. Pre-conditions: • encFrame references the encoded frame • encBytes is the number of bytes in the encoded frame. • decFrame will be initialised with pointers to the decompressed frame in Y'CbCr 4:2:0 format. • decFlags controls the decompression of the encoded frame. Post-conditions: • True Returns: • If the frame was successfully decompressed then 1 is returned. Alternatively, if the frame could not be decompressed then 0 is returned.

Claims

1. A method of encoding digital data for bit stream distribution, said method including the steps of: compressing the digital data in accordance with a chosen compression algorithm; compiling at least one cooperating decompressor from source code into an intermediate code format capsule; and combining the compiled decompressor capsule and the compressed digital data to produce encoded content for distribution in a bit stream.

2. A method of encoding Audio and Video content including the steps of: compressing Audio and Video content in accordance with a chosen compressor; compiling at least one decompressor from source code into an intermediate code format; and combining the intermediate code format and the compressed AΛ/ content to produce encoded content.

3. A method for distributing Audio and Video content including the steps of: compressing Audio and Video content in accordance with a chosen compressor; compiling at least one decompressor from source code into an intermediate code format; combining the intermediate code format and the compressed Audio and Video content; transporting the combined Audio and Video and intermediate code format to a remote site; extracting the compressed Audio and Video content and at least one decompressor at the remote site, wherein the extracted at least one decompressor is in an intermediate code format; translating the intermediate code format of the at least one decompressor into the native code format of the host system; and decompressing the Audio and Video content utilising the native code format of said at least one decompressor, into a playable data format.

4. A method of decoding digital data distributed as a bit stream, said method including the steps of: extracting compressed digital data and at least one decompressor from the bit stream, wherein said at least one decompressor is contained in an intermediate code format capsule; translating the intermediate code format of the at least one decompressor to the native code format of the host system; and decompressing the digital data utilising the native code format of the said at least one decompressor, into a useful data format.

5. A method of decoding Audio and Video content including the steps of: extracting compressed Audio and Video content and at least one decompressor from a bit stream, wherein the extracted at least one decompressor is in an intermediate code format; translating the intermediate code format of the at least one decompressor into the native code format of the host system; and decompressing the Audio and Video content utilising the native code format of said at least one decompressor, into a playable data format.

6. The method according to any one of claims 1 to 3 wherein the step of combining further includes applying a suitable electronic counter measure.

7. The method according to claim 6 wherein the electronic counter measure is selected from one or more of the following full encryption, registration codes, rolling the encryption key or changing the encoding by transporting an updated version of the decompressor.

8. The method according to claim 4 or claim 5 wherein the step of decoding further includes the step of verifying that the decompressor is valid before execution.

9. The method according to any one of claims 1 to 8 wherein the compression and decompression algorithms are selected from one or more of MPEG-1 , MPEG-2, MPEG-4, MHEG, H.261 , H.263, H.264, or other suitable compression and decompression algorithms.

10. The method according to any one of claims 1 to 9 wherein the intermediate code format is selected from one or more of a Register Transfer Language (RTL), D- Code, Architecture Neutral Intermediate code format (ANDF), or other suitable intermediate representation.

11. An apparatus for encoding Audio and Video content including: at least one processor, wherein the at least one processor is loaded with program instructions adapted to: • compress the Audio and Video content in accordance with a chosen compression algorithm; • compile at least one decompressor from source code into an intermediate code format; and • combine the compressed the Audio and Video content and the intermediate code format to produce encoded content.

12. An apparatus for decoding Audio and Video content including: at least one processor, wherein the at least one processor is loaded with program instructions adapted to: • extract compressed Audio and Video content and at least one decompressor from a bit stream, wherein the extracted at least one decompressor is in an intermediate code format; • translate the intermediate code format of the at least one decompressor to a native code format suited to said at least one processor; and • decompress the Audio and Video content in accordance with the native code format of the at least one decompressor, into a playable data format.

13. The apparatus according to claim 11 wherein the processor is further adapted to apply an electronic counter measure to the encoded content.

14. The apparatus according to claim 13 wherein the electronic counter measure is selected from one or more of the following full encryption, registration codes, rolling the encryption key or changing the encoding by transporting an updated version of the decompressor.

15. The apparatus according to claim 12 wherein the processor is further adapted to verify that the decompressor is valid before execution.

16. The apparatus according to any one of claims 11 to 14 wherein the compression and decompression algorithms are selected from one or more of MPEG-1 , MPEG-2, MPEG-4, MHEG, H.261 , H.263, H.264, or other suitable compression and decompression algorithms.

17. The apparatus according to any one of claims 11 to 16 wherein the intermediate code format is selected from one or more of a Register Transfer Language (RTL), D-Code, Architecture Neutral Intermediate code format (ANDF), or other suitable intermediate representation.

18. The apparatus according to any one of claims 11 to 17 further including an application programming interface (API) which allows a user to select an appropriate decompressor for a desired bit rate.

19. A system for distributing Audio and Video content, the system including: a first processor, wherein the first processor is loaded with program instructions adapted to: • compress Audio and Video content in accordance with a chosen compression algorithm; • compile at least one decompressor from source code into an intermediate code format; and β combine the compressed Audio and Video content and the intermediate code format; at least one distribution channel for transporting the combined intermediate code format and AΛ/ content in a bit stream to a remote site; and a second processor at the remote site, wherein the second processor is loaded with program instructions adapted to: β extract compressed Audio and Video content and at least one decompressor from the bit stream, wherein said at least one decompressor is in an intermediate code format; • translate the intermediate code format of said at least one decompressor to a native code format suited to said second processor; and • decompress the Audio and Video content utilising the native code format of the at least one decompressor, into a playable data format.

20. The system according to claim 19 wherein the distribution channel is a retail and/or a wholesale channel.

21. The system according to claim 19 wherein the distribution channel employs signals sent over a communications network.

22. The system according to claim 19 wherein the distribution channel employs physical media including optical, magnetic, electronic or other suitable storage media.

23. The system of any one of claims 19 to 22 wherein said second processor type is detected prior to translation of intermediate code of said at least one decompressor into a native code format.

24. The system according to anyone of claims 19 to 23 wherein the first processor is further adapted to apply an electronic counter measure to the encoded content.

25. The system according to claim 24 wherein the electronic counter measure is selected from one or more of the following: full encryption, registration codes, rolling the encryption key or changing the encoding by transporting an updated version of the decompressor.

26. The system according to anyone of claims 19 to 25 wherein the second processor is further adapted to verify that the decompressor is valid before execution.

27. The system according to anyone of claims 19 to 26 wherein the audio content is compressed in accordance with a first compression algorithm and said video content is compressed in accordance with a second compression algorithm.

28. The system according to anyone of claims 19 to 27 wherein the compression and decompression algorithms are selected from one or more of MPEG-1 , MPEG-2, MPEG-4, MHEG, H.261 , H.263, H.264, or other suitable compression, decompression algorithms.

29. The system according to anyone of claims 19 to 28 wherein the intermediate code format is selected from one or more of a Register Transfer Language (RTL), D- Code, Architecture Neutral Intermediate code format (ANDF), or other suitable intermediate representation.

30. The system according to anyone of claims 19 to 29 further including an application programming interface (API) which allows a user to select an appropriate decompressor for a desired bit rate.

31. A computer readable medium bearing program instructions for the implementation of a method according to any one of claims 1 to 10.