AU2012203827A1 - Method, apparatus and system for encoding and decoding the reference picture index of a prediction unit - Google Patents

Abstract

Abstract METHOD, APPARATUS AND SYSTEM FOR ENCODING AND DECODING THE REFERENCE PICTURE INDEX OF A PREDICTION UNIT 5 A method of decoding a reference picture index from a stream of video data is disclosed. The reference picture index is configured for selecting a previously decoded frame of video data received at a decoder according to a long term picture list. A reference picture list length is determined based on a received maximum length of the reference picture list. The method also determines, according to the reference picture list length, a 10 bin coding type threshold for use on the reference picture index. The bin coding type threshold is a number of bins in a bin string of the reference picture list that use arithmetic coding with any remaining bins of the bit string using bypass coding. The reference picture index is decoded using the bin coding type threshold to select one of arithmetic and bypass encoding to decode the bin string of the reference picture index. P038632 / 6,422,486_1 / P038632_SpeciAs Filed

Description

S&F Ref: P038632 AUSTRALIA PATENTS ACT 1990 COMPLETE SPECIFICATION FOR A STANDARD PATENT Name and Address Canon Kabushiki Kaisha, of 30-2, Shimomaruko 3 of Applicant: chome, Ohta-ku, Tokyo, 146, Japan Actual Inventor(s): Christopher James Rosewarne Address for Service: Spruson & Ferguson St Martins Tower Level 35 31 Market Street Sydney NSW 2000 (CCN 3710000177) Invention Title: Method, apparatus and system for encoding and decoding the reference picture index of a prediction unit The following statement is a full description of this invention, including the best method of performing it known to me/us: 5845c(642431 0_1) METHOD, APPARATUS AND SYSTEM FOR ENCODING AND DECODING THE REFERENCE PICTURE INDEX OF A PREDICTION UNIT TECHNICAL FIELD The present invention relates generally to digital video signal processing and, in particular, to a method, apparatus and system for encoding and decoding reference picture indices of a prediction unit (PU). The present invention also relates to a computer program 5 product including a computer readable medium having recorded thereon a computer program forencoding and decoding reference picture indices of a prediction unit (PU). BACKGROUND Many applications for video coding currently exist, including applications for transmission and storage of video data. Many video coding standards have also been 10 developed and others are currently under 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). The Joint Collaborative Team on Video Coding (JCT VC) includes members of Study Group 16, Question 6 (SGI6/Q6) of the Telecommunication Standardisation Sector (ITU-T) of the International 15 Telecommunication Union (ITU), known as the Video Coding Experts Group (VCEG), and members of the International Organisations for Standardisation/InternationalElectrotechnical Commission Joint Technical Committee 1 / Subcommittee 29 / Working Group 11 (ISO/IEC JTCI/SC29/WG 11), also known as the Moving Picture Experts Group (MPEG). 20 The Joint Collaborative Team on Video Coding (JCT-VC) has the goal of producing a new video coding standard to significantly outperform the presently existing video coding standard known as "H.264/MPEG-4 AVC". The H.264/MPEG-4 AVC standard is itself a large improvement on previous video coding standards such as MPEG-4 Visual and ITU-T H.263. The new video coding standard under development has been 25 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 HEVC standard to operate at high resolutions or high frame rates. One area of the H.264/MPEG-4 AVC video coding standard that presents 30 difficulties for achieving high compression efficiency is the coding of reference picture indices used to represent video data. Video data is formed by a sequence of frames (or, P038632 / 6,422,486_1 / P038632_SpeciAs Filed 2 pictures), with each frame having a two-dimensional array of samples. Typically, frames include one luminance (luma) and two chrominance (chroma) channels. Colour information is typically represented using a colour space such as YUV, with Y being the luma channel and U and V being two chroma channels. A colour space such 5 as YUV has an advantage in that the majority of the frame content is contained in the luma channel. The relatively smaller amount of content stored in the UV chroma channels is sufficient to reconstruct a colour frame. Furthermore, the chroma channels may also be down sampled to a lower spatial resolution with negligible resultant perceptual quality loss. A commonly used chroma format is 4:2:0 which results in each chroma channel 10 having half the vertical and horizontal resolution of the luma channel. A coding unit is a square shaped set of collocated luma and chroma samples. Coding units vary in size from 4x4 to 64x64, with edge dimensions being a power of two and having a square shape. A 64x64 area is defined as a largest coding unit (LCU) and contains one or more coding units, such that the 64x64 area is completely filled with non-overlapping coding units. 15 Other power-of-two sizes for the largest coding unit are possible and the maximum size of a coding unit is not required to be equal to the size of a largest coding unit (LCU). Each frame is decomposed into an array of largest coding units (LCUs). A quadtree structure enables the subdivision of each largest coding unit (LCU) into four coding units (CUs), each having half the width and height of a parent largest coding unit (LCU). Each of the 20 coding units (CUs) may be further subdivided into four equally-sized coding units (CUs). Such a subdivision process may be applied recursively until a smallest coding unit (SCU) size is reached, enabling coding units (CUs) to be defined down to a minimum supported size. This recursive subdivision of a largest coding unit into a hierarchy of coding units produces a quadtree structure and is referred to as a coding tree block (CTB). The 25 subdivision process is encoded in a bitstream as a sequence of flags, coded as bins. Coding units therefore have a square shape. The array of largest coding units (LCUs) comprising a frame are coded in a bitstream in raster scan order. Each frame is divided into one or more slices, each containing an integer number of consecutive largest coding units. Each slice consists of a slice header followed by slice data. The slice header includes information 30 necessary to construct reference picture lists and the slice data contains one or more largest coding units (LCUs). In addition to frame data, bitstreams also contain additional data specifying things such as reference picture list dimensions, quantisation matrices, frame size and chroma formats. Two types of parameter sets are used to encode this data, known as sequence P038632 / 6,422,486 1 / P038632_SpeciAs Filed 3 parameter sets (SPSs) and picture parameter sets (PPSs). These must be sent before the first frame in order for a decoder to correctly parse the encoded frame. Each coding unit at the leaf nodes of the coding trees are subdivided into one or more arrays of predicted data samples, each known as a prediction unit (PU). Each 5 prediction unit (PU) contains a prediction of a portion of the input video frame data, the prediction being derived by applying an intra-prediction or an inter-prediction process. For 'P' slices, the prediction for each prediction unit (PU) in an inter-predicted coding unit (CU) is created from a single reference picture. For 'B' slices, the prediction for a prediction unit (PU) within an inter-predicted coding unit (CU) is created from either one 10 or two reference pictures. Several methods may be used for coding prediction units (PUs) within a coding unit (CU), specified by a partition mode. When the partition mode is 'PART_2Nx2N' a single prediction unit (PU) occupies the entire area of the coding unit (CU). Partition modes of 'PART_2NxN' and 'PARTNx2N' divide coding unit (CU) into two equal-sized 15 rectangular prediction units (PUs) vertically and horizontally, respectively. A 'PARTNxN' partition mode divides the coding units (CU) into four equal-sized square prediction units (PUs). In subdividing a coding unit (CU) into one or more prediction units (PUs), the prediction units (PU) are non-overlapping and occupy the entire area of the coding unit (CU). 20 For inter-predicted coding units (CUs), additional partition modes are available. The additional partitions divide the coding unit (CU) horizontally (PART_2NxnU and PART_2NxnD) and vertically (PART_nLx2N and PARTnRx2N) into two rectangular prediction units (PUs), such that the ratios of the dimension in which the coding unit is split is 3:1 and 1:3, respectively. The ratios result in two prediction units spatially 25 occupying % and /4 (or vice versa) of the coding unit (CU). Other partition modes are also possible. A coded sequence of frames begins with an instantaneous decode picture (IDR). Each instantaneous decode picture resets a frame counter to zero. Each subsequent reference picture increments the frame number, where a picture is analogous to a frame. Video compression standards supporting interlacing may instead decode fields, which are 30 equivalent to pictures. In some implementations, frame numbers may be skipped. In this instance, the decoder is required to insert "dummy" decoded pictures into the gaps in the frame number. The order in which pictures are displayed may differ from the order in which the pictures are decoded. Each decoded picture has a picture order count (POC) that P038632 / 6,422,486 1 / P038632_SpeciAs Filed 4 determines the display order. There are three methods for specifying the picture order count (POC) for a picture, as follows: Type 0: Explicitly code the least significant bits of the picture order count in each slice header. When the least significant bits rollover, a counter holding the most 5 significant bits of the picture order count (POC) is incremented. The least significant bits and the most significant bits of the picture order count (POC) are concatenated to create the full value of the picture order count (POC). The Type 0 method provides maximum flexibility, however the bit cost of explicit coding is highest. Type 1: The sequence parameter set specifies the number of reference frames in a 10 picture order count (POC) cycle, the cycle being a repeating group of reference and non reference frames). Reference picture lists are derived from known temporal relationships between frames in the bitstream. Type 2: The picture order count (POC) is derived from the frame count, resulting in the display order being the same as the decode order. 15 Picture display occurs once the decoded picture buffer is full. When the decoded picture buffer is full, the frame with the lowest value for picture order count (POC) is evicted from the decoded picture buffer and displayed. Evicting frames according to the picture order count (POC) permits display order to differ from decode order. Pictures available for reference are stored in a decoded picture buffer (DPB). 20 Pictures in the decoded picture buffer are either marked as short term reference pictures (STRPs) or long term reference pictures (LTRPs). Short term reference pictures are either indexed according to frame number or picture order count (POC). Long term reference pictures are indexed and assigned a LongTermPicNum when the pictures are marked as being for long term reference. Any short-term picture may be assigned a 25 LongTermPicNum, changing the short-term picture into a long term reference picture (LTRP). Short term reference pictures (STRPs) are removed from the decoded picture buffer (DPB) either when the buffer is full, or via an explicit command encoded in the bitstream. Long term reference pictures (LTPRs) are removed from the decoded picture buffer (DPB) 30 when an explicit command is encoded in the bitstream. There are two types of inter-prediction process, which use either a single reference block for each prediction unit (PU) or two reference blocks for each prediction unit (PU). In a 'P' slice, each prediction unit is only permitted to use a single reference block. In a '13' slice, each prediction unit (PU) is permitted to use up to two reference blocks. Each P038632 / 6,422,486_1 / P038632_Speci_As Filed 5 reference block is obtained by selecting a reference frame from a reference picture list. 'P' slices have one reference picture list '10' (or 'list 0') and 'B' slices have two reference picture lists '10' (or 'list 0') and '11' (or 'list 1'). In a 'B' slice, the bitstream may encode an 'interpredide' syntax element for each prediction unit (PU) within an inter-predicted 5 coding unit (CU). The 'interpredidc' syntax element specifies whether the prediction unit (PU) uses both list 0 and list 1, indicating two reference frames per prediction unit (PU), or uses one of list 0 or list 1, indicating one reference frame per prediction unit (PU). When the motion vector(s) and reference frame(s) for a prediction unit (PU) are obtained from a list of candidates, the value of 'interpred_ide' is also obtained from the list of 10 candidates. Reference picture lists are constructed at the beginning of each slice. By default, each reference picture list is constructed such that short term reference pictures (STRPs) are located first (i.e. at lower list indices), followed by the long term reference pictures (LTRPs). When the current slice is a P slice, the ordering of short term reference pictures 15 (STRPs) in the reference picture list depends on the decode order (represented by a PicNum variable). When the current slice is a B slice, the ordering of short term reference pictures (STRPs) in each reference picture list depends on the display order. List 0 is ordered in decreasing order of POC for pictures earlier (in POC) than the current picture, followed by increasing order of POC for pictures later (in POC) than the current picture. 20 List I is ordered in increasing order of POC for pictures earlier (in POC) than a current picture, followed by increasing order of POC for pictures later (in POC) than the current picture. The size of the two reference picture lists, list 0 and list 1, is limited by the availability of reference frames within the decoded picture buffer (DPB) and a specified 25 maximum length of each reference picture list. A picture parameter set (PPS) includes syntax elements named (i) numrefidx_10_defaultactiveminusl and (ii) numrefidxlldefaultactive_minusl, which provide default lengths for the two reference picture lists. The maximum lengths of the reference picture lists list 0 and list I may be specified in a bitstream via a picture parameter set (PPS), by default or via the slice 30 header (SH). In this instance,'num_refidxactiveoverrideflag' is set to '1' in the slice header, then the maximum length if list 0 is specified by a 'numrefidx_10_activeminusl' syntax element (present in the slice header for P and B slice) and the maximum length of list I is specified by a 'numrefidx_11 _activeminusl' syntax element (present for B slices).If the 'num ref idxactiveoverrideflag' is set to P038632 / 6,422,486_ / P038632-SpeciAs Filed 6 '0', then the reference picture lists list 0 and list 1 are derived using shortterm-_ref pic set syntax. For short term reference picture set syntax, the sequence parameter set (SPS) includes a definition of one or more short term reference picture sets, used to construct sets 5 of short term reference pictures (STRPs) and a flag named 'longtermref picspresent flag' indicating the presence of long term reference pictures (LTRPs). A unary binarisation represents a positive integer 'n' as a sequence of 'n-l' bins having a '1' value following by a final bin having a '0' value. In the unary binarisation 10 scheme, the '1' and '0' values may be reversed while retaining an intelligible bin string. The unary binarisation scheme permits representation of any positive integer. However, in many applications an upper limit on the value of 'n' is known. In such applications a truncated unary (TU) binarisation is applied. The truncated unary (TU) binarisation for a positive integer 'n' having a maximum value 'max' has the same form as the unary 15 binarisation, except that the bin string has a maximum length of 'max' bins. At each position in the bin string, either arithmetic or bypass coding may be used for the corresponding bin. If arithmetic coding is used, then the context model for this bin must be specified. In a video encoder or video decoder, since separate context information is available 20 for each bin, context selection for bins provides a means to improve coding efficiency. In particular, coding efficiency may be improved by selecting a particular bin such that statistical -properties from previous instances of the bin, where the associated context information was used, correlate with statistical properties of a current instance of the bin. Such context selection frequently utilises spatially local information within a given frame 25 to determine the optimal context. In the high efficiency video coding (HEVC) standard under development and in H.264/MPEG-4 AVC, a prediction for a prediction unit is derived, based on reference sample data either from other frames, or from neighbouring regions within the current frame that have been previously decoded. The difference between the prediction and the 30 desired sample data is known as the residual. A frequency domain representation of the residual is a two-dimensional array of residual coefficients. By convention, the upper-left corner of the two-dimensional array contains residual coefficients representing low frequency information. P038632 / 6,422,486_1 / P038632_Speci_As Filed 7 SUMMARY It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements. According to one aspect of the present disclosure there is provided a method of 5 decoding a reference picture index from a stream of video data, the reference picture index being configured for selecting a previously decoded frame of video data received at a decoder according to a long term picture list, the method comprising: determining a reference picture list length based on a received maximum length of the reference picture list; 10 determining, according to the reference picture list length, a bin coding type threshold for use on the reference picture index, the bin coding type threshold being a number of bins in a bin string of the reference picture list that use arithmetic coding with any remaining bins of the bit string using bypass coding; and decoding the reference picture index using the bin coding type threshold to select 15 one of arithmetic and bypass encoding to decode the bin string of the reference picture index. According to another aspect of the present disclosure there is provided a method of encoding a reference picture index from a stream of video data, the reference picture index being configured for selecting a previously decoded frame of video data received at an 20 encoder according to a long term picture list, the method comprising: determining a reference picture list length based on a received maximum length of the reference picture list; determining, according to the reference picture list length, a bin coding type threshold for use on the reference picture index, the bin coding type threshold being a 25 number of bins in a bin string of the reference picture list that use arithmetic coding with any remaining bins of the bit string using bypass coding; and encoding the reference picture index using the bin coding type threshold to select one of arithmetic and bypass encoding to encode the bin string of the reference picture index. 30 Other aspects are also disclosed. BRIEF DESCRIPTION OF THE DRAWINGS At least one embodiment of the present invention will now be described with reference to the following drawings, in which: P038632 / 6,422,486_ / P038632_SpeciAs Filed 8 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; 5 Figs. 3A and 3B form a schematic block diagram of a general purpose computer system upon which the encoder and decoder of Figs. I and 2, respectively, may be practiced; Fig. 4 is a schematic block diagram showing an entropy encoder module; Fig. 5 is a schematic block diagram showing an entropy decoder module; 10 Fig. 6 shows a portion of a bitstream containing a slice, encoding motion vectors and reference picture indices; Fig. 7A is a schematic block diagram showing an example binarisation for encoding a reference picture index; Fig. 7B is a schematic block diagram showing a further example binarisation for 15 encoding a reference picture index; Fig. 7C is a schematic block diagram showing a further example binarisation for encoding a reference picture index; Fig. 8A is a schematic block diagram showing a further example binarisation for encoding a reference picture index; 20 Fig. 8B is a schematic block diagram showing a further example binarisation for encoding a reference picture index; Fig. 9A is a schematic block diagram showing a further example binarisation for encoding a reference picture index; Fig. 9B is a schematic block diagram showing a further example binarisation for 25 encoding a reference picture index; Fig. 10 is a schematic block diagram shows an example encoded prediction unit (PU) for encoding a bi-predicted block in a 'B' slice; Fig. 1 A is a schematic flow diagram showing a method for encoding a portion of a bitstream encoding a reference picture index; 30 Fig. I IB is a schematic flow diagram showing a method of encoding a reference picture index in a bitstream, as executed in the method of Fig. I1 A; Figs. 12A is a schematic flow diagram showing a method for decoding a portion of a bitstream encoding a reference picture index; P038632 / 6,422,486 1 / P038632_Speci_As Filed 9 Fig. 12B is a schematic flow diagram showing a method of decoding a reference picture index in a bitstream, as executed in the method of Fig. 12A; Fig. 13A is a schematic flow diagram showing a method for encoding a portion of a bitstream encoding a reference picture index; 5 Fig. 13B is a schematic flow diagram showing a method of encoding a plurality of reference picture indices, as executed in the method of Fig. 13A; Fig. 14A is a schematic flow diagram showing a method for decoding a plurality of reference picture indices; Fig. 14B is a schematic flow diagram showing a method of decoding a plurality of 10 reference picture indices, as executed in the method of Fig. 14A; Fig. 15 is a schematic block diagram showing an example of a portion of an encoded slice; Figs. 16A to 16C are schematic block diagrams showing example binarisations for encoding a merge index; and 15 Appendices A and B show syntax tables. DETAILED DESCRIPTION INCLUDING BEST MODE 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 20 intention appears. It is to be noted that the discussions contained in the "Background" section relate to discussions of documents or devices which may form public knowledge through their respective publication and/or use. Such discussions should not be interpreted as a representation by the present inventor(s) or the patent applicant that such documents or 25 devices in any way form part of the common general knowledge in the art. A video encoder compresses video data into a bitstream by converting the video data into a sequence of syntax elements. A context adaptive binary arithmetic coding (CABAC) scheme is defined within the high efficiency video coding (HEVC) standard under development, using an identical arithmetic coding scheme to that defined in the 30 MPEG4-AVC/H.264 video compression standard. In the high efficiency video coding (HEVC) standard under development, when context adaptive binary arithmetic coding (CABAC) is in use, each syntax element is expressed as a sequence of bins. Each bin is either bypass-coded or arithmetically coded. Bypass coding may be considered a type of static probability modelling and is used where the value of the bin is P038632 / 6,422,486_1 / P038632_SpeciAs Filed 10 equally likely to be 0 or 1. This equiprobable static modelling permits a bin to be encoded in a bitstream using exactly 1 bit. In this case, there is no further compression achievable. Arithmetic coding is used for bins for which probability distribution is such that the likelihood of the bin having a 0 or a 1 value is not equal. Each arithmetically coded bin is 5 associated with information known as a 'context'. Contexts contain a likely bin value (the 'vaIMPS') and a probability state, which is an integer which maps to an estimated probability of the likely bin value occurring. Creating such a sequence of bins, comprising combinations of bypass-coded bins and arithmetic-coded bins, from a syntax element is known as "binarising" the syntax element and sequence of bins (or 'bin string') 10 representing the particular value of the syntax element is known as a "binarisation". Reconstructing the value of a syntax element from a sequence of bins is known as "debinarising" or "inverse binarising" or "parsing"). Each type of syntax element has specific 'rules' for representing all possible values of that syntax element with unique binarisations. In assigning contexts to arithmetically coded bins in the binarisation, the 15 rules enable modelling of the statistical behaviour of the values of the syntax elements being binarised, due to the adaptive probability model updating mechanism. Where a particular bin is known to have an equiprobable distribution of '1' and '0' values, there is no coding gain possible by assigning a context to this bin and accordingly, a bypass coding mechanism is appropriate for this bin. Using bypass coding for bins known to have a 20 probability distribution far from equiprobable results in reduced coding efficiency, as the cost of the bin is fixed at one bit per bypass bin regardless of the underlying distribution of the bin's values. Finally, sequences of bins coded using bypass coding may be either fixed in length or variable in length and, as stated previously, do not use context information. Where the binarisations result in the concatenation of multiple bypass bins, it is 25 possible for a decoder implementation, such as a hardware or a software implementation, to fetch multiple (abutted) bypass bins in a single operation. An encoder implementation may correspondingly write multiple bypass bins in a single operation. This property to abutted bypass bins may be exploited to increase the throughput of bins through the entropy encoder or entropy decoder. Such a throughput increase is desirable. An upper 30 limit on the throughput of arithmetic bins is bound by implementation aspects such as the system clock frequency. The opportunity of encoding or decoding multiple arithmetic bins in a single cycle is limited by the relative complexity of the arithmetic bin encoding and decoding process. The arithmetic encoding and decoding process requires a relatively long timing path, which limits the ability to perform multiple encode or decode operations in a P038632 / 6,422,486 1 / P038632_SpeciAs Filed I I single clock cycle. In contrast, binarisation arrangements that result in larger fetches of bypass bins in a single operation provide a means to further increase the overall bin throughput of an entropy encoder or entropy decoder without requiring complex logic with long timing paths. However, as was previously noted, encoding a bin as a bypass bin only 5 provides optimal coding when the bin has an equiprobable statistical distribution. Fig. I is a schematic block diagram showing functional modules of a video encoder 100. Fig. 2 is a schematic block diagram showing functional modules of a corresponding video decoder 200. The video encoder 100 and video decoder 200 may be implemented using a general-purpose computer system 300, as shown in Figs. 3A and 3B where the 10 various functional modules may be implemented by dedicated hardware within the computer system 300, by software executable within the computer system 300, or alternatively by a combination of dedicated hardware and software executable within the computer system 300. As seen in Fig. 3A, the computer system 300 includes: a computer module 301; 15 input devices such as a keyboard 302, a mouse pointer device 303, a scanner 326, a camera 327, and a microphone 380; and output devices including a printer 315, a display device 314 and loudspeakers 317. An external Modulator-Demodulator (Modem) transceiver device 316 may be used by the computer module 301 for communicating to and from a communications network 320 via a connection 321. The communications network 20 320 may be a wide-area network (WAN), such as the Internet, a cellular telecommunications network, or a private WAN. Where the connection 321 is a telephone line, the modem 316 may be a traditional "dial-up" modem. Alternatively, where the connection 321 is a high capacity (e.g., cable) connection, the modem 316 may be a broadband modem. A wireless modem may also be used for wireless connection to the 25 communications network 320. The computer module 301 typically includes at least one processor unit 305, and a memory unit 306. For example, the memory unit 306 may have semiconductor random access memory (RAM) and semiconductor read only memory (ROM). The computer module 301 also includes an number of input/output (I/O) interfaces including: an audio 30 video interface 307 that couples to the video display 314, loudspeakers 317 and microphone 380; an I/O interface 313 that couples to the keyboard 302, mouse 303, scanner 326, camera 327 and optionally a joystick or other human interface device (not illustrated); and an interface 308 for the external modem 316 and printer 315. In some implementations, the modem 316 may be incorporated within the computer module 301, P038632 / 6,422,486_ / P038632_SpeciAs Filed 12 for example within the interface 308. The computer module 301 also has a local network interface 31 1,which permits coupling of the computer system 300 via a connection 323 to a local-area communications network 322, known as a Local Area Network (LAN). As illustrated in Fig. 3A, the local communications network 322 may also couple to the wide 5 network 320 via a connection 324, which would typically include a so-called "firewall" device or device of similar functionality. The local network interface 311 may comprise an EthernetTM circuit card, a Bluetooth TM wireless arrangement or an IEEE 802.11 wireless arrangement; however, numerous other types of interfaces may be practiced for the interface 311. 10 The I/O interfaces 308 and 313 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 309 are provided and typically include a hard disk drive (HDD) 310. Other storage devices such as a floppy disk drive and a magnetic tape drive (not illustrated) may also be 15 used. An optical disk drive 312 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 300. Typically, any of the HDD 310, optical drive 312, networks 320 and 322, or camera 327 may for a source for video data to be 20 encoded, or, with the display 314, a destination for decoded video data to be stored or reproduced. The components 305 to 313 of the computer module 301 typically communicate via an interconnected bus 304 and in a manner that results in a conventional mode of operation of the computer system 300 known to those in the relevant art. For example, the 25 processor 305 is coupled to the system bus 304 using a connection 318. Likewise, the memory 306 and optical disk drive 312 are coupled to the system bus 304 by connections 319. Examples of computers on which the described arrangements can be practised include IBM-PC's and compatibles, Sun Sparcstations, Apple MacTM or alike computer systems. 30 Where appropriate or desired, the encoder 100 and the decoder 200, as well as methods described below, may be implemented using the computer system 300 wherein the encoder 100, the decoder 200 and the processes to be described, may be implemented as one or more software application programs 333 executable within the computer system 300. In particular, the encoder 100, the decoder 200 and the steps of the described P038632 / 6,422,486_1 / P038632_SpeciAs Filed 13 methods are effected by instructions 331 (see Fig. 3B) in the software 333 that are carried out within the computer system 300. The software instructions 331 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 5 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 may be stored in a computer readable medium, including the storage devices described below, for example. The software is loaded into the computer system 300 from the computer readable medium, and then executed by the computer system 300. 10 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 300 preferably effects an advantageous apparatus for implementing the encoder 100, the decoder 200 and the described methods. The software 333 is typically stored in the HDD 310 or the memory 306. The 15 software is loaded into the computer system 300 from a computer readable medium, and executed by the computer system 300. Thus, for example, the software 333 may be stored on an optically readable disk storage medium (e.g., CD-ROM)325 that is read by the optical disk drive 312. In some instances, the application programs 333 may be supplied to the user 20 encoded on one or more CD-ROMs 325 and read via the corresponding drive 312, or alternatively may be read by the user from the networks 320 or 322. Still further, the software can also be loaded into the computer system 300 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 300 for 25 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 301. Examples of transitory or non-tangible computer readable 30 transmission media that may also participate in the provision of the software, application programs, instructions and/or video data or encoded video data to the computer module 301 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. P038632 / 6,422,4861 / P038632_SpeciAs Filed 14 The second part of the application programs 333 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 314. Through manipulation of typically the keyboard 302 and the mouse 303, a user of the computer 5 system 300 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 317 and user voice commands input via the microphone 380. 10 Fig. 3B is a detailed schematic block diagram of the processor 305 and a "memory" 334. The memory 334 represents a logical aggregation of all the memory modules (including the HDD 309 and semiconductor memory 306) that can be accessed by the computer module 301 in Fig. 3A. When the computer module 301 is initially powered up, a power-on self-test 15 (POST) program 350 executes. The POST program 350 is typically stored in a ROM 349 of the semiconductor memory 306 of Fig. 3A. A hardware device such as the ROM 349 storing software is sometimes referred to as firmware. The POST program 350 examines hardware within the computer module 301 to ensure proper functioning and typically checks the processor 305, the memory 334 (309, 306), and a basic input-output systems 20 software (BIOS)module 351, also typically stored in the ROM 349, for correct operation. Once the POST program 350 has run successfully, the BIOS 351 activates the hard disk drive 310 of Fig. 3A. Activation of the hard disk drive 310 causes a bootstrap loader program 352 that is resident on the hard disk drive 310 to execute via the processor 305. This loads an operating system 353 into the RAM memory 306, upon which the operating 25 system 353 commences operation. The operating system 353 is a system level application, executable by the processor 305, 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 353 manages the memory 334 (309, 306) to ensure that each 30 process or application running on the computer module 301 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 300 of Fig. 3A must be used properly so that each process can run effectively. Accordingly, the aggregated memory 334 is not intended to illustrate how particular segments of memory are allocated P038632 / 6,422,486 1 / P038632_SpeciAs Filed 15 (unless otherwise stated), but rather to provide a general view of the memory accessible by the computer system 300 and how such is used. As shown in Fig. 3B, the processor 305 includes a number of functional modules including a control unit 339, an arithmetic logic unit (ALU) 340, and a local or internal 5 memory 348, sometimes called a cache memory. The cache memory 348 typically includes a number of storage registers 344- 346 in a register section. One or more internal busses 341 functionally interconnect these functional modules. The processor 305 typically also has one or more interfaces 342 for communicating with external devices via the system bus 304, using a connection 318. The memory 334 is coupled to the bus 304 10 using a connection 319. The application program 333 includes a sequence of instructions 331 that may include conditional branch and loop instructions. The program 333 may also include data 332 which is used in execution of the program 333. The instructions 331 and the data 332 are stored in memory locations 328, 329, 330 and 335, 336, 337, respectively. 15 Depending upon the relative size of the instructions 331 and the memory locations 328 330, a particular instruction may be stored in a single memory location as depicted by the instruction shown in the memory location 330. 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 328 and 329. 20 In general, the processor 305 is given a set of instructions which are executed therein. The processor 305 waits for a subsequent input, to which the processor 305 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 302, 303, data received from an external source across one of the 25 networks 320, 302, data retrieved from one of the storage devices 306, 309 or data retrieved from a storage medium 325 inserted into the corresponding reader 312, all depicted in Fig. 3A. 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 334. The encoder 100, the decoder 200 and the described methods use input 30 variables 354, which are stored in the memory 334 in corresponding memory locations 355, 356, 357. The encoder 100, the decoder 200 and the described methods produce output variables 361, which are stored in the memory 334 in corresponding memory locations 362, 363, 364. Intermediate variables 358 may be stored in memory locations 359, 360, 366 and 367. P038632 / 6,422,486_1 / P038632_SpeciAs Filed 16 Referring to the processor 305 of Fig. 3B, the registers 344, 345, 346, the arithmetic logic unit (ALU) 340, and the control unit 339 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 333. Each fetch, decode, 5 and execute cycle comprises: (a) a fetch operation, which fetches or reads an instruction 331 from a memory location 328, 329, 330; (b) a decode operation in which the control unit 339 determines which instruction has been fetched; and 10 (c) an execute operation in which the control unit 339 and/or the ALU 340 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 339 stores or writes a value to a memory location 332. 15 Each step or sub-process in the processes of Figs. 6, 7, 9 and 10 to be described is associated with one or more segments of the program 333 and is performed by the register section 344, 345, 347, the ALU 340, and the control unit 339 in the processor 305 working together to perform the fetch, decode, and execute cycles for every instruction in the instruction set for the noted segments of the program 333. 20 The encoder 100, the decoder 200 and the described methods may alternatively be implemented in dedicated hardware such as one or more gate arrays and/or integrated circuits performing the GTTCR functions or sub functions. Such dedicated hardware may also include graphic processors, digital signal processors, or one or more microprocessors and associated memories. If gate arrays are used, the process flow charts described here 25 may be converted to Hardware Description Language (HDL) form. The HDL description is converted to a device level net list which is used by a Place and Route (P&R) tool to produce a file. The file may then be downloaded to a gate array to program the file with the design specified in the HDL description. As described above, the video encoder 100 may be implemented as one or more 30 software code modules of the software application program 333 resident on the hard disk drive 305 and being controlled in its execution by the processor 305. In particular the video encoder 100 comprises modules 102 to 112, 114 and 115 which may each be implemented as one or more software code modules of the software application program 333. P038632 / 6,422,486_1 / P038632_SpeciAs Filed 17 Although the video encoder 100 is an example of a high efficiency video coding (HEVC) video decoding pipeline, processing stages performed by the modules 102 to 112, 114 and 115 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 including 5 luminance and chrominance samples. The video encoder 100 divides each frame of the frame data 101 into hierarchical sets of coding units (CUs), representable for example as a coding unit (CU) tree. The video encoder 100 operates by outputting, from a multiplexer module 11 0,an array of predicted data samples known as a prediction unit (PU) 120. A difference module 10 115 outputs the difference between the prediction unit (PU) 120 and a corresponding array of data samples received from the frame data 101, the difference being known as residual data samples 122. The residual data samples 122 from the difference module 115 are received by a transform module 102, which converts the difference from a spatial representation to a 15 frequency domain representation to create transform coefficients 124 for each transform unit (TU) in the transform tree. For the high efficiency video coding (HEVC) standard under development, the conversion to the frequency domain representation is implemented using a modified Discrete Cosine Transform (DCT), in which a traditional DCT is modified to be implemented using shifts and additions. The transform coefficients 124 are 20 then input to a scale and quantise module 103 and are scaled and quantised to produce residual coefficients 126. The scale and quantisation process results in a loss of precision. The residual coefficients 126 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 transform coefficients 128, which are resealed versions of the residual coefficients 126. 25 The resealed transform coefficients 128 are identical to the transform coefficients available to a decoder. Availability of the resealed transform coefficients 128 allows the encoder 100 to reconstruct frames identical to those available to a decoder, which may then be used by a motion compensation module 134 and a motion estimation module 107 for inter prediction. 30 The residual coefficients 126 are also taken as input to an entropy encoder module 104 which encodes the residual coefficients in an encoded video data bitstream 113. Due to the loss of precision resulting from the scale and quantise module 103, the resealed transform coefficients 128 are not identical to the original transform coefficients 124. The resealed transform coefficients 128 from the inverse scaling module 105 are then output to P038632 / 6,422,4861 / P038632_SpeciAs Filed 18 an inverse transform module 106. The inverse transform module 106 performs an inverse transform from the frequency domain to the spatial domain of the rescaled transform coefficients 128 to produce a spatial-domain representation 130 of the rescaled transform coefficients 128 identical to a spatial domain representation that is produced at a decoder. 5 A motion estimation module 107 produces motion vectors 132 and reference picture indices 133 by comparing the frame data 101 with previous frame data stored in a frame buffer module 112, typically configured within the memory 306. Various methods of motion estimation are possible, such as a full search, which searches all possible motion vectors within permitted limits. A full search method is 10 prohibitively slow but can find motion vectors which mimimise residue. Each inter-predicted prediction unit (PU) has either one or two motion vectors and reference picture list indices. Motion vectors and reference picture list indices may be explicitly coded in the bitstream or the vector and indices may be inferred from neighbouring prediction units (PUs). Accordingly, coding units (CUs) containing multiple 15 prediction units (PUs) have multiple sets of motion vectors and reference picture list indices explicitly coded. When a motion vector is to be inferred, several candidate motion vectors are available from neighbouring prediction units (PUs). In high efficiency video coding (HEVC) there are five candidates for inferring a motion vector. Selection of a candidate motion vector may be performed using a merge index syntax element named 20 'mergeidx', having a range from 0-4. The reference picture list index for list 0 is coded using a syntax element named 'refidx_10'. The reference picture list index for list 1 is coded using a syntax element named 'ref idx 11'. The reference picture lists are recreated at each slice. The lengths of the reference picture lists may vary dynamically on a slice by slice basis. 25 Fast search algorithms also exist, such as a 3-step method that searches nine positions, including a present prediction unit (PU) position, by realising all combinations of adding, subtracting or omitting a constant offset to X and Y vector components, relative to the present prediction unit (PU) position. The position with the minimised residue is selected and the process repeated, with a reduced offset value. The process is repeated a 30 fixed number of times, enabling fast determination of a fairly optimal motion vector. The presence of multiple reference frames also increases the search space for the motion estimation operation, although there is no requirement to perform a search over all available reference frames. P038632 / 6,422,486_1 / P038632_SpeciAs Filed 19 One method of motion estimation applies a search on the first reference frame in the reference picture list and then applies the motion vector to each reference frame to discover if further reduction in the residue is possible. For P slices, a single motion vector 132 and reference picture index 133 is produced for each prediction unit (PU) within an 5 inter-predicted coding unit (CU), whereas for B slices, two motion vectors 132 and two references indices 133 are produced. If long term reference pictures (LTRPs) are present in the reference picture list, the long term reference pictures (LTRPs) may also be accessed by the motion estimation module 107. Advantageous encoder implementations may detect situations where a past frame 10 would be valuable for long term reference, but would not be available as a short term picture buffer (STRP) when required, due to the temporal delay. One example of such a situation is in coding scenes with irregular lighting, such as strobe lighting. For such scenes the ideal reference frame may occur many frames in the past, while short term reference pictures (STRPs) contain minimal useful information for inter-prediction, due to 15 the change in lighting conditions. The motion vectors 132 and reference picture indices 133 are input to a motion compensation module 108 which produces inter-predicted reference samples 134 by filtering samples stored in the frame buffer module 112, taking into account a spatial offset derived from the motion vectors 132. Not illustrated in Fig. 1, the motion vectors 132 are 20 also passed as syntax elements to the entropy encoder module 104 for coding in the encoded bitstream 113. An intra-frame prediction module 109 produces intra-predicted reference samples 136 using samples 138 obtained from a summation module 114, which sums the output 120 of the multiplexer module 110 and the output 130 from the inverse transform module 106. 25 Motion vectors may be chosen by a motion estimation process which attempts to minimise the residue, the difference between the selected block of the reference frame and the input frame. Consequently, a motion vector is not guaranteed to correspond to actual detected motion in a video sequence. Prediction units (PUs) may be coded using intra-prediction or inter-prediction 30 methods. The decision as to whether to use intra-prediction or inter-prediction is made according to a rate-distortion trade-off between a desired bit-rate of the resulting encoded bitstream 113 and the amount of image quality distortion introduced by either the intra prediction or inter-prediction method. The multiplexer module 110 selects either the intra predicted reference samples 136 from the intra-frame prediction module 109 or the inter P038632 / 6,422,4861 / P038632_SpeciAs Filed 20 predicted reference samples 134 from the motion compensation module 108, depending on a current prediction mode 142, determined by control logic not illustrated. The prediction mode 142 is also provided to the entropy encoder 104 as illustrated and as such is used to determine or otherwise establish the scan pattern of transform units as will be described. 5 Inter-frame prediction uses only a diagonal scan pattern, whereas intra-frame prediction may use the diagonal scan, a horizontal scan or a vertical scan pattern. The summation module 114 produces a sum 138 that is input to a deblocking filter module I 11. The deblocking filter module I I I performs filtering along transform unit boundaries, producing deblocked samples 140 that are written to the frame buffer module 10 112 configured within the memory 306. The frame buffer module 112 is a buffer with sufficient capacity to hold data from multiple past frames for future reference. In the video encoder 100, the residual data samples 122 within one transform unit (TU) are determined by finding the difference between data samples of the input frame data 101 and the prediction 120 of the data samples of the input frame data 101. The 15 difference provides a spatial representation of the residual coefficients of the transform unit (TU). The entropy encoder module 104 also produces syntax elements from incoming residual coefficient data (or residual coefficients) 126 received from the scale and quantise module 103. The entropy encoder module 104 outputs the encoded bitstream 113 and will 20 be described in more detail below. For the high efficiency video coding (HEVC) standard under development, the encoded bitstream 113 is delineated into network abstraction layer (NAL) units. Each slice of a frame is contained in one NAL unit. There are several alternatives for the entropy encoding method implemented in the entropy encoder module 104. The high efficiency video coding (HEVC) standard under 25 development supports context adaptive binary arithmetic coding (CABAC), based on context adaptive binary arithmetic coding (CABAC) found in H.264/MPEG-4 AVC. An alternative entropy coding method is known as the probability interval partitioning entropy (PIPE) coder. For a video encoder 100 supporting multiple video coding methods, one of the 30 supported entropy coding methods is selected according to the configuration of the encoder 100. Further, in encoding the coding units from each frame, the entropy encoder module 104 writes the encoded bitstream 113 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 P038632 / 6,422,486 1 / P038632_SpeciAs Filed 21 per frame reduces overhead associated with delineating each slice boundary. However, dividing the frame into multiple slices is also possible. Fig. 2 is a schematic block diagram showing functional modules of a video decoder 200. The video decoder 200 may be implemented as one or more software code modules of 5 the software application program 333 resident on the hard disk drive 305 and being controlled in its execution by the processor 305. 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 333. Alternately, the video decoder 200 may be implemented in hardware or a mix of hardware and software. 10 Although the video decoder 200 is described with reference to a high efficiency video coding (HEVC) 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 H.264/MPEG-4 AVC, MPEG-2 and VC-1. An encoded bitstream, such as the encoded bitstream 113, is received by the video 15 decoder 200. The encoded bitstream 113 may be read from memory 306, the hard disk drive 310, a CD-ROM, a Blu-ray T M disk or other computer readable storage medium. Alternatively the encoded bitstream 113 may be received from an external source such as a server connected to the communications network 320 or a radio-frequency receiver. The encoded bitstream 113 contains encoded syntax elements representing frame data to be 20 decoded. The encoded bitstream 113 is input to an entropy decoder module 202 which extracts the syntax elements from the encoded bitstream 113 and passes the values of the syntax elements to other modules in the video decoder 200. There may be multiple entropy decoding methods implemented in the entropy decoder module 202, such as those 25 described with reference to the entropy encoder module 104. Syntax element data 220 representing residual coefficient data is passed to an inverse scale and transform module 203 and motion vectors 222 and reference picture indices 223 are passed to a motion compensation module 204. For P slices, one motion vector 222 and one reference picture index 223 is passed to the motion compensation module 204 for each prediction unit (PU) 30 within an inter-predicted coding unit (CU). For B slices, either one or two motion vectors 222 and reference picture indices 223 are passed to the motion compensation module 204 for each prediction unit (PU) within an inter-predicted coding unit (CU). The inverse scale and transform module 203 performs inverse scaling on the residual coefficient data to create reconstructed transform coefficients. The module 203 then performs an inverse P038632 / 6,422,486 1 / P038632_SpeciAs Filed 22 transform to convert the reconstructed transform coefficients from a frequency domain representation to a spatial domain representation, producing residual samples 224, such as the inverse transform described with reference to the inverse transform module 106. A motion compensation module 204 uses motion vector 222 and reference picture 5 index 223 from the entropy decoder module 202, combined with reference frame data 226 from a decoded picture buffer (DPB) within the frame buffer module 208, configured within the memory 306, to produce inter-predicted reference samples 228 for a prediction unit (PU), being a prediction of output decoded frame data. The reference frame data 226 is retrieved by selecting a particular reference frame from the decoded picture buffer 10 (DPB) according to the entry in the reference picture list specified by the reference picture index 223.A portion of the reference frame data 226 is accessed, in accordance with the motion vector 222 and the size of the current prediction unit (PU). When a syntax element indicates that the current coding unit was coded using intra-prediction, the intra-frame prediction module 205 produces intra-predicted reference samples 230 for the prediction 15 unit (PU) using samples spatially neighbouring the prediction unit (PU). The spatially neighbouring samples are obtained from a sum 232 output from a summation module 210. The multiplexer module 206 selects intra-predicted reference samples or inter-predicted reference samples for the prediction unit (PU) depending on the current prediction mode, which is indicated by a syntax element in the encoded bitstream 113. An array of samples 20 234 output from the multiplexer module 206 is added to the residual samples 224 from the inverse scale and transform module 203 by the summation module 210 to produce the sum 232 which is then input to each of a deblocking filter module 207 and the intra-frame prediction module 205. In contrast to the encoder 100, the intra-frame prediction module 205 receives a prediction mode 236 from the entropy decoder 202. The multiplexer 206 25 receives an intra-frame prediction / inter-frame prediction selection signal 236 from the entropy decoder 202. The deblocking filter module 207 performs filtering along transform unit boundaries to smooth artefacts visible along the transform unit boundaries. The output of the deblocking filter module 207 is written to the frame buffer module 208 configured within the memory 306. The frame buffer module 208 provides sufficient storage to hold 30 multiple decoded frames for future reference. Decoded frames 209 are also output from the frame buffer module 208. Fig. 4 is a schematic block diagram showing the entropy encoder 104 in more detail. The encoder 104 may be implemented as one or more software code modules of the software application program 333 resident on the hard disk drive 305 and being controlled P038632 / 6,422,486_1 / P038632_SpeciAs Filed 23 in its execution by the processor 305.The entropy encoder 104 will be described with reference to encoding reference picture indices. A binariser module 401 creates a binarisation for reference picture index 133, received from the motion estimation module 107. A mode control module 420 signals whether the current bin is to be arithmetically 5 encoded or bypass encoded. If arithmetic encoding is selected, the binariser module 401 further selects a context, such as context 404, from a context model 403. The context model 403 is a buffer holding an array of contexts. The context model 403 may be stored or configured within the memory 306 or hard disk drive 310. A selected context 405 issued by an arithmetic encoder module 406 to encode bins, such as a bin 407, when 10 arithmetic encoding is selected to the encoded bitstream 113. When bypass coding is selected, the arithmetic encoder module 406 encodes the bin without using a context, by allocating one bit in the bitstream to the bin. The bin 407 is used to update the state of the selected context 405, to create an updated selected context 409. The updated selected context 409 is written back to the selected context, such as the context 404, of the context 15 model 403. Fig. 5 is a schematic block diagram showing the entropy decoder module 202 in more detail. The entropy decoder module 202 will be described with reference to decoding reference picture indices. Modules in the entropy decoder 202 operate in a similar manner to corresponding modules in the entropy encoder 104, the difference being that syntax 20 elements are being decoded instead of being encoded. As such, the binarisation of the syntax element is being reconstructed in the entropy decoder module 202 as the syntax element is decoded. An inverse binariser module 501 generates a mode 520 to indicate use of arithmetic coding or bypass coding for each bin in the bin string. When arithmetic coding is selected, 25 the inverse binariser module 501 further selects a context, such as a context 504, from a context model 503. Again, the context model 503 is a buffer holding an array of contexts. The context model 503 may be stored or configured within the memory 306 or hard disk drive 3 1 0.A selected context505 is used by an arithmetic decoder module 506 to decode bins, such as a bin 507, from the encoded bitstream 113. The bin 507 is used to update the 30 state of the selected context 505, to create an updated selected context 509. The updated selected context 509 is written back to the selected context, such as the context 504, of the context model 503. Accessing the context model 503 for each bin requires a large memory bandwidth. Memories requiring a large memory bandwidth are ideally placed on-chip, however on P038632 / 6,422,486_ / P038632_SpeciAs Filed 24 chip memory consumes large silicon area and hence is only suitable for small memories. Accordingly, reducing the size of the context model 503 is advantageous for low-cost implementation of the entropy coder 202. The bin 507 is also input to the inverse binariser 501 to enable progression of the inverse binarisation process. Progression of the inverse 5 binarisation process causes the entropy decoder 202 to construct the reference picture indices 223, which are output to the motion compensation module 204. Fig. 6 shows a portion of the bitstream 113 containing an example slice 600. The slice 600 contains one or more largest coding units (LCUs), which are sub-divided into coding tree blocks (CTBs). On the leaf node of each coding tree block (CTB) is a 10 prediction unit (PU), such as an encoded prediction unit (PU) 602. The encoded prediction unit (PU) 602 is coded using inter-prediction. The slice 600 contains a slice header 601. The slice header 601 may contain an override to specify the maximum number of reference pictures in the reference picture lists for the slice 600. If the slice 600 is a 'P' slice, one list (list 0) is available for referencing frames in the decoded picture buffer (DPB). If the slice 15 600 is a 'B' slice, two lists (list 0 and list 1) are available. A skip flag 610 indicates the method for determining the motion vectors and reference picture indices for the encoded prediction unit (PU) 602. When the skip flag 610 is true, a mergeidx syntax element is coded which specifies which one of several motion vector and reference picture indices are available from spatially neighbouring prediction units (PUs). When the skipflag 610 is 20 false, a reference picture index 611 (present when the list 0 reference picture list length is greater than one) and a motion vector 612 are coded in the slice 600. For a 'B' slice, a reference picture index 613 (present when the list I reference picture list length is greater than one) and a motion vector 614 are coded in the slice 600. A binarisation 700 performed by the binariser 401 and inverse binariser 501 for a 25 reference picture index will be described with reference to Fig. 7A. In Fig. 7A, the reference picture list contains six (6) frames. Accordingly, the range of ref idx_10 and ref idxl1 (if present) is [0, 5]. For each value of refidx, bin strings are depicted horizontally as a sequence of boxes, ordered from the 0 th bin up to the 4th bin in the longest binarisation (reached when refidx = 4). For each bin in the bin string, the type is either 30 'A' to indicate use of arithmetic coding or 'B' to indicate use of bypass coding. If arithmetic coding is used, a context offset (or a 'ctxldx') is further provided. The context offset provides an offset into a group of contexts, with a context model such as the context models 403, 503, dedicated for modelling the statistical behaviour of bins used to represent refidx. Each bin has a value of either '0' or '1', indicated by the number in each box. P038632 / 6,422,486_1 / P038632_SpeciAs Filed 25 The refidx_10 and refidx_1l syntax elements may share the contexts of a single group. Alternatively, the refidx_10 and refidxl 1 syntax elements may each have a separate, dedicated group of contexts. Using a single group of contexts results in joint probability modelling between reference picture lists for contexts at each offset in the context group. 5 Unique bin strings are required for a decoder to be able to determine the value of the syntax element in the bitstream 113. An example binarisation 701 illustrates the bin string used to represent refidx = 3 when the reference picture list length is six (6). The conventional binarisation 700 is a truncated unary binarisation with arithmetic coding used for all bins. Three contexts are used, with the 0 th, and 1" bins having unique contexts and 10 the 2 nd and above bins sharing a context. The position of each bin in a binarisation (counted as 0 th 1 st 2 nd...) is also known as a 'binldx'. Another binarisation 710 performed by the binariser 401 and the inverse binariser 501 for a reference picture index will be described with reference to Fig. 7B. The nomenclature of Fig. 7B is defined with reference to Fig. 7A. A difference between 15 binarisation 710 and binarisation 700 is that the 2 "d and above bins in binarisation 710 use bypass coding instead of arithmetic coding. Accordingly, the third context is no longer accessed and hence is removed from the context model. The fixed allocation of arithmetic and bypass coding to the bins in the bin string provides a trade-off that enables removing one context from the context model. A drawback of the binaraisation 710 is that accessing 20 reference pictures at later positions in the reference picture list becomes more costly, due to the requirement to code multiple bypass bins. Accessing the reference picture at list index five (5) is particularly costly, requiring three bypass coded bins. Another binarisation 720 performed by the binariser 401 and the inverse binariser 501 for a reference picture index will be described with reference to Fig. 7C. The 25 nomenclature of Fig. 7C is defined with reference to Fig. 7A. A difference between the binarisation 720 and the binarisations 700, 710 is that bypass coding is applied from the 4 h bin and above for the binarisation 720. Bins 0-3 of the binarisation 720 are coded using a truncated unary (TU) code. Bins four (4) and above of the binarisation 720 are coded using a k=0 exponential golomb codeword. Accordingly, no limit is placed on the range of 30 possible values for the reference picture index. Similar, to the binarisations 700 and 710, three contexts are used in the binarisation 720. Fig. 8A shows a binarisation 800 that may be applied by the binariser 401 and the inverse binariser 501 when the length of the reference picture list is four (4). Fig. 8B shows a similar binarisation 810 that may be applied by the binariser 401 and the inverse P038632 / 6,422,486. / P038632_SpeciAs Filed 26 binariser 501 when the length of the reference picture list is six (6). In the binarisations 800 and 810 a rule is applied where the threshold for transition from arithmetic coding to bypass coding occurs at the ith bin, where i = max(2, reference picture list length - 2). This results in the 0 th bin and 1 " bin (if present) being arithmetically coded, whilst any 5 further required bins are bypass coded. For example, when reference picture list length = 4, i=2 and when reference picture list length = 5, i = 3. The constant 2 subtracted from reference picture list length may be increased, to make the transition to bypass coded bins occur earlier in the binarisation. Also, the constant 2 applied to the max operator may be altered, to change the minimum bin index at which any bypass coding will be used. 10 The adaptivity of the binarisations 800 and 810 provides an advantageous trade-off that prevents very long strings of bypass bins being required to access later reference pictures in the reference picture list. Other rules for determining the threshold may also be used, retaining a dependency on the reference picture list length. The binarisation 810 uses three contexts to code the arithmetic bins of the reference 15 picture index binarisations. The third context may be removed, resulting in one context being used for the 0 th bin and a second context being used for the Ist and above bins (until the threshold for using bypass coding is reached). Additionally, the second context may be removed, resulting in one context being used for all arithmetically coded bins in the binarisation 810. When the second context is removed, alternative context indices 20 (indicated in parentheses) are used. Particularly for hardware implementations, the silicon area consumed by on-chip memory is an important factor in the manufacturing cost of the integrated circuit. Accordingly, where it is possible to remove contexts yet have minimal impact on the coding efficiency of the video encoder 100 or the video decoder 200, it is desirable to do so. The binarisations 800, 810, when using the formula i = max(2, 25 reference picture list length - 2), have the property that only the last bin of the binarisation is bypass coded (when reference picture list length exceeds 3). The last bin selects between the last two reference frames, which experiments show for longer reference picture lists (e.g.: when reference picture list length exceeds 3) are approximately equally likely to be selected. Therefore, the last bin is a candidate for bypass coding. 30 Fig. 9A shows a binarisation 900 that may be applied by the binariser 401 and the inverse binariser 501 when the length of the reference picture list is four (4). Fig. 9B shows a binarisation 910 that may be applied when the length of the reference picture list is seven (7). In the binarisations 900 and 910, a rule is applied where the threshold for the transition from arithmetic coding to bypass coding occurs at the ith bin, where i = min (3, P038632 / 6,422,486_1 / P038632_SpeciAs Filed 27 max(2, reference picture list length - 2)). The value three (3) applied to the min (minimum) operator implies that the maximum length of the arithmetically coded portion is 3. However, other threshold values are also possible. The adaptivity of the binarisations 900 and 910 provides an advantageous trade-off that prevents very long strings of bypass 5 bins being required to access later reference pictures in the reference picture list. In the binarisations 900 and 910, remaining bits are a variable length code for the encoder 100 and decoder 200. In particular, the introduced bypass portion is a variable-length codeword. The bypass portion codeword length is determined by the reference picture list length and is sufficient for a unique binary encoding of all remaining reference picture list 10 index values. Unique binary encodings of remaining reference picture list index values result in bin strings with individual bins being closer to equiprobable, which results in improved coding efficiency and therefore may be used for bypass coded bins. Other rules for determining the threshold may also be used, retaining a dependency on the reference picture list length. In other implementations, for a given reference picture list length the 15 remaining bits are a fixed length code for the encoder 100 and decoder 200. The binarisation 910 uses three contexts to code the arithmetic bins of the reference picture index binarisations with a variable length bypass coded portion in the binarisation 910 (i.e., two bins in this example, sufficient to encode reference picture indices from 3-6). The third context may be removed, resulting in one context being used for the 0 'h bin and a 20 second context being used for the 1st and above bins (until the threshold for using bypass coding is reached). As described above, particularly for hardware implementations, the silicon area consumed by on-chip memory is an important factor in the manufacturing cost of the integrated circuit. Accordingly, where it is possible to remove contexts yet have minimal impact on the coding efficiency of the video encoder 100 or the video decoder 25 200, it is desirable to do so. As described above, implementations of the encoder 100 and decoder 200 can realise higher throughput by fetching multiple bypass bins in a single operation. A rearrangement of the bins of the reference picture indices of two reference picture lists (list 0 and list 1) may be applied when coding a 'B' slice. 30 Fig. 10 shows an example encoded prediction unit (PU) 1000 that may be written to the bitstream 113 by the encoder 104 to encode a bi-predicted block in a 'B' slice. Accordingly, for the example of Fig. 10, two reference picture indices, for reference picture lists list 0 and list 1, are encoded. A skip flag 1010 set to '0' indicates that the encoded prediction unit (PU) 1000 does not predict motion vectors from neighbouring P038632 / 6,422,486_ / P038632_SpeciAs Filed 28 merge candidates. An arithmetic reference picture index portion 1011 encodes the arithmetically coded bins of a reference picture index, such as list 0. An arithmetic reference picture index portion 1012 encodes the arithmetically coded bins of a second reference picture index, such as list 1. In the example of Fig. 10, the arithmetically coded 5 bins of a reference picture index are defined with reference to Fig. 8A as the bins having a bin type of 'A' and being included in the binarisation for the refidx value being encoded. A bypass reference picture index portion 1013 encodes the bypass coded bins of a reference picture index, such as list 0. A bypass reference picture index portion 1014 encodes the bypass coded bins of a second reference picture index, such as list 1. 10 Accordingly, remaining (bypass coding) bits of list 0 and list I are concatenated for the decoder 202 (and for the encoder 104). In the example of Fig. 10, the bypass coded bins of a reference picture index are defined with reference to Fig. 8A as the bins having a bin type of 'B' and being included in the binarisation for the refidx value being encoded. In the example of Fig. 10, the reference picture indices in the encoded prediction unit (PU) 1000 15 results in an abutment of the bypass coded bins for list 0 and list 1. As previously discussed, such an arrangement permits implementations to achieve higher throughput processing when parsing reference picture indices. Fig. I lA shows a method I100 for encoding a reference picture index from a stream of video data. The method I 100 may be implemented as one or more code modules 20 of the software application program 333 implementing the encoder 104, the program 333 being resident in the hard disk drive 310 and being controlled its execution by the processor 305. The method 1100 begins at a determine threshold step 1101, where the processor 305 is used for determining a bin coding type threshold for use on the reference picture 25 index and for storing the bin coding type threshold in the memory 306. In particular, the bin coding type threshold is used for transitioning from arithmetic coding to bypass coding in the reference picture index bin string. The bin coding type threshold is a number of bins in a bin string of the reference picture list that use arithmetic coding with any remaining bins of the bit string using bypass coding. The bin coding type threshold may be 30 determined according to the reference picture list length. In one implementation, the bin coding type threshold is set equal to the max(2, reference picture list length - 2), which results in at most one bypass bin being used in the binarisation for a reference picture index and the first bin in the binarisation always using arithmetic coding. The reference picture list length may be based on a received maximum length of the reference picture list. Other P038632 / 6,422,486 1 / P038632_Speci_As Filed 29 relationships between the bin coding type threshold and the reference picture list length are also possible, including non-linear relationships. In other implementations, additional adaptivity may be introduced into the bin coding type threshold using past statistical behaviour of the encoder 100. For example, previous reference picture index values may 5 be used in the determination of the bin coding type threshold. The method 1100 continues at an encode reference picture index step 1102, where the processor 305 is used for encoding a reference picture index in the bitstream 113, using the bin coding threshold to select one of arithmetic and bypass encoding to encode the bin string of the reference picture index. A method 1110 of encoding a reference picture index 10 in the bitstream 113, as executed at step 1102, will now be described with reference to Fig 1 B. The method 1110 may be implemented as one or more code modules of the software application program 333 implementing the encoder 100, the program 333 being resident in the hard disk drive 310 and being controlled its execution by the processor 305. The method 1110 begins with an encode arithmetic portion step 1111, where the 15 entropy encoder module 406, under execution of the processor 305, encodes the arithmetic bins of the binarisation (e.g., 800), where the encoder module 406 is configured for arithmetic encoding. The encoded bins may be stored by the processor 305 within the memory 306. For each bin, the encoder 406 uses a context such as the context 408, selected for each arithmetic bin according to the context specified by the bin position in the 20 binarisation. Example syntax for the encode arithmetic portion step 1 I11 is shown as a syntax element 'refidx_10_arith' and 'refidxlI _arith' in Appendix 2. Then at an encode bypass portion step 1112, the encoder module 406, under execution of the processor 305, encodes the bypass bins (if any) of the binarisation, where the encoder module 406 is configured for bypass encoding. Example syntax for the encode 25 bypass portion step 1112 is shown in the syntax table 'refidx_10_bypass' and 'refidx_ll_bypass' in Appendix 2. The bypass bins may be stored within the memory 306. A method 1200 for decoding a reference picture index from a stream of video data, will be described with reference to Fig. 12A. The reference picture index is configured for 30 selecting a previously decoded frame of video data received at the decoder 202 according to a reference picture list, such as list 0 or list 1. The method 1200 may be implemented as one or more code modules of the software application program 333 implementing the decoder 202, the program 333 being resident in the hard disk drive 310 and being controlled its execution by the processor 305. P038632 / 6,422,486 1 / P038632_SpeciAs Filed 30 The method 1200 begins at a determine threshold step 1201, where the processor 305 is used for determining a bin coding type threshold for use on the reference picture index. The bin coding type threshold may be stored in the memory 306. In particular, the bin coding threshold is used for transitioning from arithmetic coding to bypass coding in 5 the reference picture index bin string. Step 1201 operates in an identical manner to step 1 101 as described above, which is a requirement for the decoder 202 to be able to decode the bitstream 113 produced by the encoder 104. As described above, the bin coding type threshold may be determined according to the reference picture list length. In one implementation, the bin coding type threshold is set equal to the max(2, reference picture 10 list length - 2), which results in at most one bypass bin being used in the binarisation for a reference picture index and the first bin in the binarisation always using arithmetic coding. The reference picture list length may be based on a received maximum length of the reference picture list. Then at a decode reference picture index step 1202, the processor 305 is used for 15 decoding the reference picture index from the bitstream 113, using the bin coding threshold to select one of arithmetic and bypass encoding to decode the bin string of the reference picture index. A method 1210 of decoding a reference picture index from the bitstream 113, as executed at step 1202, will be described with reference to Fig. 12B. The method 1210 may be implemented as one or more code modules of the 20 software application program 333 implementing the decoder 202, the program 333 being resident in the hard disk drive 310 and being controlled in its execution by the processor 305. The method 1210 begins with a decode arithmetic portion step 1211, where the arithmetic bins of the binarisation are decoded using the entropy decoder 506 under execution of the processor 305. The decoded bins may be stored by the processor 305 25 within the memory 306. The entropy decoder 506 is configured for arithmetic decoding. For each bin, the decoder 506 uses a context such as the context 508, selected for each arithmetic bin according to the context specified by the bin position in the binarisation. Example syntax for the decode arithmetic portion step 1211 is shown in the syntax table 'refidx_10_arith' and 'refidxll _arith' in Appendix 2. 30 Then at a decode bypass portion step 1212, the entropy decoder 506, under execution of the processor305, decodes the bypass bins (if any) of the binarisation, where the decoder 506 is configured for bypass encoding. In decoding the reference picture index, the method 1210 decodes bins sequentially, determining the bin value to be either '0' or '1'. Based on the determined bin values, the reference picture index value is P038632 / 6,422,486 1 / P038632_SpeciAs Filed 31 determined by matching the sequence of bin values to a binarisation, such as the binarisation 800. Example syntax for the decode bypass portion step 1212 is shown in the syntax table 'ref idx_10_bypass' and 'ref idx_l _bypass' in Appendix 2. A method 1300 for encoding a plurality of reference picture indices, from a stream 5 of video data, will be described with reference to Fig. 13A. Although the method 1300 is described with two reference picture lists, the method 1300 may also be extended to higher numbers of reference pictures lists. The method 1300 may be implemented as one or more code modules of the software application program 333 implementing the encoder 104. The method 1300 may be applied to binarisations including at least one bypass bin, such as the 10 binarisations 710, 720, 810, 900, 910. The method 1300 may be implemented as one or more code modules of the software application program 333 implementing the decoder 202, the program 333 being resident in the hard disk drive 310 and being controlled its execution by the processor 305. The method 1300 begins at a determine thresholds step 1301, where the processor 15 305 is used for determining a bin coding type threshold for each list, such as list 0 and list 1. The bin coding type threshold may be stored by the processor 305 within the memory 306. Each bin coding type threshold is determined according to the method disclosed above in the determine threshold step 1101. As described above, the bin coding type threshold may be determined according to the reference picture list length. In one 20 implementation, the bin coding type threshold is set equal to the max (2, reference picture list length - 2), which results in at most one bypass bin being used in the binarisation for a reference picture index. The reference picture list length may be based on a received maximum length of the reference picture list. Then at an encode reference picture indices step 1302, the processor 305 is used for 25 encoding the plurality of reference picture indices, using the bin coding threshold to select one of arithmetic and bypass encoding to encode the bin string of each of the reference picture indices. A method 13 10 of encoding a plurality of reference picture indices, as executed at step 1302, will be described with reference to Fig. 13B. The method 1310 may be implemented as one or more code modules of the software application program 333 30 implementing the encoder 104, the program 333 being resident within the hard disk drive 310 and being controlled in its execution by the processor 305. The method 1310 begins at an encode arithmetic portions for 10 and 11 step 1311, where the arithmetic encoder 406, under execution of the processor 305, encodes the arithmetically coded bins for reference picture indices for each of list 0 and list I in P038632 / 6,422,486_1 / P038632_SpeciAs Filed 32 accordance with the method described above in the encode arithmetic portion step 1111. Example syntax for the encode arithmetic portions for 10 and 11 step 1311 is shown in the syntax table 'ref idxcodingarith' in Appendix 2. The encoded bins may be stored by the processor 305 within the memory 306. 5 Then at an encode bypass portions for 10 and 11 step 1312, the processor 305 is used to encode the bypass coded bins (if present) for reference picture indices for each of list 0 and list 1 in accordance with the method disclosed above with reference to the encode bypass portion step 1112. Example syntax for the encode bypass portions for 10 and 11 step 1312 is shown in the syntax table 'refidxcodingbypass' in Appendix 2. 10 A method 1400 for decoding a plurality of reference picture indices from a stream of video data, will be described with reference to Figs. 14A. Although the method 1400 is described with two reference picture lists, the method 1400 may be extended to higher number of reference pictures lists. The method 1400 may be implemented as one or more code modules of the software application program 333 implementing the encoder 104, the 15 program 333 being resident in the hard disk drive 310 and being controlled in its execution by the processor 305. The method 1400 may be applied to binarisations including at least one bypass bin, such as the binarisations 710, 720, 810, 900, 910. The method 1400 begins at a determine thresholds step 1401, where the processor 305 is used for determining a bin coding type threshold for each list, such as list 0 and list 20 1. The determined bin coding type thresholds may be stored by the processor 305 within the memory 306. Each bin coding type threshold is determined according to the method disclosed above in the determine threshold step 1201. As described above, the bin coding type threshold may be determined according to the reference picture list length. In one implementation, the bin coding type threshold is set equal to the max(2, reference picture 25 list length - 2), which results in at most one bypass bin being used in the binarisation for a reference picture index. The reference picture list length may be based on a received maximum length of the reference picture list. Then at a decode reference picture indices step 1402, the processor 305 is used for decoding the plurality of reference picture indices, using the bin coding threshold to select 30 one of arithmetic and bypass encoding to decode the bin string of the reference picture index. The decoded indices may be stored by the processor 305 within the memory 306. A method 1410 of decoding a plurality of reference picture indices, as executed at step 1402 will be described with reference to Fig. 14B. The method 1410 may be implemented as one or more code modules of the software application program 333 P038632 / 6,422,486_1 / P038632_SpeciAs Filed 33 implementing the encoder 104, the program 333 being resident in the hard disk drive 310 and being controlled in its execution by the processor 305. The method 1410 begins at a decode arithmetic portions for 10 and I I step 1411, where arithmetic decoder 506, under execution of the processor 305, decodes the 5 arithmetically coded bins for reference picture indices for each of list 0 and list 1 in accordance with the method described above in the decode arithmetic portion step 1211. Example syntax for the decode arithmetic portions for 10 and II step 1411 is shown in the syntax table 'refidxcodingarith' in Appendix 2. The decoded bins may be stored by the processor 305 within the memory 306. 10 Then at a decode bypass portions for 10 and 11 step 1412, the processor 305 is used to decode the bypass coded bins (if present) for reference picture indices for each of list 0 and list 1 in accordance with the method disclosed above with reference to the encode bypass portion step 1212. Example syntax for the decode bypass portions for 10 and 11 step 1412 is shown in the syntax table 'refidx codingbypass' in Appendix 2. The 15 decoded bypass bins may be stored by the processor 305 within the memory 306. The methods 1300 and 1400 both result in an abutting of bypass coded data from the reference picture indices when multiple reference lists are in use (e.g.: in a 'B' slice). The abutting of the bypass coded data permits higher throughput to be achieved through combining fetch operations for individual bins into a single operation. 20 A slice 1500 encoded by the encoder 100 or decoded by the decoder 200 will be described with reference to Fig. 15. A slice header 1501 indicates that the slice 1500 is either a 'P' or a 'B' slice and therefore, inter-prediction is available. The slice 1500 contains coding units (CUs), such as a coding unit 1502. The coding unit (CU) 1502 contains two bi-predicted prediction units (PUs), specified by a partition mode 1510, 25 although other partition modes may result in a different number of prediction units (PUs) being contained in the coding unit (CU) 1502. The coding unit (CU) 1502 contains arithmetic portions and bypass portions for each reference picture list index arranged such that the bypass portions of all prediction units (PUs) within the coding unit (CU) 1502 are concatenated. Appendix 2 contains exemplary working draft (WD) text illustrating syntax 30 tables resulting in the bypass portions of all reference picture list indices within the coding unit (CU) 1502 being concatenated. An arithmetic portion 1511 includes an arithmetic portion of one or two(one for 'P' slices and one or two for 'B' slices) reference picture list indices for a first prediction unit (PU) in the coding unit (CU) 1502 and an arithmetic portion 1512 includes an arithmetic P038632 / 6,422,486_ / P038632_Speci As Filed 34 portion of one or two reference picture list indices for a second prediction unit (PU) in the coding unit (CU) 1502. A bypass portion 1513 includes a bypass portion (if present) of the one or two reference picture list indices for the first prediction unit (PU) in the coding unit (CU) 1502 and a bypass portion 1514 includes a bypass portion (if present) of the one or 5 two reference picture list indices for the second prediction unit (PU) in the coding unit (CU) 1502. A residual 1515 encodes residual coefficients for each transform unit (TU) in the coding unit (CU) 1502. A binarisation 1600 performed by the binariser 401 and the inverse binariser 501 for a merge index will be described with reference to Fig. 16A. In Fig. 16A, the merge 10 candidate list contains five (5) candidate motion vectors. Accordingly, the range of mergeidx is [0, 4]. For each value of mergeidx, bin strings are depicted horizontally as a sequence of boxes, ordered from the 01h bin up to the 3rdbin in the longest binarisation (reached when mergeidx = 4). For each bin in the bin string, the type is either 'A' to indicate use of arithmetic coding or 'B' to indicate use of bypass coding. If arithmetic 15 coding is used, a context offset is further provided. The context offset provides an offset into a group of contexts, with a context model such as the context models 403, 503, dedicated for modelling the statistical behaviour of bins used to represent refidx. Each bin has a value of either '0' or '1', indicated by the number in each box. Unique bin strings are required for a decoder to be able to determine the value of the syntax element in 20 the bitstream 113. The binarisation 1600 is a truncated unary binarisation with arithmetic coding used for all bins. One context is used for the 0 th bin and the Istand above bins are bypass coded. Such an approach has a drawback that frequent use of merge candidates at higher list indices result in excessively long sequences of bypass coded bins. As the bypass coded bins provide the greatest coding efficiency when the bin value being coded is 25 equiprobable, long sequences of bypass coded bins in truncated unary binarisations is undesirable. A binarisation 1610 performed by the binariser 401 and the inverse binariser 501 for a merge index will be described with reference to Fig. 16B. As in Fig. 16A, the merge candidate list contains five (5) candidate motion vectors and therefore the range of 30 mergeidx is [0, 4]. The binarisation 1610 is a truncated unary binarisation with arithmetic coding used for all bins. Advantageously, one context is used for all bins in the binarisation 1610, resulting in no increase in context model 403, 503 size. The one context provides ajoint probability model of each of the bins in the binarisation 1610. P038632 / 6,422,4861 / P038632_SpeciAs Filed 35 A binarisation 1620 performed by the binariser 401 and the inverse binariser 501 for a merge index will be described with reference to Fig. 16C. As in Fig. 16A, the merge candidate list contains five (5) candidate motion vectors and therefore the range of mergeidx is [0, 4]. The binarisation 1620 introduces a fixed length (2 bit) bypass portion 5 for coding merge index values from 1-4. One context is used for the 0 th bin and the I" and above bins are bypass coded. Advantageously, the longest possible bin-string (for merge index value 4) is three bins long, instead of four bins long. Methods for encoding and decoding the binarisations 1600, 1610 are performed by the binariser 401 and the inverse binariser 501 in a manner similar to the methods 1110, 10 1210 by invoking a truncated unary (TU) binarisation and inverse binarisation process with allocation of each bin in the bin-string according with Fig. 16A and Fig. 16B respectively. The binarisation 1610 includes no bypass bins resulting in the encode bypass portion step 1112 and the decode bypass portion step 1212 being omitted. A binarisation 1620 encodes a merge index and will be described with reference to 15 Fig. 16C. The binarisation 1620 uses a single arithmetic context, and an optional 2-bin bypass portion. Methods for encoding and decoding the binarisations 1620 are performed by the binariser 401 and the inverse binariser 501 in a manner similar to the methods (corresponding to the steps 1110, 1210) by invoking a single arithmetic encode or decode step (corresponding to steps 1 111, 1211) and optional 2-bin bypass encode or decode step 20 (corresponding to steps 1112, 1212) allocation of each bin in the bin-string according with Fig. 16C. Example working draft (WD) text is included in Appendix 1 and Appendix 2. Other arrangements of syntax elements are also possible, that preserve the property that the bypass portions of the affected syntax elements remain concatenated and thus remain 25 within the scope of the invention. INDUSTRIAL APPLICABILITY The arrangements described are applicable to the computer and data processing industries and particularly for the digital signal processing for the encoding a decoding of signals such as video signals. 30 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 P038632 / 6,422,486_1 / P038632_SpeciAs Filed 36 of'. Variations of the word "comprising", such as "comprise" and "comprises" have correspondingly varied meanings. P038632 / 6,422,4861 / P038632_SpeciAs Filed 37 APPENDIX 1 EXAMPLE WORKING DRAFT (WD) TEXT. 5 Further embodiment: Bypass concatenation across refidx_10 and refidx_1 predictionunit( x0, yO, log2CbSize) { Descriptor if(skipflag[ x ][y0]) { if( MaxNumMergeCand> I ) mergeidxl x0 11 yO I ae(v) } else if( PredMode == MODEINTRA) if( PartMode = = PART_2Nx2N &&pcmenabled_flag&& log2CbSize >= Log2MinIPCMCUSize && log2CbSize <= Log2MaxlPCMCUSize) pcmflag ae(v) if( pcm flag) { numsubsequentpcm tu(3) NumPCMBlock = num_subsequent_pcm + I while( !byte_aligned( ) pcmalignment zerobit f(l) pcmsample( xO, yO, log2CbSize) } else { prev intra luma predflag| x0 ][ yO I ae(v) if( previntra_lumapredflag[ x0 ][ yO] ) mpmidxl x0 1 yO I ae(v) Else rem intra lumapredmodel x0 1[ yO I ae(v) intrachromapredmode[ x0 ][ yO ] ae(v) SignalledAsChromaDC = (chroma_predfromlumaenabled_flag ? intrachromaj-red mode[ x0 ][ yO ]= 3 : intra chromajpred mode[ x ][ yO ] == 2) } else { /* MODEINTER */ merge flag xO ][ yO I ae(v) if( mergeflag[ x0 ][ yO] ) if( MaxNumMergeCand> I ) mergeidxl xO 11 yO I ae(v) } else { if( slicetype == B) inter predidcl x0 1[ yO I ae(v) refidxcodingarith( x0, yO) ref idx codingbypass( x0, yO) if( inter_predidc[ x ][ yO] Pred_LI ) { mvdcoding( mvd_l I[ xO ][ yO ][ 0 ], mvd l[ x yO ] 1]) mvp 10 flag x ]| yO I ae(v) if( inter pred idc[ x ][ yO] Pred LO) { P038632 / 6,422,486_1 / P038632_SpeciAs Filed 38 if( mvd_II_zeroflag && inter-pred idc[ x0 J[ yO ] Pred BI) { mvd ll[x0][yO][0]=0 mvd 11[ xO ][y0][ ]= 0 else mvdcoding( mvdll[ x0 ][ yO ][ 0], mvd ll[x0][yO][ l]) mvp Il flagI x0 || y0 I ae(v) Reference index coding ref idx coding arith( x0, yO) { Descriptor if( interpredidc[ x ][ yO ] != Pred_L l&& num ref idx 10 active minus > 0) ref idx_10_arith[ x ][ yO ] ae(v) if( interpredidc[ x ][ yO ] != PredLO && num ref idx Il active minus > 0) ref idx_lIarith[ xO |1 yO I ae(v) } ref idx coding bypass( x0, yO) { Descriptor if( interpredidc[ x0 ][ yO] Pred_L LI&& num ref idx 10 active minus I> 0) ref idx 10 bypass[ xO ][ yO] ae(v) if( inter_predidc[ x0 ][ yO ] != PredLO && num ref idx 11 active minusI > 0) ref idx_ll_bypassl x0 || yO I ae(v) } 5 P038632 / 6,422,486 1 / P038632_SpeciAs Filed 39 APPENDIX 2 Further Example Working Draft (WD) 5 Bypass concatenation across prediction units (PUsO in a coding unit (CU) (uses functions defined in Appendix 1). codingunit( x0, yO, log2CbSize) { Descriptor CurrCbAddrTS = MinCbAddrZS[ x >> Log2MinCbSize [ yO >> Log2MinCbSize ] if( transquantbypass enableflag) { cu transquant bypassflag ae(v) } if( slicetype != I) skip_flag[ xO ][ yO ] ae(v) if( skipflag[ x ][ yO ]) predictionunit( xO, yO , log2CbSize) else { if( slice_type != I) pred_mode_flag ae(v) if( PredMode!= MODEINTRA | log2CbSize = Log2MinCbSize ) partmode ae(v) xl =x0+(( 1 << log2CbSize )>> I) yl yO+(( I << log2CbSize )>> I) x2 = x l - ( ( I << log2CbSize ) >> 2 ) y2 = y I - ( ( I << log2CbSize )>> 2 ) x3 =xl + (( I <<log2CbSize) >>2) y3 l + ((I <<log2CbSize) >>2) if( PartMode = = PART_2Nx2N ) Predictionunit( x0, yO , log2CbSize ) else if( PartMode = = PART_2NxN ) { Predictionunit( xO, yO , log2CbSize ) Predictionunit( xO, yI , log2CbSize ) } else if( PartMode = = PARTNx2N ) { Predictionunit( xO, yO , log2CbSize ) Predictionunit( x l, yO , log2CbSize ) } else if( PartMode = = PART_2NxnU) { Prediction unit( xO, yO , log2CbSize) Predictionunit( xO, y2 , log2CbSize) else if( PartMode == PART_2NxnD) { Prediction unit( x0, yO , log2CbSize) Predictionunit( xO, y3 , log2CbSize) else if( PartMode = = PARTnLx2N) { Prediction unit( x0, yO , log2CbSize) P038632 / 6,422,486_ / P038632_SpeciAs Filed 40 Predictionunit( x2, yO, log2CbSize) } else if( PartMode = = PARTnRx2N) Predictionunit( xO, yO, log2CbSize ) Predictionunit( x3, yO , log2CbSize) } else { /* PARTNxN */ Predictionunit( xO, yO , log2CbSize) Predictionunit( x 1, yO , log2CbSize) Predictionunit( xO, yl , log2CbSize) Prediction unit( x1, y I , log2CbSize) } if( PartMode = = PART_2Nx2N) refidxcodingbypass( xO, yO) else if( PartMode = = PART_2NxN) { ref idxcodingbypass( x0, yO) ref idxcodingbypass( xO, y I ) } else if( PartMode == PARTNx2N){ refidxcodingbypass( x0, yO) ref idxcodingbypass(xl, yO) else if( PartMode == PART_2NxnU ) { ref_idxcodingbypass( x0, y0) refidxcodingbypass( x0, y2 ) else if( PartMode == PART_2NxnD ) { refidxcodingbypass( xO, yO) refidxcodingbypass( xO, y3 ) else if( PartMode == PART nLx2N ) { ref idxcodingbypass( x0, yO) refidxcodingbypass( x2, yO) } else if( PartMode = = PART_nRx2N ) { refidxcodingbypass( x0, yO) ref idx coding bypass( x3, yO) } else (/* PARTNxN */ refidxcodingbypass( x0, yO) refidxcodingbypass( x1, yO) ref idxcodingbypass( x0, yI ) refidxcodingbypass( xl, yl ) } if( !pcmflag) { if( PredMode MODEINTRA && !(PartMode = PART 2Nx2N &&merge flag[xO][yO])) no residual dataflag ae(v) if( !noresidualdataflag) { MaxTrafoDepth = ( PredMode == MODEINTRA ? maxtransform hierarchydepthintra + IntraSplitFlag : max transform hierarchy depth inter) transformtree( x0, yO, xO, yO, x0, yO, log2CbSize, log2CbSize, log2Cb Size, 0, 0) P038632 / 6,422,486_ / P038632_SpeciAs Filed 41 }I _ predictionunit( xO, yO, log2CbSize) { Descriptor if( skipflag[ x0 ][ yO ] ) { if( MaxNumMergeCand> I) mergeidxl xO 11 yO I ae(v) }else if( PredMode = = MODEINTRA) if( PartMode = = PART_2Nx2N &&pcmenabled flag&& log2CbSize >= Log2MinIPCMCUSize && log2CbSize <= Log2MaxIPCMCUSize) pcmflag ae(v) if( pcmflag) { numsubsequentpcm tu(3) NumPCMBlock = numsubsequentpcm + I while( !bytealigned( ) pcmalignment zero bit f(l) pcmsample( x0, yO, log2CbSize) else { prev-intra luma predflagi x0 1[ yO I ae(v) if( previntralumajpredflag[ x0 ][ yO]) mpmidxl xO 11 yO I ae(v) Else rem intra-lumapredmodel xO || yO I ae(v) intrachromapredmode[ x0 ][ yO] ae(v) SignalledAsChromaDC = (chroma_predfromlumaenabled_flag ? intrachroma-predmode[ x0 ][ yO ] = = 3 intra chromapred mode[ x0 ][ yO ] == 2) } else { /* MODEINTER */ mergeflagi xO 11 yO I ae(v) if( mergeflag[ xO ][ yo] ) { if( MaxNumMergeCand> I ) Mergeidx[ x0 J[ yO I ae(v) } else { if( slicetype = B) inter predidel xO 11 yO I ae(v) ref idxcodingarith( xO, yO) if( interpredidc[ xO ][ yO ] != Pred_LI ) { mvdcoding( mvdl1[ x0 ][ yO ][ 0], mvd I[ xO[ yO ][]) mvp 10 flag xO 1[ yO I ae(v) if( inter pred idc[ xO ][ yO] != Pred LO) if( mvd_l l _zeroflag && inter pred idc[ xO ][ y0 = Pred BI) MvdI l[ x0 ][y0 ][ 0 ]0 Mvd ll[ x ][y0 ][ l 1_= 0 P038632 / 6,422,486 1 / P038632_SpeciAs Filed 42 } else mvdcoding( mvd_l l [ xO ][ y0][ 01, mvd l[x][ y ][l] ) mvp 1i flagj xO l yO I ae(v) P038632 / 6,422,486_1 I P038632_SpeciAs Filed

