Method and system for processing video content

Abstract

This invention provides a system and method for processing video content. [Solution] This method includes receiving chromablocks and lumablocks associated with a picture, determining lumascale information associated with the lumablock, determining a chromascale factor based on the lumascale information, and processing the chromablock using the chromascale factor.

Description

[Technical Field]

[0001] Cross-reference of related applications

[0001] This disclosure claims the benefit of priority to U.S. Provisional Patent Application No. 62 / 813,728, filed 4 March 2019, and U.S. Provisional Patent Application No. 62 / 817,546, filed 12 March 2019, both of which are incorporated herein by reference in their entirety.

[0002] Technical field

[0002] This disclosure relates in general to video processing, and more particularly to a method and system for performing in-loop mapping by chroma scaling. [Background technology]

[0003] background

[0003] Video encoding systems are often used to compress digital video signals, for example, to reduce the amount of memory space consumed or to reduce the amount of transmission bandwidth consumed associated with such signals. As high-definition (HD) video (e.g., with a resolution of 1920x1080 pixels) becomes increasingly popular in various video compression applications such as online video streaming, video conferencing, or video surveillance, there is a constant need to develop video encoding tools that can improve the compression efficiency of video data.

[0004]

[0004] For example, video surveillance applications are being used more and more widely in many application scenarios (e.g., security, traffic, environmental monitoring, etc.), and the number of surveillance devices and resolutions are increasing rapidly. Many video surveillance application scenarios choose to provide users with HD video in order to capture more information, and HD video has more pixels per frame in order to capture such information. However, HD video bitstreams can have high bitrates that require high bandwidth for transmission and large space for storage. For example, a surveillance video stream with an average resolution of 1920x1080 may require as much as 4Mbps of bandwidth for real-time transmission. Furthermore, video surveillance generally involves continuous monitoring 24 hours a day, 7 days a week, which can significantly test the capacity of the storage system if video data is to be stored. Therefore, the demand for high bandwidth and large storage space of HD video is the main limit to the large-scale deployment of HD video in video surveillance. [Overview of the project] [Means for solving the problem]

[0005] Summary of Disclosure

[0005] Embodiments of the present disclosure provide a method for processing video content. This method may include receiving chroma blocks and luma blocks associated with a picture, determining luma scale information associated with the luma blocks, determining a chroma scale factor based on the luma scale information, and processing the chroma blocks using the chroma scale factor.

[0006]

[0006] Embodiments of the present disclosure provide a device for processing video content. The device may include a memory for storing a set of instructions and a processor coupled to the memory and configured to execute a set of instructions to cause the device to receive chroma blocks and luma blocks associated with a picture, determine luma scale information associated with the luma blocks, determine a chroma scale factor based on the luma scale information, and process the chroma blocks using the chroma scale factor.

[0007]

[0007] Embodiments of the present disclosure provide a non - transient 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 chroma blocks and luma blocks related to a picture, determining luma scale information related to the luma blocks, determining a chroma scale factor based on the luma scale information, and processing the chroma blocks using the chroma scale factor.

[0008] Brief Description of the Drawings

[0008] Embodiments and various aspects of the present disclosure are shown in the following detailed description and the accompanying drawings. The various features shown in the figures are not drawn to scale.

Brief Description of the Drawings

[0009] [Figure 1]

[0009] An example structure of a video sequence according to some embodiments of the present disclosure is shown. [Figure 2A]

[0010] A schematic diagram of an example of an encoding process according to some embodiments of the present disclosure is shown. [Figure 2B]

[0011] A schematic diagram of another example of an encoding process according to some embodiments of the present disclosure is shown. [Figure 3A]

[0012] A schematic diagram of an example of a decoding process according to some embodiments of the present disclosure is shown. [Figure 3B]

[0013] A schematic diagram of another example of a decoding process according to some embodiments of the present disclosure is shown. [Figure 4]

[0014] A block diagram of an example of a device for encoding or decoding video according to some embodiments of the present disclosure is shown. [Figure 5]

[0015] A schematic diagram of an exemplary luma mapping with chroma scaling (LMCS) process according to some embodiments of this disclosure is shown. [Figure 6]

[0016] The following is a tile group-level syntax table for LMCS piecewise linear models according to some embodiments of this disclosure. [Figure 7]

[0017] The following is a different tile group-level syntax table for LMCS piecewise linear models according to some embodiments of this disclosure. [Figure 8]

[0018] This is a table of syntactic structures at the coding tree level according to some embodiments of this disclosure. [Figure 9]

[0019] This is a table of the syntactic structure of a dual-tree partition according to some embodiments of this disclosure. [Figure 10]

[0020] This document presents an example of simplifying the averaging of Luma prediction blocks according to some embodiments of this disclosure. [Figure 11]

[0021] This is a table of syntactic structures at the coding tree level according to some embodiments of this disclosure. [Figure 12]

[0022] This is a table of syntactic elements relating to the modified signaling of the LMCS piecewise linear model at the tile group level, according to some embodiments of the present disclosure. [Figure 13]

[0023] This is a flowchart of a method for processing video content according to some embodiments of the present disclosure. [Figure 14]

[0024] This is a flowchart of a method for processing video content according to some embodiments of the present disclosure. [Figure 15]

[0025] This is a flowchart of another method for processing video content according to some embodiments of the present disclosure. [Figure 16]

[0026] This is a flowchart of another method for processing video content according to some embodiments of the present disclosure. [Modes for carrying out the invention]

[0010] Detailed explanation

[0027] Next, the examples will be described in detail with reference to the exemplary embodiments shown in the accompanying drawings. The following description will refer to the accompanying drawings, in which the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following description of the exemplary embodiments do not represent all implementations that conform to the present invention. Rather, they are merely examples of devices and methods that conform to the embodiments relating to the present invention enumerated in the accompanying claims. Unless otherwise specified, the words "or" include all possible combinations except in impractical cases. For example, if it is stated that a component may include A or B, then unless otherwise specified or in impractical cases, that component may include A or B, or A and B. As a second example, if it is stated that a component may include A, B, or C, then unless otherwise specified or in impractical cases, that component may include A or B, or C, or A and B, or A and C, or B and C, or A and B and C.

[0011]

[0028] An image is a set of still pictures (or "frames") arranged in chronological order to store visual information. An image capture device (e.g., a camera) can be used to capture and store these pictures in chronological order, and an image playback device (e.g., a television, computer, smartphone, tablet computer, video player, or any end-user terminal with display capabilities) can be used to display such pictures in chronological order. Furthermore, in some applications, the image capture device can transmit the captured image in real time to an image playback device (e.g., a computer with a monitor) for surveillance, conferencing, or live broadcasting.

[0012]

[0029] To reduce the memory space and transmission bandwidth required by such applications, video can be compressed before storage and transmission, and decompressed before display. This compression and decompression can be implemented by software executed by a processor (e.g., a general-purpose computer processor) or dedicated hardware. The module for compression is generally called an "encoder," and the module for decompression is generally called a "decoder." Encoders and decoders can be collectively called a "codec." Encoders and decoders can be implemented as various appropriate hardware, software, or combinations thereof. For example, a hardware implementation of an encoder and decoder may include circuits such as one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), rewritable gate arrays (FPGAs), discrete logic, or any combination thereof. A software implementation of an encoder and decoder may include program code, computer executable instructions, firmware, or algorithms or processes implemented by any appropriate computer fixed in a computer-readable medium. Video compression and decompression can be implemented by various algorithms or standards such as MPEG-1, MPEG-2, MPEG-4, and the H.26x series. In some applications, a codec can decompress video from a first encoding standard and then recompress the decompressed video using a second encoding standard; in such cases, the codec can be called a "transcoder."

[0013]

[0030] A video encoding process can identify and retain useful information that can be used to reconstruct the picture, while ignoring information that is not important for reconstruction. If the ignored, non-important information cannot be fully reconstructed, such an encoding process can be called "lossy." Otherwise, such an encoding process can be called "lossy." Most encoding processes are lossy, which is a trade-off to reduce the required memory space and transmission bandwidth.

[0014]

[0031] Useful information in an encoded picture (referred to as the "current picture") includes changes relative to a reference picture (e.g., a picture previously encoded and reconstructed). Such changes can include changes in pixel position, brightness, or color, with positional changes being the most relevant. Changes in the position of a group of pixels representing an object can reflect the movement of the object between the reference picture and the current picture.

[0015]

[0032] A picture that is coded without referencing another picture (i.e., such a picture is its own reference picture) is called an "I picture". A picture that is coded using a past picture as a reference picture is called a "P picture". A picture that is coded using both a past picture and a future picture as reference pictures (i.e., the reference is "bidirectional") is called a "B picture".

[0016]

[0033] As mentioned earlier, video surveillance using HD video faces the challenge of high bandwidth and large storage requirements. To address this challenge, the bitrate of encoded video can be reduced. Of I-pictures, P-pictures, and B-pictures, I-pictures have the highest bitrate. Since the background of most surveillance video is almost static, one way to reduce the overall bitrate of encoded video might be to use fewer I-pictures for encoding the video.

[0017]

[0034] However, since I-pictures are generally not the primary element in encoded video, improvements that reduce I-picture usage may be negligible. For example, in a typical video bitstream, the ratio of I-pictures, B-pictures, and P-pictures may be 1:20:9, with I-pictures accounting for less than 10% of the total bitrate. In other words, in such an example, removing all I-pictures may only reduce the bitrate by 10%.

[0018]

[0035] This disclosure provides methods, apparatus, and systems for characteristics-based video processing for video surveillance. “Characteristics” as used herein refers to content characteristics relating to video content within a picture, motion characteristics relating to motion estimation for encoding or decoding a picture, or both. For example, content characteristics may be pixels within one or more consecutive pictures in a video sequence, where the pixels relate to at least one object, scene, or environmental event within the picture. In another example, motion characteristics may include information relating to the video encoding process, examples of which will be detailed later.

[0019]

[0036] In this disclosure, when encoding pictures in a video sequence, a feature classifier can be used to detect and classify one or more features of the pictures in the video sequence. Different classes of features can be associated with different priority levels, which in turn can be associated with different bitrates for encoding. Different priority levels can be associated with different sets of parameters for encoding, thereby resulting in different levels of encoding quality. The higher the priority level, the higher the image quality that can be produced by its associated set of parameters. Such feature-based video processing can significantly reduce the bitrate for surveillance video without causing significant information loss. In addition, embodiments of this disclosure can customize the corresponding relationships between priority levels and parameter sets for various application scenarios (e.g., security, traffic, environmental monitoring, etc.), thereby significantly improving the encoding quality of the video and significantly reducing bandwidth and storage costs.

[0020]

[0037] Figure 1 shows the structure of an example of a video sequence 100 according to some embodiments of the present disclosure. The video sequence 100 can be live video or captured and archived video. The video 100 may be real video, computer-generated video (e.g., computer game video), or a combination thereof (e.g., real video with augmented reality effects). The video sequence 100 may be input from a video capture device (e.g., a camera), a video archive containing previously captured video (e.g., video files stored in a storage device), or a video feed interface for receiving video from a video content provider (e.g., a video broadcast transceiver).

[0021]

[0038] As shown in Figure 1, the video sequence 100 may include a series of pictures arranged in time along a timeline, including pictures 102, 104, 106, and 108. Pictures 102-106 are sequential, with more pictures between picture 106 and picture 108. In Figure 1, picture 102 is the I picture, and its reference picture is picture 102 itself. Picture 104 is the P picture, and its reference picture is picture 102, as indicated by the arrow. Picture 106 is the B picture, and its reference pictures are pictures 104 and 108, as indicated by the arrow. In some embodiments, the reference picture of a picture (e.g., picture 104) may not be immediately before or immediately after it. For example, the reference picture of picture 104 may be a picture preceding picture 102. It should be noted that the reference pictures 102-106 are merely examples, and this disclosure is not limited to the examples shown in Figure 1 of the examples of the reference pictures.

[0022]

[0039] Typically, a video codec does not encode or decode all pictures at once because such a task is computationally complex. Rather, a video codec can divide a picture into basic segments and encode or decode the picture segment by segment. In this disclosure, such basic segments are referred to as basic processing units ("BPUs"). For example, structure 110 in Figure 1 shows an example of the structure of a picture (e.g., any of pictures 102-108) in video sequence 100. In structure 110, the picture is divided into 4x4 basic processing units, the boundaries of which are indicated by dashed lines. In some embodiments, basic processing units may be referred to as "macroblocks" in some video encoding standards (e.g., the MPEG family, H.261, H.263, or H.264 / AVC) and as "encoded tree units" ("CTUs") in some other video encoding standards (e.g., H.265 / HEVC or H.266 / VVC). The basic processing unit can have a variable size within a picture, such as 128x128, 64x64, 32x32, 16x16, 4x8, 16x32, or any arbitrary shape and size of pixels. The size and shape of the basic processing unit can be selected for the picture based on a balance between coding efficiency and the level of detail to be maintained within the basic processing unit.

