Systems and methods for performing intra prediction in video coding

Abstract

A method for generating prediction samples of a current transform block in video coding is disclosed. The method includes setting a neighboring left luma sample value defined as x equal to -1, -2, or -3, corresponding to the current transform block, equal to a reconstructed luma sample; setting a neighboring top-left luma sample value defined as x equal to -2 and y equal to -1, corresponding to the current transform block, equal to the neighboring left luma sample value in case the neighboring top-left luma sample value is not available; deriving down-sampled neighboring left luma sample values of the current transform block by using the neighboring left luma sample value and based on a chroma format; and generating the prediction samples by using the down-sampled neighboring luma sample values.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to video coding, and more specifically to techniques for performing intra prediction of a coded video. BACKGROUND

[0002] Digital video capabilities can be incorporated into a wide range of devices, including digital televisions, laptop or desktop computers, tablet computers, digital recording devices, digital media players, video gaming devices, cellular telephones, including so-called smartphones, medical imaging devices, and the like. Digital video can be coded according to a video coding standard. Video coding standards define the format of a compliant bitstream encapsulating encoded video data. A compliant bitstream is a data structure that can be received and decoded by a video decoding device to generate reconstructed video data. Video coding standards can incorporate video compression techniques. Examples of video coding standards include ISO / IEC MPEG-4 Visual and ITU-T H.264 / AVC (also known as ISO / IEC MPEG-4 AVC) and High-Efficiency Video Coding (HEVC). HEVC is described in High Efficiency Video Coding (HEVC), ITU-T H.265 Recommendation, December 2016, which is incorporated by reference, and is referred to herein as ITU-T H.265. Extensions and improvements to ITU-T H.265 are currently being considered for the development of next generation video coding standards. For example, the ITU-T Video Coding Experts Group (VCEG) and the ISO / IEC Moving Picture Experts Group (MPEG) (collectively referred to as the Joint Video Exploration Team (JVET)) are working on standardizing video coding technology with compression capability significantly exceeding that of ITU-T H.265. Joint Exploration Test Model 7 (JEM 7), Algorithm Description of Joint Exploration Test Model 7 (JEM 7), ISO / IEC JTC1 / SC29 / WG11 Document: JVET-G1001, July 2017, Torino, IT, which is incorporated by reference herein, describes the coding features under exploration by the JVET in the Joint Test Model Study, which is a potential improvement video coding technology that goes beyond the capabilities of ITU-T H.265. It is noted that the coding features of JEM 7 are implemented in the JEM reference software. As used herein, the term JEM can collectively refer to the algorithms in JEM 7 and the implementation of the JEM reference software. Further, in response to the “Joint Call for Proposals on Video Compression with Capabilities beyond HEVC,” jointly issued by VCEG and MPEG, multiple groups submitted descriptions of video coding tools at the 10th Meeting of ISO / IEC JTC1 / SC29 / WG11, April 16-20, 2018, San Diego, CA.According to various descriptions of video coding tools, a final initial draft text of a video coding specification is described in “Versatile Video Coding (Draft 1),” i.e., document JVET-J1001-v2, in the 10th Meeting of ISO / IEC JTC1 / SC29 / WG11, San Diego, CA, April 16-20, 2018, which is incorporated by reference herein and referred to as JVET-J1001. The current development of the next generation video coding standard by VCEG and MPEG is referred to as the Versatile Video Coding (VVC) project. “Versatile Video Coding (Draft 8),” i.e., document JVET-Q2001-vE, in the 17th Meeting of ISO / IEC JTC1 / SC29 / WG11, Brussel, BE, January 7-17, 2020, which is incorporated by reference herein and referred to as JVET-Q2001, represents the current iteration of the draft text of a video coding specification corresponding to the VVC project.

[0003] Video compression techniques enable the storage and transmission of video data at a lower bit rate, while avoiding or at least minimizing a degradation of video quality. Video compression techniques can reduce the data required for a given video sequence by exploiting redundant information between the video sequence and previous video sequences. Video compression techniques can divide a video sequence into successively smaller SUMMARY

[0004] In one example, a method of generating prediction samples for a current transform block in video coding is provided, the method comprising: setting a neighboring left luma sample value defined as x equal to -1, -2, or -3, corresponding to the current transform block, equal to a reconstructed luma sample; setting a neighboring top-left luma sample value defined as x equal to -2 and y equal to -1, corresponding to the current transform block, equal to the neighboring left luma sample value if the neighboring top-left luma sample value is not available; deriving down-sampled neighboring left luma sample values for the current transform block by using the neighboring left luma sample value and based on a chroma format; and generating the prediction samples by using the down-sampled neighboring luma sample values.

[0005] In one example, an apparatus is provided, the apparatus comprising one or more processors configured to: set a neighboring left luma sample value defined as x equal to -1, -2, or -3, corresponding to a current transform block, equal to a reconstructed luma sample; set a neighboring top-left luma sample value defined as x equal to -2 and y equal to -1, corresponding to the current transform block, equal to the neighboring left luma sample value if the neighboring top-left luma sample value is not available; derive down-sampled neighboring left luma sample values for the current transform block by using the neighboring left luma sample value and based on a chroma format; and generate prediction samples by using the down-sampled neighboring luma sample values. BRIEF DESCRIPTION OF DRAWINGS

[0006] [ FIG. 1 ] FIG. 1 is a block diagram illustrating an example of a system that can be configured to encode and decode video data according to one or more techniques of this disclosure.

[0007] [ FIG. 2 ] FIG. 2 is a conceptual diagram illustrating an example of quad-tree multi-type tree partitioning according to one or more techniques of this disclosure.

[0008] [ FIG. 3 ] FIG. 3 is a conceptual diagram illustrating encoded video data and a corresponding data structure according to one or more techniques of this disclosure.

[0009] [ FIG. 4 ] FIG. 4 is a conceptual diagram illustrating an example of a video component sampling format that can be used according to one or more techniques of this disclosure.

[0010] [ FIG. 5 ] FIG. 5 is a conceptual diagram illustrating a data structure that encapsulates encoded video data and corresponding metadata according to one or more techniques of this disclosure.

[0011] [ FIG. 6 ] FIG. 6 is a conceptual diagram illustrating examples of components that can be included in an implementation of a system that can be configured to encode and decode video data in accordance with one or more techniques of this disclosure.

[0012] [ FIG. 7 ] FIG. 7 is a block diagram illustrating an example of a video encoder that can be configured to encode video data in accordance with one or more techniques of this disclosure.

[0013] [ FIG. 8 ] FIG. 8 is a block diagram illustrating an example of a video decoder that can be configured to decode video data in accordance with one or more techniques of this disclosure. DETAILED DESCRIPTION

[0014] In general, this disclosure describes various techniques for performing intra prediction for encoding video data. In particular, this disclosure describes techniques for applying cross-component linear model (CCLM) for chroma intra prediction of video encoding. It should be noted that although the techniques of this disclosure are described with respect to ITU-T H.264, ITU-T H.265, JEM, and JVET-Q2001, the techniques of this disclosure are applicable universally to video encoding. For example, in addition to those techniques included in ITU-T H.265, JEM, and JVET-Q2001, the encoding techniques described herein can be incorporated into video encoding systems, including video encoding systems based on future video coding standards, including video block structures, intra prediction techniques, inter prediction techniques, transform techniques, filtering techniques, and / or other entropy encoding techniques. Accordingly, the references to ITU-T H.264, ITU-T H.265, JEM, and / or JVET-Q2001 are for descriptive purposes and should not be construed as limiting the scope of the techniques described herein. Moreover, it should be noted that the incorporation of documents by reference herein is for descriptive purposes and should not be construed as limiting or creating ambiguity with respect to terms used herein. For example, where a definition of a term provided in one incorporated reference is different from that in another incorporated reference and / or as used herein, then the term should be interpreted in a manner that broadly includes each respective definition and / or in a manner that includes each particular definition in the alternative.

[0015] In one example, a method of generating a prediction for a current block in video encoding includes determining a number of available neighboring chroma samples above and to the right of the current block, and performing a cross-component linear model intra prediction process based on the number of available neighboring chroma samples above and to the right of the current block.

[0016] In one example, an apparatus comprises one or more processors configured to determine a number of available neighboring chroma samples above and to the right of a current block and perform a cross-component linear model intra prediction process based on the number of available neighboring chroma samples above and to the right of the current block.

[0017] In one example, a non-transitory computer-readable storage medium comprises instructions stored thereon that, when executed, cause one or more processors of a device to determine a number of available neighboring chroma samples above and to the right of a current block and perform a cross-component linear model intra prediction process based on the number of available neighboring chroma samples above and to the right of the current block.

[0018] In one example, an apparatus comprises means for determining a number of available neighboring chroma samples above and to the right of a current block and means for performing a cross-component linear model intra prediction process based on the number of available neighboring chroma samples above and to the right of the current block.

[0019] The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims.

[0020] Video content includes a video sequence composed of a series of frames (or pictures). A series of frames can also be referred to as a group of pictures (GOP). Each video frame or picture can be divided into one or more regions. The regions can be defined according to a base unit (e.g., a video block) and a set of rules that define the regions. For example, the rules that define the regions can be that the regions must be an integer number of video blocks arranged in a rectangle. Further, the video blocks in a region can be ordered according to a scan pattern (e.g., a raster scan). As used herein, the term “video block” can generally refer to a region of a picture, or can more specifically refer to a maximum array of sample values that can be predictively coded, sub-partitions thereof, and / or corresponding structures. Further, the term “current video block” can refer to a region of a picture that is being coded or decoded. A video block can be defined as an array of sample values. It should be noted that in some cases, pixel values can be described as including sample values of respective components of video data, which can also be referred to as color components (e.g., luma (Y) and chroma (Cb and Cr) components or red, green, and blue components). It should be noted that in some cases, the terms “pixel value” and “sample value” can be used interchangeably. Further, in some cases, a pixel or sample can be referred to as a pel. A video sampling format (which can also be referred to as a chroma format) can define a number of chroma samples included in a video block relative to a number of luma samples included in the video block. For example, for a 4:2:0 sampling format, the sampling rate of the luma component is twice that of the chroma components in both the horizontal and vertical directions.

[0021] A video encoder can perform predictive coding on video blocks and sub-partitions thereof. Video blocks and sub-partitions thereof can be referred to as nodes. ITU-T H.264 specifies a macroblock comprising 16x16 luma samples. That is, in ITU-T H.264, a picture is segmented into macroblocks. ITU-T H.265 specifies a similar coding tree unit (CTU) structure, which can be referred to as a largest coding unit (LCU). In ITU-T H.265, a picture is segmented into CTUs. In ITU-T H.265, the CTU size can be set to include 16x16, 32x32, or 64x64 luma samples for a picture. In ITU-T H.265, a CTU is composed of respective coding tree blocks (CTBs) for each component of video data, e.g., luma (Y) and chroma (Cb and Cr). It should be noted that video having one luma component and two corresponding chroma components can be described as having two channels, i.e., a luma channel and a chroma channel. Further, in ITU-T H.265, a CTU can be partitioned according to a quadtree (QT) partitioning structure, which causes the CTBs of the CTU to be partitioned into coding blocks (CBs). That is, in ITU-T H.265, a CTU can be partitioned into quadtree leaf nodes. According to ITU-T H.265, one luma CB along with two corresponding chroma CBs and associated syntax elements are referred to as a coding unit (CU). In ITU-T H.265, a minimum allowed size of a CB can be signaled. In ITU-T H.265, the minimum allowed minimum size of a luma CB is 8x8 luma samples. In ITU-T H.265, the decision to code a picture region using intra prediction or inter prediction is made at the CU level.

[0022] In ITU-T H.265, a CU is associated with a prediction unit structure having its root at the CU. In ITU-T H.265, the prediction unit structure allows partitioning of luma CBs and chroma CBs to generate corresponding reference samples. That is, in ITU-T H.265, a luma CB and a chroma CB can be partitioned into respective luma prediction blocks and chroma prediction blocks (PBs), where a PB includes a block of sample values for which the same prediction is applied. In ITU-T H.265, a CB can be divided into 1, 2, or 4 PBs. ITU-T H.265 supports PB sizes from 64x64 samples down to 4x4 samples. In ITU-T H.265, square PBs are supported for intra prediction, where a CB can form a PB or a CB can be partitioned into four square PBs. In addition, in ITU-T H.265, rectangular PBs are supported for inter prediction in addition to square PBs, where a CB can be halved vertically or horizontally to form PBs. Further, it should be noted that in ITU-T H.265, for inter prediction, four asymmetric PB partitions are supported, where a CB is partitioned into two PBs at one quarter of the height (top or bottom) or width (left or right) of the CB. Intra prediction data (e.g., intra prediction mode syntax elements) or inter prediction data (e.g., motion data syntax elements) corresponding to a PB are used to generate reference and / or predicted sample values for the PB.

[0023] JEM specifies a CTU having a maximum size of 256x256 luma samples. JEM specifies a quadtree plus binary tree (QTBT) block structure. In JEM, the QTBT structure allows quadtree leaf nodes to be further divided by a binary tree (BT) structure. That is, in JEM, the binary tree structure allows quadtree leaf nodes to be recursively divided vertically or horizontally. In JVET-Q2001, a CTU is partitioned according to a quadtree plus multi-type tree (QTMT or QT+MTT) structure. The QTMT in JVET-Q2001 is similar to the QTBT in JEM. However, in JVET-Q2001, in addition to indicating binary splits, the multi-type tree can also indicate so-called ternary (or ternary tree (TT)) splits. A ternary split divides one block into three blocks either vertically or horizontally. In the case of a vertical TT split, the block is split at one quarter of its width from the left edge and at one quarter of its width from the right edge, and in the case of a horizontal TT split, the block is split at one quarter of its height from the top edge and at one quarter of its height from the bottom edge. FIG. 2 An example is shown in which a CTU is partitioned into quadtree leaf nodes and the quadtree leaf nodes are further partitioned according to BT splits or TT splits. That is, in FIG. 2 the dashed lines indicate additional binary and ternary splits in the quadtree.

[0024] As noted above, each video frame or picture can be divided into one or more regions. For example, according to ITU-T H.265, each video frame or picture can be partitioned to include one or more slices, and further partitioned to include one or more tiles, where each slice includes a sequence of CTUs (e.g., arranged in a raster scan order), and where a tile is a sequence of CTUs corresponding to a rectangular region of a picture. It should be noted that in ITU-T H.265, a slice is a sequence of one or more slice segments starting with an independent slice segment and containing all subsequent dependent slice segments (if any) before the next independent slice segment (if any). A slice segment (like a slice) is a sequence of CTUs. Thus, in some cases, the terms “slice” and “slice segment” can be used interchangeably to indicate a sequence of CTUs arranged in a raster scan order. Further, it should be noted that in ITU-T H.265, a tile can be composed of CTUs contained in more than one slice, and a slice can be composed of CTUs contained in more than one tile. However, ITU-T H.265 provides that one or both of the following conditions should be met: (1) all CTUs in a slice belong to the same tile; and (2) all CTUs in a tile belong to the same slice.

[0025] With respect to JVET-Q2001, a slice needs to be composed of an integer number of complete tiles or an integer number of consecutive complete CTU rows within a tile, rather than just an integer number of CTUs as provided in ITU-T H.265. It should be noted that in JVET-Q2001, the slice design does not include slice segments (i.e., there are no independent / dependent slice segments). Thus, in JVET-Q2001, a picture can include a single tile that is contained within a single slice, or a picture can include multiple tiles that can be contained within one or more slices. In JVET-Q2001, a picture is partitioned into tiles by specifying respective heights of tile rows and respective widths of tile columns. Thus, in JVET-Q2001, a tile is a rectangular region of CTUs within a particular tile row and a particular tile column position. Further, JVET-Q2001 supports two slice modes: raster scan slices and rectangular slices. For a raster scan slice, the slice contains a series of complete tiles in a tile raster scan of the picture, where the tile raster scan of the picture is a mapping of a rectangular two-dimensional pattern of tiles within the picture to a one-dimensional pattern, where the first top row of the two-dimensional pattern is scanned from left to right, followed by the second row, third row, etc. of the pattern similarly scanned from left to right (downward). For a rectangular slice, the slice contains a number of complete tiles that collectively form a rectangular region of the picture or a number of consecutive complete CTU rows that collectively form one tile of the picture. The tiles within a rectangular slice are scanned in tile raster scan order within the rectangular region corresponding to the slice.

