Systems and methods for parameterizing arithmetic coder probability update rates

Abstract

Various embodiments described herein include methods and systems for encoding and decoding video. In one aspect, the method includes receiving a video bitstream including a plurality of blocks. The method also includes obtaining, from the video bitstream, respective values ​​of one or more parameters associated with blocks within the plurality of blocks, the one or more parameters corresponding to arithmetic coder probability update rates, the respective values ​​of the one or more parameters being determined from a set of predetermined values. The method further includes calculating the arithmetic coder probability update rates based on the respective values ​​of the one or more parameters signaled in the video bitstream, and determining one or more coding contexts based on the calculated arithmetic coder probability update rates. The method also includes decoding the blocks within the plurality of blocks based on the one or more coding contexts.

Description

[Technical Field]

[0001] Related Applications This application claims priority to U.S. Provisional Patent Application No. 63 / 403,627, entitled "Adaptive Parameters for Arithmetic Coder Probability Update Rate," filed September 2, 2022, and is a continuation of and claims priority to U.S. Patent Application No. 18 / 209,205, entitled "Systems and Methods for Parameterizing Arithmetic Coder Probability Update Rates," filed June 13, 2023, both of which are incorporated herein by reference in their entireties.

[0002] FIELD Embodiments of the present disclosure relate generally to video encoding and decoding, including, but not limited to, systems and methods for parameterizing arithmetic coder probability update rates. [Background technology]

[0003] Digital video is supported by a variety of electronic devices, such as digital televisions, laptop or desktop computers, tablet computers, digital cameras, digital recording devices, digital media players, video game consoles, smartphones, video teleconferencing devices, video streaming devices, etc. The electronic devices send, receive, or communicate digital video data over communication networks and / or store the digital video data on storage devices. Because communication networks have limited bandwidth capacity and storage devices have limited memory resources, video coding may be used to compress the video data according to one or more video coding standards before the video data is communicated or stored.

[0004] Multiple video codec standards have been developed. For example, video coding standards include AOMedia Video 1 (AV1), Versatile Video Coding (VVC), Joint Exploration test Model (JEM), High-Efficiency Video Coding (HEVC / H.265), Advanced Video Coding (AVC / H.264), and Moving Picture Expert Group (MPEG) coding. Video coding generally utilizes prediction methods (e.g., inter-prediction, intra-prediction, etc.) that exploit the redundancy inherent in video data. Video coding aims to compress video data into a format that uses a lower bitrate while avoiding or minimizing degradation of video quality.

[0005] HEVC, also known as H.265, is a video compression standard designed as part of the MPEG-H project. ITU-T and ISO / IEC published the HEVC / H.265 standard in 2013 (Version 1), 2014 (Version 2), 2015 (Version 3), and 2016 (Version 4). Versatile Video Coding (VVC), also known as H.266, is a video compression standard intended as the successor to HEVC. ITU-T and ISO / IEC published the VVC / H.266 standard in 2020 (Version 1) and 2022 (Version 2). AV1 is an open video coding format designed as a replacement for HEVC. The effective version 1.0.0 of this specification, including Errata 1, was released on January 8, 2019. Summary of the Invention [Means for solving the problem]

[0006] As mentioned above, encoding (compression) reduces bandwidth and / or storage space requirements. As will be discussed in more detail below, both lossless and lossy compression can be employed. Lossless compression refers to techniques in which an exact copy of the original signal can be reconstructed from the compressed original signal through a decoding process. Lossy compression refers to a coding / decoding process in which the original video information is not fully preserved during coding and cannot be fully restored during decoding. When using lossy compression, the reconstructed signal may not be identical to the original signal, but the distortion between the original and reconstructed signal is small enough to make the reconstructed signal useful for its intended use. The amount of acceptable distortion depends on the application. For example, users of certain consumer video streaming applications may tolerate higher distortion than users of film or television broadcast applications. The compression ratio achievable by a particular coding algorithm can be selected or adjusted to reflect various distortion tolerances; i.e., generally, the greater the tolerable distortion, the higher the coding algorithm that results in higher loss and higher compression ratios.

[0007] A video encoder and / or decoder may utilize techniques from several broad categories and steps, including, for example, motion compensation, Fourier transform, quantization, and entropy coding. During entropy coding, data regarding motion may be transmitted to an entropy encoder. The entropy encoder may output a bitstream (coded video sequence), which may be transmitted to another device via a transmission channel. During the video decoding process, the bitstream may be transmitted to an entropy decoder. The entropy decoder may output data regarding motion, which may include intra-prediction information, residual information, etc., based on the bitstream. In some embodiments, entropy coding / decoding utilizes an arithmetic coding algorithm based on the probability of occurrence of a symbol (or letter) as the basis for arithmetic coding. In some embodiments, the probability of occurrence of a symbol (or letter) is dynamically updated during the coding / decoding process. For example, suppose there are only two possible letters (“a” and “b”), and the probability of “a” occurring is denoted as p_a and the probability of “b” occurring is denoted as p_b, where p_a+p_b=1 (or any other constant value). Therefore, when "a" is encountered in the coding / decoding process, p_a may be updated to a larger value, and p_b may be updated to a smaller value since their sum may be constant. This probability update process is sometimes called a "probability transition process" or a "probability state index update process."

[0008] According to some embodiments, a method for video decoding is performed on a computing system having a memory and one or more processors, the method including: (i) receiving video data comprising a plurality of blocks from a video bitstream; (ii) obtaining, from the video bitstream, respective values ​​of one or more parameters, the one or more parameters corresponding to arithmetic coder probability update rates, the respective values ​​of the one or more parameters being selected from a set of predetermined values; and (iii) analyzing the video data using the arithmetic coder probability update rates with the respective values ​​of the one or more parameters.

[0009] According to some embodiments, a method for video encoding is performed in a computing system having a memory and one or more processors, the method including: (i) obtaining video data including a plurality of blocks; (ii) selecting respective values ​​for one or more parameters, the one or more parameters corresponding to arithmetic coder probability update rates, the respective values ​​of the one or more parameters being selected from a set of predetermined values; and (iii) encoding the video data using the arithmetic coder probability update rates with the respective values ​​of the one or more parameters.

[0010] According to some embodiments, a computing system, such as a streaming system, a server system, a personal computer system, or other electronic device, is provided. The computing system includes control circuitry and a memory that stores one or more instruction sets. The one or more instruction sets include instructions for performing any of the methods described herein. In some embodiments, the computing system includes an encoder component and / or a decoder component.

[0011] According to some embodiments, a non-transitory computer-readable storage medium is provided that stores one or more sets of instructions for execution by a computing system, the one or more sets of instructions including instructions for performing any of the methods described herein.

[0012] Accordingly, devices and systems having methods for encoding and decoding video are disclosed, which may complement or replace conventional methods, devices, and systems for video encoding and / or decoding.

[0013] The features and advantages described herein are not necessarily all-inclusive, and in particular, some additional features and advantages will be apparent to those skilled in the art upon consideration of the drawings, specification, and claims provided in this disclosure. Furthermore, it should be noted that the language used herein has been chosen primarily for purposes of readability and explanation, and not necessarily to describe or limit the subject matter described herein.

[0014] In order that the present disclosure may be more fully understood, a more particular description may be made by reference to features of various embodiments, some of which are shown in the accompanying drawings. However, the accompanying drawings merely illustrate relevant features of the present disclosure and therefore should not be considered necessarily limiting, as the description may recognize other useful features as understood by those skilled in the art upon reading the present disclosure. [Brief explanation of the drawings]

[0015] [Figure 1] 1 is a block diagram illustrating an exemplary communication system according to some embodiments. [Figure 2A] FIG. 2 is a block diagram illustrating exemplary elements of an encoder component according to some embodiments. [Figure 2B] FIG. 2 is a block diagram illustrating exemplary elements of a decoder component according to some embodiments. [Figure 3] FIG. 1 is a block diagram illustrating an exemplary server system according to some embodiments. [Figure 4] FIG. 10 is a flow diagram illustrating an example flow for decoding a binary decision. [Figure 5A] 1 is a flow diagram illustrating an example method for encoding and decoding video according to some embodiments. [Figure 5B] 1 is a flow diagram illustrating an example method for encoding and decoding video according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0016] According to common practice, the various features illustrated in the drawings are not necessarily drawn to scale, and like reference numerals may be used to denote like features throughout the specification and drawings.

