Features of range asymmetric digital system encoding and decoding

Abstract

Innovations in range asymmetric numeral systems (“RANS”) encoding and decoding are described herein. Some of these innovations relate to hardware implementations of RANS decoding that organize operations in two stages, which can improve computational efficiency of RANS decoding. Other innovations relate to adapting RANS encoding / decoding to different distributions or patterns of values for symbols. For example, RANS encoding / decoding can be adapted by switching a default symbol width (number of bits per symbol), adjusting the symbol width on a per-fragment basis for different symbol fragments, switching between different static probability models on a per-fragment basis for different symbol fragments, and / or selectively flushing (or preserving) a state of a RANS decoder on a per-fragment basis for different symbol fragments. In many cases, such innovations can improve compression efficiency while also providing computationally efficient performance.

Description

[0001] This application is a divisional application of the international application PCT / US2020 / 032397, filed on May 11, 2020, entered the Chinese national phase on December 27, 2021, and has the Chinese national application number 202080047288.1, entitled "Features of Encoding and Decoding of Range Asymmetric Digital Systems". Background Technology

[0002] With the advent of media streaming on the Internet and other digital networks, digital media processing has become ubiquitous. Engineers use compression to process media efficiently while still maintaining quality. One goal of media compression is to represent media signals in a way that provides the maximum signal quality for a given number of bits. In other words, this goal is to represent media signals using the fewest possible bits for a given quality level. Other goals, such as limiting computational complexity, improving resilience to transmission errors, and limiting the total latency due to encoding / transmission / decoding, are applied in certain situations.

[0003] Media compression typically involves one or more stages of prediction, frequency conversion, and quantization, followed by entropy coding. Corresponding media decompression typically involves entropy decoding, followed by one or more stages of inverse quantization, inverse frequency conversion, and prediction. Generally, entropy coding transforms input symbols into coded data with a lower bit rate by utilizing redundancy in the input symbols (e.g., using patterns of many input symbols with common values ​​and multiple input symbols with rare values). Entropy decoding transforms the coded data into output symbols corresponding to the input symbols. Many variations of entropy coding / decoding exist, offering different trade-offs in compression efficiency (reduction in bit rate) and computational complexity. For example, Huffman coding / decoding is computationally simple but has poor compression efficiency for certain distributions of input symbol values. On the other hand, arithmetic coding / decoding generally has much better compression efficiency at the cost of much higher computational complexity.

[0004] Asymmetric digital system (“ANS”) encoding / decoding potentially offers high compression efficiency (comparable to arithmetic encoding / decoding) and low computational complexity (comparable to Huffman encoding / decoding). In particular, range ANS (“RANS”) encoding / decoding works well when symbols have many possible values ​​(a large alphabet) but some values ​​(such as zero) are very general. RANS encoding / decoding also allows the outputs from multiple RANS encoders to be interleaved into a single output bitstream of encoded data, and multiple RANS decoders can be used to simultaneously decode symbols from the bitstream, which can accelerate the RANS encoding / decoding process.

[0005] Given the importance of entropy coding / decoding to the overall efficiency of media compression and decompression, it has attracted considerable attention in research and development. While previous RANS coding / decoding methods have provided good performance for many situations, there is room for improvement in the computational efficiency and adaptability of RANS coding / decoding. Summary of the Invention

[0006] In summary, this paper details innovations in the encoding and decoding of Range Asymmetric Digital Systems (“RANS”). Some of these innovations involve hardware implementations of RANS decoding that organize operations in two phases, improving the computational efficiency of RANS decoding. Other innovations involve adapting RANS encoding / decoding to different distributions or patterns of symbol values. For example, RANS encoding / decoding can be adapted by: switching the default symbol width (number of bits per symbol), adjusting the symbol width on a segment-by-segment basis for different symbol segments (where segments may include a variable number of symbols and a variable amount of encoded data), switching between different static probability models on a segment-by-segment basis for different symbol segments, and / or selectively refreshing (or retaining) the state of the RANS decoder on a segment-by-segment basis for different symbol segments. In many cases, such innovations improve compression efficiency while also providing computationally efficient performance.

[0007] According to the first set of innovations described herein, a computer system includes an encoded data buffer and a RANS decoder. The encoded data buffer is configured to store encoded data for at least a portion of a bitstream. The RANS decoder is configured to perform operations in multiple stages using dedicated hardware. Specifically, the RANS decoder is configured to perform operations in a first stage and a second stage. These operations include, as part of the first stage, selectively updating the state of the RANS decoder using probabilistic information for output symbols from previous iterations. These operations also include, as part of the second stage, selectively incorporating portions of the encoded data from the input buffer into the state of the RANS decoder, and selectively generating output symbols for the current iteration using the state of the RANS decoder. In this way, the RANS decoder can decode the encoded data in a computationally efficient manner using dedicated hardware.

[0008] According to the second set of innovations described herein, a computer system includes a RANS encoder and an encoded data buffer. The RANS encoder is configured to encode input symbols to generate encoded data for at least a portion of a bitstream. Specifically, for encoding, the RANS encoder is configured to perform operations including: selecting a symbol width from a plurality of available symbol widths, configuring the RANS encoder to perform RANS encoding with the selected symbol width, and performing RANS encoding with the selected symbol width. As part of the configuration of the RANS encoder, the RANS encoder is configured to select a predefined lookup table set having probabilistic information for the selected symbol width. In this way, the RANS encoder can adapt to different symbol widths (or different probability distributions) of input symbols for different streams, potentially improving compression efficiency. The encoded data buffer is configured to store at least a portion of the encoded data for the bitstream for output.

[0009] For the corresponding decoding, a computer system includes an encoded data buffer and a RANS decoder. The encoded data buffer is configured to receive and store encoded data for at least a portion of the bitstream. The RANS decoder is configured to decode the encoded data for at least a portion of the bitstream to generate output symbols. Specifically, for decoding, the RANS decoder is configured to perform operations including: selecting a symbol width from a plurality of available symbol widths, configuring the RANS decoder to perform RANS decoding with the selected symbol width, and performing RANS decoding with the selected symbol width. As part of the configuration of the RANS decoder, the RANS decoder is configured to select a predefined lookup table set containing probability information for the output symbols for the selected symbol width. In this way, the RANS decoder can adapt to different symbol widths (or different probability distributions) for the output symbols of different streams, which allows the RANS decoder to benefit from improved compression efficiency.

[0010] According to the third set of innovations described herein, a computer system includes a RANS encoder and an encoded data buffer. The RANS encoder is configured to encode input symbols to generate encoded data for at least a portion of a bitstream. Specifically, for encoding, the RANS encoder is configured to perform operations including: determining whether the state of the RANS decoder should be refreshed and reinitialized for decoding the encoded data for at least a portion of the bitstream; setting syntax elements indicating the decision; and performing RANS encoding. In this way, the RANS encoder can determine on a segment-by-segment basis whether the RANS decoder should (a) refresh and reinitialize its state for decoding a given segment, or (b) continue using the state decoded from previous segments, which can improve compression efficiency. The encoded data buffer is configured to store the encoded data for at least a portion of the bitstream for output. The header in the at least portion of the bitstream includes syntax elements indicating whether the state of the RANS decoder should be refreshed and reinitialized for decoding the encoded data for at least a portion of the bitstream.

[0011] For the corresponding decoding, a computer system includes an encoded data buffer and a RANS decoder. The encoded data buffer is configured to receive and store encoded data for at least a portion of a bitstream. The header of the at least portion of the bitstream includes syntax elements that indicate whether the state of the RANS decoder should be refreshed and reinitialized for decoding the encoded data for at least a portion of the bitstream. The RANS decoder is configured to decode the encoded data for at least a portion of the bitstream to generate output symbols. Specifically, for decoding, the RANS decoder is configured to perform operations including: reading the syntax elements, (at least in part based on the syntax elements) determining whether the state of the RANS decoder should be refreshed and reinitialized for decoding the encoded data for at least a portion of the bitstream, and performing RANS decoding on the encoded data. In this way, the RANS decoder can determine on a segment-by-segment basis whether it should (a) refresh and reinitialize its state for decoding a given segment, or (b) continue using the state from decoding previous segments, which allows the RANS decoder to benefit from improved compression efficiency.

[0012] According to the fourth set of innovations described herein, a computer system includes a RANS encoder and an encoded data buffer. The RANS encoder is configured to encode input symbols to generate encoded data for at least a portion of a bitstream. Specifically, for encoding, the RANS encoder is configured to perform operations including: selecting one of a plurality of available static probability models for the encoded data for at least a portion of the bitstream; setting syntax elements indicating the selected static probability model; configuring the RANS encoder to perform RANS encoding using the selected static probability model; and performing RANS encoding using the selected static probability model. In this way, the RANS encoder can quickly and efficiently adapt to different probability distributions for input symbols on a segment-by-segment basis, potentially improving compression efficiency. The encoded data buffer is configured to store the encoded data for at least a portion of the bitstream for output. The header of the at least portion of the bitstream includes syntax elements indicating the selected static probability model for the encoded data for at least a portion of the bitstream.

[0013] For the corresponding decoding, a computer system includes an encoded data buffer and a RANS decoder. The encoded data buffer is configured to receive and store encoded data for at least a portion of a bitstream. The header of the at least portion of the bitstream includes syntax elements indicating the selection of a static probability model for the encoded data for at least a portion of the bitstream from a plurality of available static probability models. The RANS decoder is configured to decode the encoded data for at least a portion of the bitstream to generate output symbols. Specifically, for decoding, the RANS decoder is configured to perform operations including: reading the syntax elements, selecting one of the plurality of available static probability models (at least in part based on the syntax elements), configuring the RANS decoder to perform RANS decoding using the selected static probability model, and performing RANS decoding of the encoded data using the selected static probability model. In this way, the RANS decoder can quickly and efficiently adapt to different probability distributions for the output symbols on a segment-by-segment basis, which allows the RANS decoder to benefit from improved compression efficiency.

[0014] According to the fifth set of innovations described herein, a computer system includes a RANS encoder and an encoded data buffer. The RANS encoder is configured to encode input symbols to generate encoded data for at least a portion of a bitstream. Specifically, for encoding, the RANS encoder is configured to perform operations including: determining an adjustment for the symbol width of the encoded data for at least a portion of the bitstream; setting a syntax element indicating the adjustment of the symbol width; configuring the RANS encoder to perform RANS encoding with the adjusted symbol width; and performing RANS encoding with the adjusted symbol width. In this way, the RANS encoder can quickly and efficiently adapt to different symbol widths for input symbols on a segment-by-segment basis, potentially improving compression efficiency. The encoded data buffer is configured to store the encoded data for at least a portion of the bitstream for output. The header in the at least portion of the bitstream includes a syntax element indicating the adjustment of the symbol width of the encoded data for at least a portion of the bitstream.

[0015] For the corresponding decoding, a computer system includes an encoded data buffer and a RANS decoder. The encoded data buffer is configured to receive and store encoded data for at least a portion of a bitstream. The header in the at least portion of the bitstream includes syntax elements that indicate an adjustment to the symbol width of the encoded data for at least a portion of the bitstream. The RANS decoder is configured to decode the encoded data for at least a portion of the bitstream to generate output symbols. Specifically, for decoding, the RANS decoder is configured to perform operations including: reading the syntax elements, determining the adjustment to the symbol width (at least in part based on the syntax elements), configuring the RANS decoder to perform RANS decoding with the adjusted symbol width, and performing RANS decoding with the adjusted symbol width. In this way, the RANS decoder can quickly and efficiently adapt to different symbol widths for the output symbols on a segment-by-segment basis, which allows the RANS decoder to benefit from improved compression efficiency.

[0016] The innovations described herein include, but are not limited to, those covered by the claims and characterization table at the end of this application. Corresponding innovations may be implemented as part of a method, a part of a computer system configured to perform the method, or a part of a computer-readable medium storing computer-executable instructions for causing one or more processors in a computer system to perform the method. Various innovations may be used in combination or individually. This overview is provided to introduce, in a simplified form, a series of concepts that will be further described in the detailed description below. This overview is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. The foregoing and other objects, features, and advantages of the invention will become more apparent from the following detailed description, which is taken with reference to the accompanying drawings and illustrates several examples. Examples may also have other and different applications, and some details may be modified in various aspects without departing from the spirit and scope of the disclosed innovations. Attached Figure Description

[0017] The following figures illustrate some features of the disclosed innovation.

[0018] Figure 1 This is a diagram illustrating example computer systems in which some of the described examples can be implemented.

[0019] Figure 2a and Figure 2b This is a diagram illustrating an example network environment in which some of the described examples can be implemented.

[0020] Figure 3 and Figure 4 These are diagrams illustrating example media encoder systems and example media decoder systems in which some of the described examples can be implemented.

[0021] Figure 5 and Figure 6 These are diagrams illustrating example RANS encoder systems and example RANS decoder systems in which some of the described examples can be implemented.

[0022] Figure 7a and Figure 7b This is a flowchart illustrating example techniques for RANS encoding and RANS decoding, respectively, according to some examples described herein.

[0023] Figure 8 This is a diagram illustrating the stages of an example two-stage RANS decoding based on some examples described herein.

[0024] Figures 9a to 9d This is a flowchart illustrating example techniques for two-stage RANS decoding, based on some examples described herein.

[0025] Figure 10a and Figure 10b This is a flowchart illustrating example techniques for switching symbol widths during RANS encoding and RANS decoding, respectively, according to some examples described herein.

[0026] Figure 11a and Figure 11b This is a flowchart illustrating example techniques for selectively refreshing / reinitializing the RANS decoder state on a segment-by-segment basis during RANS encoding and RANS decoding, according to some examples described herein.

[0027] Figure 12a and Figure 12b This is a flowchart illustrating example techniques for switching static probability models on a segment-by-segment basis during RANS encoding and RANS decoding, according to some examples described herein.

[0028] Figure 13a and Figure 13b This is a flowchart illustrating example techniques for adjusting symbol width on a segment-by-segment basis during RANS encoding and RANS decoding, according to some examples described herein.

[0029] Figure 14 This is a diagram illustrating example bitstreams based on some examples described in this article.

[0030] Figures 15a to 15k This is a list of code examples for decoder modules that illustrate some of the examples described in this article. Detailed Implementation

[0031] This paper details innovations in the encoding and decoding of Range Asymmetric Digital Systems (“RANS”). Some of these innovations involve hardware implementations of RANS decoding that organize operations in two stages, improving the computational efficiency of RANS decoding. Other innovations involve adapting RANS encoding / decoding to different distributions or patterns of symbol values. For example, RANS encoding / decoding can be adapted by switching the default symbol width (number of bits per symbol). Alternatively, for different symbol segments, RANS encoding / decoding can be adapted by adjusting the symbol width on a segment-by-segment basis, switching between different static probability models on a segment-by-segment basis, and / or selectively refreshing (or retaining) the state of the RANS decoder on a segment-by-segment basis. In many cases, such innovations improve compression efficiency while providing computationally efficient performance.

[0032] In the examples described herein, the same reference numerals in different figures denote the same parts, modules, or operations. More generally, various alternatives to the examples described herein are possible. For example, some methods in the methods described herein can be modified by changing the order of the described method actions, by splitting, repeating, or omitting certain method actions, etc. Various aspects of the disclosed techniques can be used in combination or individually. Some of the innovations described herein solve one or more of the problems mentioned in the background art. Generally, a given technique / tool ​​cannot solve all such problems. It should be understood that other examples can be utilized, and structural, logical, software, hardware, and electrical changes can be made without departing from the scope of the invention. Therefore, the following description should not be construed as limiting. Rather, the scope of the invention is defined by the appended claims and the character list.

[0033] I. Example Computer System Figure 1 Generalized examples of suitable computer systems (100) in which several of the innovations described herein can be implemented are shown. The innovations described herein relate to RANS encoding and / or RANS decoding. Apart from its use in RANS encoding and / or RANS decoding, the computer system (100) is not intended to imply any limitations on its scope of use or functionality, as the innovations can be implemented in a wide variety of computer systems, including dedicated computer systems suitable for operation in RANS encoding and / or RANS decoding.

[0034] refer to Figure 1The computer system (100) includes one or more processing cores (110…11x) of a central processing unit (“CPU”) and local on-chip memory (118). The CPU’s processing cores (110…11x) execute computer-executable instructions. The number of processing cores (110…11x) depends on the implementation and may be, for example, 4 or 8. The local memory (118) may be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.) or some combination of both, accessible by the respective processing cores (110…11x). For a software-based implementation of RANS encoding / decoding, the local memory (118) may store software (180) in the form of computer-executable instructions for operations performed by the respective processing cores (110…11x), thereby enabling one or more innovative tools for RANS encoding and / or RANS decoding. Alternatively, for a GPU-accelerated implementation of RANS encoding / decoding or a hardware-accelerated implementation of RANS encoding / decoding, the local memory (118) may store software (180) in the form of computer-executable instructions for operations performed by corresponding processing cores (110...11x) for one or more drivers or other software layers to implement one or more innovative tools for RANS encoding and / or RANS decoding.

[0035] The computer system (100) also includes one or more processing cores (120…12x) of a graphics processing unit (“GPU”) and local on-chip memory (128). The processing cores (120…12x) of the GPU run computer-executable instructions (e.g., shader routines for media encoding / decoding operations). The number of processing cores (120…12x) depends on the implementation and can be, for example, 64 or 128. The local memory (128) can be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.) or some combination of both, which can be accessed by the respective processing core(s)(s)(s)(s). For a GPU-accelerated implementation of RANS encoding / decoding, the local memory (128) can store software implementing one or more innovative tools for RANS encoding and / or RANS decoding in the form of computer-executable instructions for operations performed by the respective processing core(s)(s)(s)(s).

[0036] The computer system (100) also includes one or more modules (130...13x) of dedicated codec hardware (e.g., application-specific integrated circuits (“ASICs”) or other integrated circuits) and local on-chip memory (138). In some example implementations, the modules (130...13x) include one or more RANS decoder modules, feeder modules configured to provide encoded data to input buffers for the respective RANS decoder modules, and decoder array modules configured to manage the RANS decoder modules. Figure 6 An example RANS decoder (630) and its associated buffer are shown as part of a RANS decoder system (600). Figures 15a to 15k A list of code (1501 to 1511) for example RANS decoder modules is shown. The modules (130…13x) may alternatively or additionally include one or more RANS encoder modules, output modules configured to interleave outputs from the respective RANS encoder modules, and encoder array modules configured to manage the RANS encoder modules. Figure 5 An example RANS encoder (520) and associated buffer are shown as part of a RANS decoder system (500). Local memory (138) may be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.) or some combination of both, which can be accessed by the corresponding modules (130...13x).

