Patent Description:
The present disclosure describes embodiments generally related to video coding.

Video coding and decoding can be performed using inter-picture prediction with motion compensation. Uncompressed digital video can include a series of pictures, each picture having a spatial dimension of, for example, <NUM> x <NUM> luminance samples and associated chrominance samples. The series of pictures can have a fixed or variable picture rate (informally also known as frame rate), of, for example <NUM> pictures per second or <NUM>. Uncompressed video has specific bitrate requirements. For example, 1080p60 <NUM>:<NUM>:<NUM> video at <NUM> bit per sample (1920x1080 luminance sample resolution at <NUM> frame rate) requires close to <NUM> Gbit/s bandwidth. An hour of such video requires more than <NUM> GBytes of storage space.

Compression can help reduce the aforementioned bandwidth and/or storage space requirements, in some cases by two orders of magnitude or more. Both lossless compression and lossy compression, as well as a combination thereof can be employed.

A video encoder and decoder can utilize techniques from several broad categories, including, for example, motion compensation, transform, quantization, and entropy coding.

Video codec technologies can include techniques known as intra coding. In intra coding, sample values are represented without reference to samples or other data from previously reconstructed reference pictures. In some video codecs, the picture is spatially subdivided into blocks of samples. When all blocks of samples are coded in intra mode, that picture can be an intra picture. Intra pictures and their derivations such as independent decoder refresh pictures, can be used to reset the decoder state and can, therefore, be used as the first picture in a coded video bitstream and a video session, or as a still image. The samples of an intra block can be exposed to a transform, and the transform coefficients can be quantized before entropy coding. Intra prediction can be a technique that minimizes sample values in the pre-transform domain. In some cases, the smaller the DC value after a transform is, and the smaller the AC coefficients are, the fewer the bits that are required at a given quantization step size to represent the block after entropy coding.

Traditional intra coding such as known from, for example MPEG-<NUM> generation coding technologies, does not use intra prediction. However, some newer video compression technologies include techniques that attempt, from, for example, surrounding sample data and/or metadata obtained during the encoding/decoding of spatially neighboring, and preceding in decoding order, blocks of data. Such techniques are henceforth called "intra prediction" techniques. Note that in at least some cases, intra prediction is using reference data only from the current picture under reconstruction and not from reference pictures.

There can be many different forms of intra prediction. When more than one of such techniques can be used in a given video coding technology, the technique in use can be coded in an intra prediction mode. In certain cases, modes can have submodes and/or parameters, and those can be coded individually or included in the mode codeword. Which codeword to use for a given mode/submode/parameter combination can have an impact in the coding efficiency gain through intra prediction, and so can the entropy coding technology used to translate the codewords into a bitstream.

A certain mode of intra prediction was introduced with H. <NUM>, refined in H. <NUM>, and further refined in newer coding technologies such as joint exploration model (JEM), versatile video coding (VVC), and benchmark set (BMS). A predictor block can be formed using neighboring sample values belonging to already available samples. Sample values of neighboring samples are copied into the predictor block according to a direction. A reference to the direction in use can be coded in the bitstream or may itself be predicted.

Referring to <FIG>, depicted in the lower right is a subset of nine predictor directions known from H. <NUM>'s <NUM> possible predictor directions (corresponding to the <NUM> angular modes of the <NUM> intra modes). The point where the arrows converge (<NUM>) represents the sample being predicted. The arrows represent the direction from which the sample is being predicted. For example, arrow (<NUM>) indicates that sample (<NUM>) is predicted from a sample or samples to the upper right, at a <NUM> degree angle from the horizontal. Similarly, arrow (<NUM>) indicates that sample (<NUM>) is predicted from a sample or samples to the lower left of sample (<NUM>), in a <NUM> degree angle from the horizontal.

Still referring to <FIG>, on the top left there is depicted a square block (<NUM>) of <NUM> x <NUM> samples (indicated by a dashed, boldface line). The square block (<NUM>) includes <NUM> samples, each labelled with an "S", its position in the Y dimension (e.g., row index) and its position in the X dimension (e.g., column index). For example, sample S21 is the second sample in the Y dimension (from the top) and the first (from the left) sample in the X dimension. Similarly, sample S44 is the fourth sample in block (<NUM>) in both the Y and X dimensions. As the block is <NUM> x <NUM> samples in size, S44 is at the bottom right. Further shown are reference samples that follow a similar numbering scheme. A reference sample is labelled with an R, its Y position (e.g., row index) and X position (column index) relative to block (<NUM>). <NUM> and H. <NUM>, prediction samples neighbor the block under reconstruction; therefore no negative values need to be used.

Intra picture prediction can work by copying reference sample values from the neighboring samples as appropriated by the signaled prediction direction. For example, assume the coded video bitstream includes signaling that, for this block, indicates a prediction direction consistent with arrow (<NUM>)-that is, samples are predicted from a prediction sample or samples to the upper right, at a <NUM> degree angle from the horizontal. In that case, samples S41, S32, S23, and S14 are predicted from the same reference sample R05. Sample S44 is then predicted from reference sample R08.

