Signaling of the Downsampling Filter for the Luma to Chroma Intra Prediction Mode

Abstract

A method and apparatus for performing cross-component intra prediction, comprising receiving a coded bitstream, obtaining a syntax element indicating a downsampling filter used for a cross-component intra prediction mode from the coded bitstream, obtaining a plurality of reconstructed sample values of a first component associated with pixels of a second component based on the downsampling filter, determining a pixel value of a downsampled pixel of the first component based on the plurality of reconstructed sample values, determining a pixel value of a pixel of the second component based on the pixel value of the downsampled pixel of the first component, and reconstructing a picture based on the pixel value of the pixel of the second component.

Description

Technical Field

[0001] Cross - reference to Related Applications This application claims priority to U.S. Provisional Application No. 63 / 356,820, filed on June 29, 2022, and U.S. Application No. 17 / 982,979, filed on November 8, 2022, with the United States Patent and Trademark Office, the disclosures of which are hereby incorporated by reference in their entireties.

[0002] Embodiments of the present disclosure relate to a set of advanced video coding techniques, and more particularly, to a signaling down - sampling filter for cross - component intra prediction mode.

Background Art

[0003] AOMedia Video 1 (AV1) is an open video coding format designed for video transmission over the Internet. Developed by the Alliance for Open Media (AOMedia), a consortium established in 2015 as a successor to VP9, it includes semiconductor companies, video - on - demand providers, video content producers, software development companies, and web browser vendors. Many of the components of the AV1 project are sourced from previous research efforts by the alliance's members. Individual contributors started experimental technology platforms years ago: Xiph / Mozilla's Daala released code in 2010, Google's experimental VP9 evolution project VP10 was announced on September 12, 2014, and Cisco's Thor was released on August 11, 2015. Based on the construction of the VP9 codebase, AV1 incorporates additional technologies, some of which were developed in these experimental formats. The first version of the AV1 reference codec, version 0.1.0, was released on April 7, 2016. The alliance released the AV1 bitstream specification on March 28, 2018, along with reference software - based encoders and decoders. On June 25, 2018, the verification version 1.0.0 of this specification was released. On January 8, 2019, the "AV1 Bitstream & Decoding Process Specification", which is the verification version 1.0.0 with Errata 1 of this specification, was released. The AV1 bitstream specification includes the reference video codec. The "AV1 Bitstream & Decoding Process Specification" (version 1.0.0 with Errata 1), The Alliance for Open Media (January 8, 2019) is incorporated herein by reference in its entirety.

[0004] The High Efficiency Video Coding (HEVC) standard has been jointly developed by the ITU-T Video Coding Experts Group (VCEG) and the ISO / IEC Moving Picture Experts Group (MPEG) standardization bodies. To develop the HEVC standard, these two standardization bodies are collaborating in a partnership known as the Joint Collaborative Team on Video Coding (JCT-VC). The first version of the HEVC standard was completed in January 2013, resulting in the acquisition of harmonized documents published by both ITU-T and ISO / IEC. Subsequently, additional work was organized to extend the standard to support several additional application scenarios, including the use of extended ranges with improved accuracy and color format support, scalable video coding, and 3D / stereo / multi-view video coding. In ISO / IEC, the HEVC standard became MPEG-H Part 2 (ISO / IEC 23008-2), and in ITU-T, it became ITU-T Recommendation H.265. The HEVC standard specification "SERIES H:AUDIOVISUAL AND MULTIMEDIA SYSTEMS,Infrastructure of audiovisual services-Coding of moving video", ITU-T H.265, International Telecommunication Union (April 2015) is hereby incorporated by reference in its entirety into this specification.

[0005] ITU-T VCEG (Q6 / 16) and ISO / IEC MPEG (JTC 1 / SC 29 / WG 11) published the H.265 / HEVC (High Efficiency Video Coding) standard in 2013 (Version 1), 2014 (Version 2), 2015 (Version 3), and 2016 (Version 4). Since then, they have been researching the potential need for standardization of future video coding technologies that may significantly exceed HEVC in compression capabilities. In October 2017, they issued a Joint Call for Proposals on Video Compression with Capability beyond HEVC (CfP). By February 15, 2018, 22 CfP responses for standard dynamic range (SDR), 12 CfP responses for high dynamic range (HDR), and 12 CfP responses in the 360 video category were submitted respectively. In April 2018, all received CfP responses were evaluated at the 122nd MPEG / 10th JVET (Joint Video Exploration Team - Joint Video Expert Team) meeting. JVET carefully evaluated and officially initiated the standardization of next-generation video coding beyond HEVC, namely the so-called Versatile Video Coding (VVC). The specification of the VVC standard, "Versatile Video Coding (Draft 7)", JVET-P2001-vE, Joint Video Experts Team (October 2019), is hereby incorporated by reference in its entirety. Another specification of the VVC standard, "Versatile Video Coding (Draft 10)", JVET-S2001-vE, Joint Video Experts Team (July 2020), is hereby incorporated by reference in its entirety.

Summary of the Invention

Means for Solving the Problems

[0006] According to an aspect of the present disclosure, a method for performing cross-component intra prediction is implemented by at least one processor and includes receiving a current chroma block from a coded bitstream, obtaining a syntax element indicating a downsampling filter used for a chroma from luma (CfL) intra prediction mode from the coded bitstream, selecting a downsampling filter from a plurality of downsampling filters used for a chroma block in the CfL intra prediction mode, determining a luma sample position associated with the current chroma block based on the selected downsampling filter, downsampling a plurality of luma samples at the luma sample position such that pixels within each downsampled luma sample are arranged in the same location as corresponding pixels within the current chroma block, and reconstructing the current chroma block based on at least the plurality of downsampled luma samples.

[0007] According to an aspect of the present disclosure, a device for performing cross-component intra prediction includes at least one memory configured to store program code, and at least one processor configured to access the program code and operate as commanded by the program code. The program code includes reception code configured to cause the at least one processor to receive a current chroma block from a coded bitstream, acquisition code configured to cause the at least one processor to obtain a syntax element indicating a downsampling filter used for a luma-to-chroma (CfL) intra prediction mode from the coded bitstream, selection code configured to cause the at least one processor to select a downsampling filter from among a plurality of downsampling filters used for a chroma block in the CfL intra prediction mode, determination code configured to cause the at least one processor to determine a luma sample position associated with the current chroma block based on the selected downsampling filter, downsampling code configured to cause the at least one processor to downsample a plurality of luma samples at the luma sample position, wherein pixels within each downsampled luma sample are arranged at the same location as corresponding pixels within the current chroma block, and reconstruction code configured to cause the at least one processor to reconstruct the current chroma block based on at least the plurality of downsampled luma samples.

[0008] According to one aspect of the present disclosure, a non-transitory computer-readable medium stores instructions that, when executed by one or more processors of a device for performing cross-component intra prediction, cause the one or more processors to receive a current chroma block from a coded bitstream, obtain a syntax element indicating a downsampling filter used for a luma-to-chroma (CfL) intra prediction mode from the coded bitstream, select a downsampling filter from among a plurality of downsampling filters used for chroma blocks in the CfL intra prediction mode, determine a luma sample position associated with the current chroma block based on the selected downsampling filter, downsample a plurality of luma samples at the luma sample position such that pixels within each downsampled luma sample are placed at the same location as corresponding pixels within the current chroma block, and reconstruct the current chroma block based on at least the plurality of downsampled luma samples, including one or more instructions.

