PL2777162T3

Context reduction for context adaptive binary arithmetic coding

Abstract

This record has no abstract on file.

Term

6 yearsto projected expiry

Projected expiry 5 October 2032, counted from filing; an application has no term until it is granted.

1 claim: 1 independent, 0 dependent

1
Zastrzeżenia patentowe 1. Sposób kodowania danych wideo obejmujący:określanie (602) pierwszego trybu predykcji dla bloku danych wideo w wycinku typu P slice;reprezentowanie (604) pierwszego trybu predykcji jako elementu składni typu predykcji wycinka typu P-slice;określanie (606) drugiego typu predykcji dla bloku danych wideo w wycinku typu B slice;elementu składni typu predykcji wycinka typu P-slice i elementu składni typu predykcji wycinka typu B-slice;znamienny tym, że binaryzacja elementu składni typu predykcji wycinka typu P-slice i binaryzacja elementu składni typu predykcji wycinka typu B-slice są określane z wykorzystaniem tej samej logiki binaryzacji. 2. Sposób według zastrzeżenia 1, w którym kodowanie danych wideo obejmuje: binaryzowanie elementu składni typu predykcji wycinka typu P-slice z wykorzystaniem określonej binaryzacji wycinka typu P-slice;binaryzowanie elementu składni typu predykcji wycinka typu B-slice z wykorzystaniem określonej binaryzacji wycinka typu B-slice;stosowanie kodowania typu context adaptive binary arithmetic coding (CABAC) względem binaryzowanego 53/59P36908PL00 EP 2 777 162 B1 elementu składni typu predykcji wycinka typu P-slice;oraz stosowanie kodowania typu context adaptive binary arithmetic coding (CABAC) względem binaryzowanego elementu składni typu predykcji wycinka typu B-slice. 3. Sposób dekodowania danych wideo obejmujący: odwzorowywanie (710) binaryzowanego elementu składni typu predykcji wycinka typu P-slice na typ predykcji z wykorzystaniem odwzorowania binaryzacji dla bloku danych wideo w wycinku typu P slice;odwzorowywanie (712) binaryzowanego elementu składni typu predykcji wycinka typu B-slice na typ predykcji oraz dekodowanie (714) danych wideo na podstawie odwzorowanych typów predykcji;znamienny przez wykorzystywanie tego samego odwzorowania binaryzacji dla bloku danych wideo w wycinku typu B slice;4. Sposób według zastrzeżenia 3, obejmujący ponadto: odbieranie (702) kodowanego za pomocą kodowania typu context adaptive binary arithmetic elementu składni typu predykcji wycinka typu P-slice, który wskazuje typ predykcji dla bloku danych wideo w wycinku typu P slice;i odbieranie kodowanego za pomocą kodowania typu context adaptive binary arithmetic elementu składni typu predykcji wycinka typu B-slice, który wskazuje typ predykcji dla bloku danych wideo w wycinku typu B slice, przy czym dekodowanie danych wideo obejmuje ponadto: dekodowanie (706) elementu składni typu predykcji wycinka typu P-slice w celu utworzenia binaryzowanego elementu składni typu predykcji wycinka typu P-slice;oraz 53/59P36908PL00 EP 2 777 162 B1 dekodowanie (708) elementu składni typu predykcji wycinka typu B-slice w celu utworzenia binaryzowanego elementu składni typu predykcji wycinka typu B-slice. 5. Sposób według zastrzeżenia 1 albo 3, w którym element składni typu predykcji wycinka typu P-slice i element składni typu predykcji wycinka typu B-slice określają tryb predykcji i typ podziału. 6. Sposób według zastrzeżenia 5, w którym tryb predykcji zawiera jedną spośród predykcji międzyobrazowej i predykcji wewnątrzobrazowej. 7. Sposób według zastrzeżenia 5, w którym typ podziału zawiera jedne spośród podziałów symetrycznych i podziałów asymetrycznych. 8. Urządzenie (20) skonfigurowane do kodowania danych wideo, zawierające: środki (41) do określania pierwszego typu predykcji dla bloku danych wideo w wycinku typu P slice;środki (41) do reprezentowania pierwszego typu predykcji jako elementu składni typu predykcji wycinka typu Pslice;środki (41) do określania drugiego typu predykcji dla bloku danych wideo w wycinku typu B slice;środki (41) do reprezentowania drugiego typu predykcji jako elementu składni typu predykcji wycinka typu Bslice;środki (41) do określania binaryzacji wycinka typu Pslice dla elementu składni typu predykcji wycinka typu Pslice;53/59P36908PL00 EP 2 777 162 B1 środki do określania binaryzacji wycinka typu B-slice dla elementu składni typu predykcji wycinka typu B-slice;oraz środki (56) do kodowania danych wideo na podstawie binaryzacji elementu składni typu predykcji wycinka typu P-slice oraz elementu składni predykcji wycinka typu Bslice;znamienne tym, że środki do określania binaryzacji wycinka typu P-slice dla elementu składni typu predykcji wycinka typu P-slice oraz środki do określania binaryzacji wycinka typu B-slice dla elementu składni typu predykcji wycinka typu B-slice są skonfigurowane do wykorzystywania tej samej logiki binaryzacji;9. Urządzenie według zastrzeżenia 8, w którym środki do kodowania danych wideo zawierają: środki do binaryzowania elementu składni typu predykcji wycinka typu P-slice z wykorzystaniem określonej binaryzacji wycinka typu P-slice;środki do binaryzowania elementu składni typu predykcji wycinka typu B-slice z wykorzystaniem określonej binaryzacji wycinka typu B-slice;środki do stosowania kodowania typu context adaptive binary arithmetic coding (CABAC) względem binaryzowanego elementu składni typu predykcji wycinka typu P-slice;oraz środki do stosowania kodowania typu context adaptive binary arithmetic coding (CABAC) względem binaryzowanego elementu składni typu predykcji wycinka typu B-slice . 10. Urządzenie (30) skonfigurowane do dekodowania danych wideo zawierające: środki do odwzorowywania binaryzowanego elementu składni typu predykcji wycinka typu P-slice na typ predykcji z 53/59P36908PL00 EP 2 777 162 B1 wykorzystaniem odwzorowania binaryzacji dla bloku danych wideo w wycinku typu P slice;środki do odwzorowywania binaryzowanego elementu składni typu predykcji wycinka typu B-slice na typ predykcji z wykorzystaniem odwzorowania binaryzacji dla bloku danych wideo w wycinku typu B slice;oraz środki (80;81) do dekodowania danych wideo na podstawie odwzorowanych typów predykcji;znamienne tym, że środki do odwzorowywania binaryzowanego elementu składni typu predykcji wycinka typu P-slice i środki do odwzorowywania binaryzowanego elementu składni typu predykcji wycinka typu B-slice są skonfigurowane do wykorzystywania tego samego odwzorowania binaryzacji. 11. Urządzenie według zastrzeżenia 10, zawierające ponadto: środki do odbierania kodowanego za pomocą kodowania typu context adaptive binary arithmetic elementu składni typu predykcji wycinka typu P-slice, który wskazuje typ predykcji dla bloku danych wideo w wycinku typu P slice;oraz środki do odbierania kodowanego za pomocą kodowania typu context adaptive binary arithmetic elementu składni typu predykcji wycinka typu B-slice, który wskazuje typ predykcji dla bloku danych wideo w wycinku typu B slice, w którym środki do dekodowania danych wideo zawierają ponadto: środki do dekodowania elementu składni typu predykcji wycinka typu P-slice w celu utworzenia binaryzowanego elementu składni typu predykcji wycinka typu P-slice;oraz środki do dekodowania elementu składni typu predykcji wycinka typu B-slice w celu utworzenia binaryzowanego elementu składni typu predykcji wycinka typu B-slice. 53/59P36908PL00 EP 2 777 162 B1 12. Urządzenie według zastrzeżenia 8 albo 10, w którym element składni typu predykcji wycinka typu P-slice i element składni typu predykcji wycinka typu B-slice określają tryb predykcji i typ podziału. 13. Urządzenie według zastrzeżenia 12, w którym tryb predykcji zawiera jedną spośród predykcji międzyobrazowej i predykcji wewnątrzobrazowej. 14. Urządzenie według zastrzeżenia 12, w którym typ podziału zawiera jedne spośród podziałów symetrycznych i podziałów asymetrycznych. 15. Odczytywalny komputerowo nośnik pamięci przechowujący instrukcje, które podczas wykonywania powodują, że jeden lub większa liczba procesorów skonfigurowanych do kodowania lub dekodowania danych wideo wykonuje sposób zgodnie z, odpowiednio, dowolnym z zastrzeżeń od 1 do 7. Qualcomm Incorporated Peł nomocnik: 53/59P36908PL00 EP 2 777 162 B1 53/59P36908PL00 EP 2 777 162 B1 53/59P36908PL00 EP 2 777 162 B1 DEKODER WIDEO FIG.3 53/59P36908PL00 EP 2 777 162 B1 53/59P36908PL00 EP 2 777 162 B1 53/59P36908PL00 EP 2 777 162 B1 53/59P36908PL00 EP 2 777 162 B1 53/59P36908PL00 EP 2 777 162 B1 53/59P36908PL00 EP 2 777 162 B1 53/59P36908PL00 EP 2 777 162 B1

