Sequence-level and slice-level syntax representation in video codecs

Abstract

The video includes a sequence of images, each of the images including one or more slices. Parsing a bitstream to obtain a value of a first flag. Determining whether the value of the first flag indicates a header extension parameter set is present. In response to the value of the first flag indicating the presence of the header extension parameter set, parsing the bitstream to obtain a value of a second flag. Determining whether the value of the second flag indicates a first parameter in the header extension parameter set is enabled for the sequence. In response to the value of the second flag indicating the first parameter is enabled, parsing the bitstream to obtain a value of the first parameter used for one of the slices in the sequence. Decoding the slice based on the value of the first parameter.

Description

[Technical field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims priority to U.S. provisional application number 63 / 219,173, filed on July 7, 2021, entitled "REPRESENTATION OF SEVERAL SPS AND SLICE RELATED SYNTAX ELEMENTS FOR VIDEO CODING," the entire contents of which are incorporated herein by reference.

[0002] An embodiment of the present invention relates to a video codec. [Background technology]

[0003] Digital video has become mainstream and is widely used in applications such as digital television, video telephony, and teleconferencing. Such digital video applications are possible due to advances in computing and communication technology and efficient video codec technology. Various video codec technologies can be used to compress video data, which allows the coding of the video data in one or more video codec standards. Examples of video codec standards include, but are not limited to, General Purpose Video Codec (H.266 / VVC), High Efficiency Video Codec (H.265 / HEVC), Advanced Video Codec (H.264 / AVC), Moving Picture Expert Group (MPEG) codecs, etc. Summary of the Invention

[0004] According to one aspect of the present invention, a method for decoding a video is disclosed. The video includes a sequence of images, each of the images includes one or more slices. A processor parses a bitstream to obtain a value of a first flag. The processor determines whether a value of the first flag indicates that a header extension parameter set is present. In response to the value of the first flag indicating that the header extension parameter set is present, the processor parses the bitstream to obtain a value of a second flag. The processor determines whether a value of the second flag indicates that the first parameter in the header extension parameter set is enabled for the sequence of images. In response to the value of the second flag indicating that the first parameter is enabled for the sequence of images, the processor parses the bitstream to obtain a value of the first parameter used for one of the slices in the sequence of images. The processor decodes the slice based on the value of the first parameter used for the slice.

[0005] According to another aspect of the invention, a video decoding system comprises a memory configured to store instructions and a processor coupled to the memory, the video including a sequence of images, each of the images including one or more slices. The processor is configured to parse a bitstream to obtain a value of a first flag when executing the instructions. The processor is further configured to determine, when executing the instructions, whether a value of the first flag indicates a presence of a header extension parameter set, and parse the bitstream to obtain a value of a second flag in response to the value of the first flag indicating the presence of the header extension parameter set. The processor is further configured to determine, when executing the instructions, whether a value of the second flag indicates that the first parameter in the header extension parameter set is enabled for the sequence of images, and parse the bitstream to obtain a value of the first parameter used for one of the slices in the sequence of images in response to the value of the second flag indicating the first parameter is enabled for the sequence of images. The processor is further configured to decode the slice based on the value of the first parameter used for the slice when executing the instructions.

[0006] According to yet another aspect of the present invention, a method for encoding a video is disclosed. The video includes a sequence of images, each of the images including one or more slices. A processor determines a value of a first parameter in a header extension parameter set for at least one of the slices in the sequence of images. The processor determines a value of a first flag indicating whether the header extension parameter set is present or not based on the value of the first parameter. The processor determines a value of a second flag indicating whether the first parameter is enabled or not for the sequence of images based on the value of the first parameter. The processor encodes the at least one slice into a bitstream based on the value of the first parameter. The processor encodes the value of the first flag, the value of the second flag, and the value of the first parameter into the bitstream.

[0007] According to yet another aspect of the present invention, a video encoding system comprises a memory configured to store instructions and a processor coupled to the memory. The video includes a sequence of images, each of the images including one or more slices. The processor is configured to determine, when executing the instructions, a value of a first parameter in a header extension parameter set for at least one of the slices in the sequence of images. The processor is further configured to determine, when executing the instructions, a value of a first flag indicating whether the header extension parameter set is present based on the value of the first parameter. The processor is further configured to determine, when executing the instructions, a value of a second flag indicating whether the first parameter is enabled for the sequence of images based on the value of the first parameter. The processor is further configured to encode, when executing the instructions, the at least one slice into a bitstream based on the value of the first parameter, and encode the value of the first flag, the value of the second flag, and the value of the first parameter into the bitstream.

[0008] These illustrative examples are not intended to limit or define the invention, but are intended to provide examples to facilitate understanding. Additional examples are described in detail in the specification and further description is provided below. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 is a block diagram of an example encoding system according to some embodiments of the present invention. [Diagram 2] 1 is a block diagram of an example decoding system according to some embodiments of the present invention. [Diagram 3] 2 is a detailed block diagram of an example encoder in the encoding system of FIG. 1, in accordance with some embodiments of the present invention. [Figure 4] 3 is a detailed block diagram of an example decoder in the decoding system of FIG. 2, in accordance with some embodiments of the present invention. [Figure 5A] 2 illustrates an example of a video segmented into a sequence of images according to some embodiments of the present invention. [Figure 5B] 2 illustrates an example of an image divided into slices according to some embodiments of the present invention. [Figure 5C] 1 illustrates an example of a slice divided into coding tree units (CTUs) according to some embodiments of the present invention. [Figure 5D] 2 illustrates an example of a CTU split into coding units (CUs) according to some embodiments of the present invention. [Figure 6] 2 illustrates an example of a transform block coded using regular residual coding (RRC) in accordance with some embodiments of the present invention. [Figure 7] 1 shows the coding path in RRC. [Figure 8A] 4 illustrates an exemplary high throughput mode in RRC, according to some embodiments of the present invention. [Figure 8B]4 illustrates another exemplary high throughput mode in RRC, according to some embodiments of the present invention. [Figure 8C] 1 illustrates yet another exemplary high throughput mode for transform unit (TU) coding, according to some embodiments of the present invention. [Figure 8D] 1 illustrates an exemplary high throughput mode for TU encoding, according to some embodiments of the present invention. [Figure 9] 4 illustrates a flowchart of an exemplary video decoding method according to some embodiments of the present invention. [Figure 10] 1 illustrates a flowchart of an exemplary video encoding method according to some embodiments of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] The drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and, together with the description, serve to further explain the principles of the invention, thereby enabling those skilled in the art to make and use the invention.

[0011] An embodiment of the present invention will be described with reference to the drawings.

[0012] While certain configurations and arrangements are described, it should be understood that this is done for illustrative purposes only. Those skilled in the art will recognize that other configurations and arrangements can be used without departing from the spirit and scope of the invention. Clearly, those skilled in the art will recognize that the present invention can be used in a variety of other applications.

[0013] In this specification, the terms "one embodiment," "one embodiment," "exemplary embodiment," "some embodiments," "particular embodiment," and the like indicate that the described embodiment may include a particular feature, structure, or characteristic, but not all embodiments necessarily include the particular feature, structure, or characteristic. Furthermore, such terms do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with an embodiment, such feature, structure, or characteristic may be realized by combining it with other embodiments within the knowledge of a person skilled in the art, regardless of whether it is explicitly described.

[0014] Generally, terms can be understood, at least in part, from their use in context. For example, the term "one or more" as used herein may be used in a singular sense to describe any feature, structure, or characteristic, or in a plural sense to describe a combination of features, structures, or characteristics, depending at least in part on the context. Similarly, terms such as "a," "one," or "said" may also be understood to convey singular or plural usage, depending at least in part on the context. Additionally, the term "based on" is not necessarily intended to convey an exclusive set of factors, but instead may permit the presence of additional factors, not necessarily explicitly stated, depending at least in part on the context.

[0015] Various aspects of the video codec system will now be described with reference to various apparatus and methods. These apparatus and methods are described in the detailed description which follows and are illustrated by various modules, components, circuits, steps, operations, processes, algorithms, etc. (collectively referred to as "elements"). These elements may be implemented using electronic hardware, firmware, computer software, or any combination thereof. Whether such elements are implemented as hardware, firmware, or software depends upon the particular application and design constraints imposed on the overall system.

[0016] The techniques described herein may be used for various video codec applications. As described herein, video codec includes video encoding and decoding. Video encoding and decoding may be performed on a block-by-block basis. For example, encoding / decoding processes such as transform, quantization, prediction, in-loop filtering, reconstruction, etc. may be performed on a coding block, a transform block, or a prediction block. As described herein, a block to be coded / decoded is referred to as a "current block." For example, depending on the current coding / decoding process, the current block may represent a codec block, a transform block, or a prediction block. Furthermore, it should be understood that the term "unit" in the present invention refers to a basic unit for performing a particular coding / decoding process, and the term "block" refers to a sample array of a predetermined size. Unless otherwise specified, "block" and "unit" may be used interchangeably.

[0017] In video coding, quantization is used to reduce the dynamic range of a transformed or untransformed video signal, so that the video signal can be represented with fewer bits. Before quantization, the transformed or untransformed video signal at a particular position is called a "coefficient". After quantization, the quantized value of the coefficient is called a "quantization level" or a "level". In the present invention, the quantization level of a position refers to the quantization level of the coefficient at that position. In video coding, residual coding is used to code the quantization level of the position into a bitstream. After quantization, there are N×M quantization levels for an N×M sized coding block. These N×M quantization levels may be zero or non-zero values. If the non-zero levels are not binary, a binarization method is used to further convert (e.g., binarize) the non-zero levels into a binary representation (such as binary bins). Then, a coding algorithm (such as an entropy coding algorithm) is used to compress the binary representation (such as binary bins) into a bitstream. Examples of binarization methods include, but are not limited to, Golomb-Rice binarization, such as combined Truncated Rice (TR) binarization, limited k-th order Exp-Golomb (EGk) binarization, and k-th order Exp-Golomb binarization. Examples of entropy coding algorithms include, but are not limited to, variable-length coding (VLC) schemes, context-adaptive VLC schemes (CAVLC), arithmetic coding schemes, binarization, context adaptive binary arithmetic coding (CABAC), syntax-based context-adaptive binary arithmetic coding (SBAC), probability interval partitioning entropy (PIPE) coding, or other entropy coding techniques.

