Method, apparatus and computer program for video decoding

Abstract

Aspects of the present disclosure provide a method and an apparatus including a processing circuit for video decoding. The processing circuit decodes, from an encoded video bitstream, a first syntax element indicating whether a first component in the encoded video bitstream is coded based on a second component in the encoded video bitstream. The processing circuit determines, based on the first syntax element, whether to decode one or more second syntax elements for a saturation-related coding tool. The saturation-related coding tool is a saturation scaling coding tool or a luma mapping with a cross-component adaptive loop filter. The one or more second syntax elements are decoded if the first syntax element indicates that the first component is coded based on the second component. If the first syntax element indicates that the first component is not coded based on the second component, the one or more second syntax elements are not decoded.

Description

[Technical Field]

[0001] Incorporation by Reference This application claims benefit of priority to U.S. Provisional Application No. 62 / 958,694, entitled "SIGNALING OF CHROMA PRESENT FLAG FOR SUPPORTING VARIOUS CHROMA FORMAT," filed January 8, 2020, which claims benefit of priority to U.S. Patent Application No. 17 / 096,674, entitled "METHOD AND APPARATUS FOR VIDEO CODING," filed November 12, 2020. The entire disclosures of the prior applications are incorporated herein by reference in their entireties.

[0002] This disclosure describes embodiments generally related to video encoding. [Background technology]

[0003] The background art discussion provided herein is intended to generally present the context for the present disclosure. The inventors' work, to the extent that it is described in this background art section, and aspects of the description that may not be admitted as prior art at the time of filing, are not admitted expressly or implicitly as prior art to the present disclosure.

[0004] Video encoding and decoding can be performed using inter-picture prediction with motion compensation. Uncompressed digital video can include a series of images, each with spatial dimensions of, for example, 1920 x 1080 luma samples and associated chroma samples. The series of images can have a fixed or variable image rate (also informally known as a frame rate), for example, 60 images per second or 60 Hz. Uncompressed video has specific bitrate requirements. For example, 1080p 60 4:2:0 video (1920 x 1080 luma sample resolution at a 60 Hz frame rate) with 8 bits per sample requires a bandwidth approaching 1.5 Gbit / s. One hour of such video requires more than 600 GBytes of storage space.

[0005] One goal of video encoding and decoding is to reduce redundancy in the input video signal through compression. Compression can help reduce the aforementioned bandwidth and / or storage space requirements by two orders of magnitude or more, in some cases. Both lossless and lossy compression, as well as combinations thereof, can be employed. Lossless compression refers to techniques that allow an exact copy of the original signal to be restored from a compressed version of the original signal. When lossy compression is used, the reconstructed signal may not be identical to the original signal, but the distortion between the original and reconstructed signal is small enough to make the reconstructed signal useful for its intended application. For video, lossy compression is widely adopted. The amount of acceptable distortion depends on the application; for example, users of certain consumer streaming applications may tolerate higher distortion than users of television distribution applications. The achievable compression ratio can reflect that higher acceptable / tolerable distortion can result in a higher compression ratio.

[0006] Video encoders and decoders may utilize techniques from several broad categories, including, for example, motion compensation, transform, quantization, and entropy coding.

[0007] Video coding techniques can include a technique known as intra-coding. In intra-coding, sample values ​​are represented without reference to other data from samples or previously reconstructed reference images. In some video coding, an image is spatially subdivided into blocks of samples. If all blocks of samples are coded in intra mode, the image may be an intra-image. Intra-images and their derivatives, such as independent decoder refresh images, can be used to reset the decoder state and thus can be used as the first image in a coded video bitstream and video session, or as still images. Samples in intra-blocks may be subjected to a transform, and the transform coefficients may be quantized before entropy coding. Intra-prediction can be a technique that minimizes sample values ​​in the pre-transform domain. In some cases, the smaller the DC value and AC coefficients after the transform, the fewer bits required for a given quantization step size to represent the block after entropy coding.

[0008] Conventional intra-coding, such as that known from MPEG-2 generation coding techniques, does not use intra-prediction. However, some newer video compression techniques include techniques that rely on, for example, surrounding sample data and / or metadata obtained during the encoding / decoding of spatially adjacent and preceding blocks of data in decoding order. Such techniques are hereinafter referred to as "intra-prediction" techniques. Note that, at least in some cases, intra-prediction uses only reference data from the current picture being reconstructed, and not from reference pictures.

[0009] Intra-prediction can take many different forms. When two or more of such techniques can be used in a given video coding technique, the technique in use can be coded as an intra-prediction mode. In some cases, a mode can have sub-modes and / or parameters, which can be coded separately or included in a mode codeword. The codeword used for a given mode / sub-mode / parameter combination can affect the coding efficiency gain via intra-prediction, and so can the entropy coding technique used to convert the codeword into a bitstream.

[0010] Certain modes of intra prediction were introduced in H.264, refined in H.265, and further refined in new coding techniques such as the Joint Search Model (JEM), Universal Video Coding (VVC), and Benchmark Set (BMS). Predictor blocks can be formed using neighboring sample values ​​belonging to already available samples. The sample values ​​of neighboring samples are copied into the predictor block according to their direction. A reference to the direction in use can be coded in the bitstream or can itself be predicted.

[0011] Referring to FIG. 1A, shown at the bottom right is a subset of nine known predictor directions from the 33 possible predictor directions in H.265 (corresponding to the 33 angle modes of the 35 intra modes). The point where the arrows converge (101) represents the sample to be predicted. The arrows represent the direction from which the sample is predicted. For example, arrow (102) indicates that sample (101) is predicted from the upper right sample at a 45-degree angle from horizontal. Similarly, arrow (103) indicates that sample (101) is predicted to the lower left sample (101) at a 22.5-degree angle from horizontal.

[0012] 1A, a square block (104) of 4x4 samples (shown in bold with dashed lines) is shown in the upper left. The square block (104) includes 16 samples, each labeled with an "S," along with its position in the Y dimension (e.g., row index) and its position in the X dimension (e.g., column index). For example, sample S21 is the second sample in the Y dimension (from the top) and the first sample in the X dimension (from the left). Similarly, sample S44 is the fourth sample in both the Y and X dimensions of the block (104). Because the size of the block is 4x4 samples, S44 is shown in the lower right. Reference samples are also shown, following a similar numbering scheme. The reference samples are labeled R, their Y position (e.g., row index), and their X position (column index) relative to the block (104). In both H.264 and H.265, predicted samples neighbor the block being reconstructed. Therefore, negative values ​​do not need to be used.

[0013] Intra prediction can work by copying reference sample values ​​from adjacent samples as appropriate for the signaled prediction direction. For example, assume that the coded video bitstream includes a signal indicating a prediction direction consistent with arrow (102) for this block, i.e., the upper right sample is predicted from the predicted sample at a 45-degree angle from horizontal. In that case, samples S41, S32, S23, and S14 are predicted from the same reference sample R05. Next, sample S44 is predicted from reference sample R08.

[0014] In some cases, especially when the orientation is not evenly divisible by 45 degrees, the values ​​of multiple reference samples can be combined, for example by interpolation, to calculate the reference sample.

[0015] The number of possible directions has increased as video coding technology has evolved. In H.264 (2003), nine different directions could be represented. This increased to 33 in H.265 (2013), and JEM / VVC / BMS, as of the time of this disclosure, can support up to 65 directions. Experiments have been conducted to identify the most likely directions, and specific techniques in entropy coding are used to represent those likely directions with a small number of bits, accepting a specific penalty for less likely directions. Furthermore, the direction itself may be predictable from neighboring directions used in adjacent, already decoded blocks.

[0016] FIG. 1B shows a schematic diagram (180) showing 65 intra-prediction directions with JEM to illustrate the increasing number of prediction directions over time.

[0017] The mapping of intra-prediction direction bits within a coded video bitstream to represent directions can vary from one video coding technique to another. For example, it can range from a simple direct mapping from prediction direction to intra-prediction mode, to complex adaptation schemes involving codewords, most likely modes, and similar techniques. However, in all cases, there may be certain directions that are statistically less likely to occur in the video content than certain other directions. Because the goal of video compression is to reduce redundancy, in well-performing video coding techniques, these less likely directions are represented with more bits than more likely directions.

[0018] Video encoding and decoding can be performed using inter-picture prediction with motion compensation. Uncompressed digital video can include a series of images, each with spatial dimensions of, for example, 1920 x 1080 luma samples and associated chroma samples. The series can have a fixed or variable image rate (also informally known as a frame rate), for example, 60 images per second or 60 Hz. Uncompressed video has significant bitrate requirements. For example, 1080p 60 4:2:0 video (1920 x 1080 luma sample resolution at a 60 Hz frame rate) with 8 bits per sample requires a bandwidth approaching 1.5 Gbit / s. One hour of such video requires more than 600 GBytes of storage space.

[0019] One goal of video encoding and decoding is to reduce redundancy in the input video signal through compression. Compression can help reduce the aforementioned bandwidth or storage requirements by two or more orders of magnitude, in some cases. Both lossless and lossy compression, as well as combinations of them, can be used. Lossless compression refers to techniques that allow an exact copy of the original signal to be restored from a compressed version of the original. When lossy compression is used, the reconstructed signal may not be identical to the original signal, but the distortion between the original and reconstructed signal is small enough to make the reconstructed signal useful for its intended application. For video, lossy compression is widely adopted. The amount of acceptable distortion depends on the application; for example, users of certain consumer streaming applications can tolerate higher distortion than users of television distribution applications. Achievable compression ratios can reflect that higher acceptable / tolerable distortion can result in higher compression ratios.

[0020] Motion compensation can be a lossy compression technique in which blocks of sample data from a previously reconstructed image or portion thereof (reference image) are spatially shifted in a direction indicated by a motion vector (MV) and then used to predict a newly reconstructed image or image portion. In some cases, the reference image may be the same as the image currently being reconstructed. The MV can have two dimensions, X and Y, or three dimensions, with the third dimension being a representation of the reference image in use (the latter may indirectly be the temporal dimension).

[0021] In some video compression techniques, the MV applicable to a particular region of sample data can be predicted from other MVs, for example, from an MV associated with another region of sample data that is spatially adjacent to the region being reconstructed and precedes that MV in decoding order. Doing so can significantly reduce the amount of data required to encode the MV, thereby eliminating redundancy and increasing compression. MV prediction can work effectively, for example, when encoding input video signals derived from a camera (known as natural video), because there is a statistical likelihood that regions larger than the region to which a single MV is applicable will move in a similar direction and, therefore, in some cases, can be predicted using similar motion vectors derived from MVs in neighboring regions. This results in the MV found for a given region being similar or identical to the MV predicted from surrounding MVs, and after entropy coding, can be represented using fewer bits than would be used to directly encode the MV. In some cases, MV prediction can be an example of lossless compression of a signal (i.e., MV) derived from the original signal (i.e., sample stream). In other cases, MV prediction itself can be lossy, for example, due to rounding errors when calculating a predictor from several surrounding MVs.

[0022] Various MV prediction mechanisms are described in H.265 / HEVC (ITU-T Rec. H.265, "High Efficiency Video Coding", December 2016). Here, we will explain a technique called "spatial merging" from among the many MV prediction mechanisms provided by H.265.

[0023] Referring to Figure 2, the current block (201) contains samples found by the encoder during the motion search process to be predictable from a spatially shifted previous block of the same size. Instead of directly encoding its MV, the MV can be derived from metadata associated with one or more reference pictures, e.g., the most recent (in decoding order) reference picture, using the MV associated with any one of five surrounding samples, denoted A0, A1, and B0, B1, B2 (202 to 206, respectively). In H.265, MV prediction can use predictors from the same reference picture as neighboring blocks. Summary of the Invention [Means for solving the problem]

[0024] Aspects of the present disclosure provide methods and apparatuses for video encoding / decoding. In some examples, the apparatus for video decoding includes a processing circuit. The processing circuit can decode a first syntax element from an encoded video bitstream. The first syntax element can indicate whether a first component in the encoded video bitstream is coded based on a second component in the encoded video bitstream. The processing circuit can determine whether to decode one or more second syntax elements for chroma-related coding tools based on the first syntax element. The chroma-related coding tools are one of (i) a luma mapping with chroma scaling (LMCS) coding tool and (ii) a cross-component adaptive loop filter (CC-ALF). The processing circuit can decode the one or more second syntax elements for the chroma-related coding tools based on the first syntax element indicating that the first component is coded based on the second component in the encoded video bitstream and that the first component is a chroma component. One or more second syntax elements for chroma-related coding tools are not decoded based on the first syntax element indicating that the first component is not coded based on the second component in the coded video bitstream.

[0025] In one embodiment, the first syntax element is signaled in an adaptation parameter set (APS).

[0026] In one embodiment, the first syntax element indicates at a sequence level whether the first component is coded based on the second component.

[0027] In one embodiment, based on a first syntax element indicating that a first component is encoded based on a second component, the second component is one of a second chroma component and a luma component in the encoded video bitstream. Based on a first syntax element indicating that the first component is not encoded based on the second component, (i) the first component is the only component in the encoded video bitstream, or (ii) the encoded video bitstream includes at least a first component and a second component, and the first component is not encoded based on the second component. In one example, the encoded video bitstream includes a first chroma component, a second chroma component, and a luma component having a 4:4:4 chroma format. The first component is the first chroma component. The second component is either the second chroma component or the luma component. The first chroma component, the second chroma component, and the luma component are encoded independently of each other.