473 paragraphs in 84 sections, as filed

TECHNICAL FIELD [0001] The present invention relates to video coding, in particular context adaptive binary arithmetic coding (CABAC) coding used in video coding.

BACKGROUND [0002] Digital video capabilities can be contained in a wide range of devices, including digital television, digital direct broadcast systems, wireless broadcast systems, digital assistant (PDA) devices, laptops or desktop computers, tablet computers, e-book readers, digital cameras, digital recording devices, digital media players, video game devices, video game consoles, cellular or satellite radiotelephones, so-called 'smartphones', video teleconferencing devices, video streaming devices and the like. Digital video devices implement video compression techniques, such as those described in the standards defined by MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264 / MPEG-4, Part 10, advanced video coding ( AVC), a high performance video coding standard (HEVC) that is currently in the state of development and extension of such standards. Video devices can transmit, receive, encode, decode and / or save digital video information in a more efficient way by implementing such video compression techniques.

[0003] Video compression techniques implement spatial (intra-picture) and / or time (inter-picture) prediction to reduce or remove the redundancy present in video sequences. For block-based

53 / 59P36908PL00

In video coding, the slice video slice (i.e., video or part of a video image) can be divided into video blocks, which can also be referred to as tree blocks, encoding units (CUs), and / or nodes coding. The video blocks in the intra-picture (I) coded slice of the image are coded using spatial prediction with reference samples in adjacent blocks in the same image. Video blocks in inter-image coded (P or B) image slice can use spatial prediction for reference samples in adjacent blocks for reference in the same image or time prediction for reference samples in other images. Images can be referred to as frames, and reference images can be referred to as reference frames.

[0004] The result of spatial or temporal prediction is the predictor block for the block to be coded. Residual data represents pixel differences between the original block to be encoded and the predictor block. The inter-picture coded block is coded according to a motion vector that indicates a block of reference samples forming a predictor block, and residual data indicating the difference between the coded block and the predictor block. The in-picture coded block is encoded according to the in-picture coding mode and the residual data. For additional compression, residual data can be transformed from the pixel domain to the transformation domain, resulting in residual transformation coefficients that can then be quantized. Quantized transformation coefficients, initially ordered in a two-dimensional array, can be scanned to create a one-dimensional transformation coefficient vector, and entropy coding can be used to achieve even greater compression.

53 / 59P36908PL00

EP 2 777 162 B1 [0005] In the document "WD4: Working Draft of High-Efficiency Video Coding" by B Bross et al, from the 6th JCT-VC meeting; 97.MPEG Meeting, Torino July 14-22, 2011 describes adaptive context coding.

SUMMARY OF THE INVENTION not limiting inter_pred_flag, merge_idx, cbf_cr, [0006] The invention is defined in the claims to which reference is now made. Basically, this document describes techniques for context adaptive binary arithmetic coding (CABAC) in video encoding. In particular, this document proposes to reduce the number of CABAC contexts used for one or more syntax elements, examples of which include pred_type, ref_idx_lx, cbf_cb, coeff_abs_level_greater1_flag, and coeff_abs_level_greater2_flag. Modifications can provide a reduction of up to 56 contexts with negligible changes in coding performance. The proposed context reductions for syntax elements can be used individually or in any combination.

[0007] A method for coding video data is described that includes determining a split type for a prediction mode for a video data block, encoding a binary symbol of the split type syntax of a prediction type video block using video CABAC coding with a single context, the single context being such alone for any type of division, and encoding the binary symbol size of the prediction type syntax element for the video data block using CABAC encoding in bypass mode.