[0018] In addition to the representation of the levels (or possibly coefficients), representations of other information (such as syntax elements) used for video coding may also be coded / written into the bitstream. Since video coding is structured at different levels by splitting the video into different pieces (sequences, pictures, slices, etc.), the representations of syntax elements are also located at different levels (sequence level, picture level, slice level, etc.), e.g., as corresponding header information. Furthermore, parsing some syntax elements in video coding may require multiple condition checks, which further increases the complexity of organizing and parsing the representations of syntax elements.

[0019] The present invention provides various ways to improve the efficiency and reduce the complexity of organizing and parsing the representation of syntax elements in video coding. According to some aspects of the present invention, various syntax elements at different levels (e.g., sequence level flags and slice level flags) may be used in combination with corresponding condition checks at different levels to organize and parse certain optional parameters (such as header extension parameters) in a simplified and efficient manner. In some embodiments, the flag indicates the presence of a header extension parameter set. The header extension parameters may include various parameters that may be associated with some sequences of images but not with other sequences of images. In some embodiments, if such a header extension parameter set exists, a sequence level flag is used for each parameter in the header extension parameter set to indicate whether the corresponding parameter is enabled for a particular sequence of images in the video. In some embodiments, if the parameter is enabled at the sequence level, a slice level syntax element is used for each parameter to indicate the value of the parameter for encoding / decoding a particular slice in the sequence of images.

[0020] According to some aspects of the invention, expressions of different syntax elements having the same condition checks at the same level may be grouped to reduce the number of condition checks, thereby further simplifying the solution.

[0021] FIG. 1 is a block diagram of an exemplary encoding system 100 according to some embodiments of the present invention. FIG. 2 is a block diagram of an exemplary decoding system 200 according to some embodiments of the present invention. Each of the systems 100 or 200 can be applied to or integrated into various systems and devices capable of data processing, such as computers and wireless communication devices. For example, the system 100 or 200 can be a whole or part of a mobile phone, a desktop computer, a laptop computer, a tablet, a vehicle computer, a gaming console, a printer, a positioning device, a wearable electronic device, a smart sensor, a virtual reality (VR) device, an augmented reality (AR) device, or any other suitable electronic device having data processing capabilities. As shown in FIG. 1 and FIG. 2, the system 100 or 200 can include a processor 102, a memory 104, and an interface 106. Although these components are shown as being connected to each other by a bus, other connection types are also permissible. It should be noted that the system 100 or 200 can include any other suitable components for performing the functions described herein.

