Method and system for processing video content

Abstract

The embodiments disclosed herein provide a system and method for processing video content. The method includes: receiving chroma blocks and luminance blocks associated with a screen; determining luminance scaling information associated with the luminance blocks; determining a chroma scaling factor based on the luminance scaling information; and processing the chroma blocks using the chroma scaling factor.

Description

Method and System for Processing Video Content This disclosure generally relates to video processing, and more particularly to methods and systems for performing in-loop luminance mapping with chroma scaling. Cross-reference to Related Applications This disclosure claims the benefit of priority of U.S. Provisional Application No. 62 / 813,728, filed on March 4, 2019, and U.S. Provisional Application No. 62 / 817,546, filed on March 12, 2019, both of which are hereby incorporated by reference in their entirety. Video coding systems are commonly used to compress digital video signals, for example, to reduce the storage space consumed or to reduce the transmission bandwidth consumption associated with such signals. With the increasing popularity of high-definition (HD) video (e.g., video with a resolution of 1920×1080 pixels) in various video compression applications such as online video streaming, video conferencing, or video surveillance, there is a continuing need to develop video coding tools that can increase the compression efficiency of video data. For example, video surveillance applications are being used more and more widely in many application scenarios (e.g., security, traffic, or environmental monitoring, etc.), and the number and resolution of surveillance devices continue to grow rapidly. Many video surveillance application scenarios tend to provide users with HD video to capture more information because HD video has more pixels per frame to capture such information. However, an HD video bitstream may have a high bitrate, which requires high bandwidth for transmission and large storage capacity for storage. For example, for real-life transmission, a surveillance video stream with an average resolution of 1920×1080 may require a bandwidth of up to 4 Mbps. In addition, video surveillance is usually continuous 24 / 7, which poses a great challenge to the storage system if the video data is to be stored. The demand for high bandwidth and large storage space for HD video thus becomes the biggest limiting factor in the large-scale deployment of HD video in video surveillance. Embodiments of this disclosure provide a method for processing video content. The method may include: receiving a chroma block and a luminance block associated with a picture; determining luminance scaling information associated with the luminance block; determining a chroma scaling factor based on the luminance scaling information; and processing the chroma block using the chroma scaling factor. Embodiments of this disclosure provide a device for processing video content. The device may include: a memory that stores a set of instructions; and a processor coupled to the memory and configured to execute the set of instructions to cause the device to perform: receiving a chroma block and a luminance block associated with a picture; determining luminance scaling information associated with the luminance block; determining a chroma scaling factor based on the luminance scaling information; and processing the chroma block using the chroma scaling factor. Embodiments of the present disclosure provide a non-transitory computer-readable storage medium storing a set of instructions executable by one or more processors of a device to cause the device to perform a method for processing video content. The method includes: receiving a chrominance block and a luminance block associated with a picture; determining luminance scaling information associated with the luminance block; determining a chrominance scaling factor based on the luminance scaling information; and processing the chrominance block using the chrominance scaling factor. Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. The following description refers to the accompanying drawings, where like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations set forth in the description of the following exemplary embodiments do not represent all implementations consistent with the present invention. Rather, they are merely examples of apparatus and methods consistent with aspects of the invention as recited in the appended claims. Unless otherwise noted, the term "or" encompasses all possible combinations except where infeasible. For example, if it is claimed that a component can include A or B, then the component can include A or B, or A and B, unless otherwise explicitly stated or infeasible. As a second example, if it is claimed that a component can include A, B, or C, then the component can include A or B or C, or A and B, or A and C, or B and C, or A and B and C, unless otherwise explicitly stated or infeasible. Video is a set of still pictures (or "frames") configured to store visual information in a time sequence. A video capture device (e.g., a camera) can be used to capture and store these pictures in a time sequence, and a video playback device (e.g., a television, a computer, a smartphone, a tablet computer, a video player, or any end-user device with a display function) can be used to display these pictures in a time sequence. Additionally, in some applications, a video capture device can transmit the captured video to a video playback device (e.g., a computer with a screen) in real life, such as for surveillance, meetings, or real-life broadcasts. To reduce the storage space and transmission bandwidth required for such applications, the video can be compressed before storage and transmission and decompressed before display. This compression and decompression can be implemented by software or special hardware executed by a processor (e.g., the processor of a general-purpose computer). The module for compression is generally referred to as an "encoder", and the module for decompression is generally referred to as a "decoder". The encoder and decoder can be collectively referred to as a "codec". The encoder and decoder can be implemented as any of a variety of suitable hardware, software, or combinations thereof. For example, the hardware implementation of the encoder and decoder can include circuits such as one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), discrete logic, or any combination thereof. The software implementation of the encoder and decoder can include code, computer-executable instructions, firmware, or any suitable computer-implemented algorithm or process fixed in a computer-readable medium. Video compression and decompression can be achieved through various algorithms or standards, such as MPEG-1, MPEG-2, MPEG-4, the H.26x series, etc. In some applications, the codec can decompress the video from a first encoding standard and recompress the decompressed video using a second encoding standard, in which case the codec can be referred to as a "transcodec". Video encoding processing can identify and retain the useful information that can be used to reconstruct the picture and ignore the information that is irrelevant to the reconstruction. If ignored, this unimportant information cannot be fully reconstructed, and such encoding processing can be referred to as "lossy". Otherwise, it is referred to as "lossless". Most encoding processing is lossy, which is a trade-off for reducing the required storage space and transmission bandwidth. The useful information of the encoded picture (referred to as the "current picture") includes the changes relative to a reference picture (e.g., a previously encoded and reconstructed picture). Such changes can include changes in the position of pixels, brightness changes, or color changes, with the change in position being of the greatest concern. The change in the position of a group of pixels representing an object can reflect the movement of the object between the reference picture and the current picture. A picture encoded without referring to another picture (i.e., it is its own reference picture) is referred to as an "I-picture". A picture encoded using a previous picture as a reference picture is referred to as a "P-picture". A picture encoded using both a previous picture and a future picture as reference pictures (i.e., the reference is bidirectional) is referred to as a "B-picture". As described above, video surveillance using HD video faces challenges of high bandwidth and large storage space. To address these challenges, the bit rate of the encoded video can be reduced. Among I-pictures, P-pictures, and B-pictures, I-pictures have the highest bit rate. Since the background of most surveillance videos is almost static, one way to reduce the total bit rate of the encoded video can be to use fewer I-pictures for video encoding. However, the improvement using fewer I-pictures may be negligible because I-pictures are typically not common in encoded videos. For example, in a typical video bitstream, the ratio of I-pictures, B-pictures, and P-pictures can be 1:20:9, where I-pictures can account for less than 10% of the total bit rate. In other words, in this example, even if all I-pictures are removed, the reduction in bit rate may be no more than 10%. The present disclosure provides methods, devices, and systems for feature-based video processing for video surveillance. Herein, "feature" may refer to content features associated with the video content in the frame, motion features associated with motion estimation for encoding or decoding the frame, or both. For example, in one or more consecutive frames of a video sequence, the content feature can be a pixel that is related to at least one object, scene, or environmental event in the frame. For another example, the motion feature can include information associated with video encoding processing, and examples thereof will be described below. In the present disclosure, when encoding frames of a video sequence, a feature classifier can be used to detect and classify one or more features of the frames of the video sequence. Different types of features can be associated with different priority levels, which in turn are associated with different encoding bit rates. Different priority levels can be associated with different parameter sets for encoding, which can result in different encoding quality levels. The higher the priority level, the higher the video quality that the associated parameter set can produce. By using this feature-based video processing, the bit rate can be significantly reduced for surveillance videos without causing significant information loss. In addition, embodiments of the present disclosure can customize the correspondence between the priority levels and the parameter sets for different application scenarios (e.g., security, traffic, environmental monitoring, etc.), thereby significantly improving the video encoding quality and significantly reducing the costs of bandwidth and storage space. Figure 1 depicts the structure of an exemplary video sequence 100 according to some embodiments of the present disclosure. The video sequence 100 can be a live video or a video that has been captured and archived. The video 100 can be a real-life video, a computer-generated video (e.g., a computer game video), or a combination thereof (e.g., a real-life video with augmented reality effects). The video sequence 100 can be input from a video capture device (e.g., a camera), a video archive containing previously captured videos (e.g., a video file stored in a storage device), or from a video feed interface (e.g., a video broadcast transceiver) to receive the video from a video content provider. As FIG. 1 shows, the video sequence 100 can include a series of frames that are temporally arranged along a time axis, including frames 102, 104, 106, and 108. Frames 102-106 are consecutive, and there can be more frames between frames 106 and 108. In FIG. 1, frame 102 is an I-picture, and its reference frame is frame 102 itself. Frame 104 is a P-picture, and its reference frame is frame 102, as indicated by the arrow. Frame 106 is a B-picture, and its reference frames are frames 104 and 108, as indicated by the arrows. In some embodiments, the reference frame of a frame (e.g., frame 104) may not be the frame immediately before or after that frame. For example, the reference frame of frame 104 can be a frame before frame 102. It should be noted that the reference frames of frames 102-106 are only exemplary, and the present disclosure does not limit the embodiments of the reference frames to be FIG. the examples shown in 1. Typically, due to the computational complexity of such work, a video codec does not encode or decode an entire frame at once. Instead, it divides the frame into basic segments and encodes or decodes the frame segment by segment. Such a basic segment is referred to as a basic processing unit (BPU) in the present disclosure. For example, FIG. The structure 110 in FIG. 1 shows an example structure of a frame (e.g., any of frames 102-108) of the video sequence 100. In the structure 110, the frame is divided into 4×4 basic processing units, and their boundaries are shown by dashed lines. In some embodiments, this basic processing unit in some video coding standards (e.g., MPEG family, H.261, H.263, or H.264 / AVC) may be referred to as a "macroblock", or in some other video coding standards (e.g., H.265 / HEVC or H.266 / VVC) is referred to as a "coding tree unit (CTU)". In a frame, the basic processing unit may have a variable size, such as 128×128, 64×64, 32×32, 16×16, 4×8, 16×32 or pixels of any arbitrary shape and size. The size and shape of the basic processing unit can be selected for a frame according to the balance of coding efficiency and the level of detail retained in the basic processing unit. The basic processing unit can be a logical unit, which may include a group of different types of video data stored in a computer memory (e.g., in a video frame buffer). For example, a basic processing unit of a color frame may include: a luminance component (Y), which represents achromatic luminance information; one or more chrominance components (e.g., Cb and Cr), which represent color information; and associated syntax elements, where the luminance and chrominance components may have the same size as the basic processing unit. In some video coding standards (e.g., H.265 / HEVC or H.266 / VVC), the luminance and chrominance components may be referred to as "coding tree blocks" ("CTB"). Any operation performed on the basic processing unit can be repeated for each of its luminance and chrominance components. Video encoding has a multi-stage operation, such as the examples to be described in detail in FIGS. 2A-2B and 3A-3B. For each stage, the size of the basic processing unit may still be too large to be processed, and thus the unit can be further divided into segments referred to as "basic processing sub-units" in this disclosure. In some embodiments, in some video coding standards (e.g., MPEG family, H.261, H.263, or H.264 / AVC), the basic processing sub-unit can be referred to as a "block", or in some other video coding standards (e.g., H.265 / HEVC or H.266 / VVC) as a "coding unit (CU)". The basic processing sub-unit can have the same or smaller size than the basic processing unit. Similar to the basic processing unit, the basic processing sub-unit can also be a logical unit that can include a group of different types of video data (e.g., Y, Cb, Cr, and associated syntax elements) stored in a computer memory (e.g., in a video frame buffer). Any operation performed on the basic processing sub-unit can be repeated for each of its luminance and chrominance components. It should be noted that this division can be carried out to a further extent depending on the processing requirements. It should also be noted that different stages can use different schemes to divide the basic processing unit. For example, in the mode decision stage (instances of which will be depicted in detail in FIG 2B), the encoder can decide which prediction mode (e.g., intra-frame prediction or inter-frame prediction) to use for the basic processing unit, which may be too large to make this decision. The encoder can divide the basic processing unit into multiple basic processing sub-units (e.g., CUs in H.265 / HEVC or H.266 / VVC), and decide the prediction type for each individual basic processing sub-unit. For another example, in the prediction stage (instances of which will be depicted in detail in FIG 2A), the encoder can perform prediction operations at the basic processing sub-unit (e.g., CU) level. However, in some cases the basic processing sub-unit may still be too large to be processed. The encoder can further divide the basic processing sub-unit into smaller segments (e.g., referred to as "prediction blocks" or "PBs" in H.265 / HEVC or H.266 / VVC), at which level prediction operations can be performed. For another example, in the transformation stage (instances of which will be depicted in detail in FIG As shown in FIG. 2A), the encoder may perform a transformation operation on a basic processing unit (e.g., a CU) of the residual. However, in some cases, the basic processing unit may still be too large to be processed. The encoder may further divide the basic processing unit into smaller segments (e.g., referred to as "transformation blocks" or "TBs" in H.265 / HEVC or H.266 / VVC), and the transformation operation may be performed at this level. It should be noted that the partitioning scheme of the same basic processing unit in the prediction stage and the transformation stage may be different. For example, in H.265 / HEVC or H.266 / VVC, the prediction blocks and transformation blocks of the same CU may have different sizes and numbers. In FIG. 1's structure 110, the basic processing unit 112 is further divided into 3×3 basic processing sub-units, and its boundaries are shown by dotted lines. Different basic processing units of the same picture can be divided into basic processing sub-units by different schemes. In some implementations, to provide the ability for parallel processing and error resilience in video encoding and decoding, a picture can be divided into regions for processing such that for one region of the picture, the encoding or decoding process does not depend on information from any other region of the picture. In other words, each region of the picture can be processed independently. Thereby, the codec can process different regions of the picture in parallel and thus increase the encoding efficiency. Additionally, when the data of one region being processed is damaged or lost during network transmission, the codec can correctly encode or decode other regions of the same picture without relying on the damaged or lost data, thereby providing the ability of error recovery. In some video encoding standards, a picture can be divided into different types of regions. For example, H.265 / HEVC and H.266 / VVC provide two types of regions: "slices" and "tiles". It should be noted that different pictures of the video sequence 100 can have different partitioning schemes for dividing a picture into regions. For example, in FIG. 1, the structure 110 is divided into three regions 114, 116, and 118, and their boundaries are shown by solid lines in the structure 110. Region 114 includes four basic processing units. Regions 116 and 118 each include six basic processing units. It should be noted that FIG. the basic processing units, basic processing sub-units, and regions of the structure 110 in FIG. 1 are only illustrative, and the present disclosure is not limited to its embodiments. FIG. 2A depicts a schematic diagram of an exemplary encoding process 200A according to some embodiments of the present disclosure. According to process 200A, the encoder may encode the video sequence 202 into a video bitstream 228. Similar to Figure For video sequence 100 of FIG. 1, video sequence 202 may include a set of pictures (referred to as "original pictures") arranged in chronological order. Similar to Figure the structure 110 of FIG. 1, each original picture of video sequence 202 may be divided by an encoder into basic processing units, basic processing subunits, or regions for processing. In some embodiments, the encoder may perform processing 200A at the level of basic processing units on each original picture of video sequence 202. For example, the encoder may iteratively perform processing 200A, where the encoder may encode a basic processing unit in one iteration of processing 200A. In some embodiments, the encoder may perform processing 200A in parallel on regions (e.g., regions 114-118) of each original picture of video sequence 202. In Figure 2A, the encoder may feed basic processing units (referred to as "original BPUs") of the original pictures of video sequence 202 to a prediction stage 204 to generate prediction data 206 and prediction BPU 208. The encoder may subtract prediction BPU 208 from the original BPU to generate a residual BPU 210. The encoder may feed residual BPU 210 to a transform stage 212 and a quantization stage 214 to generate quantized transform coefficients 216. The encoder may feed prediction data 206 and quantized transform coefficients 216 to a binary encoding stage 226 to generate a video bitstream 228. Components 202, 204, 206, 208, 210, 212, 214, 216, 226, and 228 may be referred to as a "forward path". During processing 200A, after the quantization stage 214, the encoder may feed quantized transform coefficients 216 to an inverse quantization stage 218 and an inverse transform stage 220 to generate a reconstructed residual BPU 222. The encoder may add reconstructed residual BPU 222 to prediction BPU 208 to generate a prediction reference 224, which is used in prediction stage 204 for the next iteration of processing 200A. Components 218, 220, 222, and 224 of processing 200A may be referred to as a "reconstruction path". This reconstruction path may be used to ensure that both the encoder and the decoder use the same reference data for prediction. The encoder may iteratively perform processing 200A to encode each original BPU (in the forward path) of the original picture and generate a prediction reference 224 for encoding the next original BPU (in the reconstruction path) of the original picture. After encoding all the original BPUs of the original picture, the encoder may continue to encode the next picture in video sequence 202. Referring to process 200A, the encoder can receive video sequence 202 generated by a video capture device (e.g., a camera). As used herein, the term "receive" can refer to receiving, inputting, acquiring, obtaining, getting, reading, accessing, or any other form of action that inputs data. In the prediction stage 204, at the current iteration, the encoder can receive the original BPU and prediction reference 224, and perform a prediction operation to generate prediction data 206 and prediction BPU 208. The prediction reference 224 can be generated from the reconstruction path of a previous iteration of process 200A. The purpose of the prediction stage 204 is to reduce information redundancy by extracting prediction data 206 from the prediction data 206 and prediction reference 224 that can be used to reconstruct the original BPU into the prediction BPU 208. Ideally, the prediction BPU 208 can be the same as the original BPU. However, due to non-ideal prediction and reconstruction operations, the prediction BPU 208 is usually slightly different from the original BPU. To record this difference, after generating the prediction BPU 208, the encoder can subtract it from the original BPU to generate a residual BPU 210. For example, the encoder can subtract the value of a pixel of the prediction BPU 208 from the value of the corresponding pixel of the original BPU (e.g., grayscale value or RGB value). These subtractions between the corresponding pixels of the original BPU and the prediction BPU 208 result in each pixel of the residual BPU 210 having a residual value. Compared with the original BPU, the prediction data 206 and the residual BPU 210 can have fewer bits, but they can be used to reconstruct the original BPU without significant quality degradation. Thus, the original BPU is compressed. To further compress the residual BPU 210, in the transform stage 212, the encoder can reduce the spatial redundancy of the residual BPU 210 by decomposing the residual BPU 210 into a set of two-dimensional "basis patterns", with each basis pattern associated with a "transformation coefficient". The basis patterns can have the same size (e.g., the size of the residual BPU 210). Each basis pattern can represent a variation frequency (e.g., the frequency of luminance variation) component of the residual BPU 210. None of these basis patterns can be reproduced from any combination (e.g., linear combination) of any other basis patterns. In other words, this decomposition can decompose the variation of the residual BPU 210 into the frequency domain. This kind of decomposition is similar to the discrete Fourier transform of a function, where the basis patterns are similar to the basis functions of the discrete Fourier transform (e.g., trigonometric functions), and the transformation coefficients are similar to the coefficients associated with the basis functions. Different transformation algorithms can use different basis patterns. Various transformation algorithms can be used in the transformation stage 212, such as the discrete cosine transform, the discrete sine transform, etc. The transformation in the transformation stage 212 is reversible. That is, the encoder can recover the residual BPU 210 through the reverse operation of the transformation (referred to as "inverse transformation"). For example, in order to recover the pixels of the residual BPU 210, the inverse transformation can multiply the values of the corresponding pixels of the basis pattern by individual correlation coefficients and then sum the products to generate a weighted sum. For a video coding standard, both the encoder and the decoder can use the same transformation algorithm (and thus, the same basis pattern). Therefore, the encoder can record only the transformation coefficients, and the decoder can reconstruct the residual BPU 210 from them without having to receive the basis pattern from the encoder. Compared with the residual BPU 210, the transformation coefficients can have fewer bits, but they can be used to reconstruct the residual BPU 210 without significant quality degradation. Therefore, the residual BPU 210 is further compressed. In the quantization stage 214, the encoder can further compress the transformation coefficients. In the transformation process, different basis patterns can represent different variation frequencies (e.g., luminance variation frequencies). Since the human eye is generally more sensitive to low-frequency variations, the encoder can ignore the information of high-frequency variations without significant quality degradation in decoding. For example, in the quantization stage 214, the encoder can generate the quantized transformation coefficients 216 by dividing each transformation coefficient by an integer value (referred to as "quantization parameter") and rounding the quotient to the nearest integer value. Through such an operation, some transformation coefficients of the high-frequency basis pattern can be transformed into zero, and the transformation coefficients of the low-frequency basis pattern can be transformed into smaller integers. The encoder can ignore the zero-valued quantized transformation coefficients 216, thereby further compressing the transformation coefficients. The quantization process is also reversible, where the quantized transformation coefficients 216 can be reconstructed into the transformation coefficients in the reverse operation of quantization (referred to as "dequantization"). Because in the rounding operation, the encoder ignores the remainder of such division, the quantization stage 214 can be lossy. Typically, in the process 200A, the quantization stage 214 can contribute the most information loss. The greater the information loss, the fewer bits the quantized transformation coefficients 216 require. To obtain different levels of information loss, the encoder can use different values of the quantization parameter or any parameter of the quantization process. In the binary encoding stage 226, the encoder may use binary encoding techniques, such as entropy encoding, variable length encoding, arithmetic encoding, Huffman encoding, context adaptive binary arithmetic encoding, or any other lossless or lossy compression algorithm, to encode the prediction data 206 and the quantized transform coefficients 216. In some embodiments, in addition to the prediction data 206 and the quantized transform coefficients 216, the encoder may also encode other information in the binary encoding stage 226, such as the prediction mode used in the prediction stage 204, the parameters of the prediction operation, the type of transform in the transform stage 212, the parameters of the quantization process (e.g., quantization parameter), or the encoder control parameters (e.g., bit rate control parameter), etc. The encoder may use the output data of the binary encoding stage 226 to generate the video bitstream 228. In some embodiments, the video bitstream 228 may be further packetized for network transmission. Referring to the reconstruction path of the processing 200A, in the inverse quantization stage 218, the encoder may perform inverse quantization on the quantized transform coefficients 216 to generate reconstructed transform coefficients. In the inverse transform stage 220, the encoder may generate a reconstructed residual BPU 222 based on the reconstructed transform coefficients. The encoder may add the reconstructed residual BPU 222 to the prediction BPU 208 to generate a prediction reference 224, which is used in the next iteration of the processing 200A. It should be noted that other variations of the processing 200A may be used to encode the video sequence 202. In some embodiments, the encoder may perform the stages of the processing 200A in a different order. In some embodiments, one or more stages of the processing 200A may be combined into a single stage. In some embodiments, a single stage of the processing 200A may be divided into multiple stages. For example, the transform stage 212 and the quantization stage 214 may be combined into a single stage. In some embodiments, the processing 200A may include additional stages, and in some embodiments, the processing 200A may omit Figure one or more stages in Figure 2A. In general, prediction techniques can be classified into two types: spatial domain prediction and temporal domain prediction. Spatial domain prediction (e.g., in-frame picture prediction or "intra prediction") can use pixels from one or more already-encoded adjacent BPUs in the same picture to predict the current BPU. That is, the prediction reference 224 in spatial domain prediction can include adjacent BPUs. Spatial domain prediction can reduce the inherent spatial redundancy of the picture. Temporal domain prediction (e.g., inter-frame picture prediction or "inter prediction") can use regions from one or more already-encoded pictures to predict the current BPU. That is, the prediction reference 224 in temporal domain prediction can include encoded pictures. Temporal domain prediction can reduce the inherent temporal redundancy of several pictures. Referring to processing 200B, in the forwarding path, the encoder performs prediction operations in the spatial domain prediction stage 2042 and the temporal domain prediction stage 2044. For example, in the spatial domain prediction stage 2042, the encoder can perform intra prediction. For the original BPU of the picture being encoded, the prediction reference 224 can include one or more adjacent BPUs that have been encoded (in the forwarding path) and reconstructed (in the reconstruction path) in the same picture. By extrapolating the adjacent BPUs, the encoder can generate a predicted BPU 208. Such extrapolation techniques can include, for example, linear extrapolation or interpolation, polynomial extrapolation or interpolation, etc. In some embodiments, the encoder can perform extrapolation at the pixel level, such as by extrapolating the value of the corresponding pixel for each pixel of the predicted BPU 208. The adjacent BPUs used for extrapolation can be in various directions relative to the original BPU, such as the vertical direction (e.g., above the original BPU), the horizontal direction (e.g., to the left of the original BPU), the diagonal direction (e.g., in the lower left, lower right, upper left, or upper right of the original BPU), or any direction defined in the used video coding standard. For intra prediction, the prediction data 206 can include, for example, the position (e.g., coordinates) of the adjacent BPUs used, the size of the adjacent BPUs used, the parameters of the extrapolation, or the direction of the adjacent BPUs used relative to the original BPU, etc. For another example, in the temporal prediction stage 2044, the encoder may perform inter-frame prediction. For the original BPU of the current picture, the prediction reference 224 may include one or more pictures (referred to as "reference pictures") that have been encoded (in the transmission path) and reconstructed (in the reconstruction path). In some embodiments, the reference pictures may be encoded and reconstructed on a per-BPU basis. For example, the encoder may add the reconstructed residual BPU 222 to the predicted BPU 208 to generate a reconstructed BPU. After all the reconstructed BPUs of the same picture are generated, the encoder may generate a reconstructed picture as a reference picture. The encoder may perform an operation of "motion estimation" to search for a matching region within a reference picture range (referred to as a "search window"). The position of the search window in the reference picture may be determined based on the position of the original BPU in the current picture. For example, the search window may be centered in the reference picture at a position having the same coordinates as the original BPU in the current picture and may be extended by a predetermined distance. When the encoder identifies (e.g., by using a pel-recursive algorithm or a block matching algorithm, etc.) a region in the search window that is similar to the original BPU, the encoder may determine this region as a matching region. The matching region may have dimensions different from those of the original BPU (e.g., smaller, equal, larger, or of a different shape). Since the reference picture and the current picture are temporally separated on the time axis (as shown in FIG 1), it can be understood that the matching region "moves" to the position of the original BPU over time. The encoder may record the direction and distance of such motion as a "motion vector". When using multiple reference pictures (such as FIG 106 of picture 1 in FIG. 1), the encoder may search for the matching region and determine its associated motion vector for each reference picture. In some embodiments, the encoder may assign weights to the pixel values of the matching regions of the individual matching reference pictures. Motion estimation can be used to identify various types of motion (such as translation, rotation, or scaling, etc.). For inter-frame prediction, the prediction data 206 may include, for example, the position of the matching region (e.g., coordinates), the motion vector associated with the matching region, the number of reference pictures, or the weights associated with the reference pictures, etc. To generate the predicted BPU 208, the encoder may perform an operation of "motion compensation". Motion compensation can be used to reconstruct the predicted BPU 208 based on the prediction data 206 (e.g., the motion vector) and the prediction reference 224. For example, the encoder may move the matching region of the reference picture according to the motion vector, where the encoder may predict the original BPU of the current picture. When using multiple reference pictures (such as FIG When moving the matching area of the reference picture (e.g., the matching area of picture 106 of 1), the encoder can move the matching area of the reference picture according to the respective motion vectors and the average pixel value of the matching area. In some embodiments, if the encoder has assigned weights to the pixel values of the matching areas of the respective matching reference pictures, the encoder can add the weighted sums of the pixel values of the moved matching areas. In some embodiments, inter-block prediction can be unidirectional or bidirectional. Unidirectional inter-block prediction can use one or more reference pictures in the same temporal direction relative to the current picture. For example, Figure In Figure 1, picture 104 is a unidirectional inter-block prediction picture, where the reference picture (i.e., picture 102) is before picture 104. Bidirectional inter-block prediction can use one or more reference pictures in both temporal directions relative to the current picture. For example, Figure In Figure 1, picture 106 is a bidirectional inter-block prediction picture, where the reference pictures (i.e., pictures 104 and 108) are in both temporal directions relative to picture 104. Still referring to the forwarding path of process 200B, after the spatial domain prediction 2042 and the temporal domain prediction stage 2044, at the mode decision stage 230, the encoder can select a prediction mode (e.g., one of intra-block prediction or inter-block prediction) for the current iteration of process 200B. For example, the encoder can perform rate-distortion optimization techniques, where the encoder can select the prediction mode that minimizes the value of the cost function depending on the bit rate of the candidate prediction mode and the distortion of the reconstructed reference picture under the candidate prediction mode. Depending on the selected prediction mode, the encoder can generate the corresponding prediction BPU 208 and prediction data 206. In the reconstruction path of process 200B, if an intra prediction mode has been selected in the transfer path, then after generating a prediction reference 224 (e.g., the current BPU, which has been encoded and reconstructed in the current picture), the encoder may directly feed the prediction reference 224 to the spatial prediction stage 2042 for later use (e.g., for extrapolation of the next BPU in the current picture). If an inter prediction mode has been selected in the transfer path, then after generating a prediction reference 224 (e.g., the current picture, in which all BPUs have been encoded and reconstructed), the encoder may feed the prediction reference 224 to the loop filter stage 232, where the encoder may apply loop filtering to the prediction reference 224 to reduce or eliminate the distortion introduced by inter prediction (e.g., blocking artifacts). In the loop filter stage 232, the encoder may apply various loop filtering techniques, such as deblocking, sample adaptive offset, or adaptive loop filtering. The reference picture for loop filtering may be stored in a buffer 234 (or "decoded picture buffer") for later use (e.g., as an inter prediction reference picture for future pictures of the video sequence 202). The encoder may store one or more reference pictures in the buffer 234 for use in the temporal prediction stage 2044. In some embodiments, the encoder may encode the loop filter parameters (e.g., loop filter strength) in the binary encoding stage 226, along with the encoded quantization transform coefficients 216, prediction data 206, and other information. Figure 3A depicts a schematic diagram of an exemplary decoding process 300A according to some embodiments of the present disclosure. The process 300A may be a decompression process corresponding to the compression process 200A in Figure 2A. In some embodiments, the process 300A may be similar to the reconstruction path of the process 200A. According to the process 300A, the encoder may decode the video bitstream 228 into a video stream 304. The video stream 304 may be very similar to the video sequence 202. However, due to information loss in the compression and decompression processes (e.g., Figure the quantization stage 214 in FIGS. 2A-2B), generally the video stream 304 will not be identical to the video sequence 202. Similar to Figure The processing of 200A and 200B in 2A-2B is similar. The decoder can perform processing 300A at the basic processing unit (BPU) level on each frame encoded in the video bitstream 228. For example, the decoder can iteratively perform processing 300A, where the decoder can decode the basic processing unit in one iteration of processing 300A. In some embodiments, the decoder can perform processing 300A in parallel on regions (e.g., regions 114-118) of each frame encoded in the video bitstream 228. In Figure 3A, the decoder can feed a portion of the video bitstream 228 associated with the basic processing unit of the encoded frame (referred to as the "encoded BPU") to the binary decoding stage 302. In the binary decoding stage 302, the decoder can decode the portion into prediction data 206 and quantized transform coefficients 216. The decoder can feed the quantized transform coefficients 216 to the inverse quantization stage 218 and the inverse transform stage 220 to generate a reconstructed residual BPU 222. The decoder can feed the prediction data 206 to the prediction stage 204 to generate a predicted BPU 208. The decoder can add the reconstructed residual BPU 222 to the predicted BPU 208 to generate a prediction reference 224. In some embodiments, the prediction reference 224 can be stored in a buffer (e.g., a decoded frame buffer in a computer memory). The decoder can feed the prediction reference 224 to the prediction stage 204 for performing a prediction operation in the next iteration of processing 300A. The decoder can iteratively perform processing 300A to decode each encoded BPU of the encoded frame and generate a prediction reference 224 for encoding the next encoded BPU of the encoded frame. After decoding all the encoded BPUs of the encoded frame, the decoder can output the frame to the video stream 304 for display and continue to decode the next encoded frame in the video bitstream 228. In the binary decoding stage 302, the decoder can perform the reverse operation of the binary encoding technique used by the encoder (such binary encoding techniques as entropy encoding, variable length encoding, arithmetic encoding, Huffman encoding, context adaptive binary arithmetic encoding, or any other lossless compression algorithm). In some embodiments, in addition to the prediction data 206 and the quantized transform coefficients 216, the decoder can also decode other information in the binary decoding stage 302, such other information as a prediction mode, parameters of a prediction operation, a transform type, parameters of quantization processing (e.g., quantization parameters), or encoder control parameters (e.g., bit rate control parameters), etc. In some embodiments, if the video bitstream 228 is transmitted in packets over a network, the decoder can depacketize the video bitstream 228 before feeding it to the binary decoding stage 302. Figure FIG. 3B illustrates another exemplary decoding process 300B according to some embodiments of the present disclosure. Process 300B may be adapted from process 300A. For example, process 300B may be used by a decoder to conform to a hybrid video coding standard (e.g., H.26x series). Compared with process 300A, process 300B additionally divides the prediction stage 204 into a spatial prediction stage 2042 and a temporal prediction stage 2044, and additionally includes a loop filter stage 232 and a buffer 234. In process 300B, for an encoded basic processing unit (referred to as the "current BPU") of the encoded picture being decoded (referred to as the "current picture"), the prediction data 206 decoded by the decoder from the binary decoding stage 302 may include various types of data, depending on which prediction mode the encoder uses to encode the current BPU. For example, if the encoder uses intra prediction to encode the current BPU, the prediction data 206 may include a prediction mode indicator (e.g., a flag value) that indicates intra prediction, or parameters of the intra prediction operation, etc. The parameters of the intra prediction operation may include, for example, the position (e.g., coordinates) of one or more adjacent BPUs used as references, the size of the adjacent BPUs, extrapolation parameters, or the direction of the adjacent BPUs relative to the original BPU, etc. As another example, if the encoder uses inter prediction to encode the current BPU, the prediction data 206 may include a prediction mode indicator (e.g., a flag value) that indicates inter prediction, or parameters of the inter prediction operation, etc. The parameters of the inter prediction operation may include, for example, the number of reference pictures associated with the current BPU, the weights respectively associated with the reference pictures, the position (e.g., coordinates) of one or more matching regions in each of the reference pictures, or one or more motion vectors respectively associated with the matching regions. Based on the prediction mode indicator, the decoder may determine whether to perform spatial prediction (e.g., intra prediction) in the spatial prediction stage 2042 or temporal prediction (e.g., inter prediction) in the temporal prediction stage 2044. FIG. The details of performing such spatial prediction or temporal prediction have been described in FIG. 2B, and thus their descriptions will not be repeated below. After performing such spatial prediction or temporal prediction, the decoder may generate a predicted BPU 208. The decoder may add the predicted BPU 208 to the reconstructed residual BPU 222 to generate a predicted reference 224, as FIG. shown in FIG. 3A. In process 300B, the decoder can feed prediction reference 224 to the spatial prediction stage 2042 or the temporal prediction stage 2044 for performing prediction operations in the next iteration of process 300B. For example, if the current BPU is decoded using intra prediction in the spatial prediction stage 2042, after generating the prediction reference 224 (e.g., the decoded current BPU), the decoder can directly feed the prediction reference 224 to the spatial prediction stage 2042 for later use (e.g., for extrapolation of the next BPU of the current picture). If the current BPU is decoded using inter prediction in the temporal prediction stage 2044, after generating the prediction reference 224 (e.g., the reference picture in which all BPUs have been decoded), the encoder can feed the prediction reference 224 to the loop filter stage 232 to reduce or eliminate distortion (e.g., the blocking artifact). The decoder can Figure perform loop filtering on the prediction reference 224 in the manner described in FIG. 2B. The reference picture for loop filtering can be stored in the buffer 234 (e.g., the decoded picture buffer in a computer memory) for later use (e.g., can be used as an inter prediction reference picture for future encoded pictures of the video bitstream 228). The decoder can store one or more reference pictures in the buffer 234 for using them in the temporal prediction stage 2044. In some embodiments, when the prediction mode indicator of the prediction data 206 indicates that inter prediction is used to encode the current BPU, the prediction data may further include parameters of loop filtering (e.g., loop filter strength). Figure 4 is a block diagram of an exemplary device 400 for encoding or decoding video according to some embodiments of the present disclosure. As Figure shown in FIG. 4, the device 400 may include a processor 402. When the processor 402 executes the instructions described herein, the device 400 can become a dedicated machine for video encoding or decoding. The processor 402 can be any type of circuit capable of manipulating or processing information. For example, the processor 402 may include any number of central processing units (or “CPUs”), graphics processing units (or “GPUs”), neural processing units (“NPUs”), microcontroller units (“MCUs”), optical processors, programmable logic controllers, microcontrollers, microprocessors, digital signal processors, intellectual property (IP) cores, programmable logic arrays (PLAs), programmable array logics (PALs), generic array logics (GALs), complex programmable logic devices (CPLDs), field programmable gate arrays (FPGAs), system on chips (SoCs), or application specific integrated circuits (ASICs), etc. in any combination. In some embodiments, the processor 402 may also be a group of processors grouped into a single logic component. For example, as Figure As shown in FIG. 4, the processor 402 may include multiple processors, including processor 402a, processor 402b, and processor 402n. The device 400 may also include a memory 404, which is configured to store data (e.g., instruction sets, computer code, or intermediate data, etc.). For example, as Figure shown in FIG. 4, the stored data may include program instructions (e.g., program instructions for implementing the stages in processes 200A, 200B, 300A, or 300B) and data for processing (e.g., video sequence 202, video bitstream 228, or video stream 304). The processor 402 can access the program instructions and data for processing (e.g., via bus 410), and execute the program instructions to perform operations or computations on the data for processing. The memory 404 may include a high-speed random access storage device or a non-volatile storage device. In some embodiments, the memory 404 may include any combination of any number of random access memories (RAMs), read-only memories (ROMs), optical discs, magnetic disks, hard disks, solid-state hard disks, flash drives, secure digital (SD) cards, memory sticks, or compact flash (CF) cards. The memory 404 may also be a set of memories grouped into a single logical component ( Figure not shown in FIG. 4). The bus 410 can be a communication device that transfers data between components in the device 400, such as an internal bus (e.g., a CPU memory bus), or an external bus (e.g., a universal serial bus port, a peripheral component interconnect express port), etc. For ease of explanation and without causing ambiguity, in this disclosure, the processor 402 and other data processing circuits are collectively referred to as "data processing circuits". The data processing circuit can be implemented entirely in hardware, or a combination of software, hardware, or firmware. In addition, the data processing circuit can be a single independent module or can be fully combined or partially combined with any other component of the device 400. The device 400 may further include a network interface 406 to provide wired or wireless communication with a network (e.g., the Internet, an intranet, a local area network, or a mobile communication network, etc.). In some embodiments, the network interface 406 may include any combination of any number of network interface controllers (NICs), radio frequency (RF) modules, transponders, transceivers, modems, routers, gateways, wired network adapters, wireless network adapters, Bluetooth adapters, infrared adapters, near field communication (NFC) adapters, or cellular network chips, etc. In some embodiments, optionally, device 400 may further include a peripheral interface 408 to provide connection to one or more peripheral devices. As FIG As shown in FIG. 4, the peripheral devices may include, but are not limited to, a cursor control device (e.g., a mouse, a touchpad, or a touch screen), a keyboard, a display (e.g., a cathode ray tube display, a liquid crystal display, or a light emitting diode display), or a video input device (e.g., a camera or an input interface coupled to a video archive file), etc. Note that a video codec (e.g., the codec that performs processing 200A, 200B, 300A, or 300B) may be implemented as any combination of software or hardware modules in device 400. For example, some or all stages of processing 200A, 200B, 300A, or 300B may be implemented as one or more software modules in device 400, such as program instructions loaded into memory 404. As another example, some or all stages of processing 200A, 200B, 300A, or 300B may be implemented as one or more hardware modules in device 400, such as dedicated data processing circuits (e.g., FPGA, ASIC, or NPU, etc.). FIG FIG. 5 depicts a schematic diagram of an exemplary luma mapping with chroma scaling (LMCS) process 500 according to some embodiments of the present disclosure. For example, process 500 may be used by a decoder to conform to a hybrid video coding standard (e.g., the H.26x series). LMCS is a new processing block that is applied FIG before the loop filter stage 232 of FIG. 2B. LMCS may also be referred to as a reshaper. LMCS process 500 may include in-loop mapping of luma component values based on an adaptive piecewise linear model and luma-dependent chroma residue scaling of chroma components. As FIG As shown in FIG. 5, the in-loop mapping of luma component values based on an adaptive piecewise linear model may include a forward mapping stage 518 and an inverse mapping stage 508. The luma-dependent chroma residue scaling of chroma components may include a chroma scaling stage 520. The sample values before mapping or after inverse mapping may be referred to as samples in the original domain, and the sample values after mapping and before inverse mapping may be referred to as samples in the mapped domain. When LMCS is enabled, some stages in process 500 may be performed in the mapped domain instead of in the original domain. It should be understood that the forward mapping stage 518 and the inverse mapping stage 508 may be enabled / disabled at the sequence level through the use of SPS flags. As shown in FIG 5, Q -1 &T -1 Stage 504, reconstruction stage 506, and in-frame prediction stage 514 may be performed in the transform domain. For example, Q -1 &T -1 Stage 504 may include dequantization and inverse transformation, reconstruction stage 506 may include addition of luminance prediction and luminance residual, and in-frame prediction stage 508 may include luminance in-frame prediction. Loop filter stage 510, motion compensation stages 516 and 530, in-frame prediction stage 528, reconstruction stage 522, and decode picture buffer (DPB) stages 512 and 526 are performed in the original (i.e., non-transform) domain. In some embodiments, loop filter stage 510 may include deblocking, adaptive loop filtering (ALF), and sample adaptive offset (SAO), reconstruction stage 522 may include chrominance prediction and addition along with chrominance residual, and DPBs 512 and 526 may store decoded pictures as reference pictures. In some embodiments, a luminance mapping with a piecewise linear model may be applied. In-loop mapping of the luminance component may adjust the signal statistics of the input video by redistributing codewords within the dynamic range to improve compression efficiency. Luminance mapping may be performed through a forward mapping function "FwdMap" and a corresponding inverse mapping function "InvMap". The "FwdMap" function is signaled by using a piecewise linear model with 16 equal pieces. The "InvMap" function does not need to be signaled but is derived from the "FwdMap" function. In FIG Table 1 of FIG Table 2 of FIG Table 1 of FIG 6 depicts the header syntax structure of a slice group. As shown in FIG For the syntax elements shown in Table 2 of 7, the corresponding piecewise linear model parameters can be signaled in tile_group_reshaper_model(). The piecewise linear model divides an input signal of a dynamic range into 16 equal blocks. For each of the 16 equal blocks, the linear mapping parameters of the block are expressed using the number of codewords assigned to the block. A 10-bit input is taken as an example. Each of the 16 blocks can have 64 codewords pre-assigned to the block. The signaled number of codewords can be used to calculate a scaling factor and accordingly adjust the mapping function for the block. Figure Table 2 of 7 also defines the minimum index "reshaper_model_min_bin_idx" and the maximum index "reshaper_model_max_bin_idx" (including the upper and lower bounds) for which the number of codewords can be signaled. If the piece index is less than reshaper_model_min_bin_idx or greater than reshaper_model_max_bin_idx, then the number of codewords for that block is not signaled and is inferred to be zero (i.e., no codewords are assigned and no mapping / scaling is applied to the block). After signaling tile_group_reshaper_model(), at the header level of the tile group, another reshaper enable flag "tile_group_reshaper_enable_flag" is signaled to indicate whether the LMCS processing depicted in Figure 8 is applied to the current tile group. If the reshaper is enabled for the current tile group and if the current tile group does not use dual tree partitioning, then a further chroma scaling enable flag is signaled to indicate whether chroma scaling is enabled for the current tile group or not. Dual tree partition can also be referred to as chroma separation tree. The piecewise linear model can be constructed according to Figure the syntax elements signaled in Table 2 of 7 as follows. For the i-th block, i = 0, 1,..., 15 of the "FwdMap" piecewise linear model, it is defined by two input pivot points InputPivot[] and two output (mapped) pivot points MappedPivot[]. Based on the following signaling syntax, InputPivot[] and MappedPivot[] are calculated (without loss of generality, we assume the bit depth of the input video is 10 bits): The inverse mapping function "InvMap" can also be defined by InputPivot[] and MappedPivot[]. Different from "FwdMap", for the piecewise linear model of "InvMap", two input pivot points of each piece can be defined by MappedPivot[], and two output pivot points can be defined by InputPivot[], which is the opposite of FwdMap. In this way, the input of "FwdMap" is divided into equal pieces, but the input of "InvMap" is not guaranteed to be divided into equal pieces. As shown in Figure 5, for the inter-block coding block, motion compensation prediction can be performed in the mapping domain. In other words, after motion compensation prediction 516, which is calculated based on the reference signals in the DPB, the "FwdMap" function 518 can be applied to map the luminance prediction block in the original domain to the mapping domain, . For the intra-block coding block, the "FwdMap" function is not applied because the reference samples used in the intra prediction are already in the mapping domain. After reconstructing the block 506, . The "InvMap" function 508 can be applied to transform the reconstructed luminance value in the mapping domain back to the reconstructed luminance value in the original domain . The "InvMap" function 508 can be applied to both intra- and inter-coded luminance blocks. The luminance mapping process (forward or inverse mapping) can be implemented by using a look-up table (LUT) or using real-life calculations. If using an LUT, the tables "FwdMapLUT[]" and "InvMapLUT[]" can be pre-calculated and pre-stored for use at the slice group level, and the forward and inverse mappings can be easily implemented as and . Alternatively, real-life calculations can be used. Taking the forward mapping function "FwdMap" as an example. To determine which piece a luminance sample belongs to, the sample value can be right-shifted by 6 bits (which corresponds to 16 equal pieces, assuming a 10-bit video) to obtain the piece index. Then, the linear model parameters for that piece are retrieved and used in real-life calculations to calculate the mapped luminance value. The FwdMap function can be evaluated as follows: where "i" is the piece index, a1 is InputPivot[i], a2 is InputPivot [i+1], b1 is MappedPivot[i], and b2 is MappedPivot[i+1]. The "InvMap" function can perform real - life calculations in a similar way, except that when determining the block to which a sample value belongs, a conditional check needs to be imposed instead of a simple right shift, because these blocks in the mapping domain are not guaranteed to be of the same size. In some embodiments, luminance - dependent chroma - residual scaling can be performed. Chroma - residual scaling is designed to compensate for the interaction between the luminance signal and its corresponding chrominance signal. Whether chroma - residual scaling is enabled or not, it is also signaled at the tile - group level. As shown in Table 1 of FIG. 6, if luminance mapping is enabled and if dual - tree segmentation is not applied to the current tile group, an additional flag (e.g., tile_group_reshaper_chroma_residual_scale_flag) is signaled to indicate whether luminance - dependent chroma - residual scaling is enabled. When luminance mapping is not used or when dual - tree segmentation is used in the current tile group, luminance - dependent chroma - residual scaling is automatically disabled. In addition, luminance - dependent chroma - residual scaling can be disabled for chroma blocks whose area is less than or equal to 4. Chroma - residual scaling depends on the average value of the corresponding luminance prediction block (for in - block and inter - block coded blocks). , which is the average value of the luminance prediction block, can be calculated as follows: Calculated from the following steps the value of: 1) Based on the InvMap function finds the index of the piece - wise linear model where belongs to this piece - wise linear model. 2) = cScaleInv ], where cScaleInv[] is a pre - calculated 16 - block LUT. In the current LMCS method in VTM4, based on 64 static LUT ChromaResidualScaleLut and SignaledCW[i] values, the pre - calculated LUT cScaleInv[i] with i ranging from 0 to 15 is obtained: The static table ChromaResidualScaleLut[] contains 64 entries, and SignaledCW[] is in the range of [0, 128] (assuming the input is 10 - bit). Therefore, dividing by 2 (e.g., right - shifting by 1) is used to construct the chroma - scaling factor LUT cScaleInv[]. The chroma - scaling factor LUT cScaleInv[] can contain multiple chroma - scaling factors. The LUT cScaleInv[] is constructed at the tile - group level. If the current block is encoded using in-frame, CIIP, or in-block copy (IBC, also known as current picture reference or CPR) mode, then is calculated as the average of the in-frame, CIIP, or IBC predicted luma values. Additionally, is calculated as the average of the forward mapped inter-predicted luma values (i.e., Figure 5's ). Different from the luma mapping performed based on samples, is a constant value for the entire chroma block. By using the chroma residual scaling is applied at the decoder side as follows: where, is the reconstructed chroma residual of the current block. At the encoder side, the forward chroma residual scaling is performed as follows (before transform and quantization): In some embodiments, the dual-tree splitting can be performed. In VVC draft 4, the coding tree scheme supports the ability to have separate block tree splitting for luma and chroma. This is also known as dual-tree splitting. At Figure 8's Table 3 and Figure 9's Table 4 show the dual-tree splitting signaling. When the "qtbtt_dual_tree_intra_flag" (which is a sequence-level control flag signaled in the SPS) is enabled and when the current slice group is in-frame encoded, the block splitting information for luma can be signaled first, and then (separately) the block splitting information for chroma can be signaled. For inter-encoded slice groups (P and B slice groups), dual-tree splitting is not allowed. When the separate block tree mode is applied, the luma coding tree block (CTB) is split into CUs by one coding tree structure, and the chroma CTB is split into chroma CUs by another coding tree structure, as shown in the following Figure 9's Table 4. When the luminance and chrominance are allowed to have different types of partitioning, problems of dependencies between different color components may occur in coding tools. For example, in the case of LMCS, the average value of the corresponding luminance block is used to determine the scaling factor to be applied to the current block. When using dual-tree, this may cause latency for the entire CTU. For example, if the luminance block of a CTU is vertically partitioned once and the chrominance block of the CTU is horizontally partitioned once, then two luminance blocks of the CTU are decoded (to calculate the average value, which is necessary for the calculation of the chrominance scaling factor) before the first chrominance block of the CTU is decoded. In VVC, a CTU can be as large as 128×128 luminance sample units. Such a large latency poses a great problem for the hardware decoder pipeline design. Therefore, VVC draft 4 can prohibit the combination of dual-tree partitioning and luminance-dependent chrominance scaling. When dual-tree partitioning is enabled for the current picture group, chrominance scaling is forced to be off. It should be noted that the luminance mapping part of LMCS in the case of dual-tree is still allowed because it only operates on the luminance component and there is no problem of cross-color component dependencies. Another example of a coding tool relies on the dependencies between color components to achieve better coding efficiency, which is called the cross-component linear model (CCLM). Therefore, the derivation of the picture group level chrominance scaling factor LUT cScaleInv[] is not easily scalable. The derivation process currently depends on a fixed chrominance LUT ChromaResidualScaleLut with 64 entries. For 10-bit video with 16 blocks, an additional step of dividing by 2 must be applied. When the number of blocks changes, for example, using 8 blocks instead of 16 blocks, the derivation process must be changed to apply a division by 4 instead of a division by 2. This additional step not only causes a loss of accuracy but is also awkward and unnecessary. In addition, in order to calculate the block index of the current chrominance block which is used to obtain the chrominance scaling factor, the average value of the entire luminance block can be used. This is also undesirable and most likely unnecessary. Considering the maximum CTU size of 128×128. In this case, the average luminance value is calculated based on 16384 (128×128) luminance samples (this process is cumbersome). In addition, if the encoder selects a 128×128 luminance block partitioning, the block is more likely to contain homogeneous content. Therefore, a subset of the luminance samples in the block may be sufficient to calculate the luminance average. In dual-tree partitioning, chrominance scaling can be turned off to avoid potential pipeline problems in the hardware decoder. However, if explicit signaling is used to indicate the chrominance scaling factor to be applied instead of using the corresponding luminance samples to derive it, this dependency can be avoided. Enabling chrominance scaling in the intra-coded picture group can further improve the coding efficiency. The signaling of piecewise linear parameters can be further improved. Currently, for each of the 16 pieces, the signaling delta codeword values are sent. It can be observed that for the 16 pieces, usually only a limited number of different codewords are used. Therefore, the signaling burden can be further reduced. Embodiments of the present disclosure provide a method for processing video content by removing the chroma scaling LUT. As mentioned above, when using other piecewise linear models (e.g., 8 pieces, 4 pieces, and 64 pieces, etc.), the expansion of the 64-entry chroma LUT can be difficult and problematic. Since in order to achieve the same coding efficiency, the chroma scaling factor may be set to the same as the luma scaling factor of the corresponding block, so this is also unnecessary. In some embodiments of the present disclosure, as described below, the chroma scaling factor "chroma_scaling" can be determined based on the block index of the current chroma block ( ). When chroma_scaling = 1.0, no scaling is applied. The chroma scaling factor determined above may have fractional precision. It should be understood that fixed-point approximation can be applied to avoid dependence on the hardware / software platform. Furthermore, on the decoder side, inverse chroma scaling can be performed. Therefore, division can be implemented by using fixed-point arithmetic of right shift after multiplication. The inverse chroma scaling factor "inverse_chroma_scaling[]" in the fixed-point precision can be determined based on the number of bits of the following fixed-point approximation "CSCALE_FP_PREC". Where luma_bit_depth is the luma bit depth, and TOTAL_NUMBER_PIECES is the total number of blocks in the piecewise linear model, which is set to 16 in VVC draft 4. It should be understood that the value of "inverse_chroma_scaling[]" may only need to be calculated once for each slice group, and the above division is an integer division operation. Further quantization can be applied to determine the chroma scaling and inverse scaling factors. For example, the inverse chroma scaling factor can be calculated for all even (2×m) values of "SignaledCW", and the chroma scaling factor of the adjacent even value can be used for all odd (2×m + 1) values of "SignaledCW". In other words, the following can be used: The quantization of the chroma scaling factor can be further generalized. For example, the inverse chroma scaling factor "inverse_chroma_scaling[]" can be calculated for every n-th value of "SignaledCW", and all other adjacent values share the same chroma scaling factor. For example, "n" can be set to 4. Thus, every four adjacent codeword values can share the same inverse chroma scaling factor value. In some embodiments, the value of "n" can be a power of 2, which allows the use of shifts to calculate the division. Representing the value of log2(n) as LOG2_n, the above equation "tempCW = SignaledCW[ ] >> 1) << 1" can be adjusted to: In some embodiments, the value of LOG2_n can be a function of the number of blocks used in the piecewise linear model. If fewer blocks are used, it is more beneficial to use a larger LOG2_n. For example, if the value of TOTAL_NUMBER_PIECES is less than or equal to 16, then LOG2_n can be set to 1 + (4 - log2(TOTAL_NUMBER_PIECES)). If TOTAL_NUMBER_PIECES is greater than 16, then LOG2_n can be set to 0. Embodiments of the present disclosure provide a method for processing video content by simplifying the averaging step of the luminance prediction block. As described above, in order to determine the block index " " of the current chroma block, the average value of the corresponding luminance block can be used. However, for large block sizes, the averaging process may involve a large number of luminance samples. In the worst case, the averaging process may involve 128×128 luminance samples. Embodiments of the present disclosure provide a simplified averaging process to reduce the worst case to only using N×N luminance samples (N is a power of 2). In some embodiments, if neither of the two dimensions of the two-dimensional luminance block is less than or equal to a preset threshold M (in other words, at least one of the two dimensions is greater than M), then "downsampling" is applied to only use M positions in that dimension. Without loss of generality, the horizontal dimension is taken as an example. If the width is greater than M, then only the samples at position x are used for averaging, where x = i×(width >> log2(M)), i = 0,..., M - 1. Figure 10 depicts an example of applying a proposed simplification to calculate the average of 16×8 luminance blocks. In this example, M is set to 4, and only 16 luminance samples (the shaded samples) in the block are used for averaging. It should be understood that the default threshold value M is not limited to 4, and M can be set to any value that is a power of 2. For example, the default threshold value M can be 1, 2, 4, 8, and so on. In some embodiments, the horizontal dimension and the vertical dimension of the luminance block may have different default threshold values M. In other words, the worst case of the averaging operation is to use M1×M2 samples. In some embodiments, the number of samples may be limited in the averaging process regardless of the dimension. For example, the maximum of 16 samples can be used, which can be distributed in the form of 1×16, 16×1, 2×8, 8×2, or 4×4 in the horizontal or vertical dimension, and any form that adapts to the current block shape can be selected. For example, if the block is long and tall, a matrix of 2×8 samples can be used; if the block is wide and short, a matrix of 8×2 samples can be used; and if the block is square, a matrix of 4×4 samples can be used. It should be understood that when a large block size is selected, the content within the block tends to be more homogeneous. Therefore, although the above simplification may cause a difference between the average value and the true average value of the entire luminance block, this difference can be small. In addition, before applying motion compensation, motion vector refinement (DMVR) on the decoder side requires the decoder to perform a motion search to derive the motion vector. Therefore, the DMVR mode in the VVC standard can be relatively complex, especially for the decoder. The bidirectional optical flow (BDOF) mode in the VVC standard can further complicate the situation because BDOF is an additional sequential process that needs to be applied after DMVR in order to obtain the luminance prediction block. Since chroma scaling requires the average value of the corresponding luminance prediction block, DMVR and BDOF can be applied before calculating the average value. To solve the latency problem, in some embodiments of the present disclosure, a luminance prediction block is used to calculate the average luminance value before DMVR and BDOF, and the average luminance value is used to obtain the chroma scaling factor. This allows chroma scaling to be applied to the DMVR and BDOF processes in parallel, and thus significantly reduces the latency. Consistent with the present disclosure, variations in latency reduction can be considered. In some embodiments, this latency reduction can also be combined with the aforementioned simplified averaging process of using only a portion of the luminance prediction blocks to calculate the average luminance value. In some embodiments, the luminance prediction blocks can be used to calculate the average luminance value after DMVR processing and before BDOF processing. Then, the average luminance value is used to obtain the chrominance scaling factor. This design allows chrominance scaling to be applied in parallel with BDOF processing while maintaining the accuracy of determining the chrominance scaling factor. Since the DMVR processing can refine the motion vectors, using the predicted samples with refined motion vectors after DMVR processing is more accurate than using the predicted samples with motion vectors before DMVR processing. In addition, in the VVC standard, the CU syntax structure "coding_unit()" includes the syntax element "cu_cbf" which is used to indicate whether there are any non-zero residual coefficients in the current CU. At the TU level, the TU syntax structure "transform_unit()" includes the syntax elements "tu_cbf_cb" and "tu_cbf_cr" which are used to indicate whether there are any non-zero chrominance (Cb or Cr) residual coefficients in the current TU. In the prior art, in VVC draft 4, if chrominance scaling is enabled at the slice group level, the averaging process for the corresponding luminance block is always called. Embodiments of the present disclosure further provide a method for processing video content by bypassing the luminance averaging process. Consistent with the disclosed embodiments, since the chrominance scaling process is applied to the residual chrominance coefficients, the luminance averaging process can be bypassed if there are no non-zero chrominance coefficients. This can be determined based on the following conditions: Condition 1: cu_cbf is equal to 0 Condition 2: both tu_cbf_cr and tu_cbf_cb are equal to 0 As described above, "cu_cbf" can indicate whether there are any non-zero residual coefficients in the current CU, and "tu_cbf_cb" and "tu_cbf_cr" can indicate whether there are any non-zero chrominance (Cb or Cr) residual coefficients in the current TU. When either Condition 1 or Condition 2 is met, the luminance averaging process can be bypassed. In some embodiments, only the N×N samples of the prediction block are used to derive the average value, which simplifies the averaging process. For example, when N is equal to 1, only the top-left sample of the prediction block is used. However, this simplified averaging process using the prediction block still requires generating the prediction block, thereby causing latency. In some embodiments, the reference luminance samples can be directly used to generate the chrominance scaling factor. This allows the decoder to derive the scaling factor in parallel with the luminance prediction process, thereby reducing latency. Intra prediction and inter prediction using the reference luminance samples will be described individually below. In illustrative intra prediction, decoded neighboring samples in the same picture can be used as reference samples to generate a prediction block. Such reference samples can include, for example, samples at the top of the current block, samples to the left of the current block, or samples at the upper left corner of the current block. The average value of such reference samples can be used to derive a chroma scaling factor. In some embodiments, the average value of a portion of such reference samples can be used. For example, only the K reference samples closest to the upper left corner of the current block (e.g., K = 3) are averaged. In illustrative inter prediction, reference samples from a temporal reference picture can be used to generate a prediction block. Such reference samples are identified by a reference picture index and a motion vector. If the motion vector has fractional precision, interpolation can be applied. The reference samples used to determine the average value of the reference samples can include the reference samples before and after interpolation. The reference samples before interpolation can include the motion vector truncated to integer precision. Consistent with embodiments of this disclosure, all such reference samples can be used to calculate the average value. Alternatively, only a portion of the reference samples (e.g., the reference sample corresponding to the upper left corner position of the current block) can be used to calculate the average value. As shown in FIG. 5, intra prediction (e.g., intra prediction 514 or 528) can be performed in the reshaped domain, while inter prediction is performed in the original domain. Thus, for inter prediction, a forward mapping can be applied to the prediction block, and the luminance prediction block after the forward mapping is used to calculate the average value. To reduce latency, the average value is calculated using the prediction block before the forward mapping. For example, the block before the forward mapping, the N×N portion of the block after the forward mapping, or the upper left sample of the block after the forward mapping can be used. Embodiments of this disclosure further provide a method for processing video content using chroma scaling for dual-tree segmentation. Because the dependence on luminance may cause hardware design complexity, chroma scaling can be turned off for the slice group enabling intra coding for dual-tree segmentation. However, this limitation may cause a loss of coding efficiency. Instead of taking the average value of the sample values of the corresponding luminance block to calculate , determining the block index and obtaining the chroma scaling factor inverse_chroma_scaling ], the chroma scaling factor can be explicitly signaled in the bitstream to avoid the dependence on luminance in the case of dual-tree segmentation. The chroma scaling index can be signaled at different levels. For example, the chroma scaling index can be signaled at the coding unit (CU) level, along with signaling the chroma prediction mode, as shown in FIG. As shown in Table 5. The syntax element "lmcs_scaling_factor_idx" can be used to determine the chroma scaling factor for the current chroma block. When "lmcs_scaling_factor_idx" does not exist, the chroma scaling factor for the current chroma block can be deduced to be equal to 1.0 (in floating-point precision) or deduced to be equal (1 << CSCALE_FP_PREC) in fixed-point precision. The range of allowed values of "lmcs_chroma_scaling_idx" is determined at the slice group level and will thus be discussed later. Depending on the possible values of "lmcs_chroma_scaling_idx", the signaling cost may be high, especially for small blocks. Therefore, in some embodiments of the present disclosure, Figure The signaling conditions in Table 5 of Figure 11 may additionally include block size conditions. For example, this syntax element "lmcs_chroma_scaling_idx" (emphasized in italics and shaded) may be signaled only when the current block includes more than a given number of chroma samples or when the current block has a width greater than a given width W or a height greater than a given height H. For smaller blocks, if "lmcs_chroma_scaling_idx" is not signaled, its chroma scaling factor may be determined on the decoder side. In some embodiments, the chroma scaling factor may be set to 1.0 (in floating-point precision). In some embodiments, a default "lmcs_chroma_scaling_idx" value may be added at the slice group header level (see Table 1 in Figure 6). Blocks without signaling "lmcs_chroma_scaling_idx" may use this slice group level default index to derive the corresponding chroma scaling factor. In some embodiments, the chroma scaling factor of a block may be inherited from its neighbor (e.g., the upper or left neighbor) that has an explicitly signaled scaling factor. Figure 6). In addition to signaling this syntax element "lmcs_chroma_scaling_idx" at the CU level, it can also be signaled at the CTU level. However, since the maximum CTU size in VVC is 128×128, performing the same scaling at the CTU level may be too coarse. Therefore, in some embodiments of the present disclosure, this syntax element "lmcs_chroma_scaling_idx" can be signaled using a fixed granularity. For example, for each 16×16 region in the CTU, one "lmcs_chroma_scaling_idx" is signaled and applied to all samples in that 16×16 region. The range of "lmcs_chroma_scaling_idx" for the current slice group depends on the number of chroma scaling factor values allowed in the current slice group. The number of chroma scaling factor values allowed in the current slice group can be determined based on the aforementioned 64-entry chroma LUT. Alternatively, the number of chroma scaling factor values allowed in the current slice group can be determined using the aforementioned chroma scaling factor calculation. For example, in the "quantization" method, the value of LOG2_n can be set to 2 (i.e., "n" is set to 4), and the codeword assignment for each block in the piecewise linear model of the current slice group can be set to the following: {0, 65, 66, 64, 67, 62, 62, 64, 64, 64, 67, 64, 64, 62, 61, 0}. Then there are only 2 possible scaling factor values for the entire slice group because any codeword value from 64 to 67 can have the same scaling factor value (1.0 in fractional precision), and any codeword value from 60 to 63 can have the same scaling factor value (60 / 64 = 0.9375 in fractional precision). For the two end pieces that are not assigned any codewords, the chroma scaling factor is preset to 1.0. Thus, in this example, one bit is sufficient to signal "lmcs_chroma_scaling_idx" for the blocks in the current slice group. In addition to determining the number of possible chroma scaling factor values using the piecewise linear model, the encoder can signal a set of chroma scaling factor values in the slice group header. Then at the block level, the chroma scaling factor value for the block can be determined by using the set of chroma scaling factor values and the "lmcs_chroma_scaling_idx" value for the block. CABAC coding can be applied to the code "lmcs_chroma_scaling_idx". The CABAC context of a block can depend on the "lmcs_chroma_scaling_idx" of the neighboring blocks of the block. For example, the left block or the upper block can be used to form the CABAC context. In terms of the binarization of this syntax element of "lmcs_chroma_scaling_idx", the same truncated Rice binarization applied to the ref_idx_l0 and ref_idx_l1 syntax elements in VVC draft 4 can be used to binarize "lmcs_chroma_scaling_idx". The advantage of signaling "chroma_scaling_idx" is that the encoder can select the optimal "lmcs_chroma_scaling_idx" based on the rate-distortion cost. Using rate-distortion optimization to select "lmcs_chroma_scaling_idx" can improve the encoding efficiency, which can help offset the increase in signaling cost. Embodiments of the present disclosure further provide a method for processing video content with signaling of an LMCS piecewise linear model. Although the LMCS method uses a piecewise linear model with 16 segments, the number of unique values of "SignaledCW[i]" in a group tends to be much less than 16. For example, some of the 16 segments may use a default number of codewords "OrgCW", and some of the 16 segments may have the same number of codewords as each other. Therefore, an alternative to signaling the LMCS piecewise linear model may include signaling a number of unique codewords "listUniqueCW[]" and transmitting an index for each segment to indicate an element of "listUniqueCW[]" for the current segment. The adjusted syntax table is provided in Figure Table 6 of Figure In Table 6 of Figure 12, the new or adjusted syntax is emphasized with slashes and upper shading. The semantics of the disclosed signaling method are as follows, with changes underlined: reshaper_model_min_bin_idx specifies the minimum bin (or segment) index to be used in the reshaper construction process. The value of reshaper_model_min_bin_idx should be in the range of 0 to MaxBinIdx, including the upper and lower bounds. The value of MaxBinIdx should be equal to 15. reshaper_model_delta_max_bin_idx specifies the maximum allowed bin (or segment) index MaxBinIdx minus the maximum allowed bin index to be used in the reshaper construction process. The value of reshaper_model_max_bin_idx is set to be equal to MaxBinIdx - reshaper_model_delta_max_bin_idx. reshaper_model_bin_delta_abs_cw_prec_minus1 plus 1 specifies the number of bits used to represent the syntax reshaper_model_bin_delta_abs_CW[ i ]. The reshaper_model_bin_num_unique_cw_minus1 plus 1 specifies the size of the coded word array listUniqueCW. reshaper_model_bin_delta_abs_CW[i] specifies the absolute delta coded word value for the i-th bin. reshaper_model_bin_delta_sign_CW_flag[i] specifies the sign of reshape_model_bin_delta_abs_CW[i] as follows: - If reshape_model_bin_delta_sign_CW_flag[i] is equal to 0, then the corresponding variable RspDeltaCW[i] is a positive value. - Otherwise, when reshape_model_bin_delta_sign_CW_flag[i] is not equal to 0, then the corresponding variable RspDeltaCW[i] is a negative value. When reshape_model_bin_delta_sign_CW_flag[i] does not exist, it is inferred to be equal to 0. The variable RspDeltaCW[i] is derived as RspDeltaCW[i]=(1 - 2*reshape_model_bin_delta_sign_CW[i])*reshape_model_bin_delta_abs_CW[i]. The variable listUniqueCW[0] is set to be equal to OrgCW. The variable listUniqueCW[i] with i = 1…reshaper_model_bin_num_unique_cw_minus1, including the upper and lower bounds, is derived as follows: - The variable OrgCW is set to be equal to (1 << BitDepth Y ) / (MaxBinIdx + 1). - listUniqueCW[i]=OrgCW+RspDeltaCW[i - 1] reshaper_model_bin_cw_idx[i] specifies the index of the array listUniqueCW[] used to derive RspCW[i]. The value of reshaper_model_bin_cw_idx[i] should be in the range of 0 to (reshaper_model_bin_num_unique_cw_minus1 + 1), inclusive of the upper and lower bounds. RspCW[i] is derived as follows: - If reshaper_model_min_bin_idx <= i <= reshaper_model_max_bin_idx, then RspCW[i] = listUniqueCW[reshaper_model_bin_cw_idx[i]]. - Otherwise, RspCW[i] = 0. If the value of BitDepth Y is equal to 10, then the value of RspCW[i] can be in the range of 32 to 2*OrgCW - 1. Embodiments of the present disclosure further provide a method for processing video content using conditional chroma scaling at the block level. As shown in Table 1 of FIG. 6, it can be determined whether to apply chroma scaling through the "tile_group_reshaper_chroma_residual_scale_flag" signaled at the tile group level. However, it can be advantageous to determine whether to apply chroma scaling at the block level. For example, in some disclosed embodiments, a CU-level flag can be signaled to indicate whether chroma scaling is applied to the current block. The presence of the CU-level flag can depend on the tile group level flag "tile_group_reshaper_chroma_residual_scale_flag". That is, the CU-level flag can only be signaled when chroma scaling is allowed at the tile group level. Although the encoder is allowed to choose whether to use chroma scaling based on whether it is beneficial for the current block, it may also cause a significant signaling burden. Consistent with the embodiments of the present disclosure, to avoid the above-mentioned signaling burden, whether to apply chroma scaling to a block depends on the prediction mode of the block. For example, when the block is inter-predicted, the prediction signal tends to be good, especially when the reference picture is close in temporal distance. Therefore, since the residual is expected to be extremely small, chroma scaling can be bypassed. For example, in higher temporal levels, the pictures usually have reference pictures with close temporal distances. And for blocks in pictures using adjacent reference pictures, chroma scaling can be disabled. The picture order count (POC) difference between the current picture and the reference picture of the block can be used to determine whether this condition is met. In some embodiments, chroma scaling can be disabled for all inter-coded blocks. In some embodiments, chroma scaling can be disabled for the combined intra / inter prediction (CIIP) (which is defined in the VVC standard) mode. In the VVC standard, the CU syntax structure "coding_unit()" includes the syntax element "cu_cbf", which is used to indicate whether there are any non-zero residual coefficients in the current CU. At the TU level, the TU syntax structure "transform_unit()" includes the syntax elements "tu_cbf_cb" and "tu_cbf_cr", which are used to indicate whether there are any non-zero chroma (Cb or Cr) residual coefficients in the current TU. The chroma scaling process can depend on these flags. As described above, if there are no non-zero residual coefficients, the averaging corresponding to the luminance and chroma scaling process can be called. By calling this averaging, the chroma scaling process can be bypassed. Figure 13 depicts a flowchart of a computer-implemented method 1300 for processing video content. In some embodiments, the method 1300 can be executed by an encoder (e.g., Figure the encoder in FIGS. 2A-2B or Figure the decoder in FIGS. 3A-3B). For example, the encoder can be implemented as one or more software or hardware components of a device (such as device 400) for encoding or transform-encoding a video sequence. In some embodiments, the video sequence can be an uncompressed video sequence (e.g., video sequence 202) or a decoded compressed video sequence (e.g., video stream 304). In some embodiments, the video sequence can be from a monitoring device (e.g., Figure The monitoring video sequence captured by the video input device in 4). The video sequence may include multiple screens. The device may execute method 1300 at the screen level. For example, in method 1300, the device may process one screen at a time. For another example, in method 1300, the device may process a plurality of screens at a time. Method 1300 may include the following steps. In step 1302, a chrominance block and a luminance block associated with the screen may be received. It should be understood that the screen may be associated with a chrominance component and a luminance component. Therefore, the screen may be related to a chrominance block containing chrominance samples and a luminance block containing luminance samples. In step 1304, luminance scaling information associated with the luminance block may be determined. In some embodiments, the luminance scaling information may be a syntax element signaled in the data stream of the screen or a variable derived based on the syntax element signaled in the data stream of the screen. For example, the luminance scaling information may include "reshape_model_bin_delta_sign_CW[i] and reshape_model_bin_delta_abs_CW[i]" described in the above equation and / or "SignaledCW[i]" described in the above equation, etc. In some embodiments, the luminance scaling information may include a variable determined based on the luminance block. For example, the average luminance value may be determined by calculating the average of the luminance samples adjacent to the luminance block (such as the luminance samples in a row at the top of the luminance block or the luminance samples in a column on the left side of the luminance block). In step 1306, a chrominance scaling factor may be determined based on the luminance scaling information. In some embodiments, the luminance scaling factor of the luminance block may be determined based on the luminance scaling information. For example, according to the above equation "inverse_chroma_scaling[ ]=((1<<(luma_bit_depth - log2(TOTAL_NUMBER_PIECES)+CSCALE_FP_PREC))+(tempCW>>1)) / tempCW", the luminance scaling factor may be determined based on the luminance scaling information (e.g., "tempCW"). Then, the chrominance scaling factor may be further determined based on the value of the luminance scaling factor. For example, the chrominance scaling factor may be set equal to the value of the luminance scaling factor. It should be understood that further calculations may be applied to the value of the luminance scaling factor before it is set as the chrominance scaling factor. As another example, the chrominance scaling factor may be set equal to "SignaledCW[ ] / OrgCW", where the block index of the current chrominance block " " may be determined based on the average luminance value associated with the luminance block. In step 1308, a chrominance block may be processed using a chrominance scaling factor. For example, the residual of the chrominance block may be processed using the chrominance scaling factor to generate a scaled residual of the chrominance block. The chrominance block may be a Cb chrominance component or a Cr chrominance component. In some embodiments, the chrominance block may be processed if a condition is met. For example, the condition may include a target coding unit associated with a picture having no non-zero residual; or include a target transform unit associated with a picture having no non-zero chrominance residual. It may be determined that there is no target coding unit with a non-zero residual based on the value of the first coding block flag of the target coding unit. And it may be determined that there is no target transform unit with a non-zero chrominance residual based on the value of the second coding block flag for the first component of the target transform unit and the value of the third coding block flag for the second component of the target transform unit. For example, the first component may be the Cb component, and the second component may be the Cr component. It should be understood that each step in method 1300 may be executed as an independent method. For example, the method for determining the chrominance scaling factor described in step 1308 may be executed as an independent method. Figure 14 depicts a flowchart of a computer-implemented method 1400 for processing video content. In some embodiments, it may be executed by an encoder / decoder (e.g., Figure the encoder in FIGS. 2A-2B or Figure the decoder in FIGS. 3A-3B). For example, the encoder / decoder may be implemented as one or more software or hardware components of a device (such as device 400) for encoding or transform-coding a video sequence. In some embodiments, the video sequence may be an uncompressed video sequence (e.g., video sequence 202) or a decoded compressed video sequence (e.g., video stream 304). In some embodiments, the video sequence may be a surveillance video sequence captured by a surveillance device (e.g., Figure the video input device in FIG. 4) associated with a device processor (e.g., processor 402). The video sequence may include multiple pictures. The device may execute method 1400 at the picture level. For example, in method 1400, the device may process one picture at a time. For another example, in method 1400, the device may process a plurality of pictures at a time. Method 1400 may include the following steps. In step 1402, a chrominance block and a luminance block associated with a picture may be received. It should be understood that a picture may be associated with a chrominance component and a luminance component. Thus, the picture may be related to a chrominance block including chrominance samples and to a luminance block including luminance samples. In some embodiments, the luminance block may include N×M luminance samples. N may be the width of the luminance block and M may be the height of the luminance block. As described above, the luminance samples of the luminance block may be used to determine the block index of a target chrominance block. Thus, a luminance block associated with a picture of a video sequence may be received. It should be understood that N and M may have the same value. In step 1404, in response to at least one of N and M being greater than a threshold value, a subset of the N×M luminance samples may be selected. To accelerate the determination of the block index, the luminance block may be "downsampled" when a specific condition is met. In other words, a subset of the luminance samples in the luminance block may be used to determine the block index. In some embodiments, the specific condition is that at least one of N and M is greater than a threshold value. In some embodiments, the threshold value may be based on at least one of N and M. The threshold value may be a power of 2. For example, the threshold value may be 4, 8, 16, etc. Taking 4 as an example, when N or M is greater than 4, a subset of the luminance samples may be selected. In FIG 10 example, both the width and height of the luminance block are greater than the threshold value of 4, and thus a subset of 4×4 samples is selected. It should be understood that subsets such as 2×8, 1×16, or equivalents may also be selected for processing. In step 1406, the average value of a subset of the N×M luminance samples may be determined. In some embodiments, determining the average value may further include determining whether a second condition is met; and in response to the determination that the second condition has been met, determining the average value of a subset of the N×M luminance samples. For example, the second condition may include a target coding unit associated with a picture having no non-zero residual coefficients; or include a target coding unit having no non-zero chrominance residual coefficients. In step 1408, a chrominance scaling factor based on the average value can be determined. In some embodiments, to determine the chrominance scaling factor, a block index of a chrominance block can be determined based on the average value, it can be determined whether the block index of the chrominance block satisfies a first condition, and then in response to the determination that the block index of the chrominance block satisfies the first condition, the chrominance scaling factor can be set to a preset value. The preset value can indicate that no chrominance scaling is applied. For example, the preset value can be 1.0 with fractional precision. It should be understood that a fixed-point approximation can be applied to the preset value. In response to the determination that the block index of the chrominance block does not satisfy the first condition, the chrominance scaling factor can be determined based on the average value. More specifically, the chrominance scaling factor can be set to "SignaledCW[ ] / OrgCW", and the block index of the target chrominance block " " can be determined based on the average value associated with the corresponding luma block. In some embodiments, the first condition can include a block index of a chrominance block that is greater than the maximum index of the signaling codeword or less than the minimum index of the signaling codeword. The maximum index and the minimum index of the signaling codeword can be determined as follows. Codewords can be generated based on an input signal (e.g., luma samples) by using a piecewise linear model (e.g., LMCS). As described above, an input signal in a dynamic range can be divided into several blocks (e.g., 16 blocks) and each block of the input signal can be used to generate a bin of a codeword as an output. Thus, each bin of the codeword can have a bin index corresponding to the block of the input signal. In this example, the range of the bin index can be 0 - 15. In some embodiments, the value of the output (i.e., the codeword) is between a minimum value (e.g., 0) and a maximum value (e.g., 255), and a plurality of codewords having values between the minimum value and the maximum value can be signaled. And the bin indices of the plurality of signaled codewords can be determined. Among the bin indices of the plurality of signaled codewords, the maximum bin index and the minimum bin index of the bins of the plurality of signaled codewords can be further determined. In addition to the chrominance scaling factor, method 1400 can further determine a luma scaling factor based on the bins of the plurality of signaled codewords. The luma scaling factor can be used as an inverse chrominance scaling factor. The equations for determining the luma scaling factor have been described above and the repeated description thereof will be omitted herein. In some embodiments, a plurality of quantities of adjacent signaled codewords share the luma scaling factor. For example, two or four adjacent signaled codewords can share the same luma scaling factor, which can reduce the burden of determining the luma scaling factor. In step 1410, the chrominance block can be processed using the chrominance scaling factor. As previously referred to in Figure As described in 5, a plurality of chroma scaling factors can construct a chroma scaling factor LUT at the slice group level and can be applied to the reconstructed chroma residual of the target block on the decoder side. Similarly, chroma scaling factors can also be applied on the encoder side. It should be understood that each step in method 1400 can be executed as an independent method. For example, the method for determining chroma scaling factors described in step 1308 can be executed as an independent method. Figure 15 depicts a flowchart of a computer-implemented method 1500 for processing video content. In some embodiments, it can be executed by an encoder / decoder (e.g., Figure the encoder in FIGS. 2A-2B or Figure the decoder in FIGS. 3A-3B). For example, the encoder / decoder can be implemented as one or more software or hardware components of a device (such as device 400) for encoding or transform-encoding a video sequence. In some embodiments, the video sequence can be an uncompressed video sequence (e.g., video sequence 202) or a decoded compressed video sequence (e.g., video stream 304). In some embodiments, the video sequence can be a surveillance video sequence captured by a surveillance device (e.g., Figure the video input device in FIG. 4) associated with a device processor (e.g., processor 402). The video sequence can include multiple pictures. The device can execute method 1500 at the picture level. For example, in method 1500, the device can process one picture at a time. For another example, in method 1500, the device can process a plurality of pictures at a time. Method 1500 can include the following steps. In step 1502, it can be determined whether a chroma scaling index exists in the received video data. In step 1504, in response to the determination that no chroma scaling index exists in the received video data, it can be determined that the received video data has not been applied with chroma scaling. In step 1506, in response to the determination that a chroma scaling index exists in the received video data, chroma scaling factors can be determined based on the chroma scaling index. Figure 16 depicts a flowchart of a computer-implemented method 1600 for processing video content. In some embodiments, it can be executed by an encoder / decoder (e.g., Figure the encoder in FIGS. 2A-2B or Figure The decoder in 3A-3B) executes method 1600. For example, the codec can be implemented as one or more software or hardware components of a device (such as device 400) for encoding or transform coding a video sequence. In some embodiments, the video sequence can be an uncompressed video sequence (e.g., video sequence 202) or a decoded compressed video sequence (e.g., video stream 304). In some embodiments, the video sequence can be a surveillance video sequence captured by a surveillance device (such as Figure the video input device in 4). The video sequence can include multiple pictures. The device can execute method 1600 at the picture level. For example, in method 1600, the device can process one picture at a time. For another example, in method 1600, the device can process multiple pictures at a time. Method 1600 can include the following steps. In step 1602, a plurality of unique codewords for an input video signal for a dynamic range can be received. In step 1604, an index can be received. In step 1606, at least one of the plurality of unique codewords can be selected based on the index. In step 1608, a chroma scaling factor can be determined based on the selected at least one codeword. In some embodiments, a non-transitory computer-readable storage medium including instructions is also provided, and the instructions can be executed by a device (such as a disclosed encoder and decoder) that executes the above method. Common forms of non-transitory media include, for example, floppy disks, floppy disks, hard disks, solid state drives, magnetic tapes, or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a punched pattern, RAM, PROM, EPROM, FLASH-EPROM, or any other flash memory, NVRAM, cache memory, registers, any other memory chip or cartridge tape, and their network versions, etc. The device can include one or more processors (CPUs), an input / output interface, a network interface, and / or a memory. It should be understood that the above embodiments can be implemented by hardware, software (code), or a combination of hardware and software. If implemented by software, it can be stored in the above computer-readable medium. The software, when executed by a processor, can execute the disclosed method. The computing units and other functional units described in this disclosure can be implemented by hardware, software, or a combination of hardware and software. Those skilled in the art should be able to understand that many of the above modules / units can be combined into one module / unit, and each of the above modules / units can be further divided into a plurality of sub-modules / sub-units. The following examples will further illustrate these embodiments: 1. A computer-implemented method for processing video content, comprising: receiving a chrominance block and a luminance block associated with a picture; determining luminance scaling information associated with the luminance block; determining a chrominance scaling factor based on the luminance scaling information; and processing the chrominance block using the chrominance scaling factor. 2. The method according to Example 1, wherein determining the chrominance scaling factor based on the luminance scaling information further comprises: determining a luminance scaling factor of the luminance block based on the luminance scaling information; determining the chrominance scaling factor based on the value of the luminance scaling factor. 3. The method according to Example 2, wherein determining the chrominance scaling factor based on the value of the luminance scaling factor further comprises: setting the chrominance scaling factor to be equal to the value of the luminance scaling factor. 4. The method according to any one of Examples 1-3, wherein processing the chrominance block using the chrominance scaling factor further comprises: determining whether a first condition is satisfied; and performing one of the following: in response to a determination that the first condition is satisfied, processing the chrominance block using the chrominance scaling factor; or in response to a determination that the first condition is not satisfied, bypassing the processing of the chrominance block using the chrominance scaling factor. 5. The method according to Example 4, wherein the first condition comprises: a target coding unit associated with a picture having no non-zero residual; or a target transform unit associated with a picture having no non-zero chrominance residual. 6. The method according to Example 5, wherein: based on the value of a first coding block flag of the target coding unit, determining that the target coding unit has no non-zero residual, and based on the value of a second coding block flag of a first chrominance component of the target transform unit and the value of a third coding block flag of a second chrominance component of the target transform unit, determining that the target transform unit has no non-zero chrominance residual. 7. The method according to Example 6, wherein: the value of the first coding block flag is 0; and the values of the second coding block flag and the third coding block flag are 0. 8. The method according to any one of Examples 1-7, wherein processing the chrominance block using the chrominance scaling factor comprises: processing the residual of the chrominance block using the chrominance scaling factor. 9. A device for processing video content, comprising: a memory that stores a set of instructions; and a processor coupled to the memory and configured to execute the set of instructions to cause the device to perform: receiving a chrominance block and a luminance block associated with a picture; determining luminance scaling information associated with the luminance block; determining a chrominance scaling factor based on the luminance scaling information; and processing the chrominance block using the chrominance scaling factor.10. The device as described in Example 9, wherein in the step of determining the chrominance scaling factor based on the luminance scaling information, the processor is configured to execute the set of instructions to cause the device to further perform: determining the luminance scaling factor of the luminance block based on the luminance scaling information; and determining the chrominance scaling factor based on the value of the luminance scaling factor. 11. The device as described in Example 10, wherein in the step of determining the chrominance scaling factor based on the value of the luminance scaling factor, the processor is configured to execute the set of instructions to cause the device to further perform: setting the chrominance scaling factor to be equal to the value of the luminance scaling factor. 12. The device as described in any one of Examples 9-11, wherein in the step of processing the chrominance block using the chrominance scaling factor, the processor is configured to execute the set of instructions to cause the device to further perform: determining whether a first condition is satisfied; and performing one of the following: in response to a determination that the first condition is satisfied, processing the chrominance block using the chrominance scaling factor; or in response to a determination that the first condition is not satisfied, bypassing the processing of the chrominance block using the chrominance scaling factor. 13. The device as described in Example 12, wherein the first condition includes: a target coding unit associated with a picture having no non-zero residual; or a target transform unit associated with a picture having no non-zero chrominance residual. 14. The device as described in Example 13, wherein: based on the value of the first coding block flag of the target coding unit, it is determined that the target coding unit has no non-zero residual, and based on the value of the second coding block flag for the first chrominance component of the target transform unit and the value of the third coding block flag for the second chrominance component of the target transform unit, it is determined that the target transform unit has no non-zero chrominance residual. 15. The device as described in Example 14, wherein: the value of the first coding block flag is 0; and the values of the second coding block flag and the third coding block flag are 0. 16. The device as described in any one of Examples 9-15, wherein in the step of processing the chrominance block using the chrominance scaling factor, the processor is configured to execute the set of instructions to cause the device to further perform: processing the residual of the chrominance block using the chrominance scaling factor. 17. A non-transitory computer-readable storage medium that stores a set of instructions executable by one or more processors of a device to cause the device to execute a method for processing video content, the method including: receiving a chrominance block and a luminance block associated with a picture; determining luminance scaling information associated with the luminance block; determining a chrominance scaling factor based on the luminance scaling information; and processing the chrominance block using the chrominance scaling factor. 18. A computer-implemented method for processing video content, the method including: receiving a chrominance block and a luminance block associated with a picture, the luminance block including. N×M luminance samples; in response to at least one of the N and M being greater than a threshold value, selecting the A subset of N×M luminance samples; determining the average value of a subset of N×M luminance samples; determining a chrominance scaling factor based on the average value; and processing the chrominance block using the chrominance scaling factor. 19. A computer-implemented method for processing video content, the method comprising: determining whether a chrominance scaling index exists in received video data; in response to a determination that the chrominance scaling index does not exist in the received video data, determining that the received video data has not been subjected to chrominance scaling; and in response to a determination that the chrominance scaling index exists in the received video data, determining a chrominance scaling factor based on the chrominance scaling index. 20. A computer-implemented method for processing video content, the method comprising: receiving a plurality of unique codewords for an input video signal for a dynamic range; receiving an index; selecting at least one of the plurality of unique codewords based on the index; and determining a chrominance scaling factor based on the selected at least one codeword. In addition to implementing the above methods by using computer-readable program code, the above methods can also be implemented in the form of logic gates, switches, ASICs, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be regarded as a hardware component, and devices included in the controller and configured to implement various functions can also be regarded as structures in the hardware component. Alternatively, devices configured to implement various functions can even be regarded as software modules, etc. that are configured to implement methods and structures inside the hardware component. The present disclosure can be described in the general context of computer-executable instructions (such as program modules) executed by a computer. Generally, program modules include routines, programs, objects, assemblies, data structures, classes, or the like for performing specific tasks or implementing specific abstract data types. Embodiments of the present disclosure can also be implemented in a distributed computing environment. In a distributed computing environment, tasks are performed by using remote processing devices connected through a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media, including storage devices. It should be understood that related terms herein such as "first" and "second" are only used to differentiate one entity or operation from another entity or operation, and do not necessarily or imply any actual association or order between such entities or operations. In addition, the words "comprising", "having", "including", and "containing" and other similar forms are equivalent in meaning and are open-ended. Therefore, one or more items following any of these words do not mean an exhaustive list of such items, nor are they limited to the listed items. In the foregoing specification, embodiments have been described with reference to numerous specific details that may vary according to implementation manners. Certain modifications and adjustments can be made to the described embodiments. Considering the specification and implementation manners disclosed herein, other embodiments will be apparent to those skilled in the art. Therefore, the specification and examples are to be regarded as illustrative only, and the actual scope and spirit of the present disclosure will be shown by the following claims. It is also desirable that the order of steps shown in the accompanying drawings is for illustrative purposes only and is not intended to limit any particular order of steps. Accordingly, those skilled in the art will recognize that these steps can be performed in a different order while still implementing the same method. 100: Video sequence 102: Frame 104: Frame 106: Frame 108: Frame 110: Structure 112: Basic processing unit 114: Region 116: Region 118: Region 200A: Encoding process 200B: Encoding process 202: Video sequence 204: Prediction stage 2042: Spatial prediction stage 2044: Temporal prediction stage 206: Prediction data 208: Prediction BPU 210: Residual BPU 212: Transformation stage 214: Quantization stage 216: Quantized transform coefficients 218: Inverse quantization stage 220: Inverse transformation stage 222: Reconstructed residual BPU 224: Prediction reference 226: Binary encoding stage 228: Video bitstream 230: Mode decision stage 232: Loop filtering stage 234: Buffer 300A: Decoding process 300B: Decoding process 302: Binary decoding stage 304: Video stream 400: Device 402: Processor 402a~402n: Processors 404: Memory 406: Network interface 408: Peripheral interface 410: Bus 500: Luminance mapping process with chroma scaling 502: Video bitstream 504: Q -1 &T -1Stage 506: Reconstruction stage 508: Inverse mapping stage 510: Loop filtering stage 512: Decoded picture buffer stage 514: Intra prediction stage 516: Motion compensation stage 518: Forward mapping stage 520: Chroma scaling stage 522: Reconstruction stage 524: Loop filtering stage 526: Decoded picture buffer stage 528: Intra prediction stage 530: Motion compensation stage 1300: Method 1302: Step 1304: Step 1306: Step 1308: Step 1400: Method 1402: Step 1404: Step 1406: Step 1408: Step 1410: Step 1500: Method 1502: Step 1504: Step 1506: Step 1600: Method 1602: Step 1604: Step 1606: Step 1608: Step Various aspects and embodiments of the present disclosure are depicted in the following detailed description and the accompanying drawings. The various features shown in these drawings are not drawn to scale. [ FIG 1] depicts the structure of an exemplary video sequence according to some embodiments of the present disclosure. [ FIG 2A] depicts a schematic diagram of an exemplary encoding process according to some embodiments of the present disclosure. [ FIG 2B] depicts a schematic diagram of another exemplary encoding process according to some embodiments of the present disclosure. [ FIG 3A] depicts a schematic diagram of an exemplary decoding process according to some embodiments of the present disclosure. [ FIG 3B] depicts a schematic diagram of another exemplary decoding process according to some embodiments of the present disclosure. [ FIG 4] depicts a block diagram of an exemplary device for encoding or decoding video according to some embodiments of the present disclosure. [ FIG 5] depicts a schematic diagram of an exemplary luma mapping with chroma scaling (LMCS) process according to some embodiments of the present disclosure. [ FIG 6]描绘根据本揭露若干实施例的针对LMCS分段线性模型之片(tile)群组层级的语法表。 [ Figure 7]描绘根据本揭露若干实施例的针对LMCS分段线性模型之另一片群组层级的语法表。 [ Figure 8]是根据本揭露若干实施例的编码树单元语法结构之表。 [ Figure 9]是根据本揭露若干实施例的双树分割语法结构之表。 [ Figure 10]描绘根据本揭露实施例的简化亮度预测区块取平均值的实例。 [ Figure 11]是根据本揭露若干实施例的编码树单元语法结构之表。 [ Figure 12]是根据本揭露若干实施例的针对在片群组层级之LMCS分段线性模型的调整后发讯之语法元素表。 [ Figure 13]是根据本揭露若干实施例用于处理视讯内容的方法之流程图。 [ Figure 14]是根据本揭露若干实施例用于处理视讯内容的方法之流程图。 [ Figure 15]是根据本揭露若干实施例用于处理视讯内容的另一方法之流程图。 [ Figure 16]是根据本揭露若干实施例用于处理视讯内容的另一方法之流程图。 100: Video sequence 102: Frame 104: Frame 106: Frame 108: Frame 110: Structure 112: Basic processing unit 114: Region 116: Region 118: District