[0026] Furthermore, it should be noted that JVET-Q2001 specifies that an image can be divided into sub-images, where a sub-image is a rectangular CTU region within the image. The top-left CTU of a sub-image can be located at any CTU position within the image, and the sub-image is constrained to include one or more slices. Therefore, unlike tiles, sub-images are not necessarily restricted to specific row and column positions. It should be noted that sub-images can be used to encapsulate regions of interest within an image, and the sub-bitstream extraction process can be used to decode and display only specific regions of interest. That is, as described in further detail below, the bitstream of encoded video data comprises a sequence of Network Abstraction Layer (NAL) units, where NAL units encapsulate encoded video data (i.e., video data corresponding to image slices), or NAL units encapsulate metadata (e.g., parameter sets) for decoding the video data, and the sub-bitstream extraction process forms a new bitstream by removing one or more NAL units from the bitstream.

[0027] FIG. 3 This is a conceptual diagram illustrating an example of an image group divided according to tiles, slices, and sub-images. It should be noted that the techniques described herein are applicable to tiles, slices, sub-images, their sub-regions, and / or their equivalent structures. That is, the techniques described herein are generally applicable regardless of how an image is divided into regions. For example, in some cases, the techniques described herein can be applied to situations where tiles can be divided into so-called bricks, where a brick is a rectangular CTU row region within a particular tile. Furthermore, for example, in some cases, the techniques described herein can be applied to situations where one or more tiles can be included in a so-called tile group, where the tile group comprises an integer number of adjacent tiles. In one example, a tile group may be referred to as a slice. FIG. 3 In the example shown, Pic3 is depicted as comprising 16 tiles (i.e., Tile0 to Tile...). 15 ) and three slices (i.e., Slice0 to Slice2). In FIG. 3 In the example shown, Slice0 includes four tiles (i.e., Tile0 to Tile3), and Slice1 includes eight tiles (i.e., Tile4 to Tile5). 11 Slice2 includes four tiles (i.e., Tile). 12 To Tile 15 It should be noted that, FIG. 3 An example of a raster scan slice is shown. (Reference) FIG. 3 An example rectangular slice would be Slice0, which includes tiles Tile0, Tile4, Tile8, and Tile... 12Slice1 includes tiles Tile1, Tile2, Tile5, Tile6, Tile9, and Tile... 10 Tile 13 and Tile 14 Slice2 includes tiles Tile3, Tile7, and Tile8. 11 and Tile 15 In addition, such as FIG. 3 As shown in the example, Pic3 is illustrated as comprising two subpictures (i.e., Subpicture0 and Subpicture1), where Subpicture0 includes Slice0 and Slice1, and Subpicture1 includes Slice2. As described above, subpictures can be used to encapsulate regions of interest within an image, and sub-bitstream extraction processes can be used to selectively decode (and display) regions of interest. For example, see Reference... FIG. 3 Sub-image 0 may correspond to the action portion of a sports event presentation (e.g., a view of a field), and sub-image 1 may correspond to a scrolling banner displayed during the sports event presentation. By organizing images into sub-images in this way, viewers may be able to disable the display of the scrolling banner. That is, through the sub-bitstream extraction process, slice 2 NAL units can be removed from the bitstream (and therefore not decoded), while slice 0 NAL units and slice 1 NAL units can be decoded and displayed. The following describes in further detail how image slices are encapsulated into corresponding NAL unit data structures and how sub-bitstream extraction is performed.

[0028] As mentioned above, the video sampling format (also known as the chroma format) can be defined relative to the number of luminance samples included in the CU, thus defining the number of chroma samples included in the CU. For example, for a 4:2:0 sampling format, the sampling rate of the luminance component is twice the sampling rate of the chroma components in both the horizontal and vertical directions. Therefore, for a CU formatted according to the 4:2:0 format, the width and height of the sample arrays used for the luminance components are twice the width and height of each sample array used for the chroma components. FIG. 4 This is a conceptual diagram illustrating an example of a coding unit formatted according to the 4:2:0 sample format. FIG. 4 This shows the relative positions of the chromaticity samples with respect to the luminance samples within the CU. As mentioned above, the CU is typically defined based on the number of horizontal and vertical luminance samples. Therefore, as... FIG. 4 As shown, the 16×16CU, formatted according to the 4:2:0 sample format, includes 16×16 samples for the luminance component and 8×8 samples for each chrominance component. Furthermore, in FIG. 4In the illustrated example, the relative positions of the chroma samples of neighboring video blocks of a 16x16 CU relative to the luma samples are shown. For a CU formatted according to the 4:2:2 format, the width of the sample array of the luma component is twice the width of the sample array of each chroma component, but the height of the sample array of the luma component is equal to the height of the sample array of each chroma component. Further, for a CU formatted according to the 4:4:4 format, the sample array of the luma component has the same width and height as the sample array of each chroma component.

[0029] For intra-predicted coding, an intra-prediction mode can specify the location of reference samples within the picture. In ITU-T H.265, the possible intra-prediction modes that have been defined include a planar (i.e., surface-fitting) prediction mode, a DC (i.e., flat overall average) prediction mode, and 33 angular prediction modes (predMode: 2-34). In JEM, the possible intra-prediction modes that have been defined include a planar prediction mode, a DC prediction mode, and 65 angular prediction modes. It should be noted that the planar prediction mode and the DC prediction mode can be referred to as non-directional prediction modes, and the angular prediction modes can be referred to as directional prediction modes. It should be noted that the techniques described herein can be universally applicable regardless of the number of defined possible prediction modes.

[0030] For inter-predicted coding, a reference picture is determined, and a motion vector (MV) identifies a sample in that reference picture that is used to generate a prediction for the current video block. For example, a current video block can be predicted using reference sample values located in one or more previously coded pictures, and a motion vector is used to indicate the location of the reference block relative to the current video block. The motion vector can describe, for example, a horizontal displacement component of the motion vector (i.e., MV x ), a vertical displacement component of the motion vector (i.e., MV y) and the resolution of the motion vector (e.g., quarter-pixel precision, half-pixel precision, one-pixel precision, two-pixel precision, four-pixel precision). Previously decoded pictures, which can include pictures output before or after the current picture, can be organized into one or more reference picture lists and identified using reference picture index values. Moreover, in inter prediction coding, single prediction refers to generating a prediction using sample values from a single reference picture and bi-prediction refers to generating a prediction using corresponding sample values from two reference pictures. That is, in single prediction, a single reference picture and corresponding motion vector are used to generate a prediction for a current video block, while in bi-prediction, a first reference picture and corresponding first motion vector and a second reference picture and corresponding second motion vector are used to generate a prediction for a current video block. In bi-prediction, the corresponding sample values are combined (e.g., added, rounded and clamped, or averaged according to weights) to generate the prediction. Pictures and regions thereof can be classified based on which types of prediction modes can be used to encode video blocks thereof. That is, for regions having a B type (e.g., B slices), bi-prediction, single prediction, and intra prediction modes can be utilized, for regions having a P type (e.g., P slices), single prediction and intra prediction modes can be utilized, and for regions having an I type (e.g., I slices), only intra prediction modes can be utilized. As noted above, reference pictures are identified by reference index. For example, for P slices, there can be a single reference picture list, RefPicListO, and for B slices, in addition to RefPicListO, there can be a second independent reference picture list, RefPicListl. It should be noted that for single prediction in B slices, one of RefPicListO or RefPicListl can be used to generate a prediction. Moreover, it should be noted that during the decoding process, when starting to decode a picture, the reference picture lists are generated from previously decoded pictures stored in a decoded picture buffer (DPB).

[0031] Furthermore, coding standards can support various motion vector prediction modes. Motion vector prediction enables derivation of a value for a motion vector of a current video block based on another motion vector. For example, a set of candidate blocks with associated motion information can be derived from spatially and temporally neighboring blocks of the current video block. Furthermore, the generated (or default) motion information can be used for motion vector prediction. Examples of motion vector prediction include advanced motion vector prediction (AMVP), temporal motion vector prediction (TMVP), so-called "merge" mode, and "skip" and "direct" motion inference. Furthermore, other examples of motion vector prediction include advanced temporal motion vector prediction (ATMVP) and spatial-temporal motion vector prediction (STMVP). For motion vector prediction, both the video encoder and the video decoder perform the same process to derive a set of candidates. Thus, for a current video block, the same set of candidates is generated during encoding and decoding.

[0032] As noted above, for inter prediction coding, reference samples in previously coded pictures are used to code a video block in a current picture. Previously coded pictures that are available as references when coding the current picture are referred to as reference pictures. It should be noted that the decoding order does not necessarily correspond to the picture output order, i.e., the temporal order of pictures in a video sequence. In ITU-T H.265, when a picture is decoded, it is stored to a decoded picture buffer (DPB) (which can be referred to as a frame buffer, reference buffer, reference picture buffer, etc.). In ITU-T H.265, pictures stored to the DPB are removed from the DPB when they are output and are no longer needed for coding subsequent pictures. In ITU-T H.265, a determination of whether a picture should be removed from the DPB is invoked once per picture after decoding the slice header, i.e., at the beginning of decoding a picture. For example, a reference FIG. 3 Pic2 is shown to reference Picl. Similarly, Pic3 is shown to reference PicO. With respect to FIG. 3, assuming the number of pictures corresponds to the decoding order, the DPB would be populated as follows: after decoding PicO, the DPB would include {PicO}; at the start of decoding Picl, the DPB would include {PicO}; after decoding Picl, the DPB would include {PicO, Picl}; at the start of decoding Pic2, the DPB would include {PicO, Picl}. Pic2 would then be decoded with reference to Picl, and after decoding Pic2, the DPB would include {PicO, Picl, Pic2}. At the start of decoding Pic3, pictures PicO and Picl would be marked for removal from the DPB because they are not needed for decoding Pic3 (or any subsequent pictures, not shown), and assuming Picl and Pic2 have been output, the DPB would be updated to include {PicO}. Pic3 would then be decoded with reference to PicO. The process of marking pictures for removal from the DPB can be referred to as reference picture set (RPS) management.

[0033] As described above, intra prediction data or inter prediction data is used to produce reference sample values for a block of sample values. The difference between sample values included in a current PB or another type of picture region structure and associated reference samples (e.g., those generated using prediction) can be referred to as residual data. Residual data can include a respective array of difference values corresponding to each component of the video data. Residual data can be in the pixel domain. A transform such as a discrete cosine transform (DCT), a discrete sine transform (DST), an integer transform, a wavelet transform, or a conceptually similar transform can be applied to the array of difference values to generate transform coefficients. It should be noted that in ITU-T H.265 and JVET-Q2001, a CU is associated with a transform tree structure having its root at the CU’s level. The transform tree is partitioned into one or more transform units (TUs). That is, to generate transform coefficients, the array of difference values can be partitioned (e.g., four 8x8 transforms can be applied to a 16x16 array of residual values). Such sub-divisions of difference values can be referred to as transform blocks (TBs) for each component of the video data. It should be noted that in some cases, a core transform and a subsequent secondary transform can be applied (in a video encoder) to generate transform coefficients. For a video decoder, the order of the transforms is reversed.

[0034] The quantization process can be performed directly on transform coefficient or residual sample values (e.g., for palette coding quantization). Quantization approximates transform coefficients by limiting their amplitudes to a specified set of values. Quantization essentially scales transform coefficients in order to vary the amount of data needed to represent a set of transform coefficients. Quantization can include dividing transform coefficients (or values resulting from adding an offset value to transform coefficients) by a quantization scaling factor and any associated rounding function (e.g., rounding to the nearest integer). Quantized transform coefficients can be referred to as coefficient level values. Dequantization (or “dequantization”) can include multiplying coefficient level values by a quantization scaling factor, and any inverse rounding or offset addition operations. It should be noted that, as used herein, the term quantization process can refer to dividing by a scaling factor to generate level values in some cases, and multiplying by a scaling factor to recover transform coefficients in some cases. That is, the quantization process can refer to quantization in some cases, and dequantization in some cases. Further, it should be noted that while the quantization process is described in some of the examples below with respect to arithmetic operations related to decimal notation, such descriptions are for illustrative purposes and should not be interpreted as limiting. For example, the techniques described herein can be implemented in devices that use binary operations, etc. For example, the multiplication and division operations described herein can be implemented using shift operations, etc.

[0035] Quantized transform coefficients and syntax elements (e.g., syntax elements indicative of a coding structure of a video block) can be entropy encoded according to an entropy encoding technique. The entropy encoding process includes encoding the values of the syntax elements using lossless data compression algorithms. Examples of entropy encoding techniques include content adaptive variable length coding (CAVLC), context adaptive binary arithmetic coding (CABAC), probability interval partitioning entropy coding (PIPE), and the like. The entropy encoded quantized transform coefficients and corresponding entropy encoded syntax elements can form a compliant bitstream that can be used to reproduce the video data at a video decoder. The entropy encoding process, e.g., CABAC, can include binarization of the syntax elements. Binarization refers to the process of converting the value of a syntax element into a sequence of one or more bits. These bits can be referred to as “bins.” Binarization can include one or a combination of the following encoding techniques: fixed length encoding, unary encoding, truncated unary encoding, truncated Rice encoding, Golomb encoding, k-th order exponential Golomb encoding, and Golomb-Rice encoding. For example, binarization can include representing the integer value 5 of a syntax element as 00000101 using an 8-bit fixed length binarization technique, or as 11110 using a unary encoding binarization technique. As used herein, each of the terms fixed length encoding, unary encoding, truncated unary encoding, truncated Rice encoding, Golomb encoding, k-th order exponential Golomb encoding, and Golomb-Rice encoding can refer to general implementations of these techniques and / or more specific implementations of these encoding techniques. For example, a Golomb-Rice encoding implementation can be specifically defined according to a video coding standard. In the example of CABAC, for a particular bin, a context provides a most probable state (MPS) value for the bin (i.e., the MPS for the bin is one of 0 or 1), and a probability value for the bin being the MPS or a least probable state (LPS). For example, a context can indicate that the MPS for a bin is 0, and the probability of the bin being 1 is 0.3. It should be noted that the context can be determined based on values of previously encoded bins, including the current syntax element and previously coded syntax elements. For example, values of syntax elements associated with neighboring video blocks can be used to determine the context for a current bin.

[0036] With respect to the equations used herein, the following arithmetic operators can be used:

[0037] + addition

[0038] - subtraction

[0039] * multiplication, including matrix multiplication

[0040] x y power. x is designated as the power of y. In other contexts, such notation is used for superscripts and is not intended to be interpreted as a power.

[0041] / Integer division that truncates the result toward zero. For example, 7 / 4 and -7 / -4 are truncated to 1, and -7 / 4 and 7 / -4 are truncated to -1.

[0042] ÷ Used in mathematical formulas to denote division without implying truncation or rounding.

[0043] ÷ Used in mathematical formulas to denote division without implying truncation or rounding.

[0044] In addition, the following mathematical functions can be used:

[0045]

[0046] Floor(x), the largest integer less than or equal to x.

[0047] Log2(x), the logarithm of x to the base 2;

[0048]

[0049]

[0050] Ceil(x), the smallest integer greater than or equal to x.

[0051]

[0052] Round(x) = Sign(x) * Floor(Abs(x) + 0.5)

[0053]

[0054] Swap(x, y) = (y, x)

[0055] With respect to the example syntax used herein, the following definitions of logical operators can apply:

[0056] x && y Boolean logical "and" of x and y

[0057] x || y Boolean logical "or" of x and y

[0058] ! Boolean logical "not"

[0059] x? y : z evaluates to y if x is TRUE; otherwise, evaluates to z.

[0060] In addition, the following relational operators can apply:

[0061] > Greater than

[0062] >= Greater than or equal to

[0063] < Less than

[0064] ≤ Less than or equal to

[0065] == Equal to

[0066] != Not equal to

[0067] In addition, the following bitwise operators can be applied:

[0068] & Bitwise AND. When operating on integral type variables, the binary complement representation of the integer values are operated on. When operating on binary variables containing fewer bits than the other variable, the shorter variable is extended by adding more significant bits equal to zero.

[0069] | Bitwise OR. When operating on integral type variables, the binary complement representation of the integer values are operated on. When operating on binary variables containing fewer bits than the other variable, the shorter variable is extended by adding more significant bits equal to zero.

[0070] ^ Bitwise XOR. When operating on integral type variables, the binary complement representation of the integer values are operated on. When operating on binary variables containing fewer bits than the other variable, the shorter variable is extended by adding more significant bits equal to zero.

[0071] x » y Arithmetic right shift of the binary complement integer representation of x by y binary digits. The function is only defined for non-negative integer values of y. Bits shifted into the most significant bits (MSB) as a result of the right shift have a value equal to the MSB of x prior to the shift operation.

[0072] x « y Arithmetic left shift of the binary complement integer representation of x by y binary digits. The function is only defined for non-negative integer values of y. Bits shifted into the least significant bits (LSB) as a result of the left shift have a value equal to zero.

[0073] In addition, the following arithmetic operators can be applied:

[0074] = Assignment operator

[0075] ++ Increment, i.e., x++ is equivalent to x = x + 1; when used in an array index, the value of the variable is evaluated prior to the increment operation.

[0076] -- Decrement, i.e., x-- is equivalent to x = x - 1; when used in an array index, the value of the variable is evaluated prior to the decrement operation.

[0077] += Increment by a specified amount, i.e., x += 3 is equivalent to x = x + 3 and x += (-3) is equivalent to x = x + (-3).

[0078] - = decrements by the specified amount, i.e. x -= 3 is equivalent to x = x - 3, and x -= (-3) is equivalent to x = x - (-3).

[0079] Furthermore, it should be noted that in the syntax descriptors used herein, the following descriptors can apply:

[0080] - ae(v): Context Adaptive Arithmetic Entropy Coded syntax element.

[0081] - b(8): Byte (8 bits) with any bit string pattern. The parsing process of this descriptor is specified by the return value of the function read_bit(8).

[0082] - f(n): Fixed pattern bit string written using n bits (from left to right) from the leftmost bit. The parsing process of this descriptor is specified by the return value of the function read_bit(n).

[0083] - i(n): Unsigned integer using n bits. When n is "v" in the syntax table, the number of bits varies in a way that depends on the value of other syntax elements. The parsing process of this descriptor is specified by the return value of the function read_bits(n) which is interpreted as a two's complement integer representation written with the most significant bit first.

[0084] - se(v): Syntax element signed integer 0th order Exp-Golomb coded from the leftmost bit.

[0085] - u(n): Unsigned integer using n bits. When n is "v" in the syntax table, the number of bits varies in a way that depends on the value of other syntax elements. The parsing process of this descriptor is specified by the return value of the function read_bits(n) which is interpreted as a binary representation of an unsigned integer written with the most significant bit first.

[0086] - ue(v): Syntax element unsigned integer 0th order Exp-Golomb coded from the leftmost bit.

[0087] As mentioned above, a video content comprises a video sequence composed of a series of pictures, and each picture can be divided into one or more regions. In JVET-Q2001, the coded representation of a picture comprises the VCL NAL units of a particular layer within an AU and contains all the CTUs of the picture. For example, referring again to FIG. 3The coded representation of Pic3 is encapsulated in three coded slice NAL units (i.e., Slice0 NAL unit, Slice1 NAL unit, and Slice2 NAL unit). It should be noted that the term video coding layer (VCL) NAL unit is used as a generalization of coded slice NAL units, i.e., VCL NAL is a generalization that includes all types of slice NAL units. As mentioned above, and described in further detail below, NAL units can encapsulate metadata for decoding video data. NAL units that encapsulate metadata for decoding a video sequence are generally referred to as non-VCL NAL units. Thus, in JVET-Q2001, a NAL unit can be a VCL NAL unit or a non-VCL NAL unit. It should be noted that a VCL NAL unit includes slice header data that provides information for decoding a particular slice. Thus, in JVET-Q2001, information for decoding video data (which can be referred to as metadata in some cases) is not limited to being included in non-VCL NAL units. JVET-Q2001 specifies that a picture unit (PU) is a set of NAL units that are associated with each other according to a specified classification rule, are consecutive in decoding order, and contain exactly one coded picture, and an access unit (AU) is a set of PUs that belong to different layers and contain coded pictures associated with the same time as output from the DPB. JVET-Q2001 further specifies that a layer is a set of VCL NAL units and their associated non-VCL NAL units all having a layer identifier of a particular value. Furthermore, in JVET-Q2001, a PU consists of zero or one PH NAL unit, one coded picture (which is composed of one or more VCL NAL units), and zero or more other non-VCL NAL units. Moreover, in JVET-Q2001, a coded video sequence (CVS) is a sequence of AUs consisting of a CVSS AU and subsequent zero or more non-CVSS AUs in decoding order (including all subsequent AUs up to, but not including, any subsequent AU that is a CVSS AU) where a coded video sequence start (CVSS) AU is an AU in which there is a PU for each layer in the CVS and the coded picture in each present picture unit is a coded layer video sequence start (CLVSS) picture. In JVET-Q2001, a coded layer video sequence (CLVS) is a sequence of PUs within the same layer consisting of a CLVSS PU and subsequent zero or more non-CLVSS PUs in decoding order (including all subsequent PUs up to, but not including, any subsequent PU that is a CLVSS PU). That is, in JVET-Q2001, a bitstream can be described as including a sequence of AUs that form one or more CVSs.

[0088] Multi-layer video coding enables a video presentation to be decoded / displayed as a presentation corresponding to a base layer of video data and as one or more additional presentations corresponding to enhancement layers of the video data. For example, the base layer can enable a video presentation to be presented with a basic level of quality (e.g., a high definition presentation and / or a 30 Hz frame rate), and the enhancement layer can enable a video presentation to be presented with an enhanced level of quality (e.g., an ultra-high definition rendering and / or a 60 Hz frame rate). The enhancement layer can be encoded by reference to the base layer. That is, for example, a picture in the enhancement layer can be encoded by reference to one or more pictures in the base layer (including scaled versions thereof) (e.g., using inter-layer prediction techniques). It should be noted that the layers can also be encoded independently of one another. In this case, there can be no inter-layer prediction between the two layers. Each NAL unit can include an identifier indicating the layer of video data with which the NAL unit is associated. As noted above, a sub-bitstream extraction process can be used to decode and display only a particular region of interest of a picture. Further, a sub-bitstream extraction process can be used to decode and display only a particular video layer. Sub-bitstream extraction can refer to a process by which a device receiving a conformant or compliant bitstream forms a new conformant or compliant bitstream by discarding and / or modifying data in the received bitstream. For example, sub-bitstream extraction can be used to form a new conformant or compliant bitstream corresponding to a particular video representation (e.g., a high quality representation).

[0089] In JVET-Q2001, each of video sequence, GOP, picture, slice and CTU can be associated with metadata describing video coding properties, and some types of metadata are encapsulated in non-VCL NAL units. JVET-Q2001 defines parameter sets that can be used to describe video data and / or video coding properties. In particular, JVET-Q2001 includes the following four parameter sets: video parameter set (VPS), sequence parameter set (SPS), picture parameter set (PPS), and adaptation parameter set (APS), where SPS applies to zero or more integer number of CVSs, PPS applies to zero or more integer number of coded pictures, APS applies to zero or more slices, and VPS can be optionally referred to by SPS. PPS applies to the single coded picture referring to it. In JVET-Q2001, parameter sets can be encapsulated as non-VCL NAL units and / or can be signaled as messages. JVET-Q2001 also includes picture header (PH) that is encapsulated as a non-VCL NAL unit. In JVET-Q2001, picture header applies to all slices of a coded picture. JVET-Q2001 further enables signaling of decoding capability information (DCI) and supplemental enhancement information (SEI) messages. In JVET-Q2001, DCI and SEI messages assist processes related to decoding, display or other purposes, however, DCI and SEI messages can not be required to construct luma or chroma samples according to the decoding process. In JVET-Q2001, DCI and SEI messages can be signaled in the bitstream using non-VCL NAL units. In addition, DCI and SEI messages can be conveyed by some mechanism other than being present in the bitstream (i.e., signaled out-of-band).

[0090] FIG. 5 An example of a bitstream including a plurality of CVSs is shown, where a CVS includes an AU, and an AU includes a picture unit. FIG. 5 The example shown in corresponds to the example shown in FIG. 3 The example shown in corresponds to the example shown in FIG. 5 In the example shown in, the corresponding picture unit of Pic3 includes three VCL NAL coded slice NAL units, namely Slice0 NAL unit, Slice1 NAL unit and Slice2 NAL unit, and two non-VCL NAL units, namely PPS NAL unit and PH NAL unit. It should be noted that in FIG. 5 In, the header is a NAL unit header (i.e., not to be confused with a slice header). In addition, it should be noted that in FIG. 5In the example of FIG. 6, other non-VCL NAL units not shown can be included in the CVS, such as SPS NAL units, VPS NAL units, SEI message NAL units, and the like. Moreover, it should be noted that in other examples, the PPS NAL unit used to decode Pic3 can be included elsewhere in the bitstream, such as in the picture unit corresponding to PicO, or can be provided by an external agency. In JVET-Q2001, the PH syntax structure can be present in the slice header of a VCL NAL unit or in a PH NAL unit of the current PU.

[0091] As described above, a video sample format (which can also be referred to as a chroma format) can define a number of chroma samples included in a video block relative to a number of luma samples included in the video block. Table 1 illustrates how chroma formats are specified in JVET-Q2001 based on the values of syntax elements chroma format idc and separate colour plane flag included in the SPS in JVET-Q2001. Moreover, Table 1 illustrates how variables SubWidthC and SubHeightC are derived from the chroma format. SubWidthC and SubHeightC are used for intra prediction, as described in further detail below. With respect to Table 1, JVET-Q2001 provides the following provisions:

[0092] In monochrome sampling, there is only one sample array, which is nominally treated as a luma array.

[0093] In 4:2:0 sampling, each of the two chroma arrays has half the height and half the width of the luma array.

[0094] In 4:2:2 sampling, each of the two chroma arrays has the same height as the luma array and half the width.

[0095] In 4:4:4 sampling, the following applies depending on the value of separate colour plane flag:

[0096] - If separate colour plane flag is equal to 0, each of the two chroma arrays has the same height and width as the luma array.

[0097] - Otherwise (separate colour plane flag is equal to 1), the three colour planes are treated separately as monochrome-sampled pictures.

[0098] chroma_format_idc separate_colour_plane_flag chroma format SubWidth C SubHeight C 0 0 monochrome 1 1 1 0 4:2:0 2 2 2 0 4:2:2 2 1 3 0 4:4:4 1 1 3 1 4:4:4 1 1

[0099] Table 1

[0100] As further described above, the intra prediction data can indicate how to generate the prediction for the current video block. That is, the intra prediction data indicates how to generate the array of predicted sample values, e.g., predSamples[x][y]. It should be noted that the generation of the array of predicted samples can include one or more of padding (i.e., copying sample values), projection (i.e., mapping an angular direction to a particular sample, and / or interpolating sample values from angular prediction), and smoothing and / or filtering the predicted sample values. In JVET-Q2001, the defined possible intra prediction modes for luma include the planar prediction mode (predMode: 0), the DC prediction mode (predMode: 1), the angular prediction modes (preMode: 2..66), and the cross-component linear model (CCLM) prediction modes (predMode: 81..83) which are only applicable to chroma components. That is, JVET-Q2001 specifies the following process for general intra prediction:

[0101] general intra prediction

[0102] The input to this process are:

[0103] - the sample position (xTbCmp, yTbCmp) which specifies the top-left sample of the current transform block relative to the top-left sample of the current picture,

[0104] - the variable predModeIntra which specifies the intra prediction mode,

[0105] - the variable nTbW which specifies the transform block width,

[0106] - the variable nTbH which specifies the transform block height,

[0107] - the variable nCbW which specifies the coding block width,

[0108] - the variable nCbH which specifies the coding block height,

[0109] - the variable cldx which specifies the color component of the current block.

[0110] The output of this process is the predicted samples predSamples[x][y] for x = 0..nTbW-1, y = 0..nTbH-1.

[0111] The variables refW and refH are derived as follows:

[0112] - if IntraSubPartitionsSplitType is equal to ISP_NO_SPLIT or cldx is not equal to 0, the following applies:

[0113] refW = nTbW * 2

[0114] refH = nTbH * 2

[0115] - Otherwise (IntraSubPartitionsSplitType is not equal to ISP_NO_SPLIT and cldx is equal to 0), the following applies:

[0116] refW = nCbW + nTbW

[0117] refH = nCbH + nTbH

[0118] The variable refldx specifying the intra prediction reference line index is derived as follows:

[0119] refldx = (cldx == 0)? IntraLumaRefLineIdx[xTbCmp][yTbCmp] : 0

[0120] The wide-angle intra prediction mode mapping process is invoked as specified with predModeIntra, nTbW, nTbH and cldx as input and a modified predModeIntra as output, where the wide-angle intra prediction mode mapping process does not modify predModeIntra equal to (81..83) predModeIntra.

[0121] The variable refFilterFlag is derived as follows:

[0122] - If predModeIntra is equal to 0, -14, -12, -10, -6, 2, 34, 66, 72,

[0123] 76, 78 or 80, refFilterFlag is set equal to 1.

[0124] - Otherwise, refFilterFlag is set equal to 0.

[0125] For the generation of reference samples p[x][y] with x = -1 - refldx, y = -1 - refldx..refH - 1 and x = -refldx..refW - 1, y = -1 - refldx, the following ordered steps apply:

[0126] 1. Call the reference sample availability flag process specified as follows, with sample position (xTbCmp, yTbCmp), intra prediction reference line index refldx, reference sample width refW, reference sample height refH, color component index cldx as input, and with reference sample refUnfilt[x][y] (with x = -1 - refldx, y = -1 - refldx..refH - 1 and x = -refldx..refW - 1, y = -1 - refldx) as output.

[0127] 2. When at least one sample refUnfilt[x][y] (with x = -1 - refldx, y = -1 - refldx..refH - 1 and x = -refldx..refW - 1, y = -1 - refldx) is flagged as "not available for intra prediction", call the reference sample replacement process specified as follows, with intra prediction reference line index refldx, reference sample width refW, reference sample height refH, reference sample refUnfilt[x][y] (with x = -1 - refldx, y = -1 - refldx..refH - 1 and x = -refldx..refW - 1, y = -1 - refldx) and color component index cldx as input, and with modified reference sample refUnfilt[x][y] (with x = -1 - refldx, y = -1 - refldx..refH - 1 and x = -refldx..refW - 1, y = -1 - refldx) as output.

[0128] 3. Call the reference sample filtering process specified as follows, with intra prediction reference line index refldx, transform block width nTbW and height nTbH, reference sample width refW, reference sample height refH, reference filter flag refFilterFlag, unfiltered sample refUnfilt[x][y] (with x = -1 - refldx, y = -1 - refldx..refH - 1 and x = -refldx..refW - 1, y = -1 - refldx) and color component index cldx as input, and with reference sample p[x][y] (with x = -1 - refldx, y = -1 - refldx..refH - 1 and x = -refldx..refW - 1, y = -1 - refldx) as output.

[0129] The intra sample prediction process according to predModeIntra is applied as follows:

[0130] - If predModeIntra is equal to INTRA_PLANAR, the corresponding intra prediction mode process as specified below is invoked with the transform block width nTbW and the transform block height nTbH and the reference sample array p as inputs and the output is the predicted sample array predSamples.

[0131] - Otherwise, if predModeIntra is equal to INTRA_DC, the corresponding intra prediction mode process as specified below is invoked with the transform block width nTbW, the transform block height nTbH, the intra prediction reference line index refldx, and the reference sample array p as inputs and the output is the predicted sample array predSamples.