[0022] The processor 102 may include a microprocessor such as a graphic processing unit (GPU), image signal processor (ISP), central processing unit (CPU), digital signal processor (DSP), tensor processing unit (TPU), vision processing unit (VPU), neural processing unit (NPU), synergistic processing unit (SPU), or physics processing unit (PPU), a microcontroller unit (MCU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a programmable logic device (PLD), a state machine, gated logic, discrete hardware circuitry, and other suitable hardware configured to perform various functions described throughout the present invention. Although only one processor is shown in FIG. 1 and FIG. 2, it can be understood that multiple processors may be included. The processor 102 may be a hardware device having one or more processing cores. The processor 102 may execute software. Software should generally be construed broadly to refer to instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. Software may include computer instructions written in an interpreted language, a compiled language, or machine code. Other techniques for instructing hardware are also included within the broad category of software.

[0023] The memory 104 may broadly include memory (also referred to as primary / system memory) and storage (also referred to as secondary memory). For example, the memory 104 may include random access memory (RAM), read only memory (ROM), static RAM (SRAM), dynamic RAM (DRAM), ferroelectric RAM (FRAM), electrically erasable programmable ROM (EEPROM), compact disk read only memory (CD-ROM) or other optical disk storage, hard disk drive (HDD), e.g., magnetic disk storage or other magnetic storage, flash drive, solid-state drive (SSD), or any other medium that can be used to carry or store desired program code in the form of instructions that can be accessed and executed by the processor 102. In the broadest sense, the memory 104 may be embodied by any computer-readable medium, such as a non-transitory computer-readable medium. Although only one memory is shown in FIG. 1 and FIG. 2, it can be understood that multiple memories may be included.

[0024] The interface 106 may broadly include a data interface and a communication interface configured to receive and transmit signals in the process of transmitting and receiving information to and from other external network elements. For example, the interface 106 may include an input / output (I / O) device, a wired or wireless transceiver. Although only one interface is shown in Figures 1 and 2, it is understood that multiple interfaces may be included.

[0025] The processor 102, memory 104, and interface 106 may be implemented in various forms in the system 100 or system 200 to perform the video encoding functions. In some embodiments, the processor 102, memory 104, and interface 106 of the system 100 or system 200 are implemented (e.g., integrated) on one or more system-on-chip (SoC). In one example, the processor 102, memory 104, and interface 106 may be integrated into an application processor (AP) SoC that handles application processing, including execution of video encoding and decoding applications in an operating system (OS) environment. In another example, the processor 102, memory 104, and interface 106 may be integrated into a processor chip dedicated to video codecs, such as a GPU or ISP chip dedicated to image and video processing in a real-time operating system (RTOS).

[0026] As shown in FIG. 1, in the encoding system 100, the processor 102 may include one or more modules, such as the encoder 101. Although FIG. 1 shows the encoder 101 in one processor 102, it can be understood that the encoder 101 may include one or more sub-modules, which may be implemented in different processors located close to or remote from each other. The encoder 101 (and any corresponding sub-modules or sub-units) may be a hardware unit (e.g., part of an integrated circuit) of the processor 102, which is designed to be used with other components or software units that the processor 102 implements by executing at least a portion (i.e., instructions) of a program. The instructions of the program may be stored in a computer-readable medium, such as the memory 104, and when executed by the processor 102, the instructions may perform a process having one or more functions related to video encoding, such as image division, inter-prediction, intra-prediction, transformation, quantization, filtering, entropy coding, etc., as described in more detail below.

[0027] Similarly, as shown in FIG. 2, in the decoding system 200, the processor 102 may include one or more modules, such as a decoder 201. Although FIG. 2 shows the decoder 201 in one processor 102, it can be understood that the decoder 201 may include one or more sub-modules, which may be implemented in different processors located close to or remote from each other. The decoder 201 (and any corresponding sub-modules or sub-units) may be a hardware unit (e.g., part of an integrated circuit) of the processor 102, which is designed to be used with other components or software units that the processor 102 implements by executing at least a portion (i.e., instructions) of a program. The instructions of the program may be stored in a computer-readable medium, such as the memory 104, and when executed by the processor 102, the instructions may perform a process having one or more functions related to video decoding, such as entropy decoding, inverse quantization, inverse transform, inter prediction, intra prediction, transform, quantization, filtering, etc., as described in more detail below.

[0028] FIG. 3 is a detailed block diagram of an exemplary encoder 101 in the encoding system 100 of FIG. 1 according to some embodiments of the present invention. As shown in FIG. 3, the encoder 101 includes a partition module 302, an inter prediction module 304, an intra prediction module 306, a transform module 308, a quantization module 310, an inverse quantization module 312, an inverse transform module 314, a filter module 316, a buffer module 318, and an encoding module 320. Note that each element shown in FIG. 3 is shown independently to represent different characteristic functions in a video encoder, but this does not mean that each component is formed by a separate hardware or a single software unit. That is, each included element is listed as a single element for convenience of explanation, and at least two elements may be combined to form a single element, or one element may be divided into multiple elements to perform a function. Also, some elements may not be necessary to perform the functions described in the present invention, but may be optional elements for improving performance. Furthermore, these elements may be implemented using electronic hardware, firmware, computer software, or any combination thereof. Whether such elements are implemented as hardware, firmware, or software depends on the particular application and design constraints imposed on the encoder 101 .

[0029] The partitioning module 302 may be configured to partition an input image of a video into at least one processing unit. The image may be a frame of a video, or a field of a video. As shown in FIG. 5A-5D, the video is partitioned into pieces of different levels for use in a video codec. For example, in FIG. 5A, a video 500 may be partitioned into one or more sequences 502, and each sequence 502 may include one or more images 504. In some implementations, the image 504 includes an array of luma samples in monochrome format, or an array of one luma sample and two corresponding chroma samples. In this case, the processing unit may be a prediction unit (PU), a transform unit (TU), or a CU. The partitioning module 302 may partition an image into multiple combinations of coding units, prediction units, and transform units, and encode the image by selecting a combination of the coding units, prediction units, and transform units based on a predetermined criterion (e.g., a cost function).

[0030] In some embodiments, the image 504 is divided by the segmentation module 302 into one or more slices 506, as shown in FIG. 5B. Note that the shape of the slices 506 and the number of slices 506 in each image 504 may vary in different examples. According to some embodiments, each slice 506 may be the same size as its root image 504 or may be a subdivision of the root image 504.

[0031] Similar to H.265 / HEVC, H.266 / VVC is a block-based hybrid temporal and spatial prediction codec scheme. As shown in FIG. 5C, during encoding, a slice 506 may be further divided by the partitioning module 302 into square blocks CTUs 508. For example, the CTUs 508 may be blocks of 128×128 pixels. In other words, a slice 506 may include multiple CTUs 508. As shown in FIG. 5D, each CTU 508 may be further divided by the partitioning module 302 into one or more CUs 510 for prediction and transformation. Unlike H.265 / HEVC, in H.266 / VVC, the CUs 510 may be rectangular or square and may be coded without further division into prediction units or transform units. For example, as shown in FIG. 5D, the division of the CTUs 508 into CUs 510 may include quad-tree partitioning (shown by solid lines), binary tree partitioning (shown by dashed lines), and ternary tree partitioning (shown by dashed lines). According to some embodiments, each CU 510 may be the same size as its root CTU 508 or may be a subdivision as small as 4x4 blocks of the root CTU 508. As described in more detail below, by dividing the video 500 into multiple pieces at different levels (such as sequences 502, pictures 504, slices 506, CTUs 508, CUs 510, etc.), syntax elements at different levels can be used when encoding the video 500, improving the flexibility and efficiency of the video encoding.

[0032] Referring to FIG. 3, the inter prediction module 304 may be configured to perform inter prediction on the prediction unit, and the intra prediction module 306 may be configured to perform intra prediction on the prediction unit. It may be determined whether to perform inter prediction or intra prediction on the prediction unit, and specific information (e.g., intra prediction mode, motion vector, reference image, etc.) may be determined based on each prediction method. In this case, the processing unit for performing prediction may be different from the processing unit for determining the prediction method and the specific content. For example, the prediction unit may determine the prediction method and prediction mode, and the transformation unit may perform the prediction. Residual coefficients in the residual block between the generated prediction block and the original block may be input to the transformation module 308. Furthermore, the encoding module 320 may encode prediction mode information, motion vector information, etc. used for prediction, together with the residual coefficients or quantization level, into the bitstream. Note that, in a certain encoding mode, the original block may be encoded as it is without generating a prediction block via the prediction module 304 or the prediction module 306. Furthermore, in a certain encoding mode, prediction, transformation, and / or quantization may be skipped.

[0033] In some implementations, the inter prediction module 304 may predict the prediction unit based on information of at least one image before and after the current image, and in some cases, may predict the prediction unit based on information about a coded portion of the current image. The inter prediction module 304 may include sub-modules such as a reference image interpolation module, a motion prediction module, and a motion compensation module (not shown). For example, the reference image interpolation module may receive reference image information from the buffer module 318 and generate pixel information of integer pixels or less pixels from the reference image. For luma pixels, a discrete cosine transform (DCT)-based 8-tap interpolation filter with variable filter coefficients may generate pixel information of integer pixels or less pixels in units of 1 / 4 pixels. For chrominance signals, a DCT-based 4-tap interpolation filter with variable filter coefficients may generate pixel information of integer pixels or less pixels in units of 1 / 8 pixels. The motion prediction module may perform motion prediction based on a reference image interpolated by a reference image interpolator. The motion vector calculation method can be various methods such as full search-based block matching algorithm (FBMA), three-step search (TSS), new three-step search algorithm (NTS), etc. The motion vector can have a motion vector value in half pixel, quarter pixel or sixteenth pixel unit, or an integer pixel unit based on an interpolated pixel. The motion prediction module can predict the current prediction unit by changing the motion prediction method. The motion prediction method can be various methods such as skip method, merge method, Advanced Motion Vector Prediction (AMVP) method, intra-block copy method, etc.

[0034] In some embodiments, the intra prediction module 306 may generate a prediction unit based on information of reference pixels around the current block, which may be pixel information in the current image. If a neighboring block of the current prediction unit is a block on which inter prediction has been performed and the reference pixel is a pixel on which inter prediction has been performed, the reference pixel in the block on which inter prediction has been performed may be used instead of the reference pixel information of the neighboring block on which intra prediction has been performed. That is, if the reference pixel is unavailable, at least one of the available reference pixels may be used instead of the unavailable reference pixel information. In intra prediction, the prediction mode may have an angle prediction mode that uses reference pixel information according to the prediction direction, and a non-angle prediction mode that does not use direction information when performing prediction. The mode for predicting luma information may be different from the mode for predicting chrominance information, and the intra prediction mode information or the predicted luma signal information used for predicting luma information may be used for predicting chrominance information. When intra prediction is performed, if the size of the prediction unit is the same as the size of the transform unit, intra prediction may be performed on the prediction unit based on the left pixel, the upper left pixel, and the top pixel of the prediction unit. However, when intra prediction is performed, if the size of the prediction unit differs from the size of the transform unit, the intra prediction can be performed using reference pixels based on the transform unit.

[0035] The intra prediction method may generate a prediction block after applying an adaptive intra smoothing (AIS) filter to the reference pixels based on the prediction mode. The type of the AIS filter applied to the reference pixels may be changeable. To perform the intra prediction method, the intra prediction mode of the current prediction unit may be predicted from the intra prediction mode of a neighboring prediction unit of the current prediction unit. When predicting the prediction mode of the current prediction unit using mode information predicted from a neighboring prediction unit, if the intra prediction mode of the current prediction unit is the same as the intra prediction mode of the neighboring prediction unit, information indicating that the prediction mode of the current prediction unit is the same as the prediction mode of the neighboring prediction unit may be transmitted using predetermined flag information. In addition, if the prediction mode of the current prediction unit is different from the prediction mode of the neighboring prediction unit, the prediction mode information of the current block may be encoded based on additional flag information.

[0036] As shown in Fig. 3, a residual block including a prediction unit that performs prediction based on the prediction unit generated by the prediction module 304 or the prediction module 306 and residual coefficient information can be generated, and the residual coefficient information is a difference value between the prediction unit and the original block. The generated residual block can be input to the transformation module 308.

[0037] TIFF2024529313000002.tif109170

[0038] The quantization module 310 may be configured to quantize the coefficients of each position in the coding block to generate a quantization level for the position. The current block may be a residual block. That is, the quantization module 310 may perform a quantization process on each residual block. The residual block may include N×M positions (samples), each of which is associated with a transformed or untransformed video signal / data, such as luma and / or chroma information, where N and M are positive integers. In the present invention, before quantization, a transformed or untransformed video signal at a particular position is referred to herein as a "coefficient". After quantization, the quantization value of the coefficient is referred to herein as a "quantization level" or "level".

[0039] Quantization can be used to reduce the dynamic range of a transformed or untransformed video signal, which allows the video signal to be represented using fewer bits. Quantization typically involves division and rounding by a quantization step length, while inverse quantization (also called dequantization) involves multiplication by a quantization step length. The quantization step length can be indicated by a quantization parameter (QP). Such a quantization process is called scalar quantization. Quantization of all coefficients in one coding block can be done independently, and such quantization methods are used in several existing video compression standards, such as H.264 / AVC and H.265 / HEVC. The QP in quantization can affect the bitrate used for video encoding. For example, a higher QP results in a lower bitrate, and a lower QP results in a higher bitrate.

[0040] For a coding block of size N×M, a particular coding scan order may be used to convert two-dimensional (2D) coefficients of the block into a one-dimensional (1D) order for coefficient quantization and coding. Typically, the coding scan starts at the top-left corner of the coding block and stops at the bottom-right corner of the coding block or at the last non-zero coefficient / level in the bottom-right direction. It should be noted that the coding scan order may include any suitable order, such as a zigzag scan order, a vertical (column) scan order, a horizontal (row) scan order, a diagonal scan order, or any combination thereof. The quantization of the coefficients in the coding block may utilize coding scan order information. For example, it may depend on the state of the previous quantization level along the coding scan order. To further improve the coding efficiency, the quantization module 310 may use multiple quantizers, for example, two scalar quantizers. Which quantizer is used to quantize the current coefficient may depend on the previous information of the current coefficient in the coding scan order. Such a quantization process is called dependent quantization.

[0041] Referring to FIG. 3, the encoding module 320 is configured to encode the quantization level of each position in the encoding block into a bitstream. In some implementations, the encoding module 320 may perform entropy encoding on the encoding block. The entropy encoding may convert each quantization level into a corresponding binary representation, such as a binary bin, using various binarization methods, such as Golomb-Rice binarization, including, for example, EGk binarization, compound TR binarization, and finite EGk binarization. The binary representation may then be further compressed using an entropy encoding algorithm, such as VLC, CAVLC, CABAC, SBAC, PIPE encoding, etc. The compressed data may be added to the bitstream. In some implementations, the encoding module 320 may perform residual encoding on the encoding block to convert the quantization levels into a bitstream. For example, after quantization, there may be N×M quantization levels for a block of size N×M. These N×M quantization levels may be zero or non-zero values. If the non-zero levels are not binary, they can be further binarized into binary bins using, for example, combined TR binarization and finite EGk binarization.

[0042] In addition to the quantization level, the encoding module 320 can encode various other information, such as block type information of the encoding unit, prediction mode information, partition unit information, prediction unit information, transmission unit information, motion vector information, reference frame information, block interpolation information, and filtering information input from the prediction module 304 and the prediction module 306. Information other than the quantization level or coefficients (e.g., parameters used in video encoding) can be organized and included in different level headers, such as a header of a sequence 502, a header of a picture 504, a header of a slice 506, a header of a CTU 508, a header of a CU 510, etc. For example, the header of each sequence 502 may include sequence level syntax elements (e.g., flags), each having a value that applies to all pictures 504 in the corresponding sequence 502, and the header of each slice 506 may also include slice level syntax elements (e.g., flags), each having a value that applies to all CTUs 508 in the corresponding slice 506.

[0043] Consistent with the scope of the present invention, in H.266 / VVC, some parameters for video encoding are considered optional and, for example, may not always be applicable to each sequence 502, so these parameters may be referred to as a set of header extension parameters, and may be defined or parsed at the end of the header at an appropriate level based on whether these parameters are present at that level. For example, the header extension parameter set may include slice level syntax elements, as detailed below for illustrative purposes only: (i) a last significant coefficient reverse flag indicating a reference position for referencing the position of the last significant coefficient, (ii) a high throughput mode flag indicating whether the slice is encoded in a high throughput mode, (iii) a residual data bit shift flag indicating whether residual data bits are shifted in residual encoding of the slice, and (iv) a luma / chroma shift syntax element indicating the number of bits shifted in luma / chroma residual encoding of the slice.

[0044] According to some aspects of the present invention, in H.266 / VVC, the coding block is a transform block coded using regular residual coding (RRC). A transform block larger than 4×4 can be divided into 4×4 sub-blocks, which are processed using a reverse diagonal scan mode. It is noted that H.266 / VVC supports non-square rectangular shaped transform blocks, and therefore non-4×4 sub-blocks. For ease of explanation and without loss of generality, an example of a 16×16 transform block is shown in FIG. 6, which is further divided into 4×4 sub-blocks. The reverse diagonal scan mode is used to process the sub-blocks of the transform block and the frequency positions within each sub-block.

[0045] In RRC, the position of the last non-zero level (also called the last valid scan position) may be defined as the position of the last non-zero level along the coding scan order. The 2D coordinates of the last non-zero level (last_sig_coeff_x and last_sig_coeff_y) may be coded first using up to four syntax elements, namely, two context-coded syntax elements, which are the two last valid coefficient prefixes (last_sig_coeff_x_prefix and last_sig_coeff_y_prefix), and two bypass-coded syntax elements, which are the two last valid coefficient suffixes (last_sig_coeff_x_suffix and last_sig_coeff_x_suffix). Within a sub-block, RRC may first code a context-coded bin, i.e., a coded sub-block flag (sb_coded_flag) to indicate whether all levels in the current sub-block are equal to 0 or not. For example, if sb_coded_flag is equal to 1, there may be at least one nonzero coefficient in the current subblock, and if sb_coded_flag is equal to 0, all coefficients in the current subblock are zero. Note that the sb_coded_flag of the last nonzero subblock with the last nonzero level may be derived from last_sig_coeff_x and last_sig_coeff_y according to the coding scan order without coding it into the bitstream. Similarly, the sb_coded_flag of the first subblock in which the DC of the whole block exists may be derived according to the coding scan order without coding it into the bitstream. The other sb_coded_flag may be coded as context coding bins. The RRC may be coded subblock-by-subblock in the reverse coding scan order from the last nonzero subblock.

[0046] In some embodiments, the coordinates of the last valid scan position / coefficient are measured with reference to the upper left corner (0,0). For high bit rates (e.g., 16 bits or more) with high bit depth video encoding (e.g., high throughput modes of video encoding), the transform coefficients are more widely distributed within the transform block. As a result, the last valid coefficient scan position / coefficient tends to be closer to the lower right corner than the upper left corner. Therefore, in some embodiments, the alternate set of coordinates of the last valid coefficient are measured and encoded with reference to the lower right corner of the transform block. The actual coordinates can be calculated by subtracting the alternate coordinates from the width minus one or the height minus one. In some embodiments, a zero-out process may be applied to the transform block when encoding the actual coordinates. For example, coordinates may be coded relative to (Log2ZoTbWidth<<1)-1, (Log2ZoTbHeight<<1)-1, where (Log2ZoTbWidth<<1) and (Log2ZoTbHeight<<1) refer to the width and height of the zero-out region within the transform block, which is defined as a sub-region within the transform block, and all coefficients outside the zero-out region are 0, respectively.

[0047] Consistent with the scope of the present invention, for example, a sequence level flag (sps_reverse_last_sig_coeff_enabled_flag) may be provided in the header extension of a particular sequence to indicate whether the slice level flag (sh_reverse_last_sig_coeff_flag) is enabled for a slice in the sequence. The slice level flag (sh_reverse_last_sig_coeff_flag) may be a last significant coefficient reverse flag indicating a reference position for referencing the position of the last significant coefficient in the slice, and the sequence level flag (sps_reverse_last_sig_coeff_enabled_flag) may be a flag indicating enablement / disablement of the use of the last significant coefficient reverse flag in the corresponding sequence. Then, for example, the header of each slice in the sequence is provided with a corresponding slice-level flag (sh_reverse_last_sig_coeff_flag) whose value indicates whether or not to use alternate coordinates for a reference location (e.g., top-left corner or bottom-right corner) for referencing the location of the last significant coefficient, i.e., the last significant coefficient in the corresponding slice. For example, if sps_reverse_last_sig_coeff_enabled_flag in the sequence header extension is equal to 1, then for each slice in the sequence, the use of alternate coordinates is further signaled by sh_reverse_last_sig_coeff_flag in the slice header. If sh_reverse_last_sig_coeff_flag is equal to 1, the last significant coefficient may be coded using the alternate coordinates of the corresponding slice. Otherwise, the normal coordinates of the last significant coefficient may be used for the corresponding slice. If sps_reverse_last_sig_coeff_enabled_flag in the sequence header extension is equal to 0, the normalized coordinate of the last valid coefficient may be used for all slices in the sequence without further signaling at the slice level using sh_reverse_last_sig_coeff_flag.In the following example, the sps_reverse_last_sig_coeff_enabled_flag in the sequence header extension and the sh_reverse_last_sig_coeff_flag in the slice header are described. [Table 1]

[0048] Context-adaptive modeling based binary arithmetic coding (CABAC), used in H.266 / VVC, H.265 / HEVC, and H.264 / AVC according to some aspects of the present invention, uses bins to code quantization levels of positions into bits. CABAC uses two context-modeling based coding methods. The context-based method adaptively updates the context model based on neighboring coding information. Bins coded in this way are called context-coded bins (CCB). In contrast, other bypass methods always use fixed context modeling without adaptation, since they assume that the probability of 1 or 0 is always 50%. Bins coded in this way are called bypass-coded bins (BCB). Throughput becomes a more serious issue in high bit depth and high bit rate video coding. However, compared to encoding with bypass coding bins, encoding using context coding bins generally requires relatively complex hardware implementation and reduces the video encoding throughput, which makes it a bottleneck in improving the throughput of high bit depth and high bit rate video encoding.

[0049] In order to improve the throughput of video coding, especially for high bit depth and high bit rate video coding, for example, for applications that require high bit depth and high bit rate video coding to obtain better throughput, a high throughput mode can be enabled during residual coding as needed. In some embodiments, in the high throughput mode, some or all of the context coding bins for residual coding can be changed to bypass coding bins. In some embodiments, in the high throughput mode, some or all of the context coding bins for residual coding can be skipped. As a result, in the high throughput mode, only the bypass coding bins can be used for residual coding. Furthermore, bypass bit-alignment can be applied in the high throughput mode to further improve the throughput of bypass coding. Instead of going through a normal CABAC operation after applying bit alignment, bypass coding can be realized by a shift operation, which allows simultaneous coding using multiple bypass coding bins. In the high throughput mode, bypass bit-alignment can be called at different stages of residual coding as needed, such as at the start of the coding process of the current coding block, at the start of the coding process of a transform unit, etc.

[0050] To ensure worst-case throughput, the value of remaining context coding bins (remBinsPass1) may be used to limit the maximum number of context coding bins. The initial value of remBinsPass1 may be calculated, at least in part, based on the length and width of the coding block. Within the sub-block, RRC may code the level of each position in the reverse coding scan order. A predefined threshold may be compared to remBinsPass1 to determine whether the maximum number of context coding bins has been reached. For example, the threshold of remBinsPass1 in H.266 / VVC may be predefined to be 4.

[0051] TIFF2024529313000004.tif181170

[0052] If the absolute level is greater than 5 or the value of remBinsPass1 is less than 4, after encoding the aforementioned context coding bins, for the remaining levels, two other syntax elements, namely, the remainder (abs_remainder, "rem" in FIG. 7, also called "remainder level" in the present invention) and the absolute level (dec_abs_level, "decAbsLevel" in FIG. 7), may be coded as bypass coding bins in the second coding pass ("Pass 2" in FIG. 7) and the third coding pass ("Pass 3" in FIG. 7), respectively. Also, in the fourth coding pass ("Pass 4" in FIG. 7), the coefficient sign flag (coeff_sign_flag, "sign" in FIG. 7) of each non-zero level may also be coded as a bypass coding bin to fully represent the quantization level.

[0053] In some embodiments, a more general residual coding method uses a greater level flag (abs_level_gtxX_flag) and a remainder level bin to allow conditional parsing of syntax elements for level coding of transform blocks, and the corresponding binarization of the absolute value of the level is shown in Table I below, where abs_level_gtxX_flag describes whether the absolute value of the level is greater than X, where X is an integer such as 0, 1, 2..... or N. If abs_level_gtxX_flag is 0 and X is an integer between 0 and N-1, then abs_level_gtx(X+1)_flag is not present. If abs_level_gtxX_flag is 1, then abs_level_gtx(X+1)_flag is present. Also, if abs_level_gtxN_flag is 0, then no remainder is present. If abs_level_gtxN_flag is 1, then there is a residual, which represents the level minus (N+1). Typically, abs_level_gtxX_flag is coded as a context coding bin, and the remaining level bins can be coded as bypass coding bins. [Table 2]

[0054] FIG. 8A illustrates an exemplary high throughput mode in RRC according to some embodiments of the present invention. As shown in FIG. 8A, a bitstream may start with a transform unit bin of a transform unit. Various transform unit bins may be reserved as context coding bins for context coding in CABAC. The transform unit bins may include a coded Cb transform block flag (tu_cb_coded_flag), a coded Cr transform block flag (tu_cr_coded_flag), a coded luma transform block flag (tu_y_coded_flag), a quantization parameter delta value (cu_qp_delta_abs), a chroma quantization parameter offset flag (cu_chroma_qp_offset_flag), a chroma quantization parameter offset index (cu_chroma_qp_offset_idx), a joint chroma flag (tu_joint_cbcr_residual_flag), and a transform skip flag (transform_skip_flag). It should be noted that the transform unit bin may further include a bypass coding bin, such as a quantization parameter delta sign flag (cu_qp_delta_sign_flag) in some examples.

[0055] As shown in FIG. 8A, a transform unit may correspond to one coding block (e.g., transform block for RRC) of luma samples ("Y" in FIG. 8A) and two corresponding coding blocks of chroma samples ("Cb" and "Cr" in FIG. 8A). Thus, a transform unit bin may include three transform_skip_flags for Y, Cb, and Cr coding blocks, respectively, each being a context coding bin. For each coding block, the first residual coding bin of the coding block that is coded / decoded into the bitstream after the transform_skip_flag may be the last significant coefficient prefix (last_sig_coeff_x_prefix and last_sig_coeff_y_prefix) that remains a context coding bin. As shown in FIG. 8A, all other residual coding bins in each coding block may be bypass coding bins. For example, a bypass coded residual coding bin may include the last significant coefficient suffix (last_sig_coeff_x_suffix and last_sig_coeff_y_suffix), the coded sub-block flag (sb_coded_flag), the absolute level (dec_abs_level), and the coefficient sign flag (coeff_sign_flag).

[0056] That is, the high throughput mode may be enabled for each coding block after last_sig_coeff_x_prefix and last_sig_coeff_y_prefix and before sb_coded_flag. In some embodiments where last_sig_coeff_x_sufix and last_sig_coeff_y_sufix also need to be coded, the high throughput mode may be enabled for each coding block after last_sig_coeff_x_prefix and last_sig_coeff_y_prefix and before last_sig_coeff_x_sufix and last_sig_coeff_y_sufix. In other words, the high throughput mode may be enabled for each coding block immediately after last_sig_coeff_x_prefix and last_sig_coeff_y_prefix. In the high throughput mode, for each position of each sub-block, the residual coding bin, i.e., sb_coded_flag, may be changed from a context coding bin to a bypass coding bin. The coding of all other context coding bins such as the valid flag (sig_coeff_flag), the greater than 1 flag (abs_level_gtx_flag[n][0]), the parity flag (par_level_flag) and the greater than flag (abs_level_gtx_flag[n][1]) can be skipped, such as by setting the value of the remaining context coding bin (remBinsPass1) to a value less than threshold 4 (e.g., 0). Thus, the coding of the remaining level / residual (abs_remainder[n]) can also be skipped. In other words, in high throughput mode, by skipping the first and second coding passes at each position of each sub-block of the coding block, the context coding bins can be prevented from appearing in the first coding pass. As a result, in high throughput mode, each coding block can be coded using only bypass coding bins, except for last_sig_coeff_x_prefix and last_sig_coeff_y_prefix.The coding of each quantization level may be done by the bypass coded absolute level (dec_abs_level) rather than the remaining level / residue (abs_remainder).

[0057] FIG. 8B illustrates another exemplary high-throughput mode in RRC according to some embodiments of the present invention. Different from the bypass coding in FIG. 8A, the high-throughput mode in FIG. 8B can further change last_sig_coeff_x_prefix and last_sig_coeff_y_prefix from context coding bin to bypass coding bin, and in the high-throughput mode in FIG. 8B, each coding block can be coded using only bypass coding bin. As shown in FIG. 8B, the high-throughput mode can be enabled at the coding block level. Compared with the scheme in FIG. 8A, the scheme in FIG. 8B can further improve the throughput of video coding by changing the last significant coefficient prefix from context coding bin to bypass coding bin. For very high bit rate and high bit depth operating range, the bit of the last significant coefficient position can also be quite high because most blocks are coded to small block size. Since an index for the context variables is derived for each bin of last_sig_coeff_x_prefix and last_sig_coeff_y_prefix, the derivation of the context index for last_sig_coeff_x_prefix and last_sig_coeff_y_prefix may impact throughput.

[0058] 8C illustrates yet another exemplary high-throughput mode for transform unit coding according to some embodiments of the present invention. Different from the high-throughput mode of FIG. 8B, the bypass coding mode of FIG. 8C further changes transform_skip_flag from context coding bin to bypass coding bin.

[0059] FIG. 8D illustrates yet another exemplary high-throughput mode in transform unit coding according to some embodiments of the present invention. Different from FIG. 8C, the high-throughput mode of FIG. 8D further changes the transform unit bin of the transform unit from context-coded bin to bypass-coded bin, so that all transform unit bins of the transform unit are also coded as bypass-coded bins in the high-throughput mode. For example, in addition to transform_skip_flags, the bypass coding mode can also change tu_cb_coded_flag, tu_cr_coded_flag, tu_y_coded_flag, cu_qp_delta_abs, cu_chroma_qp_offset_flag, cu_chroma_qp_offset_idx, and tu_joint_cbcr_residual_flag from context-coded bin to bypass-coded bin. As a result, the high-throughput mode of FIG. 8D can code the transform unit and three corresponding coding blocks using only bypass-coded bins. Compared with the scheme of Figure 8C, the bypass coding mode of Figure 8D can further improve the video coding throughput by coding the transform unit bin as only bypass coding bin to avoid switching between context coding and bypass coding by the CABAC coding engine when coding the transform unit. The bypass coding mode can be enabled at the transform unit level.

[0060] Consistent with the scope of the present invention, another sequence level flag (sps_high_throughput_mode_enabled_flag) may be provided, for example, in a header extension of a particular sequence, to indicate whether a slice level flag (sh_high_throughput_mode_flag) is enabled for a slice in that sequence. A corresponding slice level flag (sh_high_throughput_mode_flag) may then be provided, for example, in the header of each slice in the sequence, with the value of the flag indicating whether the slice is coded in high throughput mode. For example, if sps_high_throughput_mode_enabled_flag in the sequence header extension is equal to 1, the use of high throughput mode for coding a slice may be further signaled with sh_high_throughput_mode_flag in the slice header of each slice in the sequence. If sh_high_throughput_mode_flag is equal to 1, the slice may be coded in high throughput mode. Otherwise, the slice may not be coded in high throughput mode. If sps_high_throughput_mode_enabled_flag in the sequence header extension is equal to 0, high-throughput mode may not be invoked for all slices in the sequence and no further signaling at slice level using sh_high_throughput_mode_flag is required. The following example explains sps_high_throughput_mode_enabled_flag in the sequence header extension and sh_high_throughput_mode_flag in the slice header. [Table 3]

[0061] According to some aspects of the present invention, a modification of the coding of the residual data may be used in which the significance, GT1, and GT2 are shifted left by a few bits. This may improve the efficiency of the coefficient coding since it gives more information about the coefficient values, although the coding efficiency of the flags themselves is low. The Golomb-Rice coding is necessary because the number of coefficients is reduced due to the reduction in the proportion of set bins.

[0062] Consistent with the scope of the present invention, yet another sequence level flag (sps_shift_residual_data_enabled_flag) may be provided, for example, in a header extension of a particular sequence to indicate whether slice level syntax elements (slice_flagshift_luma and slice_flagshift_chroma) are enabled for slices in the sequence. The slice level syntax elements (slice_flagshift_luma and slice_flagshift_chroma) may be syntax elements indicating the number of shift bits of luma / chroma data in the residual coding of the slice, and the sequence level flag (sps_shift_residual_data_enabled_flag) may be a flag indicating enablement / disabling of the use of the slice level bit shifting syntax elements in the corresponding sequence. Then, the corresponding slice level syntax elements (slice_flagshift_luma and slice_flagshift_chroma) may be provided, for example, in the header of each slice in the sequence, and the values ​​of these syntax elements indicate the number of shift bits in the luma / chroma residual coding of the slice. For example, if sps_shift_residual_data_enabled_flag in the sequence header extension is equal to 1, then for each slice in the sequence, the use of residual data bit shifting to code the slice may be further signaled with slice_flagshift_luma and slice_flagshift_chroma in the slice header. The values ​​of slice_flagshift_luma and slice_flagshift_chroma may indicate the number of bits shifted for the corresponding luma and chroma residual data. If sps_shift_residual_data_enabled_flag in the sequence header extension is equal to 0, then residual data bit shifting may not be invoked for all slices in the sequence, and therefore there is no need to further specify it at the slice level using slice_flagshift_luma and slice_flagshift_chroma.The following example explains sps_shift_residual_data_enabled_flag in the sequence header extension, and slice_flagshift_luma and slice_flagshift_chroma in the slice header. [Table 4]

[0063] In some embodiments, another slice level flag (sh_shift_residual_data_enabled_flag) is added between the sequence level flag (sps_shift_residual_data_enabled_flag) and the slice level syntax elements (slice_flagshift_luma and slice_flagshift_chroma) to add another layer of condition checking / analysis at the slice level. For example, sps_shift_residual_data_enabled_flag provided in the header extension of a particular sequence may indicate whether the residual data bit shift flag (sh_shift_residual_data_enabled_flag) indicates, for a slice in that sequence, whether residual data bit shifting is enabled for the residual coding of that slice. A corresponding slice level flag (sh_shift_residual_data_enabled_flag) is then provided, for example, in the header of each slice in the sequence, with the value of the flag ('0' or '1') indicating whether residual data bits are shifted for the residual coding of the slice. For example, if sh_shift_residual_data_enabled_flag in the slice header is equal to 1, the use of residual data bit shifting in residual coding of the slice may be further specified by slice_flagshift_luma and slice_flagshift_chroma, as described above. Otherwise, the slice may be coded without residual data bit shifting, and there is no need to further specify values ​​for slice_flagshift_luma and slice_flagshift_chroma. The following example describes sh_shift_residual_data_enabled_flag, slice_flagshift_luma, and slice_flagshift_chroma in the slice header. [Table 5]

[0064] As mentioned above, the above last significant coefficient reverse flag, high throughput mode flag, residual data bit shift flag, and luma / chroma shift flag are examples of syntax elements that may be specified by their values ​​at the slice level and enabled / disabled at the sequence level by corresponding sequence level flags. These syntax element examples, along with any other suitable syntax elements, may be part of the parameters belonging to a header extension parameter set at any suitable level. Consistent with the scope of the present invention, a PPS flag (pps_slice_header_extension_present_flag) may be provided, for example, in the header of any suitable level to indicate whether a header extension parameter set of that level is present or not. Certain sequence level flags (e.g., sps_reverse_last_sig_coeff_enabled_flag, sps_high_throughput_mode_enabled_flag, and sps_shift_residual_data_enabled_flag) may be provided, for example, in the header extension of a sequence, and their values ​​indicate whether the corresponding header extension parameters are enabled or not in the sequence, as described in detail above. For example, if pps_slice_header_extension_present_flag is equal to 1, then the specific sequence level flags for the header extension parameters (e.g., sps_reverse_last_sig_coeff_enabled_flag, sps_high_throughput_mode_enabled_flag, and sps_shift_residual_data_enabled_flag) can be further parsed from the sequence header. If pps_slice_header_extension_present_flag is equal to 0, then the header extension parameters are not used and there is no need to further parse the specific sequence level flags of the header extension parameters to encode the sequence.

[0065] According to some aspects of the present invention, syntax elements in the same condition check / analysis may be grouped together to further reduce complexity and improve video coding efficiency. For example, some or all of the syntax elements (e.g., header extension parameters and their corresponding specific sequence level flags) may be grouped by a general flag (pps_slice_header_extension_present_flag) in the same condition check / analysis, as shown in the following two examples: [Table 6]

[0066] In some embodiments, slice level syntax elements of header extension parameters may be conditionally parsed in slice header extension to reduce design complexity. For example, if the sum of bits consumed by some slice level syntax elements of header extension parameters is more than one byte, these syntax elements may be on a byte boundary. In one example, if there are five syntax elements in a header extension parameter for a slice level extension, with three syntax elements consuming one bit per element and two syntax elements consuming four bits per element, two 8-bit (byte) syntax elements may be used together to represent these five syntax elements, and the bytes may be placed on a byte alignment boundary to avoid using additional bits to align the bytes. As shown in the above example, more_data_in_slice_header_extension( ) may be any value and may be used as a condition to specify slice_header_extension_data_bit. For example, if the current position in the slice header minus the position immediately following slice_header_extension_length is less than (slice_header_extension_length * 8), the return value of more_data_in_slice_header_extension( ) is equal to TRUE, which triggers slice_header_extension_data_bit. Otherwise, the return value of more_data_in_slice_header_extension( ) is equal to FALSE.

[0067] 3, the inverse quantization module 312 may be configured to inverse quantize the quantization levels by the inverse quantization module 312, and the inverse transform module 314 may be configured to inverse transform the coefficients transformed by the transform module 308. The reconstructed residual blocks generated by the inverse quantization module 312 and the inverse transform module 314 may be combined with the prediction units predicted by the prediction module 304 or the prediction module 306 to generate reconstructed blocks.

[0068] The filter module 316 may include at least one of a deblocking filter, a sample adaptive offset (SAO) filter, and an adaptive in-loop filter (ALF). The deblocking filter may remove block distortion generated by boundaries between blocks in the reconstructed image. The SAO module may compensate for an offset with respect to the original video on a pixel-by-pixel basis for the deblocked video. The ALF may be performed based on a value obtained by comparing the reconstructed and filtered video with the original video. The buffer module 318 may be configured to store the reconstructed blocks or images calculated by the filter module 316, and may provide the reconstructed and stored blocks or images to the inter prediction module 304 when inter prediction is performed.

[0069] FIG. 4 is a detailed block diagram of an exemplary decoder 201 in the decoding system 200 of FIG. 2 according to some embodiments of the present invention. As shown in FIG. 4, the decoder 201 may include a decoding module 402, an inverse quantization module 404, an inverse transform module 406, an inter prediction module 408, an intra prediction module 410, a filter module 412, and a buffer module 414. Note that each element shown in FIG. 4 is shown independently to represent different characteristic functions in a video decoder, but does not mean that each component is formed by an individual hardware or a single software configuration unit. That is, each included element is listed as a single element for convenience of explanation, and at least two elements may be combined into one element, or one element may be divided into multiple elements to perform a function. In addition, some elements may not be necessary to perform the functions described in the present invention, but may be optional elements for improving performance. Furthermore, these elements may be implemented using electronic hardware, firmware, computer software, or any combination thereof. Whether such elements are implemented as hardware, firmware, or software depends on the particular application and design constraints imposed on the decoder 201 .

[0070] When a video bitstream is input from a video encoder (e.g., encoder 101), the input bitstream may be decoded by the decoder 201 in a process opposite to that of the video encoder. Therefore, for convenience of explanation, some details of the decoding corresponding to the above description of the encoding are omitted. The decoding module 402 may be configured to decode the bitstream to obtain various information encoded in the bitstream, such as the quantization level of each position in the coding block. In some embodiments, the decoding module 402 may perform entropy decoding (decompression) corresponding to the entropy encoding (compression) performed by the encoder (e.g., VLC, CAVLC, CABAC, SBAC, PIPE encoding, etc.) to obtain a binary representation (e.g., binary bin). The decoding module 402 may further convert the binary representation into a quantization level using Golomb-Rice binarization (e.g., including EGk binarization, complex TR binarization, and finite EGk binarization, etc.). In addition to the quantization level of the position within the transform unit, the decoding module 402 can decode various other information such as parameters used for Golomb-Rice binarization (e.g., Rice parameters), block type information of the coding unit, prediction mode information, partition unit information, prediction unit information, transmission unit information, motion vector information, reference frame information, block interpolation information, and filtering information. During the decoding process, the decoding module 402 can perform reordering on the bitstream in a reverse scan manner based on the encoding scan order used by the encoder to reconstruct and rearrange the data from a 1D order into 2D rearranged blocks.

[0071] Consistent with the scope of the present invention, the decoding module 402 may parse the bitstream to obtain values ​​of various syntax elements associated with different levels of header extension parameters disclosed herein, such as a general flag indicating the presence of a header extension parameter, sequence level flags for various header extension parameters, and various slice level header extension parameters. In some embodiments, the decoding module 402 may perform conditional parsing of a group of syntax elements under the same condition (e.g., the presence of a header extension parameter as detailed above). Depending on the result of the condition check, parsing of lower level syntax elements may be skipped. For example, if the condition check at the sequence level fails, parsing for slice level flags does not need to be performed by the decoder 201, thus simplifying the process by the decoder 201. If the sequence level condition check passes, the decoding module 402 may obtain values ​​of the header extension parameters for a particular slice and decode the slice based on the obtained values.

[0072] The inverse quantization module 404 may be configured to inverse quantize the quantization levels of each position of an encoding block (e.g., a 2D reconstruction block) to obtain a coefficient for each position. In some embodiments, the inverse quantization module 404 may also perform dependent inverse quantization based on a quantization parameter provided by an encoder, the quantization parameter including information related to the quantizers used in the dependent quantization, such as the quantization step length used in each quantizer.

[0073] The inverse transform module 406 may be configured to perform inverse transforms (e.g., inverse DCT, inverse DST, and inverse KLT) for the DCT, DST, and KLT, respectively, performed by the encoder to transform data from the transform domain (e.g., coefficients) back to the pixel domain (e.g., luma and / or chroma information). In some embodiments, the inverse transform module 406 may selectively perform transform operations (e.g., DCT, DST, KLT) according to multiple information such as a prediction method, a size of a current block, a prediction direction, etc.

[0074] The inter prediction module 408 and the intra prediction module 410 may be configured to generate a prediction block based on information related to the generation of the prediction block provided by the decoding module 402 and information on a previously decoded block or image provided by the buffer module 414. As described above, when performing intra prediction in the same manner as the operation of the encoder, if the size of the prediction unit and the size of the transform unit are the same, intra prediction can be performed on the prediction unit based on the pixels located to the left, the pixels located to the upper left, and the pixels located at the top. However, when performing intra prediction, if the size of the prediction unit is different from the size of the transform unit, intra prediction can be performed using reference pixels based on the transform unit.

[0075] A reconstructed block or image combined from the output of the inverse transform module 406 and the prediction module 408 or the prediction module 410 may be provided to a filter module 412. The filter module 412 may include a deblocking filter, an offset correction module, and an ALF. The buffer module 414 may store the reconstructed image or block and use it as a reference image or block for the inter prediction module 408, and output the reconstructed image.

[0076] Consistent with the scope of the present invention, the encoding module 320 and the decoding module 402 may be configured to implement various approaches disclosed herein to improve the efficiency and reduce the complexity of organizing and parsing representations of syntax elements in video encoding.

[0077] 9 illustrates a flowchart of an exemplary video decoding method 900 according to some embodiments of the present invention. The method 900 may be performed at the sequence level and the slice level by the decoder 201 in the decoding system 200 or any other suitable video decoding system. As described below, the method 900 may include operations 902, 904, 906, 908, 910, 912, 914, 916, and 918. Note that some operations may be optional, may be performed simultaneously, or may be performed in a different order than that shown in FIG. 9.

[0078] At operation 902, the bitstream is parsed to obtain a value of a first flag, which indicates whether a header extension parameter set is present. For example, as shown in FIG. 4, the decoding module 402 may be configured to parse the input bitstream to obtain a value of a general flag (pps_slice_header_extension_present_flag) (e.g., “0” or “1”).

[0079] At operation 904, it is determined whether the value of the first flag indicates the presence of a header extension parameter set. For example, as shown in FIG. 4, the decoding module 402 may be configured to determine that a general flag value of "1" indicates the presence of header extension parameters and a value of "0" indicates the absence of header extension parameters.

[0080] In operation 906, in response to the value of the first flag indicating the presence of the header extension parameter set, parse the bitstream to obtain a value of a second flag. The value of the second flag indicates whether the first parameter in the header extension parameter set is enabled for the sequence of the image. The first parameter may include a last significant coefficient reverse flag indicating a reference position for referencing a position of a last significant coefficient, a high throughput mode flag indicating whether the slice is coded in a high throughput mode, or a residual data bit shift flag indicating whether residual data bits are shifted in the residual coding of the slice. For example, as shown in FIG. 4, only if the decoding module 402 determines that a header extension parameter is present, the decoding module 402 may be configured to further parse the input bitstream to obtain a value (e.g., "0" or "1") of a particular sequence level flag (sps_shift_residual_data_enabled_flag, sps_reverse_last_sig_coeff_enabled_flag, or sps_high_throughput_flag) of a header extension parameter. If not, the decoding module 402 may not further parse the input bitstream to obtain the value of any particular sequence-level flag in the header extension parameters.

[0081] In operation 908, it is determined whether the value of the second flag indicates that the first parameter in the header extension parameter set is enabled for the sequence of images. For example, as shown in FIG. 4, the decoding module 402 may be configured to determine that a value of "1" for a particular sequence-level flag indicates that the corresponding header extension parameter is enabled for the sequence, and a value of "0" indicates that the corresponding header extension parameter is disabled for the sequence.

[0082] In operation 910, in response to the value of the second flag indicating that the first parameter is enabled for the sequence of images, parse the bitstream to obtain a value of the first parameter used for one of the slices in the sequence of images. For example, as shown in FIG. 4, only if the decoding module 402 determines that a corresponding header extension parameter is enabled for a sequence, the decoding module 402 may be configured to further parse the input bitstream to obtain a value of the corresponding header extension parameter (sh_shift_residual_data_flag, slice_flagshift_luma / slice_flagshift_chroma, sh_reverse_last_sig_coeff_flag, or sh_high_throughput_mode_flag). Otherwise, the decoding module 402 may not further parse the input bitstream to obtain a value of the corresponding header extension parameter.

[0083] Optionally, in operation 912, in response to the value of the first flag indicating that the header extension parameter set is present, parse the bitstream to obtain a value of a third flag. The value of the third flag indicates whether a second parameter in the header extension parameter set is enabled for the sequence of the image. The second parameter may include a last significant coefficient reverse flag, a high-throughput mode flag, or a residual data bit shift flag indicating whether residual data bits are shifted in residual coding of a slice. For example, as shown in FIG. 4, only if the decoding module 402 determines that a header extension parameter is present for a sequence, the decoding module 402 may be configured to further parse the input bitstream to obtain a value (e.g., “0” or “1”) of another particular sequence-level flag (sps_shift_residual_data_enabled_flag, sps_reverse_last_sig_coeff_enabled_flag, or sps_high_throughput_flag) of another header extension parameter.

[0084] Optionally, in operation 914, it is determined whether the value of the third flag indicates that the second parameter in the header extension parameter set is enabled for the sequence of the image. For example, as shown in Fig. 4, the decoding module 402 may be configured to determine that if the value of another particular sequence level flag is "1", it indicates that the corresponding another header extension parameter is enabled for the sequence, and if the value is "0", it indicates that the corresponding another header extension parameter is disabled for the sequence.

[0085] Optionally, in operation 916, in response to the value of the third flag indicating that the second parameter is enabled for the sequence of images, parse the bitstream to obtain a value of the second parameter used for the slice. For example, as shown in Fig. 4, only if the decoding module 402 determines that a corresponding another header extension parameter is enabled for the sequence, the decoding module 402 may be configured to further parse the input bitstream to obtain a value of the corresponding header extension parameter (sh_shift_residual_data_flag, slice_flagshift_luma / slice_flagshift_chroma, sh_reverse_last_sig_coeff_flag or sh_high_throughput_mode_flag). Otherwise, the decoding module 402 may not further parse the input bitstream to obtain a value of the corresponding another header extension parameter.

[0086] In operation 918, the slice is decoded based on the value of the first parameter and the value of the second parameter used for the slice. For example, as shown in FIG. 4, the decoding module 402 may be configured to decode the slice based on the value of the obtained header extension parameters, such as a reference position for referencing the position of the last significant coefficient, whether the slice is coded in a high throughput mode, and / or a number of shift bits in luma / chroma residual coding of the slice.

[0087] 10 shows a flowchart of an exemplary video encoding method 1000 according to some embodiments of the present invention. The method 1000 may be performed at a transform unit level by the encoder 101 in the encoding system 100 or any other suitable video encoding system. As described below, the method 1000 may include operations 1002, 1004, 1006, 1008, 1010, 1012, and 1014. Note that some operations may be optional, may be performed simultaneously, or may be performed in a different order than that shown in FIG.

[0088] In operation 1002, a value of a first parameter in a header extension parameter set of at least one slice in a sequence of images is determined. The first parameter may include a last significant coefficient reverse flag indicating a reference position for referencing a position of a last significant coefficient, a high throughput mode flag indicating whether a slice is coded in a high throughput mode, or a residual data bit shift flag indicating whether a residual data bit is shifted in the residual coding of the at least one slice. For example, as shown in FIG. 3, the coding module 320 is configured to determine that a value of any one of the slice level flags (sh_shift_residual_data_flag, sh_reverse_last_sig_coeff_flag, or sh_high_throughput_mode_flag) is equal to "1" if the at least one slice needs to use a corresponding header extension parameter when coding the slice (e.g., in a high throughput mode, to code the last significant coefficient using an alternative coordinate or to apply a residual data bit shift to the residual coding).

[0089] In operation 1004, a value of a first flag indicating whether the header extension parameter set is present is determined based on the value of the first parameter. For example, as shown in FIG. 3, the encoding module 320 may determine a value ("0" or "1") of a general flag (pps_slice_header_extension_present_flag) based on the determined value ("0" or "1") of any of the header extension parameters. For example, if the value of any of the slice level flags (sh_shift_residual_data_flag, sh_reverse_last_sig_coeff_flag, or sh_high_throughput_mode_flag) is equal to "1", which means that the corresponding header extension parameter needs to be used when encoding at least one slice, the value of the general flag (pps_slice_header_extension_present_flag) may also be determined to be equal to "1", thereby indicating that the header extension parameter is present.

[0090] In operation 1006, based on the value of the first parameter, a value of a second flag indicating whether the first parameter is enabled for the sequence of images is determined. For example, as shown in FIG. 3, the encoding module 320 may also determine the value ("0" or "1") of a corresponding sequence level flag (sps_shift_residual_data_enabled_flag, sps_reverse_last_sig_coeff_enabled_flag, or sps_high_throughput_flag) based on the determined value ("0" or "1") of the header extension parameter. For example, if the value of any of the slice level flags (sh_shift_residual_data_flag, sh_reverse_last_sig_coeff_flag or sh_high_throughput_mode_flag) is equal to "1", this means that the corresponding header extension parameter needs to be used when encoding at least one slice, and the value of the corresponding sequence level flag (sps_shift_residual_data_enabled_flag, sps_reverse_last_sig_coeff_enabled_flag, sps_high_throughput_flag) is also determined to be equal to "1", thereby indicating the enablement of the header extension parameter at the sequence level.

[0091] Optionally, in operation 1008, a value of a second parameter in the header extension parameter set of the at least one slice is determined. The second parameter may include the last significant coefficient reverse flag indicating a reference position for referencing a position of the last significant coefficient, the high throughput mode flag indicating whether a slice is encoded in the high throughput mode, or the residual data bit shift flag indicating whether residual data bits are shifted in residual encoding of the at least one slice. For example, as shown in FIG. 3, the encoding module 320 is configured to determine that another value in a slice level flag (sh_shift_residual_data_flag, sh_reverse_last_sig_coeff_flag, or sh_high_throughput_mode_flag) is also equal to "1" if at least one slice needs to use a corresponding another header extension parameter when encoding the slice (e.g., in high throughput mode, to encode the last significant coefficient using an alternative coordinate or to apply a residual data bit shift to residual encoding).

[0092] Optionally, in operation 1010, based on the value of the second parameter, determine a value of a third flag indicating whether the second parameter is enabled for the sequence of images. For example, as shown in Figure 3, the encoding module 320 may also determine a value ("0" or "1") of a corresponding sequence level flag (sps_shift_residual_data_enabled_flag, sps_reverse_last_sig_coeff_enabled_flag, or sps_high_throughput_flag) based on the determined value ("0" or "1") of another header extension parameter. For example, if the value of another one of the slice level flags (sh_shift_residual_data_flag, sh_reverse_last_sig_coeff_flag, or sh_high_throughput_mode_flag) is equal to "1", which means that a corresponding another header extension parameter needs to be used when encoding at least one slice, and the value of the corresponding sequence level flag (sps_shift_residual_data_enabled_flag, sps_reverse_last_sig_coeff_enabled_flag, or sps_high_throughput_flag) is also determined to be equal to "1", thereby indicating the enablement of the other header extension parameter at the sequence level.

[0093] In operation 1012, the slice is encoded into a bitstream based on the value of the first parameter and the value of the second parameter used for the slice. For example, as shown in FIG. 3, encoding module 320 may be configured to encode the slice based on the value of header extension parameters, such as a reference position for referencing the position of the last significant coefficient, whether the slice is encoded in a high throughput mode, and / or the number of shift bits in luma / chroma residual encoding of the slice.

[0094] At operation 1014, the first flag value, the second flag value, the first parameter value, and the second parameter value are encoded into the bitstream. For example, as shown in FIG 3, encoding module 320 may be configured to encode the obtained general flag value, sequence level flag value, and header extension parameter value into the bitstream.

[0095] In various aspects of the invention, the functions described herein can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions can be stored as instructions in a non-transitory computer-readable medium. Computer-readable media includes computer storage media. The storage medium may be any available medium accessible to a processor, such as the processor 102 of FIG. 1 and FIG. 2. By way of non-limiting example, such computer-readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, HDD (magnetic disk storage or other magnetic storage), flash drive, SSD, or any other medium. The medium may be used to carry or store desired program code in the form of instructions or data structures, and can be accessed by a processing system (such as a mobile device or computer). As used herein, disk and disc include CDs, laser discs, optical discs, digital video discs (DVDs), and floppy disks, where disks typically reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0096] According to one aspect of the present invention, a method for decoding a video is disclosed. The video includes a sequence of images, each of the images includes one or more slices. A processor parses a bitstream to obtain a value of a first flag. The processor determines whether a value of the first flag indicates that a header extension parameter set is present. In response to the value of the first flag indicating that the header extension parameter set is present, the processor parses the bitstream to obtain a value of a second flag. The processor determines whether a value of the second flag indicates that the first parameter in the header extension parameter set is enabled for the sequence of images. In response to the value of the second flag indicating that the first parameter is enabled for the sequence of images, the processor parses the bitstream to obtain a value of the first parameter used for one of the slices in the sequence of images. The processor decodes the slice based on the value of the first parameter used for the slice.