[0037] More generally, the term "processor" can refer to any device capable of processing computer-executable instructions and can include microprocessors, microcontrollers, programmable logic devices, digital signal processors, and / or other computing devices. A processor can be a CPU, other general-purpose units, or the processing core of a GPU. A processor can also be a special-purpose processor implemented using, for example, an ASIC or a field-programmable gate array ("FPGA").

[0038] The term "control logic" can refer to a controller or more generally to one or more processors operable to process computer-executable instructions, determine results, and generate output. Depending on the implementation, control logic can be implemented as software executable on a CPU, as software controlling dedicated hardware (e.g., a GPU or other graphics hardware), or as dedicated hardware (e.g., in an ASIC).

[0039] Reference Figure 1The computer system (100) includes a shared memory (140), which may be volatile memory (e.g., RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.) or some combination of both, which can be accessed by processing cores(s). The memory (140) stores software (180) that implements one or more innovative tools for RANS encoding and / or RANS decoding.

[0040] The computer system (100) includes one or more network adapters (151). As used herein, the term network adapter means any network interface card (“NIC”), network interface, network interface controller, or network interface device. The network adapters (151) enable communication with another computing entity (e.g., a server, other computer system) over a network. The network may be a telephone network, a wide area network (WAN), a local area network (LAN), a storage area network (SAN), or other networks. The network adapters (151) may support wired and / or wireless connections for WANs, LANs, personal area networks (PANs), or other networks. The network adapters (151) transmit information such as computer-executable instructions, encoded media, or other data in modulated data signals over the network connections. A modulated data signal is a signal in which one or more of its characteristics are set or altered in a manner that encodes information in the signal. By way of example and not limitation, network connections may use electrical, optical, RF, or other carriers.

[0041] The camera input (152) accepts video input in analog or digital form from the camera that captures natural video. The audio input accepts audio input in analog or digital form from the microphone (152) that captures audio.

[0042] The computer system (100) optionally includes motion sensor / tracker inputs (153) that can track the movement of a user and objects around the user. For example, the motion sensor / tracker allows a user (e.g., a player of a game) to interact with the computer system (100) through a natural user interface using gestures and verbal commands. The motion sensor / tracker may incorporate gesture recognition, facial recognition, and / or voice recognition.

[0043] The game controller input (154) receives control signals from one or more game controllers via a wired or wireless connection. The control signals may indicate user input from one or more directional pads, buttons, triggers, and / or one or more joysticks of the game controller. The control signals may also indicate user input from a touchpad or touchscreen, gyroscope, accelerometer, angular rate sensor, magnetometer, and / or other control or measuring instruments of the game controller.

[0044] The computer system (100) optionally includes a media player (155) and a video input (156). The media player (155) can play DVDs, Blu-ray discs, other optical disc media, and / or other media formats. The video input (156) can accept input video in analog or digital form (e.g., from cable input, HDMI input, or other input). A graphics engine (not shown) can provide texture data for graphics in a computer-represented environment.

[0045] The video output (157) provides video output to the display device. The video output (157) may be an HDMI output or other types of output. The audio output (157) provides audio output to one or more speakers.

[0046] The memory (160) may be removable or non-removable and includes magnetic media (such as magnetic disks, magnetic tapes, or tape cartridges), optical disk media, and / or any other media that can be used to store information and is accessible within the computer system (100). The memory (160) stores instructions for implementing one or more innovative software (180) for RANS encoding and / or RANS decoding.

[0047] The computer system (100) may have additional features. For example, the computer system (100) includes one or more other input devices and / or one or more other output devices. The (multiple) other input devices may be touch input devices such as a keyboard, mouse, pen or trackball, scanning devices, or other devices that provide input to the computer system (100). The (multiple) other output devices may be a printer, CD burner, or other devices that provide output from the computer system (100).

[0048] Interconnection mechanisms such as buses, controllers, or networks (not shown) interconnect the components of the computer system (100). Typically, operating system software (not shown) provides an operating environment for other software running in the computer system (100) and coordinates the activities of the components of the computer system (100).

[0049] Figure 1 The computer system (100) is a physical computer system. Virtual machines may include, for example, Figure 1 The components of the organization shown.

[0050] The terms “application” or “program” can refer to software such as any user-mode instructions that provide functionality. The software of an application (or program) may also include instructions for operating systems and / or device drivers. The software may be stored in associated memory. The software can be, for example, firmware. While a properly programmed general-purpose computer or computing device is expected to be used to run such software, hardwired circuitry or custom hardware (e.g., ASICs) is also expected to be used in place of or in combination with software instructions. Therefore, the examples described herein are not limited to any particular combination of hardware and software.

[0051] The term "computer-readable medium" refers to any medium that contributes to providing data (e.g., instructions) that can be read by a processor and accessed within a computing environment. Computer-readable media can take many forms, including, but not limited to, non-volatile and volatile media. Non-volatile media include, for example, optical discs or magnetic disks and other permanent storage. Volatile media include dynamic random access memory ("DRAM"). Common forms of computer-readable media include, for example, solid-state drives, flash drives, hard disks, any other magnetic media, CD-ROMs, digital versatile discs ("DVDs"), any other optical media, RAM, programmable read-only memory ("PROM"), erasable programmable read-only memory ("EPROM"), USB flash drives, any other memory chips or cartridges, or any other media from which a computer can read them. The term "computer-readable storage" specifically excludes transient propagating signals, carrier waves and waveforms, or other intangible or transient media that can still be read by a computer. The term "carrier wave" can refer to an electromagnetic wave modulated in amplitude or frequency to transmit a signal.

[0052] This innovation can be described in the general context of computer-executable instructions that run on a computer system targeting a real or virtual processor. Computer-executable instructions may include instructions executable on the processing core of a general-purpose processor to provide the functionality described herein, instructions executable to control a GPU or dedicated hardware to provide the functionality described herein, instructions executable on the processing core of a GPU to provide the functionality described herein, and / or instructions executable on the processing core of a dedicated processor to provide the functionality described herein. In some implementations, computer-executable instructions may be organized into program modules. Typically, program modules include routines, programs, libraries, objects, classes, components, data structures, etc., that perform specific tasks or implement specific abstract data types. The functionality of program modules can be combined or split among program modules as needed in various embodiments. The computer-executable instructions used for program modules can run within a local or distributed computer system.

[0053] Numerous examples are described in this disclosure and are presented for illustrative purposes only. The described examples are not and are not intended to be limiting in any sense. The innovations of this disclosure are broadly applicable to many contexts, as are apparent from this disclosure. Those skilled in the art will recognize that the disclosed innovations can be practiced with various modifications and variations, such as structural, logical, software, and electrical modifications. Although specific features of the disclosed innovations may be described with reference to one or more particular examples, it should be understood that, unless expressly stated otherwise, such features are not limited to their use in the one or more particular examples describing them. This disclosure is neither a verbal description of all examples nor a list of features of the invention that must be present in all examples.

[0054] When ordinal numbers (such as "first," "second," "third," etc.) are used as adjectives preceding terms, their use (unless otherwise expressly specified) is solely to indicate a particular characteristic, such as distinguishing that characteristic from another characteristic described by the same or similar terms. The mere use of ordinal numbers such as "first," "second," "third," etc., does not indicate any physical order or location, any chronological order, or any ranking in terms of importance, quality, or other aspects. Furthermore, the use of ordinal numbers alone does not impose numerical restrictions on the characteristics identified by those ordinal numbers.

[0055] When describing elements, the words “a,” “one,” “the,” and “the” are intended to indicate the presence of one or more elements among the elements. The terms “including,” “contains,” and “have” are intended to be inclusive and mean that additional elements may exist in addition to those listed.

[0056] When describing a single device, component, module, or structure, multiple devices, components, modules, or structures (whether or not they cooperate) may be used instead of a single device, component, module, or structure. A function described as being owned by a single device may be owned by multiple devices, whether or not they cooperate. Similarly, where multiple devices, components, modules, or structures are described herein, a single device, component, module, or structure may be used instead of multiple devices, components, modules, or structures, whether or not they cooperate. A function described as being owned by multiple devices may be owned by a single device. Typically, a computer system or device may be local or distributed and may include dedicated hardware and / or any combination of hardware and software that implements the functions described herein.

[0057] Furthermore, the techniques and tools described herein are not limited to the specific examples described herein. Rather, the corresponding techniques and tools can be used independently and separately from the other techniques and tools described herein.

[0058] Devices, components, modules, or structures that communicate with each other do not need to communicate continuously unless otherwise expressly specified. Instead, such devices, components, modules, or structures only need to transmit data to each other as needed or expected, and can avoid exchanging data most of the time. For example, a device communicating with another device via the Internet may not send data to the other device for several weeks. Furthermore, devices, components, modules, or structures that communicate with each other can communicate directly or indirectly through one or more intermediaries.

[0059] As used herein, the term "transmit" refers to any manner of transferring information from one device, component, module, or structure to another. The term "receive=" refers to any manner of obtaining information from one device, component, module, or structure at another. A device, component, module, or structure can be part of the same computer system or a different computer system. Information can be passed by value (e.g., as an argument to a message or function call) or by reference (e.g., in a buffer). Depending on the context, information can be transmitted directly or conveyed through one or more intermediate devices, components, modules, or structures. As used herein, the term "connection" refers to an operational communication link between devices, components, modules, or structures, which can be part of the same computer system or a different computer system. An operational communication link can be a wired or wireless network connection, which can be direct or through one or more intermediaries (e.g., a network).

[0060] The description of examples with multiple features does not imply the need for all or even any of these features. Rather, a variety of optional features are described to illustrate multiple possible examples of the innovation described herein. Unless otherwise expressly stated, features are not essential or required.

[0061] Furthermore, although process steps and stages can be described sequentially, such a process can be configured to operate in different orders. A description of a particular sequence or order does not necessarily imply a requirement that steps / stages be performed in that order. Steps or stages can be performed in any feasible order. Moreover, some steps or stages can be performed simultaneously, although they may be described or implied as not occurring simultaneously. Describing a process as including multiple steps or stages does not mean that all or even any of the steps or stages are essential or required. Various other examples may omit some or all of the described steps or stages. Unless expressly stated otherwise, a step or stage is not essential or required. Similarly, while a product can be described as including multiple aspects, qualities, or characteristics, this does not mean that all of them are essential or required. Various other examples may omit some or all of the aspects, qualities, or characteristics.

[0062] Many of the techniques and tools described herein are illustrated with reference to media encoder / decoder systems, such as video encoder / decoder systems, audio encoder / decoder systems, or texture encoder / decoder systems. Alternatively, the techniques and tools described herein can generally be implemented in data encoder / decoder systems used for encoding / decoding text data or other data.

[0063] The listing of items does not imply that any or all of the items are mutually exclusive, unless otherwise expressly stated. Similarly, the listing of items does not imply that any or all of the items are a combination of any category, unless otherwise expressly stated.

[0064] For clarity, the terminology used in the description of computer operations in a computer system is as follows: terms such as “determine” and “select” are used. These terms refer to operations performed by one or more processors or other components in the computer system and should not be confused with actions performed by humans. The actual computer operations corresponding to these terms vary depending on the implementation.

[0065] II. Example network environment.

[0066] Figure 2a and 2b An example network environment (201, 202) is shown, including a media encoder (220) and a media decoder (270). The encoder (220) and decoder (270) are connected via a network (250) using an appropriate communication protocol. The network (250) may include the Internet and / or another computer network.

[0067] exist Figure 2a In the network environment (201) shown, each real-time communication (“RTC”) tool (210) includes both an encoder (220) and a decoder (270) for bidirectional communication. A given encoder (220) can produce output conforming to a media codec format or an extension of that format, where the corresponding decoder (270) receives encoded data from the encoder (220). Bidirectional communication can be part of a conference call or other two- or multi-party communication scenarios. Although Figure 2a The network environment (201) includes two real-time communication tools (210), but the network environment (201) may alternatively include three or more real-time communication tools (210) participating in multi-party communication.

[0068] The real-time communication tool (210) is configured to manage the encoding performed by the encoder (220). Figure 3An example encoder system (300) that can be included in a real-time communication tool (210) is shown. Alternatively, the real-time communication tool (210) may use another encoder system. The real-time communication tool (210) is also configured to manage decoding performed by a decoder (270). Figure 4 An example decoder system (400) that may be included in a real-time communication tool (210) is shown. Alternatively, the real-time communication tool (210) may use another decoder system.

[0069] exist Figure 2b In the network environment (202) shown, the encoding tool (212) includes an encoder (220) configured to encode media for delivery to multiple playback tools (214) including a decoder (270). One-way communication can be provided for monitoring systems, web surveillance systems, remote desktop conferencing presentations, game playback broadcasts, or other scenarios where media is encoded and transmitted from one location to one or more other locations for playback. Although Figure 2b The network environment (202) includes two playback tools (214), but the network environment (202) may include more or fewer playback tools (214). Typically, the playback tool (214) is configured to communicate with the encoding tool (212) to determine the encoded media stream to be received by the playback tool (214). The playback tool (214) is configured to receive the stream, buffer the received encoded data for an appropriate period of time, and begin decoding and playback.

[0070] Figure 3 An example encoder system (300) that may be included in the encoding tool (212) is shown. Alternatively, the encoding tool (212) may use another encoder system. The encoding tool (212) may also include server-side controller logic for managing connections to one or more playback tools (214). Figure 4 An example decoder system (400) that can be included in a playback tool (214) is shown. Alternatively, the playback tool (214) may use another decoder system. The playback tool (214) may also include client controller logic for managing the connection with the encoding tool (212).

[0071] III. Example Media Encoder System.

[0072] Figure 3This is a block diagram of an example encoder system (300), which, in combination with the example encoder system, can implement some of the described examples. The encoder system (300) can be a general-purpose encoding tool capable of operating in any of a variety of encoding modes, such as a low-latency encoding mode for real-time communication, a code-transfer mode, and a higher-latency encoding mode for generating media from a file or stream for playback, or it can be a specialized encoding tool adapted to one such encoding mode. The encoder system (300) can be adapted to encode specific types of content, such as camera video content, screen content, texture content for graphics. The encoder system (300) can be implemented as part of an operating system module, part of an application library, part of a standalone application, using GPU hardware, and / or using dedicated hardware. In summary, the encoder system (300) is configured to receive input (305) from a source and produce encoded data (395) in a bitstream as output to a channel. For example, the source can be a camera (for natural video), a screen capture module (for screen content), a graphics engine (for textures), or a microphone (for audio).

[0073] The encoder system (300) includes one or more prediction modules (310), one or more residual encoding modules (320), one or more residual reconstruction modules (330), one or more buffers (335), one or more entropy encoders (340), and a multiplexer (350). The encoder system (300) may include other modules (not shown) configured to perform preprocessing operations (e.g., for color space conversion, subsampling, etc.), control operations (e.g., receiving feedback from modules, providing control signals to modules to set and change encoding parameters during encoding, setting syntax elements indicating decisions made during encoding so that the corresponding decoder can make consistent decisions), filtering operations, or other operations.

[0074] Multiple prediction modules (310) are configured to predict the current unit of the media (e.g., frame, block, object, set) using previously reconstructed media content stored in multiple buffers (335). Typically, for video or image content, a block is an m × n arrangement of sample values, while a frame is an arrangement of blocks in one or more color planes. For audio content, a block or frame is a series of sample values. For texture content, the set of sample values ​​may represent texture values ​​for points of a graphic object. For example, for video content, multiple prediction modules (310) may be configured to perform motion compensation operations relative to previously encoded / reconstructed images (inter-image prediction). Alternatively, as another example, for video or image content, multiple prediction modules (310) may be configured to perform operations for intra-frame spatial prediction or intra-frame block copy prediction within an image (intra-image prediction). In some types of encoder systems (300), multiple prediction modules (310) are arranged differently. For example, for audio content, multiple prediction modules (310) may be configured to perform operations for linear prediction. In other types of encoder systems (300), there are no (multiple) prediction modules.

[0075] exist Figure 3 In this configuration, multiple prediction modules (310) are configured to generate a prediction (315) for the current media unit. An encoder system (300) is configured to determine the difference between the current media unit from the input (305) and its prediction (315). This provides the value of the residual (318). For lossy encoding, the value of the residual (318) is processed by multiple residual encoding modules (320) and multiple residual reconstruction modules (330). For lossless encoding, the multiple residual encoding modules (320) and multiple residual reconstruction modules (330) can be bypassed.

[0076] Multiple residual coding modules (320) are configured to encode the values ​​of residuals (318). Typically, the multiple residual coding modules (320) include a frequency converter and a scaler / quantizer. The frequency converter is configured to convert input domain values ​​to frequency domain (i.e., spectral transform) values. For block-based coding, the frequency converter may apply a discrete cosine transform (“DCT”), its integer approximation, or another type of forward block transform to a block of residual values ​​(or sample values, if the prediction (315) is empty), thereby producing a block of frequency transform coefficients. The scaler / quantizer is configured to scale and quantize the transform coefficients. Alternatively, the multiple residual coding modules (320) may include a scaler / quantizer but not a frequency converter, in which case the values ​​of the residuals (318) are directly scaled / quantized.

[0077] Multiple residual reconstruction modules (330) are configured to reconstruct the value of the residual (318), which typically produces an approximation of the value of the residual (318). Typically, the multiple residual reconstruction modules (320) include a scaler / inverse quantizer and an inverse frequency converter. The scaler / inverse quantizer is configured to perform inverse scaling and inverse quantization on the quantized transform coefficients. When the transform stage has not been skipped, the inverse frequency converter is configured to perform an inverse frequency transform, thereby producing the reconstructed residual value or sample value. If the transform stage has been skipped, the inverse frequency transform is also skipped. In this case, the scaler / inverse quantizer can be configured to perform inverse scaling and inverse quantization on the residual value (or sample value data), thereby producing the reconstructed value.

