Decoder-side intra-mode derivation for constructing a most probable modelist in video coding.

Abstract

This invention provides a method and device for encoding / decoding video data to improve coding efficiency. [Solution] A method for decoding video data includes deriving a list of intra-modes using reconstructed samples of adjacent blocks with respect to the current block of video data and decoder-side intra-mode derivation (DIMD), and constructing a most likely mode (MPM) list with respect to the current block. Herein, constructing the MPM list comprises inserting at least one intra-mode from the derived list of intra-modes into the MPM list. The method also includes predicting the current block using a candidate selected from the constructed MPM list.

Description

Technical Field

[0001]

[0001] This application claims priority to U.S. Patent Application No. 17 / 502,875, filed Oct. 15, 2021, and U.S. Provisional Application No. 63 / 129,004, filed Dec. 22, 2020, the entire contents of which are hereby incorporated by reference. U.S. Patent Application No. 17 / 502,875, filed Oct. 15, 2021, claims the benefit of U.S. Provisional Patent Application No. 63 / 129,004, filed Dec. 22, 2020.

[0002]

[0002] This disclosure relates to video encoding and video decoding.

Background Art

[0003]

[0003] Digital video capabilities can be incorporated into a wide range of devices including digital televisions, digital direct broadcast systems, wireless broadcast systems, personal digital assistants (PDAs), laptop or desktop computers, tablet computers, e-book readers, digital cameras, digital recording devices, digital media players, video gaming devices, video game consoles, cellular phones or satellite radiotelephones, so-called “smartphones,” video teleconferencing devices, video streaming devices, etc. Digital video devices implement video coding techniques such as those described in standards defined by MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264 / MPEG-4, Part 10, Advanced Video Coding (AVC), ITU-T H.265 / High Efficiency Video Coding (HEVC), and extensions to such standards. By implementing such video coding techniques, video devices can transmit, receive, encode, decode, and / or store digital video information more efficiently.

[0004]

[0004] Video coding techniques include spatial (intra-picture) prediction and / or temporal (inter-picture) prediction to reduce or eliminate redundancy inherent in video sequences. In block-based video coding, a video slice (e.g., a video picture or a portion of a video picture) may be divided into video blocks, which may also be called coding tree units (CTUs), coding units (CUs), and / or coding nodes. A video block in an intra-coded (I) slice of a picture is coded using spatial prediction for a reference sample in a neighboring block within the same picture. A video block in an inter-coded (P or B) slice of a picture may use spatial prediction for a reference sample in a neighboring block within the same picture, or temporal prediction for a reference sample in another reference picture. A picture may be called a frame, and a reference picture may be called a reference frame. [Overview of the project]

[0005]

[0005] Generally speaking, this disclosure describes techniques for coding video data using derived intra-mode deviation (DIMD). To perform intra-mode coding without using DIMD, a video coder (e.g., a video encoder and / or video decoder) may construct a list of intra-mode candidates (e.g., a most probable mode (MPM) list) and signal which candidate from the list will be used as the intra-mode for the current block. To perform intra-mode coding with DIMD, a video decoder may implicitly derive the intra-mode for the current block based on reconstructed samples of adjacent blocks and predict the current block based on a mixture of derived intra-modes. A video encoder may determine whether to use DIMD to predict the current block and signal a syntax element indicating whether the current block is predicted using DIMD or a list (e.g., not predicted using DIMD). However, various implementations of DIMD can present various drawbacks. For example, an implementation of DIMD prediction may involve the video encoder determining whether intra-prediction should be performed using a mixture of predictions from multiple DIMD derived modes or from a single mode. Such an implementation may sacrifice robustness, where the optimal prediction mode is one of the DIMD derived modes, but the optimal prediction may come from only a single prediction (as opposed to a mixture of predictions from DIMD derived modes).

[0006]

[0006] According to one or more techniques of the present disclosure, a video coder (e.g., a video encoder and / or video decoder) may include one or more of the DIMD derived modes in a most likely mode (MPM) list as candidate intra-modes. For example, a video coder may derive one or more DIMD modes and perform DIMD mode derivation to include one or more derived DIMD modes in a list of intra-mode candidates. The video coder may signal which candidate from the list will be used as the intra-mode for the current block. For example, if a particular DIMD mode among the DIMD modes included in the list is the best predictive mode, the video encoder may signal that the particular DIMD mode should be used as the intra-mode for the current block. Using a more optimal mode may reduce the number of bits used to represent the video data. Thus, in this way, the techniques of the present disclosure can improve coding efficiency.

[0007]

[0007] In one example, a method for decoding video data includes: deriving a list of intra-modes using reconstructed samples of adjacent blocks with respect to the current block of video data and using DIMD; constructing a most likely mode (MPM) list with respect to the current block, wherein constructing the MPM list includes inserting at least one intra-mode from the derived list of intra-modes into the MPM list; and predicting the current block using a candidate selected from the constructed MPM list.

[0008]

[0008] In another example, the encoding method includes: for the current block of video data and using DIMD to derive a list of intra-modes using reconstructed samples of adjacent blocks; for the current block, constructing an MPM list, wherein constructing the MPM list comprises inserting at least one intra-mode from the derived list of intra-modes into the MPM list; and for the current block, encoding one or more syntax elements that specify the candidate intra-modes.

[0009]

[0009] In another example, a device for decoding video data includes a memory configured to store the video data and one or more processors implemented in the circuit, the one or more processors being configured to derive a list of intra-modes using reconstructed samples of adjacent blocks with respect to the current block of video data and using DIMD, and to predict the current block using a candidate selected from the constructed MPM list, wherein constructing the MPM list comprises inserting at least one intra-mode from the derived list of intra-modes into the MPM list.

[0010]

[0010] In another example, a device for encoding video data includes a memory configured to store video data and one or more processors implemented in the circuit, the one or more processors being configured to: derive a list of intra-modes using reconstructed samples of adjacent blocks for the current block of video data and using DIMD; construct an MPM list for the current block, wherein constructing the MPM list comprises inserting at least one intra-mode from the derived list of intra-modes into the MPM list; and encode one or more syntax elements for the current block that specify a candidate intra-mode.

[0011]

[0011] Details of one or more examples are described in the accompanying drawings and the following description. Other features, purposes, and advantages will become apparent from the description, drawings, and claims. [Brief explanation of the drawing]

[0012] [Figure 1]

[0012] A block diagram showing an exemplary video coding and decoding system capable of implementing the techniques of the present disclosure. [Figure 2A]

[0013] A conceptual diagram illustrating an exemplary quad-tree binary tree (QTBT) structure. [Figure 2B] A conceptual diagram showing the corresponding coding tree unit (CTU). [Figure 3]

[0014] A block diagram showing an exemplary video encoder capable of implementing the techniques of this disclosure. [Figure 4]

[0015] A block diagram illustrating an exemplary video decoder capable of implementing the techniques of this disclosure. [Figure 5]

[0016] A conceptual diagram showing the set of pixels on which a video coder can perform gradient analysis. [Figure 6]

[0017] A graph showing an example of orientation index mapping using horizontal and vertical gradients. [Figure 7]

[0018] A graph showing the selection of the two most possible prediction modes. [Figure 8]

[0019] A conceptual diagram showing an exemplary prediction for the decoder side intra mode derivation (DIMD) mode. [Figure 9A]

[0020] A flowchart showing an exemplary technique for intra-block decoding. [Figure 9B]

[0021] A flowchart showing an exemplary technique for intra-block decoding using DIMD. [Figure 10]

[0022] A flowchart showing an exemplary technique for intra-block decoding using DIMD most probable mode (MPM) list construction according to one or more techniques of the present disclosure. [Figure 11]

[0023] A flowchart showing an exemplary technique for MPM list construction according to one or more techniques of the present disclosure. [Figure 12]

[0024] A flowchart showing an exemplary technique for deriving a list of intra modes by DIMD according to one or more techniques of the present disclosure. [Figure 13]

[0025] A conceptual diagram showing an example of an adjacent block. [Figure 14]

[0026] A flowchart showing an exemplary technique for adding the DIMD derived mode to the MPM list according to one or more techniques of the present disclosure. [Figure 15]

[0027] A flowchart showing an exemplary method for encoding a current block according to the techniques of the present disclosure. [Figure 16]

[0028] A flowchart illustrating an exemplary method for decoding a current block using the technique of the present disclosure. [Figure 17]

[0029] A flowchart illustrating exemplary techniques for encoding video data using DIMD, using one or more techniques of the present disclosure. [Figure 18]

[0030] A flowchart illustrating exemplary techniques for decoding video data using DIMD, using one or more techniques of the present disclosure. [Modes for carrying out the invention]

[0013]

[0031] The video coding standards are ITU-T H.261, ISO / IEC MPEG-1 Visual, ITU-T H.262, or ISO / IEC MPEG-2. Visual, ITU-T H.263, ISO / IEC MPEG-4 Visual (MPEG-4 Part 2), ITU-T H.264 (also known as ISO / IEC MPEG-4 AVC), which includes its Scalable Video Coding (SVC) and Multiview Video Coding (MVC) extensions, ITU-T H.265 (also known as ISO / IEC MPEG-4 HEVC), which has extensions to it, and the Video Coding (VVC) standardization activity (also known as ITU-T H.266).

[0014]

[0032] JVET-L0164 "CE3-related: Decoder-side Intra Mode Derivation" Joint Video Expert Team (JVET) of ITU-T SG16 WP3 and ISO / IEC JTC 1 / SC29 / WG11, 12th Meeting: Macau, China, October 3-12, 2018, Document: (Available at https: / / jvet-experts.org / doc_end_user / documents / 12_Macao / wg11 / JVET-L0164-v2.zip) JVET-L0164, JVET-M0094 "CE3: Decoder-side Intra Mode Derivation (tests 3.1.1, 3.1.2, 3.1.3 and 3.1.4)" ITU-T SG16 WP3 and ISO / IEC JTC Joint Video Expert Team (JVET) with 1 / SC29 / WG11, 13th Meeting: Marrakech, Morocco, January 9-18, 2019, Document: JVET-M0094 (https: / / jvet-experts.org / doc_end_user / documents / 13_Marrakech / wg11 / JVET-M0094-v2.zip), JVET-N0342 "Non-CE3: Decoder-side Intra Mode Derivation with Prediction Fusion" ITU-T SG16 WP3 and ISO / IEC JTC Joint Video Expert Team (JVET) with 1 / SC29 / WG11, 14th Meeting: Geneva, Switzerland, March 19-29, 2019, Document: JVET-N0342 (https: / / jvet-experts.org / doc_end_user / documents / 14_Geneva / wg11 / JVET-N0342-v5.zip), JVET-O0449 "Non-CE3: Decoder-side Intra Mode Derivation with Prediction Fusion Using Planar" ITU-T SG16 WP3 and ISO / IEC JTC The Joint Video Expert Team (JVET) with 1 / SC29 / WG11, at its 15th meeting in Gothenburg, Sweden, July 3-12, 2019, document JVET-O0449 (https: / / jvet-experts.org / doc_end_user / documents / 15_Gothenburg / wg11 / JVET-O0449-v2.zip), proposes decoder-side intra-mode derivation (DIMD) as a coding tool for intra-mode prediction. The difference from existing intra-mode prediction tools is that when DIMD is implemented, the video coder may not explicitly signal the intra-mode. Instead, the video coder may implicitly derive the intra-mode using reconstructed samples from adjacent blocks. The aim is to improve coding efficiency by omitting intra-mode signaling. Note that DIMD may only be applicable to ruma. In Chroma, the classic intracoding mode can be applied.

[0015]

[0033] In some examples, to perform DIMD on the current block, the videocoder may perform a gradient calculation to derive one or more possible modes (e.g., M1 and M2). The videocoder may then use each of the derived one or more possible modes to predict the current block in order to generate an intermediate prediction block and, depending on the intermediate prediction block, generate an output prediction. Details of an exemplary DIMD workflow are as follows:

[0016]

[0034] The videocoder may perform gradient calculations on reconstructed samples of adjacent blocks. To derive an intra prediction mode for a block, the videocoder may select a set of adjacent pixels from adjacent reconstructed lumens, as shown in Figure 5. The videocoder may then apply gradient calculations to the center pixels of any 3x3 windows formed by the set of adjacent pixels. Note that if adjacent pixels are not reconstructed, their gradient value may not be calculated.

[0017]

[0035] The video coder may perform gradient calculations using Sobel filters (indicated as "Mx" and "My"). Dot generation between these two filters and each 3x3 window (indicated as "W") may be performed to derive the horizontal and vertical gradients (indicated as "Gx" and "Gy"), respectively. The following may be examples of such filters.

[0018]

number

[0019]

[0036] A video coder can map gradient values ​​to directions. For example, a video coder can map G x and G yThe intensity (G) and orientation (O) for each window can be derived using this method.

[0020]

number

[0021]

[0037] In some cases, to reduce the computational cost of the arctangent operation ("atan"), the orientation can be represented by an index value (in the range of 2 to 66) using a mapping table "atan", which can be estimated by comparing the mapping table with Gy / Gx, G y / G x If the value is within the range (atan[i], atan[i+1]), the orientation is assigned the value "i". Note that when the intensity G is 0, O is assigned to 0 by default (planar mode). Figure 6 is a graph showing an example of orientation index mapping using horizontal and vertical gradients.

[0022]

[0038] In the example in Figure 6, for a given 3x3 window, it (for example, the index value) satisfies the following:

[0023]

number

[0024]

[0039] The orientation can be mapped to the prediction direction 60.

[0025]

[0040] The videocoder can perform a selection of two most likely modes. The videocoder can accumulate intensity values ​​for each orientation index in all 3x3 windows. The videocoder can select the top two directions with the highest sums as the two most likely modes (the mode with the highest sum is shown as the first mode "M1", and the second highest as the second mode "M2"). Note that if all values ​​are 0, the planar mode is selected. Figure 7 is a graph showing the selection of two most likely prediction modes. In the example in Figure 7, 18 and 24 are the first and second highest sums of amplitude, respectively, so the videocoder can select mode 18 as the first mode M1 and mode 24 as the second mode M2.

[0026]