Claims (8)

1. A method of decoding a reference picture index from a stream of video data, the reference picture index being configured for selecting a previously decoded frame of video 5 data received at a decoder according to a long term picture list, the method comprising: determining a reference picture list length based on a received maximum length of the reference picture list; determining, according to the reference picture list length, a bin coding type threshold for use on the reference picture index, the bin coding type threshold being a 10 number of bins in a bin string of the reference picture list that use arithmetic coding with any remaining bins of the bit string using bypass coding; and decoding the reference picture index using the bin coding type threshold to select one of arithmetic and bypass encoding to decode the bin string of the reference picture index. 15

2. The method according to claim 1, wherein remaining bits of list 0 and list 1 are concatenated for the decoder.

3. The method according to claim 1, wherein remaining bits are a fixed length code 20 for the decoder.

4. The method according to claim 1, wherein remaining bits are a variable length code for the decoder. 25 5. A method of encoding a reference picture index from a stream of video data, the reference picture index being configured for selecting a previously decoded frame of video data received at an encoder according to a long term picture list, the method comprising: determining a reference picture list length based on a received maximum length of the reference picture list; 30 determining, according to the reference picture list length, a bin coding type threshold for use on the reference picture index, the bin coding type threshold being a number of bins in a bin string of the reference picture list that use arithmetic coding with any remaining bins of the bit string using bypass coding; and P038632 / 6,422,4861 / P038632_Speci As Filed 44 encoding the reference picture index using the bin coding type threshold to select one of arithmetic and bypass encoding to encode the bin string of the reference picture index.

5

6. The method according to claim 5, wherein remaining bits of reference picture index for list 0 and reference picture list index for list I are concatenated for the encoder.

7. The method according to claim 1, wherein remaining bits are a fixed length code for the encoder. 10

8. The method according to claim 1, wherein remaining bits are a variable length code for the encoder. Dated this 29 June 2012 15 CANON KABUSHIKI KAISHA Patent Attorneys for the Applicant Spruson&Ferguson P038632 / 6,422,486_1 / P038632_Speci_As Filed