[0008] A method for decoding video data is described which comprises receiving a prediction type syntax element for a video data block that has been encoded using encoding

53 / 59P36908PL00

EP 2 777 162 B1

CABAC, wherein the prediction type syntax element includes a split type binary symbol representing the split type and a split size binary symbol representing the split size, decode the binary symbol split type of the prediction type syntax element using context adaptive binary arithmetic coding with a single context, with a single the context is the same for any type of split, and decoding the binary symbol size of the prediction type syntax element using CABAC encoding in bypass mode.

[0009] A method of coding video data is described which comprises coding a coded Cb chrominance block tag for a video block using CABAC coding, wherein coding a coded CbAC chrominance block tag comprises using a set of contexts comprising one or more contexts as part of the CABAC coding. and coding the coded Cr chrominance block tag using CABAC coding, wherein the coding of the coded Cr chrominance block tag includes the use of the same set of contexts as the coded Cb chrominance block tag as part of the CABAC coding.

[0010] The details of one or more examples are set out in the accompanying drawings and the description below. Other features, objectives and advantages will become apparent based on the description and drawings, as well as the reservations.

BRIEF DESCRIPTION OF THE DRAWINGS [0011]

FIG. 1 is a block diagram illustrating an exemplary video coding and decoding system that can use the techniques described herein.

53 / 59P36908PL00

EP 2 777 162 B1

FIG. 2 is a block diagram illustrating an exemplary video encoder that can implement the techniques described herein.

FIG. 3 is a block diagram illustrating an example video decoder that can implement the techniques described herein.

FIG. 4 is a schematic diagram illustrating both types of square and non-square division.

FIG. 5 is a schematic diagram illustrating types of asymmetric division.

FIG. 6 is a flowchart illustrating an exemplary video coding method according to the invention.

FIG. 7 is a flowchart illustrating an exemplary video decoding method according to the invention. FIG. 8 is a flowchart illustrating an exemplary video coding method according to the invention.

FIG. 9 is a flowchart illustrating an exemplary video decoding method according to the invention. FIG. 10 is a flowchart illustrating an exemplary video coding method according to the invention.

DETAILED DESCRIPTION [0012] This document describes techniques for encoding data such as video data. In particular, the document describes techniques that can promote efficient coding of video data using contextual adaptive entropy coding processes. In particular, this document proposes to reduce the number of CABAC contexts used to encode syntax elements such as pred_type, merge_idx, inter_pred_flag, ref_idx_lx, cbf_cb, cbf_cr, coeff_abs_level_greater1_flag and coeff_abs_level_greater. Modifications reduce

53 / 59P36908PL00

EP 2 777 162 B1 with up to 56 contexts with negligible changes in coding performance. This document describes video coding for illustrative purposes. However, the techniques described in this document may also be used to encode other types of data.

[0013] FIG. 1 is a block diagram illustrating an example video encoding and decoding system 10 that can be configured to use context adaptive binary arithmetic coding (CABAC) techniques in accordance with examples of the present invention. As shown in FIG. 1, the system 10 includes a source device 12 that transmits the encoded video to the target device 14 via the communication channel 16. The encoded video data can also be saved on storage medium 34 or on server 36 files and can be accessed via target device 14 as required. When data is stored on a storage media or on a file server, the video encoder 20 can provide encoded video data to another device, such as a network interface, compact disc (CD), recorder or device for pressing Blu-ray discs or universal video discs (DVDs) ), or other devices for storing encoded video data on a storage medium. Similarly, a device separate from the video decoder 30, such as a network interface, CD or DVD reader, or the like, can recover encoded video data from a storage medium and provide the recovered data to the video decoder 30.

[0014] The source device 12 and the target device 14 can be any of a variety of different devices, including desktop computers, notebook computers (i.e. laptops), tablet computers, set-top boxes, handsets such as so-called smartphones , televisions, cameras, display devices, digital media players, video game consoles, or the like. In many cases, such devices can

53 / 59P36908PL00

EP 2 777 162 B1 be equipped to implement wireless communication. Thus, the communication channel 16 may include a wireless channel, a wired channel, or a combination of wireless and wired channels suitable for transmitting encoded video data. Similarly, target device 14 can access the file server 36 via any standard data connection, including an internet connection. It may include a wireless channel (e.g. Wi-Fi connection), wired connection (e.g. DSL, cable modem, etc.), or a combination of both that is suitable for accessing encoded video data saved on a file server.

[0015] CABAC coding techniques, according to the examples of the present invention, can be used in video coding to support any of a wide variety of multimedia applications, such as over-the-air broadcasting, cable television broadcasts, satellite broadcasts, video streaming, for example. via the Internet, digital video encoding for recording on a data storage medium, decoding digital video recorded on a data storage medium, or other applications. In some examples, the system 10 may be configured to support unidirectional or bidirectional video transmission to support applications such as video streaming, video playback, video broadcasting and / or video telephony.

[0016] In the example of FIG. 1, source device 12 includes a video source 18, video encoder 20, modulator / demodulator 22 and transmitter 24. In source device 12, video source 18 may include a source such as a video capture device such as a video camera, archive video containing previously captured video, a video resource interface for receiving video from a video content provider, and / or a computer graphics layout to generate computer graphics data as

53 / 59P36908PL00

Source video, or a combination of such sources. As one example, if the video source 18 is a video camera, the source device 12 and the target device 14 may form so-called video cameras or video phones. However, the techniques described in this document can be used essentially in video coding, and can be used in wireless and / or wired applications, or in an application in which the encoded video data is stored on a local disk.

[0017] Captured, previously captured or computer generated video may be encoded by a video encoder. The encoded video information can be modulated by modem 22 in accordance with a communication standard, such as a wireless communication protocol, and transmitted to target device 14 via transmitter 24. Modem 22 may include various mixers, filters, amplifiers or other components designed to modulate signals. The transmitter 24 may include systems for transmitting data, including amplifiers, filters and one or more antennas.

[0018] Captured, previously captured or computer generated video, which is encoded by the video encoder 20, can also be saved on storage medium 34 or on server 36 files for later use. The storage medium 34 may be Blu-ray discs, DVD discs, CD-ROMs, flash memory, or any other suitable storage medium for storing encoded video. The encoded video stored on the storage medium 34 can then be accessed by the target device 14 for decoding and playback. Although not shown in FIG. 1, in some examples, storage medium 34 and / or file server 36 can store transmitter output 24.

[0019] The file server 36 may be any type of server capable of storing the encoded video and transmitting the encoded video to the target device 14.