[0009] The following detailed description and the accompanying drawings will make the further features, properties and various effects of the disclosed subject matter more apparent.

Brief Description of the Drawings

[0010]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11A

Figure 11B

Figure 11C

Figure 11D

Figure 11E

Figure 12

Figure 13

Figure 14

DETAILED DESCRIPTION OF THE INVENTION

[0011] In the present disclosure, the term "block" can be interpreted as a prediction block, a coding block, or a coding unit (CU). The term "block" in this specification can also be used to refer to a transform block.

[0012] In the present disclosure, the term "conversion set" refers to a group of conversion kernel (or candidate) options. A conversion set may include one or more conversion kernel (or candidate) options. According to embodiments of the present disclosure, when two or more conversion options are available, an index may be signaled to indicate which of the conversion options within the conversion set is to be applied to the current block.

[0013] In the present disclosure, the term "prediction mode set" refers to a group of prediction mode options. A prediction mode set may include one or more prediction mode options. According to embodiments of the present disclosure, when two or more prediction mode options are available, an index may be further signaled to indicate which of the prediction mode options within the prediction mode set is to be applied to the current block for performing prediction.

[0014] In the present disclosure, the term "neighborhood reconstruction sample set" refers to a group of reconstruction samples from previously decoded neighboring blocks or reconstruction samples within a previously decoded picture.

[0015] In the present disclosure, the term "neural network" refers to the general concept of a data processing structure having one or more layers, as described herein with reference to "deep learning for video coding". According to embodiments of the present disclosure, any neural network may be configured to implement the embodiments.

[0016] FIG. 1 shows a simplified block diagram of a communication system (100) according to an embodiment of the present disclosure. The system (100) may include at least two terminals (110, 120) interconnected via a network (150). In the case of unidirectional data transmission, the first terminal (110) may code video data at a local location for transmission to the other terminal (120) via the network (150). The second terminal (120) may receive the coded video data of the other terminal from the network (150), decode the coded data, and display the restored video data. Unidirectional data transmission may be common in media serving applications and the like.

[0017] FIG. 1 shows a second pair of terminals (130, 140) provided to support bidirectional transmission of coded video that may occur, for example, during a video conference. In the case of bidirectional data transmission, each terminal (130, 140) may code video data captured at a local location for transmission to the other terminal via the network (150). Each terminal (130, 140) may also receive the coded video data transmitted by the other terminal, may decode the coded data, and may display the restored video data on a local display device.

[0018] In FIG. 1, the terminals (110 - 140) may be shown as servers, personal computers, and smartphones, and / or any other type of terminal. For example, the terminals (110 - 140) may be laptop computers, tablet computers, media players, and / or dedicated video conferencing equipment. The network (150) represents any number of networks that transmit coded video data between the terminals (110 - 140), including, for example, wired and / or wireless communication networks. The communication network (150) may exchange data over circuit - switched channels and / or packet - switched channels. Representative networks include telecommunications networks, local area networks, wide area networks, and / or the Internet. For the purposes of this discussion, the architecture and topology of the network (150) may not be important for the operation of the present disclosure, unless otherwise described below.

[0019] FIG. 2 shows the arrangement of video encoders and decoders in a streaming environment as an example of the use of the disclosed subject matter. The subject matter of the present disclosure can be equally applied to other video - related applications, such as video conferencing, digital television, storage of compressed video on digital media including CDs, DVDs, memory sticks, etc.

[0020] As shown in FIG. 2, the streaming system (200) may include a capture subsystem (213) that can include a video source (201) and an encoder (203). The video source (201) may be, for example, a digital camera and may be configured to create an uncompressed video sample stream (202). The uncompressed video sample stream (202) can provide a high data volume as compared to an encoded video bit stream and can be processed by an encoder (203) coupled to the video source (201), such as a camera. The encoder (203) can include hardware, software, or a combination thereof to enable or implement aspects of the disclosed subject matter, as will be described in more detail below. The encoded video bit stream (204) may include a lower data volume as compared to the sample stream and can be stored at the streaming server (205) for future use. One or more streaming clients (206) can access the streaming server (205) to obtain a video bit stream (209) that can be a copy of the encoded video bit stream (204).

[0021] In an embodiment, the streaming server (205) may also function as a Media Aware Network Element (MANE). For example, the streaming server (205) can be configured to prune the encoded video bit stream (204) to fit one or more of the streaming clients (206) with potentially different bit streams. In an embodiment, the MANE may be provided separately from the streaming server (205) in the streaming system (200).

[0022] The streaming client (206) can include a video decoder (210) and a display (212). The video decoder (210) can decode, for example, a video bitstream (209) that is an input copy of an encoded video bitstream (204), and generate an output video sample stream (211) that can be rendered on the display (212) or another rendering device (not shown). In some streaming systems, the video bitstreams (204, 209) can be encoded according to a specific video coding / compression standard. Examples of such standards include, but are not limited to, ITU-T Recommendation H.265. A video coding standard, informally known as Versatile Video Coding (VVC), is under development. Embodiments of the present disclosure can be used in the context of VVC.

[0023] FIG. 3 shows an exemplary functional block diagram of a video decoder (210) attached to a display (212) according to one embodiment of the present disclosure.

[0024] The video decoder (210) can include a channel (312), a receiver (310), a buffer memory (315), an entropy decoder / parser (320), a scaler / inverse transform unit (351), an intra prediction unit (352), a motion compensation prediction unit (353), an aggregator (355), a loop filter unit (356), a reference picture memory (357), and a current picture memory (). In at least one embodiment, the video decoder (210) can include an integrated circuit, a series of integrated circuits, and / or other electronic circuits. The video decoder (210) may also be partially or fully embodied in software operating on one or more CPUs having associated memory.

[0025] In this and other embodiments, the receiver (310) may receive one or more coded video sequences to be decoded by the decoder (210) one coded video sequence at a time, and the decoding of each coded video sequence is independent of other coded video sequences. The coded video sequence may be received from a channel (312) that may be a hardware / software link to a storage device storing the encoded video data. The receiver (310) may receive the encoded video data along with other data that may be transferred to respective using entities (not shown), such as coded audio data and / or auxiliary data streams. The receiver (310) may separate the coded video sequence from the other data. To counter network jitter, a buffer memory (315) may be coupled between the receiver (310) and the entropy decoder / parser (320) (hereinafter “parser”). When the receiver (310) is receiving data from a storage / transfer device with sufficient bandwidth and controllability, or from an isochronous network, the buffer memory (315) may not be used or may be small. When used in a best-effort packet network such as the Internet, the buffer memory (315) may be required and may be relatively large and may be of an adaptable size.

[0026] Video decoder (210) may include a parser (320) for reconstructing symbols (321) from an entropy-coded video sequence. The categories of these symbols include, for example, information used to manage the operation of decoder (210) and potentially information for controlling a rendering device such as a display (212) that may be coupled to the decoder as shown in FIG. 2. The control information for the rendering device may be in the form of a Supplementary Enhancement Information (SEI) message or a Video Usability Information (VUI) parameter set fragment (not shown). Parser (320) may parse / entropy-decode the received coded video sequence. The coding of the coded video sequence can be in accordance with a video coding technology or video coding standard and can follow principles well-known to those skilled in the art, including variable-length coding, Huffman coding, arithmetic coding with or without context dependence, etc. Parser (320) may extract a set of sub-group parameters of at least one sub-group of pixels within the video decoder based on at least one parameter corresponding to a group from the coded video sequence. Sub-groups can include Group of Pictures (GOP), picture, tile, slice, macroblock, Coding Unit (CU), block, Transform Unit (TU), Prediction Unit (PU), etc. Parser (320) may also extract information such as transform coefficients, quantization parameter values, motion vectors, etc. from the coded video sequence.