In certain cases, the values of multiple reference samples may be combined, for example through interpolation, in order to calculate a reference sample; especially when the directions are not evenly divisible by <NUM> degrees.

The number of possible directions has increased as video coding technology has developed. <NUM> (year <NUM>), nine different directions could be represented. That increased to <NUM> in H. <NUM> (year <NUM>), and JEM/VVC/BMS, at the time of disclosure, can support up to <NUM> directions. Experiments have been conducted to identify the most likely directions, and certain techniques in the entropy coding are used to represent those likely directions in a small number of bits, accepting a certain penalty for less likely directions. Further, the directions themselves can sometimes be predicted from neighboring directions used in neighboring, already decoded, blocks.

<FIG> shows a schematic (<NUM>) that depicts <NUM> intra prediction directions according to JEM to illustrate the increasing number of prediction directions over time.

The mapping of intra prediction directions bits in the coded video bitstream that represent the direction can be different from video coding technology to video coding technology; and can range, for example, from simple direct mappings of prediction direction to intra prediction mode, to codewords, to complex adaptive schemes involving most probable modes, and similar techniques. In all cases, however, there can be certain directions that are statistically less likely to occur in video content than certain other directions. As the goal of video compression is the reduction of redundancy, those less likely directions will, in a well working video coding technology, be represented by a larger number of bits than more likely directions.

In some video compression techniques, an MV applicable to a certain area of sample data can be predicted from other MVs, for example from those related to another area of sample data spatially adjacent to the area under reconstruction, and preceding that MV in decoding order. Doing so can substantially reduce the amount of data required for coding the MV, thereby removing redundancy and increasing compression. MV prediction can work effectively, for example, because when coding an input video signal derived from a camera (known as natural video) there is a statistical likelihood that areas larger than the area to which a single MV is applicable move in a similar direction and, therefore, can in some cases be predicted using a similar motion vector derived from MVs of neighboring area. That results in the MV found for a given area to be similar or the same as the MV predicted from the surrounding MVs, and that in turn can be represented, after entropy coding, in a smaller number of bits than what would be used if coding the MV directly. In some cases, MV prediction can be an example of lossless compression of a signal (namely: the MVs) derived from the original signal (namely: the sample stream). In other cases, MV prediction itself can be lossy, for example because of rounding errors when calculating a predictor from several surrounding MVs.

Various MV prediction mechanisms are described in H. <NUM>/HEVC (ITU-T Rec. <NUM>, "High Efficiency Video Coding", December <NUM>). Out of the many MV prediction mechanisms that H. <NUM> offers, described here is a technique henceforth referred to as "spatial merge".

Referring to <FIG>, a current block (<NUM>) comprises samples that have been found by the encoder during the motion search process to be predictable from a previous block of the same size that has been spatially shifted. Instead of coding that MV directly, the MV can be derived from metadata associated with one or more reference pictures, for example from the most recent (in decoding order) reference picture, using the MV associated with either one of five surrounding samples, denoted A0, A1, and B0, B1, B2 (<NUM> through <NUM>, respectively). <NUM>, the MV prediction can use predictors from the same reference picture that the neighboring block is using.

Published patent application <CIT>, discloses signalling the CTU size (for JEM said to range between 16x16 and 256x256). It also discloses entropy coding the syntax elements - in particular the ones relative to the "coding structure" of a video block (understood to refer to the partitioning scheme, including the CTU size) - using (among other possibilities) binarisation based on truncated unary coding.

The invention is defined by the appended independent claims, addressed to a method for video decoding, an apparatus for video decoding and a computer-readable storage means storing a program for video decoding.

The dependent claims define further optional elements of the invention.

The invention is disclosed by <FIG> and the corresponding parts of the description. Unless defining further matter falling under the scope of one or more claims, the alternative approaches and - more generally - any further teaching are/is to be considered as representing further examples not defining the invention even if occasionally the expressions "embodiment" and/or "invention" happen to be used therefor.

Representative networks include telecommunications networks, local area networks, wide area networks and/or the Intemet.

A streaming system may include a capture subsystem (<NUM>), that can include a video source (<NUM>), for example a digital camera, creating for example a stream of video pictures (<NUM>) that are uncompressed. In an example, the stream of video pictures (<NUM>) includes samples that are taken by the digital camera. The stream of video pictures (<NUM>), depicted as a bold line to emphasize a high data volume when compared to encoded video data (<NUM>) (or coded video bitstreams), can be processed by an electronic device (<NUM>) that includes a video encoder (<NUM>) coupled to the video source (<NUM>). The video encoder (<NUM>) can include hardware, software, or a combination thereof to enable or implement aspects of the disclosed subject matter as described in more detail below. The encoded video data (<NUM>) (or encoded video bitstream (<NUM>)), depicted as a thin line to emphasize the lower data volume when compared to the stream of video pictures (<NUM>), can be stored on a streaming server (<NUM>) for future use. One or more streaming client subsystems, such as client subsystems (<NUM>) and (<NUM>) in <FIG> can access the streaming server (<NUM>) to retrieve copies (<NUM>) and (<NUM>) of the encoded video data (<NUM>). A client subsystem (<NUM>) can include a video decoder (<NUM>), for example, in an electronic device (<NUM>). The video decoder (<NUM>) decodes the incoming copy (<NUM>) of the encoded video data and creates an outgoing stream of video pictures (<NUM>) that can be rendered on a display (<NUM>) (e.g., display screen) or other rendering device (not depicted). In some streaming systems, the encoded video data (<NUM>), (<NUM>), and (<NUM>) (e.g., video bitstreams) can be encoded according to certain video coding/compression standards. Examples of those standards include ITU-T Recommendation H. In an example, a video coding standard under development is informally known as Versatile Video Coding (VVC). The disclosed subject matter may be used in the context of VVC.

