Inherited context initialization in CABAC

Abstract

Aspects of the present disclosure provide a method and apparatus for encoding / decoding video. In some examples, the apparatus for video decoding includes a receiving circuit and a processing circuit. The processing circuit determines the use of inherited context initialization in context-based adaptive binary arithmetic coding (CABAC) for decoding a current portion of a video sequence carried by a bitstream. The processing circuit decodes from the bitstream a syntax value indicating a decoded portion of the video sequence for context inheritance, and initializes a context model for CABAC based on a stored context state associated with the decoded portion. Furthermore, the processing circuit decodes the current portion from the bitstream according to the context model initialized based on the stored context state associated with the decoded portion.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims benefit of priority to U.S. Patent Application No. 17 / 940,981, entitled "CABAC INHERITED CONTEXT INITIALIZATION," filed September 8, 2022, which claims benefit of priority to U.S. Provisional Application No. 63 / 331,940, entitled "Method and Apparatus for Context-Based Adaptive Binary Arithmetic Coding Inherited Context Initialization," filed April 18, 2022. The disclosures of the prior applications are incorporated herein by reference in their entireties.

[0002] This disclosure generally describes embodiments related to video coding. [Background technology]

[0003] The background discussion provided herein is intended to generally present the context of the present disclosure. The inventors' work, to the extent that it is described in this background section, and aspects of the description that may not be admitted as prior art at the time of filing, are not admitted expressly or impliedly as prior art to the present disclosure.

[0004] Uncompressed digital video may include a sequence of pictures, each having spatial dimensions of, for example, 1920x1080 luma samples and associated chroma samples. The sequence of pictures may have a fixed or variable picture rate (also informally known as frame rate), for example, 60 pictures per second or 60 Hz. Uncompressed video has specific bitrate requirements. For example, 1080p60 4:2:0 video (1920x1080 luma sample resolution at a frame rate of 60 Hz) at 8 bits per sample requires a bandwidth approaching 1.5 Gbit / s. One hour of such video requires more than 600 GByte of storage space.

[0005] One objective of video coding and decoding may be the reduction of redundancy in the input video signal through compression. Compression may help reduce the aforementioned bandwidth and / or storage space requirements, in some cases by more than two orders of magnitude. Both lossless and lossy compression may be employed, as well as combinations thereof. Lossless compression refers to techniques where an exact copy of the original signal can be reconstructed from the compressed original signal. When using lossy compression, the reconstructed signal may not be identical to the original signal, but the distortion between the original signal and the reconstructed signal is small enough to make the reconstructed signal useful for its intended application. For video, lossy compression is widely adopted. The amount of acceptable distortion depends on the application, e.g., a user of a particular consumer streaming application may tolerate higher distortion than a user of a television distribution application. The achievable compression ratio may reflect that the higher the tolerable / acceptable distortion, the higher the compression ratio can be.

[0006] Video encoders and decoders can utilize techniques from a number of broad categories, including, for example, motion compensation, transform, quantization, and entropy coding.

[0007] Video codec techniques can include a technique known as intra-coding. In intra-coding, sample values ​​are represented without reference to samples or other data from previously reconstructed reference pictures. In some video codecs, a picture is spatially subdivided into blocks of samples. When all blocks of samples are coded in intra mode, the picture can be an intra picture. Intra pictures and their derivatives, such as independent decoder refresh pictures, are used to reset the decoder state and can therefore be used as the first picture in a coded video bitstream and video session or as a still image. Samples of an intra block undergo a transform and the transform coefficients can be quantized before entropy coding. Intra prediction can be a technique that minimizes sample values ​​in the pre-transform domain. In some cases, the smaller the DC value after the transform and the smaller the AC coefficients, the fewer bits are needed for a given quantization step size to represent the block after entropy coding.

[0008] Conventional intra-coding, for example as known from MPEG-2 generation coding techniques, does not use intra-prediction. However, some newer video compression techniques include techniques that attempt to predict from surrounding sample data and / or metadata obtained during encoding / decoding of spatially neighboring and preceding data blocks in decoding order. Such techniques are hereinafter referred to as "intra-prediction" techniques. It should be noted that at least in some cases, intra-prediction uses only reference data from the current picture being reconstructed, and not from the reference picture.

[0009] Intra prediction can take many different forms. If more than one of such techniques is available for a given video coding technique, the technique used can be coded in the intra prediction mode. In certain cases, a mode can have sub-modes and / or parameters that can be coded separately or included in a mode codeword. For a given mode, sub-mode, and / or parameter combination, which codeword is used can affect the coding efficiency gains via intra prediction, as can the entropy coding technique used to convert the codeword into a bitstream.

[0010] A specific mode of intra prediction was introduced in H.264, improved in H.265, and further improved in newer coding techniques such as Joint Search Model (JEM), Versatile Video Coding (VVC), and Benchmark Set (BMS). It is possible to form a predictor block using neighboring sample values ​​belonging to already available samples. The sample values ​​of the neighboring samples are copied to the predictor block according to the direction. The reference to the direction in use can be coded in the bitstream or may itself be predicted.

[0011] Referring to FIG. 1A, a subset of 9 known predictor directions from the 33 possible predictor directions (corresponding to the 33 angle modes of the 35 intra modes) of H.265 is depicted at the bottom right. The point where the arrows meet (101) represents the sample being predicted. The arrows represent the direction in which the sample is predicted. For example, arrow (102) indicates that sample (101) is predicted from one or more samples to the upper right at an angle of 45 degrees from the horizontal. Similarly, arrow (103) indicates that sample (101) is predicted from one or more samples to the lower left of sample (101) at an angle of 22.5 degrees from the horizontal.

[0012] Still referring to FIG. 1A, at the top left is shown a square block (104) of 4×4 samples (indicated by a thick dashed line). The square block (104) contains 16 samples, each labeled with an “S”, its position in the Y dimension (e.g., row index), and its position in the X dimension (e.g., column index). For example, sample S21 is the second sample (from the top) in the Y dimension and the first sample (from the left) in the X dimension. Similarly, sample S44 is the fourth sample in both the Y and X dimensions in the block (104). Since the block is 4×4 samples in size, S44 is at the bottom right. Also shown are reference samples that follow a similar numbering scheme. The reference samples are labeled with R and their Y position (e.g., row index) and X position (column index) relative to the block (104). In both H.264 and H.265, the prediction samples are in the neighborhood of the block being reconstructed, so there is no need for negative values ​​to be used.

[0013] Intra-picture prediction can work by copying reference sample values ​​from neighboring samples as appropriated by the signaled prediction direction. For example, assume that the coded video bitstream includes signaling for this block indicating a prediction direction that coincides with the arrow (102), i.e., the sample is predicted from one or more prediction samples in the upper right corner at an angle of 45 degrees from the horizontal. In that case, samples S41, S32, S23, and S14 are predicted from the same reference sample R05. Then, sample S44 is predicted from reference sample R08.

[0014] In certain cases, to calculate a reference sample, especially when the orientation is not evenly divisible by 45 degrees, the values ​​of multiple reference samples may be combined, for example by interpolation.

[0015] The number of possible directions is increasing as video coding technology develops. In H.264 (2003), nine different directions could be represented. In H.265 (2013), this increased to 33, and at the time of this disclosure, JEM / VVC / BMS can support up to 65 directions. Experiments have been conducted to identify the most likely directions, and certain techniques in entropy coding are used to represent those likely directions with a small number of bits, accepting a certain penalty for less likely directions. Furthermore, in some cases, the direction itself can be predicted from nearby directions used in nearby, already decoded blocks.

[0016] FIG. 1B shows a schematic diagram (110) showing 65 intra prediction directions with JEM to illustrate the increasing number of prediction directions over time.

[0017] The mapping of intra-prediction direction bits in a coded video bitstream representing directions may vary from one video coding technique to another, ranging, for example, from a simple direct mapping of prediction directions to intra-prediction modes, to complex adaptation schemes involving codewords, most probable modes, and similar techniques. In all cases, however, there may be certain directions that are statistically less likely to occur in the video content than certain other directions. Because the goal of video compression is to reduce redundancy, these less likely directions are represented with more bits than more likely directions in a video coding technique that works well.

[0018] Video coding and decoding may be performed using inter-picture prediction with motion compensation. Motion compensation may be a lossy compression technique and may refer to a technique in which blocks of sample data from a previously reconstructed picture or part thereof (reference picture) are spatially shifted in a direction indicated by a motion vector (hereafter MV) and then used to predict a newly reconstructed picture or part of a picture. In some cases, the reference picture may be the same as the picture currently being reconstructed. The MV may have two dimensions X and Y, or three dimensions, with the third dimension being an indication of the reference picture in use (the third dimension may indirectly be a temporal dimension).

[0019] In some video compression techniques, the MV applicable to a particular area of ​​sample data can be predicted from other MVs, e.g., from MVs associated with other areas of sample data that are spatially adjacent to the area being reconstructed and that precede that MV in decoding order. Doing so can significantly reduce the amount of data required to code the MV, thereby eliminating redundancy and increasing the compression ratio. For example, when coding an input video signal derived from a camera (known as natural video), MV prediction can work effectively because there is a statistical likelihood that areas larger than the area to which a single MV is applicable move in similar directions and therefore, in some cases, can be predicted using similar motion vectors derived from MVs of nearby areas. As a result, the detected MV for a given area is similar or the same as the MV predicted from the surrounding MVs, which, after entropy coding, can be represented with fewer bits than would be used if the MVs were coded directly. In some cases, MV prediction can be an example of lossless compression of a signal (i.e., MV) derived from an original signal (i.e., a sample stream). In other cases, the MV prediction itself can be lossy, e.g., due to rounding errors when computing a predictor from several surrounding MVs.

