WO2021018084A1 - Interdépendance de la taille de transformée et de la taille d'une unité d'arbre de codage dans un codage vidéo - Google Patents

Interdépendance de la taille de transformée et de la taille d'une unité d'arbre de codage dans un codage vidéo Download PDF

Info

Publication number
WO2021018084A1
WO2021018084A1 PCT/CN2020/104790 CN2020104790W WO2021018084A1 WO 2021018084 A1 WO2021018084 A1 WO 2021018084A1 CN 2020104790 W CN2020104790 W CN 2020104790W WO 2021018084 A1 WO2021018084 A1 WO 2021018084A1
Authority
WO
WIPO (PCT)
Prior art keywords
video
size
block
luma
coding
Prior art date
Application number
PCT/CN2020/104790
Other languages
English (en)
Inventor
Zhipin DENG
Li Zhang
Kai Zhang
Hongbin Liu
Original Assignee
Beijing Bytedance Network Technology Co., Ltd.
Bytedance Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Bytedance Network Technology Co., Ltd., Bytedance Inc. filed Critical Beijing Bytedance Network Technology Co., Ltd.
Priority to CN202080053871.3A priority Critical patent/CN114175650A/zh
Publication of WO2021018084A1 publication Critical patent/WO2021018084A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/119—Adaptive subdivision aspects, e.g. subdivision of a picture into rectangular or non-rectangular coding blocks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/132—Sampling, masking or truncation of coding units, e.g. adaptive resampling, frame skipping, frame interpolation or high-frequency transform coefficient masking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/176—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/90—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using coding techniques not provided for in groups H04N19/10-H04N19/85, e.g. fractals
    • H04N19/96—Tree coding, e.g. quad-tree coding