[0028] In one embodiment, the processing circuitry can disable chroma-related encoding tools based on a first syntax element indicating that a first component is not encoded based on a second component in the encoded video bitstream.

[0029] In one embodiment, the chroma-related coding tool is an LMCS coding tool. The one or more second syntax elements for the LMCS coding tool include a first LMCS parameter indicating an absolute value of a variable for LMCS chroma residual scaling (CRS). The processing circuit can decode a second LMCS parameter for the LMCS coding tool based on the absolute value of the variable in the LMCS CRS being greater than zero. The one or more second syntax elements include a second LMCS parameter indicating a sign of the variable in the LMCS CRS. The second LMCS parameter of the LMCS coding tool is not decoded based on the absolute value of the variable in the LMCS CRS not being greater than zero.

[0030] In one embodiment, the chroma-related coding tool is CC-ALF. The one or more second syntax elements for CC-ALF include a first CC-ALF flag and a second CC-ALF flag. The first CC-ALF flag indicates whether the first CC-ALF is signaled in the coded video bitstream. The second CC-ALF flag indicates whether the second CC-ALF is signaled in the coded video bitstream. The processing circuit can decode the syntax elements of the first CC-ALF based on the first CC-ALF flag indicating that the first CC-ALF is signaled. The one or more second syntax elements for CC-ALF include syntax elements for the first CC-ALF. The syntax elements of the first CC-ALF are not decoded based on the first CC-ALF flag indicating that the first CC-ALF is not signaled. The processing circuit can decode a syntax element of the second CC-ALF based on the second CC-ALF flag indicating that the second CC-ALF is signaled. The one or more second syntax elements for the CC-ALF include a syntax element for the second CC-ALF. The syntax element of the second CC-ALF is not decoded based on the second CC-ALF flag indicating that the second CC-ALF is not signaled.

[0031] Aspects of the present disclosure also provide a non-transitory computer-readable medium storing instructions that, when executed by a computer, cause the computer to perform a method for video decoding.

[0032] Further features, nature and various advantages of the disclosed subject matter will become more apparent from the following detailed description and accompanying drawings. [Brief explanation of the drawings]

[0033] [Figure 1A] FIG. 2 is a schematic diagram of an example subset of intra-prediction modes. [Figure 1B] FIG. 1 is a diagram of an exemplary intra-prediction direction. [Figure 2]FIG. 1 is a schematic diagram of a current block and its surrounding spatial merge candidates in one example. [Figure 3] FIG. 3 is a simplified block diagram schematic of a communication system (300) according to one embodiment. [Figure 4] FIG. 4 is a schematic diagram of a simplified block diagram of a communication system (400) according to one embodiment. [Figure 5] FIG. 2 is a schematic diagram of a simplified block diagram of a decoder according to one embodiment. [Figure 6] FIG. 2 is a schematic diagram of a simplified block diagram of an encoder according to one embodiment. [Figure 7] FIG. 10 is a block diagram of an encoder according to another embodiment. [Figure 8] FIG. 10 is a block diagram of a decoder according to another embodiment. [Figure 9A] 1 illustrates an exemplary Sequence Parameter Set (SPS) Raw Byte Sequence Payload (RBSP) syntax according to one embodiment of the present disclosure. [Figure 9B] 1 illustrates an exemplary Sequence Parameter Set (SPS) Raw Byte Sequence Payload (RBSP) syntax according to one embodiment of the present disclosure. [Figure 9C] 1 illustrates an exemplary Sequence Parameter Set (SPS) Raw Byte Sequence Payload (RBSP) syntax according to one embodiment of the present disclosure. [Figure 9D] 1 illustrates an exemplary Sequence Parameter Set (SPS) Raw Byte Sequence Payload (RBSP) syntax according to one embodiment of the present disclosure. [Figure 9E] 1 illustrates an exemplary Sequence Parameter Set (SPS) Raw Byte Sequence Payload (RBSP) syntax according to one embodiment of the present disclosure. [Figure 9F] 1 illustrates an exemplary Sequence Parameter Set (SPS) Raw Byte Sequence Payload (RBSP) syntax according to one embodiment of the present disclosure. [Figure 9G] 1 illustrates an exemplary Sequence Parameter Set (SPS) Raw Byte Sequence Payload (RBSP) syntax according to one embodiment of the present disclosure. [Figure 10A]1 illustrates an exemplary Picture Parameter Set (PPS) RBSP syntax, according to one embodiment of the present disclosure. [Figure 10B] 1 illustrates an exemplary Picture Parameter Set (PPS) RBSP syntax, according to one embodiment of the present disclosure. [Figure 10C] 1 illustrates an exemplary Picture Parameter Set (PPS) RBSP syntax, according to one embodiment of the present disclosure. [Figure 10D] 1 illustrates an exemplary Picture Parameter Set (PPS) RBSP syntax, according to one embodiment of the present disclosure. [Figure 11A] 1 illustrates an exemplary adaptive loop filter (ALF) data syntax according to one embodiment of the present disclosure. [Figure 11B] 1 illustrates an exemplary adaptive loop filter (ALF) data syntax according to one embodiment of the present disclosure. [Figure 12] 1 illustrates an exemplary SPS RBSP syntax according to one embodiment of the present disclosure. [Figure 13] 1 illustrates an exemplary SPS RBSP syntax according to one embodiment of the present disclosure. [Figure 14] 1 illustrates an exemplary PPS RBSP syntax according to one embodiment of the present disclosure. [Figure 15] 1 illustrates an exemplary APS RBSP syntax according to one embodiment of the present disclosure. [Figure 16] 1 illustrates an exemplary adaptive loop filter (ALF) data syntax according to one embodiment of the present disclosure. [Figure 17] 17 shows a flowchart outlining a process (1700) according to one embodiment of the present disclosure. [Figure 18] 18 shows a flowchart outlining a process (1800) according to one embodiment of the present disclosure. [Figure 19] 19 shows a flowchart outlining a process (1900) according to one embodiment of the present disclosure. [Figure 20] FIG. 1 illustrates an exemplary architecture of a Luminance Mapping with Chroma Scaling (LMCS) encoding tool, according to one embodiment of the present disclosure. [Figure 21] 1 illustrates an exemplary LMCS data syntax according to one embodiment of the present disclosure. [Figure 22A] 1 illustrates an exemplary ALF data syntax according to one embodiment of the present disclosure. [Figure 22B] 1 illustrates an exemplary ALF data syntax according to one embodiment of the present disclosure. [Figure 23] 2 shows a flowchart outlining a process (2300) according to one embodiment of the present disclosure. [Figure 24] FIG. 1 is a schematic diagram of a computer system according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0034] FIG. 3 illustrates a simplified block diagram of a communication system (300) according to one embodiment of the present disclosure. The communication system (300) includes multiple terminal devices capable of communicating with each other, for example, via a network (350). For example, the communication system (300) includes a first pair of terminal devices (310) and (320) interconnected via the network (350). In the example of FIG. 3, the first pair of terminal devices (310) and (320) perform unidirectional data transmission. For example, the terminal device (310) can encode video data (e.g., a stream of video images captured by the terminal device (310)) for transmission to another terminal device (320) via the network (350). The encoded video data can be transmitted in the form of one or more coded video bitstreams. The terminal device (320) can receive the encoded video data from the network (350), decode the encoded video data to reconstruct the video image, and display the video image according to the reconstructed video data. Unidirectional data transmission can be common in media serving applications, for example.

[0035] In another example, the communication system (300) includes a second pair of terminal devices (330) and (340) that perform bidirectional transmission of encoded video data, such as may occur during a video conference. For the bidirectional transmission of data, in one example, each of the terminal devices (330) and (340) can encode video data (e.g., a stream of video images captured by the terminal device) for transmission to the other of the terminal devices (330) and (340) over the network (350). Each of the terminal devices (330) and (340) can also receive the encoded video data transmitted by the other of the terminal devices (330) and (340), decode the encoded video data to recover the video images, and display the video images on an accessible display device according to the recovered video data.

[0036] In the example of FIG. 3 , the terminal devices 310, 320, 330, and 340 may be depicted as a server, a personal computer, and a smartphone, although the principles of the present disclosure need not be so limited. Embodiments of the present disclosure apply to laptop computers, tablet computers, media players, and / or dedicated videoconferencing equipment. The network 350 represents any number of networks that convey coded video data between the terminal devices 310, 320, 330, and 340, including, for example, wired (cable) and / or wireless communication networks. The communication network 350 may exchange data over circuit-switched and / or packet-switched channels. Exemplary networks include telecommunications networks, local area networks, wide area networks, and / or the Internet. For purposes of this description, the architecture and topology of the network 350 may not be important to the operation of the present disclosure, unless otherwise described herein below.

[0037] 4 illustrates the arrangement of a video encoder and a video decoder in a streaming environment as an example of an application of the disclosed subject matter. The disclosed subject matter may be equally applicable to other video-enabled applications, including, for example, video conferencing, digital TV, storage of compressed video on digital media including CDs, DVDs, memory sticks, etc.

[0038] The streaming system may include a capture subsystem (413), which may include a video source (401), such as a digital camera, that generates an uncompressed video image stream (402). In one example, the video image stream (402) includes samples captured by the digital camera. The video image stream (402), depicted as a thick line to emphasize its high data volume compared to the encoded video data (404) (or encoded video bitstream), may be processed by electronics (420) that includes a video encoder (403) coupled to the video source (401). The video encoder (403), as described in more detail below, may include hardware, software, or a combination thereof to enable or implement aspects of the disclosed subject matter. The encoded video data (404) (or encoded video bitstream (404)), depicted as a thin line to emphasize its low data volume compared to the video image stream (402), may be stored on a streaming server (405) for future use. One or more streaming client subsystems, such as the client subsystems (406) and (408) of FIG. 4, can access the streaming server (405) to obtain copies (407) and (409) of the encoded video data (404). The client subsystem (406) can include a video decoder (410), for example, within an electronic device (430). The video decoder (410) decodes an input copy (407) of the encoded video data and creates an output stream (411) of video images that can be rendered on a display (412) (e.g., a display screen) or other rendering device (not shown). In some streaming systems, the encoded video data (404), (407), and (409) (e.g., a video bitstream) can be encoded according to a particular video encoding / compression standard, such as ITU-T Recommendation H.265. In one example, a video encoding standard under development is informally known as Versatile Video Coding (VVC).The disclosed subject matter can be used in the context of VVC.

[0039] It should be noted that the electronics (420) and (430) may include other components (not shown). For example, the electronics (420) may include a video decoder (not shown), and the electronics (430) may also include a video encoder (not shown).

[0040] 5 shows a block diagram of a video decoder (510) according to one embodiment of the present disclosure. The video decoder (510) may be included in electronic equipment (530). The electronic equipment (530) may include a receiver (531) (e.g., receiving circuitry). The video decoder (510) may be used in place of the video decoder (410) in the example of FIG. 4.

[0041] The receiver (531) may receive one or more coded video sequences to be decoded by the video decoder (510). In the same or another embodiment, one coded video sequence at a time, with the decoding of each coded video sequence being independent of the other coded video sequences. The coded video sequences may be received from a channel (501), which may be a hardware / software link to a storage device that stores the coded video data. The receiver (531) may receive coded video data with other data, such as coded audio data and / or auxiliary data streams, which may be transferred to each other using entities (not shown). The receiver (531) may separate the coded video sequences from other data. To combat network jitter, a buffer memory (515) may be coupled between the receiver (531) and the entropy decoder / analyzer (520) (hereinafter, "analyzer (520)"). In certain applications, the buffer memory (515) is part of the video decoder (510). In other cases, it may be external to the video decoder (510) (not shown). In still other implementations, there may be a buffer memory (not shown) external to the video decoder (510), for example, to combat network jitter, and another buffer memory (515) internal to the video decoder (510), for example, to handle playback timing. When the receiver (531) is receiving data from a store-and-forward device of sufficient bandwidth and controllability, or from an asynchronous network, the buffer memory (515) may not be required, or may be small. For use with best-effort packet networks such as the Internet, the buffer memory (515) may be required, may be relatively large, advantageously adaptively sized, and may be implemented at least in part in an operating system or similar element (not shown) external to the video decoder (510).

[0042] The video decoder (510) may include a parser (520) to reconstruct symbols (521) from the encoded video sequence. These symbol categories include information used to manage the operation of the video decoder (510) and, potentially, information for controlling a rendering device, such as a rendering device (512) (e.g., a display screen) that is not an integral part of the electronic device (530) but can be coupled to the electronic device (530), as shown in FIG. 5. The rendering device control information may be in the form of additional extension information (SEI messages) or video usability information (VUI) parameter set fragments (not shown). The parser (520) can parse / entropy decode the received encoded video sequence. The encoding of the encoded video sequence can follow a video coding technique or standard and can follow various principles, including variable length coding, Huffman coding, arithmetic coding with or without context sensitivity, etc. The analyzer (520) can extract, from the coded video sequence, a set of subgroup parameters for at least one of a subgroup of pixels in the video decoder based on at least one parameter corresponding to the group. The subgroups can include groups of pictures (GOPs), images, tiles, slices, macroblocks, coding units (CUs), blocks, transform units (TUs), prediction units (PUs), etc. The analyzer (520) can also extract coded video sequence information such as transform coefficients, quantizer parameter values, motion vectors, etc.