[0097] In some embodiments, the first parameter includes a last significant coefficient inverse flag indicating a reference location for referencing the location of the last significant coefficient.

[0098] In some embodiments, the first parameter includes a high throughput mode flag indicating whether the slice is encoded in a high throughput mode.

[0099] In some embodiments, the first parameter includes a residual data bit shift flag indicating whether residual data bits are shifted in the residual coding of the slice.

[0100] In some embodiments, the value of the second flag is encoded in a header extension of the sequence of images.

[0101] In some embodiments, the value of the first parameter is encoded in the header of the slice.

[0102] In some embodiments, in response to the value of the first flag indicating that the header extension parameter set is present, the processor parses the bitstream to obtain a value of a third flag. In some embodiments, the processor determines whether the value of the third flag indicates that a second parameter in the header extension parameter set is enabled for the sequence of images. In some embodiments, in response to the value of the third flag indicating that the second parameter is enabled for the sequence of images, the processor parses the bitstream to obtain a value of the second parameter used for the slice. In some embodiments, the processor decodes the slice based on the value of the first parameter and the value of the second parameter used for the slice.

[0103] According to another aspect of the invention, a video decoding system comprises a memory configured to store instructions and a processor coupled to the memory, the video including a sequence of images, each of the images including one or more slices. The processor is configured to parse a bitstream to obtain a value of a first flag when executing the instructions. The processor is further configured to determine, when executing the instructions, whether a value of the first flag indicates a header extension parameter set is present, and in response to the value of the first flag indicating the presence of the header extension parameter set, to parse the bitstream to obtain a value of a second flag. The processor is further configured to determine, when executing the instructions, whether a value of the second flag indicates that the first parameter in the header extension parameter set is enabled for the sequence of images, and in response to the value of the second flag indicating that the first parameter is enabled for the sequence of images, to parse the bitstream to obtain a value of the first parameter used for one of the slices in the sequence of images. The processor is further configured, when executing the instructions, to decode the slice based on the value of the first parameter used for the slice.