Definitions

  • This document is related to video and image coding and decoding technologies.
  • Digital video accounts for the largest bandwidth use on the internet and other digital communication networks. As the number of connected user devices capable of receiving and displaying video increases, it is expected that the bandwidth demand for digital video usage will continue to grow.
  • the disclosed techniques may be used by video or image decoder or encoder to performing coding or decoding of video in which a configurable coding tree unit size is used.
  • a method of video processing includes performing a conversion between a video comprising one or more video regions comprising one or more video blocks and a bitstream representation of the video, wherein the conversion conforms to a rule that allows use of different sizes for the one or more video blocks in different video regions of the one or more video regions for performing the conversion.
  • a method of video processing includes determining, based on a size of a video block of a video region of a video exceeding a threshold, that the video block is split using a quadtree-based splitting until a size condition is met and an indication of the quadtree-based splitting is excluded from a bitstream representation of the video, and performing, based on the determining, a conversion between the video and the bitstream representation.
  • a method of video processing includes determining, based on dimensions of a video block of a video region of a video exceeding a threshold, whether an indication for ternary-tree (TT) splitting of the video block is signaled in a bitstream representation of the video, and performing, based on the determining, a conversion between the video and the bitstream representation.
  • TT ternary-tree
  • a method of video processing includes determining, based on dimensions of a video block of a video region of a video exceeding a threshold, whether an indication for binary-tree (BT) splitting of the video block is signaled in a bitstream representation of the video, and performing, based on the determining, a conversion between the video and the bitstream representation.
  • BT binary-tree
  • a method of video processing includes performing a conversion between a video comprising a video region comprising a video block and a bitstream representation of the video, wherein the conversion comprises an affine model parameters calculation, and wherein the affine model parameters calculation is based on dimensions of the video block.
  • a method of video processing includes performing a conversion between a video comprising a video region comprising a video block and a bitstream representation of the video, wherein the conversion comprises an application of an intra block copy (IBC) tool, and wherein a size of an IBC buffer is based on maximum configurable and/or allowable dimensions of the video block.
  • IBC intra block copy
  • a method of video processing includes performing a conversion between a video comprising one or more video regions comprising one or more video blocks and a bitstream representation of the video, wherein the conversion is performed according to a rule that specifies a relationship between an indication of a size of a video block of the one or more video blocks and an indication of a maximum size of a transform block (TB) used for the video block.
  • TB transform block
  • the above-described method may be implemented by a video encoder apparatus that comprises a processor.
  • these methods may be embodied in the form of processor-executable instructions and stored on a computer-readable program medium.
  • FIG. 1 is a block diagram of an example of a hardware platform used for implementing techniques described in the present document.
  • FIG. 2 is a block diagram of an example video processing system in which disclosed techniques may be implemented.
  • FIG. 3 is a flowchart for an example method of video processing.
  • FIG. 4 is a flowchart for another example method of video processing.
  • FIG. 5 is a flowchart for yet another example method of video processing.
  • FIG. 6 is a flowchart for yet another example method of video processing.
  • FIG. 7 is a flowchart for yet another example method of video processing.
  • FIG. 8 is a flowchart for yet another example method of video processing.
  • FIG. 9 is a flowchart for yet another example method of video processing.
  • the present document provides various techniques that can be used by a decoder of image or video bitstreams to improve the quality of decompressed or decoded digital video or images.
  • video is used herein to include both a sequence of pictures (traditionally called video) and individual images.
  • a video encoder may also implement these techniques during the process of encoding in order to reconstruct decoded frames used for further encoding.
  • Section headings are used in the present document for ease of understanding and do not limit the embodiments and techniques to the corresponding sections. As such, embodiments from one section can be combined with embodiments from other sections.
  • This document is related to video coding technologies. Specifically, it is directed to configurable coding tree units (CTUs) in video coding and decoding. It may be applied to the existing video coding standard like HEVC, or the standard (Versatile Video Coding) to be finalized. It may be also applicable to future video coding standards or video codec.
  • CTUs configurable coding tree units
  • Video coding standards have evolved primarily through the development of the well-known ITU-T and ISO/IEC standards.
  • the ITU-T produced H. 261 and H. 263, ISO/IEC produced MPEG-1 and MPEG-4 Visual, and the two organizations jointly produced the H. 262/MPEG-2 Video and H. 264/MPEG-4 Advanced Video Coding (AVC) and H. 265/HEVC standards.
  • AVC H. 264/MPEG-4 Advanced Video Coding
  • H. 265/HEVC High Efficiency Video Coding
  • the video coding standards are based on the hybrid video coding structure wherein temporal prediction plus transform coding are utilized.
  • Joint Video Exploration Team JVET was founded by VCEG and MPEG jointly in 2015.
  • JEM Joint Exploration Model
  • VTM-5.0 software allows 4 different CTU sizes: 16x16, 32x32, 64x64 and 128x128.
  • the minimum CTU size was redefined to 32x32 due to the adoption of JVET-O0526.
  • the CTU size in VVC working draft 6 is encoded in the SPS header in a UE-encoded syntax element called log2_ctu_size_minus_5.
  • VVC draft 6 With the definition of Virtual pipeline data units (VPDUs) and the adoption of JVET-O0526.
  • VPDUs Virtual pipeline data units
  • log2_ctu_size_minus5 plus 5 specifies the luma coding tree block size of each CTU. It is a requirement of bitstream conformance that the value of log2_ctu_size_minus5 be less than or equal to 2.
  • log2_min_luma_coding_block_size_minus2 plus 2 specifies the minimum luma coding block size.
  • MinCbLog2SizeY log2_min_luma_coding_block_size_minus2+2 (7-17)
  • MinCbSizeY 1 ⁇ MinCbLog2SizeY (7-18)
  • IbcBufWidthY 128*128/CtbSizeY (7-19)
  • IbcBufWidthC IbcBufWidthY/SubWidthC
  • CtbWidthC and CtbHeightC which specify the width and height, respectively, of the array for each chroma CTB, are derived as follows:
  • chroma_format_idc is equal to 0 (monochrome) or separate_colour_plane_flag is equal to 1, CtbWidthC and CtbHeightC are both equal to 0.
  • CtbWidthC and CtbHeightC are derived as follows:
  • the up-right diagonal and raster scan order array initialization process as specified in clause 6.5.2 is invoked with 1 ⁇ log2BlockWidth and 1 ⁇ log2BlockHeight as inputs, and the output is assigned to DiagScanOrder [log2BlockWidth] [log2BlockHeight] and RasterScanOrder [log2BlockWidth] [log2BlockHeight] .
  • slice_log2_diff_max_bt_min_qt_luma specifies the difference between the base 2 logarithm of the maximum size (width or height) in luma samples of a luma coding block that can be split using a binary split and the minimum size (width or height) in luma samples of a luma leaf block resulting from quadtree splitting of a CTU in the current slice.
  • the value of slice_log2_diff_max_bt_min_qt_luma shall be in the range of 0 to CtbLog2SizeY-MinQtLog2SizeY, inclusive.
  • the value of slice_log2_diff_max_bt_min_qt_luma is inferred as follows:
  • slice_log2_diff_max_bt_min_qt_luma is inferred to be equal to sps_log2_diff_max_bt_min_qt_intra_slice_luma
  • slice_log2_diff_max_bt_min_qt_luma is inferred to be equal to sps_log2_diff_max_bt_min_qt_inter_slice.
  • slice_log2_diff_max_tt_min_qt_luma specifies the difference between the base 2 logarithm of the maximum size (width or height) in luma samples of a luma coding block that can be split using a ternary split and the minimum size (width or height) in luma samples of a luma leaf block resulting from quadtree splitting of a CTU in in the current slice.
  • the value of slice_log2_diff_max_tt_min_qt_luma shall be in the range of 0 to CtbLog2SizeY-MinQtLog2SizeY, inclusive.
  • the value of slice_log2_diff_max_tt_min_qt_luma is inferred as follows:
  • slice_log2_diff_max_tt_min_qt_luma is inferred to be equal to sps_log2_diff_max_tt_min_qt_intra_slice_luma
  • slice_log2_diff_max_tt_min_qt_luma is inferred to be equal to sps_log2_diff_max_tt_min_qt_inter_slice.
  • slice_log2_diff_min_qt_min_cb_chroma specifies the difference between the base 2 logarithm of the minimum size in luma samples of a chroma leaf block resulting from quadtree splitting of a chroma CTU with treeType equal to DUAL_TREE_CHROMA and the base 2 logarithm of the minimum coding block size in luma samples for chroma CUs with treeType equal to DUAL_TREE_CHROMA in the current slice.
  • the value of slice_log2_diff_min_qt_min_cb_chroma shall be in the range of 0 to CtbLog2SizeY-MinCbLog2SizeY, inclusive.
  • slice_log2_diff_min_qt_min_cb_chroma When not present, the value of slice_log2_diff_min_qt_min_cb_chroma is inferred to be equal to sps_log2_diff_min_qt_min_cb_intra_slice_chroma.
  • slice_max_mtt_hierarchy_depth_chroma specifies the maximum hierarchy depth for coding units resulting from multi-type tree splitting of a quadtree leaf with treeType equal to DUAL_TREE_CHROMA in the current slice.
  • the value of slice_max_mtt_hierarchy_depth_chroma shall be in the range of 0 to CtbLog2SizeY-MinCbLog2SizeY, inclusive.
  • the values of slice_max_mtt_hierarchy_depth_chroma is inferred to be equal to sps_max_mtt_hierarchy_depth_intra_slices_chroma.
  • slice_log2_diff_max_bt_min_qt_chroma specifies the difference between the base 2 logarithm of the maximum size (width or height) in luma samples of a chroma coding block that can be split using a binary split and the minimum size (width or height) in luma samples of a chroma leaf block resulting from quadtree splitting of a chroma CTU with treeType equal to DUAL_TREE_CHROMA in the current slice.
  • the value of slice_log2_diff_max_bt_min_qt_chroma shall be in the range of 0 to CtbLog2SizeY-MinQtLog2SizeC, inclusive.
  • slice_log2_diff_max_bt_min_qt_chroma When not present, the value of slice_log2_diff_max_bt_min_qt_chroma is inferred to be equal to sps_log2_diff_max_bt_min_qt_intra_slice_chroma
  • slice_log2_diff_max_tt_min_qt_chroma specifies the difference between the base 2 logarithm of the maximum size (width or height) in luma samples of a chroma coding block that can be split using a ternary split and the minimum size (width or height) in luma samples of a chroma leaf block resulting from quadtree splitting of a chroma CTU with treeType equal to DUAL_TREE_CHROMA in the current slice.
  • the value of slice_log2_diff_max_tt_min_qt_chroma shall be in the range of 0 to CtbLog2SizeY-MinQtLog2SizeC, inclusive.
  • slice_log2_diff_max_tt_min_qt_chroma is inferred to be equal to sps_log2_diff_max_tt_min_qt_intra_slice_chroma
  • MinQtLog2SizeY, MinQtLog2SizeC, MinQtSizeY, MinQtSizeC, MaxBtSizeY, MaxBtSizeC, MinBtSizeY, MaxTtSizeY, MaxTtSizeC, MinTtSizeY, MaxMttDepthY and MaxMttDepthC are derived as follows:
  • MinQtLog2SizeY MinCbLog2SizeY+slice_log2_diff_min_qt_min_cb_luma (7-86)
  • MinQtLog2SizeC MinCbLog2SizeY+slice_log2_diff_min_qt_min_cb_chroma (7-87)
  • MinQtSizeY 1 ⁇ MinQtLog2SizeY
  • MinQtSizeC 1 ⁇ MinQtLog2SizeC
  • MaxBtSizeY 1 ⁇ (MinQtLog2SizeY+slice_log2_diff_max_bt_min_qt_luma) (7-90)
  • MaxBtSizeC 1 ⁇ (MinQtLog2SizeC+slice_log2_diff_max_bt_min_qt_chroma) (7-91)
  • MinBtSizeY 1 ⁇ MinCbLog2SizeY
  • MaxTtSizeY 1 ⁇ (MinQtLog2SizeY+slice_log2_diff_max_tt_min_qt_luma) (7-93)
  • MaxTtSizeC 1 ⁇ (MinQtLog2SizeC+slice_log2_diff_max_tt_min_qt_chroma) (7-94)
  • MinTtSizeY 1 ⁇ MinCbLog2SizeY
  • MaxMttDepthY slice_max_mtt_hierarchy_depth_luma (7-96)
  • MaxMttDepthC slice_max_mtt_hierarchy_depth_chroma (7-97)
  • Max chroma transform size is derived from the chroma sampling ratio relative to the max luma transform size.
  • sps_max_luma_transform_size_64_flag 1 specifies that the maximum transform size in luma samples is equal to 64.
  • sps_max_luma_transform_size_64_flag 0 specifies that the maximum transform size in luma samples is equal to 32.
  • MinTbLog2SizeY MinTbLog2SizeY
  • MinTbSizeY MinTbSizeY
  • MaxTbSizeY MaxTbSizeY
  • MaxTbLog2SizeY sps_max_luma_transform_size_64_flag? 6: 5 (7-28)
  • MinTbSizeY 1 ⁇ MinTbLog2SizeY (7-29)
  • MaxTbSizeY 1 ⁇ MaxTbLog2SizeY
  • sps_sbt_max_size_64_flag 0 specifies that the maximum CU width and height for allowing subblock transform is 32 luma samples.
  • sps_sbt_max_size_64_flag 1 specifies that the maximum CU width and height for allowing subblock transform is 64 luma samples.
  • MaxSbtSize Min (MaxTbSizeY, sps_sbt_max_size_64_flag ? 64 : 32) (7-31)
  • the maximum transform size and CTU size are defined independently.
  • CTU size could be 32, whereas transform size could be 64. It is desirable that the maximum transform size should be equal or smaller than the CTU size.
  • the block partition process depends on the maximum transform block size other than the VPDU size. Therefore, if the maximum transform block size is 32x32, in addition to prohibit 128x128 TT split and 64x128 vertical BT split, and 128x64 horizontal BT split to obey the VPDU rule, it further prohibits TT split for 64x64 block, prohibits vertical BT split for 32x64/16x64/8x64 coding block, and also prohibits horizontal BT split for 64x8/64x16/64x32 coding block, which may not efficient for coding efficiency.
  • the CTU size is signaled at SPS level.
  • the adoption of reference picture resampling (a.k.a. adaptive resolution change) allows that the pictures could be coded with difference resolutions in one bistream, the CTU size may be different across multiple layers.
  • the video unit size/dimension may be either the height or width of a video unit (e.g., width or height of a picture/sub-picture/slice/brick/tile/CTU/CU/CB/TU/TB) . If a video unit size is denoted by MxN, then M denotes the width and N denotes the height of the video unit.
  • a coding block may be a luma coding block, and/or a chroma coding block.
  • the size/dimension in luma samples for a coding block may be used in this invention to represent the size/dimension measured in luma samples.
  • a 128x128 coding block (or a coding block size 128x128 in luma samples) may indicate a 128x128 luma coding block, and/or a 64x64 chroma coding block for 4: 2: 0 color format.
  • 4: 2: 2 color format it may refer to a 128x128 luma coding block and/or a 64x128 chroma coding block.
  • 4: 4 color format it may refer to a 128x128 luma coding block and/or a 128x128 chroma coding block.
  • CTU dimensions such as width and/or height
  • video units such as Layers/Pictures/Subpictures/Slices/Tiles/Bricks.
  • one or multiple sets of CTU dimensions may be explicitly signaled at a video unit level such as VPS/DPS/SPS/PPS/APS/Picture/Subpicture/Slice/Slice header/Tile/Brick level.
  • the CTU dimensions may be different across difference layers.
  • the CTU dimensions of an inter-layer picture may be implicitly derived according to the downsample/upsample scaling factor.
  • the CTU dimensions in the inter-layer coded picture may be derived to (M ⁇ S) ⁇ (N ⁇ T) , or (M/S) ⁇ (N/T) .
  • CTU dimensions may be explicitly signalled for multiple layers at video unit level, e.g., for inter-layer resampling pictures/subpictures, the CTU dimensions may be signaled at VPS/DPS/SPS/PPS/APS/picture/subpicture/Slice/Slice header/Tile/Brick level which is different from the base-layer CTU size.
  • TT or BT split may be dependent on VPDU dimensions (such as width and/or height) .
  • VPDU is with dimension VSize in luma samples
  • the coding tree block is with dimension CtbSizeY in luma samples.
  • VSize min (M, CtbSizeY) .
  • M is an integer value such as 64.
  • whether TT or BT split is allowed or not may be independent of the maximum transform size.
  • TT split may be disabled when a coding block width or height in luma samples is greater than min (VSize, maxTtSize) .
  • TT split may be disabled for 128x128/128x64/64x128 coding block.
  • TT split may be allowed for 64x64 coding block.
  • vertical BT split may be disabled when a coding block width in luma samples is less than or equal to VSize, but its height in luma samples is greater than VSize.
  • vertical BT split may be disabled for 64x128 coding block.
  • vertical BT split may be allowed for 32x64/16x64/8x64 coding block.
  • vertical BT split may be disabled when a coding block exceeds the Picture/Subpicture width in luma samples, but its height in luma samples is greater than VSize.
  • horizontal BT split may be allowed when a coding block exceeds the Picture/Subpicture width in luma samples.
  • horizontal BT split may be disabled when a coding block width in luma samples is greater than VSize, but its height in luma samples is less than or equal to VSize.
  • vertical BT split may be disabled for 128x64 coding block.
  • horizontal BT split may be allowed for 64x8/64x16/64x32 coding block.
  • horizontal BT split may be disabled when a coding block exceeds the Picture/Subpicture height in luma samples, but its width in luma samples is greater than VSize.
  • vertical BT split may be allowed when a coding block exceeds the Picture/Subpicture height in luma samples.
  • the TT or BT split flag may be not signaled and implicitly derived to be zero.
  • the TT and/or BT split flag may be explicitly signaled in the bitstream.
  • the TT or BT split flag may be signaled but ignored by the decoder.
  • the TT or BT split flag may be signaled but it must be zero in a conformance bitstream.
  • the CTU dimensions (such as width and/or height) may be larger than 128.
  • the signaled CTU dimensions may be 256 or even larger (e.g., log2_ctu_size_minus5 may be equal to 3 or larger) .
  • the derived CTU dimensions may be 256 or even larger.
  • the derived CTU dimensions for resampling pictures/subpictures may be larger than 128.
  • the QT split flag may be inferred to be true and the QT split may be recursively applied till the dimension of split coding block reach a specified value (e.g., a specified value may be set to the maximum transform block size, or 128, or 64, or 32) .
  • the recursive QT split may be implicitly conducted without signaling, until the split coding block size reach the maximum transform block size.
  • the QT split flag may be not signalled for a coding block larger than maximum transform block size, and the QT split may be forced to be used for the coding block until the split coding block size reach the maximum transform block size.
  • TT split flag may be conditionally signalled for CU/PU dimensions (width and/or height) larger than 128.
  • both horizontal and vertical TT split flags may be signalled for a 256x256 CU.
  • vertical TT split but not horizontal TT split may be signalled for a 256x128/256x64 CU/PU.
  • horizontal TT split but not vertical TT split may be signalled for a 128x256/64x256 CU/PU.
  • TT split flag when TT split flag is prohibited for CU dimensions larger than 128, then it may not be signalled and implicitly derived as zero.
  • horizontal TT split may be prohibited for 256x128/256x64 CU/PU.
  • vertical TT split may be prohibited for 128x256/64x256 CU/PU.
  • BT split flag may be conditionally signalled for CU/PU dimensions (width and/or height) larger than 128.
  • both horizontal and vertical BT split flags may be signalled for 256x256/256x128/128x256 CU/PU.
  • horizontal BT split flag may be signaled for 64x256 CU/PU.
  • vertical BT split flag may be signaled for 256x64 CU/PU.
  • BT split flag when BT split flag is prohibited for CU dimension larger than 128, then it may be not signalled and implicitly derived as zero.
  • vertical BT split may be prohibited for Kx256 CU/PU (such as K is equal to or smaller than 64 in luma samples) , and the vertical BT split flag may be not signaled and derived as zero.
  • vertical BT split may be prohibited for 64x256 CU/PU.
  • vertical BT split may be prohibited to avoid 32x256 CU/PU at picture/subpicture boundaries.
  • horizontal BT split may be prohibited for 256xK (such as K is equal to or smaller than 64 in luma samples) coding block, and the horizontal BT split flag may be not signaled and derived as zero.
  • horizontal BT split may be prohibited for 256x64 coding block.
  • horizontal BT split may be prohibited to avoid 256x32 coding block at picture/subpicture boundaries.
  • affine model parameters calculation may be dependent on the CTU dimensions.
  • the derivation of scaled motion vectors, and/or control point motion vectors in affine prediction may be dependent on the CTU dimensions.
  • the intra block copy (IBC) buffer may depend on the maximum configurable/allowable CTU dimensions.
  • the above-mentioned specified coding tool may be palette, and/or intra block copy (IBC) , and/or intra skip mode, and/or triangle prediction mode, and/or CIIP mode, and/or regular merge mode, and/or decoder side motion derivation, and/or bi-directional optical flow, and/or prediction refinement based optical flow, and/or affine prediction, and/or sub-block based TMVP, and etc.
  • IBC intra block copy
  • IBC intra skip mode
  • triangle prediction mode and/or CIIP mode
  • regular merge mode and/or decoder side motion derivation
  • bi-directional optical flow and/or prediction refinement based optical flow
  • affine prediction and/or sub-block based TMVP, and etc.
  • screen content coding tool such as palette and/or intra block copy (IBC) mode may be applied to large CU/PU.
  • IBC intra block copy
  • it may explicitly use syntax constraint for disabling the specified coding tool (s) for a large CU/PU.
  • Palette/IBC flag may explicitly signal for a CU/PU which is not a large CU/PU.
  • bitstream constraint for disabling specified coding tool (s) for a large CU/PU.
  • the maximum TU size may be dependent on CTU dimensions (width and/or height) , or CTU dimensions may be dependent on the maximum TU size
  • a bitstream constraint may be used that the maximum TU size shall be smaller or equal to the CTU dimensions.
  • the signaling of maximum TU size may depend on the CTU dimensions.
  • the signaled maximum TU size must be smaller than N.
  • the indication of whether the maximum luma transform size is 64 or 32 may not be signaled and the maximum luma transform size may be derived as 32 implicitly.
  • Newly added parts are enclosed in bolded double parentheses, e.g., ⁇ ⁇ a ⁇ ⁇ denotes that “a” has been added, whereas the deleted parts from VVC working draft are enclosed in bolded double brackets, e.g., [ [b] ] denotes that “b” has been deleted.
  • the modifications are based on the latest VVC working draft (JVET-O2001-v11)
  • the embodiment below is for the invented method that making the maximum TU size dependent on the CTU size.
  • sps_max_luma_transform_size_64_flag 1 specifies that the maximum transform size in luma samples is equal to 64.
  • sps_max_luma_transform_size_64_flag 0 specifies that the maximum transform size in luma samples is equal to 32.
  • MinTbLog2SizeY MinTbLog2SizeY
  • MinTbSizeY MinTbSizeY
  • MaxTbSizeY MaxTbSizeY
  • MaxTbLog2SizeY sps_max_luma_transform_size_64_flag? 6: 5 (7-28)
  • MinTbSizeY 1 ⁇ MinTbLog2SizeY (7-29)
  • MaxTbSizeY ⁇ ⁇ min (CtbSizeY, 1 ⁇ MaxTbLog2SizeY) ⁇ ⁇ (7-30)
  • the embodiment below is for the invented method that making the TT and BT split process dependent on the VPDU size.
  • variable allowBtSplit is derived as follows:
  • allowBtSplit is set equal to FALSE
  • allowBtSplit is set equal to FALSE
  • allowBtSplit is set equal to FALSE
  • allowBtSplit is set equal to FALSE
  • variable allowTtSplit is derived as follows:
  • allowTtSplit is set equal to FALSE:
  • treeType is equal to DUAL_TREE_CHROMA and (cbWidth/SubWidthC) * (cbHeight/SubHeightC) is less than or equal to 32
  • treeType is equal to DUAL_TREE_CHROMA and modeType is equal to INTRA
  • allowTtSplit is set equal to TRUE.
  • log2_ctu_size_minus5plus 5 specifies the luma coding tree block size of each CTU. It is a requirement of bitstream conformance that the value of log2_ctu_size_minus5 be less than or equal to [ [2] ] ⁇ ⁇ 3 (could be larger per specified) ⁇ ⁇ .
  • ⁇ ⁇ CtbLog2SizeY is used to indicate the CTU size in luma sampales of current video unit.
  • the CtbLog2SizeY is calculated by above equation. Otherwise, CtbLog2SizeY may depend on the actual CTU size which may be explicit signalled or implicit derived for the current video unit. (an example) ⁇ ⁇
  • variable availableFlagLX is derived as follows:
  • availableFlagLX is set equal to TRUE:
  • refIdxLXCorner [0] is equal to refIdxLXCorner [2]
  • availableFlagLX is set equal to FALSE.
  • the second control point motion vector cpMvLXCorner [1] is derived as follows:
  • FIG. 1 is a block diagram of a video processing apparatus 1300.
  • the apparatus 1300 may be used to implement one or more of the methods described herein.
  • the apparatus 1300 may be embodied in a smartphone, tablet, computer, Internet of Things (IoT) receiver, and so on.
  • the apparatus 1300 may include one or more processors 1302, one or more memories 1304 and video processing hardware 1306.
  • the processor (s) 1302 may be configured to implement one or more methods described in the present document.
  • the memory (memories) 1304 may be used for storing data and code used for implementing the methods and techniques described herein.
  • the video processing hardware 1306 may be used to implement, in hardware circuitry, some techniques described in the present document. In some embodiments, the hardware 1306 may be at least partially included in the processor 1302, e.g., a graphics co-processor.
  • the video coding methods may be implemented using an apparatus that is implemented on a hardware platform as described with respect to FIG. 1.
  • Some embodiments of the disclosed technology include making a decision or determination to enable a video processing tool or mode.
  • the encoder when the video processing tool or mode is enabled, the encoder will use or implement the tool or mode in the processing of a block of video, but may not necessarily modify the resulting bitstream based on the usage of the tool or mode. That is, a conversion from the block of video to the bitstream representation of the video will use the video processing tool or mode when it is enabled based on the decision or determination.
  • the decoder when the video processing tool or mode is enabled, the decoder will process the bitstream with the knowledge that the bitstream has been modified based on the video processing tool or mode. That is, a conversion from the bitstream representation of the video to the block of video will be performed using the video processing tool or mode that was enabled based on the decision or determination.
  • Some embodiments of the disclosed technology include making a decision or determination to disable a video processing tool or mode.
  • the encoder will not use the tool or mode in the conversion of the block of video to the bitstream representation of the video.
  • the decoder will process the bitstream with the knowledge that the bitstream has not been modified using the video processing tool or mode that was enabled based on the decision or determination.
  • FIG. 2 is a block diagram showing an example video processing system 200 in which various techniques disclosed herein may be implemented.
  • the system 200 may include input 202 for receiving video content.
  • the video content may be received in a raw or uncompressed format, e.g., 8 or 10 bit multi-component pixel values, or may be in a compressed or encoded format.
  • the input 202 may represent a network interface, a peripheral bus interface, or a storage interface. Examples of network interface include wired interfaces such as Ethernet, passive optical network (PON) , etc. and wireless interfaces such as Wi-Fi or cellular interfaces.
  • PON passive optical network
  • the system 200 may include a coding component 204 that may implement the various coding or encoding methods described in the present document.
  • the coding component 204 may reduce the average bitrate of video from the input 202 to the output of the coding component 204 to produce a coded representation of the video.
  • the coding techniques are therefore sometimes called video compression or video transcoding techniques.
  • the output of the coding component 204 may be either stored, or transmitted via a communication connected, as represented by the component 206.
  • the stored or communicated bitstream (or coded) representation of the video received at the input 202 may be used by the component 208 for generating pixel values or displayable video that is sent to a display interface 210.
  • the process of generating user-viewable video from the bitstream representation is sometimes called video decompression.
  • certain video processing operations are referred to as “coding” operations or tools, it will be appreciated that the coding tools or operations are used at an encoder and corresponding decoding tools or operations that reverse the results of the coding will be performed
  • peripheral bus interface or a display interface may include universal serial bus (USB) or high definition multimedia interface (HDMI) or Displayport, and so on.
  • storage interfaces include SATA (serial advanced technology attachment) , PCI, IDE interface, and the like.
  • FIG. 3 is a flowchart for a method 300 of video processing.
  • the method 300 includes, at operation 310, performing a conversion between a video comprising one or more video regions comprising one or more video blocks and a bitstream representation of the video, the conversion conforming to a rule that allows use of different sizes for the one or more video blocks in different video regions of the one or more video regions for performing the conversion.
  • FIG. 4 is a flowchart for a method 400 of video processing.
  • the method 400 includes, at operation 410, determining, based on a size of a video block of a video region of a video exceeding a threshold, that the video block is split using a quadtree-based splitting until a size condition is met and an indication of the quadtree-based splitting is excluded from a bitstream representation of the video.
  • the method 400 includes, at operation 420, performing, based on the determining, a conversion between the video and the bitstream representation.
  • FIG. 5 is a flowchart for a method 500 of video processing.
  • the method 500 includes, at operation 510, determining, based on dimensions of a video block of a video region of a video exceeding a threshold, whether an indication for ternary-tree (TT) splitting of the video block is signaled in a bitstream representation of the video.
  • TT ternary-tree
  • the method 500 includes, at operation 520, performing, based on the determining, a conversion between the video and the bitstream representation.
  • FIG. 6 is a flowchart for a method 600 of video processing.
  • the method 600 includes, at operation 610, determining, based on dimensions of a video block of a video region of a video exceeding a threshold, whether an indication for binary-tree (BT) splitting of the video block is signaled in a bitstream representation of the video.
  • BT binary-tree
  • the method 600 includes, at operation 620, performing, based on the determining, a conversion between the video and the bitstream representation.
  • FIG. 7 is a flowchart for a method 700 of video processing.
  • the method 700 includes, at operation 710, performing a conversion between a video comprising a video region comprising a video block and a bitstream representation of the video, the conversion comprising an affine model parameters calculation, and the affine model parameters calculation being based on dimensions of the video block.
  • FIG. 8 is a flowchart for a method 800 of video processing.
  • the method 800 includes, at operation 810, performing a conversion between a video comprising a video region comprising a video block and a bitstream representation of the video, the conversion comprising an application of an intra block copy (IBC) tool, and a size of an IBC buffer being based on maximum configurable and/or allowable dimensions of the video block.
  • IBC intra block copy
  • FIG. 9 is a flowchart for a method 900 of video processing.
  • the method 900 includes, at operation 910, performing a conversion between a video comprising one or more video regions comprising one or more video blocks and a bitstream representation of the video, the conversion being performed according to a rule that specifies a relationship between an indication of a size of a video block of the one or more video blocks and an indication of a maximum size of a transform block (TB) used for the video block.
  • TB transform block
  • a method of video processing comprising performing a conversion between a video comprising one or more video regions comprising one or more video blocks and a bitstream representation of the video, wherein the conversion conforms to a rule that allows use of different sizes for the one or more video blocks in different video regions of the one or more video regions for performing the conversion.
  • A5 The method of solution A2, wherein the syntax element is included in a video parameter set (VPS) , a decoding parameter set (DPS) , an adaptation parameter set (APS) , a picture header, a subpicture header, a slice header, a tile header, or a brick header.
  • VPS video parameter set
  • DPS decoding parameter set
  • APS adaptation parameter set
  • A6 The method of solution A1, wherein the one or more video regions correspond to video layers, and wherein the one or more video blocks correspond to coding tree units (CTUs) representing logical partitions used for coding the video into the bitstream representation.
  • CTUs coding tree units
  • A12 The method of solution A8, wherein a size of a video block of the one or more video blocks of an inter-layer picture or an intra-layer picture is M ⁇ N, wherein the inter-layer picture or the intra-layer picture is resampled by a first scale factor (S) in a width dimension and by a second scale factor (T) , wherein the dimensions of video blocks for inter-layer referencing or intra-layer referencing are (M ⁇ S) ⁇ (N ⁇ T) or (M/S) ⁇ (N/T) , and wherein M, N, S, and T are positive integers.
  • S first scale factor
  • T second scale factor
  • A14 The method of solution A13, wherein the different sizes are signaled in a sequence parameter set (SPS) or a picture parameter set (PPS) .
  • SPS sequence parameter set
  • PPS picture parameter set
  • a method of video processing comprising determining, based on a size of a video block of a video region of a video exceeding a threshold, that the video block is split using a quadtree-based splitting until a size condition is met and an indication of the quadtree-based splitting is excluded from a bitstream representation of the video; and performing, based on the determining, a conversion between the video and the bitstream representation.
  • a method of video processing comprising determining, based on dimensions of a video block of a video region of a video exceeding a threshold, whether an indication for ternary-tree (TT) splitting of the video block is signaled in a bitstream representation of the video; and performing, based on the determining, a conversion between the video and the bitstream representation.
  • TT ternary-tree
  • A27 The method of any of solutions A22 to A26, wherein the video block is a coding unit (CU) or a prediction unit (PU) .
  • CU coding unit
  • PU prediction unit
  • a method of video processing comprising determining, based on dimensions of a video block of a video region of a video exceeding a threshold, whether an indication for binary-tree (BT) splitting of the video block is signaled in a bitstream representation of the video; and performing, based on the determining, a conversion between the video and the bitstream representation.
  • BT binary-tree
  • A33 The method of any of solutions A28 to A32, wherein the video block is a coding unit (CU) or a prediction unit (PU) .
  • CU coding unit
  • PU prediction unit
  • a method of video processing comprising performing a conversion between a video comprising a video region comprising a video block and a bitstream representation of the video, wherein the conversion comprises an affine model parameters calculation, and wherein the affine model parameters calculation is based on dimensions of the video block.
  • A36 The method of solution A34 or A35, wherein the video block corresponds to a coding tree unit (CTU) representing a logical partition used for coding the video into the bitstream representation.
  • CTU coding tree unit
  • a method of video processing comprising performing a conversion between a video comprising a video region comprising a video block and a bitstream representation of the video, wherein the conversion comprises an application of an intra block copy (IBC) tool, and wherein a size of an IBC buffer is based on maximum configurable and/or allowable dimensions of the video block.
  • IBC intra block copy
  • A38 The method of solution A37, wherein a width of the IBC buffer in luma samples is equal to N ⁇ N divided by a width or a height of the video block, wherein N ⁇ N is the maximum configurable dimensions of the video block in luma samples, and wherein N is an integer.
  • A40 The method of any of solutions A37 to A39, wherein the video block corresponds to a coding tree unit (CTU) representing a logical partition used for coding the video into the bitstream representation.
  • CTU coding tree unit
  • An apparatus in a video system comprising a processor and a non-transitory memory with instructions thereon, wherein the instructions upon execution by the processor, cause the processor to implement the method in any one of solutions A1 to A42.
  • a computer program product stored on a non-transitory computer readable media, the computer program product including program code for carrying out the method in any one of solutions A1 to A42.
  • a method of video processing comprising performing a conversion between a video comprising one or more video regions comprising one or more video blocks and a bitstream representation of the video, wherein the conversion is performed according to a rule that specifies a relationship between an indication of a size of a video block of the one or more video blocks and an indication of a maximum size of a transform block (TB) used for the video block.
  • TB transform block
  • bitstream representation excludes an indication of the maximum size of the luma transform block when at least one of the dimensions of the video block is smaller than N, wherein the maximum size of the luma transform block is implicitly derived as 32, and wherein N is a positive integer.
  • An apparatus in a video system comprising a processor and a non-transitory memory with instructions thereon, wherein the instructions upon execution by the processor, cause the processor to implement the method in any one of solutions B1 to B19.
  • a computer program product stored on a non-transitory computer readable media including program code for carrying out the method in any one of solutions B1 to B19.
  • the disclosed and other solutions, examples, embodiments, modules and the functional operations described in this document can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this document and their structural equivalents, or in combinations of one or more of them.
  • the disclosed and other embodiments can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer readable medium for execution by, or to control the operation of, data processing apparatus.
  • the computer readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more them.
  • data processing apparatus encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers.
  • the apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.
  • a propagated signal is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus.
  • a computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.
  • a computer program does not necessarily correspond to a file in a file system.
  • a program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document) , in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code) .
  • a computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.
  • the processes and logic flows described in this document can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output.
  • the processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit) .
  • processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer.
  • a processor will receive instructions and data from a read only memory or a random-access memory or both.
  • the essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data.
  • a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks.
  • mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks.
  • a computer need not have such devices.
  • Computer readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks.
  • semiconductor memory devices e.g., EPROM, EEPROM, and flash memory devices
  • magnetic disks e.g., internal hard disks or removable disks
  • magneto optical disks e.g., CD ROM and DVD-ROM disks.
  • the processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

