Patent Description:
Various video coding techniques may be used to compress video data. Video coding is performed according to one or more video coding standards. For example, video coding standards include versatile video coding (VVC), joint exploration test model (JEM), high-efficiency video coding (H. <NUM>/HEVC), advanced video coding (H. <NUM>/AVC), moving picture expert group (MPEG) coding, or the like. Video coding generally utilizes prediction methods (e.g., inter-prediction, intra-prediction, or the like) that take advantage of redundancy present in video images or sequences. An important goal of video coding techniques is to compress video data into a form that uses a lower bit rate, while avoiding or minimizing degradations to video quality.

The first version of the HEVC standard was finalized in October <NUM>, which offers approximately <NUM>% bit-rate saving or equivalent perceptual quality compared to the prior generation video coding standard H. <NUM>/MPEG AVC. Although the HEVC standard provides significant coding improvements than its predecessor, there is evidence that superior coding efficiency can be achieved with additional coding tools over HEVC. Based on that, both VCEG and MPEG started the exploration work of new coding technologies for future video coding standardization. one Joint Video Exploration Team (JVET) was formed in Oct. <NUM> by ITU-T VECG and ISO/IEC MPEG to begin significant study of advanced technologies that could enable substantial enhancement of coding efficiency. One reference software called joint exploration model (JEM) was maintained by the JVET by integrating several additional coding tools on top of the HEVC test model (HM).

<NUM>, the joint call for proposals (CfP) on video compression with capability beyond HEVC was issued by ITU-T and ISO/IEC. <NUM>, <NUM> CfP responses were received and evaluated at the <NUM>-th JVET meeting, which demonstrated compression efficiency gain over the HEVC around <NUM>%. Based on such evaluation results, the JVET launched a new project to develop the new generation video coding standard that is named as Versatile Video Coding (VVC). In the same month, one reference software codebase, called VVC test model (VTM), was established for demonstrating a reference implementation of the VVC standard.

In general, this disclosure describes examples of techniques relating to lossless coding modes in video decoding.

According to a first aspect of the present disclosure, a method for video decoding is provided, comprising: determining whether a current block is in a lossless mode based on a first indication in the bitstream which indicates whether the current block is coded lossless and in response to determining that the current block is in the lossless mode, determining whether a first residual coding scheme or a second residual coding scheme is applied for the current block in the lossless mode further based on a second indication in the bitstream which indicates which residual coding scheme is used, wherein the first residual coding scheme is a residual coding scheme which is pre-defined for a non-transform skip block, and the second residual coding scheme is a residual coding scheme which is pre-defined for a transform-skip block.

According to a second aspect of the present disclosure, an apparatus for video decoding is provided, comprising: one or more processors and a memory configured to store instructions executable by the one or more processors wherein the one or more processors, upon execution of the instructions, are configured to: determine whether a current block is in a lossless mode based on a first indication in the bitstream which indicates whether the current block is coded lossless and in response to determining that the current block is in the lossless mode, determine whether a first residual coding scheme or a second residual coding scheme is applied for the current block in the lossless mode further based on a second indication in the bitstream which indicates which residual coding scheme is used, wherein the first residual coding scheme is a residual coding scheme which is pre-defined for a non-transform skip block, and the second residual coding scheme is a residual coding scheme which is pre-defined for a transform-skip block.

According to a third aspect of the present disclosure, a non-transitory computer readable storage medium storing a plurality of programs for execution by a computing device having one or more processors is provided, wherein the plurality of programs, when executed by the one or more processors, cause the computing device to perform the method for video decoding according to the first aspect to process a bitstream.

A more particular description of the examples of the present disclosure will be rendered by reference to specific examples illustrated in the appended drawings. Given that these drawings depict only some examples and are not therefore considered to be limiting in scope, the examples will be described and explained with additional specificity and details through the use of the accompanying drawings.

Reference will now be made in detail to specific implementations, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous non-limiting specific details are set forth in order to assist in understanding the subject matter presented herein. But it will be apparent to one of ordinary skill in the art that various alternatives may be used within the scope as defined by the claims. For example, it will be apparent to one of ordinary skill in the art that the subject matter presented herein may be implemented on many types of electronic devices with digital video capabilities.

In the following, embodiments and features not covered by the claims may be described in connection with the invention. These parts of the description serve to provide a better understanding of the invention. The scope of the invention is defined by the appendant claims.

Throughout the disclosure, the terms "first," "second," "third," etc. are all used as nomenclature only for references to relevant elements, e.g. devices, components, compositions, steps, etc., without implying any spatial or chronological orders, unless expressly specified otherwise. For example, a "first device" and a "second device" may refer to two separately formed devices, or two parts, components or operational states of a same device, and may be named arbitrarily.

As used herein, the term "if" or "when" may be understood to mean "upon" or "in response to" depending on the context. These terms, if appear in a claim, may not indicate that the relevant limitations or features are conditional or optional.