[0017] This disclosure describes parameterization of the probability update rate. Conventional probability update rates use a predetermined constant for probability update rate calculation. However, in some situations, using a predetermined constant reduces coding efficiency. This disclosure describes selection and signaling of parameters (e.g., Ai, Bi, Ci, and Ei in Equation 4 below). This parameterization improves the coding efficiency of arithmetic coder(s) in some situations.

[0018] Exemplary Systems and Devices 1 is a block diagram illustrating a communication system 100 according to some embodiments. Communication system 100 includes a source device 102 and multiple electronic devices 120 (e.g., electronic devices 120-1 through 120-m) communicatively coupled to each other via one or more networks. In some embodiments, communication system 100 is a streaming system for use in video-enabled applications such as, for example, video conferencing applications, digital TV applications, and media storage and / or distribution applications.

[0019] Source device 102 includes a video source 104 (e.g., a camera component or media storage) and an encoder component 106. In some embodiments, video source 104 is a digital camera (e.g., configured to generate an uncompressed video sample stream). Encoder component 106 generates one or more encoded video bitstreams from the video stream. The video stream from video source 104 may have a high data volume compared to encoded video bitstream 108 generated by encoder component 106. Because encoded video bitstream 108 has a lower data volume (less data) compared to the video stream from the video source, encoded video bitstream 108 requires less bandwidth for transmission and less storage space for storage compared to the video stream from video source 104. In some embodiments, source device 102 does not include encoder component 106 (e.g., configured to transmit uncompressed video data to network(s) 110).

[0020] The one or more networks 110 represent any number of networks that convey information between the source device 102, the server system 112, and / or the electronic device 120, including, for example, wired (cabled) and / or wireless communication networks. The one or more networks 110 may exchange data over circuit-switched and / or packet-switched channels. Exemplary networks include telecommunications networks, local area networks, wide area networks, and / or the Internet.

[0021] The one or more networks 110 include a server system 112 (e.g., a distributed / cloud computing system). In some embodiments, the server system 112 is or includes a streaming server (e.g., configured to store and / or distribute video content, such as an encoded video stream from the source device 102). The server system 112 includes a coder component 114 (e.g., configured to encode and / or decode video data). In some embodiments, the coder component 114 includes an encoder component and / or a decoder component. In various embodiments, the coder component 114 is instantiated as hardware, software, or a combination thereof. In some embodiments, the coder component 114 is configured to decode the encoded video bitstream 108 and re-encode the video data using a different encoding standard and / or methodology to generate encoded video data 116. In some embodiments, the server system 112 is configured to generate multiple video formats and / or encodings from the encoded video bitstream 108.

[0022] In some embodiments, server system 112 functions as a media-enabled network element (MANE). For example, server system 112 may be configured to prune encoded video bitstreams 108 to adapt potentially different bitstreams to one or more of electronic devices 120. In some embodiments, a MANE is provided separate from server system 112.

[0023] Electronic device 120-1 includes a decoder component 122 and a display 124. In some embodiments, decoder component 122 is configured to decode encoded video data 116 to generate an output video stream that can be rendered on a display or other type of rendering device. In some embodiments, one or more of electronic devices 120 does not include a display component (e.g., communicatively coupled to an external display device and / or includes media storage). In some embodiments, electronic device 120 is a streaming client. In some embodiments, electronic device 120 is configured to access server system 112 to obtain encoded video data 116.

[0024] The source device and / or the plurality of electronic devices 120 may also be referred to as “terminal devices” or “user devices.” In some embodiments, one or more of the source device 102 and / or the electronic devices 120 are instances of a server system, a personal computer, a portable device (e.g., a smartphone, tablet, or laptop), a wearable device, a videoconferencing device, and / or other types of electronic devices.

[0025] In an exemplary operation of communication system 100, source device 102 transmits encoded video bitstream 108 to server system 112. For example, source device 102 may code a stream of pictures captured by the source device. Server system 112 may receive encoded video bitstream 108 and decode and / or encode encoded video bitstream 108 using coder component 114. For example, server system 112 may apply optimal coding to the video data for network transmission and / or storage. Server system 112 may transmit encoded video data 116 (e.g., one or more coded video bitstreams) to one or more of electronic devices 120. Each electronic device 120 may decode encoded video data 116 to recover and optionally display video pictures.

[0026] In some embodiments, the transmission is a unidirectional data transmission. Unidirectional data transmission may be utilized in media serving applications, etc. In some embodiments, the transmission is a bidirectional data transmission. Bidirectional data transmission may be utilized in video conferencing applications, etc. In some embodiments, the coded video bitstream 108 and / or the coded video data 116 are coded and / or decoded according to any of the video coding / compression standards described herein, such as HEVC, VVC, and / or AV1.

[0027] FIG. 2A is a block diagram illustrating exemplary elements of the encoder component 106 according to some embodiments. The encoder component 106 receives a source video sequence from a video source 104. In some embodiments, the encoder component includes a receiver (e.g., transceiver) component configured to receive the source video sequence. In some embodiments, the encoder component 106 receives a video sequence from a remote video source (e.g., a video source that is a component of a device different from the encoder component 106). The video source 104 may provide the source video sequence in the form of a digital video sample stream that may be of any suitable bit depth (e.g., 8-bit, 10-bit, or 12-bit), any color space (e.g., BT.601 Y CrCb, or RGB), and any suitable sampling structure (e.g., Y CrCb 4:2:0 or Y CrCb 4:4:4). In some embodiments, the video source 104 is a storage device that stores previously captured / prepared video. In some embodiments, the video source 104 is a camera that captures local image information as a video sequence. Video data may be provided as multiple individual pictures that, when viewed sequentially, convey motion. The pictures themselves are organized as a spatial array of pixels, each of which may contain one or more samples, depending on the sampling structure, color space, etc., in use. Those skilled in the art will readily understand the relationship between pixels and samples. The following discussion focuses on samples.

[0028] The encoder component 106 is configured to code and / or compress pictures of a source video sequence into a coded video sequence 216 in real time or under other time constraints required by the application. Enforcing an appropriate coding rate is one function of the controller 204. In some embodiments, the controller 204 controls and is operatively coupled to other functional units described below. Parameters set by the controller 204 may include rate control-related parameters (e.g., picture skip, quantizer, and / or lambda value for rate-distortion optimization techniques), picture size, group of pictures (GOP) layout, maximum motion vector search range, etc. Those skilled in the art can readily identify other functions of the controller 204 that may be associated with the encoder component 106 being optimized for a particular system design.

[0029] In some embodiments, the encoder component 106 is configured to operate in a coding loop. In a simplified example, the coding loop includes a source coder 202 (e.g., responsible for generating symbols, such as a symbol stream, based on an input picture to be coded and one or more reference pictures) and a (local) decoder 210. The decoder 210 reconstructs the symbols to generate sample data, similar to a (remote) decoder (when the compression between the symbols and the coded video bitstream is lossless). The reconstructed sample stream (sample data) is input to a reference picture memory 208. Because decoding of the symbol stream yields bit-exact results regardless of the location of the decoder (local or remote), the contents of the reference picture memory 208 are also bit-exact between the local and remote encoders. In this way, the predictor of the encoder interprets the same sample values ​​as reference picture samples as the decoder interprets when using prediction during decoding. This principle of reference picture synchrony (and the resulting drift if synchrony cannot be maintained, e.g., due to channel error) is known to those skilled in the art.

[0030] The operation of decoder 210 may be the same as that of a remote decoder, such as decoder component 122, described in detail below in connection with Figure 2B. However, with brief reference to Figure 2B, because symbols are available and the encoding / decoding of the symbols into a coded video sequence by entropy coder 214 and parser 254 may be lossless, the entropy decoding portion of decoder component 122, including buffer memory 252 and parser 254, may not be fully implemented in local decoder 210.