[0027] Parser (320) may perform an entropy decoding / parsing operation on the video sequence received from buffer memory (315) to create symbols (321).

[0028] The reconstruction of symbol (321) can involve multiple different units depending on the type of the coded video picture or a portion thereof (such as inter and intra pictures, inter and intra blocks), as well as other factors. Which units are involved and how they are involved can be controlled by subgroup control information parsed from the coded video sequence by parser (320). Such a flow of subgroup control information between parser (320) and the following multiple units is not shown for clarity.

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

[0030] One unit can be a scaler / inverse transform unit (351). The scaler / inverse transform unit (351) can receive from parser (320) quantization transform coefficients and control information including which transform to use, block size, quantization coefficients, quantization scaling matrix, etc. as symbol (321). The scaler / inverse transform unit (351) can output a block including sample values that can be input to aggregator (355).

[0031] In some cases, the output samples of the scaler / inverse transform unit (351) may be related to intra-coded blocks, i.e., blocks that do not use prediction information from previously reconstructed pictures but may use prediction information from previously reconstructed parts of the current picture. Such prediction information can be provided by the intra-picture prediction unit (352). In some cases, the intra-picture prediction unit (352) uses surrounding already reconstructed information fetched from the current (partially reconstructed) picture in the current picture memory (358) to generate a block of the same size and shape as the block being reconstructed. The aggregator (355) may, in some cases, add, sample by sample, the prediction information generated by the intra prediction unit (352) to the output sample information provided by the scaler / inverse transform unit (351).

[0032] In other cases, the output samples of the scaler / inverse transform unit (351) can be related to inter-coded, potentially motion-compensated blocks. In such cases, the motion compensation prediction unit (353) can access the reference picture memory (357) to fetch the samples used for prediction. After motion-compensating the samples fetched according to the symbols (321) related to the block, these samples can be added by the aggregator (355) to the output of the scaler / inverse transform unit (351) to generate the output sample information (in this case, called residual samples or residual signal). The address in the reference picture memory (357) from which the motion compensation prediction unit (353) fetches the prediction samples can be controlled by the motion vector. The motion vector can be in the form of, for example, a symbol (321) that can have X, Y, and reference picture components and be available to the motion compensation prediction unit (353). Motion compensation can also include interpolation of the sample values fetched from the reference picture memory (357) when an exact motion vector with sub-samples is used, a motion vector prediction mechanism, etc.

[0033] The output samples of the aggregator (355) can undergo various loop filtering techniques in the loop filter unit (356). The video compression technique is controlled by parameters included in the coded video bitstream and can include in-loop filter techniques that are made available to the loop filter unit (356) as symbols (321) from the parser (320), but can also respond to meta information obtained during the decoding of a previous part (in decoding order) of the coded picture or coded video sequence, and can also respond to previously reconstructed and loop filtered sample values.

[0034] The output of the loop filter unit (356) can be an output sample stream that can be output to a rendering device such as a display (212) and can also be stored in the reference picture memory (357) for use in future inter-picture prediction.

[0035] Once fully reconstructed, a particular coded picture can be used as a reference picture for future prediction. When a coded picture is fully reconstructed and the coded picture is identified as a reference picture (e.g., by the parser (320)), the current reference picture can become part of the reference picture memory (357), and a new current picture memory can be reallocated before starting the reconstruction of the next coded picture.

[0036] The video decoder (210) can perform a decoding operation according to a predetermined video compression technology that can be documented in a standard such as ITU-T Rec.H.265. The coded video sequence can conform to the syntax specified by the video compression technology or standard being used, in the sense that it is faithful to the syntax of the video compression technology or standard as specified in the video compression technology document or standard, specifically the profile document therein. Also, in order to conform to some video compression technology or standard, the complexity of the coded video sequence can also be within the range defined by the level of the video compression technology or standard. In some cases, the level limits, for example, the maximum picture size, the maximum frame rate, the maximum reconstruction sample rate (measured in megasamples per second, for example), the maximum reference picture size, etc. The limitations set by the level may, in some cases, be further restricted by the virtual reference decoder (HRD) specification and the metadata of the HRD buffer management conveyed in the coded video sequence.

[0037] In one embodiment, the receiver (310) can receive additional (redundant) data together with the encoded video. The additional data can be included as part of the coded video sequence. The additional data can be used by the video decoder (210) to properly decode the data and / or to more accurately reconstruct the original video data. The additional data can be in the form of, for example, a temporal layer, a spatial layer, or an SNR enhancement layer, a redundant slice, a redundant picture, a forward error correction code, etc.

[0038] FIG. 4 shows an exemplary functional block diagram of a video encoder (203) associated with a video source (201) according to an embodiment of the present disclosure.

[0039] The video encoder (203) may include, for example, an encoder such as a source coder (430), a coding engine (432), a (local) decoder (433), a reference picture memory (434), a predictor (435), a transmitter (440), an entropy coder (445), a controller (450), and a channel (460).

[0040] The encoder (203) may receive video samples from a video source (201) (which is not part of the encoder) that may capture a video image to be coded by the encoder (203).

[0041] The video source (201) may provide a source video sequence to be coded by the encoder (203) in the form of a digital video sample stream that can be of any suitable bit depth (e.g., 8 bits, 10 bits, 12 bits, …), any color space (e.g., BT.601 Y CrCB, RGB, …), and any suitable sampling structure (e.g., Y CrCb 4:2:0, Y CrCb 4:4:4). In a media supply system, the video source (201) can be a storage device that stores previously prepared video. In a video conferencing system, the video source (201) can be a camera that captures local image information as a video sequence. The video data may be provided as a plurality of individual pictures that convey motion when viewed in sequence. Each picture itself may be organized as a spatial array of pixels, and each pixel can include one or more samples depending on the sampling structure, color space, etc. used. Those skilled in the art can easily understand the relationship between pixels and samples. The following description focuses on samples.

[0042] According to one embodiment, the encoder (203) can code and compress the pictures of the source video sequence into the coded video sequence (443) in real time or under any other arbitrary time constraints required by the application. Enforcing an appropriate coding speed is one function of the controller (450). The controller (450) may also control other functional units as will be described later and may be functionally coupled to these units. The couplings are not shown for clarity. The parameters set by the controller (450) can include rate control related parameters (such as picture skip, quantizer, lambda value of rate distortion optimization techniques), group of pictures (GOP) layout, maximum motion vector search range, and the like. Those skilled in the art can easily identify other functions of the controller (450) since they can be related to the video encoder (203) optimized for a particular system design.