Abstract

L'invention concerne des procédés, des systèmes et des dispositifs de codage ou de décodage de vidéo qui comprennent des unités d'arbre de codage configurables (CTU). Un procédé de traitement vidéo donné à titre d'exemple consiste à réaliser une conversion entre une vidéo comprenant une ou plusieurs régions vidéo comprenant un ou plusieurs blocs vidéo et une représentation de flux binaire de la vidéo, la conversion étant conforme à une règle qui permet l'utilisation de différentes tailles pour le ou les blocs vidéo dans différentes régions vidéo de la ou des régions vidéo pour effectuer la conversion. Un autre procédé de traitement vidéo donné à titre d'exemple consiste à déterminer, sur la base des dimensions d'un bloc vidéo d'une région vidéo d'une vidéo dépassant un seuil, si une indication de division d'arbre binaire (BT) du bloc vidéo est signalée dans une représentation de flux binaire de la vidéo et réaliser, sur la base de la détermination, une conversion entre la vidéo et la représentation de flux binaire.
PCT/CN2020/104790 2019-07-26 2020-07-27 Interdépendance de la taille de transformée et de la taille d'une unité d'arbre de codage dans un codage vidéo WO2021018084A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202080053871.3A CN114175650A (zh) 2019-07-26 2020-07-27 视频编解码中的变换尺寸和编解码树单元尺寸的相互依赖

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CNPCT/CN2019/097926 2019-07-26
CN2019097926 2019-07-26

