WO2012126037A1

WO2012126037A1 - Method, apparatus and system for encoding video data

Info

Publication number: WO2012126037A1
Application number: PCT/AU2012/000229
Authority: WO
Inventors: Christopher James ROSEWARNE
Original assignee: Canon Kabushiki Kaisha
Priority date: 2011-03-23
Filing date: 2012-03-06
Publication date: 2012-09-27
Also published as: AU2011201344B2; AU2011201344A1

Abstract

A video encoding (100) and decoding (200) system that can reallocate arithmetically coded symbols to reduce buffering requirements is disclosed. The reallocation occurs by mapping bins used to represent each syntax element in a video bitstream between a probability level contained in a context model and an arithmetic encoder or decoder. A process for deriving a mapping is performed in the encoder and the decoder.

Description

METHOD, APPARATUS AND SYSTEM FOR ENCODING VIDEO DATA

FIELD OF INVENTION

The present invention relates generally to digital video signal processing and, more specifically, to a method, apparatus and system for generating bins for use in encoding binarised syntax elements representing video data. The present invention also relates to a computer program product including a computer readable medium having recorded thereon a computer program for generating bins . for use in encoding binarised syntax elements representing video data.

DESCRIPTION OF BACKGROUND ART

Many applications for video coding currently exist, including applications for transmission and storage of video data. Many video coding standards have also been developed and are currently in development. Recent developments in video coding standardisation have led to the formation of a group called the "Joint Collaborative Team on Video Coding" (JCT-VC) which includes members of the International Telecommunications Union (ITU-T) and the Moving Picture Experts Group (MPEG). The Joint Collaborative Team on Video Coding (JCT-VC) has the goal to produce a new video coding standard to significantly outperform the H.264/MPEG-4 AVC standard, which is itself a large improvement on previous video coding standards such as MPEG-4 and ITU-T H.263. The new video coding standard under development has been named high efficiency video coding (HEVC). The Joint Collaborative Team on Video Coding (JCT-VC) is also considering implementation challenges arising from technology proposed for high efficiency video coding (HEVC) that create difficulties when scaling implementations of the standard to operate at high resolutions or high frame rates.

One area of the H.264/MPEG-4 AVC standard that presents difficulties for implementation is efficiently entropy coding the syntax elements used to represent video data. The . H.264/MPEG-4 AVC standard introduced a coding scheme known as the context adaptive binary arithmetic coding (CABAC) scheme, which provides significant coding benefits over an earlier coding scheme known as the context adaptive variable length coding (CAVLC) scheme. A reduction in bitstream size of 12-15% is achieved for many bitstreams, with higher reductions possible for some bitstreams. This size reduction is achieved at a cost of increased computational complexity in performing the arithmetic coding and difficulty in performing any of the coding steps in parallel, due to serial data dependencies inherent in the context adaptive binary arithmetic coding (CAB AC) algorithm.

Some progress has been made in arithmetic coding. In the H.264/MPEG-4 AVC standard, when context adaptive binary arithmetic coding (CABAC) is enabled, each syntax element is expressed as a sequence of bins, where the bins are selected from a set of available bins. Creating such a sequence of bins is known as "binarising" a syntax element. The set of available bins is known as the "context model". Each bin has context information, including an associated probability level which is used to perform arithmetic coding. Each bin also has an associated value, indicating the likely bin value, known as the "most probable symbol" or 'valMPS'. As each bin is encoded or decoded, the associated probability level is updated. An instance of the context model exists at both the encoder and decoder and, provided no errors in transmission occur, updating of the probability level for each bin is synchronised between the encoder and decoder. For each bin in the binarised syntax element, a symbol is coded in the bitstream by an arithmetic encoder, using the probability level associated with the bin. Symbol values of '0' and T indicate whether the bin value is equal to the most probable symbol ( 'valMPS') or not equal to the most probable symbol ('valMPS') respectively.

An issue for implementing context adaptive binary arithmetic coding (CABAC) is that the context adaptive binary arithmetic coding algorithm has a feedback dependency loop between a context modeller, for updating context information of each bin, and an arithmetic coder. The length of the feedback dependency loop limits bin throughput achievable in hardware implementations of context adaptive binary arithmetic coding (CABAC) for a given clock frequency. The limitation becomes problematic when an implementation is required to provide higher bin throughput required to support higher frame rates and higher resolutions that are becoming increasingly relevant, such as Super Hi-Vision.

An entropy coding concept known as the 'novel entropy coding concept' submission to the Joint Collaborative Team on Video Coding (JCT-VC) ("JCTVC-A032") submitted by Fraunhofer Heinrich Hertz Institute proposes that instead of coding all symbols serially into a single bitstream, a multitude of bitstreams may be produced. The multitude of bitstreams are subsequently merged into a single bitstream. The symbols being coded are quantized into a number of data streams according to their associated probability level. Each data stream is coded using a symbol encoder optimised to encode symbols where ' 1 ' values occur at a particular probability, known as a fixed probability. The novel entropy coding concept scheme enables multiple fixed probability arithmetic coders to operate in parallel, significantly shortening the serial loop existing in H.264/MPEG-4 AVC between syntax element binarisation and arithmetic coding.

Using an array of fixed probability arithmetic encoders, each one designed to encode symbols occurring at particular fixed probability, enables replacement of a sequential symbol coding mechanism from context adaptive binary arithmetic coding (CABAC) with a set of look-up tables. The look-up tables accept a variable number of bins as input and produce a variable length codeword as output. The contents of the look-up table are designed such that symbols with T values occurring at a particular probability at the input result in output variable length codewords having the most compact representation of the symbol data. The novel entropy coding concept scheme is applied in reverse at the decoder to recover symbols having ' 1 ' values occurring at each fixed probability. A separate bitstream is created for symbols coded at each fixed probability. Alternatively, a fixed mapping from multiple groupings of fixed probabilities to each fixed probability arithmetic encoder or decoder may be used. This reduces the number of arithmetic encoders and decoders, achieving a compromise between throughput and coding efficiency. Throughput is increased, at a cost of a small reduction in coding efficiency. The reduction in coding efficiency occurs because the mapping results in a suboptimal fixed probability coder being used for a given bin probability level.

In a submission titled 'Dynamic Source Selection', submission (JCTVC-B034) to the Joint Collaborative Team on Video Coding (JCT-VC), it was observed that for each fixed probability that a bin may take, the actual number of encoded least probable symbol (LPS) values, as a proportion of the total number of symbols coded at that fixed probability, differed from the proportion implied by the fixed probability. For example, if the fixed probability was 0.2, one would expect that when coding batches of one-thousand (1000) symbols at the fixed probability on average two-hundred (200) symbols would be least probable symbol (LPS) symbols. In practice, actual symbol count was observed to differ from a predicted count by up to a factor of two (2).

A dynamic source selection encoding method has been proposed. In the dynamic, source selection method, a source is defined as the symbols provided by the binarisation process having probability levels within a particular range. A remapping of each set of symbol probability levels to available fixed probability encoders is provided, thus improving the entropy coding of the bins by better selecting fixed probability encoders. Adapting such a mapping from the range of available bin probability levels onto a set of fixed probability encoders requires measuring the quantity of symbols occurring at each fixed probability. The results of the measurement are then used to select an optimal mapping.

Dynamic source selection, as described in JCTVC-B034, has two key disadvantages. Firstly, a mapping must be coded in a bitstream, increasing the size of the bitstream. Such an overhead is incurred once per slice of data. Secondly, all symbols must be examined to determine the mapping which will be used to code the same symbols. In an implementation, the mapping requires a buffer large enough to hold up to all the symbols for one slice of data. The exact buffer size required is unpredictable, depending on frame size and also on image statistical characteristics that cannot be known prior to encoding. The large size of the buffer requires use of off-chip storage, such as SDRAM, as on-chip SRAM is very costly and hence only suitable for small fixed-size buffering. Yet the bandwidth to off-chip memory is already a contended resource, with significant bandwidth required for fetching reference frame data. Additionally introducing a dedicated SDRAM would represent a significant cost increase. Buffering also introduces additional latency that is undesirable for streaming applications, which already suffer from latencies due to frame buffering and communication channel delays.

Thus, a need clearly exists for a video codec implementation that meets real-time performance constraints while offering a feasible hardware cost. SUMMARY OF THE INVENTION

It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements.

Disclosed are arrangements which seek to address the above problems by providing a method of encoding bins for use in encoding video data, which uses a mapping between bin probability ranges and fixed probability encoders and decoders. The method allows the mapping to be reconstructed in a decoder, avoiding the need to encode the mapping into a bitstream. In addition, the method avoids the need to buffer all symbols in the encoder prior to determining the mapping.

According to one aspect of the present disclosure there is provided a method of generating bins used to encode binarised syntax elements representing video data, the method comprising:

receiving a plurality of bitstreams encoding symbols indicating values of the bins; decoding each of the plurality of bitstreams into the symbols using one of a plurality of decoders, each of said decoders being configured for a particular probability value;

determining a first mapping from probability ranges associated with an expected probability value of each of the bins to said plurality of decoders;

selecting a plurality of the decoded symbols to generate a first subset of the bins, each of the selected symbols being selected from one of said decoders according to the first mapping;

determining a count of the selected symbols associated with each of the probability ranges;

determining a second mapping, from said probability ranges to said plurality of decoders, based on said determined counts; and

generating a second subset of the bins by selecting further ones of said symbols from said plurality of decoders according to said second mapping.

According to another aspect of the present disclosure there is provided a system for generating bins used to encode binarised syntax elements representing video data, the system comprising:

a memory for storing data and a computer program;

a processor coupled to said memory for executing said computer program, said computer program comprising instructions for:

_; receiving a plurality of bitstreams encoding symbols indicating values of the bins;

decoding each of the plurality of bitstreams into the symbols using one of a plurality of decoders, each of said decoders being configured for a particular probability value;

determining a second mapping, from said probability ranges to said plurality of decoders, based on said determined counts; and generating a second subset of the bins by selecting further ones of said symbols from said plurality of decoders according to said second mapping.

According to still, another aspect of the present disclosure there is provided an apparatus for generating bins used to encode binarised syntax elements representing video data, the apparatus comprising:

means for receiving a plurality of bitstreams encoding symbols indicating values of the bins;

means for decoding each of the plurality of bitstreams into the symbols using one of a plurality of decoders, each of said decoders being configured for a particular probability value; means for determining a first mapping from probability ranges associated with an expected probability value of each of the bins to said plurality of decoders;

means for selecting a plurality of the decoded symbols to generate a first subset of the bins, each of the selected symbols being selected from one of said decoders according to the first mapping;

means for determining a count of the selected symbols associated with each of the probability ranges;

means for determining a second mapping, from said probability ranges to said plurality of decoders, based on said determined counts; and

means for generating a second subset of the bins by selecting further ones of said symbols from said plurality of decoders according to said second mapping.

According to still another aspect of the present disclosure there is provided a computer readable medium, having a program recorded thereon, where the program is configured to make a computer execute a procedure to generate bins used to encode binarised syntax elements representing video data, the program comprising:

code for receiving a plurality of bitstreams encoding symbols indicating values of the bins;