[0031] At this point, it can be said that any decoder technology, other than analysis / entropy decoding, present in the decoder must necessarily also exist in the corresponding encoder in substantially the same functional form. For this reason, the subject matter of this disclosure focuses on the operation of the decoder. A description of the encoder technology can be omitted, since the encoder technology is the reverse of the decoder technology, which is described generically. Only in certain areas is a more detailed description necessary, as will be presented below.

[0032] As part of its operation, source coder 202 may perform motion-compensated predictive coding, which predictively codes an input frame with reference to one or more previously coded frames from the video sequence, designated as reference frames. In this method, coding engine 212 codes differences between pixel blocks of the input frame and pixel blocks of reference frame(s) that may be selected as prediction reference(s) for the input frame. Controller 204 may manage the coding operations of source coder 202, including, for example, setting parameters and subgroup parameters used to encode the video data.

[0033] The decoder 210 decodes the coded video data of a frame that may be designated as a reference frame based on symbols created by the source coder 202. The operation of the coding engine 212 may preferably be a lossy process. When the coded video data is decoded by a video decoder (not shown in FIG. 2A), the reconstructed video sequence may be a replica of the source video sequence with some errors. The decoder 210 may replicate the decoding process that may be performed by a remote video decoder on the reference frame and store the reconstructed reference frame in the reference picture memory 208. In this way, the encoder component 106 locally stores a copy of the reconstructed reference frame that has common content as the reconstructed reference frame that will be obtained by the remote video decoder (without transmission errors).

[0034] The predictor 206 may perform a predictive search for the coding engine 212. That is, for a new frame to be coded, the predictor 206 may search the reference picture memory 208 for sample data (as candidate reference pixel blocks) or specific metadata such as reference picture motion vectors, block shapes, etc. that may serve as suitable predictive references for the new picture. The predictor 206 may operate on sample block by pixel block to find a suitable predictive reference. In some cases, as determined by the search results obtained by the predictor 206, the input picture may have predictive references drawn from multiple reference pictures stored in the reference picture memory 208.

[0035] The outputs of all the aforementioned functional units may undergo entropy coding in entropy coder 214. Entropy coder 214 converts the symbols produced by the various functional units into a coded video sequence by losslessly compressing the symbols according to techniques known to those skilled in the art (e.g., Huffman coding, variable length coding, and / or arithmetic coding).

[0036] In some embodiments, the output of the entropy coder 214 is coupled to a transmitter. The transmitter may be configured to buffer the coded video sequence(s) generated by the entropy coder 214 to prepare them for transmission over a communication channel 218, which may be a hardware / software link to a storage device that stores the coded video data. The transmitter may be configured to merge the coded video data from the source coder 202 with other data to be transmitted, such as coded audio data and / or an auxiliary data stream (source not shown). In some embodiments, the transmitter may transmit additional data along with the coded video. The source coder 202 may include such data as part of the coded video sequence. The additional data may include other forms of redundant data, such as temporal / spatial / SNR enhancement layers, redundant pictures and slices, supplemental enhancement information (SEI) messages, visual usability information (VUI) parameter set fragments, etc.

[0037] The controller 204 may manage the operation of the encoder component 106. During coding, the controller 204 may assign a specific coded picture type to each coded picture, which may affect the coding technique applied to the respective picture. For example, a picture may be assigned as an intra picture (I picture), a predicted picture (P picture), or a bidirectionally predicted picture (B picture). An intra picture may 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, including, for example, independent decoder refresh (IDR) pictures. Those skilled in the art will recognize these variations of I pictures and their respective uses and characteristics, so they will not be repeated here. A predicted picture may be coded and decoded using intra prediction or inter prediction, which uses at most one motion vector and reference index to predict sample values ​​for each block. A bidirectionally predicted picture may be coded and decoded using intra prediction or inter prediction, which uses at most two motion vectors and reference indexes to predict sample values ​​for each block. Similarly, a multi-predicted picture can use more than two reference pictures and associated metadata for the reconstruction of a single block.

[0038] A source picture is generally spatially subdivided into multiple sample blocks (e.g., blocks of 4x4, 8x8, 4x8, or 16x16 samples each) and may be coded block by block. Blocks may be predictively coded with reference to other (already coded) blocks as determined by the coding assignment applied to the block's respective picture. For example, blocks of an I-picture may be nonpredictively coded or predictively coded with reference to already coded blocks of the same picture (spatial prediction or intra-prediction). Pixel blocks of a P-picture may be nonpredictively coded via spatial prediction or via temporal prediction with reference to one previously coded reference picture. Pixel blocks of a B-picture may be nonpredictively coded via spatial prediction or via temporal prediction with reference to one or two previously coded reference pictures.

[0039] Video may be captured in time sequence as multiple source pictures (video pictures). Intra-picture prediction (often abbreviated as intra-prediction) uses spatial correlation within a given picture, while inter-picture prediction uses correlation (temporal or other) between pictures. In one example, a particular picture being encoded / decoded, called the current picture, is divided into blocks. When a block in the current picture is similar to a reference block in a previously coded and still buffered reference picture in the video, the block in the current picture may be coded by a vector called a motion vector. The motion vector points to a reference block in the reference picture and may have a third dimension that identifies the reference picture if multiple reference pictures are used.

[0040] Encoder component 106 may perform coding operations according to a predetermined video coding technique or standard, such as any of those described herein. In doing so, encoder component 106 may perform various compression operations, including predictive coding operations that exploit temporal and spatial redundancies in the input video sequence. Thus, the coded video data may conform to a syntax specified by the video coding technique or standard being used.

[0041] 2B is a block diagram illustrating exemplary elements of the decoder component 122 according to some embodiments. The decoder component 122 of FIG. 2B is coupled to the channel 218 and the display 124. In some embodiments, the decoder component 122 includes a transmitter coupled to the loop filter unit 256 and configured to transmit data to the display 124 (e.g., via a wired or wireless connection).

[0042] In some embodiments, decoder component 122 includes a receiver coupled to channel 218 and configured to receive data from channel 218 (e.g., via a wired or wireless connection). The receiver may be configured to receive one or more coded video sequences to be decoded by decoder component 122. In some embodiments, the decoding of each coded video sequence is independent of the other coded video sequences. Each coded video sequence may be received from channel 218, which may be a hardware / software link to a storage device that stores the coded video data. The receiver receives the coded video data along with other data, e.g., coded audio data and / or auxiliary data streams, which may be forwarded to their respective using entities (not shown). The receiver may separate the coded video sequence from the other data. In some embodiments, the receiver receives additional (redundant) data along with the coded video. The additional data may be included as part of the coded video sequence(s). The additional data may be used by decoder component 122 to decode the data and / or to more accurately reconstruct the original video data. The additional data may be in the form of, for example, a temporal layer, a spatial layer, or an SNR enhancement layer, redundant slices, redundant pictures, forward error correction codes, etc.

[0043] According to some embodiments, the decoder component 122 includes a buffer memory 252, a parser 254 (sometimes referred to as an entropy decoder), a scaler / inverse transform unit 258, an intra-picture prediction unit 262, a motion compensation prediction unit 260, an aggregator 268, a loop filter unit 256, a reference picture memory 266, and a current picture memory 264. In some embodiments, the decoder component 122 is implemented as an integrated circuit, a series of integrated circuits, and / or other electronic circuitry. In some embodiments, the decoder component 122 is implemented at least partially in software.

[0044] Buffer memory 252 is coupled between channel 218 and parser 254 (e.g., to combat network jitter). In some embodiments, buffer memory 252 is separate from decoder component 122. In some embodiments, a separate buffer memory is provided between the output of channel 218 and decoder component 122. In some embodiments, in addition to buffer memory 252 within decoder component 122 (e.g., configured to handle playout timing), a separate buffer memory is provided external to decoder component 122 (e.g., to combat network jitter). When receiving data from a storage / forwarding device with sufficient bandwidth and controllability or from an isosynchronous network, buffer memory 252 may be unnecessary or may be small. For use in a best-effort packet network such as the Internet, buffer memory 252 may be required, and may be relatively large, advantageously adaptively sized, and at least partially implemented in an operating system or similar element (not shown) external to decoder component 122.

