Systems and methods including syntax design for multi-symbol arithmetic coding

Abstract

A system and method for encoding and decoding using syntax design for multi-symbol arithmetic coding are provided. The method includes receiving a coded video bitstream including a plurality of syntax elements, determining a first maximum alphabet size for arithmetic coding by an arithmetic coding engine, wherein the first maximum alphabet size is determined based on hardware constraints, determining a second maximum alphabet size smaller than the first maximum alphabet size, and decoding the plurality of syntax elements included in the coded video bitstream based on the determined second maximum alphabet size, wherein each of the plurality of syntax elements is entropy coded with an alphabet size less than or equal to the determined second maximum alphabet size.

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 358,309, filed on July 5, 2022, and U.S. Patent Application No. 17 / 983,876, filed on November 9, 2022, the disclosures of which are hereby incorporated by reference in their entireties.

[0002] Embodiments of the present disclosure relate to advanced video coding techniques, and more particularly, to syntax design for multi - symbol arithmetic coding.

Background Art

[0003] AOMedia Video 1 (AV1) is an open video coding format designed for video transmission over the Internet. Developed by the Alliance for Open Media (AOMedia), a consortium established in 2015 as a successor to VP9, it includes semiconductor companies, video - on - demand providers, video content producers, software development companies, and web browser vendors. Many of the components of the AV1 project were provided from previous research efforts by the Alliance's members. Individual contributors started experimental technology platforms several years ago, i.e., Xiph's / Mozilla's Daala had already made its code public in 2010, Google's experimental VP9 evolution project VP10 was announced on September 12, 2014, and Cisco's Thor was made public on August 11, 2015. Based on the construction of the VP9 codebase, AV1 incorporates additional technologies, some of which were developed in these experimental formats. The first version 0.1.0 of the AV1 reference codec was made public on April 7, 2016. The Alliance released the AV1 bitstream specification on March 28, 2018, along with a reference software - based encoder and decoder. On June 25, 2018, the valid version 1.0.0 of this specification was released. On January 8, 2019, the valid version 1.0.0 including Errata1 of this specification was released. The AV1 bitstream specification includes a reference video codec.

Summary of the Invention

Means for Solving the Problems

[0004] According to an embodiment, a method performed by a decoder is provided. The method includes receiving a coded video bitstream including a plurality of syntax elements, determining a first maximum alphabet size for arithmetic coding by an arithmetic coding engine, wherein the first maximum alphabet size is determined based on hardware constraints, determining a second maximum alphabet size smaller than the first maximum alphabet size, and decoding the plurality of syntax elements included in the coded video bitstream based on the determined second maximum alphabet size, wherein each of the plurality of syntax elements is entropy-coded with an alphabet size less than or equal to the determined second maximum alphabet size.

[0005] According to one or more embodiments, the second maximum alphabet size is an integer value between 2 and 15, inclusive.

[0006] According to one or more embodiments, the plurality of syntax elements includes a first syntax element that is a set index indicating in which of a set of sets a selected one of symbols is, and a second syntax element that is an index indicating which of the symbols in a selected one of the sets is used for encoding or decoding.

[0007] According to one or more embodiments, the symbol is a class of motion vector differences, the alphabet size of the first syntax element is 2, and the total number of classes of motion vector differences in each of the sets is 3 and 8, respectively.

[0008] According to one or more embodiments, the symbol is a class of motion vector differences, the alphabet size of the first syntax element is 3, and the total number of classes of motion vector differences in each of the sets is 3, 4, and 4, respectively.

[0009] According to one or more embodiments, each symbol indicates the absolute value of a scaling parameter for chroma from a luminance (CfL) mode.

[0010] According to one or more embodiments, each symbol is a mode of luma intra mode coding.

[0011] According to one or more embodiments, each symbol is a mode of chroma intra mode coding.

[0012] According to one or more embodiments, each symbol is a waffle pattern.

[0013] According to one or more embodiments, each symbol is an end of block (eob) value.

[0014] According to an embodiment, a system is provided. The system includes at least one memory configured to store computer program code, and at least one processor configured to receive a coded video bitstream including a plurality of syntax elements, access the computer program code, and operate as instructed by the computer program code. The computer program code includes a first determination code configured to cause the at least one processor to determine a first maximum alphabet size for arithmetic coding by an arithmetic coding engine, where the first maximum alphabet size is determined based on hardware constraints; a second determination code configured to cause the at least one processor to determine a second maximum alphabet size smaller than the first maximum alphabet size; and a decoding code configured to cause the at least one processor to decode the plurality of syntax elements included in the coded video bitstream based on the determined second maximum alphabet size, where each of the plurality of syntax elements is entropy-coded with an alphabet size less than or equal to the determined second maximum alphabet size.

[0015] According to one or more embodiments, the second maximum alphabet size is an integer value between 2 and 15, inclusive.

[0016] According to one or more embodiments, the plurality of syntax elements includes a first syntax element that is a set index indicating in which set of sets a selected one of the symbols is, and a second syntax element that is an index indicating which symbol in a selected one of the sets is used for encoding or decoding.

[0017] According to one or more embodiments, the symbol is a class of motion vector differences, the alphabet size of the first syntax element is 2, and the total number of classes of motion vector differences within each of the sets is 3 and 8, respectively.

[0018] According to one or more embodiments, the symbol is a class of motion vector differences, the alphabet size of the first syntax element is 3, and the total number of classes of motion vector differences within each of the sets is 3, 4, and 4, respectively.

[0019] According to one or more embodiments, each symbol indicates the absolute value of the scaling parameter for chroma from the luma (CfL) mode.

[0020] According to one or more embodiments, each symbol is a mode of luma intra mode coding.

[0021] According to one or more embodiments, each symbol is a mode of chroma intra mode coding.

[0022] According to one or more embodiments, each symbol is a wavelet pattern.

[0023] According to an embodiment, a non-transitory computer-readable medium storing computer code is provided. When the computer code is executed by at least one processor, the at least one processor is caused to receive a coded video bitstream including a plurality of syntax elements, determine a first maximum alphabet size for arithmetic coding by an arithmetic coding engine, the first maximum alphabet size being determined based on hardware constraints, determine a second maximum alphabet size smaller than the first maximum alphabet size, and decode the plurality of syntax elements included in the coded video bitstream based on the determined second maximum alphabet size, each of the plurality of syntax elements being entropy-coded with an alphabet size less than or equal to the determined second maximum alphabet size, and is configured to implement a decoder.

[0024] Further features, properties, and various advantages of the disclosed subject matter will become more apparent from the following detailed description and the accompanying drawings.

Brief Description of the Drawings

[0025]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Mode for Carrying Out the Invention

[0026] The following detailed description of the exemplary embodiments refers to the accompanying drawings. The same reference numerals in different drawings may identify the same or similar elements.

[0027] The foregoing disclosure provides examples and explanations, but is not intended to be exhaustive or to limit the implementation forms to the exact forms disclosed. Modifications and variations are possible in light of the disclosure or may be obtained from the practice of the implementation forms. Further, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). In addition, in the flowcharts and descriptions of operations provided below, one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least partially), and the order of one or more operations may be interchanged.

[0028] It will be apparent that the systems and / or methods described herein may be implemented in different forms of hardware, software, or a combination of hardware and software. It should be understood that the actual dedicated control hardware or software code used to implement these systems and / or methods does not limit the implementation forms. It should be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0029] The features described below may be used separately or combined in any order. Further, embodiments may be implemented by a processing circuit (e.g., one or more processors or one or more integrated circuits). In one example, one or more processors execute a program stored in a non-transitory computer-readable medium.

[0030] Elements, operations, or instructions used in this specification should not be construed as important or essential unless explicitly described as such. Also, as used in this specification, the articles “a” and “an” are intended to include one or more items and may be used interchangeably with “one or more.” When only one item is intended, the term “one” or similar words are used. Also, terms such as “has,” “have,” “having,” “include,” “including,” etc. used in this specification are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “at least partially based on” unless otherwise specified. Further, expressions such as “at least one of A and B” or “at least one of A or B” should be understood to include only A, only B, or both A and B.