[0104] In some embodiments, the first parameter includes a last significant coefficient inverse flag indicating a reference location for referencing the location of the last significant coefficient.

[0105] In some embodiments, the first parameter includes a high throughput mode flag indicating whether the slice is encoded in a high throughput mode.

[0106] In some embodiments, the first parameter includes a residual data bit shift flag indicating whether residual data bits are shifted in the residual coding of the slice.

[0107] In some embodiments, the value of the second flag is encoded in a header extension of the sequence of images.

[0108] In some embodiments, the value of the first parameter is encoded in the header of the slice.

[0109] In some embodiments, the processor is further configured to parse the bitstream to obtain a value of a third flag in response to a value of the first flag indicating that the header extension parameter set is present. In some embodiments, the processor is further configured to determine whether a value of the third flag indicates that a second parameter in the header extension parameter set is enabled for the sequence of images. In some embodiments, the processor is further configured to parse the bitstream to obtain a value of the second parameter used for the slice in response to a value of the third flag indicating that the second parameter is enabled for the sequence of images. In some embodiments, the processor is further configured to decode the slice based on the value of the first parameter and the value of the second parameter used for the slice.

[0110] According to yet another aspect of the present invention, a method for encoding a video is disclosed. The video includes a sequence of images, each of the images including one or more slices. A processor determines a value of a first parameter in a header extension parameter set for at least one of the slices in the sequence of images. The processor determines a value of a first flag indicating whether the header extension parameter set is present or not based on the value of the first parameter. The processor determines a value of a second flag indicating whether the first parameter is enabled or not for the sequence of images based on the value of the first parameter. The processor encodes the at least one slice into a bitstream based on the value of the first parameter. The processor encodes the value of the first flag, the value of the second flag, and the value of the first parameter into the bitstream.