[0045] Parser 254 is configured to reconstruct symbols 270 from the coded video sequence. The symbols may include, for example, information used to manage the operation of decoder component 122 and / or information for controlling a rendering device such as display 124. The control information for the rendering device(s) may be in the form of a Supplementary Enhancement Information (SEI) message or a Video Usability Information (VUI) parameter set fragment (not shown). Parser 254 parses (entropy decodes) the coded video sequence. The coding of the coded video sequence may follow a video coding technique or standard and may follow principles well known to those skilled in the art, including variable length coding, Huffman coding, arithmetic coding with or without contextual dependency, etc. Parser 254 may extract a set of subgroup parameters for at least one of the subgroups of pixels in the video decoder from the coded video sequence based on at least one parameter corresponding to the group. The subgroups may include groups of pictures (GOPs), pictures, tiles, slices, macroblocks, coding units (CUs), blocks, transform units (TUs), prediction units (PUs), etc. Parser 254 may also extract information from the coded video sequence, such as transform coefficients, quantization parameter values, motion vectors, etc.

[0046] The reconstruction of symbols 270 may involve several different units, depending on the type of video picture or portion thereof being coded (inter-picture and intra-picture, inter-block and intra-block, etc.), as well as other factors. Which units are involved and how they are involved may be controlled by subgroup control information parsed from the coded video sequence by parser 254. The flow of such subgroup control information between parser 254 and the following units is not depicted for convenience of explanation.

[0047] In addition to the functional blocks already mentioned, the decoder component 122 can be conceptually subdivided into several functional units, as described below. In an actual implementation operating under commercial constraints, many of these units will interact closely with each other and may be at least partially integrated with each other. However, for purposes of describing the disclosed subject matter, the conceptual division into the following functional units will be maintained.

[0048] The scaler / inverse transform unit 258 receives the quantized transform coefficients as well as control information (e.g., which transform to use, block size, quantization coefficients, and / or quantization scaling matrix) as symbol(s) 270 from the parser 254. The scaler / inverse transform unit 258 may output blocks containing sample values ​​that may be input to an aggregator 268.

[0049] In some cases, the output samples of the scaler / inverse transform unit 258 relate to intra-coded blocks, i.e., blocks that do not use prediction information from a previously reconstructed picture but can use prediction information from a previously reconstructed portion of the current picture. Such prediction information may be provided by the intra-picture prediction unit 262. The intra-picture prediction unit 262 may generate blocks of the same size and shape as the block being reconstructed using surrounding already reconstructed information fetched from the current (partially reconstructed) picture from the current picture memory 264. The aggregator 268 may add, on a sample-by-sample basis, the prediction information generated by the intra-picture prediction unit 262 to the output sample information provided by the scaler / inverse transform unit 258.

[0050] In other cases, the output samples of the scalar / inverse transform unit 258 relate to an inter-coded, potentially motion-compensated, block. In such cases, the motion-compensated prediction unit 260 may access the reference picture memory 266 to fetch samples used for prediction. After motion-compensating the fetched samples according to the symbols 270 associated with the block, these samples may be added to the output of the scalar / inverse transform unit 258 by the aggregator 268 to generate output sample information (in this case, referred to as residual samples or a residual signal). The addresses in the reference picture memory 266 from which the motion-compensated prediction unit 260 fetches the prediction samples may be controlled by a motion vector. The motion vector may be available to the motion-compensated prediction unit 260 in the form of a symbol 270, which may have, for example, X, Y, and reference picture components. Motion compensation may also include interpolation of fetched sample values ​​from the reference picture memory 266 when sub-sample accurate motion vectors are used, motion vector prediction mechanisms, and the like.

[0051] The output samples of aggregator 268 may be subjected to various loop filtering techniques in loop filter unit 256. Video compression techniques may include in-loop filter techniques controlled by parameters included in the coded video bitstream and made available to loop filter unit 256 as symbols 270 from parser 254, but may also be responsive to meta-information obtained during decoding of a coded picture or previous portion (in decoding order) of the coded video sequence, or to previously reconstructed and loop-filtered sample values.

[0052] The output of the loop filter unit 256 may be a sample stream that can be output to a rendering device such as the display 124, and also stored in a reference picture memory 266 for use in future inter-picture prediction.

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

[0054] Decoder component 122 may perform decoding operations according to a predetermined video compression technology, which may be documented in a standard, such as any of the standards described herein. The coded video sequence may conform to the syntax specified by the video compression technology or standard being used, in the sense of adhering to the syntax of the video compression technology or standard as specified in the video compression technology document or standard, specifically the profile document therein. Also, to comply with some video compression technologies or standards, the complexity of the coded video sequence may also be within a range specified by the level of the video compression technology or standard. In some cases, the level limits the maximum picture size, maximum frame rate, maximum reconstruction sample rate (e.g., measured in megasamples per second), maximum reference picture size, etc. The limits set by the level may, in some cases, be further limited by the specification of a hypothetical reference decoder (HRD) and metadata for HRD buffer management signaled in the coded video sequence.

[0055] 3 is a block diagram illustrating a server system 112 according to some embodiments. The server system 112 includes a control circuit 302, one or more network interfaces 304, a memory 314, a user interface 306, and one or more communication buses 312 for interconnecting these components. In some embodiments, the control circuit 302 includes one or more processors (e.g., a CPU, a GPU, and / or a DPU). In some embodiments, the control circuit includes one or more field programmable gate arrays (FPGAs), hardware accelerators, and / or one or more integrated circuits (e.g., application specific integrated circuits).

[0056] The network interface(s) 304 may be configured to interface with one or more communication networks (e.g., wireless, wired, and / or optical networks). The communication networks may be local, wide-area, metropolitan, vehicular and industrial, real-time, delay-tolerant, etc. Examples of communication networks include local area networks such as Ethernet; cellular networks including WLAN, GSM, 3G, 4G, 5G, LTE, etc.; television wired or wireless wide-area digital networks including cable, satellite, and terrestrial television; vehicular and industrial networks including CANBus; and the like. Such communications may be unidirectional, receive only (e.g., broadcast television), unidirectional transmit only (e.g., CANbus to a specific CANbus device), or bidirectional (e.g., to another computer system using a local or wide-area digital network). Such communications may include communications to one or more cloud computing networks.

[0057] The user interface 306 includes one or more output devices 308 and / or one or more input devices 310. The input device(s) 310 may include one or more of a keyboard, a mouse, a trackpad, a touchscreen, a data glove, a joystick, a microphone, a scanner, a camera, etc. The output device(s) 308 may include one or more of an audio output device (e.g., a speaker), a visual output device (e.g., a display or monitor), etc.

[0058] Memory 314 may include high-speed random-access memory (such as DRAM, SRAM, DDR RAM, and / or other random-access solid-state memory devices) and / or non-volatile memory (such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, and / or other non-volatile solid-state storage devices). Memory 314 optionally includes one or more storage devices located remotely from control circuitry 302. Memory 314, or the non-volatile solid-state memory device(s) within memory 314, comprises a non-transitory computer-readable storage medium. In some embodiments, memory 314, or the non-transitory computer-readable storage medium of memory 314, stores the following programs, modules, instructions, and data structures, or a subset or superset thereof: • an operating system 316 that contains procedures for handling various basic system services and performing hardware-dependent tasks; • a network communications module 318 used to connect the server system 112 to other computing devices via one or more network interfaces 304 (e.g., via wired and / or wireless connections); A coding module 320 for performing various functions related to encoding and / or decoding data, such as video data. In some embodiments, the coding module 320 is an instance of the coder component 114. The coding module 320 may include, but is not limited to, one or more of the following: a decoding module 322 for performing various functions related to decoding the encoded data, such as those described above with respect to the decoder component 122; an encoding module 340 for performing various functions on the encoded data, such as those described above with respect to the encoder component 106; A picture memory 352 for storing pictures and picture data, e.g., for use with the coding module 320. In some embodiments, the picture memory 352 includes one or more of the reference picture memory 208, the buffer memory 252, the current picture memory 264, and the reference picture memory 266.