During operation, in some examples, the source coder (<NUM>) may perform motion compensated predictive coding, which codes an input picture predictively with reference to one or more previously coded picture from the video sequence that were designated as "reference pictures. " In this manner, the coding engine (<NUM>) codes differences between pixel blocks of an input picture and pixel blocks of reference picture(s) that may be selected as prediction reference(s) to the input picture.

When the coded video data may be decoded at a video decoder (not shown in <FIG>), the reconstructed video sequence typically may be a replica of the source video sequence with some errors.

A block partitioning structure can be referred to as a coding tree. In some embodiments, the block partitioning structure uses a quad-tree (QT) plus binary tree (BT). For example, by using a QT structure, a CTU is split into CUs to adapt to various local characteristics. A decision on whether to code a picture area using an inter-picture (temporal) or intra-picture (spatial) prediction can be made at a CU level. Each CU can be further split into one, two, or four PUs according to a PU splitting type. Inside one PU, a same prediction process is applied and relevant information can be transmitted to a decoder on a PU basis.

After obtaining a residual block by applying a prediction process based on the PU splitting type, a CU can be partitioned into TUs according to another QT structure. As can be seen, there are multiple partition conceptions including CU, PU, and TU.

At a picture boundary, in some embodiments, implicit quadtree split can be employed so that a block will keep QT splitting until the size fits the picture boundary.

In some embodiments, a quadtree plus binary tree (QTBT) structure is employed. The QTBT structure removes the concepts of multiple partition types (e.g., the CU, PU, and TU concepts), and supports more flexibility for CU partition shapes. In the QTBT block structure, a CU can have either a square or rectangular shape.

<FIG> shows a CTU (<NUM>) that is partitioned by using a QTBT structure (<NUM>) shown in <FIG>. The CTU (<NUM>) is first partitioned by a QT structure. The QT leaf nodes are further partitioned by a BT structure or a QT structure. There can be two splitting types, symmetric horizontal splitting and symmetric vertical splitting, in the BT splitting. The BT leaf nodes are called CUs that can be used for prediction and transform processing without any further partitioning. Accordingly, CU, PU, and TU have the same block size in the QTBT coding block structure.

In some embodiments, a CU can include coding blocks (CBs) of different color components. For example, one CU contains one luma CB and two chroma CBs in the case of P and B slices of the <NUM>:<NUM>:<NUM> chroma format. A CU can include a CB of a single color component. For example, one CU contains only one luma CB or just two chroma CBs in the case of I slices.

The following parameters are defined for the QTBT partitioning scheme in some embodiments:.

In one example of the QTBT partitioning structure, the CTU size is set as <NUM>×<NUM> luma samples with two corresponding <NUM>×<NUM> blocks of chroma samples, the MinQTSize is set as <NUM>×<NUM>, the MaxBTSize is set as <NUM>×<NUM>, the MinBTSize (for both width and height) is set as <NUM>×<NUM>, and the MaxBTDepth is set as <NUM>. The QT partitioning is applied to the CTU first to generate QT leaf nodes. The QT leaf nodes may have a size from <NUM>×<NUM> (i.e., the MinQTSize) to <NUM>×<NUM> (i.e., the CTU size). If the leaf QT node is <NUM>×<NUM>, it will not be further split by the binary tree since the size exceeds the MaxBTSize (i.e., <NUM>×<NUM>). Otherwise, the leaf QT node could be further partitioned by the binary tree. Therefore, the QT leaf node is also the root node for the binary tree and it has the BT depth as <NUM>.

When the BT depth reaches MaxBTDepth (i.e., <NUM>), no further splitting is considered. When the BT node has a width equal to MinBTSize (i.e., <NUM>), no further horizontal splitting is considered. Similarly, when the BT node has height equal to MinBTSize, no further vertical splitting is considered. The leaf nodes of the binary tree are further processed by prediction and transform processing without any further partitioning. In an embodiment, a maximum CTU size is <NUM>×<NUM> luma samples.

In <FIG>, the solid lines indicate QT splitting and dotted lines indicate BT splitting. In each splitting (i.e., non-leaf) node of the binary tree, one flag can be signaled to indicate which splitting type (i.e., horizontal or vertical) is used. For example, <NUM> indicates a horizontal splitting and <NUM> indicates a vertical splitting. For the QT splitting, there is no need to indicate the splitting type since quadtree splitting always splits a block both horizontally and vertically to produce <NUM> sub-blocks with an equal size.