[0078] The encoder system (300) is configured to combine the reconstructed values ​​of the residual (318) and the prediction (315) to produce an approximate or exact reconstruction of the original content from the input (305). The reconstruction is stored in buffers (335) for use in subsequent prediction operations. (In lossy compression, some information is lost from the input (305).) The value of the residual (318) can be combined with the prediction (315) if the residual encoding module (320) and the residual reconstruction module (330) (for lossless compression) are bypassed. If the residual value has not yet been encoded / signed, the encoder system (300) can be configured to use the value of the prediction (315) as the reconstruction.

[0079] Multiple entropy encoders (340) are configured to entropy encode the outputs (e.g., quantized transform coefficients) from multiple residual coding modules (320) and side information (e.g., parameters indicating how predictions have been performed) and other side information (e.g., parameters indicating decisions made during encoding) from multiple prediction modules (310). The multiple entropy encoders (340) can be configured to determine parameters representing the quantized transform coefficients, side information, etc. The multiple entropy encoders (340) can be configured to predict the values ​​of the parameters based on contextual information and then encode the difference between the actual and predicted values. For input symbols representing the values ​​to be encoded, the multiple entropy encoders (340) can be configured to perform entropy encoding in various ways. Typical entropy coding techniques include Exponential-Golomb coding, Golomb-Rice coding, Context Adaptive Binary Arithmetic Coding (“CABAC”), differential coding, Huffman coding, run-length coding, Lempel-Ziv (“LZ”) coding, dictionary coding, RANS coding, and other variations of ANS coding, as well as combinations thereof. Multiple entropy encoders (340) can be configured to use different coding techniques for different types of data and to apply multiple techniques in combination. Specifically, multiple entropy encoders (340) include one or more RANS encoders. See below for reference. Figure 5 An example of a RANS encoder is described. A multiplexer (350) is configured to format encoded data for use as a portion of the output of a bitstream (395).

[0080] Depending on the implementation and the desired type of compression, modules of the encoder system (300) may be added, omitted, split into multiple modules, combined with other modules, and / or replaced using similar modules. In alternative embodiments, encoder systems with different modules and / or other configurations of modules perform one or more of the techniques described herein. Specific embodiments of the encoder system typically use variations or supplementary versions of the encoder system (300). The relationships shown between modules within the encoder system (300) indicate the general information flow within the encoder system; other relationships are not shown for simplicity.

[0081] An encoded data buffer (not shown) is configured to store encoded data for the bitstream (395) for output. Typically, the encoded data contains syntax elements for various bitstream syntax layers, based on the syntax of the underlying encoded media bitstream. Media metadata may also be stored in the encoded data buffer. A channel encoder (not shown) can be configured to implement one or more media system multiplexing protocols or transport protocols, in which case the channel encoder can be configured to add syntax elements as part of the syntax of the protocol(s). The channel encoder can be configured to provide output to a channel representing a memory, communication connection, or another channel for output.

[0082] IV. Example Media Decoder System.

[0083] Figure 4 This is a block diagram of an example decoder system (400), in which some of the described examples can be implemented. The decoder system (400) can be a general-purpose decoding tool capable of operating in any of a variety of decoding modes, such as a low-latency decoding mode for real-time communication and a higher-latency decoding mode for media playback from a file or stream, or it can be a dedicated decoding tool suitable for one of such decoding modes. The decoder system (400) can be implemented as part of an operating system module, part of an application library, part of a standalone application, using GPU hardware, and / or using dedicated hardware.

[0084] Encoded data is received from a channel that can represent storage, a communication connection, or another channel for input encoded data. A channel decoder (not shown) can process the encoded data from the channel. For example, a channel decoder can be configured to implement one or more media system demultiplexing protocols or transport protocols, in which case the channel decoder can be configured to parse syntax elements added as part of the syntax of the protocol(s).

[0085] An encoded data buffer (not shown) is configured to store encoded data output from the channel decoder. The encoded data contains syntax elements at various levels of the bitstream syntax, according to the syntax of the basic encoded media bitstream. The encoded data buffer can also be configured to store media metadata. Generally, the encoded data buffer is configured to temporarily store encoded data until such encoded data is used by the decoder system (400). At this time, the encoded data is transferred from the encoded data buffer to the decoder system (400). As decoding continues, new encoded data is added to the encoded data buffer, and the oldest remaining encoded data in the encoded data buffer is transferred to the decoder system (400).

[0086] The decoder system (400) is configured to receive encoded data in a bitstream (405) and produce reconstructed media as output (495). The decoder system (400) includes a demultiplexer (410), one or more entropy decoders (420), one or more residual reconstruction modules (430), one or more prediction modules (440), and one or more buffers (435). The decoder system (400) may include other modules (not shown) configured to perform control operations (e.g., receiving feedback from modules, providing control signals to modules to set and change decoding parameters during decoding), filtering operations, post-processing operations (e.g., for color space conversion, upsampling, etc.), or other operations.

[0087] An encoded data buffer is configured to receive and store encoded data from a bitstream (405) and make the received encoded data available to a demultiplexer (410). The demultiplexer (410) is configured to parse the encoded data from the bitstream (405) and provide it to the appropriate entropy decoder(420). The entropy decoder(420) is configured to entropy decode the encoded data to produce output symbols for parameters. Parameters may represent data to be provided to the residual reconstruction module(430) (e.g., quantized transform coefficients), side information to be provided to the prediction module(440) (e.g., parameters indicating how prediction has been performed), or other side information (e.g., parameters indicating decisions made during encoding). The entropy decoder(420) can be configured to predict the value of the parameter based on contextual information, decode the difference between the actual value and the predicted value, and combine the difference with the predicted value. Thus, the entropy decoder(420) can be configured to reconstruct the parameters representing the quantized transform coefficients and side information. The (multiple) entropy decoders (420) can be configured to perform entropy decoding in various ways. Typical entropy decoding techniques include exponential Columbus decoding, Columbus Rice decoding, context-adaptive binary arithmetic decoding, Huffman decoding, run-length decoding, Lempel-Ziv (“LZ”) decoding, dictionary decoding, RANS decoding, and other variations of ANS decoding, as well as combinations thereof. The entropy decoder (420) can be configured to use different decoding techniques for different types of data and to apply multiple techniques in combination. Specifically, the (multiple) entropy decoders (340) include one or more RANS decoders. See below for reference. Figure 6 An example describing a RANS decoder.

[0088] Multiple residual reconstruction modules (430) are configured to reconstruct the values ​​of the residuals (432), which typically produce approximations of the original values ​​of the residuals (432). For example, the multiple residual reconstruction modules (430) include a scaler / inverse quantizer and an inverse frequency transformer. The scaler / inverse quantizer is configured to perform inverse scaling and inverse quantization on the quantized transform coefficients. When the transform stage has not been skipped, the inverse frequency transformer is configured to perform an inverse frequency transform to produce reconstructed residual values ​​or sample values. The inverse frequency transform can be an inverse DCT, its integer approximation, or another type of inverse frequency transform. If the transform stage has been skipped, the inverse frequency transform is also skipped. In this case, the scaler / inverse quantizer can be configured to perform inverse scaling and inverse quantization on the residual values ​​(or sample value data) to produce reconstructed values. For lossless decompression, the multiple residual reconstruction modules (330) can be bypassed.

[0089] Multiple prediction modules (440) are configured to predict the current media unit (e.g., frame, block, object, set) using previously reconstructed media content stored in multiple buffers (435). For example, for video content, the multiple prediction modules (440) may be configured to perform motion compensation operations relative to previously encoded / reconstructed images (inter-image prediction). Alternatively, as another example, for video or image content, the multiple prediction modules (440) may be configured to perform intra-frame spatial prediction or intra-frame block copy prediction (intra-image prediction). In some types of decoder systems (400), the multiple prediction modules (440) are arranged differently. For example, for audio content, the multiple prediction modules (440) may be configured to perform linear prediction operations. In other types of decoder systems (440), there are no multiple prediction modules.

[0090] exist Figure 4 In this configuration, multiple prediction modules (440) are configured to generate a prediction (442) for the current media unit. A decoder system (400) is configured to combine the residual (432) and the reconstructed value of the prediction (442) to produce an approximate or exact reconstruction of the media content. The reconstruction is stored in multiple buffers (435) for use in subsequent prediction operations. If the residual value has not yet been encoded / signaled, the decoder system (400) can be configured to use the value of the prediction (442) as the reconstruction.

[0091] Depending on the implementation and the desired type of decompression, modules of the decoder system (400) may be added, omitted, split into multiple modules, combined with other modules, and / or replaced with similar modules. In alternative embodiments, decoder systems with different modules and / or other configurations of modules perform one or more of the techniques described herein. Specific embodiments of the decoder system typically use variations or supplementary versions of the decoder system (400). The relationships shown between modules within the decoder system (400) indicate the general information flow in the decoder system; other relationships are not shown for simplicity.

[0092] V. General RANS encoding / decoding.

[0093] Asymmetric digital system (“ANS”) encoding / decoding potentially offers high compression efficiency and low computational complexity. In particular, range ANS (“RANS”) encoding / decoding works well when symbols have many possible values ​​(a large alphabet), but some values ​​are very common. RANS encoding / decoding also allows the outputs from multiple RANS encoders to be interleaved into a single output bitstream of encoded data, where multiple RANS decoders can be used to simultaneously decode symbols from the bitstream, which can accelerate the RANS encoding / decoding process.

[0094] A RANS encoder generates an updated state x by modifying the input state x to encode symbols s. State x can be represented as a single natural number. The main encoding function used for RANS encoding can be expressed as: C(s, x) = floor(x / fs)< <n + mod(x, fs) + cs, where floor(input) is a function that accepts a real number as input and returns the largest integer less than or equal to that input, mod(a, b) is a function that gives the remainder of a divided by b, and <<n indicates a left shift of n bits. The value n indicates the number of bits used to represent the probability of the value of the symbol within the range 0...2n - 1. The value n depends on the implementation. For example, n is 16. The value fs represents the factor for symbol s according to the expansion function. Generally, the expansion function tracks the frequency of the possible corresponding values for symbol s as a subrange within the range 0...2n - 1. More likely values for symbol s have larger subranges and larger values of fs, while less likely values for symbol s have smaller subranges and smaller values of fs. For example, if the range is 0...65535, for a value that occurs 25% of the time, fs can be 16384, for a value that occurs 6.25% of the time, fs can be 4096, for a value that occurs 1% of the time, fs can be 655, and so on. The sum of the probabilities is 100%. Similarly, for a range represented using n bits, the sum of the values of fs is 2n. The value cs represents the offset for symbol s, where the offset cs is the sum of the subranges from f0 up to but not including fs - 1.

[0095] The RANS decoder decodes symbol s from the input state x, resulting in symbol s and an updated state x. The state x can be represented as a single natural number. The main decoding function for RANS decoding can be represented as: D(x) = (s, fs * (x>>n) + (x&mask) - cs), where >>n indicates a right shift of n bits for the value n as defined above, and & indicates a bitwise AND operation. The value mask is the n - bit value 2n - 1. Thus, the mask consists of n 1 - bits. In the decoding function, the updated value of state x is given by fs * (x>>n) + (x&mask) - cs. The value of symbol s is found such that cs <= mod(x, 2n) < cs + 1.

[0096] The encoding function C(s, x) increases the value of state x. If fs is large, the value of floor(x / fs) tends to be small, and the resulting increase in the value of state x tends to be small. On the other hand, if fs is small, the value of floor(x / fs) tends to be large, and the resulting increase in the value of state x tends to be large. Thus, for more common symbol values, the increase in state x is smaller. In any case, to prevent state x from overflowing any buffer holding it, bits are selectively shifted out of state x as output encoded data.

[0097] Conversely, the decoding function D(x) decreases the value of state x. If fs is large, the value of fs * (x >> n) tends to be large, and the resulting decrease in the value of state x tends to be small. On the other hand, if fs is small, the value of fs * (x >> n) tends to be small, and the resulting decrease in the value of state x tends to be large. Therefore, for more common symbol values, the decrease in state x is smaller. In any case, to prevent state x from underflowing (because the RANS decoder typically does not include the state for all encoded symbols at the start of decoding), bits are selectively shifted into state x as input encoded data.

[0098] For an implementation where encoded data is streamed from an encoder system (including one or more RANS encoders) to a decoder system (including one or more RANS decoders), the encoding function C(s, x) can be embedded in logic that selectively shifts the encoded data out of state x as output. Similarly, the decoding function D(x) can be embedded in logic that selectively shifts the encoded data into state x as input.

[0099] For example, the encoding function C(s, x) and the logic for selectively shifting the encoded data out of state x can be represented as follows.

[0100] while more_symbols do while x>upper_threshold[s] do write_to_output ( mod(x, b) ) x = floor(x, b) end while x = C(s, x) end while The outer while loop continues as long as there are more symbols to encode (i.e., more_symbol is true). For a given symbol s to be encoded, the RANS encoder performs operations including the inner while loop and the encoding function C(s, x). As long as state x is greater than upper_threshold[s], the RANS encoder selectively outputs encoded data from state x in log2(b) bit blocks. The value log2(b) indicates the number of bits of encoded data (state) to be output. For example, log2(b) is 8 to output one byte at a time, and b is 256. The value of upper_threshold[s] is the upper limit of the interval in which state x of the RANS encoder should fall in order to encode symbol s. If state x is above the upper limit of this interval, bits are shifted out of state x until state x falls within this interval. The function write_to_output(mod(x,b)) outputs log2(b) bits produced by mod(x,b), which is the least significant log2(b) bit of state x. Then, state x is adjusted by shifting log2(b) bits out of state x according to floor(x,b). When state x is less than or equal to the upper limit of the interval (i.e., x <= upper_threshold[s]), symbol s is encoded using the encoding function C(s, x) to produce the updated state x.

[0101] For the corresponding decoding, the decoding function D(x) and the logic for selectively shifting the encoded data into state x can be represented as follows.

[0102] while more_encoded_data do (s, x) = D(x) use(s) while x <lower_threshold do x = b × x + new_input end while end while The outer while loop continues as long as there is more encoded data to decode (i.e., more_encoded_data is true). For a given symbol s to be decoded, the RANS decoder performs operations including the decoding function D(s, x), the function using symbol s, and the inner while loop. The symbol s is decoded using the encoding function D(x), which also produces an updated state x. The symbol s is used (as indicated by the use function(s)). Then, as long as state x is less than lower_threshold, the RANS decoder selectively inputs encoded data in a block of log2(b) bits into state x. The value log2(b) indicates the number of bits of encoded data (state) to be input. For example, log2(b) is 8 to input one byte at a time, and b is 256. The value of lower_threshold is the lower limit of the interval in which the RANS decoder's state should fall so that the next symbol s can be decoded. If state x is below the lower limit of this interval, bits are shifted into that state until state x falls within that interval. Specifically, the state x is shifted by log2(b) bits according to b × x + new_input, and the value new_input is added. The value new_input has log2(b) bits.

[0103] For additional notes on RANS coding and RANS decoding, see, for example, Duda's "Asymmetric Numeral Systems: Entropy Coding Combining Speed ​​of Huffman Coding with Compression Rate of Arithmetic Coding" 24 pp. (2014) and Duda et al.'s "The use of asymmetric number systems as an accurate replacement for huffman coding" IEEE, pp. 65-69 (2015).

[0104] VI. Example RANS encoder and RANS decoder.

[0105] Previous RANS encoding / decoding methods have provided good performance in many situations, but there is room for improvement in the computational efficiency of RANS decoding hardware implementation and the adaptability of RANS encoding / decoding. This section describes the innovative features of the RANS encoder and RANS decoder. These features include, but are not limited to, the following.

[0106] A two-stage implementation of RANS decoding. A RANS decoder can be implemented in hardware using a two-stage structure. In one stage (Stage 0), the RANS decoder state is selectively updated, potentially consuming encoded data. In the other stage (Stage 1), new encoded data is selectively incorporated into the RANS decoder state, and output symbols are selectively generated. For a given amount of area and power, the two-stage structure provides high throughput. Furthermore, the two-stage structure allows for higher clock rates compared to other RANS decoding implementations. Moreover, the two-stage structure allows for simultaneous (concurrent) decoding of multiple data streams (e.g., two data streams).

[0107] Configurable symbol width. RANS encoders and decoders can have configurable default symbol widths. For example, the default symbol width for a stream's symbols can be set to d bits, where d is between 2 and 9. This allows the same RANS encoder and decoder to be used for various types of symbols.

[0108] Switchable static probabilistic models. The RANS encoder and decoder can switch between multiple static probabilistic models. This allows the RANS encoder / decoder to quickly adapt to changes in the probability distribution of symbols. Static probabilistic models can be represented using lookup tables or other "pluggable" structures. The selected static probabilistic model can be represented using syntax elements that consume a few bits in the bitstream. A moderate number of probabilistic models (e.g., 8, 16, or 32) can provide good compression efficiency without consuming excessive storage or memory resources.

[0109] The RANS decoder state can be selectively refreshed. The RANS decoder can selectively refresh its state between segments during decoding. If it contributes to compression efficiency, the final state after decoding one segment can be used as the initial state for decoding the next segment. Conversely, if compression efficiency is better when decoding the next segment begins with a new initial state, the RANS decoder state can be refreshed and reinitialized. The decision regarding whether to refresh the RANS decoder state can be signaled using syntax elements that consume a few bits in the bitstream.

[0110] Adjusting the symbol width between segments. The RANS encoder and decoder can selectively adjust the symbol width for segments. Even if all symbols in the stream have the same default symbol width, symbols in a segment of the stream may have only low values ​​(less than a threshold). In this case, the RANS encoder / decoder can adjust (narrow) the symbol width for symbols in that segment, thereby improving compression efficiency. A syntax element that consumes a few bits in the bitstream can be used to signal the adjustment of the symbol width.

[0111] The above-mentioned innovative features can be used in combination or individually.

[0112] A. Example configuration of RANS encoder / decoder.

[0113] Figure 5 An example RANS encoder system (500) in which some of the described examples can be implemented is shown. The RANS encoder system (500) includes a single RANS encoder (520), but in practice, the RANS encoder system (500) can include multiple instances of the RANS encoder (520). Figure 5 The modules shown are implemented using dedicated computing hardware (encoder logic, buffers, etc.), but can also be implemented in software using general-purpose computing hardware as an alternative.

