Method and system for processing video content
Patent Information
- Authority / Receiving Office
- TW · TW
- Patent Type
- Patents
- Current Assignee / Owner
- HFI INNOVATION INC
- Filing Date
- 2020-03-03
- Publication Date
- 2026-08-01
Smart Images

Figure TWG2TB001903619_001 
Figure TWG2TB001903619_002 
Figure TWG2TB001903619_003
Abstract
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 Mar. 4, 2019, and U.S. Provisional Application No. 62 / 817,546, filed on Mar. 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. As high-definition (HD) video (e.g., video with a resolution of 1920×1080 pixels) becomes more prevalent 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 monitoring 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 bit rate, 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 has thus become 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 an apparatus for processing video content. The apparatus 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 apparatus 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 the 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 static 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., a 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 in any of various 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, the 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 to reduce 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 represents the movement of an object, which 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 bitrate of the encoded video can be reduced. Among I-pictures, P-pictures, and B-pictures, I-pictures have the highest bitrate. Since the background of most surveillance videos is almost static, one way to reduce the total bitrate of the encoded video can be to use fewer I-pictures for video encoding. However, the improvement by using fewer I-pictures may be insignificant 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 bitrate. In other words, in this example, even if all I-pictures are removed, the reduction in bitrate may be no more than 10%. This 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 associated with at least one object, scene, or environmental event in the frame. For another example, the motion feature may include information associated with video encoding processing, and examples thereof will be described below. In this 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 bitrates. 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 bitrate can be significantly reduced for surveillance videos without causing significant information loss. In addition, embodiments of this disclosure can customize the correspondence between the priority levels and the parameter sets for different application scenarios (such as 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 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 several 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 called a "coding tree unit (CTU)". In a frame, the basic processing unit can 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 called "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 called a "block", or in some other video coding standards (e.g., H.265 / HEVC or H.266 / VVC) it is called 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, which 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 depending on the processing requirements, such division can be carried out to a further extent. 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 (examples of which will be described 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 (examples of which will be described 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., called "prediction blocks" or "PBs" in H.265 / HEVC or H.266 / VVC), and prediction operations can be performed at this level. For another example, in the transform stage (examples of which will be described in detail in FIG As shown in FIG. 2A), the encoder may perform a transformation operation on a basic processing unit (e.g., 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., called "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. In the structure 110 of FIG. 1, the basic processing unit 112 is further divided into 3×3 basic processing subunits, and its boundaries are shown by dotted lines. Different basic processing units of the same picture can be divided into basic processing subunits by different schemes. In some implementations, to provide the ability of parallel processing and error resilience for video encoding and decoding, a picture can be divided into regions for processing, so that for one region of the picture, the encoding or decoding process can be independent of the 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 during processing 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 coding 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 may have different partitioning schemes for dividing a picture into regions. For example, in FIG. 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 subunits, and regions of the structure 110 in FIG. 1 are only illustrative, and the present disclosure is not limited to its embodiments. FIG. 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 the video sequence 100 of FIG. 1, the 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 the video sequence 202 may be divided by an encoder into basic processing units, basic processing sub-units, 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 the 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 the video sequence 202. In Figure 2A, the encoder may feed basic processing units (referred to as "original BPUs") of the original pictures of the video sequence 202 to a prediction stage 204 to generate prediction data 206 and a prediction BPU 208. The encoder may subtract the prediction BPU 208 from the original BPU to generate a residual BPU 210. The encoder may feed the residual BPU 210 to a transform stage 212 and a quantization stage 214 to generate quantized transform coefficients 216. The encoder may feed the prediction data 206 and the 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 the 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 the reconstructed residual BPU 222 to the prediction BPU 208 to generate a prediction reference 224, which is used in the 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 the 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, obtaining, acquiring, getting, reading, accessing, or any other form of data input action. 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 will typically be 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., a grayscale value or an RGB value). These subtractions between the corresponding pixels of the original BPU and the prediction BPU 208 will result in each pixel of the residual BPU 210 having a residual value. Compared to 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 pattern 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 brightness variation) component of the residual BPU 210. None of these basis patterns can be reproduced from any combination (e.g., a 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 pattern is similar to the basis function of the discrete Fourier transform (e.g., a trigonometric function), and the transformation coefficient is similar to the coefficient associated with the basis function. Different transformation algorithms can use different base 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, to recover the pixels of the residual BPU 210, the inverse transformation can multiply the values of the corresponding pixels of the base 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 base pattern). Therefore, the encoder can record only the transformation coefficients, and the decoder can reconstruct the residual BPU 210 from them without receiving the base 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 base patterns can represent different variation frequencies (e.g., luminance variation frequencies). Since the human eye is usually 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 the "quantization parameter") and rounding the quotient to the nearest integer value. Through such an operation, some transformation coefficients of the high-frequency base pattern can be transformed into zero, and the transformation coefficients of the low-frequency base 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 this 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 can use binary encoding techniques to encode the prediction data 206 and the quantized transform coefficients 216. Such binary encoding techniques include entropy encoding, variable length encoding, arithmetic encoding, Huffman encoding, context adaptive binary arithmetic encoding, or any other lossless or lossy compression algorithm. In some embodiments, in addition to the prediction data 206 and the quantized transform coefficients 216, the encoder can also encode other information in the binary encoding stage 226. Such other information includes, for example, 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 can use the output data of the binary encoding stage 226 to generate the video bitstream 228. In some embodiments, the video bitstream 228 can be further packetized for network transmission. Referring to the reconstruction path of the processing 200A, in the inverse quantization stage 218, the encoder can perform inverse quantization on the quantized transform coefficients 216 to generate the reconstructed transform coefficients. In the inverse transform stage 220, the encoder can generate the reconstructed residual BPU 222 based on the reconstructed transform coefficients. The encoder can add the reconstructed residual BPU 222 to the prediction BPU 208 to generate the 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 can be used to encode the video sequence 202. In some embodiments, the encoder can perform the stages of the processing 200A in a different order. In some embodiments, one or more stages of the processing 200A can be combined into a single stage. In some embodiments, a single stage of the processing 200A can be divided into multiple stages. For example, the transform stage 212 and the quantization stage 214 can be combined into a single stage. In some embodiments, the processing 200A can include additional stages, and in some embodiments, the processing 200A can omit Fig. one or more stages in Fig. 2A. Generally, 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 transfer 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 transfer 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, and so on. 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., bottom-left, bottom-right, top-left, or top-right of the original BPU), or any direction defined in the video coding standard used. For intra prediction, the prediction data 206 can include, for example, the position (e.g., coordinates) of the adjacent BPU used, the size of the adjacent BPU used, the parameters of the extrapolation, or the direction of the adjacent BPU used relative to the original BPU, and so on. 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 transfer 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 the reconstructed BPU. After all the reconstructed BPUs of the same picture are generated, the encoder may generate the 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 with 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 the matching region. The matching region may have different dimensions (e.g., smaller, equal, larger, or different shapes) from the original BPU. 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 this 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 region of the reference picture (e.g., the matching region of picture 106 of 1), the encoder can move the matching region of the reference picture according to the respective motion vectors and the average pixel value of the matching region. In some embodiments, if the encoder has assigned weights to the pixel values of the matching regions of the respective matching reference pictures, the encoder can add the weighted sums of the pixel values of the moved matching regions. In some embodiments, inter-picture prediction can be unidirectional or bidirectional. Unidirectional inter-picture 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 an unidirectional inter-picture prediction picture, where the reference picture (i.e., picture 102) is before picture 104. Bidirectional inter-picture 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-picture 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 prediction 2042 and the temporal prediction stage 2044, at the mode decision stage 230, the encoder can select a prediction mode (e.g., one of intra-picture prediction or inter-picture 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 modes and the distortion of the reconstructed reference pictures under the candidate prediction modes. 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 within the selected box 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 can 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 within the selected box 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 can feed the prediction reference 224 to the loop filter stage 232, where the encoder can apply loop filtering to the prediction reference 224 to reduce or eliminate distortions introduced by inter prediction (e.g., blocking artifacts). In the loop filter stage 232, the encoder can apply various loop filtering techniques, such as deblocking, sample adaptive offset, or adaptive loop filtering. The reference picture for loop filtering can be stored in a buffer 234 (or "decoded picture buffer") for later use (e.g., can be used as an inter prediction reference picture for future pictures of the video sequence 202). The encoder can store one or more reference pictures in the buffer 234 for use in the temporal prediction stage 2044. In some embodiments, the encoder can encode 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. Process 300A can be a decompression process corresponding to the compression process 200A in Figure 2A. In some embodiments, process 300A can be similar to the reconstruction path of process 200A. According to process 300A, the encoder can decode the video bitstream 228 into a video stream 304. The video stream 304 can 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, and the decoder can perform processing 300A at the level of the basic processing unit (BPU) 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") into 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 into 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 into 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 into 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 prediction mode, parameters of the prediction operation, transform type, parameters of the quantization process (e.g., quantization parameter), or encoder control parameters (e.g., bitrate control parameter), 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 into the binary decoding stage 302. Figure FIG. 3B depicts a schematic diagram of another exemplary decoding process 300B in accordance with 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 to 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 a coded basic processing unit (referred to as the “current BPU”) of the coded 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 code the current BPU. For example, if the encoder uses intra prediction to code 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 positions (e.g., coordinates) of one or more adjacent BPUs used as references, the sizes of the adjacent BPUs, extrapolation parameters, or the directions of the adjacent BPUs relative to the original BPU, etc. As another example, if the encoder uses inter prediction to code 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 positions (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. Details of performing such spatial prediction or temporal prediction have been described in FIG. 2B, and thus their descriptions will not be repeated hereinafter. 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 prediction reference 224, as FIG. shown in FIG. 3A. In process 300B, the decoder may 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 may 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 may feed the prediction reference 224 to the loop filter stage 232 to reduce or eliminate distortion (e.g., blocking artifacts). The decoder may apply loop filtering to the prediction reference 224 in the manner described in FIG 2B. The reference picture for loop filtering may be stored in buffer 234 (e.g., the decoded picture buffer in a computer memory) for later use (e.g., as an inter prediction reference picture for future encoded pictures of video bitstream 228). The decoder may store one or more reference pictures in 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 for loop filtering (e.g., loop filter strength). FIG 4 is a block diagram of an exemplary device 400 for encoding or decoding video according to some embodiments of the present disclosure. As FIG 4 shows, the device 400 may include a processor 402. When the processor 402 executes the instructions described herein, the device 400 may become a dedicated machine for video encoding or decoding. The processor 402 may 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. Device 400 may also include a memory 404, which is configured to store data (such as instruction sets, computer code, or intermediate data, etc.). For example, as Figure shown in FIG. 4, the stored data may include program instructions (such as program instructions for implementing the stages in processes 200A, 200B, 300A, or 300B) and data for processing (such as video sequence 202, video bitstream 228, or video stream 304). The processor 402 can access the program instructions and data for processing (such as via bus 410), and execute the program instructions to perform operations or computations on the data for processing. The memory 404 may include high-speed random access storage devices or non-volatile storage devices. In some embodiments, the memory 404 may include any combination of any number of random access memories (RAM), read-only memories (ROM), optical discs, magnetic disks, hard disks, solid state drives, flash drives, secure digital (SD) cards, memory sticks, or compact flash (CF) cards. The memory 404 may also be a group of memories grouped into a single logical component ( Figure not shown in FIG. 4). The bus 410 can be a communication device for transferring data between components in device 400, such as an internal bus (such as a CPU memory bus), or an external bus (such as 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 circuits can be implemented entirely in hardware, or a combination of software, hardware or firmware. In addition, the data processing circuits can be a single independent module or can be fully combined or partially combined into any other component of device 400. Device 400 may further include a network interface 406 to provide wired or wireless communication with a network (such as the Internet, intranet, local area network, or mobile communication network, etc.). In some embodiments, the network interface 406 may include any combination of any number of network interface controllers (NIC), 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), and so on. It should be noted that a video codec (e.g., the codec implementing processes 200A, 200B, 300A, or 300B) may be implemented as any combination of any software or hardware modules in device 400. For example, some or all stages of processes 200A, 200B, 300A, or 300B may be implemented as one or more software modules in device 400, such as program instructions loadable into memory 404. As another example, some or all stages of processes 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 applied before the loop filter stage 232 in FIG 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 chroma-residual scaling that is luminance-dependent for 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 luminance-dependent chroma-residual scaling for chroma components may include a chroma scaling stage 520. Sample values before mapping or after inverse mapping may be referred to as samples in the original domain, and 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 executed 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 inverse quantization and inverse transform, reconstruction stage 506 may include addition of a luminance prediction and a luminance residual, and in-frame prediction stage 508 may include luminance in-frame prediction. The loop filter stage 510, motion compensation stages 516 and 530, in-frame prediction stage 528, reconstruction stage 522, and decoded 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 addition of a chrominance prediction and a 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. The 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 and is derived from the "FwdMap" function. In FIG Table 1 in FIG Table 2 in FIG Table 1 in FIG 6 depicts the header syntax structure of a slice group. As shown in FIG For the syntax elements shown in Table 2 in 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 the scaling factor and accordingly adjust the mapping function for the block. Figure Table 2 in 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 as 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 in 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 the reconstructed 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 the 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 may be performed. Chroma residual scaling is designed to compensate for the interaction between the luminance signal and its corresponding chroma signal. Whether chroma residual scaling is enabled or not, it is also signaled at the tile group level. As Figure shown in Table 1 of FIG. 6, if the luminance mapping is enabled and if the 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 the luminance - dependent chroma residual scaling is enabled. When luminance mapping is not used or when the dual - tree segmentation is used in the current tile group, the luminance - dependent chroma residual scaling is automatically disabled. In addition, the 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 the 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., of Figure 5). Different from the luma mapping performed based on samples, is a constant value for the entire chroma block. By using 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, forward chroma residual scaling is performed as follows (before transform and quantization): In some embodiments, dual-tree splitting may 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 referred to as dual-tree splitting. In of Figure 8 and Table 3 of Figure 9 and Table 4 show 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 Table 4 of Figure When the luminance and chrominance are allowed to have different types of partitioning, problems of dependencies between different color components may occur in the 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 the dual-tree, this may cause latency for the entire CTU. For example, if the luminance block of the 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, the 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 slice group, the chrominance scaling is forced to be off. It should be noted that the luminance mapping part of LMCS in the dual-tree case 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 slice group level chrominance scaling factor LUT cScaleInv[] is not easily scalable. The derivation process currently depends on the constant 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, 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 value. In dual-tree partitioning, the 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 slice 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 be the same as the luma scaling factor of the corresponding block, thus 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 through 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 in the following fixed-point approximation "CSCALE_FP_PREC". Where luma_bit_depth is the luma bit depth, 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 group of slices, 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 nth 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 value 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 fits 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 bi-directional 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 before DMVR and BDOF to calculate the average luminance value, 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. In accordance 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 the DMVR process and before the BDOF process. Then, the average luminance value is used to obtain the chroma scaling factor. This design allows chroma scaling to be applied in parallel with the BDOF process while maintaining the accuracy of determining the chroma scaling factor. Since the DMVR process can refine the motion vectors, using the predicted samples with refined motion vectors after the DMVR process is more accurate than using the predicted samples with motion vectors before the DMVR process. 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 chroma (Cb or Cr) residual coefficients in the current TU. In the prior art, in VVC draft 4, if chroma 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. In accordance with the disclosed embodiments, since the chroma scaling process is applied to the residual chroma coefficients, the luminance averaging process can be bypassed if there are no non-zero chroma 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 chroma (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 chroma 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 exemplary intra-frame 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 exemplary inter-frame prediction, reference samples from a temporal reference picture can be used to generate a prediction block. Such reference samples are identified through 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 the present 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-frame prediction (e.g., intra-frame prediction 514 or 528) can be performed in a reshaped domain, while inter-frame prediction is performed in the original domain. Thus, for inter-frame 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, an 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 the present disclosure further provide a method for processing video content using chroma scaling for dual-tree partitioning. Because the dependence on luminance may cause hardware design complexity, chroma scaling can be turned off for the slice group enabling intra-frame coding for dual-tree partitioning. 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 signaled explicitly in the bitstream to avoid the dependence on luminance in the case of dual-tree partitioning. 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 in fixed-point precision (1 << CSCALE_FP_PREC). 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 of Table 5 in Figure 11 may additionally include a block size condition. 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 can be determined on the decoder side. In some embodiments, the chroma scaling factor can 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" can use this slice group level default index to derive the corresponding chroma scaling factor. In some embodiments, the chroma scaling factor of a block can be inherited from its neighbor with an explicitly signaled scaling factor (e.g., the upper or left neighbor). 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" according to 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 the 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 list of unique codewords listUniqueCW. The reshaper_model_bin_delta_abs_CW[i] specifies the absolute delta codeword value for the i-th bin. The 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] shall 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, 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. In accordance 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-frame predicted, the prediction signal tends to be good, especially when its reference picture is close in temporal distance. Therefore, since the expected residual is extremely small, chroma scaling can be bypassed. For example, in higher temporal levels, 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 / 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 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 multiple screens at a time. Method 1300 may include the following steps. In step 1302, the chroma block and the luma block associated with the screen may be received. It should be understood that the screen may be associated with a chroma component and a luma component. Therefore, the screen may be related to a chroma block containing chroma samples and a luma block containing luma samples. In step 1304, the luma scaling information associated with the luma block may be determined. In some embodiments, the luma 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 luma 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 luma scaling information may include a variable determined based on the luma block. For example, the average luma value may be determined by calculating the average of the luma samples adjacent to the luma block (such as the luma samples in a row at the top of the luma block or the luma samples in a column on the left side of the luma block). In step 1306, the chroma scaling factor may be determined based on the luma scaling information. In some embodiments, the luma scaling factor of the luma block may be determined based on the luma 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 luma scaling factor may be determined based on the luma scaling information (e.g., "tempCW"). Then, the chroma scaling factor may be further determined based on the value of the luma scaling factor. For example, the chroma scaling factor may be set equal to the value of the luma scaling factor. It should be understood that further calculations may be applied to the value of the luma scaling factor before it is set as the chroma scaling factor. As another example, the chroma scaling factor may be set equal to "SignaledCW[ ] / OrgCW", where the block index of the current chroma block " " may be determined based on the average luma value associated with the luma 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 may 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 multiple 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 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, an 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 a 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 may be determined. In some embodiments, to determine the chrominance scaling factor, a block index of a chrominance block may be determined based on the average value, it may 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 may be set to a preset value. The preset value may indicate that no chrominance scaling is applied. For example, the preset value may be 1.0 with fractional precision. It should be understood that a fixed-point approximation may 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 may be determined based on the average value. More specifically, the chrominance scaling factor may be set to "SignaledCW[ ] / OrgCW", and the block index of the target chrominance block " " may be determined based on the average value associated with the corresponding luminance block. In some embodiments, the first condition may 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 may be determined as follows. Codewords may be generated based on an input signal (e.g., luminance samples) by using a piecewise linear model (e.g., LMCS). As described above, an input signal of a dynamic range may be divided into several blocks (e.g., 16 blocks) and each block of the input signal may be used to generate a bin of a codeword as an output. Thus, each bin of the codeword may have a bin index corresponding to the block of the input signal. In this example, the range of the bin index may 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 may be signaled. And the bin indices of the plurality of signaled codewords may 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 may be further determined. In addition to the chrominance scaling factor, method 1400 may further determine a luminance scaling factor based on the bins of the plurality of signaled codewords. The luminance scaling factor may be used as an inverse chrominance scaling factor. The equations for determining the luminance scaling factor have been described above and the repeated description thereof will be omitted herein. In some embodiments, a plurality of numbers of adjacent signaled codewords share the luminance scaling factor. For example, two or four adjacent signaled codewords may share the same luminance scaling factor, which may reduce the burden of determining the luminance scaling factor. In step 1410, the chrominance block may be processed using the chrominance scaling factor. As previously referred to in FIG 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. FIG 15 depicts a flowchart of a computer-implemented method 1500 for processing video content. In some embodiments, the method 1500 can be executed by an encoder / decoder (e.g., FIG the encoder in FIGS. 2A-2B or FIG 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-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 (e.g., FIG 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, a chroma scaling factor can be determined based on the chroma scaling index. FIG 16 depicts a flowchart of a computer-implemented method 1600 for processing video content. In some embodiments, the method 1600 can be executed by an encoder / decoder (e.g., FIG the encoder in FIGS. 2A-2B or FIG 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-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 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 the 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 chroma 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 chroma 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 chroma 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 chroma 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 chroma block using the chroma 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 chroma block using the chroma scaling factor; or in response to a determination that the first condition is not satisfied, bypassing the processing of the chroma block using the chroma 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 residuals; or a target transform unit associated with a picture having no non-zero chroma residuals. 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 residuals, and based on the value of the second coding block flag for the first chroma component of the target transform unit and the value of the third coding block flag for the second chroma component of the target transform unit, it is determined that the target transform unit has no non-zero chroma residuals. 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 chroma block using the chroma scaling factor, the processor is configured to execute the set of instructions to cause the device to further perform: processing the residuals of the chroma block using the chroma 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 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. 18. A computer-implemented method for processing video content, the method including: receiving a chroma 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 the 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 codes, 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 may 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 may 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 may 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, so 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 for patent. 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 specific 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 transformation 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 method for processing video content, comprising: receiving a chroma block associated with a screen, the chroma block including a plurality of luminance samples; determining an average value of the plurality of luminance samples in the screen; and determining a chroma scaling factor based on the average value, wherein, The chroma scaling factor is used to process the residual of the chroma block, wherein processing the residual of the chroma block includes: determining whether the chroma block has a non-zero residual; and in response to determining that the chroma block has a non-zero residual, applying the chroma scaling factor to the residual of the chroma block.
2. As described in claim 1, whether the chroma block has a non-zero residual is determined based on the value of the coding block flag associated with the chroma block.
3. The method as described in claim 1, further comprising: In response to a value of 1 for the coded block flag associated with the chroma block, it is determined that the chroma block has a non-zero residual.
4. The method as described in claim 1, wherein, The determination of the average value of the plurality of brightness samples is triggered by determining that a first condition is met.
5. An apparatus for processing video content, the apparatus comprising: Memory, which stores instruction sets; and a processor connected to the memory and configured to execute the instruction set to cause the device to perform the following operations: receiving a chroma block associated with a screen, the chroma block comprising a plurality of luminance samples; determining the average value of the plurality of luminance samples in the screen; and determining a chroma scaling factor based on the average value; The residual of the chroma block is processed by applying the chroma scaling factor to the residual of the chroma block, wherein the processing of the residual of the chroma block includes: determining whether the chroma block has a non-zero residual; and in response to determining that the chroma block has a non-zero residual, applying the chroma scaling factor to the residual of the chroma block.
6. The device as described in claim 5, 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.
7. The device as described in claim 5, wherein, The processor is configured to execute the instruction set to enable the device to further perform the following operations: in response to a value of 1 for the coded block flag associated with the chroma block, determine that the chroma block has a non-zero residual.
8. A non-transitory computer-readable storage medium storing an instruction set and a bit stream, the instruction set being executable by one or more processors of a device to generate the bit stream, causing the device to perform a method for processing video content, the method comprising the steps of: receiving a chroma block associated with a frame, the chroma block comprising a plurality of luminance samples; and determining an average value of the plurality of luminance samples in the frame; The chromaticity scaling factor is determined based on the average value. The residual of the chroma block is processed by applying the chroma scaling factor to the residual of the chroma block, wherein the processing of the residual of the chroma block includes: determining whether the chroma block has a non-zero residual; and in response to determining that the chroma block has a non-zero residual, applying the chroma scaling factor to the residual of the chroma block.
9. The media as described in claim 8, 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.
10. The media as described in claim 8, wherein, The method further includes the following steps: In response to a value of 1 for the coded block flag associated with the chroma block, it is determined that the chroma block has a non-zero residual.