[0020] Various MV prediction mechanisms are described in H.265 / HEVC (ITU-T Rec. H.265, “High Efficiency Video Coding”, December 2016). Among the many MV prediction mechanisms offered by H.265, a technique referred to below as “spatial merging” is described herein.

[0021] Referring to Figure 2, a current block (201) contains samples that have been discovered by the encoder during the motion search process to be predictable from a previous block of the same size but spatially shifted. Instead of coding its MV directly, the MV can be derived from metadata associated with one or more reference pictures, e.g., from the most recent reference picture (in decoding order), using MVs associated with any one of five surrounding samples, denoted A0, A1, and B0, B1, B2 (202-206, respectively). In H.265, MV prediction can use predictors from the same reference picture that neighboring blocks are using. Summary of the Invention [Means for solving the problem]

[0022] Aspects of the present disclosure provide a method and apparatus for encoding / decoding video. In some examples, the apparatus for video decoding includes a receiving circuit and a processing circuit. The processing circuit determines the use of inherited context initialization in context-based adaptive binary arithmetic coding (CABAC) for decoding a current portion of a video sequence carried by a bitstream. The processing circuit decodes from the bitstream a syntax value indicating a decoded portion of the video sequence for context inheritance, and initializes a context model for CABAC based on a stored context state associated with the decoded portion. Furthermore, the processing circuit decodes the current portion from the bitstream according to the context model initialized based on the stored context state associated with the decoded portion.

[0023] In examples, the syntax value indicates a decoded picture for context inheritance. In other examples, the syntax value indicates a decoded slice for context inheritance. In some examples, the syntax value is decoded from at least one of a picture parameter set (PPS), a picture header, and a slice header.

[0024] In some instances, the decoded portion is a reference used to decode the current portion.

[0025] In some examples, the processing circuit decodes syntax values ​​indicating at least a first decoded portion and a second decoded portion, and initializes a context model for CABAC according to a weighted average of probability values ​​indicated by at least a first context state associated with the first decoded portion and a second context state associated with the second decoded portion.

[0026] In some examples, the processing circuit may decode a first weighting factor associated with the first decoded portion and a second weighting factor associated with the second decoded portion. The processing circuit calculates the weighted average by applying the first weighting factor to a first probability value indicated by a first context state associated with the first decoded portion and applying the second weighting factor to a second probability value indicated by a second context state associated with the second decoded portion.

[0027] In some examples, in response to a bitstream that does not carry a weighting factor associated with the first decoded portion, the processing circuit determines to use a weighting factor of zero or a default weighting factor associated with the first decoded portion.

[0028] In some examples, the processing circuit decodes an indicator from the bitstream at a Group of Pictures (GOP) level. The indicator indicates one or more pictures allowed for context inheritance. The processing circuit prioritizes decoding of a first picture of the one or more pictures before decoding of a second picture that is not in the one or more pictures. In an example, the processing circuit decodes the indicator from a reference picture list structure syntax.

[0029] Aspects of the present disclosure also provide a non-transitory computer-readable medium storing instructions that, when executed by a computer, cause the computer to perform a method for video decoding.

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

[0031] [Figure 1A] FIG. 2 is a schematic diagram of an example subset of intra-prediction modes. [Figure 1B] FIG. 2 is a diagram of an example intra-prediction direction. [Diagram 2] FIG. 2 is a schematic diagram of a current block and its surrounding spatial merge candidates in one example. [Diagram 3] 1 is a schematic diagram of a simplified block diagram of a communication system (300), according to an embodiment. [Figure 4] FIG. 4 is a schematic diagram of a simplified block diagram of a communication system (400), according to an embodiment. [Diagram 5] FIG. 2 is a schematic diagram of a simplified block diagram of a decoder according to an embodiment; [Figure 6] FIG. 2 is a schematic diagram of a simplified block diagram of an encoder according to an embodiment; [Figure 7] FIG. 4 is a block diagram of an encoder according to another embodiment. [Figure 8]FIG. 11 is a block diagram of a decoder according to another embodiment. [Figure 9] 1 shows a table of quantization values ​​for the least probable symbol (LPS) range in some examples. [Figure 10] 1 shows a flowchart outlining a process for decoding a single binary decision in some examples. [Figure 11] 1 shows a flowchart outlining a process according to some embodiments of the present disclosure. [Figure 12] 10 is a flowchart outlining another process in accordance with some embodiments of the present disclosure. [Figure 13] FIG. 1 is a schematic diagram of a computer system according to an embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0032] FIG. 3 illustrates a simplified block diagram of a communication system (300) according to an embodiment of the present disclosure. The communication system (300) includes a plurality of terminal devices that can communicate with each other, for example, via a network (350). For example, the communication system (300) includes a first pair of terminal devices (310) and (320) interconnected via the network (350). In the example of FIG. 3, the first pair of terminal devices (310) and (320) perform unidirectional transmission of data. For example, the terminal device (310) may code video data (e.g., a stream of video pictures captured by the terminal device (310)) for transmission to the other terminal device (320) via the network (350). The encoded video data may be transmitted in the form of one or more coded video bitstreams. The terminal device (320) may receive the coded video data from the network (350), decode the coded video data to reconstruct the video pictures, and display the video pictures according to the reconstructed video data. Unidirectional data transmission may be common, such as in media serving applications.

[0033] In another example, the communication system (300) includes a second pair of terminal devices (330) and (340) for bidirectional transmission of coded video data, such as may occur during a video conference. In the case of bidirectional transmission of data, in one example, each of the terminal devices (330) and (340) may code video data (e.g., a stream of video pictures captured by the terminal device) for transmission to the other of the terminal devices (330) and (340) over the network (350). Each of the terminal devices (330) and (340) may also receive coded video data transmitted by the other of the terminal devices (330) and (340), decode the coded video data to reconstruct the video pictures, and display the video pictures on an accessible display device according to the reconstructed video data.

[0034] In the example of FIG. 3, the terminal devices (310), (320), (330), and (340) may be depicted as a server, a personal computer, and a smartphone, although the principles of the present disclosure are not so limited. The embodiments of the present disclosure find application in laptop computers, tablet computers, media players, and / or dedicated video conferencing equipment. The network (350) represents any number of networks that convey decoded video data between the terminal devices (310), (320), (330), and (340), such as, for example, wired (wired) and / or wireless communication networks. The communication network (350) may exchange data over circuit-switched and / or packet-switched channels. Exemplary networks include telecommunications networks, local area networks, wide area networks, and / or the Internet. For purposes of this discussion, the architecture and topology of the network (350) may not be important to the operation of the present disclosure, unless otherwise described herein below.

[0035] 4 illustrates an arrangement of video encoders and video decoders in a streaming environment as an example of application of the subject matter of this disclosure. The subject matter of this disclosure is equally applicable to other video-enabled applications, such as, for example, video conferencing, digital television, and storage of compressed video on digital media including CDs, DVDs, memory sticks, etc.

[0036] The streaming system may include a capture subsystem (413) that may include a video source (401), such as a digital camera, that creates a stream of uncompressed video pictures (402). In an example, the stream of video pictures (402) includes samples taken by a digital camera. The stream of video pictures (402) is shown with a thick line to emphasize its large amount of data compared to the encoded video data (404) (or coded video bitstream) that may be processed by an electronic device (420) that includes a video encoder (403) coupled to the video source (401). The video encoder (403) may include hardware, software, or a combination thereof to enable or implement aspects of the subject matter of this disclosure, as described in more detail below. The encoded video data (404) (or encoded video bitstream (404)) is shown with a thin line to emphasize its small amount of data compared to the stream of video pictures (402) that may be stored on a streaming server (405) for future use. One or more streaming client subsystems, such as the client subsystems (406) and (408) of FIG. 4, can access the streaming server (405) to retrieve copies (407) and (409) of the encoded video data (404). The client subsystem (406) can include a video decoder (410), for example within an electronic device (430). The video decoder (410) decodes an input copy (407) of the encoded video data and creates an output stream (411) of video pictures that can be rendered on a display (412) (e.g., a display screen) or other rendering device (not shown). In some streaming systems, the encoded video data (404), (407), and (409) (e.g., a video bitstream) can be encoded according to a particular video coding / compression standard. Examples of such standards include ITU-T Recommendation H.265.In an example, the developing video coding standard is informally known as Versatile Video Coding (VVC), and the disclosed subject matter may be used in conjunction with VVC.

[0037] It should be noted that the electronic devices (420) and (430) may include other components (not shown). For example, the electronic device (420) may also include a video decoder (not shown), and the electronic device (430) may also include a video encoder (not shown).

[0038] 5 shows a block diagram of a video decoder (510) according to an embodiment of the present disclosure. The video decoder (510) can be included in an electronic device (530). The electronic device (530) can include a receiver (531) (e.g., receiving circuitry). The video decoder (510) can be used in place of the video decoder (410) of the example of FIG. 4.

[0039] The receiver (531) may receive one or more coded video sequences to be decoded by the video decoder (510), in the same or other embodiments, one coded video sequence at a time, with the decoding of each coded video sequence being independent of the other coded video sequences. The coded video sequences may be received from a channel (501), which may be a hardware / software link to a storage device that stores the encoded video data. The receiver (531) may receive the encoded video data along with other data, e.g., coded audio data and / or auxiliary data streams, which may be forwarded to their respective using entities (not shown). The receiver (531) may separate the coded video sequences from the other data. To combat network jitter, a buffer memory (515) may be coupled between the receiver (531) and the entropy decoder / parser (520) (hereinafter "parser (520)"). In certain applications, the buffer memory (515) is part of the video decoder (510). In other applications, the buffer memory (515) can be external to the video decoder (510) (not shown). In still other applications, there can be a buffer memory (not shown) external to the video decoder (510), e.g., to combat network jitter, plus another buffer memory (515) internal to the video decoder (510), e.g., to handle playout timing. When the receiver (531) is receiving data from a store / forward device of sufficient bandwidth and controllability, or from an isosynchronous network, the buffer memory (515) may not be necessary or can be small.For use over a best-effort packet network such as the Internet, a buffer memory (515) may be required, which may be relatively large and advantageously be adaptively sized, and may be implemented at least in part within an operating system or similar element (not shown) external to the video decoder (510).