Publications (1)

Publication Number Publication Date
WO2021018084A1 true WO2021018084A1 (fr) 2021-02-04

Family

ID=74229220

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/CN2020/104784 WO2021018081A1 (fr) 2019-07-26 2020-07-27 Taille d'unité d'arbre de codage configurable dans une technique de codage vidéo
PCT/CN2020/104790 WO2021018084A1 (fr) 2019-07-26 2020-07-27 Interdépendance de la taille de transformée et de la taille d'une unité d'arbre de codage dans un codage vidéo

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/104784 WO2021018081A1 (fr) 2019-07-26 2020-07-27 Taille d'unité d'arbre de codage configurable dans une technique de codage vidéo

Country Status (2)

Country Link
CN (2) CN114175649A (fr)
WO (2) WO2021018081A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023034748A1 (fr) * 2021-08-31 2023-03-09 Bytedance Inc. Procédé, appareil et support de traitement vidéo

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103299637A (zh) * 2011-01-12 2013-09-11 三菱电机株式会社 运动图像编码装置、运动图像译码装置、运动图像编码方法以及运动图像译码方法
CN103503457A (zh) * 2011-06-24 2014-01-08 三菱电机株式会社 运动图像编码装置、运动图像解码装置、运动图像编码方法以及运动图像解码方法
JP2014045434A (ja) * 2012-08-28 2014-03-13 Nippon Hoso Kyokai <Nhk> 画像符号化装置、画像復号装置及びそれらのプログラム
CN104604225A (zh) * 2012-09-10 2015-05-06 松下电器（美国）知识产权公司 图像编码方法、图像解码方法、图像编码装置、图像解码装置及图像编码解码装置
US20170064335A1 (en) * 2015-08-31 2017-03-02 Samsung Electronics Co., Ltd. Method and apparatus for image transformation, and method and apparatus for image inverse-transformation based on scanning sequence

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9877034B2 (en) * 2014-04-14 2018-01-23 Avago Technologies General Ip (Singapore) Pte. Ltd. Pipelined video decoder system
US20170150176A1 (en) * 2015-11-25 2017-05-25 Qualcomm Incorporated Linear-model prediction with non-square prediction units in video coding
US10212444B2 (en) * 2016-01-15 2019-02-19 Qualcomm Incorporated Multi-type-tree framework for video coding
WO2017157249A1 (fr) * 2016-03-16 2017-09-21 Mediatek Inc. Procédé et appareil de traitement de données vidéo avec une longueur de bloc restreinte dans un codage vidéo
BR112019013978A2 (pt) * 2017-01-12 2020-03-03 Sony Corporation Dispositivo e método de processamento de imagem.
CN117201820A (zh) * 2017-05-26 2023-12-08 Sk电信有限公司 对视频数据进行编码或解码的方法和发送比特流的方法
KR102501105B1 (ko) * 2017-09-20 2023-02-17 한국전자통신연구원 영상 부호화/복호화 방법, 장치 및 비트스트림을 저장한 기록 매체

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103299637A (zh) * 2011-01-12 2013-09-11 三菱电机株式会社 运动图像编码装置、运动图像译码装置、运动图像编码方法以及运动图像译码方法
CN103503457A (zh) * 2011-06-24 2014-01-08 三菱电机株式会社 运动图像编码装置、运动图像解码装置、运动图像编码方法以及运动图像解码方法
JP2014045434A (ja) * 2012-08-28 2014-03-13 Nippon Hoso Kyokai <Nhk> 画像符号化装置、画像復号装置及びそれらのプログラム
CN104604225A (zh) * 2012-09-10 2015-05-06 松下电器（美国）知识产权公司 图像编码方法、图像解码方法、图像编码装置、图像解码装置及图像编码解码装置
US20170064335A1 (en) * 2015-08-31 2017-03-02 Samsung Electronics Co., Ltd. Method and apparatus for image transformation, and method and apparatus for image inverse-transformation based on scanning sequence