code for decoding each of the plurality of bitstreams into the symbols using one of a plurality of decoders, each of said decoders being configured for a particular probability value; code for determining a first mapping from probability ranges associated with an expected probability value of each of the bins to said plurality of decoders;

code for selecting a plurality of the decoded symbols to generate a first subset of the bins, each of the selected symbols being selected from one of said decoders according to the first mapping; code for determining a count of the selected symbols associated with each of the probability ranges;

code for determining a second mapping, from said probability ranges to said plurality of decoders, based on said determined counts; and

code for generating a second subset of the bins by selecting further ones of said symbols from said plurality of decoders according to said second mapping.

According to still another aspect of the present disclosure there is provided a method of encoding bins used to encode binarised syntax elements representing video data, the method comprising:

receiving the binarised syntax elements encoded in a plurality of bins;

generating a plurality of symbols, indicating the values of said bins, each of the symbols being associated with a probability range;

determining a first mapping to a plurality of encoders, each said encoder being configured for a particular probability, the first mapping being determined from the probability ranges associated with an expected value of each of the bins;

assigning a plurality of the symbols, representing a first subset of said bins, to one of said encoders according to said first mapping;

determining a count of the symbols associated with each of the probability ranges; determining a second mapping, from said probability ranges to said plurality of encoders, based on said determined counts; and

encoding symbols, representing a second subset of said bins, by assigning further ones of said symbols to said plurality of encoders according to said second mapping.

According to still another aspect of the present disclosure there is provided a system for encoding bins used to encode binarised syntax elements representing video data, the system comprising:

a memory for storing data and a computer program;

receiving the binarised syntax elements encoded in a plurality of bins;

generating a plurality of symbols,^' indicating the values of said bins, each of the symbols being associated with a probability range; determining a first mapping to a plurality of encoders, each said encoder being configured for a particular probability, the first mapping being determined from the probability ranges associated with an expected value of each of the bins;

determining a count of the symbols associated with each of the probability ranges;

determining a second mapping, from said probability ranges to said plurality of encoders, based on said determined counts; and

According to still another aspect of the present disclosure there is provided an apparatus for encoding bins used to encode binarised syntax elements representing video data, the apparatus comprising:

means for receiving the binarised syntax elements encoded in a plurality of bins;

means for generating a plurality of symbols, indicating the values of said bins, each of the symbols being associated with a probability range;

means for determining a first mapping to a plurality of encoders, each said encoder being configured for a particular probability, the first mapping being determined from the probability ranges associated with an expected value of each of the bins;

means for assigning a plurality of the symbols, representing a first subset of said bins, to one of said encoders according to said first mapping;

means for determining a count of the symbols associated with each of the probability ranges;

means for determining a second mapping, from said probability ranges to said plurality of encoders, based on said determined counts; and

means for encoding symbols, representing a second subset of said bins, by assigning further ones of said symbols to said plurality of encoders according to said second mapping.

According to still another aspect of the present disclosure there is provided a computer readable medium, having a program recorded thereon, where the program is configured to make a computer execute a procedure for encoding bins used to encode binarised syntax elements representing video data, the program comprising: code for receiving the binarised syntax elements encoded in a plurality of bins;

code for generating a plurality of symbols, indicating the values of said bins, each of the symbols being associated with a probability range;

code for determining a first mapping to a plurality of encoders, each said encoder being configured for a particular probability, the first mapping being determined from the probability ranges associated with an expected value of each of the bins;

code for assigning a plurality of the symbols, representing a first subset of said bins, to one of said encoders according to said first mapping;

code for determining a count of the symbols associated with each of the probability ranges;

code for determining a second mapping, from said probability ranges to said plurality of encoders, based on said determined counts; and

code for encoding symbols, representing a second subset of said bins, by assigning further ones of said symbols to said plurality of encoders according to said second mapping.

Other aspects of the invention are also disclosed.

BRIEF DESCRIPTION OF THE DRAWINGS

One or more embodiments of the present invention will now be described with reference to the following drawings, in which:

Fig. 1 is a schematic block diagram showing functional modules of a video encoder;-

Fig. 2 is a schematic block diagram showing functional modules of a video decoder;

Fig. 3 is a schematic diagram showing division of a probability interval into a set of contiguous probability ranges;

Fig. 4 is a schematic diagram showing an alternative division of the probability interval of Fig. 3 into a set of contiguous probability ranges;

Fig. 5 is a schematic block diagram showing a video entropy encoder used in the video encoder of Fig. 1 ;

Fig. 6 is a schematic block diagram showing a video entropy decoder used in the video decoder of Fig. 2;

Fig. 7 is a schematic flow diagram showing a method of encoding one bin into a symbol and updating context information for the bin; Fig. 8 is a schematic flow diagram showing a method of decoding one bin from a symbol and updating the context information for the bin;

Fig. 9 is a schematic flow diagram showing a method of encoding a stream of symbols at a particular fixed probability;

Fig. 10 is a schematic flow diagram showing a method of decoding a stream of bins encoded at a particular fixed probability;

Fig. 1 1 is a schematic flow diagram showing a method of encoding or decoding a series of symbols with ' 1 ' values occurring at a particular fixed probability, using a lookup table;

Fig. 12 is a schematic flow diagram showing a method of collecting statistics for symbols at each probability level during symbol encoding;

Fig. 13 is a schematic flow diagram showing a method of collecting statistics for symbols at each probability level during symbol decoding;

Fig. 14 is a schematic flow diagram showing a method of determining an initial mapping between a set of fixed probability encoders and available probability levels;

Fig. 15 is a schematic flow diagram showing a method of determining an updated R mapping;

Fig. 16 is a schematic flow diagram showing a method of determining pairs of groups of symbols at a Q mapping to be merged;

Figs. 17A and 17B form a schematic block diagram of a general purpose computer system upon which the encoder and decoder of Figs. 1 and 2, respectively, may be practiced;

Fig. 18 is a schematic flow diagram showing a method of encoding bins used to encode binarised syntax elements representing video data, as executed by the video entropy encoder of Fig. 5 ; and

Fig. 19 is a schematic flow diagram showing a method of generating bins used to encode binarised syntax elements representing video data, as executed by the entropy decoder of Fig. 6.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

Where reference is made in any one or more of the accompanying drawings to steps and/or features, which have the same reference numerals, those steps and/or features have for the purposes of this description the same function(s) or operation(s), unless the contrary intention appears. Described below is a video encoding and decoding system that can reallocate arithmetically coded symbols to reduce buffering requirements and eliminate the need to transmit a mapping explicitly in a video bitstream. The reallocation occurs by mapping bins used to represent each syntax element in the video bitstream between a probability level contained in a context model and an optimal arithmetic encoder or decoder. The benefit of the system described below is that a process for deriving the mapping is performed in the encoder and the decoder. In contrast, a scheme known as Dynamic Source Selection derives the mapping only at the encoder and then encodes the mapping in the bitstream for use by the decoder. The described encoding and decoding system also overcomes the need of the prior art for buffering of all the symbols in one slice of data before a mapping could be constructed. Such buffering introduces latency and increases memory requirements for such conventional encoders.

Fig. 1 is a schematic block diagram showing functional software modules of a video encoder 100. Fig. 2 is a schematic block diagram showing functional software modules of a video decoder 200. The video encoder 100 and video decoder 200 may be implemented using a general-purpose computer system 1700, as shown in Figs. 17A and 17B.

As seen in Fig. 17A, the computer system 1700 includes: a computer module 1701 ; input devices such as a keyboard 1702, a mouse pointer device 1703, a scanner 1726, a camera 1727, and a microphone 1780; and output devices including a printer 1715, a display device 1714 and loudspeakers 1717. An external Modulator-Demodulator (Modem) transceiver device 1716 may be used by the computer module 1701 for communicating to and from a communications network 1720 via a connection 1721. The communications network 1720 may be a wide-area network (WAN), such as the Internet, a cellular telecommunications network, or a private WAN. Where the connection 1721 is a telephone line, the modem 1716 may be a traditional "dial-up" modem. Alternatively, where the connection 1721 is a high capacity (e.g., cable) connection, the modem 1716 may be a broadband modem. A wireless modem may also be used for wireless connection to the communications network 1720.

The computer module 1701 typically includes at least one processor unit 1705, and a memory unit 1706. For example, the memory unit 1706 may have semiconductor random access memory (RAM) and semiconductor read only memory (ROM). The computer module 1701 also includes an number of input/output (I/O) interfaces including: an audio- video interface 1707 that couples to the video display 1714, loudspeakers 1717 and microphone 1780; an I/O interface 1713 that couples to the keyboard 1702, mouse 1703, scanner 1726, camera 1727 and optionally a joystick or other human interface device (not illustrated); and an interface 1708 for the external modem 1716 and printer 1715. In some implementations, the modem 1716 may be incorporated within the computer module 1701, for example within the interface 1708. The computer module 17Q1 also has a local network interface 171 1 , which permits coupling of the computer system 1700 via a connection 1723 to a local-area communications network 1722, known as a Local Area Network (LAN). As illustrated in Fig. 17A, the local communications network 1722 may also couple to the wide network 1720 via a connection 1724,. which would typically include a sorcalled "firewall" device or device of similar functionality. The local network interface 171 1 may comprise an Ethernet™ circuit card, a Bluetooth™ wireless arrangement or an IEEE 802.i l wireless arrangement; however, numerous other types of interfaces may be practiced for the interface 171 1.

The I/O interfaces 1708 and 1713 may afford either or both of serial and parallel connectivity, the former typically being implemented according to the Universal Serial Bus (USB) standards and having corresponding USB connectors (not illustrated). Storage devices 1709 are provided and typically include a hard disk drive (HDD) 1710. Other storage devices such as a floppy disk drive and a magnetic tape drive (not illustrated) may also be used. An optical disk drive 1712 is typically provided to act as a non- volatile source of data. Portable memory devices, such optical disks (e.g., CD-ROM, DVD, Blu-ray Disc™), USB- RAM, portable, external hard drives, and floppy disks, for example, may be used as ^' appropriate sources of data to the system 1700.

The components 1705 to 1713 of the computer module 1701 typically communicate via an interconnected bus 1704 and in a manner that results in a conventional mode of operation of the computer system 1700 known to those in the relevant art. For example, the processor 1705 is coupled to the system bus 1704 using a connection 1718. Likewise, the memory 1706 and optical disk drive 1712 are coupled to the system bus 1704 by connections 1719. Examples of computers on which the described arrangements can be practised include IBM-PC's and compatibles, Sun Sparcstations, Apple Mac™ or a like computer systems.

The encoder 100 and the decoder 200, as well as methods described below, may be implemented using the computer system 1700 wherein the encoder 100, the decoder 200 and the processes of Figs. 7 to 16, to be described, may be implemented as one or more software application programs 1733 executable within the computer system 1700. In particular, the encoder 100, the decoder 200 and the steps of the described methods are effected by instructions 1731 (see Fig. 17B) in the software 1733 that are carried out within the computer system 1700. The software instructions 1731 may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part and the corresponding code modules performs the described methods and a second part and the corresponding code modules manage a user interface between the first part and the user.