[0023]

[0040] A basic processing unit can be a logical unit that may contain various types of video data stored in computer memory (e.g., in a video frame buffer). For example, a basic processing unit of a color picture may include a luminance component (Y) representing achromatic luminance information, one or more chroma components (e.g., Cb and Cr) representing color information, and associated syntactic elements of the basic processing unit in which the lumina and chroma components may have the same size. In some video encoding standards (e.g., H.265 / HEVC or H.266 / VVC), the lumina and chroma components may be called a "coding tree block" ("CTB"). Any operation performed on a basic processing unit can be repeated on its lumina and chroma components, respectively.

[0024]

[0041] Video encoding involves multiple operational stages, examples of which are detailed in Figures 2A-2B and 3A-3B. For each stage, the size of the basic processing unit may still be too large to process and can therefore be further divided into segments referred to in this disclosure as “basic processing subunits.” In some embodiments, a basic processing subunit may be referred to as a “block” within some video encoding standards (e.g., the MPEG family, H.261, H.263, or H.264 / AVC) or as an “encoded unit” (“CU”) within other video encoding standards (e.g., H.265 / HEVC or H.266 / VVC). A basic processing subunit may have the same or smaller size as the basic processing unit. Like the basic processing unit, a basic processing subunit is a logical unit that may contain various types of video data (e.g., Y, Cb, Cr, and associated syntactic elements) stored in computer memory (e.g., in a video frame buffer). Any operation performed on the basic processing subunit can be repeated on its luma and chroma components, respectively. It should be noted that such divisions may be performed at further levels depending on the processing needs. It should also be noted that various stages can divide the basic processing unit using various methods.

[0025]

[0042] For example (one example is detailed in Figure 2B), during the mode determination stage, the encoder can determine which prediction mode (e.g., intra-picture prediction or inter-picture prediction) to use for a basic processing unit, and the basic processing unit may be too large to make such a decision. The encoder can divide the basic processing unit into multiple basic processing subunits (e.g., CUs in H.265 / HEVC or H.266 / VVC) and determine the type of prediction for each basic processing subunit.

[0026]

[0043] In another example (an example of which is detailed in Figure 2A), during the prediction phase, the encoder can perform prediction operations at the level of the basic processing subunit (e.g., CU). However, in some cases, the basic processing subunit may still be too large to process. The encoder can further divide the basic processing subunit into smaller segments (e.g., called "prediction blocks" or "PBs" in H.265 / HEVC or H.266 / VVC) and perform prediction operations at that level.

[0027]

[0044] In another example (an example of which is detailed in Figure 2A), during the conversion phase, the encoder can perform conversion operations on residual subunits (e.g., CUs). However, in some cases, the subunit may still be too large to process. The encoder can further divide the subunit into smaller segments (e.g., called "conversion blocks" or "TBs" in H.265 / HEVC or H.266 / VVC) and perform conversion operations at that level. It should be noted that the division method for the same subunit may differ between the prediction phase and the conversion phase. For example, in H.265 / HEVC or H.266 / VVC, the prediction blocks and conversion blocks of the same CU may have different sizes and numbers.

[0028]

[0045] In the structure 110 of Figure 1, the basic processing unit 112 is further divided into 3x3 basic processing subunits, with the boundaries indicated by dotted lines. Different basic processing units of the same picture can be divided into basic processing subunits in different ways.

[0029]

[0046] In some implementations, a picture can be divided into processing regions to provide parallel processing and error tolerance for video encoding and decoding, thereby ensuring that the encoding or decoding process does not depend on information from any other region of the picture. In other words, each region of the picture can be processed independently. This allows the codec to process different regions of the picture in parallel, thus increasing encoding efficiency. Furthermore, if data in a region is corrupted during processing or lost during network transmission, the codec can correctly encode or decode other regions of the same picture without relying on the corrupted or lost data, thus providing error tolerance. Some video encoding standards allow a picture to be divided into different types of regions. For example, H.265 / HEVC and H.266 / VVC offer two types of regions: "slice" and "tile". It should also be noted that various pictures in video sequence 100 may have various division methods for dividing the picture into regions.

[0030]

[0047] For example, in Figure 1, structure 110 is divided into three regions 114, 116, and 118, with their boundaries shown as solid lines within structure 110. Region 114 contains four basic processing units. Regions 116 and 118 each contain six basic processing units. It should be noted that the basic processing units, basic sub-units, and regions of structure 110 in Figure 1 are merely examples, and this disclosure does not limit its embodiments.

[0031]

[0048] Figure 2A shows a schematic diagram of an example of an encoding process 200A according to some embodiments of the present disclosure. The encoder can encode a video sequence 202 into a video bitstream 228 according to process 200A. Similar to video sequence 100 in Figure 1, video sequence 202 may contain a set of pictures (referred to as “original pictures”) arranged in chronological order. Similar to structure 110 in Figure 1, each original picture in video sequence 202 may be divided by the encoder into a basic processing unit, a basic processing subunit, or a processing area. In some embodiments, the encoder can execute process 200A at the level of a basic processing unit for each original picture in video sequence 202. For example, the encoder can execute process 200A in an iterative manner, and the encoder can encode a basic processing unit in a single iteration of process 200A. In some embodiments, the encoder can execute process 200A in parallel for each area of ​​the original picture in video sequence 202 (e.g., areas 114-118).

[0032]

[0049] In Figure 2A, the encoder can feed the basic processing unit of the original picture of the video sequence 202 (referred to as the "original BPU") to the prediction stage 204 to generate predicted data 206 and predicted BPU 208. The encoder can subtract the predicted BPU 208 from the original BPU to generate the residual BPU 210. The encoder can feed the residual BPU 210 to the conversion stage 212 and the quantization stage 214 to generate quantized conversion coefficients 216. The encoder can feed the predicted data 206 and quantized conversion coefficients 216 to the binary encoding stage 226 to generate the video bitstream 228. Components 202, 204, 206, 208, 210, 212, 214, 216, 226, and 228 can be referred to as the "forward path". During process 200A, the encoder can feed the quantized transformation coefficients 216 after the quantization stage 214 to the inverse quantization stage 218 and the inverse transformation stage 220 to generate the reconstructed residual BPU 222. The encoder can add the reconstructed residual BPU 222 to the predicted BPU 208 to generate the prediction criterion 224, which will be used in the prediction stage 204 of the next iteration of process 200A. Components 218, 220, 222, and 224 of process 200A can be called a “reconstruction path”. The reconstruction path can be used to ensure that both the encoder and the decoder use the same reference data for prediction.

[0033]

[0050] The encoder can iteratively perform process 200A to encode each original BPU of the original picture (in the forward path) and generate a predicted criterion 224 for encoding the next original BPU of the original picture (in the reconstruction path). After encoding all the original BPUs of the original picture, the encoder can proceed to encode the next picture in the video sequence 202.

[0034]

[0051] Referring to process 200A, the encoder may receive a video sequence 202 generated by a video acquisition device (e.g., a camera). As used herein, the term “receive” may mean receiving, inputting, acquiring, retrieving, obtaining, reading, accessing, or any action in any way to input data.

[0035]

[0052] In the prediction stage 204 of the current iteration, the encoder receives the original BPU and prediction criterion 224 and can perform a prediction operation to generate prediction data 206 and predicted BPU 208. The prediction criterion 224 may be generated from the reconstruction path of the previous iteration of process 200A. The purpose of the prediction stage 204 is to reduce information redundancy by extracting prediction data 206 that can be used to reconstruct the original BPU as predicted BPU 208 from the prediction data 206 and prediction criterion 224.

[0036]

[0053] Ideally, the predicted BPU208 can be identical to the original BPU. However, due to less-than-ideal prediction and reconstruction operations, the predicted BPU208 is generally slightly different from the original BPU. To record such differences, the encoder can generate the residual BPU210 by subtracting the predicted BPU208 from the original BPU after generating it. For example, the encoder can subtract the pixel values ​​(e.g., grayscale or RGB values) of the predicted BPU208 from the corresponding pixel values ​​of the original BPU. As a result of such subtraction between the corresponding pixels of the original BPU and the predicted BPU208, each pixel of the residual BPU210 may have a residual value. Compared to the original BPU, the predicted data 206 and residual BPU210 may have fewer bits, but they can be used to reconstruct the original BPU without significantly degrading quality.

[0037]

[0054] To further compress the residual BPU210, in transformation step 212, the encoder can reduce the spatial redundancy of the residual BPU210 by decomposing it into a set of two-dimensional "basis patterns," each basis pattern being associated with "transformation coefficients." The basis patterns can have the same size (e.g., the size of the residual BPU210). Each basis pattern can represent the variation frequency component (e.g., luminance variation frequency) of the residual BPU210. No basis pattern can be reconstructed from any combination (e.g., a linear combination) of any other basis pattern. In other words, such decomposition allows the variation of the residual BPU210 to be decomposed into the frequency domain. Such decomposition is analogous to the discrete Fourier transform of a function, the basis patterns are analogous to the basis functions (e.g., trigonometric functions) of the discrete Fourier transform, and the transformation coefficients are analogous to the coefficients associated with the basis functions.

[0038]

[0055] Various transformation algorithms can use various basis patterns. For example, various transformation algorithms can be used in transformation stage 212, such as discrete cosine transform and discrete sine transform. The transformation in transformation stage 212 is reversible. That is, the encoder can reconstruct the residual BPU 210 by the inverse operation of the transformation (called the "inverse transform"). For example, to reconstruct the pixels of the residual BPU 210, the inverse transform may be to multiply the values ​​of the corresponding pixels in the basis pattern by the respective coefficients in question, and then add the products to obtain a weighted sum. In the video coding standard, both the encoder and decoder can use the same transformation algorithm (and therefore the same basis pattern). Therefore, the encoder can record only the transformation coefficients from which the decoder can reconstruct the residual BPU 210 without receiving the basis pattern from the encoder. The transformation coefficients may have fewer bits than the residual BPU 210, but these transformation coefficients can be used to reconstruct the residual BPU 210 without significantly degrading the quality. Thus, the residual BPU 210 is further compressed.

[0039]

[0056] The encoder can further compress the conversion coefficients in the quantization stage 214. In the conversion process, various basis patterns can represent various fluctuation frequencies (e.g., luminance fluctuation frequencies). Since the human eye is generally good at recognizing low-frequency fluctuations, the encoder can ignore high-frequency fluctuation information without causing significant quality degradation during decoding. For example, in the quantization stage 214, the encoder can generate quantized conversion coefficients 216 by dividing each conversion coefficient by an integer value (called a "quantization parameter") and rounding the quotient to its nearest neighbor. After this operation, some conversion coefficients of the high-frequency basis pattern can be converted to zero, and the conversion coefficients of the low-frequency basis pattern can be converted to smaller integers. The encoder can ignore the zero-value quantized conversion coefficients 216, thereby further compressing the conversion coefficients. The quantization process is also reversible, and the quantized conversion coefficients 216 can be reconstructed into conversion coefficients by the inverse operation of quantization (called "inverse quantization").

[0040]

[0057] Since the encoder ignores the remainder of such division in rounding operations, the quantization stage 214 can be irreversible. Typically, the quantization stage 214 can contribute the greatest information loss within process 200A. The greater the information loss, the fewer bits the quantized conversion coefficients 216 may require. To obtain various levels of information loss, the encoder can use various values ​​of the quantization parameters or any other parameters of the quantization process.

[0041]

[0058] In the binary encoding stage 226, the encoder can encode the predicted data 206 and the quantized conversion coefficients 216 using a binary encoding technique such as entropi 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 predicted data 206 and the quantized conversion coefficients 216, the encoder can encode other information in the binary encoding stage 226, such as the prediction mode used in the prediction stage 204, the parameters of the prediction operation, the type of transformation in the transformation stage 212, the parameters of the quantization process (e.g., quantization parameters), and the encoder control parameters (e.g., bitrate control parameters). The encoder can use the output data from the binary encoding stage 226 to generate a video bitstream 228. In some embodiments, the video bitstream 228 can be further packetized for network transmission.

[0042]

[0059] Referencing the reconstruction path of process 200A, in the inverse quantization step 218, the encoder can perform inverse quantization on the quantized transformation coefficients 216 to generate reconstructed transformation coefficients. In the inverse transformation step 220, the encoder can generate reconstructed residual BPU 222 based on the reconstructed transformation coefficients. The encoder can add the reconstructed residual BPU 222 to the predicted BPU 208 to generate a prediction criterion 224 to be used in the next iteration of process 200A.

[0043]

[0060] It should be noted that other variations of process 200A can be used to encode the video sequence 202. In some embodiments, the encoder may perform the steps of process 200A in a different order. In some embodiments, one or more steps of process 200A may be combined into a single step. In some embodiments, a single step of process 200A may be divided into multiple steps. For example, the conversion step 212 and the quantization step 214 may be combined into a single step. In some embodiments, process 200A may include additional steps. In some embodiments, process 200A may omit one or more steps in Figure 2A.