[0040] The video decoder (510) may include a parser (520) that reconstructs symbols (521) from the coded video sequence. These categories of symbols include information used to manage the operation of the video decoder (510), and potentially include information for controlling a rendering device, such as a rendering device (512) (e.g., a display screen) that is not an integral part of the electronic device (530) but may be coupled to the electronic device (530) as shown in FIG. 5. The control information for the rendering device may be in the form of a supplemental enhancement information (SEI message) or a video usability information (VUI) parameter set fragment (not shown). The parser (520) may parse / entropy decode the received coded video sequence. The coding of the coded video sequence may follow a video coding technique or standard and may follow various principles including variable length coding with or without context dependency, Huffman coding, arithmetic coding, etc. The parser (520) may extract from the coded video sequence a set of subgroup parameters for at least one of the subgroups of pixels in the video decoder based on at least one parameter corresponding to the group. The subgroups may include Group of Pictures (GOPs), pictures, tiles, slices, macroblocks, coding units (CUs), blocks, transform units (TUs), prediction units (PUs), etc. The parser (520) may also extract information from the coded video sequence, such as transform coefficients, quantization parameter values, motion vectors, etc.

[0041] The parser (520) may perform entropy decoding / parsing operations on the video sequence received from the buffer memory (515) to create symbols (521).

[0042] The reconstruction of the symbols (521) can involve several different units, depending on the type of coded video picture or part thereof (inter-picture and intra-picture, inter-block and intra-block, etc.), as well as other factors. Which units are involved and how they are involved can be controlled by subgroup control information parsed from the coded video sequence by the parser (520). The flow of such subgroup control information between the parser (520) and the following units is not shown for clarity.

[0043] Beyond the functional blocks already mentioned, the video decoder (510) may be conceptually subdivided into several functional units, as described below. In an actual implementation operating under commercial constraints, many of these units may interact closely with each other and may be at least partially integrated with each other. However, for purposes of describing the disclosed subject matter, the conceptual subdivision into the functional units described below is expedient.

[0044] The first unit is a scalar / inverse transform unit (551), which receives quantized transform coefficients as well as control information from the parser (520) including which transform to use, block size, quantization coefficients, quantization scaling matrices, etc. as symbols (521). The scalar / inverse transform unit (551) can output blocks containing sample values ​​that can be input to an aggregator (555).

[0045] In some cases, the output samples of the scaler / inverse transform (551) may relate to intra-coded blocks, i.e., blocks that do not use prediction information from a previously reconstructed picture, but may use prediction information from a previously reconstructed portion of the current picture. Such prediction information may be provided by an intra-picture prediction unit (552). In some cases, the intra-picture prediction unit (552) generates a block of the same size and shape as the block being reconstructed using surrounding already reconstructed information fetched from a current picture buffer (558). The current picture buffer (558) buffers, for example, a partially reconstructed current picture and / or a fully reconstructed current picture. The aggregator (555) may append the prediction information generated by the intra-prediction unit (552) to the output sample information provided by the scaler / inverse transform unit (551) on a sample-by-sample basis.

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

[0047] The output samples of the aggregator (555) can be subjected to various loop filtering techniques in the loop filter unit (556). Video compression techniques can include in-loop filter techniques controlled by parameters contained in the coded video sequence (also referred to as the coded video bitstream) as symbols (521) from the parser (520) and made available to the loop filter unit (556), but can also be sensitive to meta-information obtained when decoding the coded picture or earlier parts of the coded video sequence (in decode order), and potentially sensitive to previously reconstructed loop filtered sample values.

[0048] The output of the loop filter unit (556) can be a sample stream that can be output to a render device (512) and can also be stored in a reference picture memory (557) for use in future inter-picture prediction.

[0049] Once fully reconstructed, a particular coded picture can be used as a reference picture for future prediction. For example, once a coded picture corresponding to a current picture is fully reconstructed and the coded picture is identified as a reference picture (e.g., by the parser (520)), the current picture buffer (558) can become part of the reference picture memory (557), and a new current picture buffer can be reallocated before beginning reconstruction of the next coded picture.

[0050] The video decoder (510) may perform decoding operations according to a given video compression technique in a standard, such as ITU-T Rec. H.265. The coded video sequence may comply with the syntax specified by the video compression technique or standard being used, in the sense that the coded video sequence adheres to both the syntax of the video compression technique or standard and the profile documented in the video compression technique or standard. In particular, the profile may select certain tools from among all tools available in the video compression technique or standard as tools that are only available to them under the profile. Also, compliance may require that the complexity of the coded video sequence be within a range defined by the level of the video compression technique or standard. In some cases, the level limits the maximum picture size, maximum frame rate, maximum reconstruction sample rate (e.g., measured in megasamples per second), maximum reference picture size, etc. The limits imposed by the level may be further restricted in some examples by the specification of a hypothetical reference decoder (HRD) and metadata for HRD buffer management signaled in the coded video sequence.

[0051] In an embodiment, the receiver (531) may receive additional (redundant) data along with the encoded video. The additional data may be included as part of the coded video sequence. The additional data may be used by the video decoder (510) to properly decode the data and / or to more accurately reconstruct the original video data. The additional data may be in the form of, for example, temporal, spatial, or signal-to-noise ratio (SNR) enhancement layers, redundant slices, redundant pictures, forward error correction codes, etc.

[0052] 6 shows a block diagram of a video encoder (603) according to an embodiment of the present disclosure. The video encoder (603) is included in an electronic device (620). The electronic device (620) includes a transmitter (640) (e.g., a transmission circuit). The video encoder (603) can be used in place of the example video encoder (403) of FIG.

[0053] The video encoder (603) may receive video samples from a video source (601) (which is not part of the electronic device (620) in the example of FIG. 6) that may capture video images to be coded by the video encoder (603). In other examples, the video source (601) is part of the electronic device (620).

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

[0055] According to an embodiment, the video encoder (603) may code and compress pictures of a source video sequence into a coded video sequence (643) in real time or under any other time constraint required by the application. Enforcing an appropriate coding rate is one function of the controller (650). In some embodiments, the controller (650) controls and is operatively coupled to other functional units described below. This coupling is not depicted for clarity. Parameters set by the controller (650) may include rate control related parameters (picture skip, quantizer, lambda value for rate distortion optimization techniques, ...), picture size, Group of Pictures (GOP) layout, maximum motion vector search range, etc. The controller (650) can be configured to have other appropriate functions associated with the video encoder (603) optimized for a particular system design.

[0056] In some embodiments, the video encoder (603) is configured to operate in a coding loop. As an oversimplified explanation, in an example, the coding loop may include a source coder (630) (e.g., responsible for creating symbols, such as a symbol stream, based on an input picture to be coded and a reference picture) and a (local) decoder (633) embedded in the video encoder (603). The decoder (633) reconstructs the symbols to create sample data in a similar manner as the (remote) decoder does (since any compression between the symbols and the coded video bitstream is lossless in the video compression techniques considered in the disclosed subject matter). The reconstructed sample stream (sample data) is input to a reference picture memory (634). Since the decoding of the symbol stream results in a bit-exact result regardless of the location of the decoder (local or remote), the contents of the reference picture memory (634) are also bit-exact between the local and remote encoders. In other words, the prediction part of the encoder "sees" exactly the same sample values ​​as the decoder will "see" when using the prediction during decoding. This basic principle of reference picture synchrony (and the resulting drift when synchrony cannot be maintained, e.g., due to channel errors) is also used in several related technologies.

[0057] The operation of the "local" decoder (633) may be the same as that of a "remote" decoder, such as the video decoder (510) already described in detail above in connection with Figure 5. However, with brief reference also to Figure 5, because symbols are available and the encoding / decoding of symbols into a coded video sequence by the entropy coder (645) and parser (520) may be lossless, the entropy decoded portions of the video decoder (510), including the buffer memory (515) and parser (520), may not be fully implemented in the local decoder (633).

[0058] At this point, it can be said that any decoder technology other than parsing / entropy decoding that exists in the decoder must also necessarily exist in the corresponding encoder in substantially the same functional form. Therefore, the subject matter of this disclosure focuses on the operation of the decoder. The description of the encoder technology can be omitted because the encoder technology is the opposite of the decoder technology, which is described generically. Only certain parts require more detailed description, and are described below.

[0059] In operation, in some examples, the source coder (630) may perform motion-compensated predictive coding, which predictively codes an input picture with reference to one or more previously coded pictures from a video sequence designated as “reference pictures.” In this manner, the coding engine (632) codes differences between pixel blocks of the input picture and pixel blocks of reference pictures that may be selected as predictive references for the input picture.

[0060] The local video decoder (633) may decode the coded video data of pictures that may be designated as reference pictures based on the symbols created by the source coder (630). The operation of the coding engine (632) may advantageously be a lossy process. When the coded video data may be decoded in a video decoder (not shown in FIG. 6), the reconstructed video sequence may typically be a replica of the source video sequence with some errors. The local video decoder (633) may replicate the decoding process that may be performed by the video decoder on the reference pictures and store the reconstructed reference pictures in a reference picture cache (634). In this way, the video encoder (603) may locally store copies of reconstructed reference pictures that have common content with the reconstructed reference pictures obtained by the far-end video decoder (without transmission errors).

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

[0062] The controller (650) may manage the coding operations of the source coder (630), including, for example, setting the parameters and subgroup parameters used to encode the video data.