[0041] A videocoder can perform DIMD predictions. As shown in Figure 8, if the sum of the amplitudes of the second most likely modes is 0 (e.g., Σamplitude[M2]==0), the videocoder can perform a normal intra prediction, which can be performed in mode M1; otherwise, the videocoder can produce an output prediction block as a weighted sum of three prediction blocks (M1, M2, and the planar mode). This is sometimes called performing a mixed prediction (for example, since the modes are mixed to produce a single prediction). As an example, the videocoder may produce weights for each of the prediction blocks (e.g., ω1 for M1, ω2 for M2, and ω3 for the planar mode) according to the following equation:

[0027]

number

[0028]

[0042] The video coder may generate intermediate prediction blocks (e.g., Pred1 for M1, Pred2 for M2, and Pred3 for the planar mode) based on the reference pixels. The video coder may apply weights to the intermediate prediction blocks to generate the output prediction block according to the following formula:

[0029]

number

[0030]

[0043] The video decoder may perform DIMD mode signaling. Figure 9A is a flowchart showing an exemplary intra-coding process for a VVC, and Figure 9B is a modification of the process in Figure 9A when DIMD is involved. As shown in Figure 9B, the video decoder may parse a DIMD flag. If the DIMD flag is true (e.g., has a value of 1), the video decoder may derive an intra-predictive mode and perform prediction as described above. If the DIMD flag is false (e.g., has a value of 0), the video decoder may parse an intra-predictive mode from the bitstream (e.g., build an MPM list and signal an index to the MPM list) and perform prediction accordingly. Thus, in the example in Figure 9B, if the DIMD flag is false, the video decoder may not perform DIMD intra-mode derivation.

[0031]

[0044] The DIMD mechanism described above may present one or more drawbacks. For example, the potential of DIMD may not be fully utilized for several reasons. As an example, DIMD prediction implicitly determines whether the prediction is a mixture of predictions from multiple modes or from a single mode. The DIMD mechanism described above may sacrifice robustness, where the optimal prediction mode is the DIMD derivation mode, but the optimal prediction may be from a single prediction only. As another example, in other cases, the optimal intra-mode intra-mode may differ from the DIMD derivation mode, but the difference is small (one or two index differences). Using normal mode index coding requires more bits, but using the DIMD derivation mode does not lead to the best RD performance.

[0032]

[0045] According to one or more techniques of this disclosure, a video coder (e.g., a video encoder and / or video decoder) may insert a DIMD derived mode into an MPM list. Thus, the video coder may use the DIMD derived mode in the MPM list to code a block for intra-prediction.

[0033]

[0046] Figure 10 is a flowchart illustrating exemplary techniques for intra-block decoding using DIMD most likely mode (MPM) list construction, using one or more techniques of the present disclosure. A comparison between Figure 10 and Figure 9B yields several differences. For example, compared to the JVET DIMD design (Figure 9), a video coder implementing the techniques of the present disclosure (Figure 10) may perform DIMD mode derivation regardless of whether the current block is predicted using DIMD modes, and the derived modes are added to the MPM list (the MPM list construction process is therefore deferred to after the DIMD process).

[0034]

[0047] For blocks with a DIMD flag equal to true, the videocoder may perform DIMD prediction as described above. For blocks with a DIMD flag equal to false, the videocoder typically performs intra prediction and may add the DIMD derivation mode to the MPM list. Thus, the videocoder may use the DIMD derivation mode for predictions for blocks with a DIMD flag equal to true.

[0035]

[0048] By implementing the technique shown in Figure 10, a video coder can further extend the potential of DIMD and contribute to improved coding efficiency. Block can perform normal predictions by using DIMD derivation modes and selecting a DIMD derivation mode (or a DIMD derivation mode with an offset) from the MPM list.

[0036]

[0049] Figure 11 is a flowchart illustrating exemplary techniques for constructing / deriving an MPM list using one or more techniques of the present disclosure. The techniques of Figure 11 may be implemented by a video coder, such as a video encoder 200 and / or video decoder 300.

[0037]

[0050] As shown in Figure 11, in step 1 (1102), the videocoder may derive a list of intra-modes using reconstructed samples of adjacent blocks via DIMD. In step 2 (1104), the videocoder may add predicted modes from adjacent blocks to the MPM list. In step 3 (1106), the videocoder may add the list of intra-modes derived by DIMD to the MPM list. In step 4 (1108), the videocoder may add further candidates to the MPM list using a list of candidates. An exemplary method is to add multiple offsets (in the range of -3 to 3) to all candidates in the list, or to some of the candidates in the list (e.g., the first three candidates). In step 5 (1110), the videocoder may add default intra-modes (modes such as DC, planar, horizontal, vertical, etc.) to the MPM list (e.g., insert

[0051] Therefore, steps 4 and / or 5 in Figure 11 show a step in which the video coder may insert one or more additional intra mode candidates, which may be default candidates, into the MPM list and after at least one intra mode from the derived list of intra modes. Additional or alternative, step 2 may show a step in which the video coder may insert one or more intra mode candidates, which are predicted modes from adjacent blocks of the current block, into the MPM list and before at least one intra mode from the derived list of intra modes.

[0038]

[0052] Figure 12 is a flowchart illustrating exemplary techniques for deriving an intra-mode list by DIMD using one or more techniques of the present disclosure. The technique of Figure 12 may be performed by a video coder, such as a video encoder 200 and / or video decoder 300. The technique of Figure 12 may be an example of step 1(1102) of the technique of Figure 11.

[0039]

[0053] In 1202, the videocoder may calculate the horizontal and vertical gradient values ​​of each window in an adjacent block as Gx and Gy. Figure 5 shows an exemplary window. In 1204, for each set of horizontal and vertical gradient values, the videocoder may derive an intensity value (|Gx|+|Gy|) and an orientation value (Gy / Gx), and map each orientation to an intra-mode within the range of 2 to 66 (an exemplary process is given above). The videocoder may also calculate the intensity value as the sum of the absolute values ​​of the horizontal and vertical gradient values, and the intensity value may also be calculated as the sum of the squares of the horizontal and vertical gradient values. In 1206, for each intra-mode, the videocoder may accumulate its corresponding intensity value. In 1208, the videocoder may classify intra-modes according to their accumulated intensity values ​​from high to low. The DIMD list may be a classified list of intra-modes, or may contain only a portion of the list. The DIMD list can exclude intra-modes with a sum of intensity values ​​equal to 0. The DIMD list can also exclude intra-modes with a sum of intensity values ​​less than a threshold. The size of the list can be 0, 1, 2, or greater. The first candidate may be set to DC or planar mode if the sum of all intensity values ​​is 0.

[0040]

[0054] As shown above in Figure 11, in 1104, the video coder may add the intra-prediction mode of an adjacent block to the MPM list. Illustrative adjacent blocks are the left, top, top-left, top-right, and bottom-left blocks, as shown in Figure 13.

[0041]

[0055] Figure 14 is a flowchart illustrating exemplary techniques for adding a DIMD derivation mode to an MPM list using one or more techniques of the present disclosure. The technique of Figure 14 may be performed by a video coder, such as a video encoder 200 and / or video decoder 300. The technique of Figure 14 may be an example of step 3 of the technique of Figure 11.

[0042]

[0056] In step 1402, the videocoder may add the first candidate (indicated as "M1" as described above) with the highest sum of intensity to the MPM list. In step 1404, the videocoder may determine whether the sum of intensity of the second candidate (indicated as "M2" as described above) is 0. If it is determined to be 0, the second candidate may be skipped; otherwise, step 1406 is performed. In step 1406, the videocoder may add the second candidate to the MPM list.

[0043]

[0057] Some exemplary variations and / or alternative forms are as follows: 1) In 1404, the video coder may determine whether the sum of the intensities of the second candidate is less than a threshold. If it is less than the threshold, the video coder may skip the second candidate; otherwise, the video coder may add the second candidate during MPM list construction. 2) The condition in 1404 may also apply to the first candidate. 3) The order of the techniques in Figure 11 may be interchanged with each other or interleaved. For example, 1106 may be performed before 1104, or the DIMD derivation mode and the intra mode from the adjacent block may be added interleaved. 4) When the coder performs 1104 before 1102, the list of intra-modes derived by DIMD may be pruned by intra-modes from adjacent blocks; for example, if an intra-mode has already been added to the MPM list in 1104, the intra-mode may be skipped when creating the list of intra-modes in the DIMD list. 5) In 4), if an intra-mode has already been added to the MPM list in 1104, modes and offsets equal to the intra-mode (offset values ​​can be -3 to 3) are skipped when creating the list of intra-modes in the DIMD list. 6) The list of intra-modes derived by DIMD may also be classified in a different order (e.g., sum of intensity values ​​from low to high, and retain the last few candidates). 7) Each candidate added to the MPM list may be pruned to avoid duplicate modes being added to the MPM list. 8) A first candidate may be skipped if it is equal to a DC or planar mode.

[0044]

[0058] Some other exemplary variations and / or alternative forms are as follows: 1) The DIMD flag may be signaled after the MPM flag. 2) The DIMD flag may be signaled as one of the MPM indices. 3) There may be only one mode derived by DIMD that is added to the MPM list. 4) There may be three or more modes derived by DIMD that are added to the MPM list. 5) DIMD may also be applied to chroma blocks. 6) DIMD derived modes may also be added to the chroma MPM list. 7) Intra prediction may always use a single prediction mode. 8) In case 7), the DIMD flag may not be signaled. 9) DIMD prediction may use only one mode. 10) DIMD prediction may be a mixed prediction of derived modes and planar modes. 11) DIMD prediction may be a mixed prediction of (one or more) derived modes and DC modes. 12) DIMD may use predicted samples instead of reconstructed samples for mode derivation. 13) If a block is in DIMD mode, its predicted mode derived by DIMD may be used for constructing the MPM list of adjacent blocks. 14) If a block is in DIMD mode, the default mode (DC or Planar) may be used to construct the MPM list for adjacent blocks.

[0045]

[0059] Figure 1 is a block diagram illustrating an exemplary video coding and decoding system 100 capable of implementing the techniques of the present disclosure. The techniques of the present disclosure generally concern coding (encoding and / or decoding) video data. Generally, video data includes any data for processing video. Thus, video data may include raw, unencoded video, encoded video, decoded (e.g., reconstructed) video, and video metadata such as signaling data.

[0046]

[0060] As shown in Figure 1, system 100 includes, in this example, a source device 102 that provides encoded video data to be decoded and displayed by a destination device 116. In particular, the source device 102 provides the video data to the destination device 116 via a computer-readable medium 110. The source device 102 and the destination device 116 may comprise any of a wide range of devices, including desktop computers, notebook (i.e., laptop) computers, mobile devices, tablet computers, set-top boxes, telephone handsets such as smartphones, televisions, cameras, display devices, digital media players, video gaming consoles, video streaming devices, broadcast receiver devices, and the like. In some cases, the source device 102 and the destination device 116 may be equipped for wireless communication and are therefore sometimes referred to as wireless communication devices.

[0047]

[0061] In the example in Figure 1, the source device 102 includes a video source 104, a memory 106, a video encoder 200, and an output interface 108. The destination device 116 includes an input interface 122, a video decoder 300, a memory 120, and a display device 118. According to this disclosure, the video encoder 200 of the source device 102 and the video decoder 300 of the destination device 116 may be configured to apply techniques for intra-mode derivation for the construction of a most probable mode list. Thus, the source device 102 represents an example of a video encoding device, and the destination device 116 represents an example of a video decoding device. In other examples, the source and destination devices may include other components or arrangements. For example, the source device 102 may receive video data from an external video source, such as an external camera. Similarly, the destination device 116 may interface with an external display device rather than including an integrated display device.

[0048]

[0062] The system 100 shown in Figure 1 is merely an example. In general, any digital video coding and / or decoding device may employ techniques for intra-mode derivation to construct a most probable mode list. Source device 102 and destination device 116 are merely examples of coding devices such that source device 102 generates coded video data for transmission to destination device 116. This disclosure refers to a “coding” device as a device that performs coding (encoding and / or decoding) of data. Thus, video encoder 200 and video decoder 300 represent examples of coding devices, in particular, a video encoder and a video decoder, respectively. In some examples, source device 102 and destination device 116 may operate substantially symmetrically such that each of source device 102 and destination device 116 includes video coding components and video decoding components. Thus, system 100 may support one-way or two-way video transmission between source device 102 and destination device 116 for, for example, video streaming, video playback, video broadcasting, or video telephony.

[0049]

[0063] Generally, the video source 104 represents a source of video data (i.e., raw, unencoded video data) and provides the video encoder 200 with a sequence of pictures (also called "frames") of video data, which the video encoder 200 encodes the data for the pictures. The video source 104 of source device 102 may include video capture devices such as a video camera, a video archive containing previously captured raw video, and / or a video feed interface for receiving video from a video content provider. As a further alternative, the video source 104 may generate computer graphics-based data as source video, or a combination of live video, archived video, and computer-generated video. In each case, the video encoder 200 encodes the captured video data, pre-captured video data, or computer-generated video data. The video encoder 200 may rearrange the pictures from the reception order (sometimes called the "display order") to the coding order for encoding. The video encoder 200 may generate a bitstream containing the encoded video data. The source device 102 may then output the encoded video data onto a computer-readable medium 110 via the output interface 108 for reception and / or retrieval by the input interface 122 of the destination device 116, for example.

[0050]

[0064] Memory 106 of source device 102 and memory 120 of destination device 116 represent general-purpose memory. In some examples, memories 106 and 120 may store raw video data, for example, raw video from video source 104, and raw decoded video data from video decoder 300. Additional or alternative, memories 106 and 120 may store, for example, software instructions executable by video encoder 200 and video decoder 300, respectively. Although memories 106 and 120 are shown separately from video encoder 200 and video decoder 300 in this example, it should be understood that video encoder 200 and video decoder 300 may also include internal memory for functionally similar or equivalent purposes. Furthermore, memories 106 and 120 may store encoded video data, for example, output from video encoder 200 and input to video decoder 300. In some examples, portions 106 and 120 of memory may be allocated as one or more video buffers to store, for example, raw decoded and / or encoded video data.

[0051]

