System and method for performing planar intra prediction video coding

Abstract

The present disclosure relates to a system and method for performing planar intra prediction video coding. A video coding device can be configured to perform video coding according to one or more techniques described herein.

Description

[0001] Divisional

[0002] This application is a divisional of the application with the application number 201780085182.9, the title of which is "Systems and Methods for Performing Planar Intra Prediction Video Coding", and the filing date of which is December 21, 2017. TECHNICAL FIELD

[0003] The present disclosure relates to video coding, and more specifically, to techniques for tiling pictures of video data. BACKGROUND

[0004] Digital video capabilities can be incorporated into a wide range of devices, including digital televisions, laptop or desktop computers, tablet computers, digital recording devices, digital media players, video gaming devices, cellular telephones, including so-called smartphones, medical imaging devices, and the like. Digital video can be coded according to a video coding standard. Video coding standards can incorporate video compression techniques. Examples of video coding standards include ISO / IEC MPEG-4 Visual and ITU-T H.264 / AVC (also known as ISO / IEC MPEG-4 AVC) and High-Efficiency Video Coding (HEVC). HEVC is described in High Efficiency Video Coding (HEVC), Rec. ITU-T H.265, April 2015, which is incorporated herein by reference, and is referred to herein as ITU-T H.265. Extensions and improvements to HEVC are currently under consideration for the development of the next generation of video coding standard. For example, the ITU-T Video Coding Experts Group (VCEG) and ISO / IEC (Moving Picture Experts Group (MPEG) (collectively referred to as the Joint Video Exploration Team (JVET)) are studying the potential requirements for future video coding technology standardization, which can have significantly greater compression capability than the current HEVC standard. Joint Exploration Test Model 3 (JEM 3), Algorithm Description of Joint Exploration Test Model 3 (JEM 3), ISO / IEC JTC1 / SC29 / WG11 Document: JVET-C1001-v3, May 2016, Geneva, CH (which is incorporated herein by reference) describes coding features under test model exploration by the JVET as a potential enhancement video coding technology that goes beyond the capabilities of ITU-T H.265. It should be noted that the coding features of JEM 3 are implemented in the JEM reference software maintained by Fraunhofer Research Organization. Currently, an updated version of the JEM reference software, version 3 (JEM 3.0) can be used. As used herein, the term JEM is used to collectively refer to the algorithms included in JEM 3 and the implementation of the JEM reference software.

[0005] Video compression techniques enable the data requirements for storing and transmitting video data to be reduced. Video compression techniques can reduce data requirements by exploiting redundancies in video sequences. Video compression techniques can subdivide a video sequence into successive smaller portions (i.e., groups of frames within a video sequence, frames within a group of frames, slices within a frame, coding tree units (e.g., macroblocks) within a slice, coding blocks within a coding tree unit, etc.). Intra-frame prediction encoding techniques (e.g., intra-picture (spatial)) and inter-frame prediction techniques (i.e., inter-picture (temporal)) can be used to generate difference values between a video data unit to be encoded and a reference unit of video data. The difference values can be referred to as residual data. The residual data can be encoded as quantized transform coefficients. Syntax elements can relate to the residual data and the reference coding unit (e.g., intra-prediction mode indices, motion vectors, and block vectors). The residual data and the syntax elements can be entropy encoded. The entropy encoded residual data and syntax elements can be included in a compliant bitstream. SUMMARY

[0006] In general, this disclosure describes various techniques for encoding video data. In particular, this disclosure describes techniques for partitioning pictures of video data. It should be noted that although the techniques of this disclosure are described with respect to ITU-T H.264, ITU-T H.265, and JEM, the techniques of this disclosure are generally applicable to video encoding. For example, the encoding techniques described herein can be incorporated into video encoding systems that include block structures, intra-prediction techniques, inter-prediction techniques, transform techniques, filtering techniques, and / or entropy encoding techniques other than those included in ITU-T H.265 and JEM, including video encoding systems based on future video coding standards. Accordingly, references to ITU-T H.264, ITU-T H.265, and / or JEM are for descriptive purposes and should not be construed as limiting the scope of the techniques described herein. Furthermore, it should be noted that documents incorporated by reference herein are for descriptive purposes and should not be construed as limiting or creating ambiguity with respect to the terms used herein. For example, where an incorporated reference provides a definition of a term that is different than another incorporated reference and / or the term as used herein, the term should be interpreted in a manner that broadly includes each respective definition and / or each specific definition in the alternative.

[0007] In one example, a method of generating a prediction for a region of video data includes receiving a rectangular video block including sample values, and for each sample included in the video block, generating a predictive sample value by averaging a horizontal interpolation and a vertical interpolation corresponding to a position of the sample within the video block.

[0008] In one example, a device for producing a prediction for a region of video data includes one or more processors configured to: receive a rectangular video block comprising sample values; and for each sample included in the video block, produce a predictive sample value by averaging a horizontal interpolation and a vertical interpolation corresponding to a position of the sample within the video block.

[0009] In one example, a non-transitory computer-readable storage medium comprising instructions stored thereon that, when executed, cause one or more processors of a device to: receive a rectangular video block comprising sample values; and for each sample included in the video block, produce a predictive sample value by averaging a horizontal interpolation and a vertical interpolation corresponding to a position of the sample within the video block.

[0010] In one example, an apparatus comprising: means for receiving a rectangular video block comprising sample values; and means for producing, for each sample included in the video block, a predictive sample value by averaging a horizontal interpolation and a vertical interpolation corresponding to a position of the sample within the video block.

[0011] The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF DRAWINGS

[0012] Figure 1 FIG. 1 is a conceptual diagram illustrating an example of a set of pictures encoded according to quad tree binary tree (QTBT) partitioning, in accordance with one or more techniques of this disclosure.

[0013] Figure 2 FIG. 2 is a conceptual diagram illustrating an example of a quad tree binary tree, in accordance with one or more techniques of this disclosure.

[0014] Figure 3 FIG. 3 is a conceptual diagram illustrating video component quad tree binary tree partitioning, in accordance with one or more techniques of this disclosure.

[0015] Figure 4 FIG. 4 is a conceptual diagram illustrating an example of a video component sampling format, in accordance with one or more techniques of this disclosure.

[0016] Figure 5 FIG. 5 is a conceptual diagram illustrating possible coding structures for a block of video data, in accordance with one or more techniques of this disclosure.

[0017] Figure 6A FIG. 6 is a conceptual diagram illustrating an example of encoding a block of video data, in accordance with one or more techniques of this disclosure.

[0018] Figure 6B is a conceptual diagram illustrating an example of encoding a block of video data according to one or more techniques of this disclosure.

[0019] Figure 7 is a block diagram illustrating an example of a system that can be configured to encode and decode video data according to one or more techniques of this disclosure.

[0020] Figure 8 is a block diagram illustrating an example of a video encoder that can be configured to encode video data according to one or more techniques of this disclosure.

[0021] Figure 9 is a conceptual diagram illustrating video component quad-tree binary-tree partitioning according to one or more techniques of this disclosure.

[0022] Figure 10 is a conceptual diagram illustrating video component quad-tree binary-tree partitioning according to one or more techniques of this disclosure.

[0023] Figure 11 is a conceptual diagram illustrating an example of quad-tree binary-tree according to one or more techniques of this disclosure.

[0024] Figure 12 is a conceptual diagram illustrating quad-tree binary-tree partitioning according to one or more techniques of this disclosure.

[0025] Figure 13 is a conceptual diagram illustrating quad-tree binary-tree partitioning according to one or more techniques of this disclosure.

[0026] Figure 14 is a block diagram illustrating an example of a video decoder that can be configured to decode video data according to one or more techniques of this disclosure.

[0027] Figure 15A is a conceptual diagram illustrating an example of performing intra prediction according to one or more techniques of this disclosure.

[0028] Figure 15B is a conceptual diagram illustrating an example of performing intra prediction according to one or more techniques of this disclosure.

[0029] Figure 16A is a conceptual diagram illustrating an example of performing intra prediction according to one or more techniques of this disclosure.

[0030] Figure 16B is a conceptual diagram illustrating an example of performing intra prediction according to one or more techniques of this disclosure. DETAILED DESCRIPTION

[0031] Video content typically includes a video sequence composed of a series of frames (or pictures). A series of frames can also be referred to as a group of pictures (GOP). Each video frame or picture can include a plurality of slices or tiles, where a slice or tile includes a plurality of video blocks. As used herein, the term video block can generally refer to a region of a picture or can more specifically refer to a maximum array of sample values that can be predictively coded, sub-partitions thereof, and / or corresponding structures. Further, the term“current video block” can refer to a region of a picture being coded or decoded. A video block can be defined as an array of sample values that can be predictively coded. It should be noted that in some instances, pixel values can be described as including sample values of individual components of video data, which can also be referred to as color components (e.g., luma (Y) and chroma (Cb and Cr) components or red, green, and blue components). It should be noted that in some instances, the terms pixel value and sample value are used interchangeably. Video blocks and sub-partitions thereof can be ordered within a picture according to a scan pattern (e.g., a raster scan). A video encoder can perform predictive coding on video blocks and sub-partitions thereof. Video blocks and sub-partitions thereof can be referred to as nodes.

[0032] ITU-T H.264 specifies a macroblock including 16x16 luma samples. That is, in ITU-T H.264, pictures are segmented into macroblocks. ITU-T H.265 specifies a similar coding tree unit (CTU) structure. In ITU-T H.265, pictures are segmented into CTUs. In ITU-T H.265, for a picture, a CTU size can be set to include 16x16, 32x32, or 64x64 luma samples. In ITU-T H.265, a CTU is composed of respective coding tree blocks (CTBs) for each component of video data (e.g., luma (Y) and chroma (Cb and Cr)). Further, in ITU-T H.265, a CTU can be partitioned according to a quadtree (QT) partitioning structure, which results in CTBs of the CTU being partitioned into coding blocks (CBs). That is, in ITU-T H.265, a CTU can be partitioned into quadtree leaf nodes. According to ITU-T H.265, one luma CB together with two corresponding chroma CBs and associated syntax elements is referred to as a coding unit (CU). In ITU-T H.265, a minimum allowed size of a CB can be signaled. In ITU-T H.265, the smallest minimum allowed size of a luma CB is 8x8 luma samples. In ITU-T H.265, the decision to code a picture region using intra prediction or inter prediction is made at the CU level.

[0033] In ITU-T H.265, a CU is associated with a prediction unit (PU) structure having its root at the CU. In ITU-T H.265, the PU structure allows splitting of luma and chroma CBs in order to produce corresponding reference samples. That is, in ITU-T H.265, luma and chroma CBs can be split into respective luma and chroma prediction blocks (PBs), where a PB includes a block of sample values that apply the same prediction. In ITU-T H.265, a CB can be split into 1, 2, or 4 PBs. ITU-T H.265 supports PB sizes from 64x64 samples down to 4x4 samples. In ITU-T H.265, square PBs are supported for intra prediction, where a CB can form a PB or a CB can be split into four square PBs (i.e., intra prediction PB size types include MxM or M / 2xM / 2, where M is the height and width of a square CB. In ITU-T H.265, in addition to square PBs, rectangular PBs are supported for inter prediction, where a CB can be halved vertically or horizontally to form PBs (i.e., inter prediction PB types include MxM, M / 2xM / 2, M / 2xM, or MxM / 2). Further, it should be noted that in ITU-T H.265, for inter prediction, four asymmetric PB splits are supported, where a CB is split into two PBs at one quarter of the height (at the top or bottom) or one quarter of the width (at the left or right) of the CB (i.e., asymmetric splits include M / 4xM left, M / 4xM right, MxM / 4 top, and MxM / 4 bottom). Intra prediction data (e.g., intra prediction mode syntax elements) or inter prediction data (e.g., motion data syntax elements) corresponding to a PB are used to produce reference and / or predicted sample values for the PB.

[0034] JEM specifies a maximum size of a CTU to be 256x256 luma samples. JEM specifies a quadtree plus binary tree (QTBT) block structure. In JEM, the QTBT structure enables quadtree leaf nodes to be further split by a binary tree (BT) structure. That is, in JEM, the binary tree structure enables quadtree leaf nodes to be recursively divided vertically or horizontally. Figure 1 An example is shown in which a CTU (e.g., a CTU having a size of 256x256 luma samples) is split into quadtree leaf nodes and the quadtree leaf nodes are further split according to a binary tree. That is, in Figure 1 the dashed lines represent additional binary tree splits in the quadtree. Thus, the binary tree structure in JEM enables square and rectangular leaf nodes, where each leaf node includes CBs. As shown in Figure 1 The pictures included in a GOP can include slices, where each slice includes a sequence of CTUs, and each CTU can be split according to a QTBT structure. Figure 1An example of a QTBT to include one CTU in a slice is shown. Figure 2 An example QTBT corresponding to the example QTBT tolices shown. Figure 1 A conceptual diagram of an example of a QTBT corresponding to the example QTBT tolices shown.

[0035] In JEM, QTBT is signaled by signaling a QT split flag and a BT split mode syntax element. When the QT split flag has a value of 1, QT splitting is indicated. When the QT split flag has a value of 0, the BT split mode syntax element is signaled. When the BT split mode syntax element has a value of 0, no binary split is indicated. When the BT split mode syntax element has a value of 1, a split mode is indicated. When the BT split mode syntax element has a value of 2, a horizontal split mode is indicated. Further, BT splitting can be performed until a maximum BT depth is reached. Thus, according to JEM, a QTBT as shown in Table 1 can be signaled based on a pseudo syntax provided in Table 1. Figure 2

[0036]

[0037]

[0038] Table 1

[0039] In one example, when a maximum QT depth is reached, signaling of a QT flag can be skipped and its value can be inferred, e.g., to be 0. In one example, when a current depth is less than a minimum QT depth, signaling of a QT flag can be skipped and its value can be inferred, e.g., to be 1. In one example, when a maximum depth for signaling of a block type is reached, an associated syntax element can not be signaled in the bitstream and its value can be inferred. In one example, when a minimum depth for signaling of a block type has not been reached, an associated syntax element can not be signaled in the bitstream and its value can be inferred. In one example, when QT splitting is not allowed and a current depth is less than a minimum BT depth, then signaling of a BT split can be modified to not allow a BT split to equal 0.

[0040] In one example, a tree walk can be followed for signaling of split decisions. For example:

[0041] 1. Signal the split decision for the current node

[0042] 2. For i = 1 to the number of children of the current node (step size 1), perform the following:

[0043] a. Determine the child node n corresponding to i (this can be based on a lookup, i.e., based on the split mode of the current node)

[0044] ​b. recursively call the walk function to walk the subtree rooted at child node n.

[0045] In one example, following tree walk can be used to signal split decisions. For example:

[0046] 1. For i = 1 to the number of child nodes of the current node (step size 1), perform the following:

[0047] a. Determine the child node n corresponding to i (this can be based on lookup, i.e., based on the split pattern of the current node)

[0048] b. Recursively call the walk function to walk the subtree rooted at child node n.

[0049] c. Signal the split decision for the current node

[0050] In one example, following tree walk can be used to signal split decisions. For example:

[0051] 1. For i = 1 to the number of child nodes of the current node (step size 1), perform the following:

[0052] a. Determine the child node n corresponding to i (this can be based on lookup, i.e., based on the split pattern of the current node)

[0053] b. Recursively call the walk function to walk the subtree rooted at child node n.

[0054] 2. Signal the split decision for the current node.

[0055] In one example, the tree can be traversed at increasing depths. In this case, all split decisions for a node at a particular depth can be signaled before proceeding to the next depth.

[0056] As shown in Figure 2 and Table 1, the QT split flag syntax element and the BT split pattern syntax element are associated with a depth, where zero depth corresponds to the root of the QTBT, and higher value depths correspond to subsequent depths beyond the root. Furthermore, in JEM, the luma and chroma components can have separate QTBTs for block. That is, in JEM, the luma and chroma components can be independently block by signaling respective QTBTs. Figure 3 An example of a CTU block by a QTBT for the luma component and an independent QTBT for the chroma component is shown. As shown in Figure 3As shown, when independent QTBT is used for partitioning a CTU, CBs of luma components do not need and are not necessarily aligned with CBs of chroma components. Currently, in JEM, independent QTBT structures are implemented for slices using intra prediction techniques. It should be noted that in some cases, values of chroma variables can need to be derived from related luma variable values. In these cases, sample positions of chroma and chroma formats can be used to determine corresponding sample positions in luma to determine associated luma variable values.

[0057] In addition, it should be noted that JEM includes the following parameters for signaling of QTBT trees:

[0058] CTU size: root node size of quadtree (e.g., 256x256, 128x128, 64x64, 32x32, 16x16 luma samples);

[0059] MinQTSize: minimum allowed quadtree leaf node size (e.g., 16x16, 8x8 luma samples);

[0060] MaxBTSize: maximum allowed binary tree root node size, i.e., maximum size of a leaf quadtree node that can be partitioned by binary splitting (e.g., 64x64 luma samples);

[0061] MaxBTDepth: maximum allowed binary tree depth, i.e., lowest level at which a quadtree leaf node is a root at which binary splitting can occur (e.g., 3);

[0062] MinBTSize: minimum allowed binary tree leaf node size; i.e., minimum width or height of a binary leaf node (e.g., 4 luma samples).

[0063] It should be noted that in some examples, MinQTSize, MaxBTSize, MaxBTDepth, and / or MinBTSize can be different for different components of a video.

[0064] In JEM, CBs are used for prediction without further partitioning. That is, in JEM, CBs can be blocks of sample values for which the same prediction is applied. Thus, JEM QTBT leaf nodes can be similar to PBs in ITU-T H.265.

[0065] A video sampling format, which can also be referred to as a chroma format, can define a number of chroma samples included in a CU relative to a number of luma samples included in the CU. For example, for a 4:2:0 sampling format, the sampling rate of the luma component is twice that of the chroma components in both the horizontal and vertical directions. As a result, for a CU formatted according to the 4:2:0 format, the width and height of the sample array of the luma component is twice that of each sample array of the chroma components. Figure 4 is a conceptual diagram illustrating an example of a coding unit formatted according to a 4:2:0 sample format. Figure 4 The relative positions of the chroma samples relative to the luma samples within the CU are illustrated. As noted above, a CU is typically defined according to the number of horizontal and vertical luma samples. Thus, as illustrated, a 16x16 CU formatted according to the 4:2:0 sample format includes 16x16 samples of the luma component and 8x8 samples of each chroma component. Furthermore, in the example illustrated, the relative positions of the chroma samples relative to the luma samples of the video blocks adjacent to the 16x16 CU are illustrated. Figure 4 As noted above, a CU is typically defined according to the number of horizontal and vertical luma samples. Thus, as illustrated, a 16x16 CU formatted according to the 4:2:0 sample format includes 16x16 samples of the luma component and 8x8 samples of each chroma component. Furthermore, in the example illustrated, the relative positions of the chroma samples relative to the luma samples of the video blocks adjacent to the 16x16 CU are illustrated. Figure 4 As noted above, a CU is typically defined according to the number of horizontal and vertical luma samples. Thus, as illustrated, a 16x16 CU formatted according to the 4:2:0 sample format includes 16x16 samples of the luma component and 8x8 samples of each chroma component. Furthermore, in the example illustrated, the relative positions of the chroma samples relative to the luma samples of the video blocks adjacent to the 16x16 CU are illustrated.

[0066] As noted above, intra prediction data or inter prediction data is used to produce reference sample values for a block of sample values. The difference between the sample values included in a current PB or another type of picture region structure and the associated reference samples (e.g., the reference samples produced using the prediction) can be referred to as residual data. The residual data can include an array of individual difference values corresponding to each component of the video data. The residual data can be in the pixel domain. A transform such as a discrete cosine transform (DCT), a discrete sine transform (DST), an integer transform, a wavelet transform, or a conceptually similar transform can be applied to the array of difference values to produce transform coefficients. It should be noted that in ITU-T H.265, a CU is associated with a transform unit (TU) structure having its root at the CU level. That is, in ITU-T H.265, a difference value array can be subdivided (e.g., four 8x8 transforms can be applied to a 16x16 array of residual values) in order to produce transform coefficients. This subdivision of difference values for each component of the video data can be referred to as a transform block (TB). It should be noted that in ITU-T H.265, TBs need not be aligned with PBs. Figure 5Examples of alternative PB and TB combinations that can be used to encode a particular CB are shown. Also, it should be noted that in ITU-T H.265, a TB can have the following sizes: 4x4, 8x8, 16x16, and 32x32.

[0067] It should be noted that in JEM, residual values corresponding to a CB are used to produce transform coefficients without further blocking. That is, in JEM, QTBT leaf nodes can be analogous to PBs and TBs in ITU-T H.265. It should be noted that in JEM, a core transform and a subsequent secondary transform can be applied (in a video encoder) to produce transform coefficients. For a video decoder, the order of the transforms is reversed. Also, in JEM, whether a secondary transform is applied to produce transform coefficients can depend on a prediction mode.

[0068] Quantization processing can be performed on transform coefficients. Quantization scales transform coefficients in order to change the amount of data required to represent a set of transform coefficients. Quantization can include dividing transform coefficients by a quantization scaling factor and any associated rounding function (e.g., rounding to the nearest integer). Quantized transform coefficients can be referred to as coefficient level values. Dequantization (or “inverse quantization”) can include multiplying coefficient level values by a quantization scaling factor. It should be noted that, as used herein, in some cases the term quantization process can refer to dividing by a scaling factor to produce level values and multiplying by a scaling factor to recover transform coefficients in some cases. That is, quantization processing can refer to quantization in some cases and dequantization in some cases. Also, it should be noted that although in the following examples the following quantization processes are described in terms of arithmetic operations associated with decimal notation, such descriptions are for illustrative purposes and should not be interpreted as limiting. For example, the techniques described herein can be implemented in devices using binary operations and the like. For example, multiplication and division operations described herein can be implemented using bit shifting operations and the like.

[0069] Figure 6A to Figure 6B is a conceptual diagram showing an example of encoding a block of video data. As shown in Figure 6A , a current block of video data (e.g., a CB corresponding to a video component) is encoded by producing residuals by subtracting a set of prediction values from the current block of video data, performing a transform on the residuals, and quantizing transform coefficients to produce level values. As shown in Figure 6B , the current block of video data is decoded by performing inverse quantization on the level values, performing an inverse transform, and adding a set of prediction values to the resulting residuals. It should be noted that in Figure 6A to Figure 6BIn the example of FIG. 1, the sample values of the reconstructed block are different from the sample values of the current video block being encoded. In this way, the encoding can be considered lossy. However, to a viewer of the reconstructed video, the difference in sample values can be considered acceptable or imperceptible. Moreover, as shown in Figure 6A to Figure 6B

[0070] In ITU-T H.265, the scaling factor array is produced by selecting a scaling matrix and multiplying each entry in the scaling matrix by a quantization scaling factor. In ITU-T H.265, the scaling matrix is selected based on the prediction mode and the color component, where scaling matrices of the following sizes are defined: 4x4, 8x8, 16x16, and 32x32. Thus, it should be noted that ITU-T H.265 does not define scaling matrices for sizes other than 4x4, 8x8, 16x16, and 32x32. In ITU-T H.265, the value of the quantization scaling factor can be determined by a quantization parameter, QP. In ITU-T H.265, QP can take 52 values from 0 to 51, and a change of 1 in QP typically corresponds to a change of about 12% in the value of the quantization scaling factor. Moreover, in ITU-T H.265, the QP value for a set of transform coefficients can be derived using a predicted quantization parameter value (which can be referred to as a predicted QP value or a QP prediction value) and optionally a signaled quantization parameter delta value (which can be referred to as a QP delta value or a delta QP value). In ITU-T H.265, the quantization parameter can be updated for each CU, and the quantization parameter can be derived for each of the luma (Y) and chroma (Cb and Cr) components.

[0071] Figure 6A ​​As shown, the quantized transform coefficients are encoded into the bitstream. The quantized transform coefficients and syntax elements (e.g., syntax elements indicative of the coding structure of the video block) can be entropy encoded according to an entropy encoding technique. Examples of entropy encoding techniques include content adaptive variable length coding (CAVLC), context adaptive binary arithmetic coding (CABAC), probability interval partitioning entropy coding (PIPE), and the like. The entropy encoded quantized transform coefficients and corresponding entropy encoded syntax elements can form a compliant bitstream that can be used to reproduce the video data at a video decoder. The entropy encoding process can include performing binarization on the syntax elements. Binarization refers to the process of converting a value for a syntax element into a sequence of one or more bins. A bin can be referred to as a “bin.” Binarization is a lossless process and can include one or a combination of the following encoding techniques: fixed length encoding, unary encoding, truncated unary encoding, truncated Rice encoding, Golomb encoding, k-th order exponential Golomb encoding, and Golomb-Rice encoding. For example, binarization can include representing the integer value 5 for a syntax element as 00000101 using an 8-bit fixed length binarization technique or as 11110 using a unary encoding binarization technique. As used herein, each of the terms fixed length encoding, unary encoding, truncated unary encoding, truncated Rice encoding, Golomb encoding, k-th order exponential Golomb encoding, and Golomb-Rice encoding can refer to general implementations of these techniques and / or more specific implementations of these encoding techniques. For example, a Golomb-Rice encoding implementation can be defined according to a video coding standard, such as ITU-T H.265. The entropy encoding process also includes encoding the bin values using lossless data compression algorithms. In the example of CABAC, for a particular bin, a context model can be selected from a set of available context models associated with the bin. In some examples, the context model can be selected based on previous bins and / or values of previous syntax elements. The context model can identify a probability for a bin having a particular value. For example, the context model can indicate a 0.7 probability of encoding a 0-valued bin and a 0.3 probability of encoding a 1-valued bin. It should be noted that in some cases, the sum of the probability of encoding a 0-valued bin and the probability of encoding a 1-valued bin can not be 1. After selecting an available context model, the CABAC entropy encoder can arithmetically encode the bin based on the identified context model. The context model can be updated based on the value of the encoded bin. The context model can be updated based on associated variables stored with the context, such as an adaptive window size, a number of bins encoded using the context. It should be noted that according to ITU-T H.265, the CABAC entropy encoder can be implemented such that some syntax elements can be entropy encoded using arithmetic encoding without the need to use an explicitly assigned context model, which can be referred to as bypass encoding.

[0072] As described above, intra prediction data or inter prediction data can associate a region of a picture (e.g., a PB or a CB) with corresponding reference samples. For intra prediction coding, an intra prediction mode can specify the location of reference samples within the picture. In ITU-T H.265, the defined possible intra prediction modes include a planar (i.e., surface fitting) prediction mode (predMode: 0), a DC (i.e., flat overall average) prediction mode (predMode: 1), and 33 angular prediction modes (predMode: 2-34). In JEM, the defined possible intra prediction modes include a planar prediction mode (predMode: 0), a DC prediction mode (predMode: 1), and 65 angular prediction modes (predMode: 2-66). It should be noted that the planar and DC prediction modes can be referred to as non-directional prediction modes, and the angular prediction modes can be referred to as directional prediction modes. It should be noted that the techniques described herein are generally applicable regardless of the number of defined possible prediction modes.

[0073] As described above, the planar prediction mode defined according to ITU-T H.265 can be described as surface fitting. The planar prediction mode defined according to ITU-T H.265 includes averaging two linear predictions. That is, in ITU-T H.265, for each sample included in a CB, a respective prediction is determined as the average of two linear predictions. The first horizontal linear prediction is produced by interpolating the values of the reconstructed sample values in the neighboring top row of the CB (denoted by T in FIG. 1) to the location of the current sample value of the reconstructed sample having the same vertical position as the current sample in the neighboring left column of the CB (i.e., defined as p[-1][y]). The second vertical linear prediction is produced by interpolating the values of the reconstructed sample values in the neighboring left column of the CB (denoted by L in FIG. 1) to the location of the current sample value of the reconstructed sample having the same horizontal position as the current sample in the neighboring top row of the CB (i.e., defined as p[x][-1]). Thus, referring to FIG. 1, the planar prediction mode defined according to ITU-T H.265 can generally be described as the average of (1) the interpolated value of T and p[-1][y] and (2) the interpolated value of L and p[x][-1]. Figure 15A Figure 15A Figure 15A

[0074] ​​​predSamples[ x ][ y ] = ( ( nTbS - 1 - x ) * p[ -1 ][ y ] + ( x + 1 ) * p[ nTbS ][ -1 ] + ( nTbS - 1 - y ) * p[ x ][ -1 ] + ( y + 1 ) * p[ -1 ][ nTbS ] + nTbS ) » ( Log2( nTbS ) + 1 )

[0075] wherein

[0076] nTbS specifies the size of the corresponding transform block;

[0077] p[ -1 ][ y ] is the sample value of the reconstructed sample located in the neighboring left column of the CB and having the same vertical position as the current sample;

[0078] p[ nTbS ][ -1 ] is the sample value of T;

[0079] p[ x ][ -1 ] is the sample value of the reconstructed sample located in the neighboring top row of the CB and having the same horizontal position as the current sample;

[0080] p[ -1 ][ nTbS ] is the sample value of L;

[0081] x » y is an arithmetic right shift of the two’s complement integer representation of x by y binary digits; and

[0082] Log2( x ) is the base-2 logarithm of x.

[0083] Figure 15B An example is shown for a current sample C, p[ -1 ][ y ] is denoted as b and p[ x ][ -1 ] is denoted as a.

[0084] For inter prediction coding, a motion vector (MV) identifies a reference sample in a picture other than the picture of the video block to be coded, thereby exploiting temporal redundancy in the video. For example, a current video block can be predicted from a reference block located in a previously coded frame, and a motion vector can be used to indicate the position of the reference block. Motion vectors and related data can describe, for example, a horizontal component of a motion vector, a vertical component of a motion vector, a resolution of a motion vector (e.g., quarter-pel precision, half-pel precision, one-pel precision, double-pel precision, four-pel precision), a prediction direction, and / or a reference picture index value. Furthermore, coding standards, such as ITU-T H.265, can support motion vector prediction. Motion vector prediction enables the use of motion vectors of neighboring blocks to specify a motion vector. Examples of motion vector prediction include advanced motion vector prediction (AMVP), temporal motion vector prediction (TMVP), so-called “merge” mode, and “skip” and “direct” motion inference. Furthermore, JEM supports advanced temporal motion vector prediction (ATMVP) and spatial-temporal motion vector prediction (STMVP).

[0085] As described above, in JEM, QTBT leaf nodes that allow for arbitrary rectangular CBs can be similar to PBs and TBs in ITU-T H.265. Thus, in some cases, JEM can provide less flexibility in possible PB and TB structures than ITU-T H.265. As described further above, in ITU-T H.265, only square TBs are allowed, and for intra prediction, only square PBs are allowed. Thus, some processes in ITU-T H.265 are defined based on the assumption that the array of sample values input to the process must be square, and thus, some processes in ITU-T H.265 can not provide sufficient support for encoding arbitrary rectangular video blocks. Furthermore, QTBT partitioning and related signaling defined in JEM can not be ideal. This disclosure describes techniques for performing video encoding using arbitrary rectangular video blocks.

[0086] Figure 7 is a block diagram illustrating an example of a system that can be configured to encode (i.e., encode and / or decode) video data according to one or more techniques of this disclosure. System 100 represents an example of a system that can perform video encoding using arbitrary rectangular video blocks according to one or more techniques of this disclosure. As shown, system 100 includes source device 102, communication medium 110, and destination device 120. In the example shown, source device 102 can include any device configured to encode video data and send the encoded video data to communication medium 110. Destination device 120 can include any device configured to receive encoded video data via communication medium 110 and decode the encoded video data. Source device 102 and / or destination device 120 can include computing devices equipped for wired and / or wireless communication, and can include set-top boxes, digital video recorders, televisions, desktop, laptop, or tablet computers, gaming consoles, mobile devices including, e.g., “smart” phones, cellular telephones, personal gaming devices, and medical imagining devices. Figure 1 Figure 1

[0087] ​​The communication media 110 can include any combination of wireless and wired communication media and / or storage devices. The communication media 110 can include coaxial cables, fiber-optic cables, twisted pair cables, wireless transmitters and receivers, routers, switches, repeaters, base stations, or any other equipment that can facilitate communication over a network. The communication media 110 can include one or more networks. For example, the communication media 110 can include a network configured to enable access to the World Wide Web (e.g., the Internet). The network can operate according to one or more combinations of telecommunications protocols. The telecommunications protocols can include proprietary aspects and / or can include standardized telecommunications protocols. Examples of standardized telecommunications protocols include Digital Video Broadcasting (DVB) standards, Advanced Television Systems Committee (ATSC) standards, Integrated Services Digital Broadcasting (ISDB) standards, Data Over Cable Service Interface Specification (DOCSIS) standards, Global System for Mobile Communications (GSM) standards, Code Division Multiple Access (CDMA) standards, Third Generation Partnership Project (3GPP) standards, European Telecommunications Standards Institute (ETSI) standards, Internet Protocol (IP) standards, Wireless Application Protocol (WAP) standards, and Institute of Electrical and Electronics Engineers (IEEE) standards.

[0088] The storage devices can include any type of device or storage medium capable of storing data. The storage media can include tangible or non-transitory computer-readable media. Computer-readable media can include optical disks, flash memories, magnetic storage, or any other suitable digital storage media. In some examples, a memory device or portions thereof can be described as non-volatile storage, and in other examples, portions of the memory device can be described as volatile storage. Examples of volatile storage can include random access memory (RAM), dynamic random access memory (DRAM), and static random access memory (SRAM). Examples of non-volatile storage can include magnetic hard disks, optical disks, floppy disks, flash memories, or forms of electrically programmable memory (EPROM) or electrically erasable and programmable (EEPROM) memory. The storage devices can include memory cards (e.g., Secure Digital (SD) memory cards), internal / external hard disk drives, and / or internal / external solid state drives. Data can be stored on the storage devices according to a defined file format.

[0089] Referring again to Figure 1The source device 102 includes a video source 104, a video encoder 106, and an interface 108. The video source 104 can include any device configured to capture and / or store video data. For example, the video source 104 can include a video camera and a storage device operably coupled thereto. The video encoder 106 can include any device configured to receive video data and generate a compliant bitstream representative of the video data. A compliant bitstream can refer to a bitstream that a video decoder can receive and reproduce video data therefrom. Aspects of a compliant bitstream can be defined according to a video coding standard. When generating a compliant bitstream, the video encoder 106 can compress the video data. The compression can be lossy (identifiable or non-identifiable) or lossless. The interface 108 can include any device configured to receive a compliant video bitstream and transmit and / or store the compliant video bitstream to a communication medium. The interface 108 can include a network interface card, such as an Ethernet card, and can include an optical transceiver, a radio frequency transceiver, or any other type of device that can send and / or receive information. Further, the interface 108 can include a computer system interface that can enable a compliant video bitstream to be stored on a storage device. For example, the interface 108 can include a chipset supporting Peripheral Component Interconnect (PCI) and Peripheral Component Interconnect Express (PCIe) bus protocols, proprietary bus protocols, Universal Serial Bus (USB) protocols, or any other logical and physical structure(s) that can be used to interconnect peer devices. 2 The destination device 120 includes an interface 122, a video decoder 124, and a display 126. The interface 122 can include any device configured to receive a compliant video bitstream from a communication medium. The interface 108 can include a network interface card, such as an Ethernet card, and can include an optical transceiver, a radio frequency transceiver, or any other type of device that can receive and / or send information. Further, the interface 122 can include a computer system interface that can enable a compliant video bitstream to be retrieved from a storage device. For example, the interface 122 can include a chipset supporting PCI and PCIe bus protocols, proprietary bus protocols, USB protocols, or any other logical and physical structure(s) that can be used to interconnect peer devices. The video decoder 124 can include any device configured to receive a compliant bitstream and / or acceptable variations thereof and reproduce video data therefrom. The display 126 can include any device configured to display video data. The display 126 can include one of a variety of display devices such as a liquid crystal display (LCD), a plasma display, an organic light emitting diode (OLED) display, or other type of display. The display 126 can include a high definition display or an ultra-high definition display. It should be noted that although the video decoder 124 is shown as a separate device from the interface 122, the video decoder 124 can be integrated into the interface 122.

[0090] Referring again to Figure 1 The destination device 120 includes an interface 122, a video decoder 124, and a display 126. The interface 122 can include any device configured to receive a compliant video bitstream from a communication medium. The interface 108 can include a network interface card, such as an Ethernet card, and can include an optical transceiver, a radio frequency transceiver, or any other type of device that can receive and / or send information. Further, the interface 122 can include a computer system interface that can enable a compliant video bitstream to be retrieved from a storage device. For example, the interface 122 can include a chipset supporting PCI and PCIe bus protocols, proprietary bus protocols, USB protocols, or any other logical and physical structure(s) that can be used to interconnect peer devices. The video decoder 124 can include any device configured to receive a compliant bitstream and / or acceptable variations thereof and reproduce video data therefrom. The display 126 can include any device configured to display video data. The display 126 can include one of a variety of display devices such as a liquid crystal display (LCD), a plasma display, an organic light emitting diode (OLED) display, or other type of display. The display 126 can include a high definition display or an ultra-high definition display. It should be noted that although the video decoder 124 is shown as a separate device from the interface 122, the video decoder 124 can be integrated into the interface 122. Figure 7In the illustrated example, video decoder 124 is described as outputting data to display 126, but video decoder 124 can be configured to output video data to various types of devices and / or subcomponents thereof. For example, video decoder 124 can be configured to output video data to any communication medium, as described herein.

[0091] Figure 8 is a block diagram illustrating an example of a video encoder 200 that can implement techniques for encoding video data described herein. It should be noted that although the example video encoder 200 is illustrated as having different functional blocks or modules, such an illustration is for descriptive purposes and does not limit video encoder 200 and / or its sub-components to a particular hardware or software architecture. It will be understood that any combination of hardware, firmware, and / or software can be used to implement the functionality of video encoder 200. In one example, video encoder 200 can be configured to encode video data according to the techniques described herein. Video encoder 200 can perform intra-prediction encoding and inter-prediction encoding of picture regions, and can therefore be referred to as a hybrid video encoder. In Figure 8 In the illustrated example, video encoder 200 receives a source video block. In some examples, the source video block can include a picture region that has been partitioned according to an encoding structure. For example, the source video data can include macroblocks, CTUs, CBs, sub-partitions thereof, and / or other equivalent encoding units. In some examples, video encoder 200 can be configured to perform additional sub-partitioning of the source video block. It should be noted that some techniques described herein can generally be applicable to video encoding regardless of how source video data is partitioned prior to and / or during encoding. In Figure 8 In the illustrated example, video encoder 200 includes summer 202, transform coefficient generator 204, coefficient quantization unit 206, inverse quantization / transform processing unit 208, summer 210, intra-prediction processing unit 212, inter-prediction processing unit 214, post filter unit 216, and entropy encoding unit 218.

[0092] As shown in Figure 8 Video encoder 200 receives a source video block and outputs a bitstream, as shown in FIG. 2. As described above, JEM includes the following parameters for signaling of QTBT trees: CTU size, MinQTSize, MaxBTSize, MaxBTDepth, and MinBTSize. Table 2 shows block sizes for QT leaf nodes at various QT depths for different CTU sizes (MinQTSize is 8 in this example). In addition, Table 3 shows allowed block sizes for BT leaf nodes at various BT depths for binary tree root node sizes (i.e., leaf quad-tree node sizes).

[0093]

[0094] Table 2

[0095]

[0096] Table 3

[0097] Accordingly, with reference to Table 2, the size of the quad-tree node forming the root of the binary tree can be determined based on the CTU size and the QT depth. If the quad-tree is further partitioned into binary trees, the size of the binary tree leaf node can be determined based on the QT node size and the BT depth, as shown in Table 3. Each of MaxBTSize, MaxBTDepth, and MinBTSize can be used to determine the minimum allowed binary tree leaf node size. For example, if the CTU size is 128x128, the QT depth is 3, MaxBTSize is 16x16, and MaxBTDepth is 2, the minimum allowed binary tree leaf node size includes 64 samples (i.e., 8x8, 16x4, or 4x16). In this case, if MaxBTDepth is 1, the minimum allowed binary tree leaf node size includes 128 samples (i.e., 16x8 or 8x16). Table 4 shows the block size of the BT leaf node for various combinations of QT depth and BT depth for a CTU size of 128x128.

[0098]

[0099] Table 4

[0100] As described above, the QTBT partitioning defined in JEM and related signaling can not be ideal. For example, as described above with reference to Figure 3 , in JEM, when independent QTBTs are used to partition a CTU, the CBs of the luma component do not need and are not necessarily aligned with the CBs of the chroma components. That is, in JEM, when independent QTBTs are used to partition a CTU, each of the luma and chroma component partitions is signaled using a separate set of QT split flags and BT split mode syntax elements, such signaling can not be ideal.

[0101] In some examples, video encoder 200 can be configured to partition CTUs such that luma and chroma components have a common partitioning structure up to a particular depth, and thus share a common set of QT split flags and BT split mode syntax elements up to the particular depth, according to the techniques described herein. It should be noted that in this case, the depth can correspond to an absolute depth of the QTBT (i.e., a depth formed by the sum of the QT depth and the BT depth). It should be noted that in some cases, the depth can correspond to a number of samples in a component (e.g., luma and / or chroma) of a block, and can optionally be indicated according to a minimum width and / or a minimum height. For example, QTBTs can be shared up to a point at which an array of chroma samples is partitioned to a particular size. For example, QTBTs can be shared up to a point at which one of a height or width of a node is less than a specified number of samples for a component, e.g., 8 samples. For example, QTBTs can be shared up to a point at which a number of samples for a component (e.g., luma and / or chroma) of a node is less than a specified number, e.g., 64. In one example, a depth can be predetermined for a group of CTUs. For example, a depth can be set to 2 for a slice of video data, or for example, a depth can be set to 2 for a picture of video data. In one example, a depth can be signaled using a syntax element (e.g., shared_depth, etc.). In one example, a shared depth syntax element can be signaled at a CTU level. In one example, a shared depth syntax element can be signaled at a slice level. In one example, a shared depth syntax element can be signaled at a parameter set level (e.g., a picture parameter set (PPS) or a sequence parameter set (SPS)). In one example, a higher level flag can be used to indicate the presence of a shared depth syntax element at a lower level. For example, a syntax element included at a slice level can indicate whether a shared depth syntax element is included for each CTU included in the slice. It should be noted that in a similar manner, a CTU level flag can be used to indicate one or more of a shared QTBT, a partially shared QTBT, or independent QTBTs for luma and chroma components.

[0102] In one example, a shared depth syntax element can be a flag at a split level. For example, for each QT split flag and / or BT split mode, a respective flag can indicate whether the indicated split is shared. In one example, a shared depth syntax element at a higher level can be used to set a shared depth, and a lower level flag can be used to indicate sharing beyond the level specified by the syntax element. For example, a shared depth can be set to a depth of 1 at a slice level, and each CTU within the slice can include a flag indicating whether the particular CTU shares is extended beyond the depth of 1 to a depth of 2.

[0103] Figure 9 and Figure 10This is a conceptual diagram illustrating an example of a common block where the luminance and chrominance components share a common depth. Figure 9 In the example shown, the luminance component is further segmented beyond a shared depth of 1, while the chrominance component is not segmented beyond a depth of 1. Figure 10 In the example shown, both the luma and chroma components are independently blocked beyond a shared depth of 1. As described above, the video sampling format can define the number of chroma samples included in the CU relative to the number of luma samples included in the CU. In one example, the video encoder 200 can be configured to selectively block the chroma components beyond the shared depth based on the sampling format. For example, in the case of formatting the CTU according to a 4:2:0 sample format, in one example, the video encoder 200 can be configured such that the chroma components are not further blocked beyond the shared depth. Furthermore, in the case of formatting the CTU according to a 4:4:4 sample format, in one example, the video encoder 200 can be configured such that the chroma components are further blocked beyond the shared depth. In addition, as an addition or alternative to the sampling format, one or more of the following can be used: CTU size, MinQTSize, MaxBTSize, MaxBTDepth, and / or MinBTSize can be used to determine the chroma components that are allowed to be blocked beyond the shared depth.

[0104] Figure 11 It is shown that... Figure 10 The example QTBT block shown is a conceptual diagram of an example QTBT. Figure 11 As shown, the QTBT for luminance and the QTBT for chrominance are the same up to depth 1, i.e., they share a depth of 1. Furthermore, it should be noted that, for illustrative purposes, Figure 11 The brightness tree shown Figure 2 The QTBT shown is the same. Thus, for Figure 11 As shown in the example, video encoder 200 can be configured to signal the luma QTBT based on the pseudo-syntax provided in Table 1. In one example, video encoder 200 can be configured to signal the chroma QTBT that exceeds the shared QTBT based on the pseudo-syntax provided in Table 5.

[0105]

[0106]

[0107] Table 5

[0108] In the example shown in Table 5, adding the partitioning condition can include a condition based on one or more of: a sampling format, a CTU size, a MinQTSize, a MaxBTSize, a MaxBTDepth, and / or a MinBTSize, as described above. It should be noted that in one example, video encoder 200 can be configured to signal the QTBTs that exceed the shared QTBT chroma by multiplexing the syntax elements illustrated in Table 1 and Table 5. For example, the syntax elements for the chroma component nodes that exceed the shared node and the syntax elements that are descendants of the shared node can be signaled after the syntax elements for the luma component nodes that exceed the shared node and the syntax elements that are descendants of the shared node. Table 6 shows an example of pseudo syntax where the syntax elements for the chroma components are signaled after the syntax elements that terminate the shared node as a leaf node for the luma component. In one example, the chroma syntax elements can be signaled before the luma syntax elements.

[0109]

[0110]

[0111] Table 6

[0112] In this way, video encoder 200 represents an example of a device configured to receive a video block including sample values of a first component of video data and a second component of video data; partition the sample values of the first component of video data according to a first quadtree binary tree partitioning structure; and partition the sample values of the second component of video data according to the first quadtree binary tree partitioning structure to a shared depth.

[0113] As described above, ITU-T H.265 supports four asymmetric PB partitions for inter prediction. It should be noted that the asymmetric PB partitions provided in ITU-T H.265 can not be ideal. That is, the asymmetric PB partitions provided in ITU-T H.265 are limited to PBs that have a width or height that is one quarter of a square CB. For example, for a 32x32 CB in ITU-T H.265, the M / 4xM left partition splits the CB into an 8x32 PB and a 24x32 PB. ITU-T H.265 does not provide a mechanism to partition a CB into PBs based on an arbitrary offset. That is, PBs are not allowed to have an arbitrary width or height. In some cases, it can be useful to partition a CTB according to an arbitrary offset. For example, in the example above, for a 32x32 CB, in some cases, it can be useful to partition the CB into a 10x32 PB and a 22x32 PB based on the properties of the image. Further, with reference to Table 3 above, in some cases, it can be useful to further divide the binary leaf nodes according to an arbitrary offset. That is, in JEM, the potential leaf node sizes are limited to those shown in Table 3. For example, in the case of a binary leaf node that is 32x128, it can be useful to further partition the binary leaf node into a 32x28 CB and a 32x100 CB. It should be noted that partitioning video data blocks according to an arbitrary offset according to the techniques described herein can be applied in at least one or more of the following cases: (1) in the case where a CU (or CB) forms the root of a PU (or PB), arbitrary offset partitioning can be applied to partitioning a CTU (or CTB) into CUs (or CBs); (2) in the case where a CU (or CB) does not form the root of a PU (or PB), i.e., in the case where prediction is determined at the CB level, arbitrary offset partitioning can be applied to partitioning a CTU (or CTB) into CUs (or CBs); (3) arbitrary offset partitioning can be applied to partitioning of PUs (or PBs); and (4) arbitrary offset partitioning can be applied to partitioning of sample blocks corresponding to nodes of a coding tree. It should be noted that in some cases, arbitrary offset partitioning can be selectively enabled for CTU partitioning and / or PU partitioning.

[0114] Figure 12 An example is shown of further horizontally partitioning a binary leaf node according to an offset. It should be noted that although the example shown in FIG. 6 includes partitioning a binary leaf node according to arbitrary offset partitioning, such examples should not be construed as limiting and as described herein, arbitrary offset partitioning can be applied to various scenarios in which video data has been partitioned. For example, in the case of a binary leaf node that is 32x128, it can be useful to further partition the binary leaf node into a 32x28 CB and a 32x100 CB. Figure 12 Figure 12 ​In the example shown, the CTB can correspond to a luminance CTB of size 256×256. In this case, the size of the top-right binary leaf node is 32×128. As mentioned above, it might be useful to further divide the 32×128 binary leaf node into 32x28 CBs and 32x100 CBs. Figure 12 In the example chunk shown, the offset value is 28. In one example, the video encoder 200 can be configured to chunk the leaf nodes of the QTBT based on the offset. In one example, the video encoder 200 can be configured to allow any number of asymmetric offset chunk structures. That is, in some examples, for vertical offsets, the offset can be in the range of 2 to the chunk height minus 2, and for horizontal offsets, the offset can be in the range of 2 to the chunk width minus 2. In some examples, for vertical offsets, the offset can be in the range of 1 to the chunk height minus 1, and for horizontal offsets, the offset can be in the range of 1 to the chunk width minus 1. In some examples, the allowed asymmetric offset chunks can be limited based on attributes associated with the CTU and / or prediction mode. For example, asymmetric offset chunks can be limited based on whether the CU is encoded based on intra-frame prediction or inter-frame prediction. Furthermore, in some examples, asymmetric offset chunks can be limited based on the size of the CU or CB. In one example, the offset value can be limited to an integer multiple of the set value. In one example, the offset value can be limited to an integer multiple of the set value plus some additional integer values ​​(e.g., 2). In some examples, the set of integer multiples can be based on the size of the leaf node to which the offset is being applied. For example, regarding the case of horizontally partitioning 32×128 leaf nodes as described above. In one example, the offset value can be restricted to a multiple of 4 (i.e., allowed offset values ​​include 4, 8, 12, 16, ..., 120, 124). In one example, a set of offset values ​​for the index can be used to specify the offset value. For example, regarding the case of horizontally partitioning 32×128 leaf nodes as described above, in one example, the offset value can be restricted to the following set of offset values: 28, 42, 84, and 100. In some examples, a set of offset values ​​for the index can be selected to avoid partitions that can be signaled using QTBT signaling or its approximate variations. For example, in the case of horizontally partitioning 32×128 leaf nodes, in some cases (e.g., depending on the value of MaxBTDepth), the BT structure can allow the 32×128 leaf nodes to be divided into two 32x64 blocks. In this case, a set of offset values ​​for the index can be selected such that the offset is not within the specified range of 64. In addition, in some examples, a set of offset values ​​for the index can be based on the value of MaxBTDepth.

[0115] It should be noted that in some examples, the permitted asymmetric offset blocks may include horizontal or vertical blocks. For example, in one example, regarding a 32×128 binary leaf node, the video encoder 200 may be configured to further divide the 32×128 binary leaf node into 8×128 CBs and 24×128 CBs. In this way, the offset may indicate an offset value relative to an anchor point. For example, the anchor point may include the left edge for the vertical block and the top edge for the horizontal block. It should be noted that in some examples, the anchor may be a set number of samples from the edge. For example, the anchor may be set to 4 samples from the edge. In this way, an offset value of zero would indicate a block of 4 samples from the edge. In one example, the offset may include fixed-length binarization. In one example, the offset may include truncated univariate binarization.

[0116] As described above, in one example, a set of offset values ​​for the index can be used to specify the value of the offset. In one example, the set of offset values ​​for the index can correspond to fractional blocks. Tables 7 and 8 provide examples of a set of offset values ​​for the index corresponding to fractional blocks. Regarding Tables 7 and 8, it should be noted that in some examples, fractional blocks can be rounded to the nearest sample value. For example, regarding the case of horizontally dividing 32×128 leaf nodes as described above, in one example, the offset from 1 / 3 of the edge value can be rounded to 43. Regarding Tables 7 and 8, it should be noted that in the examples, fractional blocks can be rounded to the nearest integer multiple of the sample value. For example, regarding the case of horizontally dividing 32×128 leaf nodes as described above, in one example, the offset from 1 / 3 of the edge value can be rounded to 44, which is the nearest multiple of 4 samples. Regarding Tables 7 and 8, it should be noted that in the examples, fractional blocks can be rounded down to the nearest integer multiple of the sample value. For example, regarding the case of horizontally dividing 32×128 leaf nodes as described above, in one example, an offset of 1 / 3 from the edge value can be rounded to 40, which is the closest multiple of 4 samples.

[0117] Offset from edge Binary representation of offset 1 / 4 of block size under consideration 01 1 / 2 of block size under consideration 1 3 / 4 of block size under consideration 00

[0118] Table 7

[0119] Offset from edge Binary representation of offset 1 / 3 of block size under consideration 01 1 / 2 of block size under consideration 1 2 / 3 of block size under consideration 00

[0120] Table 8

[0121] As described above, the video encoder 200 can be configured to signal the QTBT. In one example, the video encoder 200 can be configured to indicate an offset value by incorporating offset signaling within the QTBT's signaling. For example, Figure 12 The examples shown include those with Figure 1The same QTBT structure shown in the example in Table 9. In this way, the offset signaling can be based on the example pseudo syntax shown in Table 1, where, in one example, the offset signaling is included after the syntax indicating a leaf node. Table 9 shows an example pseudo syntax corresponding to the case where, for a 256x256 CTB, the top-right binary leaf node with a size of 32x128 is further partitioned into 32x28 Cb and 32x100 CB.

[0122]

[0123] Table 9

[0124] Accordingly, according to the example shown in Table 9, video encoder 200 can be configured to signal a flag indicating that offset partitioning applies to a QTBT leaf node, signal a signal indicating whether the offset partitioning is vertical or horizontal partitioning, and signal a value indicating the offset value. It should be noted that, in other examples, video encoder 200 can be configured to use other signaling techniques to indicate the offset value. For example, video encoder 200 can be configured to signal the offset value for a CB height. It should be noted that, in some examples, the offset can be signaled as an extension of the current BT split mode signaling. That is, for example, in JEM, the BT split mode syntax element results in halving of the node. In one example, according to the techniques described herein, the BT split mode signaling can include signaling the split type and the offset pair. For example, referring to Figure 12 , in one example, the offset can be signaled as follows: (BT split = 2, Offset value = 28).

[0125] Further, in one example, each CB of a CTB can be indexed according to a defined scan order, and video encoder 200 can be configured to signal the offset value by signaling an index value for the CB. For example, referring to Figure 13 , the top-right binary leaf node is shown as being indexed as CB8. Accordingly, in one example, video encoder 200 can be configured to use this index value to indicate that offset partitioning is performed on this leaf node. In this way, video encoder 200 represents an example of a device configured to determine an offset value and partition a leaf node according to the offset value.

[0126] In one example, a predetermined order of a set of split decisions (arbitrary offset partitioning and / or QT partitioning) can be applied to a sample block, and indicated in the bitstream using a single indicator.

[0127] Referring again to Figure 8The video encoder 200 generates residual data by subtracting a predictive video block from a source video block. The summer 202 represents the component configured to perform this subtraction operation. In one example, the subtraction of the video block occurs in the pixel domain. The transform coefficient generator 204 applies a transform, such as the Discrete Cosine Transform (DCT), Discrete Sine Transform (DST), or a conceptually similar transform, to its residual block or sub-partition (e.g., four 8×8 transforms can be applied to a 16×16 array of residual values) to produce a set of residual transform coefficients. The transform coefficient generator 204 can be configured to perform any and all combinations of transforms included in the discrete trigonometric transform family. As mentioned above, in ITU-T H.265, TB is limited to the following sizes: 4×4, 8×8, 16×16, and 32×32. In one example, the transform coefficient generator 204 can be configured to perform transforms based on arrays of sizes 4×4, 8×8, 16×16, and 32×32. In one example, the transform coefficient generator 204 can also be configured to perform transforms based on arrays with other dimensions. In particular, performing transforms on rectangular arrays of differences can be useful in certain cases. In one example, the transform coefficient generator 204 can be configured to perform transforms based on arrays of the following sizes: 2×2, 2×4N, 4M×2, and / or 4M×4N. In one example, a 2D (2M×N) inverse transform can be implemented as a 1D (1D) M-point inverse transform followed by a 1D N-point inverse transform. In one example, a 2D inverse transform can be implemented as a 1D N-point vertical transform followed by a 1D N-point horizontal transform. In another example, a 2D inverse transform can be implemented as a 1D N-point horizontal transform followed by a 1D N-point vertical transform. The transform coefficient generator 204 can output transform coefficients to the coefficient quantization unit 206.

[0128] Coefficient quantization unit 206 can be configured to perform quantization of transform coefficients. As described above, the quantization level can be modified by adjusting the quantization parameters. Coefficient quantization unit 206 can also be configured to determine quantization parameters and output QP data (e.g., data for determining the quantization group size and / or ΔQP value), which can be reconstructed by the video decoder to perform inverse quantization during video decoding. It should be noted that in other examples, one or more additional or alternative parameters (e.g., scaling factors) can be used to determine the quantization level. The techniques described herein are generally applicable to determining the quantization level of transform coefficients corresponding to components of video data based on the quantization level of the transform coefficients corresponding to another component of the video data.

[0129] like Figure 8 As shown, the quantized transform coefficients are output to the inverse quantization / transform processing unit 208. The inverse quantization / transform processing unit 208 can be configured to apply inverse quantization and inverse transform to generate reconstructed residual data. Figure 8As shown, at summer 210, reconstructed residual data can be added to the predictive video block. In this way, the encoded video block can be reconstructed, and the resulting reconstructed video block can be used to evaluate the coding quality of a given prediction, transform, and / or quantization. Video encoder 200 can be configured to perform multiple encoding passes (e.g., performing encoding while varying one or more of the prediction, transform parameters, and quantization parameters). Rate-distortion or other system parameters of the bitstream can be optimized based on the evaluation of the reconstructed video block. Moreover, the reconstructed video block can be stored and used as a reference for predicting subsequent blocks.

[0130] As described above, video blocks can be encoded using intra prediction. Intra prediction processing unit 212 can be configured to select an intra prediction mode for a video block to be encoded. Intra prediction processing unit 212 can be configured to evaluate the frame and / or regions thereof, and determine an intra prediction mode to use to encode the current block. As described above, possible intra prediction modes can include a planar prediction mode, a DC prediction mode, and an angular prediction mode. Moreover, in some examples, predictions for chroma components can be inferred from the intra prediction for luma, as described above. Figure 8 As shown, intra prediction processing unit 212 outputs intra prediction data (e.g., syntax elements) to entropy encoding unit 218 and transform coefficient generator 204. As described above, the transform performed on residual data can be mode dependent. As described above, possible intra prediction modes can include a planar prediction mode, a DC prediction mode, and an angular prediction mode. Moreover, in some examples, predictions for chroma components can be inferred from the intra prediction for luma.

[0131] As described above, ITU-T H.265 provides a formal definition of the planar prediction mode that is based on a variable nTbS that specifies the size of the corresponding transform block. As further described above, in ITU-T H.265, TBs are restricted to the following sizes 4x4, 8x8, 16x16, and 32x32. Thus, nTbS can have the values 4, 8, 16, or 32 to indicate the size of a square, and thus cannot indicate a rectangular shape of arbitrary size. Thus, the planar prediction mode defined according to ITU-T H.265 can not be ideal for performing planar prediction with respect to rectangular shapes of arbitrary size. According to the techniques described herein, video encoder 200 can be configured to perform planar prediction with respect to rectangular CBs of arbitrary size.

[0132] In one example, video encoder 200 can be configured to perform planar prediction with respect to rectangular CBs of arbitrary size by averaging the horizontal interpolation and the vertical prediction. Such planar prediction can be generally described as follows:

[0133] predSamples[x][y] = (Hor_Interpolation[x][y] + Ver_Interpolation[x][y] + 1) / 2

[0134] In one example, Hor_Interpolation[x][y] and Ver_Interpolation[x][y] can be based on the width and height of the CB, respectively, according to the following equations:

[0135] Hor_Interpolation[x][y] = ((nCbSW - 1 - x) * p[-1][y] + (x + 1) * p[nCbSW][-1]) / nCbSW

[0136] and

[0137] Ver_Interpolation[x][y] = ((nCbSH - 1 - y) * p[x][-1] + (y + 1) * p[-1][nCbSH]) / nCbSH

[0138] which can be expressed as:

[0139] predSamples[x][y] = (((nCbSW - 1 - x) * p[-1][y] + (x + 1) * p[nCbSW][-1]) * nCbSH + ((nCbSH - 1 - y) * p[x][-1] + (y + 1) * p[-1][nCbSH]) * nCbSW + nCbSW * nCbSH) / (2 * nCbSW * nCbSH)

[0140] wherein

[0141] nCbSW specifies the width of the corresponding coding block;

[0142] nCbSH specifies the height of the corresponding coding block;

[0143] p[-1][y] is the sample value of the reconstructed sample located in the neighboring left column of the CB and having the same vertical position as the current sample;

[0144] P[nCbSW][-1] is the sample value of T;

[0145] p[x][-1] is the sample value of the reconstructed sample located in the neighboring top row of the CB and having the same horizontal position as the current sample;

[0146] p[-1][nCbSH] is the sample value of L; and

[0147] / is an integer division operation, the result of which is truncated to zero.

[0148] With respect to the example equations above, it should be noted that although the equations are described with respect to CBs, in other examples, the equations can be described with respect to PBs, TBs, and / or other coding structures or picture regions.

[0149] With respect to the above example equations, it should be noted that in some cases, a coding block can correspond to a transform block, and in other cases, the coding block and transform block structures can be independent. Figure 16A The positions of T and L with respect to the example rectangular CB according to the above equations are shown. Figure 16B An example is shown for a current sample, C, p[-1][y] denoted as b and p[x][-1] denoted as a. It should be noted that according to the above equations, a relatively higher weight is applied compared to b in cases where nCbSW is greater than nCbSH, and a relatively higher weight is applied compared to b in cases where nCbSH is greater than nCbSW. Thus, video encoder 200 can be configured to perform planar prediction in a manner that takes into account the orientation of the rectangular array of sample values. It should be noted that in some examples, a weighted average can be applied to the horizontal interpolation and the vertical interpolation. For example, such planar prediction can be generally described as follows:

[0150] predSamples[x][y] = (a * Hor_Interpolation[x][y] + β * Ver_Interpolation[x][y] + (a + β) / 2) / (a + β),

[0151] where a and β depend on nCbSH and / or nCbSW. Further, a and β can depend on PB, TB, and / or other coding structures or picture regions in other examples.

[0152] Inter-prediction processing unit 214 can be configured to perform inter-prediction encoding on a current video block. Inter-prediction processing unit 214 can be configured to receive a source video block and calculate motion vectors for PUs of the video block. A motion vector can indicate a displacement of a PU (or similar coding structure) of a video block within a current video frame relative to a predictive block within a reference frame. Inter-prediction encoding can use one or more reference pictures. Further, motion prediction can be single prediction (using one motion vector) or bi-prediction (using two motion vectors). Inter-prediction processing unit 214 can be configured to select a predictive block by calculating pixel differences determined by, for example, sum of absolute differences (SAD), sum of squared differences (SSD), or other difference metrics. As noted above, motion vectors can be determined and specified according to motion vector prediction. Inter-prediction processing unit 214 can be configured to perform motion vector prediction, as described above. Inter-prediction processing unit 214 can be configured to produce a predictive block using motion prediction data. By way of example, inter-prediction processing unit 214 can locate a predictive video block in a frame buffer Figure 8inter-prediction processing unit 214 can be further configured to apply one or more interpolation filters to the reconstructed residual block to calculate sub-integer pixel values for motion estimation. Inter-prediction processing unit 214 can output motion prediction data for the calculated motion vectors to entropy encoding unit 218. As Figure 8 As shown in FIG. 2, inter-prediction processing unit 214 can receive reconstructed video blocks via post filter unit 216. Post filter unit 216 can be configured to perform deblocking and / or sample adaptive offset (SAO) filtering. Deblocking refers to a process of smoothing boundaries of reconstructed video blocks (e.g., so that the boundaries are not easily noticeable to a viewer). SAO filtering is a non-linear amplitude mapping that can be used to improve reconstruction by adding an offset to the reconstructed video data.

[0153] Referring again to FIG. 2, Figure 8 Entropy encoding unit 218 receives quantized transform coefficients and predictive syntax data (i.e., intra-prediction data, motion prediction data, QP data, etc.). It should be noted that in some examples, coefficient quantizing unit 206 can perform a scan of a matrix including the quantized transform coefficients before outputting the coefficients to entropy encoding unit 218. In other examples, entropy encoding unit 218 can perform the scan. Entropy encoding unit 218 can be configured to perform entropy encoding according to one or more techniques described herein. Entropy encoding unit 218 can be configured to output a compliant bitstream, i.e., a bitstream from which a video decoder can receive and reproduce video data.

[0154] Figure 14 is a block diagram illustrating an example of a video decoder that can be configured to decode video data according to one or more techniques of this disclosure. In one example, video decoder 300 can be configured to reconstruct video data based on one or more of the techniques described above. That is, video decoder 300 can operate in a reverse manner to video encoder 200 described above. Video decoder 300 can be configured to perform intra-prediction decoding and inter-prediction decoding, and thus can be referred to as a hybrid decoder. In Figure 14In the illustrated example, video decoder 300 includes an entropy decoding unit 302, an inverse quantization unit 304, an inverse transform processing unit 306, an intra prediction processing unit 308, an inter prediction processing unit 310, a summer 312, a post filter unit 314, and a reference buffer 316. Video decoder 300 can be configured to decode video data in a manner consistent with a video coding standard that can implement one or more aspects of a video coding standard. It should be noted that although example video decoder 300 is illustrated as having distinct functional blocks, such an illustration is for descriptive purposes and does not limit video decoder 300 and / or its sub-components to a particular hardware or software architecture. Video decoder 300 can be implemented using any combination of hardware, firmware, and / or software implementations.

[0155] As Figure 14 illustrated, entropy decoding unit 302 receives an entropy encoded bitstream. Entropy decoding unit 302 can be configured to decode quantized syntax elements and quantized coefficients from the bitstream according to a process reciprocal to the entropy encoding process. Entropy decoding unit 302 can be configured to perform entropy decoding according to any of the entropy encoding techniques described above. Entropy decoding unit 302 can parse the encoded bitstream in a manner consistent with a video coding standard. Video decoder 300 can be configured to parse the encoded bitstream, where the encoded bitstream is generated based on the techniques described above. That is, for example, video decoder 300 can be configured to determine a QTBT partitioning structure that is generated and / or signaled based on one or more techniques described above for reconstructing video data. By way of example, video decoder 300 can be configured to parse syntax elements and / or evaluate properties of video data in order to determine a shared depth for the QTBT. Further, video decoder 300 can be configured to determine an offset value and partition a block of video data according to the offset value.

[0156] Referring again to Figure 14quantization parameter data. The quantization parameter data can include any and all combinations of the ΔQP values and / or quantization group size values described above, etc. Video decoder 300 and / or inverse quantization unit 304 can be configured to determine a QP value for inverse quantization based on values signaled by the video encoder and / or by video properties and / or coding parameters. That is, inverse quantization unit 304 can operate in a ping-pong fashion to quantization unit 206 described above. For example, inverse quantization unit 304 can be configured to infer predetermined values (e.g., determine a sum of QT depths and BT depths based on coding parameters, allowed quantization group sizes, etc.) according to the techniques described above. Inverse quantization unit 304 can be configured to apply inverse quantization. Inverse transform processing unit 306 can be configured to perform inverse transforms to produce reconstructed residual data. The techniques performed by inverse quantization unit 304 and inverse transform processing unit 306 can be similar to the techniques performed by inverse quantization / transform processing unit 208 described above. Inverse transform processing unit 306 can be configured to apply inverse DCTs, inverse DSTs, inverse integer transforms, non-separable secondary transforms (NSSTs), or conceptually similar inverse transform processes to the transform coefficients in order to produce residual blocks in the pixel domain. Moreover, as described above, whether a particular transform is performed (or the type of particular transform) can depend on the intra prediction mode. As shown in FIG. 3, the reconstructed residual data can be provided to summer 312. Summer 312 can add the reconstructed residual data to a predictive video block and produce reconstructed video data. The predictive video block can be determined according to the predictive video techniques (i.e., intra prediction and inter prediction). In one example, video decoder 300 and post filter unit 314 can be configured to determine QP values and use them for post filtering (e.g., deblocking). In one example, other functional blocks of video decoder 300 that utilize QP can determine QP based on received signaling and use it for decoding. Figure 14

[0157] ​Intra prediction processing unit 308 can be configured to receive intra prediction syntax elements and retrieve a predictive video block from reference buffer 316. Reference buffer 316 can include a memory device configured to store one or more frames of video data. The intra prediction syntax elements can identify an intra prediction mode, such as the intra prediction modes described above. In one example, intra prediction processing unit 308 can reconstruct the video block using one or more of the intra prediction coding techniques described herein. Inter prediction processing unit 310 can receive inter prediction syntax elements and generate motion vectors to identify a predictive block in one or more reference frames stored in reference buffer 316. Inter prediction processing unit 310 can generate a motion compensated block, such that interpolation can be performed based on an interpolation filter. An identifier for an interpolation filter used for motion estimation with sub-pixel accuracy can be included in the syntax elements. Inter prediction processing unit 310 can use the interpolation filter to calculate interpolated values for sub-integer pixels of the reference block. Post filter unit 314 can be configured to perform filtering on reconstructed video data. For example, post filter unit 314 can be configured to perform deblocking and / or SAO filtering, as described above with respect to post filter unit 216. In addition, it should be noted that in some examples, post filter unit 314 can be configured to perform proprietary free selection filters (e.g., visual enhancement). As Figure 14 As shown in FIG. 3, the reconstructed video block can be output by video decoder 300. In this way, video decoder 300 can be configured to generate reconstructed video data according to one or more techniques described herein. In this way, video decoder 300 can be configured to parse a first quadtree binary tree partitioning structure, apply the first quadtree binary tree partitioning structure to a first component of video data, determine a shared depth, and apply the first quadtree binary tree partitioning structure to a second component of video data up to the shared depth. In this way, video decoder 300 represents an example of a device configured to determine an offset value and partition a leaf node according to the offset value.

[0158] In one or more examples, the functions described can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions can be stored on or transmitted over 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 storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another, e.g., according to a communication protocol. In this manner, computer- readable media generally can correspond to (1) tangible computer-readable storage media which is non-transitory or (2) a communication medium such as a signal or carrier wave. Data storage media can 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 implementation of the techniques described in this disclosure. A computer program product can include a computer-readable medium.

[0159] By way of example, and not limitation, such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other storage medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any

[0160] Instructions can be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application-specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Accordingly, the term "processor," as used herein can refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described herein. In addition, in some aspects, the functionality described herein can be provided within dedicated hardware and / or software modules configured for encoding and decoding, or incorporated in a combined codec. Also, the techniques could be fully implemented in one or more circuits or logic elements.

[0161] The techniques of this disclosure can be implemented in a variety of devices or apparatuses, including a wireless handset, an integrated circuit (IC), or a set of one or more ICs (e.g., a chip set). Various components, modules, or units described herein can be implemented as hardware, software, or a combination thereof. Various components, modules, or units described herein can be implemented as hardware, software, or a combination thereof. In some aspects, the various components, modules, or units described herein can be implemented as a machine or set of machines that function in a distributed environment, as a train of machines that function in a cloud environment, or as a combination thereof.

[0162] Furthermore, each functional block or various features of the base station device and the terminal device used in each of the aforementioned embodiments can be implemented as an electrical circuitry that is composed of a combination of a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other equivalent integrated circuits or a combination thereof. Designing an electrical circuitry designed to perform the functions described in the present specification is well within the ordinary skill in the art. The general purpose processor can be a microprocessor, or alternatively, a processor similar to a conventional processor, a controller, a microcontroller, or a state machine. Each of the general purpose processor or the electrical circuitry can be configured by a digital circuit or can be configured by an analogue circuit. Further, when a technology of making an integrated circuit by a semiconductor manufacturing process is substituted with a technology of making an integrated circuit by using a deposition process or the like, the integrated circuit can be made by the technology.

[0163] Various examples have been described. These and other examples are within the scope of the following claims.

Claims

1. A method for generating a predicted sample value corresponding to a current sample at position (x, y) in a rectangular video block based on planar prediction, the method comprising: Calculate the vertical interpolation value equal to the product of the width W of the rectangular video block and the sum of the first value (H-1-y)*p[x][-1] and the second value (y+1)*p[-1][H]. Calculate the horizontal interpolation value equal to the product of the height H of the rectangular video block and the sum of the third value (W-1-x)*p[-1][y] and the fourth value (x+1)*p[W][-1]; and in p[x][-1] is the sample value of the reconstructed sample located in the adjacent row above the rectangular video block and at the same horizontal position as the current sample. p[-1][H] is the sample value of the reconstructed sample located at the lower left corner of the rectangular video block. p[-1][y] is the sample value of the reconstructed sample located in the adjacent left column of the rectangular video block and having the same vertical position as the current sample. p[W][-1] is the sample value of the reconstructed sample located at the adjacent upper right corner of the rectangular video block. as well as The predicted sample value is equal to the quotient of the following two: (a) the sum of the vertical interpolation value, the horizontal interpolation value, and the product W*H of the width and height of the rectangular video block, and (b) the product 2*W*H of twice the width of the rectangular video block and the height of the rectangular video block.

2. The method as described in claim 1, wherein, The width of the rectangular video block is not equal to the height of the rectangular video block.

3. The method as described in claim 2, wherein, The rectangular video block is a transform block.

4. An apparatus for encoding video data by generating predicted sample values ​​corresponding to a current sample at position (x, y) in a rectangular video block based on planar prediction, the apparatus comprising a memory and one or more processors, the memory storing instructions, the processors being configured to: Calculate the vertical interpolation value equal to the product of the width W of the rectangular video block and the sum of the first value (H-1-y)*p[x][-1] and the second value (y+1)*p[-1][H]. Calculate the horizontal interpolation value equal to the product of the height H of the rectangular video block and the sum of the third value (W-1-x)*p[-1][y] and the fourth value (x+1)*p[W][-1]; and in p[x][-1] is the sample value of the reconstructed sample located in the adjacent row above the rectangular video block and at the same horizontal position as the current sample. p[-1][H] is the sample value of the reconstructed sample located at the lower left corner of the rectangular video block. p[-1][y] is the sample value of the reconstructed sample located in the adjacent left column of the rectangular video block and having the same vertical position as the current sample. p[W][-1] is the sample value of the reconstructed sample located at the adjacent upper right corner of the rectangular video block. as well as The predicted sample value is equal to the quotient of the following two: (a) the sum of the vertical interpolation value, the horizontal interpolation value, and the product W*H of the width and height of the rectangular video block, and (b) the product 2*W*H of twice the width of the rectangular video block and the height of the rectangular video block.

5. The device as claimed in claim 4, wherein, The rectangular video block is a transform block, wherein the width and height of the transform block are not equal.

6. A non-transitory computer-readable storage medium storing instructions that, when executed, cause one or more processors of a device to perform the steps of claim 1.

Images