The terms "module," "sub-module," "circuit," "sub-circuit," "circuitry," "sub-circuitry," "unit," or "sub-unit" may include memory (shared, dedicated, or group) that stores code or instructions that may be executed by one or more processors. A module may include one or more circuits with or without stored code or instructions. The module or circuit may include one or more components that are directly or indirectly connected. These components may or may not be physically attached to, or located adjacent to, one another.

<FIG> shows a block diagram illustrating an exemplary block-based hybrid video encoder <NUM> which may be used in conjunction with many video coding standards using block-based processing. The VVC is built upon the block-based hybrid video coding framework. In the encoder <NUM>, the input video signal is processed block by block, which may be called coding units (CUs). In VTM-<NUM>, CU can be up to 128x128 pixels. However, different from the HEVC which partitions blocks only based on quad-trees, in the VVC, one coding tree unit (CTU) is split into CUs to adapt to varying local characteristics based on quad/binary/ternary-tree. By definition, coding tree block (CTB) is an NxN block of samples for some value of N such that the division of a component into CTBs is a partitioning. CTU includes a CTB of luma samples, two corresponding CTBs of chroma samples of a picture that has three sample arrays, or a CTB of samples of a monochrome picture or a picture that is coded using three separate colour planes and syntax structures used to code the samples. Additionally, the concept of multiple partition unit type in the HEVC is removed, i.e., the separation of CU, prediction unit (PU) and transform unit (TU) does not exist in the VVC anymore; instead, each CU is always used as the basic unit for both prediction and transform without further partitions.

In the multi-type tree structure, one CTU is firstly partitioned by a quad-tree structure. Then, each quad-tree leaf node can be further partitioned by a binary and ternary tree structure. As shown in <FIG>, there are five splitting types, quaternary partitioning (<FIG>), horizontal binary partitioning (<FIG>), vertical binary partitioning (<FIG>), horizontal ternary partitioning (<FIG>), and vertical ternary partitioning (<FIG>).

For each given video block, a prediction is formed based on either an inter prediction approach or an intra prediction approach. In inter prediction, one or more predictors are formed through motion estimation and motion compensation, based on pixels from previously reconstructed frames. In intra prediction, predictors are formed based on reconstructed pixels in a current frame. Through mode decision, a best predictor may be chosen to predict a current block.

A prediction residual, representing the difference between a current video block and its predictor, is sent to a Transform circuitry <NUM>. Transform coefficients are then sent from the Transform circuitry <NUM> to a Quantization circuitry <NUM> for entropy reduction. Quantized coefficients are then fed to an Entropy Coding circuitry <NUM> to generate a compressed video bitstream. As shown in <FIG>, prediction-related information <NUM> from an inter prediction circuitry and/or an Intra Prediction circuitry <NUM>, such as video block partition info, motion vectors, reference picture index, and intra prediction mode, are also fed through the Entropy Coding circuitry <NUM> and saved into a compressed video bitstream <NUM>.

In the encoder <NUM>, decoder-related circuitries are also needed in order to reconstruct pixels for the purpose of prediction. First, a prediction residual is reconstructed through an Inverse Quantization <NUM> and an Inverse Transform circuitry <NUM>. This reconstructed prediction residual is combined with a Block Predictor <NUM> to generate un-filtered reconstructed pixels for a current video block.

Spatial prediction (or "intra prediction") uses pixels from samples of already coded neighboring blocks (which are called reference samples) in the same video frame as the current video block to predict the current video block.

Temporal prediction (also referred to as "inter prediction") uses reconstructed pixels from already-coded video pictures to predict the current video block. Temporal prediction reduces temporal redundancy inherent in the video signal. Temporal prediction signal for a given coding unit (CU) or coding block is usually signaled by one or more motion vectors (MVs) which indicate the amount and the direction of motion between the current CU and its temporal reference. Further, if multiple reference pictures are supported, one reference picture index is additionally sent, which is used to identify from which reference picture in the reference picture store the temporal prediction signal comes.

After spatial and/or temporal prediction is performed, an intra/inter mode decision circuitry <NUM> in the encoder <NUM> chooses the best prediction mode, for example based on the rate-distortion optimization method. The block predictor <NUM> is then subtracted from the current video block; and the resulting prediction residual is de-correlated using the transform circuitry <NUM> and the quantization circuitry <NUM>. The resulting quantized residual coefficients are inverse quantized by the inverse quantization circuitry <NUM> and inverse transformed by the inverse transform circuitry <NUM> to form the reconstructed residual, which is then added back to the prediction block to form the reconstructed signal of the CU. Further in-loop filtering <NUM>, such as a deblocking filter, a sample adaptive offset (SAO), and/or an adaptive in-loop filter (ALF) may be applied on the reconstructed CU before it is put in the reference picture store of the picture buffer <NUM> and used to code future video blocks. To form the output video bitstream <NUM>, coding mode (inter or intra), prediction mode information, motion information, and quantized residual coefficients are all sent to the entropy coding unit <NUM> to be further compressed and packed to form the bit-stream.