53 / 59P36908PL00

EP 2 777 162 B1

Exemplary file servers include a network server (e.g. for a website), an FTP server, network attached storage (NAS) devices, a local disk drive, or any other type of device capable of saving encoded video data and transmitting it to the target device. The transmission of encoded video data from a 36 file server can be streaming, download, or a combination of both. The target file server 14 can be accessed by the target device 14 via any standard data connection, including an internet connection. It may include a wireless channel (e.g. Wi-Fi connection), a wired connection (e.g. DSL, cable modem, Ethernet, USB, etc.), or a combination of both that is suitable for accessing encoded video data stored on the server files.

[0020] Target device 14, in the example of FIG. 1, includes receiver 26, modem 28, video decoder 30, and display device 32. Receiver 26 of destination device 14 receives information via channel 16, and modem 28 demodulates information to create a demodulated bit stream for video decoder 30. Information communicated via channel 16 may include a variety of different syntax information generated by the video encoder 20 for use by the video decoder 30 in decoding video data. Such submission may also be included in the encoded video data recorded on the storage medium 34 or on the server 36 files. Each of the video encoder 20 and the video decoder 30 may be part of a respective codec (CODEC) that is capable of encoding or decoding video data.

[0021] The display device 32 may be integrated with or on the outside of the target device 14. In some examples, the target device 14 may include an integrated display device, and may also be configured to connect to an external device

53 / 59P36908PL00

EP 2 777 162 B1. In other examples, the target device 14 may be a display device. Basically, the display device 32 displays the decoded video data to a user, and can include any of a variety of display devices, such as a liquid crystal display (LCD), a plasma display, an organic light-emitting diode (OLED) display, or any other type of display device.

[0022] In the example of FIG. 1, the communication channel 16 may include any wireless or wired communication medium, such as a radio frequency (RF) spectrum or one or more physical transmission lines, or any combination of wireless and wired carriers. The communication channel 16 may form part of a packet network, such as a local area network, wide area network, or a global network, such as the Internet. The communication channel 16 generally represents any suitable communication medium, or collection of different communications, for transmitting video data from the source 12 to the destination device 14, including any suitable combination of wired or wireless carriers. The communication channel 16 may include routers, switches, base stations or any other equipment that may be useful to allow communication from the source device 12 to the target device 14.

[0023] The video encoder 20 and video decoder 30 may operate in accordance with a video compression standard such as the High Performance Video Encoding Standard (HEVC) currently being developed by the Joint Collaborative Team on Video Coding (JCT-VC) within the Video Coding Experts group Group (VCEG) ITU-T and the ISO / IEC Motion Picture Experts Group (MPEG). The latest draft of the HEVC standard, referred to as "HEVC Working Draft 6" or "WD6" is described in document JCTVCH1003 by Bross et al., "High efficiency video coding of device carriers

53 / 59P36908PL00

EP 2 777 162 B1 (HEVC) text specification draft 6 "Joint Collaborative Team on

Video Coding (JCT-VC) in ITU-T SG16 WP3 and ISO / IEC

JTC1 / SC29 / WG11, 8th Meeting: San Jose, California, USA, February, 2012, which, from June 1, 2012, can be downloaded from http://phenix.intevry.fr/jct/doc_end_user/documents/8_San%20Jose/ WG11 / JCTVCH1003-v22.zip.

[0024] Alternatively, the video encoder 20 and the video decoder 30 may operate in accordance with proprietary or industrial standards, such as the ITU-T H.264 standard, alternatively referred to as MPEG-4, Part 10, advanced extensions of such standards.

however, the present invention is not limited to any particular coding standard. Other examples include MPEG-2 and ITU-T video coding (AVC) or the techniques of the present

H.263.

[0025] Although not shown in FIG. 1, in some aspects, both the video encoder 20 and the video decoder 30 may be integrated in the audio encoder and decoder, and may include appropriate MUX-DEMUX units, or other hardware and software, to support both audio and video in a shared data stream or separate data streams. If applicable, in some examples, MUX-DEMUX units may be in accordance with the ITU H.223 multiplexer protocol, or other protocols such as the user datagram protocol (UDP).

[0026] Both the video encoder 20 and the video decoder 30 can be implemented as any of a wide variety of suitable encoder circuits, such as one or more microprocessors, digital signal processors (DSP), special purpose integrated circuits (ASICs), directly programmable gate arrays (FPGAs), discrete logic, software, hardware, firmware or any combination thereof. When the techniques are implemented partly in software, the device can store

53 / 59P36908PL00

Instructions for the software in a suitable non-transitive computer readable medium and execute the instructions on the hardware using one or more processors to implement the techniques in accordance with the present invention. Each of the video encoder 20 and video decoder 30 may be included in one or more encoders or decoders, each of which may be integrated as part of a combined encoder / decoder (CODEC) in a respective device.

[0027] The video encoder 20 may implement any or all of the techniques of the present invention for CABAC encoding in the video coding process. Similarly, the video decoder 30 may implement any or all of the techniques for CABAC encoding in the video encoding process. The video encoder as described herein may refer to the video encoder or video decoder. Similarly, the video coding unit may relate to a video encoder or video decoder. Similarly, video encoding may relate to video encoding or video decoding.

[0028] In one example of the invention, the video encoder 20 can be configured to determine the first prediction type for the video slice in a P slice, represent the first prediction type as a syntax element of the P slice slice prediction type, and specify a second prediction type for the block video data in a B slice slice, representing the second prediction type as part of the B-slice slice prediction type syntax, determining the binarization of the Pslice slice for the Pslice slice prediction type syntax element, determining the binarization of the B-slice slice for the B-slice slice prediction syntax element, where the P-slice slice prediction syntax element and the slice type prediction syntax element B-slice are determined using the same binarization logic, and encoding video data based on the binarization of the P-slice slice prediction syntax element and the B-slice slice prediction syntax element.

53 / 59P36908PL00

[0029] In another example of the invention, the video decoder 30 may be configured to map the binaryized syntax element of the P-slice slice prediction type into a prediction type using binarization mapping for the video data block in the P slice slice, binaryized mapping syntax element of the B-slice slice prediction type to the prediction type using the same binarization mapping for the video data block in the B slice slice, and decoding video data based on mapped prediction types.

[0030] In another example of the invention, the video encoder 20 can be configured to determine the split type for the prediction mode for the video data block, encode the binary symbol encode of the split type syntax of the prediction type video block using the single context context CABAC coding the context is the same for any type of split, and encoding the binary symbol size of the prediction type syntax element for the video data block using CABAC encoding in bypass mode.