The software ma be stored in a computer readable medium, including the storage devices described below, for example. The software is loaded into the computer system 1700 from the computer readable medium, and then executed by the computer system 1700. A computer readable medium having such software or computer program recorded on the computer readable medium is a computer program product: The use of the computer program product in the computer system 1700 preferably effects an advantageous apparatus for implementing the encoder 100, the decoder 200 and the described methods.

The software 1733 is typically stored in the HDD 1710 or the memory 1706. The software is loaded into the computer system 1700 from a computer readable medium, and executed by the computer system 1700. Thus, for example, the software 1733 may be stored on an optically readable disk storage medium (e.g., CD-ROM) 1725 that is read by the optical disk drive 1712.

In some instances, the application programs 1733 may be supplied to the user encoded on one or more CD-ROMs 1725 and read via the corresponding drive 1712, or alternatively may be read by the user from the networks 1720 or 1722. Still further, the software can also be loaded into the computer system 1700 from other computer readable media. Computer readable storage media refers to any non-transitory tangible storage medium that provides recorded instructions and/or data to the computer system 1700 for execution and/or processing. Examples of such storage media include floppy disks, magnetic tape, CD-ROM, DVD, Blu-ray Disc, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto- optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module 1701. Examples of transitory or non-tangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and/or data to the computer module 1701 include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like. The second part of the application programs 1733 and the corresponding code modules mentioned above may be executed to implement one or more graphical user interfaces (GUIs) to be rendered or otherwise represented upon the display 1714. Through manipulation of typically the keyboard 1702 and the mouse 1703, a user of the computer system 1700 and the application may manipulate the interface in a functionally adaptable manner to provide controlling commands and/or input to the applications associated with the GUI(s). Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilizing speech prompts output via the loudspeakers 1717 and user voice commands input via the microphone 1780.

Fig. 17B is a detailed schematic block diagram of the processor 1705 and a

"memory" 1734. The memory 1734 represents a logical aggregation of all the memory modules (including the HDD 1709 and semiconductor memory 1706) that can be accessed by the computer module 1701 in Fig. 17A.

When the computer module 1701 is initially powered up, a power-on self-test (POST) program 1750 executes. The POST program 1750 is typically stored in a ROM 1749 of the semiconductor memory 1706 of Fig. 17A. A hardware device such as the ROM 1749 storing software is sometimes referred to as firmware. The POST program 1750 examines hardware within the computer module 1701 to ensure proper functioning and typically checks the processor 1705, the memory 1734 (1709, 1706), and a basic input-output systems software (BIOS) module 1751, also typically stored in the ROM 1749, for correct operation. Once the POST program 1750 has run successfully, the BIOS 1751 activates the hard disk drive 1710 of Fig. 17A. Activation of the hard disk drive 1710 causes a bootstrap loader program 1752 that is resident on the hard disk drive 1710 to execute via the processor 1705. This loads an operating system 1753 into the RAM memory 1706, upon which the operating system 1753 commences operation. The operating system 1753 is a system level application, executable by the processor 1705, to fulfil various high level functions, including processor management, memory management, device management, storage management, software application interface, and generic user interface.

The operating system 1753 manages the memory 1734 (1709, 1706) to ensure that each process or application running on the computer module 1701 has sufficient memory in which to execute without colliding with memory allocated to another process. Furthermore, the different types of memory available in the system 1700 of Fig. 17A must be used properly so that each process can run effectively. Accordingly, the aggregated memory 1734 is not intended to illustrate how particular segments of memory are allocated (unless otherwise stated), but rather to provide a general view of the memory accessible by the computer system 1700 and how such is used.

As shown in Fig. 17B, the processor 1705 includes a number of functional modules including a control unit 1739, an arithmetic logic unit (ALU) 1740, and a local or internal memory 1748, sometimes called a cache memory. The cache memory 1748 typically includes a number of storage registers 1744 - 1746 in a register section. One or more internal busses 1741 functionally interconnect these functional modules. The processor 1705 typically also has one or more interfaces 1742 for communicating with external devices via the system bus 1704, using a connection 1718. The memory 1734 is Coupled to the bus 1704 using a connection 1719.

The application program 1733 includes a sequence of instructions 1731 that may include conditional branch and loop instructions. The program 1733 may also include data 1732 which is used in execution of the program 1733. The instructions 1731 and the data 1732 are stored in memory locations 1728, 1729, 1730 and 1735, 1736, 1737, respectively. Depending upon the relative size of the instructions 1731 and the memory locations 1728-1730, a particular instruction may be stored in a single memory location as depicted by the instruction shown in the memory location 1730. Alternately, an instruction may be segmented into a number of parts each of which is stored in a separate memory location, as depicted by the instruction segments shown in the memory locations 1728 and 1729.

In general, the processor 1705 is given a set of instructions which are executed therein. The processor 1 105 waits for a subsequent input, to which the processor 1705 reacts to by executing another set of instructions. Each input may be provided from one or more of a number of sources, including data generated by one or more of the input devices 1702, 1703, data received from an external source across one of the networks 1720, 1702, data retrieved from one of the storage devices 1706, 1709 or data retrieved from a storage medium 1725 inserted into the corresponding reader 1712, all depicted in Fig. 17A. The execution of a set of the instructions may in some cases result in output of data. Execution may also involve storing data or variables to the memory 1734.

The encoder 100, the decoder 200 and the described methods use input variables 1754, which are stored in the memory 1734 in corresponding memory locations 1755, 1756, 1757. The encoder 100, the decoder 200 and the described methods produce output variables 1761, which are stored in the memory 1734 in corresponding memory locations 1762, 1763, 1764. Intermediate variables 1758 may be stored in memory locations 1759, 1760, 1766 and 1767.

Referring to the processor 1705 of Fig. 17B, the registers 1744, 1745, 1746, the arithmetic logic unit (ALU) 1740, and the control unit 1739 work together to perform sequences of micro-operations needed to perform "fetch, decode, and execute" cycles for every instruction in the instruction set making up the program 1733. Each fetch, decode, and execute cycle comprises:

(a) a fetch operation, which fetches or reads an instruction 1731 from a memory location 1728, 1729, 1730;

(b) a decode operation in which the control unit 1739 determines which instruction has been fetched; and

(c) an execute operation in which the control unit 1739 and/or the ALU 1740 execute the instruction.

Thereafter, a further fetch, decode, and execute cycle for the next instruction may be executed. Similarly, a store cycle may be performed by which the control unit 1739 stores or writes a value to a memory location 1732.

Each step or sub-process in the processes of Figs. 7 to 16 is associated with one or more segments of the program 1733 and is performed by the register section 1744, 1745, 1747, the ALU 1740, and the control unit 1739 in the processor 1705 working together to perform the fetch, decode, and execute cycles for every instruction in the instruction set for the noted segments of the program 1733.

The encoder 100, the decoder 200 and the described methods may alternatively be implemented in dedicated hardware such as one or more integrated circuits performing the functions or sub functions of the described methods. Such dedicated hardware may include graphic processors, digital signal processors, or one or more microprocessors and associated memories.

The video encoder 100 may be implemented as one or more software code modules of the software application program 1733 resident on the hard disk drive 1705 and being controlled in its execution by the processor 1705. In particular the video encoder 100 comprises modules 102 to 1 12 and 1 14 which may each be implemented as one or more software code modules of the software application program 1733.

Although the video encoder 100 is illustrative of a high efficiency video coding (HEVC) video decoding pipeline, processing stages performed by the modules 102 to 1 12 and 1 14 are common to other video codecs such as VC-1 or H.264/MPEG-4 AVC. The video encoder 100 receives unencoded frame data 101 as a series of frames consisting of luminance and chrominance samples. The video encoder 100 divides each frame of the frame data 101 into one or more slices which contain an integer number of coding units (CUs). Each coding unit (CU) is encoded sequentially by further dividing the coding unit (CU) into two- dimensional arrays of samples known as blocks. The video encoder 100 operates by outputting from a multiplexer module 1 10 a prediction for each array of samples. A difference module 1 15 outputs the difference between a prediction and a corresponding array of samples received from the frame data 101. The prediction from the multiplexer module 110 will be described in more detail below.

The output from the difference module 1 15 is received by a transform module 102, which converts the difference from a spatial representation to a frequency domain representation to create transform coefficients. For H.264/MPEG-4 AVC the conversion to the frequency domain representation is implemented using a modified discrete cosine transform (DCT), modified to be implemented using shifts and additions. The transform coefficients are then input to a scale and quantise module 103 where the coefficients are scaled and quantised to produce residual coefficients. The scale and quantisation results in a loss of precision. The residual coefficients are taken as input to an inverse scaling module 105 which reverses the scaling performed by the scale and quantise module 103 to produce rescaled versions of the transform coefficients. Due to the loss of precision resulting from the scale and quantise module 103, the rescaled transform coefficients are not identical to the original transform coefficients. The rescaled transform coefficients from the inverse scaling module 105 are then output to an inverse transform module 106. The inverse transform module ,106 performs an inverse transform from the frequency domain to the spatial domain to produce a spatial-domain representation of the rescaled transform coefficients identical to a spatial domain representation that is produced at a decoder.

A motion estimation module 107 produces motion vectors by comparing the frame data 101 with previous frame data stored in a frame buffer module 112 configured within the memory 1706. The motion vectors are then input to a motion compensation module 108 which produces inter-predicted reference samples by filtering samples stored in the frame buffer module 1 12, taking into account a spatial offset derived from the motion vectors. The motion vectors are also passed as syntax elements to an entropy encoder module 104 for coding in an output bitstream 1 13. An intra-frame prediction module 109 produces intra- predicted reference samples using samples obtained from a sum 1 14 of the output of the multiplexor module 1 10 and the output from the inverse transform module 106.

Coding units (CUs) may be coded using intra-prediction or inter-prediction methods. The decision as to whether to use intra-prediction or inter-prediction is made according to a rate-distortion trade-off between desired bit-rate of the resulting bitstream and the amount of image quality distortion introduced by either the intra-prediction or inter-prediction methods. A multiplexor module 1 10 selects either the intra-predicted reference samples from the intra- frame prediction module 109 or the inter-predicted reference samples from the motion compensation module 108, depending on the current prediction mode. A summation module 1 14 produces a sum that is input to a deblocking filter module 1 1 1. The deblocking filter module 1 1 1 performs filtering along block boundaries, producing deblocked samples that are written to the frame buffer block 112 configured within the memory 1706. The frame buffer block 1 12 is a buffer with sufficient capacity to hold data from multiple past frames for future reference.

As described above, the video encoder 100 also comprises an entropy encoder module

104 implementing an entropy encoding method. The entropy encoder module 104 produces syntax elements from incoming residual coefficient data received from the scale and quantise module 103 and motion vector data from the motion estimation module 107. The entropy encoder module 104 outputs bitstream data 1 13 and will be described in more detail below. In H.264/MPEG-4 AVC, the bitstream data 113 is delineated into network abstraction layer (NAL) units. Each slice is contained in one network abstraction layer (NAL) unit.