[0031] FIG. 1 illustrates a simplified block diagram of a communication system 100 according to an embodiment of the present disclosure. The communication system 100 may include at least two terminals 110, 120 interconnected via a network 150. In the case of unidirectional data transmission, the first terminal 110 may code video data at a local location for transmission to the other terminal 120 via the network 150. The second terminal 120 may receive the coded video data of the other terminal from the network 150, decode the coded data, and display the restored video data. Unidirectional data transmission may be common in media providing applications and the like.

[0032] FIG. 1 illustrates a second pair of terminals 130, 140 provided to support two-way transmission of coded video that may occur, for example, during a video conference. In the case of two-way transmission of data, each terminal 130, 140 may code video data captured at a local location for transmission to other terminals via network 150. Each terminal 130, 140 may also receive coded video data transmitted by other terminals, may decode the coded data, and may display the restored video data on a local display device.

[0033] In FIG. 1, terminals 110-140 may be shown as servers, personal computers, and smartphones, and / or any other type of terminal. For example, terminals 110-140 may be laptop computers, tablet computers, media players, and / or dedicated video conferencing equipment. Network 150 represents any number of networks that transmit decoded video data among terminals 110-140, including, for example, wired and / or wireless communication networks. Communication network 150 may exchange data over circuit-switched and / or packet-switched channels. Representative networks include telecommunications networks, local area networks, wide area networks, and / or the Internet. For the purposes of this discussion, the architecture and topology of network 150 may not be important to the operation of the present disclosure, unless otherwise described herein below.

[0034] FIG. 2 shows the placement of a video encoder and a video decoder in a streaming environment as an example of an application for the disclosed subject matter. The disclosed subject matter may be equally applicable to other video-enabled applications, including, for example, video conferencing, digital TV, storage of compressed video on digital media such as CDs, DVDs, memory sticks, and the like.

[0035] As shown in FIG. 2, the streaming system 200 may include a capture subsystem 213 that can include a video source 201 and an encoder 203. The video source 201 may be, for example, a digital camera and may be configured to create an uncompressed video sample stream 202. The uncompressed video sample stream 202 may provide a high data volume compared to an encoded video bitstream and can be processed by an encoder 203 coupled to the video source 201. As will be described in detail below, the encoder 203 can include hardware, software, or a combination thereof to enable or implement aspects of the disclosed subject matter. The encoded video bitstream 204 may include a lower data volume compared to the sample stream and can be stored in a streaming server 205 for future use. One or more streaming clients 206 can access the streaming server 205 to obtain a video bitstream 209 that can be a copy of the encoded video bitstream 204.

[0036] In an embodiment, the streaming server 205 may also function as a Media-Aware Network Element (MANE). For example, the streaming server 205 may be configured to prune the encoded video bitstream 204 to match one or more of the streaming clients 206 with potentially different bitstreams. In an embodiment, the MANE may be provided separately from the streaming server 205 in the streaming system 200.

[0037] The streaming client 206 can include a video decoder 210 and a display 212. The video decoder 210 can decode, for example, a video bitstream 209 that is an input copy of the encoded video bitstream 204, and generate an output video sample stream 211 that can be rendered on the display 212 or another rendering device (not shown). In some streaming systems, the video bitstreams 204, 209 can be encoded according to a particular video coding / compression standard. Examples of such standards include, but are not limited to, ITU-T Recommendation H.265. A video coding standard, informally known as Versatile Video Coding (VVC), is under development. Embodiments of the present disclosure can be used in the context of VVC.

[0038] FIG. 3 shows an exemplary functional block diagram of a video decoder 210 attached to a display 212 according to an embodiment of the present disclosure.

[0039] The video decoder 210 can include a channel 312, a receiver 310, a buffer memory 315, an entropy decoder / parser 320, a scaler / inverse transform unit 351, an intra-picture prediction unit 352, a motion compensation prediction unit 353, an aggregator 355, a loop filter unit 356, a reference picture memory 357, and a current picture memory. In at least one embodiment, the video decoder 210 can include an integrated circuit, a series of integrated circuits, and / or other electronic circuits. The video decoder 210 may also be partially or fully embodied in software executed on one or more CPUs with associated memory.

[0040] In this and other embodiments, the receiver 310 may receive one or more coded video sequences in which one coded video sequence is decoded by the decoder 210 at a time, and the decoding of each coded video sequence is independent of other coded video sequences. The coded video sequences may be received from the channel 312, which may be a hardware / software link to a storage device storing the encoded video data. The receiver 310 may receive the video data encoded with other data, such as coded audio data and / or auxiliary data streams, which may be transferred to respective using entities (not shown). The receiver 310 may separate the coded video sequences from other data. To suppress network jitter, the buffer memory 315 may be coupled between the receiver 310 and the entropy decoder / parser 320 (hereinafter, "parser"). When the receiver 310 is receiving data from a sufficient bandwidth and controllable memory / transfer device or from an isochronous network, the buffer memory 315 may not be used or may be made smaller. When used in a best effort packet network such as the Internet, the buffer memory 315 may be required and may be relatively large and may be of an adaptable size.

[0041] Video decoder 210 may include a parser 320 for reconstructing symbol 321 from an entropy-coded video sequence. The categories of these symbols include, for example, information used to manage the operation of decoder 210 and potentially information for controlling a rendering device such as display 212 that may be coupled to the decoder as shown in FIG. 2. Control information for the (one or more) rendering devices may be in the form of a Supplementary Enhancement Information (SEI) message or a Video Usability Information (VUI) parameter set fragment (not shown). Parser 320 may parse / entropy-decode the received coded video sequence. The coding of the coded video sequence may follow video coding techniques or standards and may follow principles well known to those skilled in the art, including variable length coding, Huffman coding, arithmetic coding with or without context dependence, etc. Based on at least one parameter corresponding to a group, parser 320 may extract a set of at least one subgroup parameter of a subgroup of pixels within the video decoder from the coded video sequence. The subgroups may include, for example, Group of Pictures (GOP), picture, tile, slice, macroblock, coding unit (CU), block, transform unit (TU), prediction unit (PU), etc. Parser 320 may also extract from coded video sequence information such as transform coefficients, quantization parameter values, motion vectors, etc.

[0042] Parser 320 may perform an entropy-decoding / parsing operation on the video sequence received from buffer memory 315 to create symbol 321.

[0043] The reconstruction of symbol 321 can include a plurality of different units depending on the type of the coded video picture or a part thereof (e.g., between pictures and within pictures, between blocks and within blocks), and other factors. Which units are included and how they are included can be controlled by subgroup control information parsed from the video sequence coded by parser 320. Such a flow of subgroup control information between parser 320 and the following plurality of units is not shown for clarity.

[0044] Beyond the function blocks already described, decoder 210 can be conceptually subdivided into several functional units as described below. In an actual implementation operating under commercial constraints, many of these units can interact closely with each other and can be at least partially integrated with each other. However, for the purpose of explaining the disclosed subject matter, the following conceptual subdivision into functional units is appropriate.

[0045] One unit may be a scaler / inverse transform unit 351. The scaler / inverse transform unit 351 can receive, as symbol 321 from parser 320, quantized transform coefficients, as well as control information including the transform to use, block size, quantization coefficients, quantization scaling matrix, etc. The scaler / inverse transform unit 351 can output a block including sample values that can be input to aggregator 355.

[0046] In some cases, the output samples of the scaler / inverse transform unit 351 may be related to blocks that are intra-coded, i.e., blocks that do not use prediction information from previously reconstructed pictures, but can use prediction information from previously reconstructed parts of the current picture. Such prediction information can be provided by the intra-picture prediction unit 352. In some cases, the intra-picture prediction unit 352 uses the surrounding already reconstructed information fetched from the current (partially reconstructed) picture in the current picture memory 358 to generate a block of the same size and shape as the block being reconstructed. The aggregator 355 may, in some cases, add, sample by sample, the prediction information generated by the intra-picture prediction unit 352 to the output sample information provided by the scaler / inverse transform unit 351.