[0031] In another example of the invention, the video decoder 30 may be configured to receive a prediction type syntax element for a video data block that has been encoded using CABAC encoding, the prediction type syntax element comprising a split type binary symbol representing the split type and a binary symbol Split size representing the split size decoding the binary symbol of the prediction type syntax split element using single context CABAC coding, whereby the single context is the same for any type of split, and decoding the binary symbol of the prediction type syntax split element using CABAC encoding in bypass mode.

[0032] In another example of the invention, both the video encoder 20 and the video decoder 30 can be configured to

53 / 59P36908PL00

Coding a Cb chrominance block coded tag for a video data block using CABAC coding, wherein the coding of the Cb chrominance coded block tag comprises the use of a set of contexts containing one or more contexts as part of the CABAC coding, and for coding a coded chrominance block tag Cr using CABAC coding, wherein the coding of the coded Cr chrominance block tag includes the use of the same set of contexts as the coded Cb chrominance block tag as part of the CABAC coding.

[0033] The JCT-VC group is working on developing the HEVC standard. The HEVC standardization efforts are based on a growing video coding device model known as the HEVC (HM) test model. The HM model assumes several additional capabilities of video coding devices compared to existing devices according to, e.g., ITU-T H.264 / AVC. For example, while H.264 provides nine in-screen prediction coding modes, the HM model can provide up to thirty-three in-screen prediction coding modes. The following paragraph will discuss some aspects of the HM model in more detail.

[0034] In general, the working model of the HM model describes that a video frame or video can be divided into a sequence of tree blocks or largest coding units (LCU) that contain both luminance and chrominance samples. The tree block has a similar purpose to the H.264 macroblock. The slice contains many successive blocks of the tree in coding order. The video frame or picture can be divided into one or more slice slices. Each block of the tree can be divided into coding units (CU) according to a quadruple tree. For example, a tree block, such as a quad root tree node, can be divided into four child nodes, and each child node can in turn be a parent node and can be divided into four more nodes

53 / 59P36908PL00

Daughter children. The terminated, undivided child node, as the leaf node of the quad tree, contains the encoding node, i.e. the encoded video block. The syntax data associated with the coded bit stream may specify the maximum number of times the tree block splits, and may also specify the minimum size of the coding nodes.

[0035] The CU includes coding node and prediction units (PU) and transformation units (TU) associated with the coding node. The CU unit size basically matches the size of the coding node and usually must have a square shape. The CU unit size can range from 8x8 pixels, up to a tree block size of up to 64x64 pixels or more. Each CU may contain one or more PU units and one or more TU units. Syntax data associated with a CU may describe, for example, dividing the CU into one or more PU. The split modes may vary depending on whether the CU is bypassed or encoded in direct mode, encoded in intra-image prediction mode or in inter-image prediction mode. PU units can be divided so that they do not have a square shape. Syntax data associated with a CU may also describe, for example, dividing the CU into one or more TUs according to the quadruple tree. The TU unit may have a square or non-square shape.

[0036] The incoming HEVC standard allows transformations according to TUs, which can be different for different CUs. TUs typically have sizes based on the size of PU units with a given CU unit defined for a split LCU, although this case may not always be the case. TU units are usually the same size as or smaller than PU units. In some examples, residual samples corresponding to the CU unit may be

53 / 59P36908PL00

EP 2 777 162 B1 internally divided into smaller units using the quadruple tree structure known as the "residual quadruple tree" (RQT). RQT tree leaf nodes can be referred to as transformation units (TUs). The pixel difference values associated with the TU units can be transformed to create transformation coefficients that can be quantized.

[0037] Basically, the PU unit refers to data related to the prediction process. For example, when the PU unit is encoded in the intra-picture mode, the PU unit may contain data describing the intra-picture prediction mode for the PU unit. As another example, when the PU unit is encoded in cross-picture mode, the PU unit may contain data defining a motion vector for the PU unit. Data defining the motion vector for the PU unit may describe, for example, the horizontal component of the motion vector, vertical component of the motion vector, resolution for the motion vector (e.g. accuracy to one quarter pixel or accuracy to one eighth pixel), reference image as indicated by the vector motion, and / or a list of reference images (e.g., List 0, List 1 or List C) for the motion vector.

[0038] Basically, the TU unit is used for the transformation and quantization process. A CU unit having one or more PU units may also contain one or more transformation units (TUs). After prediction, the video encoder 20 may calculate residual values from the video block identified by the coding node according to the PU. The coding node is then updated to take into account the residual values of the reference instead of the original video block. Residual values contain pixel difference values that can be transformed into transformation coefficients, quantized and scanned using transformations and other transformation information specified in TU units to

53 / 59P36908PL00

EP 2 777 162 B1 to form arranged transformation coefficients for entropy coding. The coding node can be updated again to refer to these arranged transformation coefficients. This document usually uses the term "video block" to refer to the CU coding node. In some specific cases, the term "video block" may also be used in this document to refer to a treeblock, i.e. an LCU or CU that includes a coding node, and PU and TUs.

[0039] The video sequence usually includes a series of frames or video images. An image group (GOP) generally contains a series of one or more video images. The GOP group may contain syntax data in the GOP group header, the header of one or more images, or elsewhere that describe the number of images contained in the GOP group. Each slice of the image may contain slice syntax data that describe the encoding mode for the corresponding slice. The video encoder 20 typically operates on video blocks in individual slice video slices to encode video data. The video block may correspond to a coding node in the CU. Video blocks can have fixed or variable sizes, and may vary in size according to a particular encoding standard.

[0040] As an example, the HM model supports prediction for different CU unit sizes. Assuming that the specific CU unit size is 2Nx2N, the HM model supports intra-image prediction for PU unit sizes of 2Nx2N or NxN, and inter-image prediction for symmetrical PU units of 2Nx2N, 2NxN, Nx2N or NxN. The HM model also supports an asymmetrical split for inter-image prediction for PU unit sizes of 2NxnU, 2NxnD, nLx2N and nRx2N. Asymmetrical

53 / 59P36908PL00