[0044]

[0061] Figure 2B shows a schematic diagram of another example 200B of the encoding process according to some embodiments of the present disclosure. Process 200B may be modified from process 200A. For example, process 200B may be used by an encoder compliant with a hybrid video encoding standard (e.g., the H.26x series). Compared with process 200A, the forward path of process 200B further includes a mode determination stage 230 and divides the prediction stage 204 into a spatial prediction stage 2042 and a temporal prediction stage 2044. The reconstruction path of process 200B additionally includes a loop filter stage 232 and a buffer 234.

[0045]

[0062] Generally, prediction techniques can be classified into two types: spatial prediction and temporal prediction. Spatial prediction (e.g., intra-picture prediction or "intra-prediction") can use one or more already coded pixels of neighboring BPUs within the same picture to predict the current BPU. In other words, the prediction criterion 224 in spatial prediction may include neighboring BPUs. Spatial prediction can reduce the inherent spatial redundancy of a picture. Temporal prediction (e.g., inter-picture prediction or "inter-prediction") can use one or more already coded regions of a picture to predict the current BPU. In other words, the prediction criterion 224 in temporal prediction may include coded pictures. Temporal prediction can reduce the inherent temporal redundancy of a picture.

[0046]

[0063] Referencing process 200B, in the forward path, the encoder performs prediction operations in spatial prediction stage 2042 and temporal prediction stage 2044. For example, in spatial prediction stage 2042, the encoder may perform intra-prediction. With respect to the original BPU of the picture being encoded, the prediction criterion 224 may include one or more neighboring BPUs within the same picture that are encoded (in the forward path) and reconstructed (in the reconstruction path). The encoder may generate predicted BPUs 208 by extrapolating neighboring BPUs. Extrapolation techniques may include, for example, linear extrapolation or linear interpolation, polynomial extrapolation or polynomial interpolation, etc. In some embodiments, the encoder may perform pixel-level extrapolation, for example, by extrapolating the values ​​of the corresponding pixels for each pixel of the predicted BPUs 208. The adjacent BPUs used for extrapolation may be located relative to the original BPU from various directions, such as vertically (e.g., above the original BPU), horizontally (e.g., to the left of the original BPU), diagonally (e.g., below left, below right, above left, or above right of the original BPU), or in any direction specified within the video encoding standard used. In intra-prediction, the prediction data 206 may include, for example, the location (e.g., coordinates) of the adjacent BPUs used, the size of the adjacent BPUs used, the extrapolation parameters, and the orientation of the adjacent BPUs used relative to the original BPU.

[0047]

[0064] In another example, the encoder can perform interpretation in the temporal prediction stage 2044. With respect to the original BPU of the current picture, the prediction criterion 224 may include one or more pictures (referred to as "reference pictures") that have been encoded (in the forward path) and reconstructed (in the reconstruction path). In some embodiments, the reference pictures may be encoded and reconstructed for each BPU. For example, the encoder can generate a reconstructed BPU by adding the reconstructed residual BPU 222 to the predicted BPU 208. Once all reconstructed BPUs for the same picture have been generated, the encoder can generate a reconstructed picture as a reference picture. The encoder can perform a "motion estimation" operation to search for a matching region within the range of the reference picture (referred to as the "search window"). The position of the search window in the reference picture can be determined based on the position of the original BPU in the current picture. For example, the search window can be centered in the reference picture at a position having the same coordinates as the original BPU in the current picture and can be extended over a predetermined distance. When the encoder identifies a region similar to the original BPU within the search window (e.g., by using a PEL recursive algorithm, block matching algorithm, etc.), the encoder can determine that region as a match region. The match region may have different dimensions from the original BPU (e.g., smaller, equal to, larger, or different shape). Since the reference picture and the current picture are separated in time on the timeline (e.g., as shown in Figure 1), the match region can be considered to "move" to the original BPU's position over time. The encoder can record the direction and distance of such movement as a "motion vector". If multiple reference pictures are used (e.g., picture 106 in Figure 1), the encoder can search for a match region for each reference picture and determine its associated motion vector. In some embodiments, the encoder can assign weights to the pixel values ​​of the match region for each matching reference picture.

[0048]

[0065] Motion estimation can be used to identify various types of motion, such as translation, rotation, and scaling. In interpretation, the prediction data 206 may include, for example, the location of the matching region (e.g., coordinates), motion vectors associated with the matching region, the number of reference pictures, and weights associated with the reference pictures.

[0049]

[0066] To generate a predicted BPU 208, the encoder can perform a “motion compensation” operation. Motion compensation can be used to reconstruct the predicted BPU 208 based on prediction data 206 (e.g., motion vectors) and prediction criteria 224. For example, the encoder can move the matching region of a reference picture according to the motion vector, within which the encoder can predict the original BPU of the current picture. If multiple reference pictures are used (e.g., picture 106 in Figure 1), the encoder can move the matching region of each reference picture according to the individual motion vectors and average the pixel values ​​of the matching region. In some embodiments, if the encoder assigns weights to the pixel values ​​of the matching region of each matching reference picture, the encoder can calculate a weighted sum of the pixel values ​​of the moved matching region.

[0050]

[0067] In some embodiments, the inter-prediction may be unidirectional or bidirectional. Unidirectional inter-prediction can use one or more reference pictures that are in the same temporal direction relative to the current picture. For example, picture 104 in Figure 1 is a unidirectional inter-prediction picture in which the reference picture (i.e., picture 102) precedes picture 104. Bidirectional inter-prediction can use one or more reference pictures that are in both temporal directions relative to the current picture. For example, picture 106 in Figure 1 is a bidirectional inter-prediction picture in which the reference pictures (i.e., pictures 104 and 108) are in both temporal directions relative to picture 104.

[0051]

[0068] Continuing to refer to the forward path of process 200B, after the spatial prediction stage 2042 and the temporal prediction stage 2044, in the mode determination stage 230, the encoder may select a prediction mode (e.g., one of intra-prediction or inter-prediction) for the current iteration of process 200B. For example, the encoder may perform a rate distortion optimization technique, in which the encoder may select a prediction mode to minimize the value of the cost function depending on the bit rate of the candidate prediction mode and the distortion of the reconstructed reference picture under the candidate prediction mode. Depending on the selected prediction mode, the encoder may generate the corresponding predicted BPU 208 and predicted data 206.

[0052]

[0069] In the reconstruction path of process 200B, if intra-prediction mode is selected in the forward path, after generating prediction criterion 224 (e.g., the current BPU being encoded and reconstructed within the current picture), the encoder can directly feed prediction criterion 224 to spatial prediction stage 2042 for later use (e.g., to extrapolate the next BPU of the current picture). If inter-prediction mode is selected in the forward path, after generating prediction criterion 224 (e.g., the current picture with all BPUs encoded and reconstructed), the encoder can feed prediction criterion 224 to loop filtering stage 232, where the encoder can apply loop filtering to prediction criterion 224 to reduce or eliminate distortions caused by inter-prediction (e.g., blocking artifacts). Various loop filtering techniques can be applied in loop filtering stage 232, such as deblocking, sample-adaptive offset, and adaptive loop filtering. Loop-filtered reference pictures can be stored in buffer 234 (or “decoded picture buffer”) for later use (for example, as interpretation reference pictures for future pictures in video sequence 202). The encoder may store one or more reference pictures in buffer 234 for use in the temporal prediction stage 2044. In some embodiments, the encoder may encode loop filter parameters (e.g., loop filter strength) along with quantized transformation coefficients 216, prediction data 206, and other information in the binary encoding stage 226.

[0053]

[0070] Figure 3A shows a schematic diagram of an example of a decoding process 300A according to some embodiments of the present disclosure. Process 300A may be a decompression process corresponding to the compression process 200A in Figure 2A. In some embodiments, process 300A may be similar to the reconstruction path of process 200A. The decoder can decode the video bitstream 228 into a video stream 304 according to process 300A. The video stream 304 may be very similar to the video sequence 202. However, due to information loss in the compression and decompression processes (e.g., the quantization stage 214 in Figures 2A-2B), the video stream 304 is generally not identical to the video sequence 202. Similar to processes 200A and 200B in Figures 2A-2B, the decoder can execute process 300A at the level of basic processing units (BPUs) for each picture encoded in the video bitstream 228. For example, the decoder can execute process 300A in an iterative manner, and the decoder can decode a basic processing unit in a single iteration of process 300A. In some embodiments, the decoder can execute process 300A in parallel for each region of the picture (e.g., regions 114-118) that is encoded within the video bitstream 228.

[0054]

[0071] In Figure 3A, the decoder can feed a portion of the video bitstream 228 associated with the basic processing unit of the encoded picture (referred to as the "encoded BPU") to the binary decoding stage 302. In the binary decoding stage 302, the decoder can decode that portion into predicted data 206 and quantized transformation coefficients 216. The decoder can feed the quantized transformation coefficients 216 to the inverse quantization stage 218 and the inverse transformation stage 220 to generate the reconstructed residual BPU 222. The decoder can feed the predicted data 206 to the prediction stage 204 to generate the predicted BPU 208. The decoder can add the reconstructed residual BPU 222 to the predicted BPU 208 to generate the predicted criterion 224. In some embodiments, the predicted criterion 224 may be stored in a buffer (e.g., a decoded picture buffer in computer memory). The decoder can feed the predicted criteria 224 to the prediction stage 204 for performing a prediction operation within the next iteration of process 300A.

[0055]

[0072] The decoder can iteratively perform process 300A to decode each encoded BPU of the encoded picture and generate a predicted criterion 224 for encoding the next encoded BPU of the encoded picture. After decoding all encoded BPUs of the encoded picture, the decoder can output the picture to the video stream 304 for display and proceed to decode the next encoded picture in the video bitstream 228.

[0056]

[0073] In the binary decoding stage 302, the decoder can perform the inverse operation of the binary encoding technique used by the encoder (e.g., entropi encoding, variable-length encoding, arithmetic encoding, Huffman encoding, context-adaptive binary arithmetic encoding, or any other arbitrary lossless compression algorithm). In some embodiments, in addition to the predicted data 206 and quantized conversion coefficients 216, the decoder can decode other information in the binary decoding stage 302, such as the prediction mode, parameters of the prediction operation, type of conversion, parameters of the quantization process (e.g., quantization parameters), and encoder control parameters (e.g., bitrate control parameters). In some embodiments, if the video bitstream 228 is transmitted in packets over the network, the decoder can depacketize the video bitstream 228 before feeding it to the binary decoding stage 302.

[0057]

[0074] Figure 3B shows a schematic diagram of another example 300B of the decoding process according to some embodiments of the present disclosure. Process 300B may be modified from process 300A. For example, process 300B may be used by a decoder compliant with a hybrid video encoding standard (e.g., the H.26x series). Compared to process 300A, process 300B further 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.

[0058]

[0075] In process 300B, with respect to the encoded basic processing unit ("current BPU") of the encoded picture being decoded ("current picture"), the prediction data 206 decoded by the decoder from binary decoding stage 302 may contain various types of data depending on which prediction mode was used by the encoder to encode the current BPU. For example, if intra-prediction was used by the encoder to encode the current BPU, the prediction data 206 may include prediction mode indicators (e.g., flag values) that show the intra-prediction, parameters of the intra-prediction operation, etc. Parameters of the intra-prediction operation may include, for example, the location (e.g., coordinates) of one or more adjacent BPUs used as a reference, the size of the adjacent BPUs, extrapolation parameters, the orientation of the adjacent BPU relative to the original BPU, etc. In another example, if inter-prediction was used by the encoder to encode the current BPU, the prediction data 206 may include prediction mode indicators (e.g., flag values) that show the inter-prediction, parameters of the inter-prediction operation, etc. The parameters for the interface prediction operation may include, for example, the number of reference pictures associated with the current BPU, the weights associated with each reference picture, the location (e.g., coordinates) of one or more matching regions within each reference picture, and one or more motion vectors associated with each matching region.

[0059]

[0076] Based on the prediction mode indicator, the decoder can decide whether to perform a spatial prediction (e.g., intra-prediction) in the spatial prediction stage 2042 or a temporal prediction (e.g., inter-prediction) in the temporal prediction stage 2044. Details of the execution of such spatial or temporal predictions are shown in Figure 2B and will not be repeated below. After performing such spatial or temporal predictions, the decoder can generate a predicted BPU 208. As shown in Figure 3A, the decoder can add the predicted BPU 208 and the reconstructed residual BPU 222 to generate a prediction criterion 224.

[0060]