There are several alternatives for the entropy encoding method implemented in the entropy encoder module 104. The alternatives available depend on which video coding method the encoder 100 is performing. For example, the high efficiency video coding (HEVC) standard currently under development supports use of low complexity entropy coding (LCEC), a variant of context adaptive variable length coding (CAVLC) in 'low complexity' configurations and supports context adaptive binary arithmetic coding (CABAC) in 'high efficiency' configurations. H.264/MPEG-4 AVC may use context adaptive variable length coding (CAVLC) in all profiles or context adaptive binary arithmetic coding (CABAC) in main and higher profiles. For a given video coding method one of the supported entropy coding methods is selected according to the configuration of the encoder 100. Further, in encoding the coding units (CUs) from each frame, the entropy encoder module 104 writes bitstream data such that each frame has one or more slices per frame, with each slice containing image data for part of the frame. Producing one slice per frame reduces overhead associated with delineating each slice boundary. However, dividing the frame into multiple slices is also possible.

The video decoder 200 may be implemented as one or more software code modules of the software application program 1733 resident on the hard disk drive 1705 and being controlled in its execution by the processor 1705. In particular the video decoder 200 comprises modules 202 to 208 and 210 which may each be implemented as one or more software code modules of the software application program 1733. Although the video decoder 200 is illustrative of an H.264/MPEG-4 AVC video decoding pipeline, processing stages performed by the modules 202 to 208 and 209 are common to other video codecs that employ entropy coding, such as MPEG-2, VC-1 and high efficiency video coding (HEVC).

An encoded bitstream 201 is received by the video decoder 200. The encoded bitstream 201 may be read from memory 1706, the hard disk drive 1710, a CD-ROM, a Blu- ray disk or other computer readable storage medium. Alternatively the encoded bitstream 201 may be received from an external source such as a server connected to the communications network 1720 or a radio-frequency receiver. The encoded bitstream 201 comprises encoded syntax elements representing frame data to be decoded.

The encoded bitstream 201 is input to an entropy decoder module 202 which extracts the syntax elements from the encoded bitstream 201 and passes the values of the syntax elements to other blocks in the video decoder 200. There may be multiple entropy decoding methods implemented in the entropy decoder module 202, such as the H.264 MPEG-4 AVC standard supporting context adaptive binary arithmetic coding (CABAC) and context adaptive variable length coding (CAVLC) entropy decoding methods or high efficiency video coding (HEVC) which supports the low complexity entropy coding (LCEC) and context adaptive binary arithmetic coding (CABAC) entropy decoding methods. Syntax element data representing residual coefficient information is passed to an inverse scale and transform module 203 and syntax element data representing motion vector information is passed to a motion compensation module 204. The inverse scale and transform module 203 performs inverse scaling on the residual coefficient data, restoring the residual coefficients to their correct magnitude, and then performs an inverse transform to convert the data from a frequency domain representation to a spatial domain representation, producing residual samples. For H.264/MPEG-4 AVC the inverse transform is a modified inverse discrete cosine transform (IDCT), using only require shifts and adds for reduced complexity. A motion compensation module 204 uses the motion vector data combined with previous frame data from a frame buffer block 208, configured in the memory 1706, to produce inter-predicted reference samples. When a syntax element indicates that the current coding unit (CU) was coded using intra-prediction, an intra-frame prediction module 205 produces intra-predicted reference samples using the sum from a summation module 210. A multiplexor module 206 selects intra-predicted reference samples or inter-predicted reference samples depending on the current prediction mode, which is indicated by a syntax element in the bitstream data 201. The output from the multiplexor module 206 is added to the residual samples from the inverse scale and transform module 203 by the summation module 210 to produce a sum which is then input to a deblocking filter module 207. The deblocking filter module 207 performs filtering along data block boundaries to smooth artefacts visible along the data block boundaries. The output of the deblocking filter module 207 is written to the frame buffer module 208 configured within the memory 1706. The frame buffer module 208 provides sufficient storage to hold multiple decoded frames for future reference. Decoded frames 209 are also output from the frame buffer module 208.

When using an arithmetic coding scheme, such as context adaptive binary arithmetic coding (CABAC), each syntax element is represented as a sequence of bins. The sequence of bins is drawn from a set of bins, creating a binarised syntax element. The process of creating the binarised syntax element is known as "binarisation" and occurs at the encoder 100 with a reversed process used in the decoder 200 to recover the syntax element. The output of the binarisation process is dependent on the syntax element type and value. The set of bins is known as a "context model". The context model contains an array of structures, with each structure holding information relating to one bin. Each structure contains an expected bin value (i.e., valMPS) and a probability level. The probability level represents the probability of occurrence of a least probable symbol (LPS). A least probable symbol(LPS) is produced when the bin value required by the binarisation is different to the expected bin value contained in the structure. When the bin value required by the binarisation matches the bin value provided by the context model a most probable symbol (MPS) is produced. The probability of occurrence of a least probable symbol (LPS) lies on an interval of (0, 0.5].

The probability levels contained within the structures of the context model will now be described with reference to Fig. 3. Fig. 3 shows a first division of a probability interval 301 into a set of contiguous probability ranges. A method of naming and grouping the probability ranges and how the ranges are mapped onto fixed probability encoders or decoders via an R mapping 308 and a Q mapping 307, will also be described with reference to Fig. 3.

Fig. 3 shows a probability interval 301 from (0, 0.5] representing an interval of probabilities at which a least probable symbol (LPS) may occur. The probability interval 301 is divided into a set of smaller contiguous probability ranges 302. The division of the probability interval into probability ranges is similar to the division of the probability interval into sixty three (63) smaller probability ranges for context adaptive binary arithmetic coding (CABAC) in the H.264/MPEG-4 AVC standard. Each of the probability ranges 302 has a unique integer identifier and for each bin in the context model, the integer is stored in the context model structure to represent the probability of occurrence of a least probable symbol (LPS) for that bin.

Each of the probability ranges 302 may also be described by a probability level 303 representative of the probability range 302. For example, if the probability interval is divided into sixty three (63) probability ranges, the sixty three (63) fixed probabilities that each bin can take can be approximated by Equation (1), below:

p_k = 0.949217148771^k/2 (1) where k = 0, ..., 62 and p_k represent probability levels.

The Q mapping 307 is configured within the memory 1706 and has a fixed N: l relationship representing a quantisation of the probability ranges 302 into a smaller number of quantised probability ranges 304. Each of the quantised probability ranges 304 may be represented by a fixed probability (e.g., 305).

The R mapping 308 is stored within the memory 1706 and has a reconfigurable N:l relationship from the quantised probability ranges 304 to a subset of the fixed probabilities 306. The R mapping 308 stored in the memory 1706 is reconfigured over time so that an initial mapping 308 may not match a later R mapping 308. The fixed probabilities 306 represent the probabilities that fixed probability encoders 508 (see Fig. 5) and fixed probability decoders 608 (see Fig. 6) are configured to operate at. The fixed probability encoders 508 and 608 will be described in more detail in relation to Figs. 5 and 6 respectively.

Fig. 4 is a schematic diagram showing an alternative division of a probability interval 401 into a set of contiguous probability ranges. A method of naming and grouping the probability ranges and how an R mapping 405 relates to the probability ranges when the Q mapping 307 is not used, will also be described. The continuous probability interval 401, probability ranges 402 and representative fixed probabilities 403 are defined in the same way used for the probability interval 301 of Fig. 3. Fixed probabilities 404, representing probabilities supported by the fixed probability encoders 508 and the fixed probability decoders 608 are also defined as described above with reference to Fig. 3. In Fig. 4, the R mapping 405 is defined as a reconfigurable N: l relationship from the probability ranges 402 to a subset of the fixed probabilities 404 with no intermediate quantised probability ranges, as were shown in the quantised probability ranges 304. When the Q mapping 307 is not used the R mapping 405 is analogous to having a 1 : 1 Q mapping 307 between the probability ranges 402 and the fixed probabilities 404.

The entropy encoder 104 will now be described in more detail with reference to Fig. 5. The entropy encoder 104 may be implemented as one or more, software code modules of the software application program 1733 resident on the hard disk drive 1705 and being controlled in its execution by the processor 1705. In particular the entropy encoder 104 comprises modules 502 to 509 which may each be implemented as one or more software code modules of the software application program 1733.

As described in detail below, the entropy encoder 104 encodes video data by collecting statistics pertaining to bins at each probability level during encoding one group of bins and uses the statistics to create a new map from the bin probability levels to fixed probability encoders 508. In particular, the entropy encoder 104 encodes video data by collecting statistics for a first group of symbols at each of the fixed probabilities 305 and uses the collected statistics to remap a next group of symbols to the fixed probability encoders 508.

A method 1800 (see Fig. 18) of encoding bins used to encode binarised syntax elements representing video data, will now be described with reference to Fig. 17. The method 1800 is implemented by the entropy encoder 104 under execution of the processor 1705. In particular, the method 1800 may be implemented as one of more software code modules of the software application program 1733 resident on the hard disk drive 1710 and being controlled in its execution by the processor 1705.

The method 1800 begins at receiving step 1801, where the processor 1705 configures the entropy encoder 105 for receiving the binarised syntax elements encoded in a plurality of bins. In particular, syntax elements 501 are received by the entropy encoder 104 and input to a binariser module 502. The binariser module 502 binarises each syntax element into a sequence of bins with the bin values determined based on the syntax element value. The sequence of bins is passed to context memory and modeller module 503. Then at step 1802, the processor 1705 configures the entropy encoder 105 for generating a plurality of symbols, indicating the values of the bins. Each of the symbols is associated with a probability range. In particular, for each bin, a symbol is created at step 1802 by XORing the bin value and the most probable symbol (valMPS) value associated with the bin. Each symbol retains an association with the probability level of the bin indicating the probability of occurrence of the least probable symbol (LPS) from the context memory and modeller module 503.

At a first mapping determining step 1803, the processor 1705 configures the entropy encoder 105 for determining a first mapping to a plurality of encoders 508. Each of the encoders 508 is optimised for a probability. The first mapping is determined from the probability ranges associated with an expected value of each of the bins. In particular, the symbols generated at step 1802 are passed to Q probability mapper module 504, which uses the Q mapping 307 to direct each symbol based on the probability level associated with the symbol from the context memory and modeller module 503 to an R probability mapper module 507. As described in detail below, at assigning step 1805, the processor 1705 configures the R probability mapper module 507 of the entropy encoder 104 for assigning a plurality of the symbols, representing a first subset of the bins, to one of the encoders 508 according to the first mapping.

Then at count determining step 1806, the processor 1705 configures the entropy encoder 104 for determining a count of the symbols associated with each of the probability ranges. In particular, a set of counters in a statistics counters module 505 record counts of the number of symbols at each group of probability ranges in the Q mapping 307, including whether the instances were least probable symbol (LPS) or most probable symbol (MPS). The counts are named 'symbol counts'.