Also Published As

Publication number Publication date
CN114175649A (zh) 2022-03-11
WO2021018081A1 (fr) 2021-02-04
CN114175650A (zh) 2022-03-11

Similar Documents

Publication Publication Date Title
US20220103817A1 (en) Handling video unit boundaries and virtual boundaries
US11553179B2 (en) Sample determination for adaptive loop filtering
US20230156189A1 (en) Sample padding in adaptive loop filtering
US11490082B2 (en) Handling video unit boundaries and virtual boundaries based on color format
AU2020321002B2 (en) Determination of picture partition mode based on block size
CN114631313A (zh) 使用亮度差值的跨分量自适应环路滤波器
CN114556924A (zh) 视频处理中色度残差的联合编解码与滤波
US20240048735A1 (en) Cross-component adaptive loop filter
US11671594B2 (en) Selective application of sample padding in adaptive loop filtering
US20220217340A1 (en) Two-part signaling of adaptive loop filters in video coding
US11683488B2 (en) Adaptive loop filtering between different video units
US11539946B2 (en) Sample padding for cross-component adaptive loop filtering
US20230156186A1 (en) Boundary location for adaptive loop filtering
WO2021018084A1 (fr) Interdépendance de la taille de transformée et de la taille d&#39;une unité d&#39;arbre de codage dans un codage vidéo
CN115362682A (zh) 视频比特流中编解码信息的信令通知
CN114902684A (zh) 控制视频编解码中的跨边界滤波

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20848101

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20848101

Country of ref document: EP

Kind code of ref document: A1

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 25/08/2022)