[0065] The computer-readable medium 110 may represent any type of medium or device capable of transferring encoded video data from the source device 102 to the destination device 116. For example, the computer-readable medium 110 may represent a communication medium that enables the source device 102 to directly transmit encoded video data to the destination device 116 in real time, for example, over a radio frequency network or a computer-based network. The output interface 108 may modulate the transmission signal containing the encoded video data, and the input interface 122 may demodulate the received transmission signal according to a communication standard such as a wireless communication protocol. The communication medium may comprise any wireless or wired communication medium, such as a radio frequency (RF) spectrum or one or more physical transmission lines. The communication medium may form part of a packet-based network, such as a local area network, a wide area network, or a global network such as the Internet. The communication medium may include routers, switches, base stations, or any other equipment that may be useful in facilitating communication from the source device 102 to the destination device 116.

[0052]

[0066] In some examples, source device 102 may output encoded data to storage device 112 via output interface 108. Similarly, destination device 116 may access encoded data from storage device 112 via input interface 122. Storage device 112 may include any of a variety of distributed or locally accessed data storage media, such as a hard drive, Blu-ray® disc, DVD, CD-ROM, flash memory, volatile or non-volatile memory, or any other suitable digital storage medium for storing encoded video data.

[0053]

[0067] In some examples, the source device 102 may output the encoded video data to a file server 114 or another intermediate storage device capable of storing the encoded video data generated by the source device 102. The destination device 116 may access the stored video data from the file server 114 via streaming or download.

[0054]

[0068] The file server 114 can be any type of server device capable of storing encoded video data and transmitting that encoded video data to the destination device 116. The file server 114 may represent a web server (for example, for a website), a server configured to provide a file transfer protocol service (such as the File Transfer Protocol (FTP) or File Delivery over Unidirectional Transport (FLUTE) protocol), a Content Delivery Network (CDN) device, a Hypertext Transfer Protocol (HTTP) server, a Multimedia Broadcast Multicast Service (MBMS) or Enhanced MBMS (eMBMS) server, and / or a Network Attached Storage (NAS) device. The file server 114 may, in addition or alternatively, implement one or more HTTP streaming protocols, such as Dynamic Adaptive Streaming over HTTP (DASH), HTTP Live Streaming (HLS), Real-Time Streaming Protocol (RTSP), or HTTP Dynamic Streaming.

[0055]

[0069] The destination device 116 may access the encoded video data from the file server 114 through any standard data connection, including an internet connection. This may include wireless channels (e.g., Wi-Fi® connection), wired connections (e.g., digital subscriber line (DSL), cable modem, etc.), or a combination of both, which are suitable for accessing the encoded video data stored in the file server 114. The input interface 122 may be configured to operate according to one or more of the various protocols described above for retrieving or receiving media data from the file server 114, or any other such protocols for retrieving media data.

[0056]

[0070] The output interface 108 and input interface 122 may represent a wireless transmitter / receiver, a modem, a wired networking component (e.g., an Ethernet® card), a wireless communication component operating according to any of the various IEEE 802.11 standards, or other physical components. In examples where the output interface 108 and input interface 122 include wireless components, the output interface 108 and input interface 122 may be configured to transfer data such as encoded video data according to cellular communication standards such as 4G, 4G-LTE® (Long-Term Evolution), LTE Advanced, or 5G. In some examples where the output interface 108 includes a wireless transmitter, the output interface 108 and input interface 122 may be configured to transfer data such as encoded video data according to other wireless standards such as the IEEE 802.11 specification, the IEEE 802.15 specification (e.g., ZigBee®), or the Bluetooth® standard. In some examples, the source device 102 and / or destination device 116 may include their respective system-on-chip (SoC) devices. For example, the source device 102 may include an SoC device for performing functions associated with the video encoder 200 and / or the output interface 108, and the destination device 116 may include an SoC device for performing functions associated with the video decoder 300 and / or the input interface 122.

[0057]

[0071] The techniques of this disclosure can be applied to video coding that supports any of a variety of multimedia applications, such as over-the-air television broadcasting, cable television transmission, satellite television transmission, internet streaming video transmission such as Dynamic Adaptive Streaming over HTTP (DASH), digital video encoded on a data storage medium, decoding of digital video stored on a data storage medium, or other applications.

[0058]

[0072] The input interface 122 of the destination device 116 receives an encoded video bitstream from a computer-readable medium 110 (e.g., a communication medium, a storage device 112, a file server 114, etc.). The encoded video bitstream may include signaling information defined by the video encoder 200, which is also used by the video decoder 300, such as syntax elements having values ​​that describe the characteristics and / or processing of video blocks or other coded units (e.g., slices, pictures, picture groups, sequences, etc.). The display device 118 displays the decoded picture of the decoded video data to the user. The display device 118 may represent any of a variety of display devices, such as a liquid crystal display (LCD), a plasma display, an organic light-emitting diode (OLED) display, or another type of display device.

[0059]

[0073] Although not shown in Figure 1, in some examples, the video encoder 200 and video decoder 300 may be integrated with an audio encoder and / or audio decoder, respectively, and may include a suitable MUX-DEMUX unit or other hardware and / or software to handle multiplexed streams containing both audio and video in a common data stream. Where applicable, the MUX-DEMUX unit may comply with the ITU H.223 Multiplexer Protocol or other protocols such as the User Datagram Protocol (UDP).

[0060]

[0074] The video encoder 200 and video decoder 300 can each be implemented as one or more suitable encoder and / or decoder circuits, or any combination thereof, including one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), discrete logic, software, hardware, firmware, etc. When the technique is partially implemented in software, the device may store instructions for the software in a suitable non-temporary computer-readable medium and execute those instructions in hardware using one or more processors to implement the technique of the Disclosure. Each of the video encoder 200 and video decoder 300 may be comprised of one or more encoders or decoders, any of which may be integrated as part of a composite encoder / decoder (codec) in their respective devices. A device including the video encoder 200 and / or video decoder 300 may comprise an integrated circuit, a microprocessor, and / or a wireless communication device such as a cellular telephone.

[0061]

[0075] The video encoder 200 and video decoder 300 may operate in accordance with video coding standards such as ITU-T H.265, also known as High Efficiency Video Coding (HEVC), or its extensions such as the Multiview and / or Scalable Video Coding Extension. Alternatively, the video encoder 200 and video decoder 300 may operate in accordance with other proprietary or industry standards, such as ITU-T H.266, also known as General Purpose Video Coding (VVC). The draft of the VVC standard is described in Bross et al., "Versatile Video Coding (Draft 10)," JVET-T2001-v2 (hereinafter, "VVC Draft 10"), 20th meeting of the Joint Video Expert Team (JVET) of ITU-T SG16 WP3 and ISO / IEC JTC1 / SC29 / WG11, held remotely from 7-16 October 2020. However, the techniques of this disclosure are not limited to any particular coding standard.

[0062]

[0076] Generally, the video encoder 200 and video decoder 300 may perform block-based coding of pictures. The term “block” generally refers to a structure containing data to be processed (e.g., to be encoded, decoded, or otherwise used in the encoding and / or decoding process). For example, a block may contain a two-dimensional matrix of samples of luminance and / or chrominance data. Generally, the video encoder 200 and video decoder 300 may code video data represented in YUV (e.g., Y, Cb, Cr) format. That is, rather than coding red, green, and blue (RGB) data for the samples of a picture, the video encoder 200 and video decoder 300 may code luminance and chrominance components, where the chrominance component may include both red and blue chrominance components. In some examples, the video encoder 200 converts the received RGB format data to a YUV representation before encoding, and the video decoder 300 converts the YUV representation to RGB format. Alternatively, pre-processing and post-processing units (not shown) may perform these conversions.

[0063]

[0077] This disclosure may refer to coding a picture (e.g., encoding and decoding) to include, in general, the process of encoding or decoding the data of a picture. Similarly, this disclosure may refer to coding a block of a picture to include, for example, the process of encoding or decoding data about a block, for example, predictive and / or residual coding. An encoded video bitstream generally contains a set of values ​​for syntax elements that represent coding decisions (e.g., coding modes) and divisions of the picture into blocks. Thus, references to coding a picture or a block should generally be understood as coding values ​​for the syntax elements that make up the picture or block.

[0064]

[0078] HEVC defines various blocks, including coding units (CUs), prediction units (PUs), and transformation units (TUs). According to HEVC, a video coder (such as video encoder 200) divides the coding tree units (CTUs) into CUs according to a quad-tree structure. That is, the video coder divides the CTUs and CUs into four equal, non-overlapping squares, and each node in the quad-tree has either zero or four child nodes. Nodes without child nodes are sometimes called "leaf nodes," and the CUs of such leaf nodes may contain one or more PUs and / or one or more TUs. The video coder may further divide the PUs and TUs. For example, in HEVC, the residual quad-tree (RQT) represents a division of the TUs. In HEVC, PUs represent intra-predicted data, and TUs represent residual data. Intra-predicted CUs contain intra-predicted information, such as intra-mode indications.

[0065]

[0079] As another example, a video encoder 200 and a video decoder 300 may be configured to operate according to VVC. According to VVC, a video coder (such as the video encoder 200) divides a picture into multiple coding tree units (CTUs). The video encoder 200 may divide the CTUs according to a tree structure, such as a quad-tree binary tree (QTBT) structure or a multi-type tree (MTT) structure. The QTBT structure eliminates the concept of multiple division types, such as the separation between CUs and PUs and TUs in HEVC. The QTBT structure includes two levels: a first level divided according to quad-tree division and a second level divided according to binary tree division. The root node of the QTBT structure corresponds to a CTU. The leaf nodes of the binary tree correspond to coding units (CUs).

[0066]

[0080] In an MTT partitioning structure, blocks can be partitioned using quad-tree (QT) partitions, binary-tree (BT) partitions, and one or more types of triple-tree (TT) (also called terminally-tree (TT)) partitions. A triple-tree or terminally-tree partition is a partition in which a block is split into three sub-blocks. In some examples, a triple-tree or terminally-tree partition divides a block into three sub-blocks without splitting the original block through a center. The partitioning types in an MTT (e.g., QT, BT, and TT) can be symmetric or asymmetric.

[0067]

[0081] In some examples, the video encoder 200 and video decoder 300 may use a single QTBT or MTT structure to represent the luminance component and the chrominance component, respectively, while in other examples, the video encoder 200 and video decoder 300 may use two or more QTBT or MTT structures, such as one QTBT / MTT structure for the luminance component and another QTBT / MTT structure for both chrominance components (or two QTBT / MTT structures for each chrominance component).

[0068]

[0082] The video encoder 200 and video decoder 300 may be configured to use a quad-tree segment, QTBT segment, MTT segment, or other segmentation structure that conforms to HEVC. For illustrative purposes, the description of the techniques of this disclosure is presented in relation to the QTBT segment. However, it should be understood that the techniques of this disclosure may also be applicable to video coders configured to use a quad-tree segment, or similarly other types of segmentation.

[0069]

[0083] In some examples, the CTU includes a coding tree block (CTB) of a lumen sample, two corresponding CTBs of a chroma sample of a picture having three sample arrays, or a CTB of a sample of a monochrome picture, or a picture coded using three separate color planes and syntax structures used to code the sample. The CTB can be an N×N block of samples, for some value N such that the division of components into the CTB is a partition. The components are an array or a single sample from one of three arrays (lumen and two chroma) that constitute the picture in a 4:2:0, 4:2:2, or 4:4:4 color format, or an array or a single sample of an array that constitutes the picture in a monochrome format. In some examples, the coding block is an M×N block of samples, for some values ​​M and N such that the division of the CTB into the coding block is a partition.

[0070]

[0084] Blocks (e.g., CTUs or CUs) can be grouped in various ways within a picture. For example, a brick may refer to a rectangular area of ​​a row of CTUs within a particular tile in a picture. A tile can be a rectangular area of ​​CTUs within a particular tile column and a particular tile row in a picture. A tile column refers to a rectangular area of ​​CTUs having a height equal to the height of the picture and a width specified by a syntax element (e.g., in a picture parameter set). A tile row refers to a rectangular area of ​​CTUs having a height specified by a syntax element (e.g., in a picture parameter set) and a width equal to the width of the picture.

[0071]

[0085] In some examples, a tile may be divided into multiple bricks, each of which may contain one or more CTU rows. A tile that is not divided into multiple bricks may also be called a brick. However, a brick that is a true subset of a tile may not be called a tile.

[0072]

[0086] Bricks within a picture can also be placed within a slice. A slice can be an integer number of bricks in a picture, which may be contained exclusively within a single Network Abstraction Layer (NAL) unit. In some examples, a slice may contain either several complete tiles or just a continuous sequence of complete bricks of a single tile.

[0073]

[0087] This disclosure may use "N×N (NxN)" and "N×N (N by N)" interchangeably to refer to the sample dimensions of a block (such as a CU or other video block) with respect to vertical and horizontal dimensions, for example, 16×16 samples or 16×16 samples. Generally, a 16×16 CU has 16 samples vertically (y=16) and 16 samples horizontally (x=16). Similarly, an N×N CU generally has N samples vertically and N samples horizontally, where N represents a non-negative integer. Samples in a CU can be arranged in rows and columns. Furthermore, a CU does not necessarily have to have the same number of samples horizontally as vertically. For example, a CU may have N×M samples, where M is not necessarily equal to N.

[0074]

[0088] The video encoder 200 encodes video data for the CU, representing prediction and / or residual information, as well as other information. The prediction information indicates how the CU should be predicted in order to form a prediction block for the CU. The residual information generally represents the sample-by-sample difference between the CU sample before encoding and the prediction block.

[0075]

[0089] To predict a CU, the video encoder 200 may generally form prediction blocks for the CU through inter-prediction or intra-prediction. Inter-prediction generally refers to predicting the CU from data of a previously coded picture, while intra-prediction generally refers to predicting the CU from data of the same picture that was coded before. To perform inter-prediction, the video encoder 200 may generate prediction blocks using one or more motion vectors. The video encoder 200 may generally perform motion search to identify a reference block that perfectly matches the CU with respect to the difference between the CU and the reference block. The video encoder 200 may compute a difference metric using absolute difference sum (SAD), squared difference sum (SSD), mean absolute difference (MAD), mean squared difference (MSD), or other such difference calculations to determine whether the reference block currently perfectly matches the CU. In some examples, the video encoder 200 may predict the current CU using unidirectional or bidirectional prediction.