[0047] In other cases, the output samples of the scaler / inverse transform unit 351 may be related to inter-coded and potentially motion-compensated blocks. In such cases, the motion compensation prediction unit 353 can access the reference picture memory 357 to fetch the samples used for prediction. After motion-compensating the samples fetched by the symbol 321 related to the block, these samples can be added by the aggregator 355 to the output of the scaler / inverse transform unit 351 (in this case, called residual samples or a residual signal) to generate output sample information. The address in the reference picture memory 357 where the motion compensation prediction unit 353 fetches the prediction samples can be controlled by the motion vector. The motion vector can be available to the motion compensation prediction unit 353, for example, in the form of a symbol 321 that can have X, Y, and reference picture components. Motion compensation can also include interpolation of the sample values fetched from the reference picture memory 357 when an exact sub-sample motion vector is used, a motion vector prediction mechanism, etc.

[0048] The output samples of aggregator 355 may depend on various loop filtering techniques in loop filter unit 356. Video compression techniques are controlled by parameters included in the coded video bitstream and can include in-loop filter techniques made available to loop filter unit 356 as symbol 321 from parser 320, but can also respond to meta information obtained during the decoding of previous (in decoding order) parts of the coded picture or coded video sequence, and can also respond to previously reconstructed and loop filtered sample values.

[0049] The output of loop filter unit 356 can be output to a rendering device such as display 212 and can be a sample stream that can also be stored in reference picture memory 357 for use in future inter-picture prediction.

[0050] Once fully reconstructed, a particular coded picture can be used as a reference picture for future prediction. When the coded picture is fully reconstructed and the coded picture is identified as a reference picture (e.g., by parser 320), the current reference picture can become part of reference picture memory 357 and a new current picture memory can be reallocated before starting the reconstruction of the next coded picture.

[0051] The video decoder 210 can perform a decoding operation by a predetermined video compression technique that can be documented in a standard such as ITU-T Rec.H.265. The coded video sequence can conform to the syntax specified by the video compression technique or standard being used, in the sense of being faithful to the syntax of the video compression technique or standard, as specified in the video compression technique document or standard, specifically the profile document therein. Also, in order to conform to some video compression techniques or standards, the complexity of the coded video sequence can also be within the range defined by the level of the video compression technique or standard. In some cases, the level limits, for example, the maximum picture size, the maximum frame rate, the maximum reconstruction sample rate (measured, for example, in megasamples per second), the maximum reference picture size, etc. The limits set by the level can, in some cases, be further restricted by the specifications of the hypothetical reference decoder (HRD) and the metadata for HRD buffer management signaled in the coded video sequence.

[0052] In one embodiment, the receiver 310 can receive additional (redundant) data accompanying the encoded video. The additional data can be included as part of the coded video sequence. The additional data can be used by the video decoder 210 to properly decode the data and / or to more accurately reconstruct the original video data. The additional data can be in the form of, for example, a temporal layer, a spatial layer, or an SNR enhancement layer, a redundant slice, a redundant picture, a forward error correction code, etc.

[0053] FIG. 4 shows an exemplary functional block diagram of a video encoder 203 associated with a video source 201 according to an embodiment of the present disclosure.

[0054] The video encoder 203 may include, for example, an encoder such as the source coder 430, a coding engine 432, a (local) decoder 433, a reference picture memory 43, a predictor 435, a transmitter 440, an entropy coder 445, a controller 450, and a channel 460.

[0055] The encoder 203 may receive video samples from a video source 201 (which is not part of the encoder) that can capture the video images to be coded by the encoder 203.

[0056] The video source 201 can provide the source video sequence to be coded by the encoder 203 in the form of a digital video sample stream that can be of any suitable bit depth (e.g., 8 bits, 10 bits, 12 bits,...), any color space (e.g., BT.601 Y CrCB, RGB,...), and a suitable sampling structure (e.g., Y CrCb 4:2:0, Y CrCb 4:4:4). In a media serving system, the video source 201 can be a storage device that stores previously prepared video. In a video conferencing system, the video source 201 can be a camera that captures local image information as a video sequence. The video data may be provided as a plurality of individual pictures that convey motion when viewed in sequence. The pictures themselves may be organized as a spatial array of pixels, and each pixel can include one or more samples depending on the sampling structure, color space, etc. used. Those skilled in the art can easily understand the relationship between pixels and samples. The following description focuses on samples.

[0057] According to one embodiment, encoder 203 can compress pictures of the source video sequence into the coded video sequence 443 by coding the pictures of the source video sequence in real time or under any other arbitrary time constraints required by the application. Enforcing an appropriate coding speed is a function of controller 450. Controller 450 may also control other functional units and may be functionally coupled to these units as will be described below. For clarity, the couplings are not shown. Parameters set by controller 450 can include rate control related parameters (such as picture skip, quantizer, lambda value of rate distortion optimization techniques), picture size, Group of Pictures (GOP) layout, maximum motion vector search range, and the like. Those skilled in the art can easily identify other functions of controller 450 since they may be related to video encoder 203 optimized for a particular system design.

[0058] Some video encoders operate in what those skilled in the art would readily recognize as a "coding loop". As an overly simplified explanation, the coding loop can consist of an encoding portion of the source coder 430 (which is responsible for creating symbols based on the input picture to be coded and the (one or more) reference pictures), and a (local) decoder 433 incorporated into the encoder 203 that reconstructs symbols to create sample data that a (remote) decoder would also create when the compression between the symbols and the coded video bitstream is reversible in a particular video compression technique. The reconstructed sample stream can be input into the reference picture memory 434. Since decoding the symbol stream results in the bits being exactly the same regardless of the location of the decoder (local or remote), the contents of the reference picture memory are also bit-exact between the local encoder and the remote encoder. In other words, the prediction portion of the encoder "sees" the same sample values as reference picture samples that the decoder will "see" when using prediction during decoding. This basic principle of reference picture synchronization (and the resulting drift if, for example, synchronization cannot be maintained due to channel errors) is known to those skilled in the art.

[0059] The operation of the "local" decoder 433 can be the same as that of the "remote" decoder 210, which has already been described in detail above in relation to Figure 3. However, since the symbols are available and the encoding / decoding of the symbols into the coded video sequence by the entropy coder 445 and the parser 320 can be reversible, the entropy decoding portion of the decoder 210, which includes the channel 312, the receiver 310, the buffer memory 315, and the parser 320, may not be fully implemented in the local decoder 433.

[0060] At this point, it can be said that any decoder technology other than the parse / entropy decoding existing in the decoder may need to exist in substantially the same functional form in the corresponding encoder. For this reason, the disclosed subject matter focuses on decoder operations. Since the description of encoder technologies can be the reverse of the decoder technologies described comprehensively, it can be omitted. Only in certain areas is a more detailed description needed, which is shown below.

[0061] As part of its operation, the source coder 430 can perform motion-compensated predictive coding, which predictively codes an input frame by referring to one or more previously coded frames from a video sequence designated as a "reference frame". In this way, the coding engine 432 codes the difference between a pixel block of the input frame and a pixel block of a reference frame that can be selected as a predictive reference to the input frame.

[0062] The local decoder 433 can decode the coded video data of a frame that can be designated as a reference frame based on the symbols created by the source coder 430. The operation of the coding engine 432 can advantageously be an irreversible process. When the coded video data can be decoded by a video decoder (not shown in FIG. 4), the reconstructed video sequence can usually be a replica of the source video sequence with some error. The local decoder 433 can reproduce the decoding process that can be performed by the video decoder for the reference frame and store the reconstructed reference frame in the reference picture memory 434. In this way, the encoder 203 can locally store a copy of the reconstructed reference frame having common content as the reconstructed reference frame obtained by the remote video decoder (without transmission errors).