[0043] The analyzer (520) can perform entropy decoding / analysis operations on the video sequence received from the buffer memory (515) to produce symbols (521).

[0044] The reconstruction of the symbols (521) may involve several different units, depending on the format of the coded video image or portions thereof (e.g., inter- and intra-images, inter- and intra-blocks), and other factors. Which units are involved and how can be controlled by subgroup control information parsed from the coded video sequence by the parser (520). The flow of such subgroup control information between the parser (520) and the following units is not shown for clarity.

[0045] Beyond the functional blocks already described, the video decoder (510) may be conceptually subdivided into several functional units, as described below. In an actual implementation operating under commercial constraints, many of these units may interact closely with each other and may be at least partially integrated with each other. However, for purposes of describing the disclosed subject matter, the following conceptual subdivision into functional units is appropriate.

[0046] The first unit is a scalar / inverse transform unit (551), which receives quantized transform coefficients from the analyzer (520) as well as control information including which transform to use, block size, quantization coefficients, quantization scaling matrices, etc. as symbol(s) (521). The scalar / inverse transform unit (551) may output blocks comprising sample values ​​that may be input to an aggregator (555).

[0047] In some cases, the output samples of the scaler / inverse transform (551) may relate to intra-coded blocks, i.e., blocks that do not use prediction information from a previously reconstructed image but can use prediction information from a previously reconstructed portion of the current image. Such prediction information may be provided by an intra-image prediction unit (552). In some cases, the intra-image prediction unit (552) generates blocks of the same size and shape as the block being reconstructed using surrounding already reconstructed information retrieved from a current image buffer (558). The current image buffer (558), for example, buffers a partially reconstructed and / or fully reconstructed current image. The aggregator (555) may optionally add the prediction information generated by the intra-prediction unit (552) to the output sample information from the scaler / inverse transform unit (551) on a sample-by-sample basis.

[0048] In other cases, the output samples of the scalar / inverse transform unit (551) may relate to an inter-coded, potentially motion-compensated block. In such cases, the motion-compensated prediction unit (553) can access a reference picture memory (557) to fetch samples used for prediction. After motion-compensating the fetched samples according to the symbols (521) associated with the block, these samples can be added by the aggregator (555) to the output of the scalar / inverse transform unit (551) (in this case, referred to as residual samples or residual signals) to generate output sample information. The addresses in the reference picture memory (557) from which the motion-compensated prediction unit (553) fetches prediction samples can be controlled by motion vectors available to the motion-compensated prediction unit (553) in the form of symbols (521), which may have, for example, X, Y, and reference picture components. Motion compensation can also include interpolation of sample values ​​fetched from the reference picture memory (557) when sub-sample accurate motion vectors are used, motion vector prediction mechanisms, and the like.

[0049] The output samples of the aggregator (555) can be subjected to various loop filtering techniques in a loop filter unit (556). Video compression techniques can include in-loop filtering techniques controlled by parameters contained in the coded video sequence (also referred to as a coded video bitstream) and available to the loop filter unit (556) as symbols (521) from the analyzer (520), but can also be responsive to meta-information obtained during decoding of a coded image or previous portion (in decoding order) of the coded video sequence, or to previously reconstructed and loop-filtered sample values.

[0050] The output of the loop filter unit (556) can be a sample stream that can be output to a rendering device (512) and stored in a reference image memory (557) for use in future inter-image prediction.

[0051] Once fully reconstructed, a particular coded image can be used as a reference image for future predictions. For example, once a coded image corresponding to a current image is fully reconstructed and the coded image is identified as a reference image (e.g., by the analyzer (520)), the current image buffer (558) can become part of the reference image memory (557), and a new current image buffer can be relocated before beginning reconstruction of a subsequent coded image.

[0052] The video decoder (510) may perform decoding operations according to a predetermined video compression technique, such as a standard such as ITU-T Rec. H.265. An encoded video sequence may conform to the syntax specified by the video compression technique or standard being used, in the sense that the encoded video sequence conforms to both the syntax of the video compression technique or standard and the profile documented in the video compression technique or standard. Specifically, a profile may select specific tools from all tools available in the video compression technique or standard as the only tools usable under that profile. Compliance may also require that the complexity of the encoded video sequence be within the boundaries defined by the level of the video compression technique or standard. In some cases, the level limits the maximum picture size, maximum frame rate, maximum reconstruction sample rate (e.g., measured in megasamples per second), maximum reference picture size, etc. The limits set by the level may, in some cases, be further constrained by a hypothetical reference decoder (HRD) specification and metadata for HRD buffer management signaled in the encoded video sequence.

[0053] In one embodiment, the receiver (531) can receive additional (redundant) data with the encoded video. The additional data may be included as part of the encoded video sequence. The additional data may be used by the video decoder (510) to properly decode the data and / or to more accurately reconstruct the original video data. The additional data may be in the form of, for example, temporal, spatial, or signal-to-noise ratio (SNR) enhancement layers, redundant slices, redundant images, forward error correction codes, etc.

[0054] 6 shows a block diagram of a video encoder (603) according to one embodiment of the present disclosure. The video encoder (603) is included in an electronic device (620). The electronic device (620) includes a transmitter (640) (e.g., a transmission circuit). The video encoder (603) can be used in place of the video encoder (403) in the example of FIG. 4.

[0055] The video encoder (603) can receive video samples from a video source (601) (not part of the electronics (620) in the example of FIG. 6) that can capture video images to be encoded by the video encoder (603). In another example, the video source (601) is part of the electronics (620).

[0056] The video source (601) may provide a source video sequence to be encoded by the video encoder (603) in the form of a digital video sample stream, which may be of any suitable bit depth (e.g., 8-bit, 10-bit, 12-bit, ...), any color space (e.g., BT.601 YCrCb, RGB, ...), and any suitable sampling structure (e.g., YCrCb 4:2:0, YCrCb 4:4:4). In a media serving system, the video source (601) may be a storage device that stores pre-prepared video. In a video conferencing system, the video source (601) may be a camera that captures local image information as a video sequence. The video data may be provided as multiple individual images that, when viewed sequentially, create a sense of motion. The image itself may be organized as a spatial array of pixels, each of which may contain one or more samples, depending on the sampling structure, color space, etc., in use. Those skilled in the art will readily understand the relationship between pixels and samples. The following description will focus on samples.

[0057] According to one embodiment, the video encoder (603) can encode and compress images of a source video sequence into a coded video sequence (643) in real time or under any other time constraint required by the application. Enforcing an appropriate coding rate is one function of the controller (650). In some embodiments, the controller (650) controls and is functionally coupled to other functional units as described below. Couplings are not shown for clarity. Parameters set by the controller (650) can include rate control-related parameters (picture skip, quantizer, lambda value for rate-distortion optimization techniques, ...), picture size, group of pictures (GOP) layout, maximum motion vector search range, etc. The controller (650) can be configured with other appropriate functions for the video encoder (603) optimized for a particular system design.

[0058] In some embodiments, the video encoder (603) is configured to operate in an encoding loop. As an overly simplified explanation, in one example, the encoding loop can include a source encoder (630) (e.g., responsible for generating symbols, such as a symbol stream, based on an input image to be encoded and a reference image) and a (local) decoder (633) embedded in the video encoder (603). The decoder (633) reconstructs the symbols to create sample data in a manner similar to that of the (remote) decoder (since any compression between the symbols and the encoded video bitstream is lossless in the video compression techniques considered in the disclosed subject matter). The reconstructed sample stream (sample data) is input to a reference image memory (634). Because decoding of the symbol stream yields bit-accurate results regardless of the decoder location (local or remote), the contents of the reference image memory (634) are also bit-accurate between the local encoder and the remote encoder. In other words, the predictor of the encoder "sees" the exact same sample values ​​as the decoder "sees" when using prediction during decoding. This basic principle of reference image synchrony (the resulting drift if synchrony cannot be maintained, e.g., due to channel error) is also used in several related technologies.

[0059] The operation of the "local" decoder (633) may be identical to the operation of a "remote" decoder, such as the video decoder (510) already described in detail in connection with Figure 5. However, with brief reference also to Figure 5, because symbols are available and the encoding / decoding of the symbols into an encoded video sequence by the entropy coder (645) and analyzer (520) may be lossless, the entropy decoder of the video decoder (510), including the buffer memory (515), and the analyzer (520) may not be fully implemented in the local decoder (633).

[0060] An observation that can be made at this point is that any decoder techniques, with the exception of parsing / entropy decoding, present in the decoder must also be present in substantially identical functional form in the corresponding encoder. For this reason, the disclosed subject matter focuses on decoder operation. Descriptions of encoder techniques can be omitted since they are the inverse of the decoder techniques described generically. Only in certain areas are more detailed descriptions required and are provided below.

[0061] In operation, in some examples, the source encoder (630) may perform motion-compensated predictive encoding, which predictively encodes an input image with reference to one or more previously encoded images from a video sequence designated as “reference images.” In this manner, the encoding engine (632) encodes differences between pixel blocks of the input image and pixel blocks of reference images that may be selected as predictive references for the input image.

[0062] The local video decoder (633) may decode the encoded video data of an image that may be designated as a reference image based on the symbols generated by the source encoder (630). The operation of the encoding engine (632) may advantageously be a lossy process. When the encoded video data is decoded by a video decoder (not shown in FIG. 6), the reconstructed video sequence may be a replica of the source video sequence, typically with some errors. The local video decoder (633) may replicate the decoding process that may be performed on the reference image by the video decoder and store the reconstructed reference image in a reference image cache (634). In this way, the video encoder (603) can locally store copies of reconstructed reference images that have common content as the reconstructed reference images to be retrieved by the far-end video decoder (without transmission errors).

[0063] The predictor (635) can perform the prediction search for the coding engine (632). That is, for a new image to be encoded, the predictor (635) can search the reference image memory (634) for sample data (as candidate reference pixel blocks) or specific metadata, such as motion vectors, block shapes, etc., of reference images that can serve as suitable prediction references for the new image. The predictor (635) can operate on a sample block-by-sample block basis to find suitable prediction references. In some cases, as determined by the search results obtained by the predictor (635), the input image can have prediction references drawn from multiple reference images stored in the reference image memory (634).

[0064] The controller (650) can manage the encoding operations of the source encoder (630), including, for example, setting the parameters and subgroup parameters used to encode the video data.

[0065] The output of all the aforementioned functional units may undergo entropy coding in an entropy coder (645), which converts the symbols produced by the various functional units into an encoded video sequence by losslessly compressing the symbols according to techniques such as Huffman coding, variable length coding, or arithmetic coding.

[0066] The transmitter (640) can buffer the encoded video sequence produced by the entropy encoder (645) and prepare it for transmission over a communication channel (660), which can be a hardware / software link to a storage device that stores the encoded video data. The transmitter (640) can merge the encoded video data from the video encoder (603) with other data to be transmitted, such as encoded audio data and / or auxiliary data streams (sources not shown).

[0067] The controller (650) can manage the operation of the video encoder (603). During encoding, the controller (650) can assign a particular encoded image format to each encoded image, which can affect the encoding technique that can be applied to the respective image. For example, images are often assigned as one of the following image formats:

[0068] Note that intra-pictures (I-pictures) may be codecable and decodable without relying on other pictures in the sequence for prediction. Some video coding allows for different forms of intra-pictures, including, for example, independent decoder refresh ("IDR") pictures. Those skilled in the art are aware of these variations of I-pictures and their respective uses and characteristics.

[0069] A predicted image (P-image) may be one that can be coded and decoded using intra- or inter-prediction, which uses at most one motion vector and reference index to predict the sample values ​​of each block.

[0070] Bidirectionally predicted images (B-images) may be those that can be coded and decoded using intra- or inter-prediction, which uses up to two motion vectors and reference indices to predict the sample values ​​of each block. Similarly, multiple predicted images may use more than two reference images and associated metadata for the reconstruction of a single block.

[0071] A source image is generally spatially subdivided into multiple sample blocks (e.g., blocks of 4x4, 8x8, 4x8, or 16x16 samples each) and may be coded block by block. Blocks may be predictively coded with reference to other (already coded) blocks, as determined by a coding assignment applied to each image of the block. For example, blocks of I images may be non-predictively coded or predictively coded with reference to previously coded blocks of the same image (spatial prediction or intra-prediction). Pixel blocks of P images may be predictively coded via spatial prediction or via temporal prediction with reference to one previously coded reference image. Blocks of B images may be predictively coded via spatial prediction or via temporal prediction with reference to one or two previously coded reference images.

[0072] The video encoder (603) may perform encoding operations according to a predetermined video encoding technique or standard, such as ITU-T Rec. H.265. In its operation, the video encoder (603) may perform various compression operations, including predictive encoding operations that exploit temporal and spatial redundancy in the input video sequence. Thus, the encoded video data may conform to a syntax specified by the video encoding technique or standard being used.

[0073] In one embodiment, the transmitter (640) can transmit additional data along with the encoded video. The source encoder (630) can include such data as part of the encoded video sequence. The additional data can include temporal / spatial / SNR enhancement layers, other forms of redundant data such as redundant pictures and slices, SEI messages, VUI parameter set fragments, etc.