For example, a deblocking filter is available in AVC, HEVC as well as the now-current version of VVC. In HEVC, an additional in-loop filter called SAO (sample adaptive offset) is defined to further improve coding efficiency. In the now-current version of the VVC standard, yet another in-loop filter called ALF (adaptive loop filter) is being actively investigated, and it has a good chance of being included in the final standard.

These in-loop filter operations are optional. Performing these operations helps to improve coding efficiency and visual quality. They may also be turned off as a decision rendered by the encoder <NUM> to save computational complexity.

It should be noted that intra prediction is usually based on unfiltered reconstructed pixels, while inter prediction is based on filtered reconstructed pixels if these filter options are turned on by the encoder <NUM>.

<FIG> is a block diagram illustrating an exemplary block-based video decoder <NUM> which may be used in conjunction with many video coding standards. This decoder <NUM> is similar to the reconstruction-related section residing in the encoder <NUM> of <FIG>. In the decoder <NUM>, an incoming video bitstream <NUM> is first decoded through an Entropy Decoding <NUM> to derive quantized coefficient levels and prediction-related information. The quantized coefficient levels are then processed through an Inverse Quantization <NUM> and an Inverse Transform <NUM> to obtain a reconstructed prediction residual. A block predictor mechanism, implemented in an Intra/inter Mode Selector <NUM>, is configured to perform either an Intra Prediction <NUM>, or a Motion Compensation <NUM>, based on decoded prediction information. A set of unfiltered reconstructed pixels are obtained by summing up the reconstructed prediction residual from the Inverse Transform <NUM> and a predictive output generated by the block predictor mechanism, using a summer <NUM>.

The reconstructed block may further go through an In-Loop Filter <NUM> before it is stored in a Picture Buffer <NUM> which functions as a reference picture store. The reconstructed video in the Picture Buffer <NUM> may be sent to drive a display device, as well as used to predict future video blocks. In situations where the In-Loop Filter <NUM> is turned on, a filtering operation is performed on these reconstructed pixels to derive a final reconstructed Video Output <NUM>.

In general, the basic intra prediction scheme applied in the VVC is kept the same as that of the HEVC, except that several modules are further extended and/or improved, e.g., intra sub-partition (ISP) coding mode, extended intra prediction with wide-angle intra directions, position-dependent intra prediction combination (PDPC) and <NUM>-tap intra interpolation.

In VVC, tile is defined as a rectangular region of CTUs within a particular tile column and a particular tile row in a picture. Tile group is a group of an integer number of tiles of a picture that are exclusively contained in a single NAL unit. Basically, the concept of tile group is the same as slice as defined in HEVC. For example, pictures are divided into tile groups and tiles.

A tile is a sequence of CTUs that cover a rectangular region of a picture. A tile group contains a number of tiles of a picture. Two modes of tile groups are supported, namely the raster-scan tile group mode and the rectangular tile group mode. In the raster-scan tile group mode, a tile group contains a sequence of tiles in tile raster scan of a picture. In the rectangular tile group mode, a tile group contains a number of tiles of a picture that collectively form a rectangular region of the picture. The tiles within a rectangular tile group are in the order of tile raster scan of the tile group.

<FIG> shows an example of raster-scan tile group partitioning of a picture, where the picture is divided into <NUM> tiles and <NUM> raster-scan tile groups.

<FIG> shows an example of rectangular tile group partitioning of a picture, where the picture is divided into <NUM> tiles (<NUM> tile columns and <NUM> tile rows) and <NUM> rectangular tile groups.

In VTM4, large block-size transforms, up to <NUM>×<NUM> in size, are enabled, which is primarily useful for higher resolution video, e.g., 1080p and <NUM> sequences. High frequency transform coefficients are zeroed out for the transform blocks with size (width or height, or both width and height) equal to <NUM>, so that only the lower-frequency coefficients are retained. For example, for an M×N transform block, with M as the block width and N as the block height, when M is equal to <NUM>, only the left <NUM> columns of transform coefficients are kept. Similarly, when N is equal to <NUM>, only the top <NUM> rows of transform coefficients are kept. When transform skip mode is used for a large block, the entire block is used without zeroing out any values.

Virtual pipeline data units (VPDUs) are defined as non-overlapping units in a picture. In hardware decoders, successive VPDUs are processed by multiple pipeline stages at the same time. The VPDU size is roughly proportional to the buffer size in most pipeline stages, so it is important to keep the VPDU size small. In most hardware decoders, the VPDU size can be set to maximum transform block (TB) size. However, in VVC, ternary tree (TT) and binary tree (BT) partition may lead to the increasing of VPDUs size.

In order to keep the VPDU size as 64x64 luma samples, the following normative partition restrictions (with syntax signaling modification) are applied in VTM5, as shown in <FIG>. For convenience, we label the examples in <FIG> from left to right for the upper examples, and <FIG> from left to right for the bottom examples.