[0063] The output of all the aforementioned functional units may undergo entropy coding in an entropy coder (645), which converts the symbols produced by the various functional units into a coded video sequence by losslessly compressing the symbols according to techniques such as Huffman coding, variable length coding, arithmetic coding, etc.

[0064] The transmitter (640) may buffer the coded video sequence created by the entropy coder (645) in preparation for transmission over a communication channel (660), which may be a hardware / software link to a storage device that stores the encoded video data. The transmitter (640) may also integrate other data to be transmitted, such as coded audio data and / or ancillary data streams (sources not shown), with the coded video data obtained from the video coder (603).

[0065] The controller (650) may manage the operation of the video encoder (603). During coding, the controller (650) may assign a particular coded picture type to each coded picture, which may affect the coding technique that may be applied to the respective picture. For example, pictures may often be assigned as one of the following picture types:

[0066] An intra picture (I-picture) may be a picture that can be coded and decoded without using any other picture of the sequence as a source of prediction. Some video codecs allow different types of intra pictures, including, for example, independent decoder refresh ("IDR") pictures. Those skilled in the art will recognize such variations of I-pictures and their corresponding applications and features.

[0067] A predicted picture (P-picture) may be a picture that may be coded and decoded using intra- or inter-prediction, and using at most one motion vector and reference index to predict sample values ​​for each block.

[0068] A bidirectionally predicted picture (B-picture) may be a picture that may be coded and decoded using intra or inter prediction and up to two motion vectors and reference indices to predict the sample values ​​of each block. Similarly, multiple predicted pictures may use more than one reference picture and associated metadata for the reconstruction of a block.

[0069] In general, a source picture can be spatially subdivided into multiple sample blocks (e.g., blocks of 4x4, 8x8, 4x8, or 16x16 samples, respectively) and the blocks can be coded one by one. Blocks can be predictively coded with reference to other (already coded) blocks determined by the coding assignment applied to the respective picture of the block. For example, blocks of an I-picture can be non-predictively coded or they can be predictively coded with reference to already coded blocks of the same picture (spatial or intra prediction). Pixel blocks of a P-picture can be predictively coded via spatial prediction with reference to one previously coded reference picture or via temporal prediction. Blocks of a B-picture can be predictively coded with spatial prediction or with reference to one or two previously coded reference pictures using temporal prediction.

[0070] The video encoder (603) may perform coding operations in accordance with a given video coding technique or standard, such as ITU-T Rec. H.265. In its operations, the video encoder (603) may perform various compression operations, including predictive coding operations that exploit temporal and spatial redundancy in the input video sequence. Thus, the coded video data may conform to a syntax specified by the video coding technique or standard being used.

[0071] In an embodiment, the transmitter (640) may transmit additional data along with the encoded video. The source coder (630) may include such data as part of the coded video sequence. The additional data may comprise temporal / spatial / SNR enhancement layers, other forms of redundant data such as redundant pictures and slices, SEI messages, VUI parameter set fragments, etc.

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

[0073] In some embodiments, bi-prediction techniques can be used for inter-picture prediction. According to bi-prediction techniques, two reference pictures, such as a first reference picture and a second reference picture, are used, both of which are before the decoding order of the current picture in the video (but the display order may be past and future, respectively). A block in the current picture can be coded by a first motion vector pointing to a first reference block in the first reference picture and by a second motion vector pointing to a second reference block in the second reference picture. A block can be predicted by a combination of the first reference block and the second reference block.

[0074] Furthermore, the merge mode method can be used for inter-picture prediction to improve coding efficiency.

[0075] According to some embodiments of the present disclosure, prediction, such as inter-picture prediction or intra-picture prediction, is performed on a block-by-block basis. For example, according to the HEVC standard, a picture in a sequence of video pictures is divided into coding tree units (CTUs) for compression, and the CTUs in a picture have the same size, such as 64×64 pixels, 32×32 pixels, or 16×16 pixels. In general, a CTU includes three coding tree blocks (CTBs), one luma CTB and two chroma CTBs. Each CTU can be recursively quadtree partitioned into one or more coding units (CUs). For example, a CTU of 64×64 pixels can be partitioned into one CU of 64×64 pixels, or into four CUs of 32×32 pixels, or into 16 CUs of 16×16 pixels. In an example, each CU is analyzed to determine a prediction type of the CU, such as an inter prediction type or an intra prediction type. A CU is divided into one or more prediction units (PUs) according to temporal predictability and / or spatial predictability. Generally, each PU includes one luma prediction block (PB) and two chroma PBs. In an embodiment, prediction operations in coding (encoding / decoding) are performed in units of prediction blocks. When using a luma prediction block as an example of a prediction block, the prediction block includes a matrix of pixel values ​​(e.g., luma values) of 8×8 pixels, 16×16 pixels, 8×16 pixels, 16×8 pixels, etc.

[0076] 7 shows a diagram of a video encoder (703) according to another embodiment of the present disclosure. The video encoder (703) is configured to receive a processed block of sample values ​​(e.g., a predictive block) in a current video picture in a sequence of video pictures and to encode the processed block into a coded picture that is part of a coded video sequence. In an example, the video encoder (703) is used in place of the example video encoder (403) of FIG. 4.

[0077] In an HEVC example, the video encoder (703) receives a matrix of sample values ​​for a processing block, such as a predictive block of 8x8 samples. The video encoder (703) determines whether the processing block is best coded using intra-mode, inter-mode, or bi-predictive mode, for example, using rate-distortion optimization. When the processing block is to be coded in intra-mode, the video encoder (703) may encode the processing block into a coded picture using intra-prediction techniques, and when the processing block is to be coded in inter-mode or bi-predictive mode, the video encoder (703) may encode the processing block into a coded picture using inter-prediction techniques or bi-prediction techniques, respectively. In certain video coding techniques, the merge mode may be an inter-picture prediction sub-mode in which a motion vector is derived from one or more motion vector predictors without the aid of coded motion vector components outside the predictors. In certain other video coding techniques, there may be motion vector components applicable to the current block. In examples, the video encoder (703) includes other components, such as a mode decision module (not shown), to determine the mode of the processing blocks.

[0078] In the example of FIG. 7, the video encoder (703) includes an inter-encoder (730), an intra-encoder (722), a residual calculator (723), a switch (726), a residual encoder (724), a general controller (721), and an entropy encoder (725), coupled together as shown in FIG.

[0079] The inter-encoder (730) is configured to receive samples of a current block (e.g., a processing block), compare the block to one or more reference blocks in a reference picture (e.g., blocks in previous and subsequent pictures), generate inter-prediction information (e.g., a description of redundant information due to inter-encoding techniques, motion vectors, merge mode information), and calculate an inter-prediction result (e.g., a predicted block) based on the inter-prediction information using any suitable technique. In some examples, the reference picture is a decoded reference picture that is decoded based on the encoded video information.

[0080] The intra encoder (722) is configured to receive samples of a current block (e.g., a processing block), possibly compare the block to already coded blocks in the same picture, generate transformed quantized coefficients, and possibly also generate intra prediction information (e.g., intra prediction direction information according to one or more intra encoding techniques). In an example, the intra encoder (722) also calculates intra prediction results (e.g., predicted blocks) based on the intra prediction information and reference blocks in the same picture.

[0081] The generic controller (721) is configured to determine generic control data and control other components of the video encoder (703) based on the generic control data. In an example, the generic controller (721) determines the mode of the block and provides a control signal to the switch (726) based on the mode. For example, if the mode is an intra mode, the generic controller (721) controls the switch (726) to select an intra mode result to be used by the residual calculator (723) and controls the entropy encoder (725) to select intra prediction information and include the intra prediction information in the bitstream; if the mode is an inter mode, the generic controller (721) controls the switch (726) to select an inter prediction result to be used by the residual calculator (723) and controls the entropy encoder (725) to select inter prediction information and include the inter prediction information in the bitstream.

[0082] The residual calculator (723) is configured to calculate a difference (residual data) between the received block and a prediction result selected from the intra-encoder (722) or the inter-encoder (730). The residual encoder (724) is configured to operate based on the residual data to encode the residual data to generate transform coefficients. In an example, the residual encoder (724) is configured to transform the residual data from a spatial domain to a frequency domain to generate transform coefficients. The transform coefficients then undergo a quantization process to obtain quantized transform coefficients. In various embodiments, the video encoder (703) also includes a residual decoder (728). The residual decoder (728) is configured to perform an inverse transform and generate decoded residual data. The decoded residual data can be used by the intra-encoder (722) and the inter-encoder (730) as appropriate. For example, the inter-encoder (730) can generate decoded blocks based on the decoded residual data and the inter-prediction information, and the intra-encoder (722) can generate decoded blocks based on the decoded residual data and the intra-prediction information. The decoded blocks are appropriately processed to generate decoded pictures, which can be buffered in a memory circuit (not shown) and used as reference pictures in some examples.

[0083] The entropy encoder (725) is configured to format a bitstream to include the encoded block. The entropy encoder (725) is configured to include various information in accordance with an appropriate standard, such as the HEVC standard. In an example, the entropy encoder (725) is configured to include in the bitstream general control data, selected prediction information (e.g., intra-prediction information or inter-prediction information), residual information, and other appropriate information. It should be noted that, in accordance with the disclosed subject matter, no residual information is present when coding a block in a merged sub-mode of either an inter-mode or a bi-prediction mode.

[0084] 8 shows a diagram of a video decoder (810) according to another embodiment of the present disclosure. The video decoder (810) is configured to receive coded pictures that are part of a coded video sequence and decode the coded pictures to generate reconstructed pictures. In an example, the video decoder (810) is used in place of the video decoder (410) of the example of FIG. 4.