In some embodiments, the QTBT scheme supports the flexibility for the luma and chroma to have a separate QTBT structure. For example, for P and B slices, the luma and chroma blocks in one CTU share the same QTBT structure. However, for I slices, the luma CTB is partitioned into CUs by a QTBT structure, and the chroma blocks are partitioned into chroma CUs by another QTBT structure. Thus, a CU in an I slice can include, or consist of, a coding block of the luma component or coding blocks of two chroma components, and a CU in a P or B slice can include, or consist of, coding blocks of all three color components.

In some embodiments, inter prediction for small blocks is restricted to reduce memory access of motion compensation. For example, bi-prediction is not supported for <NUM>×<NUM> and <NUM>×<NUM> blocks, and inter prediction is not supported for <NUM>×<NUM> blocks. In some examples, such as when the QTBT is implemented, the above restrictions can be removed.

A CTU size can be represented by a width (or a height) M of a CTU. In an embodiment, when the CTU has a square shape, the CTU size can also be represented by MxM luma samples in the CTU. Thus, the CTU size can be referred to as M or MxM. In an embodiment, a same CTU size can be used to code (e.g., encode/decode) pictures in a video sequence, and coding information indicating the CTU size can be signaled in a Sequence Parameter Setting (SPS) (e.g., in a SPS header) and shared among the pictures in the video sequence.

In some embodiments, a plurality of CTU sizes (e.g., four CTU sizes), such as <NUM>, <NUM>, <NUM>, and <NUM>, can be used. Thus, the four CTU sizes can be <NUM>×<NUM>, <NUM>×<NUM>, <NUM>×<NUM>, and <NUM>×<NUM> luma samples, respectively. A varible 'CtbSizeY' can be used to represent the four CTU sizes (e.g., <NUM>, <NUM>, <NUM>, and <NUM>). Numbers <NUM>-<NUM> are the base <NUM> logarithms of the four CTU sizes <NUM>, <NUM>, <NUM>, and <NUM>, respectively, and can be represented by a variable 'CtbLog2SizeY'. Four numbers <NUM>, <NUM>, <NUM>, and <NUM> can be used to code <NUM> (or <NUM>×<NUM> luma samples), <NUM> (or <NUM>×<NUM> luma samples), <NUM> (or <NUM>×<NUM> luma samples), and <NUM> (or <NUM>×<NUM> luma samples), respectively, and can be represented by a variable 'log2_ctu_size_minus2'. For example, the four numbers <NUM>-<NUM> (or log2_ctu_size_minus2) are differences between the base <NUM> logarithms (or CtbLog2SizeY) of the four CTU sizes <NUM>, <NUM>, <NUM>, and <NUM> and a value <NUM>, respectively. An example of a SPS header syntax for CTU sizes can be set to 'log2_ctu_size_minus2' as shown in <FIG>.

The four numbers <NUM>-<NUM> (or log2_ctu_size_minus2) can be coded using an entropy coding tool, for example Exp-Golomb coding, such as unsigned integer <NUM>-th order Exp-Golomb coding (or ue(v)). Thus, a corresponding descriptor for the variable log2_ctu_size_minus2 is ue(v) in <FIG>.

<FIG> shows an example of ue(v) coding according to an embodiment of the disclosure. Variable bit strings (<NUM>) can be used to code the variable log2_ctu_size_minus2 (also referred to coded values or code numbers (codeNums)) (<NUM>). For example, the bit strings <NUM>, <NUM>, <NUM>, and <NUM> are used to code the codeNums <NUM>-<NUM>, respectively.

Based on the description above, semantics for CTU sizes can be described below. log2_ctu_size_minus2 plus <NUM> specifies a luma CTB size of each CTU (as shown in Eq. (<NUM>)). log2_min_luma_coding_block_size_minus2 plus <NUM> specifies a minimum luma coding block size. The variables CtbLog2SizeY and CtbSizeY can be derived using Eqs. (<NUM>)-(<NUM>). <MAT> <MAT>.

For example, the bit string <NUM> represents the codeNum <NUM> based on ue(v) coding as shown in <FIG>. Thus, a value of the variable log2_ctu_size_minus2 is <NUM>. A value of the variable CtbLog2SizeY is determined to be <NUM> based on Eq. (<NUM>). A value of the variable CtbSizeY is determined to be <NUM>CtbLog2SizeY based on Eq. (<NUM>), and thus the value of the variable CtbSizeY is <NUM><NUM> = <NUM>. Thus, the CTU size is <NUM> or 16x16 luma samples. The above description can be applied to other bit strings that indicate various CTU sizes, such as <NUM>, <NUM>, or <NUM>.

In some examples, a much larger overhead can occur when using the CTU size <NUM> instead of using larger CTU sizes (e.g., <NUM>). Thus, a decoding time can be longer when using the CTU size <NUM>. In an example, a CTU size of <NUM>×<NUM> luma samples corresponds to an <NUM>×<NUM> chroma CTB size. For certain coding modules, processing the <NUM>×<NUM> chroma CTB size is challenging because a loop filter typically uses a <NUM>×<NUM> block as an input. Further, the CTU size <NUM>×<NUM> can cause a significant encoding loss. Thus, the CTU size <NUM> can be removed.

