VIDEO CODING USING A MULTI-MODEL LINEAR MODEL

Abstract

A computing device implements a method for decoding video data by generating a multiple-model linear model (MMLM) that includes a first linear model between the minimum luma value and the threshold luma value, and a second linear model between the threshold luma value and the maximum luma value of a reference luma sample group and a reference chroma sample group; and reconstructing a respective sample value of the chroma block from a weighted combination of a respective first reconstructed sample value corresponding to the luma block using the multiple-model linear model, and a respective second reconstructed sample value from a neighboring chroma block in an intra-prediction mode.

Description

VIDEO CODING USING MULTI-MODEL LINEAR MODEL REFERENCE CORRESPONDING TO RELATED REQUEST This application is based on and claims priority to U.S. Provisional Patent Application No. 63 / 176,140, ​​entitled "Video Coding Using Multi-model Linear Model," filed on April 16, 2021, the contents of which are incorporated herein by reference in their entirety. TECHNICAL FIELD This application relates to video encoding and compression, more specifically, to methods and devices for improving encoding efficiency, simplifying complexity, and improving intra-prediction accuracy. BACKGROUND OF THE INVENTION Digital video is supported by a variety of electronic devices, such as digital televisions, laptops and desktops, tablet computers, digital cameras, digital recording devices, digital media players, video game consoles, smartphones, video conferencing devices, video streaming devices, and so on. These electronic devices transmit and receive, or otherwise communicate, digital video data over a communication network, and / or store the digital video data on a storage device. Due to limited bandwidth capacity of the communication network and limited memory resources of the storage device, video coding may be used to compress video data according to one or more video coding standards before it is transmitted or stored.For example, video coding standards include Versatile Video Coding (VVC), Joint Scan Test Model (JEM), High Efficiency Video Coding (HEVC / H.265), Advanced Video Coding (AVC / H.264), Moving Picture Expert Group (MPEG) coding, and similar standards. Video coding typically uses predictive methods (e.g., interprediction, intraprediction, and similar methods) that take advantage of the inherent redundancy in video data. The goal of video coding is to compress video data in a way that uses a lower bitrate while avoiding or minimizing video quality degradation. CI 77 I n / C7n7 / R / VIAI BRIEF DESCRIPTION OF THE INVENTION This application describes implementations related to video data encoding and decoding and, more particularly, methods and devices for improving encoding efficiency, simplifying complexity, and improving intra-prediction accuracy using multiple-model linear model (MMLM) and intra-prediction mode. Pursuant to a first aspect of this application, a method for constructing a chroma block from a video signal includes: receiving a bit stream encoding the chroma block, a corresponding luma block, a plurality of neighboring luma samples surrounding the luma block, and a plurality of neighboring chroma samples surrounding the chroma block; decoding the luma block, the plurality of neighboring luma samples, and the plurality of neighboring chroma samples to obtain a plurality of reconstructed luma samples from the luma block, a plurality of reconstructed neighboring luma samples, and a plurality of reconstructed neighboring chroma samples, respectively; selecting, from the plurality of reconstructed neighboring luma samples and the plurality of reconstructed neighboring chroma samples, a group of reference luma samples and a group of reference chroma samples, wherein each reference luma sample corresponds to a respective reference chroma sample;Calculate a threshold luma value from the reference luma sample group, and a corresponding threshold chroma value from the reference chroma sample group; determine a maximum luma value and a minimum luma value from the reference luma sample group, where the threshold luma value is between the minimum luma value and the maximum luma value; generate a multi-model linear model that includes a first linear model between the minimum luma value and the threshold luma value, and a second linear model between the threshold luma value and the maximum luma value; and reconstruct a respective sample value from the chroma block from a weighted combination of a respective first reconstructed sample value from the luma block using the multi-model linear model, and a respective second reconstructed sample value from a neighboring chroma block in an intra-prediction mode. Pursuant to a second aspect of this application, an electronic apparatus includes one or more processing units, memory, and a plurality of programs stored in memory. The programs, when executed by the one or more processing units, cause the electronic apparatus to perform the method for encoding a video signal as described above. Pursuant to a third aspect of this application, a non-transient, computer-readable storage medium stores a plurality of programs for execution by an electronic device having one or more processing units. The programs, when executed by the one or more processing units, cause the electronic device to perform the method for encoding a video signal as described above. Pursuant to a fourth aspect of this application, a computer-readable storage medium stores therein a stream of bits comprising video information generated by the method for video decoding as described above. It should be understood that both the above general description and the following detailed description are examples only and are not restrictive of the present description. BRIEF DESCRIPTION OF THE FIGURES The accompanying figures, which are included to provide a better understanding of the implementations and are incorporated herein and form part of the specification, illustrate the described implementations and, together with the description, serve to explain the underlying principles. Similar reference numbers refer to the corresponding parts. Figure 1 is a block diagram illustrating an illustrative video encoding and decoding system in accordance with some implementations of the present description. Figure 2 is a block diagram illustrating an illustrative video encoder in accordance with some implementations of the present description. Figure 3 is a block diagram illustrating an illustrative video decoder in accordance with some implementations of the present description. Figures 4A to 4D are block diagrams illustrating how a frame is recursively split into a quad tree into multiple video blocks of different sizes in accordance with some implementations of the present description. Figure 5A is a block diagram illustrating spatially neighboring and temporally placed block positions of an actual CU that is to be coded in accordance with some implementations of the present description. Figure 5B is a block diagram illustrating multi-row multi-string encoding of an image CTU using parallel wavefront processing in accordance with some implementations of the present description. Figure 5C is a block diagram that illustrates intra-modes as defined in the VVC standard in accordance with some implementations of the present description. Figure 5D is a block diagram illustrating a set of reconstructed samples neighboring above and to the left of the current block as the reference for intra CI 77 I n / C7n7 / R / VIAI prediction in accordance with some implementations of this description. Figure 5E is a block diagram illustrating a set of chosen pixels on which a gradient analysis is performed in accordance with some implementations of the present description. Figure 5F is a block diagram illustrating the convolution process of the Sobel 3x3 gradient filter with the template in accordance with some implementations of the present description. Figures 6A and 6B are block diagrams illustrating an illustrative previously reconstructed luma block 602 and an illustrative associated chroma block 620 to be decoded, respectively, in accordance with some implementations of the present description. Figures 7A to 7D are graph diagrams that illustrate an illustrative process by which a video encoder implements the techniques of deriving a multi-model linear model and applying the multi-model linear model to predict chroma samples from an encoding unit in accordance with some implementations of the present description. Figure 8 is a flowchart that illustrates an illustrative process by which a video encoder implements the techniques of deriving a multi-model linear model and applying the multi-model linear model to predict chroma samples from an encoding unit in accordance with some implementations of the present description. Figure 9 is a block diagram illustrating the locations of neighboring samples (shown as gray circles) used for MMLM in accordance with some implementations of the present description. Figure 10 is a block diagram illustrating the locations of four sample sets used for MMLM in accordance with some implementations of the present description. Figure 11 is a flowchart that illustrates an illustrative process by which a video encoder implements the techniques of combining MMLM and intra-prediction to predict or construct a chroma block from a video signal in accordance with some implementations of the present description. Figure 12 is a diagram illustrating a computer environment coupled with a user interface, in accordance with some implementations of the present description. DETAILED DESCRIPTION OF THE INVENTION CI 77 I n / C7n7 / R / VIAI Specific implementations will now be discussed in detail, examples of which are illustrated in the accompanying figures. The following detailed description sets forth numerous non-limiting specific details to aid in understanding the subject matter presented herein. However, it will be evident to a person skilled in the art that various alternatives can be used without departing from the scope of the claims, and the subject matter can be practiced without these specific details. For example, it will be evident to a person skilled in the art that the subject matter presented herein can be implemented in many types of electronic devices with digital video capabilities. Figure 1 is a block diagram illustrating an illustrative system 10 for encoding and decoding video blocks in parallel, in accordance with some implementations of the present description. As shown in Figure 1, the system 10 includes a source device 12 that generates and encodes video data to be decoded at a later time by a destination device 14. The source device 12 and destination device 14 can comprise any of a wide variety of electronic devices, including desktop or laptop computers, tablet computers, smartphones, set-top boxes, digital televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, or similar devices. In some implementations, the source device 12 and destination device 14 are equipped with wireless communication capabilities. In some implementations, the destination device 14 may receive the encoded video data to be decoded via a link 16. Link 16 may comprise any type of communication medium or device capable of moving the encoded video data from the source device 12 to the destination device 14. In one example, link 16 may comprise a communication medium to allow the source device 12 to transmit the encoded video data directly to the destination device 14 in real time. The encoded video data may be modulated according to a communication standard, such as a wireless communication protocol, and transmitted to the destination device 14. The communication medium may comprise any wireless or wired communication medium, such as a radio frequency (RF) spectrum or one or more physical transmission lines.The communication medium may 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 may include routers, switches, base stations, or any other equipment that may be useful in facilitating communication from the source device 12 to the destination device 14. In some other implementations, the encoded video data can be transmitted from output interface 22 to a storage device 32. Subsequently, the video data encoded on storage device 32 can be accessed by the destination device 14 through input interface 28. Storage device 32 can include any of a variety of distributed or accessed data storage media. CI 77 I n / C7n7 / R / VIAI locally, 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 a further example, storage device 32 could be a file server or other intermediate storage device that can hold the encoded video data generated by source device 12. Destination device 14 can access the video data stored on storage device 32 via streaming or download. The file server could be any type of computer capable of storing encoded video data and streaming the encoded video data to destination device 14.Illustrative file servers include a web server (e.g., for a website), an FTP server, network-attached storage (NAS) devices, or a local disk drive. The destination device 14 can access the encoded video data through any standard data connection, including a wireless channel (e.g., a Wi-Fi connection), a wired connection (e.g., DSL, cable modem, etc.), or a combination of both suitable for accessing encoded video data stored on a file server. The transmission of encoded video data from the storage device 32 can be a continuous stream, a download stream, or a combination of both. As shown in Figure 1, the source device 12 includes a video source 18, a video encoder 20, and an output interface 22. The video source 18 may include a source such as a video capture device, for example, a video camera, a video file containing previously captured video, a video streaming interface for receiving video from a video content provider, and / or a computer graphics system for generating computer graphics data as the source video, or a combination of such sources. For example, if the video source 18 is a video camera in a security surveillance system, the source device 12 and the destination device 14 may be camera phones or video phones. However, the implementations described in this application may be applicable to video encoding in general and may be applied to both wireless and / or wired applications. The captured, pre-captured, or computer-generated video can be encoded using the video encoder 20. The encoded video data can be transmitted directly to a destination device 14 via the output interface 22 of the source device 12. The encoded video data can also (or alternatively) be stored on the storage device 32 for later access by the destination device 14 or other devices for decoding and / or playback. The output interface 22 may also include a modem and / or a transmitter. CI 77 I n / C7n7 / R / VIAI The destination device 14 includes an input interface 28, a video decoder 30, and a display device 34. The input interface 28 may include a receiver and / or a modem and receive the encoded video data via link 16. The encoded video data communicated via link 16, or provided on the storage device 32, may include a variety of syntax elements generated by the video encoder 20 for use by the video decoder 30 in decoding the video data. Such syntax elements may be included within the encoded video data transmitted over a communication medium, stored on a storage medium, or stored on a file server. In some implementations, the target device 14 may include a display device 34, which may be an integrated display device and an external display device that is configured to communicate with the target device 14. The display device 34 displays the decoded video data to a user and may comprise any of a variety of display devices such as a liquid crystal display (LCD), a plasma display, an organic light-emitting diode (OLED) display, or another type of display device. The video encoder 20 and video decoder 30 can operate in accordance with proprietary or industry standards, such as VVC, HEVC, MPEG-4 Part 10, Advanced Video Coding (AVC), or extensions of such standards. It is understood that this application is not limited to any specific video encoding / decoding standard and may be applicable to other video encoding / decoding standards. It is generally envisaged that the video encoder 20 of the source device 12 can be configured to encode video data in accordance with any of these current or future standards. Similarly, it is also generally envisaged that the video decoder 30 of the destination device 14 can be configured to decode video data in accordance with any of these current or future standards. The video encoder 20 and video decoder 30 can each be implemented as any of a variety of suitable encoder circuits, such as one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), discrete logic, software, hardware, firmware, or any combination thereof. When partially implemented in software, an electronic 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 video encoding / decoding operations described herein. CI 77 I n / C7n7 / R / VIAI description. Each of the video encoder 20 and video decoder 30 may be included in one or more encoders or decoders, any of which may be integrated as part of a combined encoder / decoder (CODEC) in a respective device. Figure 2 is a block diagram illustrating an illustrative video encoder 20 in accordance with some implementations described in this application. The video encoder 20 can perform intra- and inter-predictive encoding of video blocks within video frames. Intra-predictive encoding relies on spatial prediction to reduce or eliminate spatial redundancy in video data within a given video frame or image. Inter-predictive encoding relies on temporal prediction to reduce or eliminate temporal redundancy in video data within adjacent video frames or images of a video sequence.As shown in Figure 2, the video encoder 20 includes video data memory 40, prediction processing unit 41, decoded image buffer (DPB) 64, adder 50, transformation processing unit 52, quantization unit 54, and entropy coding unit 56. The prediction processing unit 41 further includes motion estimation unit 42, motion compensation unit 44, splitting unit 45, intra-prediction processing unit 46, and intra-block copy (BC) unit 48. In some implementations, the video encoder 20 also includes inverse quantization unit 58, inverse transformation processing unit 60, and adder 62 for video block reconstruction.An unblocking filter (not shown) can be placed between the adder 62 and DPB 64 to filter block boundaries and remove blocking artifacts from the reconstructed video. A loop filter (not shown) can also be used in addition to the unblocking filter to filter the output of the adder 62. The video encoder 20 can take the form of a single fixed or programmable hardware unit, or it can be divided among one or more of the fixed or programmable hardware units illustrated. Video data memory 40 can store video data to be encoded by the video encoder components 20. The video data in video data memory 40 can be obtained, for example, from video source 18. DPB 64 is a buffer that stores reference video data for use in video data encoding by video encoder 20 (for example, in intra- or inter-predictive encoding modes). Video data memory 40 and DPB 64 can be comprised of any of a variety of memory devices. In some examples, the video data memory 40 may be on-chip with other video encoder components 20, or off-chip in relation to those components. As shown in Figure 2, after receiving video data, the splitting unit 45 within the prediction processing unit 41 splits the video data into blocks CI 77 I n / C7n7 / R / VIAI video partitioning. This partitioning can also include dividing a video frame into segments, tiles, or other larger encoding units (CUs) according to predefined partitioning structures, such as a quad-tree structure associated with the video data. The video frame can be divided into multiple video blocks (or sets of video blocks referred to as tiles). The prediction processing unit 41 can select one of a plurality of possible predictive coding modes, such as one of a plurality of intra-predictive coding modes or one of a plurality of inter-predictive coding modes, for the current video block based on error results (e.g., coding rate and distortion level). The prediction processing unit 41 can provide the resulting intra- or inter-prediction encoded block to adder 50 to generate a residual block and to adder 62 to reconstruct the encoded block for later use as part of a reference frame. The prediction processing unit 41 also provides syntax elements, such as motion vectors, intra-mode flags, partitioning information, and other similar syntax information, to the entropy coding unit 56. In order to select an appropriate intra-predictive coding mode for the current video block, the intra-prediction processing unit 46 within the prediction processing unit 41 can perform intra-predictive coding of the current video block with respect to one or more neighboring blocks in the same frame as the current block to be encoded to provide spatial prediction. The motion estimation unit 42 and the motion compensation unit 44 within the prediction processing unit 41 perform inter-predictive encoding of the current video block relative to one or more predictive blocks in one or more reference frames to provide temporal prediction. The video encoder 20 can perform multiple encoding passes, for example, to select an appropriate encoding mode for each block of video data. In some implementations, motion estimation unit 42 determines the interprediction mode for a current video frame by generating a motion vector. This vector indicates the displacement of a prediction unit (PU) in a video block within the current video frame relative to a predictive block within a reference video frame, according to a predetermined pattern within a sequence of video frames. Motion estimation, performed by motion estimation unit 42, is the process of generating motion vectors, which estimate the motion for video blocks. A motion vector, for example, can indicate the displacement of a PU in a video block within a current video frame or image relative to a predictive block within a reference frame. CI 77 I n / C7n7 / R / VIAI a reference frame (or other encoded unit) with respect to the current block being encoded within the current frame (or other encoded unit). The default pattern can designate video frames in the sequence as P frames or B frames. The intra BC unit 48 can determine vectors, for example, block vectors, for intra BC encoding in a manner similar to the determination of motion vectors by the motion estimation unit 42 for inter-prediction, or it can use the motion estimation unit 42 to determine the block vector. A predictive block is a block of a reference frame that is considered to closely match the unit pixel (UP) of the video block to be encoded in terms of pixel difference, which can be determined by sum of absolute difference (SAD), sum of squared difference (SSD), or other difference metrics. In some implementations, the Video Encoder 20 can compute values ​​for subinteger pixel positions of reference frames stored in DPB 64. For example, the Video Encoder 20 can interpolate values ​​for quarter-pixel positions, eighth-pixel positions, or other fractional pixel positions of the reference frame.Therefore, the motion estimation unit 42 can perform a motion search relative to whole pixel positions and fractional pixel positions and generate a motion vector with fractional pixel accuracy. The motion estimation unit 42 calculates a motion vector for a PU of a video block in an inter-prediction encoded frame by comparing the position of the PU with the position of a predictive block of a reference frame selected from a first list of reference frames (List 0) or a second list of reference frames (List 1), each of which identifies one or more reference frames stored in DPB 64. The motion estimation unit 42 sends the calculated motion vector to the motion compensation unit 44 and then to the entropy encoding unit 56. Motion compensation, performed by motion compensation unit 44, may involve searching for or generating the predictive block based on the motion vector determined by motion estimation unit 42. Upon receiving the motion vector for the current video block's PU, motion compensation unit 44 can locate a predictive block to which the motion vector points in one of the reference frame lists, retrieve the predictive block from DPB 64, and forward the predictive block to adder 50. Adder 50 then forms a residual video block of pixel difference values ​​by subtracting the pixel values ​​from the predictive block provided by motion compensation unit 44 from the pixel values ​​of the current video block being encoded. The pixel difference values ​​that form the residual video block may include components of CI 77 I n / C7n7 / R / VIAI difference in luma or chroma of both. The motion compensation unit 44 can also generate syntax elements associated with the video blocks of a video frame for use by the video decoder 30 in decoding the video blocks of the video frame. Syntax elements may include, for example, syntax elements that define the motion vector used to identify the predictive block, any flags that indicate the prediction mode, or any other syntax information described herein. Note that the motion estimation unit 42 and the motion compensation unit 44 may be highly integrated, but are illustrated separately for conceptual purposes. In some implementations, the BC 48 intra unit can generate vectors and retrieve predictive blocks in a manner similar to that described above in connection with the motion estimation unit 42 and the motion compensation unit 44, but with the predictive blocks in the same frame since the actual block is encoded and the vectors are referred to as block vectors as opposed to motion vectors. Specifically, the BC 48 intra unit can determine an intra-prediction mode to use for encoding a current block. In some examples, the BC 48 intra unit can encode an actual block using several intra-prediction modes, for example, during separate encoding passes, and test its performance through a velocity distortion analysis.Next, the BC 48 intra unit can select, from among the various tested intra prediction modes, an appropriate intra prediction mode to use and generate an intra mode indicator accordingly. For example, the BC 48 intra unit can calculate velocity distortion values ​​using velocity distortion analysis for the various tested intra prediction modes and select the intra prediction mode with the best velocity distortion characteristics as the appropriate BC intra mode to use. Velocity distortion analysis typically determines the amount of distortion (or error) between a coded block and the original uncoded block that was encoded to produce the coded block, as well as the bit rate (i.e., number of bits) used to produce the coded block. The BC 48 intra unit can then calculate ratios from the distortions and velocities for the various coded blocks to determine which intra prediction mode exhibits the best velocity distortion value for the block. In other examples, the intra-BC unit 48 can use the motion estimation unit 42 and the motion compensation unit 44, in whole or in part, to perform such functions for intra-BC prediction with the implementations described herein. In any case, for intra-block copying, a predictive block can be a block that is considered to closely match the block to be encoded, in terms of pixel difference, which can be determined by summing the absolute differences. CI 77 I n / C7n7 / R / VIAI (SAD), the sum of squared differences (SSD), or other difference metrics, and the identification of the predictive block may include calculating values ​​for subinteger pixel positions. Whether the predictive block is from the same frame in accordance with intra-prediction, or from a different frame in accordance with inter-prediction, the video encoder 20 can form a residual video block by subtracting the pixel values ​​of the predictive block from the pixel values ​​of the currently encoded video block, forming pixel difference values. The pixel difference values ​​that form the residual video block can include differences in both luma and chroma components. The intra-prediction processing unit 46 can intra-predict a current video block, as an alternative to the inter-prediction performed by the motion estimation unit 42 and the motion compensation unit 44, or the intra-block copy prediction performed by the intra-BC unit 48, as described above. In particular, the intra-prediction processing unit 46 can determine an intra-prediction mode to use for encoding a current block. To do this, the intra-prediction processing unit 46 can encode a real block using various intra-prediction modes, for example, during separate encoding passes, and the intra-prediction processing unit 46 (or a mode selection unit, in some examples) can select an appropriate intra-prediction mode to use from among the tested intra-prediction modes. The intra-prediction processing unit 46 can provide information indicative of the selected intra-prediction mode for the block to the entropy coding unit 56. The entropy coding unit 56 can encode the information indicating the selected intra-prediction mode into the bit stream. After the prediction processing unit 41 determines the predictive block for the current video block through inter-prediction or intra-prediction, the adder 50 forms a residual video block by subtracting the predictive block from the current video block. The residual video data in the residual block can be included in one or more transformation units (TUs) and is provided to the transformation processing unit 52. The transformation processing unit 52 transforms the residual video data into residual transformation coefficients using a transform, such as a discrete cosine transform (DCT) or a conceptually similar transform. The transformation processing unit 52 can send the resulting transformation coefficients to the quantization unit 54. The quantization unit 54 quantizes the transformation coefficients to further reduce the bit rate. The quantization process can also reduce the bit depth associated with some or all of the CI 77 I n / C7n7 / R / VIAI coefficients. The degree of quantization can be modified by adjusting a quantization parameter. In some examples, the quantization unit 54 can then perform a scan of an array that includes the quantized transformation coefficients. Alternatively, the entropy coding unit 56 can perform the scan. After quantization, the entropy coding unit 56 entropy-encodes the quantized transformation coefficients into a video bitstream using, for example, context-adaptive variable-length coding (CAVLC), context-adaptive binary arithmetic (CAB AC), syntax-based binary arithmetic (SBAC), probability interval partitioning (PIPE) entropy coding, or another entropy-coding methodology or technique. The encoded bitstream can then be transmitted to the video decoder 30 or archived to the storage device 32 for later transmission or retrieval by the video decoder 30.The entropy encoding unit 56 can also entropy encode the motion vectors and other syntax elements for the current video frame being encoded. The inverse quantization unit 58 and the inverse transform processing unit 60 apply inverse quantization and inverse transform, respectively, to reconstruct the residual video block in the pixel domain to generate a reference block for predicting other video blocks. As noted earlier, the motion compensation unit 44 can generate a motion-compensated predictive block from one or more reference blocks of the frames stored in DPB 64. The motion compensation unit 44 can also apply one or more interpolation filters to the predictive block to calculate subinteger pixel values ​​for use in motion estimation. Adder 62 adds the reconstructed residual block to the motion-compensated predictive block produced by the motion compensation unit 44 to produce a reference block for storage in DPB 64. The reference block can then be used by the intra BC unit 48, motion estimation unit 42, and motion compensation unit 44 as a predictive block to interpredict another video block in a subsequent video frame. Figure 3 is a block diagram illustrating an illustrative video decoder 30 according to some implementations of this application. The video decoder 30 includes video data memory 79, entropy coding unit 80, prediction processing unit 81, inverse quantization unit 86, inverse transform processing unit 88, adder 90, and DPB 92. The prediction processing unit 81 further includes motion compensation unit 82, intra- CI 77 I n / C7n7 / R / VIAI prediction 84, and intra BC unit 85. The video decoder 30 can perform a decoding process generally reciprocal to the encoding process described above with respect to the video encoder 20 in connection with Figure 2. For example, the motion compensation unit 82 can generate prediction data based on motion vectors received from the entropy encoding unit 80, while the intra prediction unit 84 can generate prediction data based on intra prediction mode indicators received from the entropy encoding unit 80. In some examples, the implementations described herein may be assigned to a single video decoder unit 30. Furthermore, in some examples, the implementations described herein may be divided among one or more of the video decoder units 30. For example, the intra BC 85 unit may perform the implementations described herein, either alone or in combination with other video decoder units 30, such as the motion compensation unit 82, the intra prediction processing unit 84, and the entropy coding unit 80. In some examples, the video decoder 30 may not include an intra BC 85 unit, and the functionality of the intra BC 85 unit may be performed by other components of the prediction processing unit 81, such as the motion compensation unit 82. Video data memory 79 can store video data, such as a stream of encoded video bits, to be encoded by the other components of video decoder 30. The video data stored in data memory 79 can be obtained, for example, from storage device 32, from a local video source such as a camera, or via wired or wireless network video data communication, or by accessing physical data storage media (for example, a flash drive or hard disk). Video data memory 79 can include a coded picture buffer (CPB) that stores encoded video data from a stream of encoded video bits.The decoded image buffer (DPB) 92 of video decoder 30 stores reference video data for use when decoding video data by video decoder 30 (for example, intra- or inter-predictive coding modes). The video data buffer 79 and DPB 92 can be formed by 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. For illustrative purposes, video data memory 79 and DPB 92 are shown as two separate components of video decoder 30 in Figure 3. But it will be evident to a person skilled in the art that video data memory 79 and DPB 92 can be provided by the same device. IC 77 I n / C7n7 / R / VIAI separate memory or memory devices. In some examples, the video data memory 79 may be on-chip with other components of the video decoder 30, or off-chip relative to those components. During the decoding process, video decoder 30 receives a stream of encoded video bits representing video blocks from an encoded video frame and associated syntax elements. Video decoder 30 can receive the syntax elements at the video frame level and / or the video block level. Entropy decoding unit 80 of video decoder 30 entropy-decodes the bit stream to generate quantized coefficients, motion vectors or intra-prediction mode indicators, and other syntax elements. Entropy decoding unit 80 then sends the motion vectors and other syntax elements to prediction processing unit 81. When the video frame is encoded as an intra-predictive encoded frame (I) or for intra-encoded predictive blocks in other frame types, the intra-prediction processing unit 84 of the prediction processing unit 81 can generate prediction data for a video block of the current video frame based on a signaled intra-prediction mode and reference data from previously decoded blocks of the current frame. When the video frame is encoded as an inter-predictive encoded frame (i.e., B or P), the motion compensation unit 82 of the prediction processing unit 81 produces one or more predictive blocks for a video block of the current video frame based on motion vectors and other syntax elements received from the entropy decoding unit 80. Each of the predictive blocks can be produced from a reference frame within one of the reference frame lists. The video decoder 30 can construct the reference frame lists, List 0 and List 1, by using predefined construction techniques based on reference frames stored in DPB 92. In some examples, when the video block is encoded in accordance with the intra BC mode described herein, the intra BC unit 85 of the prediction processing unit 81 produces predictive blocks for the current video block based on block vectors and other syntax elements received from the entropy decoding unit 80. The predictive blocks may be within a reconstructed region of the same image as the current encoding block defined by the video encoder 20. The motion compensation unit 82 and / or intra BC unit 85 determines prediction information for a video block from the current video frame by analyzing motion vectors and other syntax elements, and then uses this prediction information to produce predictive blocks for the current video block being decoded. For example, motion compensation unit 82 uses some of the received syntax elements to CI 77 I n / C7n7 / R / VIAI determine a prediction mode (e.g., intra or inter prediction) used to encode video blocks of the video frame, an inter prediction frame type (e.g., B or P), construction information for one or more of the reference frame lists for the frame, motion vectors of each inter-predictive encoded video block of the frame, inter-prediction state of each inter-predictive encoded video block of the frame, and other information for decoding the video blocks in the current video frame. Similarly, the intra BC 85 unit can use some of the received syntax elements, for example, a flag, to determine that the current video block was predicted using intra BC mode, the construction information of those video blocks of the frame are within the reconstructed region and should be stored in DPB 92, block vectors for each video block predicted by intra BC of the frame, intra BC prediction state for each video block predicted by intra BC of the frame, and other information to decode the video blocks in the current video frame. Motion compensation unit 82 can also perform interpolation by using interpolation filters as employed by video encoder 20 during video block encoding to calculate interpolated values ​​for subinteger pixels of reference blocks. In this case, motion compensation unit 82 can determine the interpolation filters used by video encoder 20 from the received syntax elements and use those filters to produce predictive blocks. The inverse quantization unit 86 inversely quantizes the quantized transformation coefficients provided in the bit stream and entropy-decoded by the entropy-decoding unit 80 by using the same quantization parameter calculated by the video encoder 20 for each video block in the video frame to determine a degree of quantization. The inverse transformation processing unit 88 applies an inverse transformation, for example, an inverse DCT, an inverse integer transformation, or a conceptually similar inverse transformation process, to the transformation coefficients in order to reconstruct the remaining blocks in the pixel domain. After the motion compensation unit 82 or intra BC unit 85 generates the predictive block for the current video block based on the vectors and other syntax elements, the adder 90 reconstructs the decoded video block for the current video block by adding the residual block from the inverse transform processing unit 88 and a corresponding predictive block generated by the motion compensation unit 82 and the intra BC unit 85. A loop filter (not illustrated) can be placed between the adder 90 and DPB 92 to further process the decoded video block. The decoded video blocks in a given frame are then stored in DPB 92, which stores the reference frames used for CI 77 I n / C7n7 / R / VIAI subsequent motion compensation of the following video blocks. The DPB 92, or a separate memory device from the DPB 92, can also store decoded video for later display on a display device, such as display device 94 in Figure 1. In a typical video encoding process, a video sequence typically includes an ordered set of frames or images. Each frame may include three sets of samples, denoted SL, SCb, and SCr. SL is a two-dimensional set of luma samples. SCb is a two-dimensional set of chroma samples (Cb). SCr is a two-dimensional set of chroma samples (Cr). In other cases, a frame may be monochromatic and therefore include only a two-dimensional set of luma samples. As shown in Figure 4A, the video encoder 20 (or more specifically, partitioning unit 45) generates an encoded representation of a frame by first dividing the frame into a set of encoding tree units (CTUs). A video frame can include any number of CTUs arranged sequentially in a raster scan order from left to right and top to bottom. Each CTU is a larger logical encoding unit, and the width and height of the CTU are signaled by the video encoder 20 in a set of sequence parameters, such that all CTUs in a video sequence are the same size as one that is 128 x 128, 64 x 64, 32 x 32, and 16 x 16. However, it should be noted that the present application is not necessarily limited to a particular size.As shown in Figure 4B, each CTU can comprise one luma sample encoding tree (CTB) block, two corresponding chroma sample encoding tree blocks, and syntax elements used to encode the samples in the encoding tree blocks. The syntax elements describe properties of different unit types within an encoded pixel block and how the video sequence can be reconstructed in the video decoder, including inter- or intra-prediction, intra-prediction mode, motion vectors, and other parameters. In monochrome images or images with three separate color planes, a CTU can comprise a single encoding tree block and the syntax elements used to encode the samples within that block. A decoding tree block can be an NxN block of samples. To achieve better performance, the video encoder 20 can recursively perform tree partitioning, such as binary tree partitioning, quad tree partitioning, or a combination of both, on the CTU's decoding tree blocks and divide the CTU into smaller encoding units (CUs). As illustrated in Figure 4C, the 64x64 CTU 400 is first partitioned into four smaller CUs, each with a block size of 32x32. Among these four smaller CUs, CU 410 and CU 420 are each further divided into four 16x16 CUs by block size. The two 16x16 CUs 434 and 440 are then further divided. CI 77 I n / C7n7 / R / VIAI is further divided into four 8x8 CUs by block size. Figure 4D illustrates a quad-tree data structure that illustrates the final result of the partitioning process of CTU 400 as illustrated in Figure 4C, where each leaf node of the quad-tree corresponds to a CU of a respective size ranging from 32x32 to 8x8. Similar to the CTU illustrated in Figure 4B, each CU may comprise one encoding block (CB) of luma samples and two corresponding encoding blocks of chroma samples of a frame of the same size, and syntax elements used to encode the samples in the encoding blocks. In monochrome images or images that have three separate color planes, a CU may comprise a single encoding block and syntax structures used to encode the samples in the encoding block. In some implementations, the Video Encoder 20 can further divide a CU's encoding block into one or more MxN prediction blocks (PBs). A prediction block is a rectangular (square or non-square) block of samples to which the same prediction, either between or within, is applied. A prediction unit (PU) in a CU can comprise a luma sample prediction block, two corresponding chroma sample prediction blocks, and syntax elements used to predict the prediction blocks. In monochrome images or images with three separate color planes, a PU can comprise a single prediction block and syntax structures used to predict the prediction block. The Video Encoder 20 can generate luma predictive blocks (CBs) and chroma predictive blocks (CRs) for luma, prediction CBs, and CRs for each P1 in the CU. The Video Encoder 20 can use intra-prediction or inter-prediction to generate predictive blocks for a PU. If the Video Encoder 20 uses intra-prediction to generate the predictive blocks for a PU, it can generate the PU's predictive blocks based on decoded samples from the frame associated with the PU. If the Video Encoder 20 uses inter-prediction to generate the predictive blocks for a PU, it can generate the PU's predictive blocks based on decoded samples from one or more frames other than the frame associated with the PU. After the video encoder 20 generates predictive luma blocks, Cb and Cr, for one or more PUs of a CU, the video encoder 20 can generate a luma residual block for the CU by subtracting the CU's predictive luma blocks from its original luma encoding block, such that each sample in the CU's luma residual block indicates a difference between a luma sample in one of the CU's predictive luma blocks and a corresponding sample in the CU's original luma encoding block. Similarly, the video encoder 20 can generate a Cb residual block and a Cr residual block for the CU, respectively, such that each sample in the CU's Cb residual block indicates a difference between a Cb sample in one of the CU's predictive Cb blocks and a corresponding sample in the CU's original Cb encoding block. CI 77 I n / C7n7 / R / VIAI each sample in the residual Cr block of CU can indicate a difference between a Cr sample in one of the predictive Cr blocks of CU and a corresponding sample in the original Cr coding block of CU. Furthermore, as illustrated in Figure 4C, the video encoder 20 can use quad-tree partitioning to decompose the luma Cb and Cr residual blocks of a CU into one or more luma Cb and Cr transform blocks. A transform block is a rectangular (square or non-square) block of samples to which the same transformation is applied. A transform unit (TU) of a CU can comprise a luma sample transform block, two corresponding chroma sample transform blocks, and syntax elements used to transform the transform block samples. Thus, each TU of a CU can be associated with a luma transform block, a Cb transform block, and a Cr transform block. In some examples, the luma transform block associated with the TU can be a subblock of the CU's luma residual block.The Cb transformation block can be a subblock of the Cb residual block of CU. The Cr transformation block can be a subblock of the Cr residual block of CU. In monochrome images or images with three separate color planes, a TU can comprise a single transformation block and syntax structures used to transform the samples within the transformation block. The video encoder 20 can apply one or more transformations to a luma transformation block of a TU to generate a luma coefficient block for the TU. A coefficient block can be a two-dimensional set of transformation coefficients. A transformation coefficient can be a scalar quantity. The video encoder 20 can apply one or more transformations to a Cb transformation block of a TU to generate a Cb coefficient block for the TU. The video encoder 20 can apply one or more transformations to a Cr transformation block of a TU to generate a Cr coefficient block for the TU. After generating a coefficient block (for example, a luma coefficient block, a Cb coefficient block, or a Cr coefficient block), the Video Encoder 20 can quantize the coefficient block. Quantization generally refers to a process in which transformation coefficients are quantized to potentially reduce the amount of data used to represent the transformation coefficients, providing additional compression. After the Video Encoder 20 quantizes a coefficient block, it can entropy-encode syntax elements that indicate the quantized transformation coefficients. For example, the Video Encoder 20 can perform context-adaptive binary arithmetic (CABAC) encoding on the syntax elements that indicate the quantized transformation coefficients. Finally, the Video Encoder 20 can send a CI 77 I n / C7n7 / R / VIAI bit stream that includes a bit sequence that forms a representation of encoded frames and associated data, which is either stored on storage device 32 or transmitted to destination device 14. After receiving a bitstream generated by video encoder 20, video decoder 30 can analyze the bitstream to obtain syntax elements. Video decoder 30 can reconstruct the video data frames based, at least in part, on the syntax elements obtained from the bitstream. The process of reconstructing the video data is generally the reciprocal of the encoding process performed by video encoder 20. For example, video decoder 30 can perform inverse transformations on the coefficient blocks associated with TUs of a current CU to reconstruct residual blocks associated with the TUs of the current CU. Video decoder 30 also reconstructs the encoding blocks of the current CU by adding samples from the predictive blocks for PUs of the current CU to corresponding samples from the transformation blocks of the TUs of the current CU.After rebuilding the encoding blocks for each CU of a frame, the video decoder 30 can rebuild the frame. As noted earlier, video coding achieves video compression primarily using two modes: intra-frame prediction (or intra-prediction) and inter-frame prediction (or inter-prediction). It should be noted that IBC could be considered either intra-frame prediction or a third mode. Between the two modes, inter-frame prediction contributes more to coding efficiency than intra-frame prediction because it uses motion vectors to predict a current video block from a reference video block. However, with video data capture technology constantly improving and video block sizes becoming more refined to preserve detail in the video data, the amount of data required to represent motion vectors for a current frame also increases substantially. One way to overcome this challenge is to take advantage of the fact that not only does a group of neighboring control units (CUs) in both spatial and temporal domains have similar video data for prediction purposes, but the motion vectors between these neighboring CUs are also similar. Therefore, it is possible to use motion information from spatially neighboring and / or temporally collected CUs as an approximation of the motion information (e.g., motion vector) of a current CU by exploring their spatial and temporal correlation, which is also referred to as the motion vector predictor (MVP) of the current CU. CI 77 I n / C7n7 / R / VIAI Instead of encoding, in the video bitstream, a current motion vector of the current CU, determined by motion estimation unit 42 as described earlier in connection with Figure 2, is subtracted from the actual motion vector of the current CU by the motion vector predictor to produce a motion vector difference (MVD) for the current CU. By doing so, there is no need to encode the motion vector determined by motion estimation unit 42 for each CU in a frame in the video bitstream, and the amount of data used to represent motion information in the video bitstream can be significantly reduced. Similar to the process of choosing a predictive block in a reference frame during inter-frame prediction of a current block, a set of rules needs to be adopted by both the video encoder 20 and the video decoder 30 to build a motion vector candidate list (also known as a merge list) for a current CU that uses those potential candidate motion vectors associated with spatially neighboring CUs and / or temporally placed CUs of the current CU and then select a member of the motion vector candidate list as a motion vector predictor for the current CU.By doing so, there is no need to transmit the same motion vector candidate list between video encoder 20 and video decoder 30, and an index of the selected motion vector predictor within the motion vector candidate list is sufficient for video encoder 20 and video decoder 30 to use the same motion vector predictor within the motion vector candidate list to encode and decode the current CU. In some implementations, each interprediction CU has three motion vector prediction modes: inter (also referred to as advanced motion vector prediction, or AMVP), jump, and merge, to build the motion vector candidate list. Under each mode, one or more motion vector candidates can be added to the candidate list according to the algorithms described below. Finally, one of these candidates is used as the interprediction CU's best motion vector predictor to be encoded into the video bitstream by video encoder 20 or decoded from the video bitstream by video decoder 30.To find the best motion vector predictor from the list of candidates, a motion vector competition scheme (MVC) is introduced to select a motion vector from a given set of motion vector candidates, i.e., the motion vector candidate list, which includes spatial and temporal motion vector candidates. In addition to deriving motion vector predictor candidates from spatially neighboring and temporally located CUs, motion vector predictor candidates can also be derived from the so-called history-based motion vector prediction (HMVP) table. The HMVP table contains a predefined number CI 77 I n / C7n7 / R / VIAI of motion vector predictors, each of which has been used to encode / decode a particular CU from the same CTU row (or sometimes the same CTU). Due to the spatial / temporal proximity of this CU, there is a high probability that one of the motion vector predictors in the HMVP box can be reused to encode / decode different CUs within the same CTU row. Therefore, it is possible to achieve higher coding efficiency by including the HMVP box in the process of reconstructing the motion vector candidate list. In some implementations, the HMVP frame has a fixed length (for example, 5) and is handled in a near first-in, first-out (FIFO) manner. For example, a motion vector for a CU is reconstructed when an Intercode block in the CU is decoded. The HMVP frame is updated immediately with the reconstructed motion vector because this motion vector could be the motion vector predictor for a subsequent CU. When the HMVP frame is updated, there are two scenarios: (i) the reconstructed motion vector is different from other existing motion vectors in the HMVP frame, or (ii) the reconstructed motion vector is the same as one of the existing motion vectors in the HMVP frame. For the first scenario, the reconstructed motion vector is added to the HMVP frame as the newest, and the HMVP frame is not complete.If the HMVP frame is already full, the oldest move vector in the HMVP frame needs to be removed before the reconstructed move vector is added as the newest one. In other words, the HMVP frame in this case is similar to a FIFO buffer, such that the move information located at the top of the FIFO buffer and associated with another previously intercoded block is moved out of the buffer so that the reconstructed move vector is appended to the tail of the FIFO buffer as the newest member in the HMVP frame. For the second scenario, the existing move vector in the HMVP frame that is substantially identical to the reconstructed move vector is removed from the HMVP frame before the reconstructed move vector is added as the newest one.If the HMVP frame is also maintained in the form of a FIFO buffer, the motion vector predictors after the identical motion vector in the HMVP frame are moved forward by one item to occupy the space left by the removed motion vector and the reconstructed motion vector is then appended to the tail of the FIFO buffer as the newest member in the HMVP frame. The motion vectors in the HMVP frame could be added to the motion vector candidate lists under different prediction modes such as AMVP, merge, jump, etc. It has been found that motion information from previously intercoded blocks stored in the HMVP frame, even those not adjacent to the current block, can be used for CI 77 I n / C7n7 / R / VIAI more efficient motion vector prediction. After an MVP candidate is selected from the given set of motion vector candidates for a current CU, the video encoder 20 can generate one or more syntax elements for the corresponding MVP candidate and encode them into the video bitstream so that the video decoder 30 can retrieve the MVP candidate from the video bitstream using the syntax elements. Depending on the specific mode used to construct the set of motion vector candidates, different modes (e.g., AMVP, merge, jump, etc.) have different sets of syntax elements. For AMVP mode, the syntax elements include inter-prediction flags (List 0, List 1, or bidirectional prediction), reference indices, motion vector candidate indices, motion vector prediction residual signal, and so on.For jump mode and merge mode, only merge indices are encoded in the bitstream because the current CU inherits the other syntax elements, including interprediction flags, reference indices, and move vectors, from a neighboring CU named by the encoded merge index. In the case of a jump-encoded CU, the residual move vector prediction signal is also omitted. Figure 5A is a block diagram illustrating spatially neighboring and temporally placed block positions of a current CU that is to be encoded / decoded according to some implementations of this description. For a given mode, a list of motion vector prediction (MVP) candidates is constructed by first checking the availability of motion vectors associated with the spatially left and upper neighboring block positions, and the availability of motion vectors associated with temporally placed block positions, and then the motion vectors in the HMVP box. During the process of constructing the MVP candidate list, some redundant MVP candidates are removed from the candidate list, and, if necessary, the zero-valued motion vector is added to give the candidate list a fixed length (note that different modes can have different fixed lengths).After the MVP candidate list is built, the video encoder 20 can select the best motion vector predictor from the candidate list and encode the corresponding index indicating the chosen candidate in the video bit stream. Using Figure 5A as an example and assuming that the candidate list has a fixed length of two, the current CU's motion vector predictor (MVP) candidate list can be constructed by performing the following steps in order under AMVP mode: 1) Selection of MVP candidates from spatially neighboring CUs a) Derive up to an unscaled MVP candidate from one of the two neighboring CUs CI 77 I n / C7n7 / R / VIAI left spatial starting with A0 and ending with Al; b) If no unscaled left MVP candidate is available in the previous step, derive up to a scaled MVP candidate from one of the two left spatial neighboring CUs starting with A0 and ending with Al; c) Derive up to an unscaled MVP candidate from one of the three upper spatial neighboring CUs starting with B0, then B1, and ending with B2; d) If neither A0 nor Al is available or if they are encoded in intra-mode, derive up to a scaled MVP candidate from one of the three upper spatial neighboring CUs starting with B0, then Bl, and ending with B2; 2) If two MVP candidates are found in the previous steps and are identical, remove one of the two candidates from the MVP candidate list; 3) Selection of CU MVP candidates temporarily placed a) If the list of MVP candidates after the previous step does not include two MVP candidates, derive up to one MVP candidate from the temporarily placed CUs (e.g., TO) 4) Selection of MVP candidates from the HMVP pool a) If the list of MVP candidates after the previous step does not include two MVP candidates, derive up to two MVPs based on the history of the MVP table; and 5) If the MVP candidate list after the previous step does not include two MVP candidates, add up to two zero-value MVPs to the MVP candidate list. Since there are only two candidates in the previously constructed AMVP mode MVP candidate list, a syntax element associated with a binary flag is encoded in the bitstream to indicate which of the two MVP candidates within the candidate list is used to decode the current CU. In some implementations, the MVP candidate list for the current CU under jump or merge mode can be constructed by performing a similar set of steps in a similar order to those described above. Note that a special type of merge candidate called a pair-type merge candidate is also introduced into the MVP candidate list for jump or merge mode. The pair-type merge candidate is generated by averaging the MVPs of the two previously derived merge-mode move vector candidates. The size of the merge MVP candidate list (for example, from 1 to 6) is indicated in a segment header of the current CU. For each CU in merge mode, an index of the best merge candidate is encoded using truncated unit binarization (TU). The first container of the merge index is context-encoded, and deviation encoding is used for other containers. As mentioned earlier, history-based MVPs can be added to either the AMVP mode MVP candidate list or the merge MVP candidate list. CI 77 I n / C7n7 / R / VIAI after the spatial MVP and temporal MVP. The motion information of a previously intercoded CU is stored in the HMVP frame and used as an MVP candidate for the current CU. The HMVP frame is maintained during the encoding / decoding process. Whenever an intercoded CU that is not a sub-block exists, the associated motion vector information is added to the last entry of the HMVP frame as a new candidate, while the motion vector information stored in the first entry of the HMVP frame is removed from there (if the HMVP frame is already full and there is no identical duplicate of the associated motion vector information in the frame). Alternatively, the identical duplicate of the associated motion vector information is removed from the frame before the associated motion vector information is added to the last entry of the HMVP frame. As noted earlier, intra-block copying (IBC) can significantly improve the encoding efficiency of screen content materials. Since ICC is implemented as a block-level encoding mode, block matching (BM) is performed in the video encoder to find an optimal block vector for each CU. Here, a block vector is used to indicate the offset from the current block to a reference block, which has already been reconstructed within the current image. An IBC-encoded CU is treated as a third prediction mode, distinct from intra- or inter-prediction modes. At the CU level, the IBC mode can be referred to as an IBC AMVP mode or an IBC jump / fusion mode as follows: - IBC AMVP Mode: A block vector difference (BVD) between the actual block vector of a CU and a block vector predictor of the selected CU from the CU's block vector candidates is encoded in the same way that a motion vector difference is encoded under the AMVP mode described above. The block vector prediction method uses two block vector candidates as predictors, one left neighbor and one upper neighbor (if encoded by IBC). When neither block is available, a default block vector will be used as a block vector predictor. A binary flag is flagged to indicate the block vector predictor index. The IBC AMVP candidate list consists of spatial and HMVP candidates. - IBC hop / merge mode: A merge candidate index is used to indicate which of the block vector candidates in the merge candidate list (also known as a merge list) of neighboring IBC-encoded blocks to join to predict the block vector for the current block. The IBC merge candidate list consists of spatial, HMVP, and pairwise candidates. CI 77 I n / C7n7 / R / VIAI Another approach to improving encoding efficiency adopted by the cutting-edge encoding standard is to introduce parallel processing into the video encoding / decoding process, for example, by using a multi-core processor. For instance, Wavefront Parallel Processing (WPP) has already been introduced in HEVC as a feature for encoding or decoding multi-row CTUs in parallel when using multiple strings. Figure 5B is a block diagram illustrating the encoding of multiple strings of multiple rows of CTUs from an image using wavefront parallel processing (WPP) in accordance with some implementations of this description. When WPP is enabled, it is possible to process multiple rows of CTUs in parallel in a wavefront shape, where there can be a delay of two CTUs between the start of two neighboring wavefronts. For example, to encode image 500 using WPP, a video encoder, such as a video encoder 20 and video decoder 30, can divide the encoding tree units (CTUs) of image 500 into a plurality of wavefronts, each wavefront corresponding to a respective row of CTUs in the image. The video encoder can begin encoding a higher wavefront, for example, by using a first encoder core or string.After the video encoder has encoded two or more CTUs (the upper wavefront), it can begin encoding a second wavefront in parallel with the encoding of the wavefront above, for example, by using a second parallel encoder core or chain. After the video encoder has encoded two or more CTUs of the second wavefront from the top, it can begin encoding a third wavefront in parallel with the encoding of the wavefronts above, for example, by using a third parallel encoder core or chain. This pattern can continue down to the wavefronts in Figure 500. In this description, a set of CTUs that the video encoder is currently encoding, using WPP, is referred to as a CTU group.In this way, when the video encoder uses WPP to encode an image, each CTU in the group of CTUs can belong to a single wavefront of the image, and the CTU can be shifted from one CTU in a respective wavefront, above by at least two columns of CTUs in the image. The video encoder can initiate a context for a current wavefront to perform context-adaptive binary arithmetic (CABAC) encoding of the current wavefront based on data from the first two blocks of the upstream wavefront, as well as one or more elements of a segment header for a segment that includes the first code block of the current wavefront. The video encoder can perform CABAC initiation of a subsequent wavefront (or CTU row) by using context states after encoding two CTUs from one CTU row onto the subsequent CTU row. In other words, after starting to encode a wavefront According to CI 77 I n / C7n7 / R / VIAI, a video encoder (or more specifically, a video encoder string) can encode at least two blocks of a wavefront over the current wavefront, assuming the current wavefront is not the top CTU row of an image. The video encoder can then initiate a CABAC context of the current wavefront after encoding at least two blocks of a wavefront over the current wavefront. In this example, each CTU row of image 500 is a separate partition and has an associated string (WPP1 string, WPP2 string, ...) so that the number of CTU rows in image 500 can be encoded in parallel. Due to the current implementation of the HMVP frame, which uses a global motion vector (MV) buffer to store previously reconstructed motion vectors, this HMVP frame cannot be implemented in the WPP-enabled parallel encoding scheme described earlier in connection with Figure 5B. In particular, the fact that the global MVP buffer is shared by all strings in a video encoder's encoding / decoding process prevents WPP strings after the first WPP string (i.e., WPP1 string) from starting, since these WPP strings have to wait for the HMVP frame to update the last CTU (i.e., the rightmost CTU) of the first WPP string (i.e., the first row of CTUs) to complete. To overcome this problem, it is proposed that the global MVP buffer shared by WPP strings be replaced with multiple buffers dedicated to CTU rows, such that each CTU row wavefront has its own buffer to store an HMVP frame corresponding to the CTU row being processed by a corresponding WPP sequence when WPP is enabled in the video encoder. It is noted that each CTU row having its own HMVP frame is equivalent to resetting the HMVP frame before encoding the first CTU in the CTU row. The HMVP frame reset is used to flow all motion vectors into the HMVP frame resulting from encoding another CTU row. In one implementation, the reset operation sets the size of the motion vector predictors available in the HMVP frame to zero.Even in another implementation, the reset operations could be set to an invalid value such as -1, with the reference index of all entries in the HMVP box. By doing so, the construction of the MVP candidate list of a current CTU within a particular wavefront—regardless of which of the three modes (AMVP, merge, and jump)—depends on the HMVP box associated with a WPP chain processing that particular wavefront. There is no interdependence between different wavefronts other than the two-CTU delay described earlier and the construction of motion vector candidate lists associated with different wavefronts, which can proceed in parallel as the WPP process illustrated in Figure 5B. In other words, at the start of processing a particular wavefront, the HMVP box is reset to empty. CI 77 I n / C7n7 / R / VIAI affects the encoding of another CTU wavefront by another WPP sequence. In some cases, the HMVP frame may be reset to empty before the encoding of each individual CTU. In such a case, the motion vectors in the HMVP frame are limited to a particular CTU, and there is likely a higher probability of a motion vector within the HMVP frame being selected as a motion vector for a current CU within that particular CTU. In some examples, intra-prediction modes with wide-angle intra-directions are further described. A set of pre-decoded samples adjacent to a current CU (i.e., above or to the left) is used to predict CU samples. However, to capture finer edge directions present in natural video (especially for high-resolution video content, e.g., 4K), the number of angular intra-modes extends from 33 in HEVC to 93 in VVC. In addition to angular directions, the flat mode (which assumes a gradually changing surface with horizontal or vertical tilt derived from the boundary) and DC mode (which assumes a flat surface) are also applied. Figure 5C is a block diagram illustrating intra-modes as defined in the VVC standard in accordance with some implementations of this description.Figure 5D is a block diagram illustrating a set of reconstructed samples neighboring the current block as the reference for intra-prediction, in accordance with some implementations of this description. All intra-modes (i.e., planar, DC, and angular directions) use a set of reconstructed samples neighboring the current block as the reference for intra-prediction. However, in some modes, unlike the mode where only the nearest row / column (i.e., line 0 in Figure 5D) of reconstructed samples is used as the reference, the Multiple Reference Line (MRL) is introduced, where two additional rows / columns (e.g., lines 1 and 3 in Figure 5D) are used for intra-prediction. The index of the selected reference row / column is signaled from encoder to decoder.In some examples, when the nearest row / column is selected, planar and DC modes are excluded from the set of intra-modes that can be used to predict the current block. In some examples, the decoder-side intra-mode derivation (DIMD) mode means that the intra-prediction mode is no longer searched for in the encoder but rather derived using previously encoded neighboring pixels through gradient analysis. DIMD is signaled for intra-encoded blocks using a simple flag. In the decoder, if the DIMD flag is true, the intra-prediction mode is derived during the reconstruction process using the same previously encoded neighboring pixels. Otherwise, the intra-prediction mode is analyzed from the bitstream as in classic intra-encoding mode. To derive the intra-prediction mode for a block, you must first select CI 77 I n / C7n7 / R / VIAI defines a set of neighboring pixels on which a gradient analysis is performed. For normative purposes, these pixels must be in the decoded / reconstructed group of pixels. Figure 5E is a block diagram illustrating a set of chosen pixels on which a gradient analysis is performed according to some implementations of the present description. As shown in Figure 5E, a template is chosen by surrounding the current block by T pixels to the left and T pixels above (at the top). A gradient analysis is then performed on the template pixels. This allows for the determination of a principal angular direction for the template, which is assumed to have a high probability of being identical to the current block. This assumption is the central premise of this method.In this way, a simple 3x3 Sobel gradient filter is used, which is defined by the following matrices that will convolve with the template:. CI 77 I n / C7n7 / R / VIAI -1 0 1 - 2 0 2 -1 0 1 For each pixel in the template, each of these two matrices is multiplied point by point by the 3x3 window surrounding the current pixel, composed of 8 direct neighbors, and the results are summed. This yields two values, Gx (from the multiplication with Mx) and Gy (from the multiplication with My), which correspond to the gradients at the current pixel in the horizontal and vertical directions, respectively. Figure 5F is a block diagram illustrating the convolution process of the 3x3 Sobel gradient filter with the template (as shown in Figure 5E) according to some implementations of the present description. The black pixel is the current pixel. The white pixels (and the black one) are the pixels for which gradient analysis is possible. The pixels with a bar gradient are the pixels for which gradient analysis is not possible due to the lack of some neighbors. The dotted outline pixels are available (reconstructed) pixels outside the considered template, which are used in the gradient analysis of the red pixels. In a case where the dotted outline pixel is not available (because the blocks are very close to the edge of an image, for example), the gradient analysis of the white pixels using the dotted outline line is not performed.For each white pixel, the intensity (G) and orientation (O) of the gradient are calculated using Gx and Gy as such:. - (TJ + |(í'v| and O - atan (”) G'y The gradient orientation then becomes an intra-angle prediction mode, which is used to index a histogram. Starting at zero, the histogram value in the intra-angle mode increases by G. Once all the red pixels in the template are processed, the histogram contains cumulative gradient intensity values ​​for each intra-angle mode. The mode that shows the highest peak in the histogram is selected as the intra-prediction mode for the current block. If the maximum value in the histogram is zero (meaning that no gradient analysis could be performed, or the area comprising the flat templates), the DC mode is selected as the intra-prediction mode for the current block. Figures 6A and 6B are block diagrams illustrating an illustrative pre-reconstructed luma block 602 and a corresponding illustrative chroma block to be reconstructed 620, respectively, in accordance with some implementations of the present description. In this example, the luma samples of the pre-reconstructed luma block 602 (e.g., including luma sample 604), an upper neighbor luma group 606 (e.g., including luma sample 608), and the left neighbor luma group 610 (e.g., including luma sample 615) have been provided during a video encoding process.The chroma samples in chroma block 620 (e.g., including chroma sample 622) are to be predicted, while the chroma samples in upper neighbor chroma group 624 (e.g., including chroma sample 626) and left neighbor chroma group 628 (e.g., including chroma sample 630) have been previously reconstructed during the video encoding process. In some modalities, if luma block 602 and chroma block 620 are of different size and shape, the chroma samples of chroma block 620 can be predicted by applying a multiple model linear model (MMLM) to the corresponding down-sampled luma samples (e.g., down-sampled luma sample 605) of the previously reconstructed luma block 602 together with chroma samples from the upper neighbor chroma group 624 (e.g., including chroma sample 626) and left neighbor chroma group 628 (e.g., including chroma sample 630).Derivation and application of MMLM are provided below in connection with Figures 7A to 7D. In some modes, the pre-reconstructed luma block 602 and chroma block 620 each represent a different component of a portion of a video frame. For example, in the YCbCr color space, an image is represented by a luma component (Y), a blue difference chroma component (Cb), and a red difference chroma component (Cr). The pre-reconstructed luma block 602 represents the luma component (i.e., brightness) of a portion of the video frame, and the chroma block 620 represents a chroma component (i.e., color) of the same portion of the video frame. A luma sample (e.g., luma sample 604) from the pre-reconstructed luma block 602 has a luma value representing the brightness at a particular pixel in the video frame, and a chroma sample (e.g., chroma sample 622) has a chroma value representing the color at a particular pixel in the video frame. In some modalities, the previously reconstructed luma block 602 is a 2M x 2N block with 2M luma samples across the block width and 2N luma samples across the block height. For example, M and N can be the same value (e.g., the previously reconstructed luma block c 1771 n / C7n7 / e / YiAi 602 is a square block) or different values ​​(e.g., the previously reconstructed luma block 602 is a non-square block). Chroma subsampling is a common compression technique because the human visual system is less sensitive to differences in color than to differences in brightness. As a result, the previously reconstructed luma block 602 and the chroma block 620 can represent the same portion of a video frame but are encoded at different resolutions. For example, the video frame might be encoded using a chroma subsampling scheme (e.g., 4:2:0 or 4:2:2) to encode chroma information rather than luma information at a lower resolution. As illustrated in Figures 6A and 6B, the previously reconstructed luma block 602 is encoded with a resolution of 2M x 2N, while the chroma block 620 is encoded with a lower resolution of M x N. In practice, the chroma block 620 may have another resolution such as 2M x 2N (e.g., full 4:4:4 sampling), 2M x N (e.g., 4:4:0 subsampling), M x 2N (e.g., 4:2:2 subsampling), and 1 / 2 M x 2N (e.g., 4:1:1 subsampling). The previously reconstructed luma block 602 is adjacent to the upper neighbor luma group 606 and the left neighbor luma group 610. The size of the upper neighbor luma group 606 and the left neighbor luma group 610 may be explicitly specified or depend on the size of the previously reconstructed luma block 602. For example, the upper neighbor luma group 606 may have a width of 2M samples (e.g., the same as the width of the previously reconstructed luma block 602) or 4N samples (e.g., twice the width of the previously reconstructed luma block 602), and a height of two samples. The left neighbor luma group 610 may have a width of two samples, with a height of 2N or 4N samples. In some modes, the upper neighbor luma group 606 and the left neighbor luma group 610 are each a portion of another luma block or blocks from the same reconstructed video frame. Chroma block 620 is adjacent to the upper neighbor chroma group 624 and the left neighbor chroma group 628. The size of the upper neighbor chroma group 624 and left neighbor chroma group 628 can be explicitly stated or depend on the size of chroma block 620. For example, the upper neighbor chroma group 624 can be 1 x M or 1 x 2 M, and the left neighbor chroma group 628 can be N x 1 or 2N x 1. In some modes, chroma values ​​(e.g., chroma values ​​of chroma samples in chroma block 620) can be predicted based on the luma values ​​of corresponding reconstructed luma samples (e.g., luma values ​​of luma samples in previously reconstructed luma block 602). For example, assuming a linear or near-linear relationship exists between luma values ​​and corresponding chroma values ​​of an encoding unit, a video encoder can predict chroma values ​​based on corresponding reconstructed luma values ​​using MMLM. By doing so, the video encoder can save a significant amount of time and bandwidth for encoding, transmitting, and decoding chroma values.To use the MMLM to predict unknown chroma values ​​from chroma samples based on known luma values ​​from luma samples, the video encoder (1) derives a set of linear relationships (e.g., two or more) between the known chroma values ​​of chroma samples and the known luma values ​​of the corresponding luma samples in an encoding block (with each linear relationship applicable to luma and / or chroma values ​​within a particular range), and (2) predicts unknown chroma values ​​from chroma samples by applying the appropriate linear relationships to the known luma values ​​of the corresponding previously reconstructed luma samples. See Figures 7A to 7D, 8, and the related description for details on how a video encoder uses the MMLM to predict unknown chroma values ​​from the known luma values ​​of the corresponding previously reconstructed luma samples. In some modes, because the luma and chroma blocks have different resolutions (for example, the chroma blocks may have been undersampled), the video encoder first performs downsampling on luma samples to generate downsampled luma samples (for example, upsampled luma samples 605, 609, and 613) that correspond only to their respective chroma samples. In some modes, when using MMLM to predict unknown chroma values ​​from chroma samples, the video encoder applies linear relationships to the known luma values ​​of the downsampled luma samples (for example, each of which corresponds only to a respective chroma sample) instead of the known luma values ​​of the actual luma samples.In some modalities, six reconstructed luma samples that are neighboring in both the height and width directions of the video frame are used to generate a down-sampled chroma sample, for example, by using weighted averaging schemes known in the technique that include six-lead down-sampling or similar methods. For example, the six reconstructed luma samples within region 611 (each represented by a small square in the figure) within the upper neighbor luma group are used to generate down-sampled chroma sample 600 through weighted averaging of their corresponding luma values, and the six reconstructed luma samples within region 607 (each represented by a small square in the figure) within the previously reconstructed luma block 602 are used to generate down-sampled chroma sample 605. For example, an application of an MMLM with two linear relationships can be represented as: (predc(Lj) — «i · recj. / (i, j) + / ?3si reci / Ci, j) < threshold lpredc(i, j) ~ a2recL'(i,j) + si recL'(i, j) > threshold Equation 1 where predc(i,j)predc(i,j) represents a predicted chroma value from a chroma sample c 1771 n / C7n7 / e / YiAi (for example, chroma sample 622) in an encoding unit, and reci_'(i,j) represents a known luma value from a previously reconstructed luma sample from the same encoding unit. In some modalities, reci_'(i,j) is a known luma value from a down-sampled luma sample (e.g., down-sampled luma sample 605) of the same coding unit, which is determined based on previously reconstructed luma samples (e.g., six-lead down-sampling). Threshold represents a threshold value that determines which of the multiple linear relationships of the MMLM is used for a particular luma value.For the derivation of the MMLM that includes two linear relationships (e.g., derivation of linear model parameters αι,αζ,βι,βζ, Threshold) refer to Figures 7A to 7D, 8, and the related description. In another example, an application of an MMLM with three linear relations can be represented as: f predc(i,j) — rr:i· recf,(L j) + β-λsi req< ring!. ··· -¾ >rect(i,j) + / ¾ if > threshold^ and recV(iJ) < threshold(predc(ij) = i / ¾ * if recL(i,j) > threshold2(Equation 2) Equation 2 differs from Equation 1 in that the MMLM in Equation 2 includes three different linear relationships, with two threshold values ​​that determine three separate intervals of luma values. For the derivation of the MMLM that includes three linear relationships (e.g., derivation of the parameters αι, αζ, αζ, βι, βζ, βζ, Umbrah, Umbralz), refer to Figures 7A to 7D, 8, and the related description. Figures 7A through 7D are graph diagrams illustrating a process by which a video encoder implements the techniques of deriving a multiple-model linear model (MMLM) and applying the MMLM to predict unknown chroma values ​​from chroma samples of an encoding unit, in accordance with some implementations of the present description. For convenience, the described process is described as being performed by a video encoder. For each graph, the horizontal axis represents luma values ​​of luma samples, the vertical axis represents chroma values ​​of chroma samples, and each data point on a graph represents a pair of a chroma sample and a corresponding luma sample. In some modalities, the corresponding luma sample is a downsampled luma sample.For example, a data point on a graph may represent a pair of a previously reconstructed chroma sample (e.g., chroma sample 626 in Figure 6B) in upper neighbor chroma group 624 (Figure 6B) and a corresponding down-sampled luma sample (e.g., down-sampled luma sample 613 in Figure 6A) in upper neighbor luma group 606 (Figure 6A). Figure 7A shows plot 702 with first group of data points 704. Each data point (e.g., also known as a reference sample pair) in plot 702a represents a pair of a previously reconstructed chroma sample (e.g., chroma sample 626 in Figure 6B) and a corresponding previously reconstructed luma sample (e.g., downsampled luma sample 613 in Figure 6A). The previously reconstructed chroma samples and their corresponding luma values ​​are known as reference chroma samples and reference luma samples, respectively.In some modes, the video encoder selects the reference luma samples for a current luma encoding block from neighboring reconstructed luma sample groups (e.g., upper neighbor luma group 606, left neighbor luma group 610, or both), and selects the reference chroma samples from neighboring reconstructed sample groups (e.g., upper neighbor chroma group 624, left neighbor chroma group 628, or both). The reference luma samples and their corresponding reference chroma samples are used to derive linear model parameters for the MMLM, such as the parameters α₁, α₂, β₁, β₂, Threshold for Equation 1 or the parameters α₁, α₂, α₃, β₁, β₂, β₃, Threshold for Equation 2. In some modes (also known as MMLM_A mode), the video encoder selects luma reference samples from an upper neighbor luma group (e.g., downsampled luma samples from upper neighbor luma group 606 in Figure 6A) and chroma reference samples from a corresponding upper neighbor chroma group (e.g., upper neighbor chroma group 624 in Figure 6B). Downsampled luma samples from a left neighbor group (e.g., left neighbor luma group 610 in Figure 6A) and their corresponding chroma samples from a left neighbor chroma group (e.g., left neighbor chroma group 628 in Figure 6B) are ignored.For example, in Figures 6A and 6B, the video encoder can select M down-sampled luma samples (for example, the number of down-sampled luma samples per reconstructed luma block row 602) and M reference chroma samples (for example, the number of reference chroma samples per chroma block row 620) as the reference luma samples and reference chroma samples, or 2M up-sampled luma samples (for example, twice the number of down-sampled luma samples per reconstructed luma block row 602) and 2M chroma samples (for example, twice the number of chroma samples per chroma block row 620) as the reference luma samples and reference chroma samples.In general, using more reference luma samples and reference chroma samples allows for more accurate prediction of chroma values ​​based on luma values ​​(e.g., more accurate determination of MMLM parameters), but at a higher computational cost. In some modes, (also known as the mode (such as the c 1771 n / C7n7 / e / YiAi mode) MMLM_L), the video encoder selects luma reference samples from a left-neighbor luma group (left-neighbor luma group 610 in Figure 6A) and chroma reference samples from a corresponding left-neighbor chroma group (left-neighbor chroma group 628 in Figure 6B). Down-sampled luma samples from an upper-neighbor luma group (e.g., upper-neighbor luma group 606 in Figure 6A) and their corresponding chroma samples from an upper-neighbor chroma group (e.g., upper-neighbor chroma group 628 in Figure 6B) are ignored.For example, in Figures 6A and 6B, the video encoder can select N down-sampled luma samples (for example, the number of down-sampled luma samples per reconstructed luma block column 602) and N reference chroma samples (for example, the number of reference chroma samples per chroma block column 620) as the reference luma samples and reference chroma samples, or 2N down-sampled luma samples (for example, twice the number of down-sampled luma samples per reconstructed luma block column 602) and 2M chroma samples (for example, twice the number of chroma samples per chroma block column 620) as the reference luma samples and reference chroma samples. In some modes, the video encoder selects luma and chroma reference samples when using both MMLM_L mode and MMLM_A mode. Figure 7B shows graph 702B with the second set of data points 706. The video encoder uses the second set of data points 706 to derive the MMLM parameters. In some modes, the second set of data points 706 is a subset of the first set of data points 704. Reducing the number of luma reference samples and chroma reference samples decreases the computational complexity of deriving the MMLM parameters. The video encoder determines the second set of data points 706 from the first set of data points 704 in the following ways: In some modalities, the number of data points (e.g., also known as reference sample pairs) in the second data point group 706 is limited to a predetermined value based on the size and / or shape of the chroma block (e.g., chroma block 620 in Figure 6B) from which chroma samples are to be predicted. Four different examples (labeled Method 1, 2, 3, and 4) are provided in Table 1 below, where N can be 2, 4, and / or 8 depending on the size and shape of the chroma block of the current encoding unit. TABLE 1 Chroma block size Method 1 Method 2 Method 3 Method 4 2 x η / nx 2 2 4 4 2 4xn / nx4(n >=4) 4 8 4 4 8xn / nx8(n >=8) 8 8 4 4 16 x η / nx 16 (n > = 16) 8 8 4 4 32x32 8 8 4 4 > cu κ cr\ Cj c KK u For example, if the chroma block is 4x8 or 8x4 and the video encoder selects Method 1, the number of data points in the second group of 706 data points will be limited to 4. In another example, if the chroma block is 62 x 62 and the video encoder selects Method 2, the number of data points in the second group of 706 data points is limited to 8. In some modalities, the MMLM is only applicable to blocks with a block size equal to or greater than a predetermined threshold. For example, a chroma block smaller than the threshold will not be predicted using the MMLM. For instance, the maximum number of reference sample pairs used to derive an MMLM is limited to 8, and the block size threshold is limited to 8x8 or 16x16. As a result, smaller chroma blocks that do not have enough associated reference sample pairs are not predicted using the MMLM. In some modes, the video encoder selects the reference sample pairs in the second group of 706 data points through fixed downsampling. For example, the video encoder may use a fixed downsampling method in which luma or chroma reference samples at a certain indexed position (e.g., with an odd index arrangement) in the vertical (e.g., MMLM_L mode) or horizontal (e.g., MMLM_A mode) direction are selected for derivation of the MMLM parameter. In some modes, the video encoder selects the reference sample pairs in the second group of data points 706 using adaptive downsampling. For example, the video encoder may select an adaptive downsampling method in which reference samples are chosen according to (1) a predefined sampling interval, and (2) a starting offset in the vertical or horizontal direction. More specifically, the video encoder may determine the sampling interval and starting offset based on the number of original reference sample pairs (for example, in the first group of data points 704) and the number of reduced reference sample pairs (for example, in the second group of data points 706) as follows: 1. Determine the number of original reference sample pairs: L (for example, 16) 2. Determine the number of reduced reference sample pairs: N (for example, 8) 3. Determine the sampling interval: A=L / N (for example, 2) 4. Determine the initial displacement: displacement=A / 2 (for example, 1) The video encoder selects a first reference sample (e.g., a luma or chroma sample) at the position (e.g., of neighboring luma or chroma groups) of a predefined starting position (e.g., the second reference sample) plus the start offset. The position of the other reference samples is the position of the previous point plus the sampling interval. Figure 7C shows graph 712 with the second group of data points 708, separated by luma threshold 710 into two subgroups based on luma values, with the first subgroup extending from the minimum reference luma value 712 to the luma threshold 710, and the second subgroup extending from the luma threshold to the maximum luma value 712. Within each subgroup, the video encoder then derives a respective linear model from the MMLM that maps luma values ​​to chroma values. In some modes, the video encoder calculates the luma threshold 710 by selecting all luma samples (or luma samples sampled in descending order) in the left neighbor luma group (for example, left neighbor luma group 610 in Figure 6C) and ignoring all other luma samples. The video encoder then performs an operation on the selected luma samples, such as determining the average luma value, the mean luma value, the mode luma value, or by using custom-defined formulas. In some modes, the video encoder calculates the luma threshold 710 by selecting all luma samples (or luma samples sampled downwards) in the upper neighbor luma group (for example, upper neighbor luma group 606 in Figure 6A) and ignoring all other luma samples. The video encoder then performs an operation on the selected luma samples, such as determining the average luma value, the mean luma value, the mode luma value, or by using custom-defined formulas. In some modes, the video encoder calculates the luma threshold 710 by selecting all luma samples (or luma samples sampled downwards) from both the upper and left neighbor luma groups (for example, left neighbor luma group 610 and upper neighbor luma group 606 in Figure 6A) and ignoring all other luma samples. The video encoder then performs an operation on the selected luma samples, such as determining the average luma value, the mean luma value, the mode luma value, or by using custom-defined formulas. In some modes, the video encoder calculates the luma threshold 710 by selecting all luma samples (or downsampled luma samples) within the current encoding unit (for example, luma block 602 in Figure 6A) and ignoring all other luma samples. The video encoder then performs an operation on the selected luma samples, such as determining the average luma value, the mean luma value, the mode luma value, or by using custom-defined formulas. In some modes, the video encoder calculates the luma threshold 710 by selecting all luma samples (or luma samples sampled in descending order) within the current encoding unit (e.g., luma block 602 in Figure 6A) and the upper and left neighbor groups (e.g., left neighbor luma group 610 and upper neighbor luma group 606 in Figure 6A). The video encoder then performs an operation on the selected luma samples, such as determining the average luma value, the mean luma value, the mode luma value, or other custom-defined formulas. In some modes, custom-defined formulas include Lmax+Ltnin finding the minimum and maximum luma values ​​(Lminy Lmax) and performing: N, where N is a predefined value such as 2. Similarly, the video encoder can determine chroma threshold 711 by applying the above techniques to neighboring chroma groups. Although Figure 702c includes only one luma threshold, 710, which divides the luma values ​​into two separate groups (e.g., there are two linear relationships to be derived for the MMLM), in actual practice, there may be multiple luma thresholds that divide the luma values ​​into three or more separate groups (e.g., there are three or more linear relationships to be derived for the MMLM). For example, where there are three linear relationships in the MMLM, the video encoder can determine the two luma thresholds based on the maximum reference luma value, 712, and the minimum reference luma value, 714, as follows: , , 12 ring < ~ * Lmax + - *Lmin133 threshold ¿ p * Lmax 4- - * Lmin .5ó (Equation 3) In another example, all neighboring reconstructed luma samples (upper neighbor or left neighbor) (or downsampled luma samples) are separated into two groups based on the average value of the neighboring reconstructed luma samples. Luma samples with values ​​smaller than the average value belong to one group, and those with values ​​no smaller than the average value belong to the other group. Umbrali and Umbrab can then be calculated as the average value of each group. Figure 7D shows graph 702 in which two linear relationships (linear relationships 716 and 718) from the MMLM are derived based on luma threshold 710, minimum reference luma value 712, c 1771 n / C7n7 / e / YiAi, and maximum reference luma value 714. As described earlier with reference to Figure 7C, the video encoder first separates the reference samples from the second group of data points 708 into two subgroups based on luma threshold 710. Within each subgroup, the video encoder determines a respective linear relationship (see Equation 1) that assigns luma values ​​to chroma values. In some modalities, the video encoder determines the respective linear relationship by using a regression method (e.g., by considering all data points in the group). However, performing regression is computationally intensive and is often unrealistic for the purpose of video encoding / decoding, for example, in real time.Therefore, a more efficient implementation is desired for deriving linear relationships (e.g., determining the linear parameters in Equation 1). In some modes, the video encoder derives the linear relationship 716 and 718 by using a Max-Min method. The video encoder determines the linear model parameter {ai, βι, a2, 02) from Equation 1 of (1) the reference sample having the minimum reference luma value 712 (e.g., mathematically represented by A(Xa, Ya), where Xa is the minimum reference luma value 712), (2) a data point having luma threshold 710 and chroma threshold 711 (e.g., mathematically represented by Threshold (Xt, Yt), where Xt and Yt are the luma threshold 710 and chroma threshold 711, respectively), and (3) the reference sample having the maximum reference luma value 714 (e.g., mathematically represented by B(Xb, Yb)). Note that although Xa and Xb are minimum and maximum luma values, Ya and Yb are not necessarily minimum and maximum chroma values. The video encoder determines the linear model parameters as follows: bJ NJ II 1..... ho' ' -i 1! II 1 i ^1 (Equation 4) In some modes, for a square-shaped encoding block, the video encoder applies the above technique directly. For a non-square encoding block, in some modes, the video encoder first subsamples the reference samples adjacent to the longer boundary to have the same number of samples as the shorter boundary. In the case where the MMLM includes three linear relationships (for example, represented by Equation 3), the video encoder can derive linear model parameters for linear relationships in similar ways to those described above for the MMLM with two linear relationships. For example, assuming that the two threshold data points can be represented as Threshold (Xti, Xt2) and Threshold (Xti, Ytz), with Ytz > Yti, the video encoder can determine the linear model parameters ai and βi from the straight linear relationship between A (Xa, Ya) and Threshold (Xti, Yti). The linear model parameter βi / U is derived from the straight linear relationship between Threshold (Xti, Yti) and Threshold (Xt2, Yt2). The linear model parameter coy / U can be derived from the straight linear relationship between Threshold (Xt2, Yt2) and B (Xb, Xb). After deriving the linear relationship 716 and 718 from the MMLM, the video encoder can predict chroma sample values ​​(e.g., chroma sample value 622 in Figure 6B) by applying the appropriate linear model to the corresponding luma value (or subsampled luma value). Figure 8 is a flowchart illustrating an illustrative process 600 by which a video encoder implements the techniques of deriving a multiple-model linear model (MMLM) and applying the MMLM to predict chroma samples from an encoding unit in accordance with some implementations of the present description. For convenience, process 800 will be described as being performed by a video decoder in a target device, such as video decoder 30 in Figure 3. As the first step, the video decoder receives a bit stream (e.g., sent by video encoder 20 in Figure 2) that encodes a chroma block (e.g., chroma block 620 in Figure 6B), a luma block (e.g., luma block 602 in Figure 6A) (e.g., the chroma block and the luma block belong to the same encoding unit), a plurality of neighboring luma samples surrounding the luma block (e.g., upper neighbor luma group 606 and / or left neighbor luma group 610 in Figure 6A), and a plurality of neighboring chroma samples surrounding the chroma block (e.g., upper neighbor chroma group 624 and / or left neighbor chroma group 628) (810) (e.g., one or more luma samples in the plurality of neighboring luma samples corresponds to one chroma sample in the neighboring chroma samples). In some modalities, the luma block and the chroma block are sampled at different sampling rates and have different block sizes and / or shapes.For example, the luma block may be larger than the chroma block, and subsampling of the luma block is performed to find a subsampled luma sample (e.g., a luma sample calculated by weighting neighboring luma samples) that corresponds to a chroma sample. The video decoder then decodes the luma block, the plurality of neighboring luma samples, and the plurality of neighboring chroma samples to obtain a plurality of reconstructed luma samples from the luma block, a plurality of reconstructed neighboring luma samples, and a plurality of reconstructed neighboring chroma samples, respectively (820). For example, the c 1771 n / C7n7 / e / YiAi video decoder can decode the luma block, the plurality of neighboring luma samples, and the plurality of neighboring chroma samples by using inter-mode prediction or intra-mode prediction. Each reconstructed neighboring luma sample (or reconstructed subsampled neighboring luma sample) and its corresponding reconstructed neighboring chroma sample can be represented as a reference data point (e.g., as a data point in the first group of data points 704 in Figure 7A) that illustrates the correspondence between luma and chroma values. Next, the video decoder selects, from the plurality of reconstructed neighboring luma samples (or reconstructed subsampled neighboring luma samples) and the plurality of reconstructed neighboring chroma samples, a group of reference luma samples and a corresponding group of reference chroma samples, respectively (for example, represented by the second group of data points 706 in Figure 7B) (830). In some modes, the reference luma samples and the corresponding reference chroma samples are subsets of the plurality of reconstructed neighboring luma samples and the plurality of reconstructed neighboring chroma samples, respectively. For details on the selection mechanism, refer to Figure 7B and the related description. Next, the video decoder calculates a threshold luma value (for example, an average luma value, a mean luma value, a luma value calculated from another predefined operation) from the plurality of reconstructed neighboring chroma samples, and a threshold chroma value (for example, an average chroma value, a mean chroma value, or chroma values ​​calculated in other ways from the luma samples) from the plurality of reconstructed neighboring chroma samples (for example, the data point (threshold luma value, threshold chroma value) represents an articulated point in MMLM and is used to separate a first linear model from a second linear model in MMLM, by referring to Figure 7D and the related description) (840). After determining the threshold luma value and the threshold chroma value, the video decoder determines a maximum luma value and a minimum luma value from the reference luma sample set (850). For example, in graph 702d of Figure 7D, the maximum luma value is Xb and the minimum luma value is Xa. The reference samples that include the maximum and minimum luma values ​​are B(Xb, Yb) and A(Xa, Ya), respectively. The minimum luma value (e.g., Xa in Figure 7D), the threshold luma value (e.g., Xt in Figure 7D), and the maximum luma value (e.g., Xb in Figure 7D) define two separate luma value regions, with the first region extending from the minimum luma value to the threshold luma value, and the second region extending from the threshold luma value to the maximum luma value. The threshold luma value lies between the minimum and maximum luma values.In some modes, if the maximum luma value differs from the minimum luma value, then the threshold luma value is greater than or equal to the minimum luma value and less than or equal to the maximum luma value. In some modes, if the maximum luma value is equal to the minimum luma value (for example, the region for calculating the maximum and minimum luma values ​​comprises uniform luma samples), then the maximum, minimum, and threshold luma values ​​are all equal. Therefore, the threshold luma value lies between the minimum and maximum luma values ​​if the threshold luma value is greater than or equal to the minimum luma value and less than or equal to the maximum luma value. The video decoder then generates a multi-model linear model that includes a first linear model between the minimum luma value and the threshold luma value, and a second linear model between the threshold luma value and the maximum luma value (860). The first linear model is defined by a reference sample that includes the minimum luma value (e.g., A(Xa, Ya) in Figure 7D) and a reference sample that includes the threshold luma value (e.g., Threshold(Xt, Yt) in Figure 7D). The second linear model is defined by the reference sample that includes the threshold luma value (e.g., Threshold(Xt, Yt) in Figure 7D) and a reference sample that includes the maximum luma value (e.g., B(Xb, Yb) in Figure 7D). For example, Graph 702d in Figure 7D shows the first and second linear models as linear relationship 716 and linear relationship 718, respectively. Finally, the video decoder reconstructs the chroma block from the luma block using the multiple-model linear model (870). In some modalities, the video decoder may pass through each luma sample (or subsampled luma sample) in the luma block in a raster scan order, and applies the appropriate linear relationship from the MMLM to reconstruct the corresponding chroma sample (e.g., if the luma value of the luma sample is below the luma threshold, apply the first linear relationship; if the luma value of the luma sample is greater than the luma threshold, apply the second linear relationship). In some modalities, generating the multiple-model linear model includes: determining a first chroma value from a first reference chroma sample that corresponds to a first reference luma sample having the maximum luma value, and a second chroma value from a second reference chroma sample that corresponds to a second reference luma sample having the minimum luma value; and wherein the first linear model connects (minimum luma value, first chroma value) and (threshold luma value, threshold chroma value) and the second linear model connects (threshold luma value, value, threshold) and (maximum luma value, second chroma value). In some modalities, constructing the chroma block from the luma block using the multiple-model linear model includes: for a respective chroma sample in the chroma block: determining a respective luma value of a respective luma sample in the reconstructed luma block that corresponds to the respective chroma sample; in accordance with a determination that the respective luma value is less than or equal to the threshold luma value: applying the first linear model to the respective luma value to obtain the respective chroma value; and in accordance with a determination that the respective luma value is greater than or equal to the threshold luma value: applying the second linear model to the respective luma value to obtain the respective chroma value. In some modalities, calculating the threshold luma value includes finding an average luma value from the plurality of reconstructed neighboring luma samples, and calculating the threshold chroma value includes finding an average chroma value from the plurality of reconstructed neighboring chroma samples. In some modalities, selecting the reference luma sample group and the reference chroma sample group includes determining an upper limit on the number of reference luma samples and reference chroma samples to be used. In some modalities, selecting the reference luma sample group and the reference chroma sample group includes selecting all other luma samples from the plurality of reconstructed neighboring luma samples and all other chroma samples from the plurality of reconstructed neighboring chroma samples. In some modalities, calculate a second luma threshold value greater than the luma threshold value and a corresponding second chroma threshold value greater than the chroma threshold value, and where: the second linear model is applicable to luma values ​​between the luma threshold value and the second luma threshold value, and the third linear model are luma values ​​applicable between the second luma threshold value and the maximum luma value. In some modalities, calculating the threshold luma value includes finding a weighted average luma value between the maximum luma value and the minimum luma value of the plurality of reconstructed neighboring luma samples, and calculating the threshold chroma value includes finding a weighted average chroma value between the maximum chroma value and the minimum chroma value of the plurality of reconstructed neighboring chroma samples. In some modalities, calculating the threshold luma value includes finding an average luma value from the plurality of reconstructed luma samples of the luma block. In some modalities, constructing the chroma block of the luma block using the multiple-model linear model includes: for a respective block of chroma samples in the chroma block: determining a respective average luma value from a respective block of luma samples in the decoded luma block corresponding to the respective block of chroma samples; in accordance with a determination that the respective average luma value is less than or equal to the threshold luma value: applying the first linear model to each luma value in the respective block of luma samples to obtain a respective chroma value in the respective block of chroma samples; and in accordance with a determination that the respective average luma value is greater than or equal to the threshold luma value: applying the second linear model to each luma value in the respective block of luma samples to obtain a respective chroma value in the respective block of chroma samples. Figure 9 is a block diagram illustrating the locations of the neighboring samples (shown as gray circles) used for MMLM according to some implementations of this description. In some modes, as shown in Figure 9, a derivation of a linear multi-model parameter is multi-line. In some modes, the model parameters for MMLM are generated using multiple lines of reference samples. In one embodiment, the multiple lines of reference samples are divided into N sets, where N is a positive number and its value can change dynamically based on certain encoded information from the current block, for example, the quantization parameter or size of the encoded block associated with the TB (transformation block) / CB (encoding block) and / or the segment / profile. Figure 10 is a block diagram illustrating the locations of four sample sets used for MMLM in accordance with some implementations of this description. In Figure 10, the four sample sets are represented by different symbols in the gray circles, for example, gray circles without a symbol, gray circles with a cross symbol, gray circles with a triangle symbol, and gray circles with a check symbol.In another mode, the multiple lines of reference samples are divided into N reference sets, where N is a positive number and a codeword is dynamically changed to indicate one of the N reference sets based on certain coded information from the current block, e.g., the quantization parameter, the number of sets, or the coded block size associated with the TB / CB and / or segment / profile. In one example, a control flag is set at the TB / CB / segment / image / sequence level to indicate whether the signaling of reference sets for MMLM blocks is enabled or disabled. When the control flag is enabled, an additional syntax element is signaled for each CB to indicate that a particular reference set is used for linear model parameter derivation at that CB. When the control flag is disabled (for example, by setting the flag to 0), no additional syntax element is signaled at lower levels to indicate the particular reference set for linear model parameter derivation, and a default reference set (for example, the available top (above) and left reconstruction) is used for linear model parameter derivation. In some modes, a combined MMLM and inter-prediction are used to form a prediction. In some modes, the MMLM and intra-prediction with derivative weighting are combined to form a final prediction. In one mode, the weights are derived from the prediction modes of two adjacent blocks on the left (top) and above, and are combined to form the final prediction. Only the flat mode is used as the intra-prediction mode of the weight combination. In another mode, the intra-prediction mode of the combination can be the same mode as the placed intra-prediction. In yet another mode, the weights and / or intra-prediction mode of the combination can be indicated in the CI 77 I n / C7n7 / R / VIAI TB / CB / segment / image / sequence level to indicate the weights and / or type of Interprediction mode used in the combination. In one example, a control flag is set at the TB / CB / segment / image / sequence level to indicate whether the combined MMLM and intra-prediction mode is enabled or disabled. When the control flag is enabled, a syntax element is further set for each CB to indicate that a particular intra-prediction is used as the intra-prediction mode for the combination at that CB. In another example, a control flag is set at the TB / CB / segment / image / sequence level to indicate whether the combined MMLM and intra-prediction mode is enabled or disabled. When the control flag is enabled, a syntax element is further set for each CB to indicate that weights are used for the combined MMLM and intra-prediction at that CB. Even in another mode, the type of intra-mode and weights to combine the final prediction are derived from the prediction modes of two adjacent blocks on the left and above (top). In one example, a control flag in the TB / CB / segment / image / sequence level indicates whether the combined MMLM and inter-prediction mode is enabled or disabled. When the control flag is enabled, the intra-prediction mode is derived using previously encoded neighboring pixels through gradient analysis, such as the gradient analysis used in DIMD. The mode that displays the highest peak in the histogram is selected, as in the intra-prediction mode of the combination in that CB. The weights can change dynamically based on the ratio of the highest peak in the histogram; for example, the higher the ratio of the highest peak, the higher the intra-mode weight. Figure 11 is a flowchart illustrating an illustrative process 1100 by which a video encoder implements the techniques of combining MMLM and intra-prediction to predict or construct a chroma block from a video signal in accordance with some implementations of the present description. For convenience, process 800 will be described as being performed by a video decoder in a target device, such as video decoder 30 in Figure 3. As the first step, the video decoder receives a bit stream (e.g., sent by the video encoder 20 in Figure 2) that encodes the chroma block, a corresponding luma block, a plurality of neighboring luma samples surrounding the luma block, and a plurality of neighboring chroma samples surrounding the chroma block (1110). The video decoder then decodes the luma block, the plurality of neighboring luma samples, and the plurality of neighboring chroma samples to obtain a plurality of reconstructed luma samples from the luma block, a plurality of reconstructed neighboring luma samples, CI 77 I n / C7n7 / R / VIAI and a plurality of reconstructed neighboring chroma samples, respectively (1120). The video decoder then selects, from the plurality of reconstructed neighboring luma samples and the plurality of reconstructed neighboring chroma samples, a group of reference luma samples and a group of reference chroma samples, wherein each reference luma sample corresponds to a respective reference chroma sample (1130). The video decoder then calculates a threshold luma value from the reference luma sample group, and a corresponding threshold chroma value from the reference chroma sample group (1140). The video decoder then determines a maximum luma value and a minimum luma value from the group of reference luma samples, where the threshold luma value is between the minimum luma value and the maximum luma value (1150). The video decoder then generates a multi-model linear model that includes a first linear model between the minimum luma value and the threshold luma value, and a second linear model between the threshold luma value and the maximum luma value (1160). The video decoder additionally reconstructs a respective sample value of the chroma block from a weighted combination of a respective first reconstructed sample value corresponding to the luma block using the multiple-model linear model, and a respective second reconstructed sample value from a neighboring chroma block of an intra-prediction mode (1170). In some modalities, the plurality of neighboring luma samples are selected from at least two left lines and at least two top lines surrounding the luma block, and the plurality of neighboring chroma samples are selected from at least two left lines and at least two top lines surrounding the chroma block. For example, the derivation of the linear model parameter of a multi-model is multi-line, as shown in Figure 9. In some modalities, the plurality of neighboring luma samples is divided into a predetermined number of reference sets, the plurality of neighboring chroma samples is divided into a predetermined number of reference sets, the reference luma sample group is selected from one of the predetermined number of reference sets, and the reference chroma sample group is selected from one of the predetermined number of reference sets. For example, as shown in Figure 10, the multiple lines of reference samples are divided into N reference sets, where N is a positive number and is a codeword that dynamically changes to indicate a particular reference set based on certain encoded information from the current block, such as a quantization parameter, the number of sets, or the encoded block size associated with the TB / CB and / or the segment / profile. In some modalities, the reference luma sample group and the reference chroma sample group are selected based on encoded information from a current block that includes the chroma and luma blocks. In some modes, selecting, from the plurality of reconstructed neighboring luma samples and the plurality of reconstructed neighboring chroma samples, the reference luma sample group and the reference chroma sample group (1130), includes: determining whether to signal the default number of reference sets from a control flag on a selected one from the group consisting of TB (transform block), CB (encoding block), segment, image, and sequence level, and in response to a determination that signaling the default number of reference sets is enabled from the control flag, determining from a syntax that a particular set from the default number of reference sets is selected as the reference luma sample group and the reference chroma sample group.In some examples, a control flag is set at TB / CB / segment / image / sequence level to indicate whether reference set signaling for MMLM blocks is enabled or disabled. When the control flag is set to enabled, a syntax element is also set for each CB to indicate that a particular reference set is used for deriving the linear model parameter in that CB. In some modes, reconstructing the respective sample value of the chroma block from the weighted combination of the corresponding first reconstructed sample value of the luma block using the multiple-model linear model, and the respective second reconstructed sample value of a neighboring chroma block of the intra-prediction mode (1170) includes: receiving at TB / CB / segment / image / sequence level at least one of two signals: a first signal indicating a weight of the corresponding first reconstructed sample value, and a second signal indicating a type of intra-prediction mode. For example, the weights and / or intra-prediction mode of the combination can be signaled at TB / CB / segment / image / sequence level to indicate the weights and / or type of intra-prediction mode used in the combination.The corresponding weighting of the respective second reconstructed sample value can be derived from the weighting of the respective first reconstructed sample value. In some modes, reconstructing the respective chroma block sample value from the weighted combination of the corresponding first reconstructed sample value of the luma block using the multiple-model linear model, and the respective second reconstructed sample value of a neighboring chroma block from the intra-prediction mode (1170), is performed when a control flag set in TB / CB / segment / image / sequence level is enabled. For example, a control flag in TB / CB / segment / image / sequence level is set to indicate whether the combined MMLM and intra-prediction mode is enabled or disabled. CI 77 I n / C7n7 / R / VIAI In some modalities, the intra-prediction mode is derived using previously coded neighboring samples through gradient analysis. In some modes, the plurality of neighboring luma samples are selected from a single left line and a single top line surrounding the luma block, and the plurality of neighboring chroma samples are selected from a single left line and a single top line surrounding the chroma block. For example, the single left line and the single top line surrounding the luma block or chroma block are illustrated as shown in Figure 6A and Figure 6B. In some modalities, reconstructing the respective chroma block sample value from the respective corresponding first reconstructed luma block sample value using the multiple-model linear model includes: in accordance with a determination that the respective corresponding first reconstructed luma block sample value is less than or equal to the threshold luma value: applying the first linear model to the respective corresponding first reconstructed luma block sample value to obtain the respective chroma block sample value; and in accordance with a determination that the respective corresponding first reconstructed luma block sample value is greater than the threshold luma value: applying the second linear model to the respective corresponding first reconstructed luma block sample value to obtain the respective chroma block sample value. Figure 12 shows a computing environment 1210 coupled with a user interface 1250. The computing environment 1210 can be part of a data processing server. The computing environment 1210 includes a processor 1220, memory 1230, and an input / output (I / O) interface 1240. The 1220 processor typically controls general operations of the 1210 computer lathe, such as those associated with display, data acquisition, data communications, and image processing. The 1220 processor may include one or more processors to execute instructions for performing all or some of the steps in the methods described above. In addition, the 1220 processor may include one or more modules that facilitate interaction between the 1220 processor and other components. The processor may be a central processing unit (CPU), a microprocessor, a single-chip machine, a graphics processing unit (GPU), or similar. Memory 1230 is configured to store various types of data to support the operation of computing environment 1210. Memory 1230 may include pre-installed software 1232. Examples of such data include instructions for any of the applications or methods operated in computing environment 1210, video datasets, image data, etc. Memory 1230 can be implemented using any type of volatile or non-volatile memory device. CI 77 I n / C7n7 / R / VIAI volatile, or a combination thereof, such as a static random access memory (SRAM), an electrically erasable programmable read-only memory (EEPROM), a programmable erasable read-only memory (EPROM), a programmable read-only memory (PROM), a read-only memory (ROM), a magnetic memory, a flash memory, a magnetic or optical disk. The 1240 I / O interface provides an interface between the 1220 processor and peripheral interface modules, such as a keyboard, click wheel, buttons, and the like. Buttons may include, but are not limited to, a start button, a start scan button, and a stop scan button. The 1240 I / O interface can be coupled with an encoder and decoder. In one embodiment, a non-transient, computer-readable storage medium comprising a plurality of programs, for example, in memory 1230, executable by processor 1220 in computing environment 1210, is also provided for performing the methods described above. Alternatively, the non-transient, computer-readable storage medium may store therein a bit stream or a data stream comprising encoded video information (for example, video information comprising one or more syntax elements) generated by an encoder (for example, video encoder 20 in Figure 2) using, for example, the encoding method described above, for use by a decoder (for example, video decoder 30 in Figure 3) when decoding video data.The non-transient, computer-readable storage medium can be, for example, a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, or similar. In one embodiment, a computing device comprising one or more processors (e.g., the 1220 processor) is also provided; and the non-transient computer-readable storage medium or memory 1230 having stored therein a plurality of programs executable by the one or more processors, wherein the one or more processors, after execution of the plurality of programs, are configured to perform the methods described above. In one embodiment, a computer program product is also provided, comprising a plurality of programs, for example, in memory 1230, executable by processor 1220 in computing environment 1210, to perform the methods described above. For example, the computer program product may include non-transient, computer-readable storage media. In one configuration, the 1210 computing environment can be implemented with one or more ASICs, DSPs, Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), FPGAs, GPUs, controllers, microcontrollers, CI 77 I n / C7n7 / R / VIAI microprocessors, or other electronic components, to perform the above methods. Additional modalities also include various subsets of the above modalities combined or otherwise rearranged into several other modalities. In one or more examples, the described functions may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored in or transmitted over, as one or more code instructions, a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media, which corresponds to a tangible medium such as a data storage medium, or communication media, which includes any medium that facilitates the transfer of a computer program from one location to another, for example, in accordance with a communication protocol.Thus, computer-readable media can generally correspond to (1) tangible, non-transient, computer-readable storage media or (2) a communication medium such as a signal or carrier wave. All 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 the implementation of the implementations described in this application. A computer program product may include computer-readable media. The description provided here is for illustrative purposes only and is not intended to be exhaustive or limited to the description itself. Many modifications, variations, and alternative implementations will be evident to those skilled in the art with intermediate knowledge who benefit from the teachings presented in the preceding descriptions and associated figures. Unless specifically stated otherwise, the order of steps in the method described herein is intended for illustrative purposes only, and the steps are not limited to the order specifically described above but may change according to practical conditions. Furthermore, at least one of the steps in the method described herein may be adjusted, combined, or eliminated as required by practical requirements. The examples were chosen and described to explain the principles of the description and to enable other practitioners to understand the description for various implementations and to better utilize the underlying principles and various implementations with various modifications as appropriate for the particular intended use. Therefore, it will be understood that the scope of the description is not limited to the specific examples of the implementations described and that modifications and other implementations intended to be included within the scope of the CI 77 I n / C7n7 / R / VIAI present description.