In the split, one direction of the CU unit is not divided, while the other direction is divided into 25% and 75%. The part of the CU unit corresponding to 25% of the division is indicated by 'n' followed by the indication 'Up', 'Down', 'Left' or 'Right' (' Right "). Thus, for example, "2NxnU" refers to the CU 2Nx2N unit which is horizontally divided with the 2Nx0.5N PU unit at the top and the 2Nx1.5N PU unit at the bottom.

[0041] FIG. 4 is a schematic diagram illustrating both types of quadratic and non-square divisions for intra-image prediction and inter-image prediction.

Division 102 is a 2Nx2N division and can be used for both intra-image and inter-image prediction. Division 104 is an NxN division and can be used for both intra-image and inter-image prediction. Division 106 is a division of 2NxN and is currently used in HEVC coding for inter-image prediction. Division 108 is the division of Nx2N and is currently used in HEVC coding for inter-image prediction.

<td> 112</td><td>is</td><td>division</td><td>2NxnD</td><td>and is</td>

<td>in</td><td colspan="2">HEVC encoding</td><td>for</td><td>prediction</td>

<td> 114</td><td>is</td><td>division</td><td>nLx2N</td><td>and is</td>

<td>in</td><td colspan="2">HEVC encoding</td><td>for</td><td>prediction</td>

<td> 116</td><td>is</td><td>division</td><td>nRx2N</td><td>and is</td>

<td>in</td><td colspan="2">HEVC encoding</td><td>for</td><td>prediction</td>

[0042] FIG. 5 is a schematic diagram illustrating types of asymmetric division. Division 110 is a division of 2NxnU and is currently used in HEVC coding for inter-image prediction. Division currently used between images. Division currently used between images. Division currently used between images.

[0043] In this document, the designations "NxN" and "N na

N "can be used interchangeably to refer to the pixel dimensions of the video block in terms of vertical and horizontal dimensions, e.g. 16x16 pixels or 16 by 16 pixels. basically,

53 / 59P36908PL00

The 16x16 block will have 16 pixels in the vertical direction (y = 16) and 16 pixels in the horizontal direction (x = 16). Similarly, the NxN block generally has N pixels in the vertical direction and N pixels in the horizontal direction, with N representing a non-negative integer value. Pixels in a block can be arranged in rows and columns. In addition, blocks do not necessarily have to have the same number of pixels in the horizontal and vertical directions. For example, blocks may contain NxM pixels, where M is not necessarily equal to N.

[0044] After intra-picture or inter-picture predictive coding using the PU units of the CU, the video encoder 20 can calculate residual data to which transforms determined by the CUs of the TUs are applied. Residual data may correspond to pixel differences between the pixels of the uncoded image and the prediction values corresponding to CU units. The video encoder 20 can create residual data for the CU and then transform the residual data to form transformation coefficients.

[0045] After any transformations to create the transformation coefficients, the video encoder 20 may perform the transformation coefficient quantization. Quantization basically refers to a process in which transformation coefficients are quantized to reduce as much as possible the amount of data used to represent the coefficients, providing additional compression. The quantization process can reduce the bit depth associated with some or all coefficients. For example, the n-bit value may be rounded down to the m-bit value during quantization, where n is greater than m.

[0046] In some examples, the video encoder 20 may use a predetermined scan order to scan the quantized transformation coefficients to form a sorted vector that can be

53 / 59P36908PL00

EP 2 777 162 B1 entropy coded. In other examples, the video encoder 20 may perform adaptive scanning. After scanning the quantized transformation coefficients to form a one-dimensional vector, the video encoder 20 may entropy encode the one-dimensional vector, e.g. according to context adaptive variable length coding (CAVLC), context adaptive binary arithmetic coding (CABAC), syntax-based context-adaptive binary arithmetic coding (SBAC), entropy coding with Probability Interval Partitioning Entropy Coding) (PIPE) or other entropy coding technique. The video encoder 20 may also entropy encode syntax elements associated with the encoded video data for use by the video decoder 30 in decoding video data.

[0047] To implement CABAC encoding, the video encoder 20 may assign a context within the context model to the symbol to be transmitted. The context may relate, for example, to whether the adjacent symbol values are nonzero or not. To implement CAVLC encoding, the video encoder 20 may select a variable length code for the symbol to be transmitted. The code words in the VLC code can be built so that relatively short codes correspond to more likely symbols, while longer codes correspond to less likely symbols. In this way, by using the VLC code, you can save bits compared to, for example, using code words of equal length for each symbol to be transmitted. The likelihood determination can also be based on the context assigned to the symbol.

[0048] This document relates to context adaptive binary arithmetic coding (CABAC) entropy techniques or other entropy coders such as using entropy coding

53 / 59P36908PL00

Probability (PIPE) or related encoders. Arithmetic coding is a form of entropy coding used in many compression algorithms that have high coding efficiency because it is able to map symbols to non-integer code words. An example of an arithmetic coding algorithm is the type of Context Based Binary Arithmetic Coding (CABAC) used in H.264 / AVC.

[0049] In general, coding of data symbols using CABAC encoding involves one or more of the following steps:

(1) Binarization: If the symbol to be encoded has no binary value, it is mapped to a sequence of so-called "bins". Each binary symbol can have a value of "0" or "1".

(2) Context assignment: Each binary symbol (in normal mode) is assigned to the context. The context model determines how the context for a given binary symbol is calculated based on information available for the binary symbol, such as the values of previously encoded symbols or the number of binary symbols.

(3) Coding of binary symbols: binary symbols are encoded by an arithmetic encoder. To encode a binary symbol, the arithmetic coder requires, as an input value, the probability of the value of the binary symbol, i.e. the probability that the value of the binary symbol is equal to "0", and the probability that the value of the binary symbol is equal to "1". The (estimated) probability of each context is represented by an integer value called 'context state'. Each context has a state, and therefore the state (i.e. estimated probability) is the same for binary symbols assigned to one context, and it differs between contexts.

53 / 59P36908PL00

(4) Status update: The probability (status) for the selected context is updated based on the actual coded value of the binary symbol (e.g., if the value of the binary symbol was "1", the probability for "1" is increased).

[0050] It should be noted that entropy coding by probability intervals (PIPE) uses principles similar to the principles of arithmetic coding, and therefore can also use the techniques of the present invention.

[0051] CABAC encoding in H.264 / AVC and HEVC uses states, and each state is implicitly associated with probability by default. There are CABAC coding variants in which the symbol probability ("0" or "1") is used directly, i.e. the probability (or its integer version) is a state. For example, such CABAC coding variants are described in the document "Description of video coding technology proposal by France Telecom, NTT, NTT DOCOMO, Panasonic and Technicolor," JCTVC-A114, 1st JCT-VC Meeting, Dresden, DE, April 2010 hereinafter referred to as "JCTVC-A114", and in a document by A. Alshin and E. Alshin, "Multi-parameter probability update