[0043] Some video encoders operate in what those skilled in the art would readily recognize as a "coding loop." As an overly simplified explanation, the coding loop can consist of an encoding portion of a source coder (430) (which is responsible for creating symbols based on input pictures and reference pictures to be coded) and an (local) decoder (433) incorporated in an encoder (203) that reconstructs symbols to create sample data that a (remote) decoder would also create when the compression between the symbols and the coded video bitstream is reversible in a particular video compression technique. The reconstructed sample stream can be input into a reference picture memory (434). Since bit-exact results are obtained regardless of the position of the decoder (local or remote) by decoding the symbol stream, the contents of the reference picture memory are also bit-exact between the local encoder and the remote encoder. In other words, the prediction portion of the encoder "sees" the same sample values as the reference picture samples that the decoder will "see" when using prediction during decoding. This basic principle of the synchronization of reference pictures (and the resulting drift if, for example, the synchronization cannot be maintained due to channel errors) is known to those skilled in the art.

[0044] The operation of the "local" decoder (433) may be the same as that of the "remote" decoder (210), which has already been described in detail above in connection with Figure 3. However, since the symbols are available and the encoding / decoding of the symbols into the coded video sequence by the entropy coder (445) and the parser (320) can be reversible, the entropy decoding portion of the decoder (210) including the channel (312), the receiver (310), the buffer (315), and the parser (320) may not be fully implemented in the local decoder (433).

[0045] What can be said at this point is that any decoder technology other than the parse / entropy decoding existing in the decoder may need to exist in substantially the same functional form in the corresponding encoder. For this reason, the subject matter of the disclosure focuses on decoder operations. The description of encoder technologies can be omitted because they can be the reverse of the decoder technologies described comprehensively. More detailed descriptions are needed only in specific areas and are shown below.

[0046] As part of the operation, the source coder (430) may perform motion-compensated predictive coding that predictively codes an input frame by referring to one or more previously coded frames from a video sequence designated as a "reference frame". In this way, the coding engine (432) codes the difference between a pixel block of the input frame and a pixel block of a reference frame that can be selected as a predictive reference to the input frame.

[0047] The local video decoder (433) may decode the coded video data of a frame that can be designated as a reference frame based on the symbols created by the source coder (430). The operation of the coding engine (432) may advantageously be an irreversible process. When the coded video data can be decoded by a video decoder (not shown in FIG. 4), the reconstructed video sequence may usually be a reproduction of the source video sequence with some error. The local video decoder (433) may reproduce the decoding process that may be performed by the video decoder for the reference frame and cause the reconstructed reference frame to be stored in the reference picture memory (434). In this way, the encoder (203) may locally store a copy of the reconstructed reference frame having the same content as the reconstructed reference frame obtained by the remote video decoder (without transmission errors).

[0048] The predictor (435) may perform predictive search of the coding engine (432). That is, for a new frame to be coded, the predictor (435) may find specific metadata such as sample data (as candidate reference pixel blocks) or reference picture motion vectors, block shapes, etc. that can serve as appropriate predictive references for the new picture, and search the reference picture memory (434). The predictor (435) may operate on one sample block for each pixel block to find an appropriate predictive reference. In some cases, the input picture may have predictive references drawn from a plurality of reference pictures stored in the reference picture memory (434), as determined by the search results obtained by the predictor (435).

[0049] The controller (450) may manage the coding operations of the video coder (430), including, for example, setting parameters and subgroup parameters used to encode video data.

[0050] The outputs of all the aforementioned functional units may be entropy-coded by the entropy coder (445). The entropy coder converts the symbols generated by various functional units into a coded video sequence by reversibly compressing the symbols according to techniques known to those skilled in the art, such as Huffman coding, variable-length coding, arithmetic coding, etc.

[0051] The transmitter (440) may buffer the coded video sequence created by the entropy coder (445) in preparation for transmission via a communication channel (460), which may be a hardware / software link to a storage device that will store the encoded video data. The transmitter (440) may merge the coded video data from the video coder (430) with other data to be transmitted, such as coded audio data and / or an auxiliary data stream (source not shown).

[0052] The controller (450) may manage the operation of the encoder (203). During coding, the controller (450) may assign a specific coded picture type to each coded picture, which may affect the coding technique applicable to each picture. For example, a picture may often be assigned as an intra picture (I picture), a predicted picture (P picture), or a bi-directionally predicted picture (B picture).

[0053] An intra picture (I picture) may be a picture that can be coded and decoded without using any other frame in the sequence as a source of prediction. Some video codecs allow various types of intra pictures, including, for example, an Instantaneous Decoder Refresh (IDR) picture. Those skilled in the art are aware of these variations of I pictures and their respective uses and characteristics.

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

[0055] A bi-directionally predicted picture (B picture) may be one that can be coded and decoded using intra prediction or inter prediction that uses at most two motion vectors and reference indices to predict the sample values of each block. Similarly, multiple predicted pictures can use three or more reference pictures and associated metadata for the reconstruction of a single block.

[0056] The source picture can generally be spatially subdivided into a plurality of sample blocks (e.g., blocks of samples of 4×4, 8×8, 4×8, or 16×16 each) and can be coded block by block. The blocks can be coded predictively by referring to other (already coded) blocks as determined by the coding assignment applied to each block of the picture. For example, blocks of an I picture may be coded non-predictively or may be coded predictively by referring to already coded blocks of the same picture (spatial prediction or intra prediction). Pixel blocks of a P picture can be coded non-predictively via spatial prediction or via temporal prediction that refers to one previously coded reference picture. Blocks of a B picture can be coded non-predictively by referring to one or two previously coded reference pictures and via spatial prediction or via temporal prediction.

[0057] The video coder (203) can perform coding operations according to a predetermined video coding technology or standard such as ITU-T Rec.H.265. In its operation, the video coder (203) can perform various compression operations including predictive coding operations that utilize temporal and spatial redundancies in the input video sequence. Thus, the coded video data can conform to the syntax specified by the video coding technology or standard being used.

[0058] In one embodiment, the transmitter (440) can transmit additional data along with the encoded video. The video coder (430) can include such data as part of the coded video sequence. The additional data can include temporal layer / spatial layer / SNR enhancement layer, other forms of redundant data such as redundant pictures and slices, supplementary enhancement information (SEI) messages, visual user utility information (VUI) parameter set fragments, and the like.

[0059] [Directional Intra Prediction in AV1] VP9 supports eight directional modes corresponding to angles from 45 degrees to 207 degrees. To exploit more diverse spatial redundancy in the direction texture, in AV1, the directional intra mode is extended to angles set with finer granularity. The original eight angles are slightly modified to be nominal angles, and these eight nominal angles are named V_PRED(542), H_PRED(543), D45_PRED(544), D135_PRED(545), D113_PRED(5446), D157_PRED(547), D203_PRED(548), and D67_PRED(549), which are shown in Figure 5 with respect to the current block(541). For each nominal angle, there are seven finer angles, so AV1 has a total of 56 direction angles. The prediction angle is presented by the nominal intra angle + delta angle, which is -3 to 3 times the step size of 3 degrees. In AV1, eight nominal modes are first signaled along with five non-angle smoothing modes. Next, if the current mode is an angle mode, an index is further signaled to indicate the angle delta with respect to the corresponding nominal angle. To implement the directional prediction mode in AV1 by a general method, all 56 directional intra prediction modes of AV1 are implemented using a unified direction predictor that projects each pixel to a reference sub-pixel position and interpolates the reference pixels by a 2-tap bilinear filter.

