AU2012203864A1 - Method, apparatus and system for encoding and decoding a sample adaptive offset data of encoded video data - Google Patents

Abstract

-50 Abstract METHOD, APPARATUS AND SYSTEM FOR ENCODING AND DECODING A SAMPLE ADAPTIVE OFFSET DATA OF ENCODED VIDEO DATA Disclosed is a method of determining a plurality of syntax elements of sample adaptive offset information (242;4701;4801) for a coding unit (4700;4800) from a stream (113) of encoded video data received by a video decoder. The method decodes an arithmetically encoded first portion (4703-4705; 4803-4805) of the sample adaptive offset 10 information (4701;4801) from the stream of video data, the first portion being a contiguous collection of a subset (4703-4705;4803-4805) of the syntax elements including syntax elements for each colour space channel of the video data. The method decode a bypass encoded second portion (4706-4708;4806-4808) of the sample adaptive offset information from the stream of video data, the second portion being a contiguous collection of a second 15 subset (4706-4708;4806-4808) of the syntax elements including syntax element for each colour space channel. The method then determines the plurality of syntax elements from the decoded first and second portions of the sample adaptive offset information. 6432252_1 P036645_specilodge coD - EE C)C (NY cN E-u 6430288_1 P0 38645fi gsl od ge

Description

S&F Ref: P038645 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): Volodymyr Kolesnikov 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 a sample adaptive offset data of encoded video data The following statement is a full description of this invention, including the best niethod of performing it known to me/us: 5845c(6432164_1) - 1 METHOD, APPARATUS AND SYSTEM FOR ENCODING AND DECODING A SAMPLE ADAPTIVE OFFSET DATA OF ENCODED VIDEO DATA 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 sample adaptive 5 offset data of video data. 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 (SG16/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/International Electrotechnical Commission Joint Technical Committee 1 / Subcommittee 29 / Working Group 11 (ISO/IEC JTC1/SC29/WG1 1), 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 a 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 and ITU-T H.263. The new video coding standard under development has been named 25 "high efficiency video coding (HEVC)". The Joint Collaborative Team on Video Coding JCT-VC is also considering implementation challenges arising from technology proposed for high efficiency video coding (HEVC) that create difficulties when scaling implementations of the standard to operate at high resolutions or high frame rates. The H.264/MPEG-4 AVC video coding standard presents difficulties for achieving 30 high compression efficiency when coding residual coefficients to represent video data. Video data is formed by a sequence of frames, with each frame having a two dimensional array of samples. Typically, frames include one luminance (luma) and two 6432252_1 P038645_specilodge -2 chrominance (chroma) channels. Colour information is typically represented using a colour space such as YUV, with Y being the luma channel and UV being two chroma channels. A colour space such as YUV gives the advantage that the majority of frame content is contained in the luma channels and a relatively smaller amount of content stored 5 in the UV channels is sufficient to reconstruct a colour frame. The chroma channels may also be down-sampled to a lower spatial resolution with negligible perceptual quality loss. A commonly used chroma format known as 4:2:0 results in each chroma channel having half the vertical and horizontal resolution. Each frame is decomposed into an array of largest coding units (LCUs). The largest coding units (LCUs) have a fixed size, with 10 edge dimensions being a power of two and having equal width and height, such as 64 luma samples. A coding tree 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 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 15 coding unit (SCU) size is reached, enabling coding units (CUs) to be defined down to a minimum supported size. The recursive subdivision of a largest coding unit, into a hierarchy of coding units, has a quad-tree structure and is referred to as the coding tree. The subdivision process is encoded in a communications bit-stream as a sequence of flags, coded as bins. Coding units therefore have a square shape. 20 A set of coding units exist in a coding tree that are not further sub-divided, occupying leaf nodes of the coding tree. Transform trees exist at the coding units. A transform tree may further decompose a coding unit using a quad-tree structure as used for the coding tree. At leaf nodes of the transform tree, residual data is encoded using transform units (TUs). In contrast to the coding tree, the transform tree may subdivide 25 coding units into transform units having a non-square shape. Further, the transform tree structure does not require that transform units (TUs) occupy all of the area provided by the parent coding unit. Each coding unit at 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 prediction 30 unit (PU) contains a prediction of a portion of input video frame data, derived by applying an intra-prediction or an inter-prediction process. Several methods may be used for coding prediction units (PUs) within a coding unit (CU). A single prediction unit (PU) may occupy an entire area of a coding unit (CU), or the coding unit (CU) may be split into two equal-sized rectangular prediction units 6432252_1 P038645_specilodge -3 (PUs), either horizontally or vertically. Additionally, the coding units (CU) may be split into four equal-sized square prediction units (PUs). A video encoder compresses the video data into a bit-stream by converting the video data into a sequence of syntax elements. A context adaptive binary arithmetic 5 coding (CABAC) scheme is defined within the high efficiency video coding (HEVC) standard under development, using an identical arithmetic coding scheme as to that defined in the 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 10 bin is either bypass-coded or arithmetically coded. Bypass coding is used where the bin is equally likely to be 0 or 1. In this case, there is no further compression achievable. Arithmetic coding is used for bins which have an unequal probability distribution. Each arithmetically coded bin is associated with information known as a 'context'. Contexts contain a likely bin value (the 'valMPS') and a probability state, an integer which maps to 15 an estimated probability of the likely bin value. 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. In a video encoder or video decoder, as separate context information is available for each bin, context selection for bins provides a means to improve coding efficiency. In 20 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 to determine the optimal context. 25 SUMMARY According to one aspect of the present disclosure, there is provided a method of determining a plurality of syntax elements of sample adaptive offset information for a coding unit from a stream of encoded video data received by a video decoder, the method 30 comprising: decoding an arithmetically encoded first portion of the sample adaptive offset information from the stream of video data, the first portion being a contiguous collection of a subset of the syntax elements including syntax elements for each colour space channel of the video data; decoding a bypass encoded second portion of the sample adaptive offset 6432252_1 P036645_specilodge -4 information from the stream of video data, the second portion being a contiguous collection of a second subset of the syntax elements including syntax element for each colour space channel; and determining the plurality of syntax elements from the decoded first and second portions of the sample adaptive offset information. 5 Desirably at least one of the syntax elements of the sample adaptive offset information has data encoded in both the first and second portions. For example the at least one syntax element is a sample adaptive offset type index. Preferably the coding unit is a largest coding unit. Advantageously the first and second subsets contain all of the plurality of syntax 10 elements. Also the colour space channels typically include the Y, U and V channels. According to another aspect of the present disclosure, there is provided a method of decoding sample adaptive offset type index data from a received stream of encoded video data received by a video decoder. The method determines an arithmetically encoded first 15 portion of a sample adaptive offset type index value from the stream of video data. The method determines a bypass encoded second portion of the sample adaptive offset type index value when the first portion indicates that the second portion will be present in the stream of video data. The method decodes the sample adaptive offset type index from a combination of the decoded first and second portions of the sample adaptive offset type 20 index values. The sample adaptive offset type index data are used to select one of a plurality of offsets in video decoding. Preferably the second portion has a fixed length. The length of the second portion can be determined by the first portion. Also, the decoding may comprise decoding a 0 from the first portion to give a sample adaptive offset type index value of 0, and decoding a 25 1 from the first portion to determine the presence of the second portion having a binary value, said decoding then comprising decoding the binary value to give a sample adaptive offset type index value that is an integer and not 0. For example, when the binary value is in the range 000 to 111, and the decoded sample adaptive offset type index value is in the range I to 5. 30 In another implementation the second portion has a variable length. In another implementation the first portion comprises multiple bits and a setting of one of those bits indicates the presence of the second portion. Also disclosed is a method encoding sample adaptive offset type index valueinto a stream of encoded video data for transmission from a video encoder. This method 6432252_1 P038645_specilodge -5 comprises determining whether the sample adaptive offset type index value is a most probable value, and binarising a first binary value to an arithmetically coded first portion of a binarised sample adaptive offset type index value. The method also binarises , where the sample adaptive offset type index value is not the most probable value, a second binary 5 value to the arithmetically coded first portion of the binarised sample adaptive offset type index value, and a unique binary code, dependent on the sample adaptive offset type index value, to a bypass encoded second portion of the binarised sample adaptive offset type index value such that the first portion indicates that the second portion will be present in the stream of encoded video data. The method then encodes the binarised sample adaptive 10 offset type index value into the stream of encoded video data. Other aspects are also disclosed. BRIEF DESCRIPTION OF THE DRAWINGS At least one embodiment of the present invention will be described with reference 15 to the drawings, in which: Fig. 1 is a schematic block diagram showing functional modules of a video encoder; Fig. 2 is a schematic block diagram showing functional modules of a video decoder; 20 Figs. 3A and 3B form a schematic block diagram of a general purpose computer system upon which the encoder and decoder of Figs. 1 and 2, respectively, may be practiced; Fig. 4A is a schematic representation of a largest coding unit (LCU) structure using a binarisation scheme 500 of Fig. 5A; 25 Fig. 4B is a schematic representation of an LCU structure using binarisation 500 with concatenated bypass bins; Fig. 4C is a schematic representation of an LCU structure using a binarisation scheme 520 of Fig. 5B; Fig. 4D is a schematic representation of an LCU structure using binarisation 30 scheme 540 of Fig. 5C; Fig. 4E is a schematic representation of an LCU structure using the binarisation scheme 540 with concatenated bypass bins; Fig. 4F is a schematic representation of an LCU structure using a binarisation scheme 560 of Fig. 5D; 6432252_1 P038645_specilodge -6 Fig. 4G is a schematic representation of an LCU structure using a binarisation scheme 580 of Fig. 5E; Fig. 4H is a schematic representation of an LCU structure using the binarisation scheme 580 with concatenated bypass bins; 5 Fig. 41 is a schematic representation of an LCU structure using a concatenated layout of sao-mergejleft-flag and saomergetupjflag elements; Fig. 4J is a schematic representation of an LCU structure using a layout where all arithmetically coded SAO syntax elements precede any bypass SAO syntax elements per LCU and the bypass-coded data is stored separately for each channel; 10 Fig. 4K is a schematic representation of an LCU structure using a layout where all arithmetically coded SAO syntax elements precede any bypass SAO syntax elements per LCU and the bypass-coded data is stored jointly across the three channels; Fig. 5A is structure diagram of the binarisation scheme 500; Fig. 5B is structure diagram of the binarisation scheme 520; 15 Fig. 5C is structure diagram of the binarisation scheme 540; Fig. 5D is structure diagram of the binarisation scheme 560; Fig. 5E is structure diagram of the binarisation scheme 580; Fig. 6A is a flow diagram of an LCU encoder; Fig. 6B is a flow diagram of an LCU SAO information encoder; 20 Fig. 6C is a flow diagram of saomergeleftflag and saomergeup.flag syntax elements encoder; Fig. 6D is a flow diagram of saotypejidx syntax element encoder; Fig. 6E is a flow diagram of an LCU SAO information encoder; Fig. 6F is a flow diagram of saomergeleft-flag syntax elements encoder; 25 Fig. 6G is a flow diagram of saomerge-up-flag syntax elements encoder; Fig. 6H is a flow diagram of saotypejidx syntax element encoder; Fig. 61 is a flow diagram of saotypejidx syntax element encoder; Fig. 6J(1) is a flow diagram of the binarisation process for binarisation scheme 500; Fig. 6J(2) is a flow diagram of the binarisation process for binarisation scheme 540; 30 Fig. 6K is a flow diagram of a binarisation process for the binarisation scheme 580; Fig. 6L(1) is a flow diagram of a binarisation process for binarisation scheme 560; Fig. 6L(2) is a flow diagrams of a binarisation process for binarisation scheme 520; Fig. 6M is a flow diagram of an LCU SAO information encoder; Fig. 6N is a flow diagram of an LCU SAO information encoder; 6432252_1 P038645_specilodge -7 Fig. 7A is a flow diagram of an LCU decoder; Fig. 7B is a flow diagram of an LCU SAO information decoder; Fig. 7C is a flow diagram of saomergeleft-flag and saomergetup-flag syntax elements decoder; 5 Fig. 7D is a flow diagram of saotypejidx syntax element decoder; Fig. 7E is a flow diagram of an LCU SAO information decoder; Fig. 7F is a flow diagram of saomergeleft-flag syntax elements decoder; Fig. 7G is a flow diagram of saomergeup-flag syntax elements decoder; Fig. 7H is a flow diagram of saotypejidx syntax element decoder; 10 Fig. 71 is a flow diagram of saotypejidx syntax element decoder; Fig. 7J(1) is a flow diagram of a decoding and de-binarisation process for the binarisation scheme 500; Fig. 7J(2) is a flow diagram of a decoding and de-binarisation process for the binarisation scheme 540; 15 Fig. 7K is a flow diagram of a decoding and de-binarisation process for the binarisation scheme 580; Fig. 7L(1) is a flow diagram of decoding and de-binarisation process for the binarisation scheme 560; Fig. 7L(2) is a flow diagram of decoding and de-binarisation process for the 20 binarisation scheme 520; Figs. 7M(1) and 7M(2) are flow diagrams of decoding and de-binarisation processes for the binarisation scheme 500; Figs. 7N(1) and 7N(2) are flow diagrams of the decoding and de-binarisation processes for the binarisation scheme 540; 25 Figs. 70 and 7P are flow diagrams of the decoding and de-binarisation processes respectively for the binarisation scheme 580; Fig. 7Q is a flow diagram of an LCU SAO information decoder; and Fig. 7R is a flow diagram of an LCU SAO information decoder. 30 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 intention appears. 6432252_1 P038645_specilodge -8 At each transform unit (TU), residual coefficient data may be encoded into a bit stream. Each "residual coefficient" is a number representing image characteristics within a transform unit in the frequency (DCT) domain and occupying a unique location within the transform unit. A transform unit is a block of residual data samples that may be 5 transformed between the spatial and the frequency domains. In the frequency domain, the transform unit (TU) encodes the residual data samples as residual coefficient data. Side dimensions of transform units are sized in powers of two (2), ranging from 4 samples to 32 samples for a "Luma" colour space channel, and 2 to 16 samples for a "Chroma" colour space channel. The leaf nodes of the transform unit (TU) tree may contain either a 10 transform unit (TU) or nothing at all, in the case where no residual coefficient data is required. As the spatial representation of the transform unit is a two-dimensional array of residual data samples, as described in detail below, a frequency domain representation resulting from a transform, such as a modified discrete cosine transform (DCT), is also a 15 two-dimensional array of residual coefficients. The spectral characteristics of typical sample data within a transform unit (TU) are such that the frequency domain representation is more compact than the spatial representation. Further, the predominance of lower-frequency spectral information typical in a transform unit (TU) results in a clustering of larger-valued residual coefficients towards the upper-left of the transform unit 20 (TU), where low-frequency residual coefficients are represented. Modified discrete cosine transforms (DCTs) or modified discrete sine transforms (DSTs) may be used to implement the residual transform. Implementations of the residual transform are configured to support each required transform unit (TU) size. In a video encoder, the residual coefficients from the residual transform are scaled and quantised. 25 The scaling and quantisation reduces the magnitude of the residual coefficients, reducing the size of the data coded into the bit-stream at the cost of reducing the image quality. After performing the residual transform, a quantization process is performed. The purpose of the quantization process is to achieve a higher compression ratio by reducing the precision of the magnitude of the residual coefficients. This reduction in magnitude 30 precision is a lossy process and thus has an impact on visual quality. The level of precision reduction is controlled by a quantization parameter (QP). The higher the value of the parameter the more visual quality is affected. After quantization, in some video coding arrangements, a sample adaptive offset (SAO) filtering is applied to the frame data and SAO offset data collected by the encoder. 6432252_1 P038645_specilodge -9 SAO data contains information about differences in pixel value distribution between the original image and image reconstructed after quantization. SAO data is then binarized, encoded and transferred to decoder. The decoder may use SAO data to improve visual and objective quality of the reconstructed frame. 5 The high efficiency video coding (HEVC) standard under development is seeking to achieve a high efficiency compression of video data. Estimation and statistical data analysis may be used to achieve high efficiency compression of video data. The high efficiency video coding (HEVC) standard under development is seeking to encode or decode video data at high bit-rates. The context adaptive binary arithmetic coding 10 (CABAC) scheme employed in the high efficiency video coding (HEVC) standard under development supports an 'equal probability' mode of operation referred to as 'bypass coding'. In this mode, a bin is not associated with a context from the context model, and so there is no context model update step. In such a mode, multiple adjacent bins may be read from a bit-stream in parallel, provided each bin is bypass coded which increases 15 throughput. For example, hardware implementations may write/read groups of adjacent bypass coded data in parallel to increase the throughput of encoding/decoding the bit stream. One aspect of binarisation is selection of contexts to use for coding syntax elements corresponding to individual flags. One flag may use more than one context. Determining 20 which context should be used for a particular instance of a flag depends on other already available information and is known as 'context modelling'. Context modelling is a process whereby a context that most accurately represents the statistical properties of the present instance of the flag is selected. For example, frequently the value of a flag is influenced by the values of neighbouring instances of the same flag, in which case a context can be 25 selected based on the values of neighbouring instances of the flag. Due to the majority of frame information being contained in the luma channel, context modelling frequently uses separate contexts for the luma channel versus the chroma channels. However, contexts are typically shared between chroma channels, as the statistical properties of the two chroma channels are relatively similar. 30 The high efficiency video coding (HEVC) standard under development is seeking to achieve a high efficiency compression of video data. Estimation and statistical data analysis may be used to achieve high efficiency compression of video data. The high efficiency video coding (HEVC) standard under development is seeking to encode or decode video data at high bit-rates. The context adaptive binary arithmetic coding 6432252_1 P038645_specilodge - 10 (CABAC) scheme employed in the high efficiency video coding (HEVC) standard under development supports an 'equal probability' mode of operation referred to as 'bypass coding'. In this mode, a bin is not associated with a context from the context model, and so there is no context model update step. In such a mode, multiple adjacent bins may be 5 read from a bit-stream in parallel, provided each bin is bypass coded which increases throughput. For example, hardware implementations may write/read groups of adjacent bypass coded data in parallel to increase the throughput of encoding/decoding the bit stream. Fig. 1 is a schematic block diagram showing functional modules of a video encoder 10 100 according to the present disclosure. Fig. 2 is a schematic block diagram showing functional modules of a corresponding video decoder 200 according to the present disclosure. 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 various functional modules may be implemented by dedicated hardware within the computer 15 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; input devices such as a keyboard 302, a mouse pointer device 303, a scanner 326, a 20 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 320 may be a wide-area network (WAN), such as the Internet, a cellular 25 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 communications network 320. 30 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 (1/0) interfaces including: an audio video interface 307 that couples to the video display 314, loudspeakers 317 and 6432252_1 P038645_specilodge - 11 microphone 380; an 1/0 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, 5 for example within the interface 308. The computer module 301 also has a local network interface 311, 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 network 320 via a connection 324, which would typically include a so-called "firewall" 10 device or device of similar functionality. The local network interface 311 may comprise an EthernetTm circuit card, a Bluetooth" wireless arrangement or an IEEE 802.11 wireless arrangement; however, numerous other types of interfaces may be practiced for the interface 311. The 1/0 interfaces 308 and 313 may afford either or both of serial and parallel 15 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 used. An optical disk drive 312 is typically provided to act as a non-volatile source of 20 data. Portable memory devices, such optical disks (e.g. CD-ROM, DVD, Blu-ray Dise "', 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 encoded, or, with the display 314, a destination for decoded video data to be stored or 25 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 processor 305 is coupled to the system bus 304 using a connection 318. Likewise, the 30 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 Mac"M or alike computer systems. 6432252_1 P038645_specilodge - 12 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 5 300. In particular, the encoder 100, the decoder 200 and the steps of the described methods may be 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 10 corresponding code modules performs the described methods and a second part and the corresponding code modules manage a user interface between the first part and the user. The software 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. 15 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 20 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 25 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 30 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 6432252_1 P038645_specilodge - 13 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 5 including e-mail transmissions and information recorded on Websites and the like. 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 10 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. 15 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 20 (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 25 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 30 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. 6432252_1 P038645_specilodge - 14 The operating system 353 manages the memory 334 (309, 306) to ensure that each 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 5 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 (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 10 including a control unit 339, an arithmetic logic unit (ALU) 340, and a local or internal 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 15 the system bus 304, using a connection 318. The memory 334 is coupled to the bus 304 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 20 data 332 are stored in memory locations 328, 329, 330 and 335, 336, 337, respectively. 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 25 depicted by the instruction segments shown in the memory locations 328 and 329. 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 30 devices 302, 303, data received from an external source across one of the 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. 6432252_1 P038645_specilodge - 15 The encoder 100, the decoder 200 and the described methods use input 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 5 memory locations 362, 363, 364. Intermediate variables 358 may be stored in memory locations 359, 360, 366 and 367. 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 10 every instruction in the instruction set making up the program 333. Each fetch, decode, 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 15 has been fetched; and (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 20 stores or writes a value to a memory location 332. Each step or sub-process in the processes to be described is associated with one or more segments of the program 333 and is typically 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 25 the noted segments of the program 333. The encoder 100, the decoder 200 and the described methods may alternatively be implemented in dedicated hardware such as one or more integrated circuits performing the functions or sub functions of the described methods. Such dedicated hardware may include graphic processors, digital signal processors, application specific integrated circuits 30 (ASICs), field programmable gate arrays (FPGAs) or one or more microprocessors and associated memories. As described above, the video encoder 100 may be implemented as one or more software code modules of the software application program 333 resident on the hard disk drive 310 and being controlled in its execution by the processor 305. In particular the 6432252_1 P038645_specilodge - 16 video encoder 100 comprises modules 102 to 112, 114, 115 and 151 which may each be implemented as one or more software code modules of the software application program 333. Although the video encoder 100 of Fig. 1 is an example of a high efficiency video 5 coding (HEVC) video decoding pipeline, processing stages performed by the modules 102 to 112, 114, 115 and 151 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 luminance and chrominance samples. The video encoder 100 divides each frame of the frame data 101 into hierarchical sets of coding units (CUs) which 10 may be represented, for example, as a coding unit (CU) tree. The video encoder 100 operates by outputting, from a multiplexer module 110, an array of predicted data samples known as a prediction unit (PU) 120. A difference module 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 15 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 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 20 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 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. 25 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 rescaled versions of the residual coefficients 126. The residual coefficients 126 are also taken as input to an entropy encoder module 104 which encodes the residual coefficients in an encoded bit-stream 113. 30 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 an inverse transform module 106. The inverse transform module 106 performs an inverse transform from the frequency domain to the spatial domain to produce a spatial-domain 6432252_1 P038645_specilodge - 17 representation 130 of the resealed transform coefficients 128 identical to a spatial domain representation that is produced at a decoder. A motion estimation module 107 produces motion vectors 132 by comparing the frame data 101 with previous frame data stored in a frame buffer module 112 configured 5 within the memory 306. The motion vectors 132 are then 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 also passed as syntax elements to the entropy encoder module 104 for coding in the encoded bit 10 stream 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. Prediction units (PUs) may be coded using intra-prediction or inter-prediction 15 methods. The decision as to whether to use intra-prediction or inter-prediction is made according to a rate-distortion trade-off between desired bit-rate of the resulting encoded bit-stream 113 and the amount of image quality distortion introduced by either the intra prediction or inter-prediction method. If intra-prediction is used, one intra-prediction mode is selected from a set of possible modes, also according to a rate-distortion trade-off. 20 One intra-prediction mode is selected for each prediction unit. The multiplexer module 110 selects either the intra-predicted reference samples 136 from the intra-frame prediction module 109 or the inter-predicted reference samples 134 from the motion compensation block 108, depending on a current prediction mode 142, determined by control logic not illustrated but well-known in the art. The 25 prediction mode 142 is also provided to the entropy encoder 104 and as such is used to determine or otherwise establish the scan order of transform units as will be described. Inter-frame prediction uses only a diagonal scan order, whereas intra-frame prediction may use the diagonal scan, a horizontal scan or a vertical scan order. The summation module 114 produces a sum 138 that is input to a de-blocking filter 30 module 111. The de-blocking filter module 111 performs filtering along block boundaries, producing de-blocked samples 153 which, together with the input frame data 101, are input to a sample adaptive offset (SAO) filter module 151. The SAO filter module 151 performs filtering inside the block, producing SAO filtered samples 140 and SAO offset data 152. The filtered samples 140 are written to the frame buffer module 112 configured within the 6432252_1 P038645_specilodge - 18 memory 306. The SAO offset data 152 is passed to the entropy encoder module 104 where the data 152 is entropy encoded into the bitstream 113 as discussed below. The frame buffer module 112 is a buffer with sufficient capacity to hold data from multiple past frames for future reference. 5 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 difference provides a spatial representation of the residual coefficients of the transform unit (TU). The residual coefficients of a transform unit (TU) are converted to the two 10 dimensional significance map. The significance map of the residual coefficients in the transform unit (TU) is then scanned in a particular order, known as a scan order, to form a one-dimensional list of flag values, called a list of significant coefficient flags. The scan order may be described or otherwise specified by a scan pattern, such as that received with the prediction mode 142 15 from the intra-prediction module 109. The scan pattern may be horizontal, vertical, diagonal or zig-zag. As described above, the video encoder 100 also comprises an entropy encoder module 104 that implements an entropy encoding method. The entropy encoder module 104 produces syntax elements from incoming residual coefficient data (or residual 20 coefficients) 126 received from the scale and quantise module 103 and the SAO data 152 received from the SAO module 151. The entropy encoder module 104 outputs encoded bit-stream 113 and will be described in more detail below. For the high efficiency video coding (HEVC) standard under development, the encoded bit-stream 113 is delineated into network abstraction layer (NAL) units. Each slice of a frame is contained in one NAL 25 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 development supports context adaptive binary arithmetic coding (CABAC), a variant of context adaptive binary arithmetic coding (CABAC) found in H.264/MPEG-4 AVC. An 30 alternative entropy coding scheme is known as the probability interval partitioning entropy (PIPE) coder. For the video encoder 100 supporting multiple video coding methods, one of the 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 6432252_1 P038645_specilodge -19 module 104 writes the encoded bit-stream 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 per frame reduces overhead associated with delineating each slice boundary. However, dividing the frame into multiple slices is also possible. 5 The video decoder 200 of Fig. 2 may be implemented as one or more software code modules of the software application program 333 resident on the hard disk drive 310 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. Although the video 10 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 bit-stream, such as the encoded bit-stream 113, is received by the 15 video decoder 200. The encoded bit-stream 113 may be read from memory 306, the hard disk drive 310, a CD-ROM, a Blu-ray M disk or other computer readable storage medium. Alternatively the encoded bit-stream 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 bit-stream 113 contains encoded syntax elements representing frame data to be 20 decoded. The encoded bit-stream 113 is input to an entropy decoder module 202 which extracts the syntax elements 220 and SAO offset data 242 from the encoded bit-stream 113 and passes the values of the syntax elements 220 to other blocks in the video decoder 200. There may be multiple entropy decoding methods implemented in the entropy decoder 25 module 202, such as those 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 syntax element data 222 representing motion vector information is passed to a motion compensation module 204. The inverse scale and transform module 203 performs inverse scaling on the residual coefficient data to create 30 reconstructed transform coefficients. The module 203 then performs an inverse 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. 6432252_1 P038645_specilodge -20 The motion compensation module 204 uses the motion vector data 222 from entropy decoder module 202, combined with previous frame data 226 from a frame buffer block 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. 5 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 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 10 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 bit-stream 113. The array of samples 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 15 each of a de-blocking 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 receives an intra-frame prediction I inter-frame prediction selection signal from the entropy decoder 202. The de blocking filter module 207 performs filtering along data block boundaries to smooth 20 artefacts visible along the data block boundaries. The output of the de-blocking filter module 207 together with the SAO offset data 242 from the entropy decoder 202 is input to a SAO filter module 241. The SAO filter module 241 performs filtering inside the block using the SAO offset data 242 to improve both visual and objective quality of the image. The output 244 of the SAO filter module 241 is written to the frame buffer module 208 25 configured within the memory 306. The frame buffer module 208 provides sufficient storage to hold multiple decoded frames for future reference. Decoded frames 209 are also output from the frame buffer module 208. SAO data 242 for the luminance and two chrominance channels in the stream 113 includes the following syntax elements: saomergejleft-flag, saomerge-up-flag, 30 saotypeidx, saobandposition, saooffsetabs and saooffset-sign. Saomergeleft-flag is a binary value and is present in the stream 113 only if the current LCU is not on the left-most position in the frame otherwise saomergejleft-flag is assumed to be zero. The saomergeleft-flag is coded on a per LCU and per colour channel basis and indicates the derivation of the sao-typeidx, sao-bandposition and 6432252_1 P038645_specilodge -21 saooffsetabs elements the from left neighbour LCU. Syntactically, the saomergeleftflag is a binary flag such that: Table 1 sao-mergeleft-flag Meaning 0 Not derive from left neighbour LCU I Derive from left neighbour LCU 5 Sao-mergetup-flag is a binary value and is present in the stream 113 only if the value of saomergejleft-flag is zero and the current LCU is not on the topmost position in the frame otherwise saomergetup-flag is assumed to be zero. Syntax element saojtypejidx, representing sample adaptive offset type index data, is an integer value in range zero to five inclusive and is present in the stream 113 only if 10 saomergeleft-flag and saomergetup-flag values are both zero, otherwise sao-typejidx value is assumed to be zero. Saojtypeidx indicates the edge offset type of the current coding tree block, and is coded on a per CU and per channel basis, and describes the following: Table 2 saojtype idx Edge type 0 Not applied 1 0-degree edge 2 90-degree edge 3 135-degree edge 4 45-degree edge 5 Band 15 Traditional video coding approaches use unary CABAC coding having two (2) context models and at worst case six (6) CABAC bins and the following coding for saotypeidx: Table 3 saojtype idx value unary code 0 0 1 10 2 110 3 1110 6432252_1 P038645_specilodge - 22 4 11110 5 111110 In the above unary coding, the first bin is encoded using the first context model, and all other bins are encoded using the second context model. Syntax element saobandposition is an integer value and is present in the stream 5 only if sao-typejidx value equals five. Syntax element saooffsetabs is a sequence of four integer values and is present in the stream only if the saojtypeidx value is not equal to zero. Syntax element saooffset-sign is a sequence of four integer values and is present in the stream 113 only if saotypejidx value equals five. 10 The inventors have determined that problems exist with binarisation of the SAO syntax elements. Saotypejidx binarisation is suboptimal - unary coding is useful where the value can have an unknown range of magnitudes, whereas truncated unary coding is more efficient where the maximum possible range of magnitudes is known. The inventors have also determined that the value of 0 has probability > 0.9, and that other values do not 15 significantly influence coding efficiency. Further, experiments by the inventors have shown that the context assignment of the saomergeleft-flag is also suboptimal. Context reduction can lead to coding gains, generally due to correlations between channels. According to one aspect of the present disclosure, the inventors propose an alternate binarisation approach for the saotypejidx element, such as: 20 Table 4 saojtypeidfx value Coding 0 0 1 1000 2 1100 3 1010 4 1001 5 1111 According to this coding, saotypeidx syntax elements which belong to the same LCU are merged, so that CABAC and bypass bins are not interleaved. Also in this coding the first bit represents a single CABAC bin, being an arithmetically encoded portion, and 25 the following bits represent bypass encoded data of corresponding bypass bins. For the saomergeleft-flag, a single context is shared between all channels, and thus the number 6432252_1 P038645_specilodge - 23 of context models is reduced from 3 to 1. Preliminary experiments by the inventors have shown this affords a coding gain of -0.1% in random access test conditions, 0.0% in all intra-test conditions. According to this revised binarisation, in the worst case the number of CABAC bins is reduced from 3 to 1, and one redundant context is removed, thus 5 providing for improved coding efficiency. Preliminary experiments by the inventors show no coding loss. Variations of this coding approach are also described. A binarisation scheme 500 for syntax element saotypejidx is described below with the reference to Fig. 5A. The binarisation scheme 500 is one variation of that provided in Table 4, appreciating that when three bits (giving eight options) are used to 10 encode five values, three of the available options will not be used. As such, the approach of Table 4 may have up to 6670 (=8*7*6*5*4) variations of which the scheme 500 is but one. The binarisation scheme 500 includes an arithmetically encoded portion 501 and optional bypass-encoded portion 502. Portion 501 is formed of one binary element 503. 15 The binary element 503 is assigned value "0" for one of the binarised values and "1" for all other values. Usually the value "0" is assigned to the element which has the highest estimated probability. Portion 502 is present only if the value of element 503 is "1". Portion 502 is formed of three bypass-encoded binary elements 504, 505, 506. The binary elements 504, 505, 506 are assigned a unique three bit binary value for each binarised 20 value which has element 503 equal to "I". Binary elements 503, 504, 505, 506 may be stored in the stream 113 either adjacently one after another or be interleaved with other syntax elements. An exemplary binarisation 510 for saotypejidx implements the binarisation scheme 500. As seen, the example 510 includes a single bit arithmetically encoded first portion 511, which corresponds to the arithmetically encoded portion 501, 25 and fixed length (3 bits) bypass-encoded second portion 512 which corresponds to the bypass encoded portion 502. Here, the size or length of the second portion 512 is determined by the first portion 511. The presence of a one value in the first portion 511 indicates that the bypass encoded portion 512 is present. The length of the bypass encoded portion 512 may be predetermined and known to both the encoder and decoder. 30 Alternatively a value of the first portion 511 may indicate the length of the second portion 512, however the first portion 511 is required to be at least two bits in length to encoded different lengths for the bypass encoded section portion 512. An example would be that an arithmetically encoded value of 10 indicates a bypass encoded portion of 3 bits, while an arithmetically encoded value of 11 indicates a bypass encoded portion of 4 bits. 6432252_1 P038645_specilodge - 24 A syntax structure 400 of a largest coding unit (LCU) will be described with the reference to Fig. 4A. The syntax structure 400 is formed of a block 401 representing SAO information and a block 402 representing LCU structural, residual, prediction and other information. 5 The block 401 contains three blocks 403, 404 and 405. Block 403 contains SAO information for the luminance channel, and blocks 404 and 405 contain SAO information for the two chrominance channels. The blocks 403, 404 and 405 have the same syntactical structure, so that syntax elements 406 to 411 shown on Fig. 4A for the block 403 can be also present in the blocks 404 and 405. Block 406 contains saomergeleft-flag syntax 10 element. Block 407 contains saomergeup.flag syntax element. Block 408 contains saotypeidx syntax element binarised using binarisation scheme 500 with arithmetically encoded portion 413 and bypass-encoded portion 414 stored in an order 412. Block 409 contains saobandposition syntax element. Block 410 contains saooffsetabs syntax element. Block 411 contains saooffsetsign syntax element. The order 412 relates to a 15 particular order (of bins) because the binarisation schema 500 (and some others) allows interleaving of binary elements An alternative syntax structure 420 of a largest coding unit (LCU) will be described with the reference to Fig. 4B. The syntax structure 420 includes a block 421 representing SAO information and a 20 block 422 representing LCU structural, residual, prediction and other information. The block 421 contains blocks 423, 424 and 425. Block 423 contains saomerge-left-flag and saomerge-up-flag syntax elements for the three channels. Block 424 contains saotypeidx syntax elements for the three channels encoded using the binarisation scheme 500. Block 425 contains saofbandposition, saooffsetabs and saooffsetsign syntax 25 elements for the three channels. The block 424 is formed of blocks 426 and 427. Block 426 contains three arithmetically encoded portions 428, 429 and 430 of saotypejidx syntax elements for the luminance channel and two chrominance channels correspondingly. Block 427 contains three bypass-encoded portions 431, 432 and 433 of saojtype-idx syntax elements for the 30 luminance channel and two chrominance channels correspondingly. Portions 431, 432 and 433 are present only if the corresponding portions 428, 429 and 430 indicate their presence. The total bit length of the block 427 is determined based on the values of arithmetically encoded portions 428, 429 and 430. 6432252_1 P038645_specilodge -25 An alternative binarisation scheme 520 for syntax element sao-typejidx is described below with the reference to Fig. 5B. The binarisation scheme 520 comprises three arithmetically encoded binary elements 521, 522, 523 stored in the stream 113 adjacently one after another. An 5 exemplary binarisation 530 for saotypejidx implements the binarisation scheme 520. An alternative syntax structure 440 of a largest coding unit (LCU) will be described with the reference to Fig. 4C. The syntax structure 440 has a block 441 representing SAO information and a block 442 representing LCU structural, residual, prediction and other information. The 10 block 441 contains three blocks 443, 444 and 445. Block 443 contains SAO information for the luminance channel, and blocks 444 and 445 contain SAO information for the two chrominance channels. The blocks 443, 444 and 445 have the same syntactical structure, so that syntax elements 446 to 451 shown on Fig. 4C for block 443 can be also present in the blocks 444 and 445. Block 446 contains saomergeleftjflag syntax element. Block 15 447 contains saomerge-upjflag syntax element. Block 448 contains sao-type-idx syntax element binarised using binarisation scheme 520 with all bins encoded arithmetically. Block 449 contains saobandposition syntax element. Block 450 contains saooffsetabs syntax element. Block 451 contains saooffset-sign syntax element. An alternative binarisation scheme 540 for syntax element sao-typejidx is 20 described below with the reference to Fig. 5C. The binarisation scheme 540 is formed of an arithmetically encoded portion 541 and bypass-encoded portion 542. Portion 541 contains one binary element 543. Portion 542 has two bypass-encoded binary elements 544, 545. Binary elements 543, 544, 545 uniquely identify each saojtypeidx value. Binary elements 543, 544, 545 may be stored 25 in the stream 113 either adjacently one after another or be interleaved with other syntax elements. An exemplary binarisation 550 for saotypejidx implements the binarisation scheme 540. An alternative syntax structure 460 of a largest coding unit (LCU) will be described with the reference to Fig. 4D. 30 The syntax structure 460 has a block 461 representing SAO information and a block 462 representing LCU structural, residual, prediction and other information. The block 461 contains three blocks 463, 464 and 465. Block 463 contains SAO information for the luminance channel, and blocks 464 and 465 contain SAO information for the two chrominance channels. The blocks 463, 464 and 465 have the same syntactical structure, 6432252_1 P038645_specilodge - 26 so that syntax elements 466 to 471 shown on Fig. 4D for block 463 can be also present in the blocks 464 and 465. Block 466 contains saomergeleftjflag syntax element. Block 467 contains saomergetupjflag syntax element. Block 468 contains sao-type-idx syntax element binarised using binarisation scheme 540 with arithmetically encoded portion 473 5 and bypass-encoded portion 474 stored in an order 472, similar to that described above. Block 469 contains saobandposition syntax element. Block 470 contains saooffsetabs syntax element. Block 471 contains saooffset-sign syntax element. An alternative syntax structure 480 of a largest coding unit (LCU) will be described with the reference to Fig. 4E. 10 The syntax structure 480 is formed of a block 481 representing SAO information and block 482 representing LCU structural, residual, prediction and other information. The block 481 includes blocks 483, 484 and 485. Block 483 contains saomergeleft-flag and saomerge-up-flag syntax elements for the three channels. Block 484 contains saotypeidx syntax elements for the three channels encoded using the binarisation scheme 15 540. Block 485 contains saofbandposition, saooffsetabs and saooffsetsign syntax elements for the three channels. The block 484 includes blocks 486 and 487. Block 486 contains three arithmetically encoded portions 488, 489 and 490 of sao-typejidx syntax elements for the luminance channel and two chrominance channels respectively. Block 487 contains three 20 bypass-encoded portions 491, 492 and 493 of saotypeidx syntax elements for the luminance channel and two chrominance channels correspondingly. A binarisation scheme 560 for syntax element saotypejidx is described below with the reference to Fig. 5D. In the binarisation scheme 560 the maximum length of binarised sequence 562 is 25 determined as the number of possible distinct values of the saotypeidx syntax element, minus one. For the case of six possible values of the saotypejidx syntax element, the maximum length of binarised sequence 562 is five. In the binarisation scheme 560 every saotypeidx value is assigned a unique sequence 561 of arithmetically encoded "1" values 563 followed by an optional arithmetically encoded terminating "0" value 564. The 30 sequence 561 can have length in range from zero to the maximum length of binarised sequence 562. A terminating "0" value 564 is encoded only if the number of previously encoded "1" values 563 for a given binarised value is less than the maximum length of the binarised sequence 562. An exemplary binarisation 570 for saotypeidx implements the binarisation scheme 560. 6432252_1 P038645_specilodge -27 An alternative syntax structure 4100 of a largest coding unit (LCU) will be described with the reference to Fig. 4F. The syntax structure 4100 is formed of a block 4101 representing SAO information and a block 4102 representing LCU structural, residual, prediction and other information. 5 The block 4101 is formed of three blocks 4103, 4104 and 4105. Block 4103 contains SAO information for the luminance channel, and blocks 4104 and 4105 contain SAO information for the two chrominance channels. The blocks 4103, 4104 and 4105 have the same syntactical structure, so that syntax elements 4106 to 4111 shown on Fig. 4F for block 4103 can be also present in the blocks 4104 and 4105. Block 4106 contains 10 saomergeleftflag syntax element. Block 4107 contains saomergeup-flag syntax element. Block 4108 contains saotypejidx syntax element 562 binarised using binarisation scheme 560. Block 4109 contains sao-bandtposition syntax element. Block 4110 contains saooffsetabs syntax element. Block 4111 contains saooffsetsign syntax element. 15 A binarisation scheme 580 for syntax element saotype-idx is described below with the reference to Fig. 5E. In the binarisation scheme 580 the maximum length of binarised sequence 582 is determined as the number of possible distinct values of saotypejidx syntax element minus one. For the case of six possible values of the sao-type-idx syntax element the maximum 20 length of binarised sequence 582 is five. In the binarisation scheme 580 every sao-typejidx value is assigned a unique sequence 581 of "1" values 583 followed by an optional terminating "0" value 584. In the binarisation scheme 580 all bins of a binarised value are bypass-encoded except the first T bins which are encoded arithmetically, where Tis a value in range from zero to the 25 maximum length of binarised sequence 582 minus one. For the case of six possible values of the saotypejidx syntax elements, the parameter T can take any integer value in range from zero to four. The sequence of binary elements 581 and the binary element 584 may be stored in the stream 113 either adjacently one after another or be interleaved with other syntax elements. 30 An exemplary binarisation 590 for saotypeidx implements the binarisation scheme 580 with parameter T=2. The binarisation 590 has an arithmetically encoded first portion 591 and a variable length bypass encoded second portion 592. As will be seen from Fig. 5E, the first portion 591 can have multiple bits and can include (for values 1-5) a 6432252_1 P038645_specilodge - 28 second bit that, when set (for values 2-5), indicates that the second portion 592 will be present in the stream of video data. An alternative syntax structure 4200 of a largest coding unit (LCU) will be described with the reference to Fig. 4G. 5 The syntax structure 4200 is formed of a block 4201 representing SAO information and a block 4202 representing LCU structural, residual, prediction and other information. The block 4201 includes three blocks 4203, 4204 and 4205. Block 4203 contains SAO information for the luminance channel, and blocks 4204 and 4205 contain SAO information for the two chrominance channels. The blocks 4203, 4204 and 4205 have the 10 same syntactical structure, so that syntax elements 4206 to 4211 shown in Fig. 4G for block 4203 can be also present in the blocks 4204 and 4205. Block 4206 contains saomergeleftflag syntax element. Block 4207 contains saomerge-up-flag syntax element. Block 4208 contains saotypejidx syntax element binarised using binarisation scheme 580 with all bins stored adjacently in an order 4212, as discussed above. Block 15 4209 contains saobandposition syntax element. Block 4210 contains saooffsetabs syntax element. Block 4211 contains saooffsetsign syntax element. An alternative syntax structure 4400 of a largest coding unit (LCU) will be described with the reference to Fig. 4H. The syntax structure 4400 is formed of a block 4401 representing SAO information 20 and a block 4402 representing LCU structural, residual, prediction and other information. The block 4401 is formed of blocks 4403, 4404 and 4405. Block 4403 contains saomergeleftflag and sao-merge-up-flag syntax elements for the three channels. Block 4404 contains saotype-idx syntax elements for the three channels encoded using the binarisation scheme 580. Block 4405 contains saobandposition, saooffsetabs and 25 saooffsetsign syntax elements for the three channels. Block 4404 is formed of blocks 4406 and 4407. Block 4406 contains three arithmetically encoded portions 4408, 4409 and 4410 of saojtype-idx syntax elements corresponding to the luminance channel and two chrominance channels. The maximum bit length of the block 4406 is determined by the value of the parameter T of the binarisation 30 scheme 580. Block 427 contains three bypass-encoded portions 4411, 4412 and 4413 of saotypeidx syntax elements for the luminance channel and two chrominance channels correspondingly. Portions 4411, 4412 and 4413 are present only if the corresponding portions 4408, 4409 and 4410 indicate their presence. The maximum bit length of the 6432252_1 P038645_specilodge - 29 block 4406 is determined by the value of the parameter T of the binarisation scheme 580 and by the values of arithmetically encoded portions 4408, 4409 and 4410. An alternative syntax structure 4600 of a largest coding unit (LCU) will be described with the reference to Fig. 41. 5 The syntax structure 4600 is formed of a block 4601 representing SAO information and block 4602 representing LCU structural, residual, prediction and other information. The block 4601 contains two blocks 4603 and 4604. Block 4603 contains saomergeleftflag and saomergeup-flag syntax elements for the three channels, and block 4604 contains other SAO syntax elements for the three channels such as 10 saotypeidx, sao.bandposition, sao-offset abs, saooffset-sign. Block 4603 contains blocks 4606 and 4607. The block 4606 contains the saomergejleft-flag syntax elements for the three channels, and block 4607 contains the saomergetupjflag syntax elements for the three channels. The block 4606 is present in the stream 113 only if the LCU is not on the leftmost position in the frame. The block 4607 is present only if the LCU is not on the 15 topmost position in the frame. The blocks 4606 and 4607 can have a different order in the block 4603. In an alternative implementation the saomergejleft-flag syntax elements can be grouped into a single block, while the saomerge-up-flag can be coded separately for each channel. 20 Saomergeleft flag and saomergeup-flag syntax elements in syntax structures 400, 420, 440, 460, 480, 4100, 4200 and 4400 are arithmetically encoded. Probability modelling may be performed for each of the three channels. The modelling can be performed either independently for each channel, or the two chrominance channels may use a joint context model, or the three channels may use a joint context model. 25 An alternative syntax structure 4700 of a largest coding unit (LCU) will be described with the reference to Fig. 4J. The syntax structure 4700 includes a block 4701 representing SAO information and a block 4702 representing LCU structural, residual, prediction and other information. The block 4701 includes contiguously arranged blocks 4703, 4704 4705, 4706, 4707 and 4708. 30 Block 4703 includes saomergeleftflag and saomergequpjflag syntax elements for the three channels. Block 4704 includes contiguous arithmetically coded portions of saotypeidx syntax elements for the three channels. Block 4705 includes continuous saooffset-abs syntax elements for the three channels. Block 4706 includes SAO information for the luminance channel, and blocks 4707 and 4708 include SAO 6432252_1 P038645_specilodge - 30 information for the two chrominance channels. The blocks 4706, 4707 and 4708 have the same syntactical structure, so that contiguously arranged syntax elements 4709, 4710, 4711 shown on Fig. 4J for the block 4706 are also present in the blocks 4707 and 4708. The block 4709 includes a bypass-coded portion of the saotype-idx syntax element for the 5 luminance channel. The block 4710 includes saooffset-sign syntax element and the block 4711 includes saobandposition syntax element. An important aspect of the syntactical structure 4700 is that all bypass-coded SAO syntax elements of the block 4701 are concatenated into a single chunk. Blocks 4710 and 4711 can have a different order. The order of the channels can be different in the block 10 4701. More generally, the order of logically independent syntax elements can be different from the shown on Fig. 4J. A further alternative of the syntax structure 4700 omits the block 4709 and instead the block 4704 encodes the value of the saojtypejidx syntax element using, for example, a unary or truncated unary binarisation. 15 An alternative syntax structure 4800 of a largest coding unit (LCU) will be described with the reference to Fig. 4K. The syntax structure 4800 includes a block 4801 representing SAO information and a block 4802 representing LCU structural, residual, prediction and other information. The block 4801 includes contiguous blocks 4803, 4804 4805, 4806, 4807 and 4808. Block 20 4803 includes saomergejleft-flag and saomergetup-flag syntax elements for the three channels. Block 4804 includes arithmetically coded portions of saotype-idx syntax elements for the three channels. Block 4805 includes saooffsetabs syntax elements for the three channels. Each of the blocks 4803-4805 are arithmetically encoded. The block 4806 includes the bypass-coded portion of the saotypejidx syntax element for the three 25 channels. The block 4807 includes sao-offsetsign syntax element for the three channels and the block 4808 includes sao-bandposition syntax element for the three channels. The blocks 4806-4808 are each bypass encoded. An important aspect of the syntactical structure 4800 is that all bypass-coded SAO syntax elements of the block 4801 are concatenated into a single chunk. The order of 30 logically independent syntax elements can be different from the shown on Fig. 4K. An alternative to the syntax structure 4800 can omit the block 4806 and instead the block 4804 encodes the value of the saotypejidx syntax element using for example a unary or truncated unary binarisation. 6432252_1 P038645_specilodge -31 In the syntactical structures 400, 420, 440, 460, 480, 4100, 4200, 4400, 4600, 4700, 4800, the SAO syntax elements for one of the channels may be not encoded, in which case the values of the SAO syntax elements for that channel would be inferred from another channel. An example of this would be to copy U channel data for use as the V channel 5 data. This would allow encoding of only the Y and U channels without the need to encode the V channel. A method 600 of encoding an LCU data into the stream 113 will be described with the reference to Fig. 6A. In an initial step 601,SAO information is encoded In another step 602,LCU structural, residual, prediction and other information is encoded. 10 An exemplary method 610 of encoding SAO information will be described with the reference to Fig. 6B. The method 610 may be used to implement the step 601 of the method 600 to encode the blocks 401, 441, 461, 4101, 4201 described above. The method 610 starts with step 611 where the saomergeleft-flag and saomergeup-flag values for the luminance channel are encoded. Step 612 encodes saotypeidx value for the 15 luminance channel. Step 613 encodes saobandposition, saooffsetabs and saooffsetsign values for the luminance channel. Step 614 encodes saomergejleftflag and saomergetup-flag values for the first chrominance channel. Step 615 encodes saotypeidx value for the first chrominance channel. Step 616 encodes saobandposition, saooffsetabs and saooffsetsign values for the first chrominance 20 channel. Step 617 encodes saomergeleftjflag and saomergeup.flag values for the second chrominance channel. Step 618 encodes saotypejidx value for the second chrominance channel. Step 619 encodes sao-bandposition, saooffsetabs and saooffsetsign values for the second chrominance channel. The order of the steps 611 619 may be altered as desired by any particular implementation. 25 A method 630 of encoding saomergejleft-flag and saomerge-upjflag values for a single channel will be described with the reference to Fig. 6C. The method 630 may be used to implement steps 611, 614, 617 of the method 610, step 6701 of the method 6700, and step 6801 of the method 6800, to encode saomergeleft-flag and saomergeup-flag syntax elements in syntax structures 400, 440, 460, 4100, 4200, 4600 described above. 30 The method 630 starts by step 631 which checks whether the LCU is at the leftmost position in the frame. If this condition is true then control is passed to step 634, otherwise control is passed to step 632. The step 632 encodes saomergejleft-flag into the stream 113. Step 633 tests whether the value of saomerge-leftflag equals one. If this condition is true, the control leaves the method 630. Otherwise the control is passed to step 634. 6432252_1 P038645_specilodge - 32 Step 634 encodes saomergetupjflag into the stream 113. After this step the control leaves the method 630. A method 640 of encoding saotypejidx syntax element for a single channel will be described next with the reference to Fig. 6D. The method 640 may be used to 5 implement steps 612, 615, 618 of the method 610 to encode saotypejidx syntax element in syntax structures 400, 440, 460, 4100, 4200, 4600 described above. The method 640 starts by step 641. The step 641 checks whether saomergejleft-flag and saomerge-up-flag values for the given channel are both equal to zero. If this is true then the control is passed to step 642, otherwise the control leaves method 640. The step 642 10 binarises saotypeidx value. Next, step 643 encodes the binary representation of the saotypeidx value into the stream 113. After the step 643 the control leaves the method 640. A method 650 of encoding SAO information will be described with the reference to Fig. 6E. The method 650 may be used to implement the step 601 of the method 600 to 15 encode the blocks 421, 481, 4401, 4601 described above. The method 650 starts with step 651 which checks whether this is the leftmost LCU in the frame. If this is true then control is passed to step 653, otherwise control is passed to step 652. Step 652 encodes saomergeleftflag values for the three channels. The step 653 checks whether this is the topmost LCU in the frame. If this is true then control is passed to step 655, otherwise 20 control is passed to step 654. The step 654 encodes saomerge-up-flag values for the three channels. The step 655 encodes the arithmetically encoded portions of sao-typejidx values for the three channels. The step 656 encodes the bypass-encoded portions of saotypeidx values for the three channels. Next, step 657 encodes saobandposition, saooffsetabs and saooffsetsign values for the three channels. 25 A method 660 of encoding sao-mergejleft-flag values for the three channels will be described with the reference to Fig. 6F. The method 660 may be used to implement step 652 of the method 650 to encode saomergeleft-flag syntax elements in syntax structures 420, 480, 4400, 4600, 4700, and 4800 described above. The method 660 starts by step 661 which encodes sao-mergejleft-flag value for the luminance channel. Next, 30 step 662 encodes sao-mergejleftflag value for the first chrominance channel. Next, step 663 encodes saomergeleft-flag value for the second chrominance channel. After this the control leaves the method 660. A method 670 of encoding sao-merge-up-flag values for the three channels will be described with the reference to Fig. 6G. The method 670 may be used to implement step 6432252_1 P038645_specilodge - 33 654 of the method 650, step 6701 of the method 6700, and step 6801 of the method 6800 to encode saomerge-up-flag syntax elements in syntax structures 420, 480, 4400, 4600, 4700, and 4800 described above. The method 670 starts with step 671. The step 671 checks whether the saomergeleft-flag value for the luminance channel equals zero. If 5 this is true then control is passed to step 672, otherwise control is passed to step 673. The step 672 encodes sao-merge-up-flag for the luminance channel. The step 673 checks whether the saomergeleft-flag value for the first chrominance channel equals zero. If this is true then control is passed to step 674, otherwise control is passed to step 675. The step 674 encodes saomergeup-flag for the first chrominance channel. The step 675 10 checks whether the saomergeleft-flag value for the second chrominance channel equals zero. If this is true then control leaves the method 670, otherwise control is passed to step 676. The step 676 encodes saomergetupjflag for the second chrominance channel. After this the control leaves the method 670. A method 680 for encoding arithmetically coded portions of saotypejidx values 15 for the three channels will be described with the reference to Fig. 6H. The method 680 may be used to implement step 655 of the method 650, step 6702 of the method 6700, and step 6802 of the method 6800, to encode arithmetically coded portions of sao-typejidx syntax elements in syntax structures 420, 480, 4400, 4600, 4700, and 4800 described above. The method 680 starts with step 681. The step 681 checks whether the 20 saomergeleftflag and saomergetup-flag values for the luminance channel are both zero. If this is true then control is passed to step 682, otherwise control is passed to step 684. The step 682 binarises saotypejidx value for the luminance channel. Next, step 683 encodes arithmetically coded portion of the binarised value such as portion 428, 488, 4408 into the stream 113. The step 684 checks whether the saomergeleftflag and 25 saomergetupjflag values for the first chrominance channel are both zero. If this is true then control is passed to step 685, otherwise control is passed to step 687. The step 685 binarises saotypejidx value for the first chrominance channel. Next, step 686 encodes arithmetically coded portion of the binarised value, such as portion 429, 489, 4409, into the stream 113. The step 687 checks whether the saomergeleft-flag and saomergetup-flag 30 values for the second chrominance channel are both zero. If this is true then control is passed to step 688, otherwise control leaves the method 680. The step 688 binarises saotypeidx value for the second chrominance channel. Next, step 689 encodes arithmetically coded portion of the binarised value, such as portion 430, 490, 4410, into the stream 113. 6432252_1 P038645_specilodge - 34 A method 690 of encoding bypass-coded portions of sao-typeidx values for the three channels will be described with the reference to Fig. 61. The method 690 may be used to implement step 656 of the method 650, steps 6704, 6707, 6710 of the method 6700, and step 6804 of the method 6800 to encode bypass-coded portions of saojtype-idx syntax 5 elements in syntax structures 420, 480, 4400, 4600, 4700, and 4800 described above. The method 690 accepts input of the binarised saojtypeidx values produced on the steps 682, 685, 688 of the method 680. The method 690 starts with step 691. The step 691 checks whether the saomergeleftjflag and saomergeup-flag values for the luminance channel are both zero. If this is true then control is passed to step 692, otherwise control is passed 10 to step 693. The step 692 encodes bypass-coded portion of the value binarised on step 682, such as portions 431, 491, 4411, into the stream 113. The step 693 checks whether the saomergeleftflag and saomerge-upjflag values for the first chrominance channel are both zero. If this is true then control is passed to step 694, otherwise control is passed to step 695. The step 694 encodes the bypass-coded portion of the value binarised by step 15 685, such as portions 432, 492, 4412, into the stream 113. The step 695 checks whether the saomergeleft-flag and saomerge-up-flag values for the second chrominance channel are both zero. If this is true then control is passed to step 696, otherwise control leaves the method 690. The step 696 encodes the bypass-coded portion of the value binarised in step 688, such as portions 433, 493, 4413, into the stream 113. 20 A method 6100 of binarising a saotypejidx value using the binarisation scheme 500 will be described with the reference to Fig. 6J(1). The method 6100 may be used to implement the steps 682, 685, 688 of the method 680 to binarise saotypejidx values in syntax structure 420 described above. The method 6100 may also be used to implement step 642 of the method 640 to binarise saotypeidx in syntax structure 400 described 25 above. The method 6100 starts with the step 6101. The step 6101 checks whether given saotypeidx value is estimated to be the most probable saotypejidx value. If this is true then control is passed to step 6102, otherwise control is passed to step 6103. The step 6102 assigns the binary value "0" to the binary element 503 of the portion 501. After the step 6102 the control leaves the method 6100. The step 6103 assigns the binary value "1" 30 to the binary element 503 of the arithmetically coded portion 501. Next, the step 6104 assigns a unique three bit binary code to the binary elements 504, 505, 506 of the bypass coded portion 502. After this step the control leaves the method 6100. A method 6200 of binarising a saotypejidx value using binarisation scheme 540 will be described with the reference to Fig. 6J(2). The method 6200 may be used to 6432252_1 P038645_specilodge - 35 implement the steps 682, 685, 688 of the method 680 to binarise sao-typejidx values in syntax structure 480 described above. The method 6200 may also be used to implement the step 642 of the method 640 to binarise saotype-idx values in syntax structure 460 described above. The method 6200 starts with the step 6201. The step 6201 assigns a 5 unique three bit binary code to given saotypejidx value. Next, step 6202 assigns one bit value of the assigned three bit code - usually based on the bit position, such as the least significant bit - to the binary element 543 of arithmetically coded portion 541. Next, step 6203 assigns two remaining bits of the assigned binary value to binary elements 544, 545 of the bypass-coded portion 542. After this step the control leaves the method 6200. 10 A method 6300 of binarising a saotypejidx value using binarisation scheme 580 will be described with the reference to Fig. 6K. The method 6300 may be used to implement the steps 682, 685, 688 of the method 680 to binarise sao-typejidx value in syntax structure 4400 described above. The method 6300 may also be used to implement the step 642 of the method 640 to binarise saotypeidx value in syntax structure 4200 15 described above. The method 6300 starts with step 6301. The step 6301 assigns a unique code length L in the range from zero to the maximum length LMAX of binarised sequence 582 to the given sao-typejidx value. Usually L values are assigned so that a shorter L value is assigned to a saojtypeidx value with a higher estimated probability. A parameter T is being used to determine the maximum length of arithmetically coded portion of the 20 binarised value. Next, step 6302 checks if the number ONES of binary "1" values added to the sequence 581 is less than L, and if ONES is less than T. If both conditions are true then the control is passed to step 6303, otherwise the control is passed to step 6304. The step 6303 adds an arithmetically coded binary "1" value 583 to the sequence 581. After the step 6303 the control is passed to the step 6302. The step 6304 checks if ONES is less 25 than T and if ONES is less than LMAX. If these conditions are true the control is passed to step 6309, otherwise the control is passed to step 6305. The step 6309 assigns arithmetically coded binary "0" value to the element 584. After the step 6309 the control leaves the method 6300. The step 6305 checks if ONES is less than L. If this is true then the control is passed to step 6306, otherwise the control is passed to step 6307. The step 30 6306 adds a bypass-coded binary "1" value 583 to the sequence 581. After the step 6306 the control is passed to the step 6305. The step 6307 checks if ONES is less than LMAX. If this is true then the control is passed to step 6308, otherwise the control leaves the method 6300. The step 6308 assigns a bypass-coded binary "0" value to the element 584. After this step the control leaves the method 6300. 6432252_1 P038645_specilodge - 36 A method 6500 of binarising a saotypejidx value using binarisation scheme 560 will be described with the reference to Fig. 6L(1). The method 6500 may be used to implement the step 642 of the method 640 to binarise sao-typejidx value in syntax structure 4100 described above. The method 6500 starts with step 6501. The step 6501 5 assigns a unique code length L in the range from zero to the maximum length LMAX of binarised sequence 582 to the given saotypejidx value. Usually L values are assigned so that a shorter L value is assigned to a saotypejidx value with a higher estimated probability. Next, step 6502 checks if the number ONES of binary "1" values added to the sequence 581 is less than L. If this condition is true then the control is passed to step 6503, 10 otherwise the control is passed to step 6504. The step 6503 adds an arithmetically coded binary "1" value 583 to the sequence 581. After the step 6503 the control is passed back to the step 6502. The step 6504 checks if ONES is less than LMAX. If this condition is true then the control is passed to step 6505, otherwise the control leaves method 6500. The step 6505 assigns arithmetically coded binary "0" value to the element 584. After the step 6505 15 the control leaves the method 6300. A method 6600 of binarising a saotypejidx value using binarisation scheme 520 will be described with the reference to Fig. 6L(2). The method 6600 may be used to implement the step 642 of the method 640 to binarise sao-typejidx value in syntax structure 440 described above. The method 6600 starts by the step 6601. At the step 6601 20 a unique three bit code is assigned to the saostypeidx value. Next, step 6602 assigns the assigned three bit code to the binary elements 521, 522, 523. After this step the control leaves the method 6600. An exemplary method 6700 of encoding SAO information will be described with the reference to Fig. 6M. The method 6700 may be used to implement step 601 of the 25 method 600 to encode the blocks 4703 to 4708 described above. The method 6700 starts with step 6701 where the saomergejleft-flag and saomerge-up-flag values for the three channels are encoded. Step 6702 encodes an arithmetically coded portion of saotypejidx value for the three channels. Step 6703 encodes the saooffsetabs four valued list for the three channels. A saooffsetabs list for a channel is encoded only if the value of the 30 arithmetically coded portion of saotypejidx for that channel is not zero. Step 6704 encodes the bypass-coded portion of saojtype-idx value for the luminance channel. The bypass-coded portion of saotypejidx for the luminance channel is present only if the arithmetically encoded portion of the saotypeidx value for the luminance channel indicates its presence. Step 6705 encodes the saooffsetsign four valued list for the 6432252_1 P038645_specilodge - 37 luminance channel. A saooffset-sign list entry is encoded only if the saotypeidx value for the luminance channel is equal to five and the corresponding entry in the saooffsetabs list is not zero. Step 6706 encodes saobandposition value for the luminance channel. The saofbandposition value is encoded only if the saotypejidx 5 value for the luminance channel is equal to five. Steps 6707, 6708, 6709 encode the bypass-coded portion of saotype value, saooffset-sign value and sao-bandposition for the first chrominance channel with conditions similar to those applied on the steps 6704, 6705, 6706 to the corresponding elements of the luminance channel. Steps 6710, 6711, 6712 encode the bypass-coded portion of saotype value, saooffsetsign value and 10 saobandposition for the second chrominance channel with conditions similar to those applied on the steps 6704, 6705, 6706 to the corresponding elements of the luminance channel. The order of the steps 6701-6712 may be altered as desired by any particular implementation. In particular the order of the steps 6701-6712 may be altered to accord with the order of syntax elements in the structure 4700. The method 6700 may encode the 15 further alternative of the syntax structure 4700 by omitting the steps 6702, 6707 and 6710 and having the step 6702 encode the saotypejidx syntax element in its entirety for the three channels, using for example a unary or truncated unary binarisation. An exemplary method 6800 of encoding SAO information will be described with the reference to Fig. 6N. The method 6800 may be used to implement the step 601 of the 20 method 600 to encode the blocks 4803 to 4808 described above. The method 6800 starts with step 6801 where the saomergeleft-flag and saomerge-up-flag values for the three channels are encoded. Step 6802 encodes an arithmetically coded portion of saotypejidx value for the three channels. Step 6803 encodes the saooffsetabs four valued list for the three channels. A saooffsetabs list for a channel is encoded only if the value of the 25 arithmetically coded portion of saotypejidx for that channel is not zero. Step 6804 encodes the bypass-coded portion of saotypejidx value for the three channels. The bypass-coded portion of saotypejidx for a channel is present only if the arithmetically encoded portion of the sao-typejidx value for appropriate channel indicates its presence. Step 6805 encodes the saooffset-sign four valued list for the three channels. A 30 saooffsetsign list entry is encoded only if the saotypeidx value for the appropriate channel is equal to five and the corresponding entry in the saooffsetabs list for that channel is not zero. Step 6806 encodes saobandposition value for the three channels. The saobandposition value is encoded only if the saojtypeidx value for the appropriate channel is equal to five. The order of the steps 6801-6806 may be altered as desired by 6432252_1 P038645_specilodge - 38 any particular implementation. In particular the order of the steps 6801-6806 may be altered to accord with the order of syntax elements in the structure 4800. The method 6800 may decode the further alternative of the syntax structure 4700 by omitting the step 6804 and modifying the step 6802 encode the sao-typejidx syntax 5 element in its entirety for the three channels, using for example a unary or truncated unary binarisation. A method 700 of decoding LCU data from the stream 113 will be described with the reference to Fig. 7A. In step 701, SAO information is decoded. In step 702, LCU structural, residual, prediction and other information is decoded. 10 A method 710 of decoding SAO information will be described with the reference to Fig. 7B. The method 710 may be used to implement the step 701 of the method 700 to decode the blocks 401, 441, 461, 4101, 4201 described above. The method 710 starts with step 711 where the saomergeleftjflag and saomerge-upjflag values for the luminance 15 channel are decoded. Step 712 decodes saotypeidx value for the luminance channel. Step 713 decodes saobandposition, saooffsetabs and saooffsetsign values for the luminance channel. Step 714 decodes saomergejleft-flag and saomerge-up-flag values for the first chrominance channel. Step 715 decodes sao-typejidx value for the first chrominance channel. Step 716 decodes saobandposition, saooffsetabs and 20 saooffsetsign values for the first chrominance channel. Step 717 decodes saomergeleft-flag and saomerge-up-flag values for the second chrominance channel. Step 718 decodes saotypejidx value for the second chrominance channel. Step 719 decodes saobandposition, saooffsetabs and saooffsetsign values for the second chrominance channel. The order or implementation of the steps 711-719 may be varied 25 depending upon the particular implementation. A method 730 of decoding saomergejleft-flag and saomerge-upjflag values for a single channel will be described with the reference to Fig. 7C. The method 730 may be used to implement steps 711, 714, 717 of the method 710, step 7981 of the method 7980, and step 8001 of the method 8000 to decode saomergeleft-flag and saomerge-up-flag 30 syntax elements in syntax structures 400, 440, 460, 4100, 4200, 4600, 4700, and 4800 described above. The method 730 starts at step 731 which checks whether the LCU is at the leftmost position in the frame. If this condition is true then control is passed to step 734, otherwise control is passed to step 732. The step 732 decodes saomergejleft-flag from the stream 113. Step 733 tests whether the value of saomergejleft-flag equals one. 6432252_1 P038645_specilodge - 39 If this condition is true the control leaves the method 730. Otherwise the control is passed to step 734. Step 734 decodes sao_mergetup-flag from the stream 113. After this step the control leaves the method 730. A method 740 of decoding saotypejidx syntax element for a single channel will 5 be described next with the reference to Fig. 7D. The method 740 may be used to implement steps 712, 715, 718 of the method 710 to decode saotypejidx syntax element in syntax structures 400, 440, 460, 4100, 4200, 4600 described above. The method 740 starts by step 741. The step 741 checks to determine whether decoding of sao-typejidx is required by checking whether the saomergeleftjflag and sao-merge-up-flag values for 10 the given channel are both equal to zero. If this is true then the control is passed to step 742, otherwise the control leaves method 740. The step 742 decodes and de-binarises saotypeidx value. After the step 743 the control leaves the method 740. A method 750 of decoding SAO information will be described with the reference to Fig. 7E. The method 750 may be used to implement the step 701 of the method 700 to 15 decode the blocks 421, 481, 4401, 4601 described above. The method 750 starts with step 751 which checks whether this is the leftmost LCU in the frame. If this is true then control is passed to step 753, otherwise control is passed to step 752. Step 752 decodes saomergeleftflag values for the three channels. The step 753 checks whether this is the topmost LCU in the frame. If this is true then control is passed to step 755, otherwise 20 control is passed to step 754. The step 754 decodes saomerge-up-flag values for the three channels. The step 755 decodes the arithmetically encoded portions of sao-typejidx values for the three channels. The step 756 decodes the bypass-encoded portions of saotypeidx values for the three channels. Next, step 757 decodes saobandposition, saooffsetabs and saooffsetsign values for the three channels. 25 A method 760 of decoding sao-mergejleft-flag values for the three channels will be described with the reference to Fig. 7F. The method 760 may be used to implement step 752 of the method 750, step 7981 of the method 7980, and step 8001 of the method 8000 to decode saomergejleft-flag syntax elements in syntax structures 420, 480, 4400, 4600, 4700, and 4800 described above. The method 760 starts by step 761 which decodes 30 saomergeleftjflag value for the luminance channel. Next, step 762 decodes saomergeleftflag value for the first chrominance channel. Next, step 763 decodes saomergeleftflag value for the second chrominance channel. After this the control leaves the method 760. 6432252_1 P038645_specilodge - 40 A method 770 of decoding saomergeq.upjlag values for the three channels will be described with the reference to Fig. 7G. The method 770 may be used to implement step 754 of the method 750, step 7981 of the method 7980, and step 8001 of the method 8000 to decode sao-merge-up-flag syntax elements in syntax structures 420, 480, 4400, 4600, 5 4700, and 4800 described above. The method 770 starts with step 771. The step 771 checks whether the saomergeleft-flag value for the luminance channel equals zero. If this is true then control is passed to step 772, otherwise control is passed to step 773. The step 772 decodes saomerge-up-flag for the luminance channel. The step 773 checks whether the saomergeleft-flag value for the first chrominance channel equals zero. If 10 this is true then control is passed to step 774, otherwise control is passed to step 775. The step 774 decodes saomergeup-flag for the first chrominance channel. The step 775 checks whether the saomergeleft-flag value for the second chrominance channel equals zero. If this is true then control leaves the method 770, otherwise control is passed to step 776. The step 776 decodes saomergeup-flag for the second chrominance channel. After 15 this the control leaves the method 770. A method 780 for decoding arithmetically coded portions of saotypejidx values for the three channels will be described with the reference to Fig. 7H. The method 780 may be used to implement step 755 of the method 750, step 7982 of the method 7980, and step 8002 of the method 8000 to decode arithmetically coded portions of saotypejidx 20 syntax elements in syntax structures 420, 480, 4400, 4600, 4700, and 4800 described above. The method 780 starts with step 781. The step 781 checks whether the saomergeleftflag and saomergetup-flag values for the luminance channel are both zero. If this is true then control is passed to step 782, otherwise control is passed to step 783. The step 782 decodes arithmetically coded portion of saotypeidx binarised value, 25 such as portion 428, 488, 4408, from the stream 113 for the luminance channel. The step 783 checks whether the saomergeleftflag and saomergequpjflag values for the first chrominance channel are both zero. If this is true then control is passed to step 784, otherwise control is passed to step 785. The step 784 decodes arithmetically coded portion of saojtypeidx binarised value such as portion 429, 489, 4409 from the stream 113 for the 30 first chrominance channel. The step 785 checks whether the saomergejleft-flag and saomerge-up-flag values for the second chrominance channel are both zero. If this is true then control is passed to step 786, otherwise control leaves the method 780. The step 786 decodes arithmetically coded portion of saotype-idx binarised value, such as portion 430, 490, 4410, from the stream 113 for the second chrominance channel. 6432252_1 P038645_specilodge - 41 A method 790 of decoding bypass-coded portions of sao-typeidx values for the three channels will be described with the reference to Fig. 71. The method 790 may be used to implement step 756 of the method 750, steps 7984, 7988, 7992 of the method 7980, and step 8004 of the method 8000 to decode bypass-coded portions of saojtype-idx syntax 5 elements in syntax structures 420, 480, 4400, 4600, 4700, and 4800 described above. The method 790 accepts as input the portions of saotypejidx values decoded on the steps 782, 784, 786 of the method 780, step 7982 of the method 7980, and step 8002 of the method 8000. The method 790 starts with step 791. The step 791 checks whether the saomergeleft-flag and saomerge.up-flag values for the luminance channel are both 10 zero. If this is true then control is passed to step 792, otherwise control is passed to step 793. The step 792 decodes bypass-coded portion of the saotypeidx value for the luminance channel, such as portion 431, 491, 4411, from the stream 113 and restores saotypeidx value for the luminance channel. The step 793 checks whether the saomergeleftflag and saomergeupjflag values for the first chrominance channel are 15 both zero. If this is true then control is passed to step 794, otherwise control is passed to step 795. The step 794 decodes bypass-coded portion of the saostypeidx value for the first chrominance channel, such as portion 432, 492, 4412, from the stream 113 and restores saotypejidx value for the first chrominance channel. The step 795 checks whether the saomergeleftjflag and sao_merge-up-flag values for the second 20 chrominance channel are both zero. If this is true then control is passed to step 796, otherwise the control leaves the method 790. The step 796 decodes bypass-coded portion of the saotypejidx value for the second chrominance channel such as portions 433, 493, and 4413 from the stream 113 and restores saojtypeidx value for the second chrominance channel. 25 A method 7100 of decoding from the stream 113 and de-binarising a sao-typejidx value using binarisation scheme 500 with be described with the reference to Fig. 7J(1).The method 7100 may be used to implement step 742 of the method 700 to decode and de binarise saotypejidx value in syntax structure 400 described above. The method 7100 starts with the step 7101. The step 7101 decodes arithmetically encoded bin from the 30 stream 113. Next, step 7102 check whether the decoded bin value is "1'. If this is true then the control is passed to step 7103, otherwise control is passed to step 7104. The step 7103 decodes three bypass encoded bins from the stream 113. The step 7104 returns a saotypeidx value that corresponds to the bins decoded on steps 7101, 7103 in accordance with the binarisation scheme 500. 6432252_1 P038645_specilodge - 42 A method 7200 of decoding from the stream 113 and de-binarising a sao-typejidx value using binarisation scheme 540 with be described with the reference to Fig. 7J(2). The method 7200 may be used to implement the step 742 of the method 740 to decode and de-binarise saojtypeidx values in syntax structure 460 described above. The method 5 7200 starts with the step 7201. The step 7201 decodes an arithmetically encoded bin from the stream 113. Next, step 7202 decodes two bypass-encoded bins from the stream 113. Next, step 7203 returns a saotypeidx value that corresponds to the bins decoded on steps 7201, 7202 in accordance with the binarisation scheme 540. A method 7300 of decoding and de-binarising a sao-typeidx value using 10 binarisation scheme 580 will be described with the reference to Fig. 7K. The method 7300 may be used to implement the step 742 of the method 740 to decode and de-binarise saotypeidx value in syntax structure 4200 described above. The method 7300 starts with step 7301. The step 7301 resets to zero a counter ONECNT of decoded "1" values. Next, step 7302 decodes an arithmetically encoded bin from the stream 113. Next, step 7303 15 checks if the decoded bin value is "1". If this is true then control is passed to step 7304, otherwise control is passed to step 7311. The step 7304 increments the ONECNT counter by one. Next, step 7305 checks whether the ONECNT counter is equal to the maximum number T of arithmetically coded bins for a binarised value. If this is true, the control is passed to step 7310, otherwise the control is passed to step 7306. The step 7306 check 20 whether the ONECNT counter is equal to the maximum length LMAX of binarised sequence 582. If this is true, then the control is passed to the step 7311, otherwise the control is passed to the step 7302. The step 7310 checks whether the ONECNT counter is equal to the maximum length LMAX. If this is true, the control is passed to the step 7311, otherwise the control is passed to step 7307. The step 7307 decoded a bypass-coded bin. 25 Next, step 730 checks whether the decoded bin equals "1". If this is true, the control is passed to step 7309, otherwise the control is passed to the step 7311. The step 7309 increments the ONECNT counter and passes the control to the step 7310. The step 7311 returns a saotypejidx value that corresponds to the ONECNT counter value in accordance with the binarisation scheme 580. 30 A method 7500 of decoding and de-binarising a saostypeidx value using binarisation scheme 560 will be described with the reference to Fig. 7L(1). The method 7500 may be used to implement the step 742 of the method 740 to decode and de-binarise saotypeidx value in syntax structure 4100 described above. The method 7500 starts with step 7501. The step 7501 resets a counter ONECNT of decoded "1" bins to zero. Next, 6432252_1 P038645_specilodge - 43 step 7502 decodes an arithmetically encoded bin from the stream 113. Next, step 7503 checks whether the decoded bin equals "1". If this is true, the control is passed to the 7504, otherwise the control is passed to step 7506. The step 7504 increments the ONECNT counter by one. Next, step 7505 checks whether the ONECNT counter value is 5 equal to the maximum length LMAX of binarised sequence 582. If this is true, then the control is passed to the step 7506, otherwise the control is passed to step 7502. The step 7506 returns a saotypejidx value that corresponds to the ONECNT counter value in accordance with the binarisation scheme 560. A method 7600 of decoding and de-binarising a sao-typeidx value using 10 binarisation scheme 520 will be described with the reference to Fig. 7L(2). The method 7600 may be used to implement the step 742 of the method 740 to decode and de-binarise saotypeidx value in syntax structure 440 described above. The method 7600 starts by the step 7601. The step 7601 decodes three arithmetically encoded bins from the stream 113. Next, step 7602 returns a saostypeidx value that corresponds to the values of bins 15 decoded on the step 7601 in accordance with the binarisation scheme 520. A method 7700 of decoding from the stream 113 the arithmetically encoded portion 501 of a saotypeidx value using binarisation scheme 500 will be described with the reference to Fig. 7M(1). The method 7700 may be used to implement the steps 782, 784, 786 of the method 780 to decode arithmetically encoded portions 428, 429, 430 of 20 saotypeidx values in syntax structure 420 described above. The method 7700 starts with step 7701 by decoding an arithmetically encoded bin from the stream 113. Next, step 7702 stores the decoded value in a storage location accessible to the step 7801 of method 7800 described below. After this, the control leaves the method 7700. A method 7800 of decoding from the stream 113 bypass-coded portion 502 of a 25 saotypeidx value using binarisation scheme 500 will be described with the reference to Fig. 7M(2). The method 7800 may be used to implement the steps 792, 794, 796 of the method 790 to decode bypass-encoded portions 431, 432, 433 of saotypejidx values in syntax structure 420. The method 7800 starts with the step 7801. The step 7801 checks whether the value decoded on the step 7701 of the method 7700 equals "1". If this is true, 30 then the control is passed to step 7802, otherwise the control is passed to step 7803. The step 7802 decodes three bypass encoded bins from the stream 113. The step 7803 returns a saotypeidx value that corresponds to the bins decoded on steps 7701, 7802 in accordance with the binarisation scheme 500. 6432252_1 P038645_specilodge - 44 A method 7900 of decoding from the stream 113 arithmetically encoded portion 541 of a saotypeidx value using binarisation scheme 540 will be described with the reference to Fig. 7N(1). The method 7900 may be used to implement the steps 782, 784, 786 of the method 780 to decode arithmetically encoded portions 488, 489, 490 of 5 saotypeidx values in syntax structure 480 described above. The method 7900 starts with the step 7901. The step 7901 decodes an arithmetically encoded bin from the stream 113. Next, step 7902 stores the decoded value in a storage location accessible to step 7921 of the method 7920 described below. After this, the control leaves the method 7900. A method 7920 of decoding from the stream 113 bypass-coded portion 542 of a 10 saotypeidx value using binarisation scheme 540 will be described with the reference to Fig. 7N(2). The method 7920 may be used to implement the steps 792, 794, 796 of the method 790 to decode bypass-encoded portions 491, 492, 493 of saotypejidx values in syntax structure 480 described above. The method 7920 starts with the step 7921. The step 7921 decodes two arithmetically encoded bins from the stream 113. Next, the step 15 7922 returns a saotypejidx value that corresponds to the bins decoded on steps 7901, 7921 in accordance with the binarisation scheme 540. A method 7940 of decoding from the stream 113 arithmetically coded portion 591 of the sequence 582 will be described with the reference to Fig. 70. The method 7940 may be used to implement the steps 782, 784, 786 of the method 780 to decode 20 arithmetically encoded portions 4408, 4409, 4410 of saotypejidx values in syntax structure 4400 described above. The method 7940 starts with step 7941. The step 7941 reset to zero a counter ONECNT of decoded "1" values. Next, step 7942 resets to zero a flag FINISHED indicating that a "0" value was decoded from the stream. Next, step 7943 decodes an arithmetically encode bin from the stream 113. Next, Step 7944 checks 25 whether the decoded bin value equals "1". If this is true, then the control is passed to step 7945, otherwise the control is passed to step 7948. The step 7945 increments the counter ONECNT by one. Next, step 7946 checks whether the value of the counter ONECNT is equal to the maximum number T of arithmetically coded bins for a binarised value. If this is true, then the control is passed to step 7949, otherwise the control is passed to step 7947. 30 The step 7947 checks whether the value of the counter ONECNT is equal to the maximum length LMAX of binarised sequence 582. If this is true the control is passed to step 7949, otherwise the control is passed to step 7943. The step 7948 sets the flag FINISHED to one. The step 7949 stores the values of the flag FINISHED and the counter ONECNT is a 6432252_1 P038645_specilodge - 45 storage location accessible to the steps of method 7960 (described below). After the step 7949 the control leaves the method 7940. A method 7960 of decoding from the stream 113 bypass-coded portion 592 of the sequence 582 will be described next with the reference to Fig. 7P. The method 7960 may 5 be used to implement the steps 792, 794, 796 of the method 790 to decode bypass-encoded portions 4411, 4412, 4413 of saojtypeidx values in syntax structure 4400 described above. The method 7960 starts with step 7961. The step 7961 checks whether the value of the flag FINISHED set in the method 7940 is equal to one. If this is true, then the control is passed to step 7966, otherwise the control is passed to step 7965. The step 7965 checks 10 whether the value of the counter ONECNT is equal to the maximum length LMAX of binarised sequence 582. If this is true, then the control is passed to the step 7966, otherwise the control is passed to step 7962. The step 7962 decodes a bypass coded bin from the stream 113. Next, step 7963 checks whether the decoded value is "1". If this is true, then the control is passed to step 7964, otherwise the control is passed to step 7966. 15 The step 7964 increments the counter ONECNT by one. The step 7965 checks whether the value of the counter ONECNT is equal to the maximum length LMAX of binarised sequence 582. If this is true, then the control is passed to the step 7966, otherwise the control is passed to the step 7962. The step 7966 returns a saotypejidx value that corresponds to the value of the counter ONECNT in accordance with the binarisation 20 scheme 580. An exemplary method 7980 of decoding SAO information will be described with the reference to Fig. 7Q. The method 7980 may be used to implement the step 701 of the method 700 to decode the blocks 4703 to 4708 described above. The method 7980 starts with step 7981 where the saomergeleft-flag and saomergetup-flag values for the three 25 channels are decoded. Step 7982 decodes an arithmetically coded portion of the saotypeidx value for the three channels. Step 7983 decodes the saooffsetabs four valued list for the three channels. A saooffsetabs list for a channel is decoded only if the value of the arithmetically coded portion of sao-typejidx for that channel decoded in step 7982 is not zero. Step 7984 decodes a bypass-coded portion of saotypejidx value for the 30 luminance channel. The bypass-coded portion of saotypeidx for the luminance channel is present only if the arithmetically encoded portion of the saortypeidx value for the luminance channel decoded on the step 7982 indicates its presence. Step 7985 de-binarises the sao-typejidx value for the luminance channel from the arithmetically coded portion decoded on the step 7982 and the bypass-coded portion decoded on the step 7984. Step 6432252_1 P038645_specilodge -46 7986 decodes the saooffset-sign four valued list for the luminance channel. A saooffsetsign list entry is decoded only if the saotypeidx value for the luminance channel de-binarised on the step 7985 is equal to five and the corresponding entry in the saooffsetabs list decode on the step 7983 is not zero. Step 7987 decodes 5 saobandposition value for the luminance channel. The saobandposition value is decoded only if the saotypeidx value for the luminance channel is equal to five. Steps 7988, 7989, 7990, 7991 decode the bypass-coded portion of saojtype value, saooffsetsign value and saoband-position for the first chrominance channel with conditions similar to those applied on the steps 7984, 7985, 7986, 7987 to the 10 corresponding elements of the luminance channel. Steps 7992, 7993, 7994, 7995 decode the bypass-coded portion of saojtype value, saooffset-sign value and saobandposition for the second chrominance channel with conditions similar to those applied on the steps 7984, 7985, 7986, 7987 to the corresponding elements of the luminance channel. The order of the steps 7981-7995 may be altered as desired by any particular implementation. 15 In particular the order of the steps 7981-7995 may be altered to accord with the order of syntax elements in the structure 4700. The method 7980 may decode the further alternative of the syntax structure 4700 by omitting the steps 7984, 7989 and 7992 and having the step 7982 decode the saotypeidx syntax element in its entirety for the three channels using, for example, a 20 unary or truncated unary binarisation. As the step 7982 decodes the entirety of the saotypeidx syntax elements, the steps 7985, 7990 and 7993 may be performed at any time after the step 7982, or included in the step 7982 as part of decoding the unary or truncated unary codeword. An exemplary method 8000 of decoding SAO information will be described with 25 the reference to Fig. 7R. The method 8000 may be used to implement the step 701 of the method 700 to decode the blocks 4803 to 4808 described above. The method 8000 starts with step 8001 where the saomergeleft-flag and saomerge-up-flag values for the three channels are decoded. Step 8002 decodes an arithmetically coded portion of sao-typejidx value for the three channels. Step 8003 decodes the saooffsetabs four valued list for the 30 three channels. A saooffsetabs list for a channel is decoded only if the value of the arithmetically coded portion of sao-typeidx for that channel decoded on the step 8002 is not zero. Step 8004 decodes a bypass-coded portion of saotypejidx value for the three channels. The bypass-coded portion of saotypeidx for a channel is decoded only if the arithmetically encoded portion of the saotypejidx value for appropriate channel decoded 6432252_1 P036645_specilodge - 47 on the step 8002 indicates its presence. Step 8005 de-binarises the saotypejidx values for the three channels from the arithmetically coded portions decoded on the step 8002 and bypass-coded portions decoded on the step 8004. Step 8006 decodes the saooffset-sign four valued list for the three channels. A saooffsetsign list entry is encoded only if the 5 saotypeidx value for the appropriate channel de-binarised on the step 8005 is equal to five and the corresponding entry in the saooffsetabs list for that channel decoded on the step 8003 is not zero. Step 8007 decodes saobandposition value for the three channels. The saobandposition value is decoded only if the saojtypeidx value for the appropriate channel is equal to five. The order of the steps 8001-8007 may be altered as desired by 10 any particular implementation. In particular the order of the steps 8001-8007 may be altered to accord with the order of syntax elements in the structure 4800. The method 8000 may decode the further alternative of the syntax structure 4800 by omitting the step 8004 and having the step 8002 decode the saotypejidx syntax element in its entirety for the three channels, using for example a unary or truncated unary 15 binarisation. As the step 8002 decodes the entirety of the sao-typejidx syntax elements, the step 8005 may be performed at any time after the step 8002, or included in the step 8002 as part of decoding the unary or truncated unary codeword. It will be appreciated that the decoding of Figs. 7Q and 7R are essentially complementary to the encoding of Figs. 6M and 6N. 20 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. 25 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 30 of". Variations of the word "comprising", such as "comprise" and "comprises" have correspondingly varied meanings. 6432252_1 P038645_specilodge

Claims (12)

1. A method of determining a plurality of syntax elements of sample adaptive offset information for a coding unit from a stream of encoded video data received by a video 5 decoder, the method comprising: decoding an arithmetically encoded first portion of the sample adaptive offset information from the stream of video data, the first portion being a contiguous collection of a subset of the syntax elements including syntax elements for each colour space channel of the video data; 10 decoding a bypass encoded second portion of the sample adaptive offset information from the stream of video data, the second portion being a contiguous collection of a second subset of the syntax elements including syntax element for each colour space channel; and determining the plurality of syntax elements from the decoded first and second 15 portions of the sample adaptive offset information.

2. A method according to claim 1 wherein at least one of the syntax elements of the sample adaptive offset information has data encoded in both the first and second portions. 20

3. A method according to claim 2 wherein the at least one syntax element is a sample adaptive offset type index.

4. A method according to claim 1 wherein the coding unit is a largest coding unit. 25

5. A method according to claim 1 wherein the first and second subsets contain all of the plurality of syntax elements.

6. A method according to claim I wherein the colour space channels include Y, U and V channels. 30

7. A method of determining a plurality of syntax elements of sample adaptive offset information for a coding unit from a stream of encoded video data received by a video decoder, said method being substantially as described herein with reference to any one of the embodiments, as that embodiment is illustrated in the drawings. 6432252_1 P038645_specilodge - 49

8. A computer readable storage medium having a program recorded thereon, the program being executable by computerised apparatus to perform the method of any one of the preceding claims. 5

9. A method of arranging a plurality of syntax elements of sample adaptive offset information for a coding unit into a stream of encoded video data for transmission from a video encoder, said method being a complement of the method of any one of claims 1 to 7.

10 10. A method of encoding a plurality of syntax elements of sample adaptive offset information for a coding unit into a stream of encoded video data for transmission from a video encoder, said method being substantially as described herein with reference to one of the embodiments of Figs. 4J, 4K, 6M and 6N of the drawings. 15

11. A video encoder adapted to perform the method of claim 9 or 10.

12. A computer readable storage medium having a program recorded thereon, the program being executable by computerised apparatus to perform the method of any one of claims 9 or 10. 20 Dated this 29th day of June 2012 CANON KABUSHIKI KAISHA Patent Attorneys for the Applicant Spruson&Ferguson 6432252_1 P038645_specilodge