[0085] In the example of FIG. 8, the video decoder (810) includes an entropy decoder (871), an inter decoder (880), a residual decoder (873), a reconstruction module (874), and an intra decoder (872), coupled to each other as shown in FIG. 8.

[0086] The entropy decoder (871) may be configured to reconstruct from the coded picture certain symbols representing syntax elements that make up the coded picture. Such symbols may include, for example, prediction information (e.g., intra- or inter-prediction information) that may identify the mode of coding of the block (e.g., intra- or bi-prediction mode, merged submode or other submode in the latter two, etc.), certain samples or metadata used for prediction by the intra-decoder (872) or the inter-decoder (880), respectively, residual information, for example in the form of quantized transform coefficients, etc. In an example, if the prediction mode is an inter- or bi-prediction mode, the inter-prediction information is provided to the inter-decoder (880), and if the prediction type is an intra-prediction type, the intra-prediction information is provided to the intra-decoder (872). The residual information may undergo inverse quantization and is provided to the residual decoder (873).

[0087] The inter decoder (880) is configured to receive the inter prediction information and to generate inter prediction results based on the inter prediction information.

[0088] The intra decoder (872) is configured to receive the intra prediction information and to generate a prediction result based on the intra prediction information.

[0089] The residual decoder (873) is configured to perform inverse quantization to extract inverse quantized transform coefficients, and to process the inverse quantized transform coefficients to transform the residual from the frequency domain to the spatial domain. The residual decoder (873) may also require certain control information (to include quantizer parameters (QP)), which may be provided by the entropy decoder (871) (data path not shown as this may be only low volume control information).

[0090] The reconstruction module (874) is configured to combine, in the spatial domain, the residual output by the residual decoder (873) and the prediction result (output by the inter-prediction module or the intra-prediction module, as the case may be) to form a reconstructed block, which may be part of a reconstructed picture (which may be part of a reconstructed video). It should be noted that other suitable operations, such as a deblocking operation, may be performed to improve visual quality.

[0091] It should be noted that the video encoders (403), (603), and (703) and the video decoders (410), (510), and (810) may be implemented using any suitable technology. In an embodiment, the video encoders (403), (603), and (703) and the video decoders (410), (510), and (810) may be implemented using one or more integrated circuits. In other embodiments, the video encoders (403), (603), and (603) and the video decoders (410), (510), and (810) may be implemented using one or more processors executing software instructions.

[0092] Aspects of the present disclosure provide techniques for context-based adaptive binary arithmetic coding (CABAC) initialization. In some embodiments, CABAC context initialization is based on inheriting information from a previously coded (encoded / decoded) frame.

[0093] CABAC is a coding technique used in entropy coding. In general, the encoding process of CABAC includes a binarization step, a context modeling step, and an arithmetic coding step.

[0094] In the binarization step for the CABAC-based encoding process, syntax elements with non-binary values ​​can be mapped to binary sequences, also called bin strings. If syntax elements are provided with binary form values ​​(e.g., binary sequences), the binarization step can be bypassed.

[0095] In the context modeling step of the CABAC-based encoding process, a probability model is determined depending on previously encoded syntax elements. In some examples, the probability model (also referred to as context in CABAC) can be represented by a probability state (also referred to as context state in some examples) and a most likely symbol (MPS) value. The probability state can be associated with a probability value and can implicitly represent that the probability that a particular symbol (e.g., bin) is a least probable symbol (LPS) is equal to the probability value. A symbol can be an LPS or an MPS. For binary symbols, the MPS and LPS can be 0 or 1. For example, if the LPS is 1, then the MPS is 0. If the LPS is 0, then the MPS is 1. The probability values ​​are estimated for the corresponding context and can be used to entropy code the symbol using an arithmetic coder.

[0096] The arithmetic coding step of the CABAC-based encoding process is based on the principle of recursive interval subdivision by a probability model. In some examples, the arithmetic coding step is processed by a state machine with a range parameter and a low parameter. The state machine can change the values ​​of the range parameter and the low parameter based on the context (probability model) and the sequence of bins to be coded. The value of the range parameter indicates the size of the current range in which the coding values ​​(of the bins) fall, and the value of the low parameter indicates the lower limit of the current range. In examples, according to the probability state (e.g., related to the probability value), the current range (CurrRange) is divided into a first subrange (MpsRange) (also called MPS range of the current state) and a second subrange (LpsRange) (also called LPS range of the current state). In examples, the second subrange may be calculated by multiplication, such as using equation (1): LpsRange = CurrRange × ρ Equation (1) where ρ is the probability value that the current bin is an LPS. The probability that the current bin is an MPS can be calculated by (1-ρ). The first subrange can be calculated by formula (2): MpsRange=CurrRange-LpsRange Formula (2)

[0097] In an example, if the current bin is an MPS, the value of the low parameter is retained and the value of the range parameter is updated to MpsRange. If the current bin is an LPS, the value of the low parameter is updated to (low+MpsRange) and the value of the range parameter is updated to LpsRange. The CABAC encoding process can then proceed to the next bin in the sequence of bins.

[0098] In some examples (e.g., HEVC), the value of the range parameter is represented by 9 bits and the value of the low parameter is represented by 10 bits. Furthermore, in order to maintain the range and low values ​​with sufficient accuracy, a renormalization process can be performed. For example, renormalization can be performed whenever the value of the range parameter is less than 256. Thus, the range parameter is equal to or greater than 256 after renormalization.

[0099] In some examples (e.g., HEVC), 64 possible probability values ​​of the LPS may be used, and each MPS may be 0 or 1. In an example, the probability model may be stored as 7-bit entries corresponding to the 64 probability values ​​(64 probability states) and two possible values ​​of the MPS (0 or 1). Each 7-bit entry may be assigned 6 bits to represent the probability state and 1 bit for the MPS.

[0100] In some examples, to reduce the calculations to derive the LPS range (e.g., the multiplications in equation (1)), the results for all cases are pre-calculated, quantized, and stored as approximations in a lookup table. Thus, the LPS range can be obtained using a table lookup without any multiplication operations. Avoiding multiplications can be important for some devices or applications to reduce calculations and latency.

[0101] FIG. 9 illustrates a table (900) of quantized values ​​of the LPS range in some examples. In some examples, the range parameter is represented by 9 bits and the value of the range parameter is 256 or greater. The range can be divided into four segments, referred to as segment 0, segment 1, segment 2, and segment 3. Segment 0 includes 64 ranges that are values ​​from 256 to 319. Segment 1 includes 64 ranges that are values ​​from 320 to 383. Segment 2 includes 64 ranges that are values ​​from 384 to 447. Segment 3 includes 64 ranges that are values ​​from 448 to 511. The index of the segment can be derived using (range>>6)&3 in the example, where the range represents the range parameter represented by 9 bits. In some examples, the range parameter is represented by 9 bits and then the quantized value of the LPS range can be represented using 8 bits and therefore the values ​​in the table (900) can be represented using 8 bits.

[0102] In the example of Figure 9, the table (900) includes four columns, each corresponding to four segments of the range, and 64 rows, each corresponding to 64 probability states (associated with a respective probability value). The value stored in the entry with the row index and column index is the quantized value of the LPS range associated with the probability state (corresponding to the row index) and the range segment (corresponding to the column index). In the example of Figure 9, the LPS range of the probability states is quantized to four values ​​(i.e., one value for each segment).

[0103] In some examples, a CABAC engine for performing CABAC-based encoding or decoding (e.g., in a video encoder or video decoder) may include a table (900) that stores 64×4 8-bit values ​​to approximate the calculation of Equation (1). The table (900) may be used to perform a table-based probability transition process between 64 different probability states. For example, a probability state is determined for a current range. The current range is used to determine a range segment that indicates a column index of the table (900). The probability state is used to determine a row index of the table (900). A table lookup is then performed on the table (900) to obtain a value stored in an entry having a row index and a column index, which is the approximated LPS range.

[0104] In some examples (e.g., VVC), the probability value of a probability state is linearly represented by a probability index (represented by pStateIdx), and the calculation can be performed using an equation without LUT operations. To improve the accuracy of the probability estimation, a multi-hypothesis probability update model can be applied. For example, pStateIdx used for interval subdivision in a binary arithmetic coder is a combination of two probabilities pStateIdx0 and pStateIdx1 (for two hypotheses). The two probabilities are associated with each context model and updated independently with different adaptation rates. The adaptation rates of pStateIdx0 and pStateIdx1 for each context model can be pre-trained based on the statistics of the associated bin. In some examples, the probability estimate pStateIdx is the average of the estimates obtained from the two hypotheses.

[0105] FIG. 10 shows a flowchart outlining a process (1000) for decoding a single binary decision in some examples (e.g., VVC). In some examples, a context table (e.g., indicated by a variable ctxTable) and a context index (e.g., represented by ctxIdx) can be provided to the process (1000) to obtain probability state information such as two probabilities pStateIdx0 and pStateIdx1. The process (1000) can operate on variables ivlCurrRange (indicating the current range) and ivlOffset (indicating the lower limit of the current range) based on the probability state information such as the two probabilities pStateIdx0 and pStateIdx1, output a decoded value binVal, and update the variables ivlCurrRange and ivlOffset, and the two probabilities pStateIdx0 and pStateIdx1. Note that in some examples, the variables ivlCurrRange and ivlOffset are defined in a particular way such that ivlOffset is greater than or equal to ivlCurrRange.The process (1000) starts at (S1001) and proceeds to (S1010).

[0106] At (S1010), the value of the LPS range (denoted by the variable ivlLpsRange) is derived. In the example, given the current value of ivlCurrRange, the variable qRangeIdx is derived as equation (3): qRangeIdx=ivlCurrRange>>5 Formula (3)