[0114] Typically, a RANS encoder (520) is configured to accept an input symbol stream, encode the input symbols, and output encoded data as part of a bit stream. In some example implementations, the input symbols have an indicated symbol width, and the encoded data is arranged in bytes. Typically, the total number of bits output is less than the total number of bits input, thus providing compression.

[0115] The input symbol buffer (510) is configured to store input symbols for encoding. The input symbols have a symbol width (the number of bits per symbol). The input symbols may represent parameters of the transform coefficients for quantization from media (e.g., video, images, audio, graphic textures), parameters of other residual data from the media, or other data. Typically, RANS encoding / decoding tends to provide good compression efficiency for the predicted residual value, for which symbols with zero values ​​are most common, symbols with values ​​close to zero are less common, and symbols with values ​​far from zero are even rarer.

[0116] The input buffer (522) in the RANS encoder (520) is configured to store input symbols (512) provided from the input symbol buffer (510). One or more registers (524) in the RANS encoder (520) are configured to store status information. The RANS encoder (520) is configured to encode the input symbols (512) using the status information stored in the registers (524). As needed, the RANS encoder (520) writes encoded data to the output buffer (526) and removes encoded data from the status information in the registers (524). The output buffer (526) is configured to store portions (527) of the encoded data. For example, the output buffer (526) is configured to store bytes of encoded data.

[0117] The encoded data buffer (540) is configured to store a portion (527) of the encoded data provided by the output buffer (526). The encoded data buffer (540) may store multiple portions of the encoded data until the encoded data (542) is provided to the multiplexer (550). The multiplexer (550) is configured to multiplex the encoded data (542) from the encoded data buffer (540) with other information, such as configuration information (528), initial state information (529), and data from other examples of the RANS encoder.

[0118] In some example implementations, the RANS encoder (520) has a variable symbol width. For example, the RANS encoder (520) has an input parameter that indicates the default symbol width for the input symbols provided from the input symbol buffer (510). Typically, the input parameter is set when the RANS encoder (520) is initialized. This allows the RANS encoder (520) to switch between different default symbol widths for different encoding sessions. For example, the default symbol width can be a value in the range of 2 bits to 9 bits. Alternatively, the default symbol width can have some other value (e.g., 1 bit, 10 bits, 12 bits or more). In alternative example implementations, the input parameter indicating the default symbol width can be changed during encoding. In other alternative example implementations, the RANS encoder (520) always encodes input symbols with a single, predefined symbol width.

[0119] In some example implementations, the RANS encoder (520) can change configuration parameters between segments of input symbols / coded data. A segment can include a variable number of input symbols and a variable number of encoded data. The RANS encoder (520) is configured to set boundaries between segments based on various factors. Primarily, the RANS encoder (520) is configured to change configuration parameters in doing so, thereby improving compression efficiency. The RANS encoder (520) can also be configured to set boundaries between segments at existing boundaries in the media content (e.g., pictures, frames, coding units, objects) or to improve resilience to data loss (by allowing faster recovery from a known initial state).

[0120] In some example implementations, such as Figure 5As shown, the RANS encoder (520) is configured to access a lookup table during RANS encoding, which stores probability information for different static probability models and different symbol widths. A memory (530) is configured to store the lookup tables. In some example implementations, the memory (530) is configured to store lookup tables for 16 different static probability models and for each possible symbol width. The RANS encoder (520) is configured to use the symbol width (521) and the static probability model selector (523) as indexes for the lookup tables and is configured to receive probability information (532) as a return. Alternatively, the memory (530) can be configured to store lookup tables for more or fewer static probability models (e.g., a single static probability model), or the RANS encoder (520) can be configured to use dynamic probability models. Instead of using lookup tables, the probability models can be represented in some other way (e.g., using formulas or equations with less storage but slower than lookup operations). Figure 5 In the example shown (with multiple static probability models), the RANS encoder (520) is configured to signal a syntax element indicating which static probability model to use during encoding and decoding as part of the configuration information (528). The RANS encoder (520) can switch static probability models between segments as it switches configuration parameters between segments. This allows the RANS encoder (520) to switch mid-stream to a static probability model that provides more efficient compression given the local probability distribution of the values ​​of the input symbols.

[0121] In some example implementations, the RANS encoder (520) is configured to adjust the symbol width used for RANS encoding relative to the default symbol width. This allows the RANS encoder (520) to reduce the symbol width used for RANS encoding / decoding if all the input symbols being encoded have values ​​below a certain threshold. For example, if the default symbol width is 8 bits for input symbols with values ​​in the range of 0…255, but all input symbols have values ​​less than 64, then the symbol width used for compression could be 6 bits (because for the range of 0…63, 2⁶ = 64). Typically, for the default symbol width d, the value can be checked against thresholds 2d-1, 2d-2, 2d-3, etc., to determine if the symbol width can be reduced. In some example implementations, the adjustment to the symbol width can be 0, -1, -2, or -3. Alternatively, other values ​​can be used for adjusting the symbol width. The RANS encoder (520) is configured to signal syntax elements indicating the adjustment of the symbol width used during encoding and decoding as part of the configuration information (528). When the RANS encoder (520) switches configuration parameters between segments, it can switch the adjustment of symbol width from segment to segment. This allows the RANS encoder (520) to switch to a symbol width that provides more efficient compression given local values ​​of the input symbols in the middle of the stream. In an alternative example implementation, the RANS encoder (520) does not switch between different symbol widths.

[0122] In some example implementations, the RANS encoder (520) is configured to determine whether the corresponding RANS decoder should refresh its state for a new segment or use the final state from decoding a previous segment as the initial state for the new segment. The RANS encoder (520) is also configured to determine and signal initial state information (529) for the new segment when the RANS decoder state is refreshed. In practice, the initial state information (529) can be signaled as the first part of the encoded data (542) for the new segment. For example, the initial state information (529) may include four bytes of encoded data (542) or some other amount of encoded data (542). The RANS encoder (520) is configured to signal a syntax element indicating whether the RANS decoder state should be refreshed for a new segment as part of the configuration information (528). The RANS encoder (520) can signal the syntax element for each segment. This allows the RANS encoder (520) to selectively maintain or refresh the RANS decoder state depending on which option provides more efficient compression. Even if the retained RANS decoder state is not ideal, using it eliminates the need to signal the initial state information for new segments (529). In an alternative example implementation, the RANS encoder (520) always refreshes the RANS decoder state between segments. In other alternative example implementations, the RANS encoder (520) always maintains the RANS decoder state between segments.

[0123] Figure 6 An example RANS decoder system (600) in which some of the described examples can be implemented is shown. The RANS decoder system (600) includes a single RANS decoder (630), but in practice, the RANS decoder system (600) can include multiple instances of the RANS decoder (630). Figure 6 The modules shown are implemented using dedicated computing hardware (decoder logic, buffers, etc.), but alternatively, they can be implemented in software using general-purpose computing hardware.

[0124] Typically, the RANS decoder (630) is configured to receive encoded data as part of a bitstream, decode the output symbols, and generate an output symbol stream. In some example implementations, the encoded data is arranged in bytes, and the output symbols have an indicated symbol width. Typically, the total number of bits in the output is greater than the total number of bits in the input, thus providing decompression.

[0125] A demultiplexer (610) is configured to demultiplex encoded data (612) from the input bitstream, as well as other information (e.g., configuration information (614), initial state information (616), and other examples of data for the RANS decoder). The demultiplexer (610) is configured to provide encoded data (612) to an encoded data buffer (620), which is configured to store the encoded data (612) and provide it to the RANS decoder (630) as needed. The encoded data buffer (620) may store multiple portions (e.g., bytes) of the encoded data until the appropriate portion (622) is provided to the RANS decoder (630).

[0126] An input buffer (632) is configured to store a portion of the encoded data provided by the encoded data buffer (620). For example, the input buffer (632) is configured to store bytes of encoded data. The RANS decoder (630) is configured to read a portion of the encoded data from the input buffer (632) as needed and shift that portion of the encoded data into state information. One or more registers (634) in the RANS decoder (630) are configured to store state information. The RANS decoder (630) is configured to decode output symbols using the state information stored in register(634). The RANS decoder (630) can perform decoding using a two-stage structure as described in the next section or some other method. An output buffer (636) in the RANS decoder (630) is configured to store output symbols (638), which are then provided to the symbol vector buffer (650).

[0127] A symbol vector buffer (650) is configured to store output symbols generated during decoding. The output symbols have a symbol width (the number of bits per symbol). The output symbols may represent parameters of quantized transform coefficients from media (e.g., video, images, audio, textures for graphics), parameters of other residual data from the media, or other data.

[0128] In some example implementations, the RANS decoder (630) has a variable symbol width. For example, the RANS decoder (630) has an input parameter indicating the default symbol width for the output symbols generated by the RANS decoder (630). Typically, the input parameter is set when the RANS decoder (630) is initialized. This allows the RANS decoder (630) to switch between different default symbol widths for different decoding sessions. For example, the default symbol width can be a value in the range of 2 bits to 9 bits. Alternatively, the default symbol width can have some other value (e.g., 1 bit, 10 bits, 12 bits or more bits). In alternative example implementations, the input parameter indicating the default symbol width can be changed during decoding. In other alternative example implementations, the RANS decoder (6300) always decodes output symbols with a single, predefined symbol width.

[0129] In some example implementations, the RANS decoder (630) can change configuration parameters between segments of output symbols / coded data. A segment can include a variable number of output symbols and a variable number of coded data segments. The RANS decoder (630) is configured to determine the boundaries between segments based on information signaled in the bitstream, such as the byte count of the coded data in the corresponding segment, the presence of a start code or other marker in the bitstream.

[0130] In some example implementations, such as Figure 6 As shown, the RANS decoder (630) is configured to access lookup tables storing probability information for different static probability models and different symbol widths during RANS decoding. A memory (640) is configured to store the lookup tables. In some example implementations, the memory (640) is configured to store lookup tables for 16 different static probability models and for each possible symbol width. The RANS decoder (640) is configured to use the symbol width (631) and the static probability model selector (633) as indexes for the lookup tables and is configured to receive probability information (642) in return. Alternatively, the memory (640) can be configured to store lookup tables for more or fewer static probability models (e.g., a single static probability model), or the RANS decoder (630) can be configured to use dynamic probability models. Instead of using lookup tables, the probability models can be represented in some other way (e.g., using formulas or equations with less storage but slower than lookup operations). Figure 6In the example shown (with multiple static probability models), the RANS decoder (630) is configured to receive a syntax element indicating which static probability model to use during decoding as part of configuration information (614). The RANS decoder (630) can switch static probability models from segment to segment as it switches configuration parameters between segments. This allows the RANS decoder (630) to switch to a static probability model mid-stream that provides more efficient compression given the local probability distribution of the values ​​of the input symbols.

[0131] In some example implementations, the RANS decoder (630) is configured to adjust the symbol width used for RANS decoding relative to the default symbol width. This allows the RANS decoder (520) to reduce the symbol width used for RANS decoding if the output symbols being decoded all have values ​​below a certain threshold, as described above. In some example implementations, the adjustment to the symbol width can be 0, -1, -2, or -3. Alternatively, other values ​​can be used for adjusting the symbol width. The RANS decoder (630) is configured to receive a syntax element indicating the adjustment of the symbol width used during decoding as part of configuration information (614). The RANS decoder (630) can switch the adjustment to the symbol width between segments as the configuration parameters are switched between segments. This allows the RANS decoder (630) to switch in the middle of the stream to provide a more efficient compression symbol width given local values ​​of the input symbols. In alternative example implementations, the RANS decoder (630) does not switch between different symbol widths.

[0132] In some example implementations, the RANS decoder (630) is configured to decide whether to refresh its state for a new segment or use the final state from decoding a previous segment as the initial state for the new segment. The RANS decoder (630) is also configured to receive initial state information (616) for the new segment when the RANS decoder state is refreshed. In practice, the initial state information (616) may be signaled as the first part of the encoded data (612) for the new segment. For example, the initial state information (616) may include four bytes of encoded data (612) or some other amount of encoded data (612). The RANS decoder (630) is configured to receive a syntax element indicating whether the RANS decoder state should be refreshed for a new segment as part of configuration information (614). The RANS decoder (630) may receive a syntax element for each segment. This allows the RANS decoder (630) to selectively maintain or refresh the RANS decoder state. In alternative example implementations, the RANS decoder (630) always refreshes the RANS decoder state between segments. In other alternative example implementations, the RANS decoder (630) always maintains the RANS decoder state between segments.

[0133] B. Generalized RANS encoding / decoding techniques.

[0134] Figure 7a and 7b Example techniques (700) for RANS encoding and example techniques (750) for RANS decoding are shown respectively. The example technique (700) for RANS encoding can be implemented, for example, by means of an implementation such as the reference. Figure 5 The RANS encoder described or other RANS encoder encoding tools are used to perform this. Example techniques (750) for RANS decoding can be implemented, for example, by means of implementations such as those in the reference. Figure 6 The RANS decoder or other RANS decoder decoding tools described herein are used to perform the decoding.

[0135] Reference Figure 7a The encoding tool uses a RANS encoder to encode the input symbols (720), thereby generating encoded data for at least a portion of the bitstream. Typically, the input symbols are used for residual data of media (e.g., video, images, audio, textures for graphics), but alternatively, the input symbols can be used for some other type of data. The RANS encoder implements one or more of the innovations described herein. For example, the RANS encoder implementation is as referenced. Figure 10a , Figure 11a , Figure 12a and / or Figure 13a The operations described. Alternatively, the RANS encoder implements other and / or additional operations for RANS encoding.

[0136] The encoding tool outputs (730) encoded data for at least a portion of the bitstream. The encoded data may include syntax elements indicating configuration parameters, such as references... Figure 11a , Figure 12a and / or Figure 13a As described. Alternatively, the encoded data may include syntax elements that indicate other and / or additional configuration parameters.

[0137] The example technique (700) can be executed as a method by an encoding tool. A computer system including a RANS encoder and an encoded data buffer can be configured to execute the example technique (700). One or more computer-readable media can store computer-executable instructions thereon, which, when programmed thereon, are used to cause one or more processors to execute the example technique (700). In addition, one or more computer-readable media can store encoded data generated by the example technique (700) thereon.

[0138] refer to Figure 7b The decoding tool receives (760) encoded data for at least a portion of the bitstream. The encoded data can be stored, for example, in an encoded data buffer configured to store encoded data. The encoded data may include syntax elements indicating configuration parameters, such as references... Figure 11b , Figure 12b and / or Figure 13b As described. Alternatively, the encoded data may include syntax elements that indicate other and / or additional configuration parameters.

[0139] The decoding tool uses a RANS decoder to decode at least a portion of the encoded data for the bitstream (770), thereby generating output symbols. Typically, the output symbols are used for residual data of media (e.g., video, images, audio, textures for graphics), but alternatively, the output symbols can be used for some other type of data. The RANS decoder implements one or more of the innovations described herein. For example, the RANS decoder implementation is as referenced. Figures 9a to 9d , Figure 10b , Figure 11b , Figure 12b and / or Figure 13b The operations described. Alternatively, the RANS decoder implements other and / or additional operations for RANS decoding.

[0140] The example technique (750) can be executed as a method by a decoding tool. A computer system including an encoded data buffer and a RANS decoder can be configured to execute the example technique (750). One or more computer-readable media may store computer-executable instructions thereon, which, when programmed thereon, are used to cause one or more processors to execute the example technique (750). In addition, one or more computer-readable media may store encoded data thereon, which is organized for decoding according to the example technique (750).

[0141] C. An example of RANS decoding with a two-stage structure.

[0142] This section describes a computationally simple and fast two-stage implementation of RANS decoding. In dedicated hardware, the two-stage implementation can be implemented in a compact configuration of components. In terms of compression efficiency, the two-stage implementation benefits from the compression efficiency of RANS encoding. In particular, when implemented using a static probability model and adaptive segment selection with adjustable symbol width, the two-stage implementation of RANS decoding provides excellent overall performance in many cases.

[0143] Figure 8 The stages of an example two-stage structure (800) for RANS decoding, based on some examples described herein, are shown. Figure 8 In the method shown, the RANS decoding operation is divided into two stages. In one stage (stage 0), the RANS decoder consumes the input encoded data. In the other stage (stage 1), the RANS decoder generates the output symbols. In some example implementations, each stage occurs within a separate clock cycle. In alternative example implementations, both stages occur within the same clock cycle. The stages shown in the two-stage structure (800) are logical stages. The decoding operation is performed iteratively in the order of processing in stage 0, then stage 1, then stage 0 again, then stage 1 again, and so on.

[0144] If a valid output symbol exists from a previous iteration, the output buffer (810) is configured to store the output symbol from the previous iteration. The register (820) is configured to store state information, which is represented as RANS state P1 at the start of phase 0. In some example implementations, the decoder state is a 32-bit value. Alternatively, the decoder state may have some other number of bits.

[0145] In stage 0, the RANS decoder selectively updates the RANS decoder state, potentially consuming encoded data in the RANS decoder state. The RANS decoder determines whether there is an output symbol (valid output symbol) from a previous iteration in the output buffer (810). If so, the RANS decoder determines (830) the forward probability information for the output symbol (e.g., using one or more lookup tables) and uses the forward probability information to update (840) the RANS decoder state. Thus, if the output buffer (810) stores an output symbol (valid output symbol) from a previous iteration, the RANS decoder state is updated using the forward probability information for that output symbol, resulting in RANS state P0. Otherwise (no valid output symbol), the RANS decoder state remains unchanged in stage 0 (i.e., RANS state P0 is set to RANS state P1). In particular, if state x (i.e., RANS state P1) is updated in stage 0, the new state x (i.e., RANS state P0) is computed using the operation equivalent to the following, as explained in part V: x = fs * (x>>n) + (x&mask) - cs An example of such an operation is explained in section VI. M. This consumes the encoded data when it is removed from the state. However, in some iterations, the RANS decoder state is not updated, and the encoded data is not consumed.

[0146] After stage 0 processing, register (820) stores the selectively updated RANS decoder state, which is designated as RANS state P0.