[0076]

[0090] Some examples of VVC also offer an affine motion compensation mode, which can be considered an interpredictive mode. In affine motion compensation mode, the video encoder 200 may determine two or more motion vectors representing non-translational motion, such as zooming in or out, rotation, perspective motion, or other anomalous motion types.

[0077]

[0091] To perform intra-prediction, the video encoder 200 may select an intra-prediction mode to generate a prediction block. Several examples of VVCs offer 67 intra-prediction modes, including various directional modes, as well as planar and DC modes. Generally, the video encoder 200 selects an intra-prediction mode that describes adjacent samples to the current block (e.g., a block of CU) from which samples of the current block should be predicted. Such samples could generally be above, to the upper left, or to the left of the current block in the same picture as the current block, assuming the video encoder 200 codes CTU and CU in raster scan order (left to right, top to bottom).

[0078]

[0092] The video encoder 200 encodes data representing the prediction mode for the current block. For example, in interprediction mode, the video encoder 200 may encode data representing which of the various available interprediction modes is used, as well as motion information for the corresponding mode. For example, in unidirectional or bidirectional interprediction, the video encoder 200 may encode motion vectors using advanced motion vector prediction (AMVP) or merge mode. The video encoder 200 may use similar modes to encode motion vectors for affine motion compensation mode.

[0079]

[0093] Following predictions such as intra-prediction or inter-prediction of a block, the video encoder 200 may compute residual data for the block. Residual data, such as residual blocks, represents the sample-by-sample difference between the block and the predicted block for the block, formed using the corresponding prediction mode. The video encoder 200 may apply one or more transformations to the residual blocks to produce data that has been transformed in the transformation region rather than the sample region. For example, the video encoder 200 may apply a discrete cosine transform (DCT), integer transform, wavelet transform, or a conceptually similar transform to the residual video data. Furthermore, following the first transformation, the video encoder 200 may apply a quadratic transform such as a mode-dependent non-separable secondary transform (MDNSST), signal-dependent transform, or Carunen-Löwe ​​transform (KLT). The video encoder 200 produces transformation coefficients following the application of one or more transformations.

[0080]

[0094] As described above, following any transformation to produce the transformation coefficients, the video encoder 200 may perform quantization of the transformation coefficients. Quantization generally refers to the process of further compression in which the transformation coefficients are quantized to reduce the amount of data used to represent them as much as possible. By performing the quantization process, the video encoder 200 may reduce the bit depth associated with some or all of the transformation coefficients. For example, the video encoder 200 may round an n-bit value to an m-bit value during quantization, where n is greater than m. In some examples, to perform quantization, the video encoder 200 may perform a bitwise right shift of the value to be quantized.

[0081]

[0095] Following quantization, the video encoder 200 may scan the transformation coefficients to create a one-dimensional vector from a two-dimensional matrix containing the quantized transformation coefficients. The scan may be designed to place higher-energy (and therefore lower-frequency) transformation coefficients at the beginning of the vector and lower-energy (and therefore higher-frequency) transformation coefficients at the end. In some examples, the video encoder 200 may utilize a predefined scan order to scan the quantized transformation coefficients to create a serialized vector, and then entropy-encode the quantized transformation coefficients of the vector. In other examples, the video encoder 200 may perform adaptive scanning. After scanning the quantized transformation coefficients to form a one-dimensional vector, the video encoder 200 may entropy-encode the one-dimensional vector, for example, according to context-adaptive binary arithmetic coding (CABAC). The video encoder 200 may also entropy-encode values ​​for syntax elements describing metadata associated with the encoded video data for use by the video decoder 300 when decoding the video data.

[0082]

[0096] To perform CABAC, the video encoder 200 may assign a context from the context model to the symbol to be transmitted. The context may relate, for example, to whether the adjacent value of the symbol is zero. Probability decisions may be based on the context assigned to the symbol.

[0083]

[0097] The video encoder 200 may further generate syntax data for the video decoder 300, such as block-based syntax data, picture-based syntax data, and sequence-based syntax data, in other syntax data such as picture headers, block headers, slice headers, or sequence parameter sets (SPS), picture parameter sets (PPS), or video parameter sets (VPS). The video decoder 300 may similarly decode such syntax data to determine how the corresponding video data should be decoded.

[0084]

[0098] In this way, the video encoder 200 can generate a bitstream containing encoded video data, for example, a bitstream containing syntax elements that describe the division of a picture into blocks (e.g., CUs) and predictive and / or residual information about the blocks. Finally, the video decoder 300 can receive the bitstream and decode the encoded video data.

[0085]

[0099] Generally, the video decoder 300 performs the reverse process of what the video encoder 200 did to decode the encoded video data of the bitstream. For example, the video decoder 300 may decode values ​​for syntax elements of the bitstream using CABAC in a substantially similar manner to, but in reverse, the CABAC encoding process of the video encoder 200. The syntax elements may define partitioning information for partitioning a picture into CTUs, and partitions for each CTU, following a corresponding partitioning structure such as a QTBT structure, in order to define the CUs of the CTUs. The syntax elements may further define prediction and residual information for blocks of video data (e.g., CUs).

[0086]

[0100] Residual information may be represented, for example, by quantized transformation coefficients. The video decoder 300 may dequantize and inverse transform the quantized transformation coefficients of a block in order to reconstruct the residual block for the block. The video decoder 300 uses a signaled prediction mode (intra or inter-prediction) and associated prediction information (for example, motion information for inter-prediction) to form a prediction block for the block. The video decoder 300 may then combine the prediction block and the residual block (sample by sample) to reconstruct the original block. The video decoder 300 may perform additional processing, such as performing a deblocking process to reduce visual artifacts along the block boundaries.

[0087]

[0101] According to one or more techniques of this disclosure, a video coder (e.g., a video encoder and / or video decoder) may insert a DIMD derived mode into an MPM list. Thus, the video coder may use the DIMD derived mode in the MPM list to code a block for intra-prediction.

[0088]

[0102] This disclosure may generally refer to “signaling” certain information, such as syntax elements. The term “signaling” may generally refer to the communication of values ​​about syntax elements and / or other data used to decode encoded video data. That is, the video encoder 200 may signal values ​​about syntax elements in the bitstream. Generally, signaling refers to generating values ​​in the bitstream. As described above, the source device 102 may transfer the bitstream to the destination device 116 in substantially real time, or non-real time, such as when storing the syntax elements in the storage device 112 for later retrieval by the destination device 116.

[0089]

[0103] According to one or more techniques of the present disclosure, the encoder 200 and / or decoder 300 may insert one or more derived DIMD modes into the MPM list. For example, the encoder 200 and / or decoder 300 may implement the technique shown in Figure 10.

[0090]

[0104] Figures 2A and 2B are conceptual diagrams showing an exemplary quad-tree binary tree (QTBT) structure 130 and its corresponding coding tree unit (CTU) 132. Solid lines represent quad-tree splitting, and dotted lines represent binary tree splitting. At each split (i.e., non-leaf) node of the binary tree, one flag is signaled to indicate which splitting type (i.e., horizontal or vertical) is used, where in this example, 0 indicates horizontal splitting and 1 indicates vertical splitting. In quad-tree splitting, the quad-tree node splits a block horizontally and vertically into four sub-blocks of equal size, so there is no need to indicate the splitting type. Therefore, the video encoder 200 can encode and the video decoder 300 can decode syntax elements (such as splitting information) for the region tree level (i.e., solid lines) of the QTBT structure 130 and syntax elements (such as splitting information) for the prediction tree level (i.e., dashed lines) of the QTBT structure 130. The video encoder 200 can encode and the video decoder 300 can decode video data such as prediction and transformation data for CUs represented by terminal leaf nodes of the QTBT structure 130.

[0091]

[0105] Generally, the CTU132 in Figure 2B can be associated with parameters that define the size of the blocks corresponding to the nodes of the QTBT structure 130 at the first and second levels. These parameters may include the CTU size (representing the size of the CTU132 in the sample), the minimum quad tree size (MinQTSize, representing the minimum allowable quad tree leaf node size), the maximum binary tree size (MaxBTSize, representing the maximum allowable binary tree root node size), the maximum binary tree depth (MaxBTDepth, representing the maximum allowable binary tree depth), and the minimum binary tree size (MinBTSize, representing the minimum allowable binary tree leaf node size).

[0092]

[0106] The root node of a QTBT structure corresponding to a CTU may have four child nodes at the first level of the QTBT structure, each of which may be subdivided according to a quad-tree partition. That is, a node at the first level is either a leaf node (without child nodes) or has four child nodes. An example of QTBT structure 130 represents a node that includes a parent node and child nodes with solid lines for branching. If the node at the first level is not larger than the maximum allowable binary tree root node size (MaxBTSize), the node may be further subdivided by its respective binary tree. Binary tree splitting of a node may be repeated until the nodes resulting from the split reach the minimum allowable binary tree leaf node size (MinBTSize) or the maximum allowable binary tree depth (MaxBTDepth). An example of QTBT structure 130 represents a node with dashed lines for branching. Binary tree leaf nodes are called coding units (CUs), and CUs are used for prediction (e.g., intra-picture or inter-picture prediction) and transformation without further subdivision. As explained above, CU is sometimes called a "video block" or "block".

[0093]

[0107] In one example of a QTBT partition structure, the CTU size is set to 128×128 (a chroma sample and two corresponding 64×64 chroma samples), MinQTSize is set to 16×16, MaxBTSize is set to 64×64, MinBTSize (for both width and height) is set to 4, and MaxBTDepth is set to 4. The quadtree partition is first applied to the CTU to generate quadtree leaf nodes. Quadtree leaf nodes can have sizes ranging from 16×16 (i.e., MinQTSize) to 128×128 (i.e., CTU size). If a quadtree leaf node is 128×128, the leaf quadtree node is not further split by the binary tree because its size exceeds MaxBTSize (i.e., 64×64 in this example). In other cases, the quadtree leaf node is further partitioned by the binary tree. Therefore, a quad-tree leaf node is also the root node for a binary tree and has a binary tree depth of 0. When the binary tree depth reaches MaxBTDepth (4 in this example), no further splitting is allowed. A binary tree node with a width equal to MinBTSize (4 in this example) implies that no further vertical splitting (i.e., splitting of width) is allowed for that binary tree node. Similarly, a binary tree node with a height equal to MinBTSize implies that no further horizontal splitting (i.e., splitting of height) is allowed for that binary tree node. As mentioned above, leaf nodes of a binary tree are called CUs and are further processed according to prediction and transformation without further division.

[0094]

[0108] Figure 3 is a block diagram illustrating an exemplary video encoder 200 capable of implementing the techniques of this disclosure. Figure 3 is provided for illustrative purposes only and should not be considered to limit the techniques broadly illustrated and described in this disclosure. For illustrative purposes, this disclosure describes the video encoder 200 according to the techniques of VVC (ITU-T H.266 under development) and HEVC (ITU-T H.265). However, the techniques of this disclosure may be implemented by video encoding devices configured to other video coding standards.

[0095]

[0109] In the example shown in Figure 3, the video encoder 200 includes a video data memory 230, a mode selection unit 202, a residual generation unit 204, a conversion processing unit 206, a quantization unit 208, an inverse quantization unit 210, an inverse conversion processing unit 212, a reconstruction unit 214, a filter unit 216, a decoded picture buffer (DPB) 218, and an entropy coding unit 220. Any or all of the video data memory 230, the mode selection unit 202, the residual generation unit 204, the conversion processing unit 206, the quantization unit 208, the inverse quantization unit 210, the inverse conversion processing unit 212, the reconstruction unit 214, the filter unit 216, the DPB 218, and the entropy coding unit 220 may be implemented in one or more processors or processing circuits. For example, a unit of the video encoder 200 may be implemented as one or more circuit or logic elements, as part of a hardware circuit, or as part of a processor, ASIC, or FPGA. Furthermore, the video encoder 200 may include additional or alternative processors or processing circuits to perform these and other functions.

[0096]

[0110] The video data memory 230 can store video data to be encoded by the components of the video encoder 200. The video encoder 200 can receive video data to be stored in the video data memory 230 from, for example, a video source 104 (Figure 1). The DPB 218 can act as a reference picture memory that stores reference video data for use in predicting subsequent video data by the video encoder 200. The video data memory 230 and the DPB 218 can be formed by any of various memory devices, including DRAM (SDRAM), magnetoresistive RAM (MRAM), resistive RAM (RRAM®), or other types of memory devices. The video data memory 230 and the DPB 218 can be provided by the same memory device or by separate memory devices. In various examples, the video data memory 230 may be on-chip with the other components of the video encoder 200, as shown in the figure, or off-chip relative to those components.

[0097]

[0111] In this disclosure, references to video data memory 230 should not be interpreted as being limited to memory inside the video encoder 200 unless specifically described so, nor should they be interpreted as being limited to memory outside the video encoder 200 unless specifically described so. Rather, references to video data memory 230 should be understood as reference memory that stores video data received by the video encoder 200 for encoding (e.g., video data for the current block to be encoded). Memory 106 in Figure 1 may also provide temporary storage for outputs from various units of the video encoder 200.

[0098]

[0112] The various units in Figure 3 are shown to help understand the operations performed by the video encoder 200. The units may be implemented as fixed-function circuits, programmable circuits, or a combination thereof. Fixed-function circuits refer to circuits that provide a specific function and are preset in terms of the operations they may perform. Programmable circuits refer to circuits that can be programmed to perform various tasks and to provide flexible functionality in the operations they may perform. For example, a programmable circuit may execute software or firmware that operates the programmable circuit in a manner defined by software or firmware instructions. Fixed-function circuits may execute software instructions (e.g., to receive or output parameters), but the type of operation performed by a fixed-function circuit is generally immutable. In some examples, one or more of the units may be separate circuit blocks (fixed-function or programmable), and in some examples, one or more of the units may be integrated circuits.

[0099]

[0113] The video encoder 200 may include a programmable core formed from an arithmetic logic unit (ALU), an EFU, digital circuits, analog circuits, and / or programmable circuits. In an example where the operation of the video encoder 200 is carried out using software executed by the programmable circuits, memory 106 (Figure 1) may store software instructions (e.g., object code) that the video encoder 200 receives and executes, or another memory (not shown) within the video encoder 200 may store such instructions.