[0107] Next, given qRangeIdx, pStateIdx0 and pStateIdx1 (associated with ctxTable and ctxIdx), the value of the MPS (represented by valMps) and the value of the LPS range (represented by ivlLpsRange) are derived, for example according to equations (4), (5) and (6): pState=pStateIdx1+16×pStateIdx0 Equation (4) valMps=pState>>14 Equation (5) ivlLpsRange=(qRangeIdx×((valMps?32767-pState:pState)>>9)>>1)+4 Equation (6)

[0108] Additionally, assuming that the bin is an MPS, the variable ivlCurrRange is set equal to (ivlCurrRange-ivlLpsRange).

[0109] In (S1020), if the variable ivlOffset is greater than or equal to ivlCurrRange, then the assumption (the bin is MPS) is not true and the process proceeds to (S1030), otherwise the process proceeds to (S1040).

[0110] At (S1030), the bin is LPS, so the bin's value (denoted by the variable binVal) is set equal to (1-valMps), and the lower limit of the current range and the current range are updated accordingly. In the example, the variable ivlOffset is decremented by ivlCurrRange, and ivlCurrRange is set equal to ivlLpsRange.

[0111] At (S1040), the bin is the MPS and a variable binVal is set equal to valMps.

[0112] At (S1050), state transition is performed. Based on the decoded value binVal, probability state information such as two probabilities pStateIdx0 and pStateIdx1 is updated.

[0113] In some examples, the two adaptation variables shift0 and shift1 are derived from the shiftIdx value associated with ctxTable and ctxIdx, as shown by equations (7) and (8): shift0 = (shiftIdx>>2) + 2 Equation (7) shift1=(shiftIdx&3)+3+shift0 Equation (8)

[0114] The probability state information, such as the two probabilities pStateIdx0 and pStateIdx1, is updated according to the decoded value binVal, as shown by equations (9) and (10): pStateIdx0=pStateIdx0-(pStateIdx0>>shift0)+(1023×binVal>>shift0) Formula (9) pStateIdx1=pStateIdx1-(pStateIdx1>>shift1)+(16383×binVal>>shift1) Formula (10)

[0115] At (S1060), a renormalization step may be performed, for example, if the current range ivlCurrRange is less than 256. The process (1000) then proceeds to (S1099) and ends.

[0116] According to aspects of the present disclosure, the probability states may be initialized at the beginning of each slice. In some examples (e.g., HEVC and VVC), CABAC may have a QP-dependent initialization process that is invoked at the beginning of each slice. In examples, given an initial value of the luma QP for a slice, the initial probability state of the context model, denoted as preCtxState, is derived according to Equations (11)-(15): slopeIdx=initValue>>3 Equation (11) offsetIdx=initValue&7 Equation (12) m=slopeIdx-4 Equation (13) n=(offsetIdx×18)+1 Equation (14) preCtxState=Clip3(1,127,((m×(Clip3(0,63,SliceQp Y )-16))>>1)+n) Equation (15) In the formula, the variable initValue is a 6-bit variable obtained from the table associated with the variables ctxTable and ctxIdx, and SliceQ pYdenotes the slice QP value, and slopeIdx and offsetIdx are limited to 3 bits. The probability state preCtxState directly represents the probability in the linear domain. Note that Clip3(x,y,z) is a function that clips z to the range of [x,y].

[0117] Note that in some examples, appropriate shift operations can be performed on preCtxState to generate the input to the arithmetic coding engine (to perform the arithmetic coding step). In some examples, the mapping from the logarithmic domain to the linear domain as well as the table (900) is not required. In some examples, the two probabilities pStateIdx0 and pStateIdx1 can be derived from an initialization using shift operations, for example according to equations (16) and (17): pStateIdx0=preCtxState<<3 Equation (16) pStateIdx1=preCtxState<<7 Equation (17)

[0118] According to some aspects of the present disclosure, the inherited context initialization method can improve CABAC efficiency. For example, the context model for CABAC can be adapted to the content of the first frame after coding (encoding / decoding) the first frame. By using the context model in the second frame having similar content to the first frame, better coding efficiency for coding the second frame can be achieved. In some related examples for inherited context initialization, the context state of the context model of the inter slice (i.e., when the slice type is B or P) containing the last CTU of the picture can be stored. The stored context state can be used to initialize the context model of the next inter slice having the same slice type, QP value and temporal layer ID (e.g., similar content). In some examples, for each inter slice, a control flag is signaled to indicate the context initialization scheme used for the inter slice. For example, a control flag equal to 0 may indicate that the inter-slice context model is initialized using one of the existing context initialization tables (e.g., the context initialization table may be indicated by the slice header level flag sh_cabac_init_flag), and a control flag equal to 1 may indicate that the inter-slice context model is initialized by inheriting a stored context state from a previously coded picture.

[0119] According to aspects of the present disclosure, the related examples can improve coding efficiency, but the related examples introduce dependencies between frames at the same temporal level (e.g., the same temporal layer ID), so that frame-level parallelism such as frame parallel processing (FPP) in both the encoder and the decoder can be broken. In the examples, frame-level parallelism is used to enable multiple frames, such as a first frame and a second frame, to be processed simultaneously. However, if the context model for coding the second frame is initialized based on the context state of the context model of the inter slice including the last CTU of the first frame, the coding of the second frame needs to wait until the inter slice including the last CTU of the first frame is coded. In that case, the first frame and the second frame cannot be processed simultaneously using frame-level parallelism.

[0120] According to some aspects of the present disclosure, at the encoder side, the encoder can select a first portion of a video sequence as a source of inherited context initialization for coding a second portion of the video sequence. The first portion can be selected to avoid a break in frame-level parallelism. The encoder can include in the coding bitstream a signal indicating the first portion as a source for inherited context initialization for coding the second portion. Then, at the decoder side, the decoder can decode the signal indicating the source of the inherited context initialization and perform the inherited context initialization accordingly.

[0121] According to some aspects of the disclosure, a signal indicating which picture / slice the CABAC state (including but not limited to a context associated with an adaptation rate and a window size) is inherited from for the current picture / slice may be included in the bitstream, such as at the picture level, the picture header level, or the slice level. In an example, a signal indicating which picture the CABAC state was inherited from for the current picture is included in the bitstream, such as in a picture header, in a picture parameter set, etc. In another example, a signal indicating which slice the CABAC state is inherited from for the current slice is included in the bitstream, such as a slice header.

[0122] In some embodiments, the encoder can select a coding part that is a reference for coding the current part, and thus no additional dependency is introduced by CABAC state inheritance. In an example, the encoder can select a coding picture that is a reference picture for coding the current picture (P or B type) and include a signal in the bitstream to indicate the coding picture as a source for inherited context initialization. In another example, the encoder can select a coding slice that is a reference slice for coding the current slice (P or B type) and include a signal in the bitstream to indicate the coding slice as a source for inherited context initialization.

[0123] In some embodiments, the encoder can select two or more portions as a source of inherited context initialization and can signal the two or more portions in the bitstream. A context model for the inherited context initialization can be determined based on a weighted average of the context models associated with the two or more portions. The weighted average can be calculated based on weighting factors respectively associated with the two or more portions. The weighting factors can be predefined and known to the encoder and decoder in examples. In other examples, the weighting factors are signaled in the bitstream.

[0124] In an embodiment, the encoder may select multiple pictures as sources for inherited context initialization and may signal the multiple pictures in the bitstream. A context model for the inherited context initialization may be determined based on a weighted average of the context models associated with the multiple pictures. The weighted average may be calculated based on weighting factors respectively associated with the multiple pictures. The weighting factors may be predefined and known to the encoder and decoder in an example. In another example, the weighting factors are signaled in the bitstream.

[0125] In other embodiments, the encoder may select multiple slices as sources for the inherited context initialization and may signal the multiple slices in the bitstream. A context model for the inherited context initialization may be determined based on a weighted average of the context models associated with the multiple slices. The weighted average may be calculated based on weighting factors respectively associated with the multiple slices. The weighting factors may be predefined and known to the encoder and decoder in examples. In other examples, the weighting factors are signaled in the bitstream.

[0126] In some examples, a flag is signaled at the slice / picture level (e.g., current picture, current slice) to indicate whether CABAC state inheritance is allowed. If the flag indicates that CABAC state inheritance is allowed, a weighting factor may be further signaled for each reference (e.g., reference picture, reference slice). A weighting factor of 0 indicates that the reference picture / slice is not used as a source picture for inheritance. In examples, the weighting factor of a reference (picture or slice) is not signaled and the weighting factor of a reference (picture or slice) may be set to 0. In other examples, a default weighting factor may be signaled in the bitstream. If a weighting factor is not signaled for a reference (picture or slice), a default weighting factor is used for the reference (picture or slice).

[0127] In some examples, an indicator is signaled at the Group of Pictures (GOP) level to indicate which pictures are allowed to be used as sources of CABAC state inheritance. The encoder and / or decoder can then prioritize those pictures (allowed to be used as sources of CABAC state inheritance) in parallel processing. For example, the encoder / decoder may place those pictures to be processed before other pictures. In an example, the indicator may be included in a reference picture list structure syntax, where the indicator indicates one or more reference pictures that are allowed to be used as sources of CABAC state inheritance.

[0128] FIG. 11 shows a flow chart outlining a process (1100) according to an embodiment of the present disclosure. The process (1100) can be used in a video encoder. In various embodiments, the process (1100) is performed by a processing circuit, such as the processing circuit of the terminal devices (310), (320), (330), and (340), a processing circuit performing the function of the video encoder (403), a processing circuit performing the function of the video encoder (603), a processing circuit performing the function of the video encoder (703), etc. In some embodiments, the process (1100) is implemented with software instructions, and thus the processing circuit performs the process (1100) when the processing circuit executes the software instructions. The process starts at (S11301) and proceeds to (S1110).

[0129] At (S1110), the encoder determines use of the inherited context initialization in context-based adaptive binary arithmetic coding (CABAC) for encoding a current portion of a video sequence.