Transform coefficient coding refers to the coding process of transform coefficient quantization level values of a TU. In HEVC, transform coefficients of a coding block are coded using non-overlapped coefficient groups (or subblocks), and each CG contains the coefficients of a 4x4 block of a coding block. The CGs inside a coding block, and the transform coefficients within a CG, are coded according to pre-defined scan orders. The coding of transform coefficient levels of a CG with at least one non-zero transform coefficient may be separated into multiple scan passes. In the first pass, the first bin (denoted by bin0, also referred as significant_coeff_flag, which indicates the magnitude of the coefficient is greater than <NUM>) is coded. Next, two scan passes for context coding the second/third bins (denoted by bin1 and bin2, respectively, also referred as coeff_abs_greater1_flag and coeff_abs_greater2_flag) may be applied. Finally, two more scan passes for coding the sign information and the remaining values (also referred as coeff_abs_level_remaining) of coefficient levels are invoked, if necessary. Note that only bins in the first three scan passes are coded in a regular mode and those bins are termed regular bins in the following descriptions.

In the VVC <NUM>, for each subblock, the regular coded bins and the bypass coded bins are separated in coding order; first all regular coded bins for a subblock are transmitted and, thereafter, the bypass coded bins are transmitted. The transform coefficient levels of a subblock are coded in four passes over the scan positions as follows:.

It is guaranteed that no more than <NUM> regular-coded bins (sig_flag, par_flag, gt1_flag and gt2_flag) are encoded or decoded for a 4x4 subblock. For 2x2 chroma subblocks, the number of regular-coded bins is limited to <NUM>.

The Rice parameter (ricePar) for coding the non-binary syntax element remainder (in Pass <NUM>) is derived similar to HEVC. At the start of each subblock, ricePar is set equal to <NUM>. After coding a syntax element remainder, the Rice parameter is modified according to predefined equation. For coding the non-binary syntax element absLevel (in Pass <NUM>), the sum of absolute values sumAbs in a local template is determined. The variables ricePar and posZero are determined based on dependent quantization and sumAbs by a table look-up. The intermediate variable codeValue is derived as follows:.

The value of codeValue is coded using a Golomb-Rice code with Rice parameter ricePar.

In the following description of the disclosure, transform coefficient coding is also referred as residual coding.

Decoder-side Motion Vector Refinement (DMVR) is a technique for blocks coded in bi-prediction Merge mode and controlled by SPS signaling sps_dmvr_enabled_flag flag. Under this mode, the two motion vectors (MV) of the block can be further refined using bilateral matching (BM) prediction.

<FIG> is a schematic diagram illustrating an example of decoder-side motion vector refinement (DMVR). As shown in the <FIG>, the bilateral matching method is used to refine motion information of a current CU <NUM> in current picture <NUM> by searching the closest match between its two reference blocks <NUM>, <NUM> along the motion trajectory of the current CU in its two associated reference pictures, i.e. refPic in List L0 <NUM> and refPic in List L1 <NUM>. The patterned rectangular blocks <NUM>, <NUM>, and <NUM>, indicate the current CU and its two reference blocks based on the initial motion information from Merge mode. The patterned rectangular blocks <NUM>, <NUM> indicate one pair of reference blocks based on a MV candidate used in the motion refinement search process, i.e. motion vector refinement process.

The MV differences between the MV candidate and the initial MV (also called original MV) are MVdiff and -MVdiff, respectively. The MV candidate and the initial MV are both bi-directional motion vectors. During DMVR, a number of such MV candidates around the initial MV may be checked. Specifically, for each given MV candidate, its two associated reference blocks may be located from its reference pictures in List <NUM> and List <NUM> respectively, and the difference between them is calculated. Such block difference is usually measured in SAD (or sum of absolute difference), or row-subsampled SAD (i.e. the SAD calculated with every other row of the block involved). At the end, the MV candidate with the lowest SAD between its two reference blocks becomes the refined MV and used to generate the bi-predicted signal as the actual prediction for the current CU.

In VVC, the DMVR is applied to a CU that satisfies the following conditions:.

The refined MV derived by DMVR process is used to generate the inter prediction samples and also used in temporal motion vector prediction for future picture coding. While the original MV is used in deblocking process and also in spatial motion vector prediction for future CU coding. Some additional features of DMVR are illustrated in the following sub-clauses.

The bi-directional optical flow (BDOF) tool is included in VTM5. BDOF, previously referred to as BIO, was included in the JEM. Compared to the JEM version, the BDOF in VTM5 is a simpler version that requires much less computation, especially in terms of number of multiplications and the size of the multiplier. BDOF is controlling by SPS sps_bdof_enabled _flag flag.