[0132] - Otherwise, if predModeIntra is equal to INTRA_LT_CCLM, INTRA_L_CCLM, or INTRA_T_CCLM, the corresponding intra prediction mode process as specified below is invoked with the intra prediction mode predModeIntra, the sample position (xTbCmp, yTbCmp) set equal to (xTbC, yTbC), the transform block width nTbW and height nTbH, the color component index cldx, and the reference sample array p as inputs and the output is the predicted sample array predSamples.

[0133] - Otherwise, the corresponding intra prediction mode process as specified below is invoked with the intra prediction mode predModeIntra, the intra prediction reference line index refldx, the transform block width nTbW, the transform block height nTbH, the reference sample width refW, the reference sample height refH, the coding block width nCbW and height nCbH, the reference filter flag refFilterFlag, the color component index cldx, and the reference sample array p as inputs and with the predicted sample array predSamples as output.

[0134] When all of the following conditions are true, the position dependent prediction sample filtering process is invoked with the intra prediction mode predModeIntra, the transform block width nTbW, the transform block height nTbH, the predicted samples predSamples [x][y] for x = 0..nTbW - 1, y = 0..nTbH - 1, the reference sample width refW, the reference sample height refH, and the reference samples p[x][y] for x = -1, y = -1..refH - 1 and x = 0..refW - 1, y = -1 as inputs and the output is the modified predicted sample array predSamples:

[0135] - nTbW is greater than or equal to 4 and nTbH is greater than or equal to 4

[0136] - refldx is equal to 0 or cldx is not equal to 0

[0137] - BdpcmFlag[ xTbCmp ][ yTbCmp ][ cldx ] is equal to 0

[0138] - one of the following conditions is true:

[0139] - predModeIntra is equal to INTRA PLANAR

[0140] - predModeIntra is equal to INTRA DC

[0141] - predModeIntra is less than or equal to INTRA ANGULAR 18

[0142] - predModeIntra is greater than or equal to INTRA ANGULAR 50 and less than INTRA LT CCLM

[0143] reference sample availability flagging process

[0144] The input to the process is:

[0145] - a sample position ( xTbCmp, yTbCmp ) specifying the top-left sample of the current transform block relative to the top-left sample of the current picture,

[0146] - a variable refldx specifying the intra prediction reference line index,

[0147] - a variable refW specifying the width of the reference region in samples,

[0148] - a variable refH specifying the height of the reference region in samples,

[0149] - a variable cldx specifying the color component of the current block.

[0150] The output of the process is the reference samples refUnfilt[ x ][ y ] for intra sample prediction, where x = -1 - refldx, y = -1 - refldx.. refH - 1 and x = - refldx.. refW - 1, y = -1 - refldx.

[0151] As reconstructed samples prior to the cycle filter process, refW + refH + 1 + (2 * refldx) neighboring samples refUnfilt[x][y] (with x = -1 - refldx, y = -1 - refldx..refH - 1, and x = -refldx..refW - 1, y = -1 - refldx) are derived as follows:

[0152] - The neighboring position (xNbCmp, yNbCmp) is specified as follows:

[0153] (xNbCmp, yNbCmp) = (xTbCmp + x, yTbCmp + y)

[0154] - The current luma position (xTbY, yTbY) and the neighboring luma position (xNbY, yNbY) are derived as follows:

[0155] (xTbY, yTbY) = (cldx == 0)? (xTbCmp, yTbCmp) : (xTbCmp * SubWidthC, yTbCmp * SubHeightC)

[0156] (xTbCmp * SubWidthC, yTbCmp * SubHeightC)

[0157] (xNbY, yNbY) = (cldx == 0)? (xNbCmp, yNbCmp) : (xNbCmp * SubWidthC, yNbCmp * SubHeightC)

[0158] (xNbCmp * SubWidthC, yNbCmp * SubHeightC)

[0159] - The derivation process of the neighboring block availability specified as follows is invoked with the current luma position (xCurr, yCurr) set equal to (xTbY, yTbY), the neighboring luma position (xNbY, yNbY), checkPredModeY set equal to FALSE, and cldx as inputs, and the output is assigned to availableN.

[0160] - Each sample refUnfilt[x][y] is derived as follows:

[0161] - If availableN is equal to FALSE, the sample refUnfilt[x][y] is marked as “not available for intra prediction”.

[0162] - Otherwise, the sample refUnfilt[x][y] is marked as “available for intra prediction” and the sample at position (xNbCmp, yNbCmp) is assigned to refUnfilt[x][y].

[0163] derivation process for neighbouring block availability

[0164] The input of this process are:

[0165] - the luma position (xCurr, yCurr) of the top-left sample of the current block relative to the top-left luma sample of the current picture,

[0166] - the luma position (xNbY, yNbY) covered by the neighboring block relative to the top-left luma sample of the current picture,

[0167] - the variable checkPredModeY which specifies whether the availability depends on the prediction mode,

[0168] - the variable cldx which specifies the color component of the current block.

[0169] The output of this process is the availability of the neighboring block at the covered position (xNbY, yNbY), denoted as availableN.

[0170] The neighboring block availability availableN is derived as follows:

[0171] - availableN is set equal to FALSE if one or more of the following conditions are true:

[0172] - xNbY is less than 0.

[0173] - yNbY is less than 0.

[0174] - xNbY is greater than or equal to pic_width_in_luma_samples.

[0175] - yNbY is greater than or equal to pic_height_in_luma_samples.

[0176] - IsAvailable[cldx][xNbY][yNbY] is equal to FALSE.

[0177] - the neighboring block is contained in a different slice than the current block.

[0178] - the neighboring block is contained in a different tile than the current block.

[0179] - sps_entropy_coding_sync_enabled_flag is equal to 1 and (xNbY » CtbLog2SizeY) is greater than or equal to (xCurr » CtbLog2SizeY) + 1.

[0180] - Otherwise, availableN is set equal to TRUE.

[0181] availableN is set equal to FALSE when all of the following conditions are true:

[0182] - checkPredModeY is equal to TRUE.

[0183] - availableN is set equal to TRUE.

[0184] - CuPredMode[0][xNbY][yNbY] is not equal to CuPredMode[0][xCurr][yCurr].

[0185] reference sample replacement process

[0186] The inputs of the process are:

[0187] - a variable refldx specifying the intra prediction reference line index,

[0188] - a variable refW specifying the width of the reference region in sample units,

[0189] - a variable refH specifying the height of the reference region in sample units,

[0190] - the reference samples refUnfilt[x][y] for intra sample prediction, where x = -1 - refldx, y = -1 - refldx..refH - 1 and x = -refldx..refW - 1, y = -1 - refldx,

[0191] - a variable cldx specifying the color component of the current block.

[0192] The output of the process is the modified reference samples refUnfilt[x][y] for intra sample prediction, where x = -1 - refldx, y = -1 - refldx..refH - 1 and x = -refldx..refW - 1, y = -1 - refldx.

[0193] The value of the sample refUnfilt[x][y] (where x = -1 - refldx, y = -1 - refldx..refH - 1 and x = -refldx..refW - 1, y = -1 - refldx) is modified as follows:

[0194] - If all samples refUnfilt[x][y] with x = -1 - refldx, y = -1 - refldx..refH - 1 and x = -refldx..refW - 1, y = -1 - refldx are marked as "not available for intra prediction", all values of refUnfilt[x][y] are set equal to 1 « (BitDepth - 1).

[0195] - Otherwise (at least one but not all samples refUnfilt[x][y] are marked as "not available for intra prediction"), the following ordered steps are applied:

[0196] 1. When refUnfilt[-1 - refldx][refH - 1] is marked as "not available for intra prediction", search for a sample refUnfilt[x][y] marked as "available for intra prediction" in order from x = -1 - refldx, y = refH - 1 to x = -1 - refldx, y = -1 - refldx, and then from x = -refldx, y = -1 - refldx to x = refW - 1, y = -1 - refldx. Once a sample refUnfilt[x][y] marked as "available for intra prediction" is found, terminate the search and set the value of refUnfilt[-1 - refldx][refH - 1] equal to the value of refUnfilt[x][y].

[0197] 2. For x = -1 - refldx, y = refH - 2..-1 - refldx, when refUnfilt[x][y] is marked as "not available for intra prediction", set the value of refUnfilt[x][y] equal to the value of refUnfilt[x][y + 1].

[0198] 3. For x = -refldx..refW - 1, y = -1 - refldx, when refUnfilt[x][y] is marked as "not available for intra prediction", set the value of refUnfilt[x][y] equal to the value of refUnfilt[x - 1][y].

[0199] All samples refUnfilt[x][y] with x = -1 - refldx, y = -1 - refldx..refH - 1 and x = -refldx..refW - 1, y = -1 - refldx are marked as "available for intra prediction".

[0200] reference sample filtering process

[0201] The input to this process is:

[0202] - variable refldx specifying the intra prediction reference line index,

[0203] - variable nTbW specifying the transform block width,

[0204] - variable nTbH specifying the transform block height,

[0205] - variable refW specifying the reference sample width,

[0206] - variable refH specifying the reference sample height,

[0207] - variable refFilterFlag specifying the value of the reference filter flag,

[0208] - (unfiltered) neighboring samples refUnfilt[x][y] with x = -1 - refldx, y = -1 - refldx.. refH - 1 and x = -refldx.. refW - 1, y = -1 - refldx,

[0209] - variable cldx specifying the color component of the current block.

[0210] The output of the process is the reference samples p[x][y] with x = -1 - refldx, y = -1 - refldx.. refH - 1 and x = -refldx.. refW - 1, y = -1 - refldx.

[0211] The variable filterFlag is derived as follows:

[0212] - filterFlag is set equal to 1 if all of the following conditions are true:

[0213] - refldx is equal to 0

[0214] - nTbW * nTbH is greater than 32

[0215] - cldx is equal to 0

[0216] - IntraSubPartitionsSplitType is equal to ISP_NO_SPLIT

[0217] - refFilterFlag is equal to 1

[0218] - Otherwise, filterFlag is set equal to 0.

[0219] For the derivation of the reference samples p[x][y], the following applies:

[0220] - If filterFlag is equal to 1, the filtered sample values p[x][y] with x = -1, y = -1..refH-1 and x = 0..refW-1, y = -1 are derived as follows:

[0221] P[-1][-1] = (refUnfilt[-1][0] + 2*refUnfilt[-1][-1] + refUnfilt[0[-1] + 2) » 2 p[-1][y] =

[0222] (refUnfilt[-1][y+1] + 2*refUnfilt[-1][y] + refUnfilt[-1][y-1] + 2) » 2 for y = 0..refH-2

[0223] p[-1][refH-1] = refUnfilt[1][refH-1]

[0224] p[x][-1] =

[0225] (refUnfilt[x-1][-1] + 2*refUnfilt[x][-1] + refUnfilt[x+1][-1] + 2) » 2 for x = 0..refW-2

[0226] p[refW-1][-1] = refUnfilt[refW-1][-1]

[0227] Otherwise, the reference sample values p[x][y] are set equal to the unfiltered sample values refUnfilt[x][y] with x = -1-refIdx, y = -1-refIdx..refH-1 and x = -refIdx..refW-1, y = -1-refIdx.

[0228] JVET-Q2001 specifies the following intra prediction mode process for the Cross-Component Linear Model (CCLM) prediction mode:

[0229] The inputs of this process are:

[0230] - the intra prediction mode predModeIntra,

[0231] - the sample position (xTbC, yTbC) of the top-left sample of the current transform block relative to the top-left sample of the current picture,

[0232] - the variable nTbW specifying the transform block width,

[0233] - the variable nTbH specifying the transform block height,

[0234] - variable cldx specifying the color component of the current block,

[0235] - chroma neighboring samples p[x][y] with x = -1, y = 0..2*nTbH-1, and x = 0..2*nTbW-1, y = -1.

[0236] The output of this process is the predicted samples predSamples[x][y] with x = 0..nTbW-1, y = 0..nTbH-1.

[0237] The current luma position (xTbY, yTbY) is derived as follows:

[0238] (xTbY, yTbY) = (xTbC « (SubWidthC - 1), yTbC « (SubHeightC - 1))

[0239] The variables availL, availT and availTL are derived as follows:

[0240] - the neighboring block availability derivation process as specified above is invoked with the current luma position (xCurr, yCurr) set equal to (xTbY, yTbY), the neighboring luma position (xTbY - 1, yTbY), checkPredModeY set equal to FALSE and cldx as input and the output is assigned to availL.

[0241] - the neighboring block availability derivation process as specified above is invoked with the current luma position (xCurr, yCurr) set equal to (xTbY, yTbY), the neighboring luma position (xTbY, yTbY - 1), checkPredModeY set equal to FALSE and cldx as input and the output is assigned to availT.

[0242] - the variable availTL is derived as follows:

[0243] availTL = availL && availT

[0244] - the number of available top right chroma samples numTopRight is derived as follows:

[0245] - the variable numTopRight is set equal to 0 and availTR is set equal to TRUE.

[0246] - When predModeIntra is equal to INTRA_T_CCLM, the following applies for x = nTbW..2*nTbW-1 until availTR is equal to FALSE or x is equal to 2*nTbW-1:

[0247] - The derivation process of neighbouring block availability as described above is invoked with the current luma position (xCurr, yCurr) set equal to (xTbY, yTbY), the neighbouring luma position (xTbY+x, yTbY-1), checkPredModeY and cldx set equal to FALSE as inputs, and the output assigned to availTR

[0248] - When availTR is equal to TRUE, numTopRight is incremented by one.

[0249] - The number of available top-right chroma samples, numTopRight, is derived as follows:

[0250] - The variable numTopRight is set equal to 0 and availTR is set equal to TRUE.

[0251] - When predModeIntra is equal to INTRA_L_CCLM, the following applies for y = nTbH..2*nTbH-1 until availLB is equal to FALSE or y is equal to 2*nTbH-1:

[0252] - The derivation process of neighbouring block availability as described above is invoked with the current luma position (xCurr, yCurr) set equal to (xTbY, yTbY), the neighbouring luma position (xTbY-1, yTbY+y), checkPredModeY and cldx set equal to FALSE as inputs, and the output assigned to availLB

[0253] - When availLB is equal to TRUE, numLeftBelow is incremented by one.

[0254] The number of available top and top-right chroma samples, numSampT, and the number of available left and left-bottom chroma samples, numSampL, are derived as follows:

[0255] - If predModeIntra is equal to INTRA_LT_CCLM, the following applies:

[0256] numSampT = availT? nTbW : 0

[0257] numSampL = availL? nTbH : 0

[0258] - Otherwise, the following applies:

[0259] numSampT = (availT && predModeIntra == INTRA_T_CCLM)? (nTbW + Min(numTopRight, nTbH)) : 0

[0260] numSampL = (availL && predModeIntra == INTRA_L_CCLM)? (nTbH + Min(numLeftBelow, nTbW)) : 0

[0261] numSampN = (availN && predModeIntra == INTRA_N_CCLM)? (nTbW + Min(numTopRight, nTbH) + Min(numLeftBelow, nTbW)) : 0

[0262] numSampLT = (availT && availL && predModeIntra == INTRA_LT_CCLM)? (nTbW + Min(numTopRight, nTbH) + Min(numLeftBelow, nTbW)) : 0

[0263] The variable bCTUboundary is derived as follows:

[0264] bCTUboundary = (yTbY & (CtbSizeY - 1) == 0)? TRUE : FALSE.

[0265] The variables cntN and the array pickPosN, N replaced by L and T, are derived as follows:

[0266] - The variable numIs4N is derived as follows:

[0267] numIs4N = ((availT && availL && predModeIntra == INTRA_LT_CCLM)? 0 : 1)

[0268] - The variable startPosN is set equal to numSampN >>

[0269] - The variable pickStepN is set equal to Max(1, numSampN >>

[0270] - If availN is equal to TRUE and predModeIntra is equal to INTRA_LT_CCLM or INTRA_N_CCLM, the following assignments are made:

[0271] - cntN is set equal to Min(numSampN, (1 + numIs4N) «

[0272] - pickPosN[pos] is set equal to (startPosN + pos * pickStepN) for pos = 0..cntN-1.

[0273] - Otherwise, cntN is set equal to 0.

[0274] The prediction samples predSamples[ x ][ y ] with x = 0..nTbW - 1, y = 0..nTbH - 1 are derived as follows:

[0275] - If numSampL and numSampT are both equal to 0, the following applies:

[0276] predSamples[ x ][ y ] = 1 « ( BitDepth - 1 )

[0277] - Otherwise, the following ordered steps are applied:

[0278] 1. The collocated luma samples pY[ x ][ y ] with x = 0..nTbW * SubWidthC - 1, y = 0..nTbH * SubHeightC - 1 are set equal to the reconstructed luma samples at positions ( xTbY + x, yTbY + y ) prior to the deblocking filter process.

[0279] 2. The neighboring luma samples pY[ x ][ y ] are derived as follows:

[0280] - When numSampL is greater than 0, the neighboring left luma samples pY[ x ][ y ] with x = -1..-3, y = 0..SubHeightC * numSampL - 1 are set equal to the reconstructed luma samples at positions ( xTbY + x, yTbY + y ) prior to the deblocking filter process.

[0281] - When availT is equal to FALSE, the neighboring top luma samples pY[ x ][ y ] with x = -1..SubWidthC * numSampT - 1, y = are set equal to the luma samples pY[ x ][ 0 ].

[0282] - When availL is equal to FALSE, the neighboring left luma samples pY[ x ][ y ] with x = -1..-3, y = -1..SubHeightC * numSampL - 1 are set equal to the luma samples pY[ 0 ][ y ].

[0283] - When numSampT is greater than 0, the neighboring top luma samples pY[ x ][ y ] with x = 0..SubWidthC * numSampT - 1, y = -1,-2 are set equal to the reconstructed luma samples at positions ( xTbY + x, yTbY + y ) prior to the deblocking filter process.

[0284] - When availTL is equal to TRUE, the neighboring top-left luma sample pY[x][y] with x = -1, y = -1, -2 is set equal to the reconstructed luma sample at position (xTbY + x, yTbY + y) before the deblocking filter process.

[0285] 3. The down-sampled collocated luma samples pDsY[x][y] with x = 0..nTbW - 1, y = 0..nTbH - 1 are derived as follows:

[0286] - If SubWidthC and SubHeightC are both equal to 1, the following applies:

[0287] - The pDsY[x][y] with x = 1..nTbW - 1, y = 1..nTbH - 1 are derived as follows:

[0288] pDstY[x][y] = pY[x][y]

[0289] - Otherwise, the following applies:

[0290] - The two-dimensional filter coefficient arrays F1 and F2 and the two-dimensional filter coefficient arrays F3 and F4 are specified as follows.

[0291] F1[0] = 2, F1[1] = 0

[0292] F2[0] = 1, F2[1] = 2, F2[2] = 1

[0293] F3[i][j] = F4[i][j] = 0, with i = 0..2, j = 0..2

[0294] - If SubWidthC and SubHeightC are both equal to 2, the following applies:

[0295] F1[0] = 1, F1[1] = 1

[0296] F3[0][1] = 1, F3[1][1] = 4, F3[2][1] = 1,

[0297] F3[1][0] = 1, F3[1][2] = 1

[0298] F4[0][1] = 1, F4[1][1] = 2, F4[2][1] = 1

[0299] F4[0][2] = 1, F4[1][2] = 2, F4[2][2] = 1

[0300] - Otherwise, the following applies:

[0301] F3[1][1] = 8

[0302] F4[0][1] = 2, F4[1][1] = 4, F4[2][1] = 2,

[0303] - If sps_chroma_vertical_collocated_flag is equal to 1, the following applies:

[0304] - pDsY[ x ][ y ], where x = 0..nTbW - 1, y = 0..nTbH - 1, is derived as follows:

[0305] pDsY[ x ][ y ] = ( F3[1][0] * pY[ SubWidthC * x ][ SubHeightC * y - 1 ] + F3[0][1] * pY[ SubWidthC * x - 1 ][ SubHeightC * y ] + F3[1][1] * pY[ SubWidthC * x ][ SubHeightC * y ] + F3[2][1] * pY[ SubWidthC * x + 1 ][ SubHeightC * y ] + F3[1][2] * pY[ SubWidthC * x ][ SubHeightC * y + 1 ] + 4 ) » 3 *

[0306] - Else ( sps_chroma_vertical_collocated_flag is equal to 0 ), the following applies:

[0307] - pDsY[ x ][ y ], where x = 0..nTbW - 1, y = 0..nTbH - 1, is derived as follows:

[0308] pDsY[ x ][ y ] = ( F4[0][1] * pY[ SubWidthC * x - 1 ][ SubHeightC * y ] + F4[0][2] * pY[ SubWidthC * x - 1 ][ SubHeightC * y + 1 ] + F4[1][1] * pY[ SubWidthC * x ][ SubHeightC * y ] + F4[1][2] * pY[ SubWidthC * x ][ SubHeightC * y + 1 ] + F4[2][1] * pY[ SubWidthC * x + 1 ][ SubHeightC * y ] + F4[2][2] * pY[ SubWidthC * x + 1 ][ SubHeightC * y + 1 ] + 4 ) » 3

[0309] ​4. When numSampL is greater than 0, the selected neighboring left chroma samples pSelC[idx] are set equal to p[-1][pickPosL[idx]] (where idx = 0..cntL-1), and the selected downsampled neighboring left luma samples pSelDsY[idx] (where idx = 0..cntL-1) are derived as follows:

[0310] - The variable y is set equal to pickPosL[idx].

[0311] - If SubWidthC and SubHeightC are both equal to 1, the following applies:

[0312] pSelDsY[idx] = pY[-1][y]

[0313] - Otherwise, the following applies:

[0314] - If sps_chroma_vertical_collocated_flag is equal to 1, the following applies:

[0315] pSelDsY[idx] = (F3[1][0] * pY[-SubWidthC][SubHeightC*y-1] + F3[0][1] * pY[-1-SubWidthC][SubHeightC*y] + F3[1][1] * pY[-SubWidthC][SubHeightC*y] + F3[2][1] * pY[1-SubWidthC][SubHeightC*y] + F3[1][2] * pY[-SubWidthC][SubHeightC*y+1] + 4) » 3

[0316] - Otherwise (sps_chroma_vertical_collocated_flag is equal to 0),

[0317] The following applies:

[0318] pSelDsY[idx] = ( F4[0][1] * pY[ -1 - SubWidthC ][ SubHeightC * y ] + F4[0][2] * pY[ -1 - SubWidthC ][ SubHeightC * y + 1 ] + F4[1][1] * pY[ -SubWidthC ][ SubHeightC * y ] + F4[1][2] * pY[ -SubWidthC ][ SubHeightC * y + 1 ] + F4[2][1] * pY[ 1 - SubWidthC ][ SubHeightC * y ] + F4[2][2] * pY[ 1 - SubWidthC ][ SubHeightC * y + 1 ] + 4 ) » 3

[0319] 5. When numSampT is greater than 0, the selected neighboring top chroma samples pSelC[idx] are set equal to p[ pickPosT[ idx - cntL ] ][ -1 ] (where idx = cntL..cntL + cntT - 1 ), and the downsampled neighboring top luma samples pSelDsY[idx] (where idx = 0..cntL + cntT - 1 ) are specified as follows:

[0320] - The variable x is set equal to pickPosT[ idx - cntL ].

[0321] - If SubWidthC and SubHeightC are both equal to 1, the following applies:

[0322] pSelDsY[idx] = pY[ x ][ -1 ]

[0323] - Otherwise, the following applies:

[0324] - If spschroma_vertical_collocated_flag is equal to 1, the following applies:

[0325] - If bCTUboundary is equal to FALSE, the following applies:

[0326] pSelDsY[idx] = ( F3[1][0] * pY[ SubWidthC * x ][ -1 - SubHeightC ] + F3[0][1] * pY[ SubWidthC * x - 1 ][ -SubHeightC ] + F3[1][1] * pY[ SubWidthC * x ][ -SubHeightC ] + F3[2][1] * pY[ SubWidthC * x + 1 ][ -SubHeightC ] + F3[1][2] * pY[ SubWidthC * x ][ 1 - SubHeightC ] + 4 ) » 3

[0327] - Otherwise (bCTUboundary is equal to TRUE), the following applies:

[0328] pSelDsY[idx] = (F2[0] * pY[SubWidthC * x - 1][-1] + F2[1] * pY[SubWidthC * x][-1] + F2[2] * pY[SubWidthC * x + 1][-1] + 2) » 2

[0329] - Otherwise (sps_chroma_vertical_collocated_flag is equal to 0), the following applies:

[0330] - If bCTUboundary is equal to FALSE, the following applies:

[0331] pSelDsY[idx] = (F4[0][1] * pY[SubWidthC * x - 1][-1] + F4[0][2] * pY[SubWidthC * x - 1][-2] + F4[1][1] * pY[SubWidthC * x][-1] + F4[1][2] * pY[SubWidthC * x][-2] + F4[2][1] * pY[SubWidthC * x + 1][-1] + F4[2][2] * pY[SubWidthC * x + 1][-2] + 4) » 3

[0332] - Otherwise (bCTUboundary is equal to TRUE), the following applies:

[0333] pSelDsY[idx] = (F2[0] * pY[SubWidthC * x - 1][-1] + F2[1] * pY[SubWidthC * x][-1] + F2[2] * pY[SubWidthC * x + 1][-1] + 2) » 2

[0334] 6. When cntT + cntL is not equal to 0, the variables minY, maxY, minC and maxC are derived as follows:

[0335] - When cntT + cntL is equal to 2, pSelComp[3] is set equal to pSelComp[0], pSelComp[2] is set equal to pSelComp[1], pSelComp[0] is set equal to pSelComp[1], pSelComp[1] is set equal to pSelComp[3], where Comp is replaced by DsY and C.

[0336] - The arrays minGrpIdx and maxGrpIdx are derived as follows:

[0337] minGrpIdx[0] = 0

[0338] minGrpIdx[1] = 2

[0339] maxGrpIdx[0] = 1

[0340] maxGrpIdx[1] = 3

[0341] - When pSelDsY[minGrpIdx[0]] is greater than pSelDsY[minGrpIdx[1]], minGrpIdx[0] and minGrpIdx[1] are swapped as follows:

[0342] (minGrpIdx[0], minGrpIdx[1]) = Swap(minGrpIdx[0], minGrpIdx[1])

[0343] - When pSelDsY[maxGrpIdx[0]] is greater than pSelDsY[maxGrpIdx[1]], maxGrpIdx[0] and maxGrpIdx[1] are swapped as follows:

[0344] (maxGrpIdx[0], maxGrpIdx[1]) = Swap(maxGrpIdx[0], maxGrpIdx[1])

[0345] - When pSelDsY[minGrpIdx[0]] is greater than pSelDsY[maxGrpIdx[1]], the arrays minGrpIdx and maxGrpIdx are swapped as follows:

[0346] (minGrpIdx, maxGrpIdx) = Swap(minGrpIdx, maxGrpIdx)

[0347] - When pSelDsY[minGrpIdx[1]] is greater than pSelDsY[maxGrpIdx[0]], minGrpIdx[1] and maxGrpIdx[0] are swapped as follows:

[0348] (minGrpIdx[1], maxGrpIdx[0]) = Swap(minGrpIdx[1], maxGrpIdx[0])

[0349] - The variables maxY, maxC, minY and minC are derived as follows:

[0350] maxY = ( pSelDsY[ maxGrpIdx[ 0 ] ] + pSelDsY[ maxGrpIdx[ 1 ] ] + 1 ) » 1

[0351] maxC = ( pSelC[ maxGrpIdx[ 0 ] ] + pSelC[ maxGrpIdx[ 1 ] ] + 1 ) » 1

[0352] minY = ( pSelDsY[ minGrpIdx[ 0 ] ] + pSelDsY[ minGrpIdx[ 1 ] ] + 1 ) » 1

[0353] minC = ( pSelC[ minGrpIdx[ 0 ] ] + pSelC[ minGrpIdx[ 1 ] ] + 1 ) » 1

[0354] 7. The variables a, b and k are derived as follows:

[0355] - If numSampL is equal to 0 and numSampT is equal to 0, the following apply:

[0356] k = 0

[0357] a = 0

[0358] b = 1 « ( BitDepth - 1 )

[0359] - Otherwise, the following apply:

[0360] diff = maxY - minY

[0361] - If diff is not equal to 0, the following apply:

[0362] diffC = maxC - minC

[0363] x = Floor( Log2( diff ) )

[0364] normDiff = ( ( diff « 4 ) » x ) & 15

[0365] x += ( normDiff!= 0 )? 1 : 0

[0366] y = Abs( diffC ) > 0? Floor( Log2( Abs( diffC ) ) ) + 1 : 0

[0367] a = ( diffC * ( divSigTable[ normDiff ] | 8 ) + 2 y-1 ) » y

[0368] k = ( ( 3 + x - y ) < 1 )? 1 : 3 + x - y

[0369] a = ((3 + x - y) < 1)? Sign(a) * 15 : a

[0370] b = minC - ((a * minY) » k)

[0371] where divSigTable[ ] is specified as follows:

[0372] divSigTable[ ] = { 0, 7, 6, 5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 1, 1, 0}

[0373] - Otherwise (diff is equal to 0), the following applies:

[0374] k = 0

[0375] a = 0

[0376] b = minC

[0377] 8. The prediction samples predSamples[ x ][ y ] (with x = 0..nTbW - 1, y = 0..nTbH - 1) are derived as follows:

[0378] predSamples[ x ][ y ] = Clip1( ( ( pDsY[ x ][ y ] * a ) » k ) + b )

[0379] NOTE - This process uses sps_chroma_vertical_collocated_flag. However, for simplicity of implementation, it does not use sps_chroma_horizontal_collocated_flag.

[0380] In case the syntax element sps_chroma_vertical_collocated_flag is included in the SPS and has the following semantics:

[0381] sps_chroma_vertical_collocated_flag equal to 1 specifies that the prediction process operates in a way designed for chroma sample positions that are not vertically shifted relative to the corresponding luma sample positions. sps_chroma_vertical_collocated_flag equal to 0 specifies that the prediction process operates in a way designed for chroma sample positions that are shifted downward by 0.5 luma sample unit relative to the corresponding luma sample positions. When sps_chroma_vertical_collocated_flag is not present, it is inferred to be equal to 1.

[0382] The intra prediction mode process for the cross-component linear model (CCLM) prediction mode specified in JVET-Q2001 is less than ideal when operating in at least the following cases: (1) when the top-left neighbor is not available, and (2) when processing video having a 4:2:2 chroma format. According to the techniques herein, a process for the cross-component linear model (CCLM) prediction mode is provided in which the processing of the above cases is improved.

[0383] FIG. 1 is a block diagram illustrating an example of a system that can be configured to encode (e.g., encode and / or decode) video data according to one or more techniques of this disclosure. System 100 represents an example of a video data system that can be encapsulated according to one or more techniques of this disclosure. As shown, system 100 includes source device 102, communication medium 110, and destination device 120. In the example shown, source device 102 can include any device configured to encode video data and transmit the encoded video data to communication medium 110. Destination device 120 can include any device configured to receive encoded video data via communication medium 110 and decode the encoded video data. Source device 102 and / or destination device 120 can include computing devices equipped for wired and / or wireless communication, and can include, for example, set-top boxes, digital video recorders, televisions, desktop computers, laptop computers or tablet computers, game consoles, medical imaging devices, and mobile devices including, for example, smartphones, cellular telephones, personal gaming devices. FIG. 1 FIG. 1

[0384] Communication medium 110 can include any combination of wireless and wired communication media and / or storage devices. Communication medium 110 can include coaxial cables, fiber optic cables, twisted pair cables, wireless transmitters and receivers, routers, switches, repeaters, base stations, or any other equipment that can functionally facilitate communication between various devices and sites. Communication medium 110 can include one or more networks. For example, communication medium 110 can include a network configured to enable access to the World Wide Web, for example, the Internet. The network can operate according to one or more combinations of telecommunications protocols. The telecommunications protocols can include proprietary aspects and / or can include standard telecommunications protocols. Examples of standard telecommunications protocols include digital video broadcasting (DVB) standards, advanced television systems committee (ATSC) standards, integrated services digital broadcasting (ISDB) standards, data over cable service interface specification (DOCSIS) standards, global system for mobile communications (GSM) standards, code division multiple access (CDMA) standards, third generation partnership project (3GPP) standards, European telecommunications standards institute (ETSI) standards, Internet protocol (IP) standards, wireless application protocol (WAP) standards, and institute of electrical and electronics engineers (IEEE) standards. ​​

[0385] A storage device can include any type of device or storage medium capable of storing data. A storage medium can include a tangible or non-transitory computer-readable medium. A computer readable medium can include optical, flash memory, magnetic memory, or any other suitable digital storage medium. In some examples, a memory device or portions thereof can be described as non-volatile storage, and in other examples portions of a memory device can be described as volatile storage. Examples of volatile storage can include random access memory (RAM), dynamic random access memory (DRAM), and static random access memory (SRAM). Examples of non-volatile storage can include magnetic, optical, flash, or forms of electrically programmable memory such as EPROM and electrically erasable and programmable (EEPROM) memory. A storage device can include a memory card (e.g., a Secure Digital (SD) memory card), an internal / external hard disk drive, and / or an internal / external solid state drive. Data can be stored on a storage device in accordance with a defined file format.

[0386] FIG. 6 is a conceptual diagram illustrating examples of components that can be included in implementations of the system 100. In FIG. 6 In the example implementation shown, the system 100 includes one or more computing devices 402A-402N, a television service network 404, a television service provider site 406, a wide area network 408, a local area network 410, and one or more content provider sites 412A-412N. FIG. 6 The implementation shown in FIG. 1 represents an example of a system that can be configured to allow digital media content, such as movies, live sporting events, etc., and data and applications associated therewith and media presentations to be distributed to and accessed by a plurality of computing devices, such as the computing devices 402A-402N. In FIG. 6 In the example shown, the computing devices 402A-402N can include any devices configured to receive data from one or more of the television service network 404, the wide area network 408, and / or the local area network 410. For example, the computing devices 402A-402N can be equipped for wired and / or wireless communication, and can be configured to receive services over one or more data channels, and can include televisions, including so-called smart televisions, set-top boxes, and digital video recorders. In addition, the computing devices 402A-402N can include desktop computers, laptop or tablet computers, game consoles, mobile devices, including, for example, “smart” phones, cellular telephones, and personal gaming devices.

[0387] The television service network 404 is an example of a network configured to enable the distribution of digital media content that can include television services. For example, the television service network 404 can include public over-the-air television networks, public or subscription-based satellite television service provider networks, and public or subscription-based cable television provider networks and / or over-the-top or Internet service providers. It should be noted that although in some examples the television service network 404 can primarily be used to allow for the provision of television services, the television service network 404 can also allow for the provision of other types of data and services in accordance with any combination of the telecommunication protocols described herein. Further, it should be noted that in some examples the television service network 404 can allow for bidirectional communication between the television service provider site 406 and one or more of the computing devices 402A-402N. The television service network 404 can include any combination of wireless and / or wired communication media. The television service network 404 can include coaxial cables, fiber optic cables, twisted pair cables, wireless transmitters and receivers, routers, switches, repeaters, base stations, or any other equipment that can be useful to facilitate communications between various devices and sites. The television service network 404 can operate according to one or more combinations of telecommunication protocols. The telecommunication protocols can include proprietary aspects and / or can include standardized telecommunication protocols. Examples of standardized telecommunication protocols include DVB standards, ATSC standards, ISDB standards, DTMB standards, DMB standards, Data Over Cable Service Interface Specification (DOCSIS) standards, HbbTV standards, W3C standards, and UPnP standards.

[0388] Referring again to FIG. 6 , the television service provider site 406 can be configured to distribute television services via the television service network 404. For example, the television service provider site 406 can include one or more broadcast stations, cable television providers, or satellite television providers or Internet-based television providers. For example, the television service provider site 406 can be configured to receive transmissions (including television programs) through satellite uplink / downlink. Further, as shown, the television service provider site 406 can be in communication with the wide area network 408 and can be configured to receive data from the content provider sites 412A-412N. It should be noted that in some examples the television service provider site 406 can include a television studio and content can originate from the television studio. FIG. 6

[0389] ​The wide area network 408 can include a packet-based network, and operate according to a combination of one or more telecommunication protocols. The telecommunication protocols can include proprietary aspects and / or can include standard telecommunications protocols. Examples of standard telecommunications protocols include the global system for mobile communications (GSM) standard, code division multiple access (CDMA) standards, 3rd Generation Partnership Project (3GPP) standards, European Telecommunications Standards Institute (ETSI) standards, European Norm (EN), IP standards, wireless application protocol (WAP) standards, and Institute of Electrical and Electronics Engineers (IEEE) standards, such as one or more IEEE 802 standards (e.g., Wi-Fi). The wide area network 408 can include any combination of wireless and / or wired communication media. The wide area network 408 can include coaxial cables, fiber optic cables, twisted pair cables, Ethernet cables, wireless transmitters and receivers, routers, switches, repeaters, base stations, or any other equipment that can be useful to facilitate communications between various devices and sites. In one example, the wide area network 408 can include the Internet. The local area network 410 can include a packet-based network, and operate according to a combination of one or more telecommunication protocols. The local area network 410 can be distinguished from the wide area network 408 based on access level and / or physical infrastructure. For example, the local area network 410 can include a secure home network.

[0390] Referring again to FIG. 6 , the content provider sites 412A-412N represent examples of sites that can provide multimedia content to the television service provider site 406 and / or the computing devices 402A-402N. For example, the content provider sites can include a studio having one or more studio content servers configured to provide multimedia files and / or streams to the television service provider site 406. In one example, the content provider sites 412A-412N can be configured to provide multimedia content using the IP suite. For example, the content provider sites can be configured to provide multimedia content to receiver devices according to the real-time streaming protocol (RTSP), HTTP, and / or the like. In addition, the content provider sites 412A-412N can be configured to provide data, including hypertext-based content and / or the like, to one or more of the receiver devices 402A-402N and / or the television service provider site 406 over the wide area network 408. The content provider sites 412A-412N can include one or more web servers. The data provided by the content provider sites 412A-412N can be defined according to a data format.

[0391] Referring again to FIG. 1Source device 102 includes a video source 104, a video encoder 106, a data encapsulator 107, and an interface 108. Video source 104 may include any device configured to capture and / or store video data. For example, video source 104 may include a camera and a storage device operatively coupled thereto. Video encoder 106 may include any device configured to receive video data and generate a compatible bitstream representing the video data. A compatible bitstream can refer to a bitstream from which a video decoder can receive and reproduce video data. Aspects of a compatible bitstream may be defined according to a video coding standard. When generating a compatible bitstream, video encoder 106 may compress the video data. Compression may be lossy (perceptible to an observer) or lossless. FIG. 7 This is a block diagram illustrating an example of a video encoder 500 that can implement the techniques described herein for encoding video data. It should be noted that although the exemplary video encoder 500 is shown as having different functional blocks, such illustrations are intended for descriptive purposes and do not limit the video encoder 500 and / or its sub-components to a particular hardware or software architecture. The functionality of the video encoder 500 can be implemented using any combination of hardware, firmware, and / or software implementations.

[0392] The video encoder 500 can perform intra-frame predictive coding and inter-frame predictive coding of image regions, and therefore can be called a hybrid video encoder. FIG. 7 In the example shown, video encoder 500 receives a source video block. In some examples, the source video block may include picture regions that have been partitioned according to the coding structure. For example, source video data may include macroblocks, CTUs, CBs, their sub-partitions, and / or another equivalent coding unit. In some examples, video encoder 500 may be configured to perform additional subdivision of the source video block. It should be noted that the techniques described herein are generally applicable to video coding, regardless of how the source video data is partitioned before and / or during coding. FIG. 7 In the example shown, the video encoder 500 includes an adder 502, a transform coefficient generator 504, a coefficient quantization unit 506, an inverse quantization and transform coefficient processing unit 508, an adder 510, an intra-frame prediction processing unit 512, an inter-frame prediction processing unit 514, a filter unit 516, and an entropy coding unit 518. FIG. 7 As shown, the video encoder 500 receives source video blocks and outputs a bitstream.

[0393] exist FIG. 7In the illustrated example, video encoder 500 can generate residual data by subtracting the predicted video block from the source video block. The selection of the predicted video block is described in detail below. Summer 502 represents the component configured to perform this subtraction operation. In one example, the subtraction of the video blocks occurs in the pixel domain. Transform coefficient generator 504 applies a transform, such as a discrete cosine transform (DCT), a discrete sine transform (DST), or a conceptually similar transform that can be considered a member of the class of integer and / or integer-like transforms, to a residual block or sub-partition thereof to produce a set of residual transform coefficients. Transform coefficient generator 504 can be configured to perform any and all combinations of the transforms included in the family of discrete trigonometric transforms, including approximations thereof. Transform coefficient generator 504 can output the transform coefficients to quantization unit 506. Quantization unit 506 can be configured to perform quantization of the transform coefficients. The quantization process can reduce the bit depth associated with some or all of the coefficients. The degree of quantization can alter the rate-distortion (i.e., bit rate versus video quality) of the encoded video data. The degree of quantization can be modified by adjusting a quantization parameter (QP). The quantization parameter can be determined based on slice level values and / or CU level values (e.g., CU delta QP values). QP data can include any data used to determine the QP used to quantize a particular set of transform coefficients. As FIG. 7 As illustrated, the quantized transform coefficients (which can be referred to as level values) are output to inverse quantization and transform coefficient processing unit 508. Inverse quantization and transform coefficient processing unit 508 can be configured to apply inverse quantization and inverse transforms to generate reconstructed residual data. As FIG. 7 As illustrated, at summer 510, the reconstructed residual data can be added to the predicted video block. In this manner, the encoded video block can be reconstructed, and the resulting reconstructed video block can be used to evaluate the quality of the encoding for a given prediction, transform, and / or quantization. Video encoder 500 can be configured to perform multiple encoding passes (e.g., perform encoding while varying one or more of the prediction, transform parameters, and quantization parameters). The rate-distortion or other system parameters of the bitstream can be optimized based on the evaluation of the reconstructed video blocks. Moreover, the reconstructed video blocks can be stored and used as a reference for predicting subsequent blocks.

[0394] Referring again to FIG. 7Intra prediction processing unit 512 can be configured to select an intra prediction mode for a video block to be encoded. Intra prediction processing unit 512 can be configured to evaluate the frame and determine an intra prediction mode to use to encode the current block. As noted above, possible intra prediction modes can include planar prediction mode, DC prediction mode, and angular prediction modes. Moreover, it should be noted that in some examples, the prediction mode for chroma components can be inferred from the prediction mode for the luma prediction mode. Intra prediction processing unit 512 can select the intra prediction mode after performing one or more encoding passes. Moreover, in one example, intra prediction processing unit 512 can select the prediction mode based on a rate-distortion analysis. As shown in FIG. 5, intra prediction processing unit 512 outputs intra prediction data (e.g., syntax elements) to entropy encoding unit 518 and transform coefficient generator 504. As noted above, the transform performed on the residual data can be mode dependent (e.g., a quadratic transform matrix can be determined based on the prediction mode). FIG. 7

[0395] As noted above, the intra prediction mode process for cross-component linear model (CCLM) prediction modes provided in JVET-Q2001 is less than ideal. In one example, in accordance with the techniques herein, the intra prediction mode process for cross-component linear model (CCLM) prediction modes can be based on the following:

[0396] The inputs to this process are:

[0397] - an intra prediction mode predModeIntra,

[0398] - the sample position (xTbC, yTbC) of the top-left sample of the current transform block relative to the top-left sample of the current picture,

[0399] - a variable nTbW specifying the transform block width,

[0400] - a variable nTbH specifying the transform block height,

[0401] - a variable cldx specifying the color component of the current block,

[0402] - chroma neighboring samples p[x][y] with x = -1, y = 0..2*nTbH-1, and x = 0..2*nTbW-1, y = -1.

[0403] The output of this process is the predicted samples predSamples[x][y] with x = 0..nTbW-1, y = 0..nTbH-1.

[0404] The current luma position (xTbY, yTbY) is derived as follows:

[0405] ​(xTbY, yTbY) = (xTbC « (SubWidthC - 1), yTbC « (SubHeightC - 1))

[0406] The variables availL, availT and availTL are derived as follows:

[0407] - The derivation process of neighbouring block availability as specified above is invoked with the current luma position (xCurr, yCurr) set equal to (xTbY, yTbY), the neighbouring luma position (xTbY - 1, yTbY), checkPredModeY set equal to FALSE and cldx as input and the output assigned to availL.

[0408] - The derivation process of neighbouring block availability as specified above is invoked with the current luma position (xCurr, yCurr) set equal to (xTbY, yTbY), the neighbouring luma position (xTbY, yTbY - 1), checkPredModeY set equal to FALSE and cldx as input and the output assigned to availT.

[0409] - The derivation process of neighbouring block availability as specified above is invoked with the current luma position (xCurr, yCurr) set equal to (xTbY, yTbY), the neighbouring luma position (xTbY - 1, yTbY - 1), checkPredModeY set equal to FALSE and cldx as input and the output assigned to availTL.

[0410] - The number of available top right chroma samples, numTopRight, is derived as follows:

[0411] - The variable numTopRight is set equal to 0 and availTR is set equal to TRUE.

[0412] - When predModeIntra is equal to INTRA_T_CCLM, the following applies for x = nTbW.. 2 * nTbW - 1 until availTR is equal to FALSE:

[0413] - The derivation process of neighbouring block availability as specified above is invoked with the current luma position (xCurr, yCurr) set equal to (xTbY, yTbY), the neighbouring luma position (xTbY + x, yTbY - 1), checkPredModeY set equal to FALSE and cldx as input and the output assigned to availTR

[0414] - When availTR is equal to TRUE, numTopRight is incremented by one.

[0415] - The number of available top-right chroma samples numTopRight is derived as follows:

[0416] - The variable numTopRight is set equal to 0 and availTR is set equal to TRUE.

[0417] - When predModeIntra is equal to INTRA_L_CCLM, the following applies for y = nTbH..2*nTbH-1 until availLB is equal to FALSE:

[0418] - The derivation process of neighbouring block availability as specified in clause 6.4.4 is invoked with the current luma position (xCurr, yCurr) set equal to (xTbY, yTbY), the neighbouring luma position (xTbY-1, yTbY+y), checkPredModeY and cldx set equal to FALSE as inputs, and the output is assigned to availLB

[0419] - When availLB is equal to TRUE, numLeftBelow is incremented by one.

[0420] The number of available top and top-right chroma samples numSampT and the number of available left and left- below chroma samples numSampL are derived as follows:

[0421] - If predModeIntra is equal to INTRA LT_CCLM, the following applies:

[0422] numSampT = availT? nTbW : 0

[0423] numSampL = availL? nTbH : 0

[0424] - Otherwise, the following applies:

[0425] numSampT = (availT && predModeIntra == INTRA_T_CCLM)?

[0426] (nTbW + Min(numTopRight, nTbH)) : 0

[0427] numSampL = (availL && predModeIntra == INTRA_L_CCLM)?

[0428] (nTbH + Min(numLeftBelow, nTbW)) : 0

[0429] The variable bCTUboundary is derived as follows:

[0430] bCTUboundary = (yTbY & (CtbSizeY - 1) == 0)? TRUE : FALSE.

[0431] The variables cntN and the array pickPosN, N replaced by L and T, are derived as follows:

[0432] The variable numIs4N is derived as follows:

[0433] numIs4N = ((availT && availL && predModeIntra == INTRA_LT_CCLM)? 0 : 1)

[0434] The variable startPosN is set equal to numSampN » (2 + numIs4N).

[0435] The variable pickStepN is set equal to Max(1, numSampN » (1 + numIs4N)).

[0436] If availN is equal to TRUE and predModeIntra is equal to INTRA_LT_CCLM or INTRA_N_CCLM, the following assignments are made:

[0437] cntN is set equal to Min(numSampN, (1 + numIs4N) « 1).

[0438] pickPosN[pos] is set equal to (startPosN + pos * pickStepN) for pos = 0..cntN - 1.

[0439] Otherwise, cntN is set equal to 0.

[0440] The prediction samples predSamples[x][y] for x = 0..nTbW - 1, y = 0..nTbH - 1 are derived as follows:

[0441] If numSampL and numSampT are both equal to 0, the following applies:

[0442] predSamples[x][y] = 1 « (BitDepth - 1)

[0443] Otherwise, the following ordered steps apply:

[0444] 1. The collocated luma sample pY[x][y] (with x = 0..nTbW*SubWidthC-1, y = 0..nTbH*SubHeightC-1) is set equal to the reconstructed luma sample at position (xTbY+x, yTbY+y) before the deblocking filter process.

[0445] 2. The neighboring luma samples pY[x][y] are derived as follows:

[0446] - When availL is equal to FALSE, the neighboring left luma sample pY[x][y] (with x = -1, y = 0..SubHeightC*nTbH-1) is set equal to the luma sample pY[0][y].

[0447] - When availL is equal to TRUE, the neighboring left luma sample pY[x][y] (with x = -1, y = 0..SubHeightC*nTbH-1) is set equal to the reconstructed luma sample at position (xTbY+x, yTbY+y) before the deblocking filter process.

[0448] - When numSampL is greater than 0, the neighboring left luma samples pY[x][y] (with x = -1..-3, y = 0..SubHeightC*numSampL-1) are set equal to the reconstructed luma samples at position (xTbY+x, yTbY+y) before the deblocking filter process.

[0449] - When numSampL is greater than 0 and availTL is equal to TRUE, the neighboring top-left sample pY[-2][-1] is set equal to the reconstructed luma sample at position (xTbY-2, yTbY-1) before the deblocking filter process.

[0450] - When numSampL is greater than 0 and availTL is equal to FALSE, the neighboring top-left sample pY[-2][-1] is set equal to the luma sample pY[-2][0].

[0451] - When availT is equal to FALSE, the neighboring top luma sample pY[x][y] (with x = 0..SubWidthC*nTbW-1, y = -1) is set equal to the luma sample pY[x][0].

[0452] - When availT is equal to TRUE, the neighboring top luma sample pY[x][y] (with x = 0..SubWidthC*nTbW-1, y = -1) is set equal to the reconstructed luma sample at position (xTbY+x, yTbY+y) before the deblocking filter process.

[0453] - When numSampT is greater than 0, the neighboring top luma samples pY[x][y] with x = 0..SubWidthC*numSampT - 1, y = -1..-3 are set equal to the reconstructed luma samples at positions (xTbY + x, yTbY + y) before the deblocking filter process.

[0454] - When numSampT is greater than 0 and availTL is equal to TRUE, the neighboring top-left sample pY[-1][y] with y = -1..-2 is set equal to the reconstructed luma sample at position (xTbY - 1, yTbY + y) before the deblocking filter process.

[0455] - When numSampT is greater than 0 and availTL is equal to FALSE, the neighboring top-left sample pY[-1][y] with y = -1..-2 is set equal to the luma sample pY[0][y].

[0456] 3. The downsampled collocated luma samples pDsY[x][y] with x = 0..nTbW - 1, y = 0..nTbH - 1 are derived as follows:

[0457] - If SubWidthC and SubHeightC are both equal to 1, the following applies:

[0458] - The pDsY[x][y] with x = 0..nTbW - 1, y = 0..nTbH - 1 are derived as follows:

[0459] pDsY[x][y] = pY[x][y]

[0460] - Otherwise, the following applies:

[0461] - The filter coefficient array F1 is specified as follows.

[0462] - If SubWidthC and SubHeightC are both equal to 2, the following applies:

[0463] F1[0] = 1, F1[1] = 1

[0464] - Otherwise, the following applies:

[0465] F1[0] = 2, F1[1] = 0

[0466] - If sps_chroma_vertical_collocated_flag is equal to 1, the following applies:

[0467] - pDsY[x][y] (with x = 0..nTbW-1, y = 0..nTbH-1) is derived as follows:

[0468] pDsY[x][y] = (Fl[l]*pY[SubWidthC*x][SubHeightC*(y-1)+l] + Fl[O]*pY[SubWidthC*x- l][SubHeightC*y] + 4*pY[SubWidthC*x][SubHeightC*y] + Fl[O]*pY[SubWidthC*x+ l][SubHeightC*y] + Fl[l]*pY[SubWidthC*x][SubHeightC*(y+ l)-l] + 4) » 3

[0469] In one example, pDsY[x][y] (with x = 0..nTbW-1,

[0470] y = 0..nTbH-1) can be derived as follows:

[0471] pDsY[x][y] = (Fl[l]*pY[SubWidthC*x][SubHeightC*(y-1)+l] + Fl[O]*pY[SubWidthC*x- l][SubHeightC*y] + 4*pY[SubWidthC*x][SubHeightC*y] + Fl[O]*pY[SubWidthC*x+ l][SubHeightC*y] + Fl[l]*pY[SubWidthC*x][SubHeightC*(y+ l)-l] + 4) » 3

[0472] - Otherwise (sps_chroma_vertical_collocated_flag is equal to 0), the following applies:

[0473] - pDsY[x][y] (with x = 0..nTbW-1, y = 0..nTbH-1) is derived as follows:

[0474] pDsY[x][y] = (pY[SubWidthC*x- l][SubHeightC*y] + pY[SubWidthC*x- l][SubHcightC*y+ l] + 2*pY[SubWidthC*x][SubHeightC*y] + 2*pY[SubWidthC*x][SubHeightC*y+ l] + pY[SubWidthC*x+ l][SubHeightC*y] + pY[SubWidthC*x+ l][SubHeightC*y+ l] + 4) » 3

[0475] 4. When numSampT is greater than 0, the selected neighboring top chroma sample pSelC[idx] is set equal to p[pickPosT[idx]][-1] (where idx = 0..cntT-1), and the downsampled neighboring top luma sample pSelDsY[idx] (where idx = 0..cntT-1) is specified as follows:

[0476] - The variable x is set equal to pickPosT[idx].

[0477] - If SubWidthC and SubHeightC are both equal to 1, the following applies:

[0478] pSelDsY[idx] = pY[x][-1]

[0479] - Otherwise, the following applies:

[0480] - If bCTUboundary is equal to FALSE, the following applies:

[0481] - If sps_chroma_vertical_collocated_flag is equal to 1, the following applies:

[0482] pSelDsY[idx] = (F1[1] * pY[SubWidthC * x][-1 - SubHeightC] + F1[0] * pY[SubWidthC * x - 1][-SubHeightC] + 4 * pY[SubWidthC * x][-SubHeightC] + F1[0] * pY[SubWidthC * x + 1][-SabHeightC] + F1[1] * pY[SubWidthC * x][1 - SubHeightC] + 4) » 3

[0483] In one example, pSelDsY[idx] can be specified as follows:

[0484] pSelDsY[idx] = (F1[1] * pY[SubWidthC * x][1 - 2 * SubHeightC] + F1[0] * pY[SubWidthC * x - 1][-SubHeightC] + 4 * pY[SubWidthC * x][-SubHeightC] + F1[0] * pY[SubWidthC * x + 1][-SubHeightC] + F1[1] * pY[SubWidthC * x][-1] + 4) » 3

[0485] - Otherwise (sps_chroma_vertical_collocated_flag is equal to 0), the following applies:

[0486] pSelDsY[idx] = ( pY[ SubWidthC * x - 1 ][ -1 ] + pY[ SubWidthC * x - 1 ][ -2 ] + 2 * pY[ SubWidthC * x ][ 1 ] + 2 * pY[ SubWidthC * x ][ -2 ] + pY[ SubWidthC * x + 1 ][ -1 ] + pY[ SubWidthC * x + 1 ][ -2 ] + 4 ) » 3

[0487] - Otherwise (bCTUboundary is equal to TRUE), the following applies:

[0488] pSelDsY[idx] = ( pY[ SubWidthC * x - 1 ][ -1 ] + 2 * pY[ SubWidthC * x ][ -1 ] + pY[ SubWidthC * x + 1 ][ -1 ] + 2 ) » 2

[0489] 5. When numSampL is greater than 0, the selected neighboring left chroma sample pSelC[idx] is set equal to p[ -1 ][ pickPosL[ idx - cntT ] ] (where idx = cntT..cntT+cntL-1), and the selected downsampled neighboring left luma sample pSelDsY[idx] (where idx = cntT..cntT+cntL-1) is derived as follows:

[0490] - The variable y is set equal to pickPosL[ idx - cntT ].

[0491] - If SubWidthC and SubHeightC are both equal to 1, the following applies:

[0492] pSelDsY[idx] = pY[ -1 ][ y ]

[0493] - Otherwise, the following applies:

[0494] - If sps_chroma_vertical_collocated_flag is equal to 1, the following applies:

[0495] pSelDsY[idx] = (F1[1] * pY[-SubWidthC][SubHeightC * y - 1] + F1[0] * pY[-1 - SubWidthC][SubHeightC * y] + 4 * pY[-SubWidthC][SubHeightC * y] + F1[0] * pY[1 - SubWidthC][SubHeightC * y] + F1[1] * pY[-SubWidthC][SubHeightC * y + 1] + 4) » 3

[0496] In one example, pSelDsY[idx] can be specified as follows:

[0497] pSelDsY[idx] = (F1[1] * pY[-SubWidthC][SubHeightC * (y - 1) + 1] + F1[0] * pY[-1 - SubWidthC][SubHeightC * y] + 4 * pY[-SubWidthC][SubHeightC * y] + F1[0] * pY[1 - SubWidthC][SubHeightC * y] + F1[1] * pY[-SubWidthC][SubHeightC * (y + 1) - 1] + 4) » 3

[0498] - Otherwise (sps_chroma_vertical_collocated_flag is equal to 0),

[0499] The following applies:

[0500] pSelDsY[idx] = (pY[-1 - SubWidthC][SubHeightC * y] + pY[-1 - SubWidthC][SubHeightC * y + 1] + 2 * pY[-SubWidthC][SubHeightC * y] + 2 * pY[-SubWidthC][SubHeightC * y + 1] + pY[1 - SubWidthC][SubHeightC * y] + pY[1 - SubWidthC][SubHeightC * y + 1] + 4) » 3

[0501] 6. When cntT + cntL is not equal to 0, the variables minY, maxY, minC and maxC are derived as follows:

[0502] - When cntT + cntL is equal to 2, pSelComp[3] is set equal to pSelComp[0], pSelComp[2] is set equal to pSelComp[1], pSelComp[0] is set equal to pSelComp[1], pSelComp[1] is set equal to pSelComp[3], with Comp replaced by DsY and C.

[0503] - The arrays minGrpIdx and maxGrpIdx are derived as follows:

[0504] minGrpIdx[0] = 0

[0505] minGrpIdx[1] = 2

[0506] maxGrpIdx[0] = 1

[0507] maxGrpIdx[1] = 3

[0508] - When pSelDsY[minGrpIdx[0]] is greater than pSelDsY[minGrpIdx[1]], minGrpIdx[0] and minGrpIdx[1] are swapped as follows:

[0509] (minGrpIdx[0], minGrpIdx[1]) = Swap(minGrpIdx[0], minGrpIdx[1])

[0510] - When pSelDsY[maxGrpIdx[0]] is greater than pSelDsY[maxGrpIdx[1]], maxGrpIdx[0] and maxGrpIdx[1] are swapped as follows:

[0511] (maxGrpIdx[0], maxGrpIdx[1]) = Swap(maxGrpIdx[0], maxGrpIdx[1])

[0512] - When pSelDsY[minGrpIdx[0]] is greater than pSelDsY[maxGrpIdx[1]], the arrays minGrpIdx and maxGrpIdx are swapped as follows:

[0513] (minGrpIdx, maxGrpIdx) = Swap(minGrpIdx, maxGrpIdx)

[0514] - When pSelDsY [minGrpIdx[1]] is greater than pSelDsY [maxGrpIdx[0]], minGrpIdx[1] and maxGrpIdx[0] are swapped as follows:

[0515] (minGrpIdx[1], maxGrpIdx[0]) = Swap(minGrpIdx[1], maxGrpIdx[0])

[0516] - Variables maxY, maxC, minY and minC are derived as follows:

[0517] maxY = (pSelDsY [maxGrpIdx[0]] + pSelDsY [maxGrpIdx[1]] + 1) » 1

[0518] maxC = (pSelC [maxGrpIdx[0]] + pSelC [maxGrpIdx[1]] + 1) » 1

[0519] minY = (pSelDsY [minGrpIdx[0]] + pSelDsY [minGrpIdx[1]] + 1) » 1

[0520] minC = (pSelC [minGrpIdx[0]] + pSelC [minGrpIdx[1]] + 1) » 1

[0521] 7. Variables a, b and k are derived as follows:

[0522] - If numSampL is equal to 0 and numSampT is equal to 0, the following apply:

[0523] K = 0

[0524] a = 0

[0525] b = 1 « (BitDepth - 1)

[0526] - Otherwise, the following apply:

[0527] diff = maxY - minY

[0528] - If diff is not equal to 0, the following apply:

[0529] diffC = maxC - minC

[0530] x = Floor(Log2(diff))

[0531] normDiff = ((diff « 4) » x) & 15

[0532] x+ = (normDiff!= 0)? 1 : 0

[0533] y = Abs(diffC) > 0? Floor(Log2(Abs(diffC))) + 1 : 0

[0534] a = (diffC * (divSigTable[normDiff] | 8) + 2 y-1 ) >> y

[0535] k = ((3 + x - y) < 1)? 1 : 3 + x - y

[0536] a = ((3 + x - y) < 1)? Sign(a) * 15 : a

[0537] b = minC - ((a * minY) >> k)

[0538] where divSigTable[] is specified as follows:

[0539] divSigTable[] = { 0, 7, 6, 5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 1, 1, 0}

[0540] - Otherwise (diff is equal to 0), the following applies:

[0541] k = 0

[0542] a = 0

[0543] b = minC

[0544] 8. The prediction samples predSamples[x][y] (with x = 0..nTbW-1, y = 0..nTbH-1) are derived as follows:

[0545] predSamples[x][y] = Clip 1(((pDsY[x][y] * a) >> k) + b)

[0546] It should be noted that in the above process, the filtered luma sample pSelDsY[idx] can be based on luma samples pY[-1][-1], pY[-1][-2], and pY[-2][-1]. When the above and left samples of the current block are available, e.g., the samples were previously processed in the same slice and availTL is equal to TRUE, the luma samples pY[-1][-1], pY[-1][-2], and pY[-2][-1] are set equal to the reconstructed luma samples at the corresponding positions above and to the left of the current block prior to the deblocking filter process. According to the techniques herein, when the above and left samples of the current block are not available, i.e., availTL is equal to FALSE, the luma samples pY[-1][-1], pY[-1][-2], and pY[-2][-1] are set equal to the reconstructed luma samples at the nearby positions above or to the left of the current block prior to the deblocking filter process. In this way, according to the techniques herein, an intra prediction mode process for cross component linear model (CCLM) prediction can determine a prediction predSamples[x][y] based on a linear model that is derived based on the filtered luma sample pSelDsY[idx]. The determination of the luma sample pSelDsY[idx] can be based on the chroma format.

[0547] In this way, video encoder 200 represents an example of a device configured to determine a number of available neighboring chroma samples above and to the right of a current block and perform a cross component linear model intra prediction process based on the number of available neighboring chroma samples above and to the right of the current block.

[0548] Referring again to FIG. 7 , inter prediction processing unit 514 can be configured to perform inter prediction encoding for a current video block. Inter prediction processing unit 514 can be configured to receive a source video block and calculate a motion vector for a PU of the video block. The motion vector can indicate a displacement of a prediction unit of the video block within a current video frame relative to a prediction block within a reference frame. Inter prediction encoding can use one or more reference pictures. Further, motion prediction can be single-directional prediction (using one motion vector) or bi-directional prediction (using two motion vectors). Inter prediction processing unit 514 can be configured to select a prediction block by calculating pixel differences determined by, for example, sum of absolute differences (SAD), sum of squared differences (SSD), or other difference metrics. As described above, a motion vector can be determined and specified according to motion vector prediction. As described above, inter prediction processing unit 514 can be configured to perform motion vector prediction. Inter prediction processing unit 514 can be configured to generate a prediction block using the motion prediction data. For example, inter prediction processing unit 514 can locate a prediction video block within a frame buffer FIG. 7The inter prediction processing unit 514 can be configured to perform motion estimation on the reconstructed video data to determine a motion vector for a video block. The inter prediction processing unit 514 can output the motion prediction data for the motion vector to the entropy encoding unit 518. The motion prediction data can include a motion vector difference between the motion vector and a motion vector predictor. The motion vector predictor can be determined based on a motion vector of a collocated block in a previously reconstructed picture. The motion vector predictor can be refined to form the motion vector based on the motion prediction data.

[0549] As shown, the filter unit 516 receives the reconstructed video blocks and the encoding parameters and outputs modified reconstructed video data. The filter unit 516 can be configured to perform deblocking, sample adaptive offset (SAO) filtering, adaptive loop filtering (ALF), and the like. SAO filtering is a non-linear amplitude mapping that can be used to improve reconstruction by adding an offset to the reconstructed video data. It should be noted that, as shown, the intra prediction processing unit 512 and the inter prediction processing unit 514 can receive the modified reconstructed video blocks via the filter unit 516. The entropy encoding unit 518 receives the quantized transform coefficients and the prediction syntax data (i.e., the intra prediction data and the motion prediction data). The entropy encoding unit 518 can be configured to perform entropy encoding in accordance with one or more of the techniques described herein. FIG. 1 FIG. 6 As shown, the filter unit 516 receives the reconstructed video blocks and the encoding parameters and outputs modified reconstructed video data. The filter unit 516 can be configured to perform deblocking, sample adaptive offset (SAO) filtering, adaptive loop filtering (ALF), and the like. SAO filtering is a non-linear amplitude mapping that can be used to improve reconstruction by adding an offset to the reconstructed video data. It should be noted that, as shown, the intra prediction processing unit 512 and the inter prediction processing unit 514 can receive the modified reconstructed video blocks via the filter unit 516. The entropy encoding unit 518 receives the quantized transform coefficients and the prediction syntax data (i.e., the intra prediction data and the motion prediction data). The entropy encoding unit 518 can be configured to perform entropy encoding in accordance with one or more of the techniques described herein.

[0550] Referring again to FIG. 1 , the data packager 107 can receive the encoded video data and generate a compliant bitstream, e.g., a sequence of NAL units, in accordance with a defined data structure. A device that receives the compliant bitstream can render video data therefrom. Moreover, as described above, sub-bitstream extraction can refer to a process by which a device that receives a compliant ITU-T H.265 bitstream forms a new compliant ITU-T H.265 bitstream by discarding and / or modifying data in the received bitstream. It should be noted that the term compliant bitstream can be used in place of the term compliant bitstream. It should be noted that the data packager 107 need not necessarily be located in the same physical device as the video encoder 106. For example, the functions described as being performed by the video encoder 106 and the data packager 107 can be distributed among devices as shown. FIG. 1 The interface 108 can include any device configured to receive data generated by the data packager 107 and to transmit and / or store the data to a communication medium. The interface 108 can include a network interface card, such as an Ethernet card, and can include an optical transceiver, a radio frequency transceiver, or any other type of device that can send and / or receive information. Further, the interface 108 can include a computer system interface that can enable a file to be stored on a storage device. For example, the interface 108 can include a peripheral component interconnect (PCI) and peripheral component interconnect express (PCIe) bus protocols, a proprietary bus protocol, a universal serial bus (USB) protocol, an I2C bus, and the like. 2 ​a chipset of Intel® Celeron®, or any other logical and physical structure that can be used to interconnect peer devices.

[0551] Referring again to FIG. 8 , the target device 120 includes an interface 122, a data unpackager 123, a video decoder 124, and a display 126. The interface 122 can include any device configured to receive data from a communication medium. The interface 122 can include a network interface card such as an Ethernet card, and can include an optical transceiver, a radio frequency transceiver, or any other type of device that can receive and / or transmit information. Further, the interface 122 can include a computer system interface that allows retrieval of compatible video bitstreams from a storage device. For example, the interface 122 can include a bus protocol that supports PCI and PCIe bus protocols, a proprietary bus protocol, a USB protocol, an I2C protocol, a SPI protocol, or any other type of bus protocol. The data unpackager 123 can be configured to receive and parse any of the example syntax structures described herein. 2 a chipset of Intel® Celeron®, or any other logical and physical structure that can be used to interconnect peer devices. The data unpackager 123 can be configured to receive and parse any of the example syntax structures described herein.

[0552] The video decoder 124 can include any device configured to receive a bitstream (e.g., sub-bitstream extraction) and / or acceptable variations thereof and reproduce video data therefrom. The display 126 can include any device configured to display video data. The display 126 can include one of various display devices such as a liquid crystal display (LCD), a plasma display, an organic light emitting diode (OLED) display, or another type of display. The display 126 can include a high definition display or an ultra-high definition display. It should be noted that although the video decoder 124 is described as outputting data to the display 126 in the example shown, the video decoder 124 can be configured to output video data to various types of devices and / or subcomponents thereof. For example, the video decoder 124 can be configured to output video data to any communication medium, as described herein. FIG. 8

[0553] FIG. 8 is a block diagram illustrating an example of a video decoder that can be configured to decode video data according to one or more techniques of this disclosure (e.g., decoding processes for the above-described reference picture list construction). In one example, the video decoder 600 can be configured to decode transform data and reconstruct residual data from transform coefficients based on the decoded transform data. The video decoder 600 can be configured to perform intra prediction decoding and inter prediction decoding, and thus can be referred to as a hybrid decoder. The video decoder 600 can be configured to parse any combination of the above-described syntax elements. The video decoder 600 can decode pictures based on or in accordance with the above-described processes.

[0554] In FIG. 8 ​In the illustrated example, video decoder 600 includes an entropy decoding unit 602, an inverse quantization unit 604, an inverse transform processing unit 606, an intra prediction processing unit 608, an inter prediction processing unit 610, a summer 612, a post filter unit 614, and a reference buffer 616. Video decoder 600 can be configured to decode video data in a manner consistent with the video encoding system. It should be noted that although the illustrated example video decoder 600 has distinct functional blocks, such an illustration is merely intended to facilitate description of the functionality, and the video decoder 600 and / or its sub-components can be implemented by any combination of hardware, firmware, and / or software that is consistent with the described functionality.

[0555] As FIG. 8 shown, entropy decoding unit 602 receives an entropy encoded bitstream. Entropy decoding unit 602 can be configured to decode syntax elements and quantized coefficients from the bitstream according to a process reciprocal to the entropy encoding process. Entropy decoding unit 602 can be configured to perform entropy decoding according to any of the entropy encoding techniques described above. Entropy decoding unit 602 can determine values for syntax elements in the encoded bitstream in a manner consistent with a video coding standard. As FIG. 6 shown, entropy decoding unit 602 can determine quantized coefficient values and prediction data from the bitstream.

[0556] Inverse quantization unit 604 receives quantized transform coefficients (i.e., bit- scale values) and quantization parameter data from entropy decoding unit 602. The quantization parameter data can include any and all combinations of delta QP values and / or quantization group size values, etc. Video decoder 600 and / or inverse quantization unit 604 can be configured to determine QP values for inverse quantization based on values signaled by the video encoder and / or by video properties and / or encoding parameters. That is, inverse quantization unit 604 can operate in a manner reciprocal to quantization unit 506 described above. For example, inverse quantization unit 604 can be configured to infer predetermined values), allowed quantization group sizes, derive quantization parameters, etc. according to the techniques described above. Inverse quantization unit 604 can be configured to apply inverse quantization. Inverse transform processing unit 606 can be configured to perform inverse transforms to generate reconstructed residual data. The techniques performed by inverse quantization unit 604 and inverse transform processing unit 606 can be similar to the techniques performed by inverse quantization / transform processing unit 508 described above. Inverse transform processing unit 606 can be configured to apply an inverse DCT, an inverse DST, an inverse integer transform, a non-separable secondary transform (NSST), or a probabilistically similar inverse transform process to the transform coefficients in order to produce a residual block in the pixel domain. Moreover, as described above, whether a particular transform is performed (or the type of particular transform) can depend on the intra prediction mode. As ​As shown, the reconstructed residual data can be provided to summer 612. Summer 612 can add the reconstructed residual data to the predicted video block and generate reconstructed video data. The predicted video block can be determined according to the prediction video techniques (i.e., intra prediction and inter prediction).

[0557] Intra prediction processing unit 608 can be configured to receive intra prediction syntax elements and retrieve the predicted video block from reference buffer 614. Reference buffer 614 can include a memory device configured to store one or more frames of video data. The intra prediction syntax elements can identify an intra prediction mode, such as the intra prediction modes described above. In one example, intra prediction processing unit 608 can reconstruct the video block using one or more of the intra prediction coding techniques described herein. For example, intra prediction processing unit 608 can generate a prediction according to the intra prediction mode process of the cross-component linear model described above. Inter prediction processing unit 610 can receive inter prediction syntax elements and generate motion vectors to identify a predicted block in one or more reference frames stored in reference buffer 616. Inter prediction processing unit 610 can generate a motion compensated block, possibly performing interpolation based on an interpolation filter. Identifiers for the interpolation filter used for motion estimation with sub-pixel accuracy can be included in the syntax elements. Inter prediction processing unit 608 can use the interpolation filter to calculate interpolated values for sub-integer pixels of the reference block. Post filter unit 614 can be configured to perform filtering on the reconstructed video data according to one or more of the techniques described above. For example, post filter unit 614 can be configured to perform deblocking, ALF, and / or sample adaptive offset (SAO) filtering based on the techniques described above and, for example, based on parameters specified in the bitstream. Further, it should be noted that, in some examples, post filter unit 614 can be configured to perform specialized arbitrary filtering (e.g., visual enhancements such as mosquito noise removal). As ​ As shown, video decoder 600 can output the reconstructed video block. In this way, video decoder 600 represents an example of a device configured to determine a number of available neighboring chroma samples above and to the left of a current block and perform a cross-component linear model intra prediction process based on the number of available neighboring chroma samples above and to the left of the current block.

[0558] In one or more examples, the functions described can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions can be stored on or transmitted over as one or more instructions or code on a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media can include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another, e.g., according to a communication protocol. In this manner, computer- readable media generally can correspond to (1) tangible computer-readable storage media which is non-transitory or (2) a communication medium such as a signal or carrier wave. Data storage media can be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and / or data structures for implementation of the techniques described in this disclosure. A computer program product can include a computer-readable medium.

[0559] By way of example, and not limitation, such computer-readable storage media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other storage medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any

[0560] Instructions can be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Accordingly, the term "processor," as used herein can refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described herein. In addition, in some aspects, the functionality described herein can be provided within dedicated hardware and / or software modules configured for encoding and decoding, or incorporated in a combined codec. Also, the techniques could be fully implemented in one or more circuits or logic elements.

[0561] The techniques of this disclosure can be implemented in a variety of devices or apparatuses including a wireless mobile device, an integrated circuit (IC), or a set of ICs (e.g., a chip set). Various components, modules, or units described in the disclosure can be implemented as hardware, software, or a combination thereof. Various components and functions described herein can be implemented as machine executable instructions (i.e., software) stored in memory or other computer readable media, hardware, or a combination thereof. In some examples, the machine executable instructions can be executed by one or more processors to implement the functions / acts described herein.

[0562] Furthermore, each functional block or various features of the base station device and the terminal device used in each of the above-described embodiments can be implemented as an integrated circuit or a plurality of integrated circuits, which are designed to perform the functions of the corresponding unit, in addition to software for performing the functions. That is, the functional blocks or features can be implemented (1) by hardware only, or (2) by software only, or (3) by hardware-and-software in combination.

[0563] Various examples have been described. These and other examples are within the scope of the following claims.

[0564] <SUMMARY>

[0565] In one example, a method of generating a prediction for a current block in video coding is provided, the method comprising: determining a number of available neighboring chroma samples above and to the right of the current block; and performing a cross-component linear model intra prediction process based on the number of available neighboring chroma samples above and to the right of the current block.

[0566] In one example, the method is provided, wherein a number of available neighboring chroma samples on top and right up of the current block is based on a chroma format.

[0567] In one example, an apparatus is provided that includes one or more processors configured to perform any and all combinations of the steps.

[0568] In one example, the apparatus is provided, wherein the apparatus includes a video encoder.

[0569] In one example, the apparatus is provided, wherein the apparatus includes a video decoder.

[0570] In one example, a system is provided that includes: an apparatus that includes a video encoder; and the apparatus includes a video decoder.

[0571] In one example, an apparatus is provided that includes: means for performing any and all combinations of the steps.

[0572] In one example, a non-transitory computer-readable storage medium is provided that includes instructions stored thereon that, when executed, cause one or more processors of an apparatus to perform any and all combinations of the steps.

[0573] In one example, a method of generating prediction samples for a current transform block in video coding is provided, the method comprising: setting a neighboring left luma sample value defined as x equal to -1, -2, or -3, corresponding to the current transform block, equal to a reconstructed luma sample; setting a neighboring top-left luma sample value defined as x equal to -2 and y equal to -1, corresponding to the current transform block, equal to the neighboring left luma sample value in case the neighboring top-left luma sample value is not available; deriving down-sampled neighboring luma sample values of the current transform block by using the neighboring left luma sample value and based on a chroma format; and generating the prediction samples by using the down-sampled neighboring luma sample values.

[0574] In one example, the method is provided, wherein in case the chroma format indicates a 4:2:2 format, the down-sampled neighboring luma sample values are derived by using three neighboring luma sample values.

[0575] In one example, the method is provided, wherein in case the chroma format indicates a 4:2:0 format, the down-sampled neighboring luma sample values are derived by using at least five neighboring luma sample values.

[0576] In one example, the method is provided, wherein in the case that the neighboring top-left luma sample value is not available, the neighboring top-left luma sample value with position (-2,-1) is set to the neighboring left luma sample value with position (-2,0).

[0577] In one example, a device is provided that includes one or more processors configured to: set a neighboring left luma sample value defined as x equal to -1, -2, or -3, corresponding to a current transform block, equal to a reconstructed luma sample; set a neighboring top-left luma sample value defined as x equal to -2 and y equal to -1, corresponding to the current transform block, equal to the neighboring left luma sample value in a case that the neighboring top-left luma sample value is not available; derive down-sampled neighboring left luma sample values of the current transform block by using the neighboring left luma sample value and based on a chroma format; and generate a prediction sample by using the down-sampled neighboring luma sample values.

[0578] <cross-reference>

[0579] This non-provisional patent application claims priority under 35 U.S.C. § 119 to provisional application 63 / 010,323, filed April 15, 2020, and provisional application 63 / 010,955, filed April 16, 2020, the entire contents of both applications are hereby incorporated by reference.

Claims

1. A method for generating prediction samples for a current transform block in video coding, the method comprising: The setting is defined as x equal to -1, -2, or -3, and pY[x][y] for the current transform block is equal to the reconstructed luminance sample, where, When the available variable is equal to the unavailable variable, the adjacent top-left luminance sample with position (-2, -1) is set to be equal to the reconstructed luminance sample with position (-2, 0); With the chroma format specified as 4:2:2, the selected downsampled adjacent left luminance sample pSelDsY[idx] is exported as (( pY[-3][y] + 2*pY[-2][y] + pY[-1][y]) + 2) / 4; and Predictive samples are generated by using the selected downsampled adjacent left luminance samples pSelDsY[idx].

2. An apparatus for performing intra-frame prediction, the apparatus comprising one or more processors, the one or more processors being configured to: The setting is defined as x equal to -1, -2, or -3, and pY[x][y] for the current transform block is equal to the reconstructed luminance sample, where, When the available variable is equal to the unavailable variable, the adjacent top-left luminance sample with position (-2, -1) is set to be equal to the reconstructed luminance sample with position (-2, 0); With the chroma format specified as 4:2:2, the selected downsampled adjacent left luminance sample pSelDsY[idx] is exported as (( pY[-3][y] + 2*pY[-2][y] + pY[-1][y]) + 2) / 4; and Predictive samples are generated by using the selected downsampled adjacent left luminance samples pSelDsY[idx].

Images