[0059] In some embodiments, the decoding module 322 includes a parsing module 324 (e.g., configured to perform the various functions described above with respect to the parser 254), a transform module 326 (e.g., configured to perform the various functions described above with respect to the scaler / inverse transform unit 258), a prediction module 328 (e.g., configured to perform the various functions described above with respect to the motion compensation prediction unit 260 and / or the intra-picture prediction unit 262), and a filter module 330 (e.g., configured to perform the various functions described above with respect to the loop filter unit 256).

[0060] In some embodiments, the encoding module 340 includes a code module 342 (e.g., configured to perform various functions described above with respect to the source coder 202, the coding engine 212, and / or the entropy coder 214) and a prediction module 344 (e.g., configured to perform various functions described above with respect to the predictor 206). In some embodiments, the decoding module 322 and / or the encoding module 340 include a subset of the modules shown in FIG. 3. For example, a shared prediction module is used by both the decoding module 322 and the encoding module 340.

[0061] Each of the above-identified modules stored in memory 314 corresponds to a set of instructions for performing functions described herein. The above-identified modules (e.g., instruction sets) need not be implemented as separate software programs, procedures, or modules; thus, various subsets of these modules may be combined or otherwise rearranged in various embodiments. For example, coding module 320 optionally does not include separate decoding and encoding modules, but rather uses the same set of modules to perform both sets of functionality. In some embodiments, memory 314 stores a subset of the above-identified modules and data structures. In some embodiments, memory 314 stores additional modules and data structures not described above, such as an audio processing module.

[0062] In some embodiments, the server system 112 includes a web or Hypertext Transfer Protocol (HTTP) server, a File Transfer Protocol (FTP) server, and web pages and applications implemented using Common Gateway Interface (CGI) scripts, the PHP Hypertext Preprocessor (PHP), Active Server Pages (ASP), Hypertext Markup Language (HTML), Extensible Markup Language (XML), Java, JavaScript, Asynchronous JavaScript and XML (AJAX), XHP, Javelin, Wireless Universal Resource Files (WURFL), and the like.

[0063] While FIG. 3 illustrates a server system 112 according to some embodiments, FIG. 3 is not intended as a structural schematic of the embodiments described herein, but rather as a functional description of various features that may be present in one or more server systems. In practice, and as will be recognized by those skilled in the art, items shown separately may be combined and some items may be separated. For example, some items shown separately in FIG. 3 may be implemented on a single server, and single items may be implemented by one or more servers. The actual number of servers used to implement server system 112 and how functionality is allocated among them will vary from implementation to implementation and, optionally, depend in part, on the amount of data traffic the server system handles during peak and average usage periods.

[0064] Entropy Coding As mentioned above, during entropy coding, data regarding the operation may be transmitted to an entropy encoder (e.g., entropy coder 214). The entropy encoder may output a bitstream, which may be transmitted to another device via a transmission channel. During the video decoding process, the bitstream may be transmitted to an entropy decoder. The entropy decoder may be configured to reconstruct, from a coded picture, certain symbols that represent the syntax elements of which the coded picture is composed. Such symbols may include, for example, prediction information (e.g., intra-prediction information or inter-prediction information) that may identify the mode in which the block is coded (e.g., intra-mode, inter-mode, bi-prediction mode, merged sub-mode, or another sub-mode), certain samples or metadata used for prediction by an intra-decoder or an inter-decoder, residual information, e.g., in the form of quantized transform coefficients, etc.

[0065] For example, in HEVC, the entropy coder / decoder may use a context-adaptive binary arithmetic coding (CABAC) algorithm. The CABAC engine in HEVC uses a table-based probability transition process between 64 different representative probability states.

[0066] Syntax elements describing video frame content may undergo binary arithmetic coding to obtain a stream encoded as a binary bin stream. During CABAC, the initial interval [0,1) may be stretched by an integer multiplier (e.g., 512), and the least likely symbol probability (pLPS) may be presented as an integer division by rounding their quotient. Then, the interval division operation by general arithmetic coding may be performed as an approximation using integer arithmetic of a specified resolution.

[0067] The updated interval length corresponding to the LPS (rLPS) may be calculated as rLPS=R*pLPS, where R is the current interval length value. To save time and increase efficiency, the above computationally intensive multiplication operation may be replaced with a look-up table (LUT) that captures pre-calculated multiplication results, and thus the updated interval length corresponding to the LPS (ivLpsRange) may be obtained by two indexes pStateIdx and qRangeIdx, for example, as given in Equation 1: ivlLpsRange=rangeTabLps[pStateIdx][qRangeIdx] formula 1

[0068] During encoding / decoding, the probability value pLPS may be recursively updated each time a new value (binVal) of the bin to be encoded / decoded is obtained. For example, at the kth step (i.e., during encoding or decoding of the kth bin), the new value of pLPS may be calculated to be a larger value when binVal is the value of LPS, or the new value of pLPS may be calculated to be a smaller value when binVal is the value of the most likely symbol (MPS).

[0069] In some embodiments, pLPS may be one of 64 possible values ​​indexed by the 6-bit pStateIdx variable. Updating the probability value may be accomplished by updating the index pStateIdx, which may be performed by looking up a value from a pre-computed table to save computational power and / or improve efficiency.

[0070] In some embodiments, the range ivlCurrRange representing the state of the coding engine may be quantized to a set of four values ​​before calculating a new interval range. State transitions may be implemented using a table containing all 64x4 8-bit pre-calculated values ​​to approximate the value of ivlCurrRange*pLPS(pStateIdx). Decoding decisions may also be implemented using a pre-calculated LUT. The LUT is used to obtain a first ivlLpsRange, and then the ivlLpsRange is used to update the ivlCurrRange and calculate the output binVal.

[0071] As an example, in VVC, probabilities may be linearly represented by a probability index pStateIdx. Therefore, all calculations can be performed using formulas without LUT operations. To improve the accuracy of probability estimation, a multi-hypothesis probability update model can be used, as shown in Figure 4. In this example, pStateIdx, used for interval subdivision in a binary arithmetic coder, is a combination of two probabilities, pStateIdx0 and pStateIdx1. The two probabilities are 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 associated bin. The probability estimate pStateIdx can be the average of the estimates from the two hypotheses.

[0072] 4 is a flow diagram illustrating an example flow for decoding a single decision (DecodeDecision), including a renormalization process (RenomD) in an arithmetic decoding engine. In some embodiments, the inputs to DecodeDecision are a context table (ctxTable) and a context index (ctxIdx). The value of the variable ivlLpsRange is derived as shown at 402. Given the current value of ivlCurrRange, the variable qRangeIdx is derived as qRangeIdx=ivlCurrRange≫5. Given qRangeIdx, pStateIdx0, and pStateIdx1 associated with ctxTable and ctxIdx, valMps and ivlLpsRange are derived as pState=pStateIdx1+16*pStateIdx0, valMps=pState≫14, and ivlLpsRange=(qRangeIdx*((valMps?32767-pState:pState)≫9)≫1)+4. The variable ivlCurrRange is set to ivlCurrRange-ivlLpsRange.

[0073] If ivlOffset is greater than or equal to ivlCurrRange, then the variable binVal is set equal to 1-valMps, ivlOffset is decremented by ivlCurrRange, and ivlCurrRange is set equal to ivlLpsRange; otherwise, the variable binVal is set equal to valMps.

[0074] To update the probabilities, during the state transition process, the inputs to this process are the current pStateIdx0 and pStateIdx1 and the decoded value binVal, and the output of this process is the updated pStateIdx0 and pStateIdx1 of the context variables associated with ctxTable and ctxIdx. The variables shift0 and shift1 are derived from the shiftIdx value associated with ctxTable and ctxIdx in 404, where shift0=(shiftIdx≫2)+2 and shift1=(shiftIdx&3)+3+shift0, and according to the decoded value binVal, the updates of the two variables pStateIdx0 and pStateIdx1 associated with ctxTable and ctxIdx are derived as pStateIdx0=pStateIdx0-(pStateIdx0≫shift0)+(1023*binVal≫shift0) and pStateIdx1=pStateIdx1-(pStateIdx1≫shift1)+(16383*binVal≫shift1).

[0075] As an example, VVC CABAC may have a quantization parameter (QP)-dependent initialization process that is invoked at the beginning of each slice. Given an initial value of luma QP for the slice, the initial probability state of the context model, denoted as preCtxState, may be derived by m=slopeIdx×5−45, n=(offsetIdx≪3)+7, and preCtxState=Clip3(1,127,((m×(QP−32))≫4)+n).