BDOF is used to refine the bi-prediction signal of a CU at the <NUM>×<NUM> sub-block level. BDOF is applied to a CU if it satisfies the following conditions: <NUM>) the CU's height is not <NUM>, and the CU is not in size of <NUM>×<NUM>, <NUM>) the CU is not coded using affine mode or the ATMVP merge mode; <NUM>) the CU is coded using "true" bi-prediction mode, i.e., one of the two reference pictures is prior to the current picture in display order and the other is after the current picture in display order. BDOF is only applied to the luma component.

As its name indicates, the BDOF mode is based on the optical flow concept, which assumes that the motion of an object is smooth. The BDOF adjusts the prediction sample by calculated the gradient of current block to improve the coding efficiency.

In current VVC, BDOF/DMVR are always applied if its SPS flag is enabled and some bi-prediction and size constrains are met for a regular merge candidate.

DMVR is applied to a regular merge mode when all the following conditions are true:.

BDOF is applied to bi-prediction when all the following conditions are true:.

VTM5 allows the transform skip mode to be used for luma blocks of size up to 32x32 (inclusive). When a CU is coded in transform skip mode, its prediction residual is quantized and coded using the transform skip residual coding process. This residual coding process is modified from the transform coefficient coding process described in the previous section. In transform skip mode, the residuals of a CU are also coded in units of non-overlapped subblocks of size 4x4. Different from the regular transform coefficient coding process, in transform skip mode, the last coefficient position is not signaled; instead, the coded_subblock_flag is signaled for all 4x4 subblocks in the CU in the forward scan order, i.e., from the top-left subblock to the last subblock.

For each subblock, if the coded_subblock_flag is equal to <NUM> (i.e., there is at least one non-zero quantized residual in the subblock), coding of the quantized residual levels is performed in three scan passes:.

The bins in scan passes #<NUM> and #<NUM> (the first scan pass and the greater than x scan pass) are context coded until the maximum number of context coded bins in the CU have been exhausted. The maximum number of context coded bins in a residual block is limited to <NUM>*block_width*block_height, or equivalently, <NUM> context coded bins per sample position on average. The bins in the last scan pass (the remainder scan pass) are bypass coded.

The lossless coding mode in HEVC is achieved by simply bypassing transform, quantization, and in-loop filters (de-blocking filter, sample adaptive offset, and adaptive loop filter). The design is aimed to enable the lossless coding with minimum changes required to the regular HEVC encoder and decoder implementation for mainstream applications.

In HEVC the lossless coding mode can be turned on or off at the individual CU level. This is done through a syntax cutransquant_bypass_flag signaled at CU level. In order to reduce signaling overhead where lossless coding mode is unnecessary, the cu_transquant_bypass _flag syntax is not always signaled. It is signaled only when another syntax called transquant_bypass_enabled_flag has a value of <NUM>. In other words, the syntax transquant_bypass_enabled_flag is used to turn on the syntax signaling of cu_transquant_bypass_flag.

In HEVC, the syntax _transquant_bypass_enabled_flag is signaled in the picture parameter set (PPS) to indicate whether the syntax cu_transquant_bypass_flag needs to be signaled for every CU inside a picture referring to the PPS. If this flag is set equal to <NUM>, the syntax cu_transquant_bypass _flag is sent at the CU level to signal whether the current CU is coded with the lossless mode or not. If this flag is set equal to <NUM> in the PPS, cu_transquant_bypass_flag is not sent, and all the CUs in the picture are encoded with transform, quantization, and loop filters involved in the process, which will generally result in a certain level of video quality degradation. To code an entire picture losslessly, one has to set the flag transquant_bypass_enabled_flag in the PPS to <NUM> and set the CU-level flag cu_transquant_bypass _flag equal to <NUM> for every CU in the picture. The detailed syntax signaling related to the lossless mode in HEVC is illustrated below.

In VVC, the maximum CU size is 64x64 and the VPDU is also set as 64x64. The maximum block size for coefficients coding in VVC is 32x32 because of the coefficient zero-out mechanism for width/height greater than <NUM>. Under this constraint, current transform skip only supports up to 32x32 CU so that the maximum block size for residual coding can be aligned with the maximum block size for coefficient coding which is 32x32. However, in VVC, the constraint for the block size of residual coding for a lossless CU is not defined. As a result, currently in VVC it is possible to generate a residual block under lossless coding mode with a size greater than 32x32, which would require the support of residual coding for blocks greater than 32x32. This is not preferred for the codec implementation. In this disclosure, several methods are proposed to address this issue.

Another issue associated with lossless coding support in VVC is how to choose the residual (or referred as coefficient) coding scheme. In the current VVC two different residual coding schemes are available. For a given block (or CU), the selection of residual coding scheme is based on the transform skip flag of a given block (or CU). Therefore, if under lossless mode the transform skip flag is assumed to be <NUM> in VVC as in HEVC, the residual coding scheme used under transform skip mode would be always used for a lossless mode CU. However, the current residual coding scheme used when the transform skip flag is true is designed mainly for screen content coding. It may not be optimal to be used for lossless coding of regular content (i.e. non-screen content). In this disclosure, several methods are proposed to select the residual coding for lossless CUs.