[0111] In some embodiments, the first parameter includes a last significant coefficient inverse flag indicating a reference location for referencing the location of the last significant coefficient.

[0112] In some embodiments, the first parameter includes a high throughput mode flag indicating whether the at least one slice is encoded in a high throughput mode.

[0113] In some embodiments, the first parameter includes a residual data bit shift flag indicating whether residual data bits are shifted in the residual coding of the at least one slice.

[0114] In some embodiments, the value of the second flag is encoded in a header extension of the sequence of images.

[0115] In some embodiments, the value of the first parameter is encoded in a header of the at least one slice.

[0116] In some embodiments, the processor determines a value of a second parameter in the header extension parameter set for the at least one slice. In some embodiments, the processor determines a value of a third flag indicating whether the second parameter is enabled for the sequence of images based on the value of the second parameter. In some embodiments, the processor encodes the at least one slice into the bitstream based on the value of the first parameter and the value of the second parameter. In some embodiments, the processor encodes the value of the first flag, the value of the second flag, the value of the first parameter, and the value of the second parameter into the bitstream.

[0117] According to yet another aspect of the present invention, a video encoding system comprises a memory configured to store instructions and a processor coupled to the memory. The video includes a sequence of images, each of the images including one or more slices. The processor is configured to determine, when executing the instructions, a value of a first parameter in a header extension parameter set for at least one of the slices in the sequence of images. The processor is further configured to determine, when executing the instructions, a value of a first flag indicating whether the header extension parameter set is present based on the value of the first parameter. The processor is further configured to determine, when executing the instructions, a value of a second flag indicating whether the first parameter is enabled for the sequence of images based on the value of the first parameter. The processor is further configured to encode, when executing the instructions, the at least one slice into a bitstream based on the value of the first parameter, and encode the value of the first flag, the value of the second flag, and the value of the first parameter into the bitstream.