In some embodiments, a plurality of CTU sizes (e.g., three CTU sizes), such as <NUM>, <NUM>, and <NUM> (or <NUM>×<NUM>, <NUM>×<NUM>, <NUM>×<NUM> luma samples) are used. Similarly, the varible 'CtbSizeY' can be used to represent the three CTU sizes. Numbers <NUM>-<NUM> are the base <NUM> logarithms of the three CTU sizes <NUM>, <NUM>, and <NUM>, respectively, and can be represented by the variable 'CtbLog2SizeY'. Syntax and corresponding description in the SPE header can be modified as below and shown in <FIG>.

Three numbers <NUM>-<NUM> can be used to code the three CTU sizes, e.g., <NUM> (or <NUM>×<NUM> luma samples), <NUM> (or <NUM>×<NUM> luma samples), and <NUM> (or <NUM>×<NUM> luma samples), respectively, and can be represented by a variable 'log2_ctu_size_minus5'. For example, the three numbers <NUM>-<NUM> (or log2_ctu_size_minus5) are differences between the base <NUM> logarithms (i.e., <NUM>-<NUM>) (or CtbLog2SizeY) of the three CTU sizes <NUM>, <NUM>, and <NUM> and a number <NUM>, respectively. As described above, a SPS header syntax for CTU sizes can be set to 'log2_ctu_size_minus5' as shown in <FIG>.

The three numbers <NUM>-<NUM> (or log2_ctu_size_minus5) can be coded using an entropy coding tool having a fixed length coding, such as unsigned integer using n bits (or u(n)). In an example, <NUM> bits can be used (e.g., n = <NUM>). Thus, a corresponding descriptor is u(<NUM>) in <FIG>. Comparing <FIG> and <FIG>, the differences are indicated by labels <NUM> and <NUM>.

<FIG> shows an example of u(<NUM>) coding according to an embodiment of the disclosure. Fixed-length bit strings (<NUM>) can be used to code the variable log2_ctu_size_minus5 (also referred to coded values or codeNums) (<NUM>). For example, the bit strings <NUM>, <NUM>, and <NUM> can be used to code the codeNums <NUM>-<NUM>, respectively.

Semantics for CTU sizes are described as follows, and some differences associated with log2_ctu_size_minus2 and log2_ctu_size_minus5 are highlighted using italics.

log2_ctu_size_minus5 plus <NUM> specifies the luma CTB size of each CTU. In an example, it is a requirement of bitstream conformance that the value of log2_ctusize_minus5 be less than or equal to <NUM>.

log2_min_luma_coding_block_size_minus2 plus <NUM> can specify the minimum luma coding block size.

The variables CtbLog2SizeY and CtbSizeY can be derived using Eqs. (<NUM>)-(<NUM>) where Eq. (<NUM>) is different from Eq. (<NUM>).

For example, the bit string <NUM> represents the codeNum <NUM> based on u(<NUM>) coding as shown in <FIG>. Thus, log2_ctu_size_minus5 is <NUM>. A value of the variable CtbLog2SizeY is determined to be <NUM> based on Eq. (<NUM>). A value of the variable CtbSizeY is determined to be <NUM>CtbLog2SizeY based on Eq. (<NUM>), and thus the value of the variable CtbSizeY is <NUM><NUM> = <NUM>. Thus, the CTU size is <NUM> or 32x32 luma samples. The above description can be applied to other bit strings that indicates other CTU sizes (e.g., <NUM> or <NUM>).

In some embodiments, only three numbers (e.g., the codeNums <NUM>-<NUM>) representing the three CTU sizes are encoded. Using the fixed length coding u(<NUM>) to describe the syntax log2_ctu_size_minus5 can waste one bit, for example, when the encoded number is <NUM> or <NUM>.

In some embodiments described above, the number <NUM> (e.g., the codeNum <NUM>) can be used to represent the CTU size <NUM> (or 32x32 luma samples) and the number <NUM> (e.g., the codeNum <NUM>) can be used to represent the CTU size <NUM> (or 128x128 luma samples). In various examples, the CTU size <NUM> is the most frequently used CTU size in a video sequence, and thus encoding the CTU size <NUM> with the number <NUM> can decrease coding efficiency and increase coding complexity.

In some embodiments, for pictures in a video sequence, a CTU size to be used for coding the pictures can be indicated in coded information for the video sequence. Information indicating the CTU size can be in an SPS header. The CTU size can be one of a plurality of CTU sizes, such as the three CTU sizes <NUM>, <NUM>, and <NUM>. According to aspects of the disclosure, a truncated unary coding can be used to code (e.g., encode/decode) numbers (e.g., coded values or codeNums) indicating CTU sizes. When compared with the fixed-length coding described in above (e.g., with reference to <FIG>), the truncated unary coding can improve coding efficiency, for example, by eliminating unnecessary waste of bits. Thus, a size of the SPS header can be smaller when the truncated unary coding is used instead of the fixed-length coding u(<NUM>), and thus improving the coding efficiency. Further, in some examples, an illegal bitstream generated by a non-conforming encoder (e.g., enabling the CTU size 16x16 that is not allowed in some standards or coders) can be avoided.