At a second mapping determining step 1807, the processor 1705 configures the entropy encoder 104 for determining a second mapping, from the probability ranges to the plurality of encoders 508, based on the count determined at step 1805. Then at symbol encoding step 1809, the processor 1705 configures the entropy encoder 104 for encoding symbols, representing a second subset of the bins, by assigning further ones of the symbols to the plurality of encoders 508 according to the second mapping. In particular, the counters in the statistics counters module 505 are reset to zero at the start of each slice or frame of the frame data 101. Also, the counters in the statistics counters module 505 are reset when a total count of all symbols (since the last reset of the encoder 104) reaches a trigger point (or threshold number of symbols). In one implementation, the statistics counters module 505 includes filtering of each statistic counter prior to output for filtering the determined counts of the selected symbols. Such filtering provides smoothing of the symbol counts over many trigger points. The smoothing is performed to reject spurious variations in the symbol counts which may be considered as high frequency noise. A spurious variation may be an occurrence when a statistics counter value is significantly different from a historical value based on a previous statistics counter values, such as an average. For example, a low-pass IIR ("infinite impulse response") filter may be used to filter each statistics counter.

The trigger point (or threshold) may be a constant value (or threshold). The trigger point (or threshold) may be a value dependant on video data stream (e.g., the frame data 101) parameters such as frame dimensions (i.e., frame size) and selected quantisation parameter, or a value dependent on the quantities of symbols occurring at each probability level. In one implementation, the trigger point is dependent on the symbol counts. The trigger point is reached when the difference between probability levels determined from the symbol counts and corresponding fixed probabilities 306 of the fixed probability encoders 508 or fixed probability decoders 608 exceeds a threshold.

At the trigger point, the statistics counts output from the statistics counters module 505 are read by a mapping control module 506 which determines an updated R mapping 308. Operation of the mapping control module 506 is in accordance with a method 1400 (see Fig. 14) of determining an initial (or first) R mapping 308 and a method 1500 (see Fig. 15) of determining an updated (or second) R mapping 308 as performed when depicted by a method 1200 (see Fig. 12) of collecting statistics for symbols at each probability level during symbol encoding (i.e., entropy encoding). The updated R mapping 308 is applied by R probability mapper block 507 to map each of the allocated symbols to a subset of available fixed probability encoders 508.

Each of the fixed probability encoders 508 is optimised to encode incoming symbol data where least probable symbol (LPS) instances are, on average, at a particular probability level, known as the fixed probability 306. In applying the updated R mapping 308, the selection of fixed probability encoders 508 required is output to an interleaver module 509. The interleaver module 509 may place output from each of the fixed probability encoders 508, selected according to mapping control module 506, for example into separate network abstraction layer (NAL) units in a single video bitstream. Alternatively interleaving may take place at a finer granularity, such as at a bit level, resulting in a single network abstraction layer (NAL) unit being produced. Output from interleaver module 509 is an encoded bitstream 510.

The entropy encoder 104 and each of the modules of the entropy encoder 104 will be described in further detail below.

Fig. 6 is a schematic block diagram showing the entropy decoder 202 of Fig. 2 in more detail. The entropy decoder 202 may be implemented as one or more software code modules of the software application program 1733 resident on the hard disk drive 1705 and being controlled in its execution by the processor 1705. In particular the entropy decoder 202 comprises modules 602 to 609 which may each be implemented as one or more software code modules of the software application program 1733.

As described in detail below, the entropy decoder 202, under execution of the processor 1705, decodes an encoded video bitstream 610 by collecting statistics pertaining to bins at each probability level during decoding one group of bins and uses the statistics to create a new map from the bin probability levels to fixed probability decoders 608.

A method 1900 of generating bins used to encode binarised syntax elements representing video data, will now be described with reference to Fig. 19. The method 1900 is implemented by the entropy decoder 202 under execution of the processor 1705. In particular, the method 1900 may be implemented as one of more software code modules of the software application program 1733 resident on the hard disk drive 1710 and being controlled in its execution by the processor 1705.

The method 1900 begins at receiving step 1901, where the processor 1705 configures the entropy decoder 202 for receiving a plurality of bitstreams encoding symbols indicating values of the bins. In particular, the entropy decoder 202 decodes an encoded bitstream, such as the encoded bitstream 510 produced by the entropy encoder 104. The encoded bitstream 510 comprises either a separate network abstraction layer (NAL) unit for each bitstream containing symbols encoded using a particular one of the fixed probability encoders 508, or a single network abstraction layer (NAL) unit containing interleaved streams of symbols encoded using each of the fixed probability encoders 508.

The encoded bitstream 510 is received by the entropy decoder 202. The encoded bitstream 510 is input into a de-interleaver module 609. The de-interleaver module 609 is configured at the start of each slice of the encoded bitstream 510 to de-interleave the incoming encoded bitstream 510 and output de-interleaved data as a series of separate bitstreams. At decoding step 1903, the processor 1705 configures the entropy decoder 202 for decoding each of the plurality of bitstreams received at step 1901 into the symbols using one of a plurality of decoders 608. Each of the decoders 608 is optimized for a particular probability value. In particular, each of the separate bitstreams contains symbols that have been entropy coded using a specific one of the fixed probability encoders 508.

Then at first mapping step 1905, the processor 1705 configures the entropy decoder 202 for determining a first mapping from probability ranges associated with an expected probability value of each of the bins to the plurality of decoders. The de-interleaving module 609 is initially configured to use a predetermined subset of fixed probability decoders 608, according to an initial (or first) R mapping 308 applied by an R probability mapper module 605 and provided by a mapping control module 607. The mapping control module 607 operates in accordance with the method 1400, for creating an initial R mapping 308 and the method 1500 for updating the R mapping 308 performed as depicted by a method 1300 of collecting statistics for symbols at each probability level during symbol decoding (i.e., entropy decoding). Each of the fixed probability decoders 608 decodes a bitstream of arithmetically encoded symbols, the symbols having been encoded at a particular one of the fixed probabilities 306.

Initialisation of de-interleaver module 609 occurs prior to decoding the encoded bitstream 610, so that the encoded bitstream 610 will be correctly de-interleaved to each of the fixed probability decoders 608. Reconfiguration of the de-interleaver block 609 to match the output from the mapping control module 607 occurs whenever a new R mapping 308 is generated. A method 1 100 of encoding or decoding a series of symbols as executed by the fixed probability encoders 508 and the fixed probability decoders 608, respectively, will be described below with reference to Fig. 1 1.

At selecting step 1907, the processor 1705 configures the entropy decoder 202 for selecting a plurality of the decoded symbols to generate a first subset of the bins. Each of the selected symbols are selected from one of the decoders 608 according to the initial (or first) R mapping 308. In particular, symbol values are output from each of the fixed probability decoders 608 and are passed to the R probability mapper module 605. The R probability mapper module 605 selects a symbol from one of the fixed probability decoders 608 and maps the symbol to one of the groups of probability ranges received as input to a Q probability mapper module 604, by applying a mapping provided by the mapping control module 607. Then at count determining step 1909, the processor 1705 configures the entropy decoder 202 for determining a count of the selected symbols associated with each of the probability ranges. In particular, a statistics counters module 606 receives a symbol output from each of the decoders 608 and increments a counter corresponding to the probability level of the symbol and the value of the symbol (i.e., least probable symbol or most probable symbol). In one implementation, statistics counters module 606 includes filtering of each statistic counter prior to output for filtering the determined counts of the selected symbols. For example, a low-pass IIR filter ("infinite impulse response") filter may be used to filter each statistics counter. During initialisation of the entropy decoder 202 the mapping control module 607 provides a default mapping for use by the R probability mapper module 605. Such filtering provides smoothing of the symbol counts over many trigger points and may be similar to the filtering described for the Statistics Counter module 505 of the entropy encoder 104.

At second mapping determining step 191 1, the processor 1705 configures the entropy decoder 202 for determining a new (or second) R mapping 308 from the probability ranges to the plurality of decoders 608, based on the count determined at step 1909. In particular, at a trigger point the mapping control module 607 produces a new (or second) R mapping 308 for use by the R probability mapper module 605 using the count values obtained from the statistics counters module 606. In order for the R mappings 308 to be synchronised between the video encoder 100 and the video decoder 200 a trigger point used in video decoder 200 is the same as the trigger point, as described above, used in video encoder 100. The statistics counters module 606 and the mapping control module 607 will be described in more detail below with reference to the method 1400 of Fig. 14.

Then at generating step 1913, the processor 1705 configures the entropy decoder 202 for generating a second subset of the bins by selecting further ones of the symbols from the plurality of decoders 608 according to new (or second) R mapping 308. In particular, the mapping control module 607 configures de-interleaver module 609 to direct de-interleaved encoded symbols to the fixed probability decoders 608 specified for use by the R mapping 308. Where the symbols coded at each of the fixed probabilities 306 are contained in a single network abstraction layer (NAL) unit, de-interleaving is achieved using a round-robin method to allocate symbols from the encoded bitstream 610 to each of the fixed probability decoders 608 in use. Where the symbols coded at each of the fixed probabilities 306 are contained in separate network abstraction layer (NAL) units, the de-interleaver 609 assigns each network abstraction layer (NAL) unit pay load to one of the corresponding fixed probability decoders 608.

A total number of symbols and a number of least probable symbol (LPS) instances of a symbol are recorded by a set of counters in the statistics counters module 606 count for each group of probability ranges in the Q mapping 307. The Q probability mapper module 604 receives symbols from the R probability mapper module 605 and passes the symbols to a context memory and modeller module 603. The Q probability mapper module 604 maps probability ranges, such as the probability ranges 302 of Fig. 3, requested by the context memory and modeller module 603 to quantised probability ranges 304. The context memory and modeller module 603 determines each bin value by XORing the most probable symbol (valMPS) value for a selected bin with the symbol value received from Q probability mapper module 604. Each bin value produced is also used to update the most probable symbol (valMPS) value and the context information for the bin. Bin values are provided to the binariser module 602 from the context memory and modeller module 603 to allow evaluation of a syntax element value. As each bin value is received, the binariser module 602 determines whether the bin is the last in the syntax element or if an additional bin is required to determine a value of the syntax element. If the bin is the last then the binariser module 602 outputs another one of the syntax elements 601, otherwise further bins are requested until a syntax element may be decoded.

In one alternative implementation, the fixed probability encoders 508 and the fixed probability decoders 608 are replaced with a set of reconfigurable fixed probability encoders and decoders respectively. In this instance, when a new R mapping 308 is produced by mapping control module 506 607, the fixed probability encoders 508 and the fixed probability decoders 608 are reconfigured such that the encoders 508 and decoders 608 operate at the new fixed probabilities as indicated by the R mapping 308.

The entropy decoder 202 and each of the modules of the entropy decoder 202 will be described in further detail below.

Fig. 7 is a flow diagram showing a method 700 of encoding a single bin into a symbol, performed in the context- memory and modeller module 503 under execution of the processor 1705. The method 700 may be implemented as one or more software code modules of the software application program 1733 resident on the hard disk drive 1710 and being controlled in its execution by the processor 1705. The method 700 begins at exclusive OR step 7Q1, where the processor 1705 performs an exclusive OR (XOR) step 701 to determine a symbol value by XORing a bin value provided by the binariser module 502 with the most probable symbol ('valMPS') value obtained from the context model of the single bin being processed. The context model for the bin is obtained by the processor 1705 from the context memory and modeller module 503. ^' The determined symbol value may be stored in the memory 1706.

At write symbol step 702, the processor 1705 outputs the symbol value determined in step 701 to the Q probability mapper module 504. The symbol may be stored as a symbol value in memory 1706. Next, at comparison step 703, the processor 1705 compares the symbol value stored at step 702 with a logic ' 1 ' and if true, control of the method 700 passes to an update least probable symbol (LPS) step 704. Otherwise control of the method 700 passes to an update most probable symbol (MPS) step 705.