[0130] In (S1120), the encoder determines an encoded portion of the video sequence for context inheritance by the current portion according to frame-level parallelism for coding the video sequence. The context inheritance by the current portion to the encoded portion enables frame-level parallelism for coding the video sequence and does not disturb or interrupt the frame-level parallelism. In an example, a first frame and a second frame can be coded (encoded or decoded) in parallel according to the frame-level parallelism, and then the context inheritance enables the first frame and the second frame to be coded in parallel without introducing a dependency between the first frame and the second frame.

[0131] At (S1130), the encoder encodes a signal (e.g., syntax value) indicating an encoded portion for context inheritance. In an example, the signal indicates an encoded picture for context inheritance. In another example, the signal indicates an encoded slice for context inheritance. The signal may be encoded in at least one of a picture parameter set (PPS), a picture header, and a slice header.

[0132] In some cases, the encoded part is the reference used to encode the current part. Thus, context inheritance does not introduce additional dependencies that could break frame-level parallelism.

[0133] In some examples, an encoder encodes a first signal and a second signal of a bitstream carrying a video sequence, where the first signal indicates use of inherited context initialization of CABAC for encoding a current portion and the second signal indicates an encoded portion of the video sequence for context inheritance.

[0134] At (S1140), the encoder initializes a context model for CABAC based on a stored context state associated with the encoded portion.

[0135] In some embodiments, the signal indicates at least a first encoded portion and a second encoded portion. Then, a context model for CABAC can be initialized according to a weighted average of probability values ​​indicated by at least a first context state associated with the first encoded portion and a second context state associated with the second encoded portion. For example, to initialize the context model, a first probability is determined based on a first stored context state associated with the first encoded portion, and a second probability is determined based on a second stored context state associated with the second encoded portion. Then, a weighted average is calculated based on the first probability and the second probability, and the context model is initialized according to the weighted average.

[0136] In some examples, weighting factors for calculating the weighted average may be encoded in the bitstream. In examples, if a weighting factor is not signaled for an encoded portion, a weighting factor of 0 is used. In other examples, if a weighting factor is not signaled for an encoded portion, a default weighting factor may be used. The default weighting factor may be signaled in the bitstream or may be predefined and known at the encoder and decoder sides.

[0137] At (S1150), the encoder encodes the current portion based on a context model initialized based on a stored context state associated with the encoded portion.

[0138] In some examples, the encoder may encode an indicator at a Group of Pictures (GOP) level. The indicator may indicate one or more pictures allowed for context inheritance. The indicator may assist the decoder side to prioritize decoding of one or more pictures. In an example, the indicator is encoded in the reference picture list structure syntax to indicate one or more reference pictures of the reference picture list structure syntax.

[0139] The process then proceeds to (S1199) and ends.

[0140] The process 1100 may be adapted as appropriate. Steps of the process 1100 may be modified and / or omitted. Additional steps may be added. Any suitable order of implementation may be used.

[0141] FIG. 12 shows a flow chart outlining a process (1200) according to an embodiment of the present disclosure. The process (1200) can be used in a video decoder. In various embodiments, the process (1200) is performed by a processing circuit, such as the processing circuit of the terminal devices (310), (320), (330), and (340), the processing circuit performing the function of the video decoder (410), the processing circuit performing the function of the video decoder (510), etc. In some embodiments, the process (1200) is implemented with software instructions, and thus the processing circuit performs the process (1200) when the processing circuit executes the software instructions. The process starts at (S1201) and proceeds to (S1210).

[0142] At (S1210), the decoder determines the use of inherited context initialization in context-based adaptive binary arithmetic coding (CABAC) for decoding a current portion of a video sequence carried by a bitstream. In an example, the decoder decodes, from the bitstream, a control signal indicating the use of inherited context initialization of CABAC for decoding the current portion of the video sequence.

[0143] At (S1220), the decoder decodes, from the bitstream, a signal (eg, syntax value) indicating a decoded portion of the video sequence for context inheritance.

[0144] In an example, the signal indicates a decoded picture for context inheritance. In another example, the signal indicates a decoded slice for context inheritance. The signal can be decoded from at least one of a picture parameter set (PPS), a picture header, and a slice header.

[0145] In some examples, the decoded portion is a reference (e.g., a reference picture, a reference slice) used for decoding the current portion, and therefore no additional dependencies are introduced by context inheritance.

[0146] At (S1230), the decoder initializes a context model for CABAC based on the stored context state associated with the decoded portion.

[0147] In some examples, the signal may indicate at least a first decoded portion and a second decoded portion. A context model for CABAC may be initialized according to a weighted average of probability values ​​indicated by at least a first context state associated with the first decoded portion and a second context state associated with the second decoded portion. For example, to initialize the context model, a first probability is determined based on a first stored context state associated with the first decoded portion, and a second probability is determined based on a second stored context state associated with the second decoded portion. Then, a weighted average is calculated based on the first probability and the second probability, and the context model is initialized according to the weighted average.

[0148] In some examples, the decoder can decode a first weighting factor associated with the first decoded portion and decode a second weighting factor associated with the second decoded portion. The decoder can then calculate a weighted average based on the first weighting factor and the second weighting factor. For example, the decoder can calculate the weighted average by applying the first weighting factor to a first probability value indicated by a first context state associated with the first decoded portion and applying the second weighting factor to a second probability value indicated by a second context state associated with the second decoded portion.

[0149] In some examples, in response to a bitstream that does not carry a weighting factor associated with the first decoded portion, the decoder may determine to use a weighting factor of zero or a default weighting factor associated with the first decoded portion.

[0150] At (S1240), the decoder decodes the current portion from the bitstream according to a context model initialized based on the stored context state associated with the decoded portion.

[0151] In some examples, the decoder may decode an indicator at a Group of Pictures (GOP) level from the bitstream. The indicator indicates one or more pictures allowed for context inheritance. The decoder may prioritize decoding of a first picture of the one or more pictures before decoding of a second picture that is not in the one or more pictures. In some examples, the indicator is decoded from a reference picture list structure syntax.

[0152] The process then proceeds to (S1299) and ends.

[0153] The process 1200 may be adapted as appropriate. Steps of the process 1200 may be modified and / or omitted. Additional steps may be added. Any suitable order of implementation may be used.

[0154] The techniques described above may be implemented as computer software using computer-readable instructions and physically stored on one or more computer-readable media. For example, Figure 13 illustrates a computer system (1300) suitable for implementing certain embodiments of the disclosed subject matter.

[0155] Computer software can be coded using any suitable machine code or computer language that is amenable to mechanisms such as assembly, compilation, linking, etc., to create code that includes instructions that may be executed by one or more computer central processing units (CPUs), graphics processing units (GPUs), etc. directly, or via interpretation, microcode execution, etc.

[0156] The instructions may be executed on various types of computers or computer components including, for example, personal computers, tablet computers, servers, smart phones, gaming consoles, Internet of Things devices, and the like.

[0157] 13 for computer system (1300) are exemplary in nature and are not intended to suggest any limitation as to the scope of use or functionality of the computer software implementing the embodiments of the present disclosure. The arrangement of components should not be interpreted as having any dependency or requirement regarding any one or combination of components illustrated in the exemplary embodiment of computer system (1300).

[0158] The computer system (1300) may include certain human interface input devices. Such human interface input devices may be responsive to input by one or more human users, for example, via tactile input (keystrokes, swipes, data glove movements, etc.), audio input (voice, clapping, etc.), visual input (gestures, etc.), olfactory input (not shown). The human interface devices may also be used to capture certain media not necessarily directly associated with conscious human input, such as audio (voice, music, ambient sounds, etc.), images (scanned images, photographic images obtained from still image cameras, etc.), and video (two-dimensional video, three-dimensional video including stereoscopic video, etc.).

[0159] The input human interface devices may include one or more of a keyboard (1301), a mouse (1302), a trackpad (1303), a touch screen (1310), a data glove (not shown), a joystick (1305), a microphone (1306), a scanner (1307), and a camera (1308) (only one of each is depicted).

[0160] The computer system (1300) may also include certain human interface output devices. Such human interface output devices may stimulate one or more of the senses of a human user, for example, via haptic output, sound, light, and smell / taste. Such human interface output devices may include haptic output devices (e.g., haptic feedback via a touch screen (1310), data gloves (not shown), or joystick (1305), although there may be haptic feedback devices that do not function as input devices), audio output devices (such as speakers (1309), headphones (not depicted)), visual output devices (such as screens (1310), including CRT screens, LCD screens, plasma screens, OLED screens, each with or without touch screen input capability, each with or without haptic feedback capability, some of which may output two-dimensional visual output or three- or more-dimensional output via means such as stereographic output, virtual reality glasses (not depicted), holographic displays, and smoke tanks (not depicted)), and printers (not depicted).

[0161] The computer system (1300) may also include human-accessible storage devices and their associated media, such as optical media, including CD / DVD ROM / RW (1320) with CD / DVD or similar media (1321), thumb drives (1322), removable hard drives or solid state drives (1323), legacy magnetic media (not depicted) such as tapes and floppy disks, and specialized ROM / ASIC / PLD based devices (not depicted) such as security dongles.

[0162] Those skilled in the art should also understand that the term "computer-readable medium" as used in connection with the subject matter of this disclosure does not encompass transmission media, carrier waves, or other transitory signals.