In current VVC, two decoder-side tools, i.e., BDOF and DMVR, refined decoded pixel by filtering current block therefore improving the coding performance. However, in lossless coding, since the prediction pixels are already perfectly predicted, the BDOF and DMVR do not contribute coding gain. Hence, the BDOF and DMVR should not be applied in lossless coding because theses decoder-side tools are not benefit for VVC. However, in current VVC, BDOF and DMVR are always applied if its SPS flag is enabled and some bi-prediction and size constrains are met for a regular merge candidate. Therefore, for lossless VVC coding, it is benefit for the performance efficiency of VVC lossless coding if controlling DMVR and BDOF in lower level, i.e., slice level and cu level.

According to an example of the disclosure, it is proposed to align the maximum residual coding block size for a lossless CU with the maximum block size supported by transform skip mode. In one example, the transform skip mode can only be enabled for a residual block whose width and height are both smaller than or equal to <NUM>, which means the maximum residual coding block size under transform skip mode is 32x32. According to the example, the maximum width and/or height of the residual block for a lossless CU is also set to be <NUM>, with a maximum residual block size as 32x32. Whenever the width/height of a lossless CU is greater than <NUM>, the CU residual block is divided into multiple smaller residual blocks with a size of 32xN and/or Nx32 so that the width or height of the smaller residual blocks are not greater than <NUM>. For example, a 128x32 lossless CU is divided into four 32x32 residual blocks for residual coding. In another example, a 64x64 lossless CU is divided into four 32x32 residual blocks.

According to another example of the disclosure, it is proposed to align the maximum block size for residual coding for a lossless CU with the size of VPDU. In one example, the width/height of maximum residual block for lossless CU is set to the VPDU size (e.g. 64x64 in current VVC). Whenever the width/height of a lossless CU is greater than <NUM>, the CU residual block is divided into multiple smaller residual blocks with a size of 64xN and/or Nx64 so that the width or height of the smaller residual blocks are not greater than VPDU width and/or height. For example, a 128x128 lossless CU is divided into four 64x64 residual blocks for residual coding. In another example, a 128x32 lossless CU is divided into two 64x32 residual blocks.

In current VVC, different residual coding schemes are utilized by a CU depending on if the CU is coded with the transform skip mode. The current residual coding used under transform skip mode is generally more suitable for screen content coding.

According to an example of the present disclosure, a lossless CU uses the same residual coding scheme as the one used by the transform skip mode CUs.

According to another example of the present disclosure, a lossless CU uses the same residual coding scheme as the one used by the non-transform skip mode CUs.

According to another example of the present disclosure, the residual coding scheme for lossless CUs is selected adaptively from the existing residual coding schemes based on certain conditions and/or predefined procedures. Such conditions and/or predefined procedures are followed by both the encoder and decoder, so that there is no signaling needed in the bitstream to indicate the selection. In one example, a simple screen content detection scheme may be specified and utilized in both encoder and decoder. Based on the detection scheme, a current video block may be classified as screen content or regular content. In case it is screen content, the residual coding scheme used under transform skip mode is selected. Otherwise, the other residual coding scheme is selected.

According to the invention, syntax is signaled in the bitstream to explicitly specify which residual coding scheme is used by a lossless CU. Such a syntax may be a binary flag, with each binary value indicating the selection of one of the two residual coding schemes. The syntax can be signaled at different levels. For example, it may be signaled in sequence parameter set (SPS), picture parameter set (PPS), slice header, tiles group header, or tile. It may also be signaled at CTU or CU level. When such a syntax is signaled, all the lossless CUs at the same or lower level would use the same residual coding scheme indicated by the syntax. For example, when the syntax is signaled at SPS level, all the lossless CUs in the sequence would use the same residual coding scheme indicated. When the syntax is signaled at PPS level, all the lossless CUs in a picture would use the same residual coding scheme indicated in the associated PPS. In case there is a syntax at CU level to indicate if a CU is coded in lossless mode, such as the cu_transquant_bypass_flag, the syntax indicating residual coding scheme is conditionally signaled based on the lossless mode flag of the CU. For example, only when the lossless mode flag cu_transquant_bypass _flag indicates that the current CU is coded in lossless mode, the syntax indicating residual coding scheme is signaled for the CU. When the syntax is signaled by a flag at slice header level, all the CUs coded in lossless mode within this slice would use the same residual coding scheme identified based on the signaled flag. The residual coding scheme for each one of the plurality of CUs is selected based on the signaled first flag, where the residual coding scheme selected for the lossless CU is the residual coding scheme used by transform skip mode CUs or the non-transform skip mode CUs depending on the signaled flag at the slice header.