[0063] Predictor 435 can perform predictive search for the coding engine 432. That is, for a new frame to be coded, predictor 435 can search the reference picture memory 434 to find sample data (as candidate reference pixel blocks) or specific metadata such as reference picture motion vectors and block shapes, which can function as appropriate predictive references for the new picture. Predictor 435 can operate on the sample blocks for each pixel block to find an appropriate predictive reference. In some cases, the input picture can have predictive references drawn from a plurality of reference pictures stored in the reference picture memory 434, as determined by the search results obtained by predictor 435.

[0064] Controller 450 can manage the coding operations of source coder 430, including, for example, setting parameters and subgroup parameters used for encoding video data.

[0065] The outputs of all the aforementioned functional units can be subjected to entropy coding by entropy coder 445. The entropy coder converts the symbols generated by various functional units into a coded video sequence by reversibly compressing the symbols using techniques known to those skilled in the art, such as Huffman coding, variable length coding, arithmetic coding, etc.

[0066] Transmitter 440 can buffer the coded video sequence created by entropy coder 445 and prepare it for transmission via communication channel 460, which can be a hardware / software link to a storage device that stores the encoded video data. Transmitter 440 can merge the coded video data from source coder 430 with other data to be transmitted, such as coded audio data and / or auxiliary data streams (sources not shown).

[0067] The controller 450 can manage the operation of the encoder 203. During coding, the controller 450 may assign a specific coded picture type to each coded picture, which may affect the coding techniques applicable to each picture. For example, a picture can often be assigned as an intra picture (I picture), a predicted picture (P picture), or a bi - directionally predicted picture (B picture).

[0068] An intra picture (I picture) can be a picture that can be coded and decoded without using any other frame in the sequence as a source of prediction. Some video codecs allow various types of intra pictures, such as, for example, an Instantaneous Decoder Refresh (IDR) picture. Those skilled in the art are aware of these variations of I pictures and their respective uses and characteristics.

[0069] A predicted picture (P picture) can be one that can be coded and decoded using intra prediction or inter prediction that uses at most one motion vector and a reference index to predict the sample values of each block.

[0070] A bi - directionally predicted picture (B picture) can be one that can be coded and decoded using intra prediction or inter prediction that uses at most two motion vectors and reference indices to predict the sample values of each block. Similarly, multiple predicted pictures can use more than two reference pictures and associated metadata for the reconstruction of a single block.

[0071] The source picture is typically spatially subdivided into a plurality of sample blocks (e.g., 4×4, 8×8, 4×8, or 16×16 sample blocks each), and can be coded block by block. The blocks can be coded predictively by referring to other (already coded) blocks as determined by the coding assignment applied to each block of the picture. For example, blocks of an I picture may be coded non-predictively, or may be coded predictively by referring to already coded blocks of the same picture (spatial prediction or intra prediction). Pixel blocks of a P picture can be coded non-predictively via spatial prediction or via temporal prediction that refers to one previously coded reference picture. Blocks of a B picture may be coded non-predictively, via spatial prediction, or via temporal prediction by referring to one or two previously coded reference pictures.

[0072] Video encoder 203 can perform coding operations according to a predetermined video coding technology or standard such as ITU-T Recommendation H.265. In its operation, video encoder 203 may perform various compression operations, including predictive coding operations that utilize temporal and spatial redundancies in the input video sequence. Thus, the coded video data can conform to the syntax specified by the video coding technology or standard being used.

[0073] In one embodiment, transmitter 440 can transmit additional data with the encoded video. Source coder 430 can include such data as part of the coded video sequence. The additional data can include, for example, temporal / spatial / SNR extension layers, other forms of redundant data such as redundant pictures and slices, supplementary enhancement information (SEI) messages, and visual user utility information (VUI) parameter set fragments.

[0074] [Context-Adaptive Arithmetic Coding Engine in HEVC and VVC] The context adaptive arithmetic coding (CABAC) engines in HEVC and VVC can use a table-based probability transition process among 64 different representative probability states. In HEVC, the range ivlCurrRange representing the state of the coding engine can be quantized into a set of four values before the calculation of the new interval range. The HEVC state transition may be implemented using a table containing all 64×4 8-bit pre-computed values for approximating the value of ivlCurrRange*pLPS(pStateIdx), where pLPS is the probability of the least probable symbol (LPS) and pStateIdx is the index of the current state. Also, the decoding decision may be implemented using one pre-computed look-up table (LUT). First, ivlLpsRange can be obtained using the LUT as shown in Equation 1 below. Then, ivlLpsRange can be used to update ivlCurrRange and calculate the output binVal. ivlLpsRange = rangeTabLps[pStateIdx][qRangeIdx] (Equation 1)

[0075] In VVC, the probability can be linearly represented by the probability index pStateIdx. Therefore, all calculations may be performed by formulas without LUT operations. To improve the accuracy of probability estimation, a multiple hypothesis probability update model can be applied. The pStateIdx used in interval subdivision in the binary arithmetic coder may be a combination of two probabilities pStateIdx0 and pStateIdx1. The two probabilities may be associated with each context model and updated independently at different adaptation rates. The adaptation rates of pStateIdx0 and pStateIdx1 for each context model can be pre-trained based on the statistics of the related bins. The probability estimation value pStateIdx may be the average of the estimated values from two hypotheses.

[0076] FIG. 5 shows an embodiment of a process (500) for decoding a single binary decision. Process 500 may begin at operation 502 to determine the value of variable ivlCurrRange. In operation 504, if the variable ivlCurrRange is less than or equal to the variable ivlOffset, the process proceeds to operation 506 to update the values of variables binVal, ivlOffset, and ivlCurrRange. If the variable ivlCurrRange is greater than the value of the variable ivlOffset, the process proceeds to operation 508 to update the value of variable binVal. The process proceeds from either operation 506 or operation 508 to operation 510 to update variables pStateIdx0 and pStateIdx1. The process proceeds to operation 512 to perform the RenormD process.

[0077] Similar to what is done in HEVC, VVC CABAC may also have a quantization parameter QP-dependent initialization process that is called at the start of each slice. Given the initial value of the slice's luma QP, the initial probability state of the context model, denoted as preCtxState, can be derived as follows in Equations 2-4. m = slopeIdx × 5 - 45 (Equation 2) n = (offsetIdx << 3) + 7 (Equation 3) preCtxState = Clip3(1, 127, ((m × (QP - 32)) >> 4) + n) (Equation 4) Here, slopeIdx and offsetIdx are limited to 3 bits, and the total initialization value can be represented with 6-bit precision. The probability state preCtxState can directly represent the probability in the linear region. Thus, referring to Equations 5-6, preCtxState only needs an appropriate shift operation before being input to the arithmetic coding engine, and the logarithmic mapping to the linear region and a 256-byte table are stored. pStateIdx0 = preCtxState << 3 (Equation 5) pStateIdx1 = preCtxState << 7 (Equation 6)