Claims

1. A computer-implemented video decoding method, comprising: reconstructing multiple luminance samples associated with the image; And reconstructing the chromaticity blocks associated with the image, wherein, Reconstructing the chroma block includes: determining whether the chroma block has a non-zero residual; In response to the determination that the chroma block has one or more non-zero chroma residuals, before reconstructing the chroma block, the average value of a plurality of reconstructed luminance samples is determined, and the residuals of the chroma block are scaled based on the average value.

2. The method as described in claim 1, wherein, Reconstructing the chromaticity block further includes: in response to the determination that the chromaticity block does not have a non-zero chromaticity residual, bypassing the determination of the average value of the plurality of reconstructed luminance samples.

3. The method as described in claim 1, wherein, Scaling the residual of the chroma block based on the average of the plurality of reconstructed luminance samples includes: determining a chroma scaling factor based on the average of the plurality of reconstructed luminance samples; and applying the chroma scaling factor to the residual of the chroma block.

4. The method as described in claim 1, wherein, Whether the chroma block has a non-zero residual is determined based on the value of the coded block flag associated with the chroma block.

5. The method as described in claim 4, further comprising: In response to the value of the coded block flag being equal to 1, it is determined that the chroma block has one or more non-zero residuals.

6. The method as described in claim 4, further comprising: If the value of the coded block flag is equal to 0, it is determined that the chroma block does not have a non-zero residual.