[0076] In some embodiments, slopeIdx and offsetIdx are limited to 3 bits, and the total initialization value is represented with 6-bit precision. The probability state preCtxState may directly represent the probability in the linear domain. Therefore, preCtxState only needs an appropriate shift operation before being input to the arithmetic coding engine, and the mapping from the logarithmic to the linear domain and the 256-byte table may be predefined and stored / preserved in memory. pStateIdx0 and pStateIdx1 may be obtained by pStateIdx0=preCtxState<<3 and pStateIdx1=preCtxState<<7.

[0077] In some embodiments, the CABAC algorithm may use a binary system that includes two possible letters / symbols (e.g., "0" and "1"). In binary-based arithmetic coding algorithms, the two possible letters / symbols may also be represented as least likely symbol (LPS) and most likely symbol (MPS).

[0078] In some embodiments, an entropy encoder or decoder may use an arithmetic algorithm in an M-ary basis that includes M possible characters / symbols. For example, M may be any integer value between 2 and 16. For example, if M is equal to 5, then the M-ary basis includes five possible characters / symbols that can be represented as "0," "1," "2," "3," and "4."

[0079] An M-ary arithmetic coding engine is used to entropy code syntax elements. Each syntax element is associated with an alphabet of M elements. As input to an encoder or decoder, a coding context may include a sequence of M-ary symbols with a set of M probabilities. Each of the M probabilities may correspond to each of the M-ary symbols and may be represented by a cumulative distribution function (CDF).