[0147] As part of the Phase 1 processing, the RANS decoder selectively merges (860) portions (e.g., bytes) of the encoded data from the input buffer (850) into the RANS decoder state. If the RANS decoder state (as shown in RANS state P0 at the start of Phase 1) is below a threshold amount, the RANS decoder shifts the RANS decoder state and adds the encoded data portion from the input buffer (850). Otherwise, the RANS decoder state remains unchanged in Phase 1 (i.e., RANS state P1 is set to RANS state P0). Therefore, in some iterations, no encoded data is merged into the RANS decoder state. In any case, after the Phase 1 processing, the register (820) stores the RANS decoder state (as shown in RANS state P1 at the end of Phase 1).

[0148] In some example implementations, the RANS decoder state is a 32-bit value, and this 32-bit value is compared to a threshold. For example, the threshold is 224. If the RANS decoder state is less than the threshold, the RANS decoder state is shifted left by 8 bits, and bytes of encoded data are added to the RANS decoder state. That is, the state x is updated using an operation equivalent to the following formula.

[0149] x = x<<8 + encoded_data_byte. An example of such an operation is explained in part VI. M.

[0150] according to Figure 8 The example two-stage structure (800) shown in the diagram adds at most one portion of the encoded data to the RANS decoder state in each iteration of the stage 1 processing. If a portion of the encoded data is added to the RANS decoder state, the new portion of the encoded data can be read into the input buffer (e.g., as a portion processed in stage 0 of the next iteration). To merge multiple portions of the encoded data into the RANS decoder state, these portions are added in successive iterations of the stage 1 processing until the RANS decoder state is no longer less than a threshold, at which point a new output symbol can be generated.

[0151] Still processed as part of Phase 1, the RANS decoder selectively generates output symbols from the RANS decoder state. The RANS decoder determines whether the RANS decoder state (RANS state P1 after selective merging of the encoded data) is sufficient to generate output symbols. If so, the RANS decoder (e.g., using one or more lookup tables) determines inverse probability information and generates output symbols. The RANS decoder evaluates some parts of the RANS decoder state that indicate the rolling probabilities for different values ​​of the output symbol in order to find the output symbol. On the other hand, if the RANS decoder state (RANS state P1 after selective merging of the encoded data) is insufficient to generate output symbols, no output symbols are generated. Therefore, in some iterations, no output symbols are generated.

[0152] When an output symbol is generated, the output symbol is stored in the output buffer (810). Processing continues in another iteration of the stage 0 process.

[0153] In summary, the sequence of RANS decoding operations with a two-stage structure differs from existing methods in several ways. With the two-stage structure, the input encoded data is consumed at a finite rate (e.g., at most one byte at a time), while additional encoded data is required in the RANS decoder state. Furthermore, the selective merging operation for merging at most one byte of encoded data is interleaved with operations for selectively generating at most one output symbol and operations for selectively updating the RANS decoder state. The stages for selectively updating the RANS decoder state, selectively merging encoded data into the RANS decoder state, and selectively generating output symbols are discrete, predictable, and structured, making them well-suited for hardware implementation.

[0154] D. An example of RANS decoding with a two-stage structure.

[0155] Figure 9a An example technique (900) for RANS decoding with a two-stage structure is shown. The example technique (900) can be, for example, by using... Figure 7b The partial implementation of the decoding stage (770) shown is as described in the reference. Figure 6 The RANS decoder described herein, or other RANS decoder decoding tools, are used to perform this operation. In any case, the RANS decoder is configured to perform various operations for RANS decoding with a two-stage structure. These two stages are logical stages, and their operations can be performed in different clock cycles or in the same clock cycle. Figures 9b to 9d It shows that it can be used for Figure 9a The details of the operation performed are shown more generally in the text.

[0156] A decoding tool can initialize a RANS decoder by reading one or more syntax elements from the header for at least a portion (e.g., for a segment) of a bitstream and configuring the RANS decoder at least in part based on the syntax elements(s). For example, the syntax elements(s) ... Alternatively, the decoding tool can configure the RANS decoder in other ways. In some example implementations, the RANS decoder is initialized as part of an iteration of a two-stage process, where the configuration operation occurs in one or both stages of some iterations. Alternatively, the RANS decoder can be initialized using a separate operation before the start of an iteration of a two-stage process.

[0157] As part of the first stage (stage 0 in some examples described in this paper), the RANS decoder selectively updates the (910) RANS decoder state using probabilistic information about the output symbols from previous iterations. In some example implementations, such as Figure 9bAs shown, the RANS decoder determines (912) whether an output symbol from a previous iteration has been generated. If so, the RANS decoder determines (914) the probability information for the output symbol from the previous iteration and uses this probability information to adjust (916) the state of the RANS decoder. Adjusting the state of the RANS decoder consumes at least some of the states in the RANS decoder (and thus some of the data in the encoded data). For example, the probability information used during stage 0 processing is forward probability information. The RANS decoder can determine the probability information for the output symbol from the previous iteration by performing a lookup operation in one or more lookup tables (e.g., using the symbol width and / or the selected static probability model as the index of the lookup table(s)) or in some other way. When updating the state of the RANS decoder in the first stage, the value of state x is computed using the operation equivalent to the following, as explained in part V: x = fs * (x>>n) + (x&mask) - cs. Part VI.M describes an example of such an operation. In this example, the probability information for the output symbols from previous iterations includes: the subrange size fwd_f and the cumulative subrange threshold fwd_cf. To adjust the state x of the RANS decoder, the RANS decoder performs an adjustment equivalent to the following: x = fwd_f × x[upper] + x[lower]- fwd_cf, Where x represents the state of the RANS decoder after adjustment, x[upper] represents the upper part of the state of the RANS decoder before adjustment, and x[lower] represents the lower part of the state of the RANS decoder before adjustment.

[0158] On the other hand, if the RANS decoder determines that no output symbols from previous iterations have been generated (i.e., no valid output symbols have been generated), the RANS decoder skips adjusting its state. In this case, the RANS decoder's state remains unchanged (e.g., in...). Figure 8 In this process, RANS state P0 is set to RANS state P1.

[0159] Alternatively, the RANS decoder performs other operations to selectively update the state of the (910) RANS decoder using probability information for the output symbols from previous iterations.

[0160] As part of the second stage (stage 1 in some examples described herein), the RANS decoder selectively merges (920) portions (e.g., bytes) of the encoded data from the input buffer into the state of the RANS decoder. The input buffer can be configured to store one byte of encoded data at a time or some other number of encoded data.

[0161] In some example implementations, such as Figure 9c As shown, the RANS decoder determines (922) whether the state of the RANS decoder satisfies a threshold. For example, the RANS decoder compares the state of the RANS decoder with a threshold. If the state of the RANS decoder is less than the threshold, then the state of the RANS decoder satisfies the threshold.

[0162] If the RANS decoder state meets a threshold, the RANS decoder combines a portion of the encoded data (924) with the RANS decoder state. For example, the RANS decoder shifts the RANS decoder state by a given number of bits and adds a portion of the encoded data with that given number of bits. In some example implementations, the RANS decoder state x is tracked as a 32-bit value and updated using an operation equivalent to the following.

[0163] x = x<<8 + encoded_data_byte. Part VI.M describes an example of such an operation.

[0164] On the other hand, if the state of the RANS decoder does not meet the threshold, the RANS decoder skips the part that combines the encoded data and the state of the RANS decoder. In this case, no input encoded data is incorporated into the state of the RANS decoder for the current iteration.

[0165] Alternatively, the RANS decoder performs other operations to selectively incorporate (920) portions of the encoded data from the input buffer into the state of the RANS decoder.

[0166] As part of the second phase, the RANS decoder also uses the state of the RANS decoder to selectively generate (930) output symbols for the current iteration. For example, the output symbols are for the residual data used in the media. Alternatively, the output symbols are for some other type of data.

[0167] In some example implementations, such as Figure 9d As shown, the RANS decoder determines (932) whether the state of the RANS decoder contains enough information to generate output symbols for the current iteration.

[0168] If so, the RANS decoder determines (934) inverse probability information. For example, the RANS decoder performs a lookup operation in one or more lookup tables. The RANS decoder then uses the inverse probability information and the RANS decoder state to find (936) the output symbol for the current iteration. For example, the RANS decoder determines a subrange of the RANS decoder state associated with the output symbol for the current iteration. An example of such an operation is described in Part VI.M.

[0169] On the other hand, if the state of the RANS decoder does not contain enough information to generate an output symbol for the current iteration, the RANS decoder skips finding an output symbol for the current iteration. In this case, no output symbol is generated for the current iteration.

[0170] Alternatively, the RANS decoder performs other operations to selectively generate (930) output symbols for the current iteration using the state of the RANS decoder.

[0171] refer to Figure 9a The RANS decoder checks (940) whether to continue, and if so, continues the processing in the first stage. In this way, the RANS decoder iteratively performs the processing for the first stage and the processing for the second stage. Thus, the RANS decoder repeats selective update (910), selective merging (920), and selective generation (930) in successive iterations until there are no more output symbols to be decoded in at least a portion of the encoded data for the bitstream.

[0172] As part of the first stage, the RANS decoder can perform other operations (not shown). For example, the RANS decoder can selectively refill the input buffer from the encoded data buffer, adding new portions of the encoded data (e.g., bytes). Alternatively, as another example, the RANS decoder can selectively write output symbols from previous iterations into the symbol vector buffer.

[0173] In some example implementations, the RANS decoder is implemented using dedicated hardware. This dedicated hardware includes input buffers, output buffers, and a status register. The output buffers are configured to store output symbols from previous iterations (if any) until a replacement for the output symbol of the current iteration (if any) is used. The status register is configured to store a value representing the state of the RANS decoder. The dedicated hardware also includes logic configured to perform selective update (910) operations (coupled to the output buffers and status register), logic configured to perform selective merge (920) operations (coupled to the status register and input buffer), and logic configured to perform selective generation (930) operations (coupled to the status register and output buffer). Alternatively, the RANS decoder can be implemented using other components.

[0174] E. An example of RANS encoding / decoding with adaptive symbol width.

[0175] In some previous methods, the RANS encoder and RANS decoder processed symbols with a single predefined symbol width. Such RANS encoders and decoders cannot process symbols with different symbol widths.

[0176] This section describes examples of RANS encoders and RANS decoders with configurable symbol widths. Specifically, in some example implementations, the input parameters to the hardware-based RANS encoder or hardware-based RANS decoder indicate the symbol width used for the encoding / decoding session. Having configurable symbol widths allows the RANS encoder / decoder to work with symbols of any symbol width within a different range.

[0177] Figure 10a An example technique (1000) for RANS coding with adaptive symbol width is shown. The example technique (1000) can be performed, for example, by a coding tool as... Figure 7a The portion of the encoding stage (720) shown is implemented as referenced. Figure 5 The RANS encoder described or other RANS encoders.

[0178] Initially, as part of encoding the input symbols using a RANS encoder, the encoding tool selects a (1010) symbol width from a plurality of available symbol widths. For example, the plurality of available symbol widths includes 1 bit, 2 bits, 3 bits, 4 bits, 5 bits, 6 bits, 7 bits, 8 bits, 9 bits, 10 bits, 11 bits, and 12 bits. Alternatively, the plurality of available symbol widths may include other and / or additional symbol widths.

[0179] The encoding tool configures the RANS encoder (1020) to perform RANS encoding with a selected symbol width. Specifically, the encoding tool selects a predefined lookup table set that has probabilistic information for the selected symbol width. For example, this predefined lookup table set includes one or more predefined lookup tables with forward probability information for the selected symbol width, and one or more predefined lookup tables with inverse probability information for the selected symbol width. This predefined lookup table set may incorporate a static probability model for the encoded data selected from multiple available static probability models for different predefined lookup table sets. Alternatively, the predefined lookup tables may include probabilistic information for only a single static probability model for the selected symbol width, or the RANS encoder may use a dynamic probability model for the selected symbol width.

[0180] The encoding tool performs (1030) RANS encoding with the selected symbol width. As part of the RANS encoding, the encoding tool can optionally determine initial state information for the RANS decoder (e.g., for a segment). In this case, the encoded data output by the RANS encoder includes the initial state information.

[0181] Figure 10b An example technique (1050) for RANS decoding with adaptive symbol width is shown. The example technique (1050) can be performed, for example, by a decoding tool as... Figure 7b The decoding stage (770) shown is part of the decoding tool implemented as referenced. Figure 6 The RANS decoder described or other RANS decoders.

[0182] Initially, as part of using a RANS decoder to decode the encoded data, the decoding tool selects a (1060) symbol width from a plurality of available symbol widths. For example, the plurality of available symbol widths includes 1 bit, 2 bits, 3 bits, 4 bits, 5 bits, 6 bits, 7 bits, 8 bits, 9 bits, 10 bits, 11 bits, and 12 bits. Alternatively, the plurality of available symbol widths may include other and / or additional symbol widths.

[0183] The decoding tool configures the RANS decoder (1070) to perform RANS decoding with the selected symbol width. Specifically, the decoding tool selects a predefined lookup table set that has probabilistic information for the output symbols for the selected symbol width. For example, this predefined lookup table set includes one or more predefined lookup tables with forward probability information for the selected symbol width, and one or more predefined lookup tables with inverse probability information for the selected symbol width. This predefined lookup table set may incorporate a static probability model for the encoded data selected from multiple available static probability models from different predefined lookup table sets. Alternatively, the predefined lookup tables may include probability information for only a single static probability model for the selected symbol width, or the RANS decoder may use a dynamic probability model for the selected symbol width.

[0184] The decoding tool performs (1080) RANS decoding with the selected symbol width. RANS decoding can include, as referenced... Figures 9a to 9d The described operation uses a two-stage structure. Alternatively, RANS decoding can use other operations that implement RANS decoding. As part of RANS decoding, the decoding tool can receive initial state information for the RANS decoder (e.g., for a segment) and set the RANS decoder state accordingly. In this case, the encoded data received by the RANS decoder includes the initial state information.

[0185] For reference Figure 10a and 10b As described in the example, the header in the bitstream may include a syntax element indicating the selected symbol width. Depending on which features of the segment adaptive RANS coding are used, the header in the bitstream may also include (a) a syntax element indicating whether the state of the RANS decoder should be refreshed / reinitialized for decoding, (b) a syntax element indicating an adjustment to the selected symbol width, (c) a syntax element indicating the selection of a static probability model, and / or (d) one or more other syntax elements indicating configuration parameters.

[0186] F. An example of selectively refreshing the RANS decoder state between segments.

[0187] When the RANS decoder finishes generating output symbols from the encoded data for a segment, its state can still contain useful state information. This useful state information is lost if the RANS decoder refreshes and reinitializes its state to decode another segment.

[0188] This section describes various aspects of the selective refresh of the RANS decoder state between segments. The RANS encoder can decide whether the RANS decoder state should be preserved or refreshed / reinitialized for decoding a new segment. For example, for a segment (or the first p symbols of that segment, where p is the number depending on the implementation, such as 1, 3, 5, 10, or 15), the RANS encoder can evaluate the compression efficiency with the RANS decoder state preserved versus with it being refreshed / reinitialized. In doing so, if the RANS decoder state is refreshed / reinitialized, the RANS encoder can consider the overhead cost of signaling state information. Alternatively, the RANS encoder can perform other operations to determine whether the RANS decoder state should be preserved or refreshed / reinitialized for decoding a new segment.

[0189] The RANS encoder sets a syntax element that indicates whether the RANS decoder state for a segment should be refreshed / reinitialized. In some example implementations, this syntax element is a 1-bit flag in the segment's header. If the RANS decoder state is refreshed / reinitialized, the RANS encoder also determines and signals the segment's state information. In some example implementations, the state information is signaled as the first few bytes (e.g., 4 bytes) of the encoded data for the segment. Therefore, retaining the RANS decoder state from previous segments eliminates the need for encoded data.

[0190] The RANS decoder receives and parses syntax elements indicating whether the RANS decoder state for a segment should be preserved or refreshed / reinitialized. If the RANS decoder state is preserved, the RANS decoder uses the final RANS decoder state from the previous segment as the initial RANS decoder state for the new segment. Otherwise, the RANS decoder refreshes (sets) the RANS decoder state to zero and reinitializes it by loading state information signaled for the new segment (e.g., as part of the encoded data for the segment).

[0191] G. An example of RANS encoding / decoding with selective refresh of RANS decoder state between segments.

[0192] Figure 11a An example technique (1100) for RANS encoding of selective refresh of RANS decoder state between segments is shown. The example technique (1100) can be performed, for example, by an encoding tool as... Figure 7a The portion of the encoding stage (720) shown is implemented as referenced. Figure 5 The RANS encoder described or other RANS encoders.