At the update least probable symbol (LPS) step 704, the processor 1705 updates context information for the current bin given that the most probable symbol ('valMPS') value differed from the bin value requested by the binariser module 502. The updated context information may be stored in the memory 1706.

At the update most probable symbol (MPS) step 705, the processor 1705 updates context information for the current bin given that the most probable symbol ('valMPS') value matched the bin value requested by the binariser module 502. The method 700 concludes following step 704 or step 705.

Fig. 8 is a schematic flow diagram showing a method 800 of decoding a bin value, performed in the context memory and modeller module 603 under execution of the processor 1705. The method 800 may be implemented as one or more software code modules of the software application program 1733 resident on the hard disk drive 1710 and being controlled in its execution by the processor 1705.

The method 800 begins at a read symbol step 801, where the processor 1705 obtains one symbol from the Q probability mapper module 604. Then at an exclusive OR (XOR) step 802, the processor 1705 determines the bin value ('binVal') by XORing the symbol read with the most probable symbol ('valMPS') value for the current bin. Then at a decision step 803, the processor 1705 tests the symbol value read at step 802 and if equal to logic ' , then the method 800 proceeds to an update least probable symbol (LPS) step 804. Otherwise, the method 800 proceeds to an update most probable symbol (MPS) step 805. At the update least probable symbol (LPS) step 804, the processor 1705 updates the probability for the current bin in the least probable symbol (LPS) case using a look-up table configured within the memory 1706. The updated probability values may be stored in the memory 1706.

At the update most probable symbol (MPS) step 805, the processor 1705 updates the current bin probability for the most probable symbol (MPS) case also using a look-up table configured within the memory 1706. The updated most probable value ('valMPS') and probability values determined at steps 804 and 805 are stored in the context memory and modeller module 603. .

The method 800 concludes following either of steps 804 and 805.

Fig. 9 is a schematic flow diagram showing a method 900 of arithmetically encoding a stream of symbols at a particular one of the fixed probabilities 306. The method 900 may be performed by each of the supported fixed probability encoders 508 in encoder 500 under the execution of the processor 1705. In particular, the method 900 may be implemented as one or more code modules of the software application program 1733 resident on the hard disk drive 1710 and being controlled in its execution by the processor 1705.

The method 900 may be performed as an alternative to using look-up table based method 1 100 (see Fig. 1 1) of approximating arithmetic encoding, which is described below with reference to Fig. 1 1. The method 900 is based on the context adaptive binary arithmetic coding- (CABAC) bin encoding method specified in the H.264/MPEG-4 AVC standard and makes use of recursive interval subdivision. An interval represents a range of values available for use to arithmetically encode a symbol. When a symbol is encoded, the interval is subdivided depending on the symbol value. The subdivision results in a reduction in the range of the interval and the range is restored by a process known as renormalisation.

The method 900 uses a 'range' variable configured within the memory 1706 for storing the range of the interval used by the encoder 508 ("an arithmetic encoder") for recursive interval subdivision and has a legal range of [2⁸, 2⁹). The method 900 also uses a 'low' variable configured within the memory 1706 for storing the lower bound of the interval. A 'bitsToRead' variable is also configured within the memory 1706 for storing the number of symbols to encode in a current slice. If the number of symbols to encode is unknown, the 'bitsToRead' variable may instead store a flag indicating the presence for further symbols to encode. A 'bitsToFollow' variable is also configured within the memory 1706 for storing the number of bits to be written to the bitstream as part of a renormalisation process. The method 900 begins at an initialise step 901 , where the processor 1705 sets the 'range' variable configured within the memory 1706 to a maximum permitted subinterval width of five hundred and ten (510) and the 'low' variable to zero (0). Also at step 901, the 'bitsToRead' variable is assigned a number of symbols to encode and the 'bitsToFollow' variable is set to zero (0). The maximum permitted subinterval width is derived from the upper boundary of the interval (i.e., five hundred and eleven (51 1)).

Then at a decision step 902, the processor 1705 tests the 'bitsToRead' variable to determine if the value of the 'bitsToRead' variable is greater than zero, then the method 900 concludes, terminating the encoding process for a current one of the fixed probabilities 306, as there are no bits to read. Otherwise, if the processor 1705 determines that the value of the 'bitsToRead' variable is not zero, then the method 900 proceeds to step 903.

At set least probable symbol range (LPSR) step 903, a 'least probable symbol range (LPSR)' variable configured within memory 1706 is assigned a value by performing a table look-up using the upper two (2) bits of a 'range' variable as input to a least probable symbol range look-up table configured within the memory 1706. At update step 904, the processor 1705 updates the 'range' variable by reducing the 'range' variable by the value of the 'least probable symbol range (LPSR)' variable. In read step 905, the processor 1705 reads one symbol from the R probability mapper module 507, which may be decoupled via a first-in- first-out (FIFO) buffer to enable the R probability mapper module 507 and the encoder 508 to operate independently.

In decision step 906 the bit read in the read step 905 is tested by the processor 1705. If the bit is ' 1 ' then control of the method 900 passes to an update low step 907. Otherwise, the method 900 proceeds to a range decision step 909. In update low step 907, the value of the 'range' variable configured in the memory 1706 is added to the value of the 'low' variable. Then in an update range step 908, the value of the 'least probable symbol range (LPSR)' variable is assigned to 'range' variable.

At range decision step 909, the processor 1705 tests the 'range' variable and if the 'range' variable has a value greater than or equal to two hundred and fifty six (256) control of the method 900 passes to decision step 902. Otherwise, control of the method 900 passes to a low decision step 910. At low decision step 910, the processor 1705 tests the 'low' variable configured within the memory 1706 and if the value of the 'low' variable is greater or equal to five hundred and twelve (512), control of the method 900 passes to a write step 91 1. Otherwise, the method 900 proceeds to a second low decision step 913.' At write step 91 1 , the processor 1705 firstly writes a Ί ' to the memory 1706 as output. Also at write step 91 1, the processor 1705 outputs a string of '0' bits, with length equal to 'bitsToFollow', to the memory 1706. Finally, at the write step 911, the processor 1705 sets the 'bitsToFollow' variable configured within the memory 1706 to zero (0). At update low step 912, the processor 1705 subtracts five hundred and twelve (512) from the value of the 'low' variable configured within the memory 1706. Then at second low decision step 913, the processor 1705 compares the value of the 'low^? variable with two hundred and fifty six (256). If the value of the 'low' variable is less than two hundred and fifty six (256) control of the method 900 passes to a write step 914. Otherwise, the method 900 proceeds to an increment step 915.

In the write step 914, firstly a '0' is written as output to the memory 1706. Secondly, at the write step 914, the processor 1705 outputs a string of ' Γ bits to the memory 1706, with length equal to the value of the 'bitsToFollow' variable configured within memory 1706. Finally, at the write step 914, the processor 1705 sets the 'bitsToFollow' variable to zero (0). At increment step 915, the processor 1705 increments the 'bitsToFollow' variable. Then at an update low step 916, the processor 1705 subtracts two-hundred and fifty six (256) from the value of the 'low' variable. Then at an update low and range step 917, the 'low' and 'range' variables are both left shifted by one bit by the processor 1705. In accordance with the method 900, the processor 1705 continues to process symbols from the R probability mapper module 507 until the value of the , bitsToRead variable is equal to zero.

Fig. 10 is a schematic flow diagram showing a method 1000 of arithmetically decoding a stream of symbols encoded at a particular one of the fixed probabilities 306. The method 1000 is performed by each of the supported fixed probability decoders 608, under execution of the processor 1705, and is based on the context adaptive variable length coding (CABAC) bin decoding scheme specified in the H.264/MPEG-4/AVC standard. In particular, the method 1000 may be implemented as one or , more code modules of the software application program 1733 resident on the hard disk drive 1710 and being controlled in its execution by the processor 1705.

The method 1000 starts at an initialise step 1001, where a 'bitsToRead' variable configured within the memory 1706 is initialised by the processor 1705 to the number of bits representing symbols encoded at a particular fixed probability level to decode. In implementations where the number of bits is unknown, for example, because the length of the network abstraction layer (NAL) unit is unknown during initialisation of the decoder 608, the 'bitsToRead' variable may be represented by a flag indicative of the presence of more data available to decode.

In range initialisation step 1002, a 'range' variable is initialised to five hundred and ten (510), representing the full range of interval subdivision. In value initialisation step 1003 a 'value' variable configured within the memory 1706 is initialised to zero (0). In a bitsToRead decision step 1004, the 'bitsToRead' variable is tested by the processor 1705 to determine if there are any bits left to be read for the fixed probability decoder 608 from the network abstraction layer (NAL) unit by the decoder 608. If the processor 1705 determines that the value of the 'bitsToRead' variable is greater than zero (0) then the method 1000 proceeds to step 1005. Otherwise, the method 1000 concludes.

In a set least probable symbol range (LPSR) step 1005, a 'least probable symbol range (LPSR)' variable configured within memory 1706 is initialised by performing a table lookup using the two (2) most significant bits of the 'range' variable as input to the least probable symbol range look-up table configured within the memory 1706. In performing the initialisation at step 1005, the processor 1705 subdivides the current interval and is dependent on the probability for each of the fixed probability decoders 608. In a range update step 1006, the 'range' variable is updated by subtracting the value of the 'least probable symbol range (LPSR)' variable from the value of the range variable.

At value decision step 1007, the processor 1705 compares the values of the 'value' and the 'range' variables. If the value of the 'value' variable is less than the value of the 'range' variable, a '0' bit is output from the fixed probability decoder 608 to memory 1706 in output '0' step 1009. Otherwise, a T bit is inserted into an output buffer of the fixed probability decoder 608 in output ' 1 ' step 1008.

At an update value step 1010, the processor 1705 updates the 'value' variable by subtracting the value of the 'range' variable from the value of the 'value' variable. Next, at an update range step 101 1, the processor 1705 assigns the value of the 'least probable symbol range (LPSR)' variable to the value of the 'range' variable.

At range decision step 1012, the processor 1705 tests if the value of the 'range' variable is less than two hundred and fifty six (256). If the result of the test is false, control of the method 1000 returns to the bitsToRead decision step 1004. Otherwise, the method 1000 proceeds to an update range step 1013. At the update range step 1013, the processor 1705 left-shifts the 'range' variable by one bit. Then in read step 1014, one bit is read from the de- interleaver module 609. In an update bitsToRead step 1015, the 'bitsToRead' variable is decremented by one (1) and control of the method 1000 returns to the range decision step 1012.

In accordance with the method 1000, the processor 1705 continues to process bits from the deinterleaver module 609 until the 'bitsToRead' variable value is equal to zero, at which point the method 1000 concludes.

The method 900 and the method 1000 show how the fixed probability encoders 508 and the fixed probability decoders 608 may be implemented using arithmetic coding. Arithmetic coding requires each symbol to be encoded or decoded sequentially, which can limit the achievable throughput for a hardware implementation. An alternative method 1 100 for implementing the encoder 508 or decoder 608 at a particular one of the fixed probabilities 306 will now be described with reference to Fig. 1 1.