According to an example of the present disclosure, even for a lossless mode coded CU, a transform skip mode flag is signaled. In this case, regardless s of a CU being coded in lossless mode or not, the selection of residual coding scheme for the CU is based on its transform skip mode flag.

In current VVC, the controlling of DMVR on/off is not defined for lossless coding mode. In an example of the disclosure, it is proposed to control turn on/off DMVR in slice level by a <NUM>-bit signaling slice_disable_dmvr_flag flag. In one example, the slice_disable_dmvr_flag flag is needed to be signaled if sps_dmvr_enabled_flag is set equal to <NUM> and transquant_bypass_enabled_flag flag is set equal to <NUM>. If slice_disable_dmvr_flag flag is not signaled, it is inferred to be <NUM>. If slice_disable_dmvr_flag is equal to <NUM>, DMVR is turned off. In this case, the signaling is as followed:.

In another example, it is proposed to control turn on/off DMVR in cu level by cu_transquant_bypass_flag. In one example, the cu level controlling for DMVR is followed:
DMVR is applied to a regular merge mode when all the following conditions are true:.

In current VVC, the controlling of BDOF on/off is not defined for lossless coding mode. In an example of the present disclosure, it is proposed to control turn on/off BDOF by a <NUM>-bit signaling slice_disable_bdof_flag flag. In one example, the slice_disable_bdof_flag flag is signaled if sps_bdof_enabled_flag is set equal to <NUM> or transquant_bypass_enabled_flag flag is set equal to <NUM>. If slice_disable_bdof_flag flag is not signaled, it is inferred to be <NUM>. If slice_disable_bdof_flag flag is equal to <NUM>, BDOF is disable. In this case, the signaling is illustrated as follows:.

In another example of the present disclosure, it is proposed to control turn on/off BDOF in cu level by cu_transquant_bypass_flag. In one example, the cu level controlling for BDOF is followed:
BDOF is applied to a regular merge mode when all the following conditions are true:.

In current VVC, both of BDOF and DMVR are always applied for decoder-side refinement to improve coding efficiency and controlled by each SPS flag and condition of some bi-prediction and size constrains are met for a regular merge candidate. In an example of the present disclosure, it is proposed to disable both BDOF and DMVR by a <NUM>-bit slice_disable_bdof_dmvr_flag slice flag. If the slice_disable_bdof_dmvr_flag flag is set equal to <NUM>, both BDOF and DMVR are turned off. If slice_disable_bdof_dmvr_flag flag is not signaled, it is inferred to be <NUM>. In one example, slice_disable_bdof_dmvr_flag is signaled if following condition is met.

The above methods may be implemented using an apparatus that includes one or more circuitries, which include application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, micro-controllers, microprocessors, or other electronic components. The apparatus may use the circuitries in combination with the other hardware or software components for performing the above described methods. Each module, sub-module, unit, or sub-unit disclosed above may be implemented at least partially using the one or more circuitries.

<FIG> is a block diagram illustrating an apparatus for video coding in accordance with some implementations of the present disclosure. The apparatus <NUM> may be a terminal, such as a mobile phone, a tablet computer, a digital broadcast terminal, a tablet device, or a personal digital assistant.

As shown in <FIG>, the apparatus <NUM> may include one or more of the following components: a processing component <NUM>, a memory <NUM>, a power supply component <NUM>, a multimedia component <NUM>, an audio component <NUM>, an input/output (I/O) interface <NUM>, a sensor component <NUM>, and a communication component <NUM>.

The processing component <NUM> usually controls overall operations of the apparatus <NUM>, such as operations relating to display, a telephone call, data communication, a camera operation and a recording operation. The processing component <NUM> may include one or more processors <NUM> for executing instructions to complete all or a part of steps of the above method. Further, the processing component <NUM> may include one or more modules to facilitate interaction between the processing component <NUM> and other components. For example, the processing component <NUM> may include a multimedia module to facilitate the interaction between the multimedia component <NUM> and the processing component <NUM>.

The memory <NUM> is configured to store different types of data to support operations of the apparatus <NUM>. Examples of such data include instructions, contact data, phonebook data, messages, pictures, videos, and so on for any application or method that operates on the apparatus <NUM>. The memory <NUM> may be implemented by any type of volatile or non-volatile storage devices or a combination thereof, and the memory <NUM> may be a Static Random Access Memory (SRAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), an Erasable Programmable Read-Only Memory (EPROM), a Programmable Read-Only Memory (PROM), a Read-Only Memory (ROM), a magnetic memory, a flash memory, a magnetic disk or a compact disk.

The multimedia component <NUM> includes a screen providing an output interface between the apparatus <NUM> and a user. In some examples, the screen may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen receiving an input signal from a user. The touch panel may include one or more touch sensors for sensing a touch, a slide and a gesture on the touch panel. The touch sensor may not only sense a boundary of a touching or sliding actions, but also detect duration and pressure related to the touching or sliding operation. In some examples, the multimedia component <NUM> may include a front camera and/or a rear camera. When the apparatus <NUM> is in an operation mode, such as a shooting mode or a video mode, the front camera and/or the rear camera may receive external multimedia data.