[0060] [Non-directional Smoothing Intra Predictor in AV1] In AV1, there are five non - directional smoothing intra - prediction modes: DC, PAETH, SMOOTH, SMOOTH_V, and SMOOTH_H. In DC prediction, the average value of the left and upper neighboring samples is used as the predictor for the block to be predicted. In the case of the PAETH predictor, first the upper, left, and upper - left reference samples are fetched, and then the value closest to (upper + left - upper - left) is set as the predictor for the pixel to be predicted. Figure 6 shows the positions of the upper sample (554), left sample (556), and upper - left sample (558) of the pixel (552) within the current block (550). In the SMOOTH mode, SMOOTH_V mode, and SMOOTH_H mode, the current block (550) is predicted using vertical or horizontal bilinear interpolation, or the average value in both directions.

[0061] [Chroma predicted from luma] In addition to the above - mentioned modes, Chroma from Luma (CfL) is a chroma - only intra - predictor that models chroma pixels as a linear function of the corresponding reconstructed luma pixels. The CfL prediction can be expressed as in the following equation (1). CfL(α)=α×L AC +DC (Equation 1) In Equation (1), L AC represents the AC contribution of the luma component, α represents the parameter of the linear model, and DC represents the DC contribution of the chroma component.

[0062] Figure 7 is a graph of the linear function described by Equation (1). As can be seen from Figure 7 and Equation (1), the reconstructed luma pixels are subsampled to chroma resolution and then the average value is subtracted to form the AC contribution. Instead of requiring the decoder to calculate a scaling parameter as in some prior arts to approximate the chroma AC component from the AC contribution, AV1 CfL determines the parameter α based on the original chroma pixels and signals them in the bitstream. This reduces the complexity of the decoder and obtains a more accurate prediction. Regarding the DC contribution of the chroma component, it is sufficient for most chroma contents and can be calculated using the intra DC mode which has a mature high-speed implementation form.

[0063] In CfL mode, when some samples within a luma block placed at the same location are outside the picture boundary, these samples can be padded and used to calculate the average of the luma samples. As shown in Figure 8, the samples within region 802 of the current block 800 are outside the picture as indicated by the picture boundary 804, and these samples can be padded by copying the values of the nearest available samples within the current block 800, for example, the samples included in region 806 of the current block 800.

[0064] In CfL mode, as shown in Figure 7, the luma subtraction step is combined with the average subtraction step. In this way, not only is the equation simplified, but also the subsampling division and the corresponding rounding error are removed. An example of the equation corresponding to the combination of both steps is given in Equation (2), which can be simplified to form Equation (3).

Equation

[0065] Note that both equations use integer division. M×N represents a matrix of pixels in the luma plane.

[0066] Based on the supported chroma subsampling, it can be shown that \(S_x\times S_y\in\{1,2,4\}\), and since both \(M\) and \(N\) are powers of 2, \(M\times N\) is also a power of 2.

[0067] For example, in the context of 4:2:0 chroma subsampling, instead of applying a box filter, the proposed approach may simply sum the four reconstructed luma pixels that coincide with the chroma pixels. That is, use a 4-tap \(\{1 / 4, 1 / 4, 1 / 4, 1 / 4, 1 / 4\}\) filter to downsample the luma samples located at the same position and adjust the chroma resolution. Then, when CfL scales that luma pixel to improve the prediction accuracy, the approach of some embodiments described herein may scale by only 2.

[0068] [Chroma Downsampling Format] In embodiments, there may be different chroma downsampling phases, i.e., different YUV formats depending on the chroma format, an example of which is shown in FIG. 9. Different chroma formats define different downsampling grids or phases for different color components. In the case of the 4:2:0 format, as shown in FIG. 9, there can be two different downsampling formats, sometimes referred to as 4:2:0 MPEG1 or 4:2:0 MPEG2.

[0069] [Downsampling Filter] In the case of the luma downsampling filter in AV1, the following equation (4) is applied to derive the reconstructed luma samples.

Equation

[0070] In the above equation (4) and the following equations, rec’ L represents the pixel value of the reconstructed luma pixel that is downsampled at the position \((i,j)\) which can be the position of the corresponding chroma pixel. Also, recL (x, y) represents the reconstructed luma sample value located at position (x, y).

[0071] The downsampling filter in AV1 assumes the chroma downsampling format 1000 shown in FIG. 10, which may correspond to the 4:2:0 MPEG1 downsampling format of FIG. 9. In particular, FIG. 10 shows a chroma sample 1002 and four corresponding luma samples 1004 indexed from 0 to 3. In an embodiment, the chroma sample may be a chroma pixel, and the luma sample may be a luma pixel. In an embodiment, the luma sample may be used to determine the value of the downsampled luma sample corresponding to the chroma sample or the value of the downsampled luma pixel corresponding to the chroma pixel according to the above formula (4).

[0072] In some implementations of the CfL mode, only one downsampling filter is supported, but in some content or different chroma downsampling formats, the current proprietary downsampling filter may not be the optimal filter.

[0073] Therefore, an embodiment may provide support for multiple downsampling filters for luma reconstruction samples when a cross-component prediction mode, such as the CfL prediction mode, is selected.

[0074] The embodiment may also be applied to modes other than the CfL prediction mode. For example, it may be another prediction mode that uses one color component to predict another color component that requires downsampling in one or more color components. Therefore, for example, the embodiment may be applied by replacing luma with any specific color component (e.g., R) and chroma with another specific color component (e.g., G or B).

[0075] Examples of downsampling filters according to the embodiment are provided below.

[0076] Example 1 According to Example 1, a 6-tap filter can be supported for a cross-component downsampling process, for example, for a CfL luma downsampling process. FIG. 11A shows a chroma downsampling format 1110 corresponding to a 6-tap filter according to an embodiment. As can be seen from FIG. 11A, the chroma downsampling format 1110 includes chroma samples 1112 and six corresponding luma samples 1114 indexed from 0 to 5. In an embodiment, the luma samples 1114 can be reconstructed luma samples that can be used to derive downsampled luma pixels corresponding to the chroma samples 1112 that can be located at position (i,j) based on the following equation (5). [Number]

[0077] In the above equation (5) and other equations described herein, "rounding" can represent a rounding value. In equation (5), the rounding value can be, for example, 0 or 4. In an embodiment, the 6-tap downsampling filter can assume that the chroma downsampling format corresponds to a 4:2:0 MPEG2 downsampling format.

[0078] Example 2 According to Example 2, the 5-tap filter can be supported for a cross-component downsampling process, for example, a CfL luma downsampling process. FIG. 11B shows a chroma downsampling format 1120 corresponding to a 5-tap filter according to an embodiment. As can be seen from FIG. 11B, the chroma downsampling format 1110 includes a chroma sample 1122 and five corresponding luma samples 1124 indexed from 0 to 4. In an embodiment, the luma sample 1124 corresponding to index 4 may be arranged at the same location as the chroma sample 1122. In an embodiment, the luma sample 1124 may be a reconstructed luma sample, which can be used to derive a downsampled luma pixel corresponding to the chroma sample 1122 that may be located at position (i,j) based on one of the following equations (6) and (7).

Number

[0079] In an embodiment, the rounding value may be 0 or non-zero. For example, in Equation (6), the rounding value may be 4, and in Equation (7), the rounding value may be 8.

[0080] In an embodiment, when a sample is not available from the upper row, the current row pixel (for example, the luma sample 1124 located at index 4) can be used to pad the upper sample (for example, the luma sample 1124 located at index 0). In an embodiment, when the current sample is located at a superblock / CTU boundary, the current row pixel can be used to pad the sample located at the sample position with index 0.