In an embodiment, the three CTU sizes <NUM>, <NUM>, and <NUM> (or <NUM>×<NUM>, <NUM>×<NUM>, <NUM>×<NUM> luma samples) can be used. As described above, the variable 'CtbSizeY' can be used to represent the three CTU sizes. Numbers <NUM>-<NUM> are the base <NUM> logarithms of the three CTU sizes <NUM>, <NUM>, and <NUM>, respectively, and can be represented by the variable 'CtbLog2SizeY'. Syntax and corresponding description in the SPS header can be modified as below and shown in <FIG>.

The three numbers <NUM>-<NUM> can be used to code or represent the three CTU sizes. According to aspects of the disclosure, <NUM> is used to represent (or code) <NUM> (or <NUM>×<NUM> luma samples), <NUM> is used to represent (or code) <NUM> (or <NUM>×<NUM> luma samples), and <NUM> is used to represent (or code) <NUM> (or <NUM>×<NUM> luma samples), and thus the three numbers can be represented by a variable 'seven_minus_log2_ctu_size'. For example, the three numbers <NUM>-<NUM> (or seven_minus_log2_ctu_size) are differences between <NUM> and the base <NUM> logarithms <NUM>, <NUM>, and <NUM> (or CtbLog2SizeY) of the three CTU sizes <NUM>, <NUM>, and <NUM>, respectively. As described above, a SPS header syntax for CTU sizes can be set to 'seven _minus_log2_ctu_size' as shown in <FIG>.