The audio component <NUM> is configured to output and/or input an audio signal. For example, the audio component <NUM> includes a microphone (MIC). When the apparatus <NUM> is in an operating mode, such as a call mode, a recording mode and a voice recognition mode, the microphone is configured to receive an external audio signal. The received audio signal may be further stored in the memory <NUM> or sent via the communication component <NUM>. In some examples, the audio component <NUM> further includes a speaker for outputting an audio signal.

The I/O interface <NUM> provides an interface between the processing component <NUM> and a peripheral interface module. The above peripheral interface module may be a keyboard, a click wheel, a button, or the like. These buttons may include but not limited to, a home button, a volume button, a start button and a lock button.

The sensor component <NUM> includes one or more sensors for providing a state assessment in different aspects for the apparatus <NUM>. For example, the sensor component <NUM> may detect an on/off state of the apparatus <NUM> and relative locations of components. For example, the components are a display and a keypad of the apparatus <NUM>. The sensor component <NUM> may also detect a position change of the apparatus <NUM> or a component of the apparatus <NUM>, presence or absence of a contact of a user on the apparatus <NUM>, an orientation or acceleration/deceleration of the apparatus <NUM>, and a temperature change of apparatus <NUM>. The sensor component <NUM> may include a proximity sensor configured to detect presence of a nearby object without any physical touch. The sensor component <NUM> may further include an optical sensor, such as a CMOS or CCD image sensor used in an imaging application. In some examples, the sensor component <NUM> may further include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

The communication component <NUM> is configured to facilitate wired or wireless communication between the apparatus <NUM> and other devices. The apparatus <NUM> may access a wireless network based on a communication standard, such as WiFi, <NUM>, or a combination thereof. In an example, the communication component <NUM> receives a broadcast signal or broadcast related information from an external broadcast management system via a broadcast channel. In an example, the communication component <NUM> may further include a Near Field Communication (NFC) module for promoting short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID) technology, infrared data association (IrDA) technology, Ultra-Wide Band (UWB) technology, Bluetooth (BT) technology and other technology.

In an example, the apparatus <NUM> may be implemented by one or more of Application Specific Integrated Circuits (ASIC), Digital Signal Processors (DSP), Digital Signal Processing Devices (DSPD), Programmable Logic Devices (PLD), Field Programmable Gate Arrays (FPGA), controllers, microcontrollers, microprocessors or other electronic elements to perform the above method.

A non-transitory computer readable storage medium may be, for example, a Hard Disk Drive (HDD), a Solid-State Drive (SSD), Flash memory, a Hybrid Drive or Solid-State Hybrid Drive (SSHD), a Read-Only Memory (ROM), a Compact Disc Read-Only Memory (CD-ROM), a magnetic tape, a floppy disk and etc..

<FIG> is a flowchart illustrating an exemplary process of techniques relating to lossless coding modes in video coding in accordance with some implementations of the present disclosure.

In step <NUM>, the processor <NUM> partitions a video picture into a plurality of coding units (CUs), at least one of which is a lossless CU.

In step <NUM>, the processor <NUM> determines a residual coding block size of the lossless CU.

In step <NUM>, the processor <NUM> splits the residual coding block into two or more residual blocks for residual coding, in response to determining that the residual coding block size of the lossless CU is greater than a predefined maximum value.

In some examples, there is provided an apparatus for video coding. The apparatus includes a processor <NUM>; and a memory <NUM> configured to store instructions executable by the processor; where the processor, upon execution of the instructions, is configured to perform a method as illustrated in <FIG>.

In some other examples, there is provided a non-transitory computer readable storage medium <NUM>, having instructions stored therein. When the instructions are executed by a processor <NUM>, the instructions cause the processor to perform a method as illustrated in <FIG>.

In step <NUM>, the processor <NUM> selects a residual coding scheme for the lossless CU, wherein the residual coding scheme selected for the lossless CU is same as the residual coding scheme used by non-transform skip mode CUs.

The description of the present disclosure has been presented for purposes of illustration, and is not intended to be exhaustive or limited to the present disclosure. Many modifications, variations, and alternative implementations will be apparent to those of ordinary skill in the art having the benefit of the teachings presented in the foregoing descriptions and the associated drawings.

Claim 1:
A method for video decoding, comprising:
determining whether a current block is in a lossless mode based on a first indication in the bitstream which indicates whether the current block is coded lossless; characterized by
in response to determining that the current block is in the lossless mode, determining whether a first residual coding scheme or a second residual coding scheme is applied for the current block in the lossless mode further based on a second indication in the bitstream which indicates which residual coding scheme is used;
wherein the first residual coding scheme is a residual coding scheme which is pre-defined for a non-transform skip block, and the second residual coding scheme is a residual coding scheme which is pre-defined for a transform-skip block.