[0074] Video may be captured in time sequence as multiple source images (video images). Intra-image prediction (often abbreviated as intra-prediction) exploits spatial correlation within a given image, while inter-image prediction exploits correlation (temporal or otherwise) between images. In one example, a particular image being encoded / decoded, called the current image, is divided into blocks. When a block in the current image is similar to a reference block in a previously encoded and still buffered reference image in the video, the block in the current image can be coded by a vector called a motion vector. The motion vector points to a reference block in the reference image and may have a third dimension that identifies the reference image if multiple reference images are used.

[0075] In some embodiments, bi-prediction techniques can be used for inter-picture prediction. According to bi-prediction techniques, two reference images, such as a first reference image and a second reference image, are used, both of which are before the decoding order of the current image in the video (but may be in the past and future display order, respectively). A block in the current image can be coded by a first motion vector pointing to a first reference block in the first reference image and a second motion vector pointing to a second reference block in the second reference image. A block can be predicted by a combination of the first reference block and the second reference block.

[0076] Furthermore, merge mode techniques can be used for inter-picture prediction to improve coding efficiency.

[0077] According to some embodiments of the present disclosure, prediction, such as inter-picture prediction and intra-picture prediction, is performed block-by-block. For example, according to the HEVC standard, images in a sequence of video images are divided into coding tree units (CTUs) for compression, and the CTUs in an image have the same size, such as 64x64 pixels, 32x32 pixels, or 16x16 pixels. Generally, a CTU includes three coding tree blocks (CTBs), one luma CTB and two chroma CTBs. Each CTU can be recursively quadtree-divided into one or more coding units (CUs). For example, a 64x64 pixel CTU can be divided into one CU of 64x64 pixels, four CUs of 32x32 pixels, or 16 CUs of 16x16 pixels. In one example, each CU is analyzed to determine the prediction format of the CU, such as an inter-prediction format or an intra-prediction format. The CU is divided into one or more prediction units (PUs) according to temporal and / or spatial predictability. Generally, each PU includes a luma prediction block (PB) and two chroma PBs. In one embodiment, prediction operations in coding (encoding / decoding) are performed in units of prediction blocks. Taking a luma prediction block as an example of a prediction block, the prediction block includes a matrix of pixel values ​​(e.g., luma values) of 8x8 pixels, 16x16 pixels, 8x16 pixels, 16x8 pixels, etc.

[0078] 7 shows a diagram of a video encoder (703) according to another embodiment of the present disclosure. The video encoder (703) is configured to receive a processed block of sample values ​​(e.g., a predicted block) in a current video image in a sequence of video images and to encode the processed block into an encoded image that is part of the encoded video sequence. In one example, the video encoder (703) is used in place of the video encoder (403) of the example of FIG. 4.

[0079] In an HEVC example, the video encoder (703) receives a matrix of sample values ​​for a processing block, such as a predictive block of 8x8 samples. The video encoder (703) determines whether the processing block is best coded using intra-mode, inter-mode, or bi-predictive mode, for example, using rate-distortion optimization. If the processing block is coded in intra-mode, the video encoder (703) may use intra-prediction techniques to code the processing block into a coded image. When the processing block is to be coded in inter-mode or bi-predictive mode, the video encoder (703) may use inter-prediction or bi-prediction techniques, respectively, to code the processing block into a coded image. In certain video coding techniques, the merge mode may be an inter-image prediction submode in which a motion vector is derived from one or more motion vector predictors without the benefit of coded motion vector components outside the predictors. In certain other video coding techniques, there may be motion vector components applicable to the current block. In one example, the video encoder (703) includes other components, such as a mode determination module (not shown) for determining the mode of the processing block.

[0080] In the example of Figure 7, the video encoder (703) includes an inter encoder (730), an intra encoder (722), a residual calculator (723), a switch (726), a residual encoder (724), a general controller (721), and an entropy encoder (725), all coupled together as shown in Figure 7.

[0081] The inter-encoder (730) is configured to receive samples of a current block (e.g., a processing block), compare the block with one or more reference blocks in reference images (e.g., blocks in a previous image and a subsequent image), generate inter-prediction information (e.g., a description of redundant information through an inter-coding technique, a motion vector, merge mode information), and calculate an inter-prediction result (e.g., a predicted block) based on the inter-prediction information using any suitable technique. In some examples, the reference image is a decoded reference image that is decoded based on the coded video information.

[0082] The intra encoder (722) is configured to receive samples of a current block (e.g., a processing block), possibly compare the block with blocks already coded in the same image, generate quantized coefficients after transformation, and possibly also generate intra prediction information (e.g., intra prediction direction information according to one or more intra coding techniques). In one example, the intra encoder (722) also calculates an intra prediction result (e.g., a prediction block) based on the intra prediction information and a reference block in the same image.

[0083] The general-purpose controller (721) is configured to determine general-purpose control data and control other components of the video encoder (703) based on the general-purpose control data. In one example, the general-purpose controller (721) determines the mode of the block and provides a control signal to the switch (726) based on the mode. For example, if the mode is intra mode, the general-purpose controller (721) controls the switch (726) to select an intra-mode result to be used by the residual calculation unit (723) and controls the entropy encoder (725) to select intra-prediction information to include in the bitstream. If the mode is inter mode, the general-purpose controller (721) controls the switch (726) to select an inter-prediction result to be used by the residual calculation unit (723) and controls the entropy encoder (725) to select inter-prediction information to include in the bitstream.

[0084] The residual calculation unit (723) is configured to calculate the difference (residual data) between the received block and a prediction result selected from the intra-encoder (722) or the inter-encoder (730). The residual encoder (724) is configured to operate on the residual data to encode the residual data to generate transform coefficients. In one example, the residual encoder (724) is configured to transform the residual data from the spatial domain to the frequency domain to generate transform coefficients. The transform coefficients then undergo a quantization process to obtain quantized transform coefficients. In various embodiments, the video encoder (703) also includes a residual decoder (728). The residual decoder (728) is configured to perform an inverse transform and generate decoded residual data. The decoded residual data is suitable for use in the intra-encoder (722) and the inter-encoder (730). For example, the inter-encoder (730) may generate decoded blocks based on the decoded residual data and inter-prediction information, and the intra-encoder (722) may generate decoded blocks based on the decoded residual data and intra-prediction information. In some examples, the decoded blocks are appropriately processed to generate a decoded image, which may be buffered in a memory circuit (not shown) and used as a reference image.

[0085] The entropy encoder (725) is configured to format the bitstream to include the coding block. The entropy encoder (725) is configured to include various information in accordance with an appropriate standard, such as the HEVC standard. In one example, the entropy encoder (725) is configured to include general control data, selected prediction information (e.g., intra-prediction information or inter-prediction information), residual information, and other appropriate information in the bitstream. It should be noted that, according to the disclosed subject matter, when encoding a block in a merged sub-mode of either an inter mode or a bi-prediction mode, residual information is not present.

[0086] 8 shows a diagram of a video decoder (810) according to another embodiment of the present disclosure. The video decoder (810) is configured to receive coded images that are part of an encoded video sequence and decode the coded images to generate reconstructed images. In one example, the video decoder (810) is used in place of the video decoder (410) of the example of FIG. 4.

[0087] In the example of Figure 8, the video decoder (810) includes an entropy decoder (871), an inter decoder (880), a residual decoder (873), a reconstruction module (874), and an intra decoder (872), which are coupled together as shown in Figure 8.

[0088] The entropy decoder (871) may be configured to reconstruct, from the coded image, specific symbols representing the syntax elements of which the coded image is composed. Such symbols may include, for example, prediction information (e.g., intra-prediction information, inter-prediction information, etc.) that can identify the mode in which the block is coded (e.g., intra-mode, inter-mode, bi-prediction mode, the latter two being merged or separate submodes), specific samples or metadata used for prediction by the intra decoder (872) or inter decoder (880), respectively, residual information, e.g., in the form of quantized transform coefficients, etc. In one example, if the prediction mode is an inter-prediction mode or a bi-prediction mode, the inter-prediction information is provided to the inter decoder (880). If the prediction format is an intra-prediction format, the intra-prediction information is provided to the intra decoder (872). The residual information may undergo inverse quantization and be provided to the residual decoder (873).

[0089] The inter decoder (880) is configured to receive the inter prediction information and to generate inter prediction results based on the inter prediction information.

[0090] The intra decoder (872) is configured to receive intra prediction information and to generate a prediction result based on the intra prediction information.

[0091] The residual decoder (873) is configured to perform inverse quantization to extract dequantized transform coefficients and process the dequantized transform coefficients to transform the residual from the frequency domain to the spatial domain. The residual decoder (873) may also require certain control information (to include quantizer parameters (QP)), which may be provided by the entropy decoder (871) (the data path not shown may be low volume control information only).

[0092] The reconstruction module (874) is configured to combine, in the spatial domain, the residual as output by the residual decoder (873) and the prediction result (possibly as output by an inter- or intra-prediction module) to form a reconstructed block that may be part of a reconstructed image, which may be part of a reconstructed video. It should be noted that other suitable operations, such as a deblocking operation, may be performed to improve visual quality.

[0093] It should be noted that the video encoders (403), (603), and (703) and the video decoders (410), (510), and (810) may be implemented using any suitable technology. In one embodiment, the video encoders (403), (603), and (703) and the video decoders (410), (510), and (810) may be implemented using one or more integrated circuits. In another embodiment, the video encoders (403), (603), and (603) and the video decoders (410), (510), and (810) may be implemented using one or more processors executing software instructions.

[0094] For example, a video source represented by a video bitstream can be a sequence of images in encoding order (e.g., encoding order, decoding order). The video source (e.g., coded images, sequence of images) can include one or more sample arrays (also called components or planes), such as an array representing (1) a luma (Y)-only (monochromatic) component (or monochrome component), (2) a luma component and two chroma components (e.g., YCbCr or YCgCo), (3) a green component, a blue component, and a red component (GBR, also known as RGB), and (4) other unspecified monochromatic or tristimulus color sampling (e.g., YZX, also known as XYZ).

[0095] As mentioned above, a video source may include multiple components, such as a luma component and two chroma components (e.g., YCbCr or YCgCo), three color components (e.g., RGB), etc. The components of a video source may refer to a luma component (e.g., Y) or a chroma component (e.g., Cb, Cr, R, G, or B).

[0096] When a video source (e.g., a video sequence) includes multiple components, the multiple components may be coded together, and for example, the coding of one of the multiple components (e.g., a first chroma component) may be based on or dependent on another of the multiple components (e.g., a second chroma component or a luma component). For example, if a chroma component is coded together with or based on one of the multiple components, the chroma component is present in the video source (e.g., the chroma component is present in the multiple components coded together).

[0097] Alternatively, if a video source (e.g., a video sequence) includes multiple components, the multiple components can be coded independently. For example, coding of one of the multiple components (e.g., a first chroma component) is not based on or dependent on another of the multiple components (e.g., a second chroma component or a luma component). Thus, coding of one of the multiple components (e.g., a first chroma component) is independent of another of the multiple components (e.g., a second chroma component or a luma component). The multiple components can be referred to as separately coded multiple components. In one example, the separately coded multiple components are referred to as separately coded multiple color planes or color components.

[0098] In one example, if a video source includes only a monochromatic component, a chroma component is not present. Alternatively, if multiple components in a video source are coded independently or separately, a chroma component is not present. In one example, if multiple components in a video source are coded independently, each of the multiple components can be treated as a monochromatic component (e.g., a luma component), and therefore a chroma component (e.g., a chroma component coded based on one of the multiple components) is not present in the video source. If multiple components in a video source are coded independently, each of the multiple components can be treated as a monochromatic component, and therefore various chroma-related coding tools are not required.

[0099] In some examples, the video sequence to be coded includes multiple color planes, and different combinations of the multiple color planes may be coded together. In one example, a color plane refers to a luma component or a chroma component. In some applications, the video is monochromatic, or the color planes of the video are coded independently, so certain joint color plane coding tools are not applicable. To support applications in which a monochromatic color plane should be coded or in which the color planes should be coded independently, aspects of the present disclosure can provide syntax and semantics beyond Versatile Video Coding (VCC), for example, to disable one or more of the joint color plane coding tools as needed.

[0100] The chroma format index (e.g., chroma_format_idc) may indicate, for example, the chroma subsampling format (or chroma format) between the chroma block and the corresponding luma block. In one example, if the chroma format index (e.g., chroma_format_idc) is 0, the chroma format may be "monochrome," corresponding to monochromatic sampling with only one sample array, nominally considered to be the luma array. If the chroma format index is 1, the chroma format may be 4:2:0 (e.g., each of the two chroma arrays has half the height and half the width of the corresponding luma array). If the chroma format index is 2, the chroma format may be 4:2:2 (e.g., each of the two chroma arrays has the same height and half the width of the luma array). If the chroma format index is 3, the chroma format may be 4:4:4, depending on the value of the separate color plane flag (e.g., separate_color_plane_flag). For example, if the separate color plane flag is equal to 0, then the chroma format is 4:4:4 (e.g., each of the two chroma arrays has the same height and width as the luma array). Otherwise, the separate color plane flag is equal to 1, and the three color planes may be processed separately as three monochromatically sampled images.