[0081] Example 3 According to Example 3, the 4-tap filter can be supported for a cross-component downsampling process, for example, a CfL luma downsampling process. FIG. 11C shows a chroma downsampling format 1130 corresponding to the 4-tap filter according to an embodiment. As can be seen from FIG. 11C, the chroma downsampling format 1130 includes a chroma sample 1132 and four corresponding luma samples 1134 indexed from 0 to 3. In an embodiment, the luma sample 1124 corresponding to index 3 may be arranged at the same location as the chroma sample 1132. In an embodiment, the luma samples 1134 may be reconstructed luma samples, which can be used to derive the downsampled luma pixels corresponding to the chroma sample 1132 that can be located at position (i,j) based on one of the following equations (8) and (9).

Number

[0082] In an embodiment, the rounding value may be 0 or non-zero. For example, in Equation (8), the rounding value may be 4, and in Equation (9), the rounding value may be 8.

[0083] Example 4 According to Example 4, another 4-tap filter can be supported for a cross-component downsampling process, e.g., a CfL luma downsampling process. FIG. 11D shows a chroma downsampling format 1140 corresponding to a 4-tap filter according to an embodiment. As can be seen from FIG. 11D, the chroma downsampling format 1140 includes a chroma sample 1142 and four corresponding luma samples 1144 indexed from 0 to 3. In an embodiment, the luma sample 1144 corresponding to index 3 may be placed in the same location as the chroma sample 1142. In an embodiment, the luma samples 1144 may be reconstructed luma samples, which can be used to derive the downsampled luma pixels corresponding to the chroma sample 1142 that can be located at position (i,j) based on either of the following equations (10) and (11).

Number

[0084] In an embodiment, the rounding value may be 0 or non-zero. For example, in Equation (10), the rounding value may be 4, and in Equation (11), the rounding value may be 8.

[0085] Example 5 According to Example 5, the 3-tap filter can be supported for a cross-component downsampling process, for example, a CfL luma downsampling process. FIG. 11E shows a chroma downsampling format 1150 corresponding to the 3-tap filter according to an embodiment. As can be seen from FIG. 11E, the chroma downsampling format 1150 includes a chroma sample 1152 and three corresponding luma samples 1154 indexed from 0 to 2. In an embodiment, the luma sample 1154 corresponding to index 1 may be arranged at the same location as the chroma sample 1152. In an embodiment, the luma sample 1154 may be a reconstructed luma sample, which can be used to derive a downsampled luma pixel corresponding to the chroma sample 1152 that may be located at position (i,j) based on either of the following equations (12) and (13).

Equation

[0086] In an embodiment, the rounding value may be 0 or non-zero. For example, in Equation (12), the rounding value may be 4, and in Equation (13), the rounding value may be 8.

[0087] In an embodiment, in addition to the filter corresponding to Equation (4) and the downsampling format 1000 of AV1, the filters described in Examples 1 to 5 can be supported when a downsampling process of luma reconstructed samples is required.

[0088] In one embodiment, N filters can be used, and N can be 1, 2, 3, 4, 5, or 6. In an embodiment, when N is 4, the filters corresponding to Examples 1 to 3 and the AV1 filter corresponding to Equation (4) can be used. In an embodiment, when N is 3, the filters corresponding to Examples 1 and 2 and the AV1 filter corresponding to Equation (4) can be used. In an embodiment, when N is 3, the filters corresponding to Examples 1 and 3 and the AV1 filter corresponding to Equation (4) can be used.

[0089] In an embodiment, the high-level syntax flag / index can be signaled to indicate which downsampling filter is used in a cross-component intra prediction mode such as the CfL prediction mode or other downsampling processes, which requires downsampling luma to a lower resolution and is involved in the encoding / decoding process that aligns with chroma. In an embodiment, the high-level flag / index can be signaled in at least one of a sequence header or a sequence parameter set (SPS), a picture parameter set (PPS), an adaptive parameter set (APS), a video parameter set (VPS), a slice header (SH), a picture header (PH), a frame header, a tile header, a coding tree unit (CTU) header, a superblock header, and a block having a specific predefined block size (e.g., 32×32, 64×64).

[0090] In an embodiment, the downsampling filter can be signaled on a per-pixel basis, and the tap coefficients at nine positions around the luma pixels located at the same location can be signaled. In one embodiment, when signaling the filter coefficients, the filter coefficients corresponding to the positions located at the same location can be associated with a larger size. FIG. 12 shows an example of nine positions indexed from 0 to 8. In an embodiment, the center position (index 4) may be located at the same location as the chroma sample.

[0091] In an embodiment, the filter coefficient may be signaled in at least one of a sequence header, SPS, PPS, APS, VPS, SH, PH, a frame header, a tile header, a CTU / superblock header, and a block having a specific predefined block size (e.g., 32×32, 64×64).

[0092] FIG. 13 is a flowchart of a process 1300 for performing cross-component intra prediction according to an embodiment.

[0093] As shown in FIG. 13, in operation 1302, process 1300 includes receiving a current chroma block from the coded bitstream.

[0094] As further shown in FIG. 13, in operation 1304, process 1300 includes obtaining, from the coded bitstream, a syntax element indicating a downsampling filter used for the chroma from luma (CfL) intra prediction mode. In an embodiment, the downsampling filter may be any of the filters described above with respect to Examples 1-5, and the filters corresponding to Equation 4 and FIG. 10. In an embodiment, the syntax element may be the high-level flag or index described above. In an embodiment, the syntax element may be signaled in at least one of a sequence header, a sequence parameter set, a picture parameter set, an adaptive parameter set, a video parameter set, a slice header, a picture header, a frame header, a tile header, a coding tree unit header, a superblock header, or a block having a predetermined block size.

[0095] As further shown in FIG. 13, in operation 1306, process 1300 includes selecting a downsampling filter from among a plurality of downsampling filters used for a chroma block in the CfL intra prediction mode.

[0096] As further shown in FIG. 13, in operation 1308, process 1300 includes determining the luma sample positions associated with the current chroma block based on the selected downsampling filter.

[0097] As further shown in FIG. 13, in operation 1310, process 1300 includes downsampling a plurality of luma samples at the luma sample positions, wherein the pixels within each downsampled luma sample are arranged in the same location as the corresponding pixels within the current chroma block. In an embodiment, operation 1310 may be implemented using any one or more of the above-described equations (4)-(13).

[0098] As further shown in FIG. 13, in operation 1312, process 1300 includes reconstructing the current chroma block based on at least the plurality of downsampled luma samples.

[0099] FIG. 13 shows an example block of process 1300. However, in some implementations, process 1300 may include additional blocks, fewer blocks, different blocks, or blocks in a different arrangement compared to those shown in FIG. 13. In addition to or instead of this, two or more of the blocks of process 1300 may be executed in parallel.

[0100] Furthermore, the proposed method may be implemented by a processing circuit (e.g., one or more processors or one or more integrated circuits). In one example, a program stored on a non-transitory computer-readable medium is executed by one or more processors to implement one or more of the proposed methods.

[0101] The techniques of the embodiments of the present disclosure described above can be implemented as computer software physically stored on one or more computer-readable media using computer-readable instructions. For example, FIG. 14 shows a computer system (900) suitable for implementing an embodiment of the disclosed subject matter.