7. The method as described in claim 1, wherein, Whether the chroma block has a non-zero residual is determined based on the following values: the value of the first coding block flag associated with the first chroma component of the chroma block, and the value of the second coding block flag associated with the second chroma component of the chroma block.

8. The method as described in claim 7, further comprising: In response to at least one of the values ​​of the first coded block flag or the second coded block flag being equal to 1, it is determined that the chroma block has one or more non-zero residuals.

9. The method as described in claim 7, further comprising: If both the value of the first coded block flag and the value of the second coded block flag are equal to 0, it is determined that the chroma block does not have a non-zero residual.

10. A video decoding device, comprising: One or more memory stores an instruction set; and one or more processors are configured to execute the instruction set to cause the video decoding device to perform the following operations: reconstructing a plurality of luminance samples associated with a picture; and reconstructing a chroma block associated with the picture, wherein, when reconstructing the chroma block, the one or more processors are configured to execute the instruction set to cause the video decoding device to further perform the following operations: determining whether the chroma block has a non-zero residual; and in response to determining that the chroma block has one or more non-zero chroma residuals, determining an average value of a plurality of reconstructed luminance samples before reconstructing the chroma block, and scaling the residual of the chroma block based on the average value.

11. The device as described in claim 10, wherein, The one or more processors are configured to execute the instruction set to cause the device to further perform: in response to the determination that the chroma block does not have a non-zero chroma residual, bypassing the average value of the plurality of reconstructed luminance samples.