[0100]

[0114] The video data memory 230 is configured to store the received video data. The video encoder 200 can retrieve a picture of the video data from the video data memory 230 and provide the video data to the residual generation unit 204 and the mode selection unit 202. The video data in the video data memory 230 may be raw video data to be encoded.

[0101]

[0115] The mode selection unit 202 includes a motion estimation unit 222, a motion compensation unit 224, and an intra-prediction unit 226. The mode selection unit 202 may include additional functional units for performing video prediction according to other prediction modes. For example, the mode selection unit 202 may include a pallet unit, an intra-block copy unit (which may be part of the motion estimation unit 222 and / or the motion compensation unit 224), an affine unit, a linear model (LM) unit, and the like.

[0102]

[0116] The mode selection unit 202 generally coordinates multiple coding paths to test combinations of coding parameters and the resulting rate-distortion values ​​for such combinations. The coding parameters may include the division of the CTU to the CU, the prediction mode for the CU, the transformation type for the residual data of the CU, and the quantization parameters for the residual data of the CU. The mode selection unit 202 may ultimately select a combination of coding parameters that has a better rate-distortion value than other tested combinations.

[0103]

[0117] The video encoder 200 divides the picture retrieved from the video data memory 230 into a series of CTUs, and may encapsulate one or more CTUs within a slice. The mode selection unit 202 may divide the CTUs of a picture according to a tree structure, such as the HEVC QTBT structure or quad-tree structure described above. As described above, the video encoder 200 may form one or more CUs from dividing the CTUs according to a tree structure. Such CUs are sometimes generally referred to as “video blocks” or “blocks”.

[0104]

[0118] In general, the mode selection unit 202 also controls its components (e.g., motion estimation unit 222, motion compensation unit 224, and intra-prediction unit 226) to generate a predicted block for the current block (e.g., the current CU, or in HEVC, the overlapping portion of PU and TU). For intra-prediction of the current block, the motion estimation unit 222 may perform a motion search to identify one or more perfectly matching reference blocks in one or more reference pictures (e.g., one or more previously coded pictures stored in the DPB 218). In particular, the motion estimation unit 222 may calculate a value representing how similar the potential reference blocks are to the current block, for example, according to the sum of absolute differences (SAD), sum of squared differences (SSD), mean absolute difference (MAD), mean squared difference (MSD), etc. The motion estimation unit 222 may generally perform these calculations using sample-by-sample differences between the current block and the reference blocks under consideration. The motion estimation unit 222 can identify the reference block with the lowest value obtained from these calculations, which indicates the reference block that best matches the current block.

[0105]

[0119] The motion estimation unit 222 may form one or more motion vectors (MVs) that define the position of a reference block in a reference picture relative to the position of a current block in the current picture. The motion estimation unit 222 may then provide the motion vectors to the motion compensation unit 224. For example, in unidirectional interpretation, the motion estimation unit 222 may provide a single motion vector, while in bidirectional interpretation, the motion estimation unit 222 may provide two motion vectors. The motion compensation unit 224 may then use the motion vectors to generate predicted blocks. For example, the motion compensation unit 224 may use the motion vectors to extract data for a reference block. As another example, if the motion vectors have partial sample accuracy, the motion compensation unit 224 may interpolate values ​​for the predicted block according to one or more interpolation filters. Furthermore, in bidirectional interpretation, the motion compensation unit 224 may extract data for the two reference blocks identified by each motion vector and combine the extracted data, for example, through sample-wise averaging or weighted averaging.

[0106]

[0120] As another example, for intra-prediction, or intra-prediction coding, the intra-prediction unit 226 may generate a prediction block from samples adjacent to the current block. For example, in directional mode, the intra-prediction unit 226 may mathematically combine the values ​​of adjacent samples to produce a prediction block and populate these calculated values ​​in a direction defined across the current block. As another example, in DC mode, the intra-prediction unit 226 may calculate the average of adjacent samples relative to the current block and generate a prediction block so that each sample of the prediction block contains this obtained average.

[0107]

[0121] The mode selection unit 202 provides the prediction block to the residual generation unit 204. The residual generation unit 204 receives the raw, unencoded version of the current block from the video data memory 230 and the prediction block from the mode selection unit 202. The residual generation unit 204 calculates the sample-by-sample difference between the current block and the prediction block. The resulting sample-by-sample difference defines the residual block for the current block. In some examples, the residual generation unit 204 may also determine the difference between sample values ​​in the residual block in order to generate the residual block using residual difference pulse code modulation (RDPCM). In some examples, the residual generation unit 204 may be formed using one or more subtractor circuits that perform binary subtraction.

[0108]

[0122] In an example where the mode selection unit 202 divides a CU into PUs, each PU may be associated with a lumar prediction unit and a corresponding chroma prediction unit. The video encoder 200 and video decoder 300 may support PUs of various sizes. As shown above, the size of a CU may refer to the size of the lumar coding block of the CU, and the size of a PU may refer to the size of the lumar prediction unit of the PU. Assuming that the size of a particular CU is 2N×2N, the video encoder 200 may support 2N×2N or N×N PU sizes for intra-prediction and symmetric PU sizes of 2N×2N, 2N×N, N×2N, N×N, or similar for inter-prediction. The video encoder 200 and video decoder 300 may also support asymmetric divisions for PU sizes of 2N×nU, 2N×nD, nL×2N, and nR×2N for inter-prediction.

[0109]

[0123] In an example where the mode selection unit 202 does not further subdivide the CUs into PUs, each CU may be associated with a ruma coding block and a corresponding chroma coding block. As described above, the size of a CU may refer to the size of the ruma coding block of the CU. The video encoder 200 and video decoder 300 may support CU sizes of 2N×2N, 2N×N, or N×2N.

[0110]

[0124] In some examples, such as intra-block copy mode coding, affine mode coding, and linear model (LM) mode coding, the mode selection unit 202 generates a predicted block for the current block being coded via the respective unit associated with the coding technique. In some examples, such as palette mode coding, the mode selection unit 202 may not generate a predicted block, but instead generate syntax elements indicating the mode in which the block should be reconstructed based on the selected palette. In such modes, the mode selection unit 202 may provide these syntax elements to be coded to the entropy coding unit 220.

[0111]

[0125] As described above, the residual generation unit 204 receives video data for the current block and the corresponding predicted block. The residual generation unit 204 then generates a residual block for the current block. To generate the residual block, the residual generation unit 204 calculates the sample-by-sample difference between the predicted block and the current block.

[0112]

[0126] The transformation processing unit 206 applies one or more transformations to the residual block to generate blocks of transformation coefficients (referred to herein as “transformation coefficient blocks”). The transformation processing unit 206 may apply various transformations to the residual block to form the transformation coefficient blocks. For example, the transformation processing unit 206 may apply a discrete cosine transform (DCT), a directional transform, a Carunenlebe transform (KLT), or a conceptually similar transform to the residual block. In some examples, the transformation processing unit 206 may perform multiple transformations on the residual block, such as linear and quadratic transformations, such as a rotation transform. In some examples, the transformation processing unit 206 does not apply any transformations to the residual block.

[0113]

[0127] The quantization unit 208 may quantize the transformation coefficients in a transformation coefficient block to produce a quantized transformation coefficient block. The quantization unit 208 may quantize the transformation coefficients of a transformation coefficient block according to a quantization parameter (QP) value associated with the current block. The video encoder 200 may adjust the degree of quantization applied to the transformation coefficient block associated with the current block by adjusting the QP value associated with the CU (for example, via the mode selection unit 202). Quantization may result in a loss of information, and therefore the quantized transformation coefficients may have lower precision than the original transformation coefficients produced by the transformation processing unit 206.

[0114]

[0128] The inverse quantization unit 210 and the inverse transform processing unit 212 may apply inverse quantization and inverse transform, respectively, to the quantized transform coefficient block in order to reconstruct the residual block from the transform coefficient block. The reconstruction unit 214 may produce a reconstructed block corresponding to the current block (potentially with some distortion) based on the reconstructed residual block and the predicted block generated by the mode selection unit 202. For example, the reconstruction unit 214 may add samples from the reconstructed residual block to the corresponding samples from the predicted block generated by the mode selection unit 202 in order to produce the reconstructed block.

[0115]

[0129] The filter unit 216 may perform one or more filtering operations on the reconstructed block. For example, the filter unit 216 may perform a deblocking operation to reduce blocking artifacts along the edges of the CU. In some examples, the operation of the filter unit 216 may be skipped.

[0116]

[0130] The video encoder 200 stores the reconstructed blocks in the DPB 218. For example, in an example where the filter unit 216 does not operate, the reconstruction unit 214 may store the reconstructed blocks in the DPB 218. In an example where the filter unit 216 operates, the filter unit 216 may store the filtered reconstructed blocks in the DPB 218. The motion estimation unit 222 and the motion compensation unit 224 may retrieve a reference picture formed from the reconstructed (and potentially filtered) blocks from the DPB 218 to interpret blocks of the picture to be encoded later. Furthermore, the intraprediction unit 226 may use the reconstructed blocks in the DPB 218 of the current picture to intrapret other blocks in the current picture.

[0117]

[0131] In general, the entropy coding unit 220 can entropy code syntax elements received from other functional components of the video encoder 200. For example, the entropy coding unit 220 can entropy code quantized transformation coefficient blocks from the quantization unit 208. As another example, the entropy coding unit 220 can entropy code prediction syntax elements from the mode selection unit 202 (e.g., motion information for inter-prediction, or intra-mode information for intra-prediction). The entropy coding unit 220 can perform one or more entropy coding operations on syntax elements, which are another example of video data, to generate entropy-coded data. For example, the entropy coding unit 220 may perform context-adaptive variable-length coding (CAVLC) operation, CABAC operation, variable-to-variable (V2V) length coding operation, syntax-based context-adaptive binary arithmetic coding (SBAC) operation, probability interval partitioned entropy (PIPE) coding operation, exponential Golomb coding operation, or another type of entropy coding operation on the data. In some examples, the entropy coding unit 220 may operate in a bypass mode in which syntax elements are not entropically coded.

[0118]

[0132] The video encoder 200 may output a bitstream containing entropy-encoded syntax elements necessary for reconstructing slices or blocks of pictures. In particular, the entropy encoding unit 220 may output a bitstream.

[0119]

[0133] The behavior described above is described in relation to blocks. Such descriptions should be understood as behavior for rumacoding blocks and / or chromacoding blocks. As described above, in some examples, the rumacoding block and chromacoding block are the ruma and chroma components of the CU. In some examples, the rumacoding block and chromacoding block are the ruma and chroma components of the PU.

[0120]

[0134] In some cases, actions performed for a rumacoding block do not need to be repeated for a chromacoding block. For example, actions to identify the motion vector (MV) and reference picture for a rumacoding block do not need to be repeated to identify the MV and reference picture for a chromablock. Rather, the MV for the rumacoding block may be scaled to determine the MV for the chromablock, and the reference picture may be the same. In another example, an intra-prediction process may be the same for both rumacoding and chromacoding blocks.

[0121]

[0135] The video encoder 200 represents an example of a device configured to encode video data, comprising a memory configured to store video data and one or more processing units implemented in the circuit, the one or more processing units configured to: derive a list of intra-modes using reconstructed samples of adjacent blocks for the current block of video data and using decoder-side intra-mode derivation (DIMD); construct a most likely mode (MPM) list for the current block that includes at least one intra-mode from the derived list of intra-modes; and predict the current block using a candidate selected from the constructed MPM list.

[0122]

[0136] Figure 4 is a block diagram showing an exemplary video decoder 300 capable of implementing the techniques of this disclosure. Figure 4 is provided for illustrative purposes only and is not intended to limit the techniques broadly illustrated and described in this disclosure. For illustrative purposes, this disclosure describes the video decoder 300 according to the techniques of VVC (ITU-T H.266 under development) and HEVC (ITU-T H.265). However, the techniques of this disclosure may be implemented by video coding devices configured to other video coding standards.

[0123]

[0137] In the example in Figure 4, the video decoder 300 includes a coded picture buffer (CPB) memory 320, an entropy decoding unit 302, a prediction processing unit 304, an inverse quantization unit 306, an inverse transformation processing unit 308, a reconstruction unit 310, a filter unit 312, and a decoded picture buffer (DPB) 314. Any or all of the CPB memory 320, the entropy decoding unit 302, the prediction processing unit 304, the inverse quantization unit 306, the inverse transformation processing unit 308, the reconstruction unit 310, the filter unit 312, and the DPB 314 may be implemented in one or more processors or processing circuits. For example, the units of the video decoder 300 may be implemented as one or more circuits or logic elements, as part of a hardware circuit, or as part of a processor, ASIC, or FPGA. Furthermore, the video decoder 300 may include additional or alternative processors or processing circuits to perform these and other functions.

[0124]

[0138] The prediction processing unit 304 includes a motion compensation unit 316 and an intra-prediction unit 318. The prediction processing unit 304 may include additional units for performing predictions according to other prediction modes. For example, the prediction processing unit 304 may include a pallet unit, an intra-block copy unit (which may form part of the motion compensation unit 316), an affine unit, a linear model (LM) unit, and the like. In other examples, the video decoder 300 may include more, fewer, or different functional components.

[0125]

[0139] The CPB memory 320 can store video data, such as an encoded video bitstream, to be decoded by the components of the video decoder 300. The video data stored in the CPB memory 320 may be obtained, for example, from a computer-readable medium 110 (Figure 1). The CPB memory 320 may include a CPB that stores encoded video data (e.g., syntax elements) from the encoded video bitstream. The CPB memory 320 may also store video data other than syntax elements of the coded picture, such as temporary data representing outputs from various units of the video decoder 300. The DPB 314 generally stores the decoded picture, which the video decoder 300 may output and / or use as reference video data when decoding subsequent data or pictures from the encoded video bitstream. The CPB memory 320 and DPB 314 may be formed by any of various memory devices, such as DRAM, MRAM, RRAM, or other types of memory devices, including SDRAM. The CPB memory 320 and DPB 314 may be provided by the same memory device or by separate memory devices. In various examples, the CPB memory 320 may be on-chip with the other components of the video decoder 300, or off-chip relative to those components.