[0077] In process 300B, the decoder can feed the predicted criterion 224 to the spatial prediction stage 2042 or the temporal prediction stage 2044 for performing a prediction operation within the next iteration of process 300B. For example, if the current BPU is decoded using intra-prediction in spatial prediction stage 2042, after generating the prediction criterion 224 (e.g., the decoded current BPU), the decoder can directly feed the prediction criterion 224 to spatial prediction stage 2042 for later use (e.g., to extrapolate the next BPU of the current picture). If the current BPU is decoded using inter-prediction in temporal prediction stage 2044, after generating the prediction criterion 224 (e.g., the reference picture from which all BPUs have been decoded), the encoder can feed the prediction criterion 224 to the loop filter stage 232 to reduce or eliminate distortion (e.g., blocking artifacts). The decoder can apply a loop filter to the prediction criterion 224 in the manner shown in Figure 2B. Loop-filtered reference pictures can be stored in buffer 234 (e.g., a decoded picture buffer in computer memory) for later use (e.g., for use as an inter-prediction reference picture for future encoded pictures of the video bitstream 228). The decoder can store one or more reference pictures in buffer 234 for use in the temporal prediction stage 2044. In some embodiments, if the prediction mode indicator in prediction data 206 indicates that inter-prediction was used to encode the current BPU, the prediction data may further include loop filter parameters (e.g., loop filter strength).

[0061]

[0078] Figure 4 is a block diagram of an example of a device 400 for encoding or decoding video according to some embodiments of the present disclosure. As shown in Figure 4, the device 400 may include a processor 402. When the processor 402 executes instructions described herein, the device 400 can become a dedicated machine for encoding or decoding video. The processor 402 may be any type of circuit capable of manipulating or processing information. For example, the processor 402 may include any combination of any number of central processing units ("CPUs"), graphics processing units ("GPUs"), neural processing units ("NPUs"), microcontroller units ("MCUs"), optical processors, programmable logic controllers, microcontrollers, microprocessors, digital signal processors, IP (intellectual property) cores, programmable logic arrays (PLAs), programmable array logic (PALs), general-purpose array logic (GALs), composite programmable logic units (CPLDs), rewritable gate arrays (FPGAs), systems on a chip (SoCs), application-specific integrated circuits (ASICs), and the like. In some embodiments, the processor 402 may be a set of processors grouped together as a single logical component. For example, as shown in Figure 4, the processor 402 may include multiple processors, including processor 402a, processor 402b, and processor 402n.

[0062]

[0079] The device 400 may also include a memory 404 configured to store data (e.g., a set of instructions, computer code, intermediate data, etc.). For example, as shown in Figure 4, the stored data may include program instructions (e.g., program instructions for implementing stages within processes 200A, 200B, 300A, or 300B) and processing data (e.g., video sequence 202, video bitstream 228, or video stream 304). The processor 402 can access the program instructions and processing data (e.g., via a bus 410) and execute the program instructions to perform operations or processing on the processing data. The memory 404 may include a high-speed random-access storage device or a non-volatile storage device. In some embodiments, the memory 404 may include any combination of any number of random-access memories (RAM), read-only memories (ROM), optical disks, magnetic disks, hard drives, solid-state drives, flash drives, security digital (SD) cards, memory sticks, CompactFlash® (CF) cards, etc. Memory 404 can also be a group of memories (not shown in Figure 4) that are grouped together as a single logical component.

[0063]

[0080] Buses 410, such as an internal bus (e.g., CPU memory bus) or an external bus (e.g., a universal serial bus port, a peripheral component interconnection express port), may be communication devices that transfer data between components within the device 400.

[0064]

[0081] To simplify the explanation without causing ambiguity, the processor 402 and other data processing circuits are collectively referred to as "data processing circuits" in this disclosure. Data processing circuits can be implemented entirely as hardware, or as a combination of software, hardware, or firmware. In addition, data processing circuits can be a single, independent module, or can be fully or partially combined with any other component of the device 400.

[0065]

[0082] The device 400 may further include a network interface 406 for providing wired or wireless communication with a network (e.g., the Internet, an intranet, a local area network, a mobile communication network, etc.). In some embodiments, the network interface 406 may include any combination of any number of network interface controllers (NICs), radio frequency (RF) modules, transponders, transceivers, modems, routers, gateways, wired network adapters, wireless network adapters, Bluetooth adapters, infrared adapters, near-field communication ("NFC") adapters, cellular network chips, etc.

[0066]

[0083] In some embodiments, the device 400 may optionally further include a peripheral device interface 408 for providing connectivity to one or more peripheral devices. As shown in Figure 4, peripheral devices may include, but are not limited to, a cursor control device (e.g., mouse, touchpad, or touchscreen), a keyboard, a display (e.g., a cathode ray tube display, a liquid crystal display, or a light-emitting diode display), a video input device (e.g., a camera or input interface coupled to a video archive), and the like.

[0067]

[0084] It should be noted that a video codec (for example, a codec that runs processes 200A, 200B, 300A, or 300B) can be implemented as any combination of any software or hardware modules within device 400. For example, some or all stages of processes 200A, 200B, 300A, or 300B may be implemented as one or more software modules of device 400, such as program instructions that can be loaded into memory 404. In another example, some or all stages of processes 200A, 200B, 300A, or 300B may be implemented as one or more hardware modules of device 400, such as dedicated data processing circuits (e.g., FPGA, ASIC, NPU, etc.).

[0068]

[0085] Figure 5 shows a schematic diagram of an exemplary chroma-scaling lumamapping (LMCS) process 500 according to some embodiments of the present disclosure. For example, process 500 may be used by a decoder compliant with a hybrid video encoding standard (e.g., the H.26x series). LMCS is a new processing block applied before the loop filter 232 in Figure 2B. LMCS may also be called a reshaper.

[0069]

[0086] The LMCS process 500 may include in-loop mapping of luma component values ​​and luma-dependent chroma residual scaling of chroma components based on an adaptive piecewise linear model.

[0070]

[0087] As shown in Figure 5, the in-loop mapping of luma component values ​​based on an adaptive piecewise linear model may include a forward mapping step 518 and an inverse mapping step 508. The luma-dependent chroma residual scaling of the chroma component may include chroma scaling 520.

[0071]

[0088] Sample values ​​before mapping or after reverse mapping can be called samples in the original region, and sample values ​​after mapping and before reverse mapping can be called samples in the mapped region. When LMCS is enabled, some stages within process 500 can be performed in the mapped region rather than the original region. It will be understood that the forward mapping stage 518 and reverse mapping stage 508 can be enabled / disabled at the sequence level using the SPS flag.

[0072]

[0089] As shown in Figure 5, Q -1 &T -1 Stages 504, 506, and 508 are performed within the map area. For example, Q -1 &T -1 Step 504 may include inverse quantization and inverse transformation, reconstruction 506 may include addition of Luma prediction and Luma residual, and intra prediction 508 may include Luma intra prediction.

[0073]

[0090] The loop filter 510, motion compensation stages 516 and 530, intra-prediction stage 528, reconstruction stage 522, and decoded picture buffers (DPBs) 512 and 526 are performed within the original (i.e., unmapped) region. In some embodiments, the loop filter 510 may include deblocking, adaptive loop filter (ALF), and sample adaptive offset (SAO), the reconstruction stage 522 may include summing of chroma prediction and chroma residual, and the DPBs 512 and 526 may store the decoded picture as a reference picture.

[0074]

[0091] In some embodiments, luma mapping using a piecewise linear model can be applied.

[0075]

[0092] Luma component in-loop mapping can improve compression efficiency by adjusting the signal statistics of the input video through the redistribution of codewords across the dynamic range. Luma mapping can be performed using the forward mapping function "FwdMap" and its corresponding inverse mapping function "InvMap". The "FwdMap" function is signaled using a piecewise linear model with 16 equal divisions. The "InvMap" function does not need to be signaled and is instead derived from the "FwdMap" function.

[0076]

[0093] The signaling for the piecewise linear model is shown in Table 1 of Figure 6 and Table 2 of Figure 7. Table 1 of Figure 6 shows the tile group header syntax structure. As shown in Figure 6, a reshaper model parameter presence flag is signaled to indicate whether a Luma Mapping model exists in the current tile group. If a Luma Mapping model exists in the current tile group, the corresponding piecewise linear model parameters can be signaled in tile_group_reshaper_model() using the syntax elements shown in Table 2 of Figure 7. The piecewise linear model divides the dynamic range of the input signal into 16 equal divisions. For each of the 16 equal divisions, the linear mapping parameters for the division are represented using the number of codewords assigned to the division. Taking a 10-bit input as an example, each of the 16 divisions may have 64 codewords assigned to it by default. The number of codewords signaled can be used to calculate the scale factor and adjust the mapping function accordingly for that division. Table 2 in Figure 7 also comprehensively defines the minimum index "reshaper_model_min_bin_idx" and the maximum index "reshaper_model_max_bin_idx" for which the number of codewords is signaled. If a partition index is smaller than reshaper_model_min_bin_idx or larger than reshaper_model_max_bin_idx, the number of codewords for that partition is not signaled and is inferred to be zero (i.e., no codewords are assigned to that partition and mapping / scaling is not applied).

[0077]

[0094] After tile_group_reshaper_model() is signaled, another reshaper enable flag, "tile_group_reshaper_enable_flag", is signaled at the tile group header level to indicate whether the LMCS process shown in Figure 8 is applied to the current tile group. If the reshaper is enabled for the current tile group and the current tile group does not use dual-tree partitioning, a further chroma scaling enable flag is signaled to indicate whether chroma scaling is enabled for the current tile group. Dual-tree partitioning can also be called chroma-separated trees.

[0078]

[0095] The piecewise linear model can be constructed as follows, based on the signaled syntactic elements in Table 2 of Figure 7. Each i-th piece of the "FwdMap" piecewise linear model, i=0,1,...,15, is defined by two input pivot points, InputPivot[] and two output (mapped) pivot points, MappedPivot[]. InputPivot[] and MappedPivot[] are calculated based on the signaled syntax as follows (assuming a bit depth of 10 bits for the input video without loss of generality): 1) OrgCW=64 2) For i=0:16, InputPivot[i]=i*OrgCW 3)i=reshaper_model_min_bin_idx: in reshaper_model_max_bin_idx SignaledCW[i]=OrgCW+(1￢2*reshape_model_bin_delta_sign_CW[i])*reshape_model_bin_delta_abs_CW[i]; 4) For i=0:16, MappedPivot[i] is calculated as follows: MappedPivot[0] = 0; (i=0; i<16; i++) MappedPivot[i+1]=MappedPivot[i]+SignaledCW[i]

[0079]

[0096] The inverse mapping function "InvMap" can also be defined by InputPivot[] and MappedPivot[]. Unlike "FwdMap", in the "InvMap" piecewise linear model, two input pivot points for 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 inputs of "FwdMap" are divided into equal pieces, but there is no guarantee that the inputs of "InvMap" will be divided into equal pieces.

[0080]