12. The device as described in claim 10, wherein, The one or more processors are configured to execute the instruction set to cause the device to further perform: determining a chroma scaling factor based on the average value of the plurality of reconstructed luminance samples; and applying the chroma scaling factor to the residual of the chroma block.

13. The device as described in claim 10, wherein, The one or more processors are configured to execute the instruction set to cause the device to further perform: determining whether the chroma block has a non-zero residual based on the value of the coded block flag associated with the chroma block.

14. The device as described in claim 13, wherein, The one or more processors are configured to execute the instruction set to cause the device to further perform: in response to the value of the coded block flag being equal to 1, determining that the chroma block has one or more non-zero residuals.

15. The device as described in claim 13, wherein, The one or more processors are configured to execute the instruction set to cause the device to further perform: in response to the value of the coded block flag being equal to 0, determining that the chroma block does not have a non-zero residual.

16. A non-transitory computer-readable storage medium storing a bitstream associated with a video sequence, wherein, The bitstream includes encoded information for reconstructing chroma blocks associated with the image, the encoded information including: an encoded block flag indicating whether the chroma block has a non-zero residual, wherein the bitstream is processed according to a method including the following steps: reconstructing a plurality of luminance samples associated with the image; and when the encoded block flag indicates that the chroma block has one or more non-zero chroma residuals, determining the average value of the plurality of reconstructed luminance samples before reconstructing the chroma block, and scaling the residual of the chroma block based on the average value.

17. The media as described in claim 16, wherein, The method further includes the following steps: when the coded block flag indicates that the chroma block does not have a non-zero chroma residual, the determination of the average value of the plurality of reconstructed luminance samples is bypassed.

18. The media as described in claim 16, wherein, Scaling the residual of the chroma block based on the average of the plurality of reconstructed luminance samples includes: determining a chroma scaling factor based on the average of the plurality of reconstructed luminance samples; and applying the chroma scaling factor to the residual of the chroma block.

19. The media as described in claim 16, wherein, A value of 1 for the coded block flag indicates that the chroma block has a non-zero residual, and a value of 0 for the coded block flag indicates that the chroma block does not have a non-zero residual.

20. The media as described in claim 16, wherein, The coded block flag includes: a first coded block flag associated with a first chroma component of the chroma block, and a second coded block flag associated with a second chroma component of the chroma block, wherein: when at least one of the value of the first coded block flag or the value of the second coded block flag is equal to 1, it indicates that the chroma block has one or more non-zero residuals; and when both the value of the first coded block flag and the value of the second coded block flag are equal to 0, it indicates that the chroma block does not have non-zero residuals.

Images