RU2575398C2 - Reduction of number of contexts for context adaptive binary arithmetic coding - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: method of encoding video data comprises determining a partition type for a prediction mode for a block of video data; encoding a partition type structural element of a prediction type syntax element for the block of video data using context adaptive binary arithmetic coding (CABAC) with a single context, wherein the single context is the same for any partition type; and encoding a partition size structural element of the prediction type syntax element for the block of video data using CABAC in bypass mode.

EFFECT: reducing the number of CABAC contexts used for one or more syntax elements without significant impact on coding efficiency.

32 cl, 10 dwg, 22 tbl

Description

[0001] This application claims the priority of provisional application US 61/557, 325, filed November 8, 2011, and provisional application US 61/561, 911, filed November 20, 2011, both of which are incorporated herein by reference throughout their fullness.

FIELD OF TECHNOLOGY

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

BACKGROUND OF THE INVENTION

[0003] Digital video capabilities can be incorporated into a wide range of devices, including digital TVs, digital direct broadcast systems, wireless broadcast systems, personal digital assistants (PDAs), laptop or desktop computers, tablet computers, e-books, digital cameras, digital recordings devices, digital media players, game video devices, game consoles, cellular or satellite radiotelephones, so-called “smartphones”, video teleconferencing devices, streaming video devices EO and the like. Digital video devices implement video compression technologies, such as those described in the standards defined by MPEG-2, MPEG-4, ITU-T Η.263, ITU-T Η.264 / MPEG-4, part 10, Advanced video encoding (AVC), the High Performance Video Coding (HEVC) standard currently under development, and an extension to such standards. Video devices can transmit, receive, encode, decode and / or store digital video information more efficiently by implementing such video compression methods.

[0004] Video compression techniques perform spatial (intra image, intra) prediction and / or temporal (between image, inter) prediction to reduce or eliminate redundancy inherent in video sequences. For block coding, a video slice (i.e., a video image or part of a video image) can be divided into video blocks, which can also be referred to as tree blocks, coding units (CUs) and / or coding nodes. Video blocks in an intra-coded (I) image slice (segment) are encoded using spatial prediction with respect to reference samples in neighboring blocks in the same image. Video blocks in an inter-coded (P or B) image segment may use spatial prediction for reference samples in neighboring blocks in the same image or temporal prediction for reference samples in other reference images. Images may be referred to as frames, and reference images may be referred to as reference frames.

[0005] Spatial or temporal prediction results in a prediction block for the block to be encoded. The residual data represents the pixel differences between the source block to be encoded and the prediction block. The inter-coded block is encoded in accordance with a motion vector that points to a block of reference samples forming a prediction block and residual data indicating the difference between the coded block and the prediction block. The intra-encoded block is encoded in accordance with the intra-encoding mode and the residual data. For further compression, the residual data can be converted from the pixel region to the transformation region, resulting in residual transform coefficients, which can then be quantized. The quantized transform coefficients originally ordered in a two-dimensional array can be scanned to form a one-dimensional vector of transform coefficients, and entropy coding can be applied to achieve even greater compression.

SUMMARY OF THE INVENTION

[0006] In general, this disclosure describes methods for context adaptive binary arithmetic coding (SAVAS) in a video coding process. In particular, this disclosure offers a reduction in the number of SAVAC contexts used for one or more syntax elements, non-limiting examples of which include pred_typ, merge_idx, inert_pred_flag, ref_idx__lx, cbf_cb, cbf_cr, coeff abs_level_greaterl_flag and coeff_abs_level_reg_reg_reg_reg_reg_reg_reg_reg_reg_reg_reg_reg_reg_reg_reg_reg_reg_reg_reg_reg_reg_reg_reg_reg_grel_greater. Modifications can reduce to 56 contexts with negligible changes in coding efficiency. The proposed contextual abbreviations for syntax elements can be used individually or in any combination.

[0007] In one embodiment, the video encoding method may include determining a first prediction type for a block of video data in a slice (segment), representing the first type of prediction as a syntax element of a prediction type Ρ segment, determining a second prediction type for a block of video data in In a segment, representing the second type of prediction as a syntax element of a type of prediction In a segment, the definition of binarization Ρ segment for a syntax element of a type of prediction Ρ segment, segmentation of B binarization for a syntax element of prediction type B segment, wherein the syntax element of prediction type Ρ segment and the syntax element of prediction type B are determined using the same binarization logic, and video encoding based on the binarization of the syntax element of prediction type Ρ segment and syntax prediction type element in the segment.

[0008] In another example of the present disclosure, a video decoding method may include mapping a binarized syntax element of a prediction type Ρ segment to a prediction type using a binarization map for a block of video data in a Ρ segment, mapping a binarized syntax element of a prediction type B segment to a prediction type using mapping binarization for a block of video data in the In segment, and decoding video data based on the displayed prediction types.

[0009] In another example of the present disclosure, a video encoding method includes determining a split type for a prediction mode for a video block, encoding a structural element of a split type syntax for a prediction type block for a video block using CABAC with one context, this single context being that the same for any type of separation, and encoding a structural element of a separation size of a prediction type syntax element for a video block using CABAC bypass mode.

[0010] In another example of the present disclosure, a method for decoding video data comprises receiving a prediction type syntax element for a block of video data that has been encoded using SAVAS, the prediction type syntax element including a separation type structural element representing a separation type and a size structural element. separation representing the size of the separation, decoding the structural element of the type of separation of the syntax element of the prediction type using context but-adaptive binary arithmetic coding with one context, and one context this is the same for any type of separation and decoding of the structural element separation type syntax prediction type element using CABAC in bypass mode.

[0011] In another example of the present disclosure, a video encoding method includes encoding a flag of a coded chroma block Cb for a video block using CABAC, wherein encoding a flag of a coded chroma block Cb includes using a set of contexts including one or more contexts as part of SAVAS, and encoding the flag of the encoded chroma block Cr using SAVAS, wherein encoding the flag of the encoded chroma block Cr contains using the same set of cont Kstovo as for the coded block flag chrominance Cb, as part of CABAC.

[0012] The present disclosure also describes the above methods in terms of devices configured to execute these methods, as well as in terms of computer-readable media for storing instructions that, when executed, cause one or more processors to execute these methods.

[0013] Details of one or more examples are provided in the accompanying drawings and description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] FIG. 1 is a block diagram illustrating an example video encoding and decoding system that may use the techniques described in the present disclosure.

[0015] FIG. 2 is a flowchart illustrating an example video encoder that can implement the methods described in the present disclosure.

[0016] FIG. 3 is a flowchart illustrating an example video decoder that can implement the methods described in the present disclosure.

[0017] FIG. 4 is a conceptual drawing showing both square and non-square types of separation.

[0018] FIG. 5 is a conceptual drawing showing asymmetric separation types.

[0019] FIG. 6 is a flowchart illustrating an example of a video encoding method according to the present disclosure.

[0020] FIG. 7 is a flowchart illustrating an example of a video decoding method according to the present disclosure.

[0021] FIG. 8 is a flowchart illustrating an example of a video encoding method according to the present disclosure.

[0022] FIG. 9 is a flowchart illustrating an example of a video decoding method according to the present disclosure.

[0023] FIG. 10 is a flowchart illustrating an example of a video encoding method according to the present disclosure.

DETAILED DESCRIPTION

[0024] The present disclosure describes methods for encoding data, such as video data. In particular, the present disclosure describes methods that can facilitate efficient coding of video data using context adaptive entropy coding processes. In particular, this disclosure proposes a reduction in the number of SAVAS contexts used to encode syntax elements such as pred_typ, merge_idx, inert_pred_flag, ref_idx_1x, cbf_cb, cbf_cr, coeff_abs_level_greaterl_flag and coeff_abs_level_greater. Modifications are reduced to 56 contexts with negligible changes in coding efficiency. The present disclosure describes video encoding for illustration purposes. However, the methods described herein may also be applicable to encoding other types of data.

[0025] FIG. 1 is a block diagram illustrating an example of a video encoding and decoding system 10 that can be configured to use context adaptive binary arithmetic coding (SAVAS) methods in accordance with examples of the present disclosure. As shown in FIG. 1, system 10 includes a source device 12 that transmits encoded video to a destination device 14 via a communication channel 16. The encoded video data may also be stored on the storage medium 34 or the file server 36, and the recipient device 14 may access it as desired. When stored on a storage medium or file server, video encoder 20 may provide encoded video data to another device, such as a network interface, compact disc (CD), programmer or Blu-ray punching equipment or DVD, or other devices, for storing encoded video data on a storage medium. In addition, a device separate from the video decoder 30, such as a network interface, a CD or DVD reader, or the like, can extract encoded video data from the storage medium and provide the extracted data to the video decoder 30.

[0026] The source device 12 and the recipient device 14 may include any of a wide variety of devices, including desktop computers, laptops (ie laptop computers), tablet computers, set-top boxes, telephones, such as so-called smartphones , televisions, cameras, display devices, digital media players, game consoles, or the like. In many cases, such devices may be equipped for wireless communication. Thus, the communication channel 16 may comprise a wireless channel, a wired channel, or a combination of wired and wireless channels suitable for transmitting encoded video data. Similarly, file server 36 can be accessed by destination device 14 via any standard data connection, including an Internet connection. This may include a wireless channel (for example, a Wi-Fi connection), a wired connection (for example, DSL, cable modem, etc.), or a combination of the two that is suitable for accessing encoded video data stored on a file server .

[0027] The SAVAS methods, in accordance with examples of the present disclosure, can be applied to video encoding to support any of a variety of multimedia applications, such as terrestrial television broadcasting, cable television broadcasts, satellite television broadcasts, streaming video streams, for example, over the Internet, encoding digital video for storage on a storage medium; decoding a digital video stored on a storage medium or other applications. In some examples, system 10 may be configured to support one-way or two-way video transmissions to support applications such as video streaming, video playback, video broadcasting and / or video telephony.

[0028] In the example of FIG. 1, the source device 12 includes a video source 18, a video encoder 20, a modulator / demodulator 22, and a transmitter 24. In the source device 12, the video source 18 may include a source, such as a video capture device, for example, a video camera, video archive containing previously captured video, a video channel interface for receiving video from a video content provider and / or a computer graphics system for generating computer graphics data as 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 receiving device 14 may form so-called camera telephones or video telephones. However, the methods described in the present disclosure can be applied to video encoding in general and can be applied to wireless and / or wired applications or an application in which encoded video data is stored on a local disk.