[0102] The computer software can be coded using any suitable machine code or computer language and be the subject of assembly, compilation, linking, or similar mechanisms to create code that includes instructions executable directly by a computer central processing unit (CPU), a graphics processing unit (GPU), etc., or through interpretation, microcode execution, etc.

[0103] The instructions can be executed on various types of computers or their components, including, for example, personal computers, tablet computers, servers, smartphones, game devices, Internet of Things devices, etc.

[0104] The components shown in FIG. 14 with respect to the computer system (900) are exemplary in nature and are not intended to suggest any limitation regarding the use or functionality scope of the computer software implementing the embodiments of the present disclosure. The configuration of the components should not be construed as having any dependency or requirement regarding any one or combination of the components shown in the exemplary embodiment of the computer system (900).

[0105] The computer system (900) may include a specific human interface input device. Such a human interface input device may respond to input by one or more human users via, for example, tactile input (e.g., keystrokes, swipes, movement of a data glove), audio input (e.g., voice, clapping), visual input (e.g., gestures), olfactory input (not shown). The human interface device can also be used to capture specific media that is not necessarily directly related to conscious human input, such as audio (speech, music, ambient sound, etc.), images (scanned images, photographic images obtained from a still image camera, etc.), video (2D video, 3D video including stereoscopic video, etc.).

[0106] The input human interface device may include one or more (only one of each shown) of a keyboard (901), a mouse (902), a trackpad (903), a touch screen (910), a data glove, a joystick (905), a microphone (906), a scanner (907), and a camera (908).

[0107] The computer system (900) may also include certain human interface output devices. Such human interface output devices can stimulate the senses of one or more human users, for example, by tactile output, sound, light, and smell / taste. Such human interface output devices can include tactile output devices (e.g., tactile feedback by a touch screen (910), a data glove, or a joystick (905), although there can also be tactile feedback devices that do not function as input devices). For example, such devices can include audio output devices (such as speakers (909), headphones (not shown)), visual output devices (screens (910) including CRT screens, LCD screens, plasma screens, OLED screens, each with or without a touch screen input function and each with or without a tactile feedback function, some of which can output two-dimensional vision, or stereoscopic images, or output in four or more dimensions by means such as virtual reality glasses (not shown), holographic displays, and smoke tanks (not shown)), and printers (not shown).

[0108] The computer system (900) may also include optical media such as a CD / DVD ROM / RW (920) having a CD / DVD or similar medium (921), a thumb drive (922), a removable hard drive or solid state drive (923), legacy magnetic media such as tapes and floppy disks (not shown), special ROM / ASIC / PLD-based devices such as security dongles (not shown), etc., and human-accessible storage devices and the media associated therewith.

[0109] One of ordinary skill in the art should also understand that the term "computer-readable medium" as used in connection with the subject matter of this disclosure does not include a transmission medium, a carrier wave, or other transient signals.