Claims

1. A method for constructing a chroma block from a video signal, characterized in that it comprises: receiving a bit stream encoding the chroma block, a corresponding luma block, a plurality of neighboring luma samples surrounding the luma block, and a plurality of neighboring chroma samples surrounding the chroma block; decoding the luma block, the plurality of neighboring luma samples, and the plurality of neighboring chroma samples to obtain a plurality of reconstructed luma samples from the luma block, a plurality of reconstructed neighboring luma samples, and a plurality of reconstructed neighboring chroma samples, respectively;Select, from the plurality of reconstructed neighboring luma samples and the plurality of reconstructed neighboring chroma samples, a group of reference luma samples and a group of reference chroma samples, where each reference luma sample corresponds to a respective reference chroma sample; calculate a threshold luma value from the group of reference luma samples, and a corresponding threshold chroma value from the group of reference chroma samples; determine a maximum luma value and a minimum luma value from the group of reference luma samples, where the threshold luma value is between the minimum luma value and the maximum luma value; generate a multiple-model linear model that includes a first linear model between the minimum luma value and the threshold luma value, and a second linear model between the threshold luma value and the maximum luma value;and reconstruct a respective sample value of the chroma block from a weighted combination of a respective first reconstructed sample value corresponding to the luma block using the multiple-model linear model, and a respective second reconstructed sample value from a neighboring chroma block in an intra-prediction mode.