[0101] Some examples, such as VVC, support (i) encoding monochrome video and / or (ii) separately encoding the three color components of 4:4:4 chroma format video. To separately support (i) encoding monochrome video and / or (ii) separately encoding the three color components of 4:4:4 chroma format video, a variable (or chroma array type) (e.g., ChromaArrayType) can be defined in VVC to, for example, enable or disable associated encoding tools. The associated encoding tools may be applicable or inapplicable based on whether the input video is monochrome and / or whether the color components of the input video need to be coded separately and independently. In one example, if the input video is monochrome and / or if the color components of the input video need to be coded separately and independently, the associated encoding tools are inapplicable and therefore disabled. Otherwise, the associated encoding tools are applicable and therefore can be enabled.

[0102] In examples such as VVC, the value of the chroma array type (e.g., ChromaArrayType) is assigned based on the value of a separate color plane flag (e.g., separate_color_plane_flag). In one example, the separate color plane flag (e.g., separate_color_plane_flag) indicates whether separately coded color planes are used. If the separate color plane flag (e.g., separate_color_plane_flag) is equal to 0, indicating that separately coded color planes are not used, then the chroma array type (e.g., ChromaArrayType) is set equal to the chroma format (also called the chroma subsampling format, e.g., specified by chroma_format_idc). Otherwise, if the separate color plane flag (e.g., separate_color_plane_flag) is equal to 1, indicating that separately coded color planes are used, then the chroma array type (e.g., ChromaArrayType) is set to 0.

[0103] If the chroma array type (e.g., ChromaArrayType) is 0, the input video may be monochrome or may have a 4:4:4 chroma format (or a 4:4:4 chroma format) with separately coded color planes. In some examples, it may be desirable to disable certain coding tools that are inapplicable to monochrome video and / or video in which each color component of the video is coded as if each component were monochrome. In some examples, such as VCC, one or more of the certain coding tools cannot be disabled when the chroma array type (e.g., ChromaArrayType) is 0. For example, certain coding tools include coding tools enabled by a joint coding flag (e.g., sps_joint_cbcr_enabled_flag), which may indicate joint coding of chroma residual and a PPS joint offset present flag (e.g., pps_joint_cbcr_qp_offset_present_flag), respectively. The PPS joint offset present flag may indicate whether a PPS joint CbCr QP offset value and a joint CbCr QP offset list are present in the PPS RBSP syntax structure.

[0104] Aspects of the present disclosure provide embodiments / methods that disable some encoding tools, for example, when the input video is monochromatic, the input video has multiple components that are separately coded (e.g., the coding of one of the multiple components is independent from the other components of the multiple components). In one example, the input video has a chroma format 4:4:4 with separately coded color planes.

[0105] 9A-9G show tables of an exemplary Sequence Parameter Set (SPS) Raw Byte Sequence Payload (RBSP) syntax, for example, from VVC.

[0106] 10A-10D show tables of an exemplary Picture Parameter Set (PPS) RBSP syntax, for example from VVC.

[0107] 11A-11B show tables of an exemplary adaptive loop filter (ALF) data syntax, for example, from VVC.

[0108] FIG. 12 shows an exemplary SPS RBSP syntax.

[0109] 9A-9G and the table shown in FIG. 12, a joint coding flag (e.g., sps_joint_cbcr_enabled_flag) may indicate joint coding of chroma residuals. A joint coding flag (e.g., sps_joint_cbcr_enabled_flag) equal to 0 may specify that joint coding of chroma residuals is disabled. A joint coding flag (e.g., sps_joint_cbcr_enabled_flag) equal to 1 may specify that joint coding of chroma residuals is enabled. If a joint coding flag (e.g., sps_joint_cbcr_enabled_flag) is not present, the joint coding flag (e.g., sps_joint_cbcr_enabled_flag) may be inferred to be a default value, such as 0.

[0110] Referring to box 910 in FIG. 9D, the joint coding flag (e.g., sps_joint_cbcr_enabled_flag) can be signaled regardless of the value of the chroma array type (e.g., ChromaArrayType). Referring to boxes 1201-1202 in FIG. 12, signaling the joint coding flag (e.g., sps_joint_cbcr_enabled_flag) depends on the chroma array type (e.g., ChromaArrayType). When the chroma array type (e.g., ChromaArrayType) is equal to 0, the joint coding flag (e.g., sps_joint_cbcr_enabled_flag) is not analyzed and can be inferred to be 0, for example, in the SPS shown in FIG. 12. This disables joint coding of chroma residuals (e.g., joint Cb and Cr residual coding) as chroma residual coding, avoiding unnecessary decoding processes.

[0111] In some examples, a chroma present flag is signaled in a PPS, an adaptation parameter set (APS), etc. to not decode chroma-related syntax elements if chroma components are not present in the video bitstream. The chroma present flag may be signaled in a PPS as a PPS chroma present flag (e.g., pps_chromat_present_flag), in an APS as an APS chroma present flag (e.g., aps_chromat_present_flag), and / or the like to indicate whether chroma components are present in a video bitstream such as a video sequence. In one example, a chroma component is present if it is coded together with another component (e.g., a luma component, another chroma component).

[0112] A PPS chroma present flag (e.g., pps_chromat_present_flag) can specify whether a chroma component is present. When the PPS chroma present flag (e.g., pps_chromat_present_flag) is equal to 1, the chroma component is present and chroma-related syntax can be present in the PPS. A PPS chroma present flag (e.g., pps_chromat_present_flag) equal to 0 can specify that the chroma component is not present. A bitstream conformance requirement can be that the PPS chroma present flag (e.g., pps_chromat_present_flag) is equal to 0 when the chroma array type (e.g., ChromaArrayType) is equal to 0.

[0113] An APS chroma present flag (e.g., aps_chroma_present_flag) can specify whether a chroma component is present. When an APS chroma present flag (e.g., aps_chroma_present_flag) is equal to 1, a chroma component is present, and therefore one or more chroma-related syntax may be present in the APS. An APS chroma present flag (e.g., aps_chroma_present_flag) equal to 0 can specify that a chroma component is not present and that no chroma-related syntax is present. A bitstream conformance requirement may be that when a chroma array type (e.g., ChromaArrayType) is equal to 0, the APS chroma present flag (e.g., aps_chroma_present_flag) is equal to 0.

[0114] To ensure consistency in signaling chroma array types (e.g., ChromaArrayType) and related syntax elements, the SPS RBSP syntax of Figures 9A-9G, the PPS RBSP syntax of Figures 10A-10D, and the ALF data syntax of Figures 11A-11B can be modified as shown in Figures 13-16. Changes are highlighted using strikethrough boxes and text indicating the removed text.

[0115] Referring to boxes 911-912 in Figures 9E-9F, a chroma format (e.g., chroma_format_idc) equal to 3 can refer to a 4:4:4 chroma format with a separate color plane flag (e.g., separate_color_plane_flag) of 0 or 1. Thus, an SPS block-based delta pulse code modulation (BDPCM) chroma-enabled flag (e.g., sps_bdpcm_chroma_enabled_flag), an SPS palette-enabled flag (e.g., sps_palette_enabled_flag), and an SPS adaptive color transform (ACT)-enabled flag (e.g., sps_act_enabled_flag), which indicate a chroma-only coding tool and / or a coding tool that uses a chroma component, are signaled regardless of the value of the separate color plane flag (e.g., separate_color_plane_flag). 9E-9F and boxes 1301-1302 in FIG. 13, the chroma array type (e.g., ChromaArrayType) in FIG. 13 can replace the chroma format (e.g., chroma_format_idc) in the tables shown in FIG. 9E-9F. Thus, the syntax "ChromaArrayType==3" in FIG. 13 can replace the syntax "chroma_format_idc==3" in the tables shown in FIG. 9E-9F. As described above, a chroma array type (e.g., ChromaArrayType) of 3 can indicate that the chroma format is 4:4:4 and the separate color plane flag (e.g., separate_color_plane_flag) is 0. Therefore, the SPS BDPCM chroma enable flag (e.g., sps_bdpcm_chroma_enabled_flag), the SPS palette enable flag (e.g., sps_palette_enabled_flag), and the SPS ACT enable flag (e.g., sps_act_enabled_flag) can only be signaled when the value of the chroma array type (e.g., ChromaArrayType) is 3 (e.g., when chroma components are present and the chroma format is 4:4:4).In one example, if no chroma components are present, the chroma array type (e.g., ChromaArrayType) is 0, and thus the SPS BDPCM chroma enable flag (e.g., sps_bdpcm_chroma_enabled_flag), the SPS palette enable flag (e.g., sps_palette_enabled_flag), and the SPS ACT enable flag (e.g., sps_act_enabled_flag) are not signaled. Thus, flags related to chroma encoding tools are not signaled when no chroma components are present, and thus signaling overhead can be reduced and encoding efficiency can be improved.