[0118] In some embodiments, the first parameter includes a last significant coefficient inverse flag indicating a reference location for referencing the location of the last significant coefficient.

[0119] In some embodiments, the first parameter includes a high throughput mode flag indicating whether at least one slice is encoded in a high throughput mode.

[0120] In some embodiments, the first parameter includes a residual data bit shift flag indicating whether residual data bits are shifted in the residual coding of the at least one slice.

[0121] In some embodiments, the value of the second flag is encoded in a header extension of the sequence of images.

[0122] In some embodiments, the value of the first parameter is encoded in a header of the at least one slice.

[0123] In some embodiments, the processor is further configured to determine a value of a second parameter in the header extension parameter set for the at least one slice. In some embodiments, the processor is further configured to determine a value of a third flag indicating whether the second parameter is enabled for the sequence of images based on the value of the second parameter. In some embodiments, the processor is further configured to encode the at least one slice into the bitstream based on the value of the first parameter and the value of the second parameter. In some embodiments, the processor is further configured to encode the value of the first flag, the value of the second flag, the value of the first parameter, and the value of the second parameter into the bitstream.

[0124] The foregoing description of the embodiments will clarify the general nature of the present invention, and others may easily modify these embodiments and / or adapt these embodiments to various applications without undue experimentation and by applying knowledge of the art, without departing from the general concept of the present invention. Such adaptations and modifications are therefore intended to be within the meaning and range of equivalents of the disclosed embodiments based on the teaching and guidance presented herein. It should be noted that the terms or terms used herein are for the purposes of description and not limitation, and therefore the terms or terms used herein should be interpreted by those skilled in the art in light of the teaching and guidance.