2. The method according to claim 1, further characterized in that the plurality of neighboring luma samples are selected from at least two left lines and at least two upper lines surrounding the luma block, and the plurality of neighboring chroma samples are selected from at least two left lines and at least two upper lines surrounding the chroma block.

3. The method according to claim 2, further characterized in that the plurality of neighboring luma samples is divided into a predetermined number of reference sets, the plurality of neighboring chroma samples is divided into a predetermined number of reference sets, the reference luma sample group is selected from one of the predetermined number of reference sets, and the reference chroma sample group is selected from one of the predetermined number of reference sets.

4. The method according to claim 3, further characterized in that the reference luma sample group and the reference chroma sample group are selected based on coded information from an actual block that includes the chroma and luma blocks.

5. The method according to claim 3, further characterized in that selecting, from the plurality of reconstructed neighboring luma samples and the plurality of reconstructed neighboring chroma samples, the reference luma sample group and the reference chroma sample group, includes: determining whether the signaling of the predetermined number of reference sets from a control flag on a selected one from the group consisting of TB (transform block), CB (encoding block), segment, image, and sequence level, and in response to a determination that the signaling of the predetermined number of reference sets is enabled from the control flag, determining from a syntax that a particular set from the predetermined number of reference sets is selected as the reference luma sample group and the reference chroma sample group.