The method 1 100 of encoding or decoding a series of symbols using a look-up table, where the look-up table contents are optimised for a particular one of the fixed probabilities 306, as executed by the fixed probability encoders 508 and decoders 608, will now be described with reference to Fig. 1 1. The method 1 100 may be implemented as one or more code modules of the software application program 1733 resident on the hard disk drive 1710 and being controlled in its execution by the processor 1705. The look-up table used in the method 1 100 consists of two sets of entries, the entries in each set having variable lengths. In particular, a 'variable number of bins' (VNB) set represents sequences of symbols and a 'variable length codewords' (VLC) set represents arithmetically encoded symbols. An association exists between each entry in the variable number of bins (VNB) set and a corresponding entry in the variable length codewords (VLC) set. Entries in each of the variable number of bins (VNB) and the variable length codewords (VLC) sets are configured such that unique decodability is provided.

When executed by one of the fixed probability encoders 508, a buffer input bit step

1 101 is performed by the processor 1705 to receive symbols from the R probability mapper module 507 and buffers the symbols in a shift register configured within the memory 1706. For each received symbol, at match table entry step 1102, the processor 1705 compares the shift register contents with entries in the variable number of bins (VNB) set to determine if there is a matching entry in the variable number of bins (VNB) set . If no match is determined by the processor 1705 at step 1 102, then control of the method 1100 passes back to the buffer input bit step 1 101. If the processor 1705 determines a match at step 1 102, then the method 1 100 proceeds to a translate codeword step 1 103. At step 1 103, the processor 1705 retrieves a codeword corresponding to the matched entry from the variable length codewords (VLC) set that is associated with the matched entry from the variable number of bins (VNB) set. Then at codeword output step 1 104, the processor 1705 outputs the retrieved codeword bit-serially to the interleaver module 509.

When executed by one of the fixed probability decoders 608, at the buffer input bit step 1 101 , the processor 1705 receives bits from the deinterleaver module 609 and buffers the bits in a shift register configured within the memory 1706. For each received bit, at the match table entry step 1 102, the processor 1705 compares the shift register contents with entries in the variable length codeword (VLC) set to determine if there is a matching entry in the variable length codeword (VLC) set. If no match is determined by the processor 1705 at step 1 102, the control of the method 1 100 passes back to the buffer input bit step 1101. If the processor 1705 determines a match at step 1 102, then the method 1100 proceeds to translate codeword step 1103. At step 1 103, the processor 1705 retrieves the entry from the variable number of bins (VNB) set that is associated with the matched entry in the variable length codeword (VLC) set. Then at codeword output step 1104, the processor 1705 outputs the retrieved codeword bit-serially to the R probability mapper module 605.

Each look-up table may be implemented as a binary tree since the variable length codewords produced by method 1 100 are uniquely decodable, with each node of the binary tree being stored in an array configured within memory 1706. The leaf nodes of the tree contain information to generate the output codewords at step 1104.

Alternatively, a gate logic implementation may be used for hardware implementations. Such a gate logic implementation avoids the need for a memory element and hence reduces circuit size.

The method 1200 of collecting counts for symbols at each of the probability levels 303 during the encoding of one slice of data, will now be described with reference to Fig. 12. The method 1200 is performed in the entropy encoder 104 by the statistics counters module 505 under execution of the processor 1705. In particular, the method 1200 may be implemented as one or more code modules of the software application program 1733 resident on the hard disk drive 1710 and being controlled in its execution by the processor 1705. The statistics counters module 505 maintains, for each of the probability levels 303, a count indicating the total number of symbols occurring (total count) and the number of least probable symbol (LPS) symbols occurring (i.e., least probable symbol (LPS) count). The method 1200 commences at initialise mapping step 1201 where an initial (or first) R mapping 308 is determined by the processor 1705. When the entropy encoder 500 is first run the initial R mapping 308 is a predetermined default mapping. At reset statistics counters step 1202, the processor 1705 resets all counters for the total count and the least probable symbol (LPS) count to zero.

Then at reset total count step 1203, the processor 1705 resets the total count value to zero. At an update symbol counter step 1204, the processor 1705 increments the symbol counter corresponding to a current symbol probability by one (1) and a least probable symbol (LPS) count is also incremented if the symbol value indicates an occurrence of a least probable symbol (LPS). In an increment total symbol count step 1205, the total symbol count is incremented. In an end of slice decision step 1206, an end-of-slice condition is tested. If the encoder 104 has reached the last coding unit (CU) for the current slice of data, then encoding for the current slice of data ceases and the method 1200 concludes as the current context information is no longer required. If the processor 1705 determines that the encoder 104 has not reached the end-of-slice, then the method 1200 proceeds to a remap trigger point decision step 1207. In one implementation of the remap trigger point decision step 1207 the total symbol count value stored in the memory 1706 is compared with a threshold by the processor 1705.

In one implementation, the threshold is a predetermined constant value for all encoding. In an alternative implementation, the threshold is determined at the start of each slice of data according to stream characteristics such as the frame dimensions and quantisation parameter, so that the trigger points occur with sufficient frequency. In still another implementation, the threshold is continuously updated during slice encoding based on current values of the statistics counters module 505. An actual probability level is measured by determining the ratio of the, least probable symbol (LPS) to least probable symbol (LPS) plus most probable symbol (MPS) counts to determine the actual probability level for symbols to the fixed probability encoders 508 or from the fixed probability decoders 608. In this case, a threshold for the actual probability levels deviating away from the particular fixed probability 303 is compared and if the threshold is exceeded, then the method 1200 proceeds to create updated mapping step 1208. Otherwise, the method 1200 returns to step 1204.

At step 1208, a new updated R mapping 308 is created within the memory 1706 to reflect the changes in symbol statistical behaviour. At step 1208, the processor 1705 creates the new R mapping 308 based on the statistics counter module 505 values. A method 1500 of determining an R mapping, as executed at step 1208, will be described in detail below with reference to Fig. 15.

A method 1300 of gathering statistics relating to the symbols and performing the R mapping 308 update during the decoding of one slice of data, will now be described with reference to Fig. 13. The method 1300 is performed by the statistics counters module 606 of decoder 102, under execution of the processor 1705. In particular, the method 1300 may be implemented as one or more software code modules of the software application program 1733. The operation of method 1300 should match the operation of method 1200 described in relation to fig. 12 to enable the encoder and decoder to produce the same mappings when processing the same symbols.

The method 1300 begins at initialise mapping step 1301, where an initial (or first) R mapping 308 is determined by the processor 1705. A predetermined default mapping configured within the memory 1706 may be used for a first mapping. Alternatively, where a frame of data is divided into multiple slices, step 1301 may be omitted after decoding the first slice of the frame as the R mapping 308 from the previous slice of data is used. A method 1400 of determining an initial mapping as executed at step 1301 will be described below with reference to Fig. 14.

Then in a reset all counters step 1302, all counters in the statistics counters module 609 are reset. In reset total count step 1303, a symbol count value of a symbol counter configured within memory 1706 is reset. Then in an update step 1304, the symbol counter corresponding to the value and probability level 303 of the current symbol is incremented.

In increment step 1305, the symbol count is incremented by one to indicate that the symbol has been mapped. In end of slice decision step 1306 a check of the end-of-slice condition is made by the processor 1705. If the end-of-slice condition is true, then the method 1300 concludes, as there are no further symbols to decode. If the end-of-slice condition is false, control of the method 1300 proceeds to remap trigger point decision step 1307. The trigger point decision used in the remap decision step 1307 matches the trigger point decision used in the remap decision step 1207 of Fig. 12. Having the two trigger point decisions the same in the encoder and decoder allows operation of the decoder to match the operation of the encoder.

In one implementation the total count value is compared with a threshold value stored in the memory 1706. If the symbol count is below the threshold, then the method 1300 returns to step 1304. If the symbol count has reached the threshold, then the method 1300 continues to R mapping creation step 1308. In the mapping creation step 1308, the R mapping 308 stored in the memory 1706 is updated by the processor 1705. The R mapping is updated in accordance with the method 1500, as will be described in more detail below in relation to Fig. 15.

Fig. 14 is a schematic flow diagram showing a method 1400 of initialising the R mapping 308 between the set of fixed probability encoders 508 or the set of fixed probability decoders 608, and the probability ranges. As described above, the method 1400 is executed in the initialise R mapping steps 1201 and 1301. The method 1400 may be implemented as one or more software code modules of the software application program 1733 resident in the hard disk drive 1710 and being controlled in its execution by the processor 1705.

In coder selection step 1401, a subset of the fixed probability encoders 508 or of the fixed probability decoders 608 are selected by the processor 1705 for use in the initial R mapping 308. Then at a reset level step 1402, the processor 1705 resets a probability level, counter within memory 1706, representing a probability level 303, to Ό'. At a quantise level step 1403, the processor 1705 quantises the current probability level counter according to the Q mapping 307 to produce a quantised probability 305.

At a select representative coder step 1404, the processor 1705 selects one of the fixed probability encoders 508 or one of the fixed probability decoders 608 such that the selected fixed probability 306 is most representative of the quantised probability 305. The result of the selection is assigned to the R mapping 308 configured within the memory 1706. At an increment level step 1405, the processor 1705 increments the value of the probability level counter configured within memory 1706 by one. Then at a level decision step 1406, the probability level counter value is tested by the processor 1705 to determine if all supported probabilities have been processed. If the processor 1705 determines at step 1406 that there are still supported probabilities to process, then the method 1400 returns to the quantise level step 1403. Otherwise the method 1400 concludes.

Fig. 15 is a schematic flow diagram showing a method 1500 for determining an R mapping 308 based on statistics derived from the symbol counts for each group of symbols at the Q mapping 307 stored within the memory 1706. The method 1500 may be implemented as one or more software code modules of the software application program 1733 resident within the hard disk drive 1710 and being controlled in its execution by the processor 1705.

The method 1500 is executed at- step 1208 for the video encoder 100 and at step 1309 for the video decoder 200. ^■ In an initialisation step 1501, the R mapping 308 is initialised by the processor 1705 such that each probability range in the Q mapping 307 is assigned to one of the fixed probability encoders 508 or one of the fixed probability decoders 608 of entropy encoder 104 entropy of entropy decoder 202 respectively. Also, a variable, 'mergedStateCount', is initialised to the number of fixed probability encoders 508 or fixed probability decoders 608.

At a determine candidate step 1502, the processor 1705 determines an optimal pair of adjacent probability ranges from the current R mapping 308 to merge, with the first probability range returned in a 'bestMergeCandidate' variable and a resulting gain is returned in a 'bestMergeGain' variable stored within the memory 1706. If the processor 1705 determines that no gain can be achieved, the 'bestMergeGain' variable is not updated and therefore remains at an initial (negative) value. A method 1600 of determining an optimal pair of adjacent probability ranges to merge, as executed at step 1502, will be described in further detail below with reference to Fig. 16.