[0116] The PPS QP offsets (e.g., pps_cb_qp_offset and pps_cr_qp_offset) may specify offsets relative to the luma QP (e.g., Qp'Y) used to derive the chroma QPs (e.g., Qp'Cb and Qp'Cr), respectively. The values ​​of the PPS QP offsets (e.g., pps_cb_qp_offset and pps_cr_qp_offset) may be in the range of -12 to +12. If the chroma array type (e.g., ChromaArrayType) is equal to 0, the PPS QP offsets (e.g., pps_cb_qp_offset and pps_cr_qp_offset) are not used in the decoding process, and the decoder may ignore the values ​​of the PPS QP offsets.

[0117] A PPS joint offset present flag (e.g., pps_joint_cbcr_qp_offset_present_flag) equal to 1 may specify that the PPS joint CbCr QP offset value (e.g., pps_joint_cbcr_qp_offset_value) and the joint CbCr QP offset list (e.g., joint_cbcr_qp_offset_list[i]) are present in the PPS RBSP syntax structure. A PPS joint offset present flag (e.g., pps_joint_cbcr_qp_offset_present_flag) equal to 0 may specify that the PPS joint CbCr QP offset value (e.g., pps_joint_cbcr_qp_offset_value) and the joint CbCr QP offset list (e.g., joint_cbcr_qp_offset_list[i]) are not present in the PPS RBSP syntax structure. If the PPS joint offset present flag (eg, pps_joint_cbcr_qp_offset_present_flag) is not present, the PPS joint offset present flag (eg, pps_joint_cbcr_qp_offset_present_flag) may be inferred to be equal to 0.

[0118] A PPS slice flag (e.g., pps_slice_chroma_qp_offset_present_flag) equal to 1 may indicate that the slice Cb QP offset (e.g., slice_cb_qp_offset) and slice Cr QP offset (e.g., slice_cr_qp_offset) syntax elements are present in the associated slice header. A PPS slice flag (e.g., pps_slice_chroma_qp_offset_present_flag) equal to 0 may indicate that the slice Cb QP offset (e.g., slice_cb_qp_offset) and slice Cr QP offset (e.g., slice_cr_qp_offset) syntax elements are not present in the associated slice header. If the PPS slice flag (e.g., pps_slice_chroma_qp_offset_present_flag) is not present, the PPS slice flag (e.g., pps_slice_chroma_qp_offset_present_flag) may be inferred to be equal to 0.

[0119] A PPS CU flag (e.g., pps_cu_chroma_qp_offset_list_enabled_flag) equal to 1 may specify that intra-slice (e.g., pic_cu_chroma_qp_offset_subdiv_intra_slice) and inter-slice (e.g., pic_cu_chroma_qp_offset_subdiv_inter_slice) syntax elements are present in the image header referencing the PPS, and that CU flags (e.g., cu_chroma_qp_offset_flag) may be present in the transform unit syntax and palette coding syntax. A PPS CU flag (e.g., pps_cu_chroma_qp_offset_list_enabled_flag) equal to 0 may specify that the intra-slice (e.g., pic_cu_chroma_qp_offset_subdiv_intra_slice) and inter-slice (e.g., pic_cu_chroma_qp_offset_subdiv_inter_slice) syntax elements are not present in the picture header referencing the PPS, and that the CU flag (e.g., cu_chroma_qp_offset_flag) is not present in the transform unit syntax and palette coding syntax. If the PPS CU flag (e.g., pps_cu_chroma_qp_offset_list_enabled_flag) is not present, it may be inferred that the PPS CU flag (e.g., pps_cu_chroma_qp_offset_list_enabled_flag) is equal to 0.

[0120] Referring to boxes (1001)-(1002) of FIG. 10C, as shown in FIGS. 10A-10D, specific PPS syntax indicating chroma-related information, such as PPS quantization parameter (QP) offsets (e.g., pps_cb_qp_offset and pps_cr_qp_offset) for each chroma component (e.g., Cb component and Cr component), PPS joint presence flag (e.g., pps_joint_cbcr_qp_offset_present_flag), PPS slice flag (e.g., pps_slice_chroma_qp_offset_present_flag), and / or PPS CU flag (e.g., pps_cu_chroma_qp_offset_list_enabled_flag), can be signaled in the PPS RSRP syntax, e.g., whether a chroma component is present or not. 14, when the PPS chroma present flag (e.g., pps_chromat_present_flag) is 1, indicating that the chroma component is present, PPS syntax indicating PPS-related information, such as PPS QP offsets (e.g., pps_cb_qp_offset and pps_cr_qp_offset), PPS joint offset present flags (e.g., pps_joint_cbcr_qp_offset_present_flag), PPS slice flags (e.g., pps_slice_chroma_qp_offset_present_flag), and / or PPS CU flags (e.g., pps_cu_chroma_qp_offset_list_enabled_flag), can be signaled in the PPS RSRP syntax. Otherwise, when the PPS chroma present flag (e.g., pps_chromat_present_flag) is 0, indicating that the chroma component is not present, no PPS syntax is signaled. This can improve coding efficiency.

[0121] When the chroma array type (e.g., ChromaArrayType) is 0, the video source can have a single component (e.g., a monochrome component), or the video source can have a chroma format of 4:4:4 with multiple components, where the multiple components are coded separately or independently. Thus, for example, there is no chroma component coded based on another component. Thus, when the chroma array type (e.g., ChromaArrayType) is 0, the video component can be coded as if the video component were monochrome, or have a chroma format of 4:4:4 with separately coded color planes.

[0122] 17 shows a flowchart outlining a process (1700) according to one embodiment of the present disclosure. For example, when a PPS chroma present flag (e.g., pps_chroma_present_flag), indicating the absence of a chroma component, is 0, chroma QP-related parsing can be disabled to avoid unnecessary decoding processing. Syntax elements including PPS QP offsets (e.g., pps_cb_qp_offset and pps_cr_qp_offset), PPS joint offset present flags (e.g., pps_joint_cbcr_qp_offset_present_flag), PPS slice flags (e.g., pps_slice_chroma_qp_offset_present_flag), and / or PPS CU flags (e.g., pps_cu_chroma_qp_offset_list_enabled_flag) can be inferred to be 0 and thus not applied in the decoder-side QP derivation process.

[0123] In one example, the process 1700 starts from step S1701 and proceeds to step S1710.

[0124] In (S1710), it can be determined whether the PPS saturation presence flag is 1. If it is determined that the PPS saturation presence flag is not 1, the process (1700) proceeds to (S1720). On the other hand, if it is determined that the PPS saturation presence flag is 1, the process (1700) proceeds to (S1730).

[0125] At (S1720), it can be inferred that one of the chroma QP-related syntax elements, such as the PPS QP offset (e.g., pps_cb_qp_offset and pps_cr_qp_offset), the PPS joint offset present flag (e.g., pps_joint_cbcr_qp_offset_present_flag), the PPS slice flag (e.g., pps_slice_chroma_qp_offset_present_flag), and the PPS CU flag (e.g., pps_cu_chroma_qp_offset_list_enabled_flag), is 0. The process (1700) proceeds to (S1740).

[0126] In (S1740), chroma QP related syntax elements that are 0 are not applied. The process (1700) proceeds to (S1799) and ends.

[0127] At step S1730, the chroma QP related syntax elements can be decoded. The process 1700 proceeds to step S1750.

[0128] In (S1750), it can be determined whether the saturation QP related syntax element is not 0. If it is determined that the saturation QP related syntax element is 0, the process (1700) proceeds to (S1740). On the other hand, if it is determined that the saturation QP related syntax element is not 0, the process (1700) proceeds to (S1760).

[0129] In (S1760), it is possible to apply a saturation QP related syntax element that is not 0. The process (1700) proceeds to (S1799) and ends.

[0130] An ALF chroma filter signal flag (e.g., alf_chroma_filter_signal_flag) equal to 1 can specify that the ALF chroma filter is signaled. An ALF chroma filter signal flag (e.g., alf_chroma_filter_signal_flag) equal to 0 can specify that the ALF chroma filter is not signaled. When an ALF chroma filter signal flag (e.g., alf_chroma_filter_signal_flag) is not present, the ALF chroma filter signal flag (e.g., alf_chroma_filter_signal_flag) can be inferred to be equal to 0.

[0131] Box (1101) in FIG. 11A indicates that an ALF chroma filter signal flag (e.g., alf_chroma_filter_signal_flag) is signaled in the ALF data syntax. Box (1102) in FIG. 11B indicates that when an ALF chroma filter signal flag (e.g., alf_chroma_filter_signal_flag) is 1, the ALF chroma filter information of the corresponding ALF chroma filter can be parsed. Referring to box (1501) in FIG. 15, an ALF chroma present flag (e.g., alf_chroma_present_flag) can be signaled in the APS to indicate whether a chroma component is present. Referring to box (1601) in FIG. 16, when an ALF chroma present flag (e.g., alf_chroma_present_flag) is 1 indicating that a chroma component is present, the ALF chroma filter signal flag (e.g., alf_chroma_filter_signal_flag) is signaled. Further, referring to box (1602), when an ALF chroma filter signal flag (e.g., alf_chroma_filter_signal_flag) is 1, the ALF chroma filter information of the corresponding ALF chroma filter can be parsed. Alternatively, when the ALF chroma present flag (e.g., alf_chroma_present_flag) is 0, indicating that the chroma component is not present, the ALF chroma filter signal flag (e.g., alf_chroma_filter_signal_flag) is not signaled. Then, the ALF chroma filter information of the corresponding ALF chroma filter is not parsed, thus reducing signaling overhead and improving coding efficiency.

[0132] 18 shows a flowchart outlining a process (1800) according to an embodiment of the present disclosure. For example, if the APS chroma present flag (e.g., aps_chroma_present_flag) is 0, the ALF chroma filter can be disabled as a chroma filter to avoid unnecessary decoding processing. Therefore, the ALF chroma filter signal flag (e.g., alf_chroma_filter_signal_flag) can be inferred to be 0.

[0133] In one example, the process 1800 starts from S1801 and proceeds to S1810.

[0134] In (S1810), it can be determined whether the APS saturation presence flag is 1. If it is determined that the APS saturation presence flag is not 1 and that a saturation component is not present, the process (1800) proceeds to (S1820). On the other hand, if it is determined that the APS saturation presence flag is 1, the process (1800) proceeds to (S1830).

[0135] In step S1820, it can be inferred that the ALF chroma filter signal flag is 0. The process 1800 proceeds to step S1840.

[0136] At step S1840, the ALF chroma filter is not applied to the chroma component since there is no chroma component. The process 1800 then proceeds to step S1899 and ends.

[0137] At step S1830, the ALF chroma filter signal flag can be decoded, and the process 1800 proceeds to step S1850.

[0138] In (S1850), it can be determined whether the ALF chroma filter signal flag is 1. If it is determined that the ALF chroma filter signal flag is not 1 (for example, it is 0), the process (1800) proceeds to (S1840). On the other hand, if it is determined that the ALF chroma filter signal flag is 1, the process (1800) proceeds to (S1860).

[0139] At step S1860, an ALF chroma filter can be applied to the chroma components present, and the process 1800 proceeds to step S1899 where it ends.

[0140] 19 shows a flowchart outlining a process (1900) according to one embodiment of the present disclosure. In some examples, such as VVC, certain encoding tools (e.g., BDPCM for chroma, palette mode encoding, and ACT) are applied only when the chroma format is 4:4:4 and there are no separate color planes. Syntax elements associated with certain encoding tools are not parsed when the chroma format is 4:4:4 with separate color planes (e.g., the chroma component is coded as the luma component). Therefore, syntax elements can be parsed only when the chroma array type (e.g., ChromaArrayType) is equal to 3 to avoid unnecessary decoding processing.

[0141] In one example, the process (1900) starts from (S1901) and proceeds to (S1910).

[0142] In (S1910), it can be determined whether the chroma array type is 3. A chroma array type of 3 can indicate a 4:4:4 chroma format without a separate code plane. If it is determined that the chroma array type is not a 4:4:4 chroma format without a separate code plane, the process (1900) proceeds to (S1920). On the other hand, if it is determined that the chroma array type is a 4:4:4 chroma format without a separate code plane, the process (1900) proceeds to (S1930).

[0143] In (S1920), syntax elements such as the SPS BDPCM chroma disabled flag (e.g., sps_bdpcm_chroma_enabled_flag), the SPS palette disabled flag (e.g., sps_palette_enabled_flag), or the SPS ACT disabled flag (e.g., sps_act_enabled_flag), which are associated with a 4:4:4 chroma format without separate color planes, can be inferred to be 0. The process (1900) proceeds to (S1940).

[0144] In step S1940, coding tools related to 4:4:4 chroma formats without separate color planes (e.g., BDPCM, palette coding, or ACT) are not applied. The process 1900 proceeds to step S1999 and ends.

[0145] At step S1930, syntax elements associated with the 4:4:4 chroma format without separate color planes may be decoded. The process 1900 then proceeds to step S1950.

[0146] In (S1950), it can be determined whether the syntax element is 1. If it is determined that the syntax element is not 1 (e.g., equal to 0), the process (1900) proceeds to (S1940). On the other hand, if it is determined that the syntax element is 1, the process (1900) proceeds to (S1960).

[0147] In step S1960, coding tools related to the 4:4:4 chroma format, which does not have separate color planes, can be applied. The process 1900 then proceeds to step S1999 and ends.

[0148] If there is no chroma component present in the video bitstream, such as monochrome or 4:4:4 with separately coded color planes, it is desirable not to decode chroma-related syntax elements in high-level syntax such as SPS, PPS, APS, picture headers, etc.

[0149] To ensure there is no inconsistency in the signaling between the chroma array type (e.g., ChromaArrayType) and the associated syntax elements, embodiments and / or methods of the present disclosure may modify the SPS RBSP syntax, the PPS RBSP syntax, and / or the ALF data syntax.

[0150] FIG. 20 illustrates an example architecture (e.g., decoder-side) of a luma mapping with chroma scaling (LMCS) coding tool according to one embodiment of the present disclosure. In an example such as VVC, the LMCS coding tool is added as a new processing block before the loop filter. The LMCS coding tool can include two components: 1) in-loop mapping of the luma component based on an adaptive piecewise linear model; and 2) luma-dependent chroma residual scaling (CRS) applied to the chroma component. Multiple blocks (e.g., blocks (2011), (2012), and (2015)) can indicate where the processing is applied in the mapped region, including the inverse quantization and inverse transform block (2011), the luma intra prediction block (2015), and the luma residual Y res along with the brightness prediction Y' pred The luminance prediction Y′ can be calculated by adding the luminance prediction Y′ to the reconstruction block (2012). pred is the luminance signal Y pred The luminance signal Y can be from the luma intra prediction block (2015) or the forward mapping block (2018). pred can be generated by a motion compensation prediction block (2016) that can have input from a decoded picture buffer (DPB) (2014). The DPB (2014) can be a buffer that can store decoded pictures.

[0151] Multiple blocks (e.g., blocks (2002), (2003), (2005), (2006)) can indicate where processing is applied in the non-mapped region, such as deblocking, ALF, and SAO loop filters (2003), motion compensation prediction block (2006), chroma intra prediction block (2005), chroma residual C resalong with the saturation prediction C pred , and storing the decoded image as a reference image in the DPB (2004). The LMCS functional block pred The inverse quantization and inverse transform block (2011) may include a forward mapping block (2018) of the luminance signal, a backward mapping block (2017) of the luminance signal, and a luminance-dependent chroma scaling processing block (2001). resscale ) can be provided to the luminance-dependent chroma scaling processing block (2001). The luminance-dependent chroma scaling processing block (2001) can provide a chroma residual scaling parameter (e.g., C resscale ) and a parameter (e.g., cScaleInv). The parameter (e.g., cScaleInv) may be determined by the reconstruction block (2012) (e.g., based on reconstructed luma neighbors, such as upper and / or left neighbors, of the current virtual pipeline data unit (VPDU)). The output of the backward mapping block (2017) may be filtered by the loop filter (2013) and then stored in the DPB (2014). The LMCS coding tools may be enabled and / or disabled at the sequence level using the SPS flag.

[0152] According to aspects of the present disclosure, a first syntax element may be decoded from the coded video bitstream. The first syntax element may indicate whether a first component in the coded video bitstream is coded based on a second component in the coded video bitstream. Whether to decode one or more second syntax elements for chroma-related coding tools may be determined based on the first syntax element. The chroma-related coding tool may be a coding tool used only for chroma component(s) or a coding tool that uses chroma component(s). In some examples, the chroma-related coding tool is one of (i) an LMCS coding tool and (ii) a cross-component adaptive loop filter (CC-ALF).

[0153] The one or more second syntax elements for the chroma-related coding tool can be decoded based on the first syntax element indicating that the first component is coded based on the second component in the coded video bitstream and that the first component is a chroma component. The one or more second syntax elements for the chroma-related coding tool are not decoded based on the first syntax element indicating that the first component is coded independently in the coded video bitstream, e.g., the first component is not coded based on the second component in the coded video bitstream.

[0154] The first syntax element can signal APS. The first syntax element can be an APS chroma present flag (e.g., aps_chroma_present_flag). The first syntax element can indicate at a sequence level whether the first component is coded based on the second component.

[0155] The first syntax element may indicate whether a chroma component is present in the coded video bitstream.

[0156] When the first syntax element indicates that the first component is encoded based on the second component, the second component may be one of the second chroma component and the luma component in the encoded video bitstream. Thus, the chroma component (e.g., the first chroma component) is present in the encoded video bitstream.

[0157] If the first syntax element indicates that the first component is independently coded, e.g., the first component is not coded based on the second component, (i) the first component is the only component in the coded video sequence, or (ii) the coded video bitstream includes at least the first component and the second component, and the first component is coded independently from the second component. Therefore, it is determined that the chroma component is not present in the coded video bitstream. For example, the coded video bitstream includes at least the independently coded first component and the second component. If the first component is a chroma component, the first component can be processed as a monochrome component or a luma component without the need to use chroma-related coding tools. Therefore, there is no chroma component to be coded based on another component in the coded video bitstream.