[0163] The computer system (1300) may also include an interface (1354) to one or more communication networks (1355). The networks may be, for example, wireless, wired, optical. The networks may further be local, wide area, metropolitan, vehicular and industrial, real-time, delay tolerant, and the like. Examples of networks include local area networks such as Ethernet, wireless LAN, cellular networks including GSM, 3G, 4G, 5G, LTE, and the like, television wired or wireless wide area digital networks including cable television, satellite television, and terrestrial broadcast television, vehicular and industrial including CANBus, and the like. Certain networks typically require an external network interface adapter connected to a particular general-purpose data port or peripheral bus (1349) (e.g., a USB port on the computer system (1300)), while others are generally integrated into the core of the computer system (1300) by connecting to a system bus, as described below (e.g., an Ethernet interface for a PC computer system, or a cellular network interface for a smartphone computer system). Using any of these networks, the computer system (1300) may communicate with other entities. Such communications may be one-way, receive-only (e.g., television broadcast), one-way transmit-only (e.g., from a CANbus to a particular CANbus device), or two-way, e.g., to other computer systems using local or wide area digital networks. Specific protocols and protocol stacks may be used in each of these networks and network interfaces, as previously described.

[0164] The aforementioned human interface devices, human accessible storage devices, and network interfaces may be attached to a core (1340) of the computer system (1300).

[0165] The cores (1340) may include one or more central processing units (CPUs) (1341), graphics processing units (GPUs) (1342), dedicated programmable processing devices in the form of field programmable gate areas (FPGAs) (1343), hardware accelerators for specific tasks (1344), graphics adapters (1350), etc. These devices may be connected through a system bus (1348), along with read only memory (ROM) (1345), random access memory (1346), internal mass storage (1347), such as an internal non-user accessible hard drive, SSD, etc. In some computer systems, the system bus (1348) may be accessible in the form of one or more physical plugs to allow expansion with additional CPUs, GPUs, etc. Peripheral devices may be attached directly to the core's system bus (1348) or through a peripheral bus (1349). In an example, a screen (1310) may be connected to the graphics adapter (1350). Architectures for peripheral buses include PCI, USB, etc.

[0166] The CPU (1341), GPU (1342), FPGA (1343) and accelerator (1344) may combine to execute certain instructions that may constitute the aforementioned computer code. This computer code may be stored in ROM (1345) or RAM (1346). Persistent data may be stored, for example, in internal mass storage (1347), while transitory data may also be stored in RAM (1346). Rapid storage and retrieval from any of the memory devices may be enabled using cache memory, which may be closely associated with one or more of the CPU (1341), GPU (1342), mass storage (1347), ROM (1345), RAM (1346), etc.

[0167] The computer-readable medium can bear computer code for performing various computer-implemented operations. The medium and computer code may be those specially designed and constructed for the purposes of the present disclosure, or they may be of the available kind well known to those skilled in the computer software arts.

[0168] By way of example and not limitation, a computer system (1300) having an architecture, and specifically a core (1340), may provide functionality as a result of a processor (one or more) (including a CPU, GPU, FPGA, accelerator, etc.) executing software embodied in one or more tangible computer-readable media. Such computer-readable media may be user-accessible mass storage as previously described, as well as media associated with a particular storage of the core (1340) that is of a non-transitory nature, such as a core internal mass storage (1347) or a ROM (1345). Software implementing various embodiments of the present disclosure may be stored in such devices and executed by the core (1340). The computer-readable media may include one or more memory devices or chips, depending on the particular needs. The software may cause the core (1340), and specifically the processors therein (including a CPU, GPU, FPGA, etc.) to perform particular processes or particular portions of particular processes described herein, including defining data structures stored in RAM (1346) and modifying such data structures according to processes defined by the software. Additionally, or alternatively, the computer system may provide functionality as a result of hardwired or otherwise embodied logic in circuitry (e.g., accelerator (1344)) that can operate in place of or in conjunction with software to perform particular processes or particular portions of particular processes described herein. References to software may encompass logic, and vice versa, where appropriate. References to computer-readable media may encompass circuitry (such as integrated circuits (ICs)) that store software for execution, circuitry that embodies logic for execution, or both, where appropriate. The present disclosure encompasses any suitable combination of hardware and software.

[0169] Appendix A: Acronyms JEM: Joint exploration model VVC: versatile video coding BMS: Benchmark set MV: Motion Vector HEVC: High Efficiency Video Coding SEI: Supplementary Enhancement Information VUI: Video Usability Information GOP: Group of Pictures TU: Transform Unit PU: Prediction Unit CTU: Coding Tree Unit CTB: Coding Tree Block PB: Prediction Block HRD: Hypothetical Reference Decoder SNR: Signal to Noise Ratio CPU: Central Processing Unit GPU: Graphics Processing Unit CRT: Cathode Ray Tube LCD: Liquid Crystal Display OLED: Organic Light-Emitting Diode CD: Compact Disc DVD: Digital Video Disc ROM: Read-Only Memory RAM: Random Access Memory ASIC: Application-Specific Integrated Circuit PLD: Programmable Logic Device LAN: Local Area Network GSM: Global System for Mobile communications LTE: Long-Term Evolution CANBus: Controller Area Network Bus USB: Universal Serial Bus PCI: Peripheral Component Interconnect FPGA: Field Programmable Gate Area SSD: Solid-state drive IC: Integrated Circuit CU: Coding Unit

[0170] While this disclosure describes several exemplary embodiments, there are alterations, substitutions, and various alternative equivalents that fall within the scope of this disclosure. It will thus be appreciated that those skilled in the art will be able to devise numerous systems and methods that, although not explicitly shown or described herein, embody the principles of this disclosure and are therefore within the spirit and scope of the present disclosure. [Explanation of symbols]

[0171] 101 sample, 102 arrow, 103 arrow, 104 block, 110 schematic diagram, 201 current block, 300 communication system, 310 terminal device, 320 terminal device, 330 terminal device, 340 terminal device, 350 communication network, 400 communication system, 401 video source, 402 stream, 403 video encoder, 404 video data, video bitstream, 405 streaming server, 406 client subsystem, 407 input copy, 408 client subsystem, 409 copy, 410 video decoder, 411 output stream, 412 display, 413 capture subsystem, 420 electronic device, 430 electronic device, 501 channel, 510 video decoder, 512 render device, 515 buffer memory, 520 parser, 521 symbol, 530 electronic device, 531 receiver, 551 Scaler / inverse transform unit, 552 Intra picture prediction unit, 553 Motion compensation prediction unit, 555 Aggregator, 556 Loop filter unit, 557 Reference picture memory, 558 Current picture buffer, 601 Video source, 603 Video coder, video encoder, 620 Electronic device, 630 Source coder, 632 Coding engine, 633 Local video decoder, 634 Reference picture memory, reference picture cache, 635 Predictor, 640 Transmitter, 643 Video sequence, 645 Entropy coder, 650 Controller, 660 Communication channel, 703 Video encoder, 721 General controller, 722 Intra encoder, 723 Residual calculator, 724 Residual encoder, 725 Entropy encoder, 726 Switch, 728 Residual decoder, 730 Inter encoder, 810 Video decoder, 871 Entropy decoder, 872, intra decoder, 873, residual decoder, 874, reconstruction module, 880, inter decoder, 900, table, 1000, process, 1100, process, 1200, process, 1300, computer system, 1301, keyboard, 1302, mouse, 1303, track pad, 1305, joystick, 1306, microphone, 1307scanner, 1308 camera, 1309 speaker, 1310 touch screen, 1321 media, 1322 thumb drive, 1323 solid state drive, 1340 core, 1341 central processing unit (CPU), 1342 graphics processing unit (GPU), 1343 field programmable gate area (FPGA), 1344 hardware accelerator, 1345 read only memory (ROM), 1346 random access memory, RAM, 1347 core internal mass storage, 1348 system bus, 1349 peripheral bus, 1350 graphics adapter, 1354 interface, 1355 communication network

Claims

1. A method of video processing performed by a decoder, comprising: determining a use of the inherited context initialization in context-based adaptive binary arithmetic coding (CABAC) for decoding a current portion of a video sequence carried by the bitstream; decoding, from the bitstream, syntax values ​​indicating decoded portions of the video sequence for context inheritance; initializing a context model for the CABAC based on a stored context state associated with the decoded portion; and decoding the current portion from the bitstream according to the context model initialized based on the stored context state associated with the decoded portion.

2. The step of decoding the syntax values ​​comprises: decoding the syntax value indicating the decoded picture for the context inheritance; or The method of claim 1 , further comprising at least one of the steps of: decoding the syntax value indicating the decoded slice for the context inheritance.

3. The method of claim 1 , wherein the syntax values ​​are decoded from at least one of a picture parameter set (PPS), a picture header, and a slice header.

4. The method of claim 1 , wherein the decoded portion is a reference used in the step of decoding the current portion.

5. decoding the syntax values ​​indicating at least a first decoded portion and a second decoded portion; initializing the context model of the CABAC according to a weighted average of probability values ​​indicated by at least a first context state associated with the first decoded portion and a second context state associated with the second decoded portion; The method of claim 1 further comprising:

6. The step of decoding the syntax values ​​comprises: decoding a first weighting factor associated with the first decoded portion; and decoding a second weighting factor associated with the second decoded portion.

7. calculating the weighted average by applying the first weighting factor to a first probability value indicated by the first context state associated with the first decoded portion and by applying the second weighting factor to a second probability value indicated by the second context state associated with the second decoded portion.

7. The method of claim 6, further comprising:

8. determining, in response to the bitstream not carrying a weighting factor associated with the first decoded portion, to use a weighting factor of zero or a default weighting factor associated with the first decoded portion; 6. The method of claim 5, further comprising:

9. decoding a Group of Pictures (GOP) level indicator from the bitstream, the indicator indicating one or more pictures that are allowed to inherit the context; prioritizing the decoding of a first picture of the one or more pictures before the decoding of a second picture that is not in the one or more pictures; The method of claim 1 further comprising:

10. The step of decoding the indicator at the GOP level comprises: The method of claim 9 , further comprising decoding the indicator from a reference picture list structure syntax.

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

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

Images