The 'bestMergeGain' variable is tested by the processor 1705 in a bestMergeGain test step 1503. If the processor 1705 determines that no further gain can be achieved by merging adjacent probability ranges then control of the method 1500 passes to an assignment step 1505. Otherwise proceeds to a merge step 1504. In merge step 1504, the R mapping 308 stored within memory 1706 is amended so that the pair of adjacent probability ranges indicated by the 'bestMergeCandidate' variable are merged together. The result of step 1504 are fixed probabilities belonging to each adjacent probability range being mapped to a single larger probability range.

In assignment step 1505, for each entry in the R mapping 308, an optimal one of the fixed probability encoders 508 or fixed probability decoders 608 is determined and assigned to the R mapping 308 within memory 1706. The determination of the optimal fixed probability encoders 508 or decoders 608 is based on the total count and least probable symbol (LPS) count for the probability ranges merged together according to the R mapping 308.

The method 1600 of determining an optimal pair of adjacent probability ranges to merge, as executed at step 1502, will now be described with reference to Fig. 16. The method 1600 determines which, if any, pair of groups of symbols at the Q mapping 307 should be merged together to obtain a coding gain.

The method 1600 begins at a get best tree step 1601, where a first group of symbols is matched with an optimal one of the fixed probability encoders 508 or fixed probability decoders 608. The fixed probability encoder 508 or decoder 608 is selected by the processor 1705 as a closest match to the least probable symbol (LPS) probability of the group of symbols. A group of symbols is defined as all the symbols mapped together according to fixed probability 305 from a Q mapping 307 that were encountered between trigger points in entropy encoder 104 and entropy decoder 202.

Step 1601 returns an index 'bestTree' configured within memory 1706 to indicate which one of the available encoders of the fixed probability encoders 508 or decoders 608 was selected as optimal to encode or decode the group of symbols.

In a get cost step 1602, the processor 1705 determines a coding cost for coding the group of symbols with the selected one of the fixed probability encoders 508 or decoders 608. The coding cost is determined and assigned to a 'rawCost' variable configured within the memory 1706. The coding cost is a measure of how many bits are required to code the group of symbols with the fixed probability encoder 508 or decoder 608 selected at step 1601.

The 'rawCost' variable is a measure of the cost of coding a group comprising a plurality ("total_coun ") of symbols with least probable symbol (LPS) occurrences indicated by a variable, LPS_C0Unt, using one of the fixed probability encoders 508 or decoders 608. The one of the fixed probability encoders 508 or decoders 608 matched to the group of symbols at step 1601 is optimised to encode or decode the symbols occurring at a probability, treeProb. The cost of coding, 'rawCost', the group of symbols may be determined at step 1602 in accordance with Equation (2), as follows:

rawCost = ^LPS " ^l°Z(^tT∞^?roh<< > ^{+ tota} « - ^LPScoun, ) logfl - treeProb, ) \

log(2)

Equation (2) determines the cost of coding the symbols in the group based on the fixed probability 306 corresponding to the one of the fixed probability encoders 508 or decoders 608 matched to the group of symbols at step 1601.

When the fixed probability encoders 508 or decoders 608 are implemented using arithmetic encoders, the coding cost value determined at step 1602 provides the final cost value for coding a group of symbols.

When the fixed probability encoders 508 or decoders 608 are implemented using lookup tables, the coding gain achieved is close to the optimal coding gain. However, due to the look-up tables only approximating the ideal performance of an arithmetic encoder or decoder, the coding gain realised is always less than that achieved with an arithmetic encoder or decoder. A 'treeLoss' parameter configured within the memory 1706 is defined for a look-up table implementation of each of the fixed probability encoders 508 or decoders 608. The 'treeLoss' parameter specifies how closely the entropy coding of a binary tree structure corresponding to the look-up table approaches the entropy coding gain achieved by an arithmetic encoder or decoder implementation. The reduction of coding gain due to use of a look-up table may be compensated for by incorporating the 'treeLoss' parameter. Further compensation may be required when using variable length tables for coding, as the sequence of symbols in the group of symbols being coded will typically not terminate on a table entry boundary. Therefore, some padding is added to reach a table entry boundary and thus allow the translation to occur. The padding is modelled by a 'termCost' parameter, which provides the expected termination cost for each of the fixed probability encoders 508 or decoders 608, when implemented using look-up tables. The expected termination cost variable, 'totalCost', may be determined in accordance with Equation (3), as follows: totalCost = (1 + treeLoss_k ) x rawCost + termCost_k (3)

v

In an initialise variables step 1603, a 'k' variable configured within the memory 1706, indicating a current group of symbols according to the Q mapping 307, is cleared. Also at step 1706, a 'mergeCandidate' variable configured within the memory 1706 is set to '- indicating that no merge candidate exists presently. A 'bestMergeGain' variable configured within memory 1706 is set to a large negative number, such as -1,000,000, as a temporary value until a gain from a particular merge candidate is determined. Further, a 'cost' variable configured within memory 1706 is set to zero (0).

In a get bestTreeNext step 1604, an optimal one of the fixed probability encoders 508 or fixed probability decoders 608 is identified by the processor 1705 for grouping a next group of symbols 'k+Γ in the same manner as in the get best tree step 1601. Also at step 1604, a representative index for one of the fixed probability encoders 508 or decoders 608 is assigned by the processor 1705 to the 'bestTreeNext' variable configured within memory 1706.

In a get bestTreeMerged step 1605, an optimal one of the fixed probability encoders 508 or fixed probability decoders 608 is identified by the processo 1705 for a combined group of symbols formed by the groups 'k' and 'k+ in the same manner as step 1601. Also at step 1605, a representative index for one of the fixed probability encoders 508 or decoders 608 is assigned by the processor 1705 to a 'bestTreeMerged' variable configured within memory 1706. Combining the groups of symbols 'k' and 'k+Γ is achieved by summing the total symbol count and the least probable symbol (LPS) count respectively for each group of symbols, 'k' and 'k+ .

In get costNext step 1606, the cost for coding the group of symbols, 'k+Γ, using the binary tree corresponding to the one of the fixed probability encoders 508 or decoders 608 identified at step 1604, is determined in accordance with Equation (3). The cost determined in step 1606 is assigned to a 'costNext' variable configured within the memory 1706.

In get costMerged step 1607, the cost of coding the merged groups of symbols 'k' and 'k+r using the binary tree corresponding to the one of the fixed probability encoders 508 or decoders 608 selected at step 1604 is determined in accordance^* with Equation (3). The cost determined at step 1607 is assigned to a 'costMerged' variable configured within the memory 1706.

In a cost decision step 1608, the value of the "cost" variable configured within memory 1706 is added to the value of the 'costNext' variable configured within memory 1706 and the value of the 'costMerged' variable is subtracted. If the result of step 1608 is greater than the value of the 'bestMergeGain' variable configured within memory 1706, control of the method 1600 passes to update merge variables step 1609. Otherwise, the method 1600 passes to update tree step 1610.

In update merge variables step 1609, the value of the 'k' variable configured in memory 1706 is assigned to the variable 'mergeCandidate'. Further, the value of the 'bestMergeGain' variable is assigned with the result of the value of the cost variable added to the value of the 'costNext' variable and the value of the 'costMerged' variable is subtracted.

In update tree step 1610, the value of the 'treeNext' variable is assigned to a variable tree configured within memory 1706. Further, at step 1610, the value of the 'costNext' variable is assigned to the cost variable configured within memory.

Next, in an update k step 161 1 , the 'k' variable configured within memory 1706 is incremented. At decision step 1612, the value of the 'k' variable is compared with a maximum number of groups, Qmax, representing the number of quantisation probability ranges in the Q mapping 307. If the processor 1705 determines that the value of the variable 'k' is less than the maximum number of groups, Qmax, then control of the method 1600 passes to the get bestTreeNext step 1604. Otherwise, the method 1600 concludes. Industrial Applicability

The arrangements described are applicable to the computer and data processing industries and particularly for the digital signal processing.

The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive.

In the context of this specification, the word "comprising" means "including principally but not necessarily solely" or "having" or "including", and not "consisting only of. Variations of the word "comprising", such as "comprise" and "comprises" have correspondingly varied meanings.

Claims

CLAIMS:

1. A method of generating bins used to encode binarised syntax elements representing video data, the method comprising:

2. The method according to claim 1 , further comprising filtering the determined counts of the selected symbols based on history of counts of the selected symbols.

3. The method according to claim 1, wherein the second mapping is determined when a total count of said symbols reaches a threshold.

4. The method according to claim 1, further comprising resetting the count of the selected symbols, associated with each of the probability ranges, when the second mapping is determined.

5. The method according to claim 3, where the threshold is a constant value.

6. The method according to claim 3, wherein the threshold is dependent on frame size associated with the video data.

7. The method according to claim 3, wherein the threshold is based on a difference between probability levels determined from the symbol counts and the probability values associated with each of the decoders.

8. A system for generating bins used to encode binarised syntax elements representing video data, the system comprising:

a memory for storing data and a computer program;

receiving a plurality of bitstreams encoding symbols indicating values of the bins;

9. An apparatus for generating bins used to encode binarised syntax elements representing video data, the apparatus comprising:

* means for receiving a plurality of bitstreams encoding symbols indicating values of the bins;

10. A computer readable medium, having a program recorded thereon, where the program is configured to make a computer execute a procedure to generate bins used to encode binarised syntax elements representing video data, the program comprising:

code for selecting a plurality of the decoded symbols to generate a first subset of the bins, each of the selected symbols being selected from one of said decoders according to the first mapping;

code for determining a count of the selected symbols associated with each of the probability ranges; '

1 1. A method of encoding bins used to encode binarised syntax elements representing video data, the method comprising:

receiving the binarised syntax elements encoded in a plurality of bins;

12. The method according to claim 1 1, further comprising filtering the determined counts of the selected symbols based on history of counts of the selected symbols.

13. The method according to claim 1 1, wherein the second mapping is determined when a total count of said symbols reaches a threshold.

14. The method according to claim 11, further comprising resetting the count of the selected symbols, associated with each of the probability ranges, when the second mapping is determined.

15. The method according to claim 13, where the threshold is a constant value.

16. The method according to claim 13, wherein the threshold is dependent on frame size associated with the video data.

17. The method according to claim 10, wherein the threshold is based on a difference between probability levels determined from the symbol counts and the probability values associated with each of the decoders.

18. A system for encoding bins used to encode binarised syntax elements representing video data, the system comprising:

a memory for storing data and a computer program;

receiving the binarised syntax elements encoded in a plurality of bins;

generating a plurality of symbols, indicating the values of said bins, each f the symbols being associated with a probability range;

19. An apparatus for encoding bins used to encode binarised syntax elements representing video data, the apparatus comprising:

means for determining a first mapping to a plurality of encoders, each said encoder being configured for a particular probability, the first mapping being determined from the probability ranges associated with an expected value of each of the bins; means for assigning a plurality of the symbols, representing a first subset of said bins, to one of said encoders according to said first mapping;

20. A computer readable medium, having a program recorded thereon, where the program is configured to make a computer execute a procedure for encoding bins used to encode binarised syntax elements representing video data, the program comprising:

code for receiving the binarised syntax elements encoded in a plurality of bins;

code for determining a first mapping to a plurality of encoders, each said encoder; being configured for a particular probability, the first mapping being determined from the probability ranges associated with an expected value of each of the bins;