[0158] In one example, the coded video bitstream includes a first chroma component, a second chroma component, and a luma component having a 4:4:4 chroma format. The first component is the first chroma component. The second component is the second chroma component or the luma component. The first chroma component, the second chroma component, and the luma component are coded independently of each other.

[0159] The chroma-related coding tools can be disabled based on a first syntax element that indicates that a first component is to be coded independently within the coded video bitstream, e.g., that the first component is not coded based on a second component within the coded video bitstream.

[0160] In one embodiment, the chroma-related coding tool is an LMCS coding tool. The first syntax element may indicate that a first chroma component is coded based on a second component. The one or more second syntax elements for the LMCS coding tool may include a first LMCS parameter indicating an absolute value of a variable (e.g., lmcsDeltaCrs) for LMCS chroma residual scaling (CRS). The second LMCS parameter for the LMCS coding tool may be decoded when the absolute value of the variable for the LMCS CRS is greater than 0. The second LMCS parameter may indicate a sign of the variable for the LMCS CRS. The one or more second syntax elements may include a second LMCS parameter. The second LMCS parameter for the LMCS coding tool is not decoded when the absolute value of the variable for the LMCS CRS is less than or equal to 0.

[0161] LMCS is a residual scaling tool that can be applied to the luma component and one or more chroma components. If no chroma components are present in the video bitstream, the chroma-related syntax elements (e.g., first LMCS parameter, second LMCS parameter) for the LMCS coding tool are not required, for example, in APS.

[0162] The first LMCS parameter (e.g., lmcs_delta_abs_crs) may specify the absolute codeword value of an LMCS CRS variable (e.g., lmcsDeltaCrs). If the first LMCS parameter (e.g., lmcs_delta_abs_crs) is not present, the first LMCS parameter (e.g., lmcs_delta_abs_crs) may be inferred to be equal to 0.

[0163] The second LMCS parameter (e.g., lmcs_delta_sign_crs_flag) can specify the sign of the variable (e.g., lmcsDeltaCrs). If the second LMCS parameter (e.g., lmcs_delta_sign_crs_flag) is not present, the second LMCS parameter (e.g., lmcs_delta_sign_crs_flag) can be inferred to be equal to 0.

[0164] According to aspects of the present disclosure, chroma-related syntax elements for an LMCS coding tool (e.g., a first LMCS parameter, a second LMCS parameter) may not be signaled. When an APS chroma present flag (e.g., aps_chroma_present_flag) is equal to 1, a chroma component is present (e.g., the chroma component should be coded based on another component in the coded video bitstream), and thus, chroma-related syntax for the LMCS coding tool can be signaled in the video bitstream. When an APS chroma present flag (e.g., aps_chroma_present_flag) is equal to 0, a chroma component is not present, and chroma-related syntax for the LMCS coding tool is not signaled in the video bitstream. Thus, the chroma-related syntax is not parsed or decoded by the decoder. Thus, signaling overhead can be reduced by not signaling chroma-related syntax elements for an LMCS coding tool when they are not needed and can improve coding efficiency.

[0165] 21 illustrates an exemplary LMCS data syntax according to one embodiment of the present disclosure. Referring to box 2101, whether chroma-related syntax for an LMCS coding tool is signaled can be determined based on an APS chroma present flag (e.g., aps_chroma_present_flag). When the APS chroma present flag (e.g., aps_chroma_present_flag) is 1, a chroma component is present. In one example, one chroma-related syntax element for an LMCS coding tool, such as a first LMCS parameter (e.g., lmcs_delta_abs_crs), is signaled in the video bitstream. Whether other chroma-related syntax elements for the LMCS coding tool are signaled can be determined based on the first LMCS parameter (e.g., lmcs_delta_abs_crs). In one example, a second LMCS parameter (e.g., lmcs_delta_sign_crs_flag), which is a chroma-related syntax element for the LMCS encoding tool, is signaled if a first LMCS parameter (e.g., lmcs_delta_abs_crs) is greater than 0. Otherwise, the second LMCS parameter (e.g., lmcs_delta_sign_crs_flag) is not signaled.

[0166] Referring to box (2101), when the APS chroma present flag (e.g., aps_chroma_present_flag) is equal to 0, the chroma component is not present. Chroma-related syntax elements for LMCS coding tools, such as the first LMCS parameter (e.g., lmcs_delta_abs_crs) and the second LMCS parameter (e.g., lmcs_delta_sign_crs_flag), are not signaled in the video bitstream.

[0167] In one embodiment, the chroma-related coding tool is CC-ALF. The first syntax element indicates that a first chroma component is coded based on a second component. The one or more second syntax elements for CC-ALF can include a first CC-ALF flag and a second CC-ALF flag. The first CC-ALF flag can indicate whether the first CC-ALF is signaled in the coded video bitstream, and the second CC-ALF flag can indicate whether the second CC-ALF is signaled in the coded video bitstream. The first CC-ALF syntax element can be decoded based on the first CC-ALF flag indicating that the first CC-ALF is signaled. The one or more second syntax elements for CC-ALF can include a syntax element for the first CC-ALF. If the first CC-ALF flag indicates that the first CC-ALF is not signaled, the first CC-ALF syntax element is not decoded.

[0168] The syntax elements of the second CC-ALF can be decoded based on a second CC-ALF flag indicating that the second CC-ALF is signaled. The one or more second syntax elements for the CC-ALF can include syntax elements for the second CC-ALF. If the second CC-ALF flag indicates that the second CC-ALF is not signaled, the syntax elements of the second CC-ALF are not decoded.

[0169] CC-ALF is an ALF applied to the chroma component. The chroma-related syntax elements for CC-ALF may include a first CC-ALF flag (e.g., alf_cross_component_cb_filter_signal_flag) indicating whether the first CC-ALF is signaled in the coded video bitstream, a second CC-ALF flag (e.g., alf_cross_component_cr_filter_signal_flag) indicating whether the second CC-ALF is signaled in the coded video bitstream, a syntax element for the first CC-ALF, a syntax element for the second CC-ALF, etc.

[0170] A first CC-ALF flag (e.g., alf_cross_component_cb_filter_signal_flag) equal to 1 may specify that the first CC-ALF (e.g., a cross-component Cb filter) is signaled. A first CC-ALF flag (e.g., alf_cross_component_cb_filter_signal_flag) equal to 0 may specify that the first CC-ALF (e.g., a cross-component Cb filter) is not signaled. If the first CC-ALF flag (e.g., alf_cross_component_cb_filter_signal_flag) is not present, then the first CC-ALF flag (e.g., alf_cross_component_cb_filter_signal_flag) may be inferred to be 0.

[0171] A second CC-ALF flag (e.g., alf_cross_component_cr_filter_signal_flag) equal to 1 may specify that the second CC-ALF (e.g., cross-component Cr filter) is signaled. A second CC-ALF flag (e.g., alf_cross_component_cr_filter_signal_flag) equal to 0 may specify that the second CC-ALF (e.g., cross-component Cr filter) is not signaled. If the second CC-ALF flag (e.g., alf_cross_component_cr_filter_signal_flag) is not present, the second CC-ALF flag (e.g., alf_cross_component_cr_filter_signal_flag) may be inferred to be 0.

[0172] The absence of a chroma component in a video bitstream can indicate that each component in the video bitstream is coded independently as a monochrome or luma component. Therefore, CC-ALF is not required for the component, and therefore chroma-related syntax elements for CC-ALF are not required, for example, in APS. Therefore, chroma-related syntax elements for CC-ALF may not be signaled.

[0173] When an APS chroma present flag (e.g., aps_chroma_present_flag) is equal to 1, a chroma component is present, and one or more of the chroma-related syntax elements for CC-ALF (e.g., first CC-ALF flag, second CC-ALF flag) can be signaled in the video bitstream. When an APS chroma present flag (e.g., aps_chroma_present_flag) is equal to 0, a chroma component is not present, and thus no chroma-related syntax elements are signaled in the video bitstream. Thus, when chroma-related syntax elements for CC-ALF are not needed, signaling overhead can be reduced and coding efficiency can be improved by not signaling the chroma-related syntax elements.

[0174] 22A-22B show an example ALF data syntax according to one embodiment of the present disclosure. Referring to box 2201, whether one or more chroma-related syntax elements for CC-ALF are signaled in the video bitstream can be determined based on an APS chroma present flag (e.g., aps_chroma_present_flag). When the APS chroma present flag (e.g., aps_chroma_present_flag) is equal to 1, a chroma component is present, and one or more of the chroma-related syntax elements for CC-ALF (e.g., a first CC-ALF flag, a second CC-ALF flag) can be signaled in the video bitstream.

[0175] Whether additional syntax elements of the chroma-related syntax elements for CC-ALF are signaled can be determined based on one or more of the chroma-related syntax elements for CC-ALF (e.g., a first CC-ALF flag, a second CC-ALF flag). Referring to box (2202), if the first CC-ALF flag is 1, the first CC-ALF syntax element can be signaled in the video bitstream and therefore can be parsed or decoded by a decoder. Referring to box (2203), if the second CC-ALF flag is 1, the second CC-ALF syntax element can be signaled in the video bitstream and therefore can be parsed or decoded by a decoder.

[0176] Referring back to boxes (2201)-(2203), when the APS chroma present flag (e.g., aps_chroma_present_flag) is equal to 0, the chroma component is not present, and therefore, no chroma-related syntax elements of CC-ALF are signaled in the video bitstream.

[0177] FIG. 23 shows a flowchart outlining a process (2300) according to one embodiment of the present disclosure. The process (2300) can be used to signal a chroma presence flag (e.g., an APS chroma presence flag, a PPS chroma presence flag) to support various chroma formats and chroma-related coding tools (e.g., an LMCS coding tool, CC-ALF). In various embodiments, the process (2300) is performed by a processing circuit, such as the processing circuit of the terminal devices (310), (320), (330), and (340), a processing circuit that performs the functions of the video encoder (403), a processing circuit that performs the functions of the video decoder (410), a processing circuit that performs the functions of the video decoder (510), or a processing circuit that performs the functions of the video encoder (603). In some embodiments, the process (2300) is implemented by software instructions, and thus, the processing circuit performs the process (2300) when the processing circuit executes the software instructions. The process starts at (S2301) and proceeds to (S2310).

[0178] At (S2310), a first syntax element may be decoded from the coded video bitstream. The first syntax element may indicate whether a first component in the coded video bitstream is coded based on a second component in the coded video bitstream.

[0179] At (S2320), it may be determined based on the first syntax element whether to decode one or more second syntax elements for a chroma-related coding tool. The chroma-related coding tool may be one of (i) a luma mapping with chroma scaling (LMCS) coding tool and (ii) a cross-component adaptive loop filter (CC-ALF). If the first syntax element indicates that the first component is coded based on the second component in the coded video bitstream, the process (2300) proceeds to (S2330). Otherwise, if the first syntax element indicates that the first component is coded independently in the coded video bitstream, e.g., the first component is not coded based on the second component in the coded video bitstream, the process (2300) proceeds to (S2399) without decoding one or more second syntax elements for the chroma-related coding tool.

[0180] At (S2330), one or more second syntax elements for chroma-related coding tools may be decoded. The first component may be a first chroma component. The first chroma component is present in the coded video bitstream. The process (2300) proceeds to (S2399) and ends.

[0181] The decoding of one or more second syntax elements for a saturation-related coding tool can be skipped if the saturation present is not present in the coded video bitstream. The saturation-related coding tool is not required, and therefore the saturation-related syntax elements for the saturation-related coding tool are not signaled in the coded video bitstream and are not decoded at the decoder side, reducing signaling overhead and improving coding efficiency.

[0182] The process (2300) may be adapted as appropriate. Steps of the process (2300) may be modified and / or omitted. Additional steps may be added. Any suitable order of execution may be used. For example, if the maximum number of merging candidates does not satisfy the condition, the image level parameters are not decoded.

[0183] The embodiments of the present disclosure may be used separately or combined in any order. Furthermore, each of the methods (or embodiments), the encoder, and the decoder may be implemented by processing circuitry (e.g., one or more processors or one or more integrated circuits). In one example, the one or more processors execute a program stored on a non-transitory computer-readable medium.

[0184] The techniques described above can be implemented as computer software using computer-readable instructions and physically stored on one or more computer-readable media. For example, Figure 24 illustrates a computer system (2400) suitable for implementing certain embodiments of the disclosed subject matter.

[0185] Computer software can be encoded using any suitable machine code or computer language and can be subject to assembly, compilation, linking, or similar mechanisms to create code containing instructions that can be executed by one or more computer central processing units (CPUs), graphics processing units (GPUs), etc., directly, or through interpretation, execution of microcode, etc.

[0186] The instructions may be executed on various types of computers or components thereof, including, for example, personal computers, tablet computers, servers, smartphones, gaming devices, Internet of Things devices, and the like.

[0187] 24 for computer system 2400 are exemplary in nature and are not intended to suggest any limitation as to the scope of use or functionality of the computer software implementing embodiments of the present disclosure, nor should the arrangement of components be interpreted as having a dependency or requirement related to any one or combination of components illustrated in the exemplary embodiment of computer system 2400.