JCTVC-F254, 6th JCT-VC Meeting, Torino, IT, hereinafter referred to as "JCTVC-F254".

[0052] This document proposes to reduce the number of binarizations and / or contexts used in CABAC coding. In particular, this document proposes techniques that can reduce the number of contexts used in CABAC coding by up to 56. With the number of contexts reduced by 56, the experimental results show a change in the bitdistortion (BD) rate of 0.00%, 0.01% and -0.13% under test conditions only for CABAC coding respectively " , July 2011, high efficiency intra-image (high efficiency intra53 / 59P36908PL00

EP 2 777 162 B1 only), random access and low-delay. As such, reducing the number of contexts needed reduces the memory requirement in both the encoder and decoder without significantly affecting coding performance.

[0053] In this document, it is proposed to reduce the number of CABAC contexts used for the syntax elements, pred_type, merge_idx, inter_pred_flag, ref_idx_lx, cbf_cb, cbf_cr, coeff_abs_level_greater1_flag and coeff_abs_level_greater2_flag. Modifications reduce up to 56 contexts with negligible changes in coding performance. The proposed context reductions for the syntax elements above can be used individually or in any combination.

[0054] The pred_type syntax element contains a prediction mode (pred_mode_flag) and a split type (part_mode) for each coding unit. The pred_mode_flag syntax element of 0 specifies that the current coding unit is encoded in cross-picture prediction mode. The syntax element pred_mode_flag of 1 specifies that the current coding unit is encoded in in-mode prediction mode. The part_mode syntax element specifies the split mode of the current coding unit.

[0055] The syntax element merge_idx [x0] [y0] defines the merging candidate index of the merger candidate list, where x0, y0 specify the location (x0, y0) of the upper left luminance sample of the considered prediction block relative to the upper left luminance sample . When merge_idx [x0] [y0] is not present, it is assumed that it is equal to 0. The list of linking candidates is a list of adjacent coding units for the current units from which traffic information can be copied.

[0056] The syntax element inter_pred_flag [x0] [y0] determines whether single prediction or double prediction is used for the current prediction unit. Indexes x0, y0 of the array

53 / 59P36908PL00

Determine the location (x0, y0) of the upper left luminance sample of the prediction block in question relative to the upper left luminance sample.

[0057] The syntax element ref_idx_lx refers to a specific reference image in the list of reference images.

[0058] The syntax elements cbf_cb, cbf_cr indicate whether or not chrominance transformation blocks (Cb and Cr, respectively) contain non-zero transformation coefficients. The syntax element cbf_cb [x0] [y0] [trafoDepth] equal to 1 specifies that the transformation block Cb contains one or more transformation coefficient levels that are not equal to 0. The indexes x0, y0 of the table determine the location (x0, y0) of the upper left luminance sample of the transformation block in question relative to the upper left luminance sample of the image. The index of the trafoDepth array determines the current level of internal division of the coding unit into blocks for the purposes of coding the transformation. The trafoDepth array index is 0 for blocks that correspond to coding units. When cbf_cb [x0] [y0] [trafoDepth] does not exist and the prediction mode is not an intra-picture prediction mode, it is concluded that cbf_cb [x0] [y0] [trafoDepth] is 0.

[0059] The syntax element cbf_cr [x0] [y0] [trafoDepth] equal to 1 specifies that the transformation block Cr contains one or more transformation coefficient levels that are not equal to 0. Indexes x0, y0 of the array specify location (x0, y0) upper left luminance sample of the transformation block in question relative to the upper left luminance sample of the image. The index of the trafoDepth array determines the current level of internal division of the coding unit into blocks for the purposes of coding the transformation. The trafoDepth array index is 0 for blocks that correspond to coding units. When cbf_cr [x0] [y0] [trafoDepth] does not occur and the prediction mode is not an intra-picture prediction mode,

53 / 59P36908PL00

It is concluded that the value of cbf_cr [x0] [y0] [trafoDepth] is equal to 0.

[0060] The syntax element coeff_abs_level_greater1_flag [n] determines, for scanning items n, whether there are transformation coefficient levels greater than 1. When coeff_abs_level_greater1_flag [n] does not occur, it is assumed to be 0.

[0061] The syntax element coeff_abs_level_greater2_flag [n] determines, for scanning position n, whether there are transformation coefficient levels greater than 2. When coeff_abs_level_greater2_flag [n] does not occur, it is assumed that it is equal to 0.

[0062] In one proposal for HEVC encoding, different binarizations for the pred_type syntax element are used in slice P slices of this document under conditions and B, as shown in Table 1. The proposed use of the same binarization for slice P and B slices Examples are shown in Tables 2-4. Table 5 shows the effect of coding efficiency on P slice slices in typical tests (see e.g. F. Bossen, "Common test and software reference configurations", JCTVCF900).

53 / 59P36908PL00

EP 2 777 162 B1

Table 1. Binarization for pred type in one proposal for HEVC encoding

<td rowspan="3">Type sector type slice</td><td rowspan="3">Value pred_type</td><td rowspan="3">PredMode (mode prediction)</td><td rowspan="3">PartMode (mode division)</td><td colspan="3">A string of binary symbols</td>

<td rowspan="2">cLog2CUSize> Log2MinCUSize (1)</td><td colspan="2">cLog2CUSize = = Log2MinCUSize</td>

<td>cLog2CUSize = = 3 &&! inter_4x4_enabled_flag (2)</td><td>cLog2CUSize> 3 | | inter_4x4_enabled_flag (3)</td>

<td rowspan="2">AND</td><td> 0</td><td>MODE_INTRA</td><td>PART_2Nx2N</td><td> -</td><td> 1</td><td> 1</td>

<td> 1</td><td>MODE_INTRA</td><td>PART_NxN</td><td> -</td><td> 0</td><td> 0</td>

<td rowspan="10">P</td><td> 0</td><td>MODE_INTER</td><td>PART_2Nx2N</td><td> 0 1</td><td> 0 1</td><td> 0 1</td>

<td> 1</td><td>MODE_INTER</td><td>PART_2NxN</td><td> 0 011</td><td> 0 01</td><td> 0 01</td>

<td> 2</td><td>MODE_INTER</td><td>PART_Nx2N</td><td> 0 0011</td><td> 0 00</td><td> 0 001</td>