[0029] Captured, pre-captured or computer-generated video can be encoded using video encoder 20. The encoded video information can be modulated using a modem 22 in accordance with a communication standard, for example, a wireless communication protocol, and transmitted to a destination device 14 via a transmitter 24. The modem 22 may include various mixers, filters, amplifiers and other components designed to modulate the signal. The transmitter 24 may include circuits for transmitting data, including amplifiers, filters, and one or more antennas.

[0030] Captured, pre-captured or computer generated video encoded by video encoder 20 may also be stored on the storage medium 34 or the file server 36 for subsequent consumption. The storage medium 34 may include Blu-ray discs, DVDs, CD-ROMs, flash memory, or any other suitable digital storage medium for storing encoded video. The encoded video stored on the storage medium 34 may then be available to the recipient device 14 for decoding and playback. Although not shown in FIG. 1, in some examples, the storage medium 34 and / or the file server 36 may store the output of the transmitter 24.

[0031] File server 36 may be any type of server capable of storing encoded video and transmitting this encoded video to a recipient device 14. Exemplary file servers include a web server (eg, for a website), an FTP server, storage devices, connected to a network (NAS), local disk, or any other type of device capable of storing encoded video data and transmitting it to a recipient device. The transmission of the encoded video data from the file server 36 may be streaming, downloading, or a combination of the two. File server 36 can be accessed by destination device 14 via any standard data connection, including an Internet connection. This may include a wireless channel (for example, a Wi-Fi connection), a wired connection (for example, DSL, cable modem, Ethernet, USB, etc.), or a combination of both that is suitable for access to encoded video data, stored on a file server.

[0032] The recipient device 14, in the example of FIG. 1 includes a receiver 26, a modem 28, a video decoder 30, and a display device 32. The receiver 26 of the recipient device 14 receives information on channel 16, and the modem 28 demodulates information to obtain a demodulated bit stream for video decoder 30. The information transmitted through channel 16 may include various syntactic information generated by video encoder 20 for use by video decoder 30 when video decoding. Such syntax may also be included in encoded video data stored on the storage medium 34 or file server 36. Each of the video encoder 20 and video decoder 30 may be part of a corresponding encoder-decoder (codec) that is capable of encoding or decoding video data.

[0033] The display device 32 may be internal or external to the recipient device 14. In some examples, the recipient device 14 may include an integrated display device, and may also be configured to interact with an external display device. In other examples, the recipient device 14 may be a display device. In general, the display device 32 displays decoded video data to a user and may comprise 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 another type of display device.

[0034] In the example of FIG. 1, communication channel 16 may comprise any wired or wireless communication medium, for example, a radio frequency (RF) spectrum or one or more physical transmission lines, or any combination of wireless and wired transmission media. Communication channel 16 may be part of a packet network, such as a local area network, a wide area network, or a wide area network such as the Internet. Communication channel 16 is typically any suitable communication medium or a set of different communication media for transmitting video data from source device 12 to destination device 14, including any suitable combination of wired or wireless transmission media. Communication channel 16 may include routers, switches, base stations, or any other equipment that may be useful for providing communication from source device 12 to destination device 14.

[0035] Video encoder 20 and video decoder 30 may operate in accordance with a video compression standard, such as the High Efficiency Video Encoding (HEVC) standard, currently under development by the ITU-T Joint Video Encoding Team (JCT-VC) Expert Group Video Encoding (VCEG) and ISO / IEC Moving Picture Experts Group (MPEG). A recent draft of the HEVC standard, called "HEVC Work Draft 6" or "WD6", is described in JCTVC-H1003, Bross et al., "High efficiency video coding (HEVC) text specification draft 6," of the Joint Video Encoding Team ( JCT-VC) ITU-T SGI 6 WP3 and ISO / IEC JTC1 / SC29 / WG11, 8th meeting: San Jose, California, USA, February 2012, which as of June 1, 2012 can be downloaded from http: //phenix.int-evry.fr/jct/doc_end_user/documents/8_San%20Jose/wg11/JCTVC-1003-v22.zip.

[0036] In addition, video encoder 20 and video decoder 30 may operate in accordance with other proprietary or industry standards, such as ITU-T No. 2 64, alternatively referred to as MPEG-4, part 10, Advanced video encoding (AVC), or expanding such standards. The methods of the present disclosure, however, are not limited to any particular coding standard. Other examples include MPEG-2 and ITU-T No. 263.

[0037] Although not shown in FIG. 1, in some aspects, video encoder 20 and video decoder 30 may each be integrated with an audio encoder and decoder and may include respective MUX-DEMUX units or other hardware and software for processing audio and video encoding in a common data stream or separate streams data. If applicable, in some examples, the MUX-DEMUX units may conform to the ITU H.223 multiplexer protocol or other protocols, such as the user datagram protocol (UDP).

[0038] Video encoder 20 and video decoder 30, each, can be implemented as any of a variety of suitable encoder circuits, such as one or more microprocessors, digital signal processors (DSP), specialized integrated circuits (ASIC), programmable gate arrays (FPGA), discrete logic, software, hardware, firmware, or any combination thereof. When the technologies are partially implemented in software, the device may store instructions for the software on a suitable, permanent computer-readable medium and execute instructions in hardware using one or more processors to perform the methods of the present disclosure. Each of 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 corresponding device.

[0039] Video encoder 20 may implement any or all of the methods of the present disclosure for SAVAS in a video encoding process. In addition, video decoder 30 may implement some or all of these methods for SAVAS in the video encoding process. A video encoding device, as described in this disclosure, may refer to a video encoder or video decoder. Similarly, a video encoding unit may refer to a video encoder or video decoder. In addition, video encoding may relate to video encoding or video decoding.

[0040] In one example of the present disclosure, video encoder 20 may be configured to determine a first prediction type for a block of video data in a Ρ segment, represent the first type of prediction as a syntax element of a prediction type Ρ segment, define a second type of prediction for a block of video data in a менте segment, represent the second type of prediction as a syntactic element of the prediction type of the B segment, determine the binarization of the для segment for the syntax element of the prediction type of the Ρ segment, determine the binarization of B The segment for the prediction type syntax element is B segment, and the prediction type syntax element Ρ segment and the prediction type syntax element B segment are determined using the same binarization logic, and encode video data based on the binarization of the Ρ segment prediction type syntax element and the prediction type syntax element In a segment.

[0041] In another example of the present disclosure, video decoder 30 may be configured to map a binarized prediction type syntax element of a Ρ segment to a prediction type using a binarization map for a video data block in a Ρ segment, to map a binarized prediction type syntax element of a сегмента segment to a prediction type using the same binarization mapping for the video block in the In segment, and decode the video data based on the displayed prediction types.

[0042] In another example of the present disclosure, video encoder 20 may be configured to determine a partition type for a prediction mode for a video block, encode a structural element of a partition type of a prediction type syntax element for a video block using CABAC with one context, this one context is the same for any type of separation, and encode the structural element of the separation size of the prediction type syntax element for the video block using SAVAS in Bypass Mode.

[0043] In another example of the present disclosure, video decoder 30 may be configured to receive a prediction type syntax element for a block of video data that has been encoded using SAVAS, the prediction type syntax element including a division type structure element representing a division type, and a partition size structure element representing a partition size, decode a prediction type syntax element partition type structure element using CAB AS with one context, and this one context is the same for any type of separation, and decode the structural element of the size of the separation of the syntax element of the prediction type using SAVAS in bypass mode.

[0044] In another example of the present disclosure, both video encoder 20 and video decoder 30 may be configured to encode a flag of a coded chroma block Cb for a video block using CABAC, wherein encoding a flag of a coded chroma block Cb includes using a set of contexts including one or more contexts as part of SAVAS, and encode the flag of the encoded chroma block Cr using SAVAS, wherein the encoding of the flag of the encoded chroma chromium block contains the same set itself contexts as for the chrominance Cb coded block flag as part of CABAC.

[0045] JCT-VC is working on the development of the HEVC standard. HEVC standardization efforts are based on an evolving model of a video encoding device called the HEVC Test Model (NM). NM involves several additional features of video encoding devices relative to existing devices in accordance with, for example, ITU-T H.264 / AVC. For example, while H.264 provides nine intra-prediction coding modes, HM can provide thirty-three intra-prediction coding modes. The next section will describe in more detail some aspects of NM.

[0046] In general, an NM working model describes that a video frame or image can be divided into a sequence of tree blocks or largest coding units (LCUs), which include both brightness and color samples. A tree block has a purpose similar to that of an H.264 macroblock. A segment (slice) includes a series of consecutive blocks of a tree in coding order. A video frame or image may be divided into one or more segments. Each block of the tree can be divided into coding units (CU) in accordance with the quad tree. For example, a tree block, as the root node of a quad tree, can be divided into four child nodes, and each child node, in turn, can be a parent node and can be divided into the following four child nodes. The final, inseparable child node, like the leaf node of a quad tree, includes an encoding node, i.e., a block of encoded video. The syntax data associated with the encoded bitstream can determine the maximum number of times a tree block is split, and can also determine the minimum size of encoding nodes.

[0047] The CU includes a coding unit and prediction units (PUs) and transform units (TUs) associated with the coding unit. The size of the CU usually corresponds to the size of the encoding node and usually should be square. The CU size can range from 8x8 pixels to a tree block size with a maximum of 64 × 64 pixels or more. Each CU may contain one or more PUs and one or more TUs. The syntax data associated with the CU may describe, for example, the division of the CU into one or more PUs. Separation modes may differ depending on whether the CU is skipped, or encoded in direct mode, encoded in intra prediction mode, or encoded in inter prediction mode. PU can be divided to be in non-square form. The syntax data associated with the CUs may also describe, for example, splitting a CU into one or more TUs in accordance with a quad tree. TU can be square or non-square.

[0048] The new HEVC standard allows for TU transformations, which may be different for different CUs. TUs typically have a size depending on the size of the PU within a given CU defined for a split LCU, although this may not always be the case. TUs are usually the same size, or smaller than PUs. In some examples, the residual samples corresponding to the CU can be divided into smaller units using a quad tree structure known as a “residual quad tree” (RQT). RQT leaf nodes may be referred to as transformation units (TUs). The pixel difference values associated with the TU can be converted to obtain transform coefficients that can be quantized.

[0049] In general, a PU refers to data related to a prediction process. For example, when the PU is intra-coded, the PU may include data describing the intra prediction mode for the PU. As another example, when the PU is inter-mode encoded, the PU may include data defining a motion vector for the PU. The motion vector data for the PU can describe, for example, the horizontal component of the motion vector, the vertical component of the motion vector, the resolution for the motion vector (for example, one quarter pixel accuracy or one eighth pixel precision), the reference image pointed to by the vector motion, and / or a list of reference images (for example, list 0, list 1 or list C) for the motion vector.