[0193] At the outset, as part of the encoding of the input symbols using the RANS encoder, the encoding tool determines (1110) whether the state of the RANS decoder needs to be refreshed and reinitialized for decoding at least a portion of the bitstream (in... Figure 11a In the RANS decoder, the encoded data is for a segment. The encoding tool settings (1120) indicate whether the state of the RANS decoder should be refreshed / reinitialized for decoding syntax elements of at least a portion of the encoded data of the bitstream.

[0194] The encoding tool checks (1130) whether the RANS decoder state needs to be refreshed / reinitialized. If so, the encoding tool determines (1132) the initial state information for at least a portion of the encoded data of the bitstream. In this case, the bitstream includes (e.g., as part of the encoded data) the initial state information. For example, the initial state information is a 32-bit value. Otherwise, the bitstream lacks initial state information for at least a portion of the encoded data of the bitstream. The encoding tool performs (1140) RANS encoding.

[0195] The encoding tool can repeat this technique on a segment-by-segment basis (1100). Figure 11a In this process, the encoding tool checks (1142) whether to continue for the next segment, and if so, determines (1110) whether the state of the RANS decoder needs to be refreshed / reinitialized for decoding the encoded data for the next segment. In this case, each segment in the segment includes its own header, which has syntax elements indicating whether the state of the RANS decoder needs to be refreshed / reinitialized for decoding the encoded data for that segment.

[0196] Figure 11b An example technique (1150) for selectively refreshing the RANS decoder state between segments is shown. The example technique (1150) can be performed, for example, by a decoding tool as... Figure 7b The decoding stage (770) shown in the figure is implemented as described in the reference. Figure 6 The RANS decoder described or other RANS decoders.

[0197] To begin, as part of using the RANS decoder to decode the encoded data, the decoding tool reads the (1160) syntax element. This syntax element indicates whether the state of the RANS decoder needs to be refreshed / reinitialized for decoding at least a portion of the bitstream (in...). Figure 11b In the context of encoding data for segments.

[0198] Based at least in part on syntax elements, the decoding tool determines (1170) whether the state of the RANS decoder needs to be refreshed / reinitialized for decoding at least a portion of the encoded data for the bitstream.

[0199] The decoding tool checks (1180) whether the RANS decoder state needs to be refreshed / reinitialized. If so, the decoding tool retrieves (1182) the initial state information for at least a portion of the encoded data of the bitstream, refreshes the RANS decoder state, and loads (1184) the initial state as the RANS decoder state based at least in part on the initial state information. In this case, the bitstream includes (e.g., as part of the encoded data) the initial state information for at least a portion of the encoded data of the bitstream. For example, the initial state information is a 32-bit value. Otherwise, the bitstream lacks the initial state information for at least a portion of the encoded data of the bitstream.

[0200] The decoding tool performs (1190) RANS decoding on at least a portion of the encoded data of the bitstream. RANS decoding may include, as referenced... Figures 9a to 9d The described operation uses a two-stage structure. (In some example implementations, when there is not enough RANS decoder state to generate output symbols, the first four bytes of the encoded data for the fragment can be used to refill the RANS decoder state (stages 1182, 1184) as four iterations processed through stage 1.) Alternatively, RANS decoding can use other operations that implement RANS decoding.

[0201] The decoding tool can repeat this technique on a segment-by-segment basis (1150). Figure 11b In this process, the decoding tool checks (1192) whether to continue for the next segment, and if so, reads (1160) the syntax elements for the next segment. In this case, each segment in the segment includes its own header, which has syntax elements indicating whether the state of the RANS decoder should be refreshed / reinitialized for decoding the encoded data for that segment.

[0202] For reference Figure 11a and 11b As described in the example, the header in the bitstream includes syntax elements indicating whether the state of the RANS decoder should be refreshed / reinitialized for decoding at least a portion of the encoded data for the bitstream. Depending on which features of the segment adaptive RANS encoding / decoding are used, the header in the bitstream may also include (a) syntax elements indicating adjustments to the selected symbol width, (b) syntax elements indicating the selection of a static probability model from a plurality of available static probability models, and / or (c) one or more other syntax elements indicating configuration parameters.

[0203] H. An example of switching between multiple static probability models for a fragment.

[0204] In some previous methods, the RANS encoder and RANS decoder used either a single static probability model or a single dynamic probability model. When using a single static probability model, compression efficiency suffers if the distribution of symbol values ​​deviates from the expected distribution reflected in the single static probability model. Using a dynamic probability model improves compression efficiency even if the distribution of symbol values ​​deviates from the expected distribution; however, updating the dynamic probability model can be computationally expensive, especially for hardware implementations of RANS decoding.

[0205] This section describes various aspects of switching static probability models for segments of symbols during RANS encoding / decoding. The RANS encoder and decoder store values ​​for multiple static probability models. Different static probability models can differ in their expected distribution of symbol values. In some example implementations, the values ​​for a static probability model are organized as one or more lookup tables indexed by the identifier of the static probability model. Alternatively, the static probability model can be represented in some other way (e.g., a formula or equation). The static probability model can be a piecewise linear approximation of the curve of the cumulative probability function for symbol values. The curve monotonically increases. For some static probability models, the curve is flatter. For others, the curve is steeper for common values ​​(e.g., zero, low values). Part VI.M describes examples of static probability models.

[0206] The RANS encoder selects one of the static probabilistic models for a fragment of a symbol, signaling the syntax elements of the selected static probabilistic model. In some example implementations, there are 16 static probabilistic models, and the selected static probabilistic model uses a fixed-length 4-bit value for signaling. Alternatively, the RANS encoder and RANS decoder can use more or fewer static probabilistic models.

[0207] Typically, the same static probability model is used to encode / decode the symbols of a segment. The RANS encoder selects one of the static probability models based on the distribution of values ​​for the symbols of the segment. The selection process is implementation-dependent. For example, the RANS encoder might evaluate v input symbols (where v is 1, 10, 20, 100, or some other number of input symbols) to determine which static probability model provides the highest compression efficiency for v input symbols and what the relative benefit of switching to that static probability model would be. If switching to a new static probability model involves starting a new segment, the RANS encoder considers the signaling overhead (header bytes) for that switch. (Although the RANS encoder might switch for very short segments of symbols, the overhead cost would be high.) The RANS encoder can decide whether the improvement in compression efficiency from switching to another static probability model (for another segment) justifies the overhead cost of switching the segment. In this way, the RANS encoder can consider which static probability models to use when determining where to introduce segment boundaries, and the associated switches within the static probability models.

[0208] Switching between multiple static probability models can help RANS encoding / decoding process input symbol streams with different probability distributions (e.g., more zeros than expected; fewer zeros than expected) compared to using a single static probability model. While storing values ​​for multiple static probability models can be storage-intensive, these models can be switched using simple and efficient signaling. Sending syntax elements to select one of the multiple static probability models uses less bit rate than sending a new static probability model and is simpler (and faster) than updating a dynamic probability model.

[0209] I. An example of RANS encoding / decoding that switches between static probability models between segments.

[0210] Figure 12a An example technique (1200) for RANS encoding with a static probability model switching between segments is shown. The example technique (1200) can be performed, for example, by an encoding tool as... Figure 7a The portion of the encoding stage (720) shown is implemented as referenced. Figure 5 The RANS encoder described or other RANS encoders.

[0211] Initially, as part of encoding the input symbols using a RANS encoder, the encoding tool selects one of several available static probability models for at least a portion of the encoded data of the bitstream (1210). For example, the available static probability models include static probability models where the residual data values ​​are consecutively more likely to be zero. The static probability models are predefined, and a given static probability model does not change dynamically during encoding / decoding. The static probability model can be represented accordingly using values ​​from a predefined lookup table with probability information specific to the static probability model. Alternatively, the static probability model can be represented in some other way.

[0212] When selecting a static probability model, the encoding tool can consider any of a variety of factors. For example, the encoding tool can select a static probability model based at least in part on an evaluation of the probability distribution of the values ​​of the input symbols. Or, as another example, the encoding tool can select a static probability model based at least in part on an estimate of which of a plurality of available static probability models results in the lowest bit rate for at least a portion of the encoded data of the bitstream. Or, as another example, the encoding tool can select a static probability model based at least in part on encoding using each of a plurality of available static probability models to evaluate which model results in the lowest bit rate for at least a portion of the encoded data of the bitstream. Alternatively, the encoding tool can select a static probability model in some other manner.

[0213] The encoding tool settings (1220) indicate the syntax elements of the selected static probability model. For example, the syntax element is an n-bit value that indicates one of 2n static probability models.

[0214] The encoding tool configures the RANS encoder (1230) to use the selected static probability model. Then, the encoding tool performs (1232) RANS encoding using the selected static probability model.

[0215] The encoding tool can repeat this technique on a segment-by-segment basis (1200). Figure 12a In the process, the encoding tool checks (1240) whether to continue to the next segment, and if so, selects one of the multiple available static probability models (1210) for the next segment. In this case, each segment in the segment includes its own header, which has syntax elements indicating the selected static probability model for that segment.

[0216] Figure 12b An example technique (1250) for RANS decoding with a static probability model switching between segments is shown. The example technique (1250) can be performed, for example, by a decoding tool as... Figure 7bThe decoding stage (770) shown in the figure is implemented as described in the reference. Figure 6 The RANS decoder described or other RANS decoders.

[0217] Beginning with the decoding of the encoded data using a RANS decoder, the decoding tool reads (1260) a syntax element indicating the selection of a static probability model for at least a portion of the encoded data from a plurality of available static probability models. For example, the syntax element is an n-bit value indicating one of 2n static probability models.

[0218] Based at least in part on syntactic elements, the decoder tool selects one of several available static probability models (1270) for at least a portion of the encoded data of the bitstream. For example, the available static probability models include static probability models where residual data values ​​are consecutively more likely to be zero. Static probability models are predefined, and a given static probability model does not change dynamically during encoding / decoding. Static probability models can be represented accordingly using values ​​from a predefined lookup table with probabilistic information for the static probability model. Alternatively, static probability models can be represented in some other way.

[0219] The decoding tool configures the RANS encoder (1280) to use the selected static probability model. Then, the decoding tool performs (1282) RANS decoding of the encoded data using the selected static probability model. RANS decoding may include, as referenced... Figures 9a to 9d The described operation uses a two-stage structure. Alternatively, RANS decoding can use other operations that implement RANS decoding.

[0220] The decoding tool can repeat this technique on a segment-by-segment basis (1250). Figure 12b In the process, the decoding tool checks (1290) whether to continue for the next segment, and if so, reads (1260) the syntax element indicating the selection of the static probability model for the next segment. In this case, each segment in the segment includes its own header, which has syntax elements indicating the selection of the static probability model for that segment.

[0221] For reference Figure 12a and 12bAs described in the example, the header in the bitstream includes syntax elements indicating the selected static probability model for at least a portion of the encoded data in the bitstream. Depending on which features of the segment adaptive RANS encoding / decoding are used, the header in the bitstream may also include (a) syntax elements indicating whether the state of the RANS decoder should be refreshed / reinitialized for decoding, (b) syntax elements indicating adjustments to the selected symbol width, and / or (c) one or more other syntax elements indicating configuration parameters.

[0222] J. An example of adjusting the symbol width for different segments.

[0223] When a default symbol width is set for a stream's symbols, the symbol's value varies within the stream. Long series values ​​can be much smaller than the stream's highest possible value (considering the default symbol width).

[0224] This section describes various aspects of symbol width adjustment during RANS encoding / decoding. The RANS encoder and RANS decoder can adjust the symbol width on a segment-by-segment basis (relative to the default symbol width), which can improve compression efficiency because higher values ​​do not need to be considered for probability values ​​or subranges in the RANS decoder state (which is possible with the default symbol width but not with the adjusted symbol width).

[0225] The RANS encoder decides whether to adjust the symbol width for a fragment. Typically, the RANS encoder decides to adjust (reduce) the symbol width for a fragment after evaluating its symbols. For example, if the default symbol width is 8 bits (making the possible values ​​range from 0 to 255), but the highest value among the fragment's symbols is 61, then the symbol width can be reduced by 2 bits (making the range of possible symbol values ​​from 0 to 63). More generally, for the default symbol width d and the adjustment z, the RANS encoder can find the maximum value of z such that 2d - z is greater than the highest value among the fragment's symbols.

[0226] The RANS encoder signals adjustments to the symbol width for a segment. For example, a syntax element in the segment header indicates the adjustment. In some example implementations, the syntax element is a 2-bit value that can indicate an adjustment of 0 bits, -1 bit, -2 bits, or -3 bits relative to the default symbol width. Alternatively, the adjustment can have some other range in bits. The RANS encoder adjusts the symbol width accordingly, configuring it to perform RANS encoding with the (adjusted) symbol width, and performs RANS encoding with the adjusted symbol width.

[0227] The RANS decoder receives a syntax element indicating an adjustment to the symbol width. The RANS decoder then adjusts the default symbol width accordingly, configures the RANS decoder to perform RANS decoding with the (adjusted) symbol width, and performs RANS decoding with the adjusted symbol width.

[0228] K. An example of RANS encoding / decoding with adjustable symbol width between segments.

[0229] Figure 13a An example technique (1300) for RANS encoding with adjustments to the symbol width between segments is shown. The example technique (1300) can be performed, for example, by an encoding tool as... Figure 7a The portion of the encoding stage (720) shown is implemented as referenced. Figure 5 The RANS encoder described or other RANS encoders.

[0230] Initially, as part of encoding the input symbols using a RANS encoder, the encoding tool determines (1310) an adjustment to the symbol width for at least a portion of the encoded data of the bitstream. For example, the encoding tool identifies the highest value among the input symbols and determines the adjustment to the symbol width based on the highest value among the input symbols.

[0231] The encoding tool settings (1320) are syntax elements that indicate adjustments to the symbol width. For example, a syntax element is an n-bit value that indicates an amount ranging from 0 to 2n-1 bits that reduce the symbol width.

[0232] The encoding tool checks (1330) whether the symbol width needs to be adjusted; if so, it adjusts (1332) the symbol width. The encoding tool configures (1340) the RANS encoder to perform RANS encoding with the adjusted symbol width. For example, the encoding tool selects a predefined lookup table set with probability information for the adjusted symbol width and / or performs other operations to configure the RANS encoder. The encoding tool then performs (1342) RANS encoding with the adjusted symbol width.

[0233] The encoding tool can repeat this technique on a segment-by-segment basis (1300). Figure 13aIn this process, the encoding tool checks (1344) whether to continue to the next segment. If so, it determines (1310) the adjustment of the symbol width of the encoded data for that segment. In this case, each segment in the segment includes its own header, which has syntax elements indicating the adjustment of the symbol width of the encoded data for that segment. In some example implementations, a default symbol width is set for the bitstream, and the adjusted symbol width is applied to a given segment, thereby narrowing the effective symbol width of that segment for the RANS encoder / decoder.

[0234] Figure 13b An example technique (1350) for RANS decoding with adjustments to the symbol width between segments is shown. The example technique (1350) can be performed, for example, by a decoding tool as... Figure 7b The decoding stage (770) shown in the figure is implemented as described in the reference. Figure 6 The RANS decoder described or other RANS decoders.

[0235] Beginning, as part of using a RANS decoder to decode the encoded data, the decoding tool reads (1360) a syntax element indicating an adjustment to the symbol width of at least a portion of the encoded data for the bitstream. For example, the syntax element is an n-bit value indicating an amount ranging from 0 to 2n-1 bits in terms of reducing the symbol width. Based at least in part on the syntax element, the decoder tool determines (1370) the adjustment to the symbol width of at least a portion of the encoded data for the bitstream.

[0236] The decoding tool checks (1380) whether the symbol width needs to be adjusted; if so, it adjusts (1382) the symbol width. The decoding tool configures (1390) the RANS decoder to perform RANS decoding with the adjusted symbol width. For example, the decoding tool selects a predefined lookup table set with probability information for the adjusted symbol width and / or performs other operations to configure the RANS decoder. The decoding tool then performs (1392) RANS decoding with the adjusted symbol width. RANS decoding may include, as referenced... Figures 9a to 9d The described operation uses a two-stage structure. Alternatively, RANS decoding can use other operations that implement RANS decoding.

[0237] The decoding tool can repeat this technique on a segment-by-segment basis (1350). Figure 13bIn this process, the decoding tool checks (1394) whether to continue to the next segment. If so, it reads (1360) a syntax element indicating an adjustment to the symbol width for the next segment. In this case, each segment includes its own header with syntax elements indicating an adjustment to the symbol width of the encoded data for that segment. In some example implementations, a default symbol width is set for the bitstream, and the adjusted symbol width is applied to a given segment, thus narrowing the effective symbol width of that segment for the RANS decoder.

[0238] For reference Figure 13a and 13b As described in the example, the header in the bitstream includes a syntax element indicating an adjustment to the symbol width of at least a portion of the encoded data for the bitstream. Depending on which features of the segment adaptive RANS encoding / decoding are used, the header in the bitstream may also include (a) a syntax element indicating whether the state of the RANS decoder should be refreshed / reinitialized for decoding, (b) a syntax element indicating the selection of a static probability model, and / or (c) one or more other syntax elements indicating configuration parameters.

[0239] L. Example bitstream.

[0240] Figure 14 An example bitstream (1400) comprising multiple segments of encoded data is shown. Specifically, the bitstream (1400) comprises g variable-size segments (1410), which... Figure 14 The segments are numbered from segment 0 to segment g-1.

[0241] Each segment (1410) includes a header (1420) and optional information, as well as one or more bytes of encoded data (1430). The number of bytes in the encoded data (1430) is variable, which in turn makes the segment (1410) have a variable size.

[0242] Typically, the header (1420) includes fields for configuration parameters and length information. For a fragment, the header (1420) includes a field (1421) with a syntax element indicating an adjustment to the symbol width, a field (1422) with a syntax element indicating the selection of a static probability model, and a field (1423) with a state reinitialization flag. The length field (1425) indicates how many bytes of encoded data (1430) are in the payload for the fragment. If the encoded data (1430) includes more bytes than can be indicated by the length field (1425), a field (1424) with an additional length flag indicates the presence of additional length information (1426). In some example implementations, the length field (1425) is one byte, the amount indicated is given by adding 1 to the length field (an amount in the range of 1 to 257 bytes), and the additional length flag is a one-bit flag. If the encoded data (1430) includes more than 257 bytes, the extra length flag (1424) indicates that there is an extra byte of length information (1426).

[0243] The symbol width adjustment indicates an adjustment to the default symbol width of the fragment's symbols. In some example implementations, the syntax element indicating the symbol width adjustment is a 2-bit value, indicating a value in the range 0…3 (a reduction of 0, 1, 2, or 3 bits). If the fragment's symbols do not contain values ​​above a certain threshold (a common case in recompressed streams with high quantization), the RANS encoder / decoder can process the stream's symbols as if they were narrower (with fewer bits) than the default symbol width. For the default symbol width d and adjustment z, the fragment's symbols are processed to have a symbol width of dz bits. For example, if the default symbol width d for the stream's symbols is 6, the possible values ​​range from 0 to 63. If at least one symbol of the fragment has a value of 32 or greater, the adjustment z is 0. On the other hand, for a range of values ​​from 0 to 31, if the highest value is within the range 16…31, the adjustment z is -1, and the effective symbol width for RANS encoding / decoding is 5. If the highest value is in the range 8…15, then for values ​​in the range 0…15, the adjustment z is -2, and the effective symbol width for RANS encoding / decoding is 4. Otherwise, since the highest value is less than 8, for values ​​in the range 0…7, the adjustment z is -3, and the effective symbol width for RANS encoding / decoding is 3.

[0244] The choice of a static probability model indicates one of several available static probability models. In some example implementations, the syntax element indicating the choice of static probability model is a 4-bit value, indicating one of 16 static probability models. Static probabilities vary in terms of the tightness of the expected distribution of sign values ​​near 0. For the first static probability model, all possible values ​​have equal probabilities. For successive static probability models, the expected frequency of zero-valued signs increases, while the probability for other sign values ​​decreases. For the final static probability model, zero-valued signs are expected to be very common, and the expected probability for most other sign values ​​is zero.

[0245] The state reinitialization flag (also known as the state refresh flag) controls the refresh of the RANS decoder state between segments. The flag for a segment indicates whether the RANS decoder should be refreshed (set to zero) and its state reinitialized for decoding the symbols of the segment. In some example implementations, the flag is a 1-bit value. If the flag is 1, the first few bytes of the encoded data (1430) are used to load the RANS decoder state. If the flag is 0, the RANS decoder state at the end of the decoded segment is left as the initial RANS decoder state for the next segment.

[0246] M. Example combined implementation for RANS decoding.

[0247] Figures 15a to 15k A code listing snippet (1501-1511) in Hardware Description Language is shown for a model of the example decoder. The code listing snippet (1501-1511) includes code for the decoder module, which typically corresponds to a single instance of the RANS decoder. The code listing snippet (1501-1511) includes placeholders for various lookup tables, but for brevity, the values ​​stored in the lookup tables are not explicitly shown. Such values ​​depend on the implementation. Furthermore, for brevity, code for the feeder module (which writes values ​​from the encoded data buffer to the input buffer) and the decoder_array module (which coordinates the operation of multiple instances of the RANS decoder when output symbols are interleaved in the encoded data) is not shown.

[0248] Figure 15a The code snippet (1501) includes comments about the operations performed by different modules in the two phases (phase 0 and phase 1). Figure 15a and 15bThe code snippets (1501-1502) include specifications for the input and output parameters for the decoder module instance. These input and output parameters include various parameters used for overall control and configuration. Specifically, the input parameter `alphabet_bits` indicates the default symbol width. The input parameter `out_target` indicates the target number of output symbols to be generated. Other input and output parameters are used for interfacing with the feeder module. For example... Figure 15b As shown in the code list snippet (1502), other input and output parameters are used to interface with downstream modules (e.g., indicating the output symbol in the output buffer and indicating whether the output symbol is a valid output symbol).

[0249] Various variable tracking configuration settings for instances of the decoder module, which can be changed between segments. For example... Figure 15b As shown in the code listing snippet (1502), the variable eab indicates the adjusted symbol width, which is later set by reducing the default symbol width (alphabet_bits) as indicated by the field in the header for the snippet. The variable current_q indicates the selected static probability model, as indicated by the field in the header for the snippet.

[0250] Figure 15b The code listing snippet (1502) also includes placeholders for lookup tables used by the decoder module. Typically, each lookup table is depicted as a 3D array. For a lookup table, the first dimension of the 3D array is indexed by the adjusted symbol width / effective alphabet bits. The second dimension is indexed by the selected static probability model. The third dimension is indexed by the bit positions relative to the adjusted symbol width. Typically, each bit of the symbol width stores a non-zero value.

[0251] The lookup table `base_table` stores values ​​corresponding to subranges within the range 0 to 65536. For a given symbol width `eab` and a chosen static probability model `current_q`, the lookup table `base_table[eab][current_q]` stores values ​​for subranges of that range, or alternatively, stores cumulative frequency values ​​for the corresponding subranges. For example, for `base_table[8]

[12] `, the lookup table could store ten values ​​[0, 7575, 14276, 25440, 41008, 56352, 64256, 65344, 65408, 0]. This corresponds to nine subranges: 0 to 7575, 7576 to 14276, 14277 to 25440, 25441 to 41008, 41009 to 56352, 56353 to 64256, 64257 to 65344, 65345 to 65408, and 65409 to 65536. The variable `base_table_sel1` is a 2D array with probability values ​​for different static probability models for a given symbol width indicated by the variable `eab`. The variable `base_table_sel2` is a 1D array with probability values ​​for the selected static probability model (`current_q`) for a given symbol width (`eab`), such as... Figure 15i The code list snippet (1509) is shown.

[0252] The lookup table `freq_table` stores values ​​associated with the values ​​in the `base_table`. For a given symbol width `eab` and the chosen static probability model `current_q`, the lookup table `freq_table[eab][current_q]` stores values, each indicating a difference in log2p-1 compared to the previous value for each position `p` after position 0. Alternatively, these values ​​can be considered as the width of the corresponding subrange. For example, for `freq_table[8]

[12] `, the lookup table could store ten values ​​[7575, 6701, 5582, 3892, 1918, 494, 34, 1, 1, 0]. This corresponds to the subrange widths of the corresponding subranges: 7575, 6701×1, 5582×2, 3892×4, 1918×8, 494×16, 34×32, 1×64, and 1×128. For a given symbol width indicated by the variable eab, the variable freq_table_sel1 is a 2D array with values ​​for different static probability models. The variable freq_table_sel2 is a 1D array with values ​​for a given symbol width (eab) and for the selected static probability model (current_q), such as... Figure 15i The code list snippet (1509) is shown.

[0253] The lookup tables rf_table, rs_table, and rn_table store the encoded versions of the probabilities for different static probability models and different sign widths. By using values ​​from the lookup tables rf_table, rs_table, and rn_table in bit shift operations or addition / subtraction operations, the decoder module can avoid explicit division operations.

[0254] Specifically, the lookup table `rf_table` stores the inverse values ​​for the inverse probability distribution information, which are used when determining the output symbol based on the RANS decoder state. The variable `rf_table_sel1` is a 2D array with inverse values ​​for different static probability models for a given symbol width indicated by the variable `eab`. The variable `rf_table_sel2` is a 1D array with inverse values ​​for the selected static probability model (`current_q`) for a given symbol width (`eab`), as shown below. Figure 15i The code list snippet (1509) is shown.

[0255] The lookup table `rs_table` stores shift values ​​associated with the inverse probability distribution information, which are used when determining the output symbol based on the RANS decoder state. The variable `rs_table_sel1` is a 2D array with shift values ​​for different static probability models for a given symbol width indicated by the variable `eab`. The variable `rs_table_sel2` is a 1D array with shift values ​​for a given symbol width (`eab`) for the selected static probability model (`current_q`), such as... Figure 15i The code list snippet (1509) is shown.

[0256] The lookup table `rn_table` stores offset values ​​associated with the inverse probability distribution information, which are used when determining the output symbol based on the RANS decoder state. The variable `rn_table_sel1` is a 2D array with offset values ​​for different static probability models for a given symbol width indicated by the variable `eab`. The variable `rn_table_sel2` is a 1D array with offset values ​​for a given symbol width (`eab`) and for the selected static probability model (`current_q`), such as... Figure 15i The code list snippet (1509) is shown.

[0257] like Figure 15cAs shown in the code listing snippet (1503), the decoder module has multiple control states. These control states include an idle control state (DSTATE_IDLE), three control states in which fields of the header bytes are processed (DSTATE_HDR0, DSTATE_HDR1, DSTATE_HDR2), a main processing control state in which the decoder module reads the input encoded data and generates output symbols (DSTATE_PROCESSING), and a control state in which the decoder module has completed processing the input encoded data but is still generating output symbols (DSTATE_DRAINING).

[0258] Figure 15c The code listing snippet (1503) also illustrates the constraints on various internal variables used by the decoder module. For example, the variable `phase` tracks the current phase, phase 0 or phase 1. The variable `input_buf` stores bytes of encoded data (or, in some cases, bytes of the header for the fragment). The variable `input_buf_full` tracks whether there are bytes in `input_buf`. The variable `sym_buf_full` tracks whether the output buffer includes actual (valid) output symbols from previous iterations. The variable `input_remaining` tracks how much encoded data remains to be decoded for the fragment. The variables `rans_state_p0` and `rans_state_p1` track the RANS decoder state across two phases. The variable `hdr3` tracks whether there is additional length information for the fragment. The variable `flush_per_frag` tracks whether the initial state is flushed and reloaded for the fragment.

[0259] Then, Figure 15c and 15dThe code snippets (1503, 1504) illustrate the variables used during Phase 1 when portions of the encoded data (from the input buffer `input_buf`) are selectively incorporated into the RANS decoder state. The variable `want_to_feed_rans` tracks whether the RANS decoder state will be updated. `want_to_feed_rans` is set based on a comparison of the RANS decoder state with a threshold (`rans_state_p0 < 'MDU_RANS_LOWER_LIMIT') and whether there is any remaining encoded input data to decode. The variable `will_feed_rans` depends on `want_to_feed_rans` and whether the input buffer includes bytes of encoded data. If the RANS decoder state will not be updated, the variable `rans_state_with_input` is set to the RANS decoder state (`rans_state_p0`). In this case, the RANS decoder state remains unchanged. Otherwise, if the RANS decoder state is updated, the variable `rans_state_with_input` is set to include the lower three bytes of the RANS decoder state (`rans_state_p0`) and the new bytes of encoded data. The updated RANS decoder state is tracked as `rans_state_with_input`. The variable `new_input_remaining` tracks the amount of remaining encoded input data to be decoded.

[0260] Figure 15c and 15d The code snippets (1503, 1504) then show the variables used during phase 1 to determine whether to load the input buffer with another byte of encoded data (tracked by need_ib_load, then by din_req and din_ready) and to check various stopping conditions.

[0261] Figure 15d The code listing snippet (1504) also shows variables set during configuration based on values ​​from bytes in the header. The variable `hdr0_z_field` is set by a two-bit value in the bytes in the input buffer. This value indicates the adjustment to the default symbol width (alphabet_bits) for the segment. The variable `hdr0_q_field` is set by a four-bit value in the bytes in the input buffer. This value indicates the selected static probability model for the segment. The variable `eab_unclitted` indicates the adjusted symbol width for the segment, based on the default symbol width (alphabet_bits) and the adjustment (hdr_z_field). The variable `eab_unclamped` indicates that the adjusted symbol width after clamping does not exceed 9 bits.

[0262] Next, Figure 15d and 15e The code snippets (1504, 1505) in the table show the variables set when the decoder module uses inverse probability information and the RANS decoder state to selectively generate output symbols. Specifically, the variable `new_sym` indicates the potential output symbol, while the variable `sym_valid` indicates whether the output symbol is valid.

[0263] The variables `inv_seg`, `inv_base_x`, and `dist_x` are set based on the RANS decoder state (in the variable `cf_in`), the base table values ​​(`base_table_sel2`), the adjusted symbol width (`eab`), and the offset values ​​(`rn_table_sel2`). The variable `cf_in` is set based on the updated RANS decoder state tracked as `rans_state_with_input`. For a given symbol width, the array `base_table_sel2` is a 1D array with probability values ​​for the selected static probability model. For a given symbol width, the array `rn_table_sel2` is a 1D array with offset values ​​for the selected static probability model. The values ​​of `base_table_sel2` and `rn_table_sel2` are set for the selected static probability model (`current_q`) for a given symbol width (`eab`), as shown below. Figure 15i The code list (1509) is shown.

[0264] The variable `inv_seg` indicates the segment from 0 to 9 associated with the output symbol. The variable `inv_base_x` indicates the base value, which typically depends on the segment. The variable `dist_x` indicates the adjusted state value based on `cf_in`, the entry for that segment in `base_table_sel2`, and the shift value for that segment in `rn_table_sel2`.

[0265] The variable `new_sym` indicates the potential output symbol, which is set using the values ​​of the variables `inv_seg`, `inv_base_x`, and `dist_x` along with the value looked up in `rf_table_sel2` and `rs_table_sel2` for the segment (`inv_seg`). Figure 15eAs shown in the diagram. The array `rf_table_sel2` is a 1D array containing the inverse values ​​for the selected static probability model for a given sign width. The array `rs_table_sel2` is a 1D array containing shift values ​​for the selected static probability model for a given sign width. The values ​​of `rf_table_sel2` and `rs_table_sel2` are set for the selected static probability model (`current_q`) for a given sign width (`eab`), as shown in the diagram. Figure 15i The code list (1509) shows this. The variables `rf` and `rs` are set by lookup operations in `rf_table_sel2` and `rs_table_sel2` using `inv_seg` as an index. The variable `add_mul` is set by multiplying `dist_x` by the value looked up in `rf_table_sel2`. The variable `inv_steps` is set by shifting the first 17 bits of `add_mul` by the shift value looked up in `rs_table_sel2`. The variable `new_sym` is set by adding the value `inv_steps` to `inv_base_x`.

[0266] The variable `sym_valid` indicates whether a new output symbol is valid. The variable `next_sym_buf_full` tracks whether a valid symbol has been generated, depending on whether the RANS decoder state (tracked using `rans_state_with_input`) is greater than a threshold amount ('MDU_RANS_LOWER_LIMIT') and whether there are remaining output symbols to be generated (`output_remaining>0`). As described below, the variable `sym_buf_full` is set to the value of `next_sym_buff_full`. In phase 0, based on `sym_buf_full`, the variable `sym_valid` is set to indicate whether a new symbol is valid. In this way, the decoder selectively generates output symbols (i.e., valid output symbols) depending on the RANS decoder state. (In some cases, the value of `new_sym` is calculated but does not indicate an output symbol.) The variable `new_rans_state_p1` indicates the updated RANS decoder state based on the RANS decoder state with selectively incorporated new bytes (`rans_state_with_input`). The variable `new_output_remaining` tracks the remaining output symbols to be generated, and it decrements as valid output symbols have already been generated.

[0267] Figure 15f and 15gThe code snippets (1506, 1507) illustrate the variables set when the decoder module selectively updates the RANS decoder state based on whether an output symbol has been generated. Some of these variables depend on values ​​looked up in the arrays `base_table_sel2` and `freq_table_sel2`. `base_table_sel2` is a 1D array containing probability values ​​for a given symbol width and for the selected static probability model. `freq_table_sel2` is a 1D array containing frequency values ​​for a given symbol width and for the selected static probability model. The values ​​of `base_table_sel2` and `freq_table_sel2` are set during configuration based on values ​​in the header, as described below.

[0268] The variables fwd_seg and fwd_segstart are set based on the values ​​of the output symbols (sym) generated in stage 1 of the previous iteration. The variable fwd_seg indicates the segment from 0 to 9 associated with the output symbol. The variable fwd_segstart is a basic quantity that typically depends on the segment. The variable fwd_base is set by using fwd_seg as an index in a lookup operation in the base table (base_table_sel2). The variable fwd_fa is set by using fwd_seg as an index in a lookup operation in the frequency table (freq_table_sel2). The variable new_rans_state_p0, indicating the updated RANS decoder state, is set using the values ​​of the variables fwd_f, fwd_p, and fwd_cf along with 16 bits of the RANS decoder state from stage 1 (rans_state_p1[31:16]). The variables fwd_f, fwd_p, and fwd_cf are as follows: Figure 15g The calculation is shown in the code snippet (1507) in the list of codes.

[0269] Figure 15g The code snippet (1507) illustrates the operations performed when the decoder module is initialized (when the variable nrst is 0). The control state of the decoder module is set to DSTATE_IDLE, and the stage is set to stage 1. The state variables (rans_state_p0 and rans_state_p1), the variable tracking the remaining bytes of the input encoded data to be decoded (input_remaining), and the variable tracking the remaining output symbols to be generated (output_remaining) are set to 0. Other variables indicating the output symbols, whether the output symbols are valid, the adjusted symbol width, the selected static probability model, and the values ​​of the lookup table are similarly initialized.

[0270] Next, Figure 15g to 15k The code snippets (1507-1511) show the main processing loop for the decoder module (when the variable nrst is 1) when the decoder module performs operations in phase 0 or phase 1, and when the decoder module transitions from control state to control state. Specifically, Figure 15g and 15h The code snippets (1507, 1508) in the table show the operations performed as part of the phase 0 processing (when the variable phase is 0). The decoder module checks for error overrun conditions and performs various operations if decoding does not stop.

[0271] If the decoder module's control state is DSTATE_PROCESSING or DSTATE_DRAINING, the decoder module selectively updates the RANS decoder state. If the variable sym_buf_full indicates that an output symbol (valid output symbol) was generated in stage 1 of the previous iteration (see [link to documentation]), then... Figure 15e and 15j If so, the decoder module will set the variable rans_state_p0 to the value of the variable new_rans_state_p0 (which is as follows). Figure 15g (as set in the previous iteration). Otherwise (the variable sym_buf_full indicates that no output symbol was generated in stage 1 of the previous iteration), the decoder module sets the variable rans_state_p0 to the value of the variable rans_state_p1 (i.e., the RANS decoder state does not change between stage 1 and stage 0).

[0272] As part of stage 0 processing, the decoder module then processes the input, regardless of its control state. Figure 15h As shown. This depends on the values ​​of the variables din_valid and din_ready (which were set during the previous stage 1 processing; see...) Figure 15d The decoder module uses another byte of the encoded data (from the variable din) to selectively refill the input buffer (input_buf) and indicates that the input buffer is full (input_buf_full<=1).

[0273] Still processed as part of stage 0, the decoder module processes the output, regardless of its control state. Figure 15h As shown. Depending on the values ​​of the variables sym_valid and sym_ready, they are directed to downstream modules (see...). Figure 15a The interface part and (in the case of sym_valid) is processed in the previous stage 1 (see Figure 15e During this period, the decoder module is configured to selectively output symbols. Figure 15h The placeholder shown in the figure indicates that the output buffer is empty (sym_buf_full<=0).

[0274] This completes the iteration of phase 0 processing. For example... Figure 15k As shown in the code snippet (1511), the decoder module switches the variable `phase`. Here, the variable `phase` is changed from 0 to 1.

[0275] Figure 15h to 15k The code snippets (1508-1511) in the table show the operations performed as part of Phase 1 processing (when the variable phase is 1). The operations performed as part of Phase 1 processing depend on the control state of the decoder module, as shown by the selection statement that depends on ctrl_state.

[0276] like Figure 15h As shown in the code listing snippet (1508), if the decoder module's control state is DSTATE_IDLE, the decoder module is in an idle control state. The decoder module's control state is changed to DSTATE_HDR0 for subsequent processing. The variables tracking the RANS decoder state (rans_state_p0 and rans_state_p1) are initialized (set to zero). The remaining amount of output symbols to be generated is set as the target amount (out_target), which is the input parameter used for the interface to the decoder module. This completes the iteration of Phase 1 processing (for control state DSTATE_IDLE), and as... Figure 15k As shown in the code snippet (1511) in the code list, the decoder module switches the variable phase, changing the variable phase from 1 to 0.

[0277] like Figure 15i As shown in the code snippet (1509), if the decoder module's control state is DSTATE_HDR0, the decoder module processes the first byte of the header for the segment. Assuming the input buffer stores the first byte of the header (input_buf_full is 1, as set during previous stage 0 processing when the input buffer is refilled), the decoder module initializes the amount of encoded data to be decoded to zero (input_remaining <= 0) and changes the decoder module's control state to DSTATE_HDR1 for subsequent processing. The decoder module then uses the variable hdr0_q_field (see...) Figure 15dThe first four bits of the header (represented by hdr0_z_field) are used to set the variable current_q, indicating the selected static probability model for the segment. The decoder module sets the variable hdr3 based on another bit in the first byte of the header, indicating whether the header includes an extra length field. The decoder module also sets the variable flush_per_flag based on another bit in the first byte of the header, indicating whether the RANS decoder state has been flushed and reinitialized (or maintained from a previous segment) for this segment. The decoder module uses hdr0_z_field (see hdr0_z_field) to set the variable current_q. Figure 15d The first two bits of the header of `eab_clamped` are used to set the variable `eab`, which indicates the adjusted symbol width for the fragment. Finally, the decoder module sets the variable `input_buf_full` to zero to indicate that a byte in the input buffer has been processed. This completes the iteration of Phase 1 processing (for control state `DSTATE_HDR0`), and as... Figure 15k As shown in the code snippet (1511) in the code list, the decoder module switches the variable phase, changing the variable phase from 1 to 0.

[0278] like Figure 15i As shown in the code listing snippet (1509), if the decoder module's control state is DSTATE_HDR1, the decoder module processes the second byte of the header for the segment, which indicates the length of the encoded data in the segment. Assuming the input buffer stores the first byte of the header (input_buf_full is 1, as set during previous stage 0 processing when the input buffer is refilled), the decoder module, based on the selected static probability model (current_q) and the adjusted symbol width eab (see...),... Figure 15bThe decoder module sets the values ​​of the lookup tables for `base_table_sel2`, `freq_table_sel2`, `rf_table_sel2`, `rs_table_sel2`, and `rn_table_sel2`. Next, the decoder module sets the number of bytes of encoded data to be decoded (`input_remaining`). If the variable `hdr3` indicates that the header includes an extra length field, the decoder module sets the number of bytes of encoded data to be decoded (`input_remaining`) to the value of the second byte of the header (in `input_buf`) and changes the decoder module's control state to `DSTATE_HDR2` for subsequent processing. Otherwise (if the variable `hdr3` indicates that the header does not include an extra length field), the decoder module sets the number of bytes of encoded data to be decoded (`input_remaining`) to the value of the second byte of the header plus 1 and changes the decoder module's control state to `DSTATE_PROCESSING` for subsequent processing. The decoder module also sets the variable `input_buf_full` to zero to indicate that bytes in the input buffer have been processed. This completes the iteration of Phase 1 processing (for control state DSTATE_HDR1), and as Figure 15k As shown in the code snippet (1511) in the code list, the decoder module switches the variable phase, changing the variable phase from 1 to 0.

[0279] like Figure 15i As shown in the code listing snippet (1509), if the decoder module's control state is DSTATE_HDR2, the decoder module processes the third byte of the header for the segment, which indicates the additional length of the encoded data in the segment. Assuming the input buffer stores the first byte of the header (input_buf_full is 1, as set during the previous stage 0 processing when the input buffer is refilled), the decoder module uses the value of the third byte of the header and the value set for input_remaining when processing the second byte of the header to set the amount of encoded data to be decoded (input_remaining). The decoder module also changes its control state to DSTATE_PROCESSING for subsequent processing. The decoder module sets the variable input_buf_full to zero to indicate that the bytes in the input buffer have been processed. This completes the iteration of stage 1 processing (for control state DSTATE_HDR2), and as... Figure 15k As shown in the code snippet (1511) in the code list, the decoder module switches the variable phase, changing the variable phase from 1 to 0.

[0280] like Figure 15jAs shown in the code listing snippet (1510), if the control state of the decoder module is DSTATE_PROCESSING, the decoder module sets the RANS decoder state (rans_state_p1) to the updated RANS decoder state (new_rans_state_p1) based on the RANS decoder state with new bytes selectively incorporated therein, as referenced. Figure 15c and 15e As explained. The decoder module uses, as Figure 15c The variable `new_input_remaining`, as shown in the diagram, is used to update the amount of remaining bytes of input encoded data to be decoded (`input_remaining`). The decoder module also uses... Figure 15e The variable `new_output_remaining` is set as shown to update the remaining amount of output symbols to be generated (`output_remaining`). The decoder module selectively sets the variable `input_buf_full` to zero based on whether bytes of encoded data in the input buffer have been merged into the decoder state. The decoder module selectively generates the output symbol (`sym`) for the current iteration, setting the variable `sym` to `new_sym` and the variable `sym_buf_full` to `next_sym_buf_full`, where `new_sym` and `next_sym_buf_full` are as follows: Figure 15e The settings shown.

[0281] As long as there is at least some remaining encoded data to be decoded, the decoder module's control state remains at DSTATE_PROCESSING. Conversely, if there is no remaining input encoded data to decode (new_input_remaining is 0), the decoder module performs other operations. If at least one output symbol needs to be generated (new_output_remaining > 0), the decoder module checks the state of the RANS decoder. If the RANS decoder's state is insufficient to continue decoding (new_rans_state_p1 == 'MDU_RANS_LOWER_LIMIT'), the decoder module initiates a switch to decode another segment, changing its control state to DSTATE_HDR0 and selectively flushing the RANS decoder's state (depending on the value of the variable flush_per_frag). Otherwise (if at least one output symbol needs to be generated and the RANS decoder's state is sufficient to continue decoding), the decoder module changes its control state to DSTATE_DRAINING. If no more output symbols need to be generated, the decoder module changes its control state to DSTATE_IDLE and sets the variable done to 1.

[0282] This completes the iteration of Phase 1 processing (for the control state DSTATE_PROCESSING). For example... Figure 15k As shown in the code snippet (1511) in the code list, the decoder module switches the variable phase, changing the variable phase from 1 to 0.

[0283] like Figure 15j As shown in the code listing snippet (1510), if the control state of the decoder module is DSTATE_DRAINING, the decoder module sets the RANS decoder state (rans_state_p1) to the updated RANS decoder state (new_rans_state_p1) based on the RANS decoder state with new bytes selectively incorporated therein, as referenced. Figure 15c and 15e As explained. The decoder module uses, as Figure 15e The variable `new_output_remaining` is set as shown to update the remaining amount of output symbols to be generated (`output_remaining`). The decoder module selectively generates output symbols (`sym`) for the current iteration, setting the variable `sym` to `new_sym` and the variable `sym_buf_full` to `next_sym_buf_full`, where `new_sym` and `next_sym_buf_full` are as follows: Figure 15eThe settings shown.

[0284] As long as the RANS decoder's state is sufficient to continue decoding, the decoder module's control state remains DSTATE_DRAINING. Conversely, if the RANS decoder's state is insufficient to continue decoding (new_rans_state_p1 <= "MDU_RANS_LOWER_LIMIT"), the decoder module performs other operations. If at least one output symbol needs to be generated (new_output_remaining > 0), the decoder module initiates a switch to decode another fragment, changing the decoder module's control state to DSTATE_HDR0 and selectively flushing the RANS decoder's state (depending on the value of the variable flush_per_frag). Otherwise (no more output symbols are generated), the decoder module changes its control state to DSTATE_IDLE and sets the variable done to 1.

[0285] This completes the iteration of Phase 1 processing (for the control state DSTATE_DRAINING). For example... Figure 15k As shown in the code snippet (1511) in the code list, the decoder module switches the variable phase, changing the variable phase from 1 to 0.

[0286] Finally, as Figure 15k As shown in the code snippet (1511) in the code listing, for any other value of ctrl_state, the decoder module changes the decoder module's control state to DSTATE_IDLE for subsequent processing. This completes the iteration of stage 1 processing (for the default control state), and as... Figure 15k As shown in the code snippet (1511) in the code list, the decoder module switches the variable phase, changing the variable phase from 1 to 0.

[0287] VII. Additional features.

[0288] The following diagram illustrates some of the additional features of the innovations described in this paper.

[0289]

[0290] Considering the many possible embodiments in which the principles of the disclosed invention can be applied, it should be understood that the illustrated embodiments are merely preferred examples of the invention and should not be construed as limiting the scope of the invention. Rather, the scope of the invention is defined by the appended claims. Therefore, we claim protection for all inventions falling within the scope and spirit of these claims.

Claims

1. A method in a computer system, comprising: The input symbols are encoded using a range-asymmetric digital system (RANS) encoder to generate encoded data for at least a portion of the bitstream, including: Determine whether the state of the RANS decoder needs to be refreshed by setting the state of the RANS decoder to zero and reinitialized by loading an initial state as the state of the RANS decoder for decoding the encoded data for at least a portion of the bitstream; Set syntax elements indicating whether the state of the RANS decoder should be refreshed by setting the state of the RANS decoder to zero and reinitialized by loading the initial state as the state of the RANS decoder for decoding the encoded data for at least a portion of the bitstream; and Perform RANS encoding; and Output the encoded data for at least a portion of the bitstream, wherein the header of the at least a portion of the bitstream includes the syntax element indicating whether the state of the RANS decoder should be refreshed by setting the state of the RANS decoder to zero and reinitialized by loading the initial state as the state of the RANS decoder for decoding the encoded data for at least a portion of the bitstream.

2. The method of claim 1, wherein the syntax element instructs the state of the RANS decoder to be refreshed and reinitialized for decoding the encoded data for at least a portion of the bitstream, and wherein the encoding further comprises: Determine initial state information for at least a portion of the encoded data of the bitstream, the bitstream further including the initial state information for at least a portion of the encoded data of the bitstream.

3. The method of claim 1, wherein the syntax element instructs the state of the RANS decoder not to be refreshed and reinitialized for decoding the encoded data for at least a portion of the bitstream, and wherein the bitstream lacks initial state information for the encoded data for at least a portion of the bitstream.

4. The method according to claim 1, further comprising: For each of the plurality of segments, the encoding is repeated on a segment-by-segment basis, each of the plurality of segments including its own header having syntax elements indicating whether the state of the RANS decoder should be refreshed and reinitialized for decoding the encoded data for that segment.

5. The method of claim 1, wherein determining whether the state of the RANS decoder needs to be refreshed and reinitialized for decoding the encoded data for at least a portion of the bitstream comprises: For the fragment of the input symbol or the initial of the fragment p Given input symbols, evaluate the compression efficiency when the state of the RANS decoder is preserved versus the compression efficiency when the state of the RANS decoder is refreshed and reinitialized.

6. The method of claim 1, wherein the encoding further comprises: Select the symbol width; Sets a syntax element that indicates the width of the selected symbol; as well as Configuring the RANS encoder to perform RANS coding at the selected symbol width includes selecting a predefined lookup table set with probability information for the selected symbol width.

7. The method of claim 1, wherein the encoding further comprises: Selectively adjust the default symbol width of the encoded data for at least a portion of the bitstream; The header of at least a portion of the bitstream further includes the syntax element indicating the selectively adjusted symbol width, which is configured to specify the selectively adjusted symbol width. as well as Configuring the RANS encoder to perform the RANS coding under the selectively adjusted symbol width includes selecting a predefined lookup table set with probability information for the selectively adjusted symbol width.

8. The method of claim 1, wherein the encoding further comprises: A static probability model is selected from a plurality of available static probability models for the encoded data of at least a portion of the bitstream; The header of the bitstream, in the at least portion thereof, further includes the syntax element indicating the selected static probability model, which specifies the selected static probability model; and Configure the RANS encoder to perform the RANS coding using the selected static probability model.

9. The method according to claim 1, further comprising: The encoded data for at least a portion of the bitstream is stored on a computer-readable medium.

10. The method of claim 1, wherein the state of the RANS decoder is implemented using a state variable configured to include portions of the encoded data for at least a portion of the bitstream that have been incorporated into the state of the RANS decoder.

11. The method of claim 4, wherein the plurality of segments includes a first segment and a second segment, the syntax element of the first segment instructs the state of the RANS decoder to be refreshed and reinitialized for decoding encoded data for the first segment, and the syntax element of the second segment instructs the state of the RANS decoder not to be refreshed and reinitialized for decoding encoded data for the second segment, and wherein the encoding further includes: The initial state information for the encoded data of the first segment is determined. The bit stream also includes the initial state information for the encoded data of the first segment, but does not include the initial state information for the encoded data of the second segment.

12. A computer system comprising an encoded data buffer and a Range Asymmetric Digital System (RANS) decoder, the encoded data buffer being implemented in the memory of the computer system, and the RANS decoder being implemented using one or more processors of the computer system, wherein: The encoded data buffer is configured to receive encoded data for at least a portion of a bitstream, wherein the header of the at least portion of the bitstream includes a syntax element indicating whether the state of the RANS decoder should be refreshed by setting the state of the RANS decoder to zero and reinitialized by loading an initial state as the state of the RANS decoder for decoding the encoded data for the at least portion of the bitstream. as well as The RANS decoder is configured to decode the encoded data for at least a portion of the bitstream by performing operations to generate output symbols, the operations including: Read the syntax element; Based at least in part on the syntax elements, determine whether the state of the RANS decoder should be refreshed by setting the state of the RANS decoder to zero and reinitialized by loading an initial state as the state of the RANS decoder for decoding the encoded data for at least a portion of the bitstream; and RANS decoding is performed on the encoded data of at least a portion of the bitstream.

13. The computer system of claim 12, wherein the operation further comprises: When the syntax element instructs the RANS decoder to be refreshed and reinitialized for decoding the encoded data for at least a portion of the bitstream: Retrieve initial state information of the encoded data for at least a portion of the bitstream from the bitstream; as well as The initial state is loaded as the state of the RANS decoder based at least in part on the initial state information.

14. The computer system of claim 13, wherein the initial state information is a 32-bit value.

15. The computer system of claim 12, wherein the operation further comprises: When the syntax element instructs the RANS decoder to be refreshed and reinitialized for decoding the encoded data for at least a portion of the bitstream: The initial state is loaded as the state of the RANS decoder.

16. The computer system according to claim 12, wherein, The operation further includes, when the syntax element instructs the RANS decoder not to refresh and reinitialize its state for decoding the encoded data for at least a portion of the bitstream: The state of the RANS decoder is preserved.

17. The computer system of claim 12, wherein the RANS decoder is configured to perform the operation on a segment-by-segment basis for each of a plurality of segments, each of the plurality of segments including its own header having syntax elements indicating whether the state of the RANS decoder should be refreshed and reinitialized for decoding encoded data for that segment.

18. The computer system of claim 12, wherein performing the RANS decoding comprises: As part of the first phase, the state of the RANS decoder is selectively updated using probabilistic information for the output symbols from previous iterations; As part of the second phase, portions of the encoded data for at least a portion of the bitstream from the encoded data buffer are selectively merged into the state of the RANS decoder; as well as As part of the second phase, the state of the RANS decoder is used to selectively generate output symbols for the current iteration.

19. The computer system of claim 12, wherein the operation further comprises: Read from the header of at least a portion of the bitstream a syntax element indicating the selection of symbol width; The symbol width is selected based on the syntax element indicated by the selection; as well as Configuring the RANS decoder to perform RANS decoding at the selected symbol width includes selecting a predefined lookup table set with probability information for the output symbols for the selected symbol width.

20. The computer system of claim 12, wherein the operation further comprises: Syntax elements are read from the header of at least a portion of the bitstream, the syntax elements indicating a selective adjustment of the default symbol width for the encoded data for at least a portion of the bitstream; Based on the syntax element indicating the selective adjustment, the default symbol width of the encoded data for at least a portion of the bitstream is selectively adjusted; as well as Configuring the RANS decoder to perform the RANS decoding under the selectively adjusted symbol width includes selecting a predefined lookup table set having probability information for the output symbols with respect to the selectively adjusted symbol width.

21. The computer system of claim 12, wherein the operation further comprises: Syntax elements are read from the header of at least a portion of the bitstream, the syntax elements indicating the selection of a static probability model from a plurality of available static probability models for the encoded data for at least a portion of the bitstream; Based on the syntax element indicating the selection, the static probability model is selected for the encoded data of at least a portion of the bitstream; as well as Configure the RANS decoder to perform the RANS decoding using the selected static probability model.

22. The computer system of claim 12, wherein the state of the RANS decoder is implemented using a state variable configured to include portions of the encoded data for at least a portion of the bitstream that have been incorporated into the state of the RANS decoder.

23. The computer system of claim 17, wherein the plurality of segments includes a first segment and a second segment, the syntax element of the first segment instructing the state of the RANS decoder to be refreshed and reinitialized for decoding encoded data for the first segment, and the syntax element of the second segment instructing the state of the RANS decoder not to be refreshed and reinitialized for decoding encoded data for the second segment, and wherein the operation includes: Regarding the first segment: Set the state of the RANS decoder to zero; Retrieve initial state information of the encoded data for the first segment from the bit stream; as well as The initial state is loaded as the state of the RANS decoder, based at least in part on the initial state information of the encoded data for the first segment; as well as For the second segment, the state of the RANS decoder is preserved.

24. One or more computer-readable media storing encoded data for at least a portion of a bitstream, wherein a header in the at least portion of the bitstream includes syntax elements indicating whether the state of a Range Asymmetric Digital System (RANS) decoder is to be refreshed by setting the state of the RANS decoder to zero and reinitialized by loading an initial state as the state of the RANS decoder for decoding the encoded data for the at least portion of the bitstream, the encoded data for the at least portion of the bitstream being organized to facilitate decoding by including the following operations: Read the syntax element; Based at least in part on the syntax elements, it is determined whether the state of the RANS decoder should be refreshed by setting the state of the RANS decoder to zero and reinitialized by loading the initial state as the state of the RANS decoder for decoding the encoded data for at least a portion of the bitstream; as well as Perform RANS decoding on at least a portion of the encoded data of the bitstream.

Images