[0188] The computer system (2400) may include certain human interface input devices. Such human interface input devices may respond to input by one or more users, such as, for example, tactile input (e.g., keystrokes, swipes, data glove movements), audio input (e.g., voice, clapping), visual input (e.g., gestures), olfactory input (not shown), etc. Human interface devices may also be used to capture certain media that are not necessarily directly related to conscious human input, such as audio (e.g., speech, music, ambient sounds), images (e.g., scanned images, photographic images obtained from a still image camera), and video (e.g., two-dimensional video, three-dimensional video including stereoscopic video).

[0189] The input human interface devices may include one or more (only one of each shown) of a keyboard (2401), a mouse (2402), a trackpad (2403), a touchscreen (2410), a data glove (not shown), a joystick (2405), a microphone (2406), a scanner (2407), and a camera (2408).

[0190] The computer system (2400) may also include certain human interface output devices. Such human interface output devices may stimulate one or more of the human user's senses, for example, through tactile output, sound, light, and smell / taste. Such human interface output devices may include haptic output devices (e.g., haptic feedback via a touchscreen (2410), data gloves (not shown), or joystick (2405), although some haptic feedback devices may not function as input devices), audio output devices (e.g., speakers (2409), headphones (not shown), etc.), visual output devices (e.g., screens (2410), including CRT screens, LCD screens, plasma screens, and OLED screens, each with or without touchscreen input capability, each with or without haptic feedback capability, some capable of outputting two-dimensional visual output or greater than three-dimensional output by means of stereographic output, virtual reality glasses (not shown), holographic displays, and smoke tanks (not shown), and printers (not shown).

[0191] The computer system (2400) may also include human-accessible storage and associated media such as optical media (2421) such as CD / DVD ROM / RW (2420) including CDs / DVDs, thumb drives (2422), removable hard drives or solid state drives (2423), legacy magnetic media such as tape and floppy disks (not shown), and specialized ROM / ASIC / PLD-based devices such as security dongles (not shown).

[0192] Those skilled in the art should also understand that the term "computer-readable medium" as used in connection with the subject matter disclosed herein does not encompass transmission media, carrier waves, or other transitory signals.

[0193] The computer system (2400) may also include an interface (2454) to one or more communication networks (2455). The network may be, for example, wireless, wired, or optical. The network may further be local, wide-area, metropolitan, vehicular, industrial, real-time, delay-tolerant, or the like. Examples of networks include local area networks such as Ethernet, WLAN, and cellular networks including GSM, 3G, 4G, 5G, LTE, etc.; TV wired or wireless wide-area digital networks including cable television, satellite television, and terrestrial broadcast television; and vehicular and industrial networks including CANbus, etc. Certain networks generally require an external network interface adapter connected to a particular general-purpose data port or peripheral bus (2449) (e.g., a USB port on the computer system (2400)); others are generally integrated into the core of the computer system (2400) by connecting to a system bus, as described below (e.g., an Ethernet interface to a PC computer system or a cellular network interface to a smartphone computer system). Using any of these networks, the computer system (2400) can communicate with other entities. Such communication may be unidirectional, receive only (e.g., broadcast TV), unidirectional transmit only (e.g., from a CANbus to a particular CANbus device), or bidirectional, e.g., to other computer systems using local area digital networks or wide area digital networks. Specific protocols and protocol stacks may be used with each of these networks and network interfaces, as described above.

[0194] The aforementioned human interface devices, human-accessible storage devices, and network interfaces may be connected to the core (2440) of the computer system (2400).

[0195] The cores (2440) may include one or more central processing units (CPUs) (2441), graphics processing units (GPUs) (2442), dedicated programmable processing units in the form of field programmable gate arrays (FPGAs) (2443), task-specific hardware accelerators (2444), graphics adapters (2450), etc. These devices may be connected via a system bus (2448), along with read-only memory (ROM) (2445), random access memory (2446), and internal mass storage devices (2447) such as internal hard drives or SSDs that are not user-accessible. In some computer systems, the system bus (2448) may have access in the form of one or more physical plugs to allow expansion with additional CPUs, GPUs, etc. Peripheral devices may be connected directly to the core's system bus (2448) or via a peripheral bus (2449). In one example, a screen (2410) may be connected to the graphics adapter (2450). Peripheral bus architectures include PCI, USB, etc.

[0196] The CPU (2441), GPU (2442), FPGA (2443), and accelerator (2444) can execute specific instructions that, in combination, can constitute the aforementioned computer code. That computer code can be stored in ROM (2445) or RAM (2446). Transient data can also be stored in RAM (2446), while persistent data can be stored, for example, in internal mass storage (2447). The use of cache memory, which can be closely associated with one or more of the CPU (2441), GPU (2442), mass storage (2447), ROM (2445), RAM (2446), etc., allows for fast storage and retrieval from any memory device.

[0197] The computer-readable medium may bear computer code for performing various computer-implemented operations. The medium and computer code may be those specially designed and constructed for the purposes of the present disclosure, or they may be of the kind well known and available to those skilled in the computer software arts.

[0198] By way of example and not limitation, the architecture (2400), and in particular a computer system having a core (2440), can provide functionality as a result of a processor (including a CPU, GPU, FPGA, accelerator, etc.) executing software embodied in one or more tangible computer-readable media. Such computer-readable media may be the user-accessible mass storage devices introduced above, as well as media associated with specific storage of the core (2440) that is non-transitory in nature, such as the core's internal mass storage device (2447) or ROM (2445). Software implementing various embodiments of the present disclosure may be stored on such devices and executed by the core (2440). The computer-readable media may include one or more memory devices or chips according to particular needs. The software may cause the core (2440), and in particular the processor (including a CPU, GPU, FPGA, etc.) therein, to perform specific processes or portions of specific processes described herein, including defining data structures stored in RAM (2446) and modifying such data structures according to software-defined operations. Additionally, or alternatively, a computer system may provide functionality as a result of logic embodied in or otherwise implemented in circuitry (e.g., accelerator (2444)) that can operate in place of or together with software to perform particular processes or portions of particular processes described herein. References to software may include logic, and vice versa, as appropriate. References to computer-readable media may encompass circuitry (such as an integrated circuit (IC)) that stores software for execution, circuitry that embodies logic for execution, or both, as appropriate. The present disclosure encompasses any suitable combination of hardware and software. Appendix A: Acronyms JEM: Joint exploration model VVC: versatile video coding BMS:benchmark set MV: Motion Vector HEVC: High Efficiency Video Coding SEI: Supplementary Enhancement Information VUI:Video Usability Information GOP: Groups of Pictures TU: Transform Units PU: Prediction Units CTU: Coding Tree Units CTB: Coding Tree Blocks PB: Prediction Blocks HRD: Hypothetical Reference Decoder SNR: Signal Noise Ratio CPU: Central Processing Units GPU: Graphics Processing Units CRT:Cathode Ray Tube LCD: Liquid-Crystal Display OLED: Organic Light-Emitting Diode CD:Compact Disc DVD: Digital Video Disc ROM: Read-Only Memory RAM: Random Access Memory ASIC: Application-Specific Integrated Circuit PLD: Programmable Logic Device LAN: Local Area Network GSM: Global System for Mobile communications, a pan-European digital mobile communications system LTE: Long-Term Evolution CANBus: Controller Area Network Bus USB: Universal Serial Bus PCI: Peripheral Component Interconnect FPGA: Field Programmable Gate Areas SSD: solid-state drive IC: Integrated Circuit CU:Coding Unit Encoder

[0199] While this disclosure has described several exemplary embodiments, there are alterations, permutations, and various substitute equivalents that fall within the scope of this disclosure. It will thus be appreciated that those skilled in the art will be able to devise numerous systems and methods that, although not explicitly shown or described herein, embody the principles of the present disclosure and are therefore within its spirit and scope. [Explanation of symbols]

[0200] 101 Samples 102, 103 Arrows 104 Square Blocks 180 Schematic 201 Current Block 202, 203, 204, 205, 206 Ambient samples 300, 400 communication systems 310, 320, 330, 340 Terminal Equipment 350 Network 401, 601 video sources 402 Video Image Stream 403, 603, 703 video encoder 404, 643 encoded video data 405 Streaming Server 406, 408 Client Subsystem 407, 409 Copy 410, 510, 810 Video Decoder 411 Video Image Output Stream 412 Display 413 Capture Subsystem 420, 430, 530, 620 electronic equipment 501 Channel 512 Rendering Device 515 buffer memory 520 Analyzer 521 Symbol 531 Receiver 551 Scaler / Descaler Unit 552 Intra-Image Prediction Unit 553 Motion Compensation Prediction Unit 555 Aggregator 556 Loop Filter Unit 557 Reference Image Memory 558 Image Buffer 630 Source Encoder 632 encoding engine 633 Decoder 634 Reference Image Memory 635 Predictor 640 Transmitter 645, 725 Entropy Coder 650 Controller 660 Communication Channels 721 General-purpose controller 722 Intra Encoder 723 Residual Calculator 724 Residual Encoder 726 Switch 728, 873 Residual Decoder 730 Intercoder 871 Entropy Decoder 872 Intra Decoder 874 Reconstruction Module 880 Inter Decoder 910, 911, 912, 1001, 1002, 1101, 1102, 1201, 1202, 1301, 1302, 1501, 1601, 1602, 2101, 2201, 2202, 2203 Box 17:00, 18:00, 19:00, 23:00 Processing 2001 Chroma Scaling Processing Block 2002 Reconstruction Block 2003, 2013 Loop Filter 2004, 2014 DPB 2005 chroma intra prediction block 2006, 2016 Motion compensation prediction block 2011 Inverse Quantization and Inverse Transform Block 2012 Reconstruction Block 2015 Luma Intra Prediction Block 2017 Reverse Mapping Block 2018 Forward Mapping Block 2400 Computer System 2401 keyboard 2402 Mouse 2403 Trackpad 2405 Joystick 2406 Mike 2407 Scanner 2408 Camera 2409 Speaker 2410 Touchscreen 2420 CD / DVD ROM / RW 2421 Optical Media 2422 thumb drive 2423 Solid State Drive 2440 cores 2441 CPU 2442 GPU 2443 FPGA 2444 Accelerator 2445 ROM 2446 RAM 2447 Internal Mass Storage 2448 System Bus 2449 Peripheral Bus 2450 graphics adapter 2454 network interface 2455 Communication Network

Claims

1. 1. A method for video decoding performed by a decoder, comprising: decoding a chroma format index from the coded video bitstream, determining whether monochrome sampling is used based on the chroma format index, wherein a value of the chroma format index of 0 indicates that monochrome sampling is used, a value of the chroma format index of 1 indicates a 4:2:0 chroma format, a value of the chroma format index of 2 indicates a 4:2:2 chroma format, and a value of the chroma format index of 3 indicates a 4:4:4 chroma format; determining whether to decode a second syntax element of a cross-component adaptive loop filter (CC-ALF) based on a first syntax element indicating whether a chroma component is present in the coded video bitstream, the second syntax element of the CC-ALF being a chroma-related syntax element and including a first CC-ALF flag and a second CC-ALF flag, the first CC-ALF flag indicating whether a first CC-ALF is decoded by the decoder, and the second CC-ALF flag indicating whether a second CC-ALF is decoded by the decoder; decoding the second syntax element of the CC-ALF if the value of the first syntax element is 1, indicating the presence of the chroma component in the coded video bitstream; 2. The method of claim 1, wherein decoding of the second syntax element of the CC-ALF is skipped if the value of the first syntax element is 0, indicating that the chroma component is not present in the coded video bitstream.

2. The method of claim 1 , wherein the chroma format index is decoded in a sequence parameter set (SPS).

3. The method of claim 1 or 2, wherein the first syntax element indicates at a sequence level whether the chroma component is coded based on another component.

4. based on the chroma component being coded based on the other component, the other component being one of a second chroma component and a luma component in the coded video bitstream. The method of claim 3.

5. the encoded video bitstream includes a first chroma component, a second chroma component, and a luma component having a 4:4:4 chroma format; the saturation component is the first saturation component, the other component is the second chroma component or the luminance component, the first chroma component, the second chroma component, and the luma component are coded independently of each other.

5. The method of claim 3 or 4.

6. disabling the CC-ALF based on the first syntax element indicating the absence of the chroma component in the coded video bitstream. The method of any one of claims 1 to 5, further comprising:

7. the step of decoding the second syntax element further includes a step of decoding a syntax element of the first CC-ALF based on the first CC-ALF flag indicating that the first CC-ALF is to be decoded, the second syntax element of the CC-ALF includes a syntax element of the first CC-ALF, and the syntax element of the first CC-ALF is not decoded based on the first CC-ALF flag indicating that the first CC-ALF is not to be decoded; the step of decoding the second syntax element further includes a step of decoding a syntax element of the second CC-ALF based on the second CC-ALF flag indicating that the second CC-ALF is to be decoded, the second syntax element of the CC-ALF includes a syntax element of the second CC-ALF, and the syntax element of the second CC-ALF is not decoded based on the second CC-ALF flag indicating that the second CC-ALF is not to be decoded; The method of claim 1.

8. An apparatus configured to perform the method according to any one of claims 1 to 7.

9. A computer program for causing a computer to carry out the method according to any one of claims 1 to 7.

Images