[0050] In general, TU is used for transformation and quantization processes. A given CU having one or more PUs may also include one or more transformation units (TUs). After the prediction, video encoder 20 may calculate the residual values from the video block identified by the encoding node in accordance with the PU. The encoding node is then updated to refer to residual values instead of the original video block. Residual values contain pixel difference values that can be converted to transform coefficients, quantized, and scanned using transforms and other information

transform defined in TU to create serialized transform coefficients for entropy coding. The coding unit may again be updated to refer to these serialized transform coefficients. The present disclosure typically uses the term “video block” to refer to a CU encoding node. In some specific cases, the present disclosure may also use the term “video block” to refer to a tree block, i.e. LCU or CU, which includes an encoding node and PU and TU.

[0051] A video sequence typically includes a series of video frames or images. A group of images (GOP) typically includes a sequence of one or more video images. A GOP may include syntax data in a GOP header, a header of one or more images, or elsewhere that describes a series of images included in the GOP. Each image segment may include segment syntax data that describes the encoding mode for the corresponding segment. Video encoder 20 typically operates on blocks of video in separate video segments to encode video data. The video block may correspond to an encoding node within the CU. Video blocks may have fixed or variable sizes and may vary in size in accordance with a given coding standard.

[0052] As an example, HM supports prediction in various PU sizes. Assuming that the size of a specific CU is 2Ν × 2Ν, NM supports intra prediction in PUs of 2Ν × 2Ν or Ν × Ν, and inter prediction in symmetric PUs of 2Ν × 2Ν, 2Ν × Ν, Ν × 2Ν or Ν × Ν. NM also supports asymmetric separation for inter prediction in PUs of sizes 2N × nU, 2N × nD, nL × 2N and nR × 2N. In asymmetric separation, one direction of the CU is not divided, and the other direction is divided by 25% and 75%. The portion of the CU corresponding to the 25% separation is indicated by “n” followed by “up”, “down”, “left” or “right”. So, for example, “2N × nU” refers to 2N × 2N CU, which is divided horizontally with 2N × 0.5N PU on top and 2N × 1.5N PU on the bottom.

[0053] FIG. 4 is a conceptual diagram illustrating both square and non-square separation types for intra prediction and inter prediction. Division 102 is a 2N × 2N division and can be used for both intra prediction and inter prediction. Division 104 is a Ν × Ν division and can be used for both intra prediction and inter prediction. Division 106 is a 2Ν × Ν division and is currently used in HEVC for inter prediction. Separation 108 is a Ν × 2Ν division and is currently used in HEVC for inter prediction.

[0054] FIG. 5 is a conceptual diagram showing asymmetric separation types. Split 110 is a 2N × nU split and is currently used in HEVC for inter prediction. Division 112 is a 2N × nD division and is currently used in HEVC for inter prediction. Division 114 is an nL × 2N division and is currently used in HEVC for inter prediction. Division 116 is an nR × 2N division and is currently used in HEVC for inter prediction.

[0055] In this description, “N × N” and “N by N” can be used interchangeably to indicate the pixel sizes of a video block vertically and horizontally, for example, 16 × 16 pixels or 16 by 16 pixels. In general, a 16 × 16 block will have 16 pixels in the vertical direction (y = 16) and 16 pixels in the horizontal direction (x = 16). Similarly, an N × N block, in general, has N pixels in the vertical direction and N pixels in the horizontal direction, where N is a non-negative integer. Pixels in a block can be arranged in rows and columns. In addition, the blocks do not have to have the same number of pixels in the horizontal direction and in the vertical direction. For example, blocks may contain N × M pixels, where Μ is not necessarily equal to N.

[0056] After intra-prediction or inter-prediction encoding using the PU for the CU, video encoder 20 may calculate the residual data to which the transforms indicated by the TU to the PU are applied. Residual data may correspond to a difference in pixels between the pixels of the unencoded image and the prediction values corresponding to the CU. Video encoder 20 may generate residual data for the CU, and then convert the residual data to obtain transform coefficients.

[0057] After any transforms, to generate transform coefficients, video encoder 20 may quantize the transform coefficients. Quantization generally refers to a process in which transform coefficients are quantized to possibly reduce the amount of data used to represent the coefficients, providing further compression. The quantization process can reduce the bit depth associated with some or all of the coefficients. For example, an n-bit value can be rounded down to an m-bit value during quantization, where n is greater than t.

[0058] In some examples, video encoder 20 may use a predetermined scan order to scan the quantized transform coefficients to obtain a serialized vector that can be entropy encoded. In other examples, video encoder 20 may perform adaptive scanning. After scanning the quantized transform coefficients to form a one-dimensional vector, video encoder 20 can entropy encode a one-dimensional vector, for example, in accordance with context-adaptive variable-length coding (CAVLC), context-adaptive binary arithmetic coding (CABAC) based on context-adaptive syntax binary arithmetic coding (SBAC), entropy coding with separation of the probability interval (PIPE), or other method of entropy coding. Video encoder 20 may also entropy encode syntax elements associated with encoded video data for use by video decoder 30 in decoding video data.

[0059] To perform SAVAS, video encoder 20 may assign a context in the context model for the character to be transmitted. The context may relate, for example, to whether neighboring values of the symbol are nonzero or not. To perform CAVLC, video encoder 20 may select a variable-length code for the character to be transmitted. VLC codewords can be designed so that relatively shorter codes correspond to more likely characters, while longer codes correspond to less likely characters. Thus, the use of VLC can achieve savings in bits compared to, for example, using codewords of the same length for each character to be transmitted. The definition of probability may be based on the context assigned to the symbol.

