DECODER-SIDE INTRA-MODE DERIVATION FOR MOST PROBABLE MODE LIST CONSTRUCTION IN VIDEO CODING

Abstract

A method for decoding video data includes deriving, for a current block of video data and using decoder-side intra-mode derivation (DIMD), a list of intra-modes using reconstructed samples from neighboring blocks; constructing, for the current block, a most probable mode (MPM) list, wherein constructing the MPM list comprises inserting, into the MPM list, at least one intra-mode from the derived list of intra-modes; and predicting, using a selected candidate from the constructed MPM list, the current block.

Description

DECODER-SIDE INTRA-MODE DERIVATION FOR MOST PROBABLE MODE LIST CONSTRUCTION IN VIDEO CODING ah?i nn / cznz / β / υιλι CROSS REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Patent Application No. 17 / 502,875, filed October 15, 2021, and U.S. Provisional Application No. 63 / 129,004, filed December 22, 2020, the full contents of which are incorporated herein by reference. U.S. Patent Application No. 17 / 502,875, filed October 15, 2021, claims the benefit of U.S. Provisional Patent Application No. 63 / 129,004, filed December 22, 2020. FIELD OF INVENTION This disclosure relates to video encoding and video decoding. BACKGROUND OF THE INVENTION 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), laptops or desktop computers, tablet computers, e-book readers, digital cameras, digital recording devices, digital media players, video game devices, video game consoles, cell phones or satellite radios, so-called “smartphones,” videoconferencing devices, video streaming devices, and similar devices. Digital video devices implement video coding techniques, such as those described in the standards defined by MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264 / MPEG-4, Part 10, Advanced Video Coding (AVC), ITU-T H.265 / High Efficiency Video Coding (HEVC), and extensions to these standards.Video devices can transmit, receive, encode, decode and / or store digital video information more efficiently by implementing these video coding techniques. Video coding techniques include spatial (intra-image) and / or temporal (inter-image) prediction to reduce or remove inherent redundancy in video sequences. For block-based video coding, a video segment (e.g., a video frame or a portion of a video frame) can be partitioned into video blocks, which may also be referred to as coding tree units (CTUs), coding units (CUs), and / or coding nodes. Video blocks in an intra-coded (I) segment of an image are encoded using spatial prediction with respect to reference samples in neighboring blocks in the same image. Video blocks in an inter-coded (P or B) segment of an image can use spatial prediction with respect to reference samples in neighboring blocks in the same image or temporal prediction with respect to reference samples in other reference images.Images can be referred to as charts and reference images can be referred to as reference charts. BRIEF DESCRIPTION OF THE INVENTION In general, this disclosure describes techniques for encoding video data using derived intra-mode deviation (DIMD). To perform intra-mode coding without DIMD, a video encoder (e.g., a video encoder and / or video decoder) can construct a list of intra-mode candidates (e.g., a most likely mode (MPM) list) and signal which candidate from the list is used as the intra-mode for the current block. To perform intra-mode coding with DIMD, a video decoder can implicitly derive intra-modes for a current block based on reconstructed samples of neighboring blocks and predict the current block based on a mixture of the derived intra-modes. The video encoder can determine whether to predict the current block using DIMD or not and signal a syntax element indicating whether the current block is predicted using DIMD or predicted using the list (e.g., not predicted using DIMD).However, DIMD implementations can have several disadvantages. For example, DIMD prediction implementations may require a video encoder to determine whether to perform intraprediction using a mixed prediction of multiple DIMD-derived modes or a single mode. These implementations can sacrifice robustness where the optimal prediction mode is one of the DIMD-derived modes, but the optimal prediction might be from a single prediction only (e.g., as opposed to a mixed prediction of the DIMD-derived modes). In accordance with one or more techniques in this disclosure, a video encoder (e.g., a video encoder and / or a video decoder) may include one or more DIMD-derived modes as intra-mode candidates in a most likely mode (MPM) list. For example, the video encoder may perform DIMD mode derivation to derive one or more DIMD modes and include the derived DIMD modes in the intra-mode candidate list. The video encoder may signal which candidate from the list is used as the intra-mode for the current block. For example, if a particular DIMD mode, one of the DIMD modes included in the list, is the optimal prediction mode, the video encoder may signal that the particular DIMD mode is to be used as the intra-mode for the current block. Using more optimal modes can reduce the number of bits used to represent video data.As such, in this way, the techniques of this disclosure can improve coding efficiency. In one example, a video data decoding method includes deriving, for a current block of video data and using DIMD, a list of intra-modes using reconstructed samples from neighboring blocks; constructing, for the current block, a most probable mode (MPM) list, wherein constructing the MPM list comprises inserting, into the MPM list, at least one intra-mode from the derived list of intra-modes; and predicting, using a selected candidate from the constructed MPM list, the current block. In another example, an encoding method includes deriving, for a current block of video data and using DIMD, a list of intra-modes using reconstructed samples from neighboring blocks; constructing, for the current block, a list of MPMs, wherein constructing the list of MPMs comprises inserting, into the list of MPMs, at least one intra-mode from the derived list of intra-modes; selecting, for the current block and from the list of MPMs, a candidate intra-mode; and encoding, for the current block, one or more syntax elements that specify the candidate intra-mode. In another example, a device for decoding video data includes a memory configured to store video data; and one or more processors implemented in circuitry and configured to: derive, for a current block of video data and using DIMD, a list of intra-modes using reconstructed samples from neighboring blocks; construct, for the current block, a list of MPMs, wherein constructing the list of MPMs comprises inserting, into the list of MPMs, at least one intra-mode from the derived list of intra-modes; and predict, using a selected candidate from the constructed list of MPMs, the current block. In another example, a device for encoding video data includes a memory configured to store video data; and one or more processors implemented in circuitry and configured to: derive, for a current block of video data and using DIMD, a list of intra-modes using reconstructed samples from neighboring blocks; construct, for the current block, a list of MPMs, wherein constructing the list of MPMs comprises inserting, into the list of MPMs, at least one intra-mode from the derived list of intra-modes; select, for the current block and from the list of MPMs, a candidate intra-mode; and encode, for the current block, one or more syntax elements specifying the candidate intra-mode. Details of one or more examples are set out in the accompanying drawings and the description below. Other features, objects, and advantages will be evident from the description, drawings, and claims. BRIEF DESCRIPTION OF THE FIGURES FIGURE 1 is a block diagram illustrating an example video encoding and decoding system that can perform the techniques in this disclosure. FIGURES 2A and 2B are conceptual diagrams that illustrate an example quaternary tree binary tree (QTBT) structure, and a corresponding coding tree unit (CTU). FIGURE 3 is a block diagram illustrating an example video encoder that can perform the techniques of this disclosure. FIGURE 4 is a block diagram illustrating an example video decoder that can perform the techniques in this disclosure. FIGURE 5 is a conceptual diagram that illustrates a set of pixels on which a video encoder can perform gradient analysis. ah?i nn / cznz / β / υιλι FIGURE 6 is a graph illustrating an example of orientation index mapping using horizontal and vertical gradient. FIGURE 7 is a graph illustrating a selection of two more possible prediction modes. FIGURE 8 is a conceptual diagram that illustrates an example prediction for the decoder-side intra-mode derivation mode (DIMD). FIGURE 9A is a flowchart of intra-block decoding. FIGURE 9B is a flowchart of intra-block decoding with DIMD. FIGURE 10 is a flowchart illustrating an example technique for intra-block decoding with most likely mode list (MPM) DIMD construction, in accordance with one or more techniques in this disclosure. FIGURE 11 is a flowchart illustrating an example MPM list building technique, in accordance with one or more techniques in this disclosure. FIGURE 12 is a flowchart that illustrates an example technique for deriving an intra-mode list by DIMD, in accordance with one or more techniques in this disclosure. FIGURE 13 is a conceptual diagram that illustrates examples of neighboring blocks. FIGURE 14 is a flowchart illustrating an example technique for adding DIMD-derived modes to an MPM list, in accordance with one or more techniques in this disclosure. FIGURE 15 is a flowchart that illustrates an example method for encoding a current block according to the techniques in this disclosure. FIGURE 16 is a flowchart that illustrates an example method for decoding a current block according to the techniques in this disclosure. FIGURE 17 is a flowchart illustrating an example technique for encoding video data using DIMD, in accordance with one or more techniques in this disclosure. FIGURE 18 is a flowchart illustrating an example technique for decoding video data using DIMD, in accordance with one or more techniques in this disclosure. DETAILED DESCRIPTION OF THE INVENTION Video coding standards include 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), including its Scalable Video Coding (SVC) and Multiview Video Coding (MVC) extensions, ITU-T H.265 (also known as ISO / IEC MPEG-4 HEVC) with its extensions, and Video Coding Standardization Activity (VVC) (also known as ITU-T H.266). En JVET-L0164 “CE3-related: Decoder-side Intra Mode Derivation” Joint Video Experts Team (JVET) de ITU-T SG 16 WP 3 e ISO / IEC JTC 1 / SC 29 / WG 11,12th Meeting: Macao, CN, 3-12 Oct. 2018, Document: JVET-L0164 (disponible en https: / / jvetexperts.org / doc_end_user / documents / 12_Macao / wg11 / JVET-L0164-v2.zip), JVET-M0094 “CE3: Decoder-side Intra Mode Derivation (tests 3.1.1, 3.1.2, 3.1.3 and 3.1.4)” Joint Video Experts Team (JVET) de ITU-T SG 16 WP 3 e ISO / IEC JTC 1 / SC 29 / WG 11, 13th Meeting: Marrakech, MA, 9-18 Jan. 2019, Document: JVET-M0094 (https: / / jvetexperts.org / doc_end_user / documents / 13_Marrakech / wg11 / JVET-M0094-v2.zip), JVET-N0342 “Non-CE3; Decoder-side Intra Mode Derivation with Prediction Fusión” Joint Video Experts Team (JVET) de ITU-T SG 16 WP 3 e ISO / IEC JTC 1 / SC 29 / WG 11,14th Meeting: Geneva, CH, 19-29 March. 2019, Document: JVET-N0342 (https: / / jvetexperts.org / doc_end_user / documents / 14_Geneva / wg11 / JVET-N0342-v5.JVET-O0449 “Non-CE3: Decoder-side Intra-Mode Derivation with Prediction Fusion Using Planar” Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11, 15th Meeting: Gothenburg, SE, 3-12 July 2019, Document: JVET-O0449 (https: / / jvetexperts.org / doc_end_user / documents / 15_Gothenburg / wg11 / JVET-O0449-v2.zip), proposes decoder-side intra-mode derivation (DIMD) as an encoding tool for intraprediction. One difference from existing intraprediction tools is that, when performing DIMD, a video encoder need not explicitly signal intra-mode. Instead, the video encoder can implicitly derive the intra-mode signal using reconstructed samples from neighboring blocks. The purpose is to encode an efficient enhancement by saving intra-mode signaling. Note that DIMD can only be applied to luma. For chroma, the classic intra-mode encoding method can be used. In some examples, to perform DIMD on a current block, a video encoder can perform gradient calculation to derive one or more possible modes (e.g., M1 and M2). The video encoder can then predict the current block using each of the one or more derived possible modes to generate intermediate prediction blocks, and generate an output prediction as a function of the intermediate prediction blocks. Details of an example DIMD workflow are as follows: Qhz / nn / cznz / R / viAi A video encoder can perform gradient calculations on reconstructed samples of neighboring blocks. To derive the intraprediction mode for a block, the video encoder can select a set of neighboring pixels from neighboring reconstructed luma samples, as shown in Figure 5. The video encoder can then apply the gradient calculation to the central pixel of each 3x3 window formed by the set of neighboring pixels. Note that if a neighboring pixel is not reconstructed, its gradient values ​​cannot be calculated. The video encoder can perform gradient calculations using Sobel filters (denoted as “Mx”, “My”). Point generation between these two filters and each 3x3 window (denoted as “W”) can be used to derive horizontal and vertical gradients (denoted as “Gx”, “Gy”), respectively. Examples of these filters include: Mx 11 Γ-1 2 and My= 0 1J 1 —2 -IO 0 1. Gx = Mx*W and Gy = My*W. The video encoder can map gradient values ​​to a direction. For example, the video encoder can derive the intensity (G) and orientation (O) for each window using Gxy Gy: G = |Gx| + |Gy|yO = atan(^) In some examples, 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 an “atan” mapping table, and can be estimated by comparing the mapping table and Gy / Gx; if Gy / Gx falls within the range of (atan[ij, atan[i+1]), the orientation is assigned the value “i”. Note that the intensity G is 0, O is assigned to 0 (flat mode) by default. Figure 6 is a graph illustrating an example of orientation index mapping using horizontal and vertical gradients. In the example in FIGURE 6, for a given 3x3 window, it satisfies (for example, the index value): angTable

[60] <= Gy / Gx< angTable

[61] The orientation can be mapped to the prediction direction 60. The video encoder can select from two additional possible modes. It accumulates the intensity values ​​for each orientation index across all 3x3 windows. The encoder can then select the two highest sums of these values ​​as the two additional possible modes (denoting the highest sum as the first mode “M1” and the second highest as the second mode “M2”). Note that if all values ​​are zero, the flat mode will be selected. Figure 7 illustrates a selection of these two additional possible modes. In the example in Figure 7, the video encoder can select mode 18 in the first mode (M1) and mode 24 in the second mode (M2), as 18 and 24 are, respectively, the first and second highest sums of amplitudes. The video encoder can perform DIMD prediction. As shown in Figure 8, if the sum of amplitudes of the second most likely mode is 0 (for example, if Zamplitude[M2] == 0), the video encoder can perform normal intraprediction with mode M1; otherwise, the video encoder can generate an output prediction block as a weighted sum of three prediction blocks (M1, M2, and flat mode). This can be referred to as performing a blended prediction (for example, as the modes are blended to generate a single prediction). As an example, the video encoder can generate a weight for each of the prediction blocks (for example, ω1 for M1, ω2 for M2, and ω3 for flat mode) according to the following equations: ampl(M..) + ampl(M2) ampf(M2)ω264 + amp / (M2) ω3= — 64 The video encoder can generate intermediate prediction blocks (e.g., Predi for M1, Preda for M2, and Preda for flat mode) based on the reference pixels. The video encoder can apply weights to the intermediate prediction blocks to generate the output prediction block according to the following equation: Qhz / nn / cznz / R / YiAi The video encoder can perform DIMD mode signaling. Figure 9A is a flowchart illustrating an example VVC intra-encoding process, and Figure 9B modifies the process in Figure 9A when DIMD is included. As shown in Figure 9B, a video decoder can analyze a DIMD flag. If the DIMD flag is true (e.g., has a value of 1), the video decoder can derive the intra-prediction modes and perform the prediction as explained above. If the DIMD flag is false (e.g., has a value of 0), the video decoder can analyze the bitstream's intra-prediction mode (e.g., construct a list of MPMs and signal an index in the MPM list) and perform the prediction accordingly. Therefore, in the example in Figure 9B, where the DIMD flag is false, the video decoder may not perform DIMD intra-mode derivation. The DIMD mechanism mentioned above may have one or more disadvantages. For example, the full potential of DIMD may not be utilized for various reasons. For instance, DIMD prediction implicitly determines whether the prediction should be a mixed prediction of multiple modes or a single mode. The DIMD mechanism may sacrifice robustness where the optimal prediction mode is the DIMD-derived mode, but the optimal prediction might be a single-mode prediction. As another example, in some cases, the optimal intra-mode mode might differ from the DIMD-derived mode, but the difference is small (1 or 2 index differences). Using normal-mode index coding costs more bits, but using the DIMD-derived mode does not lead to the best RD performance. In accordance with one or more techniques in this disclosure, a video encoder (e.g., a video encoder and / or a video decoder) can insert DIMD-derived modes into an MPM list. As such, a video encoder can encode a block using the DIMD-derived mode in the MPM list for intraprediction. Figure 10 is a flowchart illustrating an example technique for intra-block decoding with DIMD most probable mode (MPM) list construction, in accordance with one or more techniques in this disclosure. A comparison of Figure 10 and 9B reveals several differences. For example, compared to the JVET DIMD design (Figure 9), a video encoder implementing the techniques in this disclosure (Figure 10) can perform DIMD mode derivation regardless of whether the current block is predicted using DIMD mode, and the derived modes are added to the MPM list (the MPM list construction process is therefore postponed after the DIMD process). For blocks with the DIMD flag set to true, the video encoder can perform DIMD prediction as explained above. For blocks with the DIMD flag set to false, the video encoder can perform normal intraprediction and add DIMD derived mode to the MPM list. Therefore, the video encoder can use DIMD derived mode for prediction for a block with the MPM flag set to true. By performing the technique in FIGURE 10, a video encoder can further extend the potential of DIMD and can contribute to improved encoding efficiency; a block can use DIMD derived mode and perform normal prediction by selecting DIMD derived mode (or DIMD derived mode with an offset) in the MPM list. Figure 11 is a flowchart illustrating an example technique for constructing / deriving an MPM list, in accordance with one or more techniques in this disclosure. The techniques in Figure 11 can be performed by a video encoder, such as the Video Encoder 200 and / or Video Decoder 300. Qt77 / nn / C7n7 / R / YIAI As shown in Figure 11, in step 1 (1102), the video encoder can derive an intra-mode list using reconstructed samples of neighboring blocks by DIMD. In step 2 (1104), the video encoder can add neighboring block prediction modes to the MPM list. In step 3 (1106), the video encoder can add the DIMD-derived intra-mode list to the MPM list. In step 4 (1108), the video encoder can add more candidates to the MPM list using the candidate list. One example method is to add a plurality of 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 3 candidates). In step 5 (1110), the video encoder can add intra-default modes (DC, flat, horizontal, vertical modes, etc.) to the MPM list (e.g., insert). As such, steps 4 and / or 5 in FIGURE 11 illustrate steps in which the video encoder can insert, into the MPM list and after at least one intra-mode from the derived intra-mode list, additional intra-mode candidates, which can be one or more predetermined candidates. Alternatively, step 2 can illustrate a step in which the video encoder can insert into the MPM list and before at least one intra-mode from the derived intra-mode list, one or more intra-mode candidates that are prediction modes of neighboring blocks of the current block. Figure 12 is a flowchart illustrating an example technique for deriving an intra-mode list by DIMD, in accordance with one or more techniques in this disclosure. The techniques in Figure 12 can be performed by a video encoder, such as the Video Encoder 200 and / or Video Decoder 300. The technique in Figure 12 can be an example of step 1 (1102) of the technique in Figure 11. In 1202, the video encoder can calculate horizontal and vertical gradient values ​​for each neighboring block window as Gx and Gy. Figure 5 illustrates an example window. In 1204, for each set of horizontal and vertical gradient values, the video encoder can derive the intensity (|Gx|+|Gy|) and orientation (Gy / Gx) values ​​and map each orientation to an intra-mode in the range of 2 to 66 (example process given above). The video encoder can also calculate the intensity value as the sum of the absolute values ​​of the horizontal and vertical gradient values, or as the sum of the squares of the horizontal and vertical gradient values. In 1206, for each intra-mode, the video encoder can accumulate its corresponding intensity values.In 1208, the video encoder can classify intra-modes according to the cumulative intensity values ​​from high to low. The DIMD list can be the classified list of intra-modes, or only contain a portion of the list. The DIMD list can exclude intra-modes with a sum of intensity values ​​equal to ah?i nn / cznz / β / υιλι. 0. The DIMD list can exclude intra-mode modes with sum intensity values ​​less than a threshold. The list size can be 0, 1, 2, or more. The first candidate can be set to DC or flat mode if the sum of all intensity values ​​is 0. As shown above in FIGURE 11, in 1104, the video encoder can add intraprediction modes for neighboring blocks in MPM lists. Example neighboring blocks are the left, top, top left, top right, and bottom left blocks, as shown in FIGURE 13. Figure 14 is a flowchart illustrating an example technique for adding DIMD-derived modes to the MPM list, in accordance with one or more techniques in this disclosure. The techniques in Figure 14 can be performed by a video encoder, such as the Video Encoder 200 and / or Video Decoder 300. The technique in Figure 14 can be an example of step 3 of the technique in Figure 11. In 1402, the video encoder can add the first candidate with the highest intensity sum (denoted as “MG” as explained above) to the MPM list. In 1404, the video encoder can determine if the intensity sum of the second candidate is 0 (denoted as “M2” as explained above). If it is determined to be 0, the second candidate can be omitted; otherwise, step 1406 is performed. In 1406, the video encoder can add the second candidate to the MPM list. Below are some example variations and / or alternatives: 1) In 1404, the video encoder can determine if the sum of the intensity of the second candidate is less than a threshold. If it is less than a threshold, the video encoder can omit the second candidate; otherwise, the video encoder can add the second candidate to the MPM list build. 2) Condition 1404 can also be applied to the first candidate. 3) The order of the technique in FIGURE 11 can be switched or interleaved. For example, 1106 can be performed before 1104, or DIMD-derived modes and intra-modes from neighboring blocks can be added in an interleaved manner. 4) When an encoder performs 1104 before 1102, the list of intra-modes derived by DIMD can be cut off by intra-modes of neighboring blocks; for example, if an intra-mode has already been added to the MPM list at 1104, the intra-mode can be omitted when constructing the intra-mode list from DIMD lists. 5) In 4) if an intra-mode has already been added to the MPM list in 1104, any mode that is equal to the intra-mode plus an offset (the offset value can be from -3 to 3) will be omitted when constructing the intra-mode list of DIMD lists. 6) The list of intra-modes derived by DIMD can also be sorted in a different order (e.g., sum of intensity value from low to high and keep the last ah?i nn / cznz / β / υιλι candidates) 7) Each candidate added to the MPM list can be cut to avoid duplicate modes being added to the MPM list. The first candidate can be omitted if it is equal to DC mode or flat. Below are some variations and / or different alternative examples: 1) The DIMD flag may be signaled after the MPM flag 2) The DIMD flag can be signaled as one of the MPM index flags 3) There can only be one derived mode per DIMD that is added to the MPM list 4) There may be more than 2 derived modes per DIMD that are added to the MPM list 5) DIMD can also be applied to the chroma block 6) The DIMD derived mode can also be added to the chroma MPM list 7) Intraprediction can always use an individual prediction mode 8) In the case of 7), the DIMD flag may not be signaled 9) DIMD prediction can only use one individual mode 10) The DIMD prediction can be a mixed prediction of a derived mode and a flat mode 11) The DIMD prediction can be a mixed prediction of the derived mode(s) and DC mode 12) DIMD can use prediction samples instead of reconstructed samples for mode derivation 13) If a block is in DIMD mode, its DIMD-derived prediction mode can be used for building MPM lists of neighboring blocks. 14) If a block is in DIMD mode, a default mode (DC or flat) can be used for building the MPM list of neighboring blocks. Figure 1 is a block diagram illustrating an example video encoding and decoding system that can perform the techniques in this disclosure. The techniques in this disclosure are generally directed at encoding (encoding and / or decoding) video data. In general, video data includes any data used to process a video. Therefore, video data may include raw, unencoded video, encoded video, decoded (e.g., reconstructed) video, and video metadata, such as signaling data. As shown in FIGURE 1, system 100 includes a source device 102 that provides encoded video data to be decoded and displayed by a destination device 116 in this example. Specifically, the source device 102 provides the video data to the destination device 116 via a computer-readable medium 110. The source device 102 and destination device 116 can comprise any of a wide range of devices, including desktop computers, laptops, mobile devices, tablet computers, set-top boxes, telephone terminals such as smartphones, televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, broadcast receivers, or similar devices.In some cases, the source device 102 and destination device 116 can be equipped for wireless communication and therefore can be referred to as wireless communication devices. In the example in FIGURE 1, the source device 102 includes video source 104, memory 106, video encoder 200, and output interface 108. The destination device 116 includes input interface 122, video decoder 300, memory 120, and display device 118. According to this disclosure, a video encoder (200) from the source device (102) and a video decoder (300) from the destination device (116) can be configured to apply intra-mode derivation techniques for constructing the most probable mode list. Therefore, the source device 102 represents an example of a video encoding device, while the destination device 116 represents an example of a video decoding device. In other examples, a source device and a destination device may include other components or arrangements.For example, source device 102 can receive video data from an external video source such as an external camera. Similarly, destination device 116 can interact with an external display device, instead of having a built-in display device. System 100, as shown in Figure 1, is merely an example. In general, any digital video encoding and / or decoding device can perform intra-mode derivation techniques for constructing the most probable mode list. Source device 102 and destination device 116 are just examples of such encoding devices, in which source device 102 generates encoded video data for transmission to destination device 116. This disclosure refers to an “encoding” device as a device that performs encoding (encoding and / or decoding) of data. Therefore, video encoder (200) and video decoder (300) represent examples of encoding devices, specifically a video encoder and a video decoder, respectively.In some examples, the source device 102 and destination device 116 can operate substantially symmetrically, with each including video encoding and decoding components. Therefore, system 100 can support unidirectional or bidirectional video transmission between the source device 102 and the destination device 116, for example, for video streaming, video playback, video broadcasting, or video telephony. In general, video source 104 represents a video data source (i.e., unencoded raw video data) and provides a sequential series of images (also referred to as “frames”) from the video data to video encoder 200, which encodes the data for the images. Video source 104 of source device 102 may include a video capture device, 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. Alternatively, video source 104 may generate computer graphics-based data as the source video, or a combination of live video, archived video, and computer-generated video. In each case, video encoder 200 encodes the captured, pre-captured, or computer-generated video data.The video encoder 200 can rearrange the images from the received order (sometimes referred to as the "display order") into an encoding order for encoding. The video encoder 200 can generate a bitstream that includes encoded video data. The source device 102 can then output the encoded video data via the output interface 108 onto the computer-readable medium 110 for reception and / or retrieval, for example, via the input interface 122 of the destination device 116. Memory 106 of source device 102 and memory 120 of destination device 116 represent general-purpose memories. 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. Alternatively, memories 106 and 120 may store software instructions executable by, for example, video encoder 200 and video decoder 300, respectively. In this example, although memory 106 and memory 120 are shown separately from video encoder 200 and video decoder 300, it should be understood that video encoder 200 and video decoder 300 may also include internal memories for functionally similar or equivalent purposes.In addition, memories 106, 120 can store encoded video data, for example, produced from video encoder 200 and fed into video decoder 300. In some examples, portions of memories 106, 120 can be allocated as one or more video buffers, for example, to store raw, decoded and / or encoded video data. The computer-readable medium 110 can represent any type of medium or device capable of carrying encoded video data from the source device 102 to the destination device 116. In one example, the computer-readable medium 110 represents a communication medium to allow the source device 102 to transmit encoded video data directly to the destination device 116 in real time, for example, by Qhz / nn / cznz / R / YiAi is a radio frequency network or a computer-based network. Output interface 108 can modulate a transmission signal that includes encoded video data, and input interface 122 can demodulate the received transmission signal, according to a communication standard, such as a wireless communication protocol. The communication medium can comprise any wireless or wired communication medium, such as a radio frequency (RF) spectrum or one or more physical transmission lines. The communication medium can be 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 can 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. In some examples, the source device 102 can produce encoded data from output interface 108 to storage device 112. Similarly, the destination device 116 can access encoded data from storage device 112 via input interface 122. Storage device 112 can include any of a variety of distributed or locally accessible data storage media such as a hard drive, Blu-ray discs, DVDs, CD-ROMs, flash memory, volatile or non-volatile memory, or any other digital storage medium suitable for storing encoded video data. In some examples, the source device 102 can produce encoded video data to the file server 114 or another buffer device that can store the encoded video data generated by the source device 102. The destination device 116 can access the stored video data from the file server 114 by streaming or downloading. 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. File server 114 can represent a web server (for example, for a website), a server configured to provide a file transfer protocol service (such as File Transfer Protocol (FTP) or File Delivery Protocol over One-Way Transport (FLUTE)), 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 114 file server may, additionally 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), HTTP Dynamic Streaming, or similar. The target device 116 can access encoded video data from file server 114 via any standard data connection, including an internet connection. This can include a wireless channel (e.g., a Wi-Fi connection), a wired connection (e.g., a digital subscriber line (DSL), cable modem, etc.), or a combination of both suitable for accessing encoded video data stored on file server 114. The input interface 122 can be configured to operate according to one or more of the different protocols discussed above for retrieving or receiving media data from file server 114, or other protocols for retrieving media data. The output interface 108 and input interface 122 can represent wireless transmitters / receivers, modems, wired network components (e.g., Ethernet cards), wireless communication components operating according to any of a variety of IEEE 802.11 standards, or other physical components. In examples where the output interface 108 and input interface 122 comprise wireless components, they can be configured to transfer data, such as encoded video data, according to a cellular communication standard, such as 4G, 4G-LTE (Long Term Evolution), LTE Advanced, 5G, or similar. In some examples where the output interface 108 comprises a wireless transmitter, they can be configured to transfer data, such as encoded video data, according to other wireless standards, such as an IEEE 802 specification.11, an IEEE 802.15 specification (for example, ZigBeeMR), a BluetoothMR standard, or similar. In some examples, the source device 102 and / or target device 116 may include respective system-on-a-chip (SoC) devices. For example, the source device 102 may include an SoC to perform the functionality attributed to the video encoder 200 and / or output interface 108, and the target device 116 may include an SoC to perform the functionality attributed to the video decoder 300 and / or input interface 122. The techniques in this disclosure can be applied to video encoding on any of a variety of multimedia applications such as over-the-air television broadcasts, cable television broadcasts, satellite television broadcasts, real-time Internet streaming video broadcasts such as Dynamic Adaptive Real-Time Streaming over HTTP (DASH), digital video encoded on a data storage medium, decoding digital video stored on a data storage medium, or other applications. The input interface 122 of the destination device 116 receives a video encoded bitstream from the computer-readable medium 110 (e.g., a communication medium, Qhz / nn / cznz / R / YiAi storage device 112, file server 114, or similar). 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 that have values ​​describing characteristics and / or processing of video blocks or other encoded units (e.g., segments, frames, frames, sequences, or similar). The display device 118 displays decoded images from the decoded video data to a 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. Although not shown in Figure 1, in some examples, the 200 video encoder and 300 video decoder can each be integrated with an audio encoder and / or audio decoder and may include appropriate MUX-DEMUX units or other hardware and / or software to handle multiplexed streams that include both audio and video in a common data stream. If applicable, the MUX-DEMUX units can comply with the ITU H.223 multiplexer protocol, or other protocols such as the User Datagram Protocol (UDP). The Video Encoder 200 and Video Decoder 300 can each be implemented using any of a variety of suitable encoder and / or decoder circuitry, such as one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASIOs), field-programmable gate arrays (FPGAs), discrete logic, software, hardware, firmware, or any combination thereof. When the techniques are partially implemented in software, a device can store instructions for the software on a suitable, non-transient, computer-readable medium and execute the instructions in hardware using one or more processors to perform the techniques described herein.Each of the 200 video encoder and 300 video decoder can be included in one or more encoders or decoders, any of which can be integrated as part of a combined encoder / decoder (codec) in a respective device. A device that includes the 200 video encoder and / or 300 video decoder may comprise an integrated circuit, a microprocessor, and / or a wireless communication device, such as a cell phone. The Video Encoder 200 and Video Decoder 300 can operate in accordance with a video coding standard, such as ITU-T H.265, also referred to as High Efficiency Video Coding (HEVC), or extensions thereof, such as multiview and / or scalable video coding extensions. Alternatively, the Video Encoder 200 and Video Decoder 300 can operate in accordance with other proprietary or industry standards, such as ITU-T H.266, also referred to as coding Versatile Video Coding (VVC). A draft of the VVC standard is described in Bross, et al. “Versatile Video Coding (Draft 10),” Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11,20, Meeting: by teleconference, 7-16 Oct. 2020, JVET-T2001-v2 (hereinafter “VVC Draft 10”). The techniques in this disclosure, however, are not limited to any particular coding standard. In general, the Video Encoder 200 and Video Decoder 300 can perform block-based image encoding. The term “block” generally refers to a structure that includes data to be processed (e.g., encoded, decoded, or otherwise used in the encoding and / or decoding process). For example, a block might include a two-dimensional array of luminance and / or chrominance data samples. In general, the Video Encoder 200 and Video Decoder 300 can encode video data represented in a YUV format (e.g., Y, Cb, Cr). That is, instead of encoding red, green, and blue (RGB) data for samples of an image, the Video Encoder 200 and Video Decoder 300 can encode luminance and chrominance components, where the chrominance components can include both red-tone and blue-tone chrominance components.In some examples, the video encoder 200 converts the received RGB-formatted data into a YUV representation before encoding, and the video decoder 300 converts the YUV representation back into RGB format. Alternatively, the pre- and post-processing units (not shown) may perform these conversions. This disclosure may generally refer to the encoding (e.g., encoding and decoding) of images to include the process of encoding or decoding image data. Similarly, this disclosure may refer to the encoding of blocks of an image to include the process of encoding or decoding data for the blocks, such as prediction and / or residual encoding. A generally encoded video bitstream includes a series of values ​​for syntax elements representing encoding decisions (e.g., encoding modes) and image partitioning into blocks. Therefore, references to the encoding of an image or a block should generally be understood as encoding values ​​for syntax elements that make up the image or block. HEVC defines different blocks, including encoding units (CUs), prediction units (PUs), and transform units (TUs). According to HEVC, a video encoder (such as the 200 video encoder) partitions a coding tree unit (CTU) into CUs according to a quaternary tree structure. That is, the video encoder partitions CTUs and CUs into four equal, non-overlapping squares, and each node in the quaternary tree has either zero or four child nodes. Nodes without child nodes can be referred to as "leaf nodes," and the CUs of these leaf nodes can include one or more PUs and / or one or more TUs. The video encoder can further partition PUs and TUs. For example, in HEVC, A residual quaternary tree (RQT) represents the partitioning of the TUs. In HEVC, the PUs represent interprediction data, while the TUs represent residual data. The CUs that are intrapredicted include intraprediction information, such as an intramode indication. As another example, the Video Encoder 200 and Video Decoder 300 can be configured to operate according to VVC. According to VVC, a video encoder (such as the Video Encoder 200) partitions an image into a plurality of encoding tree units (CTUs). The Video Encoder 200 can partition a CTU according to a tree structure, such as a Quaternary Tree-Binary Tree (QTBT) or a Multi-Type Tree (MTT) structure. The QTBT structure eliminates the concepts of multiple partition types, such as the separation between CUs, PUs, and TUs in HEVC. A QTBT structure includes two levels: a first level partitioned according to the Quaternary Tree partitioning, and a second level partitioned according to the Binary Tree partitioning. A root node in the QTBT structure corresponds to a CTU. The leaf nodes of the binary trees correspond to encoding units (CUs). In an MTT partitioning structure, blocks can be partitioned using a quad-tree (QT) partition, a binary-tree (BT) partition, and one or more types of triple-tree (TT) partitions (also called ternary tree (TT) partitions). A triple-tree or ternary partition is a partition where a block is divided into three sub-blocks. In some examples, a triple-tree or ternary partition divides a block into three sub-blocks without splitting the original block through the middle. The partition types in MTT (e.g., QT, BT, and TT) can be symmetric or asymmetric. In some examples, the video encoder 200 and video decoder 300 may use an individual QTBT or MTT structure to represent each of the luminance and chrominance components, whereas 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 the respective chrominance components). The Video Encoder 200 and Video Decoder 300 can be configured to use HEVC quad-tree partitioning, QTBT partitioning, MTT partitioning, or other partitioning structures. For explanatory purposes, the techniques described in this disclosure are presented with respect to QTBT partitioning. However, it should be understood that the techniques in this disclosure can also be applied to video encoders configured to use quad-tree partitioning, or other partitioning types as well. In some examples, a CTU includes a coding tree block (CTB) of luma samples, two corresponding CTBs of chroma samples from an image that has three sample arrays, or a CTB of samples from a monochrome image or an image that is encoded using three color planes and separate syntax structures used to encode the samples. A CTB can be an NxN block of samples for some value of N, so splitting a component into CTBs is a partition. A component is an array or an individual sample from one of the three arrays (luma and two chroma) that make up an image in 4:2:0, 4:2:2, or 4:4:4 color format, or the array or an individual sample from the array that makes up an image in monochrome format. In some examples, a coding block is a block of MxN samples for some values ​​of M and N, so a division of a CTB into coding blocks is a partition. Blocks (e.g., CTUs or CUs) can be grouped in different ways within an image. For example, a cube can refer to a rectangular region of CTU rows within a particular tile in an image. A tile can be a rectangular region of CTUs within a particular tile column and a particular tile row in an image. A tile column refers to a rectangular region of CTUs with a height equal to the image height and a width specified by syntax elements (e.g., such as in an image parameter set). A tile row refers to a rectangular region of CTUs with a height specified by syntax elements (e.g., such as in an image parameter set) and a width equal to the image width. In some examples, a tiling can be split into multiple cubes, each of which can include one or more rows of CTUs within the tiling. A tiling that is not split into multiple cubes can also be referred to as a brick. However, a cube that is a true subset of a tiling cannot be referred to as a tiling. The cubes in an image can also be arranged in a segment. A segment can be an integer number of cubes in an image that can be contained exclusively within a single Network Abstraction Layer (NAL) unit. In some examples, a segment includes several complete tiles or just a consecutive sequence of complete cubes from a tile. This disclosure may use “NxN” and “N by N” interchangeably to refer to the sample dimensions of a block (such as a CU or other video block) in terms of vertical and horizontal dimensions, for example, 16x16 samples or 16 by 16 samples. In general, a 16x16 CU will have 16 samples in a vertical direction (y = 16) and 16 samples in a horizontal direction (x = 16). Similarly, an NxN CU generally has N samples in a vertical direction and N samples in a horizontal direction, where N represents a non-negative integer. The samples in a CU can be arranged in rows and columns. ah?i nn / cznz / β / υιλι Furthermore, the CUs do not necessarily have the same number of samples in the horizontal direction as in the vertical direction. For example, the CUs may comprise NxM samples, where M is not necessarily equal to N. The 200 video encoder encodes video data for CU that represents prediction and / or residual information, and other information. The prediction information indicates how the CU will be predicted in order to form a prediction block for the CU. The residual information generally represents sample-by-sample differences between samples of the CU before encoding and the prediction block. To predict a unit curve (UC), the Video Encoder 200 can generally form a prediction block for the UC through interprediction or intraprediction. Interprediction generally refers to predicting the UC from data in a previously encoded image, while intraprediction generally refers to predicting the UC from previously encoded data of the same image. To perform interprediction, the Video Encoder 200 can generate the prediction block using one or more motion vectors. The Video Encoder 200 can generally perform a motion search to identify a reference block that closely matches the UC, for example, in terms of differences between the UC and the reference block.The Video Encoder 200 can calculate a difference metric using a sum of absolute differences (SAD), sum of squared differences (SSD), mean absolute difference (MAD), mean squared differences (MSD), or other difference calculations to determine whether a reference block closely matches the current CU. In some examples, the Video Encoder 200 can predict the current CU using one-way or two-way prediction. Some examples of VVC also provide an affine motion compensation mode, which can be considered an interprediction mode. In affine motion compensation mode, the 200 video encoder can determine two or more motion vectors representing non-translational motion, such as zoom in or out, rotation, perspective motion, or other types of irregular motion. To perform intraprediction, the Video Encoder 200 can select an intraprediction mode to generate the prediction block. Some VVC examples provide sixty-seven intraprediction modes, including various directional modes, as well as flat mode and DC mode. In general, the Video Encoder 200 selects an intraprediction mode that describes samples adjacent to a current block (for example, a CU block) from which to predict samples of the current block. These samples can generally be above, above and to the left, or to the left of the current block in the same image as the current block, assuming that the Video Encoder 200 encodes CTUs and CUs in frame scan order (left to right, top to bottom). The Video Encoder 200 encodes data representing the prediction mode for a current block. For example, for interprediction modes, the Video Encoder 200 can encode data representing which of the different available interprediction modes is being used, as well as motion information for the corresponding mode. For unidirectional or bidirectional interprediction, for example, the Video Encoder 200 can encode motion vectors using Advanced Motion Vector Prediction (AMVP) or fusion mode. The Video Encoder 200 can use similar modes to encode motion vectors for affine motion compensation mode. After prediction, such as intraprediction or interprediction of a block, the Video Encoder 200 can calculate residual data for the block. Residual data, such as a residual block, represents sample-by-sample differences between the block and a prediction block for that block, formed using the corresponding prediction mode. The Video Encoder 200 can apply one or more transforms to the residual block to produce transformed data in a transform domain instead of the sample domain. For example, the Video Encoder 200 can apply a Discrete Cosine Transform (DCT), an Integer Transform, a Wavelet Transform, or a conceptually similar transform to the residual video data.Additionally, the 200 video encoder can apply a secondary transform after the first transform, such as a mode-dependent non-separable secondary transform (MDNSST), a signal-dependent transform, a Karhunen-Loeve transform (KLT), or similar. The 200 video encoder produces transform coefficients after applying one or more transforms. As noted earlier, after any transform to produce transform coefficients, the Video Encoder 200 can perform quantization of the transform coefficients. Quantization generally refers to a process in which the transform coefficients are quantized to potentially reduce the amount of data used to represent the transform coefficients, providing additional compression. By performing the quantization process, the Video Encoder 200 can reduce the bit depth associated with some or all of the transform coefficients. For example, the Video Encoder 200 can round an n-bit value down to an m-bit value during quantization, where n is greater than m. In some instances, to perform quantization, the Video Encoder 200 can perform a right-shift of bits on the value to be quantized. After quantization, the Video Encoder 200 can scan the transform coefficients, producing a one-dimensional vector from the two-dimensional array containing the quantized transform coefficients. The scan can be designed to place higher-energy (and therefore lower-frequency) transform coefficients at the front of the vector and lower-energy (and therefore higher-frequency) transform coefficients at the back. In some examples, the Video Encoder 200 can use a predefined scan order to scan the quantized transform coefficients to produce a signaled vector, and then encode the quantized transform coefficients of the vector using entropy. In other examples, the Video Encoder 200 can perform adaptive scanning.After scanning the quantized transform coefficients to form the one-dimensional vector, the video encoder 200 can encode the one-dimensional vector by entropy, for example, according to context-adaptive binary arithmetic (CABAC) coding. The video encoder 200 can also entropy-encode values ​​for syntax elements that describe metadata associated with the encoded video data for use by the video decoder 300 when decoding the video data. To perform CABAC, the 200 video encoder can assign a context within a context model to a symbol to be transmitted. The context can refer, for example, to whether the symbol's neighboring values ​​are zero or not. Probability determination can be based on a context assigned to the symbol. The video encoder 200 can also generate syntax data, such as block-based, image-based, and sequence-based syntax data, for the video decoder 300, for example, in an image header, block header, segment header, or other syntax data, such as a sequence parameter set (SPS), image parameter set (PPS), or video parameter set (VPS). The video decoder 300 can likewise decode syntax data to determine how to decode the corresponding video data. In this way, the video encoder 200 can generate a bitstream that includes encoded video data, such as syntax elements describing the partitioning of an image into blocks (e.g., CU) and prediction and / or residual information for the blocks. Ultimately, the video decoder 300 can receive the bitstream and decode the encoded video data. In general, the video decoder 300 performs a process that is the reciprocal of that performed by the video encoder 200 to decode the encoded video data from the bitstream. For example, the video decoder 300 can decode values ​​for syntax elements of the bitstream using CABAC in a manner substantially similar to, but reciprocal to, the CABAC encoding process of the video encoder 200. Syntax elements can define partitioning information for the partitioning of an image into CTUs, and the partitioning of each CTU according to a corresponding partitioning structure, such as a QTBT structure, to define the CUs of the CTU. Syntax elements can further define prediction and residual information for blocks (e.g., CUs) of video data. Residual information can be represented, for example, by quantized transform coefficients. The Video Decoder 300 can inverse quantize and inverse transform the quantized transform coefficients of a block to reproduce a residual block for that block. The Video Decoder 300 uses a signaled prediction mode (intra- or inter-prediction) and related prediction information (e.g., motion information for inter-prediction) to form a prediction block for the block. The Video Decoder 300 can then combine the prediction block and the residual block (on a sample-by-sample basis) to reproduce the original block. The Video Decoder 300 can perform additional processing, such as performing an unblocking process to reduce visual artifacts along the block boundaries. In accordance with one or more techniques in this disclosure, a video encoder (e.g., a video encoder and / or a video decoder) can insert DIMD-derived modes into an MPM list. As such, a video encoder can encode a block using the DIMD-derived mode in the MPM list for intraprediction. This disclosure may generally refer to the “signaling” of certain information, such as syntax elements. The term “signaling” may generally refer to the communication of values ​​for syntax elements and / or other data used to decode encoded video data. That is, video encoder 200 may signal values ​​for syntax elements in the bitstream. In general, signaling refers to generating a value in the bitstream. As noted earlier, source device 102 may transport the bitstream to destination device 116 substantially in real time, or not in real time, as may occur when syntax elements are stored on storage device 112 for later retrieval by destination device 116. In accordance with one or more techniques in this disclosure, the encoder 200 and / or decoder 300 can insert one or more derived DIMD modes into an MPM list. For example, the encoder 200 and / or decoder 300 can perform the technique shown in FIGURE 10. Figures 2A and 2B are conceptual diagrams illustrating an example quaternary tree binary tree (QTBT) structure and a corresponding coding unit tree (CTU). Solid lines represent quaternary tree splitting, and dashed lines indicate binary tree splitting. At each split (i.e., non-leaf) node of the binary tree, a flag is signaled to indicate which type of split (i.e., horizontal or vertical) is used, where 0 indicates horizontal splitting and 1 indicates vertical splitting in this example. For quaternary tree splitting, there is no need to indicate the split type because quaternary tree nodes split a block horizontally and vertically into four equal-sized sub-blocks.Therefore, video encoder 200 can encode, and video decoder 300 can decode, syntax elements (such as split information) for a region tree level of the QTBT 130 structure (i.e., the solid lines) and syntax elements (such as split information) for a prediction tree level of the QTBT 130 structure (i.e., the dashed lines). Video encoder 200 can encode, and video decoder 300 can decode, video data, such as prediction and transform data, for CUs represented by terminal leaf nodes of the QTBT 130 structure. In general, the CTU 132 in FIGURE 2B can be associated with parameters that define block sizes corresponding to QTBT 130 structure nodes at the first and second levels. These parameters can include a CTU size (representing a CTU 132 size in samples), a minimum quaternary tree size (MinQTSize, representing the minimum allowed size of a quaternary tree leaf node), a maximum binary tree size (MaxBTSize, representing the maximum allowed size of a binary tree root node), a maximum binary tree depth (MaxBTDepth, representing the maximum allowed depth of a binary tree), and a minimum binary tree size (MinBTSize, representing the minimum allowed size of a binary tree leaf node). The root node of a QTBT structure corresponding to a CTU can have four child nodes at the first level of the QTBT structure, each of which can be split according to the quad tree partitioning. That is, the first-level nodes are either leaf nodes (having no child nodes) or have four child nodes. The QTBT structure example 130 represents these nodes as including the source node and the child nodes, which have solid lines for branches. If the first-level nodes are no larger than the maximum allowed binary tree root node size (MaxBTSize), then the nodes can be further split by their respective binary trees. The binary tree splitting of a node can be iterated until the resulting nodes reach the minimum allowed binary tree leaf node size (MinBTSize) or the maximum allowed binary tree depth (MaxBTDepth).The QTBT 130 structure example represents these nodes as having dashed lines for branches. The leaf node of the binary tree is referred to as a coding unit (CU), which is used for prediction (e.g., intra-image or inter-image prediction) and transformation, without any further partitioning. As discussed earlier, CUs can also be referred to as “video blocks” or “blocks.” In an example of QTBT's partition structure, the CTU size is set Qhz / nn / cznz / R / YiAi is set to 128x128 (luma samples and two corresponding 64x64 chroma samples), the MinQTSize is set to 16x16, the MaxBTSize is set to 64x64, the MinBTSize (both width and height) is set to 4, and the MaxBTDepth is set to 4. The quaternary tree partitioning is first applied to the CTU to generate quaternary tree leaf nodes. The quaternary tree leaf nodes can be sized from 16x16 (i.e., the MinQTSize) to 128x128 (i.e., the size of the CTU). If the leaf node of the quad tree is 128x128, the leaf node will not be further split by the binary tree because its size exceeds the MaxBTSize (i.e., 64x64 in this example). Otherwise, the leaf node will be further split by the binary tree. Therefore, the leaf node of the quad tree is also the root node for the 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., width splitting) 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., height splitting) is allowed for that binary tree node. As noted earlier, the leaf nodes of the binary tree are referred to as CUs, and they are further processed according to the prediction and transform without additional partitioning. Figure 3 is a block diagram illustrating an example Video Encoder 200 that can perform the techniques described in this disclosure. Figure 3 is provided for explanatory purposes and should not be considered limiting to the techniques as exemplified and described extensively in this disclosure. For explanatory purposes, this disclosure describes the Video Encoder 200 in accordance with VVC (ITU-T H.266, under development) and HEVC (ITU-T H.265) techniques. However, the techniques in this disclosure can be performed by video encoding devices configured for other video encoding standards. In the example in FIGURE 3, the video encoder 200 includes video data memory 230, mode selection unit 202, residual generation unit 204, transform processing unit 206, quantization unit 208, inverse quantization unit 210, inverse transform processing unit 212, reconstruction unit 214, filter unit 216, decoded image buffer (DPB) 218, and entropic encoding unit 220. Any or all of the video data memory 230, mode selection unit 202, residual generation unit 204, transform processing unit 206, quantization unit 208, inverse quantization unit 210, inverse transform processing unit 212, reconstruction unit 214, filter unit ah?i nn / cznz / β / υιλι The 216, DPB 218, and entropic encoding unit 220 can be implemented in one or more processors or processing circuitry. For example, the units of the 200 video encoder can be implemented as one or more circuits or logic elements as part of the hardware circuitry, or as part of a processor, ASIC, or FPGA. Furthermore, the 200 video encoder can include additional or alternative processors or processing circuitry to perform these and other functions. Video data memory 230 can store video data to be encoded by the components of video encoder 200. Video encoder 200 can receive video data stored in video data memory 230 from, for example, video source 104 (FIGURE 1). DPB 218 can act as a reference image memory, storing reference video data for use in predicting subsequent video data by video encoder 200. Video data memory 230 and DPB 218 can be formed from any of a variety of memory devices, such as dynamic random-access memory (DRAM), including synchronous DRAM (SDRAM), magnetoresistive RAM (MRAM), resistive RAM (RRAM), or other types of memory devices. Video data memory 230 and DPB 218 can be provided by the same memory device or by separate memory devices.In different examples, the video data memory 230 may be on the chip with other components of the video encoder 200, as illustrated, or off the chip with respect to those components. In this disclosure, the reference to video data memory 230 should not be interpreted as being limited to the internal memory of video encoder 200, unless specifically described as such, or to memory external to video encoder 200, unless specifically described as such. Instead, the reference to video data memory 230 should be understood as reference memory that stores video data received by video encoder 200 for encoding (for example, video data for a current block to be encoded). Memory 106 in FIGURE 1 may also provide temporary storage for outputs from the various units of video encoder 200. The different units in FIGURE 3 are illustrated to help understand the operations performed by the 200 video encoder. The units can be implemented as fixed-function circuits, programmable circuits, or a combination of both. Fixed-function circuits refer to circuits that provide particular functionality and are pre-set in the operations they can perform. Programmable circuits refer to circuits that can be programmed to perform different tasks and provide flexible functionality in the operations they can perform. For example, programmable circuits can run software or firmware that causes the programmable circuits to function in the manner defined by the software or firmware instructions. Fixed-function circuits (Qhz / nn / cznz / R / viAi) can execute software instructions (for example, to receive or produce parameters), but the types of operations performed by fixed-function circuits are generally immutable. In some examples, one or more of the units may be distinct circuit blocks (fixed-function or programmable), and in some examples, one or more of the units may be integrated circuits. The Video Encoder 200 may include arithmetic logic units (ALUs), elementary function units (EFUs), digital circuits, analog circuits, and / or programmable cores, formed from programmable circuits. In examples where the operations of the Video Encoder 200 are performed using software executed by the programmable circuits, memory 106 (FIGURE 1) may store the instructions (e.g., object code) of the software that the Video Encoder 200 receives and executes, or other memory within the Video Encoder 200 (not shown) may store these instructions. Video data memory 230 is configured to store received video data. Video encoder 200 can retrieve an image from the video data in video data memory 230 and provide the video data to the residual generation unit 204 and mode selection unit 202. The video data in video data memory 230 can be raw video data that is to be encoded. The mode selection unit 202 includes a motion estimation unit 222, a motion compensation unit 224, and an intraprediction unit 226. The mode selection unit 202 may include additional functional units to perform video prediction according to other prediction modes. For example, the mode selection unit 202 may include a palette unit, an intra-block copy unit (which may be part of the motion estimation unit 222 and / or motion compensation unit 224), an affine unit, a linear model (LM) unit, or similar units. The mode selection unit 202 generally coordinates multiple encoding passes to test combinations of encoding parameters and the resulting speed-distortion values ​​for these combinations. Encoding parameters can include CTU partitioning into CUs, prediction modes for the CUs, transform types for CU residual data, quantization parameters for CU residual data, and so on. The mode selection unit 202 can ultimately select the combination of encoding parameters that has better speed-distortion values ​​than the other tested combinations. The video encoder 200 can partition an image retrieved from the video data memory 230 into a series of CTUs and encapsulate one or more CTUs within a segment. The mode selection unit 202 can partition a CTU from the image according to a tree structure, such as the QTBT structure or the HEVC quaternary tree structure described earlier. As described above, the video encoder 200 can form one or more CUs from the partitioning of a CTU according to the tree structure. This CU can also be referred to generally as a “video block” or “block.” In general, the mode selection unit 202 also controls its components (e.g., the motion estimation unit 222, motion compensation unit 224, and intraprediction unit 226) to generate a prediction block for a current block (e.g., a current CU or, in HEVC, the overlap portion of a PU and a TU). For the interprediction of a current block, the motion estimation unit 222 can perform a motion search to identify one or more closely matching reference blocks in one or more reference images (e.g., one or more pre-encoded images stored in DPB 218).In particular, the Motion Estimation Unit 222 can calculate a representative value of how similar a potential reference block is to the current block, for example, according to the Sum of Absolute Differences (SAD), Sum of Squared Differences (SSD), Mean Absolute Differences (MAD), Mean Squared Differences (MSD), or similar metrics. The Motion Estimation Unit 222 can generally perform these calculations using sample-by-sample differences between the current block and the reference block under consideration. The Motion Estimation Unit 222 can identify a reference block with a lower value resulting from these calculations, indicating a reference block that more closely matches the current block. The motion estimation unit 222 can form one or more motion vectors (MVs) that define the positions of reference blocks in the reference images relative to the position of the current block in a current image. The motion estimation unit 222 can then provide the motion vectors to the motion compensation unit 224. For example, for one-way interprediction, the motion estimation unit 222 can provide a single motion vector, while for two-way interprediction, the motion estimation unit 222 can provide two motion vectors. The motion compensation unit 224 can then generate a prediction block using the motion vectors. For example, the motion compensation unit 224 can retrieve data from the reference block using the motion vector.As another example, if the motion vector has fractional sample accuracy, the motion compensation unit 224 can interpolate values ​​for the prediction block according to one or more interpolation filters. Furthermore, for bidirectional interprediction, the motion compensation unit 224 can retrieve data for two reference blocks identified by their respective motion vectors and combine the retrieved data, for example, through sample-by-sample averaging or weighted averaging. As another example, for intraprediction, or intraprediction coding, the intraprediction unit 226 can generate the prediction block from samples neighboring the current block. For example, for directional modes, the intraprediction unit 226 can generally mathematically combine values ​​from neighboring samples and populate these calculated values ​​in the defined direction across the current block to produce the prediction block. As another example, for DC mode, the intraprediction unit 226 can calculate an average of the samples neighboring the current block and generate the prediction block to include this resulting average for each sample in the prediction block. The mode selection unit 202 provides the prediction block to the residual generation unit 204. The residual generation unit 204 receives a raw, unencoded version of the current block from video data memory 230 and the prediction block from the mode selection unit 202. The residual generation unit 204 calculates the sample-by-sample differences between the current block and the prediction block. The resulting sample-by-sample differences define a residual block for the current block. In some examples, the residual generation unit 204 can also determine differences between sample values ​​in the residual block to generate a residual block using residual differential pulse code modulation (RDPCM). In some examples, the residual generation unit 204 can be formed using one or more subtractor circuits that perform binary subtraction. In examples where the mode selection unit 202 divides the CUs into PUs, each PU can be associated with a luma prediction unit and corresponding chroma prediction units. The video encoder 200 and video decoder 300 can support PUs of different sizes. As noted earlier, the size of a CU can refer to the size of the luma encoding block of the CU, and the size of a PU can refer to the size of a luma prediction unit of the PU. Assuming the size of a particular CU is 2Nx2N, the video encoder 200 can support PU sizes of 2Nx2N or NxN for intraprediction, and symmetrical PU sizes of 2Nx2N, 2NxN, Nx2N, NxN, or similar sizes for interprediction. The 200 video encoder and 300 video decoder can also support asymmetric partitioning for PU sizes of 2NxnU, 2NxnD, nLx2N and nRx2N for interprediction. In examples where the mode selection unit 202 does not further divide a CU into PUs, each CU can be associated with a luma encoding block and corresponding chroma encoding blocks. As before, the size of a CU can refer to the size of the CU's luma encoding block. The video encoder 200 and video decoder 300 can support CU sizes of 2Nx2N, 2NxN, or Nx2N. For other video coding techniques, such as intra-block copy-mode coding, affine-mode coding, and linear model (LM) mode coding, the mode selection unit 202, through respective units associated with the coding techniques, generates a prediction block for the current block being encoded. In some examples, such as palette-mode coding, the mode selection unit 202 may not generate a prediction block and instead generate syntax elements that indicate how to reconstruct the block based on a selected palette. In these modes, the mode selection unit 202 can provide these syntax elements to the entropic coding unit 220 that will perform the encoding. As described above, the residual generation unit 204 receives the video data for the current block and the corresponding prediction 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 differences between the prediction block and the current block. Transform Processing Unit 206 applies one or more transforms to the residual block to generate a transform coefficient block (referred to herein as a “transform coefficient block”). Transform Processing Unit 206 can apply different transforms to a residual block to form the transform coefficient block. For example, Transform Processing Unit 206 can apply a discrete cosine transform (DCT), a directional transform, a Karhunen-Loeve transform (KLT), or a conceptually similar transform to a residual block. In some examples, Transform Processing Unit 206 can perform multiple transforms on a residual block, for example, a primary transform and a secondary transform, such as a rotational transform. In some examples, Transform Processing Unit 206 does not apply any transforms to a residual block. The quantization unit 208 can quantize the transform coefficients in a transform coefficient block to produce a quantized transform coefficient block. The quantization unit 208 can quantize the transform coefficients of a transform coefficient block according to a quantization parameter (QP) value associated with the current block. The video encoder 200 (for example, via the mode selection unit 202) can adjust the degree of quantization applied to the transform coefficient blocks associated with the current block by adjusting the QP value associated with the CU. Quantization can introduce information loss, and therefore the quantized transform coefficients may be less accurate than the original transform coefficients produced by the transform processing unit 206. The inverse quantization unit 210 and inverse transform processing unit 212 can apply inverse quantization and inverse transform to a quantized transform coefficient block, respectively, to reconstruct a residual block from the transform coefficient block. The reconstruction unit 214 can produce a reconstructed block that corresponds to the actual block (although potentially with some degree of distortion) based on the reconstructed residual block and a prediction block generated by the mode selection unit 202. For example, the reconstruction unit 214 can aggregate samples from the reconstructed residual block with corresponding samples from the prediction block generated by the mode selection unit 202 to produce the reconstructed block. Filter unit 216 can perform one or more filter operations on rebuilt blocks. For example, filter unit 216 can perform unblocking operations to reduce blocking artifacts along the edges of the CUs. Filter unit 216 operations can be omitted in some examples. The video encoder 200 stores reconstructed blocks in DPB 218. For example, in examples where no filter unit 216 operations are performed, the reconstruction unit 214 can store reconstructed blocks in DPB 218. In examples where filter unit 216 operations are performed, the filter unit 216 can store the filtered reconstructed blocks in DPB 218. The motion estimation unit 222 and motion compensation unit 224 can retrieve a reference image from DPB 218, formed from the reconstructed (and potentially filtered) blocks, to interpredict blocks of subsequently encoded images. Furthermore, the intraprediction unit 226 can use reconstructed blocks in DPB 218 of a current image to intrapredict other blocks in the current image. In general, the entropic encoding unit 220 can entropy-encode syntax elements received from other functional components of the video encoder 200. For example, the entropic encoding unit 220 can entropy-encode blocks of quantized transform coefficients from the quantization unit 208. As another example, the entropic encoding unit 220 can entropy-encode prediction syntax elements (e.g., motion information for interprediction or intra-mode information for intraprediction) from the mode selection unit 202. The entropic encoding unit 220 can perform one or more entropic encoding operations on the syntax elements, which are another example of video data, to generate Qhz / nn / cznz / R / YiAi entropy-encoded data. For example, the entropic coding unit 220 can perform a context-adaptive variable-length coding operation (CAVLC), a CABAC operation, a variable-to-variable-length (V2V) coding operation, a syntax-based context-adaptive binary arithmetic (SBAC) coding operation, a probability interval partitioning (PIPE) entropy coding operation, an exponential Golomb coding operation, or another type of entropic coding operation on the data. In some examples, the entropic coding unit 220 can operate in derivation mode where the syntax elements are not entropy-encoded. The video encoder 200 can produce a bitstream that includes the entropy-encoded syntax elements necessary to reconstruct blocks of a segment or image. In particular, the entropy encoding unit 220 can produce the bitstream. The operations described above are described with respect to a block. This description should be understood as operations for a luma encoding block and / or chroma encoding blocks. As described above, in some examples, the luma encoding block and the chroma encoding blocks are luma and chroma components of a CU. In some examples, the luma encoding block and the chroma encoding blocks are luma and chroma components of a PU. In some examples, the operations performed on a luma encoding block do not need to be repeated for chroma encoding blocks. For instance, the operations to identify a motion vector (MV) and a reference image for a luma encoding block do not need to be repeated to identify an MV and a reference image for chroma blocks. Instead, the MV for the luma encoding block can be scaled to determine the MV for the chroma blocks, and the reference image can be the same. As another example, the intraprediction process can be the same for both the luma encoding block and the chroma encoding blocks. The 200 video encoder represents an example of a device configured to encode video data that includes a memory configured to store video data, and one or more processing units implemented in circuitry and configured to derive, for a current block of video data and using decoder-side intra-mode derivation (DIMD), a list of intra-modes using reconstructed samples from neighboring blocks; construct, for the current block, a most possible mode (MPM) list that includes at least one intra-mode from the derived list of intra-modes; and predict, using a selected candidate from the constructed MPM list, the current block. FIGURE 4 is a block diagram illustrating a 300 video decoder Qhz / nn / cznz / R / viAi example that can perform the techniques in this disclosure. FIGURE 4 is provided for illustrative purposes and is not limiting to the techniques as exemplified and described extensively in this disclosure. For illustrative purposes, this disclosure describes the 300 video decoder in accordance with VVC (ITU-T H.266, under development) and HEVC (ITU-T H.265) techniques. However, the techniques in this disclosure can be performed by video encoding devices configured for other video encoding standards. In the example in FIGURE 4, the video decoder 300 includes a coded image buffer (CPB) 320, entropic decoding unit 302, prediction processing unit 304, inverse quantization unit 306, inverse transform processing unit 308, reconstruction unit 310, filter unit 312, and decoded image buffer (DPB) 314. Any or all of the CPB 320, entropic decoding unit 302, prediction processing unit 304, inverse quantization unit 306, inverse transform processing unit 308, reconstruction unit 310, filter unit 312, and DPB 314 may be implemented in one or more processors or in processing circuitry. For example, the 300 video decoder units can be implemented as one or more logic circuits or elements as part of the hardware circuitry, or as part of a processor, ASIO, or FPGA.In addition, the 300 video decoder may include additional or alternative processing processors or circuitry to perform these and other functions. The prediction processing unit 304 includes the motion compensation unit 316 and the intraprediction unit 318. The prediction processing unit 304 may include additional units to perform prediction according to other prediction modes. For example, the prediction processing unit 304 may include a palette unit, an intra-block copy unit (which may be part of the motion compensation unit 316), an affine unit, a linear model (LM) unit, or similar units. In other examples, the video decoder 300 may include more, fewer, or different functional components. The CPB 320 memory can store video data, such as an encoded video bitstream, to be decoded by the components of the 300 video decoder. The video data stored in the CPB 320 memory can be obtained, for example, from the 110 computer-readable medium (FIGURE 1). The CPB 320 memory can include a CPB that stores encoded video data (for example, syntax elements) from an encoded video bitstream. Also, the CPB 320 memory can store video data other than syntax elements of an encoded image, such as temporary data representing outputs from the different units of the video decoder 300. The DPB 314 generally stores decoded images, which the video decoder 300 can produce and / or use as reference video data when decoding subsequent data or images from the encoded video bitstream.The CPB 320 and DPB 314 memory can be comprised of any of a variety of memory devices, such as DRAM, including SDRAM, MRAM, RRAM, or other types of memory devices. The CPB 320 and DPB 314 memory can be provided by the same memory device or by separate memory devices. In different examples, the CPB 320 memory may be on-chip with other components of the 300 video decoder, or off-chip with respect to those components. Additionally, or alternatively, in some examples, the video decoder 300 can retrieve encoded video data from memory 120 (FIGURE 1). That is, memory 120 can store data as previously discussed with CPB 320 memory. Similarly, memory 120 can store instructions to be executed by the video decoder 300 when some or all of the video decoder 300's functionalities are implemented in the software that will be executed by the video decoder 300's processing circuitry. The different units shown in FIGURE 4 are illustrated to help understand the operations performed by the 300 video decoder. The units can be implemented as fixed-function circuits, programmable circuits, or a combination of both. Similar to FIGURE 3, fixed-function circuits refer to circuits that provide particular functionality and are pre-set in the operations they can perform. Programmable circuits refer to circuits that can be programmed to perform different tasks and provide flexible functionality in the operations they can perform. For example, programmable circuits can run software or firmware that causes the circuits to operate in the manner defined by the software or firmware instructions.Fixed-function circuits can execute software instructions (for example, to receive or produce parameters), but the types of operations they perform are generally immutable. In some examples, one or more of the units may be distinct circuit blocks (fixed-function or programmable), and in some examples, one or more of the units may be integrated circuits. The 300 video decoder may include ALUs, EFUs, digital circuits, analog circuits, and / or programmable cores formed from programmable circuits. In examples where the 300 video decoder's operations are performed by software running on the programmable circuits, on-chip or off-chip memory may store instructions (e.g., object code) from the software that the 300 video decoder receives and executes. The entropic decoding unit 302 can receive encoded video data from Qhz / nn / cznz / R / YiAi the CPB and entropy-decode the video data to reproduce syntax elements. The prediction processing unit 304, inverse quantization unit 306, inverse transform processing unit 308, reconstruction unit 310, and filter unit 312 can generate decoded video data based on the syntax elements extracted from the bitstream. In general, the 300 video decoder reconstructs an image block by block. The 300 video decoder can perform a reconstruction operation on each block individually (where the block currently being reconstructed, i.e., decoded, can be referred to as a “current block”). The entropic decoding unit 302 can entropy-decode syntax elements that define quantized transform coefficients from a block of quantized transform coefficients, as well as transform information such as a quantization parameter (QP) and / or transform mode indications. The inverse quantization unit 306 can use the QP associated with the block of quantized transform coefficients to determine a degree of quantization and, likewise, a degree of inverse quantization to which the inverse quantization unit 306 applies. The inverse quantization unit 306 can, for example, perform a bitwise left-shift operation to inversely quantize the quantized transform coefficients. The inverse quantization unit 306 can thus form a block of transform coefficients that includes transform coefficients. After the inverse quantization unit 306 forms the transform coefficient block, the inverse transform processing unit 308 can apply one or more inverse transforms to the transform coefficient block to generate a residual block associated with the current block. For example, the inverse transform processing unit 308 can apply an inverse DCT, an inverse integer transform, an inverse Karhunen-Loeve transform (KLT), an inverse rotational transform, an inverse directional transform, or another inverse transform to the transform coefficient block. Furthermore, the prediction processing unit 304 generates a prediction block according to prediction information syntax elements that were entropy-decoded by the entropic decoding unit 302. For example, if the prediction information syntax elements indicate that the current block is being interpredicted, the motion compensation unit 316 can generate the prediction block. In this case, the prediction information syntax elements can specify a reference image in DPB 314 from which to retrieve a reference block, as well as a motion vector that identifies a location of the reference block in the reference image. 0H7 / ηη / Ω7η7 / β / νΐΛΐ with respect to the location of the current block in the current image. The motion compensation unit 316 can generally perform the interprediction process in a manner that is substantially similar to that described with respect to the motion compensation unit 224 (FIGURE 3). As another example, if the prediction information syntax elements indicate that the current block is intrapredicted, intraprediction unit 318 can generate the prediction block according to an intraprediction mode indicated by the prediction information syntax elements. Again, intraprediction unit 318 can generally perform the intraprediction process in a manner that is substantially similar to that described with respect to intraprediction unit 226 (FIGURE 3). Intraprediction unit 318 can retrieve data from samples neighboring the current block from DPB 314. The 310 Reconstruction Unit can reconstruct the current block using the prediction block and the residual block. For example, the 310 Reconstruction Unit can add samples from the residual block to the corresponding samples from the prediction block to reconstruct the current block. Filter unit 312 can perform one or more filter operations on rebuilt blocks. For example, filter unit 312 can perform unlock operations to reduce lock artifacts along the edges of rebuilt blocks. Filter unit 312 operations are not necessarily performed in all examples. The video decoder 300 can store the reconstructed blocks in the DPB 314. For example, in cases where no filter unit 312 operations are performed, the reconstruction unit 310 can store reconstructed blocks in the DPB 314. In cases where filter unit 312 operations are performed, the filter unit 312 can store the filtered reconstructed blocks in the DPB 314. As discussed earlier, the DPB 314 can provide reference information, such as samples of a current image for intraprediction and previously decoded images for post-motion compensation, to the prediction processing unit 304. In addition, the video decoder 300 can produce decoded images (e.g., decoded video) from the DPB 314 for later display on a display device, such as the display device 118 in FIGURE 1. Thus, the 300 video decoder represents an example of a video decoding device that includes a memory configured to store video data, and one or more processing units implemented in circuitry and configured to derive, for a current block of video data and using decoder-side intra-mode derivation (DIMD), a list of intra-modes using reconstructed samples from neighboring blocks; construct, for the current block, a most possible mode (MPM) list that includes at least one intra-mode from the derived list of intra-modes; and predict, using a selected candidate from the constructed MPM list, the current block. Figure 15 is a flowchart illustrating an example method for encoding a current block according to the techniques in this disclosure. The current block may comprise a current CU. Although described with respect to the 200 video encoder (Figures 1 and 3), it should be understood that other devices can be configured to perform a method similar to that in Figure 15. In this example, video encoder 200 initially predicts the current block (350). For example, video encoder 200 can form a prediction block for the current block. Video encoder 200 can then calculate a residual block for the current block (352). To calculate the residual block, video encoder 200 can calculate the difference between the original unencoded block and the prediction block for the current block. Video encoder 200 can then transform the residual block and quantize transform coefficients of the residual block (354). Next, video encoder 200 can scan the quantized transform coefficients of the residual block (356). During or after scanning, video encoder 200 can encode the transform coefficients by entropy (358). For example, video encoder 200 can encode the transform coefficients using CAVLC or CABAC.The video encoder 200 can then produce the encoded data by block entropy (360). Figure 16 is a flowchart illustrating an example method for decoding a current block of video data in accordance with the techniques in this disclosure. The current block may comprise a current CU. Although described with respect to the 300 video decoder (Figures 1 and 4), it should be understood that other devices can be configured to perform a method similar to that in Figure 16. The video decoder 300 can receive entropy-encoded data for the current block, such as entropy-encoded prediction information and entropy-encoded data for transform coefficients of a residual block corresponding to the current block (370). The video decoder 300 can entropy-decode the entropy-encoded data to determine prediction information for the current block and to reproduce transform coefficients of the residual block (372). The video decoder 300 can predict the current block (374), for example, using an intra- or inter-prediction mode as indicated by the prediction information for the current block, to compute a prediction block for the current block. The video decoder 300 can then inverse-scan the reproduced transform coefficients (376) to create a block of quantized transform coefficients.The video decoder 300 can then inversely quantize the transform coefficients and apply an inverse ah?i nn / cznz / β / υιλι transform to the transform coefficients to produce a residual block (378). The video decoder 300 can ultimately decode the current block by combining the prediction block and the residual block (380). Figure 17 is a flowchart illustrating an example technique for encoding video data using DIMD, in accordance with one or more of the techniques in this disclosure. Although described with respect to the 200 video encoder (Figures 1 and 3), it should be understood that other devices can be configured to perform a method similar to that shown in Figure 17. The video encoder 200 can derive, for a current block of video data, a list of decoder-side intra-mode derivation (DIMD) intra-modes using reconstructed samples from neighboring blocks (1702). For example, the intraprediction unit 226 can derive the DIMD intra-modes using the technique discussed above with reference to FIGURE 7 to obtain a first DIMD intra-mode M1 and a second DIMD intra-mode M2. The video encoder 200 can construct, for the current block, a most probable mode (MPM) list that includes at least one intra-mode of the DIMD modes (1704). For example, the intraprediction unit 226 can construct the MPM list using the technique discussed above with reference to FIGURE 11. The constructed MPM list can include one or both of the first intra-mode of DIMD M1 and the second intra-mode of DIMD M2. The video encoder 200 can determine whether to encode the current block using DIMD (1706). For example, the mode selection unit 202 can perform an analysis to determine an optimal encoding mode for the current block (e.g., an encoding mode that uses the fewest bits to represent the current block). To determine the optimal encoding mode, the mode selection unit 202 can test encoding the current block using different modes. When the mode selection unit 202 determines that encoding the current block using DIMD is optimal, it can encode the current block using DIMD. Similarly, if the mode selection unit 202 determines that encoding the current block using one of the derived DIMD modes in the MPM list is optimal, it can decide not to encode the current block using DIMD. The video encoder 200 can encode an indication of whether the current block is predicted using DIMD. For example, the entropic encoding unit 220 can encode, for the current block, a DIMD flag with a value indicating whether DIMD is enabled for the current block of video data. As an example, in response to a determination not to predict the current block using DIMD (the "No" branch of 1706), the video encoder 200 can encode the DIMD flag with a false value (for example, 0) to indicate that the current block is not predicted using DIMD (1708). As another example, in response to the Qhz / nn / cznz / R / viAi determination to predict the current block using DIMD (1706 "Yes" branch), the 200 video encoder can encode the DIMD flag with a true value (e.g., 1) to indicate that the current block is predicted using DIMD (1714). The video encoder 200 can encode one or more syntax elements that indicate a selected intra-mode from the MPM list (1710). For example, the entropic encoding unit 220 can encode a syntax element that has a value indicating an index in the MPM list of the selected intra-mode. In some examples, as discussed earlier, the video encoder 200 can include a reconstruction loop in which video data blocks are reconstructed for reference when predicting subsequent blocks. For example, when the current block is not predicted using DIMD, the video encoder 200 can predict the current block using the selected intra-mode (1712). For example, the intra-prediction unit 226 can generate a prediction block using samples in the direction specified by the selected intra-mode. As another example, when the current block is predicted using DIMD, the video encoder 200 can predict the current block using DIMD (1716). For example, the intra-prediction unit 226 can predict the current block using the technique described above with reference to Figure 8. Figure 18 is a flowchart illustrating an example technique for decoding video data using DIMD, in accordance with one or more of the techniques in this disclosure. Although described with respect to the 300 video decoder (Figures 1 and 4), it should be understood that other devices can be configured to perform a method similar to that shown in Figure 18. The video decoder 300 can derive, for a current block of video data, a list of decoder-side intra-mode derivation (DIMD) intra-modes using reconstructed samples from neighboring blocks (1802). For example, the intraprediction unit 318 can derive the DIMD intra-modes using the technique discussed above with reference to FIGURE 7 to obtain a first DIMD intra-mode M1 and a second DIMD intra-mode M2. The video decoder 300 can construct, for the current block, a most probable mode (MPM) list that includes at least one intra-mode of the DIMD (1804) modes. For example, the intraprediction unit 318 can construct the MPM list using the technique discussed above with reference to FIGURE 11. The constructed MPM list can include one or both of the first intra-mode of DIMD M1 and the second intra-mode of DIMD M2. The video decoder 300 can determine whether to predict the current block using DIMD (1806). For example, the entropic decoding unit 302 can decode, for the current block, a DIMD flag whose value indicates whether DIMD is enabled for the current block of video data. Based on the value of the DIMD flag, the intraprediction unit 318 can determine whether to predict the current block using DIMD. For example, where the flag value is true (e.g., 1), the intraprediction unit 318 can determine whether to predict the current block using DIMD. As another example, where the flag value is false (e.g., 0), the intraprediction unit 318 can determine whether not to predict the current block using DIMD. As noted above, in some examples, the 300 video decoder can derive the DIMD intra-mode list independently of the DIMD flag value. Where video decoder 300 determines not to predict the current block using DIMD (1806 "No" branch), entropic decoding unit 302 can decode one or more syntax elements indicating a selected intra-mode from the MPM list (1808) (e.g., indicating an index in the MPM list). For example, entropic decoding unit 302 can decode a syntax element intra_luma_mpm_¡dx that specifies the index in the MPM list of the selected intra-mode. The video decoder 300 can predict the current block (1810) using the selected candidate from the constructed MPM list. For example, the intraprediction unit 318 can generate a prediction block for the current block using the selected intra-mode MPM from the list. The reconstruction unit 310 can combine the prediction block with a residual block (e.g., similar to 380 in FIGURE 16). Where the video decoder 300 determines to predict the current block using DIMD (1806's "Yes" branch), the entropic decoding unit 302 can predict the current block using DIMD (1812). For example, the intraprediction unit 318 can predict the current block using the technique described above with reference to FIGURE 8. The following numbered clauses may illustrate one or more examples of this disclosure: Clause 1 A. A video data decoding method, the method comprising: deriving, for a current block of video data and using decoder-side intra-mode derivation (DIMD), a list of intra-modes using reconstructed samples from neighboring blocks; constructing, for the current block, a most possible mode (MPM) list that includes at least one intra-mode from the derived list of intra-modes; and predicting, using a selected candidate from the constructed MPM list, the current block. Clause 2A. The method of clause 1A, wherein deriving the intra-mode list using DIMD comprises deriving the intra-mode list using DIMD independently of a value of a DIMD flag. ah?i nn / cznz / β / υιλι Clause 3A. The method of clause 1A or clause 2A, wherein constructing the MPM list comprises: inserting, into the MPM list, a first candidate from the derived intra-mode list using DIMD; and selectively inserting, on the basis of an intensity sum of a second candidate from the derived intra-mode list using DIMD, the second candidate into the MPM list. Clause 4A. The method of clause 3A, wherein constructing the MPM list further comprises: inserting, into the MPM list and after the first candidate, additional intra-mode candidates. Clause 5A. A device for encoding video data, the device comprising one or more means for performing the method of any of clauses 1A-4A. Clause 6A. The device of clause 5A, wherein the one or more means comprise one or more circuit-implemented processors. Clause 7A. The device of any of clauses 5A and 6A, further comprising a memory for storing video data. Clause 8A. The device of any of clauses 5A-7A, further comprising a display configured to show decoded video data. Clause 9A. The device of any of clauses 5A-8A, wherein the device comprises one or more of a camera, a computer, a mobile device, a broadcast receiving device, or a decoder. Clause 10A. A computer-readable storage medium having instructions stored therein that, when executed, cause one or more processors to perform the method of any of clauses 1A-4A. Clause 1B. A video data decoding method, the method comprising: deriving, for a current block of video data and using decoder-side intra-mode derivation (DIMD), a list of intra-modes using reconstructed samples from neighboring blocks; constructing, for the current block, a most probable mode (MPM) list, wherein constructing the MPM list comprises inserting, into the MPM list, at least one intra-mode from the derived list of intra-modes; and predicting, using a selected candidate from the constructed MPM list, the current block. Clause 2B. The method of clause 1B, further comprising: decoding, for the current block, 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 comprises deriving the intra-mode list using DIMD independently of a value of the DIMD flag. 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, into the MPM list, a first candidate from the derived list of intra-modes using DIMD; and selectively inserting, into the MPM list, a second candidate from the derived list of intra-modes using DIMD. Qhz / nn / eznz / R / YiAi Clause 4B. The method of clause 3B, wherein selectively inserting the second candidate comprises selectively inserting, on the basis of an intensity sum of the second candidate from the derived intra-mode list using DIMD, the second candidate in the MPM list. Clause 5B. The method of clause 1B, wherein constructing the MPM list further comprises: inserting, into the MPM list and after the at least one intra-mode of the derived intra-mode list, additional intra-mode candidates. Clause 6B. The method of clause 5B, wherein inserting additional intramode candidates comprises: inserting, into the MPM list and after at least one intramode from the derived intramode list, one or more predetermined candidates. Clause 7B. The method of clause 5B, wherein constructing the MPM list further comprises: inserting, into the MPM list and before the at least one intra-mode of the derived intra-mode list, one or more intra-mode candidates that are prediction modes of neighboring blocks of the current block. Clause 8B. A video data encoding method, the method comprising: deriving, for an actual block of video data and using decoder-side intra-mode derivation (DIMD), a list of intra-modes using reconstructed samples from neighboring blocks; constructing, for the actual block, a most likely mode (MPM) list, wherein constructing the MPM list comprises inserting, into the MPM list, at least one intra-mode from the derived list of intra-modes; selecting, for the actual block and from the MPM list, a candidate intra-mode; and encoding, for the actual block, one or more syntax elements specifying the candidate intra-mode. Clause 9B. The method of clause 8B, further comprising: encoding, for the current block, 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 comprises deriving the intra-mode list using DIMD independently of a value of the DIMD flag. 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, into the MPM list, a first candidate from the derived list of intra-modes using DIMD; and selectively inserting, into the MPM list, a second candidate from the derived list of intra-modes using DIMD. Clause 11B. The method of clause 10B, wherein selectively inserting the second candidate comprises selectively inserting, on the basis of an intensity sum of the second candidate from the derived intra-mode list using DIMD, the second candidate in the MPM list. Clause 12B. The method of clause 8B, wherein constructing the MPM list further comprises: inserting, into the MPM list and after the at least one intra-mode of the derived intra-mode list, additional intra-mode candidates. Clause 13B. The method of clause 12B, wherein inserting the additional intramode candidates comprises: inserting, into the MPM list and after the at least one intramode from the derived intramode list, one or more predetermined candidates. Clause 14B. The method of clause 12B, wherein constructing the MPM list further comprises: inserting, into the MPM list and before the at least one intra-mode of the derived intra-mode list, one or more intra-mode candidates that are prediction modes of neighboring blocks of the current block. Clause 15B. A device for decoding video data, the device comprising: a memory configured to store video data; and one or more circuit-implemented processors configured to: derive, for a current block of video data and using decoder-side intra-mode derivation (DIMD), a list of intra-modes using reconstructed samples from neighboring blocks; construct, for the current block, a most probable mode (MPM) list, wherein constructing the MPM list comprises inserting, into the MPM list, at least one intra-mode from the derived list of intra-modes; and predict, using a selected candidate from the constructed MPM list, the current block. Clause 16B. The device of clause 15B, wherein the one or more processors are further configured to: decode, for the current block, a DIMD flag having a value indicating whether DIMD is enabled for the current block of video data, wherein, to derive the intra-mode list using DIMD, the one or more processors are configured to derive the intra-mode list using DIMD regardless of a value of the DIMD flag. Clause 17B. The device of clause 15B, wherein, in order to insert at least one intra-mode from the derived intra-mode list into the MPM list, one or more processors are configured to: insert, into the MPM list, a first candidate from the derived intra-mode list using DIMD; and selectively insert, into the MPM list, a second candidate from the derived intra-mode list using DIMD. Clause 18B. The device of clause 17B, wherein, in order to selectively insert the second candidate, one or more processors are configured to selectively insert, based on a sum of the intensity of the second candidate from the derived intra-mode list using DIMD, the second candidate in the MPM list. Clause 19B. The device of clause 15B, wherein, to construct the MPM list, one or more processors are configured to: insert, into the MPM list and after at least one intra-mode derived intra-mode list, additional intra-mode candidates. Clause 20B. The device of clause 19B, wherein, in order to insert the additional intra-mode candidates, the one or more processors are configured to: insert, into the MPM list and after at least one intra-mode derived intra-mode list, one or more predetermined candidates. Clause 21B. The device of clause 19B, wherein, to construct the MPM list, one or more processors are configured to: insert, into the MPM list and before at least one intra-mode from the derived intra-mode list, one or more intra-mode candidates that are neighboring block prediction modes of the current block. Clause 22B. A device for encoding video data, the device comprising: a memory configured to store video data; and one or more circuit-implemented processors configured to: derive, for a current block of video data and using decoder-side intra-mode derivation (DIMD), a list of intra-modes using reconstructed samples from neighboring blocks; construct, for the current block, a most probable mode (MPM) list, wherein constructing the MPM list comprises inserting, into the MPM list, at least one intra-mode from the derived list of intra-modes; select, for the current block and from the MPM list, a candidate intra-mode; and encode, for the current block, one or more syntax elements specifying the candidate intra-mode. Clause 23B. The device of clause 22B, wherein the one or more processors are further configured to: encode, for the current block, a DIMD flag having a value indicating whether DIMD is enabled for the current block of video data, wherein, to derive the intra-mode list using DIMD, the one or more processors are configured to derive the intra-mode list using DIMD regardless of a value of the DIMD flag. Clause 24B. The device of clause 22B, wherein, in order to insert at least one intra-mode from the derived intra-mode list into the MPM list, one or more processors are configured to: insert, into the MPM list, a first candidate from the derived intra-mode list using DIMD; and selectively insert, into the MPM list, a second candidate from the derived intra-mode list using DIMD. Clause 25B. The device of clause 24B, wherein, in order to selectively insert the second candidate, one or more processors are configured to selectively insert, based on a sum of the intensity of the second candidate from the derived intra-mode list using DIMD, the second candidate in the MPM list. Clause 26B. The device of clause 22B, wherein, to construct the MPM list, one or more processors are configured to: insert, into the MPM list and after at least one intra-mode derived intra-mode list, additional intra-mode candidates. Clause 27B. The device of clause 26B, wherein, in order to insert additional intra-mode candidates, the one or more processors are configured to: insert, into the MPM list and after at least one intra-mode from the derived intra-mode list, one or more predetermined candidates. Clause 28B. The device of clause 26B, wherein, to construct the MPM list, one or more processors are configured to: insert, into the MPM list and before at least one intra-mode from the derived intra-mode list, one or more intra-mode candidates that are neighboring block prediction modes of the current block. Clause 1C. A video data decoding method, the method comprising: deriving, for a current block of video data and using decoder-side intra-mode derivation (DIMD), a list of intra-modes using reconstructed samples from neighboring blocks; constructing, for the current block, a most probable mode (MPM) list, wherein constructing the MPM list comprises inserting, into the MPM list, at least one intra-mode from the derived list of intra-modes; and predicting, using a selected candidate from the constructed MPM list, the current block. Clause 2C. The method of clause 1C, further comprising: decoding, for the current block, 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 comprises deriving the intra-mode list using DIMD independently of a value of the DIMD flag. Clause 3C. The method of clause 1C or 2C, wherein inserting at least one intramode from the derived list of intra-modes into the MPM list comprises: inserting, into the MPM list, a first candidate from the derived list of intra-modes using DIMD; and selectively inserting, into the MPM list, a second candidate from the derived list of intra-modes using DIMD. Clause 4C. The method of clause 3C, wherein selectively inserting the second candidate comprises selectively inserting, on the basis of an intensity sum of the second candidate from the derived intra-mode list using DIMD, the second candidate in the MPM list. Clause 5C. The method of any of clauses 1C-4C, wherein constructing the MPM list further comprises: inserting, into the MPM list and after the at least one intra-mode of the derived intra-mode list, additional intra-mode candidates. Clause 6C. The method of clause 5C, wherein inserting the additional intramode candidates comprises: inserting, into the MPM list and after the at least one intramode from the derived intramode list, one or more predetermined candidates. Clause 7C. The method of clause 5C or 6C, wherein constructing the MPM list further comprises: inserting, into the MPM list and before the at least one intra-mode of the derived intra-mode list, one or more intra-mode candidates that are prediction modes of neighboring blocks of the current block. Clause 8C. A video data encoding method, the method comprising: deriving, for an actual block of video data and using decoder-side intra-mode derivation (DIMD), a list of intra-modes using reconstructed samples from neighboring blocks; constructing, for the actual block, a most likely mode (MPM) list, wherein constructing the MPM list comprises inserting, into the MPM list, at least one intra-mode from the derived list of intra-modes; selecting, for the actual block and from the MPM list, a candidate intra-mode; and encoding, for the actual block, one or more syntax elements specifying the candidate intra-mode. Clause 9C. The method of clause 8C, further comprising: encoding, for the current block, 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 comprises deriving the intra-mode list using DIMD regardless of a value of the DIMD flag. Clause 10C. The method of clause 8C or 9C, wherein inserting at least one intramode from the derived list of intra-modes into the MPM list comprises: inserting, into the MPM list, a first candidate from the derived list of intra-modes using DIMD; and selectively inserting, into the MPM list, a second candidate from the derived list of intra-modes using DIMD. Clause 11C. The method of clause 10C, wherein selectively inserting the second candidate comprises selectively inserting, on the basis of an intensity sum of the second candidate from the derived intra-mode list using DIMD, the second candidate in the MPM list. Clause 12C. The method of any of clauses 8C-11C, wherein constructing the MPM list further comprises: inserting, into the MPM list and after the at least one intramode of the derived intramode list, additional intramode candidates. Clause 13C. The method of clause 12C, wherein inserting the additional intramode candidates comprises: inserting, into the MPM list and after the at least one intramode from the derived intramode list, one or more predetermined candidates. Clause 14C. The method of clause 12C or 13C, wherein constructing the MPM list further comprises: inserting, into the MPM list and before the at least one intra-mode of the derived intra-mode list, one or more intra-mode candidates that are prediction modes of neighboring blocks of the current block. 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 circuitry and configured to: derive, for a current block of video data and using decoder-side intra-mode derivation (DIMD), a list of intra-modes using reconstructed samples from neighboring blocks; construct, for the current block, a most probable mode (MPM) list, wherein constructing the MPM list comprises inserting, into the MPM list, at least one intra-mode from the derived list of intra-modes; and predict, using a selected candidate from the constructed MPM list, the current block. Clause 16C. The device of clause 15C, wherein the one or more processors are further configured to: decode, for the current block, a DIMD flag having a value indicating whether DIMD is enabled for the current block of video data, wherein, to derive the intra-mode list using DIMD, the one or more processors are configured to derive the intra-mode list using DIMD regardless of a value of the DIMD flag. Clause 17C. The device of clause 15C or 16C, wherein, in order to insert at least one intra-mode from the derived intra-mode list into the MPM list, one or more processors are configured to: insert, into the MPM list, a first candidate from the derived intra-mode list using DIMD; and selectively insert, into the MPM list, a second candidate from the derived intra-mode list using DIMD. Clause 18C. The device of clause 17C, wherein, in order to selectively insert the second candidate, one or more processors are configured to selectively insert, based on a sum of the intensity of the second candidate from the derived intra-mode list using DIMD, the second candidate in the MPM list. Clause 19C. The device of any of clauses 15C-18C, wherein, to construct the MPM list, one or more processors are configured to: insert, into the MPM list and after at least one intra-mode derived intra-mode list, additional intra-mode candidates. Clause 20C. The device of clause 19C, wherein, in order to insert additional intra-mode candidates, the one or more processors are configured to: insert, into the MPM list and after at least one intra-mode from the derived intra-mode list, one or more predetermined candidates. Clause 21C. The device of clause 19C or 20C, wherein, to construct the MPM list, one or more processors are configured to: insert, into the MPM list and before at least one intra-mode of the derived intra-mode list, one or more intra-mode candidates that are neighboring block prediction modes of the current block. Clause 22C. A device for encoding video data, the device comprising: a memory configured to store video data; and one or more circuit-implemented processors configured to: derive, for a current block of video data and using decoder-side intra-mode derivation (DIMD), a list of intra-mode modes using reconstructed samples from neighboring blocks; construct, for the current block, a most probable mode (MPM) list, wherein constructing the MPM list comprises inserting, into the MPM list, at least one intra-mode from the derived list of intra-modes; select, for the current block and from the MPM list, a candidate intra-mode; and encode, for the current block, one or more syntax elements specifying the candidate intra-mode. Clause 23C. The device of clause 22C, wherein the one or more processors are further configured to: encode, for the current block, a DIMD flag having a value indicating whether DIMD is enabled for the current block of video data, wherein, to derive the intra-mode list using DIMD, the one or more processors are configured to derive the intra-mode list using DIMD regardless of a value of the DIMD flag. Clause 24C. The device of clause 22C or 23C, wherein, in order to insert at least one intra-mode from the derived intra-mode list into the MPM list, one or more processors are configured to: insert, into the MPM list, a first candidate from the derived intra-mode list using DIMD; and selectively insert, into the MPM list, a second candidate from the derived intra-mode list using DIMD. Clause 25C. The device of clause 24C, wherein, in order to selectively insert the second candidate, one or more processors are configured to selectively insert, based on a sum of the intensity of the second candidate from the derived intra-mode list using DIMD, the second candidate in the MPM list. Clause 26C. The device of any of clauses 22C-25C, wherein, to construct the MPM list, one or more processors are configured to: insert, into the MPM list and after at least one intra-mode derived intra-mode list, additional intra-mode candidates. Clause 27C. The device of clause 26C, wherein, in order to insert additional intra-mode candidates, the one or more processors are configured to: insert, into the MPM list and after at least one intra-mode from the derived intra-mode list, one or more predetermined candidates. Clause 28C. The device of clause 26C or 27C, wherein, to construct the MPM list, one or more processors are configured to: insert, into the MPM list and before at least one intra-mode of the derived intra-mode list, one or more intra-mode candidates that are neighboring block prediction modes of the current block. Clause 1D. A computer-readable storage medium that stores instructions that, when executed, cause one or more processors of a video encoder to perform the method of any of clauses 1C-7C. Clause 1E. A computer-readable storage medium that stores instructions that, when executed, cause one or more processors of a video encoder to perform the method of any of clauses 8C-14C. It will be acknowledged that, depending on the example, certain actions or events of any of the techniques described herein may be performed in a different sequence, added, merged, or omitted altogether (for example, not all of the actions or events described are necessary for the practice of the techniques). Furthermore, in certain examples, the actions or events may be performed concurrently, for example, through multi-threaded processing, interrupt handling, or multiple processors, rather than sequentially. In one or more examples, the described functions can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions can be stored or transmitted as one or more instructions or code on a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media can include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media, which includes any medium that facilitates the transfer of a computer program from one location to another, for example, according to a communication protocol. Thus, computer-readable media in general can correspond to (1) tangible, non-transient computer-readable storage media or (2) a communication medium such as a signal or carrier wave.Data storage media can be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, code, and / or data structures for implementing the techniques described in this disclosure. A computer program product may include a computer-readable medium. By way of example and without limitation, these 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 that can be accessed by a computer. Furthermore, any connection is appropriately termed a computer-readable medium.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 frequency, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio frequency, and microwave are included in the definition of a medium. It should be understood, however, that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but instead refer to tangible, non-transient storage media.The term "disc" and "digital disc," as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc, where discs usually reproduce data magnetically, while digital discs reproduce data optically using lasers. Combinations of these should also be included within the scope of computer-readable media. Instructions can be executed by one or more processors, such as one or more DSPs, general-purpose microprocessors, ASIO, FPGAs, or other equivalent integrated or discrete logic circuitry. Accordingly, the terms “processor” and “processing circuitry,” as used herein, may refer to any of the above structures or any other structure suitable for implementing the techniques described herein. Furthermore, in some respects, the functionality described herein may be provided within dedicated software and / or hardware modules configured for encoding and decoding, or incorporated into a combined codec. Additionally, the techniques may be implemented entirely on one or more logic circuits or elements. The techniques in this disclosure can be implemented on a wide variety of devices or appliances, including a wireless terminal, an integrated circuit (IC), or an array of ICs (e.g., a chipset). Different components, modules, or units are described in this disclosure to emphasize functional aspects of devices configured to perform the disclosed techniques, but they do not necessarily require implementation by different hardware units. Rather, as described above, different units can be combined into a single codec hardware unit or provided by a collection of interoperable hardware units, including one or more processors as described above, in conjunction with appropriate software and / or firmware. Several examples have been described. These and other examples are within the scope of the following claims.

Claims

1. A video data decoding method, the method characterized in that it comprises: deriving, for an actual block of video data and using decoder-side intra-mode derivation (DIMD), a list of intra-modes using reconstructed samples of neighboring blocks; constructing, for the actual block, a most probable mode (MPM) list, wherein constructing the MPM list comprises inserting, into the MPM list, at least one intra-mode from the derived list of intra-modes; and predicting, using a selected candidate from the constructed MPM list, the actual block.

2. The method according to claim 1, characterized in that it further comprises: decoding, for the current block, 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 comprises deriving the intra-mode list using DIMD independently of a value of the DIMD flag.

3. The method according to claim 1, characterized in that inserting at least one intra-mode from the derived list of intra-modes into the MPM list comprises: inserting, into the MPM list, a first candidate from the derived list of intra-modes using DIMD; and selectively inserting, into the MPM list, a second candidate from the derived list of intra-modes using DIMD.

4. The method according to claim 3, characterized in that selectively inserting the second candidate comprises selectively inserting, based on an intensity sum of the second candidate from the derived intra-mode list using DIMD, the second candidate in the MPM list.

5. The method according to claim 1, characterized in that the construction of the MPM list further comprises: inserting, into the MPM list and after the at least one intra-mode of the derived intra-mode list, additional intra-mode candidates.

6. The method according to claim 5, characterized in that the insertion of the additional intra-mode candidates comprises: inserting, into the MPM list and after at least one intra-mode from the derived intra-mode list, one or more predetermined candidates.

7. The method according to claim 5, characterized in that the construction of the MPM list further comprises: inserting, into the MPM list and before at least one intra-mode of the derived intra-mode list, one or more intra-mode candidates that are prediction modes of neighboring blocks of the current block.

8. A video data encoding method, the method being characterized in that it comprises: deriving, for an actual block of video data and using decoder-side intra-mode derivation (DIMD), a list of intra-modes using reconstructed samples from neighboring blocks; constructing, for the actual block, a most probable mode (MPM) list, wherein constructing the MPM list comprises inserting, into the MPM list, at least one intra-mode from the derived list of intra-modes; selecting, for the actual block and from the MPM list, a candidate intra-mode; and encoding, for the actual block, one or more syntax elements specifying the candidate intra-mode.

9. The method according to claim 8, characterized in that it further comprises: encoding, for the current block, 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 comprises deriving the intra-mode list using DIMD independently of a value of the DIMD flag.

10. The method according to claim 8, characterized in that inserting at least one intra-mode from the derived list of intra-modes into the MPM list comprises: inserting, into the MPM list, a first candidate from the derived list of intra-modes using DIMD; and selectively inserting, into the MPM list, a second candidate from the derived list of intra-modes using DIMD.

11. The method according to claim 10, characterized in that selectively inserting the second candidate comprises selectively inserting, based on an intensity sum of the second candidate from the derived intra-mode list using DIMD, the second candidate in the MPM list.

12. The method according to claim 8, characterized in that the construction of the MPM list further comprises: inserting, into the MPM list and after the at least one intra-mode of the derived intra-mode list, additional intra-mode candidates.

13. The method according to claim 12, characterized in that the insertion of additional intra-mode candidates comprises: inserting, into the MPM list and after at least one intra-mode from the derived intra-mode list, one or more predetermined candidates.

14. The method according to claim 12, characterized in that the construction of the MPM list further comprises: inserting, in the MPM list and before at least one intra-mode of the derived intra-mode list, one or more intra-mode candidates that are prediction modes of neighboring blocks of the current block.

15. A device for decoding video data, the device being characterized in that it comprises: a memory configured to store video data; and one or more processors implemented in the circuitry and configured to: derive, for a current block of video data and using decoder-side intra-mode derivation (DIMD), a list of intra-modes using reconstructed samples of neighboring blocks; construct, for the current block, a most probable mode (MPM) list, wherein constructing the MPM list comprises inserting, into the MPM list, at least one intra-mode from the derived list of intra-modes; and predict, using a selected candidate from the constructed MPM list, the current block.

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

17. The device according to claim 15, characterized in that, for the purpose of inserting at least one intra-mode from the derived intra-mode list into the MPM list, one or more processors are configured to: insert, into the MPM list, a first candidate from the derived intra-mode list using DIMD; and selectively insert, into the MPM list, a second candidate from the derived intra-mode list using DIMD. Qhz / nn / cznz / R / YiAi 18. The device according to claim 17, characterized in that, in order to selectively insert the second candidate, the one or more processors are configured to selectively insert, based on a sum of the intensity of the second candidate from the derived intra-mode list using DIMD, the second candidate in the MPM list.

19. The device according to claim 15, characterized in that, to construct the MPM list, the one or more processors are configured to: insert, into the MPM list and after at least one intra-mode derived intra-mode list, additional intra-mode candidates.

20. The device according to claim 19, characterized in that, in order to insert the additional intra-mode candidates, the one or more processors are configured to: insert, in the MPM list and after at least one intra-mode from the derived intra-mode list, one or more predetermined candidates.

21. The device according to claim 19, characterized in that, to construct the MPM list, the one or more processors are configured to: insert, into the MPM list and before at least one intra-mode of the derived intra-mode list, one or more intra-mode candidates that are neighboring block prediction modes of the current block.

22. A device for encoding video data, the device being characterized in that it comprises: a memory configured to store video data; and one or more processors implemented in the circuitry and configured to: derive, for a current block of video data and using decoder-side intra-mode derivation (DIMD), a list of intra-modes using reconstructed samples from neighboring blocks; construct, for the current block, a most probable mode (MPM) list, wherein constructing the MPM list comprises inserting, into the MPM list, at least one intra-mode from the derived list of intra-modes; select, for the current block and from the MPM list, a candidate intra-mode; and encode, for the current block, one or more syntax elements specifying the candidate intra-mode.

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

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

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

26. The device according to claim 22, characterized in that, to construct the MPM list, the one or more processors are configured to: insert, into the MPM list and after at least one intra-mode derived intra-mode list, additional intra-mode candidates.

27. The device according to claim 26, characterized in that, in order to insert the additional intra-mode candidates, the one or more processors are configured to: insert, in the MPM list and after at least one intra-mode from the derived intra-mode list, one or more predetermined candidates.

28. The device according to claim 26, characterized in that, to construct the MPM list, the one or more processors are configured to: insert, into the MPM list and before at least one intra-mode of the derived intra-mode list, one or more intra-mode candidates that are neighboring block prediction modes of the current block.

Images