[0097] As shown in Figure 5, motion compensation prediction can be performed within the map area in the intercoding block. In other words, after motion compensation prediction 516, Y is calculated based on the reference signal within the DPB. pred The "FwdMap" function 518 can be applied to calculate and map the Luma prediction blocks in the original region to the map region (Y' pred =FwdMap(Y pred )). In intracoded blocks, the "FwdMap" function is not applied because the reference samples used in the intra prediction are already in the map region. After reconstructed block 506, Y r It is possible to calculate this. The "InvMap" function 508 can be applied to convert the reconstructed luma values ​​in the map region back to the reconstructed luma values ​​in the original region.

number

[0081]

[0098] The luma mapping process (forward or inverse mapping) can be implemented using a look-up table (LUT) or using on-the-spot calculations. When using an LUT, tables of "FwdMapLUT[]" and "InvMapLUT[]" can be pre-calculated and pre-stored for use at the tile group level, and forward mapping and inverse mapping can be simply implemented as FwdMap(Y pred ) = FwdMapLUT[Y pred , and InvMap(Y r ) = InvMapLUT[Y r respectively. Alternatively, on-the-spot calculations can be used. Taking the forward mapping function "FwdMap" as an example. To determine the section to which a luma sample belongs, the sample value can be right-shifted by 6 bits (assuming a 10-bit video, corresponding to 16 equal sections) to obtain a section index. Then the linear model parameters of that section can be obtained and applied on the spot to calculate the mapped luma value. The FwdMap function is evaluated as follows: Y’pred = FwdMap(Y pred ) = ((b2 - b1) / (a2 - a1))*(Y pred - a1) + b1 where "i" is the section index, a1 is InputPivot[i], a2 is InputPivot[i + 1], b1 is MappedPivot[i], and b2 is MappedPivot[i + 1].

[0082]

[0099] The "InvMap" function can be calculated on the spot in a similar way, except that a conditional check must be applied instead of a simple right bit shift when finding the section to which the sample value belongs, as the sections within the mapped area are not guaranteed to be of equal size.

[0083]

[0100] In some embodiments, luma-dependent chroma residual scaling can be performed.

[0084]

[0101] Chroma residual scaling is designed to compensate for the interaction between a luma signal and its corresponding chroma signal. Whether chroma residual scaling is enabled is also signaled at the tile group level. As shown in Table 1 of Figure 6, an additional flag (e.g., tile_group_reshaper_chroma_residual_scale_flag) is signaled to indicate whether luma-dependent chroma residual scaling is enabled when luma mapping is enabled and dual-tree splitting is not applied to the current tile group. Luma-dependent chroma residual scaling is automatically disabled when luma mapping is not used or when dual-tree splitting is used within the current tile group. Furthermore, luma-dependent chroma residual scaling may be disabled for chroma blocks whose region is 4 or less.

[0085]

[0102] Chroma residual scaling (for both intracoded and intercoded blocks) depends on the mean value of the corresponding chroma prediction block. The avgY' as the mean of the chroma prediction blocks can be calculated as follows:

number

[0086]

[0103] C ScaleInv Calculate the value of using the following steps: 1) Index Y of the piecewise linear model to which avgY' belongs Idx Find it based on the InvMap function. 2) C ScaleInv =cScaleInv[Y Idx The following condition holds, where cScaleInv[] is a pre-calculated LUT of 16 segments.

[0087]

[0104] In the current LMCS method in VTM4, the pre-calculated LUT cScaleInv[i] (where i is in the range of 0 to 15) is derived based on the values ​​of the 64-entry static LUT ChromaResidualScaleLut and SignaledCW[i] as follows: ChromaResidualScaleLut

[64] ={16384, 16384, 16384, 16384, 16384, 16384, 16384, 8192, 8192, 8192, 8192, 5461, 5461, 5461, 5461, 4096, 4096, 4096, 4096, 3277, 3277, 3277, 3277, 2731, 2731, 2731, 2731, 2341, 2341, 2341, 2048, 2048, 2048, 1820, 1820, 1820, 1638, 1638, 1638, 1638, 1489, 1489, 1489, 1489, 1365, 1365, 1365, 1365, 1260, 1260, 1260, 1260, 1170, 1170, 1170, 1170, 1092, 1092, 1092, 1092, 1024, 1024, 1024, 1024}; shiftC=11 -(SignaledCW[i]==0) is true, cScaleInv[i]=(1< <shiftC) -otherwise cScaleInv[i]=ChromaResidualScaleLut[(SignaledCW[i]>>1)-1]

[0088]

[0105] The static table ChromaResidualScaleLut[] contains 64 entries, and SignaledCW[] is in the range [0,128] (assuming a 10-bit input). Therefore, division by 2 (e.g., right shift by 1) is used to construct the cScaleInv[] of the chroma scale factor LUT. The cScaleInv[] of the chroma scale factor LUT can contain multiple chroma scale factors. The cScaleInv[] of the LUT is constructed at the tile group level.

[0089]

[0106] If the current block is coded using intra, CIIP, or intrablock copy (also known as IBC, current picture reference, or CPR) mode, avgY' is calculated as the average of the intra, CIIP, or IBC predicted luma values. Otherwise, avgY' is the forward-mapped intra-predicted luma value (i.e., Y' in Figure 5). pred It is calculated as the average of ). Unlike luma mapping, which is performed based on samples, C ScaleInv This is a constant value for all chroma blocks. C ScaleInv Apply chroma residual scaling to the decoder as follows:

number

[0090]

[0107] however

number

[0091]

[0108] In some embodiments, dual-tree partitioning may be performed.

[0092]

[0109] In VVC Draft 4, the coding tree scheme supports the ability for luma and chroma to have separate block tree partitions. This is also called dual-tree partitioning. Signaling for dual-tree partitioning is shown in Table 3 of Figure 8 and Table 4 of Figure 9. When the sequence level control flag "qtbtt_dual_tree_intra_flag", which is signaled within the SPS, is turned on and the current tile group is intra-coded, block partitioning information can be signaled separately, first for luma and then for chroma. Dual-tree partitioning is not permitted for inter-coded tile groups (P and B tile groups). When separate block tree modes are applied, as shown in Table 4 of Figure 9, the luma coding tree block (CTB) is partitioned into CUs by one coding tree structure, and the chroma CTB is partitioned into chroma CUs by another coding tree structure.

[0093]

[0110] If lumens and chromians are allowed to have different partitions, problems can arise with encoding tools that have dependencies between various color components. For example, in LMCS, the average value of the corresponding lumens block is used to find the scale factor applied to the current block. If dual trees are used, this can lead to latency across the entire CTU. For example, if the lumens block of a CTU is partitioned vertically once and the chromens block of a CTU is partitioned horizontally once, both lumens block of the CTU are decoded before the first chromens block of the CTU is decodeable (therefore the average value needed to calculate the chroma scale factor can be calculated). In VVC, a CTU can be as large as 128x128 in units of lumens samples. Such high latency can be a significant problem for the pipeline design of hardware decoders. Therefore, VVC Draft 4 may prohibit the combination of dual-tree partitioning and lumens-dependent chroma scaling. If dual-tree partitioning is enabled for the current tile group, chroma scaling can be forcibly turned off. It should be noted that the lumens mapping portion of LMCS only affects the lumens component and does not have the problem of dependencies across color components, so it is still permitted in dual-tree cases. Another example of a coding tool that relies on dependencies between color components to achieve better coding efficiency is called the Cross-Component Linear Model (CCLM).

[0094]

[0111] Therefore, the derivation of the cScaleInv[] of the tile group-level chroma scale factor LUT cannot be easily extended. The derivation process currently relies on a constant chroma LUT, ChromaResidualScaleLut, which has 64 entries. For a 10-bit image with 16 divisions, an additional step of division by 2 must be applied. If the number of divisions changes, for example, if 8 divisions are used instead of 16, the derivation process must be modified to apply division by 4 instead of division by 2. This additional step not only causes a loss of precision but is also unsophisticated and unnecessary.

[0095]

[0112] Furthermore, the current chromatic block partition index Y is used to obtain the chromatic scale factor. Idx To calculate this, the average of all luma blocks can be used. This is undesirable and usually unnecessary. Consider a maximum CTU size of 128x128. In this case, the average luma value is calculated based on 16384 (128x128) luma samples, and such a calculation is complex. Furthermore, if a 128x128 luma block division is selected by the encoder, that block is likely to contain homogeneous content. Therefore, a subset of luma samples within a block may be sufficient to calculate the luma average.

[0096]

[0113] In dual-tree partitioning, chroma scaling may be turned off to avoid potential pipeline issues in hardware decoders. However, this dependency can be avoided by using explicit signaling to indicate the applied chroma scaling factor instead of using corresponding chroma samples to derive the applied chroma scaling factor. Enabling chroma scaling within intra-coded tile groups can further improve coding efficiency.

[0097]

[0114] The signaling of piecewise linear parameters can be further improved. Currently, a delta codeword value is signaled for each of the 16 divisions. Often, it is observed that only a limited number of different codewords are used for these 16 divisions. Therefore, the signaling overhead can be further reduced.

[0098]

[0115] Embodiments of this disclosure provide a method for processing video content by removing a chroma scaling LUT.

[0099]

[0116] As described above, it may be difficult to expand the 64-entry chroma LUT, which can be problematic when other partitioned linear models are used (e.g., 8-partition, 4-partition, 64-partition, etc.). To achieve the same coding efficiency, such expansion is unnecessary because the chroma scale factor can be set to the same as the corresponding luma scale factor of the partition. In some embodiments of the present disclosure, the chroma scale factor (chroma_scaling) can be determined based on the partition index "Y Idx " of the current chroma block as follows. · When Y Idx >reshaper_model_max_bin_idx, Y Idx <reshaper_model_min_bin_idx or SignaledCW[Y Idx =0 holds, set chroma_scaling to the default and chroma_scaling = 1.0. · Otherwise, set chroma_scaling to SignaledCW[Y Idx / OrgCW.

[0100]

[0117] When chroma_scaling = 1.0, no scaling is applied.

[0101]

[0118] The chroma scale factor determined above may have fractional precision. It will be understood that fixed-point approximation can be applied to avoid dependencies on the hardware / software platform. Furthermore, inverse chroma scaling can be performed on the decoder side. Therefore, division can be implemented by fixed-point arithmetic using multiplication followed by a right shift. The inverse chroma scale factor "inverse_chroma_scaling[]" at fixed-point precision can be determined as follows based on the number of bits within the fixed-point approximation "CSCALE_FP_PREC". inverse_chroma_scaling[Y Idx]=((1<<(luma_bit_depth-log2(TOTAL_NUMBER_PIECES)+CSCALE_FP_PREC))+(SignaledCW[Y Idx ]>>1)) / SignaledCW[Y Idx ] However, luma_bit_depth is the luma bit depth, and TOTAL_NUMBER_PIECES is the total number of pieces in the piecewise linear model, which is set to 16 in VVC Draft 4. The value of "inverse_chroma_scaling[]" may only need to be calculated once per tile group, and it should be understood that the above division is an integer division operation.

[0102]

[0119] Further quantization can be applied to determine the chromascale factor and inverse scale factor. For example, the inverse chromascale factor can be calculated for all even (2×m) values ​​of "SignaledCW", and the odd (2×m+1) values ​​of "SignaledCW" reuse the chromascale factor of the adjacent even-value scale factor. In other words, the following can be used: for(i=reshaper_model_min_bin_idx; i<=reshaper_model_max_bin_idx; i++) { tempCW=SignaledCW[i]>>1)<<1; inverse_chroma_scaling[i]=((1<<(luma_bit_depth-log2(TOTAL_NUMBER_PIECES)+CSCALE_FP_PREC))+(tempCW>>1)) / tempCW; }

[0103]

[0120] The quantization of the chroma scale factor can be further generalized. For example, an inverse chroma scale factor "inverse_chroma_scaling[]" can be calculated for every nth value of "SignaledCW" while all other neighboring values ​​share the same chroma scale factor. For example, "n" can be set to 4. Thus, the same inverse chroma scale factor value can be shared for every four neighboring codeword values. In some embodiments, the value of "n" can be a power of 2, and such a setting allows the use of a shift to calculate the division. Representing the value of log2(n) as LOG2_n, the above equation "tempCW=SignaledCW[i]>>1)<<1" can be modified as follows: tempCW=SignaledCW[i]>>LOG2_n)< <LOG2_n

[0104]

[0121] In some embodiments, the value of LOG2_n may be a function of the number of pieces used in the piecewise linear model. If fewer pieces are used, it may be beneficial to use a larger LOG2_n. For example, if TOTAL_NUMBER_PIECES is 16 or less, LOG2_n can be set to 1 + (4 - log2(TOTAL_NUMBER_PIECES)). If TOTAL_NUMBER_PIECES is greater than 16, LOG2_n can be set to 0.

[0105]

[0122] Embodiments of this disclosure provide a method for processing video content by simplifying the averaging of Luma prediction blocks.

[0106]

[0123] As discussed above, the current chromablock classification index "Y Idx To determine the average value, the average of the corresponding luma blocks can be used. However, with larger block sizes, the averaging process may involve a large number of luma samples. In the worst case, 128x128 luma samples could be involved in the averaging process.

[0107]

[0124] Embodiments of this disclosure provide a simplified averaging process to reduce the worst-case scenario to using only NxN luma samples (where N is a power of 2).

[0108]

[0125] In some embodiments, if both dimensions of a two-dimensional luma block are less than or equal to a preset threshold M (in other words, at least one of the two dimensions is greater than M), "downsampling" can be applied to use only the position M within that dimension. Without loss of generality, let's take the width dimension as an example. If the width is greater than M, only the sample at position x (x=i×(width>>log2(M)), i=0,…M-1) is used for averaging.

[0109]

[0126] Figure 10 shows an example of applying the proposed simplification to calculate the average of a 16x8 luma block. In this example, M is set to 4, and only 16 luma samples (shaded samples) within the block are used for averaging. It should be understood that the pre-set threshold M is not limited to 4, and M can be set to any value that is a power of 2. For example, the pre-set threshold M could be 1, 2, 4, 8, etc.

[0110]

[0127] In some embodiments, the horizontal and vertical dimensions of the Luma block may have different preset thresholds M. In other words, in the worst-case scenario of the averaging operation, M1 x M2 samples may be used.

[0111]

[0128] In some embodiments, the number of samples can be limited within the averaging process without considering dimensions. For example, up to 16 samples can be used, and these samples can be distributed within the horizontal or vertical dimensions in a 1x16, 16x1, 2x8, 8x2, or 4x4 format, and any format that fits the shape of the current block can be selected. For example, a 2x8 sample matrix can be used if the block is vertically oriented, an 8x2 sample matrix can be used if the block is horizontally oriented, and a 4x4 sample matrix can be used if the block is square.

[0112]

[0129] It will be understood that when larger block sizes are chosen, the content within the block tends to be more uniform. Therefore, the above simplification may result in a difference between the average and the true average of all Luma blocks, although such a difference may be small.

[0113]

[0130] Furthermore, decoder-side motion vector refinement (DMVR) requires the decoder to perform motion detection and derive motion vectors before motion compensation can be applied. Thus, the DMVR mode can be a complexity within the VVC standard, particularly for the decoder. The BDOF mode within the VVC standard can further complicate this situation, as bidirectional optical flow (BDOF) is an additional sequential process that must be applied after DMVR to obtain the Luma prediction block. Since chroma scaling requires the average value of the corresponding Luma prediction block, DMVR and BDOF may be applied before the average value can be calculated.

[0114]

[0131] To address this latency issue, in some embodiments of this disclosure, a luma prediction block is used before DMVR and BDOF to calculate the average luma value, and the average luma value is used to obtain the chroma scaling factor. This allows chroma scaling to be applied in parallel with the DMVR and BDOF processes, thus significantly reducing latency.

[0115]

[0132] Modified forms of latency reduction can be considered in accordance with this disclosure. In some embodiments, this latency reduction can be combined with the simplified averaging process described above, which uses only a portion of the luma prediction block to calculate the average luma value. In some embodiments, the luma prediction block can be used after the DMVR process and before the BDOF process to calculate the average luma value. The average luma value is then used to obtain the chromascale factor. This design allows chroma scaling to be applied in parallel with the BDOF process while maintaining accuracy in determining the chromascale factor. Since the DMVR process may refine the motion vectors, it may be more accurate to use the prediction samples with the refined motion vectors after the DMVR process than to use the prediction samples with the motion vectors before the DMVR process.

[0116]

[0133] Furthermore, the VVC standard includes the CU syntax structure "coding_unit()" which contains the syntax element "cu_cbf" to indicate whether there are any non-zero residual coefficients in the current CU. At the TU level, the TU syntax structure "transform_unit()" contains the syntax elements "tu_cbf_cb" and "tu_cbf_cr" to indicate whether there are any non-zero chroma (Cb or Cr) residual coefficients in the current TU. Traditionally, in VVC Draft 4, if chroma scaling is enabled at the tile group level, averaging of the corresponding chroma block is always called.

[0117]

[0134] Embodiments of this disclosure further provide a method for processing video content by bypassing the luma averaging process. In accordance with the embodiments disclosed, the chroma scaling process is applied to residual chroma coefficients so that the luma 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.

[0118]

[0135] As discussed 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 chromatic (Cb or Cr) residual coefficients in the current TU. The Luma averaging process can be bypassed if either condition 1 or condition 2 is met.

[0119]

[0136] In some embodiments, the mean is derived using only NxN samples of the prediction block, which simplifies the averaging process. For example, if N is equal to 1, only the top-left sample of the prediction block is used. However, this simplified averaging process using prediction blocks still requires the generation of prediction blocks, thereby introducing latency.

[0120]

[0137] In some embodiments, a reference luma sample can be used directly to generate the chroma scale factor. This allows the decoder to derive the scale factor in parallel with the luma prediction process, thereby reducing latency. Intra-prediction and inter-prediction using a reference luma sample are described separately below.

[0121]

[0138] In an exemplary intra-prediction, decoded neighboring samples within the same picture can be used as reference samples to generate the prediction block. These reference samples may include, for example, the sample at the top of the current block, the sample to the left of the current block, or the sample in the upper left corner of the current block. The mean of these reference samples can be used to derive the chromascale factor. In some embodiments, the mean of only a subset of these reference samples can be used. For example, only the K reference samples closest to the upper left position of the current block (e.g., K=3) are averaged.

[0122]

[0139] In an exemplary interpretation, reference samples from a temporal reference picture can be used to generate prediction blocks. These reference samples are identified by a reference picture index and a motion vector. Interpolation can be applied if the motion vector has fractional precision. The reference samples used to determine the average of the reference samples may include pre-interpolation or post-interpolation reference samples. Pre-interpolation reference samples may include motion vectors clipped to integer precision. In accordance with the disclosed embodiments, the average can be calculated using all of the reference samples, or it can be calculated using only a portion of the reference samples (e.g., the reference sample corresponding to the top-left position of the current block).

[0123]

[0140] As shown in Figure 5, interpretation can be performed within the original region while intraprediction (e.g., intraprediction 514 or 528) is performed within the reshaped region. Therefore, in interpretation, forward mapping can be applied to the prediction blocks, and the average is calculated using the forward-mapped prediction blocks. To reduce latency, the average can be calculated using the prediction blocks before forward mapping. For example, the block before forward mapping, an NxN portion of the block before forward mapping, or the top-left sample of the block before forward mapping can be used.

[0124]

[0141] Embodiments of this disclosure further provide a method for processing video content with chroma scaling for dual-tree splitting.

[0125]

[0142] The dependency on Luma can lead to hardware design complexity, so chroma scaling can be turned off for intra-coded tile groups that enable dual-tree partitioning. However, this limitation may result in a loss of coding efficiency. The sample values ​​of the corresponding Luma blocks are averaged to calculate avgY', and the partition index Y Idx Determine the chroma scale factor inverse_chroma_scaling[YIdx Instead of obtaining [], the chroma scale factor can be explicitly signaled within the bitstream to avoid the dependency on luma in the case of dual-tree splitting.

[0126]

[0143] The chroma scale index can be signaled at various levels. For example, as shown in Table 5 of FIG. 11, the chroma scale index can be signaled at the coding unit (CU) level together with the chroma prediction mode. To determine the chroma scale factor of the current chroma block, the syntax element "lmcs_scaling_factor_idx" can be used. If there is no "lmcs_scaling_factor_idx", it can be inferred that the chroma scale factor of the current chroma block is equal to 1.0 with floating-point precision or equivalently (1<<CSCALE_FP_PREC) with fixed-point precision. The range of allowable values of "lmcs_chroma_scaling_idx" is determined at the tile group level and will be described later.

[0127]

[0144] Depending on the possible values ​​of “lmcs_chroma_scaling_idx”, the signaling cost can be particularly high for smaller blocks. Therefore, in some embodiments of this disclosure, the signaling conditions in Table 5 of Figure 11 may additionally include a block size condition. For example (highlighted in italics and gray shading), this syntactic element “lmcs_chroma_scaling_idx” may only be signaled if the current block contains more than a given number of chroma samples, or if 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, the decoder can determine its chroma scale factor. In some embodiments, the chroma scale factor may be set to 1.0 in floating-point precision. In some embodiments, a default “lmcs_chroma_scaling_idx” value may be added at the tile group header level (see 1 in Figure 6). Smaller blocks that do not have a signaled "lmcs_chroma_scaling_idx" can use this tile group-level default index to derive their corresponding chroma scale factor. In some embodiments, the chroma scale factor of a smaller block can be inherited from its neighbor (e.g., the top or left neighbor) that explicitly signals the scale factor.

[0128]

[0145] In addition to signaling the syntactic element "lmcs_chroma_scaling_idx" at the CU level, this syntactic element can also be signaled at the CTU level. However, given that the maximum CTU size in VVC is 128x128, performing the same scaling at the CTU level may be too coarse. Therefore, in some embodiments of this disclosure, the syntactic element "lmcs_chroma_scaling_idx" can be signaled using a fixed granularity. For example, one "lmcs_chroma_scaling_idx" is signaled for every 16x16 region within a CTU and applied to all samples within that 16x16 region.

[0129]

[0146] The range of "lmcs_chroma_scaling_idx" for the current tile group depends on the number of chroma scale factor values ​​allowed within the current tile group. The number of chroma scale factor values ​​allowed within the current tile group can be determined based on the 64-entry chroma LUT as discussed above. Alternatively, the number of chroma scale factor values ​​allowed within the current tile group can be determined using the chroma scale factor calculation discussed above.

[0130]

[0147] For example, in the "quantization" method, the value of LOG2_n can be set to 2 (i.e., "n" can be set to 4), and the codeword assignments for each segment in the piecewise linear model of the current tile group can be set as follows: {0, 65, 66, 64, 67, 62, 62, 64, 64, 64, 67, 64, 64, 62, 61, 0}. Then, any codeword values ​​from 64 to 67 can have the same scale factor value (1.0 in decimal precision), and any codeword values ​​from 60 to 63 can have the same scale factor value (60 / 64 = 0.9375 in decimal precision), so there are only two possible scale factor values ​​for the entire tile group. The chroma scale factor is set to 1.0 by default for the two terminal segments that have no codewords assigned. Therefore, in this example, 1 bit is sufficient to signal "lmcs_chroma_scaling_idx" for the blocks in the current tile group.

[0131]

[0148] In addition to determining possible chroma scale factor values ​​using a piecewise linear model, the encoder can signal a set of chroma scale factor values ​​in the tile group header. Then, at the block level, the chroma scale factor value of a block can be determined using that set of chroma scale factor values ​​and the value of the block's "lmcs_chroma_scaling_idx".

[0132]

[0149] CABAC coding can be applied to encode "lmcs_chroma_scaling_idx". The CABAC context of a block may depend on the "lmcs_chroma_scaling_idx" of its adjacent blocks. For example, the block to the left or the block above it can be used to form the CABAC context. Regarding the binarization of the syntactic elements of "lmcs_chroma_scaling_idx", the same truncated rice binarization applied to the ref_idx_10 and ref_idx_11 syntactic elements in VVC Draft 4 can be used to binarize "lmcs_chroma_scaling_idx".

[0133]

[0150] The advantage of signaling "chroma_scaling_idx" is that the encoder can select the best "lmcs_chroma_scaling_idx" in terms of rate distortion cost. Selecting "lmcs_chroma_scaling_idx" using rate distortion optimization can improve coding efficiency, which can help offset the increased signaling cost.

[0134]

[0151] Embodiments of this disclosure further provide a method for processing video content with signaling of an LMCS piecewise linear model.

[0135]

[0152] The LMCS method uses a piecewise linear model with 16 partitions, but the number of eigenvalues ​​in "SignaledCW[i]" within a tile group tends to be much less than 16. For example, some of the 16 partitions may use the default number of codewords "OrgCW", and some of the 16 partitions may have the same number of codewords as each other. Therefore, an alternative method for signaling the LMCS piecewise linear model may involve signaling the number of unique codewords "listUniqueCW[]" and sending an index for each partition to indicate the elements of "listUniqueCW[]" for the current partition.

[0136]

[0153] Figure 12 shows the revised syntax table. In Table 6 of Figure 12, new or revised syntax is highlighted in italics and gray shading.

[0137]

[0154] The semantic rules for the disclosed signaling method are as follows, with changes underlined: `reshaper_model_min_bin_idx` specifies the minimum bin (or compartment) index used during the reshaper construction process. The value of `reshape_model_min_bin_idx` must be within the range of 0 to `MaxBinIdx`. The value of `MaxBinIdx` must be equal to 15. `reshaper_model_delta_max_bin_idx` specifies the maximum bin index used within the reshaper construction process, which is the maximum allowable bin (or compartment) index, MaxBinIdx minus `reshaper_model_delta_max_bin_idx`. The value of `reshape_model_max_bin_idx` is set to equal `MaxBinIdx - reshape_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 reshape_model_bin_delta_abs_CW[i]. `reshaper_model_bin_num_unique_cw_minus1 plus 1` specifies the size of the codeword array `listUniqueCW`. reshaper_model_bin_delta_abs_CW[i] defines the absolute delta code word value for the i-th bin. reshaper_model_bin_delta_sign_CW_flag[i] defines 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, the corresponding variable RspDeltaCW[i] is positive. -Otherwise (if reshape_model_bin_delta_sign_CW_flag[i] is not equal to 0), the corresponding variable RspDeltaCW[i] is negative. If reshape_model_bin_delta_sign_CW_flag[i] is not present, the corresponding variable RspDeltaCW[i] 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 equal OrgCW. The variable listUniqueCW[i] up to i=1... reshaper_model_bin_num_unique_cw_minus1 is It is derived as follows: - Variable OrgCW (1< <BitDepth Y Set it to equal to ) / (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] is to be within the range of 0 to (reshaper_model_bin_num_unique_cw_minus1+1). RspCW[i] is derived as follows: -reshaper_model_min_bin_idx <= i <= reshaper_model_max_bin_idx if the condition is met. RspCW[i]= listUniqueCW[reshaper_model_bin_cw_idx[i]]. -Otherwise, RspCW[i]=0. BitDepth Y If the value of is equal to 10, the value of RspCW[i] can be in the range of 32 to 2*OrgCW-1.

[0138]

[0155] Embodiments of this disclosure further provide a method for processing video content with conditional chroma scaling at the block level.

[0139]

[0156] As shown in Table 1 of Figure 6, whether chroma scaling is applied can be determined by the "tile_group_reshaper_chroma_residual_scale_flag" signaled at the tile group level.

[0140]

[0157] However, it may be beneficial to determine whether to apply chroma scaling at the block level. For example, in some embodiments disclosed, a CU level flag may be signaled to indicate whether chroma scaling is applied to the current block. The presence of the CU level flag can be conditional based on the tile group level flag "tile_group_reshaper_chroma_residual_scale_flag". That is, the CU level flag may only be signaled if chroma scaling is permitted at the tile group level. The encoder is permitted to choose whether to use chroma scaling based on whether it is beneficial to the current block, but this may also incur significant signaling overhead.

[0141]

[0158] In accordance with the disclosed embodiments, to avoid the above-mentioned signaling overhead, whether chroma scaling is applied to a block can be conditional based on the block's prediction mode. For example, when a block is interpreted, the prediction signal tends to be good, especially when its reference picture is close in terms of temporal distance. Thus, since the residual is expected to be very small, chroma scaling can be bypassed. For example, pictures in higher temporal levels tend to have reference pictures that are close in terms of temporal distance. With respect to a block, chroma scaling can be disabled in pictures that use a nearby reference picture. To determine whether this condition is met, the difference in picture order counts (POCs) between the current picture and the block's reference picture can be used.

[0142]

[0159] In some embodiments, chroma scaling can be disabled for all intercoding blocks. In some embodiments, chroma scaling can be disabled for composite intra / interpredictive (CIIP) modes as defined in the VVC standard.

[0143]

[0160] In the VVC standard, the CU syntax structure "coding_unit()" includes the syntax element "cu_cbf" 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" to indicate whether there are any non-zero chroma (Cb or Cr) residual coefficients in the current TU. The chroma scaling process can be conditioned based on these flags. As described above, if there are no non-zero residual coefficients, the averaging of the corresponding luma chroma scaling process can be invoked. By invoking averaging, the chroma scaling process can be bypassed.

[0144]

[0161] Figure 13 shows a flowchart of Method 1300 as implemented by a computer for processing video content. In some embodiments, Method 1300 may be performed by a codec (e.g., an encoder in Figures 2A-2B or a decoder in Figures 3A-3B). For example, a codec may be implemented as one or more software or hardware components of a device (e.g., device 400) for encoding or converting a video sequence to another code. In some embodiments, the video sequence may be an uncompressed video sequence (e.g., video sequence 202) or a compressed video sequence to be decoded (e.g., video stream 304). In some embodiments, the video sequence may be a surveillance video sequence that can be captured by a surveillance device (e.g., a video input device in Figure 4) associated with the device's processor (e.g., processor 402). The video sequence may contain multiple pictures. The device may perform Method 1300 at the picture level. For example, the device may process pictures one by one within Method 1300. In another example, the device may process multiple pictures at once within Method 1300. Method 1300 may include the following steps:

[0145]

[0162] In step 1302, a chroma block and a luma block associated with the picture can be received. It will be understood that the picture may be associated with chroma and luma components. Therefore, the picture may be associated with a chroma block containing a chroma sample and a luma block containing a luma sample.

[0146]

[0163] In step 1304, the lumascale information associated with the luma block can be determined. In some embodiments, the lumascale information may be syntactic elements signaled in the picture's data stream, or variables derived based on syntactic elements signaled in the picture's data stream. For example, the lumascale information may include "reshape_model_bin_delta_sign_CW[i] and reshape_model_bin_delta_abs_CW[i]" and / or "SignaledCW[i]" as described in the above equation. In some embodiments, the lumascale information may include variables determined based on the luma block. For example, the average luma value may be determined by calculating the average value of luma samples adjacent to the luma block (e.g., luma samples in the top row of the luma block and luma samples in the left column of the luma block).

[0147]

[0164] In step 1306, the chromascale factors can be determined based on the lumascale information.

[0148]

[0165] In some embodiments, the lumascale factor of a lumablock can be determined based on lumascale information. For example, according to the above equation "inverse_chroma_scaling[i]=((1<<(luma_bit_depth-log2(TOTAL_NUMBER_PIECES)+CSCALE_FP_PREC))+(tempCW>>1)) / tempCW", the lumascale factor can be determined based on lumascale information (e.g., "tempCW"). Then, the chromascale factor can be further determined based on the value of the lumascale factor. For example, the chromascale factor can be set to be equal to the value of the lumascale factor. It will be understood that further calculations can be applied to the value of the lumascale factor before setting it as the chromascale factor. As another example, the chromascale factor is "SignaledCW[Y IdxIt can be set to equal to " / OrgCW", and the current chroma block partition index "Y" is based on the average chroma value associated with the chroma block. Idx It is possible to decide on this.

[0149]

[0166] In step 1308, the chroma block can be processed using a chroma scale factor. For example, the residuals of the chroma block can be processed using a chroma scale factor to generate scaled residuals of the chroma block. The chroma block may be a Cb chroma component or a Cr chroma component.

[0150]

[0167] In some embodiments, chroma blocks can be processed if certain conditions are met. For example, the conditions may include that the target coding unit associated with the picture does not have a non-zero residual, or that the target transformation unit associated with the picture does not have a non-zero chroma residual. Whether a target coding unit does not have a non-zero residual can be determined based on the value of a first coding block flag of the target coding unit. Whether a target transformation unit does not have a non-zero chroma residual can be determined based on the value of a second coding block flag of a first component and the value of a third coding block flag of a second component of the target transformation unit. For example, the first component may be a Cb component and the second component may be a Cr component.

[0151]

[0168] It will be understood that each step of Method 1300 can be performed as an independent method. For example, the method for determining the chromatic scale factor described in step 1308 can be performed as an independent method.

[0152]

[0169] Figure 14 shows a flowchart of Method 1400 implemented by a computer for processing video content. In some embodiments, Method 1300 may be performed by a codec (e.g., an encoder in Figures 2A-2B or a decoder in Figures 3A-3B). For example, the codec may be implemented as one or more software or hardware components of a device (e.g., device 400) for encoding or converting a video sequence to another code. In some embodiments, the video sequence may be an uncompressed video sequence (e.g., video sequence 202) or a compressed video sequence to be decoded (e.g., video stream 304). In some embodiments, the video sequence may be a surveillance video sequence that can be captured by a surveillance device (e.g., a video input device in Figure 4) associated with the device's processor (e.g., processor 402). The video sequence may contain multiple pictures. The device may perform Method 1400 at the picture level. For example, the device may process pictures one by one within Method 1400. In another example, the device may process multiple pictures at once within Method 1400. Method 1400 may include the following steps:

[0153]

[0170] In step 1402, a chroma block and a luma block associated with a picture can be received. It will be understood that a picture may be associated with chroma and luma components. Thus, a picture may be associated with a chroma block containing a chroma sample and a luma block containing a luma sample. In some embodiments, a luma block may contain NxM luma samples, where N is the width of the luma block and M is the height of the luma block. As discussed above, the luma samples of a luma block can be used to determine the partition index of the target chroma block. Thus, a luma block associated with a picture in a video sequence can be received. It will be understood that N and M may have the same value.

[0154]

[0171] In step 1404, a subset of NxM luma samples can be selected depending on whether at least one of N and M is above a threshold. To accelerate the determination of the piecewise index, luma blocks can be "downsampled" if certain conditions are met. In other words, a subset of luma samples within a luma block can be used to determine the piecewise index. In some embodiments, the certain condition is that at least one of N and M is above a threshold. In some embodiments, the threshold can be based on at least one of N and M. The threshold can be a power of 2. For example, the threshold can be 4, 8, 16, etc. Taking 4 as an example, if N or M is above 4, a subset of luma samples can be selected. In the example in Figure 10, both the width and height of the luma block are above the threshold of 4, and therefore a subset of 4x4 samples is selected. It will be understood that subsets such as 2x8, 1x16, etc. can also be selected for processing.

[0155]

[0172] In step 1406, the mean value of a subset of NxM luma samples can be determined.

[0156]

[0173] In some embodiments, determining the mean may further include determining whether a second condition is met, and determining the mean of a subset of NxM chroma samples in response to the determination that the second condition is met. For example, the second condition may include that the target coding unit associated with the picture does not have a non-zero residual coefficient or that the target coding unit does not have a non-zero chroma residual coefficient.

[0157]

[0174] In step 1408, the chromascale factor can be determined based on the mean value. In some embodiments, to determine the chromascale factor, the partition index of the chromablock can be determined based on the mean value, it can be determined whether the partition index of the chromablock satisfies a first condition, and depending on whether the partition index of the chromablock satisfies the first condition, the chromascale factor can be set to a default value. The default value may indicate that chroma scaling is not applied. For example, the default value may be 1.0 with decimal precision. It will be understood that a fixed-point approximation can be applied to the default value. Depending on whether the partition index of the chromablock does not satisfy the first condition, the chromascale factor can be determined based on the mean value. More specifically, the chromascale factor can be set to SignaledCW[Y Idx It can be set to ] / OrgCW, and the target chroma block partition index "Y Idx This can be determined based on the average value of the corresponding luma block.

[0158]

[0175] In some embodiments, the first condition may include the chroma block's partition index being greater than the maximum index of the signaled codeword or less than the minimum index of the signaled codeword. The maximum and minimum indices of the signaled codeword can be determined as follows:

[0159]

[0176] Codewords can be generated using a piecewise linear model (e.g., LMCS) based on an input signal (e.g., a luma sample). As discussed above, the dynamic range of the input signal can be divided into several segments (e.g., 16 segments), and each segment of the input signal can be used to generate a bin of a codeword as an output. Thus, each bin of a codeword may have a bin index corresponding to a segment of the input signal. In this example, the bin index range can be 0 to 15. In some embodiments, the output (i.e., codeword) value is between a minimum value (e.g., 0) and a maximum value (e.g., 255), and multiple codewords having values ​​between the minimum and maximum values ​​can be signaled. The bin indices of the multiple codewords to be signaled can be determined. Of the bin indices of the multiple codewords to be signaled, the maximum and minimum bin indices of the bins of the multiple codewords to be signaled can be further determined.

[0160]

[0177] In addition to the chromascale factor, Method 1400 can further determine the lumascale factor based on the bins of multiple signaled codewords. The lumascale factor can be used as an inverse chromascale factor. The equation for determining the lumascale factor is described above and is omitted from this specification. In some embodiments, multiple signaled adjacent codewords share a lumascale factor. For example, two or four signaled adjacent codewords may share the same lumascale factor, which can reduce the burden of determining the lumascale factor.

[0161]

[0178] In step 1410, chroma-scale factors can be used to process chroma-blocks. As discussed above with respect to Figure 5, multiple chroma-scale factors can be used to construct a chroma-scale factor LUT at the tile group level, which can then be applied to the reconstructed chroma residuals of the target block on the decoder side. Similarly, chroma-scale factors can also be applied on the encoder side.

[0162]

[0179] It will be understood that each step of Method 1400 can be performed as an independent method. For example, the method for determining the chromatic scale factor described in Step 1308 can be performed as an independent method.

[0163]

[0180] Figure 15 shows a flowchart of Method 1500 as implemented by a computer for processing video content. In some embodiments, Method 1500 may be performed by a codec (e.g., an encoder in Figures 2A-2B or a decoder in Figures 3A-3B). For example, the codec may be implemented as one or more software or hardware components of a device (e.g., device 400) for encoding or converting a video sequence to another code. In some embodiments, the video sequence may be an uncompressed video sequence (e.g., video sequence 202) or a compressed video sequence to be decoded (e.g., video stream 304). In some embodiments, the video sequence may be a surveillance video sequence that can be captured by a surveillance device (e.g., a video input device in Figure 4) associated with the device's processor (e.g., processor 402). The video sequence may contain multiple pictures. The device may perform Method 1500 at the picture level. For example, the device may process pictures one by one within Method 1500. In another example, the device may process multiple pictures at once within Method 1500. Method 1500 may include the following steps:

[0164]

[0181] In step 1502, it is possible to determine whether or not a chromascale index is present in the received video data.

[0165]

[0182] In step 1504, if it is determined that there is no chromascale index in the received video data, it can be determined that chromascale is not applied to the received video data.

[0166]

[0183] In step 1506, if it is determined that chroma scaling is present in the received video data, the chroma scale factor can be determined based on the chroma scale index.

[0167]

[0184] Figure 16 shows a flowchart of Method 1600 implemented by a computer for processing video content. In some embodiments, Method 1600 may be performed by a codec (e.g., an encoder in Figures 2A-2B or a decoder in Figures 3A-3B). For example, a codec may be implemented as one or more software or hardware components of a device (e.g., device 400) for encoding or converting a video sequence to another code. In some embodiments, the video sequence may be an uncompressed video sequence (e.g., video sequence 202) or a compressed video sequence to be decoded (e.g., video stream 304). In some embodiments, the video sequence may be a surveillance video sequence that can be captured by a surveillance device (e.g., a video input device in Figure 4) associated with the device's processor (e.g., processor 402). The video sequence may contain multiple pictures. The device may perform Method 1600 at the picture level. For example, the device may process pictures one by one within Method 1600. In another example, the device may process multiple pictures at once within Method 1600. Method 1600 may include the following steps:

[0168]

[0185] In step 1602, multiple unique codewords used for the dynamic range of the input video signal can be received.

[0169]

[0186] In step 1604, you can receive the index.

[0170]

[0187] In step 1606, at least one of several unique codewords can be selected based on the index.

[0171]

[0188] In step 1608, the chromascale factor can be determined based on at least one selected code word.

[0172]

[0189] In some embodiments, non-temporary computer-readable storage media containing instructions are also provided, which can be executed by a device (such as the disclosed encoder and decoder) to perform the above-described method. Common non-temporary media include, for example, floppy disks, flexible 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 having a pattern of holes, RAM, PROMs, EPROMs, flash EPROMs or any other flash memory, NVRAMs, caches, registers, any other memory chips or cartridges, and networked versions thereof. The device may include one or more processors (CPUs), input / output interfaces, network interfaces, and / or memory.

[0173]

[0190] It will be understood that the embodiments described above can be implemented in hardware, software (program code), or a combination of hardware and software. When implemented in software, the software can be stored in the computer-readable medium described above. When executed by a processor, the software can perform the disclosed methods. The computing units and other functional units described in this disclosure can be implemented in hardware, software, or a combination of hardware and software. It will also be understood by those skilled in the art that multiple of the above modules / units can be combined into a single module / unit, and each of the above modules / units can be further divided into multiple submodules / subunits.

[0174]

[0191] Embodiments can be further described using the following clauses: 1. A computer implementation method for processing video content, Receiving chroma blocks and luma blocks related to pictures, To determine the lumascale information related to the lumablock, Determining chromascale factors based on chromascale information, and Processing chromablocks using chromascale factors Methods that include... 2. Determining chromatic scale factors based on chromatic scale information is To determine the luma scale factors of luma blocks based on luma scale information. Determining the chromascale factor based on the value of the lumascale factor. The method described in Clause 1, further including the following: 3. Determining the Chromascale factor based on the value of the Lumascale factor is Set the chromatic scale factor to be equal to the value of the luma scale factor. The method described in Clause 2, further including the following: 4. Processing chromatic blocks using chromatographic scale factors is To determine whether the first condition is met, and Depending on whether the first condition is met, the chroma block is processed using a chromascale factor, or If the first condition is not met, bypass the chromablock processing using the chromascale factor. Do one of the following The method described in any one of clauses 1 to 3, further including the above. 5. The first condition is, The target coding unit associated with the picture does not have a non-zero residual, or The target transformation unit associated with the picture does not have a non-zero chroma residual. The method described in Clause 4, including the method described in Clause 4. 6. It is determined that the target coding unit does not have a non-zero residual based on the value of the first coding block flag of the target coding unit. Whether a target transformation unit has a non-zero chroma residual is determined based on the value of the second coded block flag of the first chroma component and the value of the third coded block flag of the second luma component of the target transformation unit. The method described in Article 5. 7. The value of the first coded block flag is 0, The value of the second coded block flag and the value of the third coded block flag are 0. The method described in Article 6. 8. Processing chromatic blocks using chromatographic scale factors is Processing chromablock residuals using chromascale factors. The method described in any one of the clauses 1 to 7, including the method described in any one of the clauses 1 to 7. 9. Equipment for processing video content, A memory that stores one set of instructions, Combined into memory, Receiving chroma blocks and luma blocks related to pictures, To determine the lumascale information related to the lumablock, Determining chromascale factors based on chromascale information, and Processing chromablocks using chromascale factors A processor configured to execute a set of instructions to cause a device to perform an action. Equipment including. 10. When determining chromatic scale factors based on chromatic scale information, To determine the luma scale factors of luma blocks based on luma scale information. Determining the chromascale factor based on the value of the lumascale factor. The device described in Clause 9, wherein the processor is configured to execute a set of instructions to cause the device to perform further actions. 11. When determining the Chromascale factor based on the value of the Lumascale factor, Set the chromatic scale factor to be equal to the value of the luma scale factor. The device described in Clause 10, wherein the processor is configured to execute a set of instructions to cause the device to perform further actions. 12. When processing chromatic blocks using chromatographic scale factors, To determine whether the first condition is met, and Depending on whether the second condition is met, the chroma block is processed using a chroma scale factor, or If the second condition is not met, bypass the chromablock processing using the chromascale factor. Do one of the following A device as described in any one of clauses 9 to 11, wherein the processor is configured to execute a set of instructions to cause the device to perform further actions. 13. The first condition is, The target coding unit associated with the picture does not have a non-zero residual, or The target transformation unit associated with the picture does not have a non-zero chroma residual. The equipment described in Clause 12, including the equipment described in Clause 12. 14. It is determined that the target coding unit does not have a non-zero residual based on the value of the first coding block flag of the target coding unit. Whether a target transformation unit has no non-zero chroma residuals is determined based on the value of the second coded block flag of the first chroma component of the target transformation unit and the value of the third coded block flag of the second chroma component. The equipment described in Clause 13. 15. The value of the first coded block flag is 0, The value of the second coded block flag and the value of the third coded block flag are 0. Equipment as described in Clause 14. 16. When processing chromatic blocks using chromatographic scale factors, Processing chromablock residuals using chromascale factors. A device as described in any one of clauses 9 to 15, wherein the processor is configured to execute a set of instructions to cause the device to perform further actions. 17. A non-temporary computer-readable storage medium that stores a set of instructions executable by one or more processors of a device for causing the device to perform a method for processing video content, wherein the method is: Receiving chroma blocks and luma blocks related to pictures, To determine the lumascale information related to the lumablock, Determining chromascale factors based on chromascale information, and Processing chromablocks using chromascale factors Non-temporary computer-readable storage media, including [specific type of storage medium]. 18. A computer implementation method for processing video content, Receiving chroma blocks and luma blocks associated with a picture, wherein the luma block includes NxM luma samples. Selecting a subset of NxM luma samples based on whether at least one of N and M exceeds a threshold. Determining the mean value of a subset of NxM luma samples. Determining chromascale factors based on mean values, and Processing chromablocks using chromascale factors Methods that include... 19. A computer implementation method for processing video content, To determine whether a chromascale index is present in the received video data. In determining that there is no chromascale index in the received video data, it is determined that chroma scaling will not be applied to the received video data, and In response to determining that chroma scaling is present in the received video data, the chroma scale factor is determined based on the chroma scale index. Methods that include... 20. A computer implementation method for processing video content, Receiving multiple unique code words used for the dynamic range of the input video signal, Receiving the index, Selecting at least one of several unique codewords based on an index, and Determining the chromascale factor based on at least one selected code word. Methods that include...

[0175]

[0192] In addition to implementing the above method by using computer-readable program code, the above method can also be implemented in the form of logic gates, switches, ASICs, programmable logic controllers, and embedded microcontrollers. Thus, such controllers can be considered hardware components, and devices contained within the controller and configured to implement various functions can also be considered structures within the hardware components. Or, devices configured to implement various functions can even be considered both software modules and structures within the hardware components configured to implement the method.

[0176]

[0193] This disclosure can be described in the general context of computer executable instructions, such as program modules, which are executed by computers. Generally, program modules include routines, programs, objects, assemblies, data structures, classes, etc., used to perform a particular task or to implement a particular abstract data type. Embodiments of this disclosure can also be implemented in a distributed computing environment, where tasks are performed by using remote processing units connected by a communication network. In a distributed computing environment, program modules may reside in local and remote computer storage media, including memory devices.

[0177]

[0194] It should be noted that the relational terms such as “first” and “second” used herein are used solely to distinguish one entity or operation from another, and do not imply or require any actual relationship or order between those entities or operations. Furthermore, “comprising,” “having,” “containing,” and “including,” as well as other similar forms of words, are intended to be semantically equivalent and are intended to be non-restrictive in that the items following any one of these words are not intended to be an exhaustive list of such items, nor are they intended to be limited to only the listed items.

[0178]

[0195] The above specification has described embodiments with respect to numerous specific details that may vary depending on the implementation. Certain adaptations and modifications can be made to the embodiments described. Other embodiments may become apparent to those skilled in the art by examining this specification and putting into practice the disclosures revealed herein. This specification and examples are for illustrative purposes only, and the true scope and spirit of this disclosure are intended to be shown by the appended claims. The order of steps shown in the figures is for illustrative purposes only and is not intended to limit the sequence of steps to any particular order. Therefore, those skilled in the art will understand that the steps can be performed in different orders while implementing the same method.

Claims

1. A computer implementation method for processing video content, Receiving chroma blocks and luma blocks related to pictures, To determine the lumascale information related to the lumablock, Determining the chromascale factor based on the aforementioned chromascale information, and Processing the chroma block using the chromascale factor. Methods that include...

2. Determining the chromascale factor based on the chromascale information is To determine the luma scale factor of the luma block based on the luma scale information, The chromascale factor is determined based on the value of the lumascale factor. The method according to claim 1, further comprising:

3. The chromascale factor is determined based on the value of the chromascale factor. Set the chromatar scale factor to be equal to the value of the luma scale factor. The method according to claim 2, further comprising:

4. Processing the chromatic block using the chromatic scale factor is To determine whether the first condition is met, and Processing the chroma block using the chroma scale factor in accordance with the determination that the first condition is met, or In response to the determination that the first condition is not met, the processing of the chroma block using the chroma scale factor is bypassed. Do one of the following The method according to claim 1, further comprising:

5. The first condition is, The target coding unit associated with the aforementioned picture does not have a non-zero residual, or The target transformation unit associated with the aforementioned picture does not have a non-zero chroma residual. The method according to claim 4, including the method described in claim 4.

6. It is determined that the target coding unit does not have a non-zero residual based on the value of the first coding block flag of the target coding unit. Whether the target transformation unit has no non-zero chroma residual is determined based on the value of the second coded block flag of the first chroma component and the value of the third coded block flag of the second luma component of the target transformation unit. The method according to claim 5.

7. The value of the first coded block flag is 0, The value of the second coded block flag and the value of the third coded block flag are 0. The method according to claim 6.

8. Processing the chromatic block using the chromatic scale factor is Processing the residuals of the chroma block using the chroma scale factor. The method according to claim 1, including the method described in claim 1.

9. A device for processing video content, A memory that stores one set of instructions, Combined with the aforementioned memory, Receiving chroma blocks and luma blocks related to pictures, To determine the lumascale information related to the lumablock, Determining the chromascale factor based on the aforementioned chromascale information, and Processing the chroma block using the chromascale factor. A processor configured to execute the set of instructions in order to cause the device to perform the above-mentioned action. Equipment including.

10. When determining the chromascale factor based on the chromascale information, To determine the luma scale factor of the luma block based on the luma scale information, The chromascale factor is determined based on the value of the lumascale factor. The apparatus according to claim 9, wherein the processor is configured to execute the set of instructions in order to cause the apparatus to perform the same action.

11. When determining the chromascale factor based on the value of the chromascale factor, Set the chromatar scale factor to be equal to the value of the luma scale factor. The apparatus according to claim 10, wherein the processor is configured to execute the set of instructions in order to cause the apparatus to perform the same action.

12. When processing the chromatic block using the chromat scale factor, To determine whether the first condition is met, and In accordance with the determination that the second condition is met, the chroma block is processed using the chroma scale factor, or In response to the determination that the second condition is not met, the processing of the chroma block using the chroma scale factor is bypassed. Do one of the following The apparatus according to claim 9, wherein the processor is configured to execute the set of instructions in order to cause the apparatus to perform the same action.

13. The first condition is, The target coding unit associated with the aforementioned picture does not have a non-zero residual, or The target transformation unit associated with the aforementioned picture does not have a non-zero chroma residual. The apparatus according to claim 12, including the apparatus described in claim 12.

14. It is determined that the target coding unit does not have a non-zero residual based on the value of the first coding block flag of the target coding unit. Whether the target transformation unit has no non-zero chroma residual is determined based on the value of the second coded block flag of the first chroma component and the value of the third coded block flag of the second chroma component of the target transformation unit. The apparatus according to claim 13.

15. The value of the first coded block flag is 0, The value of the second coded block flag and the value of the third coded block flag are 0. The apparatus according to claim 14.

16. When processing the chromatic block using the chromat scale factor, Processing the residuals of the chroma block using the chroma scale factor. The apparatus according to claim 9, wherein the processor is configured to execute the set of instructions in order to cause the apparatus to perform the same action.

17. A non-temporary computer-readable storage medium that stores a set of instructions executable by one or more processors of a device for causing the device to perform a method for processing video content, wherein the method is Receiving chroma blocks and luma blocks related to pictures, To determine the lumascale information related to the lumablock, Determining the chromascale factor based on the aforementioned chromascale information, and Processing the chroma block using the chromascale factor. Non-temporary computer-readable storage media, including [specific type of storage medium].

Images