WO2020003264A2 - Filtrage d'une unité zéro - Google Patents

Filtrage d'une unité zéro Download PDF

Info

Publication number
WO2020003264A2
WO2020003264A2 PCT/IB2019/055553 IB2019055553W WO2020003264A2 WO 2020003264 A2 WO2020003264 A2 WO 2020003264A2 IB 2019055553 W IB2019055553 W IB 2019055553W WO 2020003264 A2 WO2020003264 A2 WO 2020003264A2
Authority
WO
WIPO (PCT)
Prior art keywords
block
video data
video
unit
alf
Prior art date
Application number
PCT/IB2019/055553
Other languages
English (en)
Other versions
WO2020003264A3 (fr
Inventor
Kai Zhang
Li Zhang
Hongbin Liu
Hsiao Chiang Chuang
Yue Wang
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.
Publication of WO2020003264A2 publication Critical patent/WO2020003264A2/fr
Publication of WO2020003264A3 publication Critical patent/WO2020003264A3/fr

Links

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/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/117—Filters, e.g. for pre-processing or post-processing
    • 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/127—Prioritisation of hardware or computational resources
    • 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/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/157—Assigned coding mode, i.e. the coding mode being predefined or preselected to be further used for selection of another element or parameter
    • 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/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/167—Position within a video image, e.g. region of interest [ROI]
    • 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/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/186—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 a colour or a chrominance component
    • 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/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/61—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
    • 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/80—Details of filtering operations specially adapted for video compression, e.g. for pixel interpolation
    • H04N19/82—Details of filtering operations specially adapted for video compression, e.g. for pixel interpolation involving filtering within a prediction loop
    • 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/85—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression
    • H04N19/86—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression involving reduction of coding artifacts, e.g. of blockiness
    • 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
    • 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/12—Selection from among a plurality of transforms or standards, e.g. selection between discrete cosine transform [DCT] and sub-band transform or selection between H.263 and H.264

Definitions

  • This patent document is directed generally to image and video coding technologies.
  • CU specialized coding unit
  • CTU coding tree unit
  • the presently disclosed technology discloses provides the zero-unit that enhances, in an example, the processing of sub blocks that are located at the borders of a block of video data (e.g., in a picture, slice, tile and the like).
  • the described methods may be applied to both the existing video coding standards (e.g., High Efficiency Video Coding (HEVC)) and future video coding standards or video codecs.
  • HEVC High Efficiency Video Coding
  • a method of video processing includes making a determination, for a block of video data having at least a height or a width that is a non-power-of-two number of pixels, to encode the block of video data into a bitstream representation without a transform operation and performing an in-loop filtering on a result of the encoding, wherein a type of the in-loop filter is selected based on the determination.
  • another method of video processing includes making a determination, for a block of video data having at least a height or a width that is a non-power-of-two number of pixels, to decode the block of video data from a bitstream representation without a transform operation and performing an in-loop filtering on a result of the decoding, wherein a type of the in-loop filter is selected based on the determination.
  • another method of video processing includes selecting, in response to a determination that a block of video data is to be coded as one of a coding unit (CU) or a zero-unit (ZU) block, a type of in-loop filter, determining, based on the selecting, an Adaptive Loop Filter (ALF) mode for the block of video data, encoding the block of video data into a bitstream representation and applying the ALF to a result of the encoding using the ALF mode.
  • ALF Adaptive Loop Filter
  • another method of video processing includes determining, from a bitstream representation, that a block of video data is to be decoded as one of a coding unit (CU) or a zero unit (ZU) block, selecting, in response to the determining, an adaptive loop filter (ALF) mode for the block of video data, decoding the block of video data from the bitstream representation and performing adaptive loop filtering based on the ALF mode.
  • ALF adaptive loop filter
  • another method of video processing includes receiving a bitstream corresponding to a block of video data, determining that block of video data, which is a Coding Tree Unit (CTU), is to be coded as one of a coding unit (CU) or a zero-unit (ZU) block, selecting, in response to determining that the block of video data is to be coded as one of the CU or the ZU block, a type of in-loop filter, receiving signaling to control Adaptive Loop Filter (ALF) in the block based on the selection and in-loop filtering the block using the selected type of in-loop filter.
  • CTU Coding Tree Unit
  • CU coding unit
  • ZU zero-unit
  • another method of video processing includes determining that a block of video data is located near a picture boundary and is one of a coding unit (CU), a predictive unit (PU) or a transform unit (TU), controlling, in response to determining that the block of video data is located near the picture boundary and is one of the CU, the PU, or the TU, an in-loop filter and signaling controlling information for the in-loop filter based on the determination.
  • CU coding unit
  • PU predictive unit
  • TU transform unit
  • another method of video processing includes determining that a block of video data is located near a picture boundary and is one of a coding unit (CU), a predictive unit (PU) or a transform unit (TU), receiving control information for an in-loop filter based on the determination and controlling the in-loop filter based on the determination and the received controlling information.
  • CU coding unit
  • PU predictive unit
  • TU transform unit
  • the above -described method is embodied in the form of processor-executable code and stored in a computer-readable program medium.
  • the device may include a processor that is
  • a video decoder apparatus may implement a method as described herein.
  • FIG. 1 shows an example block diagram of a typical High Efficiency Video Coding (HEVC) video encoder and decoder.
  • HEVC High Efficiency Video Coding
  • FIG. 2 shows examples of macroblock (MB) partitions in H.264/AVC.
  • FIG. 3 shows examples of splitting coding blocks (CBs) into prediction blocks (PBs).
  • FIGS. 4 A and 4B show an example of the subdivision of a coding tree block (CTB) into CBs and transform blocks (TBs), and the corresponding quadtree, respectively.
  • CB coding tree block
  • TBs transform blocks
  • FIG. 5 shows an example of a partition structure of one frame.
  • FIGS. 6A and 6B show the subdivisions and signaling methods, respectively, of a CTB highlighted in the exemplary frame in FIG. 5.
  • FIG. 7A-7B are flowcharts for video processing method examples.
  • FIG. 8A-8B are flowcharts for video processing method examples.
  • FIG. 9A-9C are flowcharts for video processing method examples.
  • FIG. 10A-10I shows an example subdivision of a CB based on a QTBT.
  • FIG. 1 1 shows an example of tree-type signaling.
  • FIGS. 12A-12C show examples of CTBs crossing picture borders.
  • FIG. 13 shows an example of a zero-unit at a picture border.
  • FIG. 14 shows a flowchart of an example method for video encoding in accordance with the presently disclosed technology.
  • FIG. 15 shows a flowchart of another example method for video decoding in accordance with the presently disclosed technology.
  • FIG. 16 is a block diagram illustrating an example of the architecture for a computer system or other control device that can be utilized to implement various portions of the presently disclosed technology.
  • FIG. 17 shows a block diagram of an example embodiment of a mobile device that can be utilized to implement various portions of the presently disclosed technology.
  • FIGS. 18A and 18B show examples of partitioning a ZU block into sub-blocks for Adaptive Loop Control (ALF) on/off control.
  • ALF Adaptive Loop Control
  • Video codecs typically include an electronic circuit or software that compresses or decompresses digital video, and are continually being improved to provide higher coding efficiency.
  • a video codec converts uncompressed video to a compressed format or vice versa.
  • the compressed format usually conforms to a standard video compression specification, e.g., the High Efficiency Video Coding (HEVC) standard (also known as H.265 or MPEG-H Part 2), the Versatile Video Coding standard to be finalized, or other current and/or future video coding standards.
  • HEVC High Efficiency Video Coding
  • MPEG-H Part 2 the Versatile Video Coding standard to be finalized, or other current and/or future video coding standards.
  • Embodiments of the disclosed technology may be applied to existing video coding standards (e.g., HEVC, H.265) and future standards to improve compression performance.
  • Section headings are used in the present document to improve readability of the description and do not in any way limit the discussion or the embodiments (and/or implementations) to the respective sections only.
  • Section headings are used in the present document to facilitate ease of understanding and do not limit the embodiments disclosed in a section to only that section.
  • certain embodiments are described with reference to Versatile Video Coding or other specific video codecs, the disclosed techniques are applicable to other video coding technologies also.
  • video processing encompasses video coding or compression, video decoding or decompression and video transcoding in which video pixels are represented from one compressed format into another compressed format or at a different compressed bitrate.
  • FIG. 1 shows an example block diagram of a typical HEVC video encoder and decoder.
  • An encoding algorithm producing an HEVC compliant bitstream would typically proceed as follows. Each picture is split into block-shaped regions, with the exact block partitioning being conveyed to the decoder. The first picture of a video sequence (and the first picture at each clean random access point into a video sequence) is coded using only intra picture prediction (that uses some prediction of data spatially from region-to-region within the same picture, but has no dependence on other pictures). For all remaining pictures of a sequence or between random access points, inter-picture temporally predictive coding modes are typically used for most blocks.
  • the encoding process for inter-picture prediction consists of choosing motion data comprising the selected reference picture and motion vector (MV) to be applied for predicting the samples of each block.
  • the encoder and decoder generate identical inter-picture prediction signals by applying motion compensation (MC) using the MV and mode decision data, which are transmitted as side information.
  • MC motion compensation
  • the residual signal of the intra- or inter-picture prediction which is the difference between the original block and its prediction, is transformed by a linear spatial transform.
  • the transform coefficients are then scaled, quantized, entropy coded, and transmitted together with the prediction information.
  • the encoder duplicates the decoder processing loop (see gray-shaded boxes in FIG.
  • the quantized transform coefficients are constructed by inverse scaling and are then inverse transformed to duplicate the decoded approximation of the residual signal.
  • the residual is then added to the prediction, and the result of that addition may then be fed into one or two loop filters to smooth out artifacts induced by block-wise processing and quantization.
  • the final picture representation (that is a duplicate of the output of the decoder) is stored in a decoded picture buffer to be used for the prediction of subsequent pictures.
  • the order of encoding or decoding processing of pictures often differs from the order in which they arrive from the source;
  • decoding order i.e., bitstream order
  • output order i.e., display order
  • Video material to be encoded by HEVC is generally expected to be input as progressive scan imagery (either due to the source video originating in that format or resulting from deinterlacing prior to encoding).
  • No explicit coding features are present in the HEVC design to support the use of interlaced scanning, as interlaced scanning is no longer used for displays and is becoming substantially less common for distribution.
  • a metadata syntax has been provided in HEVC to allow an encoder to indicate that interlace-scanned video has been sent by coding each field (i.e., the even or odd numbered lines of each video frame) of interlaced video as a separate picture or that it has been sent by coding each interlaced frame as an HEVC coded picture. This provides an efficient method of coding interlaced video without burdening decoders with a need to support a special decoding process for it.
  • the core of the coding layer in previous standards was the macroblock, containing a 16x16 block of luma samples and, in the usual case of 4:2:0 color sampling, two corresponding 8x8 blocks of chroma samples.
  • An intra-coded block uses spatial prediction to exploit spatial correlation among pixels. Two partitions are defined: 16x16 and 4x4.
  • An inter-coded block uses temporal prediction, instead of spatial prediction, by estimating motion among pictures.
  • Motion can be estimated independently for either 16x16 macroblock or any of its sub -macroblock partitions: 16x8, 8x16, 8x8, 8x4, 4x8, 4x4, as shown in FIG. 2. Only one motion vector (MV) per sub-macroblock partition is allowed.
  • a coding tree unit (CTU) is split into coding units (CUs) by using a quadtree structure denoted as coding tree to adapt to various local characteristics.
  • the decision whether to code a picture area using inter-picture (temporal) or intra-picture (spatial) prediction is made at the CU level.
  • Each CU can be further split into one, two or four prediction units (PUs) according to the PU splitting type. Inside one PU, the same prediction process is applied, and the relevant information is transmitted to the decoder on a PU basis.
  • a CU After obtaining the residual block by applying the prediction process based on the PU splitting type, a CU can be partitioned into transform units (TUs) according to another quadtree structure similar to the coding tree for the CU.
  • transform units transform units
  • One of key feature of the HEVC structure is that it has the multiple partition conceptions including CU, PU, and TU.
  • Certain features involved in hybrid video coding using HEVC include:
  • HEVC coding tree unit
  • the CTU consists of a luma CTB and the corresponding chroma CTBs and syntax elements.
  • HEVC then supports a partitioning of the CTBs into smaller blocks using a tree structure and quadtree-like signaling.
  • Coding units (CUs) and coding blocks (CBs) The quadtree syntax of the CTU specifies the size and positions of its luma and chroma CBs. The root of the quadtree is associated with the CTU. Hence, the size of the luma CTB is the largest supported size for a luma CB.
  • the splitting of a CTU into luma and chroma CBs is signaled jointly.
  • a CTB may contain only one CU or may be split to form multiple CUs, and each CU has an associated partitioning into prediction units (PUs) and a tree of transform units (TUs).
  • PUs prediction units
  • TUs tree of transform units
  • Prediction units and prediction blocks The decision whether to code a picture area using inter picture or intra picture prediction is made at the CU level.
  • a PU partitioning structure has its root at the CU level.
  • the luma and chroma CBs can then be further split in size and predicted from luma and chroma prediction blocks (PBs).
  • HEVC supports variable PB sizes from 64x64 down to 4x4 samples.
  • FIG. 3 shows examples of allowed PBs for an MxM CU.
  • the prediction residual is coded using block transforms.
  • a TU tree structure has its root at the CU level.
  • the luma CB residual may be identical to the luma transform block (TB) or may be further split into smaller luma TBs. The same applies to the chroma TBs.
  • Integer basis functions similar to those of a discrete cosine transform (DCT) are defined for the square TB sizes 4x4, 8x8, f6xf 6, and 32x32.
  • DCT discrete cosine transform
  • an integer transform derived from a form of discrete sine transform (DST) is alternatively specified.
  • a CB can be recursively partitioned into transform blocks (TBs). The partitioning is signaled by a residual quadtree. Only square CB and TB partitioning is specified, where a block can be recursively split into quadrants, as illustrated in FIG. 4A-4B. For a given luma CB of size MxM, a flag signals whether it is split into four blocks of size
  • each quadrant is assigned a flag that indicates whether it is split into four quadrants.
  • the leaf node blocks resulting from the residual quadtree are the transform blocks that are further processed by transform coding.
  • the encoder indicates the maximum and minimum luma TB sizes that it will use. Splitting is implicit when the CB size is larger than the maximum TB size. Not splitting is implicit when splitting would result in a luma TB size smaller than the indicated minimum.
  • the chroma TB size is half the luma TB size in each dimension, except when the luma TB size is 4x4, in which case a single 4x4 chroma TB is used for the region covered by four 4x4 luma TBs.
  • the decoded samples of the nearest-neighboring TBs are used as reference data for intra picture prediction.
  • the HEVC design allows a TB to span across multiple PBs for inter-picture predicted CUs to maximize the potential coding efficiency benefits of the quadtree-stmctured TB partitioning.
  • the borders of the picture are defined in units of the minimally allowed luma CB size.
  • some CTUs may cover regions that are partly outside the borders of the picture. This condition is detected by the decoder, and the CTU quadtree is implicitly split as necessary to reduce the CB size to the point where the entire CB will fit into the picture.
  • FIG. 5 shows an example of a partition structure of one frame, with a resolution of 416x240 pixels and dimensions 7 CTBs x 4 CTBs, wherein the size of a CTB is 64x64.
  • the CTBs that are partially outside the right and bottom border have implied splits (dashed lines, indicated as 502), and the CUs that fall outside completely are simply skipped (not coded).
  • the highlighted CTB (504), with row CTB index equal to 2 and column CTB index equal to 3, has 64x48 pixels within the current picture, and doesn’t fit a 64x64 CTB. Therefore, it is forced to be split to 32x32 without the split flag signaled. For the top-left 32x32, it is fully covered by the frame. When it chooses to be coded in smaller blocks (8x8 for the top-left 16x16, and the remaining are coded in 16x16) according to rate -distortion cost, several split flags need to be coded.
  • FIGS. 6A and 6B show the subdivisions and signaling methods, respectively, of the highlighted CTB (504) in FIG. 5.
  • log2_min_luma_coding_block_size_minus3 plus 3 specifies the minimum luma coding block size
  • log2_diff_max_min_luma_coding_block_size specifies the difference between the maximum and minimum luma coding block size.
  • PicWidthlnMinCbsY PicWidthlnCtbsY, PicHeightlnMinCbsY, PicHeightlnCtbsY,
  • PicSizelnMinCbsY PicSizelnCtbsY, PicSizelnSamplesY, PicWidthlnSamplesC and
  • PicHeightlnSamplesC are derived as follows:
  • MinCbLog2SizeY log2_min_luma_coding_bk>ck_size_minus3 + 3
  • CtbLog2SizeY MinCbLog2SizeY + log2_diff_max_min_luma_coding_block_size
  • MinCbSizeY 1 ⁇ MinCbLog2SizeY
  • PicWidthlnMinCbsY pic_width_in_luma_samples / MinCbSizeY
  • PicWidthlnCtbsY Ceil( pic_width_in_luma_samples ⁇ CtbSizeY )
  • PicHeightlnMinCbsY pic_height_in_luma_samples / MinCbSizeY
  • PicHeightlnCtbsY Ceil( pic_height_in_luma_samples ⁇ CtbSizeY )
  • PicSizelnMinCbsY PicWidthlnMinCbsY * PicHeightlnMinCbsY
  • PicSizelnCtbsY PicWidthlnCtbsY * PicHeightlnCtbsY
  • PicSizelnSamplesY pic_width_in_luma_samples * pic_height_in_luma_samples
  • PicWidthlnSamplesC pic_width_in_luma_samples / SubWidthC
  • PicHeightlnSamplesC pic_height_in_luma_samples / SubHeightC
  • 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:
  • CtbWidthC CtbSizeY / SubWidthC
  • CtbHeightC CtbSizeY / SubHeightC
  • JEM Joint Exploration Model
  • a tree structure called a Multi-Tree Type which is a generalization of the QTBT, is supported.
  • MTT Multi-Tree Type
  • FIG. 1 a Coding Tree Unit (CTU) is firstly partitioned by a quad-tree structure.
  • the quad-tree leaf nodes are further partitioned by a binary-tree structure.
  • the stmcture of the MTT constitutes of two types of tree nodes: Region Tree (RT) and Prediction Tree (PT), supporting nine types of partitions, as shown in FIG. 10A-10I.
  • a region tree can recursively split a CTU into square blocks down to a 4x4 size region tree leaf node.
  • a prediction tree can be formed from one of three tree types: Binary Tree, Ternary Tree, and Asymmetric Binary Tree.
  • a quadtree partition in branches of the prediction tree.
  • the luma tree and the chroma tree are separated in I slices.
  • RT signaling is same as QT signaling in JEM with exception of the context derivation.
  • up to 4 additional bins are required, as shown in FIG. 11.
  • the first bin indicates whether the PT is further split or not.
  • the context for this bin is calculated based on the observation that the likelihood of further split is highly correlated to the relative size of the current block to its neighbors.
  • the second bin indicates whether it is a horizontal partitioning or vertical partitioning.
  • the presence of the center sided triple tree and the asymmetric binary trees (ABTs) increase the occurrence of“tall” or “wide” blocks.
  • the third bin indicates the tree-type of the partition, i.e., whether it is a binary- tree/triple -tree, or an asymmetric binary tree.
  • the fourth bin indicates the type of the tree.
  • the four bin indicates up or down type for horizontally partitioned trees and right or left type for vertically partitioned trees. 1.5.1. Examples of restrictions at picture borders
  • K x L samples are within picture border.
  • the CU splitting mles on the picture bottom and right borders may apply to any of the coding tree configuration QTBT+TT, QTBT+ABT or QTBT+TT+ABT. They include the two following aspects: [0084] (1) If a part of a given Coding Tree node (CU) is partially located outside the picture, then the binary symmetric splitting of the CU is always allowed, along the concerned border direction (horizontal split orientation along bottom border, as shown in FIG. 12A, vertical split orientation along right border, as shown in FIG. 12B). If the bottom-right comer of the current CU is outside the frame (as depicted in FIG. 12C), then only the quad-tree splitting of the CU is allowed. In addition, if the current binary tree depth is greater than the maximum binary tree depth and current CU is on the frame border, then the binary split is enabled to ensure the frame border is reached.
  • the ternary tree split is allowed in case the first or the second border between resulting sub-CU exactly lies on the border of the picture.
  • the asymmetric binary tree splitting is allowed if a splitting line (border between two sub-CU resulting from the split) exactly matches the picture border.
  • the width or the height of a CTU or a CU may be not equal to 2 n , where N is a positive integer. These cases are difficult to handle. Specifically, may be difficult to design a transform with integer-operations excluding division, if the number of rows or columns is not in a form of 2 N .
  • the CTU or CU are forced to be split into smaller ones, until both the width and height are in the form of 2 N or by padding or using transform skip.
  • the coding gain may be further improved if treating those blocks in a more flexible way.
  • transforms are defined for CUs with the width or the height not in the form of 2 N . Such transforms are not desirable in practical video coding applications.
  • Embodiments of the presently disclosed technology overcome the drawbacks of existing implementations, thereby providing video coding with higher efficiencies.
  • the zero-unit block is proposed as a special CU/CTU, and a block is interpreted as a zero-unit if and only if its height and/or width are not of the form 2 N .
  • Example 1 the width, or height, or both of a block can be any positive integer not in the form of 2 N .
  • Such a block is defined as a zero-unit (ZU) with all residuals set to 0.
  • FIG. 13 shows an example of zero-unit at the picture border.
  • the width and height of a ZU must be an even number (in the form of 2N).
  • the width and height of a ZU must be in the form of 2 K N
  • K (e.g., K equal to 1, 2, 3, 4, etc.).
  • Example 2 In one example, it is proposed that for a zero-unit, no transform, inverse- transform, quantization and de -quantization operations are invoked.
  • a zero-unit is inferred to be coded with the skip mode; in this case, there is no need to signal the skip flag, and indications of intra or inter or other modes.
  • the merge index may also be skipped.
  • the zero block may inherit the motion information from one of its neighboring blocks with size equal to 2 N x 2 M .
  • the neighboring block is defined as the block in parallel to the border, such as for a zero unit located at the bottom border, it may inherit motion information from its above block.
  • certain mles may be applied to select one of its neighboring block, such as continuities between the zero unit and its neighboring block.
  • the motion information may be derived from motion information of neighboring blocks.
  • a zero-unit could be coded with skip or non-skip mode, and/or intra or inter modes.
  • the conventional signaling of modes information is kept unchanged, however, no cbf_flag is signaled and all cbf_flags of the zero-unit are inferred as zero. Residual information, such as quantized coefficients or transform_skip_flag, is not signaled for a zero-unit.
  • Example 3 In one example, there may be residuals in a zero-unit. But there is no transform and inverse-transform operations for a zero-unit.
  • Transform_skip_flag is not signaled and inferred to be one for a zero-unit.
  • Example 4 A split CU in the ABT partitioning can be a zero-unit.
  • Example 5 A CTU or a CU at the picture/slice/tile border can be a zero-unit.
  • ZUs are allowed for the CUs lying on the picture borders.
  • a flag is required for all border CTU/CUs to distinguish between normal CU and ZUs. I another example, this flag may be considered in conjunction with the size constraints described in Examples 6 and 7.
  • Example 6 The maximum and minimum of width/height of a zero-block can be predefined, or they may be signaled from the encoder to the decoder. In one example, they can be signaled in Video Parameter Set (VPS), Sequence Parameter Set (SPS), Picture Parameter Set (PPS), Slice header, Coding Tree Unit (CTU) or Coding Unit (CU).
  • VPS Video Parameter Set
  • SPS Sequence Parameter Set
  • PPS Picture Parameter Set
  • RPS Picture Parameter Set
  • CTU Coding Tree Unit
  • CU Coding Unit
  • a zero-unit can be further split into two (BT or ABT), three (TT, FTT) or four (QT, EQT) units.
  • a split unit split from a zero-unit can be a zero-unit, or it can be a normal CU with its width or height in the form of 2 N .
  • a zero-unit Z is with the size SxT.
  • Z can be split with BT into two units both with the size as
  • Z can be split with BT into two units both with the size as
  • Z can be split with BT into two units with the size as Sx2 N and Sx(T-2 N ), or Sx(T-2 N ) and Sx2 N .
  • Z can be split with TT into three units with the size as S/4xT,
  • Z can be split with TT into three units with the size as SxT/4,
  • Z can be split with TT into three units with the size as 2 N 1 xT, 2 N 1 xT and (S-2 N )xT, or 2 N 1 xT, (S-2 N )xT and 2 N 1 xT, or (S-2 N )xT, 2 N 1 xT and 2 N 1 xT.
  • Z can be split with TT into three units with the size as Sx2 N 1 , Sx2 N 1 and Sx(T-2 N ), or Sx2 N 1 , Sx(T-2 N ) and Sx2 N 1 , or Sx(T-2 N ),
  • Z can be split with QT into four units both with the size as
  • Z can be split with QT into four units with the size as 2 N xT/2, 2 N xT/2, (S-2 N )xT/2 and (S-2 N )xT/2, or (S-2 N )xT/2, (S-2 N )xT/2, 2 N xT/2 and 2 N XT/2.
  • Z can be split with QT into four units with the size as S/2x2 N , S/2x2 N , S/2x(T-2 N ) and S/2x(T-2 N ), or S/2x(T-2 N ), S/2x(T-2 N ), S/2x2 N and S/2x2 N .
  • Z can be split with QT into four units with the size as 2 N x2 M , 2 N x2 M , (S-2 N )x(T-2 M ) and (S-2 N )x(T-2 M ), or (S-2 N )x(T- 2 M ), (S-2 N )x(T-2 M ), 2 N x2 M and 2 N x2 M , or 2 N x(T-2 M ), 2 N x(T-2 M ), (S-2 N )x 2 M and (S-2 N )x 2 M , or (S-2 N )x 2 m , (S-2 N )X 2 m , 2 N X(T-2 m ) and 2 N x(T-2 M ).
  • the width/height of all split units shall be even. If one partition structure results in a unit with either width or height to be odd, such a partition stmcture is automatically disallowed.
  • Z can be split with TT into three units.
  • the width and/or height of all split units shall be in a form of
  • K*M where M is the minimum width and/or height of allowed coding units/prediction units, such as 4; K is an integer larger than 0. If one partition stmcture results in a unit with either width or height not in such a form that partition stmcture is automatically disallowed.
  • width and/or height of all split non-ZUs shall be in a form of K*M, where M is the minimum width and/or height of allowed coding units/prediction units, such as 4. In this case, if a split zero unit doesn’t follow this restriction but non-ZUs follow this restriction, the partition stmcture is still allowed.
  • Example 8 The splitting signaling method of a ZU is the same to that of a normal CU.
  • splitting methods of a normal CU are allowed for a ZU.
  • the sub-set of splitting methods of a normal CU allowed for a ZU is determined by the ZU size, and/or picture/slice/tile boundary positions (bottom, right, bottom-right etc. al), and/or slice type.
  • the splitting signaling method of a ZU is still kept the same to that of a normal CU, however, the context for indications of TT (or other kinds of partition stmctures) may further depend on whether the current block is a ZU or not.
  • blocks with both width and height equal to (2 N x2 M ) could also be defined as ZUs.
  • TO and/or Tl is an integer such as 128 or 256.
  • TO and/or Tl is an integer such as 128 or 256.
  • T is an integer such as 16384 or 65536.
  • ZU must be an inter-coded block.
  • ZU can only be used in P/B -picture/slice.
  • the prediction_mode_flag is not signaled for a ZU, and is always inferred as inter-coded.
  • the ZU can be used in conjunction with the geometric partitioning (Reference [6]) for motion prediction, such that the inter prediction can generate predictors which are better fit to the motion and texture of the video.
  • the allowed partitioning types can depend on the shape of the parent partitioning. For example, if the aspect ratio of a block is greater or equal to 4 (width) to 1 (height), angles closer to the horizontal lines should be prohibited. If the aspect ratio is smaller or equal to 4 (width) to 1 (height), angles closer to vertical lines should be prohibited.
  • both merge and regular AMVP mode are available for the sub motion partitioning. Whether the regular AMVP mode is allowed can also be signaled through the slice header such that the effective coding modes can be adaptive to the video content.
  • ZUs For example, 2x2 ATMVP and 2x2 affine mode can be allowed for ZUs. This also helps minimizes the impact of corner cases when the either width or height of a ZU is 2.
  • Example 11 I n one example, a ZU must be split in an I-slice or intra-coded picture.
  • the width or height of the ZU is not in the form of 2 N .
  • the CU is treated as a ZU if:
  • TO and/or Tl is an integer such as 128 or 256.
  • TO and/or Tl is an integer such as 128 or 256.
  • T is an integer such as 16384 or 65536.
  • Example 12 The strength of in-loop filtering should be set to strong for ZUs.
  • the strong filter for de -blocking should be used for ZUs.
  • the strong bi-lateral filter should be used for ZUs.
  • a motion-compensated smoothing filter e.g., Overlapped
  • Block Motion Compensation can be used.
  • Enabling/disabling Adaptive Loop Filter (ALF) could be done in different ways for a ZU and a normal CU.
  • the CTU is partitioned into (W+w-l)/w columns and (H+h-l)/h rows sub-blocks (all divisions are integer divisions defined in C).
  • the sub-blocks in the last row/last column may be smaller than others.
  • the CTU is partitioned into W/w columns and H/h rows sub-blocks
  • FIGS. 18A and 18B show examples of partitioning a ZU block into sub-blocks for Adaptive Loop Control (ALF) on/off control.
  • ALF Adaptive Loop Control
  • Example 14 ALF or other kinds of filtering methods that requires block-level on/off control flags may be automatically disabled for a CU/PU/TU located at picture boundaries.
  • FIG. 14 shows a flowchart of an exemplary method for video coding, which may be implemented in a video encoder.
  • the method 1400 includes, at step 1410, determining dimensions of a block of video data.
  • the method 1400 includes, at step 1420, signaling, upon determining that at least one of the dimensions is a non-power-of-two, the block of video data as a zero unit (ZU) block, which is untransformable.
  • ZU zero unit
  • a non-power-of-two is any non-zero number that cannot be represented in the form 2 N .
  • the integers excluding the powers of two e.g., 1, 3, 5, 6, 7, 9, 10, 11 , 12, 13, 14, 15, 17, 18, ...) are each a non-power-of-two.
  • untransformable may be defined such that no transform, inverse-transform, quantization and de -quantization operations are invoked for a zero-unit.
  • the untransformable property of a zero-unit is that it is inferred to be coded with the skip mode, and thus, the skip mode need not be explicitly signaled.
  • untransformable may be defined in the context of Example 3 , such that although there may be non-zero residuals, there are no transform and inverse-transform operations defined for a zero- unit.
  • FIG. 15 shows a flowchart of another exemplary method for video coding, which may be implemented in a video decoder. This flowchart includes some features and/or steps that are similar to those shown in FIG. 14, and described above. At least some of these features and/or steps may not be separately described in this section.
  • the method 1500 includes, at step 1510, receiving a bitstream corresponding to a block of video data.
  • the method 1500 includes, at step 1520, receiving signaling indicating that the block of video data is a zero unit (ZU) block, which is untransformable, and has at least one dimension that is a non-power-of-two.
  • ZU zero unit
  • the method 1500 includes, at step 1530, decoding, based on the signaling, the bitstream to reconstruct the block of video data.
  • the signaling may exclude a merge index or a skip flag, and/or exclude a prediction_mode_flag, and/or include a maximum or minimum value for at least one of the dimensions of the ZU block.
  • the signaling is in a Video Parameter Set (VPS), a Sequence Parameter Set (SPS), a Picture Parameter Set (PPS), a slice header, a coding tree unit (CTU) or a coding unit (CU).
  • motion information of the ZU block is inherited from motion information of a neighboring block of size 2 N x2 M .
  • the ZU block is split into two or more units.
  • at least one of the two or more units is a zero unit.
  • at least one of the two or more units is a coding unit (CU) with dimensions 2 N X2 m .
  • the strength of in-loop filtering for the ZU block is set to strong.
  • a “strong” filter modifies three pixels on each side of the pixel of interest, whereas a“weak” filter modifies one or two pixels on each side.
  • the in-loop filtering includes bi-lateral filtering, de -blocking filtering, and/or using a motion-compensated smoothing filter.
  • FIG. 16 is a block diagram illustrating an example of the architecture for a computer system or other control device 1600 that can be utilized to implement various portions of the presently disclosed technology, including (but not limited to) methods 1400 and 1500.
  • the computer system 1600 includes one or more processors 1605 and memory 1610 connected via an interconnect 1625.
  • the interconnect 1625 may represent any one or more separate physical buses, point to point connections, or both, connected by appropriate bridges, adapters, or controllers.
  • the interconnect 1625 may include, for example, a system bus, a Peripheral Component Interconnect (PCI) bus, a HyperTransport or industry standard architecture (ISA) bus, a small computer system interface (SCSI) bus, a universal serial bus (USB), IIC (I2C) bus, or an Institute of Electrical and Electronics Engineers (IEEE) standard 674 bus, sometimes referred to as“Firewire.”
  • PCI Peripheral Component Interconnect
  • ISA HyperTransport or industry standard architecture
  • SCSI small computer system interface
  • USB universal serial bus
  • I2C IIC
  • IEEE Institute of Electrical and Electronics Engineers
  • the processor(s) 1605 may include central processing units (CPUs) to control the overall operation of, for example, the host computer. In certain embodiments, the processor(s) 1605 accomplish this by executing software or firmware stored in memory 1610.
  • the processor(s) 1605 may be, or may include, one or more programmable general-purpose or special-purpose microprocessors, digital signal processors (DSPs), programmable controllers, application specific integrated circuits (ASICs), programmable logic devices (PLDs), or the like, or a combination of such devices.
  • the memory 1610 can be or include the main memory of the computer system.
  • the memory 1610 represents any suitable form of random access memory (RAM), read-only memory (ROM), flash memory, or the like, or a combination of such devices.
  • RAM random access memory
  • ROM read-only memory
  • flash memory or the like, or a combination of such devices.
  • the memory 1610 may contain, among other things, a set of machine instructions which, when executed by processor 1605, causes the processor 1605 to perform operations to implement embodiments of the presently disclosed technology.
  • the network adapter 1615 provides the computer system 1600 with the ability to communicate with remote devices, such as the storage clients, and/or other storage servers, and may be, for example, an Ethernet adapter or Fiber Channel adapter.
  • FIG. 17 shows a block diagram of an example embodiment of a mobile device 1700 that can be utilized to implement various portions of the presently disclosed technology, including (but not limited to) methods 700, 750, 800, 850, 900, 950, 600, 1400 and 1500.
  • the mobile device 1700 can be a laptop, a smartphone, a tablet, a camcorder, or other types of devices that are capable of processing videos.
  • the mobile device 1700 includes a processor or controller 1701 to process data, and memory 1702 in communication with the processor 1701 to store and/or buffer data.
  • the processor 1701 can include a central processing unit (CPU) or a microcontroller unit (MCU).
  • CPU central processing unit
  • MCU microcontroller unit
  • the processor 1701 can include a field-programmable gate-array (FPGA).
  • the mobile device 1700 includes or is in communication with a graphics processing unit (GPU), video processing unit (VPU) and/or wireless communications unit for various visual and/or communications data processing functions of the smartphone device.
  • the memory 1702 can include and store processor-executable code, which when executed by the processor 1701 , configures the mobile device 1700 to perform various operations, e.g., such as receiving information, commands, and/or data, processing information and data, and transmitting or providing processed information/data to another device, such as an actuator or external display.
  • the memory 1702 can store information and data, such as instructions, software, values, images, and other data processed or referenced by the processor 1701.
  • various types of Random Access Memory (RAM) devices, Read Only Memory (ROM) devices, Flash Memory devices, and other suitable storage media can be used to implement storage functions of the memory 1702.
  • the mobile device 1700 includes an input/output (I/O) unit 1703 to interface the processor 1701 and/or memory 1702 to other modules, units or devices.
  • the I/O unit 1703 can interface the processor 1701 and memory 1702 with to utilize various types of wireless interfaces compatible with typical data communication standards, e.g., such as between the one or more computers in the cloud and the user device.
  • the mobile device 1700 can interface with other devices using a wired connection via the I/O unit 1703.
  • the mobile device 1700 can also interface with other external interfaces, such as data storage, and/or visual or audio display devices 1704, to retrieve and transfer data and information that can be processed by the processor, stored in the memory, or exhibited on an output unit of a display device 1704 or an external device.
  • the display device 1704 can display a video frame that includes a block (a CU, PU or TU) that applies the intra-block copy based on whether the block is encoded using a motion compensation algorithm, and in accordance with the disclosed technology.
  • a video decoder apparatus may implement a method of using zero-units as described herein is used for video decoding.
  • the various features of the method may be similar to the above-described method 1500.
  • the video decoding methods may be implemented using a decoding apparatus that is implemented on a hardware platform as described with respect to FIG. 16 and FIG. 17.
  • a method of video encoding (e.g., method 700 as depicted in FIG. 7A), comprising: making a determination (702), for a block of video data having at least a height or a width that is a non-power-of-two number of pixels, to encode the block of video data into a bitstream representation without a transform operation; and performing (704) an in-loop filtering on a result of the encoding, wherein a type of the in-loop filter is selected based on the determination.
  • a method of video decoding (e.g., method 750 depicted in FIG. 7B), comprising: making a determination (752), for a block of video data having at least a height or a width that is a non-power-of-two number of pixels, to decode the block of video data from a bitstream representation without a transform operation; and performing (754) an in-loop filtering on a result of the decoding, wherein a type of the in-loop filter is selected based on the determination.
  • a method for video encoding comprising: selecting (802), in response to a determination that a block of video data is to be coded as one of a coding unit (CU) or a zero-unit (ZU) block, a type of in-loop filter; determining (804), based on the selecting, an Adaptive Loop Filter (ALF) mode for the block of video data; encoding (806) the block of video data into a bitstream representation; and applying (808) the ALF to a result of the encoding using the ALF mode.
  • ALF Adaptive Loop Filter
  • a method of video decoding comprising: determining (852), from a bitstream representation, that a block of video data is to be decoded as one of a coding unit (CU) or a zero unit (ZU) block due to a pixel width or a pixel height of the block being a non-power-of-two integer; selecting (854), in response to the determining, an adaptive loop filter (ALF) mode for the block of video data; decoding (856) the block of video data from the bitstream representation; and performing (858) adaptive loop filtering based on the ALF mode.
  • ALF adaptive loop filter
  • a method of video decoding comprising: receiving (902) a bitstream corresponding to a block of video data, determining (904) that block of video data, which is a Coding Tree Unit (CTU), is to be coded as one of a coding unit (CU) or a zero-unit (ZU) block due to a pixel width or a pixel height of the block being a non-power-of- two integer; selecting (906), in response to determining that the block of video data is to be coded as one of the CU or the ZU block, a type of in-loop filter; receiving (908) signaling to control Adaptive Loop Filter (ALF) in the block based on the selection; and in-loop filtering (910) the block using the selected type of in-loop filter.
  • CTU Coding Tree Unit
  • a method for video encoding comprising: determining (952) that a block of video data is located near a picture boundary and is one of a coding unit (CU), a predictive unit (PU) or a transform unit (TU); controlling (954), in response to determining that the block of video data is located near the picture boundary and is one of the CU, the PU, or the TU, an in-loop filter; and signaling (956) controlling information for the in loop filter based on the determination.
  • CU coding unit
  • PU predictive unit
  • TU transform unit
  • a method of video decoding comprising: determining (962) that a block of video data is located near a picture boundary and is one of a coding unit (CU), a predictive unit (PU) or a transform unit (TU); receiving (964) control information for an in-loop filter based on the determination; and controlling (966) the in-loop filter based on the determination and the received controlling information.
  • CU coding unit
  • PU predictive unit
  • TU transform unit
  • 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 1 to 21.
  • the receiving operation may include receiving video data over a network connection or a data communication link such as a bus from a memory or storage device.
  • non-power-of-two numbers includes numbers that are not integer power of two (e.g., 4, 8, 16, 32).
  • the transform may be a DCT transform or another suitable transform for data compression (e.g., wavelet or Haar).
  • various in loop filtering examples used in the above-listed solutions include ALF, SAO, and so on.
  • the ALF may be used (or applied) to video pixels after reconstruction (e.g., dequantization).
  • signaling of information may be achieved using syntax elements that are placed in a pre -defined bitstream syntax of the coded representation of video.
  • Implementations of the subject matter and the functional operations described in this patent document can be implemented in various systems, digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them.
  • Implementations of the subject matter described in this specification can be implemented as one or more computer program products, i.e., one or more modules of computer program instmctions encoded on a tangible and non-transitory 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 of them.
  • data processing unit or“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 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 specification 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 instmctions 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 instmctions and data include all forms of nonvolatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices.
  • semiconductor memory devices e.g., EPROM, EEPROM, and flash memory devices.
  • the processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

L'invention concerne des dispositifs, des systèmes et des procédés permettant d'utiliser des unités zéro dans le codage vidéo et le codage d'images. Selon un aspect représentatif, un procédé de codage vidéo consiste à réaliser une détermination, pour un bloc de données vidéo ayant au moins une longueur ou une largeur dont le nombre de pixels n'est pas à la puissance deux, afin de coder le bloc de données vidéo en une représentation en flux binaire sans opération de transformation, et à réaliser un filtrage en boucle sur le résultat du codage, le type du filtre en boucle étant sélectionné sur la base de la détermination.
PCT/IB2019/055553 2018-06-29 2019-07-01 Filtrage d'une unité zéro WO2020003264A2 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CNPCT/CN2018/093631 2018-06-29
CN2018093631 2018-06-29
CN2018094767 2018-07-06
CNPCT/CN2018/094767 2018-07-06

Publications (2)

Publication Number Publication Date
WO2020003264A2 true WO2020003264A2 (fr) 2020-01-02
WO2020003264A3 WO2020003264A3 (fr) 2020-02-27

Family

ID=67226317

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2019/055553 WO2020003264A2 (fr) 2018-06-29 2019-07-01 Filtrage d'une unité zéro

Country Status (3)

Country Link
CN (1) CN110662035B (fr)
TW (1) TWI719520B (fr)
WO (1) WO2020003264A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022179414A1 (fr) * 2021-02-23 2022-09-01 Beijing Bytedance Network Technology Co., Ltd. Transformation et quantification sur des blocs non dyadiques

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7961963B2 (en) * 2005-03-18 2011-06-14 Sharp Laboratories Of America, Inc. Methods and systems for extended spatial scalability with picture-level adaptation
BR112013000556A2 (pt) * 2010-07-09 2019-09-24 Samsung Electronics Co Ltd método para decodificar um vídeo usando um processador de decodificação de vídeo, método para codificar um vídeo usando um processador de codificação de vídeo, aparaleho de decodificação de vídeo em relação a um processador de decodificação de vídeo, aparelho de codificação de vídeo em relação com um processador de codificação de vídeo, e meio de gravação legível por computador
CN107295342B (zh) * 2011-07-22 2020-04-28 Sk电信有限公司 视频编码装置
CN104094597B (zh) * 2011-10-17 2018-04-20 株式会社Kt 基于帧内预测的自适应变换方法及使用该方法的装置
SI2697973T1 (sl) * 2012-04-16 2017-11-30 Hfi Innovation Inc. Postopek in naprava za zančno filtriranje preko meja rezine ali ploščice
AU2012232992A1 (en) * 2012-09-28 2014-04-17 Canon Kabushiki Kaisha Method, apparatus and system for encoding and decoding the transform units of a coding unit
US20140192862A1 (en) * 2013-01-07 2014-07-10 Research In Motion Limited Methods and systems for prediction filtering in video coding
CN104202599B (zh) * 2014-09-23 2017-07-28 浙江工商大学 一种应用于hevc帧间编码的全零块检测方法
US10057574B2 (en) * 2015-02-11 2018-08-21 Qualcomm Incorporated Coding tree unit (CTU) level adaptive loop filter (ALF)
CN115134607A (zh) * 2015-06-11 2022-09-30 杜比实验室特许公司 使用自适应去块滤波编码和解码图像的方法及其装置
MX2018013461A (es) * 2016-05-13 2019-03-28 Sony Corp Aparato y metodo de procesamiento de imagenes.

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022179414A1 (fr) * 2021-02-23 2022-09-01 Beijing Bytedance Network Technology Co., Ltd. Transformation et quantification sur des blocs non dyadiques

Also Published As

Publication number Publication date
CN110662035B (zh) 2022-06-10
WO2020003264A3 (fr) 2020-02-27
TW202002655A (zh) 2020-01-01
TWI719520B (zh) 2021-02-21
CN110662035A (zh) 2020-01-07

Similar Documents

Publication Publication Date Title
US11765398B2 (en) Border partition
US11647189B2 (en) Cross-component coding order derivation
US20180139453A1 (en) Method of processing video signal and device for same
WO2019167849A1 (fr) Systèmes et procédés de partitionnement de régions d'une image permettant un codage vidéo utilisant différentes tailles d'unités de codage
WO2020003268A2 (fr) Définition d'unité zéro
WO2020016795A2 (fr) Restrictions de taille de bloc pour le codage multimédia visuel
WO2020003264A2 (fr) Filtrage d'une unité zéro
CN110662038B (zh) 零单元的划分方法、设备及介质
US12034911B2 (en) Definition of zero unit

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: 19737914

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

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 26-04-2021)

122 Ep: pct application non-entry in european phase

Ref document number: 19737914

Country of ref document: EP

Kind code of ref document: A2