[0060] The present disclosure relates to methods for entropy encoders of context adaptive binary arithmetic coding (CABAC) or other entropy encoders, such as entropy coding with separation of probability intervals (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 characters to non-integer codewords. An example of an arithmetic coding algorithm is the context-based binary arithmetic coding (SAVAS) used in H.264 / AVC.

[0061] In general, encoding data symbols using SAVAS includes one or more of the following steps:

(1) Binarization: If the character to be encoded is not a binary value, it is displayed on a sequence of so-called "structural elements". Each structural element can have a value of "0" or "1".

(2) Context Assignment: Each structural element (in normal mode) is assigned a context. The context model determines how context is calculated for a given structural element based on information available for the structural element, such as the values of previously encoded characters or the number of structural elements.

(3) Coding of structural elements: Structural elements are encoded by an arithmetic encoder. To encode a structural element, the arithmetic encoder requires as input the probability of the value of the structural element, that is, the probability that the value of the structural element is "0" and the probability that the value of the structural element is "1". The (estimated) probability of each context is represented by an integer called the "context state". Each context has a state, and thus the state (i.e. the estimated probability) is the same for the structural elements assigned to one context, and differs between contexts.

(4) Status update: The probability (state) for the selected context is updated based on the actual encoded value of the structural element (for example, if the value of the structural element was "1," probability "1" increases).

[0062] It should be noted that probability interval separation entropy coding (PIPE) uses principles similar to arithmetic coding principles, and thus may also use the method of the present disclosure.

[0063] SAVAS in H.264 / AVC and HEVC uses states, and each state is implicitly associated with probability. There are variants of SAVAS in which the probability of a symbol ("0" or "1") is used directly, that is, probability (or its integer version) is a state. For example, such SAVAS options are described in "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 A. Alshin and Ε. Alshina, “Multi-parameter probability update for CABAC”, JCTVC-F254, 6th JCT-VC Meeting, Torino, IT, July 2011, hereinafter referred to as “JCTVC-F254”.

[0064] The present disclosure proposes a reduction in the number of binarizations and / or contexts used in SAVAS. In particular, the present disclosure proposes methods that can reduce the number of contexts used in SAVAS by up to 56. With 56 less contexts, experimental results show 0.00%, 0.01%, and -0.13% change bit distortion frequencies (BD) in high-performance intra-mode only, random access and low latency test conditions, respectively. Thus, a reduction in the number of contexts required reduces storage requirements in both the encoder and the decoder without significantly affecting coding efficiency.

[0065] The present disclosure proposes a reduction in the number of SAVAS contexts used for the syntax elements pred_typ, merge_idx, inert_pred_flag, ref_idx_1x, cbf_cb, cbf cr, coeff_abs_level_greaterl_flag and coeff_abs_level_greater2_flag. Modifications are reduced to 56 contexts with negligible changes in coding efficiency. The proposed contextual abbreviations for the syntax elements above can be used individually or in any combination.

[0066] The pred_type syntax element includes a prediction mode (pred_mode_flag) and a partition type (part_mode) for each coding unit. The syntax element pred mode flag, equal to 0, determines that the current coding unit is encoded in inter-prediction mode.

The pred_mode_flag syntax element of 1 indicates that the current encoding unit is encoded in intra-prediction mode. The syntax element part_mode defines the split mode of the current coding unit.

[0067] The syntax element merge_jdx [x0] [y0] defines the merge candidate indices of the merge candidate list, where x0, y0 determine the location (x0, y0) of the upper left luma sample of the prediction block in relation to the upper left sample luma sample. When merge_jdx [x0] [y0] is absent, it is concluded that it is 0. The list of merge candidates is a list of neighboring coding units with the current units from which motion information can be copied.

[0068] The syntax element inter_pred_flag [x0] [y0] determines whether mono prediction or bi prediction is used for the current prediction unit. The array indices x0, y0 determine the location (x0, y0) of the upper-left brightness sample of the prediction block in relation to the upper-left image brightness sample.

[0069] The syntax element ref_idx_1x refers to a particular reference image within the list of reference images.

[0070] The syntax elements cbf_cb, cbf_cr indicate contain color conversion blocks (Cb and Cr, respectively) non-zero transform coefficients. The syntax element cbf_cb [x0] [y0] [trafoDepth], equal to 1, determines that the transform block Cb contains one or more levels of transform coefficients other than 0. The array indices x0, y0 indicate the location (x0, y0) of the upper-left sample brightness of the conversion unit under consideration with respect to the upper-left image brightness sample. The trafoDepth array index indicates the current level of division of the coding unit into blocks for the purpose of coding the transform. The index of the trafoDepth array is 0 for blocks that correspond to coding units. When cbf_cb [x0] [y0] [trafoDepth] is not present, and the prediction mode is not intra prediction, the value cbf_cb [x0] [y0] [trafoDepth] is output as 0.

[0071] The syntax element cbf_cr [x0] [y0] [trafoDepth] equal to 1 indicates that the Cr transform unit contains one or more levels of transform coefficients other than 0. The array indices x0, y0 indicate the location (x0, y0) of the upper - the left luma sample of the conversion unit under consideration with respect to the upper-left luma sample image. The trafoDepth array index indicates the current level of division of the coding unit into blocks for the purpose of coding the transform. The index of the trafoDepth array is 0 for blocks that correspond to coding units. When cbf_cr [x0] [y0] [trafoDepth] is not present, and the prediction mode is not intra-prediction, the value cbf_cr [x0] [y0] [trafoDepth] is output equal to 0.

[0072] The syntax element coeff_abs_level_greaterl_flag [n] indicates for scan position n whether there are conversion coefficient levels greater than 1. When coeff_abs_level_greaterl_flag [n] is not present, it is concluded that it is 0.

[0073] The syntax element coeff_abs_level_greater2_flag [n] indicates for scan position n whether there are conversion coefficient levels greater than 2. When coeff_abs_level_greater2_flag [n] is not present, it is concluded that it is 0.

[0074] In one sentence for HEVC, different binarizations for the pred_type syntax element are used in Ρ and B segments, as shown in Table 1. The present disclosure proposes to use the same binarizations for Ρ and B segments. Examples are given in tables 2-4. Table 5 shows the effect of coding efficiency on the Ρ segment under standard test conditions (see, for example, F. Bossen, "Common test conditions and software reference configurations", JCTVC-F900).

[0075] As can be seen from table 1, I segments (for example, segments that include only intra-prediction blocks) include two different types of prediction (pred_type). One row of a structural element (binarization) is used for an intra-prediction block with a division type of 2N × 2N, and another row of a structural element is used for an intra-prediction block with a division type of N × N. As shown in table 1, the line of the structural element used for I segments does not depend on the size of the CU.

[0076] For the Ρ and B segments, in Table 1, different lines of the structural element are used for each pred_type value. Again, the pred_type value depends on both the prediction mode (inter prediction or intra prediction) and the type of separation used. For Ρ and B segments, the actual line of the structural element used additionally depends on the size of the encoded CU and on whether inter prediction is supported for a 4 × 4 block size.

[0077] The first column below the row of the structural element is used for a situation where the logarithmic function of the size of the CU of the encoded CU exceeds the logarithmic function of the minimum allowable size of the CU. According to one example in HEVC, the first row column of a structural element is used if cLog2CUSize> Log2MinCUsize. The logarithmic function is used to create a smaller number, so a smaller sequential index can be used.

[0078] If the logarithmic function of the size of the CU of the encoded CU is equivalent to the logarithmic function of the minimum allowable size of the CU (ie cLog2CUSize == Log2MinCUSize), then one of the columns 2 and 3 below the row of the structural element in table 1 is used to select the binarization. Column 2 is used when the logarithmic function of the CU size of the encoded CU is equivalent to 3, and inter prediction for 4 × 4 CUs is not supported (i.e. cLog2CUSize == 3 &&! Inter_4 × 4_enabled_flag). Column 3 is used when the logarithmic function of the CU size for the encoded CU is greater than 3, or when inter prediction for the 4 × 4 CU is supported (that is, cLog2CUSize> 3 || inter_4 × 4_enabled_flag).

[0079] Table 2 below shows examples of binarization, where Ρ and B segments use the same lines of a structural element, in accordance with one or more examples described in the present disclosure. As shown in Table 2, the Ρ segments use the same binarization used for the B segments in table 1. Thus, there is no need to store and use a separate set of contexts for the Ρ and B segments. Thus, the total number of contexts needed to encode the pred_type syntax element is reduced. In addition, only one mapping (instead of two) between the row logic of the structural element (shown in columns (1) - (3)) and the actual row of the structural element must be saved.

[0080] Table 3 below shows another example of binarization for pred_type. In this example, B segments use the same binarization as Ρ segments from Table 1. Table 4 below shows an additional example where, segments and B segments use the same binarizations. Tables 2-4 are intended only to show examples of common binarizations between Ρ and B segments. Any binarization or binarization rules can be used so that the syntax elements pred_type for Ρ and B segments share the same binarization.

[0081] Video encoder 20 and video decoder 30 may store the same display rules and display tables (for example, as shown in Tables 2-4) for use with Ρ and B segments. CABAC encoding and decoding can be applied to the pred_type syntax element using these mappings.

[0082] Thus, video encoder 20 may be configured to determine a first prediction type for a block of video data in a Ρ segment, represent a first type of prediction as a syntax element of a prediction type Ρ segment, define a second type of prediction for a block of video data in a, segment, represent a second type predictions as a syntax element of type prediction In a segment, define binarization Ρ segment for a syntax element of type prediction Ρ segment, define binarization In a segment for syntax of the prediction type element in the segment, the syntax element of the prediction type Ρ segment and the syntax element of the prediction type in the segment are determined using the same binarization logic, and encode video data based on binarizations of the syntax element of the prediction type Ρ segment and the syntax element of the prediction type in the segment.

[0083] Video encoder 20 may be further configured to binarize a prediction type syntax element Ρ a segment with a specific Ρ segment binarization, binarize a prediction type syntax element on a segment with a certain binarization on a segment, applying context adaptive binary arithmetic coding (SAVAS) to the binarized syntax element type of segment prediction применения and application of context adaptive binary arithmetic coding (SAVAS) to a binarized system taksicheskomu element prediction type B segment.

[0084] Similarly, video decoder 30 may be configured to map the binarized syntax element of the Ρ segment prediction type to the prediction type using a binarization map for the video block in the Ρ segment, display the binarized syntax element of the В segment prediction type to the prediction type using the same the binarization mapping itself for a block of video data in the In segment and decoding video data based on the displayed prediction types.

[0085] Video decoder 30 may be further configured to receive a context-adaptive binary arithmetic coding syntax element of a prediction type Ρ segment that indicates a prediction type for a video block in a Ρ segment, to receive a context-adaptive binary arithmetic coding syntax element of a prediction type B a segment that indicates the type of prediction for the video block in the In segment, decode a syntax element of the prediction type anija Ρ segment to form the binarized syntax element Ρ prediction type segment, and decoding the syntax element in a prediction type segment to form a prediction type of the binarized syntax element in the segment.

[0086] Table 5 below shows the coding performance using common binarization for the Ρ and B segments shown in Table 2. As can be seen from Table 5, negligible coding efficiency is lost (or not lost at all) when using common binarizations. NOT (high performance) low latency Ρ is a general test condition for binarizations of unidirectionally predicted (P) segments. Classes AE represent different frame resolutions. Class A corresponds to a resolution of 2k × 4k. Class B corresponds to a resolution of 1920 × 1080. Class C corresponds to WVGA resolution. Class D corresponds to WQVGA resolution. Class Ε corresponds to a resolution of 720P. A change from 0.1 to 0.2 percent under the test condition of NOT a low delay P is generally considered insignificant.

[0087] Optionally, the same binarizations (not limited to tables 2-4) for the prediction type (includes prediction size and / or prediction mode) can be shared in two or more different types of inter prediction segments. Inter prediction segments may include, but are not limited to:

a. Ρ segment: the segment only supports unidirectional motion prediction

b. Per Segment: The segment supports unidirectional and bidirectional motion prediction

c. In scalable video encoding: An enhanced layer can share the same binarizations with the base layer.

d. In multi-view coding: different types (representations) can share the same binarizations.

[0088] When asymmetric separation is supported, four contexts, evenly divided into two sets of contexts, are used for SAVAS on the last two structural elements to signal the pred_type syntax element for asymmetric separations (ie, PART_2N × nU, PART_2N × nD, PART nL × 2N, PART_nR × 2N). Depending on whether the separation is performed in the horizontal direction or the vertical direction, one set of contexts is applied. The penultimate structural element (i.e., a structural element of a split type; part_mode) determines whether the current CU has symmetrical splits or asymmetric splits. The last structural element (i.e., the structural element of the partition size; part_mode) determines whether the size of the first partition is one quarter or three quarters of the size of the CU. Table 6 shows an example of the penultimate (split type) and last (split size) contexts for the pred_type syntax element.

Table 6
Contexts for the last two structural elements of the pred_type syntax element Structural element Context Separation type (symmetric or asymmetric) Set of 1 contexts (2 contexts, one for vertical separation, 1 for horizontal separation) Partition size (first partition is ¼ CU or ¾ CU) A set of 2 contexts (2 contexts, one for ¼ CU and one for ¾ CU)

[0089] The present disclosure proposes to use one context for the penultimate structural element (ie, a structural element of a split type) and use the crawl mode on the last structural element (ie, a structural element of a split size). As a result, the number of contexts decreases from 4 to 1. Table 7 shows an example of the context used according to this example of the present disclosure. Table 8 shows the coding performance associated with the proposed changes. High performance (NOT) random access is a test condition with random access frames. NOT low latency B is a test condition that allows bi-directional prediction.

Table 7
Contexts for the last two structural elements of the pred_type syntax element according to an example
of the present disclosure. Structural element Context Separation type (symmetric or asymmetric) Set of 1 contexts (1 context) Partition size (first partition is ¼ CU or ¾ CU) Crawl mode (no context)

[0090] Thus, according to this example, video encoder 20 may be configured to determine a split type for a prediction mode for a video block, encode a structural element of a split type of a prediction type syntax element for a video block using one context context adaptive binary arithmetic coding moreover, one context is the same for any type of separation, and encode the structural element of the size division of the syntax of the prediction type for the block deodannyh using context-adaptive binary arithmetic coding in bypass mode.

[0091] Furthermore, according to this example, video decoder 30 may be configured to receive a prediction type syntax element for a video block that has been encoded using context adaptive binary arithmetic coding (SAVAS), wherein the prediction type syntax element includes a structural a separation type element representing a separation type, and a separation size structural element representing a separation size, decode a syntax separation type structural element a x-prediction type element using context adaptive binary arithmetic coding with one context, with one context being the same for any type of separation, and decode a prediction type syntax separation size element for a block of video data using context-adaptive binary arithmetic coding in crawl mode.

[0092] In another example, when encoding a rectangular split type, a traversal mode or single context can be used for a structural element that indicates whether the partition mode is PART_nL × 2N or PART_nR × 2N, or whether the mode is PART_2N × nU, PART_2N × nD. Using a crawl mode or a single context is applicable because the probability of any split mode being used is close to 50%. Also optionally, a traversal mode or a single context can be used for a structural element that indicates whether the mode is symmetric separation or asymmetric separation.

[0093] The following example of the present disclosure relates to inter-prediction merge signaling. In merge mode, the encoder instructs the decoder, through the signaling of the bitstream of the prediction syntax, to copy the motion vector, the reference index (identifying the reference image, in this list of reference images indicated by the motion vector) and the direction of motion prediction (which identifies the list of reference images (List 0 or List 1), i.e., from the point of view of whether the reference frame precedes or follows the current frame) from the selected candidate motion vector for the current part of the image to be encoded. This is accomplished by signaling the index bitstream to a list of candidate motion vectors identifying the selected candidate motion vector (i.e., a particular candidate spatial motion vector predictor (MVP) or candidate temporary MVP).

[0094] Thus, in the merge mode, the prediction syntax may include a flag identifying the mode (in this case, the merge mode) and an index (merge_idx) identifying the selected candidate motion vector. In some cases, the candidate motion vector will be in the causal part relative to the current part. That is, the candidate motion vector will already be decoded by the decoder. Thus, the decoder has already received and / or determined a motion vector, a reference index, and a direction of motion of the prediction for the causal part. Thus, the decoder can simply extract the motion vector, the reference index, and the motion prediction direction associated with the causal part from the memory and copy these values as motion information for the current part. To restore the block in the merge mode, the decoder receives the prediction block using the obtained motion information for the current part, and adds residual data to the prediction block to restore the encoded block.

[0095] In HM4.0, one of the five merge candidates is signaled when the current PU is in merge mode. Truncated unary code is used to represent the syntax element merge_idx. In one sentence for HEVC, for SAVAS, each structural element uses one context. The present disclosure suggests reusing one context in all four structural elements, as shown in table 9.

Table 9
Contexts for the last two structural elements of the pred type syntax element. Structural element Context Structural element 0-3 for merge_idx Set 1 context (the same context for all structural elements)

[0096] Table 10 shows the coding performance associated with this example.

[0097] Optionally, more than one context can be used in coding the merge index, with some structural elements sharing the same context, and some structural elements using different contexts. As one example, only consecutive structural elements (bin) share the same context. For example, bin2 and bin3 can share the same context; bin2 and bin4 cannot share the same context unless bin3 also uses this context.

[0098] As another example, suppose that the total number of structural elements of the merge index is N (the first structural element is bin0, the last structural element is bin N-1). Υ thresholds, thres _i , i = 1, ..., y, are used to determine the context shared in the coding of the merge index. In this example, the following rules indicate how contexts are shared between structural elements:

1. 0 <Y <N (there are fewer thresholds than structural elements)

2.thresi <thres _{i + 1}

3.0 <thres ₁

4. thres _Y N

5. bin _j will share one context, where x = {thres _Y , ..., thres _{i + 1} -1}

[0099] Based on these rules, the previous method, in which one context is repeatedly used in all four structural elements, can be considered as one case, where N = 4, Y = 1, thres ₁ = 4. Therefore, structural elements from 0 to 3 share the same context.

[0100] Another example includes setting N = 4, Y = 2, thres ₁ = 2, thres ₂ = 4. In this example, bin0 and bin1 share the same contexts, and bin2 and bin3 share the same contexts.

[0101] The inter prediction flag (inter_pred_flag) determines whether mono prediction or bi prediction is used for the current PU. In some examples, the context index for the inter prediction flag is equal to the current CU depth. Since there are four possible CU depths (0-3), there are four possible contexts for encoding inter_pred_flag.

[0102] The present disclosure assumes that the context index used to select the context for inter_pred_flag encoding is equal to the current CU depth (for example, the quad tree decomposition level for CU), but is limited by the selected threshold (that is, less than the current CU depth or threshold). The threshold can be selected equal to 2 in one example. Alternatively, the context index may be equal to the maximum CU depth minus the current CU depth and bounded from above by a selected threshold. Alternatively, a predetermined mapping table may be designed to select a context index from a predetermined CU depth. The mapping table may be implemented as a set of logic. As a result, three contexts are used to encode the syntax element between inter_pred_flag.

[0103] Table 11 shows the coding performance when the initialization table changes, but the number of contexts does not change. Table 12 shows the coding performance of the proposed method, which reduces the number of contexts from 4 to 3.

[0104] The reference frame index {ref_idx_1x) is signaled by a truncated unary code with respect to the active reference frame in the associated list (eg, List 0 or List 1). Three contexts are used to encode the reference frame index. One context is for structural element 0, one context is for structural element 1, and one context is used for the rest of the structural elements. Table 13 shows an example of context assignments for structural elements of a unary code for ref_idx_1x.

Table 13
Context assignment for structural elements ref idx lx Structural elements of the unary code ref_idx_1x Context Structural element 0 Context 1 Structural element 1 Context 2 Structural elements 2-N (N is the total number of structural elements) Context 3

[0105] The present disclosure proposes the use of two contexts for encoding a unary code for ref_idx_1x; one context for structural element 0 and another context for other structural elements. Table 14 shows an example of context assignment for structural elements of a unary code for ref_idx_1x according to this example of the present disclosure. Table 15 shows the coding performance associated with the proposed modifications.

Table 14 Context assignment for structural elements ref_idx_1x Structural elements of the unary code ref_idx_1x Context Structural element 0 Context 1 Structural elements 1-N (N is the total number of structural elements) Context 2

[0106] For the syntax flag elements of the encoded chroma block (cbf_cb and cbf_cr), two different sets of contexts (5 contexts in each set of contexts) are used for SAVAS. The index of the actual context used in each set is equal to the current conversion depth associated with the flag of the encoded chroma block that is being encoded. Table 16 shows the context sets for the flags of the encoded chroma block cbf_cb and cbf_cr.

Table 16
Context sets for cbf_cb and cbf_cr. Color Coded Block Flag Set of contexts cbf_cb Set of contexts 1 (5 contexts) cbf_cr Set of contexts 2 (5 contexts)

[0107] The present disclosure suggests that cbf_cb and cbf_cr share the same set of contexts. The index of the actual context used in each set may still be equal to the current conversion depth associated with the flag of the encoded chroma block that is being encoded. Table 17 shows the context sets for the flags of the encoded chroma block cbf_cb and cbf_cr according to the examples of the present disclosure. Table 18 shows the coding performance associated with the proposed modifications.

Table 17
Context sets for cbf_cb and cbf_cr according to examples of the present disclosure. Color Coded Block Flag Set of contexts cbf_cb Set of contexts 1 (5 contexts) cbf_cr Set of contexts 1 (5 contexts)

[0108] Thus, according to this example, both video encoder 20 and video decoder 30 can be configured to encode the flag of the coded color block Cb for the video block using context adaptive binary arithmetic coding (SAVAS), wherein SAVAS uses a set of contexts, including one or more contexts, and encode the flag of the encoded chroma block Cr using CABAC, wherein CABAC uses the same set of contexts as for the flag of the encoded chroma block Cb. Video encoder 20 and video decoder 30 may be further configured to select a context from one or more contexts based on the conversion depth of the block transform block associated with the video data block.

[0109] In one sentence for HEVC, there are twelve sets of contexts for both coeff_abs_level_greaterl_flag and coeff_abs_level_greater2_flag. coeff_abs_level_greater1_flag indicates whether the conversion coefficient has an absolute value greater than 1. coeff_abs_level_greater2_flag indicates whether the conversion coefficient has an absolute value greater than 2. The sets of contexts are equally assigned to the luminance and color component, i.e. 6 sets of contexts for brightness and 6 contexts for chroma. Each set of contexts consists of 5 contexts. The context set index, ct × Set, is selected based on the previous level coeff_abs_level_greater1_flag. For coeff_abs_level_greater1_flag, the context index in the context set, greater1Ctx, is determined based on end units up to a maximum of 4. The context index can be represented as:

[0110] For coeff_abs_level_greater2_flag, the context index in the context set, greater2Ctx, is based on the number of coeff abs level_greater1_flag, from 1 to a maximum of 4. The context index can be represented as:

greater1Ctx is based on the number of significant coefficients and the number of coefficients that are greater than 1. On the other hand, greater2Ctx is based on the number of coefficients that are greater than 1.

[0111] In some examples, a different number of contexts can be used in different sets of contexts, including, for example:

1. Sets of contexts for a level greater than 1, or a level greater than 2, may have a different number of contexts. For example, context sets 0 and 3 may have 5 contexts, and the remaining context sets could have 2 contexts.

2. The context sets for the luminance factor may have a different number of contexts compared to the context sets for the color component. For example, a set of contexts 0 for luminance may have 5 contexts, and a set of contexts 0 for luminance may have 4 contexts.

3. A set of contexts for a level greater than 1 may have a different number of contexts compared to a set of contexts for a level greater than 2. For example, a set of contexts 0 for a level greater than 1 may have 5 contexts, and a set of contexts 0 for a level greater than 2, could have only 3 contexts.

[0112] In other examples, a different number may be used for sets of contexts for encoding greater than 1 or greater than 2, including, for example:

1. Context sets for the luminance factor may have a different number of context sets with respect to the context sets used for the color component. For example, luminance could use 6 contexts, and chroma could use 4 contexts.

2. Context sets for more than 1 may have a different number of contexts with respect to the used context sets of more than 2. For example, in the case of more than 1, 6 contexts could be used, and in the case of more than 2, 4 contexts could be used.

[0113] Optionally, a metric is used to determine which context is used in the context set, and the range of the metric value is greater than the number of contexts in the context set. In one such aspect, one context could be associated with one or more metric values. Context sharing is preferably limited to continuous values. For example, if the metric value is equal to y, y = 2 is associated with context 3 and y = 1 and y = 4 can also be associated with context 3. However, if y = 3 is associated with context 4, y = 4 cannot be associated with context 3.

[0114] For example, for coeff_abs_level_greater1_flag, context sets 0 and 3 have 5 contexts, and context sets 1, 2, 4, and 5 have 2 contexts. For coeff_abs_level_greater2_flag, context sets 0, 1, and 2 have 5 contexts, and context sets 3, 4, and 5 have 2 contexts. This can be represented as:

if ct × Set = 0 or ct × Set = 3, Thres_greater1 = 4;

otherwise, Thres_greater1 = 1

if ct × Set <3, Thres_greater2 = 4;

otherwise, Thres_greater2 = 1

Thres_greater1 and Thres_greater2 can be selected in various ways depending on the following situations:

1. The component of brightness or color

2. Sets of contexts

[0115] As another example, for

coeff_abs_level_greater1_flag, context sets 0 and 3 have 5 contexts, and context sets 1, 2, 4 and 5 have 3 contexts. For coeff_abs_level_greater2_flag, context sets 0, 1, and 2 have 5 contexts, and context sets 3, 4, and 5 have 2 contexts. This can be represented as:

ct × Idx_level_greater1 = (ct × Set * 5) + greater1Ct × _mapped (3) ct × Id × _level_greater2 = (ct × Set * 5) + greater2Ct × _mapped (4)

[0116] In such examples, the display may be as shown in Tables 19 and 20:

[0117] The CABAC initialization tables for coeff_abs_level_greater1_flag and coeff_abs_level_greater2_flag are also modified for context sets for Thres_greater1 or Thres_greater2 equal to 1. Modifications move the initialization of the fifth context forward to become the initialization of the second context. This proposed method reduces the number of contexts from 120 to 78.

[0118] Table 21 lists the number of contexts for all syntax elements mentioned in the previous sections. The overall decline is 56 contexts.

[01191 In FIG. 2 is a flowchart illustrating an example video encoder 20 that can implement the methods described in the present disclosure. Video encoder 2 0 may perform intra- and inter-coding of video blocks in video segments. Intra-coding relies on spatial prediction to reduce or eliminate spatial redundancy in a video over a specific video frame or image. Intercoding is based on temporal prediction to reduce or eliminate temporal redundancy in video in adjacent frames or images of a video sequence. The intra-mode (mode I) may refer to any of several spatial compression modes. Inter-modes, such as unidirectional prediction (mode P) or bidirectional prediction (mode B), may refer to any of various time compression modes.

[0120] In the example of FIG. 2, video encoder 20 includes a separation module 35, a prediction module 41, a reference image memory 64, an adder 50, a transform module 52, a quantization module 54, and an entropy encoding module 5 6. The prediction module 41 includes a motion estimation module 42, a motion compensation module 4 4, and an intra prediction module 4 6. To restore video blocks, video encoder 20 also includes an inverse quantization module 58, an inverse transform module 60, and an adder 62. A deblocking filter (not shown in FIG. 2) may also be included to filter block boundaries to eliminate blocking artifacts from the restored video. If desired, the deblocking filter typically filters the output of the adder 62. Additional loop filters (in or after the loop) can also be used in addition to the deblocking filter.

[0121] As shown in FIG. 2, video encoder 20 receives video data, and a dividing unit 35 divides the data into video blocks. Such a division may also include division into segments (slices), mosaic elements (tiles) or other large units, as well as the division of the video block, for example, in accordance with the structure of the quad tree LCU and CU. Video encoder 20 typically illustrates components that encode video blocks in a video segment to be encoded. A segment can be divided into several video blocks (and possibly into sets of video blocks called tiles). Prediction module 41 may select one of a plurality of possible coding modes, such as one of a plurality of intra-coding modes or one of a plurality of inter-coding modes for the current video block based on error results (e.g., coding rate and distortion level). Prediction module 41 may provide an intra- or inter-coded block to an adder 50 to generate residual block data and to an adder 62 to recover an encoded block for use as a reference image.

[0122] The intra prediction unit 46 in the prediction unit 41 may perform intra prediction encoding of the current video block with respect to one or more neighboring blocks in the same frame or segment as the current block to be encoded to provide spatial compression. Motion estimation module 42 and motion compensation module 44 in prediction module 41 perform inter-prediction encoding of the current video block with respect to one or more prediction blocks in one or more reference images to provide temporal compression.

[0123] The motion estimation module 42 may be configured to determine an inter-prediction mode for a video segment in accordance with a predetermined pattern for a video sequence. A predefined template can designate video segments in a sequence as Ρ segments, B segments, or GPB (generalized P / V) segments. Motion estimation module 42 and motion compensation module 44 may be highly integrated, but are illustrated separately for conceptual purposes. Motion estimation performed by motion estimation module 42 is a motion vector generation process that estimates motion for video blocks. The motion vector, for example, may indicate the offset of the PU block of the video within the current video frame or image relative to the prediction block in the reference image.

[0124] A prediction block is a block that exactly matches the PU of the video block being encoded in the sense of a pixel difference, which can be determined by the sum of the absolute differences (SAD), the sum of the quadratic differences (SSD), or other difference metrics. In some examples, video encoder 20 may calculate values for sub-integer pixel positions of reference images stored in the reference image memory 64. For example, video encoder 20 may interpolate values into one quarter of pixel positions, one-eighth of pixel positions, or other fractional pixel positions of a reference image. Thus, the motion estimation module 42 can search for motion relative to full pixel positions and fractional pixel positions and output a motion vector with fractional pixel accuracy.

[0125] The motion estimation module 42 calculates a motion vector for the PU of the video block in the inter-coded segment by comparing the position of the PU with the position of the prediction block of the reference image. The reference image may be selected from the first list of reference images (list 0) or the second list of reference images (List 1), each of which identifies one or more reference images stored in the memory 64 of the reference images. Motion estimation module 42 transmits the calculated motion vector to entropy encoding module 56 and motion compensation module 44.

[0126] Motion compensation by the motion compensation module 44 may include extracting or generating a prediction block based on the motion vector determined by the motion estimate, possibly performing interpolation with subpixel accuracy. After receiving the motion vector for the PU of the current video block, the motion compensation module 44 may determine the position of the prediction block indicated by the motion vector in one of the reference picture lists. Video encoder 20 generates a residual video block by subtracting the pixel values of the prediction block from the pixel values of the current encoded video block, forming pixel difference values. Pixel difference values form residual data for the block and may include difference components of both luminance and chrominance. The adder 50 is a component or components that perform this subtraction operation. Motion compensation module 44 may also generate syntax elements associated with video blocks and video segments for use by video decoder 30 when decoding video segment video blocks.

[0127] The intra prediction unit 46 may intra-predict the current block, as an alternative to the inter prediction performed by the motion estimation module 42 and the motion compensation module 44, as described above. In particular, intra prediction unit 46 may determine the intra prediction mode used to encode the current block. In some examples, intra prediction module 46 may encode the current block using various intra prediction modes, for example, during separate coding passes, and intra prediction module 46 (or mode selection module 40, in some examples) may select the corresponding mode intra prediction for use from tested modes. For example, the intra prediction unit 46 may calculate the speed-distortion ratio values by analyzing the speed-distortion ratio for the various intra-prediction modes tested and select an intra-prediction mode having the best speed-distortion ratio characteristics among the tested modes. The rate-distortion analysis usually determines the amount of distortion (or error) between the encoded block and the original, non-encoded block that was encoded to obtain the encoded block, as well as the bit rate (i.e. the number of bits) used to generate the encoded block. Intra prediction unit 46 may calculate distortion-velocity ratios for various coded blocks to determine which intra-prediction mode exhibits the best rate-distortion ratio for the block.

[0128] In any case, after selecting the intra prediction mode for the block, the intra prediction module 46 may provide information indicative of the selected intra prediction mode to the entropy encoding module 56. Entropy encoding unit 56 may encode information indicating the selected intra prediction mode in accordance with the methods of the present invention. Video encoder 20 may include configuration data in the transmitted bitstream, which may include a plurality of intra prediction mode index tables and a plurality of intra prediction mode index tables (also called codeword mapping tables), determining encoding contexts for the various blocks, and indicating the most probable intra-prediction mode, intra-prediction mode index tables and modified intra-prediction index tables, to use for each of contexts.

[0129] After the prediction module 41 generates a prediction block for the current video block by inter prediction or intra prediction, video encoder 20 generates a residual video block by subtracting the prediction block from the current video block. The residual video data in the residual block may be included in one or more TUs and supplied to the conversion unit 52. The transform unit 52 converts the residual video data to the residual transform coefficients using a transform such as a discrete cosine transform (DCT) or a conceptually similar transform. The transform unit 52 may convert the residual video data from the pixel region to the transform region, for example, the frequency domain.

[0130] The transform unit 52 may send the resulting transform coefficients to the quantization unit 54. Quantization module 54 quantizes transform coefficients to further reduce bit rate. The quantization process can reduce the bit depth associated with some or all of the coefficients. The degree of quantization can be modified by adjusting the quantization parameter. In some examples, quantization module 54 may then scan a matrix including quantized transform coefficients. Alternatively, entropy coding unit 56 may perform a scan. As one example, the encoding methods described in the present disclosure may be performed in whole or in part by entropy encoding module 56. However, aspects of the present description are not limited to this. For example, the encoding methods described in the present disclosure may be performed by a component of video encoder 20, not shown in FIG. 2, such as a processor or any other component. In some examples, the encoding methods of the present disclosure may be performed by one of the other blocks or modules shown in FIG. 2. In some other examples, the encoding methods of the present disclosure may be performed using a combination of blocks and modules of the video encoder 20. Thus, the video encoder 20 may be configured to perform the exemplary methods described in the present disclosure.

[0131] After quantization, entropy encoding unit 56 encodes the quantized transform coefficients. For example, entropy encoding module 56 may perform variable length context adaptive encoding (CAVLC), context adaptive binary arithmetic encoding (SAVAS) based on context adaptive binary arithmetic encoding (SBAC) syntax, probability interval division entropy encoding (PIPE) or other entropy coding technology or method. After entropy encoding by entropy encoding module 56, the encoded bitstream may be transmitted to video decoder 30 or archived for subsequent transmission or retrieval by video decoder 30. Entropy encoding unit 56 may also entropy encode motion vectors and other syntax elements for the current encoded video segment.

[0132] In one example of the present disclosure, entropy coding unit 56 may be configured to determine a first prediction type for a video block in a Ρ segment, represent the first prediction type as a syntax element of a Ρ segment prediction type, determine a second prediction type for a video block in B segment, represent the second type of prediction as a syntactic element of the type of prediction In the segment, define the binarization of Ρ segment for the syntax element of the type of prediction Ρ segment, define divide the binarization of the B segment for the syntax element of the prediction type B segment, the syntax element of the prediction type Ρ segment and the syntax element of the prediction type B of the segment are determined using the same binarization logic, and encode the video data based on the binarization of the syntax element of the prediction type Ρ segment and the syntax element type prediction in the segment.

[0133] In another example of the present disclosure, entropy coding unit 56 may be configured to determine a split type for a prediction mode for a video block, encode a structural element of a split type of a prediction type syntax element for a video block using a context adaptive binary

arithmetic coding with one context, and one context is the same for any type of separation, and encode a structural element of the type of separation of the syntax of the prediction type for a block of video data using context adaptive binary arithmetic coding in crawl mode.

[0134] In another example of the present disclosure, entropy coding unit 56 may be configured to encode the flag of the coded color block Cb for a video block using context adaptive binary arithmetic coding (CABAC), wherein CABAC uses a set of contexts including one or more contexts, and encode the flag of the encoded chroma block Cr using CABAC, wherein CAABC uses the same set of contexts as for the flag of the encoded chroma block Cb. Video encoder 20 and video decoder 30 may be further configured to select a context from one or more contexts based on the conversion depth of the transform module associated with the video block.

[0135] The inverse quantization unit 58 and the inverse transform unit 60 apply inverse quantization and inverse transform, respectively, to reconstruct the residual block in the pixel region for later use as the reference block of the reference image. Motion compensation module 44 may calculate the reference block by summing the residual block with the prediction block of one of the reference pictures in one of the reference picture lists. Motion compensation module 44 may also apply one or more interpolation filters to the reconstructed residual block to calculate sub-integer pixel values for use in motion estimation. An adder 62 summarizes the reconstructed residual block with a motion-compensated prediction block generated by the motion compensation unit 44 to obtain a reference block for storing 64 reference images in the memory. The reference block may be used by the motion estimation module 42 and the motion compensation module 44 as a reference block for inter prediction of the block in a subsequent video frame or image.

[0136] In FIG. 3 is a flowchart illustrating an example video decoder 30 that may implement the methods described in the present disclosure. In the example of FIG. 3, video decoder 30 includes an entropy decoding unit 80, a prediction unit 81, an inverse quantization unit 86, an inverse transform unit 88, an adder 90, and a reference image memory 92. Prediction module 81 includes motion compensation module 82 and intra-prediction module 84. Video decoder 30 may, in some examples, perform a decoding pass, generally the reverse of the coding pass described with reference to video encoder 20 of FIG. 2.

[0137] During the decoding process, video decoder 30 receives the encoded video bitstream, which represents the encoded video segment video blocks and associated syntax elements, from video encoder 20. Entropy decoding module 80 of video decoder 30 entropy decodes the bitstream to generate quantized coefficients, motion vectors, as well as other syntax elements. Entropy decoding unit 80 directs motion vectors and other syntax elements to prediction unit 81. Video decoder 30 may receive syntax elements at the video segment level and / or at the video block level.

[0138] As one example, the encoding methods described in the present disclosure may be performed in whole or in part by entropy decoding module 80. However, aspects of the present disclosure are not limited to this. For example, the encoding methods described in the present disclosure may be performed by video decoder component 30, not shown in FIG. 3, such as a processor or any other component. In some examples, the encoding methods of the present disclosure may be performed by one of the other blocks or modules shown in FIG. 3. In still some other examples, the encoding methods of the present disclosure may be performed using a combination of blocks and modules of the video decoder 30. Thus, the video decoder 30 may be configured to perform the example methods described in the present disclosure.

[0139] In one example of the present disclosure, entropy decoding module 80 may be configured to map a binarized Ρ segment prediction type syntax element to a prediction type using a binarization map for a video block in a Ρ segment, map a B segmented prediction type syntax element to a prediction type using the same binarization mapping for the video block in the B segment, and decode the video data based on the displayed prediction types Niya.

[0140] In one example of the present disclosure, entropy decoding module 80 may be configured to receive a prediction type syntax element for a video block that has been encoded using context adaptive binary arithmetic coding (SAVAS), wherein the prediction type syntax element includes a structural a separation type element representing a separation type, and a separation size structural element representing a separation size, decode the structural element nt type of splitting a syntax element of a prediction type using context adaptive binary arithmetic coding with one context, where one context is the same for any type of separation, and decode the structural element of the size of the separation of the syntax element of the prediction type for a video block using context adaptive binary arithmetic coding in bypass mode.

[0141] In another example of the present disclosure, entropy decoding module 80 may be configured to encode the flag of the coded color block Cb for a video data block using context adaptive binary arithmetic coding (CABAC), wherein CABAC uses a set of contexts including one or more contexts, and encode the flag of the encoded chroma block Cr using CABAC, wherein CABAC uses the same set of contexts as for the flag of the encoded chroma block Cb. Video encoder 20 and video decoder 30 may be further configured to select a context from one or more contexts based on the conversion depth of the transform module associated with the video block.

[0142] When a video segment is encoded as an intra-coded (I) segment, the intra-prediction unit 84 of the prediction unit 81 may generate prediction data for a video block of the current video segment based on the signalmed intra-prediction mode and data from previously decoded blocks of the current frame or Images. When a video frame is encoded as an inter-coded (i.e., B, Ρ, or GPB) segment, motion compensation module 82 of prediction module 81 generates prediction blocks for a video block of the current video segment based on motion vectors and other syntax elements obtained from entropy module 80 decoding. Prediction blocks can be formed from one of the reference images in one of the lists of reference images. Video decoder 30 may construct reference frame lists, list 0 and list 1 using default construction methods based on reference images stored in the reference image memory 92.

[0143] Motion compensation module 82 determines the prediction information for the video block of the current video segment by analyzing motion vectors and other syntax elements and uses the prediction information to obtain prediction blocks for the current decoded video block. For example, motion compensation module 82 uses some of the syntax elements obtained to determine a prediction mode (eg, intra or inter prediction) used to encode blocks of a video video segment, such as an inter prediction segment (eg, B segment, Ρ segment, or GPB segment), structural information for one or more reference picture lists for a segment, motion vectors for each inter-coded block of a video segment, inter-prediction status for each inter-coded Video block segment, and other information to decode the video blocks in the current video segment.

[0144] Motion compensation module 82 may also perform interpolation based on interpolation filters. Motion compensation module 82 may use interpolation filters, as used by video encoder 20 during encoding video blocks, to calculate interpolated values for sub-integer pixels of reference blocks. In this case, motion compensation module 82 may determine the interpolation filters used by video encoder 20 from the received syntax elements and use interpolation filters to obtain prediction blocks.

[0145] The inverse quantization unit 86 inversely quantizes, that is, de-quantizes, the quantized transform coefficients provided in the bitstream and decoded by the entropy decoding unit 80. The inverse quantization process may include using the quantization parameter calculated by video encoder 20 for each video block in the video segment to determine the degree of quantization and, likewise, the degree of inverse quantization that should be applied. The inverse transform unit 88 applies an inverse transform, such as an inverse DCT, an inverse integer transform, or a conceptually similar inverse transform process to transform coefficients to obtain residual blocks in the pixel domain.

[0146] After the motion compensation module 82 generates a prediction block for the current video block based on motion vectors and other syntax elements, the video decoder 30 generates a decoded video block by summing the residual blocks from the inverse transform module 88 with the corresponding prediction blocks generated by the module 82 motion compensation. The adder 90 is a component or components that perform this summation operation. If desired, the deblocking filter can also be used to filter decoded blocks to remove blocking artifacts. Other loop filters (in the coding loop or after the coding loop) can also be used to smooth pixel transitions or otherwise improve the quality of the video. The decoded video blocks in a given frame or image are then stored in a reference image memory 92, in which reference frames are used for subsequent motion compensation. Reference image memory 92 also stores decoded videos for later presentation on a display device, such as display device 32 in FIG. one.

[0147] FIG. 6 is a flowchart illustrating an example of a video encoding method according to the present disclosure. The method of FIG. 6 may be implemented by video encoder 20. Video encoder 20 may be configured to determine a first type of prediction for a video block in a Ρ segment (602) and represent the first type of prediction as a syntax element of a типа segment prediction type (604). Video encoder 20 may be further configured to determine a second prediction type for the video block in the B segment (606) and present the second prediction type as a syntax element of the prediction type B segment (608). Prediction type syntax element Ρ of a segment and a prediction type syntax element In a segment, a prediction mode and a division type are determined. The prediction mode may include one of inter prediction and intra prediction. The type of separation may include one of symmetrical divisions and asymmetric divisions.

[0148] Video encoder 20 may be further configured to determine Ρ segment binarization for a prediction type типа segment syntax element (610) and determine segment B binarization for a prediction type syntax element B segment, wherein the prediction type syntax element Ρ segment and the prediction type syntax element The segments are determined using the same binarization logic (612). Video encoder 20 may then encode video data based on binarizations of a prediction type syntax element Ρ segment and prediction type syntax element B segment (614).

[0149] Video coding may comprise binarization of a prediction type syntax element Ρ a segment with certain binarization Ρ segments, a prediction type syntax element binarization in a segment with certain binarization B segments, applying context adaptive binary arithmetic coding (SAVAS) to the binarized prediction type syntax element Ρ segment and application of context-adaptive binary arithmetic coding (SAVAS) to the binarized syntactic electronic The cop prediction type segment.

[0150] FIG. 7 is a flowchart illustrating an example of a video decoding method according to the present disclosure. The method of FIG. 7 may be implemented using video decoder 30. Video decoder 30 may be configured to receive a context-adaptive binary arithmetic-encoded syntax element of a prediction type Ρ segment, which indicates a prediction type for a video block in the менте segment (702), and received subjected to context-adaptive the binary arithmetic coding of the syntax element of the prediction type In segment, which indicates the type of prediction for the video block in the In segment (704). Prediction type syntax element Ρ of a segment and a prediction type syntax element In a segment, a prediction mode and a division type are determined. The prediction mode may include one of inter prediction and intra prediction. The type of separation may include one of symmetrical divisions and asymmetric divisions.

[0151] Video decoder 30 may be further configured to decode a prediction type syntax element Ρ segment to obtain a binarized prediction type syntax element Ρ segment (706) and decode a segment prediction type syntax element to obtain a binarized prediction type syntax element of a segment (708) . Video decoder 30 may be further configured to map the binarized prediction type syntax element of the Ρ segment to the prediction type using a binarization mapping for the video block in the Ρ segment (710), and to map the binarized syntax element of the prediction type B segment to the prediction type using the same the binarization mapping for the video block in the In segment (712). Video decoder 30 may then decode the video data based on the displayed prediction types (714).

[0152] In FIG. 8 is a flowchart illustrating an example of a video encoding method according to the present disclosure. The method of FIG. 8 may be implemented by video encoder 20. Video encoder 20 may be configured to determine a split type for a prediction mode for a block of video data (802) and encode a structural element of a split type of a prediction type syntax element for a video block using context adaptive binary arithmetic coding (SAVAC) with one context (804). One context is the same for any type of separation. In one example, the split type is an asymmetric split, and the split type structural element indicates whether the asymmetric split is vertically split or horizontally split. For example, a partition size structural element indicates whether the first partition is equal to one fourth of the video block size or the first division is three quarters of the video block size.

[0153] Video encoder 20 may be further configured to encode a structural element of a partition size of a prediction type syntax element for a video block using CAVAC in bypass mode (806).

[0154] FIG. 9 is a flowchart illustrating an example of a video decoding method according to the present disclosure. The method of FIG. 9 may be implemented using video decoder 30. Video decoder 30 may be configured to receive a prediction type syntax element for a block of video data that has been encoded using context adaptive binary arithmetic coding (SAVAS), wherein the prediction type syntax element includes a structural element a split type representing a split type; and a split size structural element representing a split size (902). In one example, the split type is an asymmetric split, and the split type structural element indicates whether the asymmetric split is vertically split or horizontally split. For example, a partition size structural element indicates whether the first partition is equal to one fourth of the video block size or the first division is three quarters of the video block size.

[0155] Video decoder 30 may be further configured to decode a structural element of a split type of a prediction type syntax element using CABAC with one context, wherein one context is the same for any split type (904), and decode the structural element of a split size of a syntax element type prediction using SAVAS in bypass mode (906).

[0156] FIG. 10 is a flowchart illustrating an example of a video encoding method according to the present disclosure. The method of FIG. 10 may be implemented by video encoder 20 or video decoder. For the purposes of FIG. 10, video encoder 20 and video decoder 30 will be collectively referred to as a video encoding device. In accordance with the methods of FIG. 10, a video encoding device may be configured to encode a flag of a coded chroma block Cb for a video block using context adaptive binary arithmetic coding (CABAC), wherein encoding a flag of a coded chroma block Cb includes using a set of contexts including one or more contexts as part of SAVAC (1002), and also encode the flag of the encoded chroma block Cr using SAVAS, moreover, the encoding of the flag of the encoded chroma block Cr includes flushes the use of the same set of contexts, as for the coded block flag chrominance Cb, as part of CABAC (1004). In one example, a set of contexts includes 5 contexts.

[0157] In one optional example of the present disclosure, a video encoding device may be further configured to select a context from one or more contexts based on the conversion depth of the transform unit associated with the video block (1006).

[0158] When operating as a video encoder, the video encoding device may be further configured to signal the encoded flag of the encoded chroma block Cb in the encoded video bitstream and signal the encoded flag of the encoded chroma block Cr in the encoded video bitstream. When operating as a video decoder, the video encoding device may be further configured to receive the encoded flag of the encoded chroma block Cb in the encoded video bitstream, and also to receive the encoded flag of the encoded chroma block Cr in the encoded video bitstream.

[0159] In one or more examples, the described functions may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functions may be stored or transmitted, as one or more instructions or code, on a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media can include computer-readable media that corresponds to a material medium, such as storage media, or communication media, including any medium that facilitates transferring a computer program from one place to another, for example, in accordance with a communication protocol. Thus, computer-readable media can usually correspond to (1) a material computer-readable storage medium that is not a temporary (non-transitive) or (2) communication medium, such as a signal or carrier wave. Storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code, and / or data structures for implementing the methods described in this disclosure. A computer program product may include computer-readable media.

[0160] By way of example, and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disc, magnetic disk drive or other magnetic storage devices, flash memory, or any another medium that can be used to store the desired program code in the form of instructions or data structures that the computer can access. In addition, any connection is correctly called a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair cable, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio frequency, and microwave are included in the media definition. It should be understood, however, that computer-readable storage media and storage media do not include connections, carrier waves, signals, or other transitive storage media, but instead are directed to non-transitive, tangible media. Disks (disk and disc), as used here, include a compact disk (CD), a laser disk, an optical disk, a digital versatile disk (DVD), a floppy disk and Blu-ray Disc, where magnetic disks (disk) usually play data in a magnetic way, while optical discs (disc) reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer readable media.

[0161] Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, specialized integrated circuits (ASICs), programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Accordingly, the term “processor,” as used herein, may refer to any of the above structures or any other structure suitable for implementing the methods described herein. In addition, in some aspects, the functionality described herein may be provided in specialized hardware and / or software modules configured for encoding and decoding, or included in a combination codec. In addition, these methods can be fully implemented in one or more circuits or logic elements.

[0162] The methods of the present disclosure may be implemented in a wide range of devices or apparatuses, including a cordless telephone, integrated circuit (IC), or a chipset (eg, a chipset). Various components, modules, or blocks are described in this disclosure to emphasize the functional aspects of devices configured to perform the disclosed methods, but do not necessarily require hardware implementation by various modules. Rather, as described above, the various modules may be combined in a codec hardware unit or provided by a plurality of interacting hardware modules, including one or more processors, as described above, in combination with appropriate software and / or firmware.

[0163] Various examples have been described. These and other examples are included in the scope of the attached claims.

Claims (32)

1. A method of encoding video data, comprising:
determining a split type for a prediction mode for a block of video data;
encoding a structural element of a division type of a prediction type syntax element for a video block using context adaptive binary arithmetic coding (SAVAS) with one context, wherein one context is the same for any type of separation; and
encoding a structural element of a partition size of a prediction type syntax element for a block of video data using SAVAS in bypass mode. 2. The method of claim 1, wherein the type of separation is asymmetric separation. 3. The method of claim 2, wherein the structural element of the separation type indicates whether the asymmetric separation is vertically divided or horizontally divided. 4. The method of claim 2, wherein the structural element of the split size indicates whether the first split is one quarter of the size of the video block or whether the first split is three quarters of the size of the video block. 5. A method for decoding video data, comprising:
receiving a prediction type syntax element for a block of video data that has been encoded using context adaptive binary arithmetic coding (SAVAS), the prediction type syntax element including a division type structure element representing a division type and a division size structural element representing a division size ;
decoding a structural element of a division type of a prediction type syntax element using SAVAC with one context, wherein one context is the same for any type of separation; and
decoding a structural element of a partition size of a prediction type syntax element using SAVAS in bypass mode. 6. The method of claim 5, wherein the type of separation is asymmetric separation. 7. The method according to claim 6, in which the structural element of the type of separation indicates whether the asymmetric separation is vertically divided or horizontally divided. 8. The method according to claim 6, in which the structural element of the split size indicates whether the first split is one quarter of the size of the video block or whether the first split is three quarters of the size of the video block. 9. A device configured to encode video data, comprising:
A video encoder configured to:
determine the type of separation for the prediction mode for the block of video data;
encode a structural element of a division type of a prediction type syntax element for a block of video data using context adaptive binary arithmetic coding (SAVAS) with one context, wherein one context is the same for any type of separation; and
encode a structural element of a partition size of a prediction type syntax element for a block of video data using SAVAS in bypass mode. 10. The device according to claim 9, in which the type of separation is asymmetric separation. 11. The device according to claim 10, in which the structural element of the type of separation indicates whether the asymmetric separation is vertically divided or horizontally divided. 12. The device according to claim 10, in which the structural element of the size of the separation indicates whether the first division is one quarter of the size of the block of video data or whether the first division is three quarters of the size of the block of video data. 13. A device configured to decode video data, comprising:
A video decoder configured to:
receive a prediction type syntax element for a block of video data that has been encoded using context adaptive binary arithmetic coding (SAVAS), the prediction type syntax element including a separation type structural element representing a separation type and a separation size structural element representing a separation size ;
decode a structural element of a division type of a prediction type syntax element using SAVAC with one context, wherein one context is the same for any type of separation; and
decode a prediction type syntax element partition size structural element using SAVAS in bypass mode. 14. The device according to p. 13, in which the type of separation is asymmetric separation. 15. The device according to claim 14, in which the structural element of the type of separation indicates whether the asymmetric separation is vertically divided or horizontally divided. 16. The apparatus of claim 14, wherein the structural element of the split size indicates whether the first split is one quarter of the size of the video block or whether the first split is three quarters of the size of the video block. 17. A device configured to encode video data, comprising:
means for determining a split type for a prediction mode for a block of video data;
means for encoding a structural element of a division type of a prediction type syntax element for a block of video data using context adaptive binary arithmetic coding (CABAC) with one context, wherein one context is the same for any type of separation; and
means for encoding a structural element of a partition size of a prediction type syntax element for a block of video data using SAVAS in bypass mode. 18. The device according to p. 17, in which the type of separation is asymmetric separation. 19. The device according to claim 18, in which the structural element of the type of separation indicates whether the asymmetric separation is vertically divided or horizontally divided. 20. The device according to claim 18, in which the structural element of the split size indicates whether the first split is one quarter of the size of the video block or whether the first split is three quarters of the size of the video block. 21. A device configured to decode video data, comprising:
means for receiving a prediction type syntax element for a block of video data that has been encoded using context adaptive binary arithmetic coding (SAVAS), the prediction type syntax element including a division type structure element representing a division type and a division size structural element representing split size;
means for decoding a structural element of a division type of a prediction type syntax element using SAVAC with one context, wherein one context is the same for any type of separation; and
means for decoding a structural element of a partition size of a prediction type syntax element using SAVAS in bypass mode. 22. The device according to p. 21, in which the type of separation is asymmetric separation. 23. The device according to p. 22, in which the structural element of the type of separation indicates whether the asymmetric separation is vertically divided or horizontally divided. 24. The device according to p. 22, in which the structural element of the split size indicates whether the first split is one quarter of the size of the block of video data or whether the first split is three quarters of the size of the block of video data. 25. A computer-readable storage medium that stores instructions that, when executed, prompt one or more processors configured to encode video data:
determine the type of separation for the prediction mode for the block of video data;
encode a structural element of a division type of a prediction type syntax element for a block of video data using context adaptive binary arithmetic coding (SAVAS) with one context, wherein one context is the same for any type of separation; and
encode a structural element of a partition size of a prediction type syntax element for a block of video data using SAVAS in bypass mode. 26. A computer-readable storage medium according to claim 25, wherein the type of partition is an asymmetric partition. 27. A computer-readable storage medium according to claim 26, wherein the structural element of the separation type indicates whether the asymmetric separation is vertically divided or horizontally divided. 28. The computer-readable storage medium according to claim 26, wherein the partition size structural element indicates whether the first partition is one quarter of the size of the video data block or whether the first partition is three quarters of the size of the video data block. 29. A computer-readable storage medium that stores instructions that, when executed, prompt one or more processors configured to decode video data:
receive a prediction type syntax element for a block of video data that has been encoded using context adaptive binary arithmetic coding (SAVAS), the prediction type syntax element including a separation type structural element representing a separation type and a separation size structural element representing a separation size ;
decode a structural element of a division type of a prediction type syntax element using SAVAC with one context, wherein one context is the same for any type of separation; and
decode a prediction type syntax element partition size structural element using SAVAS in bypass mode. 30. A computer-readable storage medium according to claim 29, wherein the type of partition is an asymmetric partition. 31. A computer-readable storage medium according to claim 30, wherein the partition type structural element indicates whether the asymmetric partition is vertically divided or horizontally divided. 32. A computer-readable storage medium according to claim 30, wherein the partition size structural element indicates whether the first partition is one quarter of the size of the video data block or whether the first partition is three quarters of the size of the video data block.

Images