The three numbers <NUM>-<NUM> (or seven _minus_log2_ctu_size) can be coded using the truncated unary coding (or tu(v)) as shown by a descriptor is tu(v) in <FIG>. In an embodiment, the truncated unary coding is a unary coding that generates a bin string (or bit string) of '<NUM>' followed by a '<NUM>' when a number to be coded is less than a maximum value cMax. When the number to be coded is equal to the maximum value cMax, the last '<NUM>' is truncated. In an embodiment, the maximum value cMax is <NUM> when coding the three numbers <NUM>-<NUM> (or seven_minus_log2_ctu_size). <FIG> shows an example of the truncated unary coding according to an embodiment of the disclosure. Variable-length bit strings (<NUM>) are used to code the variable seven_minus_log2_ctu_size (also referred to coded values or codeNums.

The bit string <NUM> can be used to code the codeNum <NUM>. The bit string <NUM> can be used to code the codeNum <NUM>. The bit string <NUM> can be used to code the codeNum <NUM>. Comparing <FIG> and <FIG>, the differences are indicated by labels (<NUM>) and (<NUM>). Comparing <FIG> and <FIG>, the differences are indicated by the labels (<NUM>) and (<NUM>).

In general, the three numbers <NUM>-<NUM> (or seven_minus_log2_ctu_size) can be coded using any suitable coding method, such as variable-length coding (e.g., the truncated unary coding, Exp-Golomb coding), fixed-length coding (e.g., u(n)), or the like where the number <NUM> represents the CTU size <NUM>. Code numbers can be assigned based on frequency of use of the CTU size. For example, a CTU size of <NUM> can be assigned to a lowest or smaller code number.

As described above in <FIG>, the variable 'seven _minus_log2_ctu_size' can be used to describe CTU sizes, and the CTU size <NUM> can be coded with the coded value or the codeNum <NUM>. Further, the bit string <NUM> having <NUM> bit can be used to code the codeNum <NUM>. In various examples, when the CTU size <NUM> is used more frequently than other CTU sizes (e.g., <NUM> and <NUM>), coding the CTU size <NUM> with <NUM> bit can improve coding efficiency. For example, the bit string <NUM> can be used to indicate the CTU size <NUM> has <NUM> bits (<FIG>) or the bit string <NUM> can used to indicate the CTU size <NUM> has <NUM> bits (<FIG>).

Semantics for CTU sizes are described as follows, and some differences between seven_minus_log2_ctu_sizeand other variable(s) (log2_ctu_size_minus5 and log2_ctu_size_minus2) are highlighted using italics.

seven minus_log2_ctu_size specifies the luma CTB size of each CTU. In an example, it is a requirement of bitstream conformance that the value of seven _minus_log2_ctu_size be less than or equal to <NUM>.

log2 _min_luma_coding_block_size_minus2 plus <NUM> can specify the minimum luma coding block size.

The variables CtbLog2SizeY and CtbSizeY can be derived using Eqs. (<NUM>) and (<NUM>).

Referring to <FIG>, for example, the bit string <NUM> can be used to represent the codeNum <NUM> based on tu(v) coding having the maximum value cMax of <NUM>. Thus, a value of the variable seven _minus_log2_ctu_sizeis <NUM>. A value of the variable CtbLog2SizeY is determined to be <NUM> based on Eq. (<NUM>). A value of the variable CtbSizeY is determined to be <NUM>CtbLog2SizeY based on Eq. (<NUM>), and thus the value of the variable CtbSizeY is <NUM><NUM> = <NUM>. Thus, the CTU size is <NUM> or 128x128 luma samples. The above description can be applied to other bit strings that indicate other CTU sizes (e.g., <NUM> or <NUM>).

According to aspects of the disclosure, the coded information of the pictures in the coded video sequence can be received by a decoder. The coded information can indicate a CTU size that is selected or used to encode the pictures, for example, by an encoder. The selected CTU size can be one of a plurality of CTU sizes, such as the three CTU sizes <NUM>, <NUM>, and <NUM>. The coded information can be encoded/decoded using the truncated unary coding to obtain the selected CTU size. In an example, the coding information can indicate a coding tool (e.g., the truncated unary coding) used to code the CTU size. In another example, the coding tool is predetermined or signaled beforehand.

In an embodiment, the coded information is in an SPS header (e.g., a syntax and a descriptor of the SPS header), such as described above with reference to <FIG>. The coded information can include a bit string (e.g., the bit string <NUM> in <FIG>). In an example, a coded value/codeNum (e.g., a seven_minus_log2_ctu_size) can be determined from the bit string using the truncated unary coding and the coded value is the number <NUM> shown in <FIG>. In an example, the maximum value cMax used in the truncated unary coding is <NUM>. Further, the selected CTU size (e.g., <NUM>) can be determined from the coded value (e.g., the number <NUM>) based on the syntax and associated semantics (e.g., Eq. (<NUM>) and Eq. (<NUM>)). For example, a value of the variable CtbLog2SizeY is determined to be a difference between <NUM> and the coded value using Eq. (<NUM>), and thus the value of the variable CtbLog2SizeY is <NUM> when seven_minus_log2_ctu_size is <NUM>. Then a value of the variable CtbSizeY is determined to be <NUM>CtbLog2SizeY using Eq. (<NUM>), and thus the value of the variable CtbSizeY is <NUM><NUM> = <NUM> when CtbLog2SizeY is <NUM>.

As described above with reference to <FIG>, coding a most frequently used CTU size with a smaller number of bits can improve coding efficiency. In some examples, the most frequently used CTU size is <NUM>, and thus the CTU size <NUM> can be coded with <NUM> bit (e.g., the bit string '<NUM>' as shown in <FIG>).

In some embodiments, a plurality of CTU sizes (e.g., three CTU sizes), such as <NUM>, <NUM>, and <NUM>, can be represented using the variable log2_ctu_size_minus5, for example, using Eqs. (<NUM>) and (<NUM>) and coded using truncated unary coding tu(v) having the maximum value cMax of <NUM>, such as shown in <FIG>. In an example, the CTU size <NUM> is encoded with the coded value (or codeNum) <NUM>, and thus the bit string <NUM> is used to encode the number <NUM> and the CTU size <NUM>. In an example the CTU size <NUM> is encoded with the coded value (or codeNum) <NUM>, and thus the bit string <NUM> is used to encode the number <NUM> and the CTU size <NUM>. In an example, the CTU size <NUM> is encoded with the coded value (or codeNum) <NUM>, and thus the bit string <NUM> is used to encode the number <NUM> and the CTU size <NUM>. Thus, a coded value (or log2_ctu_size_minus5) can be determined from a bit string using the truncated unary coding with the maximum value cMax of <NUM>. Further, the selected CTU size can be determined from the coded value based on the syntax and associated semantics (e.g., Eq. (<NUM>) and Eq. (<NUM>)). For example, a value of the variable CtbLog2SizeY can be determined to be a sum of <NUM> and the coded value using Eq. (<NUM>). Then a value of the variable CtbSizeY can be determined to be <NUM>CtbLog2SizeY using Eq. (<NUM>).

<FIG> shows a flow chart outlining a process (<NUM>) according to an embodiment of the disclosure. The process (<NUM>) can be used to determine a CTU size to be used for pictures in a coded video sequence. In various embodiments, the process (<NUM>) are executed by processing circuitry, such as the processing circuitry in the terminal devices (<NUM>), (<NUM>), (<NUM>) and (<NUM>), the processing circuitry that performs functions of the video encoder (<NUM>), the processing circuitry that performs functions of the video decoder (<NUM>), the processing circuitry that performs functions of the video decoder (<NUM>), the processing circuitry that performs functions of the video encoder (<NUM>), and the like. In some embodiments, the process (<NUM>) is implemented in software instructions, thus when the processing circuitry executes the software instructions, the processing circuitry performs the process (<NUM>). The process starts at (S1301) and proceeds to (S1310).

At (S1310), coded information of the pictures in the coded video sequence can be received, for example, by a decoder. The coded information can include CTU size information that indicates a CTU size that is selected for the pictures, for example, by an encoder to encode the pictures. The selected CTU size can be one of a plurality of CTU sizes, such as the three CTU sizes 32x32, 64x64, and 128x128 luma samples. The plurality of CTU sizes can include any suitable number of CTU sizes and can include any suitable CTU size(s). The CTU size information can be encoded using the truncated unary code or other coding schemes.

In an example, the coded information indicates a coding tool used to code the selected CTU size. For example, the coding information is in an SPS header that indicates the coding tool (e.g., tu(v), u(<NUM>), or ue(v)). In some examples, the syntax is included in the SPS header, and thus indicating the corresponding semantics.

At (S1320), the selected CTU size can be determined using the coding tool (e.g., the truncated unary coding) based on the CTU size information. For example, the coded information is decoded using the truncated unary decoding, as described above with reference to <FIG>. In an embodiment, the CTU size information includes a bit string. A coded value (e.g., a codeNum) can be determined from the bit string using the truncated unary decoding. For example, the coded value can be determined to be <NUM>, <NUM>, and <NUM> when the bit string is <NUM>, <NUM>, and <NUM>, respectively and a maximum value Cmax used in the truncated unary coding is <NUM>. Further, the selected CTU size can be determined based on the coded value, for example, using the syntax (or the corresponding semantics) indicated in the coding information.

In an example, the syntax indicates that the coded value refers to a value of the variable seven _minus_log2_ctu_size, and thus Eqs. (<NUM>) and (<NUM>) can be used to obtain the CTU size. Accordingly, the selected CTU size is <NUM> when the coded value is <NUM>. The selected CTU size is <NUM> when the coded value is <NUM>. The selected CTU size is <NUM> when the coded value is <NUM>. Further, the selected CTU _sizecan be determined to be <NUM>CtbLog2SizeY where a value of the variable CtbLog2SizeY is a difference between <NUM> and the coded value.

In an example, the syntax indicates that the coded value refers to a value of the variable log2_ctu_size_minus5, and thus Eqs. (<NUM>) and (<NUM>) can be used to obtain the selected CTU size. Accordingly, the selected CTU size is <NUM> when the coded value is <NUM>. The selected CTU size is <NUM> when the coded value is <NUM>. The selected CTU size is <NUM> when the coded value is <NUM>. Further, the selected CTU _sizecan be determined to be <NUM>CtbLog2SizeY where a value of the variable CtbLog2SizeY is a sum of the coded value and <NUM>.

At (S1330), samples in the pictures can be reconstructed based on the selected CTU size. For example, one of the pictures can be partitioned into CTUs having the selected CTU size. Each of the CTUs can be further partitioned into CUs where inter predictions and/or intra prediction can be used to reconstruct the samples in the CUs. The process (<NUM>) proceeds to (S1399) and terminates.

Computer system (<NUM>) can also include an interface to one or more communication networks. Networks can for example be wireless, wireline, optical. Networks can further be local, wide-area, metropolitan, vehicular and industrial, real-time, delay-tolerant, and so on. Examples of networks include local area networks such as Ethernet, wireless LANs, cellular networks to include GSM, <NUM>, <NUM>, <NUM>, LTE and the like, TV wireline or wireless wide area digital networks to include cable TV, satellite TV, and terrestrial broadcast TV, vehicular and industrial to include CANBus, and so forth. Certain networks commonly require external network interface adapters that attached to certain general purpose data ports or peripheral buses (<NUM>) (such as, for example USB ports of the computer system (<NUM>)); others are commonly integrated into the core of the computer system (<NUM>) by attachment to a system bus as described below (for example Ethernet interface into a PC computer system or cellular network interface into a smartphone computer system). Using any of these networks, computer system (<NUM>) can communicate with other entities. Such communication can be uni-directional, receive only (for example, broadcast TV), uni-directional send-only (for example CANbus to certain CANbus devices), or bi-directional, for example to other computer systems using local or wide area digital networks. Certain protocols and protocol stacks can be used on each of those networks and network interfaces as described above.

Claim 1:
A method for video decoding in a decoder comprising:
receiving (S1310) coded information of pictures in a coded video sequence, the coded information including a coding tree unit, CTU, size information that indicates a CTU size selected for the pictures, the CTU size information being encoded using a truncated unary code and includes a bit string;
determining (S1320) the selected CTU size based on the CTU size information encoded using the truncated unary code; and
reconstructing (S1330) samples in the pictures based on the selected CTU size,
characterized in that
the determining (S1320) the selected CTU size comprises:
determining, based on the CTU size information encoded using the truncated unary code, a coded value from the bit string in the coded information, a maximum number of bits in the bit string being <NUM>, the coded value being <NUM>, <NUM>, and <NUM> when the bit string is <NUM>, <NUM>, and <NUM>, respectively; and
determining the selected CTU size based on the coded value, wherein
the determining (S1320) the selected CTU size comprises:
determining that the selected CTU size is <NUM>, <NUM>, and <NUM> in a case that the coded value is <NUM>, <NUM>, and <NUM>, respectively, wherein
the determining that the selected CTU size is <NUM>, <NUM>, and <NUM> comprises:
determining the selected CTU size to be <NUM>CtbLog2SizeY, a value of CtbLog2SizeY being a difference between <NUM> and the coded value.