[0126]

[0140] As an addition or alternative, in some examples, the video decoder 300 may retrieve coded video data from memory 120 (Figure 1). That is, memory 120 may store data together with CPB memory 320 as described above. Similarly, memory 120 may store instructions to be executed by the video decoder 300 when some or all of the functions of the video decoder 300 are implemented in software to be executed by the processing circuit of the video decoder 300.

[0127]

[0141] The various units shown in Figure 4 are presented to help understand the operations performed by the video decoder 300. The units can be implemented as fixed-function circuits, programmable circuits, or a combination thereof. Similar to Figure 3, fixed-function circuits refer to circuits that provide a specific function and are preset in terms of the operations they can perform. Programmable circuits refer to circuits that can be programmed to perform various tasks and to provide flexible functionality in the operations they can perform. For example, a programmable circuit may execute software or firmware that operates the programmable circuit in a manner defined by software or firmware instructions. Fixed-function circuits may execute software instructions (e.g., to receive or output parameters), but the type of operation performed by a fixed-function circuit is generally immutable. In some examples, one or more of the units may be separate circuit blocks (fixed-function or programmable), and in some examples, one or more of the units may be integrated circuits.

[0128]

[0142] The video decoder 300 may include a programmable core formed from an ALU, EFU, digital circuitry, analog circuitry, and / or programmable circuitry. In an example where the operation of the video decoder 300 is performed by software running on the programmable circuitry, on-chip or off-chip memory may store software instructions (e.g., object code) that the video decoder 300 receives and executes.

[0129]

[0143] The entropy decoding unit 302 can receive encoded video data from the CPB and entropy decode the video data to reconstruct the syntax elements. The prediction processing unit 304, the inverse quantization unit 306, the inverse transformation processing unit 308, the reconstruction unit 310, and the filter unit 312 can generate the decoded video data based on the syntax elements extracted from the bitstream.

[0130]

[0144] Generally, the video decoder 300 reconstructs the picture block by block. The video decoder 300 can perform the reconstruction operation individually for each block (where the block currently being reconstructed, i.e., decoded, is sometimes called the "current block").

[0131]

[0145] The entropy decoding unit 302 can entropy decode transformation information such as syntax elements that define the quantized transformation coefficients of a quantized transformation coefficient block, as well as quantization parameters (QP) and / or (one or more) transformation mode indications. The inverse quantization unit 306 may use the QP associated with the quantized transformation coefficient block to determine the degree of quantization and, similarly, the degree of inverse quantization that the inverse quantization unit 306 should apply. The inverse quantization unit 306 may perform, for example, a bitwise left shift operation to inverse quantize the quantized transformation coefficients. The inverse quantization unit 306 may thereby form a transformation coefficient block containing the transformation coefficients.

[0132]

[0146] After the inverse quantization unit 306 has formed a transformation coefficient block, the inverse transformation processing unit 308 may apply one or more inverse transformations to the transformation coefficient block to generate a residual block associated with the current block. For example, the inverse transformation processing unit 308 may apply an inverse DCT, an inverse integer transformation, an inverse Carunenlebe transformation (KLT), an inverse rotation transformation, an inverse direction transformation, or another inverse transformation to the transformation coefficient block.

[0133]

[0147] Furthermore, the prediction processing unit 304 generates prediction blocks according to prediction information syntax elements entropy-decoded by the entropy decoding unit 302. For example, if the prediction information syntax elements indicate that the current block is interpredicted, the motion compensation unit 316 may generate prediction blocks. In this case, the prediction information syntax elements may indicate a reference picture in the DPB 314 from which the reference block should be extracted, as well as a motion vector identifying the location of the reference block in the reference picture relative to the location of the current block in the current picture. The motion compensation unit 316 may generally perform the interprediction process in a manner substantially similar to that described with respect to the motion compensation unit 224 (Figure 3).

[0134]

[0148] As another example, if the prediction information syntax element indicates that the current block is intra-predicted, the intra-prediction unit 318 may generate a predicted block according to the intra-prediction mode indicated by the prediction information syntax element. In this case as well, the intra-prediction unit 318 may perform the intra-prediction process in a manner that is generally substantially the same as that described with respect to the intra-prediction unit 226 (Figure 3). The intra-prediction unit 318 may retrieve data for adjacent samples for the current block from the DPB 314.

[0135]

[0149] The reconstruction unit 310 may reconstruct the current block using the predicted block and the residual block. For example, the reconstruction unit 310 may add the samples of the residual block to the corresponding samples of the predicted block in order to reconstruct the current block.

[0136]

[0150] The filter unit 312 may perform one or more filtering operations on the reconstructed block. For example, the filter unit 312 may perform a deblocking operation to reduce blocking artifacts along the edges of the reconstructed block. The operations of the filter unit 312 are not necessarily performed in all examples.

[0137]

[0151] The video decoder 300 may store the reconstructed blocks in the DPB 314. For example, in an example where the filter unit 312 does not operate, the reconstruction unit 310 may store the reconstructed blocks in the DPB 314. In an example where the filter unit 312 operates, the filter unit 312 may store the filtered reconstructed blocks in the DPB 314. As described above, the DPB 314 may provide the prediction processing unit 304 with reference information, such as a sample of the current picture for intra-prediction and a previously decoded picture for subsequent motion compensation. Furthermore, the video decoder 300 may output the decoded picture from the DPB 314 (e.g., the decoded video) for subsequent presentation on a display device such as the display device 118 in Figure 1.

[0138]

[0152] In this way, the video decoder 300 represents an example of a video decoding device, which includes a memory configured to store video data and one or more processing units implemented in the circuit, the one or more processing units being configured to: derive a list of intra-modes using reconstructed samples of adjacent blocks for the current block of video data and using decoder-side intra-mode derivation (DIMD); construct a list of most likely modes (MPMs) for the current block that include at least one intra-mode from the derived list of intra-modes; and predict the current block using a candidate selected from the constructed MPM list.

[0139]

[0153] Figure 15 is a flowchart illustrating an exemplary method for encoding a current block using the technique of the present disclosure. A current block may comprise a current CU. While the video encoder 200 (Figures 1 and 3) is described, it should be understood that other devices may be configured to perform a similar method to that shown in Figure 15.

[0140]

[0154] In this example, the video encoder 200 first predicts the current block (350). For example, the video encoder 200 may form a predicted block for the current block. The video encoder 200 may then compute the residual block for the current block (352). To compute the residual block, the video encoder 200 may compute the difference between the original unencoded block and the predicted block for the current block. The video encoder 200 may then transform the residual block and quantize the transformation coefficients of the residual block (354). Next, the video encoder 200 may scan the quantized transformation coefficients of the residual block (356). During or following the scan, the video encoder 200 may entropy encode the transformation coefficients (358). For example, the video encoder 200 may encode the transformation coefficients using CAVLC or CABAC. The video encoder 200 may then output the entropy encoded data of the block (360).

[0141]

[0155] Figure 16 is a flowchart illustrating an exemplary method for decoding the current block of video data using the technique of the present disclosure. The current block may comprise a current CU. While the video decoder 300 (Figures 1 and 4) is described, it should be understood that other devices may be configured to perform a similar method to that shown in Figure 16.

[0142]

[0156] The video decoder 300 may receive entropy-encoded data about the current block, such as entropy-encoded prediction information and entropy-encoded data about the transformation coefficients of the residual block corresponding to the current block (370). The video decoder 300 may entropy-decode the entropy-encoded data to determine the prediction information for the current block and to reconstruct the transformation coefficients of the residual block (372). The video decoder 300 may predict the current block, for example, using an intra-prediction or inter-prediction mode indicated by the prediction information for the current block, in order to compute a prediction block for the current block (374). The video decoder 300 may then back-scan the reconstructed transformation coefficients to create a block of quantized transformation coefficients (376). The video decoder 300 may then inversely quantize the transformation coefficients and apply an inverse transform to the transformation coefficients to create a residual block (378). The video decoder 300 may finally decode the current block by combining the prediction block and the residual block (380).

[0143]

[0157] Figure 17 is a flowchart illustrating exemplary techniques for encoding video data using DIMD, using one or more techniques of the present disclosure. While the video encoder 200 (Figures 1 and 3) is described, it should be understood that other devices may be configured to perform similar methods to those in Figure 17.

[0144]

[0158] The video encoder 200 may derive a list of decoder-side intra-mode derivation (DIMD) intra-modes for the current block of video data using reconstructed samples from adjacent blocks (1702). For example, the intra-prediction unit 226 may derive DIMD intra-modes using the technique described above with reference to Figure 7 to obtain a first DIMD intra-mode M1 and a second DIMD intra-mode M2.

[0145]

[0159] The video encoder 200 can construct a most likely mode (MPM) list for the current block that includes at least one intra-mode from the DIMD mode (1704). For example, the intra-prediction unit 226 can construct an MPM list using the technique described above with reference to Figure 11. The constructed MPM list may include one or both of the first DIMD intra-mode M1 and the second DIMD intra-mode M2.

[0146]

[0160] The video encoder 200 may decide whether to use DIMD to predict the current block (1706). For example, the mode selection unit 202 may perform an analysis to determine the optimal coding mode for the current block (e.g., the coding mode that uses the fewest bits to represent the current block). To determine the optimal coding mode, the mode selection unit 202 may test coding the current block using various modes. If the mode selection unit 202 determines that coding the current block using DIMD is optimal, the mode selection unit 202 may decide not to code the current block using DIMD. Similarly, if the mode selection unit 202 decides to code the current block using one of the derived DIMD modes in the MPM list, the mode selection unit 202 may decide not to code the current block using DIMD.

[0147]

[0161] The video encoder 200 may encode an instruction on whether the current block is predicted using DIMD. For example, the entropy encoding unit 220 may encode a DIMD flag for the current block, having a value that indicates whether DIMD is enabled for the current block of video data. As an example, in response to deciding not to predict the current block using DIMD (the "No" branch of 1706), the video encoder 200 may encode the DIMD flag with a false (e.g., 0) value to indicate that the current block is not predicted using DIMD (1708). As another example, in response to deciding to predict the current block using DIMD (the "Yes" branch of 1706), the video encoder 200 may encode the DIMD flag with a true (e.g., 1) value to indicate that the current block is predicted using DIMD (1714).

[0148]

[0162] The video encoder 200 may encode one or more syntax elements that indicate a selected intra-mode from the MPM list (1710). For example, the entropy encoding unit 220 may encode a syntax element having a value that indicates the index of the selected intra-mode in the MPM list.

[0149]

[0163] In some examples, as described above, the video encoder 200 may include a reconstruction loop in which blocks of video data are reconstructed so that they can be used as a reference when predicting subsequent blocks. For example, if the current block is not predicted using DIMD, the video encoder 200 may predict the current block using a selected intra-mode (1712). For example, the intra-prediction unit 226 may generate a predicted block using samples in the direction specified by the selected intra-mode. In another example, if the current block is predicted using DIMD, the video encoder 200 may predict the current block using DIMD (1716). For example, the intra-prediction unit 226 may predict the current block using the technique described above with reference to Figure 8.

[0150]

[0164] Figure 18 is a flowchart illustrating exemplary techniques for decoding video data using DIMD, using one or more techniques of the present disclosure. While the video decoder 300 (Figures 1 and 4) is described, it should be understood that other devices may be configured to perform a similar method to that shown in Figure 18.

[0151]

[0165] The video decoder 300 may derive a list of decoder-side intra-mode derivation (DIMD) intra-modes for the current block of video data using reconstructed samples from adjacent blocks (1802). For example, the intra-prediction unit 318 may derive DIMD intra-modes using the technique described above with reference to Figure 7 to obtain a first DIMD intra-mode M1 and a second DIMD intra-mode M2.

[0152]

[0166] The video decoder 300 can construct a most likely mode (MPM) list for the current block that includes at least one intra-mode from the DIMD mode (1804). For example, the intra-prediction unit 318 can construct an MPM list using the technique described above with reference to Figure 11. The constructed MPM list may include one or both of the first DIMD intra-mode M1 and the second DIMD intra-mode M2.

[0153]

[0167] The video decoder 300 may decide whether to use DIMD to predict the current block (1806). For example, the entropy decoding unit 302 may decode a DIMD flag for the current block, which has a value indicating whether DIMD is enabled for the current block of video data. Based on the value of the DIMD flag, the intra-prediction unit 318 may decide whether to use DIMD to predict the current block. As an example, if the value of the flag is true (e.g., 1), the intra-prediction unit 318 may decide to use DIMD to predict the current block. As another example, if the value of the flag is false (e.g., 0), the intra-prediction unit 318 may decide not to use DIMD to predict the current block. As described above, in some examples, the video decoder 300 may derive a list of DIMD intra-modes regardless of the value of the DIMD flag.

[0154]

[0168] If the video decoder 300 decides not to use DIMD to predict the current block (the "No" branch of 1806), the entropy decoding unit 302 may decode one or more syntax elements that indicate a selected intra-mode from the MPM list (for example, an index in the MPM list) (1808). For example, the entropy decoding unit 302 may decode the intra_luma_mpm_idx syntax element that specifies the index in the MPM list of the selected intra-mode.

[0155]

[0169] The video decoder 300 may predict the current block using a candidate selected from the constructed MPM list (1810). For example, the intra-prediction unit 318 may generate a predicted block for the current block using an intra-mode selected from the MPM list. The reconstruction unit 310 may combine the predicted block with the residual block (for example, as in 380 in Figure 16).

[0156]

[0170] If the video decoder 300 decides to predict the current block using DIMD (the "Yes" branch in 1806), the entropy decoding unit 302 may predict the current block using DIMD (1812). For example, the intra-prediction unit 318 may predict the current block using the techniques described above, with reference to Figure 8.

[0157]

[0171] The following numbered clauses may illustrate one or more examples of this disclosure.

[0158]

[0172] Clause 1A. A method for decoding video data, the method comprising: deriving a list of intra-modes using reconstructed samples of adjacent blocks with respect to the current block of video data and using decoder-side intra-mode derivation (DIMD); constructing a most likely mode (MPM) list for the current block that includes at least one intra-mode from the derived list of intra-modes; and predicting the current block using a candidate selected from the constructed MPM list.

