AU2013270596A1 - Method, apparatus and system for encoding and decoding video data - Google Patents

Abstract

- 60 Abstract METHOD, APPARATUS AND SYSTEM FOR GENERATING INTRA PREDICTED SAMPLES A method of decoding a coding unit configured to use intra block copy prediction from a stream of video data, compries determining that a size of received coding unit in the stream of video data is equal to a predetermined coding unit (LCU) size. If the coding unit size is equal to the largest coding unit size, the method associates the coding unit with a plurality 10 of prediction units by partitioning the coding unit into a plurality of prediction units, and decodes a plurality of intra-block copy block vectors for the coding unit, each of the intra block copy block vectors corresponding to a prediction unit of the plurality of prediction units. A prediction of the coding unit is then formed from the plurality of associated prediction units using the corresponding intra-block copy block vectors to thereby decode 15 the coding unit. 8144749_1 P095116_speci lodge C Start )1000 L earch block vectors Encode coding unit transquant bypass flag (CuTQB flag) 1006 Encode skip flag (Cu skipjflag) Encode intra block copy flag (Intra-bc-flag) Test CU size Encode partition mode (part-mode) Encode block vectors Encode root coded block flag (Root cbf) Test root cbf flag Encode transform tree ( End )Fig. 10A

Description

- 1 METHOD, APPARATUS AND SYSTEM FOR ENCODING AND DECODING 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 video data. The 5 present invention also relates to a computer program product including a computer readable medium having recorded thereon a computer program for encoding and decoding video data. BACKGROUND Many applications for video coding currently exist, including applications for 10 transmission and storage of video data. Many video coding standards have also been developed and others are currently in development. Recent developments in video coding standardisation have led to the formation of a group called the "Joint Collaborative Team on Video Coding" (JCT-VC). The Joint Collaborative Team on Video Coding (JCT-VC) includes members of Study Group 16, Question 6 (SG16/Q6) of the Telecommunication 15 Standardisation Sector (ITU-T) of the International 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/WG 11), also known as the Moving Picture Experts Group (MPEG). 20 The Joint Collaborative Team on Video Coding (JCT-VC) has produced a new video coding standard that significantly outperforms the "H.264/MPEG-4 AVC" video coding standard. The new video coding standard has been named "high efficiency video coding (HEVC)". Further development of high efficiency video coding (HEVC) is directed towards introducing support of different representations of chroma information 25 present in video data, known as 'chroma formats', and support of higher bit-depths. The high efficiency video coding (HEVC) standard defines two profiles, known as 'Main' and 'Main1O', which support a bit-depth of eight (8) bits and ten (10) bits respectively. Further development to increase the bit-depths supported by the high efficiency video coding (HEVC) standard are underway as part of 'Range extensions' activity. Support for bit 30 depths as high as sixteen (16) bits is under study in the Joint Collaborative Team on Video Coding (JCT-VC). 8144749_1 P095116_speci lodge -2 Video data includes one or more colour channels. Typically three colour channels are supported and colour information is represented using a 'colour space'. One example colour space is known as 'YCbCr', although other colour spaces are also possible. The 'YCbCr' colour space enables fixed-precision representation of colour information and 5 thus is well suited to digital implementations. The 'YCbCr' colour space includes a 'luma' channel (Y) and two 'chroma' channels (Cb and Cr). Each colour channel has a particular bit-depth. The bit-depth defines the width of samples in the respective colour channel in bits. Generally, all colour channels have the same bit-depth, although they may also have different bit-depths. 10 In high efficiency video coding (HEVC), there are three types of prediction available: intra-prediction, intra block copy prediction and inter-prediction. Intra prediction methods allow content of one part of a video frame to be predicted from other parts of the same video frame. Intra-prediction methods typically produce a block having a directional texture, with an intra-prediction mode specifying the direction of the texture 15 and neighbouring samples within a frame used as a basis to produce the texture. Intra block copy prediction allows a block of samples from the current frame to be used as a prediction for a current block. Inter-prediction methods allow the content of a block within a video frame to be predicted from blocks in previous video frames. The previous video frames (i.e. in 'decoding order' as opposed to 'display order' which may be different) may 20 be referred to as 'reference frames'. The first video frame within a sequence of video frames typically uses intra-prediction for all blocks within the frame, as no prior frame is available for reference. Subsequent video frames may use one or more previous video frames from which to predict blocks. To maximise coding efficiency, the prediction method that produces a predicted block that is closest to captured frame data is typically 25 used. The remaining difference between the predicted block and the captured frame data is known as the 'residual'. This spatial domain representation of the difference is generally transformed into a frequency domain representation. Generally, the frequency domain representation compactly stores the information present in the spatial domain representation. The frequency domain representation includes a block of 'residual 30 coefficients' that results from applying a transform, such as an integer discrete cosine transform (DCT). Moreover, the residual coefficients (or 'scaled transform coefficients') are quantised, which introduces loss but also further reduces the amount of information required to be encoded in a bitstream. The lossy frequency domain representation of the residual, also known as 'transform coefficients', may be stored in the bitstream. The 8144749_1 P095116_speci lodge -3 amount of lossiness in the residual recovered in a decoder affects the distortion of video data decoded from the bitstream compared to the captured frame data and the size of the bitstream. A video bitstream includes a sequence of encoded syntax elements. The syntax 5 elements are ordered according to a hierarchy of 'syntax structures'. Each syntax element is composed of one or more 'bins', which are encoded using a 'context adaptive binary arithmetic coding' (CABAC) algorithm. A given bin may be 'bypass' coded, in which case there is no 'context' associated with the bin. Alternatively, a bin may be 'context' coded, in which case there is context associated with the bin. Each context coded bin has 10 one associated with the bin, selected from a set of one or more contexts. The selected context is retrieved from a context memory and each time a context is used (i.e. selected), the context is also updated and then stored back in the context memory. When encoding or decoding the bin, prior information in the bitstream is used to select which context to use. Context information in the decoder necessarily tracks context information in the encoder 15 (otherwise a decoder could not parse a bitstream produced by an encoder). The context includes two parameters: a likely bin value (or 'valMPS') and a probability level (or 'pStateldx'). A syntax element with two distinct values may also be referred to as a 'flag' and is generally encoded and decoded using one context coded bin. A syntax element with more distinct values requires more than one bin, and may use a combination of context 20 coded bins and bypass coded bins. In the high efficiency video coding (HEVC) standard, syntax elements are grouped into syntax structures. A given syntax structure defines the possible syntax elements that can be included in the video bitstream and the circumstances in which each syntax element is included in the video bitstream. Each instance of a syntax element contributes to the size of the video bitstream. An objective of video compression 25 is to enable representation of a given sequence using a video bitstream and having minimal size (e.g. in bytes) for a given quality level (including both lossy and lossless cases). At the same time, video decoders are invariably required to decode video bitstreams in real time, placing limits on the complexity of the algorithms that can be used. As such, a trade off between algorithmic complexity and compression performance is made. In particular, 30 modifications that can improve or maintain compression performance while reducing algorithmic complexity are desirable. Additionally, in some cases the flexibility provided by a particular syntax structure may place undue burden on implementations, as a decoder must be capable of decoding 8144749_1 P095116_speci lodge -4 bitstreams that include all conceivable legal combinations of syntax elements in each syntax structure. SUMMARY 5 It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements. According to one aspect of the present disclosure there is provided a method of decoding a coding unit configured to use intra block copy prediction from a stream of video data, the method comprising: 10 determining that a size of received coding unit in the stream of video data is equal to a predetermined coding unit size; associating, if the coding unit size is equal to the largest coding unit size, the coding unit with a plurality of prediction units by partitioning the coding unit into a plurality of prediction units; 15 decoding a plurality of intra-block copy block vectors for the coding unit, each of the intra-block copy block vectors corresponding to a prediction unit of the plurality of prediction units; and forming a prediction of the coding unit from the plurality of associated prediction units using the corresponding intra-block copy block vectors to thereby decode the coding 20 unit. Preferably the predetermined coding unit size is a maximum available coding unit size for the coding of the video data. Desirably the predetermined coding unit size is 64x64. Advantageously the plurality of prediction units comprise a plurality of intra block 25 copied prediction units. In a specific implementation the largest coding unit size is not equal to the size of a smallest coding unit. In another implementation the partitioning of the coding unit is a PARTNxN partition mode. 30 The method may further comprise comparing a size of the coding unit against a predetermined size and and setting a parittion mode such that a partition will never have the same size as the predetermined size. Acording to another aspect of the present disclosure there is provided a method of decoding a coding unit configured to use intra block copy prediction from a stream of 8144749_1 P095116_speci lodge -5 video data, the method comprising: determining that a size of a received coding unit in the stream of video data is equal to a maximum size for the coding of the video data; associating, if the coding unit size is equal to the maximum size, the coding unit 5 with a plurality of prediction units by partitioning the coding unit into a plurality of prediction units; decoding a plurality of intra-block copy block vectors for the coding unit, each of the intra-block copy block vectors corresponding to a prediction unit of the plurality of prediction units; and 10 forming a prediction of the coding unit from the plurality of associated prediction units using the corresponding intra-block copy block vectors to thereby decode the coding unit. Other aspects are also disclosed. 15 BRIEF DESCRIPTION OF THE DRAWINGS At least one embodiment of the present invention will now be described with reference to the following drawings and and appendices, in which: Fig. 1 is a schematic block diagram showing a video encoding and decoding system; 20 Figs. 2A and 2B form a schematic block diagram of a general purpose computer system upon which one or both of the video encoding and decoding system of Fig. 1 may be practiced; Fig. 3 is a schematic block diagram showing functional modules of a video encoder; 25 Fig. 4 is a schematic block diagram showing functional modules of a video decoder; Fig. 5A is a schematic representation of an exemplary residual quad-tree (RQT) in a coding unit (CU) within a coding tree block (CTB); Fig. 5B is a schematic representation of coding units with a PARTNxN 30 partitioning and a PART_2Nx2N partitioning; Fig. 6A is a schematic representation of an example 'Z-scan' order of scanning coding units (CUs) within a coding tree block (CTB); Fig. 6B is a schematic representation of an example coding unit (CU) predicted by a block of samples within a coding tree block (CTB); 8144749_1 P095116_speci lodge -6 Fig. 7 is a schematic representation of an example of a coding unit (CU) occupying the whole coding tree block (CTB) predicted by another coding unit (CU) of equal size; Figs. 8A, 8B, 8C, 8D are schematic representations of an example of a coding unit (CU) covering the entire coding tree block (CTB) being split into multiple square blocks 5 with each of the blocks being predicted in the intra block copy mode; Fig. 8E is a schematic representation of an example of a coding unit (CU) predicted in the intra block copy mode by a spatially overlapping block; Fig. 8F is a schematic representation of an example of a coding tree including smallest coding units (SCUs) and using PARTNxN partitioning; 10 Figs. 9A, 9B, 9C are schematic representations of coding unit (CU) syntax structures; Fig. 10A is a schematic flow diagram showing a method for encoding a coding unit (CU) with multiple intra block copy vectors into an encoded bitstream; Fig. 10B is a schematic flow diagram showing a method for encoding a coding unit 15 (CU) into an encoded bitstream with intra block copy mode prohibited for coding units having particular size(s); Fig. 10C is a schematic flow diagram showing a method for encoding a coding unit (CU) into an encoded bitstream with a partitioning mode set according to the coding unit (CU) size; 20 Fig. 10D is a schematic flow diagram showing a method 10100 for encoding a block of intra block copy reference vectors for a coding unit (CU);Fig. 1 1A is a schematic flow diagram showing a method for decoding a coding unit (CU) with multiple intra block copy vectors from an encoded bitstream; Fig. 1 1B is a schematic flow diagram showing a method for decoding a coding unit 25 from an encoded bitstream with intra block copy mode prohibited for coding units (CUs) having particular size(s); Fig. 1 1C is a schematic flow diagram showing a method for decoding a coding unit (CU) from an encoded bitstream with a partitioning mode set according to the coding unit (CU) size; 30 Fig. 11D is a schematic flow diagram showing a method 11100 for decoding a block of intra block copy reference vectors for a coding unit (CU);Fig. 12 is a schematic flow diagram showing a method for reconstructing a coding unit (CU) after decoding from an encoded bitstream; 8144749_1 P095116_speci lodge -7 Figs. 13A, 13B and 13C schematically represent a spatial layout of several coding tree blocks (CTBs) available for use in intra block copy mode, for maximum coding unit (CU) sizes of 64x64, 32x32 and 16x16 respectively; Fig. 14 schematically represents a prediction of a transform block of a transform 5 unit; and Appendix 1 and Appendix 2 provide syntax tables according to the HEVC standard modified according to the modifications and variations disclosed herein. DETAILED DESCRIPTION INCLUDING BEST MODE 10 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. Fig. 1 is a schematic block diagram showing function modules of a video encoding 15 and decoding system 100. The system 100 may utilise techniques for intra block copy to reduce complexity, improve coding efficiency and improve error resilience. The system 100 includes a source device 110 and a destination device 130. A communication channel 120 is used to communicate encoded video information from the source device 110 to the destination device 130. In some arrangements, the source device 110 and destination 20 device 130 may comprise respective mobile telephone hand-sets, in which case the communication channel 120 is a wireless channel. In other arrangements, the source device 110 and destination device 130 may comprise video conferencing equipment, in which case the communication channel 120 is typically a wired channel, such as an internet connection. Moreover, the source device 110 and the destination device 130 may 25 comprise any of a wide range of devices, including devices supporting over the air television broadcasts, cable television applications, internet video applications and applications where encoded video data is captured on some storage medium or a file server. As shown in Fig. 1, the source device 110 includes a video source 112, a video 30 encoder 114 and a transmitter 116. The video source 112 typically comprises a source of captured video frame data, such as an imaging sensor, a previously captured video sequence stored on a non-transitory recording medium, or a video feed from a remote imaging sensor. Examples of source devices 110 that may include an imaging sensor as the video source 112 include smart-phones, video camcorders and network video cameras. 8144749_1 P095116_speci lodge -8 The video encoder 114 converts the captured frame data from the video source 112 into encoded video data and will be described further with reference to Fig. 3. The encoded video data is typically an encoded bitstream and is transmitted by the transmitter 116 over the communication channel 120 as encoded video data (or "encoded video information"). 5 It is also possible for the encoded video data to be stored in some storage device, such as a "Flash" memory or a hard disk drive, until later being transmitted over the communication channel 120. The destination device 130 includes a receiver 132, a video decoder 134 and a display device 136. The receiver 132 receives encoded video data from the 10 communication channel 120 and passes received video data to the video decoder 134. The video decoder 134 then outputs decoded frame data to the display device 136. Examples of the display device 136 include a cathode ray tube, a liquid crystal display, such as in smart-phones, tablet computers, computer monitors or in stand-alone television sets. It is also possible for the functionality of each of the source device 110 and the destination 15 device 130 to be embodied in a single device. Notwithstanding the example devices mentioned above, each of the source device 110 and destination device 130 may be configured within a general purpose computing system, typically through a combination of hardware and software components. Fig. 2A illustrates such a computer system 200, which includes: a computer module 201; input 20 devices such as a keyboard 202, a mouse pointer device 203, a scanner 226, a camera 227, which may be configured as the video source 112, and a microphone 280; and output devices including a printer 215, a display device 214, which may be configured as the display device 136, and loudspeakers 217. An external Modulator-Demodulator (Modem) transceiver device 216 may be used by the computer module 201 for communicating to and 25 from a communications network 220 via a connection 221. The communications network 220, which may represent the communication channel 120, may be a wide-area network (WAN), such as the Internet, a cellular telecommunications network, or a private WAN. Where the connection 221 is a telephone line, the modem 216 may be a traditional "dial up" modem. Alternatively, where the connection 221 is a high capacity (e.g., cable) 30 connection, the modem 216 may be a broadband modem. A wireless modem may also be used for wireless connection to the communications network 220. The transceiver device 216 may provide the functionality of the transmitter 116 and the receiver 132 and the communication channel 120 may be embodied in the connection 221. 8144749_1 P095116_speci lodge -9 The computer module 201 typically includes at least one processor unit 205, and a memory unit 206. For example, the memory unit 206 may have semiconductor random access memory (RAM) and semiconductor read only memory (ROM). The computer module 201 also includes an number of input/output (1/0) interfaces including: an audio 5 video interface 207 that couples to the video display 214, loudspeakers 217 and microphone 280; an 1/0 interface 213 that couples to the keyboard 202, mouse 203, scanner 226, camera 227 and optionally a joystick or other human interface device (not illustrated); and an interface 208 for the external modem 216 and printer 215. In some implementations, the modem 216 may be incorporated within the computer module 201, 10 for example within the interface 208. The computer module 201 also has a local network interface 211, which permits coupling of the computer system 200 via a connection 223 to a local-area communications network 222, known as a Local Area Network (LAN). As illustrated in Fig. 2A, the local communications network 222 may also couple to the wide network 220 via a connection 224, which would typically include a so-called "firewall" 15 device or device of similar functionality. The local network interface 211 may comprise an EthernetTM circuit card, a BluetoothTM wireless arrangement or an IEEE 802.11 wireless arrangement; however, numerous other types of interfaces may be practiced for the interface 211. The local network interface 211 may also provide the functionality of the transmitter 116 and the receiver 132 and communication channel 120 may also be 20 embodied in the local communications network 222. The 1/0 interfaces 208 and 213 may afford either or both of serial and parallel connectivity, the former typically being implemented according to the Universal Serial Bus (USB) standards and having corresponding USB connectors (not illustrated). Storage devices 209 are provided and typically include a hard disk drive (HDD) 210. Other storage 25 devices such as a floppy disk drive and a magnetic tape drive (not illustrated) may also be used. An optical disk drive 212 is typically provided to act as a non-volatile source of data. Portable memory devices, such optical disks (e.g. CD-ROM, DVD, Blu-ray Disc TM), USB-RAM, portable, external hard drives, and floppy disks, for example, may be used as appropriate sources of data to the computer system 200. Typically, any of the HDD 210, 30 optical drive 212, networks 220 and 222 may also be configured to operate as the video source 112, or as a destination for decoded video data to be stored for reproduction via the display 214. The source device 110 and the destination device 130 of the system 100, or the source device 110 and the destination device 130 of the system 100 may be embodied in the computer system 200. 8144749_1 P095116_speci lodge - 10 The components 205 to 213 of the computer module 201 typically communicate via an interconnected bus 204 and in a manner that results in a conventional mode of operation of the computer system 200 known to those in the relevant art. For example, the processor 205 is coupled to the system bus 204 using a connection 218. Likewise, the 5 memory 206 and optical disk drive 212 are coupled to the system bus 204 by connections 219. Examples of computers on which the described arrangements can be practised include IBM-PC's and compatibles, Sun SPARCstations, Apple MacTM or alike computer systems. Where appropriate or desired, the video encoder 114 and the video decoder 134, as 10 well as methods described below, may be implemented using the computer system 200 wherein the video encoder 114, the video decoder 134 and methods to be described, may be implemented as one or more software application programs 233 executable within the computer system 200. In particular, the video encoder 114, the video decoder 134 and the steps of the described methods are effected by instructions 231 (see Fig. 2B) in the 15 software 233 that are carried out within the computer system 200. The software instructions 231 may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part and the corresponding code modules performs the described methods and a second part and the corresponding code modules manage a user interface between the first 20 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 200 from the computer readable medium, and then executed by the computer system 200. A computer readable medium having such software or computer program recorded on the 25 computer readable medium is a computer program product. The use of the computer program product in the computer system 200 preferably effects an advantageous apparatus for implementing the video encoder 114, the video decoder 134 and the described methods. The software 233 is typically stored in the HDD 210 or the memory 206. The software is loaded into the computer system 200 from a computer readable medium, and 30 executed by the computer system 200. Thus, for example, the software 233 may be stored on an optically readable disk storage medium (e.g., CD-ROM) 225 that is read by the optical disk drive 212. In some instances, the application programs 233 may be supplied to the user encoded on one or more CD-ROMs 225 and read via the corresponding drive 212, or 8144749_1 P095116_speci lodge - 11 alternatively may be read by the user from the networks 220 or 222. Still further, the software can also be loaded into the computer system 200 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 200 for 5 execution and/or processing. Examples of such storage media include floppy disks, TM 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 201. Examples of transitory or non-tangible computer readable 10 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 401 include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like. 15 The second part of the application programs 233 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 214. Through manipulation of typically the keyboard 202 and the mouse 203, a user of the computer system 200 and the application may manipulate the interface in a functionally adaptable 20 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 217 and user voice commands input via the microphone 280. Fig. 2B is a detailed schematic block diagram of the processor 205 and a 25 "memory" 234. The memory 234 represents a logical aggregation of all the memory modules (including the HDD 209 and semiconductor memory 206) that can be accessed by the computer module 201 in Fig. 2A. When the computer module 201 is initially powered up, a power-on self-test (POST) program 250 executes. The POST program 250 is typically stored in a ROM 249 30 of the semiconductor memory 206 of Fig. 2A. A hardware device such as the ROM 249 storing software is sometimes referred to as firmware. The POST program 250 examines hardware within the computer module 201 to ensure proper functioning and typically checks the processor 205, the memory 234 (209, 206), and a basic input-output systems software (BIOS) module 251, also typically stored in the ROM 249, for correct operation. 8144749_1 P095116_speci lodge - 12 Once the POST program 250 has run successfully, the BIOS 251 activates the hard disk drive 210 of Fig. 2A. Activation of the hard disk drive 210 causes a bootstrap loader program 252 that is resident on the hard disk drive 210 to execute via the processor 205. This loads an operating system 253 into the RAM memory 206, upon which the operating 5 system 253 commences operation. The operating system 253 is a system level application, executable by the processor 205, to fulfil various high level functions, including processor management, memory management, device management, storage management, software application interface, and generic user interface. The operating system 253 manages the memory 234 (209, 206) to ensure that each 10 process or application running on the computer module 201 has sufficient memory in which to execute without colliding with memory allocated to another process. Furthermore, the different types of memory available in the computer system 200 of Fig. 2A must be used properly so that each process can run effectively. Accordingly, the aggregated memory 234 is not intended to illustrate how particular segments of memory 15 are allocated (unless otherwise stated), but rather to provide a general view of the memory accessible by the computer system 200 and how such is used. As shown in Fig. 2B, the processor 205 includes a number of functional modules including a control unit 239, an arithmetic logic unit (ALU) 240, and a local or internal memory 248, sometimes called a cache memory. The cache memory 248 typically 20 includes a number of storage registers 244-246 in a register section. One or more internal busses 241 functionally interconnect these functional modules. The processor 205 typically also has one or more interfaces 242 for communicating with external devices via the system bus 204, using a connection 218. The memory 234 is coupled to the bus 204 using a connection 219. 25 The application program 233 includes a sequence of instructions 231 that may include conditional branch and loop instructions. The program 233 may also include data 232 which is used in execution of the program 233. The instructions 231 and the data 232 are stored in memory locations 228, 229, 230 and 235, 236, 237, respectively. Depending upon the relative size of the instructions 231 and the memory locations 228 30 230, a particular instruction may be stored in a single memory location as depicted by the instruction shown in the memory location 230. Alternately, an instruction may be segmented into a number of parts each of which is stored in a separate memory location, as depicted by the instruction segments shown in the memory locations 228 and 229. 8144749_1 P095116_speci lodge - 13 In general, the processor 205 is given a set of instructions which are executed therein. The processor 205 waits for a subsequent input, to which the processor 205 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 5 devices 202, 203, data received from an external source across one of the networks 220, 202, data retrieved from one of the storage devices 206, 209 or data retrieved from a storage medium 225 inserted into the corresponding reader 212, all depicted in Fig. 2A. 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 234. 10 The video encoder 114, the video decoder 134 and the described methods may use input variables 254, which are stored in the memory 234 in corresponding memory locations 255, 256, 257. The video encoder 114, the video decoder 134 and the described methods produce output variables 261, which are stored in the memory 234 in corresponding memory locations 262, 263, 264. Intermediate variables 258 may be stored 15 in memory locations 259, 260, 266 and 267. Referring to the processor 205 of Fig. 2B, the registers 244, 245, 246, the arithmetic logic unit (ALU) 240, and the control unit 239 work together to perform sequences of micro-operations needed to perform "fetch, decode, and execute" cycles for every instruction in the instruction set making up the program 233. Each fetch, decode, 20 and execute cycle comprises: (a) a fetch operation, which fetches or reads an instruction 231 from a memory location 228, 229, 230; (b) a decode operation in which the control unit 239 determines which instruction has been fetched; and 25 (c) an execute operation in which the control unit 239 and/or the ALU 240 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 239 stores or writes a value to a memory location 232. 30 Each step or sub-process in the methods Figs. 10A, 10B, 10C, 10D, 1 1A, 11B, 1 1C, 11D, to be described is associated with one or more segments of the program 233 and is typically performed by the register section 244, 245, 247, the ALU 240, and the control unit 239 in the processor 205 working together to perform the fetch, decode, and execute 8144749_1 P095116_speci lodge -14 cycles for every instruction in the instruction set for the noted segments of the program 233. Fig. 3 is a schematic block diagram showing functional modules of the video encoder 114. Fig. 4 is a schematic block diagram showing functional modules of the video 5 decoder 134. Generally, data is passed between functional modules within the video encoder 114 and the video decoder 134 in blocks or arrays (e.g., blocks of samples or blocks of transform coefficients). Where a functional module is described with reference to the behaviour of individual array elements (e.g., samples or a transform coefficients), the behaviour shall be understood to be applied to all array elements. The video encoder 10 114 and video decoder 134 may be implemented using a general-purpose computer system 200, as shown in Figs. 2A and 2B, where the various functional modules may be implemented by dedicated hardware within the computer system 200, by software executable within the computer system 200 such as one or more software code modules of the software application program 233 resident on the hard disk drive 205 and being 15 controlled in its execution by the processor 205, or alternatively by a combination of dedicated hardware and software executable within the computer system 200. The video encoder 114, the video decoder 134 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 20 include graphic processors, digital signal processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) or one or more microprocessors and associated memories. In particular the video encoder 114 comprises modules 320-348 and the video decoder 134 comprises modules 420-436 which may each be implemented as one or more software code modules of the software application program 233. 25 Although the video encoder 114 of Fig. 3 is an example of a high efficiency video coding (HEVC) video encoding pipeline, other video codecs may also be used to perform the processing stages described herein. The video encoder 114 receives captured frame data, such as a series of frames, each frame including one or more colour channels. The video encoder 114 divides each frame of the captured frame data, such as 30 frame data 310, into regions generally referred to as 'coding tree units' (CTUs) with side sizes which are powers of two. The notion of coding tree unit (CTU) refers collectively to all colour channels of the picture. Every coding tree unit (CTU) includes individual coding tree blocks (CTBs) for each colour channel. For example in a frame coded using the YCbCr colour space, a coding tree unit (CTU) will consist of tree coding tree blocks 8144749_1 P095116_speci lodge - 15 (CTBs) for Y, Cb and Cr colour planes corresponding to the same spatial location in the picture. The size of individual coding tree blocks (CTBs) may vary across colour components and generally will depend on used colour component scaling mode. For example in the mode generally known as "4:4:4" mode where all colour components have 5 the same size, the sizes of the coding tree blocks (CTBs) will be the same. In the mode generally known as "4:2:0" where chroma components are scaled down by factor of two both horizontally and vertically the sizes of chroma coding tree blocks (CTBs) will be twice smaller (both horizontally and vertically) than the size of the luma coding tree block (CTB). When a size of a coding tree unit (CTU) is specified it usually refers to the size of 10 the luma coding tree block (CTB). The sizes of the chroma coding tree blocks (CTBs) can always be inferred from the size of the coding tree unit (CTU) and the colour component scaling mode. Each coding tree unit (CTU) includes a hierarchical quad-tree subdivision of a portion of the frame with a collection of 'coding units' (CUs), such that at each leaf node 15 of the hierarchical quad-tree subdivision one coding unit (CU) exists. The subdivision can be continued until the coding units (CU) present at the leaf nodes have a specific minimum size is reached. This size is referred to as a smallest coding unit (SCU) size. Generally, the smallest coding unit (SCU) size is 8x8, but other sizes are also possible, such as 16x16 or 32x32. Note that the size of a coding unit (CU) is specified in units of luma samples. The 20 corresponding coding block (CB) for the luma channel will thus have the same dimensions as the coding unit (CU). The corresponding coding blocks (CBs) for the chroma channels will have dimensions scaled according to the chroma subsampling size. For example, when a 4:2:0 chroma format is in use, an 8x8 coding unit (CU) includes a 4x4 coding block (CBs) for each chroma channel. The smallest coding unit (SCU) size is specified using a 25 'log2_minlumacoding blocksizeminus3' syntax element in the high level syntax. Smallest coding unit (SCU) sizes of 8x8, 16x16 and 32x32 are indicated with values of 0, 1, 2 respectively for this syntax element. If on the other hand no subdivision of a coding tree unit (CTU) is done and a single coding unit (CU) occupies the whole coding tree unit (CTU) such a coding unit (CU) is referred to as a largest coding unit (LCU) (or "maximum 30 coding unit size). Generally the largest coding unit (LCU) size is 64x64, but other sizes are also possible, such as 32x32 and 16x16. These dimensions are also specified in units of luma samples. The largest coding unit (LCU) size is signalled in the bitstream using a 'log2_diffmax_minlumacodingblocksize' syntax element in combination with the 'log2_min-lumacodingblocksizeminus3' syntax element (both in high level syntax). 8144749_1 P095116_speci lodge - 16 The sum of these two syntax elements having values of 0, 1, 2, 3 indicates a largest coding unit (LCU) size of 8x8, 16x16, 32x32 and 64x64 respectively. In specific implementations, the size of the largest coding unit is not equal to the size of the smallest coding unit. As a result of the quad-tree hierarchy, the entirety of the coding tree unit 5 (CTU) is occupied by one or more coding units (CUs). The largest coding unit size is signalled in the bitstream for a collection of frames known as a coded video sequence. Bitstreams may have various largest coding unit sizes and where multiple coded video sequences are present within one bitstream, multiple largest coding unit (LCU) sizes may exist within the one bitstream. For a given frame, the largest coding unit (LCU) size and 10 the smallest coding unit (SCU) size do not vary. A quad-tree subdivision of a coding tree unit (CTU) implies subdivision of coding tree blocks (CTBs) for each colour channel into four 'coding blocks' (CBs) of equal size. For example if a coding tree unit (CTU) of a frame encoded using the "4:2:0" colour component scaling mode, of size 64x64 samples is split, this will imply that a 15 corresponding luma coding tree block (CTB) is split into four coding blocks (CBs) of 32x32 samples, and a corresponding chroma coding tree blocks (CTBs) (having size of 32x32 samples) will be split into four coding blocks (CBs) of 16x16 samples. Coding blocks (CBs) corresponding to smallest coding units (SCUs) are referred to as smallest coding blocks (SCBs). Coding blocks (CBs) corresponding to largest coding units (LCUs) 20 are referred to as largest coding blocks (LCBs). In the HEVC standard a coding tree unit (CTU) has size 64x64 samples, although other sizes are possible, such as 16x16 or 32x32. In some cases even larger sizes for the coding tree unit (CTU), such as 128x128 samples, may be used. The video encoder 114 produces one or more 'prediction units' (PUs) for each 25 coding block (CU). Various arrangements of prediction units (PUs) in each coding unit (CU) are possible, with a requirement that the prediction units (PUs) do not overlap and that the entirety of the coding unit (CU) is occupied by the one or more prediction units (PUs). Such a requirement ensures that the prediction units (PUs) cover the entire frame area. A partitioning of a coding unit (CU) into prediction units (PUs) implies subdivision 30 of coding blocks (CBs) for each colour component into 'prediction blocks' (PBs). Depending on used colour component scaling mode, the sizes of prediction blocks (PBs) corresponding to the same coding unit (CU) for different colour component may differ in size. 8144749_1 P095116_speci lodge - 17 The video encoder 114 operates by outputting, from a multiplexer module 340, a prediction unit (PU) 382. A difference module 344 produces a 'residual sample array' 360. The residual sample array 360 is the difference between the prediction unit (PU) 382 and a corresponding 2D array of data samples from a coding unit (CU) of the coding tree block 5 (CTB) of the frame data 310. The difference is calculated for corresponding samples at each location in the arrays. As differences may be positive or negative, the dynamic range of one difference sample is the bit-depth plus one bit. The residual sample array 360 may be transformed into the frequency domain in a transform module 320. The residual sample array 360 from the difference module 344 is 10 received by the transform module 320, which converts the residual sample array 360 from a spatial representation to a frequency domain representation by applying a 'forward transform'. The transform module 320 creates transform coefficients, according to a transform having a specific precision. The coding unit (CU) is sub-divided into one or more transform units (TUs). The sub-divided coding unit (CU) may be referred to as a 15 'residual quad-tree' or a 'residual quad-tree (RQT)'. The notion of transform unit (TU) refers collectively to all colour components. Every transform unit (TU) includes individual transform blocks (TBs) for each colour channel. Depending on the colour component scaling mode applied to the picture transform blocks (TBs) for chroma channels may have smaller sizes than a corresponding luma transform block (TB) due to colour component 20 scaling. The quantiser control module 346 may test the bit-rate required in the encoded bitstream 312 for various possible quantisation parameter values according to a 'rate distortion criterion'. The rate-distortion criterion is a measure of the acceptable trade-off between the bit-rate of the encoded bitstream 312, or a local region thereof, and distortion. 25 Distortion is a measure of the difference between frames present in the frame buffer 332 and the captured frame data 310. Distortion may be determined using a peak signal to noise ratio (PSNR) or sum of absolute differences (SAD) metric. In some arrangements of the video encoder 114, the rate-distortion criterion considers only the rate and distortion for the luma colour channel and thus the encoding decision is made based on characteristics of 30 the luma channel. Generally, the residual quad-tree (RQT) is shared between the luma and chroma colour channels, and the amount of chroma information is relatively small compared to luma, so considering luma only in the rate-distortion criterion may be appropriate. 8144749_1 P095116_speci lodge - 18 A quantisation parameter 384 is output from the quantiser control module 346. The quantisation parameter may be fixed for a frame of video data, or may vary on a block by block basis as the frame is being encoded. Other methods for controlling the quantisation parameter 384 are also possible. The set of possible transform units (TUs) for a residual 5 quad-tree is dependent on the available transform sizes and coding unit (CU) size. In one arrangement, the residual quad-tree results in a lower bit-rate in the encoded bitstream 312, thus achieving higher coding efficiency. A larger sized transform unit (TU) results in use of larger transforms for both the luma and chroma colour channels. Generally, larger transforms provide a more compact representation of a residual sample array with sample 10 data (or 'residual energy') spread across the residual sample array. Smaller transform units (TUs) provide a more compact representation of a residual sample array with residual energy localised to specific regions of the residual sample array. Thus, the many possible configurations of a residual quad-tree (RQT) provide a useful means for achieving high coding efficiency of the residual sample array 360 in the high efficiency video coding 15 (HEVC) standard. A transform control module 348 selects a transform size for use in encoding each leaf node of the residual quad-tree (RQT). For example, a variety of transform sizes (and hence residual quad-tree configurations) may be tested and the transform size resulting in the best trade-off from a rate-distortion criteria may be selected. A transform size 386 20 represents the size of the selected transform. The transform size 386 is encoded in the encoded bitstream 312 and provided to the transform module 320, the quantiser module 322, the dequantiser module 326 and the inverse transform module 328. The transform size 386 may be represented by the transform dimensions (e.g. 4x4, 8x8, 16x16 or 32x32), the transform size (e.g. 4, 8, 16 or 32), or the log2 of the transform size (e.g. 2, 3, 4 or 5) 25 interchangeably. In circumstances where the numeric value of a particular representation of a transform size is used (e.g. in an equation) conversion from any other representation of the transform size deemed necessary, shall be considered to implicitly occur in the following description. A 'transform quantisation bypass' mode is provided, where the transform module 30 320 and the quantisation module 322 are bypassed. The transform quantisation bypass mode is signalled at the coding unit (CU) level using a 'cu transquant bypass flag' syntax element. The transform quantisation bypass mode provides a means to losslessly encode the frame data 310 in the encoded bitstream 312. Use of the transform quantisation bypass mode is controlled at the coding unit (CU) level, allowing portions of the frame data 310 to 8144749_1 P095116_speci lodge - 19 be losslessly encoded. The availability of the transform quantisation bypass mode is controlled via 'high level syntax', enabling the signalling overhead of controlling transform quantisation bypass mode to be removed in cases where lossless encoding is not required in any portion of the frame data 310. High level syntax refers to portions of the 5 encoded bitstream 312 that are generally encoded infrequently and are used to describe properties of the bitstream (e.g. to restrict or otherwise configure particular coding tools used in the video encoder 114 and the video decoder 134). Examples of high level syntax include 'sequence parameter sets', 'picture parameter sets' and 'slice headers'. For the high efficiency video coding (HEVC) standard, conversion of the residual 10 sample array 360 to the frequency domain representation is implemented using a transform such as a modified discrete cosine transform (DCT). In such transforms, the modification permits implementation using shifts and additions instead of multiplications. Such modifications enable reduced implementation complexity compared to a discrete cosine transform (DCT). In addition to the modified discrete cosine transform (DCT), a modified 15 discrete sine transform (DST) may also be used in specific circumstances. Various sizes of the residual sample array 360 and the scaled transform coefficients 362 are possible, in accordance with supported transform sizes. In the high efficiency video coding (HEVC) standard, transforms are performed on 2D arrays of data samples having sizes, such as 32x32, 16x16, 8x8 and 4x4. Thus, a predetermined set of transform sizes are available to 20 the video encoder 114. Moreover, the set of transform sizes may differ between the luma channel and the chroma channels. Two-dimensional transforms are generally configured to be 'separable', enabling implementation as a first set of 1D transforms operating on the 2D array of data samples in one direction (e.g. on rows). The first set of 1D transforms is followed by a second set of 25 1D transform operating on the 2D array of data samples output from the first set of 1D transforms in the other direction (e.g. on columns). Transforms having the same width and height are generally referred to as 'square transforms'. Additional transforms, having differing widths and heights may also be used and are generally referred to as 'non-square transforms'. The row and column one-dimensional transforms may be combined into 30 specific hardware or software modules, such as a 4x4 transform module or an 8x8 transform module. Transforms having larger dimensions require larger amounts of circuitry to implement, even though such larger dimensioned transforms may be infrequently used. Accordingly, the high efficiency video coding (HEVC) standard defines a maximum 8144749_1 P095116_speci lodge - 20 transform size of 32x32 luma samples. Transforms may be applied to both the luma and chroma channels. Differences between the handling of luma and chroma channels with regard to transform units (TUs) exist. Each residual quad-tree occupies one coding unit (CU) and is defined as a quad-tree decomposition of the coding unit (CU) into a hierarchy 5 including one transform unit (TU) at each leaf node of the residual quad-tree hierarchy. Each transform unit (TU) has dimensions corresponding to one of the supported transform sizes. Similarly to the coding tree unit (CTU), it is necessary for the entirety of the coding unit (CU) to be occupied by one or more transform units (TUs). At each level of the residual quad-tree hierarchy a 'coded block flag value' signals possible presence of a 10 transform in each colour channel. The signalling may indicate presence of a transform at the current hierarchy level (when no further splits are present), or that lower hierarchy levels may contain at least one transform among the resulting transform units (TUs). When the coded block flag value is zero, all residual coefficients at the present or lower hierarchy levels are known to be zero. In such a case, no transform is required to be 15 performed for the corresponding colour channel of any transform units (TU) at the present hierarchical level or at lower hierarchical levels. When the coded block flag value is one, if the present region is not further sub-divided then the region contains a transform which requires at least one non-zero residual coefficient. If the present region is further sub divided, a coded block flag value of one indicates that each resulting sub-divided region 20 may include non-zero residual coefficients. In this manner, for each colour channel, zero or more transforms may cover a portion of the area of the coding unit (CU) varying from none up to the entirety of the coding unit (CU). Separate coded block flag values exist for each colour channel. Each coded block flag value is not required to be encoded, as cases exist where there is only one possible coded block flag value. 25 The scaled transform coefficients 362 are input to the quantiser module 322 where data sample values thereof are scaled and quantised, according to a determined quantisation parameter 384, to produce transform coefficients 364. The transform coefficients 364 are an array of values having the same dimensions as the residual sample array 360. The transform coefficients 364 provide a frequency domain representation of 30 the residual sample array 360 when a transform is applied. When the transform is skipped, the transform coefficients 364 provide a spatial domain representation of the residual sample array 360 (i.e. quantised by the quantiser module 322 but not transformed by the transform module 320). For the discrete cosine transform (DCT), the upper-left value of the transform coefficients 364 specifies a 'DC' value for the residual sample array 360 and 8144749_1 P095116_speci lodge - 21 is known as a 'DC coefficient'. The DC coefficient is representative of the 'average' of the values of the residual sample array 360. Other values in the transform coefficients 364 specify 'AC coefficients' for the residual sample array 360. The scale and quantisation results in a loss of precision, dependent on the value of the determined quantisation 5 parameter 384. A higher value of the determined quantisation parameter 384 results in greater information being lost from the residual data. The loss of information increases the compression achieved by the video encoder 114, as there is less information to encode. This increase in compression efficiency occurs at the expense of reducing the visual quality of output from the video decoder 134. The determined quantisation parameter 384 10 may be adapted during encoding of each frame of the frame data 310. Alternatively, the determined quantisation parameter 384 may be fixed for a portion of the frame data 310. In one arrangement, the determined quantisation parameter 384 may be fixed for an entire frame of frame data 310. Other adaptations of the determined quantisation parameter 384 are also possible, such as quantising different residual coefficients with separate values. 15 The transform coefficients 364 and determined quantisation parameter 384 are taken as input to the dequantiser module 326. The dequantiser module 326 reverses the scaling performed by the quantiser module 322 to produce rescaled transform coefficients 366. The rescaled transform coefficients are rescaled versions of the transform coefficients 364. The transform coefficients 364, the determined quantisation parameter 384, the 20 transform size 386 and the bit-depth 390 are also taken as input to an entropy encoder module 324. The entropy encoder module 324 encodes the values of the transform coefficients 364 in an encoded bitstream 312 (or 'video bitstream'). Due to the loss of precision resulting from the operation of the quantiser module 322, the rescaled transform coefficients 366 are not identical to the original values in the scaled transform coefficients 25 362. The rescaled transform coefficients 366 from the dequantiser module 326 are then output to an inverse transform module 328. The inverse transform module 328 performs an inverse transform from the frequency domain to the spatial domain to produce a spatial domain representation 368 of the rescaled transform coefficients 366. The spatial-domain representation 368 is substantially identical to a spatial domain representation that is 30 produced at the video decoder 134. The spatial-domain representation 368 is then input to a summation module 342. A motion estimation module 338 produces motion vectors 374 by comparing the frame data 310 with previous frame data from one or more sets of frames stored in a frame buffer module 332, generally configured within the memory 206. The sets of frames are 8144749_1 P095116_speci lodge - 22 known as 'reference picture lists'. The motion vectors 374 are then input to a motion compensation module 334 which produces an inter-predicted prediction unit (PU) 376 by filtering data samples stored in the frame buffer module 332, taking into account a spatial offset derived from the motion vectors 374. Not illustrated in Fig. 3, the motion vectors 5 374 are also passed to the entropy encoder module 324 for encoding in the encoded bitstream 312. The motion vectors are encoded as 'motion vector differences', i.e. differences between the motion vector for a current block and a neighbouring block. The intra-frame prediction module 336 produces an intra-predicted prediction unit (PU) 378 using samples 370 obtained from the summation module 342. In particular, the intra-frame 10 prediction module 336 uses samples from neighbouring blocks that have already been decoded to produce intra-predicted samples for the current prediction unit (PU). When a neighbouring block is not available (e.g. at the frame boundary) the neighbouring samples are considered as 'not available' for reference. In such cases, a default value is used instead of the neighbouring sample values. Typically, the default value (or 'half-tone') is 15 equal to half of the range implied by the bit-depth. For example, when the video encoder 114 is configured for a bit-depth of eight (8), the default value is 128. The summation module 342 sums the prediction unit (PU) 382 from the multiplexer module 340 and the spatial domain output of the multiplexer 382. The intra-frame prediction module 336 also produces an intra-prediction mode 380 which is sent to the entropy encoder 324 for 20 encoding into the encoded bitstream 312. An intra block copy module 350 tests various block vectors to produce an optimal reference block for the prediction unit (PU) 382, which may be referred to as intra block copied prediction units. The reference block includes a block of samples 370 obtained from the current coding tree block (CTB) and/or the previous coding tree block (CTB). The 25 reference block cannot include samples from any coding blocks (CBs) in the current coding tree block (CTB) that have not yet been decoded (and hence are not available in the samples 370). A block vector is a two-dimensional vector into the pair of coding tree blocks (CTBs). The intra block copy module 350 may test every valid block vector by conducting a search using a nested loop. Faster approaches to the search are also possible. 30 The intra block copy module 350 may reduce the search complexity by only searching for block vectors aligned horizontally or vertically to the current coding block (CU), near horizontal and near-vertical block vectors may also be searched. The intra block copy module 350 may test a spatially sparse set of block vectors and then perform a refined search in the neighbourhood of the optimal one of the sparse block vectors to produce a 8144749_1 P095116_speci lodge - 23 final block vector. Entropy coding the block vector has an associated cost, or rate. One approach to entropy coding the block vector is to reuse the motion vector delta (i.e. 'mvdcoding') syntax structure. This syntax structure permits encoding a two-dimensional signed vector and is thus suitable for a block vector. The block vector may be coded 5 directly into the bitstream using the motion vector delta syntax structure. Alternatively, correlations between adjacent block vectors may be exploited. For example, the delta (difference) between the block vector of successive blocks using the intra block copy mode may be coded into the encoded bitstream 312. In such cases, the decoder can reconstruct the block vector for a given coding block (CB) by adding the decoded delta block vector to 10 the block vector of the previous coding block (CTB) to use intra block copy mode. Finally, an 'intra bc flag' syntax element signals that a given coding block (CB) uses the intra block copy mode. The mvddelta syntax structure encodes smaller magnitude vectors more compactly than larger magnitude vectors. Consequently, in the rate measurement, a bias towards selecting nearby reference blocks is introduced. A given 15 block vector results in a particular reference block having a particular distortion. The rate distortion trade-off is applied to determine the optimal block vector for an intra block copy mode. An overall rate distortion trade-off may compare the result for the intra block copy mode with the result for other prediction methods, such as inter-prediction and intra prediction. 20 Prediction units (PUs) may be generated using either an intra-prediction, an inter prediction of an intra-block copy method. Intra-prediction methods make use of data samples adjacent to the prediction unit (PU) that have previously been decoded (typically above and to the left of the prediction unit) in order to generate reference data samples within the prediction unit (PU). Various directions of intra-prediction are possible (33 25 directions in total), a 'DC mode' and a 'planar mode' are supported, for a total of 35 possible intra-prediction modes. Inter-prediction methods make use of a motion vector to refer to a block from a selected reference frame. The motion estimation module 338 and motion compensation module 334 operate on motion vectors 374, having a precision of one eighth (1/8) of a luma sample, enabling precise modelling of motion between frames in 30 the frame data 310. The decision on which of the intra-prediction, the inter-prediction or the intra block copy method to use is made according to a rate-distortion trade-off. The trade-off is made between the desired bit-rate of the resulting encoded bitstream 312 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 8144749_1 P095116_speci lodge - 24 the set of possible intra-prediction modes, also according to a rate-distortion trade-off. The multiplexer module 340 may select either the intra-predicted reference samples 378 from the intra-frame prediction module 336, or the inter-predicted prediction unit (PU) 376 from the motion compensation block 334. 5 The summation module 342 produces a sum 370 that is input to a de-blocking filter module 330. The de-blocking filter module 330 performs filtering along block boundaries, producing de-blocked samples 372 that are written to the frame buffer module 332 configured within the memory 206. The frame buffer module 332 is a buffer with sufficient capacity to hold data from one or more past frames for future reference as part of 10 a reference picture list. For the high efficiency video coding (HEVC) standard, the encoded bitstream 312 produced by the entropy encoder 324 is delineated into network abstraction layer (NAL) units. Frames are encoded using one or more 'slices'. Two types of slice are defined, 'independent slice segments' and 'dependent slice segments'. Generally, each slice of a 15 frame is contained in one NAL unit. The entropy encoder 324 encodes the transform coefficients 364, the intra-prediction mode 380, the motion vectors (or motion vector differences) and other parameters, collectively referred to as 'syntax elements', into the encoded bitstream 312 by performing a context adaptive binary arithmetic coding (CABAC) algorithm. Syntax elements are grouped together into 'syntax structures'. The 20 groupings may contain recursion to describe hierarchical structures. In addition to ordinal values, such as an intra-prediction mode or integer values, such as a motion vector, syntax elements also include flags, such as to indicate a quad-tree split. The video encoder 114 also divides a frame into one or more 'tiles'. Each tile is a rectangular set of coding tree blocks (CTBs) that may be encoded and decoded 25 independently, facilitating parallel implementations. Within each tile, coding tree blocks (CTBs) are scanned in a raster order and a single core (or thread) implementation scans the tiles in raster scan order. To enable parallel implementation, intra-prediction of blocks along a tile boundary may not use samples from blocks in a neighbouring tile. As such, the neighbouring samples are marked as not available for intra-prediction (even though the 30 sample values do exist). Although the video decoder 134 of Fig. 4 is described with reference to a high efficiency video coding (HEVC) video decoding pipeline, other video codecs may also employ the processing stages of modules 420-434. The encoded video information may also be read from memory 206, the hard disk drive 210, a CD-ROM, a Blu-ray diskTM or 8144749_1 P095116_speci lodge - 25 other computer readable storage medium. Alternatively the encoded video information may be received from an external source, such as a server connected to the communications network 220 or a radio-frequency receiver. As seen in Fig. 4, received video data, such as the encoded bitstream 312, is input 5 to the video decoder 134. The encoded bitstream 312 may be read from memory 206, the hard disk drive 210, a CD-ROM, a Blu-ray diskTM or other computer readable storage medium. Alternatively the encoded bitstream 312 may be received from an external source such as a server connected to the communications network 220 or a radio-frequency receiver. The encoded bitstream 312 contains encoded syntax elements representing the 10 captured frame data to be decoded. The encoded bitstream 312 is input to an entropy decoder module 420 which extracts the syntax elements from the encoded bitstream 312 and passes the values of the syntax elements to other blocks in the video decoder 134. The entropy decoder module 420 applies the context adaptive binary arithmetic coding (CABAC) algorithm to decode 15 syntax elements from the encoded bitstream 312. The decoded syntax elements are used to reconstruct parameters within the video decoder 134. Parameters include zero or more residual data array 450, motion vectors 452 (motion vector differences are decoded from the encoded bitstream 312 and from these, the motion vectors 452 are derived), a prediction mode 454, a quantisation parameter 468, a transform size 470 and a bit-depth 20 472. The transform size 470 was encoded in the encoded bitstream 312 by the video encoder 114 according to the transform size 386. The bit-depth 472 was encoded in the encoded bitstream 312 by the video encoder 114 according to the bit-depth 390. The quantisation parameter 468 was encoded in the encoded bitstream 312 by the video encoder 114 according to the quantisation parameter 384. Thus the transform size 470 is 25 equal to the transform size 386, the bit-depth 472 is equal to the bit-depth 390 and the quantisation parameter 468 is equal to the quantisation parameter 384. The residual data array 450 is passed to a dequantiser module 421, the motion vectors 452 are passed to a motion compensation module 434, and the prediction mode 454 is passed to an intra-frame prediction module 426 and to a multiplexer 428. 30 The dequantiser module 421 performs inverse scaling on the residual data of the residual data array 450 to create reconstructed data 455 in the form of transform coefficients. The dequantiser module 421 outputs the reconstructed data 455 to an inverse transform module 422. The inverse transform module 422 applies an 'inverse transform' to convert the reconstructed data 455 (i.e., the transform coefficients) from a frequency 8144749_1 P095116_speci lodge - 26 domain representation to a spatial domain representation, outputting a residual sample array 456 via a multiplexer module 423. The inverse transform module 422 performs the same operation as the inverse transform module 328. The inverse transform module 422 is configured to perform inverse transforms sized in accordance with the transform size 470 5 having a bit-depth according to the bit-depth 472. The transforms performed by the inverse transform module 422 are selected from a predetermined set of transform sizes required to decode an encoded bitstream 312 that is compliant with the high efficiency video coding (HEVC) standard. The motion compensation module 434 uses the motion vectors 452 from the 10 entropy decoder module 420, combined with reference frame data 460 from a frame buffer block 432, configured within the memory 206, to produce an inter-predicted prediction unit (PU) 462 for a prediction unit (PU). The inter-prediction prediction unit (PU) 462 is a prediction of output decoded frame data based upon previously decoded frame data. When the prediction mode 454 indicates that the current prediction unit (PU) was coded using 15 intra-prediction, the intra-frame prediction module 426 produces an intra-predicted prediction unit (PU) 464 for the prediction unit (PU). The intra-prediction prediction unit (PU) 464 is produced using data samples spatially neighbouring the prediction unit (PU) and a prediction direction also supplied by the prediction mode 454. The spatially neighbouring data samples are obtained from a sum 458, output from a summation module 20 424. An intra block copy module 436 produces a block of reference samples 438, by copying an array of samples from the current and/or the previous coding tree blocks (CTBs). The offset of the reference samples is calculated by adding a block vector (decoded by the entropy decoder 420) to the location of the current coding block (CB) within the current coding tree block (CTB). The multiplexer module 428 selects the intra 25 predicted prediction unit (PU) 464 or the inter-predicted prediction unit (PU) 462 for a prediction unit (PU) 466 or a reference block 438 from the intra block copy module 436, depending on the current prediction mode 454. The prediction unit (PU) 466, which is output from the multiplexer module 428, is added to the residual sample array 456 from the inverse scale and transform module 422 by the summation module 424 to produce sum 30 458. The sum 458 is then input to each of a de-blocking filter module 430, the intra-frame prediction module 426 and the intra block copy module 436. The de-blocking filter module 430 performs filtering along data block boundaries, such as transform unit (TU) boundaries, to smooth visible artefacts. The output of the de-blocking filter module 430 is written to the frame buffer module 432 configured within the memory 206. The frame 8144749_1 P095116_speci lodge -27 buffer module 432 provides sufficient storage to hold one or more decoded frames for future reference. Decoded frames 412 are also output from the frame buffer module 432 to a display device, such as the display device 136 (e.g., in the form of the display device 214). 5 Fig. 5A is a schematic representation of an exemplary residual quad-tree (RQT) 500 within a coding block (CB) of 32x32 samples of an individual colour component. In the encoded bitstream 312 the residual quad-tree (RQT) hierarchy of a coding unit (CU) is specified using split transform-flag syntax elements. At a given node in the residual quad-tree (RQT) hierarchy, a splitjtransform flag syntax element indicates if the node is 10 further subdivided into another four nodes. Leaf nodes of the residual quad-tree (RQT) represent spatial regions sized according to one of the supported transform sizes. The splitjtransform flag syntax element in some cases may be inferred. E.g. if the current coding unit (CU) size is larger than a maximum available transform size, the split transform_flag is inferred to be 'one' and is not present in the encoded bitstream 312. 15 Additionally, when the residual quad-tree (RQT) reaches a maximum depth, or further subdivision would result in a node with a region size smaller than the smallest allowable transform size, the split transformflag of the node is inferred to be 'zero' and is not present in the encoded bitstream 312. The hierarchical subdivision of a coding block (CB) into one or more transform blocks (TBs) according to a residual quad-tree (RQT) may be 20 referred to as a 'transform tree'. In the example of Fig. 5, at the highest (root) hierarchy level of the residual quad-tree (RQT) 500, the coding block (CB) is subdivided into four regions: an upper left block 502, an upper right block 504, a lower left block 506 and a lower right block 508. This corresponds to coding a split-transform-flag equal to one into the encoded bitstream 312. The blocks 502, 504 are not split further and form individual 25 transform blocks (TBs). This corresponds to coding a split transform-flag equal to zero for each of the blocks 502, 504 into the encoded bitstream 312. The block 506 is split further into four leaf blocks 510, 512, 514, 516, with each of the blocks 510, 512, 514, 516 forming an individual transform blocks (TBs). This corresponds to coding a splitjtransform flag equal to one for the transform block (TB) 506 and four 30 splitjtransform flag values equal to zero for the transform blocks (TBs) 510, 512, 514, 516 into the encoded bitstream 312. Finally the block 508 is not split further, forming an individual transform block (TB). This corresponds to coding a split transform-flag equal to zero into the encoded bitstream 312. This exemplary residual quad-tree (RQT) illustrates one possible arrangement of transform blocks (TBs) within a coding block (CB). 8144749_1 P095116_speci lodge - 28 The residual quad-tree (RQT) is defined across all colour channels, however the resulting transform block (TB) sizes for chroma channels are dependent on the chroma subsampling of the selected chroma format. Fig. 5B is a schematic representation of coding units with a PARTNxN 5 partitioning and a PART_2Nx2N partitioning. A coding unit (CU) 540 has a PARTNxN partitioning. The coding unit (CU) 540 is thus associated with four prediction units (PUs) 542, 544, 546 and 548. Each prediction unit (PU) 542, 544, 546 and 548 uses the same category of prediction (i.e. intra-prediction, inter-prediction or intra block copy), however each prediction unit (PU) 542, 544, 546 and 548 may use different parameters within the 10 category. For example, for intra block copy mode, each of the prediction units (PUs) 542, 544, 546 and 548 may have different block vectors. For inter-prediction, each of the prediction units (PUs) 542, 544, 546 and 548 may have different motion vectors. The coding unit (CU) 560 has a PART_2Nx2N partition. The coding unit (CU) 560 is thus associated with one prediction unit (PU) 562. Additional partition modes are also defined, 15 such as PART_2NxN and PART_Nx2N. Of all the defined partition modes, a subset is available for a given coding unit (CU). The subset of available partition modes depends on the size of the coding unit (CU), the prediction mode of the coding unit (CU) and may depend on other parameters, such as limits on the ranges of allowed coding unit (CU) sizes (e.g. the smallest coding unit size and the largest coding unit size). 20 Fig. 6A is a schematic representation of an example 'Z-scan' order of scanning coding blocks (CBs) within a coding tree block (CTB) 600. At each level of the hierarchical decomposition of the coding tree block (CTB) 600, a scan resembling a 'Z' is performed, i.e. from left to right, and then from top to bottom. This is applied recursively in a depth-first manner. In the example of Fig. 6A, the four coding blocks (CBs) in the 25 top-left of the coding tree block (CTB) 600 are scanned as in a Z-scan order 602, reaching a coding block (CB) 606 that is currently being processed in the example of Fig. 6A. The remainder of the coding tree block (CTB) 600 will be scanned according to Z-scan order 604. The samples from previously decoded coding blocks (CBs) in the coding tree block (CTB) 600 are available for intra-prediction. The samples from the coding blocks (CBs) 30 that have not yet been decoded by the video decoder 134 are not available for intra prediction. These samples are illustrated with diagonal hatching in Fig. 6A. As such, the video encoder 114 also treats these samples as not being available for intra-prediction. Fig. 6B is a schematic representation of an example intra block copy operation. A coding block (CB) 622 is configured to use intra block copy mode. A block vector 624 8144749_1 P095116_speci lodge - 29 references a reference block 626 of samples relative to the top-left sample position of the coding block (CB) 622 in a current coded tree block (CTB) 628 used to reconstruct a coding block (CB) 622. A region 630 of the current coded tree block (CTB) 628 has not yet been decoded because these regions are subsequent to the coding block (CB) 622 in the 5 Z-scan order. The region 630 is thus not available for referencing. In the example of Fig. 6B, the reference block 626 is contained entirely within the current coding tree block (CTB) 628 and the previous coding tree block (CTB) is not shown. The memory capacity of the intra block copy module 350 in the video encoder 114 and the intra block copy module 436 in the video decoder 134 is sufficient to hold the luma and chroma samples of 10 two coding tree blocks (CTBs), with the coding tree block (CTB) size configured as 64x64 luma samples and corresponding dimensions for chroma in accordance with the selected chroma format. Fig. 7 is a schematic representation of an example of a coding block (CB) 706 occupying an entire coding tree block (CTB) 702, the coding block (CB) being predicted 15 using the intra block copy mode. When the intra block copy mode is in use, the reference block generally cannot overlap with the coding block (CB). Arrangements of the video encoder 114 and the video decoder 134 may prohibit any overlap of a reference block with the coding block (CB). In such cases, a reference block 708 consists of the entirety of a previous coding tree block (CTB) 710. A block vector 704 shows the only valid block 20 vector for this case, i.e. referencing the block 708 to predict the coding block (CB) 706. The reference block 708 has the same size as the coding block (CB) 706. As the coding block (CB) 706 is equal in size to the coding tree block (CTB) 706, the only valid block vector is the a block vector 704 that results in the reference block 708 occupying the entirety of the previous coding tree block (CTB). This particular block vector is highly 25 unlikely to be selected by the video encoder 114 because the probability that an adjacent coding tree block (CTB) provides a good prediction is very low. However, the encoded bitstream 312 may include a delta block vector that results in such a reference block vector. Consequently, the video decoder 134 must be capable of decoding such a block vector and reconstructing the corresponding coding unit (CU). To decode this particular block vector, 30 the entire previous coding tree block (CTB) 708 is copied to a buffer holding the current coding tree block (CTB) 706. Such a copy operation implies a burst of relatively high memory bandwidth to perform the necessary copy operations. Additionally, control logic must be present (or software code for the processor 205) to support this particular case that has almost no probability of being selected by the video encoder 114. Arrangements of the 8144749_1 P095116_speci lodge - 30 video encoder 114 and the video decoder 134 may prohibit this case by modifying the signalling of the intra block copy operation such that this operation is not signalled when the coding unit (CU) size is equal to 64x64. Alternative arrangements of the video encoder 114 and the video decoder 134 may prohibit the general case where the coding block (CB) 5 size is equal to the coding tree block (CTB) size by prohibiting signalling of the intra block copy mode flag (i.e. intrabc-flag) whenever the coding block (CB) size is equal to the coding tree block (CTB) size. Arrangements of the video encoder 114 and video decoder 134 having restrictions on the coding block (CB) sizes for which intra block copy is available will be further discussed with reference to Figs. 10D and 1 1D respectively. 10 Figs. 8A, 8B, 8C and 8D are schematic representation of a frame portion 800 with an example of a coding block (CB) 802 occupying the entirety of a coding tree block (CTB). The frame portion 800 includes two coding tree blocks (CTBs), a current coding tree block (CTB) that is being processed (i.e. being encoded by the video decoder 114 or being decoded by the video decoder 134). For the coding block (CB) 802 having the same 15 size as coding tree unit (CTU), arrangements of the video encoder 114 and the video decoder 134 may infer a partitioning mode for this coding unit (CU) of PARTNxN. In this case, the PARTNxN partition mode is applied to a coding unit (CU) either having the size of a largest coding unit (LCU) or having a fixed size of 64x64 luma samples. In such cases, the coding unit (CU) is split into multiple square blocks (prediction units) 806, 808, 20 810, 812. In other cases, a PART_2Nx2N partition mode is used, resulting in one prediction unit (PU) occupying the entirety of the coding unit (CU). For the PARTNxN case, the prediction units (PUs) 806-812 may each use the intra block copy mode. The example of Figs. 8A-8D applies to both the video encoder 114 and the video decoder 134. Block vectors 802, 816, 822 and 828 originate from the prediction units (PUs) 806, 808, 25 810 and 812 respectively. The block vectors 802, 816, 822 and 828 reference the blocks 814, 816, 820 and 824 respectively, to predict the blocks 806, 808, 810 and 812 respectively. In the video encoder 114, the blocks 814, 816, 820 and 824 are obtained from the intra block copy module 350, e.g. by performing a search to determine which reference block will provide a good prediction for a current block. In the video decoder 30 134, the blocks 814, 818, 820 and 824 are obtained from the intra block copy module 436, which keeps a copy of the reconstructed samples prior to deblocking from the current and previous coding tree blocks (CTBs). The prediction units (PUs) 806, 808, 810 and 812 are processed in the Z-scan order, as described with reference to Fig. 6A. Each of the block 8144749_1 P095116_speci lodge -31 vectors 802, 816, 822 and 828 may be represented in the encoded bitstream 312 as a delta relative to the block vector of the previous prediction unit (PU). Fig. 8E is a schematic representation of an example of a coding block (CB) 862 configured to use the intra block copy mode and predicted by a reference block 864. The 5 coding block (CB) 864 includes a residual quad-tree (RQT) with one split. Thus, the coding block (CB) 864 is divided into four transform blocks (TUs) 878, 880, 882 and 884. A block vector 866 references the reference block 864, i.e. specifies the location of the top left sample of the reference block 864 relative to the top left sample of the coding block (CB) 862. The four transform blocks (TBs) 878, 880, 882, 884 are predicted by blocks 10 868, 870, 872, 874 respectively. If the block vector magnitude is such that either or both the horizontal and vertical components of the block vector are equal to or greater in magnitude than the width or height of the coding block (CB), then the reference block does not overlap the coding block (CB). In contrast, if the magnitude of both the horizontal and vertical components of the block vector are less than the size of the coding block (CB), 15 then an overlap between the reference block and the coding block (CB) will occur. The block vector 866 results in the coding block (CB) 862 and the block 864 having an overlapping area 876. The block copy operation of the intra block copy module 350 in the video encoder 114 and the intra block copy module 436 in the video decoder 134 perform reconstruction at a transform block (TB) granularity. This means that each reference block 20 (i.e. 868, 870, 872 and 874) is copied to each coding block (CB) (i.e. 878, 880, 882 and 884) separately, and after each block is copied, the spatial domain representation of the residual associated with each transform block TB) is added to the copied block. Consequently, when the reference block 874 is copied to coding block (CB) 884, the portion 876 of the reference block 874 is referencing part of the coding block (CB) 878 25 after reconstruction. Hence, the portion 876 includes spatial domain residual. When the reference block does not overlap with the predicted block its content is fully determined prior to reconstruction of the predicted block. When reference block overlaps with the predicted block, the contents of the overlapping portion of a reference block (such as the portion 876 of the reference block 874) is unknown prior to reconstruction of the coding 30 block (CB) 878. Various approaches as described below can be used to reconstruct the blocks in intra-block copy mode where reference block overlapping happens. Fig. 8F is a schematic representation of an example of a coding block (CB) 887 of a coding unit (CU). The example of Fig. 8F shows an arrangement where intra block copy may be applied to individual 4x4 blocks of samples. The coding block (CB) 887 is split 8144749_1 P095116_speci lodge - 32 into four coding blocks (CBs) 888, 889, 890, 891. The coding block (CB) 890 is further split into four coding blocks (CBs) 892, 893, 894, 895. The coding units (CUs) for blocks 892, 893, 894, 895 have size of a smallest coding unit (SCU) and therefore cannot be split into smaller coding units (CUs). The coding units (CUs) 892, 893, 894 and 895 each have 5 a partition mode of either PARTNxN or PART_2Nx2N, signalled independently for each coding unit (CU) using a 'part mode' syntax element in the encoded bitstream 312. Coding units (CUs) having a size larger than the smallest coding unit are inferred to use a PART_2Nx2N partition mode and thus have no associated part-mode syntax element in the encoded bitstream 312. The coding unit (CU) 894 is predicted using the intra block 10 copy mode. Coding units (CUs) corresponding to the coding blocks (CBs) 892, 893, 895 have associated partitioning mode PART_2Nx2N which means there is a single prediction unit (PU) for each of the coding units (CUs) covering the whole coding unit (CU). The coding block (CB) 894 is configured to use a PARTNxN partitioning mode. Consequently, the coding block (CB) 894 is subdivided into four prediction units (PUs). 15 Each prediction unit (PU) has a corresponding prediction block (PB) (i.e. 896, 897, 898 and 899). Collectively, the prediction blocks (PBs) 896, 897, 898 and 899 cover the entirety of the coding block (CB) 894. As the coding unit (CU) 894 size is 8x8, the size of each of the prediction units (PUs) 896-899 is 4x4. Thus, this configuration permits intra block copy to be applied to 4x4 blocks of samples. Each of the prediction units (PUs) 20 corresponding to the prediction blocks (PBs) 896, 897, 898, 899 is predicted using the intra block copy mode with an independent block vector. Although the PARTNxN partition mode has been described, other partition modes are also possible, such as PART_2NxN and PARTNx2N. For the PART_2NxN partition mode, the coding block (CB) is divided horizontally into two partitions occupying the upper and lower halves of the coding block 25 (CB). For the PARTNx2N partition mode, the coding block (CB) is divided vertically into two partitions occupying the left and right halves of the coding block (CB). In both cases, each partition corresponds to one prediction unit (PU), having an independent block vector. The block vectors may be coded in the encoded bitstream 312 using delta block vectors, in accordance with the coding of block vectors for consecutive coding blocks 30 (CBs) when the PART_2Nx2N partition mode is in use. Moreover, the ordering of the delta block vectors for coding blocks (CBs) having multiple partitions may follow the ordering implied by the Z-scan order.. For a PARTNxN partition mode, the order of processing each partition is as described in Figs. 8A-8D, which accords exactly with the Z scan order. For a PART_2NxN partition mode, the order of processing each partition is 8144749_1 P095116_speci lodge - 33 firstly the upper partition followed by the lower partition. For a PART_Nx2N partition mode, the order of processing each partition is firstly the left partition followed by the right partition. Fig. 9A is a schematic representation of a coding unit (CU) syntax structure 902 5 within a bitstream portion 900. The coding unit (CU) syntax structure 902 describes the structure of one coding unit (CU), and may invoke other syntax structures to describe the structure of other entities included in a coding unit (CU). For example, the residual quad tree (RQT) of a coding unit (CU) is described by one or more transform tree syntax structures and one or more transform unit (TU) syntax structures. The coding unit (CU) 10 syntax structure 902 is applicable when a coding unit (CU) is implicitly split into four prediction units (PUs) (i.e. partition mode of PARTNxN). Implicit splitting means that there is no syntax element to select a partition mode out of multiple possible partition modes. The context of an instance of a coding unit (CU) syntax structure may prevent particular syntax elements from being present. For example, syntax elements relating to 15 inter-prediction are not present in a coding unit (CU) syntax structure within a slice configured to only use intra-prediction. The coding unit (CU) syntax structure 902 is applicable in cases where the intra block copy function is available and in use. As shown in Fig. 9A, the coding unit (CU) syntax structure 902 includes syntax elements and syntax structures (e.g. 904 to 918). A transquant bypass flag 904 ('cu transquant bypass flag') 20 signals the use of the 'transform quantisation bypass' mode for the coding unit (CU). The transquant bypass flag 904 is only present if a 'transquant bypass enabledflag', present in the high level syntax was true. The transquant bypass flag 904 is signalled independently of whether intra block copy is enabled, thus intra block copy may be applied to both the lossless and lossy coding cases. A skip flag 906 ('cuskip flag') is present in 25 the encoded bitstream 312 for coding units (CUs) in slices that may use inter-prediction. The skip flag 906 signals that the coding unit (CU) includes an inter-predicted prediction units (PUs) and that no residual or motion vector difference is present in the encoded bitstream 312 for the prediction unit (PU) associated with this coding unit (CU). In this case, a prediction unit (PU) syntax structure is included that may result in one syntax 30 element being included, to specify a neighbouring prediction unit (PU) from which the motion vector for the coding unit (CU) will be derived. When the skip flag 906 indicates the use of skipping the coding unit (CU), no further syntax elements are included by the coding unit (CU) syntax structure. As such, an efficient means to represent coding units (CUs) in the encoded bitstream 312 is available, usable in cases where no residual is 8144749_1 P095116_speci lodge -34 required (i.e. the inter-predicted reference block is very close or identical to the corresponding portion of the frame data 310). When the coding unit (CU) is not skipped, additional syntax elements are introduced by the coding unit (CU) syntax structure 902 to further specify the configuration of the coding unit (CU). An intra block copy flag 908 5 signals the use of the intra block copy mode for the coding unit (CU). The intra block copy flag 908 is encoded only when an 'intrablockcopyenabled flag' is true. The 'intra block copyenabledflag' is encoded as high level syntax. If the intra block copy mode is in use, delta block vectors 910 are present in the encoded bitstream 312. The delta block vectors 910 includes one or more delta block vectors, such as delta block vector 912. 10 Each delta block vector is associated with one prediction unit (PU). Each delta block vector encodes the difference between the block vector of a previous prediction unit (PU) and the block vector of a current prediction unit (PU). Alternatively, the delta block vectors 910 may specify the locations of the reference blocks relative to some other entities, such as the coding tree block (CTB) in which the coding unit (CU) is contained. 15 Arrangements of the video encoder 114 and the video decoder 134 supporting a PARTNxN partition mode for coding units (CUs) configured to use the intra block copy mode have four delta bock vectors present within the delta block vectors 912. Each delta block vector includes a horizontal and a vertical offset (or 'component'). The coding of a delta block vector in the encoded bitstream 312 and may reuse a pre-existing syntax 20 structure, e.g. a 'motion vector difference' syntax structure, to encode the horizontal and vertical offsets in the encoded bitstream 312. In one arrangement the number "n" (see Fig. 9A) of block vectors 912 encoded into the block 910 is determined based on the size of the coding unit (CU). In arrangements where intra block copy is prohibited for coding units (CUs) having the same size as the coding tree unit (CTU), if the size of the coding unit 25 (CU) is equal to the size of the coding tree block (CTB), then "n" has value of four, in which case the coding unit (CU) is split into four blocks (i.e. PARTNxN partition mode) as described above with reference to Figs. 8A, 8B, 8C and 8D with each of the blocks 806, 808, 810, 812 being predicted using reference block vectors 802, 818, 822 and 828 stored in blocks BVo, BV 1 , BV 2 , BV 3 of the encoded bitstream 312. Otherwise (if the size of the 30 coding unit (CU) is less than the size of the coding tree block (CTB)), "n" has value of one, in which case the PART_2Nx2N partition mode is used, resulting in one prediction unit (PU) occupying the entirety of the coding unit (CU). In this case, one block vector is present in block BVo of the encoded bitstream 312. A root coded block flag 916 (or 'rqt root cbf) signals the presence of residual data within the coding unit (CU). If the 8144749_1 P095116_speci lodge - 35 flag 916 has a value of zero, no residual data is present in the coding unit (CU). If the flag 916 has a value of one, there is at least one significant residual coefficient in the coding unit (CU) and hence a residual quad-tree (RQT) exists in the coding unit (CU). In such cases, a transform tree 918 syntax structure encodes the uppermost hierarchical level of the 5 residual quad-tree (RQT) in the encoded bitstream 312. Additional instances of transform tree syntax structures and transform unit syntax structures are present in the transform tree 918 syntax structure, in accordance with the residual quad-tree hierarchy of the coding unit (CU). Fig. 9B is a schematic representation of a coding unit (CU) syntax structure 942 10 within a bitstream portion 940. The layout of the syntax structure 942 is similar to the layout of the syntax structure 902 described above with the reference to the Fig. 9A except that in the structure 942 the prediction mode flag ('pred mode flag') and intra block copy flag ('IBC' in Fig. 9A) are organized into a single PMF/IBC syntax element 922. Fig. 9C is a schematic representation of a coding unit (CU) syntax structure 962 15 within a bitstream portion 960. The layout of the syntax structure 962 is similar to the layout of the syntax structure 902 except that the structure 962 may include a partition mode 909 (or 'part mode'). The coding unit (CU) syntax structure 962 is applicable to the coding blocks of Fig. 8F (e.g. the coding block 887 or the coding block 894). The partition mode 909 is used to explicitly control partitioning of a coding unit (CU) into one or more 20 prediction units (PUs). In one arrangement the partition mode 909 is present in the encoded bitstream 312 only if the size of the coding unit (CU) is equal to the size of a smallest coding unit (SCU). Otherwise (if the size of the coding unit (CU) is larger than the size of a smallest coding unit (SCU)), the partition mode 909 is not present in the encoded bitstream 312. In such cases, the partitioning mode of the coding unit (CU) is 25 inferred to be PART_2Nx2N, indicating that one prediction unit (PU) occupies the entire coding unit (CU). If the partition mode 909 is present in the encoded bitstream 312, the partition mode 909 generally indicates one of two modes: PART_2Nx2N or PARTNxN for a coding unit (CU) configured to use intra block copy. Other partition modes such as PART_Nx2N and PART_2NxN may also be among the modes indicated by the partition 30 mode 909. A partition mode of PARTNxN indicates that the coding unit (CU) is split into four square non-overlapping prediction units (PUs). In another arrangement the partition mode 909 is present in the encoded bitstream 312 for all coding units (CUs) coded in the intra block copy mode. In another arrangement the partition mode 909 is present in the encoded bitstream 312 for coding units (CUs) coded in the intra block copy 8144749_1 P095116_speci lodge - 36 mode having a size less than the largest coding unit (LCU) size. In such arrangements, the partition mode of a coding unit (CU) having a size equal to the largest coding unit (LCU) size is inferred to be PARTNxN. In alternative arrangements the part_mode flag 909 may indicate a choice of four modes: PART_2Nx2N, PART_NxN, PART_2NxN, 5 PART_Nx2N. Depending on the value of the partmode flag 909 the number "n" of the reference block vectors in the syntax block 910 may be one (PART_2Nx2N) or two (PART_2NxN, PART_Nx2N) or four (PARTNxN). Fig. 10A is a schematic flow diagram showing a method 1000 for encoding a coding unit (CU) syntax structure 902 for a coding unit (CU) using the intra block copy 10 mode. The method 1000 results in encoding the coding unit (CU) syntax structure 960 of Fig. 9C into the encoded bitstream 312. Arrangements using the method 1000 include a partition mode syntax element for coding units (CUs) of a particular size, thus allowing multiple partitions modes to be used for a given coding unit (CU). For a coding unit (CU) with a prediction mode indicating that intra-prediction is in use for all prediction units 15 (PUs) within the coding unit (CU), the PARTNxN partition mode is only available when the coding unit (CU) size is equal to the smallest coding unit (SCU) size (typically 8x8). This availability of PARTNxN partition mode is extended to intra block copy mode in the method 1000. This results in the possibility to perform intra block copy module to 4x4 blocks. Such a block size is useful for areas of very high detail, such as text, because even 20 small fragments of one letter can be predicted from fragments from nearby blocks. The trade-off is that more block vectors are required, because each 4x4 block requires a separate block vector. The delta coding scheme for block vectors alleviates this concern somewhat. One consideration for such a small block size is the memory bandwidth requirement. Generally, it is expected that arrangements will not read individual samples 25 sequentially from the memory within the intra block copy module 350 in the video encoder 114 and the intra block copy module 436 in the video decoder 134. To do so would result in unacceptably slow performance for real time processing of video data at any reasonable frame rate and resolution. Instead, it is expected that samples will be read in groups, e.g. using 'single instruction multiple data' (SIMD) approaches. In such cases, each group of 30 samples has a particular 'foot print' of samples. For example, one memory read could result in reading a 4x4 array of samples aligned to a 4x4 grid within the current and/or previous coding tree block (CTB). Other arrangements of samples are also possible, but the key point is that such arrangements are regular across the buffer of reconstructed samples. For intra-prediction, 'neighbouring' samples to the below-left, left, above-left, 8144749_1 P095116_speci lodge - 37 above and above-right are required. This results in a requirement to perform five memory reads to obtain the reference samples to intra-predict one 4x4 block. For intra block copy mode applied to a 4x4 block, when the block vector is misaligned (i.e. either of both the horizontal and vertical components are not aligned to a 4 sample boundary), the memory 5 read bandwidth is two reads when one component is misaligned and four reads when both components are misaligned. Thus, it can be seen that supporting intra-block copy for 4x4 blocks does not increase the worst case memory bandwidth compared to the case of intra prediction for 4x4 blocks. At a search block vectors step 1002, the intra block copy module 350, under control 10 of the processor 205, performs search of various block vectors in order to select an optimal block vector. The search may test a subset of the possible block vectors, e.g. test just block vectors aligned horizontally and vertically to the coding unit (CU). For each block vector, the distortion of the reference block relative to the frame data 310 is checked and compared against the cost (or 'rate') of coding the block vector. A rate/distortion trade-off is applied 15 in order to select an optimal block vector. Also, other prediction modes, such as intra prediction and inter prediction are supported by the video encoder 114, however the method 1000 is generally invoked in the case where intra block copy is the optimal prediction mode. For each size of coding unit (CU), the search block vectors step 1002 searches for a reference block having the same size as the coding unit (CU) size, i.e. using 20 a 'PART_2Nx2N' partition mode. For a coding unit (CU) size equal to the smallest coding unit (SCU) size (or in some arrangements equal to 8x8), the search block vectors step 1002 also searches for four reference blocks, each occupying a 4x4 region of the coding unit (CU). This case corresponds to a 'PARTNxN' partition mode for the coding unit CU). Control in the processor 205 then passes to an encode coding unit transquant bypass flag 25 step 1004. At the encode coding unit transquant bypass flag step 1004 the entropy encoder 324, under control of the processor 205, encodes a coding unit (CU) transquant bypass flag 904 into the encoded bitstream 312. The transquant bypass flag has a value of one when lossless coding of the coding unit (CU) is being performed and a value of zero when lossy 30 coding of the coding unit (CU) is being performed. Control in the processor 205 then passes to an encode skip flag step 1006. At the encode skip flag step 1006 the entropy encoder 324, under control of the processor 205, encodes a skip flag 906 into the encoded bitstream 312. The skip flag signals if coding of the motion vector delta and residual for the coding unit (CU) will be 8144749_1 P095116_speci lodge - 38 skipped. The method 1000 is applicable to coding units (CUs) configured to use intra block copy mode, thus the skip flag value is false. Control in the processor 205 then passes to an encode intra block copy flag step 1010. At the encode intra block copy flag step 1010, the entropy encoder 324, under 5 control of the processor 205, encodes an intrabc-flag 908 into the encoded bitstream 312. As the method 1000 is applicable to coding units (CUs) configured to use intra block copy mode, the intra block copy flag associated with such a coding unit (CUs) has a value, such as 'one' indicating that intra block copy mode is enabled. Control in the processor 205 then passes to a test coding unit (CU) size step 1012. 10 At the test coding unit (CU) size step 1012, the processor 205 tests the size of the current coding unit (CU). In one arrangement, if the size of the coding unit (CU) is equal to a smallest coding unit (SCU) size, control in the processor 205 passes to an encode partition mode step 1014, otherwise control in the processor 205 passes to an encode block vectors step 1016. 15 At the encode partition mode step 1014, the entropy encoder 324, under control of the processor 205, encodes a partition mode into the encoded bitstream 312. In arrangements supporting two partition modes (i.e. PARTNxN and PART_2Nx2N), the partition mode is a flag signalling one of the two supported partition modes. Control in the processor 205 then passes to an encode block vectors step 1016. 20 At the encode block vectors step 1016, a block 910 of motion vector delta syntax structures (such as structure 912) is encoded into the encoded bitstream 312. The encode block vectors step 1016 will be further described with reference to Fig. 10D. Control in the processor 205 then passes to an encode root coded block flag step 1018. At the encode root cbf step 1018, the entropy encoder 324, under control of the 25 processor 205, encodes a root-cbf flag 916 into the encoded bitstream 312. The rootcbf flag 916 signals the presence of at least one transform (i.e. having at least one significant residual coefficient) in the residual quad-tree (RQT) of the coding unit (CU). Control in the processor 205 then passes to a test root coded block flag step 1020. At the test root cbf flag step 1020, the processor 205 tests the value of the rootcbf 30 flag. The rootcbf flag 916 indicates presence of residual information in at least one coding block (CB) of the current coding unit (CU). If the rootcbf flag 916 is equal to true or "one", control in the processor 205 passes to an encode transform tree step 1022, otherwise the method 1000 terminates. 8144749_1 P095116_speci lodge - 39 At the encode transform tree step 1018, the entropy encoder 324, under control of the processor 205, encodes a transform tree (i.e., the residual quad-tree (RQT)) for the coding unit (CU) into the encoded bitstream 312. The method 1000 then terminates. Fig. 10B is a schematic flow diagram showing a method 1040 for encoding a 5 variant of the coding unit (CU) syntax structure 902 of Fig. 9A for a coding unit (CU) using the intra block copy mode. The method 1040 prohibits signalling the use of intra block copy mode for a coding unit (CU) having a size equal to a particular value, such as 64x64 or the largest coding unit size. Such arrangements have reduced complexity because an unlikely corner case for block copy is not supported. The steps 1004, 1006, 10 1010, 1018, 1020, 1022 of the method 1040 are identical to the corresponding steps of the method 1000 and are thus numbered identically. The method 1040 begins with a search block vectors step 1042. At the search block vectors step 1042, the intra block copy module 350, under control of the processor 205, searches block vectors to determine one optimal block vector. 15 The search block vectors step 1042 operates similarly to the search block vectors step 1002 of Fig. 10A, with the following differences: In one arrangement, for a coding unit (CU) size equal to a particular value, such as 64x64, the block vector search is not performed. In such a case only one block vector is possible and is known to be highly unlikely to be a suitable block vector, so eliminating this case reduces the encoder search space and 20 simplifies the decoder without degrading coding efficiency. The particular value can also depend on the high level syntax in the encoded bitstream. For example, in another arrangement the particular value could be the largest coding unit (LCU) size. Moreover, an encoded bitstream 312 produced using the method 1040 cannot express the use of intra block copy for a coding unit (CU) having a size of the particular value. Additionally, the 25 search block vectors step 1042 does not search for multiple reference blocks within one coding unit (CU) divided according to a PARTNxN partition mode. In yet another arrangement, multiple values of coding unit (CU) are prohibited from using intra block copy mode. For example, 64x64 and 32x32 coding units (CUs) may not use intra block copy mode, i.e. intra block copy flag is not present in the encoded bitstream 312 for coding 30 units (CUs) of these sizes and is thus inferred to be disabled. In such arrangements 8x8 and 16x16 coding units (CUs) may use intra block copy mode, i.e. intra block copy is present in the encoded bitstream 312 for coding units (CUs) of these sizes. At a test coding unit (CU) size step 1044, the processor 205 tests the size of the coding unit (CU). In one arrangement of the method 1040, if the coding unit (CU) size is 8144749_1 P095116_speci lodge - 40 equal to 64x64, control in the processor 205 passes to the encode root coded block flag step 1018. This prohibits execution of the intra block copy flag step 1010, thus prohibiting the entropy encoder 324 from encoding the intra block copy flag in to the encoded bitstream 312 for a coding unit (CU) of size 64x64. Otherwise control in the processor 205 5 passes to the encode intra block copy flag step 1010. In such cases intra block copy can be used for coding units (CUs) of size 8x8, 16x16 or 32x32). At an encode block vector step 1046, the entropy encoder 324, under control of the processor 205, encodes one block vector for the entire coding unit (i.e. PART_2Nx2N partition mode). 10 Fig. 10C is a schematic flow diagram showing a method 1060 for encoding a coding unit (CU) syntax structure 902 for a coding unit (CU) using the intra block copy mode. In the method 1060, the partition mode for a coding unit (CU) using intra block copy mode is determined based on the coding unit (CU) size. Thus, there is no partmode syntax element present in the encoded bitstream, regardless of the coding unit (CU) size. 15 The method 1060, when performed by the video encoder 114, results in encoding the coding unit (CU) syntax structure 900 of Fig. 9A into the encoded bitstream 312. The steps 1004, 1006, 1010, 1016, 1018, 1020, 1022 of the method 1060 are identical to the corresponding steps of the method 1000 and are thus numbered identically. The method 1060 begins with a search block vectors step 1062. 20 At the search block vectors step 1062, the intra block copy module 350, under control of the processor 205, searches block vectors to determine one optimal block vector. The search block vectors step 1042 operates similarly to the search block vectors step 1002 of Fig. 10A, with the following differences: For a coding unit (CU) size equal to a particular value, such as 64x64 (regardless of the largest coding unit size indicated in the 25 encoded bitstream 312), the coding unit (CU) is partitioned according to the PARTNxN partition mode (i.e. into four square regions) and a block vector search is performed on each region, resulting in four block vectors. Such a partitioning of a coding unit (CU) using intra block copy mode corresponds to Figs. 8A-8D. Such a partitioning allows more flexibility in the selection of block vectors. For example, the area from which reference 30 blocks can be obtained for prediction units (PUs) in Figs. 8B-8D is larger than for the prediction unit (PU) of Fig. 8A, because the reconstructed samples from previously processed prediction units (PUs) can be used for reference. At a test coding unit (CU) size step 1064, the processor 205 compares the coding unit (CU) size against a predetermined size. If the coding unit (CU) size is equal to the 8144749_1 P095116_speci lodge - 41 predetermined size, then the partition mode is set to PARTNxN, otherwise the partition mode is set to PART_2Nx2N. The result of this assignment is that a partition will never have the same size as the predetermined size. In one arrangement the predetermined size is 64x64 samples. In such arrangements, a coding unit (CU) of size 64x64 is associated with 5 a PARTNxN partition mode. In such arrangements, coding units (CUs) of size 8x8, 16x16 or 32x32 are associated with a PART_2Nx2N partition mode. If the largest coding unit (LCU) size were less than 64x64 (e.g. 16x16 or 32x32) then coding units (CUs) would always be associated with PART_2Nx2N when intra block copy mode was in use. In another arrangement, the predetermined size is the largest coding unit (LCU) size, as 10 indicated in the encoded bitstream 312. In such arrangements, for a largest coding unit (LCU) size of 64x64, coding units (CUs) of this size are associated with a PARTNxN partition mode. Coding units (CUs) of size 8x8, 16x16 or 32x32 are associated with a PART_2Nx2N partition mode. For a largest coding unit (LCU) size of 32x32, coding units (CUs) of this size are associated with a PARTNxN partition mode. Coding units (CUs) of 15 size 8x8 or 16x16 are assocated with a PART_2Nx2N partition mode. Fig. 10D is a schematic flow diagram showing a method 10100 for encoding a block of intra block copy block vectors. Arrangements may use method 10100 to implement steps 1016 of Figs. 10A and 10C. The method 10100 allows encoding either a single block vector or multiple block vectors for one coding unit (CU) in accordance with 20 the partition mode of the coding unit (CU). The method 10100 begins with an initialize y step 10104. At the initialize y step 10104 the processor 205 assigns the vertical coordinate yo of left upper corner of the current coding unit (CU) to a variable y. At an initialize x step 10106 the processor 205 assigns the horizontal coordinate xo of left upper corner of the current coding unit (CU) to a variable x. 25 At an encode reference vector step 10108, the entropy encoder 324, under control of the processor 205, encodes an intra block copy reference vector for predicting a block with upper left corner coordinates (x, y) into the encoded bitstream 312. At an increment x step 10110 the processor 205 increments the variable x. In one arrangement the value of x is incremented based on the partitioning mode 30 (part-mode) of the current coding unit (CU). If the partitioning mode is PARTNxN or PART_Nx2N, the variable x incremented by half of the width Wcu of the current coding unit (CU). If the partitioning mode is PART_2Nx2N or PART_2NxN the variable x incremented by the width Wcu of the current coding unit (CU). 8144749_1 P095116_speci lodge - 42 At a test x step 10112 the value of the variable x is tested. If the value is less than (xO + Wcu), control in the processor 205 passes to the step 10108, otherwise control in the processor 205 passes to a step 10114. At an increment y step 10114 the processor 205 increments the variable y. 5 In one arrangement the value of y is incremented based on the partitioning mode. If the partitioning mode is PARTNxN or PART_2NxN, the variable y incremented by half of the height Hcu of the current coding unit (CU). If the partitioning mode is PART_2Nx2N or PARTNx2N the variable y incremented by the height Hcu of the current coding unit (CU). 10 At a test y step 10116 the value of y is tested. If the value is less than (yO + Hcu), control in the processor 205 passes to the step 10106, otherwise the method 10100 terminates. Fig. 11A is a schematic flow diagram showing a method 1100 for decoding a coding unit (CU) syntax structure 962 for a coding unit (CU) using the intra block copy 15 mode. The method 1100, when performed by the video decoder 134, results in decoding the coding unit (CU) syntax structure 960 of Fig. 9C from the encoded bitstream 312. For a coding unit (CU) with a prediction mode indicating that intra-prediction is in use for all prediction units (PUs) within the coding unit (CU), the PARTNxN partition mode is only available when the coding unit (CU) size is equal to the smallest coding unit (SCU) size 20 (typically 8x8). This availability of PARTNxN partition mode is extended to intra block copy mode in the method 1100. This harmonisation of partition modes between intra prediction and intra block copy mode enables 4x4 blocks to use intra block copy mode, thus providing greatly increased flexibility for improving the prediction for a given coding unit (CU) which results in reduced residual size and thus improved coding efficiency. The 25 method 1100 is intended to decode a bitstream that was encoded using the method 1000. The method 1100 begins with a decode coding unit transquant bypass step 1104. At the decode coding unit transquant bypass flag step 1104 the entropy decoder 420, under control of the processor 205, decodes a coding unit (CU) transquant bypass flag 904 from the encoded bitstream 312. The transquant bypass flag has a value of one when 30 lossless coding of the coding unit (CU) is being performed and a value of zero when lossy coding of the coding unit (CU) is being performed. Control in the processor 205 then passes to a decode coding unit (CU) skip flag step 1106. At the decode coding unit skip flag step 1106 the entropy decoder 420, under control of the processor205, decodes a skip flag 906 from the encoded bitstream 312. The 8144749_1 P095116_speci lodge - 43 flag signals if coding of the motion vector delta and residual for the coding unit (CU) will be skipped. Control in the processor 205 then passes to a test skip flag step 1108. At the test skip flag step 1108, the processor 205 tests the decoded skip flag 906 and if the flag equals true or "one" (indicating the presence of a skipped coding unit), a 5 motion vector for the coding unit (CU) is derived from previous motion vectors, e.g. from blocks adjacent to the current coding unit (CU). Also, no residual is present in the encoded bitstream for skipped coding units (CUs). As such, for skipped coding units, other than the skip flag no further information is present in the encoded bitstream 312. If the skip flag is false or "zero", control in the processor 205 then passes to a decode intra block copy flag 10 step 1110. At the decode intra block copy flag step 1110 the entropy decoder 420, under control of the processor 205, decodes an intrabc-flag 908 from the encoded bitstream 312. Control in the processor 205 then passes to a coding unit (CU) size test step 1112. At the test coding unit (CU) size step 1112, the processor 205 tests the size of the 15 current coding unit (CU). In one arrangement, if the size of the coding unit (CU) is equal to a smallest coding unit (SCU) size, control in the processor 205 passes to a decode partition mode step 1114, otherwise control in the processor 205 passes to a decode block vectors step 1116. At the decode partition mode step 1114, the entropy encoder 324, under control of 20 the processor 205, encodes a partition mode into the encoded bitstream 312. In arrangements supporting two partition modes (i.e. PARTNxN and PART_2Nx2N), the partition mode is a flag signalling one of the two supported partition modes. Control in the processor 205 then passes to a decode block vectors step 1116. At the decode block vectors step 1116, the entropy decoder 324, under control of 25 the processor 205, decodes a block 910 of 'motion vector delta' syntax structures (such as structure 912) from the encoded bitstream 312. The block includes one 'mvdcoding' syntax structure for a coding unit (CU) using a PART_2Nx2N partition mode and four 'mvd_coding' syntax structures for a coding unit (CU) using a PARTNxN partition mode. Control in the processor 205 then passes to a decode root cbf step 1118. 30 At the decode root cbf step 1118, the entropy decoder 324, under control of the processor 205, decodes a root-cbf flag 916 from the encoded bitstream 312. The rootcbf flag 916 signals the presence of at least one transform (i.e. having at least one significant residual coefficient) in the residual quad-tree (RQT) of the coding unit (CU). Control in the processor 205 then passes to a test root cbf flag step 1120. 8144749_1 P095116_speci lodge - 44 At the test root cbf flag step 1120, the processor 205 tests the value of the rootcbf flag. The rootcbf flag 916 indicates presence of residual information in at least one coding block (CB) of the current coding unit (CU). If the rootcbf flag 916 is equal to true or "one", this indicates that residual data is present in the encoded bitstream 312 and 5 control in the processor 205 then passes to a decode transform tree step 1122, otherwise the method 1100 terminates. At the decode transform tree step 1122, the entropy decoder 324, under control of the processor 205, decodes a transform tree (i.e., the residual quad-tree (RQT)) for the coding unit (CU) from the encoded bitstream 312. Control in the processor 205 then 10 passes to a form prediction step 1124. At the form prediction step 1124 the intra block copy module 350, under control of the processor 205, produces one reference block for each prediction unit (PU) in the coding unit (CU) according to the corresponding block vector. The reference blocks are produced by copying samples from buffer holding reconstructed samples of the current and/or 15 previous coding tree block (CTB) into a buffer holding the prediction of the current coding unit (CU). The copying operation copies a block of samples having the same size as a prediction unit (PU). The location of the reference block may be anywhere within the memory of the intra block copy module 350 in the video encoder 114 or the intra block copy module 436 in the video decoder 134. Control logic within these modules is required 20 to support each coding unit (CU) size for which intra block copy mode is available. Cases where intra block copy mode is not available (e.g, for a particular size coding unit, such as 64x64) thus reduce the complexity of these modules. The reference block is aligned to a unit-sample boundary and no filtering is applied (i.e. there is no sub-sample block vector precision). Note that the two buffers (i.e. reconstructed sample buffer and coding unit 25 buffer) may be combined into a single buffer, with separate regions for the reconstructed samples and the current coding unit (CU). The location of the current coding unit (CU) within the buffer is dependent on the position of the coding unit (CU) in the quad-tree hierarchical subdivision of the coding tree block (CTB) and the Z-scan order (as exemplified in Fig. 6A). The method 1100 then terminates. 30 Fig. 11B is a schematic flow diagram showing a method 1140 for decoding a variant of the coding unit (CU) syntax structure 902 of Fig. 9A for a coding unit (CU) using the intra block copy mode. The method 1140 prohibits decoding an intra-bc-flag for a coding unit (CU) having a size equal to a particular value, such as 64x64 or the largest coding unit size Steps of the method 1130 are executed by the entropy decoder module 420 8144749_1 P095116_speci lodge - 45 under the control of the processor 205. The method 1130, when performed by the video decoder 134, results in decoding the coding unit (CU) syntax structure 940 of Fig. 9B from the encoded bitstream 312. The method 1140 is intended to decode a bitstream that was encoded using the method 1040. The method 1140 begins with the step 1104. 5 At a test coding unit (CU) size step 1142, the processor 205 tests the size of the coding unit (CU). In one arrangement, if the coding unit (CU) size is equal to 64x64, control in the processor 205 passes to the decode root coded block flag step 1118 (prohibiting execution of the step 1110, prohibiting the entropy decoder 324 from decoding an intra block copy flag from the encoded bitstream 312), otherwise control in the 10 processor 205 passes to the encode intra block copy flag step 1110. In another arrangement, if the coding unit (CU) size is equal to the largest coding unit (LCU) size, the entropy decoder 324 is prohibited from decoding an intra block copy flag from the encoded bitstream 312 and the flag is inferred to be false. In yet another arrangement, multiple values of coding unit (CU) are prohibited from using intra block copy mode. For example, 15 64x64 and 32x32 coding units (CUs) are prohibited from using intra block copy mode, i.e. intra block copy flag is not present in the encoded bitstream 312 for coding units (CUs) of these sizes and is thus inferred to be disabled. In such arrangements 8x8 and 16x16 coding units (CUs) may use intra block copy mode, i.e. intra block copy is present in the encoded bitstream 312 for coding units (CUs) of these sizes. 20 Fig. 11C is a schematic flow diagram showing a method 1160 for decoding a coding unit (CU) syntax structure 902 for a coding unit (CU) using the intra block copy mode. Steps of the method 1160 are executed by the entropy decoder module 420 under the control of the processor 205. The method 1160, when performed by the video decoder 134, results in decoding the coding unit (CU) syntax structure 900 of Fig. 9A from the 25 encoded bitstream 312. The method 1160 is intended to decode a bitstream that was encoded using the method 1060. In the method 1160, the partition mode for coding units (CUs) using intra block copy mode is determined from the coding unit (CU) size and thus no part-mode syntax element is decoded from the encoded bitstream 312. The method 1160 begins with the step 1104. 30 At a test coding unit (CU) size step 1162, the processor 205 compared the coding unit (CU) size against a predetermined size. If the coding unit (CU) size is equal to the predetermined size, then the partition mode is set to PARTNxN, otherwise the partition mode is set to PART_2Nx2N. The result of this assignment is that a partition will never have the same size as the predetermined size. In one arrangement the predetermined size is 8144749_1 P095116_speci lodge - 46 64x64 samples. In such arrangements, a coding unit (CU) of size 64x64 is associated with a PARTNxN partition mode. Such an association of a coding unit (CU) using intra block copy mode corresponds to Figs. 8A-8D. Coding units (CUs) of size 8x8, 16x16 or 32x32 are associated with a PART_2Nx2N partition mode. If the largest coding unit (LCU) size 5 were less than 64x64 (e.g. 16x16 or 32x32) then coding units (CUs) would always be associated with PART_2Nx2N when intra block copy mode was in use. In another arrangement, the predetermined size is the largest coding unit (LCU) size, as indicated in the encoded bitstream 312. In such arrangements, for a largest coding unit (LCU) size of 64x64, coding units (CUs) of this size are associated with a PARTNxN partition mode. 10 Coding units (CUs) of size 8x8, 16x16 or 32x32 are associated with a PART_2Nx2N partition mode. For a largest coding unit (LCU) size of 32x32, coding units (CUs) of this size are associated with a PARTNxN partition mode. Coding units (CUs) of size 8x8 or 16x16 are assocated with a PART_2Nx2N partition mode. Fig. 11D is a schematic flow diagram showing a method 11100 for decoding a 15 block of intra block copy reference vectors. Arrangements may use the method 11100 to implement steps 1116 as seen in each of Figs. 11A, 11B and 11C. The method 11100 begins at an initialise y step 11104. At the initialize y step 11104 the processor 205 assigns the vertical coordinate yo of left upper corner of the current coding unit (CU) to a variable y. Control in the processor 20 205 then passes to an initialise x step 11106. At the initialize x step 11106 the processor 205 assigns the horizontal coordinate xo of left upper corner of the current coding unit (CU) to a variable x. Control in the processor 205 then passes to a decode block vector 11108. At the decode block vector step 11108 the entropy decoder 324, under control of 25 the processor 205, decodes an intra block copy block vector for predicting a block with upper left corner coordinates (x, y from the encoded bitstream 312. Control in the processor 205 then passes to an increment x step 11110. At the increment x step 11110 the processor 205 increments the value of variable x. Control in the processor 205 then passes to a test x step 11112. 30 In one arrangement the value of x is incremented based on the partitioning mode (part-mode) of the current coding unit (CU). If the partitioning mode is PARTNxN or PART_Nx2N, the variable x incremented by half of the width Wcu of the current coding unit (CU). If the partitioning mode is PART_2Nx2N or PART_2NxN the variable x incremented by the width Wcu of the current coding unit (CU). 8144749_1 P095116_speci lodge - 47 At the test x step 11112 the processor 205 tests value of the variable x. If the value is less than (xO + Wcu), control in the processor 205 passes to the step 11108, otherwise control in the processor 205 passes to a step 11114. At the increment y step 11114 the processor 205 increments the variable y. 5 In one arrangement the value of the variable y is incremented based on the partitioning mode. If the partitioning mode is PARTNxN or PART_2NxN, the variable y incremented by half of the height Hcu of the current coding unit (CU). If the partitioning mode is PART_2Nx2N or PART_Nx2N the variable y incremented by the height Hcu of the current coding unit (CU). 10 At a test y step 11116 the processor 205 tests the value of the variable y. If the value is less than (yO + Hcu), control in the processor 205 passes to the step 11106, otherwise the method 11100 terminates. Fig. 12 is a schematic flow diagram showing a method 1250 for reconstructing a transform unit (TU) of a coding unit (CU). The method 1250 is applicable to coding units 15 (CUs) predicted in the intra block copy mode. Steps of the method 1250 are executed by the entropy decoder module 420 under the control of the processor 205. At a test split transform-flag step 1252 the splitjtransformflag is tested. If the value of the flag indicates a split of the current residual quad-tree (RQT) node, control in the processor 205 passes to step 1254, otherwise a transform unit (TU) was reached and 20 control in the processor 205 passes to a step 1262. At a recursive call step 1254, the method 1250 is recursively called for the upper left sub-unit of the current coding unit (CU). At a recursive call step 1256, the method 1250 is recursively called for the upper right sub-unit of the current coding unit (CU). 25 At a recursive call step 1258, the method 1250 is recursively called for the lower left sub-unit of the current coding unit (CU). At a recursive call step 1260, the method 1250 is recursively called for the lower right sub-unit of the current coding unit (CU). After the step 1260, the method 1250 terminates. 30 At a determine intra block copy prediction step 1262, reference blocks for transform blocks (TBs) (one for each colour component) of the current transform unit (TU) are determined using an intra block copy block reference vector (such as block reference vector 912, Fig. 9A, 9B, 9C) associated with the current coding unit (CU). 8144749_1 P095116_speci lodge - 48 At a reconstruct TU step 1264, transform blocks (TBs) of the current transform unit (TU) are reconstructed using the reference blocks determined on the step 1262 and residuals for the transform blocks (TBs) decoded from the encoded bitstream 312. An important aspect of the method 1250 is that the reconstruction will be performed one 5 transform unit (TU) at a time. Considering the intra block copy example of Fig. 8E this means that the transform unit (TU) 878, including the overlapping block 876 will be reconstructed using the reference block 868 prior to reconstruction of the transform unit (TU) 884. At the point of reconstruction of the transform unit (TU) 884 its reference block 874 including the overlapping block 876 will be fully determined. 10 Another approach to predicting a sample block whose reference block is not available due to overlapping is to approximate the undefined samples based on previously decoded sample values. From practical point it is desirable to keep the approximation algorithm simple while keeping it reasonably efficient. One such algorithm may build the prediction as shown on the diagram of Fig. 14. A prediction for a transform block (TB) 15 1402 of size D of a transform unit (TU), is determined as a weighted average sample value Saverage of previously decoded neighbour samples in blocks 1404 and 1406. Assuming that the left top sample 1408 of the transform block (TB) 1402 has spatial coordinates (0, 0) (horizontal, vertical), then the block 1404 may be a line of samples with coordinates (0 .. D-1, -1), and the block 1406 may be a column of samples with coordinates (-1, 0 .. D-1). 20 The prediction algorithm may predict the samples for which the reference block is not available with the determined approximation average value Saverage. In the example of Fig. 8E this would result in block 886 of the transform unit (TU) 884 predicted based on the value Saverage calculated for the transform unit 884. A memory buffer allocation scheme for use with the intra block copy mode will be 25 described with the reference to Figs. 13A, 13B and 13C. This memory buffer holds reconstructed samples and is present within the intra block copy module 350 in the video encoder 114 and the intra block copy module 436 within the video decoder 134. The intra block copy mode block reference vectors may reference blocks from the current or left neighbour coding tree blocks (CTBs). In hardware and software decoder implementations 30 this implies presence of a reference memory buffer to store reference samples. For hardware implementations, this reference memory buffer is likely to be implemented using in-chip static RAM, due to the high memory access bandwidth required, particularly for coding tree units (CTUs) that are split into many small coding units (CUs). In the high efficiency video coding (HEVC) standard, the buffer size is sufficient for two coding tree 8144749_1 P095116_speci lodge - 49 units (CTUs), with a size of 64x64 per coding tree unit (CTU). The worst case for memory consumption occurs when the 4:4:4 chroma format is in use, as each chroma channel has the same number of samples as the luma channel. Thus, the memory requirement is 2 * 3 * 64 * 64 = 24576 samples. In many profiles of the HEVC standard (including the "Main", 5 "Main 4:2:2 10" and "Main 4:4:4 10" profiles) the maximum valid coding tree unit (CTU) size is 64x64 samples, other supported coding tree unit (CTU) sizes include 32x32, 16x16 and 8x8 samples. Although a reduction in the largest coding unit (LCU) size reduces the memory requirement for a particular coded video sequence, the worst case identified above must be supported. The set of samples available for reference for intra block copy may be 10 increased from the current and previous coding tree block (CTB) when the largest coding unit (LCU) size is less than a particular value, such as 64x64. In this case the reference buffer can be configured to store more than two coding tree blocks (CTBs) for intra block copy references. As a result when using coding tree units (CTUs) of a size smaller than the maximum allowed size, the intra block copy reference vectors can reference a larger 15 amount of coding tree blocks (CTBs) resulting in compression efficiency improvements. In Fig. 13A, a coding tree block (CTB) 1302 corresponding to a coding tree unit (CTU) of a maximum allowed size is predicted in the intra block copy mode. The block 1302 and its left neighbour coding tree block (CTB) 1304 are stored in a reference memory buffer 1306 seen in Fig. 13B. Fig. 13B also shows an example of a coding tree block 1308 20 corresponding to a coding tree unit (CTU) of width and height equal to half of width and height of a maximum allowed, predicted in the intra block copy mode. The reference memory buffer 1306 in this case may be configured to store up to four coding tree blocks (CTBs) 1308, 1310, 1312 and 1314, for intra block copy reference. The blocks 1308, 1310, 1312 and 1314have spatial configuration as shown on the Fig. 13A. This 25 configuration results in using half of the memory compared to the case where the largest coding unit (LCU) size is 64x64 (i.e. 12288 samples). This configuration results in the latency for the 32x32 largest coding unit (LCU) size being equal to the latency for the 64x64 largest coding unit (LCU) size. For a stream configured to use coding tree units (CTUs) of size 16x16 samples up to eight coding tree units (CTUs), including the current 30 coding tree unit (CTU) can be used for intra block copy references. Such a configuration is shown in Fig. 13C, with coding tree units (CTUs) 1320, 1322, 1324, 1326, 1328, 1330, 1332 and 1334 being held in the memory buffer for reference by intra block copy mode. For the cases of Figs. 13B and 13C, when the coding unit (CU) size is equal to the largest coding unit (LCU) size, multiple block vectors are possible because there are more than 8144749_1 P095116_speci lodge - 50 one previous coding tree block (CTB). In such cases, the vertical component of the block vector must be zero because the reference block height is equal to the largest coding unit (LCU) height, however the horizontal component has many possible values. Arrangements that prohibit intra block copy mode for coding units (CUs) of size 64x64, 5 thus provide greater flexibility for the block vector selection (e.g. in the search block vectors step 1002) when the largest coding unit (LCU) size is configured to be less than 64x64. The arrangements described herein show methods which reduce complexity, for example, by removing requirements for video encoder 114 and video decoder 134 to 10 support configurations which have little practical use still require considerable hardware resources to implement. Other arrangements described herein show methods which facilitate improvements in compression performance, for example, by allowing video encoder 114 to have higher flexibility in choosing coding unit (CU) prediction configurations for use with the intra 15 block copy mode and allowing video decoder 134 to support such configurations. Specific implementations of the arrangements described herein are expressed in Appendix 1 and Appendix 2 which show syntax tables according to the HEVC standard modified and varied according to the specific intra block copy prediction coding processes for encoding and decoding described herein. 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. 8144749_1 P095116_speci lodge -51 APPENDIX 1 8144749_1 P095116_speci lodge - 52 codingunit( x0, yo, log2CbSize) { Descriptor if( transquant-bypass enabled-flag) cutransquant-bypass-flag ae(v) if( slice_type != I) cuskipflag[ xA ][ yO] ae(v) nCbS = (1 << log2CbSize) if( cu-skip-flag[ xA ][ yO ] ) prediction-unit( x0, yO, nCbS, nCbS) else { if( intrablockcopy-enabled-flag) intra-bcflag[ x ][ yO] ae(v) if( !intra-bcflag[ x ][ yO]) { if( slice-type != I) pred-mode-flag ae(v) if( CuPredMode[ xO ][ yO] MODEINTRA II log2CbSize == MinCbLog2SizeY) partmode ae(v) } if( CuPredMode[ xO ][ yO] = = MODEINTRA) { if( PartMode == PART_2Nx2N && pcm-enabled-flag && !intra-bc-flag log2CbSize >= Log2MinlpcmCbSizeY && log2CbSize <= Log2MaxlpcmCbSizeY) pcm-fiag[ x ][ yO ] ae(v) if( pcm-flag[ x][ y ] ) { while( !byte-aligned() pcm-alignment zerobit f(1) pcm-sample( x0, yO, log2CbSize) } else { pbOffset = (PartMode = = PARTNxN) ? (nCbS / 2) nCbS if( intrabcflag[ x ][ yO ] ) for( j = 0; j < nCbS; j = j + pbOffset) for( i = 0; i < nCbS; i = i + pbOffset) 8144749_1 P095116_speci lodge - 53 mvd coding(xO + i, yO + j, 2) } else { for( j = 0; j < nCbS; j = j + pbOffset) for( i = 0; i < nCbS; i = i + pbOffset) previntra luma-pred-flag[ x0 + i ][ yO + j] ae(v) for( j = 0; j < nCbS; j = j + pbOffset ) for( i = 0; i < nCbS; i = i + pbOffset) if( previntra luma-pred-flag[ x0 + i ][ yO + j]) mpmidx[ x + i ][ yO +j] ae(v) else rem intra luma-predmode[ x0 + i ][ yO + j] ae(v) if( ChromaArrayType = = 3 ) for( j = 0; j < nCbS; j = j + pbOffset) for( i = 0; i < nCbS; i = i + pbOffset) intra chroma-predmode[ x + i ][ yO + j] ae(v) else if( ChromaArrayType != 0 ) intrachroma-predmode[ x0 ][ yO] ae(v) } else { if( PartMode = = PART_2Nx2N) predictionunit( x0, yO, nCbS, nCbS) else if( PartMode = = PART_2NxN) { prediction-unit( x0, yO, nCbS, nCbS / 2) prediction-unit( x0, yO + ( nCbS / 2), nCbS, nCbS /2 ) } else if( PartMode = = PARTNx2N) { prediction-unit( x0, yO, nCbS / 2, nCbS) prediction-unit( x0 + ( nCbS / 2 ), yO, nCbS /2, nCbS ) } else if( PartMode = = PART_2NxnU ) { prediction-unit( x0, yO, nCbS, nCbS / 4 ) prediction-unit( x0, yO + ( nCbS / 4), nCbS, nCbS * 3 / 4) } else if( PartMode = = PART_2NxnD) { 8144749_1 P095116_speci lodge - 54 prediction-unit( x0, yO, nCbS, nCbS * 3 /4) prediction-unit( x0, yO + ( nCbS * 3 /4), nCbS, nCbS / 4 ) } else if( PartMode = = PARTnLx2N ) { prediction-unit( x0, yO, nCbS / 4, nCbS) prediction-unit( xA + ( nCbS / 4 ), yO, nCbS * 3 / 4, nCbS ) } else if( PartMode = = PARTnRx2N ) { prediction-unit( x0, yO, nCbS * 3 / 4, nCbS) prediction-unit( xA + (nCbS * 3 / 4 ), y0, nCbS / 4, nCbS ) } else { /* PARTNxN */ prediction-unit( x0, yO, nCbS / 2, nCbS / 2) prediction-unit( xA + ( nCbS / 2 ), yO, nCbS / 2, nCbS / 2 ) prediction-unit( x0, yO + ( nCbS /2 ), nCbS / 2, nCbS / 2 ) prediction-unit( xA + (nCbS / 2 ), yO + ( nCbS / 2 ), nCbS / 2, nCbS /2) } } if( !pcm-flag[ x ][ yO]) { if( CuPredMode[ xO ][ yO] MODEINTRA && !( PartMode = = PART_2Nx2N && merge-flag[ xA [ yO] ) || CuPredMode[ x ][ yO] == MODEINTRA && intra-bc-flag[ x ][ yO] ) rqt-rootscbf ae(v) if( rqt-root-cbf ) I MaxTrafoDepth = (CuPredMode[ x ][ yO] = = MODEINTRA ? (max transformhierarchy-depthintra + IntraSplitFlag) maxtransformhierarchy-depth-inter) transform-tree( x0, yO, x0, yO, log2CbSize, 0, 0) } } } } 8144749_1 P095116_speci lodge - 55 APPENDIX 2 mvd_coding( xO, yO, refList) { Descriptor absmvd-greaterOflag[ xO ] [ yO ][ 0] ae(v) absmvd-greaterOflag[ xO ] [ yO ] [11] ae(v) if( abs-mvd-greaterOflag[ xO ][ yO] [ 0]) abs-mvd-greater1_flag[ xO ][ yO ] [ 0] ae(v) if( abs-mvd-greaterOflag[ xO ][ yO ] [ 1 ]) abs-mvd-greater1_flag[ xO ][ yO ] [ 1] ae(v) if( abs-mvd-greaterOflag[ xO ][ yO ] [ 0]) { if( abs-mvd-greaterlflag[ x0 ][ yO] [ 0]) absmvd minus2[ xO ]y] [ 0] ae(v) mvd_signflag[ xO ][ yO ] [ 0] ae(v) } if( abs-mvdgreaterOflag[ x0 ][ yO] [ 1]) { if( abs-mvd-greaterlflag[ x0 ][ yO] [11]) absmvd minus2 [ x0 ][ yO] [11] ae(v) mvd_signflag[ x0 ][ yO ] [11] ae(v) 5 10 8144749_1 P095116_speci lodge

Claims (12)

1. A method of decoding a coding unit configured to use intra block copy prediction from a stream of video data, the method comprising: 5 determining that a size of received coding unit in the stream of video data is equal to a predetermined coding unit size; associating, if the coding unit size is equal to the largest coding unit size, the coding unit with a plurality of prediction units by partitioning the coding unit into a plurality of prediction units; 10 decoding a plurality of intra-block copy block vectors for the coding unit, each of the intra-block copy block vectors corresponding to a prediction unit of the plurality of prediction units; and forming a prediction of the coding unit from the plurality of associated prediction units using the corresponding intra-block copy block vectors to thereby decode the coding 15 unit.

2. A method according to claim 1, wherein the predetermined coding unit size is a maximum available coding unit size for the coding of the video data.

3. A method according to claim 1, wherein the predetermined coding unit size is 64x64. 20

4. A method according to claim 1, wherein the plurality of prediction units comprise a plurality of intra block copied prediction units.

5. A method according to claim 1, wherein the largest coding unit size is not equal to the size of a smallest coding unit.

6. A method according to claim 1, wherein the partitioning of the coding unit is a 25 PARTNxN partition mode.

7. A method according to claim 1, further comprising comparing a size of the coding unit against a predetermined size and and setting a parittion mode such that a partition will never have the same size as the predetermined size. 8144749_1 P095116_speci lodge - 57

8. A method of decoding a coding unit configured to use intra block copy prediction from a stream of video data, the method comprising: determining that a size of a received coding unit in the stream of video data is equal to a maximum size for the coding of the video data; 5 associating, if the coding unit size is equal to the maximum size, the coding unit with a plurality of prediction units by partitioning the coding unit into a plurality of prediction units; decoding a plurality of intra-block copy block vectors for the coding unit, each of the intra-block copy block vectors corresponding to a prediction unit of the plurality of 10 prediction units; and forming a prediction of the coding unit from the plurality of associated prediction units using the corresponding intra-block copy block vectors to thereby decode the coding unit.

9. A computer readable stroage medium having a program recorded thereon, the 15 program being executable by a processor to decode a coding unit configured to use intra block copy prediction from a stream of video data, the program comprising: code for determining that a size of received coding unit in the stream of video data is equal to a predetermined coding unit size; code for associating, if the coding unit size is equal to the largest coding unit size, 20 the coding unit with a plurality of prediction units by partitioning the coding unit into a plurality of prediction units; code for decoding a plurality of intra-block copy block vectors for the coding unit, each of the intra-block copy block vectors corresponding to a prediction unit of the plurality of prediction units; and 25 code for forming a prediction of the coding unit from the plurality of associated prediction units using the corresponding intra-block copy block vectors to thereby decode the coding unit.

10. A computer readable stroage medium having a program recorded thereon, the program being executable by a processor to decode a coding unit configured to use intra 30 block copy prediction from a stream of video data, the program comprising: code for determining that a size of a received coding unit in the stream of video data is equal to a maximum size for the coding of the video data; 8144749_1 P095116_speci lodge - 58 code for associating, if the coding unit size is equal to the maximum size, the coding unit with a plurality of prediction units by partitioning the coding unit into a plurality of prediction units; code for decoding a plurality of intra-block copy block vectors for the coding unit, 5 each of the intra-block copy block vectors corresponding to a prediction unit of the plurality of prediction units; and code for forming a prediction of the coding unit from the plurality of associated prediction units using the corresponding intra-block copy block vectors to thereby decode the coding unit. 10

11. A video decoder configured for decoding a coding unit configured to use intra block copy prediction from a stream of video data, the decoder comprising: means for determining that a size of received coding unit in the stream of video data is equal to a predetermined coding unit size; means for associating, if the coding unit size is equal to the largest coding unit size, 15 the coding unit with a plurality of prediction units by partitioning the coding unit into a plurality of prediction units; means for decoding a plurality of intra-block copy block vectors for the coding unit, each of the intra-block copy block vectors corresponding to a prediction unit of the plurality of prediction units; and 20 means for forming a prediction of the coding unit from the plurality of associated prediction units using the corresponding intra-block copy block vectors to thereby decode the coding unit.

12. A video decoder for decoding a coding unit configured to use intra block copy prediction from a stream of video data, the decoder comprising: 25 means for determining that a size of a received coding unit in the stream of video data is equal to a maximum size for the coding of the video data; means for associating, if the coding unit size is equal to the maximum size, the coding unit with a plurality of prediction units by partitioning the coding unit into a plurality of prediction units; 30 means for decoding a plurality of intra-block copy block vectors for the coding unit, each of the intra-block copy block vectors corresponding to a prediction unit of the plurality of prediction units; and 8144749_1 P095116_speci lodge - 59 means for forming a prediction of the coding unit from the plurality of associated prediction units using the corresponding intra-block copy block vectors to thereby decode the coding unit. 5 CANON KABUSHIKI KAISHA Patent Attorneys for the Applicant Spruson & Ferguson 8144749_1 P095116_speci lodge