[0078] [Multi-symbol Arithmetic Coding in AV1] In AV1, an M-ary arithmetic coding engine can be used to entropy code syntax elements. Each syntax element may be associated with an alphabet of M elements, where M can be any integer value between 2 and 16. The input to the encoding can be a coding context that can include an M-ary symbol and a set of M probabilities represented by a cumulative distribution function (CDF). The probabilities may be updated after each syntax element is coded / parsed. The cumulative distribution function may be an array of M 15-bit integers as follows in Equation 7. C = [c0, c1, …, c (M-2) ,2 15 (Equation 7) Here, c n / 32768 is the probability that the symbol is less than or equal to n.

[0079] Probability updates can be performed using Equation 8 below. [Number] Here, α is a probability update rate (e.g., up to 32) that adapts based on the number of times the symbol has been decoded, and m is the index of the element within the CDF.

[0080] This adaptation of α enables faster probability updates at the start of coding / parsing of syntax elements. The M-ary arithmetic coding process can follow the conventional arithmetic coding engine design. However, only the most significant 9 bits of the 15-bit probability values may be input to the arithmetic encoder / decoder. The probability update rate α associated with a symbol may be calculated based on the number of occurrences of the associated symbol when analyzing the bitstream, and the value of α can be reset at the start of a frame or tile using Equation 9 below. [Number]

[0081] From Equation 9, the probability update rate initially has a larger value and then saturates after occurring 32 times.

[0082] [Multiple Hypothesis Arithmetic Coding] A multiple hypothesis probability model for encoding M-ary symbols can be provided. For example, the method can include modifications to the AV1 arithmetic coding engine related to multiple hypothesis estimation. For example, AV1 uses a data-adaptive model for probability updates, and the update rate is higher when the occurrence of syntax elements is less and lower when there are more observations. However, only a single probability model is used by the engine. Multiple hypothesis estimation that maintains two or more probability tables with different update rates for each syntax element can provide additional compression efficiency. Therefore, the multiple hypothesis probability model can be implemented with two update rates shown in Equations 10 - 11 below. [Number] Here, α2 models faster updates and α1 models slower updates. The final probability model can be calculated as a linear combination of the hypotheses. According to one embodiment, the average of the two hypotheses can be used. To adapt to various symbol statistics across frames / tiles, alpha_1 and alpha_2 can be signaled at the frame / tile level.

[0083] [Loop Intra Mode Coding] For a loop-intra-coded block, all available intra prediction modes can be permuted and inserted into the mode list before signaling, where the intra prediction modes of two adjacent blocks can be included in this permutation process. The positions of the two adjacent blocks are shown in FIG. 6. Specifically, FIG. 6 shows the current block 520, as well as the upper block 522 and the left block 524, which are adjacent blocks of the current block 520.

[0084] In particular, this rearrangement process can be defined in the following three steps, namely, (1) always place the DC, SMOOTH, SMOOTH_V, SMOOTH_H, and PAETH modes in the mode list first, (2) for each directional intra prediction mode of adjacent blocks, add the offsets [0, -1, +1, -2, +2, -3, +3, -4, +4] to the directional mode to derive nine modes, and add them to the mode list if they have not been added yet, (3) if the mode list is not full, insert the predefined default mode into the mode list.

[0085] After the above rearrangement process, the intra prediction mode can be divided into five mode sets based on the mode index. The number of modes in each mode set may be 5, 8, 16, 16, and 16. Table 1 below shows the mapping between the rearranged mode index and the mode set index associated with it.

[0086]

Table 1

[0087] To signal the intra prediction mode, a first syntax may be signaled to indicate the mode set index of the intra prediction mode, and a second syntax may be signaled to indicate the mode index of the mode set.

[0088] According to an embodiment, the delta angle may be permitted only when the block size is 8×8 or more in AV1, while the delta angle may be permitted for all block sizes in AI Music Creativity (AIMC). According to an embodiment, in the case of the vertical mode and the horizontal mode, the offset-based intra prediction improvement (ORIP) may always be enabled for 0 reference lines and disabled for non-0 reference lines.

[0089] [Chroma Intra Mode Coding] Since the texture of the chroma component is usually smoother than that of the luma component, for each chroma block, 14 intra prediction modes can be adaptively selected and can be included in only one intra mode set.

[0090] Specifically, the following aspects may be included in the embodiments.

[0091] (1) The context for signaling the chroma mode coding may depend on whether the mode set index of the luma mode located at the same place is 0.

[0092] (2) The chroma nominal mode may be reordered based on the luma intra prediction mode located at the same place. Chroma from the luma (CfL) mode may be first added to the chroma intra mode list. The nominal mode of the luma intra prediction mode located at the same place may be added to the mode list in the case of the directional intra prediction mode. The remaining 12 nominal modes may be added to the mode list in the following order, that is, [DC, SMOOTH, SMOOTH_V, SMOOTH_H, PAETH, VERTICAL, HORIZONTAL, D45_PRED, D67_PRED, D113_PRED, D135_PRED, D157_PRED, D203_PRED].

[0093] (3) The delta angle may not be signaled for the chroma component and may be derived from the luma mode located at the same place. Specifically, when the chroma intra prediction mode is a directional mode and is equal to the intra prediction mode of the luma block located at the same place, the delta angle of the chroma block may be set equal to the delta angle of the luma block located at the same place. Otherwise, the delta angle of the chroma block may be set to 0.

[0094] [Chroma Predicted from Luma] For the chroma component, in addition to 56 directional modes and 5 non - directional modes, CfL can be provided. CfL is an intra - prediction mode for chroma only, which models chroma pixels as a linear function of the corresponding reconstructed luma pixels. The CfL prediction can be expressed as shown below in Equation 12. CfL(α)=α×L AC +DC (Equation 12) Here, L AC represents the AC contribution of the luma component, α represents the scaling parameter of the linear model, and DC represents the DC contribution of the chroma component.

[0095] Figure 7 is a schematic diagram of the CfL prediction process 530. Referring to Figure 7 and Equation 12, the reconstructed luma pixels can be subsampled to the chroma resolution, and then the average value can be subtracted to form the AC contribution. Instead of requiring the decoder to calculate the scaling parameter as in some prior arts to approximate the chroma AC component from the AC contribution, AV1 CfL can determine the scaling parameter α based on the original chroma pixels and signal them within the bitstream. This reduces the complexity of the decoder and obtains a more accurate prediction. The DC contribution of the chroma component can be calculated using the intra - DC mode, which is sufficient for most chroma content and has a mature high - speed implementation form.

[0096] When the CfL mode is selected, the joint sign of the scaling factors of the U and V components can be signaled first. The sign of one scaling factor can be either negative, zero, or positive. In addition, the combination of (zero, zero) may not be permitted in the CfL mode because it results in a "DC" prediction. Thus, the combination of the signs of the two scaling factors can have a total of 8 (3 * 3 - 1 = 8) combinations. As a result, the joint sign may require an 8 - valued symbol. Only one context may be employed to signal the joint sign.

[0097] Regarding the signaling of the magnitude of the scaling parameter, a 16-value symbol is used, which can represent values in the range from 0 to 2 in 1 / 8th steps. The 16-value symbol fully utilizes the capabilities of the multi-symbol entropy encoder. The context for signaling the scaling parameter depends on the value of the joint symbol.

[0098] [Joint Motion Vector Difference Coding in AV1] AV1 enables 1 / 8 pixel motion vector accuracy (or precision), and the following syntax elements are used to signal the motion vector difference for reference frame list 0 or list 1.

[0099] The syntax element mv_joint can specify which components of the motion vector difference are non-zero. For example, a value of 0 may indicate that there is no non-zero MVD along either the horizontal or vertical direction, a value of 1 may indicate that there is a non-zero MVD only along the horizontal direction, a value of 2 may indicate that there is a non-zero MVD only along the vertical direction, and a value of 3 may indicate that there are non-zero MVDs along both the horizontal and vertical directions.

[0100] The syntax element mv_sign can specify whether the motion vector difference is positive or negative.

[0101] The syntax element mv_class can specify the class of the motion vector difference. As shown in Table 2 below, a higher class may mean that the motion vector difference has a larger magnitude.

[0102]

Table 2

[0103] The syntax element mv_bit can specify the integer part of the offset between the motion vector difference and the starting magnitude for each MV class.

[0104] The syntax element mv_fr may specify the first two fractional bits of the motion vector difference.

[0105] The syntax element mv_hp may specify the third fractional bit of the motion vector difference.

[0106] [Problems of Multi-Symbol Arithmetic Coding in AV1] Regarding multi-symbol arithmetic coding in AV1, the M-ary arithmetic coding engine used in AV1 can support syntax elements with an alphabet size of M elements, where M can be any integer value between 2 and 16. In hardware, the arithmetic coding engine must be able to handle the worst-case scenario (an alphabet size of 16), resulting in an increase in chip area and a decrease in throughput.

[0107] [Exemplary Embodiments] The embodiments of the present disclosure may be used individually or in any order in combination. Further, each of the embodiments of the present disclosure (e.g., a method, an encoder, and a decoder) may be implemented by a processing circuit (e.g., one or more processors or one or more integrated circuits). In one example, one or more processors execute a program stored in a non-transitory computer-readable medium.

[0108] The embodiments of the present disclosure may reduce the complexity of the arithmetic coding engine by supporting a reduced alphabet size N (N-ary arithmetic coding engine), where N is less than or equal to M. For this purpose, all entropy-coded syntax elements may need to have an alphabet size of N or less.

[0109] The embodiments of the present disclosure may set the maximum alphabet size to be smaller than the constraints imposed on the hardware.

[0110] Embodiments of the present disclosure may limit the alphabet size of entropy-coded syntax elements to N or less.

[0111] According to an embodiment, N can be any integer value between 2 and 16, such as 2, 4, or 8.

[0112] According to an embodiment, the syntax element mv_class defined in AV1 can have an alphabet size of 11. According to an embodiment, mv_class can specify a class of motion vector differences. When N is less than 16 (e.g., 4 or 8), new syntax elements mv_class_set and mv_class_idx may be defined to replace mv_class, and the alphabet sizes of mv_class_set and mv_class_idx may be N or less. This may be done by grouping the symbols of mv_class into multiple sets and providing an index (e.g., mv_class_set) for each symbol of the set. According to an embodiment, another index (e.g., mv_class_idx) may be provided / signaled to indicate which candidate of the selected set is being used for encoding and decoding. According to an embodiment, the encoder performs the above functions (e.g., defines syntax elements that replace mv_class based on the value of N, groups the symbols of mv_class into multiple sets, and provides an index for each symbol of the set), entropy-encodes the syntax elements to obtain a coded bitstream, and may transmit the coded bitstream to the decoder. According to an embodiment, the decoder receives the coded bitstream transmitted by the encoder, obtains the syntax elements (and their symbols) from the coded bitstream (e.g., by entropy decoding), and may decode the video data of the coded bitstream based on the syntax elements.

[0113] According to one or more embodiments, the alphabet size of mv_class_set is set to 2 (e.g., by an encoder), and the number of grouped MV classes in each mv_class_set is 3 and 8, respectively.

[0114] According to one or more embodiments, the alphabet size of mv_class_set is set to 3 (e.g., by an encoder), and the number of grouped MV classes in each mv_class_set is 3, 4, and 4, respectively.

[0115] According to an embodiment, the syntax elements cfl_alpha_u and cfl_alpha_v defined in AV1 have 16 alphabet sizes. The syntax element cfl_alpha_u may include the absolute value of alpha minus 1 for the U component, and the syntax element cfl_alpha_v may include the absolute value of alpha minus 1 for the V component. According to an embodiment, "alpha" may be a scaling parameter of the CfL mode (e.g., α in Equation 12). When N is less than 16, for example 4 or 8, new syntax elements cfl_alpha_u_set and cfl_alpha_u_idx may be defined to replace cfl_alpha_u, and new syntax elements cfl_alpha_v_set and cfl_alpha_v_idx may be defined to replace cfl_alpha_v, and the alphabet size of each of the new syntax elements is N or less. According to an embodiment, the encoder may perform the above functions (e.g., define syntax elements that replace cfl_alpha_u and cfl_alpha_v based on the value of N and transmit the coded bitstream to the decoder). According to an embodiment, the decoder may receive the coded bitstream transmitted by the encoder, obtain syntax elements (and their symbols) from the coded bitstream (e.g., by entropy decoding), and decode the video data of the coded bitstream based on the syntax elements.

[0116] According to one or more embodiments, candidate CfL alpha values may be grouped into different sets (i.e., CfL alpha value sets), and a set index (e.g., cfl_alpha_u_set, cfl_alpha_v_set) may be signaled to indicate to which set the selected CfL alpha value belongs, and another index (e.g., cfl_alpha_u_idx and cfl_alpha_v_idx) may be signaled to indicate which candidate in the selected set is being used for encoding and decoding. According to an embodiment, the encoder performs the above functions (e.g., defines syntax elements that replace cfl_alpha_u and cfl_alpha_v based on the value of N, groups candidate CfL alpha values into multiple sets, entropy encodes the syntax elements to obtain a coded bitstream, and may transmit the coded bitstream to the decoder). According to an embodiment, the decoder receives the coded bitstream transmitted by the encoder, obtains syntax elements (and their symbols) from the coded bitstream (e.g., by entropy decoding), and may decode the video data of the coded bitstream based on the syntax elements.

[0117] According to one embodiment, candidate CfL alpha values for one or more CfL alpha value sets are predefined.

[0118] According to one embodiment, one or more candidate CfL alpha values of a CfL alpha value set are determined by coding information (e.g., by an encoder or a decoder) including, but not limited to, luma and chroma adjacent reconstructed sample values, alpha values used in adjacent blocks, and block size / shape. In one example, one or more CfL alpha value sets define sets of the most likely CfL alpha values.

[0119] According to one embodiment, the candidate CfL alpha values of one or more CfL alpha value sets are determined based on related alpha values (e.g., by an encoder or a decoder). For example, when there are two sets, one set may be set to include all CfL alpha values less than a threshold value, and the remaining CfL alpha values may be included in the other set. According to an embodiment, the encoder and / or decoder can perform the above functions.

[0120] According to one embodiment, the set index (e.g., cfl_alpha_u_set, cfl_alpha_v_set) is context-coded.

[0121] According to one embodiment, the index that specifies which candidate of the selected set is being used (e.g., cfl_alpha_u_idx and cfl_alpha_v_idx) is decoded without context (i.e., coded with a fixed probability or bypassed when coded).

[0122] According to one embodiment, the set index may be determined based on the previous CfL mode set index or coding information such as the luma and chroma reconstructed pixels of adjacent samples. In this case, the set index can be implicitly signaled. According to an embodiment, the encoder and / or decoder can determine the set index.

[0123] According to one or more embodiments, the alphabet size of cfl_alpha_u_set (and cfl_alpha_v_set) is set to 2 (or 4) (e.g., by the encoder), and the number of candidate CfL alpha values in each set is 8 or 4.

[0124] According to an embodiment, the syntax elements mode_set_index&mode_idx associated with luma intra mode coding have an alphabet size of N or less.

[0125] According to one or more embodiments, the value of mode_set_index is set to 8 (e.g., by an encoder). The number of modes in the first set is set to 5 (e.g., by an encoder), and the number of modes in other sets is set to 8 (e.g., by an encoder).

[0126] According to an embodiment, the syntax elements uv_mode_set_index and uv_mode_idx associated with chroma intra mode coding have an alphabet size of N or less.

[0127] According to one or more embodiments, the value of uv_mode_set_index is set to 2 (e.g., by an encoder), the number of modes in the first set is set to 6 (e.g., by an encoder), and the number of modes in the second set is set to 8 (e.g., by an encoder).

[0128] According to an embodiment, when signaling the wedgelet pattern index (i.e., wedge_idx), all possible wedgelet patterns may be grouped into different sets, and the number of candidate wedgelet patterns in each set may be N or less.

[0129] According to one or more embodiments, the first syntax element wedgelet_set may be signaled to indicate which set of wedgelet patterns (i.e., the wedgelet pattern set) the selected wedgelet pattern is from.

[0130] According to one or more embodiments, the second syntax wedgelet_idx may be signaled to indicate which candidate in the selected wedgelet pattern set is selected for encoding and decoding.

[0131] According to one or more embodiments, one or more of the wavelet pattern sets are generated (e.g., by an encoder or a decoder) based on coding information including, but not limited to, adjacent reconstructed sample values, wavelet patterns used in adjacent blocks, and block size / shape.

[0132] According to one embodiment, one or more of the wavelet pattern sets define a set of the most likely wavelet patterns.

[0133] According to an embodiment, when the number of samples of a residual block is greater than a threshold T, multiple syntax elements are used to signal an eob value. The syntax element eob may be a variable indicating the index of the end of a block. According to an embodiment, the encoder determines whether the number of samples of the residual block is greater than the threshold T, and based on the determination that the number of samples of the residual block is greater than the threshold T, may signal the eob value in a coded bitstream using multiple syntax elements.

[0134] According to one or more embodiments, the value of T is equal to 2^(N - 1).

[0135] According to one or more embodiments, the eob value range is first classified into different groups, and a group index, i.e., eob_group_idx, is first signaled (e.g., in the coded bitstream), and then a selected entry of the selected group is further signaled (e.g., in the coded bitstream) to indicate the eob value. According to an embodiment, the encoder may perform the above functions. According to an embodiment, the decoder receives the coded bitstream transmitted by the encoder, obtains syntax elements from the coded bitstream (e.g., by entropy decoding), and may decode the video data of the coded bitstream based on the syntax elements.

[0136] According to an embodiment, at least one processor and a memory storing computer program instructions (i.e., computer code) may be provided. When the computer program instructions are executed by the at least one processor, they may implement an encoder or a decoder and perform any number of functions described in this disclosure, including the functions performed by the encoder or the decoder.

[0137] For example, referring to FIG. 8, the at least one processor may implement an encoder 702 or a decoder 704. The computer program instructions may include, for example, an encoding (or decoding) code 710 configured to cause the at least one processor to code (or decode) at least one picture received according to an embodiment of this disclosure. The encoding (or decoding) code 710 may include, for example, an alphabet determination code 720, a grouping code 730, a definition code 740, an arithmetic encoding (or decoding) code 750, a determination code 760, and a transmission code 790. Although exemplary codes for performing specific functions are described herein, it will be understood that embodiments of this disclosure may include other codes for performing any other functions described in this disclosure.

[0138] The alphabet determination code 720 may be configured to cause the at least one processor to determine a maximum alphabet size for arithmetic encoding (and / or decoding) according to an embodiment of this disclosure. For example, the alphabet determination code 720 may cause the at least one processor to determine a first maximum alphabet size for arithmetic encoding by an arithmetic coding engine, the first maximum alphabet size being determined based on hardware constraints, and based on the first maximum alphabet size, cause the at least one processor to determine a second maximum alphabet size to be smaller than the first maximum alphabet size.

[0139] The grouping code 730 can be configured to cause at least one processor to group symbols related to video coding into sets. According to an embodiment, the grouping may be performed based on determining that the maximum alphabet size is less than or equal to a predetermined value. For example, the symbols may be a class of motion vector differences, an indication of the absolute value of a scaling parameter for the CfL mode, a mode of luma intra mode coding, a mode of chroma intra mode coding, a wavelet pattern, or an eob value. According to an embodiment, the grouping may group symbols of syntax elements (e.g., mv_class, cfl_alpha_u, and cfl_alpha_v) to replace the syntax elements.

[0140] The definition code 740 can be configured to cause at least one processor to define syntax elements related to symbols according to embodiments of the present disclosure. According to an embodiment, the definition may be performed based on determining that the maximum alphabet size is less than or equal to a predetermined value. According to an embodiment, the newly defined syntax elements can replace the syntax elements.

[0141] The arithmetic encoding (or decoding) code 720 can be configured to cause at least one processor to perform arithmetic encoding on syntax elements or arithmetic decoding on syntax elements to obtain a coded video stream according to embodiments of the present disclosure. For example, the syntax elements may be encoded (or decoded) based on a determined second maximum alphabet size, and each of the plurality of syntax elements is entropy encoded (or decoded) with an alphabet size less than or equal to the determined second maximum alphabet size.

[0142] The decision code 760 can be configured to cause at least one processor to determine a set, a symbol in one or more of the sets, and / or an index based on information (e.g., coding information) according to an embodiment of the present disclosure.

[0143] When an encoder 702 is provided, the computer program instructions can further include a transmission code 790 configured to cause at least one processor to send a bitstream including a coded picture to a decoder (e.g., decoder 704), for example, according to an embodiment of the present disclosure. The encoder 702 can provide information such as the information described in the present disclosure (e.g., syntax elements and their symbols) in the bitstream according to an embodiment of the present disclosure.

[0144] The techniques of the embodiments of the present disclosure described above can be implemented as computer software physically stored on one or more computer-readable media using computer-readable instructions. For example, FIG. 9 shows a computer system 900 suitable for implementing an embodiment of the subject matter of the present disclosure.

[0145] The computer software can be coded using any suitable machine code or computer language that can undergo assembly, compilation, linking, or similar mechanisms to create code including instructions that can be executed directly by a computer central processing unit (CPU), a graphics processing unit (GPU), etc., or through interpretation, microcode execution, etc.

[0146] The instructions can be executed on various types of computers or their components including, for example, personal computers, tablet computers, servers, smartphones, gaming devices, and Internet-of-things devices.

[0147] The components shown in FIG. 9 with respect to computer system 900 are illustrative in nature and are not intended to suggest any limitation as to the use or functionality of the computer software implementing the embodiments of the present disclosure. The configuration of the components should not be construed as having any dependency or requirement regarding any one or combination of the components shown in the exemplary embodiments of computer system 900.

[0148] Computer system 900 may include a specific human interface input device. Such a human interface input device can respond to input by one or more human users via, for example, tactile input (keystrokes, swipes, movement of a data glove, etc.), audio input (voice, clapping, etc.), visual input (gestures, etc.), and olfactory input (not shown). The human interface device can also be used to capture certain media such as audio (voice, music, ambient sound, etc.), images (scanned images, photographic images obtained from a still image camera, etc.), video (2D video, 3D video including stereoscopic video, etc.) that are not necessarily directly related to conscious input by a human.

[0149] The input human interface device may include one or more (only one of each shown) of keyboard 901, mouse 902, trackpad 903, touch screen 910, data glove, joystick 905, microphone 906, scanner 907, and camera 908.

[0150] Computer system 900 may also include certain human interface output devices. Such human interface output devices may, for example, stimulate the senses of one or more human users via tactile output, sound, light, and smell / taste. Such human interface output devices may include tactile output devices (e.g., tactile feedback by touch screen 910, data glove, or joystick 905, although there can also be tactile feedback devices that do not function as input devices). For example, such devices may include audio output devices (such as speaker 909, headphones (not shown), etc.), visual output devices (screens 910 including CRT screens, LCD screens, plasma screens, OLED screens, etc., regardless of whether they have a touch screen input function and regardless of whether they have a tactile feedback function, some of which can output 2D visual output or output beyond 3D through means such as stereographic output, virtual reality glasses (not shown), holographic displays, and smoke tanks (not shown)), and printers (not shown).

[0151] Computer system 900 may also include human - accessible storage devices and associated media, such as optical media with CD / DVD ROM / RW 920 with media 921 such as CD / DVD, thumb drive 922, removable hard drive or solid - state drive 923, legacy magnetic media such as tapes and floppy disks (not shown), special ROM / ASIC / PLD - based devices such as security dongles (not shown), etc.

[0152] Also, those skilled in the art should understand that the term "computer - readable medium" as used in connection with the subject matter of this disclosure does not include transmission media, carrier waves, or other transient signals.

[0153] The computer system 900 can also include an interface to one or more communication networks. The network can be, for example, wireless, wired, or optical. The network can further be local, wide area, metropolitan, vehicle and industrial, real-time, delay tolerant, etc. Examples of networks include local area networks such as Ethernet, wireless LANs, cellular networks including GSM, 3G, 4G, 5G, LTE, etc., TV wired or wireless wide area digital networks including cable TV, satellite TV, terrestrial broadcast TV, and vehicle and industrial including CANBus. A particular network generally requires an external network interface adapter connected to a particular general-purpose data port or peripheral bus 949 (e.g., a USB port of the computer system 900, others are commonly integrated into the core of the computer system 900 by connection to the system bus as described below (e.g., an Ethernet interface to a PC computer system, or a cellular network interface to a smartphone computer system). Using any of these networks, the computer system 900 can communicate with other entities. Such communication can be unidirectional, receive only (e.g., TV broadcast), transmit only unidirectional (e.g., CANbus to a specific CANbus device), or bidirectional, e.g., for other computer systems using local or wide area digital networks. Such communication can include communication to a cloud computing environment 955. Particular protocols and protocol stacks can be used at each of those networks and network interfaces as described above.

[0154] The aforementioned human interface devices, human-accessible storage devices, and network interface 954 can be connected to the core 940 of the computer system 900.

[0155] The core 940 can include one or more central processing units (CPUs) 941, a graphics processing unit (GPU) 942, a special programmable processing unit 943 in the form of a field programmable gate array (FPGA), a hardware accelerator 944 for specific tasks, etc. These devices can be connected via a system bus 948 together with a read-only memory (ROM) 945, a random access memory 946, an internal mass storage device 947 such as an internal hard drive or SSD that is not accessible to the user. In some computer systems, the system bus 948 can be accessible in the form of one or more physical plugs and can be extended by additional CPUs, GPUs, etc. Peripheral devices can be directly connected to the core's system bus 948 or can be connected via a peripheral bus 949. The architecture of the peripheral bus includes PCI, USB, etc. The graphics adapter 950 may be included in the core 940.

[0156] The CPU 941, GPU 942, FPGA 943, and accelerator 944 can together execute specific instructions that can constitute the aforementioned computer code. The computer code can be stored in the ROM 945 or RAM 946. Migration data can also be stored in the RAM 946, while permanent data can be stored, for example, in the internal mass storage device 947. By using a cache memory that can be closely associated with one or more CPUs 941, GPUs 942, mass storage device 947, ROM 945, RAM 946, etc., fast storage and reading to / from any memory device can be enabled.

[0157] A computer-readable medium can have computer code for performing various computer-implemented operations. The medium and the computer code can be specially designed and configured for the purposes of the present disclosure or they can be of the types available and well-known to those skilled in the computer software art.

[0158] As an example, and not by way of limitation, a computer system 900 having an architecture, specifically a core 940, can implement functions as a result of software embodied in one or more tangible computer-readable media being executed by a processor (including a CPU, GPU, FPGA, accelerator, etc.). Such a computer-readable media can be related media not only to a mass storage device accessible by a user as introduced above, but also to a specific storage device of the core 940 of a non-transitory nature such as the on-core mass storage device 947 or the ROM 945. The software implementing various embodiments of the present disclosure can be stored in such a device and executed by the core 940. The computer-readable media can include one or more memory devices or chips according to specific requirements. By the software, the core 940, particularly the processors (including a CPU, GPU, FPGA, etc.) therein, can execute a specific process described herein, or a specific part of a specific process, including the definition of a data structure stored in the RAM 946 and the modification of such a data structure by a process defined by the software. Additionally, or alternatively, the computer system can provide functions as a result of logic wired or otherwise embodied in a circuit (e.g., an accelerator 944) that operates instead of or in conjunction with software to execute a specific process described herein, or a specific part of a specific process. References to software can, if necessary, include logic, and vice versa. References to computer-readable media can, if necessary, include circuits (such as integrated circuits (ICs)) that store software for execution, circuits that embody logic for execution, or both. The present disclosure encompasses any suitable combination of hardware and software.

[0159] Although the present disclosure describes some non-limiting and exemplary embodiments, there are changes, substitutions, and various alternative equivalents within the scope of the present disclosure. Thus, those skilled in the art will understand that, although not explicitly illustrated or described herein, many systems and methods that embody the principles of the present disclosure and thus fall within the spirit and scope of the present disclosure can be devised.

Description of Signs

[0160] 100 Communication system, 110 Terminal, 120 Terminal, 130 Terminal, 140 Terminal, 150 Network, 200 Streaming system, 201 Video source, 202 Uncompressed video sample stream, 203 Encoder, 204 Video bitstream, 205 Streaming server, 206 Streaming client, 209 Video bitstream, 210 Video decoder, 211 Video sample stream, 212 Display, 213 Capture subsystem, 310 Receiver, 312 Channel, 315 Buffer memory, 320 Entropy decoder / parser, 321 Symbol, 351 Scaler / inverse transform unit, 352 Intra-picture prediction unit, 353 Motion compensation prediction unit, 355 Aggregator, 356 Loop filter unit, 357 Reference picture memory, 358 Current picture memory, 430 Source coder, 432 Coding engine, 433 Decoder, 434 Reference picture memory, 435 Predictor, 440 Transmitter, 445 Entropy coder, 450 Controller, 460 Channel, 520 Current block, 522 Upper block, 524 Left block, 702 Encoder, 704 Decoder, 710 Encoding (or decoding) code, 720 Alphabet determination code, 730 Grouping code, 740 Definition code, 750 Arithmetic encoding (or decoding) code, 760 Determination code, 790 Transmission code, 900 Computer system, 901 Keyboard, 902 Mouse, 903 Track pad, 905 Joystick, 906 Microphone, 907 Scanner, 908 Camera, 909 Speaker, 910 Touch screen, 920 CD / DVD ROM / RW, 921 Media such as CD / DVD, 922 Thumb drive, 923 Removable hard drive or solid state drive, 940 Core, 941 Central processing unit (CPU), 942 Graphics processing unit (GPU), 943 Field programmable gate array (FPGA), 944 Hardware accelerator, 945 Read-only memory (ROM), 946 Random access memory, 947 Internal mass storage device, 948System bus, 949 Peripheral bus, 950 Graphics adapter, 954 Network interface, 955 Cloud computing environment

Claims

1. A decoder-implemented method, the method comprising: receiving a coded video bitstream including a plurality of syntax elements; determining a first maximum alphabet size for arithmetic coding by an arithmetic coding engine, the first maximum alphabet size being determined based on hardware constraints; determining a second maximum alphabet size that is smaller than the first maximum alphabet size; and decoding the plurality of syntax elements included in the coded video bitstream based on the determined second maximum alphabet size, each of the plurality of syntax elements being entropy coded with an alphabet size less than or equal to the determined second maximum alphabet size.

2. The method of claim 1 , wherein the second maximum alphabet size is an integer value between 2 and 15, inclusive.

3. 2. The method of claim 1, wherein the plurality of syntax elements includes a first syntax element that is a set index indicating which of the sets a selected one of the symbols is in, and a second syntax element that is an index indicating which symbol in the selected one of the sets is used for encoding or decoding.

4. the symbols are classes of motion vector differences, The method of claim 3 , wherein the alphabet size of the first syntax element is 2, and the total number of the classes of the motion vector differences in each of the sets is 3 and 8, respectively.

5. the symbols are classes of motion vector differences, The method of claim 3 , wherein the alphabet size of the first syntax element is 3, and the total number of the classes of the motion vector differences in each of the sets is 3, 4, and 4, respectively.

6. The method of claim 3 , wherein the symbols each indicate an absolute value of a scaling parameter for chroma from a luma (CfL) mode.

7. The method of claim 3 , wherein the symbols are each a mode of luma intra-mode coding.

8. The method of claim 3 , wherein each of the symbols is a mode of chrominance intra-mode coding.

9. The method of claim 3 , wherein each of the symbols is a Wadgerett pattern.

10. The method of claim 3 , wherein each of the symbols is an end-of-block (eob) value.

11. An apparatus configured to perform the method of any one of claims 1 to 10.

12. A computer program for causing a computer to execute the method according to any one of claims 1 to 10.

Images