[0080] The cumulative distribution function of the M-ary symbols is C=[c0,c 1, …,c (M-2) ,c (M-1) The cumulative distribution function of an M-ary symbol may be represented by an array of M 15-bit integers, where c (M-1) =2 15 and c n / 32768 is the probability that the symbol is less than or equal to n, where n is an integer between 0 and M-1.

[0081] In some embodiments, the M probabilities (e.g., an array of cumulative distribution functions) are updated after coding / parsing each syntax element. In some embodiments, the M probabilities are updated after coding / decoding each M-ary symbol. For example, for M=4, the array of cumulative distribution functions is [c0,c 1, c2, c3].

[0082] In some embodiments, the updating of the M probabilities is performed according to Equation 2:

number

[0083] In some embodiments, the M-ary arithmetic coding process may follow a conventional arithmetic coding engine design, but only the most significant 9 bits of the 15-bit probability value are input to the arithmetic encoder / decoder. The probability update rate α associated with a symbol is calculated based on the number of occurrences of the associated symbol when parsing the bitstream, and the value of α is reset at the beginning of a frame or tile using the following formula:

[0084] Equation 3 below shows an example of the probability update rate:

number

[0085] As noted above, the probability update rate (or rate in the case of a multi-hypothesis entropy coding engine) has the general formula:

number

[0086] 5A is a flow diagram illustrating a method 500 for encoding video according to some embodiments. Method 500 may be performed on a computing system (e.g., server system 112, source device 102, or electronic device 120) having control circuitry and memory storing instructions for execution by the control circuitry. In some embodiments, method 500 is performed by executing instructions stored in memory (e.g., memory 314) of the computing system.

[0087] As used herein, the term "block" may be interpreted as a prediction block, a coding block, a coding unit (CU), or a transform block. The term "block size" may refer to the block width, the block height, the maximum width, the maximum height, the minimum width, the minimum height, the region size (width * height), and / or the aspect ratio of the block (width:height, or height:width).

[0088] The system obtains video data including a plurality of blocks (502). The system selects respective values ​​of one or more parameters, the one or more parameters corresponding to arithmetic coder probability update rates, the respective values ​​of the one or more parameters being selected from a set of predetermined values ​​(504). The system encodes the video data with the respective values ​​of the one or more parameters using the arithmetic coder probability update rates (506).

[0089] For example, a system may use an arithmetic coder to encode / decode a bitstream of video data. The arithmetic coder is configured to estimate symbol probabilities. The arithmetic coder may use adaptive probabilities (e.g., the probability of a future symbol is based on previously encountered symbols). The rate at which the arithmetic coder is updated may also be adaptive (e.g., the coder may be updated more quickly in some contexts and more slowly in other contexts). In some embodiments, the arithmetic coder is updated based on multiple update rates. In some embodiments, a low-complexity recursive update of the estimated true probabilities is utilized.

[0090] 5B is a flow diagram illustrating a method 550 for decoding video according to some embodiments. Method 550 may be performed on a computing system (e.g., server system 112, source device 102, or electronic device 120) having control circuitry and memory storing instructions for execution by the control circuitry. In some embodiments, method 550 is performed by executing instructions stored in memory (e.g., memory 314) of the computing system.

[0091] The system receives a video bitstream including a plurality of blocks (552). The system obtains, from the video bitstream, respective values ​​of one or more parameters, the one or more parameters corresponding to arithmetic coder probability update rates, the respective values ​​of the one or more parameters being selected from a set of predetermined values ​​(554). The system calculates the arithmetic coder probability update rates based on the respective values ​​of the one or more parameters signaled in the video bitstream (556). The system determines one or more coding contexts based on the calculated arithmetic coder probability update rates (558). The system decodes blocks within the plurality of blocks based on the one or more coding contexts (560).

[0092] In some embodiments, for arithmetic coders that use single or multiple hypotheses for probability estimation, the values ​​of one or more of the parameters Ai, Bi, Ci, and Ei are selected by the encoder from a set of predetermined values ​​and signaled in a high-level syntax. i The predetermined values ​​of B include 0, 1, 2, ...., 8. In some embodiments, B i and C i Predetermined values ​​of include 0, 1, 2, ...., 128. In some embodiments, E i Predefined values ​​for include 0, 1, 2, 3, and 4.

[0093] In some embodiments, B i is Ci For example, (B i ,C i Valid combinations of B include (3,7), (3,15), (3,31), (7,15), (7,31), and (15,31). i and C i The delta value between (e.g., C i -B i ) is signaled. In some embodiments, A i , B i , C i , and / or E i A binary representation of the value of is signaled.

[0094] For example, parameter A i In this case, the syntax changes may be expressed as shown in Table 1 below, where the syntax ac_param_a0 and ac_param_a1 are A i where f(n) denotes the value of two hypotheses of n, and f(3) indicates that 3 bits are used for the corresponding parameter. In some embodiments, f(n) has a value other than 3 (e.g., 2, 4, or 7).

[0095] [Table 1]

[0096] As another example, parameter A i In this case, the syntax changes may be expressed as shown in Table 2 below, where the syntax ac_param_a indicates the value of a single hypothesis for A.

[0097] [Table 2]

[0098] In some embodiments, a lookup table is defined with possible combinations of one or more values ​​of Ai, Bi, Ci, and Ei. For example, an index into the lookup table is signaled. An exemplary lookup table for combinations of (Bi, Ci) with values ​​(3,7), (3,15), (3,31), (7,15), (7,31), and (15,31) is shown in Table 3.

[0099] [Table 3]

[0100] As another example, for a parameter combination (Bi, Ci), the syntax changes may be represented as shown in Table 4 below.

[0101] [Table 4]

[0102] In some embodiments, the default value is A for each syntax. i , B i , C i , and E i In some embodiments, a ? is used to indicate whether a default value is used. i , B i , C i , and E i For each or selected ones, a flag is signaled in the bitstream (e.g., parameter values ​​are signaled if default values ​​are not used).

[0103] A i As an example where one flag is signaled for multiple hypotheses, the syntax changes may be summarized as shown in Table 5.

[0104] [Table 5]

[0105] As another example where a separate flag is signaled for each hypothesis of parameter Ai, the syntax changes may be grouped as shown in Table 6.

[0106] [Table 6]

[0107] In some embodiments in which parameter values ​​are signaled, a first subset of parameter values ​​is signaled separately for each hypothesis, and a second subset of parameter values ​​is signaled once and shared for each hypothesis. For example, parameter values ​​for Ai are signaled separately for each hypothesis, and for other parameters (e.g., Bi, Ci, or Ei), one value for each parameter from multiple hypotheses is signaled and shared.

[0108] In some embodiments, for multi-hypothesis probability estimation, the parameters for each hypothesis satisfy the above conditions and are signaled as shown in any of Tables 1-6 above.

[0109] 5A and 5B show some logical stages in a particular order, but order-independent stages may be reordered, and other stages may be combined or separated. Some reordering or other groupings not specifically mentioned will be apparent to those skilled in the art, and therefore the reordering and groupings presented herein are not exhaustive. Furthermore, it should be recognized that the various stages can be implemented in hardware, firmware, software, or any combination thereof. Methods 500 and 550 are applicable to both multi-symbol arithmetic coding and binary (M equals 2) arithmetic coding.

[0110] Reference will now be made to some exemplary embodiments.

[0111] (A1) In one aspect, some embodiments include a method of video decoding (e.g., method 550). In some embodiments, the method is performed in a computing system (e.g., server system 112) having memory and control circuitry. In some embodiments, the method is performed in a coding module (e.g., coding module 320). In some embodiments, the method is performed in a parser (e.g., parser 254). The method includes: (i) receiving video data including a plurality of blocks from a video bitstream; (ii) obtaining, from the video bitstream, respective values ​​of one or more parameters associated with blocks in the plurality of blocks, wherein the one or more parameters correspond to arithmetic coder probability update rates, and the respective values ​​of the one or more parameters are determined from a set of predetermined values; (iii) calculating arithmetic coder probability update rates based on the respective values ​​of the one or more parameters signaled in the video bitstream; (iv) determining one or more coding contexts based on the calculated arithmetic coding probability update rates; and (v) decoding blocks in the plurality of blocks based on the one or more coding contexts. In some embodiments, the method includes analyzing the video data at respective values ​​of one or more parameters using an arithmetic coder probability update rate.

[0112] (A2) In some embodiments of A1, the values ​​of the one or more parameters are obtained from high-level syntax in the video bitstream. For example, the high-level syntax corresponds to the sequence level, the frame level, the slice level, or the tile level. In some embodiments, the high-level syntax is higher than the block level. For example, the high-level syntax may include a VPS, an SPS, a PPS, an APS, a slice header, a picture header, a tile header, and / or a CTU header.

[0113] (A3) In some embodiments of A1 or A2, the value of each of the one or more parameters is selected by an encoder component (eg, identified during the encoding process).

[0114] (A4) In some embodiments of any of A1 to A3, the one or more parameters include an offset parameter, and the predetermined value of the offset parameter is in the range of 0 to 8. For example, 3 bits are used for the predetermined value of the offset parameter. As an example, the predetermined value of parameter A may include a number in the range of 0 to 8.

[0115] (A5) In some embodiments of any of A1-A4, the one or more parameters include two or more count parameters, and the predetermined values ​​of the two or more count parameters are in the range of 0 to 128. For example, 7 bits are used for the predetermined values ​​of the two or more count parameters. As an example, the predetermined values ​​of parameters B and C may include numbers in the range of 0 to 128.

[0116] (A6) In some embodiments of A5, the two or more count parameters include a first parameter and a second parameter, and each value of the first parameter must be less than each value of the second parameter. For example, parameter B must be less than parameter C. By way of example, possible combinations of (B,C) include (3,7), (3,15), (3,31), (7,15), (7,31), and (15,31). In some embodiments, the predetermined value is 2 n-1 where n ranges from 0 to the number of bits specified for signaling the parameter value. In some situations, there are hardware advantages to using these predetermined values ​​(e.g., using a shift operation as opposed to other, more complex operations).

[0117] (A7) In some embodiments of A5 or A6, a difference value between two or more count parameters is signaled via the video bitstream. For example, each value of a first count parameter is signaled along with the difference value (e.g., rather than signaling each value of a second count parameter). As an example, a delta value between B and C (e.g., C B ) is signaled.

[0118] (A8) In some embodiments of any of A1 to A7, the one or more parameters include a syntax size parameter, and the predetermined value of the syntax size parameter is in the range of 0 to 4. For example, 2 bits are used for the predetermined value of the syntax size parameter. As an example, the predetermined value of parameter E may include a number in the range of 0 to 4.

[0119] (A9) In some embodiments of any of A1-A8, obtaining a value for each of the one or more parameters includes obtaining a binary representation of each value. For example, binary representations of values ​​A, B, C, and E are signaled.

[0120] (A10) In some embodiments of any of A1-A9, obtaining a respective value of the one or more parameters includes obtaining, for each hypothesis of the two or more hypotheses, a hypothesis-specific respective value of the one or more parameters. In some embodiments, the respective value of each parameter is signaled for each hypothesis. For example, each hypothesis in a multi-hypothesis coding engine may use a different value for one or more parameters.

[0121] (A11) In some embodiments of any of A1-A10, obtaining a value for each of the one or more parameters includes obtaining an index to a lookup table from the video bitstream. In some embodiments, the lookup table is defined with possible combinations of values ​​for the one or more parameters. For example, the index to the lookup table is signaled.

[0122] (A12) In some embodiments of any of A1-A11, a respective default value is specified for each of the one or more parameters, and a flag in the video bitstream indicates whether to use the respective default value for a first parameter of the one or more parameters. The method further includes (i) assigning the respective default value to the first parameter according to the flag having a first value, and (ii) obtaining the respective value from the video bitstream for the first parameter according to the flag having a second value. For example, default values ​​for A, B, C, and E are defined for each syntax. In this example, a flag is signaled in the bitstream for each or a subset of A, B, C, and E to indicate whether the default value is used. Otherwise, in this example, a value is signaled in the bitstream.

[0123] (A13) In some embodiments of A12, a different flag is signaled for each hypothesis of the two or more hypotheses, for example, a separate flag is signaled for each hypothesis of parameter A.

[0124] (A14) In some embodiments of any of A1-A13, (i) obtaining respective values ​​for the one or more parameters includes obtaining a first value for a first one of the one or more parameters and obtaining a second value for a second one of the one or more parameters, (ii) calculating the arithmetic coder probability update rate includes calculating the arithmetic coder probability update rate according to a first hypothesis using the first value of the first parameter and the second value of the second parameter, and (iii) the method further includes calculating a second arithmetic coder probability update rate according to a second hypothesis using the first value of the first parameter and the third value of the second parameter. For example, when the parameter values ​​are signaled, for selected parameters, the parameter values ​​are signaled separately for each hypothesis, and for the remaining parameters, the parameter values ​​are signaled once and shared for each hypothesis. As an example, the parameter value of A is signaled separately for each hypothesis, but for other parameters (e.g., B, C, and / or E), one value for each parameter is signaled and shared across multiple hypotheses.

[0125] (A15) In some embodiments of any of A1-A14, the video bitstream corresponds to video coded according to any of B1-A13 below. In some embodiments, the compressor uses past input to estimate a probability distribution (prediction) for the next symbol. The compressor may pass the prediction and symbols to an arithmetic coder and update the model with the coded symbols. The decompressor may make the same prediction using already decoded data, decode the symbols, and then update its model with the decoded output symbols. In this manner, the model may not know whether it is compressing or decompressing. In some embodiments, the update rate is initially fast and decreases as the count is incremented, e.g., resulting in a stationary model. In some embodiments, the count is bounded, e.g., resulting in an adaptive model.

[0126] (B1) In another aspect, some embodiments include a method of video encoding (e.g., method 500). In some embodiments, the method is performed in a computing system (e.g., server system 112) having memory and control circuitry. In some embodiments, the method is performed in a coding module (e.g., coding module 320). In some embodiments, the method is performed in an entropy coder (e.g., entropy coder 214). The method includes (i) obtaining video data including a plurality of blocks; (ii) selecting respective values ​​of one or more parameters, where the one or more parameters correspond to arithmetic coder probability update rates, and the respective values ​​of the one or more parameters are selected from a set of predetermined values; and (iii) encoding the video data using the arithmetic coder probability update rates with the respective values ​​of the one or more parameters.

[0127] (B2) In some embodiments of B1, the value of the one or more parameters is signaled in a high-level syntax.

[0128] (B3) In some embodiments of B1 or B2, the value of each of the one or more parameters is selected by an encoder component (eg, encoder 106).

[0129] (B4) In some embodiments of any of B1-B3, the one or more parameters include an offset parameter, and the predetermined value of the offset parameter is in the range of 0-8.

[0130] (B5) In some embodiments of any of B1-B4, the one or more parameters include two or more count parameters, and the predetermined values ​​of the two or more count parameters are in the range of 0-128.

[0131] (B6) In some embodiments of B5, the two or more count parameters include a first parameter and a second parameter, and each value of the first parameter must be less than each value of the second parameter.

[0132] (B7) In some embodiments of B5 or B6, the difference value between the two or more count parameters is signaled in the video bitstream.

[0133] (B8) In some embodiments of any of B1-B7, the one or more parameters include a syntax size parameter, and the predetermined value of the syntax size parameter is in the range of 0-4.

[0134] (B9) In some embodiments of any of B1-B8, obtaining a value for each of the one or more parameters includes obtaining a binary representation of each value.

[0135] (B10) In some embodiments of any of B1 to B9, obtaining a respective value of the one or more parameters includes obtaining, for each hypothesis of the two or more hypotheses, a respective hypothesis-specific value of the one or more parameters.

[0136] (B11) In some embodiments of any of B1-B10, obtaining a value for each of the one or more parameters includes obtaining an index into a lookup table.

[0137] (B12) In some embodiments of any of B1 to B11, a respective default value is specified for each parameter of the one or more parameters, and the method further includes the steps of: (i) setting a flag specifying whether to use the respective default value; (i) assigning the respective default value to the first parameter according to the flag having a first value; and (ii) obtaining a value for each of the first parameters according to the flag having a second value.

[0138] (B13) In some embodiments of B12, a different flag is signaled for each hypothesis of the two or more hypotheses.

[0139] The methods described herein may be used separately or combined in any order. Each method may be performed by a processing circuit (e.g., one or more processors or one or more integrated circuits). In some embodiments, the processing circuit executes a program stored on a non-transitory computer-readable medium.

[0140] In another aspect, some embodiments include a computing system (e.g., server system 112) including control circuitry (e.g., control circuitry 302) and a memory (e.g., memory 314) coupled to the control circuitry, the memory storing one or more instruction sets configured to be executed by the control circuitry, the one or more instruction sets including instructions for performing any of the methods described herein (e.g., A1-A15 and B1-B13 above).

[0141] In yet another aspect, some embodiments include a non-transitory computer-readable storage medium storing one or more instruction sets for execution by control circuitry of a computing system, the one or more instruction sets including instructions for performing any of the methods described herein (e.g., A1-A15 and B1-B13 above).

[0142] It will also be understood that although terms such as "first," "second," etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another.

[0143] The terms used herein are for the purpose of describing particular embodiments only and are not intended to limit the scope of the claims. As used in describing the embodiments and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. The term "and / or," as used herein, will also be understood to refer to and encompass any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms "comprises" and / or "comprising," as used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0144] As used herein, the term "if" can be interpreted to mean "when" or "upon" or "in response to determining" or "in accordance with a determination" or "in response to detecting" a stated precondition is true, depending on the context. Similarly, the phrase "if it is determined that [the stated precondition is true]" or "if [the stated precondition is true]" or "when [the stated precondition is true]" can be interpreted to mean "upon determining" or "in response to determining" or "in accordance with a determination" or "upon detecting" or "in response to detecting" a stated precondition is true, depending on the context.

[0145] The foregoing description has been described with reference to specific embodiments for purposes of explanation. However, the exemplary description above is not intended to be exhaustive or to limit the scope of the claims to the precise form disclosed. Many modifications and variations are possible in light of the above teachings. The embodiments were chosen and described to best explain the principles of operation and practical application, thereby enabling others skilled in the art to utilize them. [Explanation of symbols]

[0146] 100 Communication Systems 102 Source Devices 104 Video Sources 106 Encoder Components 108 Video Bitstream 110 Network 112 Server System 114 Coda Constituents 116 Encoded Video Data 120 Electronic Devices 122 Decoder Components 124 display 202 Source Coder 204 Controller 206 Predictors 208 Reference Picture Memory 210 Local Decoder 212 Coding Engine 214 Entropy Coder 216 video sequences 218 Communication Channels 252 buffer memory 254 Parser 256 Loop Filter Unit 258 Scaler / Descaler Unit 260 Motion Compensation Prediction Unit 262 Intra-picture prediction unit 264 Current Picture Memory 266 Reference Picture Memory 268 Aggregators 270 symbols 302 Control circuit 304 Network Interface 306 User Interface 308 Output Devices 310 Input Devices 312 communication bus 314 memory 316 Operating Systems 318 Network Communication Module 320 Coding Module 322 Decryption Module 324 Analysis Module 326 Conversion Module 328 Prediction Module 330 Filter Module 340 Encoding Module 342 Code Module 344 Prediction Module 352 Picture Memory 500 ways 550 method

Claims

1. A video decoding method performed by one or more processors, wherein the method is A step of receiving video data containing multiple blocks from a video bitstream, A step of obtaining the value of one or more parameters associated with a block in a plurality of blocks from the video bitstream, wherein the one or more parameters correspond to the arithmetic coder probability update rate, and the value of each of the one or more parameters is determined from a predetermined set of values. A step of calculating the arithmetic coder probability update rate based on the respective values ​​of the one or more parameters signaled in the video bitstream, The steps include determining one or more coding contexts based on the calculated arithmetic coding probability update rate, The steps of decoding the block in the plurality of blocks based on the one or more coding contexts, Methods that include...

2. The method according to claim 1, wherein the respective values ​​of the one or more parameters are obtained from the high-level syntax in the video bitstream.

3. The method according to claim 1, wherein the respective values ​​of the one or more parameters are selected by an encoder component.

4. The method according to claim 1, wherein one or more of the parameters include an offset parameter, and the predetermined value of the offset parameter is in the range of 0 to 8.

5. The method according to claim 1, wherein the one or more parameters include two or more count parameters, and the predetermined values ​​of the two or more count parameters are in the range of 0 to 128.

6. The method according to claim 5, wherein the two or more count parameters include a first parameter and a second parameter, and the value of each of the first parameters must be less than the value of each of the second parameters.

7. The method according to claim 5, wherein the difference value between the two or more count parameters is signaled via the video bitstream.

8. The method according to claim 1, wherein one or more of the parameters include a syntax size parameter, and the predetermined value of the syntax size parameter is in the range of 0 to 4.

9. The method according to claim 1, wherein the step of obtaining the respective values ​​of one or more parameters includes the step of obtaining a binary representation of the respective values.

10. The step of obtaining the respective values ​​of one or more of the aforementioned parameters is: For each of the two or more hypotheses, the step of obtaining the hypothesis-specific values ​​of the one or more parameters. The method according to claim 1, including the method described in claim 1.

11. The method according to claim 1, wherein the step of obtaining the respective values ​​of one or more parameters includes the step of obtaining an index from the video bitstream to a lookup table.

12. A default value is specified for each of the one or more parameters, and a flag in the video bitstream specifies whether to use the respective default value for the first parameter of the one or more parameters. The method described above is A step of assigning the respective default values ​​to the first parameter according to the flag having a first value, A step of obtaining the respective values ​​of the first parameter from the video bitstream according to the flag having a second value, The method according to claim 1, further comprising:

13. The method according to claim 12, wherein different flags are signaled for each hypothesis of two or more hypotheses.

14. The step of obtaining the respective values ​​of one or more parameters includes the step of obtaining the first value of the first parameter of the one or more parameters, and the step of obtaining the second value of the second parameter of the one or more parameters, The step of calculating the arithmetic coda probability update rate includes the step of calculating the arithmetic coda probability update rate according to the first hypothesis using the first value of the first parameter and the second value of the second parameter, The method further includes the step of calculating a second arithmetic coda probability update rate according to a second hypothesis, using the first value of the first parameter and the third value of the second parameter. The method according to claim 1.

15. An apparatus configured to perform the method described in any one of Claims 1 to 14.

16. A computer program for causing one or more processors to perform the method described in any one of claims 1 to 14.

Images