[0125] The embodiments of the present invention are described with the aid of functional building blocks that illustrate implementations of specified functions and their relationships. For convenience of explanation, the boundaries of these functional building blocks have been arbitrarily defined herein. Alternate boundaries may be defined so long as the specified functions and their relationships are appropriately performed.

[0126] The Summary and Abstract may set forth one or more exemplary embodiments of the invention, but not all embodiments of the invention contemplated by the inventors, and thus are not intended to limit the scope of the invention and the appended claims in any way.

[0127] Various functional blocks, modules, and steps are disclosed above. The arrangements provided are exemplary and not limiting. Thus, the functional blocks, modules, and steps may be rearranged or combined in ways different from the examples provided above. Similarly, some embodiments include only a subset of the functional blocks, modules, and steps, and any such subset is permissible.

[0128] The breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

1. 1. A method for decoding a video, the video comprising a sequence of images, each of the images comprising one or more slices, the method comprising: a processor parsing the bitstream to obtain a value of a first flag; the processor determining whether the value of the first flag indicates the presence of a header extension parameter set; in response to the value of the first flag indicating the presence of the header extension parameter set, the processor parses the bitstream to obtain the value of the second flag; the processor determining whether the value of the second flag indicates that a first parameter in the header extension parameter set is enabled for the sequence of images; in response to the value of the second flag indicating that the first parameter is enabled for the sequence of images, the processor parses the bitstream to obtain a value of the first parameter to be used for one of the slices in the sequence of images; the processor decoding the slice based on the value of the first parameter used for the slice.

2. the first parameter includes a last significant coefficient inverse flag indicating a reference position for referencing the position of the last significant coefficient; 10. The video decoding method of claim 1.

3. the first parameter includes a high-throughput mode flag indicating whether the slice is coded in high-throughput mode; 10. The video decoding method of claim 1.

4. the first parameter includes a residual data bit shift flag indicating whether residual data bits are shifted in residual coding of the slice; 10. The video decoding method of claim 1.

5. the value of the second flag is encoded in a header extension of the sequence of images; 10. The video decoding method of claim 1.

6. the value of the first parameter is coded in the header of the slice.

10. The video decoding method of claim 1.

7. The video decoding method includes: In response to the value of the first flag indicating the presence of the header extension parameter set, the processor parses the bitstream to obtain a value of a third flag; the processor determining whether the value of the third flag indicates that a second parameter in the header extension parameter set is enabled for the sequence of images; in response to the value of the third flag indicating that the second parameter is enabled for the sequence of images, the processor parses the bitstream to obtain a value of the second parameter to be used for the slice; the processor decoding the slice based on the value of the first parameter and the value of the second parameter used for the slice.

10. The video decoding method of claim 1.

8. 1. A video decoding system, the video including a sequence of images, each image including one or more slices, the system comprising: a memory configured to store instructions; A video decoding system comprising: a processor coupled to said memory, said processor configured to perform the video decoding method of claim 1 by executing said instructions.

9. 1. A method of encoding a video, the video comprising a sequence of images, each of the images comprising one or more slices, the method comprising: a processor determining a value of a first parameter in a header extension parameter set for at least one said slice in said sequence of images; the processor determining a value of a first flag indicating whether the header extension parameter set is present based on the value of the first parameter; the processor determining, based on the value of the first parameter, a value of a second flag indicating whether the first parameter is enabled for the sequence of images; the processor encoding the at least one slice into a bitstream based on the value of the first parameter; the processor encoding the value of the first flag, the value of the second flag, and the value of the first parameter into the bitstream.

10. the first parameter includes a last significant coefficient inverse flag indicating a reference position for referencing the position of the last significant coefficient; 10. The video encoding method of claim 9.

11. the first parameter includes a high-throughput mode flag indicating whether the at least one slice is coded in a high-throughput mode; 10. The video encoding method of claim 9.

12. the value of the second flag is encoded in a header extension of the sequence of images; 10. The video encoding method of claim 9.

13. the value of the first parameter is coded in a header of the at least one slice.

10. The video encoding method of claim 9.

14. The video encoding method comprises: the processor determining a value of a second parameter in the header extension parameter set for the at least one slice; the processor determining, based on the value of the second parameter, a value of a third flag indicating whether the second parameter is enabled for the sequence of images; the processor encoding the at least one slice into the bitstream based on the value of the first parameter and the value of the second parameter; the processor encoding the value of the first flag, the value of the second flag, the value of the first parameter, and the value of the second parameter into the bitstream.

10. The video encoding method of claim 9.

15. 1. A video coding system, wherein the video comprises a sequence of images, each of the images comprising one or more slices, the system comprising: a memory configured to store instructions; A video encoding system comprising: a processor coupled to said memory, said processor configured to perform the video encoding method of claims 9 to 14 by executing said instructions.

16. A computer-readable storage medium on which a computer program and a bitstream are stored, the computer program causing a processor to execute a video encoding method according to any one of claims 9 to 14 to generate the bitstream.

Images