[0159]

[0173] The method of Clause 1A, wherein deriving a list of intra-modes using DIMD is also deriving a list of intra-modes using DIMD regardless of the value of the DIMD flag.

[0160]

[0174] The method according to Clause 1A or Clause 2A, wherein constructing the MPM list comprises inserting a first candidate from a list of intra-modes derived using DIMD into the MPM list, and selectively inserting a second candidate into the MPM list based on the sum of the intensities of the second candidate from a list of intra-modes derived using DIMD.

[0161]

[0175] Clause 4A. The method of Clause 3A, wherein constructing the MPM list further comprises inserting additional intra-mode candidates in the MPM list and after the first candidate.

[0162]

[0176] Clause 5A. A device for coding video data, wherein the device comprises one or more means for carrying out the method described in any of Clauses 1A to 4A.

[0163]

[0177] Clause 6A. The device described in Clause 5A, wherein one or more means comprises one or more processors implemented in the circuit.

[0164]

[0178] Clause 7A. A device as described in either Clause 5A or 6A, further comprising memory for storing video data.

[0165]

[0179] Clause 8A. A device as described in any of Clauses 5A through 7A, further comprising a display configured to display decoded video data.

[0166]

[0180] Clause 9A. A device as described in any of Clauses 5A through 8A, comprising one or more of the following: a camera, a computer, a mobile device, a broadcast receiver device, or a set-top box.

[0167]

[0181] Clause 10A. A computer-readable storage medium storing instructions, wherein, when the instructions are executed, causes one or more processors to perform the method described in any of Clauses 1A to 4A.

[0168]

[0182] Clause 1B. A method for decoding video data, the method comprising: deriving a list of intra-modes using reconstructed samples of adjacent blocks with respect to the current block of video data and using decoder-side intra-mode derivation (DIMD); constructing a most likely mode (MPM) list with respect to the current block, wherein constructing the MPM list comprises inserting at least one intra-mode from the derived list of intra-modes into the MPM list; and predicting the current block using a candidate selected from the constructed MPM list.

[0169]

[0183] Clause 2B. The method of Clause 1B, further comprising decoding a DIMD flag having a value indicating whether DIMD is enabled for the current block of video data, wherein deriving a list of intra-modes using DIMD is also comprising deriving a list of intra-modes using DIMD regardless of the value of the DIMD flag.

[0170]

[0184] Clause 3B. The method of Clause 1B, wherein inserting at least one intra-mode from the derived list of intra-modes into the MPM list comprises inserting a first candidate from the derived list of intra-modes using DIMD into the MPM list, and selectively inserting a second candidate from the derived list of intra-modes using DIMD into the MPM list.

[0171]

[0185] Clause 4B. The method of Clause 3B, wherein selective insertion of a second candidate is performed by selectively inserting the second candidate into the MPM list based on the sum of the intensities of the second candidate from the intra-mode list derived using DIMD.

[0172]

[0186] Clause 5B. The method of Clause 1B, wherein constructing the MPM list further comprises inserting additional intra-mode candidates into the MPM list and after at least one intra-mode from the derived list of intra-modes.

[0173]

[0187] Clause 6B. The method of Clause 5B, wherein inserting additional intra-mode candidates is further comprising inserting one or more default candidates in the MPM list and after at least one intra-mode from the derived list of intra-modes.

[0174]

[0188] The method of Clause 7B, wherein constructing the MPM list further comprises inserting one or more intra-mode candidates, which are predicted modes from adjacent blocks of the current block, into the MPM list and before at least one intra-mode from the derived list of intra-modes.

[0175]

[0189] Clause 8B. A method for encoding video data, the method comprising: deriving a list of intra-modes using reconstructed samples of adjacent blocks with respect to the current block of video data and using decoder-side intra-mode derivation (DIMD); constructing a most likely mode (MPM) list with respect to the current block, wherein constructing the MPM list comprises inserting into the MPM list at least one intra-mode from a derived list of intra-modes; and selecting a candidate intra-mode from the current block and the MPM list; and encoding one or more syntax elements specifying a candidate intra-mode with respect to the current block.

[0176]

[0190] Clause 9B. The method of Clause 8B, further comprising encoding a DIMD flag having a value indicating whether DIMD is enabled for the current block of video data, wherein deriving a list of intra-modes using DIMD is also comprising deriving a list of intra-modes using DIMD regardless of the value of the DIMD flag.

[0177]

[0191] Clause 10B. The method of Clause 8B, wherein inserting at least one intra-mode from the derived list of intra-modes into the MPM list comprises inserting a first candidate from the derived list of intra-modes using DIMD into the MPM list, and selectively inserting a second candidate from the derived list of intra-modes using DIMD into the MPM list.

[0178]

[0192] Clause 11B. The method of Clause 10B, wherein selective insertion of a second candidate is performed by selectively inserting the second candidate into the MPM list based on the sum of the intensities of the second candidate from the intra-mode list derived using DIMD.

[0179]

[0193] Clause 12B. The method of Clause 8B, wherein constructing the MPM list further comprises inserting additional intra-mode candidates into the MPM list and after at least one intra-mode from the derived list of intra-modes.

[0180]

[0194] Clause 13B. The method of Clause 12B, comprising inserting an additional intra-mode candidate into the MPM list and after at least one intra-mode from the derived list of intra-modes, one or more default candidates.

[0181]

[0195] The method of Clause 12B, wherein constructing the MPM list further comprises inserting one or more intra-mode candidates, which are predicted modes from adjacent blocks of the current block, into the MPM list and before at least one intra-mode from the derived list of intra-modes.

[0182]

[0196] Clause 15B. A device for decoding video data, the device comprising a memory configured to store video data and one or more processors implemented in the circuit, the one or more processors configured to derive a list of intra-modes using reconstructed samples of adjacent blocks with respect to the current block of video data and using decoder-side intra-mode derivation (DIMD); construct a most likely mode (MPM) list with respect to the current block, wherein constructing the MPM list comprises inserting at least one intra-mode from a derived list of intra-modes into the MPM list; and predicting the current block using a candidate selected from the constructed MPM list.

[0183]

[0197] Clause 16B. The device as described in Clause 15B, wherein one or more processors are further configured to decode a DIMD flag having a value indicating whether DIMD is enabled for the current block of video data, and wherein one or more processors are configured to derive a list of intra-modes using DIMD regardless of the value of the DIMD flag in order to derive a list of intra-modes using DIMD.

[0184]

[0198] Clause 17B. The device according to Clause 15B, wherein one or more processors are configured to insert into the MPM list a first candidate from the list of intra-modes derived using DIMD and to selectively insert into the MPM list a second candidate from the list of intra-modes derived using DIMD, in order to insert at least one intra-mode from the derived list of intra-modes into the MPM list.

[0185]

[0199] Clause 18B. The device according to Clause 17B, wherein one or more processors are configured to selectively insert a second candidate into the MPM list based on the sum of the intensities of the second candidate from an intra-mode list derived using DIMD.

[0186]

[0200] Clause 19B. A device as described in Clause 15B, in which one or more processors are configured to insert additional intra-mode candidates into the MPM list and after at least one intra-mode from the derived list of intra-modes.

[0187]

[0201] Clause 20B. The device described in Clause 19B, in which one or more processors are configured to insert one or more default candidates into the MPM list and after at least one intra-mode from the derived list of intra-modes in order to insert additional intra-mode candidates.

[0188]

[0202] Clause 21B. The device according to Clause 19B, wherein one or more processors are configured to insert one or more intra-mode candidates, which are predicted modes from adjacent blocks of the current block, into the MPM list and before at least one intra-mode from the derived list of intra-modes.

[0189]

[0203] Clause 22B. A device for encoding video data, the device comprising a memory configured to store video data and one or more processors implemented in the circuit, the one or more processors configured to derive a list of intra-modes using reconstructed samples of adjacent blocks with respect to the current block of video data and using decoder-side intra-mode derivation (DIMD); construct a most likely mode (MPM) list for the current block, wherein constructing the MPM list comprises inserting at least one intra-mode from a derived list of intra-modes into the MPM list; select a candidate intra-mode for the current block and from the MPM list; and encode one or more syntax elements specifying a candidate intra-mode for the current block.

[0190]

[0204] Clause 23B. The device as described in Clause 22B, wherein one or more processors are further configured to encode a DIMD flag having a value indicating whether DIMD is enabled for the current block of video data, and wherein one or more processors are configured to derive a list of intra-modes using DIMD regardless of the value of the DIMD flag, in order to derive a list of intra-modes using DIMD.

[0191]

[0205] Clause 24B. The device according to Clause 22B, wherein one or more processors are configured to insert into the MPM list a first candidate from the list of intra modes derived using DIMD and to selectively insert into the MPM list a second candidate from the list of intra modes derived using DIMD, in order to insert at least one intra mode from the derived list of intra modes into the MPM list.

[0192]

[0206] Clause 25B. The device according to Clause 24B, wherein one or more processors are configured to selectively insert a second candidate into the MPM list based on the sum of the intensities of the second candidate from an intra-mode list derived using DIMD.

[0193]

[0207] Clause 26B. The device described in Clause 22B, wherein one or more processors are configured to insert additional intra-mode candidates into the MPM list and after at least one intra-mode from the derived list of intra-modes.

[0194]

[0208] Clause 27B. The device described in Clause 26B, wherein one or more processors are configured to insert one or more default candidates into the MPM list and after at least one intra-mode from the derived list of intra-modes in order to insert additional intra-mode candidates.

[0195]

[0209] Clause 28B. The device according to Clause 26B, wherein one or more processors are configured to insert one or more intra-mode candidates, which are predicted modes from adjacent blocks of the current block, into the MPM list and before at least one intra-mode from the derived list of intra-modes.

[0196]

[0210] Clause 1C. A method for decoding video data, the method comprising: deriving a list of intra-modes using reconstructed samples of adjacent blocks with respect to the current block of video data and using decoder-side intra-mode derivation (DIMD); constructing a most likely mode (MPM) list with respect to the current block, wherein constructing the MPM list comprises inserting at least one intra-mode from the derived list of intra-modes into the MPM list; and predicting the current block using a candidate selected from the constructed MPM list.

[0197]

[0211] Clause 2C. The method of Clause 1C, further comprising decoding a DIMD flag having a value indicating whether DIMD is enabled for the current block of video data, wherein deriving a list of intra-modes using DIMD is also comprising deriving a list of intra-modes using DIMD regardless of the value of the DIMD flag.

[0198]

[0212] Clause 3C. The method according to Clause 1C or 2C, wherein inserting at least one intra-mode from the derived list of intra-modes into the MPM list comprises inserting a first candidate from the derived list of intra-modes using DIMD into the MPM list, and selectively inserting a second candidate from the derived list of intra-modes using DIMD into the MPM list.

[0199]

[0213] Clause 4C. The method of Clause 3C, wherein selective insertion of a second candidate comprises selectively inserting a second candidate into the MPM list based on the sum of the intensities of the second candidate from the intra-mode list derived using DIMD.

[0200]

[0214] Clause 5C. The method of any one of Clauses 1C to 4C, wherein constructing the MPM list further comprises inserting additional intra-mode candidates in the MPM list and after at least one intra-mode from the derived list of intra-modes.

[0201]

[0215] Clause 6C. The method of Clause 5C, wherein inserting additional intra-mode candidates comprises inserting one or more default candidates in the MPM list and after at least one intra-mode from the derived list of intra-modes.

[0202]

[0216] The method of Clause 7C, wherein constructing the MPM list further comprises inserting one or more intra-mode candidates, which are predicted modes from adjacent blocks of the current block, into the MPM list and before at least one intra-mode from the derived list of intra-modes.

[0203]

[0217] Clause 8C. A method for encoding video data, the method comprising: deriving a list of intra-modes using reconstructed samples of adjacent blocks with respect to the current block of video data and using decoder-side intra-mode derivation (DIMD); constructing a most likely mode (MPM) list with respect to the current block, wherein constructing the MPM list comprises inserting into the MPM list at least one intra-mode from a derived list of intra-modes; and selecting a candidate intra-mode from the current block and the MPM list; and encoding one or more syntax elements specifying a candidate intra-mode with respect to the current block.

[0204]

[0218] Clause 9C. The method of Clause 8C, further comprising encoding a DIMD flag having a value indicating whether DIMD is enabled for the current block of video data, wherein deriving a list of intra-modes using DIMD is also comprising deriving a list of intra-modes using DIMD regardless of the value of the DIMD flag.

[0205]

[0219] The method according to Clause 10C, wherein inserting at least one intra-mode from a derived list of intra-modes into the MPM list comprises inserting a first candidate from a list of intra-modes derived using DIMD into the MPM list, and selectively inserting a second candidate from a list of intra-modes derived using DIMD into the MPM list.

[0206]

[0220] Clause 11C. The method of Clause 10C, wherein selective insertion of a second candidate comprises selectively inserting a second candidate into the MPM list based on the sum of the intensities of the second candidate from the intra-mode list derived using DIMD.

[0207]

[0221] Clause 12C. The method of any of Clauses 8C to 11C, wherein constructing an MPM list further comprises inserting additional intra-mode candidates in the MPM list and after at least one intra-mode from the derived list of intra-modes.

[0208]

[0222] Clause 13C. The method of Clause 12C, comprising inserting an additional intra-mode candidate into the MPM list and after at least one intra-mode from the derived list of intra-modes, one or more default candidates.

[0209]

[0223] The method of Clause 14C, wherein constructing an MPM list further comprises inserting one or more intramode candidates, which are predicted modes from adjacent blocks of the current block, into the MPM list and before at least one intramode from the derived list of intramodes.

[0210]

[0224] Clause 15C. A device for decoding video data, the device comprising a memory configured to store video data and one or more processors implemented in the circuit, the one or more processors configured to derive a list of intra-modes using reconstructed samples of adjacent blocks with respect to the current block of video data and using decoder-side intra-mode derivation (DIMD); construct a most likely mode (MPM) list with respect to the current block, wherein constructing the MPM list comprises inserting at least one intra-mode from a derived list of intra-modes into the MPM list, and predicting the current block using a candidate selected from the constructed MPM list.