6. The method according to claim 1, further characterized in that reconstructing the respective sample value of the chroma block from the weighted combination of the respective first corresponding reconstructed sample value of the luma block using the multiple-model linear model, and the respective second reconstructed sample value of a neighboring chroma block of the intra-prediction mode includes: receiving at TB / CB / segment / image / sequence level at least one of a first signal indicating a weight of the respective first corresponding reconstructed sample value, and a second signal indicating a type of intra-prediction mode.

7. The method according to claim 1, further characterized in that reconstructing the respective sample value of the chroma block from the weighted combination of the respective first reconstructed sample value corresponding to the luma block using the multiple-model linear model, and the respective second reconstructed sample value of a neighboring chroma block from the intra-prediction mode is performed when a control flag indicated in TB / CB / segment / image / sequence level is enabled.

8. The method according to claim 7, further characterized in that the intra-prediction mode is derived using previously coded neighboring samples through a gradient analysis.

9. The method according to claim 1, further characterized in that the plurality of neighboring luma samples are selected from an individual left line and an individual top line surrounding the luma block, and the plurality of neighboring chroma samples are selected from an individual left line and an individual top line surrounding the chroma block. 10.The method according to claim 1, further characterized in that reconstructing a respective sample value of the chroma block from a weighted combination of a respective first corresponding reconstructed sample value derived from the luma block using the multiple-model linear model, and a respective second reconstructed sample value from a neighboring chroma block in an intra-prediction mode includes: according to a determination that a respective luma value of the luma block is less than or equal to the threshold luma value: applying the first linear model to the respective luma value of the luma block to obtain the respective first corresponding reconstructed sample value; and according to a determination that a respective luma value of the luma block is greater than the threshold luma value: applying the second linear model to the respective luma value of the luma block to obtain the respective first corresponding reconstructed sample value.

11. An electronic apparatus, characterized in that it comprises: one or more processing units; memory coupled to the one or more processing units; and a plurality of programs stored in the memory which, when executed by the one or more processing units, cause the electronic apparatus to perform the method of any one of claims 1 to 10.

12. A computer-readable storage medium, characterized in that it has stored therein a stream of bits comprising video information generated by the method for constructing the chroma block of the video signal of any of claims 1 to 10.

13. A non-transient, computer-readable storage medium, which causes an electronic apparatus having one or more processing units to carry out the method of any of claims 1 to 10.

14. A computer-readable storage medium that stores a bit stream to be decoded by the method according to any of claims 1 to 10.

15. A method for receiving a bit stream to be decoded by an image decoder device, wherein the image decoder device comprises: one or more processors; and a memory configured to store instructions executable by the one or more processors, wherein the one or more processors, after execution of the instructions, are configured to carry out the method in any of claims 1 to 10.

Images