[0110] The computer system (900) can also include an interface to one or more communication networks. The network can be, for example, wireless, wired, optical. The network can further be local, wide area, metropolitan, vehicle and industrial, real-time, delay tolerant, etc. Examples of networks include local area networks such as Ethernet, wireless LAN, cellular networks including GSM, 3G, 4G, 5G, LTE, etc., television wired or wireless wide area digital networks including cable television, satellite television, and terrestrial broadcast television, vehicle and industrial including CANBus, etc. A particular network generally requires an external network interface adapter attached to a particular general-purpose data port or peripheral bus (949) (e.g., a USB port of the computer system (900)). Other networks are generally integrated into the core of the computer system 900 by attachment to a system bus as described later (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 (900) can communicate with other entities. Such communication can be only unidirectional reception (e.g., broadcast TV), only unidirectional transmission (e.g., CANbus to a particular CANbus device), or bidirectional with other computer systems using, for example, local or wide area digital networks. Such communication can include communication to a cloud computing environment (955). Specific protocols and protocol stacks can be used for each of those networks and network interfaces as described above.

[0111] The aforementioned human interface device, human-accessible storage device, and network interface (954) can be attached to the core (940) of the computer system (900).

[0112] The core (940) can include one or more central processing units (CPUs) (941), a graphics processing unit (GPU) (942), a dedicated programmable processing device in the form of a field-programmable gate array (FPGA) (943), a hardware accelerator (944) for specific tasks, etc. These devices can be connected via a system bus (948) together with a read-only memory (ROM) (945), a random access memory (946), an internal mass storage (947) such as an internal non-user-accessible hard drive, SSD, etc. In some computer systems, the system bus (948) can be accessible in the form of one or more physical plugs to enable expansion by additional CPUs, GPUs, etc. Peripheral devices can be attached directly to the system bus (948) of the core or via a peripheral bus (949). Architectures for peripheral buses include PCI, USB, etc. The graphics adapter (950) may be included in the core (940).

[0113] The CPU (941), GPU (942), FPGA (943), and accelerator (944) can execute specific instructions that can together constitute the aforementioned computer code. That computer code can be stored in the ROM (945) or RAM (946). Also, transitional data can be stored in the RAM (946), while persistent data can be stored, for example, in the internal mass storage (947). Fast storage and retrieval for any of the memory devices can be enabled using a cache memory that can be closely associated with one or more CPUs (941), GPUs (942), mass storage (947), ROM (945), RAM (946), etc.

[0114] A computer-readable medium can have computer code thereon for performing various computer-implemented operations. The media and the computer code can be those specially designed and constructed for the purposes of this disclosure, or they can be of the kind well-known and available to those of ordinary skill in the computer software arts.

[0115] Rather than being limiting, by way of example, the architecture corresponding to computer system (900), and in particular core (940), can provide functionality as a result of software embodied on one or more tangible computer-readable media being executed by a processor (including a CPU, GPU, FPGA, accelerator, etc.). Such computer-readable media can be associated with user-accessible mass storage as described above, as well as media specific to core (940) that is non-transitory in nature, such as core internal mass storage (947) or ROM (945). The software implementing various embodiments of the present disclosure can be stored on such devices and executed by core (940). The computer-readable media can include one or more memory devices or chips according to specific needs. The software can cause core (940), and specifically the processor therein (including a CPU, GPU, FPGA, etc.), to define data structures stored in RAM (946) and modify such data structures according to processes defined by the software, thereby executing specific processes described herein, or specific parts of specific processes. Additionally or alternatively, the computer system can provide functionality as a result of logic wired or otherwise embodied in a circuit (e.g., accelerator (944)) that can operate instead of or in conjunction with software to execute specific processes described herein or specific parts of specific processes. Where appropriate, references to software can include logic and vice versa. References to computer-readable media can, as needed, include circuits (such as integrated circuits (ICs)) that store software for execution, circuits that embody logic for execution, or both. The present disclosure encompasses any suitable combination of hardware and software.

[0116] Embodiments of the present disclosure may be used individually or combined in any order. Further, each of the embodiments (and their methods) may be implemented by a processing circuit (e.g., one or more processors or one or more integrated circuits). In one example, one or more processors execute a program stored on a non-transitory computer-readable medium.

[0117] The foregoing disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit the embodiments to the precise forms disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementation forms.

[0118] As used herein, the term element is intended to be construed broadly as hardware, firmware, or a combination of hard and soft.

[0119] Combinations of features are described in the claims and / or disclosed herein, but these combinations are not intended to limit the disclosure of possible implementation forms. In fact, many of these features may be combined in ways not explicitly recited in the claims and / or not explicitly disclosed in the specification. Each of the dependent claims listed below may depend directly on only one claim, but the disclosure of possible implementation forms includes each dependent claim in combination with all other claims in the claim set.

[0120] Elements, acts, or instructions used in this specification are not to be construed as critical or essential, unless so specified. Also, as used in this specification, the articles "a" and "an" are intended to include one or more items and may also be used in the sense of "one or more." Further, as used in this specification, "set" is intended to include one or more items (e.g., related items, unrelated items, combinations of related and unrelated items, etc.) and may also be used in the sense of "one or more." Where only one item is intended, the term "one" or similar descriptive expressions are used. Also, terms such as "has," "have," "having," etc., as used in this specification, are intended to be open-ended terms. Further, the phrase "based on" is intended to mean "at least partially based on" unless otherwise specified.

[0121] Although the present disclosure describes some non-limiting and exemplary embodiments, there are changes, substitutions, and various alternative equivalents within the scope of the present disclosure. Thus, those skilled in the art will understand that, although not explicitly illustrated or described herein, many systems and methods that embody the principles of the present disclosure and are thus within the spirit and scope of the present disclosure can be devised.

Description of Reference Numerals

[0122] 100 Communication system, 110 Terminal, 120 Terminal, 130 Terminal, 140 Terminal, 150 Network, 200 Streaming system, 201 Video source, 202 Uncompressed video sample stream, 203 Encoder, 204 Encoded video bit stream, 205 Streaming server, 206 Streaming client, 209 Video bit stream, 210 Video decoder, 211 Output video sample stream, 212 Display, 213 Capture subsystem, 310 Receiver, 312 Channel, 315 Buffer memory, 320 Entropy decoder / parser, 321 Symbol, 351 Scaler / inverse transform unit, 352 Intra prediction unit, 353 Motion compensation prediction unit, 355 Aggregator, 356 Loop filter unit, 357 Reference picture memory, 358 Current picture memory, 430 Source coder, 432 Coding engine, 433 (Local) decoder, 434 Reference picture memory, 435 Predictor, 440 Transmitter, 445 Entropy coder, 450 Controller, 460 Channel, 541 Current block, 542 V_PRED, 543 H_PRED, 544 D45_PRED, 545 D135_PRED, 546 D113_PRED, 547 D157_PRED, 548 D203_PRED, 549 D67_PRED, 550 Current block, 552 Pixel, 554 Up sample, 556 Left sample, 558 Upper left sample, 800 Block, 802 Region, 804 Picture boundary, 806 Region, 900 Computer system, 901 Keyboard, 902 Mouse, 903 Track pad, 905 Joystick, 906 Microphone, 907 Scanner, 908 Camera, 909 Speaker, 910 Touch screen, 920 CD / DVD ROM / RW, 921 CD / DVD, 922 Thumb drive, 923 Removable hard drive or solid state drive, 940 Core, 941 Central processing unit (CPU), 942 Graphics processing unit (GPU), 943 Field programmable gate array (FPGA), 944 Hardware accelerator, 945Read-only memory (ROM), 946 Random access memory, 947 Internal mass storage, 948 System bus, 949 Specific general-purpose data port or peripheral bus, 950 Graphics adapter, 954 Network interface, 955 Cloud computing environment, 1000 Chroma downsampling format, 1002 Chroma sample, 1004 Luma sample, 1110 Chroma downsampling format, 1112 Chroma sample, 1114 Luma sample, 1122 Chroma sample, 1124 Luma sample, 1130 Chroma downsampling format, 1132 Chroma sample, 1134 Luma sample, 1140 Chroma downsampling format, 1142 Chroma sample, 1144 Luma sample, 1150 Chroma downsampling format, 1152 Chroma sample, 1154 Luma sample

Claims

1. A method for cross-component intra prediction executed by at least one processor, comprising: receiving a current chroma block from a coded bitstream; obtaining, from the coded bitstream, a syntax element indicating a downsampling filter to be used for a luma-to-chroma (CfL) intra prediction mode; selecting the downsampling filter from among a plurality of downsampling filters used for the chroma blocks of the CfL intra prediction mode; determining a luma sample position associated with the current chroma block based on the selected downsampling filter; downsampling a plurality of luma samples at the luma sample location, wherein pixels in each downsampled luma sample are co-located with corresponding pixels in the current chroma block; reconstructing the current chroma block based on at least the plurality of downsampled luma samples; A method comprising:

2. the plurality of downsampling filters (1) A 6-tap filter and (2) 5-tap filter and (3) a 4-tap filter comprising a block in which the luma samples are co-located with the current chroma block or one of a block to the left, below, and right of the current chroma block; (4) a 4-tap filter comprising the block in which the plurality of luma samples are co-located with the current chroma block or the block in one of the right direction, the bottom direction, or the diagonal direction of the current chroma block; (5) 3-tap filter and The method of claim 1 , comprising:

3. the downsampling filter comprises a 6-tap filter; a pixel value for each downsampled luma sample is determined according to the following formula: [Equation 1] where the current chroma block is located at position (i, j) and rec' L denotes the pixel value of each downsampled luma sample, and rec L where (x, y) denotes the luma sample located at luma sample position (x, y), and R denotes the rounding value. The method of claim 1.

4. the downsampling filter comprises a 5-tap filter; The pixel value of each downsampled luma sample is expressed as a first equation: [Equation 2] and the second equation below: [Equation 3] is determined according to at least one of where the current chroma block is located at position (i, j) and rec' L denotes the pixel value of each downsampled luma sample, and rec L where (x, y) denotes the luma sample located at luma sample position (x, y), and R denotes the rounding value. The method of claim 1.

5. the downsampling filter comprises a 4-tap filter; One luma sample is co-located with the current chroma block. The method of claim 1.

6. The pixel value of each downsampled luma sample is expressed as a first equation: [Equation 4] and the second equation below: [Equation 5] is determined according to at least one of where the current chroma block is located at position (i, j) and rec' L denotes the pixel value of each downsampled luma sample, and rec L where (x, y) denotes the luma sample located at luma sample position (x, y), and R denotes the rounding value. The method of claim 5.

7. The pixel value of each downsampled luma sample is expressed as a first equation: [Equation 6] and the second equation below: [Equation 7] is determined according to at least one of where the current chroma block is located at position (i, j) and rec' L denotes the pixel value of each downsampled luma sample, and rec L where (x, y) denotes the luma sample located at luma sample position (x, y), and R denotes the rounding value. The method of claim 5.

8. the downsampling filter comprises a 3-tap filter; The pixel value of each downsampled luma sample is expressed as a first equation: [Equation 8] and the second equation below: [Equation 9] is determined according to at least one of where the current chroma block is located at position (i, j) and rec' L denotes the pixel value of each downsampled luma sample, and rec L where (x, y) denotes the luma sample located at luma sample position (x, y), and R denotes the rounding value. The method of claim 1.

9. 2. The method of claim 1, wherein the syntax element is signaled in at least one of a sequence header, a sequence parameter set, a picture parameter set, an adaptation parameter set, a video parameter set, a slice header, a picture header, a frame header, a tile header, a coding tree unit header, a superblock header, or a block having a predetermined block size.

10. A device configured to perform the method of any one of claims 1 to 9.

11. A computer program product for causing one or more processors to carry out the method of any one of claims 1 to 9.

Images