[0211]

[0225] Clause 16C. The device as described in Clause 15C, wherein one or more processors are further configured to decode a DIMD flag having a value indicating whether DIMD is enabled for the current block of video data, and wherein, in order to derive a list of intra-modes using DIMD, one or more processors are configured to derive a list of intra-modes using DIMD regardless of the value of the DIMD flag.

[0212]

[0226] Clause 17C. A device according to Clause 15C or 16C, in which one or more processors are configured to insert into the MPM list a first candidate from the list of intra-modes derived using DIMD and to selectively insert into the MPM list a second candidate from the list of intra-modes derived using DIMD, in order to insert at least one intra-mode from the derived list of intra-modes into the MPM list.

[0213]

[0227] Clause 18C. The device according to Clause 17C, wherein one or more processors are configured to selectively insert a second candidate into the MPM list based on the sum of the intensities of the second candidate from the intra-mode list derived using DIMD.

[0214]

[0228] Clause 19C. A device according to any one of Clauses 15C to 18C, in which one or more processors are configured to insert additional intra-mode candidates into the MPM list and after at least one intra-mode from the derived list of intra-modes.

[0215]

[0229] Clause 20C. A device as described in Clause 19C, in which one or more processors are configured to insert one or more default candidates into the MPM list and after at least one intra-mode from the derived list of intra-modes in order to insert additional intra-mode candidates.

[0216]

[0230] The device described in Clause 21C, wherein one or more processors are configured to insert one or more intra-mode candidates, which are predicted modes from adjacent blocks of the current block, into the MPM list and before at least one intra-mode from the derived list of intra-modes.

[0217]

[0231] Clause 22C. A device for encoding video data, the device comprising a memory configured to store video data and one or more processors implemented in the circuit, the one or more processors configured to derive a list of intra-modes using reconstructed samples of adjacent blocks with respect to the current block of video data and using decoder-side intra-mode derivation (DIMD); construct a most likely mode (MPM) list for the current block, wherein constructing the MPM list comprises inserting at least one intra-mode from a derived list of intra-modes into the MPM list; select a candidate intra-mode for the current block and from the MPM list; and encode one or more syntax elements specifying a candidate intra-mode for the current block.

[0218]

[0232] Clause 23C. The device as described in Clause 22C, wherein one or more processors are further configured to encode a DIMD flag having a value indicating whether DIMD is enabled for the current block of video data, and wherein, in order to derive a list of intra-modes using DIMD, one or more processors are configured to derive a list of intra-modes using DIMD regardless of the value of the DIMD flag.

[0219]

[0233] Clause 24C. A device according to Clause 22C or 23C, in which one or more processors are configured to insert into the MPM list a first candidate from the list of intra-modes derived using DIMD and to selectively insert into the MPM list a second candidate from the list of intra-modes derived using DIMD, in order to insert at least one intra-mode from the derived list of intra-modes into the MPM list.

[0220]

[0234] Clause 25C. The device according to Clause 24C, wherein one or more processors are configured to selectively insert a second candidate into the MPM list based on the sum of the intensities of the second candidate from an intra-mode list derived using DIMD.

[0221]

[0235] Clause 26C. A device according to any one of Clauses 22C to 25C, in which one or more processors are configured to insert additional intra-mode candidates into the MPM list and after at least one intra-mode from the derived list of intra-modes.

[0222]

[0236] Clause 27C. The device described in Clause 26C, wherein one or more processors are configured to insert one or more default candidates into the MPM list and after at least one intra-mode from the derived list of intra-modes in order to insert additional intra-mode candidates.

[0223]

[0237] The device described in Clause 26C or 27C, wherein one or more processors are configured to insert one or more intra-mode candidates, which are predicted modes from adjacent blocks of the current block, into the MPM list and before at least one intra-mode from the derived list of intra-modes.

[0224]

[0238] Clause 1D. A computer-readable storage medium that stores instructions, when executed, causing one or more processors of a video coder to perform the method described in any of Clauses 1C to 7C.

[0225]

[0239] Clause 1E. A computer-readable storage medium that stores instructions, when executed, causing one or more processors of a video coder to perform the method described in any of Clauses 8C to 14C.

[0226]

[0240] It should be noted that, depending on the example, some actions or events of any of the techniques described herein may be performed in different sequences, added, merged, or completely excluded (for example, not all described actions or events are necessarily required for the practice of this technique). Furthermore, in some examples, actions or events may be performed not sequentially, but simultaneously, for example, through multithreading, interrupt handling, or across multiple processors.

[0227]

[0241] In one or more examples, the described functions may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or codes on or transmitted through a computer-readable medium and executed by a hardware-based processing unit. The computer-readable medium may include computer-readable storage media corresponding to tangible media such as data storage media, or communication media including any medium that facilitates the transfer of computer programs from one location to another, for example, according to a communication protocol. Thus, the computer-readable medium may generally correspond to (1) non-transient tangible computer-readable storage media, or (2) communication media such as signals or carrier waves. The data storage medium may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, codes, and / or data structures for implementation of the techniques described herein. A computer program product may include computer-readable media.

[0228]

[0242] As an example, and not an limitation, such computer-readable storage media may include RAM, ROM, EEPROM®, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and can be accessed by a computer. Any connection is also appropriately referred to as computer-readable media. For example, if instructions are transmitted from a website, server or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of media. However, it should be understood that computer-readable storage media and data storage media refer to non-temporary, tangible storage media, rather than connections, carriers, signals, or other temporary media. As used herein, the terms "disk" and "disc" include Compact Disc (CD), LaserDisc® (disc), Optical Disc (disc), Digital Multipurpose Disc (disc) (DVD), Floppy Disk (disk), and Blu-ray Disc (disc), where a disk typically reproduces data magnetically and a disc reproduces data optically using a laser. Any combination of the above should also be included within the scope of computer-readable media.

[0229]

[0243] Instructions may be executed by one or more processors, such as one or more DSPs, general-purpose microprocessors, ASICs, FPGAs, or other equivalent integrated circuits or discrete logic circuits. Therefore, the terms “processor” and “processing circuit” as used herein may refer to any of the above-described structures or any other structure suitable for implementing the techniques described herein. Furthermore, in some embodiments, the functions described herein may be provided within dedicated hardware and / or software modules configured for encoding and decoding, or incorporated into a composite codec. Moreover, the techniques can be adequately implemented in one or more circuits or logic elements.

[0230]

[0244] The techniques of this disclosure can be implemented in a wide variety of devices or apparatus, including wireless handsets, integrated circuits (ICs), or sets of ICs (e.g., chipsets). While various components, modules, or units have been described in this disclosure to highlight the functional aspects of devices configured to implement the disclosed techniques, these components, modules, or units do not necessarily require implementation by different hardware units. Rather, as described above, the various units, along with suitable software and / or firmware, may be combined in a codec hardware unit, including one or more processors described above, or provided by a set of interoperable hardware units.

[0231]

[0245] Various examples were described. These and other examples fall within the scope of the following claims.

Claims

1. A method for decoding video data, wherein the method is Using the current block of video data and decoder-side intra-mode derivation (DIMD), a list of intra-modes is derived using reconstructed samples of adjacent blocks, With respect to the current block, the most likely mode (MPM) list is constructed, and the construction of the MPM list is comprised of inserting at least one intra-mode from the derived list of intra-modes into the MPM list. A method comprising predicting the current block using a candidate selected from the constructed MPM list.

2. The method according to claim 1, further comprising decoding a DIMD flag having a value indicating whether DIMD is enabled for the current block of video data, wherein deriving the intra-mode list using DIMD is comprising deriving the intra-mode list using DIMD regardless of the value of the DIMD flag.

3. Inserting at least one intra-mode from the derived list of intra-modes into the MPM list is Insert into the MPM list a first candidate from the list of intra-modes derived using DIMD, The method according to claim 1, further comprising selectively inserting a second candidate from the list of intra-modes derived using DIMD into the MPM list.

4. The method according to claim 3, wherein selective insertion of the second candidate comprises selectively inserting the second candidate into the MPM list based on the sum of the intensities of the second candidate from the intra-mode list derived using DIMD.

5. Constructing the aforementioned MPM list The method according to claim 1, further comprising inserting additional intramode candidates into the MPM list and after the at least one intramode from the derived list of intramodes.

6. Inserting the aforementioned additional intra-mode candidates The method according to claim 5, further comprising inserting one or more default candidates into the MPM list and after at least one intra-mode from the derived list of intra-modes.

7. Constructing the aforementioned MPM list The method according to claim 5, further comprising inserting one or more intra-mode candidates, which are predicted modes from adjacent blocks of the current block, into the MPM list and before the at least one intra-mode from the derived list of intra-modes.

8. A method for encoding video data, wherein the method is Using the current block of video data and decoder-side intra-mode derivation (DIMD), a list of intra-modes is derived using reconstructed samples of adjacent blocks, With respect to the current block, the most likely mode (MPM) list is constructed, and the construction of the MPM list is comprised of inserting at least one intra-mode from the derived list of intra-modes into the MPM list. Select a candidate intra-mode from the current block and the MPM list. A method comprising encoding one or more syntax elements that specify the candidate intra-mode for the current block.

9. The method of claim 8, further comprising encoding a DIMD flag having a value indicating whether DIMD is enabled for the current block of video data, wherein deriving the intra-mode list using DIMD is equivalent to deriving the intra-mode list using DIMD regardless of the value of the DIMD flag.

10. Inserting at least one intra-mode from the derived list of intra-modes into the MPM list is Insert into the MPM list a first candidate from the list of intra-modes derived using DIMD, The method according to claim 8, further comprising selectively inserting a second candidate from the list of intra-modes derived using DIMD into the MPM list.

11. The method according to claim 10, wherein the selective insertion of the second candidate comprises selectively inserting the second candidate into the MPM list based on the sum of the intensities of the second candidate from the intra-mode list derived using DIMD.

12. Constructing the aforementioned MPM list The method according to claim 8, further comprising inserting additional intramode candidates in the MPM list and after the at least one intramode from the derived list of intramodes.

13. Inserting the aforementioned additional intra-mode candidates The method according to claim 12, further comprising inserting one or more default candidates into the MPM list and after at least one intra-mode from the derived list of intra-modes.

14. Constructing the aforementioned MPM list The method according to claim 12, further comprising inserting one or more intra-mode candidates, which are predicted modes from adjacent blocks of the current block, into the MPM list and before the at least one intra-mode from the derived list of intra-modes.

15. A device for decoding video data, wherein the device is A memory configured to store video data, The circuit comprises one or more processors implemented in the circuit, and the one or more processors are Using the current block of video data and decoder-side intra-mode derivation (DIMD), a list of intra-modes is derived using reconstructed samples of adjacent blocks, With respect to the current block, the most likely mode (MPM) list is constructed, and the construction of the MPM list is comprised of inserting at least one intra-mode from the derived list of intra-modes into the MPM list. A device configured to predict the current block using a candidate selected from the constructed MPM list.

16. The one or more processors described above are The device according to claim 15, further configured to decode a DIMD flag having a value indicating whether DIMD is enabled for the current block of video data, wherein one or more processors are configured to derive the intra-mode list using DIMD regardless of the value of the DIMD flag, in order to derive the intra-mode list using DIMD.

17. In order to insert at least one intra-mode from the derived list of intra-modes into the MPM list, one or more processors Insert into the MPM list a first candidate from the list of intra-modes derived using DIMD, The device according to claim 15, configured to selectively insert into the MPM list a second candidate from the list of intra-modes derived using DIMD.

18. The device according to claim 17, wherein, in order to selectively insert the second candidate, one or more processors are configured to selectively insert the second candidate into the MPM list based on the sum of the intensities of the second candidate from the intra-mode list derived using DIMD.

19. In order to construct the MPM list, one or more processors The device according to claim 15, configured to insert additional intramode candidates into the MPM list and after at least one intramode from the derived list of intramodes.

20. In order to insert the additional intra-mode candidates, one or more processors The device according to claim 19, configured to insert one or more default candidates into the MPM list and after at least one intra-mode from the derived list of intra-modes.

21. In order to construct the MPM list, one or more processors The device according to claim 19, configured to insert one or more intra-mode candidates, which are predicted modes from adjacent blocks of the current block, into the MPM list and before the at least one intra-mode from the derived list of intra-modes.

22. A device for encoding video data, wherein the device is A memory configured to store video data, The circuit comprises one or more processors implemented in the circuit, and the one or more processors are Using the current block of video data and decoder-side intra-mode derivation (DIMD), a list of intra-modes is derived using reconstructed samples of adjacent blocks, With respect to the current block, the most likely mode (MPM) list is constructed, and the construction of the MPM list is comprised of inserting at least one intra-mode from the derived list of intra-modes into the MPM list. Select a candidate intra-mode from the current block and the MPM list. A device configured to encode one or more syntax elements that specify the candidate intra-mode for the current block.

23. The one or more processors described above are The device according to claim 22, further configured to encode a DIMD flag having a value indicating whether DIMD is enabled for the current block of video data, wherein, in order to derive the intra-mode list using DIMD, one or more processors are configured to derive the intra-mode list using DIMD regardless of the value of the DIMD flag.

24. In order to insert at least one intra-mode from the derived list of intra-modes into the MPM list, one or more processors Insert into the MPM list a first candidate from the list of intra-modes derived using DIMD, The device according to claim 22, configured to selectively insert into the MPM list a second candidate from the list of intra-modes derived using DIMD.

25. The device according to claim 24, wherein, in order to selectively insert the second candidate, one or more processors are configured to selectively insert the second candidate into the MPM list based on the sum of the intensities of the second candidate from the intra-mode list derived using DIMD.

26. In order to construct the MPM list, one or more processors The device according to claim 22, configured to insert additional intramode candidates into the MPM list and after at least one intramode from the derived list of intramodes.

27. In order to insert the additional intra-mode candidates, one or more processors The device according to claim 26, configured to insert one or more default candidates into the MPM list and after at least one intra-mode from the derived list of intra-modes.

28. In order to construct the MPM list, one or more processors The device according to claim 26, configured to insert one or more intra-mode candidates, which are predicted modes from adjacent blocks of the current block, into the MPM list and before the at least one intra-mode from the derived list of intra-modes.

Images