<td> 4</td><td>MODE_INTER</td><td>PART_2NxnU</td><td> 0 0100</td><td> -</td><td> -</td>

<td> 5</td><td>MODE_INTER</td><td>PART_2NxnD</td><td> 0 0101</td><td> -</td><td> -</td>

<td> 6</td><td>MODE_INTER</td><td>PART_nLx2N</td><td> 0 00100</td><td> -</td><td> -</td>

<td> 7</td><td>MODE_INTER</td><td>PART_nRx2N</td><td> 0 00101</td><td> -</td><td> -</td>

<td> 3</td><td>MODE_INTER</td><td>PART_NxN</td><td> -</td><td> -</td><td> 0000</td>

<td> 4</td><td>MODE_INTRA</td><td>PART_2Nx2N</td><td> 1</td><td> 11</td><td> 11</td>

<td> 5</td><td>MODE_INTRA</td><td>PART_NxN</td><td> -</td><td> 10</td><td> 10</td>

53 / 59P36908PL00

EP 2 777 162 B1 (continuation)

<td rowspan="2">cLog2CUSize> Log2MinCUSize (1)</td><td colspan="2">cLog2CUSize = = Log2MinCUSize</td>

<td>cLog2CUSize = = 3 &&! inter_4x4_enabled_flag (2)</td><td>cLog2CUSize> 3 | | inter_4x4_enabled_flag (3)</td>

<td rowspan="10">B</td><td> 0</td><td>MODE_INTER</td><td>PART_2Nx2N</td><td> 1</td><td> 1</td><td> 1</td>

<td> 1</td><td>MODE_INTER</td><td>PART_2NxN</td><td> 011</td><td> 01</td><td> 01</td>

<td> 2</td><td>MODE_INTER</td><td>PART_Nx2N</td><td> 0011</td><td> 001</td><td> 001</td>

<td> 4</td><td>MODE_INTER</td><td>PART_2NxnU</td><td> 0100</td><td> -</td><td> -</td>

<td> 5</td><td>MODE_INTER</td><td>PART_2NxnD</td><td> 0101</td><td> -</td><td> -</td>

<td> 6</td><td>MODE_INTER</td><td>PART_nLx2N</td><td> 00100</td><td> -</td><td> -</td>

<td> 7</td><td>MODE_INTER</td><td>PART_nRx2N</td><td> 00101</td><td> -</td><td> -</td>

<td> 3</td><td>MODE_INTER</td><td>PART_NxN</td><td> -</td><td> -</td><td> 0001</td>

<td> 4</td><td>MODE_INTRA</td><td>PART_2Nx2N</td><td> 000</td><td> 000 0</td><td> 0000 0</td>

<td> 5</td><td>MODE_INTRA</td><td>PART_NxN</td><td> -</td><td> 000 1</td><td> 0000 1</td>

53 / 59P36908PL00

[0063] As can be seen in Table 1, slice I slices (e.g. slice slices that only contain intra-picture predicted blocks) contain two different types of prediction (pred_type). One binary symbol string (binarization) is used for an intra-image predicted block with the 2Nx2N split type, while another binary symbol string is used for the intra-image predicted block with the NxN split type. As shown in Table 1, the binary symbol string used for I slice slices does not depend on the size of the CU unit.

[0064] For slice slices P and B, in Table 1, different binary symbol strings are used for each pred_type value. In contrast, the value of pred_type depends on both the prediction mode used (inter-picture prediction or intra-picture prediction) and the type of partition. For slice P and B slices, the actual binary symbol string used also depends on the size of the CU being encoded and whether cross-picture prediction is enabled for the 4x4 block size or not.

[0065] The first column under the binary symbol string applies to a situation in which the logarithmic function of the CU unit size for a coded CU unit is greater than the logarithmic function of the minimum allowable CU size. According to one example in HEVC encoding, the first column of binary symbol strings is used if cLog2CUSize>

Log2MinCUsize. The logarithmic function is used to create a smaller number so that a smaller subsequent index can be used.

[0066] If the logarithmic function of the CU unit size for the coding CU unit is equivalent to the logarithmic function of the minimum allowable CU size (i.e. cLog2CUSize = = Log2MinCUSize), then one of columns 2 and 3 under the string of binary symbols in table 1 is

53 / 59P36908PL00

EP 2 777 162 B1 used for binarization selection. Column 2 is used when the log function of the CU unit size for an encoded CU unit is equivalent to 3 and cross-image prediction for a CU 4x4 unit is not enabled (i.e. cLog2CUSize = = 3 &&

! Inter_4x4_enabled_flag). Column 3 is used when the logarithmic function of the CU unit size for the CU unit to be coded is greater than 3 or when the inter-picture prediction for the CU 4x4 unit is enabled (i.e. cLog2CUSize> 3 || inter_4x4_enabled_flag).

[0067] Table 2 below shows exemplary binarizations, where slice P and B slices use the same binary symbol strings, according to one or more of the examples described herein. As shown in Table 2, P slice slices use the same binarizations used for B slice slices in Table 1. In this way, it is not necessary to save and use a separate set of contexts for both P and B slice slices. As such, the total number of contexts needed to encode the pred_type syntax element is reduced. In addition, only one mapping (instead of two) must be saved between the logic of the binary symbol string (shown in columns (1) - (3)) and the actual string of binary symbols.

53 / 59P36908PL00

EP 2 777 162 B1

Table 2. Binarization for pred type in one example of the invention

<td rowspan="3">Type of slice slice type</td><td rowspan="3">Pred_ type value</td><td rowspan="3">PredMode (mode prediction)</td><td rowspan="3">PartMode (mode division)</td><td colspan="3">A string of binary symbols</td>

<td rowspan="2">cLog2CUSize> Log2MinCUSize (1)</td><td colspan="2">cLog2CUSize = = Log2MinCUSize</td>

<td>cLog2CUSize = = 3 &&! inter_4x4_enabled_flag (2)</td><td>cLog2CUSize> 3 | | inter_4x4_enabled_flag (3)</td>

<td rowspan="2"> 1</td><td> 0</td><td>MODE_INTRA</td><td>PART_2Nx2N</td><td> -</td><td> 1</td><td> 1</td>

<td> 1</td><td>MODE_INTRA</td><td>PART_NxN</td><td> -</td><td> 0</td><td> 0</td>

<td rowspan="10">P or B.</td><td> 0</td><td>MODE_INTER</td><td>PART_2Nx2N</td><td> 1</td><td> 1</td><td> 1</td>