Generating enhanced context information for video codec featuring adaptive changes in coding order

Abstract

Apparatus and methods are disclosed, including techniques for encoding and decoding video blocks of video data. The disclosed techniques include deriving contextual information from encoded data of video blocks located within a neighborhood of an encoded (or decoded) video block, wherein the derivation of the contextual information is based on a spatial position of a neighboring video block relative to the video block; and then, using the context information, the syntax element is encoded into the bitstream (or the syntax element is decoded therefrom). The disclosed techniques further include deriving context information based on the coding order of the neighboring video blocks.

Description

[0001] Cross-references to related applications This application claims the benefit of European application number 23306515.0, filed on 13 September 2023, the contents of which are incorporated herein by reference. Background Technology

[0002] Context-based adaptive binary arithmetic coding (CABAC) is often used in hybrid block-based video codecs to context-encode syntax elements while taking into account their probability distribution. Generally, context information is generated from video blocks in the neighborhood of the video block being encoded, and the syntax element (representing the video block) is context-coded based on this information. However, as implemented in recent video standards, the order in which neighboring blocks are encoded is not considered when generating context information. Furthermore, the neighboring blocks whose data are used to generate context information are not spatially prioritized. However, depending on the semantics of the syntax element, considering the spatial location and / or encoding order of neighboring blocks when generating context information can be crucial for coding efficiency. Summary of the Invention

[0003] The aspects disclosed in this disclosure describe a method for encoding video blocks of video data into a bitstream. Encoding a video block includes deriving context information from encoded data of neighboring video blocks located within the neighborhood of the video block, wherein the derivation of the context information is based on the spatial position of the neighboring video blocks relative to the video block. Syntax elements are then encoded into the bitstream using the context information. The aspects disclosed in this disclosure also describe a method for decoding video blocks of video data from a bitstream. Decoding a video block includes deriving context information from encoded data of neighboring video blocks located within the neighborhood of the video block, wherein the derivation of the context information is based on the spatial position of the neighboring video blocks relative to the video block. Syntax elements are then decoded from the bitstream using the context information.

[0004] The aspects disclosed in this disclosure describe an apparatus for encoding video blocks of video data. The apparatus includes at least one processor and a memory storing instructions. When executed by the at least one processor, the instructions cause the apparatus to encode the video blocks into a bitstream. Encoding the video blocks includes deriving context information from encoded data of neighboring video blocks located in the neighborhood of the video block, wherein the derivation of the context information is based on the spatial position of the neighboring video blocks relative to the video block. Syntax elements are then encoded into the bitstream using the context information. The aspects disclosed in this disclosure also describe an apparatus for decoding video blocks of video data. The apparatus includes at least one processor and a memory storing instructions. When executed by the at least one processor, the instructions cause the apparatus to decode the video blocks from the bitstream. Decoding the video blocks includes deriving context information from encoded data of neighboring video blocks located in the neighborhood of the video block, wherein the derivation of the context information is based on the spatial position of the neighboring video blocks relative to the video block. Syntax elements are then decoded from the bitstream using the context information.

[0005] Further aspects disclosed in this disclosure describe a non-transitory computer-readable medium comprising instructions executable by at least one processor to perform a method for encoding video blocks of video data into a bitstream. Encoding the video blocks includes deriving context information from encoded data of neighboring video blocks located within the neighborhood of the video block, wherein the derivation of the context information is based on the spatial position of the neighboring video blocks relative to the video block; and encoding syntax elements into the bitstream using the context information. A further aspect disclosed in this disclosure describes a non-transitory computer-readable medium comprising instructions executable by at least one processor to perform a method for decoding video blocks of video data into a bitstream. Decoding the video blocks includes deriving context information from encoded data of neighboring video blocks located within the neighborhood of the video block, wherein the derivation of the context information is based on the spatial position of the neighboring video blocks relative to the video block. Syntax elements are then decoded from the bitstream using the context information.

[0006] This overview is provided to present selected concepts in a simplified form, as further described below in the detailed description. This overview is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to addressing any or all of the shortcomings mentioned in any part of this disclosure. Attached Figure Description

[0007] Figure 1 This is a block diagram of an example system that can be used to implement aspects of this embodiment.

[0008] Figure 2A block diagram of an example video encoder that can be used to implement aspects of this embodiment.

[0009] Figure 3 This is a block diagram of an example video decoder that can be used to implement aspects of this embodiment.

[0010] Figure 4 The diagram illustrates four coding sequences that can be used to implement aspects of this embodiment.

[0011] Figure 5 The diagram illustrates a schematic representation of how the coding tree unit of this embodiment can be flipped.

[0012] Figure 6 The diagram illustrates the scanning order of sub-blocks derived from the split, which can be used to implement aspects of this embodiment.

[0013] Figure 7 The diagram illustrates the flipping of blocks and their reference samples that can be used to implement aspects of this embodiment.

[0014] Figure 8 The diagram illustrates the rotation of blocks and their reference samples that can be used to implement aspects of this embodiment.

[0015] Figure 9 The diagram illustrates the horizontal coding order in which aspects of this embodiment can be implemented.

[0016] Figure 10 This is a flowchart of an example method for decoding the SUCO flag, which can be used to implement aspects of this embodiment.

[0017] Figure 11A -B is a flowchart of an example method for decoding a segmentation type, which can be used to implement aspects of this embodiment.

[0018] Figure 12 This is a flowchart of an example method for decoding encoding mode flags, which can be used to implement aspects of this embodiment.

[0019] Figure 13 This is a flowchart of an example method for decoding the intra-block copy (IBC) flag, which can be used to implement aspects of this embodiment.

[0020] Figure 14 The diagram illustrates a flowchart of the first aspect of decoding syntax elements, which can be used to implement aspects of this embodiment.

[0021] Figure 15This is a flowchart illustrating a second aspect of decoding syntax elements, which can be used to implement aspects of this embodiment.

[0022] Figure 16 This is a flowchart illustrating a variant of the first aspect of decoding syntax elements, which can be implemented according to the aspects of this embodiment.

[0023] Figure 17 The diagram illustrates a flowchart of a third aspect of decoding syntax elements, which can be used to implement aspects of this embodiment.

[0024] Figure 18 The diagram illustrates a flowchart of a fourth aspect of decoding syntax elements, which can be used to implement aspects of this embodiment.

[0025] Figure 19 The diagram illustrates aspects that can be used to implement this embodiment. Figure 17 The flowchart (including the schematic diagram) shows the third aspect applied to the decoding of segmentation types.

[0026] Figure 20 The diagram illustrates aspects that can be used to implement this embodiment. Figure 17 The flowchart (including the schematic diagram) shows the third aspect applied to the decoding of segmentation types.

[0027] Figure 21 The diagram illustrates aspects that can be used to implement this embodiment. Figure 18 The flowchart shown in the figure illustrates the fourth aspect applied to the decoding of segmentation types.

[0028] Figure 22 The diagram illustrates aspects that can be used to implement this embodiment. Figure 17 The flowchart (including the schematic diagram) shows the third aspect applied to the decoding of the IBC mark.

[0029] Figure 23 The diagram illustrates aspects that can be used to implement this embodiment. Figure 14 The flowchart (including the schematic diagram) shows the first aspect applied to the decoding of the IBC mark.

[0030] Figure 24 The diagram illustrates aspects that can be used to implement this embodiment. Figure 14 The flowchart (including schematic diagram) shows the first aspect applied to the decoding of matrix-based intra-frame prediction (MIP) flags.

[0031] Figure 25A -B is a diagram showing aspects that can be used to implement this embodiment. Figure 15The flowchart (including schematic diagram) shows the second aspect applied to the decoding of the intra-frame prediction mode index.

[0032] Figure 26A -C is a diagram that illustrates aspects that can be used to implement this embodiment. Figure 15 The flowchart (including the diagram) shows the second aspect applied to the export of the most probable pattern (MPM) list.

[0033] Figure 27 The diagram illustrates aspects that can be used to implement this embodiment. Figure 14 The flowchart (including the schematic diagram) shows the first aspect applied to the decoding of the MIP flag.

[0034] Figure 28 This is a flowchart of an example method for encoding video data, which can be used to implement aspects of this embodiment.

[0035] Figure 29 This is a flowchart of an example method for decoding video data, which can be used to implement aspects of this embodiment. Detailed Implementation

[0036] This paper presents apparatus and methods for encoding and decoding video data. Based on the aspects disclosed herein, enhanced context information is generated, which is used to signal and decode the syntax elements representing video blocks of video data. These aspects can be applied to video codecs (generally referred to herein as one or more video codecs) characterized by adaptive block-level changes in encoding order—such as those concerning… Figure 1-3 This describes a hybrid block-based video coding and decoding system. (References: [link to relevant document]) Figure 4-13 Various methods for designing video codecs with adaptive block-level remapping of coding order are described. This paper references... Figure 14-18 and Figures 28-29 Aspects of generating context information are disclosed. Specifically, context information can be generated based on the encoding order of video blocks in the neighborhood of the video block being encoded (or decoded), while spatially balancing the influence of context information derived from these neighboring video blocks, as referenced herein. Figure 19-27 The applications of these aspects that have been disclosed are demonstrated.

[0037] Figure 1The illustration shows a block diagram of system 100. System 100 can be implemented as a device and can be configured to perform one or more of the aspects described in this application. Examples of such devices include, but are not limited to, various electronic devices such as personal computers, laptop computers, smartphones, tablet computers, digital multimedia set-top boxes, digital television receivers, personal video recording systems, connected home appliances, and servers. The elements of system 100 can be embodied individually or in combination in integrated circuits, multiple integrated circuits, and / or discrete components. For example, in at least one embodiment, the processing 110 and encoder / decoder 130 elements of system 100 are distributed across multiple integrated circuits and / or discrete components. In various embodiments, system 100 is communicatively coupled to other systems or other electronic devices via, for example, a communication bus or through dedicated input and / or output ports.

[0038] System 100 includes at least one processor 110, which can be configured to execute instructions loaded therein for implementing various aspects, such as those described in this application. Processor 110 may include embedded memory, input and output interfaces, and various other circuitry as known in the art. System 100 includes at least one memory 120, such as a volatile memory device and / or a non-volatile memory device. System 100 includes a storage device 140, which may include non-volatile memory and / or volatile memory, such as EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash memory, disk drive, and / or optical disk drive. For example, storage device 140 may be an internal storage device, an auxiliary storage device, and / or a network-accessible storage device.

[0039] System 100 includes an encoder / decoder module 130 configured to process data to provide encoded or decoded video data. The encoder / decoder module 130 may include its own processor and memory. The encoder / decoder module 130 may be implemented as a separate element of system 100 or may be incorporated within processor 110 as a combination of hardware and / or software as known to those skilled in the art. Furthermore, the encoder / decoder module 130 represents one or more modules that can be implemented in a separate device to perform encoding and / or decoding functions.

[0040] Program code to be loaded into processor 110 or encoder / decoder 130 to execute the various aspects described herein may be stored in storage device 140 and subsequently loaded into memory 120 for execution by processor 110. According to various embodiments, one or more of processor 110, memory 120, storage device 140, and encoder / decoder module 130 may store one or more of various items during execution of the processes described herein. Such stored items may include, but are not limited to, input video, decoded video or portions of decoded video, bitstreams, matrices, variables, operational logic, and intermediate or final results from equations, formulas, and operations.

[0041] In several embodiments, the memory within processor 110 and / or encoder / decoder module 130 is used to store instructions and provide working memory for processing functions required during encoding or decoding. However, in other embodiments, external memory (where, for example, the processing device may be processor 110 or encoder / decoder module 130) may be used for one or more of these functions. External memory may be memory 120 and / or storage device 140, which may include, for example, dynamically volatile memory and / or non-volatile flash memory. In several embodiments, external non-volatile flash memory is used to store the television's operating system. In at least one embodiment, fast external dynamically volatile memory, such as RAM, is used as working memory for video encoding and decoding operations.

[0042] As indicated in block 105, inputs can be provided to the components of system 100 through various input devices. Such input devices include, but are not limited to, (i) an RF section that receives, for example, RF signals transmitted over the air by a broadcaster, (ii) a composite input terminal (COMP), (iii) a USB input terminal, and / or (iv) an HDMI input terminal.

[0043] In various embodiments, the input device of block 105 has associated respective input processing elements as known in the art. For example, the RF section may be associated with elements suitable for: (i) selecting a desired frequency (also known as selecting a signal, or limiting the signal band to a band), (ii) down-converting the selected signal, (iii) further band-limiting to a narrower band to select a signal band that may be referred to as a channel in some embodiments, (iv) demodulating the down-converted and band-limited signal, (v) performing error correction, and / or (vi) demultiplexing to select a desired data packet stream. The RF section in various embodiments includes one or more elements to perform these functions, such as frequency selectors, signal selectors, band limiters, channel selectors, filters, downconverters, demodulators, error correctors, and demultiplexers. The RF section may include a tuner that performs some of these functions, including, for example, down-converting a received signal to a lower frequency (e.g., intermediate frequency or near-baseband frequency) or baseband. In one set-top box embodiment, the RF section and its associated input processing elements receive RF signals transmitted via a wired (e.g., cable) medium and perform frequency selection by filtering, down-converting, and re-filtering to a desired frequency band. Various embodiments rearrange the order of the above (and other) elements, remove some of these elements, and / or add other elements that perform similar or different functions. Adding elements may include inserting elements between existing elements, such as inserting amplifiers and analog-to-digital converters. In various examples, the RF section includes an antenna.

[0044] Furthermore, the USB and / or HDMI terminals may include their respective interface processors for connecting system 100 to other electronic devices across USB and / or HDMI connections. It should be understood that various aspects of input processing (e.g., Reed Solomon error correction) can be implemented as needed, for example, within a separate input processing integrated circuit or within processor 110. Similarly, various aspects of USB or HDMI interface processing can be implemented as needed, either within a separate interface integrated circuit or within processor 110. Demodulated, error-corrected, and demultiplexed streams are provided to various processing elements, including, for example, processor 110 and encoder / decoder 130, to operate in conjunction with memory and storage elements to process the data streams as needed for presentation on the output device.

[0045] Various components of system 100 can be housed within an integrated housing. Within the integrated housing, various components can be interconnected and transmit data between them using a suitable connection arrangement 115 (e.g., internal buses as known in the art, including I2C buses, wiring, and printed circuit boards).

[0046] System 100 includes a communication interface 150 that enables communication with other devices via a communication channel 190. The communication interface 150 may include, but is not limited to, a transceiver configured to transmit and receive data via the communication channel 190. The communication interface 150 may include, but is not limited to, a modem or network interface card (NIC). The communication channel 190 may be implemented, for example, in a wired and / or wireless medium.

[0047] In various embodiments, data can be streamed to system 100 using a Wi-Fi network such as IEEE 802.11. The Wi-Fi signal in these embodiments is received via a communication channel 190 and a communication interface 150 suitable for Wi-Fi communication. The communication channel 190 in these embodiments is typically connected to an access point or router that provides access to external networks, including the Internet, to allow streaming applications and other over-the-top communications. In other embodiments, data can be streamed to system 100 using a set-top box that delivers data via an HDMI connection to input block 105, and data can also be streamed to system 100 using an RF connection to input block 105.

[0048] System 100 can provide output signals to various output devices, including display device 165, audio device (e.g., one or more speakers) 175, and other peripheral devices 185. In various examples of embodiments, the other peripheral devices 185 include one or more of a standalone DVR, disc player, stereo system, lighting system, and other devices that provide functionality based on the output of system 100. In various embodiments, control signals communicate between system 100 and display device 165, audio device 175, or other peripheral devices 185 using signaling such as AV.link, CEC, or other communication protocols that enable device-to-device control with or without user intervention. Output devices can be communicatively coupled to system 100 via dedicated connections through their respective interfaces 160, 170, and 180. Alternatively, output devices can be connected to system 100 via communication interface 150 using communication channel 190. Display device 165 and audio device 175 can be integrated into a single unit with other components of system 100 in electronic devices (e.g., televisions). In various embodiments, the display interface 160 includes a display driver, such as a timing controller (T Con) chip.

[0049] Alternatively, display device 165 and audio device 175 may be separate from one or more other components, for example, if the RF portion of input 105 is part of a separate set-top box. In various embodiments where display device 165 and audio device 175 are external components, the output signal may be provided via a dedicated output connection, including, for example, an HDMI port, a USB port, or a COMP output.

[0050] Figure 2 The illustration shows a functional block diagram of a video encoder 200. (Reference) Figure 1 The system 100 described may employ a video encoder 200. For example, the video encoder 200 may be an encoder that operates according to encoding standards such as Advanced Video Coding (AVC, H.264 / MPEG-4 | ISO / IEC 14496-10), High Efficiency Video Coding (HEVC, ITU-T H.265 | ISO / IEC 23008-2), or Multifunctional Video Coding (VVC, standard ITU-T H.266, ISO / IEC 23090-3, 2020).

[0051] Before encoding, the video data can be preprocessed by a pre-encoding processor (not shown). Such preprocessing may include applying color model transformations (e.g., a conversion from RGB 4:4:4 to YCbCr 4:2:0) to the color components of the input video frames or mapping the color components of the input video frames to obtain a more compression-resistant signal distribution (e.g., applying a histogram equalizer and / or denoising filter to one or more of the color components of the video frame). Preprocessing may also include associating metadata with video data that can be attached to the encoded video bitstream.

[0052] In encoder 200, video frames are encoded by encoder elements as generally described below. The original video images (frames) to be encoded are partitioned into coding units (i.e., original blocks) by image partitioner 202. Typically, a coding unit (CU) contains a luma block and a corresponding chroma block, and therefore the operations typically described herein for applying to CUs are applied to both the luma and chroma blocks. After partitioning 202, each CU can be encoded using either intra-frame prediction mode or inter-frame prediction mode. In intra-frame prediction mode, CU prediction is performed by intra-frame predictor 260. In intra-frame prediction mode, the content of a CU in a frame is predicted based on the content of one or more other CUs from the same frame, using reconstructed versions of other CUs (obtainable from the output of adder 255). In inter-frame prediction mode, motion estimation and motion compensation are performed by motion estimator 275 and motion compensator 270, respectively. In inter-frame prediction mode, the content of a CU in a frame is predicted based on the content of one or more other CUs from neighboring frames, using reconstructed versions of other CUs (obtainable from reference image buffer 280). For example, the encoder determines which prediction result (obtained through operations in intra-frame prediction mode 260 or inter-frame prediction modes 270, 275) will be used to encode the CU, and indicates the selected prediction mode via a prediction mode flag. The prediction enhancer 285 can then enhance (e.g., filter) the selected prediction result to output the corresponding prediction block. Once a prediction block has been generated for each CU, the corresponding residual block is computed, for example, by subtracting the predicted CU (i.e., the prediction block) from the original CU (i.e., the original block).

[0053] The corresponding residual block or its partition (i.e., transform block) of the CU is then transformed into a coefficient block by transformer 220, that is, the residual samples of the transform block are transformed into the transform coefficients of the coefficient block. Quantizer 230 quantizes the resulting coefficient block. Next, entropy encoder 245 entropy-encodes the quantized coefficient block and the corresponding encoding parameters (e.g., syntax elements including motion vectors and other control data). Therefore, the entropy-encoded quantized coefficient block and the corresponding encoding parameters associated with each video frame of the original video are packaged into the bitstream of encoded video data.

[0054] As described above, encoder 200 reconstructs the encoded original block along with the original video block to provide a reference for future prediction. Therefore, the quantized coefficient block (provided by quantizer 230) is dequantized by inverse quantizer 240 and then inverse transformed by inverse transformer 250 to reconstruct (decode) the residual block of the corresponding original block. Adding the reconstructed residual block 255 to the corresponding prediction block yields the corresponding reconstructed original block. Then, an in-loop filter 265 can be applied to the reconstructed image (formed from the reconstructed original block) to perform, for example, deblocking filtering and / or Sample Adaptive Offset (SAO) filtering to reduce coding artifacts. The filtered reconstructed image can then be stored in reference image buffer 280 for future prediction in inter-frame prediction mode. Therefore, encoder 200 also performs decoding operations 240, 250 on the image (frame) reconstructed therethrough. As explained above, the reconstructed image can then be stored in reference image buffer 280 and used to facilitate motion estimation 275 and compensation 270.

[0055] Figure 3 The illustration shows a functional block diagram of a video decoder 300. (Reference) Figure 1 The described system 100 may employ a video decoder 300. Typically, the operational aspects of the video decoder 300 are inverses of those of the video encoder 200. In the decoder 300, the bitstream of encoded video data generated by the video encoder 200 is first entropy-decoded by an entropy decoder 330, thereby decoding quantized coefficient blocks and various coding parameters from the bitstream. The quantized coefficient blocks are dequantized by an inverse quantizer 340 and then inverse-transformed by an inverse transformer 350 to decode (reconstruct) the corresponding residual blocks. Adding the reconstructed residual blocks 355 to the corresponding prediction blocks yields the corresponding reconstructed original blocks. Depending on the selected prediction mode, the predicted original blocks can be obtained from an intra-frame predictor 360 or from a motion compensator 375, and can then be enhanced (e.g., filtered) by a prediction enhancer 390 to generate prediction blocks. An intra-loop filter 365 can be applied to the reconstructed picture (formed from the reconstructed original blocks) to output the reconstructed (decoded) video frame. The filtered and reconstructed image is also stored in the reference image buffer 380 for motion compensation 375.

[0056] A post-decoding processor (not shown) can further process the reconstructed video. For example, post-decoding processing may include inverse color model transformation (e.g., a conversion from YCbCr 4:2:0 to RGB 4:4:4) or inverse mapping to reverse the mapping process performed by the pre-encoding processor. The post-decoding processor may use metadata derived by the pre-encoding processor and / or signaled in the video bitstream.

[0057] The video blocks (i.e., blocks) of the reference video frame describe the aspects disclosed herein. However, the described aspects are similarly applicable to any region of the video frame to which the encoder 200 or decoder 300 may apply encoding tools. In general, the aspects described herein can be applied to video data regions formed by video partitions of any shape or size. A video region may be a coding tree unit (CTU) or CU (to which inter-frame prediction or intra-frame prediction may be applied) or a partition thereof, including luminance components. Y and chromaticity components Cr and Cb .

[0058] This paper discloses a technique for generating enhanced contextual information applicable to video codecs characterized by adaptive block-level changes in coding order. This paper references... Figure 4-8 Various methods are described for designing video codecs with adaptive block-level remapping coding order built on top of the High Efficiency Video Coding (HEVC) standard. See below for further details. Figure 9-13 Additional methods for designing video codecs with adaptive block-level changing horizontal coding order implemented in the Basic Video Coding (EVC) standard are described. Note that, for simplicity, only the luminance components of video blocks are mentioned and / or illustrated only in figures herein; however, the aspects described herein are similarly applicable to the chrominance components of video blocks. Also note that the availability of CUs is generally referred to herein as the availability of coded data (e.g., coding parameters) representing the CUs.

[0059] Adaptive block-level changes to the coding order, primarily developed on top of the HEVC standard, can be categorized into two types. In the first type, all CUs in the CTU share the same coding order. Therefore, for a given CTU, the encoder tests several coding orders, and the coding order that produces the minimum rate-distortion cost is selected and signaled to the decoder (see A. Zheng et al., Adaptive Block Coding Order for Intra-Frame Prediction in HEVC, IEEE Transactions on Video Technology Circuits and Systems, Vol. 26, No. 11, November 2016, hereinafter referred to as “Zheng-1”; and A. Zheng et al., Intra-Frame Prediction with Adaptive CU Processing Order in HEVC, IEEE International Conference on Image Processing, 2014, hereinafter referred to as “Zheng-2”). In the second category, for a given CTU or CU to be segmented, the encoder tests several orders for scanning the sub-blocks resulting from this segmentation and selects the order that provides the minimum rate-distortion cost, signaling this to the decoder (see L. Guo et al., Flexible Block Ordering Based on Hierarchical Quadtree in HEVC Intra-Coding, Visual Communications and Image Processing, 2016, hereinafter referred to as "Guo"). Compared to the first category (where the coding order is determined at the CTU level, i.e., all CUs in the CTU are required to follow the same coding order), the second category (where the coding order is determined at each segmentation of the CTU or CU) offers more flexibility in changing the coding order. The two categories of adaptive block-level changes in coding order are further described below.

[0060] Figure 4 This is a schematic diagram 400 illustrating four encoding orders that can be used to encode blocks (e.g., CUs) of a CTU. In (a), the encoding order is from top to bottom and from left to right (as in HEVC); in (b), the encoding order is from bottom to top and from left to right; in (c), the encoding order is from bottom to top and from right to left; and in (d), the encoding order is from top to bottom and from right to left. The CUs in each of these encoding orders are numbered according to the encoding order, and gray dashed arrows indicate sequential encoding paths (only a few CUs in the first CU of the CTU are shown). In the first category, the encoding order is determined at the CTU level, and the determined encoding order is signaled for each CTU. Therefore, on the encoder side, for a given CTU in the current encoded frame (i.e., the current frame), these four encoding orders are tested for all CUs of the CTU, and the encoder uses the encoding order that yields the minimum rate-distortion cost and signals it to the decoder (e.g., via fixed-length codes).

[0061] Changing the encoding order at the CTU level can be achieved by a video codec that follows the HEVC standard. On the encoder side, if it is desired to use a CU that differs from what is defined in the HEVC standard (i.e., ...), Figure 4 If the original CTU is encoded according to the encoding order (a) in the above sequence, then firstly, the original CTU and its reference sample are flipped so that the encoding order of the CUs in the flipped CTU is consistent with that in sequence (a) (see Zheng-1). Next, the flipped CTU can be encoded using an unmodified HEVC encoding tool. After reconstruction, the reconstructed flipped CTU can be flipped back to obtain the reconstructed original CTU. On the decoder side, a similar flipping strategy can be applied to the CTU to be decoded when the encoding order used is different from the encoding order defined in the HEVC standard.

[0062] Figure 5 This is a schematic diagram 500 showing the flipping of the CTU. In Figure 5 In the example, if the original CTU is to be encoded using a bottom-to-top and right-to-left encoding order for its CU, the original CTU and its reference sample are flipped relative to the horizontal axis and then flipped relative to the vertical axis to obtain a flipped CTU whose CU is in accordance with the encoding order defined in the HEVC standard (i.e., Figure 4 The same order in (a) is sorted, such as Figure 5 The left-hand portion is shown. Note that in the original CTU and its flipped version, the CUs are numbered according to their encoding order. For example, before and after the flip, the fourth encoded CU (i.e., CU=3) and its available reference samples are shown in... Figure 5 On the right side.

[0063] When the encoding order is determined at the segmentation level, the determined encoding order is signaled at each segmentation of the CTU or CU. As described in Guo, several orders can be used to scan the sub-blocks derived from the segmentation. Figure 6 As illustrated, given a CTU or CU specifically partitioned via a quadtree (QT), Guo proposed eight different orders for scanning the four sub-blocks derived from the partition.

[0064] Figure 6 This is a schematic diagram 600 illustrating the scan order of the segmented sub-blocks. Therefore, at the encoder end, for a given CTU or CU to be segmented via QT segmentation, the scan order of the resulting four sub-blocks must be determined. For this purpose, encoder testing... Figure 6The example shows eight scan orders, and the order that produces the minimum rate-distortion cost is preserved and signaled to the decoder (e.g., via fixed-length code). In the HEVC standard, when this adaptive change in coding (or scanning) order is used, if an 8×8 CU is divided into 4 prediction units (PUs), the order in which these PUs are scanned is inherited from the coding order of the parent 8×8 CU. Similarly, if the residual of the CU is divided into 4 transform units (TUs), the order in which these TUs are scanned is the same as the coding order of the parent CU.

[0065] Changing the encoding order at the CTU or CU segmentation level can be achieved by a video codec conforming to the HEVC standard. On the encoder side, for a given original CU, if the relative positioning of the original CU and its reference sample does not match in HEVC, Guo proposed a method for reusing the HEVC intra-prediction mechanism during intra-frame prediction of the original block in this original CU. Specifically, both the original block and its reference sample are rotated or flipped such that the relative positioning of the rotated or flipped original block and its rotated or flipped reference sample matches that defined in the HEVC standard. The rotated or flipped original block can then be predicted via an unmodified HEVC intra-frame prediction tool. The predicted block is then rotated or flipped back, resulting in a predicted block corresponding to the predicted original block. On the decoder side, a similar rotation or flip strategy can be applied to the original CU when the relative positioning of the block and its reference sample in the original CU does not match that defined in the HEVC standard.

[0066] Figure 7 This is a schematic diagram 700 showing the flipping of the illustrated block and its reference sample. For the original CTU currently being encoded, the original luma blocks are numbered according to the encoding order (see...). Figure 7 The top left portion). The original luma blocks numbered 0 to 8 (represented in dark gray) have been reconstructed. However, the original luma blocks numbered 9 to 21 (represented in white) have not yet been encoded. The next original luma block to be predicted and its reference sample (see...) Figure 7 The lower left portion is flipped relative to the vertical axis to obtain the flipped original luminance block and its flipped reference sample, whose relative positioning matches that defined in the HEVC standard (see [link to HEVC standard]). Figure 7 (The lower right part).

[0067] Figure 8 This is a schematic diagram 800 showing the rotation of the illustrated block and its reference sample. For the original CTU currently being encoded, its original luma blocks are numbered according to the encoding order (see...). Figure 8The top left portion). The original luma blocks numbered 0 to 8 (represented in dark gray) have been reconstructed. However, the original luma blocks numbered 9 to 21 (represented in white) have not yet been encoded. The next original luma block to be predicted and its reference sample (see...) Figure 8 The lower left portion is rotated 90 degrees clockwise to obtain the rotated original luminance block and its rotated reference sample, whose relative positioning matches that defined in the HEVC standard (see [link to HEVC standard]). Figure 8 (The lower right part).

[0068] Unlike the methods described in Zhang-1 and Zhang-2, the method described in Guo is not limited to reusing the HEVC encoding mechanism (as mentioned above). Figure 5 and Figure 7 (As stated above). In fact, Guo utilizes a new arrangement of available reference samples that may appear around the current block to be predicted, based on the history of changes and segmentations that led to the current block's encoding order. More precisely, for the current block to be predicted, after a potential rotation / flip of this block and its reference samples, if reference samples below or to the right of the rotated / flipped current block are available, such as... Figure 8 As shown, the intra-prediction of the rotated / flipped current block becomes bilinear whenever possible. Otherwise (when no reference samples are available below and to the right of the rotated / flipped current block), the unchanged HEVC intra-prediction is used. Another approach similar to Guo's method also involves adaptively changing the coding order (see I. Matsuda et al., Interpolation Intra-prediction by Adapting Processing Order in Block-Based Image Coding, IEEE International Conference on Image Processing, 2013, hereinafter referred to as "Matsuda"). Although the intra-prediction proposed by Matsuda utilizes a new arrangement of available reference samples that may appear around the current block to be predicted, Matsuda, which also tends to perform bilinear intra-prediction whenever possible, differs slightly from the method described by Guo.

[0069] Next reference Figure 9-13 Describes adaptive block-level changes in the horizontal coding order, as implemented in the EVC standard.

[0070] In the EVC standard, the coding order for a given segment is signaled via a process called Segmentation Unit Coding Order (SUCO). Specifically, for a given frame, during the partitioning of a given CTU, if a CU is segmented via a vertical segmentation, the SUCO flag is signaled to indicate the horizontal order of the CUs originating from this segment for coding (or scanning), i.e., from left to right or from right to left. Since the EVC standard (as in the Multi-Function Video Coding (VVC) standard) defines three segmentation families—Quadtree (QT), Binary Tree (BT), and Tritree (TT)—vertical segmentation is defined as vertical BT (BT_V) or vertical TT (TT_V) or QT, as follows. Figure 9 As shown in the diagram.

[0071] Figure 9 This is a schematic diagram of the horizontal coding order, number 900. Figure 9 This demonstrates the order (from left to right or from right to left) used to encode child CUs resulting from three possible vertical partitions of a given parent CU. For example... Figure 9 As shown in the left-hand portion, a given parent CU has a size represented by W×H. The vertical partitioning of this parent CU can be based on a vertical binary tree (denoted as BT_V), a vertical ternary tree (denoted as TT_V), or a quadtree (denoted as QT). Similarly, in the EVC standard, the parent CU can be partitioned based on a horizontal binary tree (BT_H) or a horizontal ternary tree (TT_H). Note that although in the EVC standard or related literature (see Y. Piao et al., Encoding Order of Partition Units for Video Coding, IEEE Multimedia and Expo International Conference, 2021, hereinafter referred to as "Piao"), the given unit to be partitioned is called a partition unit (SU), but the SU is equivalent to the CU in the VVC standard. Also note that the SUCO process is characterized by a parameterized minimum CU size. This means that if the partitioning of the parent CU produces child CUs with sizes smaller than the minimum CU size of the SUCO, the encoding order for these child CUs is not signaled, but rather inherited from the encoding order of their parent CU, as described in Piao.

[0072] At the EVC encoder, full rate-distortion optimization is applied to the SUCO process. Specifically, in a given CTU, for a given CU to be segmented via vertical segmentation (if the size of the CU offspring derived from the segmentation is not less than the SUCO minimum CU size), the left-to-right and right-to-left order for encoding its offspring is tested, and the order that produces the minimum rate-distortion cost is maintained and signaled to the decoder. Thus, SUCO can be viewed as Guo's perspective on a specialization of video codecs characterized by QT, BT, and TT segmentation families, where only horizontal (left-to-right or right-to-left) encoding orders are allowed.

[0073] Video codecs use CABAC to context-encode syntax elements, taking into account their respective probability distributions. CABAC can also be used for context-encoding of the SUCO flag. When a given CU is segmented via vertical segmentation, the encoder signals the SUCO flag to indicate to the decoder the order in which the CUs derived from the segment are encoded (i.e., from left to right or from right to left). However, many other conditions, besides the SUCO condition for minimum CU size, can eliminate the need for signaling the SUCO flag for the CUs. When signaling is used, the SUCO flag can be context-encoded using CABAC. Figure 10 The decoding of the SUCO flag, which is signaled and associated with a CU to be potentially segmented, is demonstrated using the ETM-7 decoder (i.e., the current version of the software model of the EVC standard).

[0074] Figure 10 This is a flowchart of an example method for decoding the SUCO flag. Figure 10 The diagram illustrates the decoding of the SUCO flag for a given CU to be potentially segmented at the ETM-7 decoder. The following variables are defined as follows.

[0075] • widthCU×heightCU represents the size of the CU.

[0076] • splitMode indicates the type of split applied to the CU, i.e., splitMode∈{NO_SPLIT, BT_H,BT_V, TT_H, TT_V, QT}, where NO_SPLIT indicates no split.

[0077] • isBoundary is a flag that is set to true if the CU overlaps with the boundary of the current frame.

[0078] • sucoFlag indicates the SUCO flag associated with CU.

[0079] • sucoFlagParent represents the SUCO flag associated with the parent CU of the CU.

[0080] • decodeBin is a function call that reads the current binary symbol (bin) using the input CABAC context index.

[0081] • idxCtxSucoFlag represents the index whose increment generates the context index for the CABAC used to decode the SUCO flag. In ETM-7, idxCtxSucoFlag = 513.

[0082] • log2MaxCuwh is a sequence parameter set (SPS) parameter that represents the logarithm of the maximum CU luminance height / width (base 2). (The default value is 7 in the ETM-7 encoding configuration.)

[0083] • log2DiffCtuSizeMaxSucoCbSize is the SPS parameter representing the difference between the base-2 logarithm of the maximum CU luminance height / width and the base-2 logarithm of the maximum CU luminance height / width with SUCO applied (set to a default value of 1 in the ETM-7 encoding configuration).

[0084] • log2DiffMaxSucoMinSucoCbSize is the SPS parameter representing the difference between log2MaxCuwh-log2DiffCtuSizeMaxSucoCbSize and the base-2 logarithm of the minimum luminance height / width of the CU with SUCO applied (the default value is 2 in the ETM-7 encoding configuration).

[0085] • log2minCuSize is the SPS parameter, which is the base-2 logarithm of the minimum CU luminance height / width (the default value is 2 in the ETM-7 encoding configuration).

[0086] • sucoLog2Maxsize=min(log2MaxCuwh-log2DiffCtuSizeMaxSucoCbSize,6).

[0087] • isSmallerSucoMin=min(widthCU,heightCU)<(1≪max(sucoLog2Maxsize-log2DiffMaxSucoMinSucoCbSize,max(4,log2minCuSize))).

[0088] • isLargerSucoMax=max(widthCU,heightCU)>(1≪sucoLog2Maxsize).

[0089] • inNoSplitHor=splitMode==NO_SPLIT || splitMode ==BT_H || splitMode ==TT_H.

[0090] • isQtCond =splitMode != QT&&widthCU ≤ heightCU.

[0091] refer to Figure 10At point 1000, for a given CU to be potentially segmented, decoding of the SUCO flag is triggered. At point 1001, a condition is determined based on the size of the CU, whether the CU overlaps with the boundary of the current frame, and the type of segmentation associated with the CU, to determine whether to proceed to point 1002 or 1003. If the condition at point 1001 is true, then at point 1002, the SUCO flag of the CU is not read from the bitstream, but is inherited from the SUCO flag of the parent CU of the given CU. If the condition at point 1001 is false, then the SUCO flag of this CU is read from the bitstream. To this end, at point 1003, the increment idxCtx of the CABAC context index used to decode the SUCO flag is derived based on the size of the CU. At point 1004, the SUCO flag of the CU is read from the bitstream using the CABAC context index idxCtxSucoFlag+idxCtx.

[0092] You can also use signals to notify the type of split (i.e., splitMode) associated with the CU that is to be potentially split. Figure 11A -B demonstrates the decoding of the segmentation type indicated by the signal by the ETM-7 decoder.

[0093] Figure 11A -B is a flowchart of an example method for decoding the segment type. Figure 11A The -B diagram illustrates the decoding of the segmentation type for a given CU to be potentially segmented at the ETM-7 decoder. The following variables are defined as follows.

[0094] • widthCU×heightCU represents the size of the CU.

[0095] • splitMode indicates the type of split in the CU. Assuming "sps_btt_flag" equals 1 (i.e., BT and TT are used), splitMode ∈ {NO_SPLIT, BT_H, BT_V, TT_H, TT_V}, where NO_SPLIT indicates no split.

[0096] • `checkSplitMode` is a function call that sets the `splitAllow` array based on `widthCU`, `heightCU`, and whether this `CU` overlaps with the boundary of the current frame. Here, `splitAllow[` i ], i ∈{NO_SPLIT, BT_H, BT_V, TT_H, TT_V}. The splitAllow array indicates whether splitting is allowed. i The type.

[0097] • smaller[0] is a flag that is set to true if a CU above a given CU is available and its width is strictly less than widthCU.

[0098] • smaller[1] is a flag that is set to true if the CU to the left of a given CU is available and its height is strictly smaller than heightCU.

[0099] • smaller[2] is a flag that is set to true if the CU to the right of a given CU is available and its height is strictly smaller than heightCU.

[0100] • decodeBin is a function call that reads the current binary symbol using the input CABAC context index.

[0101] • The variables idxCtxBttSplitFlagi, dxCtxBttSplitDir, and idxCtxBttSplitType each represent different indices in which their increments are generated to decode the CABAC context indexes for the BttSplitFlag, BttSplitDir, and BttSplitType flags, respectively.

[0102] refer to Figure 11A At 1100, for a given CU to be potentially split, decoding of its associated split type is triggered. At 1101, if widthCU and heightCU are strictly less than 8, the process proceeds to 1102. Otherwise, the process proceeds to 1103. At 1102, the split type of the CU is set to NO_SPLIT. At 1103, the splitAllow array is determined based on widthCU and heightCU. The array element splitAllow[ i ](for iThe variable ∈{NO_SPLIT, BT_H, BT_V, TT_H,TT_V} indicates whether the corresponding split type is allowed. At 1104, if at least one of splitAllow[BT_H], splitAllow[BT_V], splitAllow[TT_H], and splitAllow[TT_V] is true, the process proceeds to 1105. Otherwise, the process proceeds to 1102. At 1105, based on the widthCU, heightCU, and the size of the nearest available CU, the increment idxCtx of the CABAC context index used to decode the flag at 1106 is calculated. At 1106, the flag bttSplitFlag is read from the bitstream using the CABAC context index idxCtxBttSplitFlag + idxCtx. At 1107, if bttSplitFlag is true, the process proceeds to 1108 (in...). Figure 11B (Middle). Otherwise, the process proceeds to step 1102.

[0103] refer to Figure 11BAt 1108, if both vertical and horizontal splits are allowed within the split families BT and TT, the process proceeds to 1110. Otherwise, the process proceeds to 1109. At 1109, the flag bttSplitDir is inferred from splitAllow. At 1110, the increment idxCtx of the CABAC context index used for decoding the flag at 1111 is derived based on widthCU and heightCU. At 1111, the flag bttSplitDir is read from the bitstream using the CABAC context index idxCtxBttSplitDir + idxCtx. The process proceeds to 1112 from either 1109 or 1111. At 1112, if at least one of the two conditions (i.e., `bttSplitDir && splitAllow[BT_V] && splitAllow[TT_V]` and `bttSplitDir && splitAllow[BT_H] && splitAllow[TT_H]`) is true, the process moves to 1114. Otherwise, the process proceeds to 1113. In the first condition, `bttSplitDir` = 1 (i.e., the split type is vertical within split families BT and TT), and both `BT_V` and `TT_V` are allowed. In the second condition, `bttSplitDir` = 0 (i.e., the split type is horizontal within split families BT and TT), and both `BT_H` and `TT_H` are allowed. At 1113, the flag `bttSplitType` is inferred based on `bttSplitDir` and `splitAllow`. At 1114, the flag `bttSplitType` is read from the bitstream using the CABAC context index `idxCtxBttSplitType`. The process proceeds from 1113 or 1114 to 1115. At 1115, if `bttSplitType` is true, the process proceeds to 1117. Otherwise, it proceeds to 1116. At 1116, within the split BT family, `splitMode` is defined based on `bttSplitDir`. At 1117, within the split TT family, `splitMode` is defined based on `bttSplitDir`.

[0104] A unified process can be used to signal the flags of the coding mode associated with the CU. Figure 12 This signaling indicates the encoding mode flag (i.e., modeFlag) given to the CU at the ETM-7 decoder.

[0105] Figure 12 This is a flowchart of an example method for decoding encoding mode flags. Figure 12The diagram illustrates the unified process for decoding the mode flag of a given CU at the ETM-7 decoder. The following variables are defined as follows.

[0106] • modeFlag represents the encoding mode flag of the CU.

[0107] • nevInfo[0] is a flag that is set to true if the CU above the given CU is available and the modeFlag of the "above" CU is set to 1.

[0108] • nevInfo[1] is a flag that is set to true if the CU to the left of a given CU is available and the modeFlag of the “left” CU is set to 1.

[0109] • nevInfo[2] is a flag that is set to true if the CU to the right of a given CU is available and the modeFlag of the “right” CU is equal to 1.

[0110] • sps_cm_init_flag is a flag that is set to true if the CABAC context model has been initialized.

[0111] • idxCtxBase represents the index used to generate the CABAC context index for decoding modeFlag. The value of idxCtxBase depends on the semantics of the mode flag.

[0112] • limit is the maximum increment value idxCtx of the CABAC context index used to decode modeFlag.

[0113] • decodeBin is a function call that reads the current binary symbol using the input CABAC context index.

[0114] refer to Figure 12 At 1200, for a given CU, decoding of the encoding mode flag `modeFlag` is triggered. At 1201, `nevInfo` is defined based on the `modeFlag` of each of the three neighboring CUs. From 1202 to 1204 or 1205, the increment `idxCtx` of the CABAC context index used to decode `modeFlag` at 1206 is calculated based on `nevInfo`. At 1206, the `modeFlag` of the CU is read from the bitstream using the CABAC context index `idxCtxBase + idxCtx`.

[0115] For example (from) Figure 12 (Exported) Figure 13As illustrated, a unified process can be used to signal and decode the intra-block copy (IBC) flag for a given CU. In this case, it is assumed that the skip flag for this given CU has been decoded, and that the decoded skip flag indicates that the prediction mode is not skip mode. Furthermore, it is assumed that a flag indicating whether this given CU is predicted in intra-frame prediction mode or inter-frame prediction mode has been decoded, and that the decoded flag indicates that intra-frame prediction mode was used to predict this given CU.

[0116] Figure 13 This is a flowchart of an example method for decoding IBC flags. Figure 13 The diagram illustrates the decoding of the IBC flag (i.e., ibcFlag) of a given CU at the ETM-7 decoder. The following variables are defined as follows.

[0117] • ibcFlag represents the IBC flag of CU.

[0118] • nevInfo[0] is a flag that is set to 1 if the CU above the given CU is available and the ibcFlag of the "above" CU is set to 1.

[0119] • nevInfo[1] is a flag that is set to 1 if the CU to the left of a given CU is available and the ibcFlag of the “left” CU is set to 1.

[0120] • nevInfo[2] is a flag that is set to 1 if the CU to the right of a given CU is available and the ibcFlag of the “right” CU is set to 1.

[0121] • sps_cm_init_flag is a flag that is set to 1 if the CABAC context model has been initialized.

[0122] • isIbcAllowed is a flag that is set to true if, given some available information, IBC is allowed to be used with CU.

[0123] • idxCtxIbcFlag represents the index that its incremental generation produces for decoding the CABAC context index of ibcFlag.

[0124] • decodeBin is a function call that reads the current binary symbol using the input CABAC context index.

[0125] In addition to the conditions added in step 1306, Figure 13 The steps are similar to Figure 12 The steps. Therefore, as... Figure 13The illustrated process can be seen from Figure 12 The unified process illustrated also derives from this process; for a given CU, the decoding of the skip flag, prediction mode flag, and affine flag can also be expressed via a specialization of this unified process. Note that at the ETM-7 decoder, for a given CU, the collection of the CABAC context index used to signal the IBC flag (i.e., in...) Figure 13 The collection of CABAC context indexes (from 1301 to 1304 or 1305) and the signaling of the skip flag, prediction mode flag, and affine flag can be performed simultaneously. Then, each of these flags (i.e., IBC flag, skip flag, prediction mode flag, and affine flag) can be decoded if needed.

[0126] As shown above, the context information generated according to the EVC standard ignores local coding order. In EVC, when a syntax element is signaled to be associated with the coding of a given CU, there is no link between the context information derived from neighboring CUs (e.g., the CABAC context index used to compute the syntax element) and the coding order of these CUs. However, depending on the semantics of the syntax element signaled, such a link may be crucial for coding efficiency. For example, in Figures 11-13, the information of interest is extracted from the neighboring CUs of a given CU (i.e., the "above," "left," and "right" CUs), if they are available; and none of these neighboring CUs are prioritized based on their coding order or otherwise. Specifically, in Figure 13 In this context, for a given CU, the IBC flag is the CABAC context index (i.e., idxCtxIbcFlag The increment of ) idxInt Depending on the nevInfo[0], nevInfo[1] and nevInfo[2] derived at 1302, it means that it is important to select only the local frequency of the IBC flag, regardless of the local coding order.

[0127] Furthermore, the generation of context information according to the EVC standard can be unbalanced. In EVC, when grammar elements are signaled (e.g., IBC flags, skip flags, or affine flags), the same information is selected from the "above" CU (if available), the "left" CU (if available), and the "right" CU (if available) and merged indiscriminately to create the CABAC context index of the grammar element. Therefore, in some cases, the "left" CU and the "right" CU (i.e., the horizontally adjacent CUs) dominate the created CABAC context index. Depending on the semantics of the grammar element to be signaled, this lack of balance between the horizontally adjacent CUs and the "above" CU can degrade coding efficiency.

[0128] The aspects disclosed herein address the aforementioned drawbacks of EVC by considering the local encoding order when extracting context information from neighboring CUs and / or by spatially balancing the influence of context information derived from neighboring CUs. For example, for a given type of context information (e.g., whether a certain encoding parameter is used to encode neighboring CUs), spatial balancing can prevent context information derived from a first group of CUs located at corresponding spatial locations from dominating the same type of context information derived from a second group of CUs located at other corresponding spatial locations; the first group may include neighboring CUs positioned horizontally relative to the given CU to be encoded (e.g., to the left and right of the CU), and the second group may include neighboring CUs positioned vertically relative to the given CU (e.g., above and below the CU).

[0129] Therefore, this article references Figure 14-18 Aspects of generating context information are presented, which is used to encode or decode syntax elements associated with a given CU (i.e., the current CU) being encoded or decoded. In these aspects, for the current CU (i.e., the current block), the encoding order of neighboring CUs (i.e., neighboring blocks) from which context information is derived can be considered; and the influence of context information derived from different neighboring CUs can be balanced. Different combinations of these aspects can be applied in various variants.

[0130] In the first aspect, context information is generated as follows. First, the encoding order of blocks in the neighborhood of the current block (the so-called local encoding order) is extracted, and then these blocks are prioritized based on their availability, balance requirements, the extracted encoding order, other factors, or combinations thereof. The local encoding order may include orders such as left-to-right, right-to-left, top-to-bottom, and / or bottom-to-top. Second, optionally, based on the local encoding order, signaling-related context information for syntax elements can be derived from all prioritized blocks or subsets thereof. Depending on various aspects, prioritization of neighboring blocks is performed to balance the impact of context information derived from neighboring blocks located in different spatial regions relative to the current CU.

[0131] Figure 14 This is a flowchart illustrating the first aspect of decoding grammatical elements. Figure 14In the example, at 1400, decoding of a syntax element (e.g., a flag) can be triggered. At 1401, encoding order information `infOrderCoding`, reflecting the encoding order of blocks in the region of the current block (i.e., neighboring blocks), can be extracted. At 1402, for each neighboring block, the following internal process can be applied: Based on block availability and balancing requirements, the extracted encoding order, other factors, or a combination thereof, it is determined whether to add the block to the list of related blocks (the `accessedBlocks` array) (or reference the block therein). At 1403, optionally, based on the encoding order, the encoded data of blocks stored in (or referenced by) the `accessedBlocks` array can be used to calculate context information `infCtx` related to the decoding of the syntax element. At 1404, the calculated `infCtx` can be used to decode the syntax element.

[0132] In the second aspect, context information is generated as follows. First, the local coding order of blocks in the neighborhood of the current block is extracted. Then, optionally, based on the local coding order, neighboring blocks are traversed, and for each block, a decision is made on whether to derive signaling-related context information from the block based on block availability, balance requirements, the extracted coding order, other factors, or combinations thereof.

[0133] Figure 15 This is a flowchart illustrating the second aspect of decoding grammatical elements. Figure 15 In the example, at 1500, decoding of a syntax element (e.g., a flag) can be triggered. At 1501, information representing the encoding order in the region of the current block (i.e., neighboring blocks), infOrderCoding, can be extracted. At 1502, optionally, neighboring blocks are traversed according to the extracted encoding order; for each neighboring block, the following internal process can be applied. Based on block availability and based on balance requirements, the extracted encoding order, other factors, or a combination thereof, it can be determined whether context information related to decoding the syntax element should be derived from the encoded data of this block. The derived context information is collected in infCtx. At 1503, the computed infCtx can be used to decode the syntax element.

[0134] Figure 16 This is a flowchart illustrating a variation of the first aspect of decoding grammatical elements, showing how the order of steps describing the first aspect can be changed. Figure 16In the example, blocks in the region can be prioritized before the encoding order of blocks in the current block is extracted. Therefore, at 1600, decoding of syntax elements (e.g., flags) can be triggered. At 1601, for each neighboring block, the following internal process can be applied: Based on the block's availability and based on balancing requirements, other factors, or a combination thereof, a decision is made as to whether to add the block to the associated block list (accessedBlocks array) (or reference the block therein). At 1602, information reflecting the encoding order of neighboring blocks, infOrderCoding, can be extracted. At 1603, based on the encoding order, the encoded data of blocks stored in (or referenced by) the accessedBlocks array can be used to calculate the context information infCtx related to the decoding of the syntax element. At 1604, the calculated infCtx can be used to decode the syntax element.

[0135] In the third aspect, for example, such as Figure 17 As illustrated, the process of extracting the local encoding order or prioritizing neighboring blocks can be omitted.

[0136] Figure 17 This is a flowchart illustrating the third aspect of decoding syntax elements. Figure 17 This demonstrates the case where the extraction of the local encoding order is not performed. At 1700, decoding of syntax elements (e.g., flags) can be triggered. At 1701, for each neighboring block, the following internal process can be applied. Based on the block's availability and based on balance requirements and / or other factors, it is decided whether to add the block to the list of related blocks (the `accessedBlocks` array) (or reference the block therein). At 1702, the encoded data of blocks stored in (or referenced by) the `accessedBlocks` array can be used to calculate the context information `infCtx` related to the decoding of the syntax element. At 1703, the calculated `infCtx` can be used to decode the syntax element.

[0137] In the fourth aspect, before potentially using the local coding order to generate contextual information, the relevance of the local coding order is evaluated (e.g., regarding...). Figure 14 and Figure 15 (As described). For example, the local coding order may have a predetermined pattern (where all or most neighboring blocks are associated with that pattern), in which case the local coding order is determined to be relevant. The predetermined pattern may be, for example, a uniform pattern (e.g., a left-to-right order).

[0138] Figure 18This is a flowchart illustrating the fourth aspect of decoding grammatical elements. Figure 18 In the example, at 1800, decoding of a syntax element (e.g., a flag) can be triggered. At 1801, information infOrderCoding, representing the encoding order of blocks in the region representing the current block (i.e., neighboring blocks), can be extracted. At 1802, if the extracted encoding order is considered relevant to subsequent steps, the process proceeds to step 1803. Otherwise, the process proceeds to step 1805. At 1803, for each neighboring block, the following internal process can be applied. Based on block availability and based on balance requirements, the extracted encoding order, other factors, or a combination thereof, it is determined whether to add the block to the list of related blocks (the accessedBlocks array) (or reference the block therein). Then, at 1804, optionally, based on the encoding order, the encoded data of blocks stored in (or referenced by) the accessedBlocks array can be used to calculate the context information infCtx related to the decoding of the syntax element. Alternatively, at 1805, for each neighboring block, the following internal process can be applied. Based on the availability of the block and based on balancing requirements and / or other factors, a decision is made as to whether to add the block to the relevant block list (the `accessedBlocks` array) (or reference the block therein). Then, at 1806, the encoded data of the blocks stored in (or referenced by) the `accessedBlocks` array can be used to calculate the context information `infCtx` related to the decoding of the syntax element. The process proceeds from 1804 or 1806 to 1807. At 1807, the calculated `infCtx` can be used to decode the syntax element.

[0139] The following describes the application of the aspects and variations disclosed herein to video codecs (e.g., those conforming to the VVC or ECM standards). Specifically, refer to... Figure 23 , 24 Figures 25 and 26 describe the application of the first aspect; Figures 25 and 26 describe the application of the second aspect; see also... Figure 19 , 20 Section 22 describes the application of the third aspect; see reference. Figure 21 Describe the application of the fourth aspect.

[0140] Figure 19 The diagram is as shown in the reference. Figure 17 The flowchart (including a diagram) describes the third aspect applied to the decoding of segmentation types. Figure 19The diagram illustrates the decoding of a segmentation type signaled by a given CU 1950 for potential segmentation at the decoder of a video codec characterized by adaptive changes in horizontal coding order. The following variables are defined as follows.

[0141] • canSpl[ i ] is a flag, if CU 1950 allows its use i If the index is a split type, then this flag is set to true, for example, where i ∈{NO_SPLIT, QT, BT_H, BT_V, TT_H, TT_V}.

[0142] • ctxSplit represents the increment of the CABAC context index of the split flag.

[0143] • ctxQtSplit represents the increment of the CABAC context index of the QT flag.

[0144] • ctxBttHV represents the increment of the CABAC context index of the flag, which indicates a vertical segment belonging to the BT or TT family.

[0145] • ctxBttH12 and ctxBttV12 each represent the increment of the CABAC context index of the flag that is optionally read after the flag indicating the vertical division of BT / TT.

[0146] Note that we assume the pixel at the top left of CU 1950 has a position (0, 0). Also note that CU 1950 can be a CTU instead of a CU.

[0147] refer to Figure 19At 1900, decoding of the segmentation type for CU 1950 can be triggered. At 1901, a flag indicating whether the corresponding segmentation type is allowed for CU 1950 can be set and stored in the canSpl array. At 1902, the CU to the left of given CU 1950 (which can be an overlapping position 1951) can be placed into cuBorder (or referenced by cuBorder). At 1903, if cuBorder is NULL (indicating that the referenced CU is unavailable), the process proceeds to 1904. Otherwise, 1904 is skipped. At 1904, the CU to the right of given CU 1950 (which can be an overlapping position 1953) can be placed into cuBorder (or referenced by cuBorder). At 1905, the CU above CU 1950 (which can be an overlapping position 1952) can be placed into cuAbove (or referenced by cuAbove). As a result of steps 1902-1905, cuBorder contains at most one horizontal (left or right) CU, depending on their availability, and cuAbove contains at most one vertical (above) CU; and therefore, the context information computed from these neighboring CUs in step 1906 is balanced. At 1906, the increments of the CABAC context indices ctxSplit, ctxQtSplit, ctxBttHV, ctxBttH12, and ctxBttV12 can be computed based on the context information derived from (or referenced by) the CUs stored in cuAbove and cuBorder and based on canSpl (e.g., as in VVC or ECM-9.0). At 1907, the segmentation type of CU 1950 can be decoded (e.g., as in VVC or ECM-9.0) by reading the desired flags with the increments computed at 1906. Note that the step highlighted by dashed box 1970 can be considered as Figure 17 Specialization of step 1701.

[0148] Figure 20 The diagram is as shown in the reference. Figure 17 The flowchart (including a diagram) describes the third aspect applied to the decoding of segmentation types. Figure 20 The diagram illustrates the decoding of a segmentation type signaled by a given CU 2050 for potential segmentation at the decoder of a video codec characterized by adaptive changes in horizontal coding order. The following variables are defined as follows. • canSpl[ i [] is a flag, if CU 2050 allows it. i If the index is a split type, then this flag is set to true, for example, wherei ∈{NO_SPLIT, QT, BT_H, BT_V, TT_H, TT_V}.

[0149] • ctxSplit represents the increment of the CABAC context index of the split flag.

[0150] • ctxQtSplit represents the increment of the CABAC context index of the QT flag.

[0151] • ctxBttHV represents the increment of the CABAC context index of the flag, which indicates a vertical segment belonging to the BT or TT family.

[0152] • ctxBttH12 and ctxBttV12 each represent the increment of the CABAC context index of the flag that is optionally read after the flag indicating the vertical division of BT / TT.

[0153] Note that we assume the pixel at the top left of CU 2050 has a position (0, 0). Also note that CU 2050 can be a CTU instead of a CU.

[0154] refer to Figure 20At position 2000, decoding of the segmentation type of CU 2050 can be triggered. At position 2001, a flag indicating whether the corresponding segmentation type is allowed for CU 2050 can be set and stored in the canSpl array. At position 2002, the CU to the right of a given CU 2050 (which can be an overlapping position 2053) can be placed into cuBorder (or referenced by cuBorder). At position 2003, if cuBorder is empty (indicating that the referenced CU is unavailable), the process proceeds to position 2004. Otherwise, position 2004 is skipped. At position 2004, the CU to the left of a given CU 2050 (which can be an overlapping position 2051) can be placed into cuBorder (or referenced by cuBorder). At position 2005, the CU above CU 2050 (which can be an overlapping position 2052) can be placed into cuAbove (or referenced by cuAbove). As a result of steps 2002-2005, cuBorder contains at most one horizontal (left or right) CU, depending on their availability, and cuAbove contains at most one vertical (above) CU; and therefore, the context information computed from these neighboring CUs in step 2006 is balanced. At 2006, the increments of the CABAC context indices ctxSplit, ctxQtSplit, ctxBttHV, ctxBttH12, and ctxBttV12 can be computed based on context information derived from (or referenced by) CUs stored in cuAbove and cuBorder and based on canSpl (e.g., as in VVC or ECM-9.0). At 2007, the segmentation type of CU 2050 can be decoded (e.g., as in VVC or ECM-9.0) by reading the desired flags with the increments computed at 2006. Note that the step highlighted by dashed box 2070 can be considered as Figure 17 Specialization of step 1701.

[0155] Figure 21 The diagram is as shown in the reference. Figure 18 The flowchart (including a diagram) describes the fourth aspect applied to the decoding of segmentation types. Figure 21 The diagram illustrates the decoding of a segmentation type signaled by a given CU 2150 for potential segmentation at the decoder of a video codec characterized by adaptive changes in horizontal coding order. The following variables are defined as follows. • canSpl[ i ] is a flag, if CU 2150 allows its use i If the index is a split type, then this flag is set to true, for example, where i∈{NO_SPLIT, QT, BT_H, BT_V, TT_H, TT_V}.

[0156] • ctxSplit represents the increment of the CABAC context index of the split flag.

[0157] • ctxQtSplit represents the increment of the CABAC context index of the QT flag.

[0158] • ctxBttHV represents the increment of the CABAC context index of the flag, which indicates a vertical segment belonging to the BT or TT family.

[0159] • ctxBttH12 and ctxBttV12 each represent the increment of the CABAC context index of the flag that is optionally read after the flag indicating the vertical division of BT / TT.

[0160] • codingInversionFlagSet is an array of flags, each flag representing a codingInversionFlag and indicating the coding order associated with available neighboring CUs. codingInversionFlag=0 indicates that its associated CU is encoded from left to right, and therefore codingInversionFlag=1 indicates that its associated CU is encoded from right to left.

[0161] Note that it is assumed that the pixel at the top left of CU 2150 has a position (0, 0). Also note that CU 2150 can be a CTU instead of a CU. Furthermore, although steps 2108 and 2110 may also require codingInversionFlagSet, for readability, codingInversionFlagSet is shown as being fed only into 2103 and 2111.

[0162] refer to Figure 21At 2100, decoding of the segmentation type of CU 2150 can be triggered. At 2101, a flag indicating whether the corresponding segmentation type is allowed for CU 2150 can be set and stored in the canSpl array. At 2102, the codingInversionFlagSet can be extracted from the available neighboring CUs. Based on the extracted codingInversionFlagSet, the relevance of the coding order is checked at 2103. For this purpose, it can be determined whether the coding order represents a predetermined pattern. For example, at 2103, if at least one neighboring CU is available and all flags in the codingInversionFlagSet are equal (e.g., a pattern with a left-to-right order), the process proceeds to steps from 2108 to 2111 where the coding order is used. Otherwise, the process proceeds to steps from 2104 to 2107 where the coding order is not used. Note that steps 2102 and 2103 can be considered as specializations of steps 1801 and 1802, such as... Figure 18 As shown. Furthermore, the steps highlighted by the dashed box 2170 on the left and the dashed box 2180 on the right can be considered specializations of steps 1805 and 1803, respectively, as... Figure 18 As shown.

[0163] Therefore, without using the encoding order (where at step 2103, not all flags in the codingInversionFlagSet are equal), at 2104, the CU to the left of given CU 2150 (which can be an overlapping position 2151) can be placed into cuBorder (or referenced by cuBorder). At 2105, if cuBorder is empty (indicating that the referenced CU is unavailable), the process proceeds to 2106. Otherwise, 2106 is not executed. At 2106, the CU to the right of given CU 2150 (which can be an overlapping position 2153) can be placed into cuBorder (or referenced by cuBorder). At 2107, the CU above given CU 2150 (which can be an overlapping position 2154) can be placed into cuAbove (or referenced by cuAbove).

[0164] Alternatively, when using the encoding order (where at step 2103, not all flags in the codingInversionFlagSet are equal), the CU used to compute the context information is based on its availability and the position defined using the codingInversionFlagSet. P 0 , P 1 ,and P2 Determined (e.g.) Figure 21 (As shown at the bottom). Therefore, at 2108, given the CU on the "boundary" side of CU 2150 (which can be an overlapping position). P 0 This depends on the flag value of codingInversionFlagSet[0] (or any flag in this set) being placed into cuBorder (or referenced by cuBorder). At 2109, if cuBorder is empty (indicating that the referenced CU is not available), the process proceeds to 2110. Otherwise, 2110 is skipped. At 2110, the CU on the "opposite" side of CU 2150 (which can be an overlapping position) is... P 1 A CU can be placed into a cuBorder (or referenced by a cuBorder). At 2111, given a CU above 2150 (which can be an overlapping position), P 2 ) can be put into cuAbove (or referenced by cuAbove).

[0165] Therefore, based on the relevance of the encoding order determined in step 2103, CUs from the neighborhood of a given CU 2150 are prioritized (or selected) for use via cuBorder and cuAbove, such that the context information derived from these CUs is spatially balanced. Thus, at 2112, the increments of the CABAC context indices ctxSplit, ctxQtSplit, ctxBttHV, ctxBttH12, and ctxBttV12 can be calculated based on the context information derived from (or referenced by) CUs stored in cuBorder and cuAbove and based on canSpl (e.g., as in VVC or ECM-9.0). At 2113, the segmentation type of CU 2150 can be decoded (e.g., as in VVC or ECM-9.0) by reading the desired flags with the increments calculated at 2112.

[0166] Figure 21This can be used to illustrate other variations of the codingInversionFlagSet extracted in step 2102, defined differently. For example, codingInversionFlagSet could contain a single (Boolean) flag, which could be the codingInversionFlag for moving to a CU that was scanned just before the given CU 2150, following the coding order. In another example, codingInversionFlagSet could contain a single (Boolean) flag, which could be the codingInversionFlag for moving to a CU that was scanned just before the given CU 2150, assuming that this previously scanned CU and the given CU belong to the same CTU.

[0167] Figure 22 The diagram is as shown in the reference. Figure 17 The flowchart (including a schematic diagram) describes the third aspect applied to the decoding of the IBC flag. Figure 22 The diagram illustrates the decoding of the IBC flag, signaled for a given CU 2250, at the decoder of a video codec characterized by adaptive changes in horizontal coding order. The following variables are defined:

[0168] • ibcFlag represents the IBC flag.

[0169] • offsetIbcFlag indicates that its increment generates an index for the CABAC context index used to read the IBC flag from the bitstream.

[0170] • decodeBin is a function call that reads the current binary symbol using the input CABAC context index.

[0171] Note that we assume the pixel at the top left of CU 2250 has a position (0, 0).

[0172] refer to Figure 22At 2200, decoding of the IBC flag of CU 2250 can be triggered. At 2201, the CU to the left of given CU 2250 (which can be an overlapping position 2251) can be placed into cuBorder (or referenced by cuBorder). At 2202, if cuBorder is empty (indicating that the referenced CU is unavailable), the process proceeds to 2203. Otherwise, 2203 is skipped. At 2203, the CU to the right of given CU 2250 (which can be an overlapping position 2253) can be placed into cuBorder (or referenced by cuBorder). At 2204, the CU above given CU 2250 (which can be an overlapping position 2252) can be placed into cuAbove (or referenced by cuAbove). At 2205, the incremental idxCtx can be calculated based on the context information derived from the CUs stored in (or referenced by) cuAbove and cuBorder. At 2206, the IBC flag of CU 2250 can be read from the bitstream using the CABAC context index offsetIbcFlag + idxCtx. Note that the step highlighted by dashed box 2270 can be considered as... Figure 17 Specialization of step 1701.

[0173] Figure 23 The diagram is as shown in the reference. Figure 14 The flowchart (including a schematic diagram) describes the first aspect applied to the decoding of the IBC flag. Figure 23 The diagram illustrates the decoding of the IBC flag, signaled for a given CU 2350, at the decoder of a video codec characterized by adaptive changes in horizontal coding order. The following variables are defined:

[0174] • ibcFlag represents the IBC flag.

[0175] • offsetIbcFlag indicates that its increment generates an index for the CABAC context index used to read the IBC flag from the bitstream.

[0176] • decodeBin is a function call that reads the current binary symbol using the input CABAC context index.

[0177] • codingInversionFlag indicates the encoding order associated with the CU 2350. codingInversionFlag=0 indicates that the CU 2350 is encoded from left to right, and therefore codingInversionFlag=1 indicates that the CU 2350 is encoded from right to left.

[0178] Note that although step 2304 may also require codingInversionFlag, for readability, codingInversionFlag is shown as being fed only to steps 2302 and 2305. Also note that it is assumed that the pixel at the top left of CU 2350 has a position (0, 0).

[0179] refer to Figure 23 At position 2300, decoding of the IBC flag of CU 2350 can be triggered. At position 2301, the codingInversionFlag of CU 2350 can be extracted. Next, the CU used to calculate context information is positioned based on its availability and the location defined by using the codingInversionFlag. P 0 , P 1 ,and P 2 Determined (e.g.) Figure 23 (As shown at the bottom). Therefore, at 2302, given the CU on the "boundary" side of CU 2350 (which can be an overlapping position). P 0 A CU can be placed into a cuBorder (or referenced by a cuBorder). At 2303, if the cuBorder is empty (indicating that the referenced CU is unavailable), the process proceeds to 2304. Otherwise, 2304 is skipped. At 2304, the CU on the "opposite" side of CU 2350 (which can be an overlapping position) is given. P 1 A CU can be placed into a cuBorder (or referenced by a cuBorder). At 2305, given a CU above 2350 (which can be an overlapping position). P 2 The ) can be placed into cuAbove (or referenced by cuAbove). At 2306, the incremental idxCtx can be calculated based on the context information derived from the CU stored in (or referenced by) cuAbove and cuBorder. At 2307, the IBC flag of CU2350 can be read from the bitstream using the CABAC context index offsetIbcFlag + idxCtx. Note that steps 2301, highlighted by dashed box 2370, can be considered as respectively Figure 14 Specialization of steps 1401 and 1402.

[0180] Figure 24 The diagram is as shown in the reference. Figure 14 The flowchart (including a schematic diagram) describes the first aspect applied to the decoding of the MIP flag. Figure 24 The diagram illustrates the decoding of MIP flags signaled for a given CU 2450 at the decoder of a video codec characterized by adaptive changes in horizontal coding order. The following variables are defined:

[0181] • mipFlag represents the MIP flag.

[0182] • offsetMipFlag indicates that its increment generates an index for the CABAC context index used to read the MIP flag from the bitstream.

[0183] • decodeBin is a function call that reads the current binary symbol using the input CABAC context index.

[0184] • codingInversionFlag indicates the encoding order associated with the CU 2450. codingInversionFlag=0 indicates that the CU 2450 encodes from left to right, and therefore codingInversionFlag=1 indicates that the CU 2450 encodes from right to left.

[0185] Note that although step 2404 may also require codingInversionFlag, for readability, codingInversionFlag is shown as being fed only to steps 2402 and 2405. Also note that it is assumed that the pixel at the top left of CU 2450 has a position (0, 0).

[0186] refer to Figure 24 At position 2400, decoding of the MIP flag of CU 2450 can be triggered. At position 2401, the codingInversionFlag of CU2450 can be extracted. Next, the CU used to calculate context information is positioned based on its availability and the location defined by using the codingInversionFlag. P 0 , P 1 ,and P 2 Determined (e.g.) Figure 24 (As shown at the bottom). Therefore, at 2402, given the CU on the "boundary" side of CU 2450 (which can be an overlapping position). P 0A CU can be placed into a cuBorder (or referenced by a cuBorder). At 2403, if the cuBorder is empty (indicating that the referenced CU is unavailable), the process proceeds to 2404. Otherwise, 2404 is skipped. At 2404, the CU on the "opposite" side of CU 2450 (which can be an overlapping position) is given. P 1 A CU can be placed into a cuBorder (or referenced by a cuBorder). At 2405, given a CU above 2450 (which can be an overlapping position), P 2 The ) can be placed into cuAbove (or referenced by cuAbove). At 2406, the incremental idxCtx can be calculated based on the context information derived from the CU stored in (or referenced by) cuAbove and cuBorder. At 2407, the MIP flag of CU2450 can be read from the bitstream using the CABAC context index offsetMipFlag + idxCtx. Note that steps 2401 and 2470 can be viewed as... Figure 14 Specialization of steps 1401 and 1402.

[0187] Figure 25A -B is the diagram (as shown in the reference). Figure 15 The second aspect described herein applies to the decoding of the intra-prediction mode index (including a schematic diagram). Figure 25 illustrates the decoding of the intra-prediction mode index, signaled for the luminance component of a given PU 2550, at the decoder of a video codec characterized by adaptive changes in horizontal coding order. The following variables are defined as follows.

[0188] • ipredMode represents the index of the intra-prediction mode associated with the luma component of the PU 2550.

[0189] • borderIntraDir represents the index of the intra-prediction mode in the lumen.

[0190] • aboveIntraDir represents the index of the intra-prediction mode in the lumen.

[0191] • codingInversionFlag indicates the encoding order associated with PU 2550. codingInversionFlag=0 indicates that PU 2550 is encoded from left to right, and therefore codingInversionFlag=1 indicates that PU 2550 is encoded from right to left.

[0192] Two double slashes and two double horizontal lines indicate Figure 25A and Figure 25B The corresponding connection points between the two flowchart sections. Note that it is assumed that the pixel at the top left of PU 2550 has a position (0, 0). Also note that although 2504 may also require codingInversionFlag, for readability, codingInversionFlag is shown as being fed only to 2502 and 2505. In some video codecs (such as those conforming to the VVC standard), the CU contains the PU, making the CU and its PU equivalent in terms of the decoding process.

[0193] refer to Figure 25A -B, at 2500, can trigger decoding of the index `ipredMode` of the intra-prediction mode in the PU 2550's luminance. Note that 2500 is assumed to start from a point where the MIP flag (if needed) has already been read from the bitstream and is equal to 0, and flags related to multiple reference lines (MRLs) and intra-segment sub-partitions (ISPs) have been read from the bitstream, if needed. At 2501, the PU 2550's `codingInversionFlag` can be extracted. Next, the CU used to calculate context information is based on its availability and the position defined based on the use of `codingInversionFlag`. P 0 , P 1 ,and P 2 Determined (e.g.) Figure 25B (As shown at the bottom). At 2502, the PU on the "bottom boundary" side of PU 2550 (which can be an overlapping location). P 0 A PU can be placed in a puBorder (or referenced by a puBorder). At 2503, if the puBorder is empty (indicating the referenced PU is unavailable) or the referenced PU is not predicted using intra-frame prediction mode, the process proceeds to steps 2504 through 2506. Otherwise, the process proceeds to 2507. At 2504, given the PU on the "relative bottom" side of PU 2550 (which can be an overlapping position), P 1A PU can be placed in (or referenced by) a puBorder. At 2505, if the puBorder is empty (indicating the referenced PU is unavailable) or the referenced PU is not predicted using intra-prediction mode, the process proceeds to 2506. Otherwise, the process proceeds to 2507. At 2506, borderIntraDir can be set to the PLANAR_IDX index (representing PLANAR mode). At 2507, borderIntraDir can be set to the intra-prediction mode index selected for predicting the luma component of the PU stored in (or referenced by) the puBorder.

[0194] Possibly, steps 2508-2507 can be performed in parallel with steps 2502-2507. At 2508, given the PU on the "above-opposite" side of PU 2550 (which can be an overlapping position), P 2 The PU can be placed in puabove (or referenced by puabove). At 2509, if puabove is empty (indicating the referenced PU is unavailable), or the referenced PU is not predicted using intra-prediction mode, or the referenced PU and PU 2550 do not belong to the same CTU, the process proceeds to 2510. Otherwise, the process proceeds to 2511. At 2510, aboveIntraDir can be set to PLANAR_IDX. At 2511, aboveIntraDir can be set to the intra-prediction mode index selected for predicting the luminance components of the PU stored in puabove (or referenced by puabove).

[0195] Next, at 2512, the list of most probable modes (MPMs) of PU 2550 can be populated using borderIntraDir and aboveIntraDir. Then, the populated list of MPMs can be used to decode the ipredMode of PU 2550 (e.g., as in VVC). Note that steps 2501, highlighted by dashed box 2570, can be considered as... Figure 15 Specialization of steps 1501 and 1502 in the process.

[0196] Figure 26A -C is the diagram (as shown in the reference). Figure 15 The second aspect described applies to the flowchart (including a diagram) of the export of the MPM list. Figure 26AThe -C diagram illustrates the export of a list of MPMs for a given PU 5050 at the decoder of a video codec characterized by adaptive changes in horizontal coding order. This exported list of MPMs is then used to decode the indices of intra-frame prediction modes used for predicting the luma components of the PU 5050. Figure 26A In C, the following variables are defined as follows.

[0197] • spatialIpm[ i [Index] represents the index used to predict the intra-frame prediction mode for the luma component of the corresponding PU that is a neighbor of a given PU 5050, and has a priority level. i ,in i ∈⟦0,numCand-1⟧.

[0198] • arrayReserved[ i [Index] represents the index used to predict the intra-frame prediction mode for the luma component of the corresponding PU that is a neighbor of a given PU 5050, and has a priority level. i ,in i ∈⟦0,nbReserved-1⟧. The indices in arrayReserved are reserved for later appending to the indices in patialIpm.

[0199] • includeMode[ i This represents a flag that, if set to true, indicates the intra-prediction mode index. i It already exists in spatialIpm.

[0200] • isIdxModeValid indicates, among other things, the priority of spatialIpm[numCand] based on the availability of reference samples around heightPU, widthPU, spatialIpm[numCand], and PU 5050. Here, priority means whether spatialIpm[numCand] must be reserved for later appending to spatialIpm.

[0201] • codingInversionFlag indicates the encoding order associated with PU 5050. codingInversionFlag=0 indicates that PU 5050 is encoded from left to right, and therefore codingInversionFlag=1 indicates that PU 5050 is encoded from right to left.

[0202] Note that we assume the pixel at the top left of PU 5050 has a position (0, 0).

[0203] refer to Figure 26A At 5000, the export of the MPM list of PU 5050 can be triggered. At 5001, spatialIpm[0] is set to PLANAR_IDX, and nbReserved is set to 0. In addition, all values ​​of the includeMode array are initialized to false except for includeMode[PLANAR_IDX], which is initialized to true (indicating that at this point, only the PLANAR_IDX mode exists in spatialIpm). At 5002, the codingInversionFlag of PU 5050 can be extracted. At 5003, among other things, an ordered list of six positions around PU 5050 can be defined based on codingInversionFlag. At 5004, spatialIpm and arrayReserved can be resolved by running the command for... i From 0 to 5, The steps highlighted by dashed box 4090 as the input location ( Figure 26B Steps 4000 to 4011 in the process are used to fill in the blanks.

[0204] like Figure 26B As shown, at 4000, the PU overlap input position P (Right now The PU stored in (or referenced by) puNeighbor can be placed in puNeighbor. At 4001, if puNeighbor is empty (indicating the referenced PU is unavailable), the process proceeds to 4011. Otherwise, the process proceeds to steps 4002 through 4010. At 4002, isFound is initialized to false. At 4003, if the luminance component of the PU stored in (or referenced by) puNeighbor is predicted in intra-prediction mode, the process proceeds to 4004. Otherwise, 4004 is skipped. At 4004, spatialIpm[numCand] can be set to the index of the intra-prediction mode used to predict the luminance component of the PU stored in (or referenced by) puNeighbor. Then, isFound can be set to true. At 4005, if the luminance component of the PU stored in (or referenced by) puNeighbor is predicted using inter-prediction mode or IBC prediction mode, the process proceeds to 4006. Otherwise, skip 4006. At 4006, firstly, a search for PUs using intra-prediction modes is performed, starting with the PU stored in (or referenced by) puNeighbor, following the motion vector provided by the PU's inter-frame prediction mode or IBC mode, and ending at the PU using the intra-prediction mode in the reference frame; then, spatialIpm[numCand] is set with the index of the intra-prediction mode used to predict the luminance of the found PU, and isFound is set to true. At 4007, if isFound is true and includeMode[spatialIpm[numCand]] is false (indicating that spatialIpm[numCand] contains the index of the intra-prediction mode used to predict the luminance component of the PUs adjacent to the given PU 5050 and spatialIpm[numCand] does not yet exist in spatialIpm), the process proceeds to 4008. Otherwise, the process proceeds to 4011. At 4008, the validity of the index in spatialIpm[numCand] is tested, where isIdxModeValid can be a function of the availability of heightPU, widthPU, spatialIpm[numCand], and reference samples around PU 5050, among other things. Therefore, at 4008, if isIdxModeValid returns true, the process proceeds to 4010. Otherwise, the process proceeds to 4009.At 4009, `arrayReserved[nbReserved]` can be set to `spatialIpm[numCand]` and `nbReserved+=1`, reserving `spatialIpm[numCand]` for later appending to `spatialIpm`. At 4010, `includeMode[spatialIpm[numCand]]` can be set to true and `numCand+=1`, thus instructing `spatialIpm[numCand]` to have a high priority level of `numCand-1` for later construction of the MPM list for PU 5050.

[0205] Return to reference Figure 26A At position 5005, padding of spatialIpm can continue. For example, the index of the intra-prediction mode derived via decoder-side intra-mode derivation (DIMD) can be appended to spatialIpm, and numCand can be incremented accordingly. Similarly, the index of the prediction mode from a non-adjacent neighboring PU can be appended to spatialIpm, and numCand can be incremented accordingly. This could mean that for each position in the list of positions not adjacent to PU 5050, that position is used as input to run... Figure 26B The process 4090 is shown. For example, for each index of the intra-prediction mode in arrayReserved, if this index does not already exist in spatialIpm, it can be appended to spatialIpm, and numCand can be incremented accordingly. At 5006, a list of MPMs for PU 5050 can be created from spatialIpm (e.g., as done in ECM-9.0). It is worth noting that the first numCand index stored in spatialIpm can become the first numCand MPM. Note that steps 5070 and 5002, highlighted by dashed box 5070, can be considered as... Figure 15 Specialization of steps 1501 and 1502 in the process.

[0206] exist Figure 26A In -C, for clarity, it is assumed that the PUs around PU 5050 are not predicted via Simplified Geometric Partitioning Mode (SGPM), Template-Based Intra-Frame Mode Derivation (TIMD), or Template-Based Multi-Reference Line (TMRL). Nevertheless, Figure 26A -C can be directly applied to the case of PUs around PU 5050 predicted via SGPM, TIMD, or TMRL.

[0207] refer to Figure 26CRegarding the definition of an ordered list of 6 locations surrounding a given PU 5050. Step 5003 can be applied in various variations. In the first variation, if the codingInversionFlag of PU 5050 is equal to 0, then This can include positions [(5051), (5052), (5053), (5054), (5055), (5058)]. Otherwise (i.e., if the codingInversionFlag of PU 5050 is equal to 1), This can include positions [(5056), (5057), (5054), (5053), (5058), (5055)]. In the second variant, if the codingInversionFlag of PU 5050 is equal to 0, then This can include positions [(5051), (5052), (5053), (5054), (5055), (5056)]. Otherwise (i.e., if the codingInversionFlag of PU 5050 is equal to 1, then... This can include positions [(5056), (5057), (5054), (5053), (5058), (5051)]. In the third variant, the codingInversionFlag of PU 5050 and Any relationship between them can be valid. In the fourth variant, ordered lists It can include Location. In this case, in 5004, i From 0 all the way to n -1. In the fifth variant, Figure 26A The order of steps in the flowchart of -B can be changed. For example, step 5001 can be placed between steps 5003 and 5004. In the sixth variant, in Figure 26A In the code, at position 5005, another list of possible adjacent / non-adjacent locations to PU5050 can be defined, optionally depending on the codingInversionFlag of PU 5050. For each location in this other list, the code is... Figure 26B The process of highlighting the dashed box 4090 in the image can be run using this location as input.

[0208] The aspects described in this article can be applied to signaling and decoding of any given syntax element (e.g., a flag or index), as referenced above. Figure 19-2 The application described in 6 is shown. For example, (see reference) Figure 14The first aspect (described) can be applied to the decoding of any grammatical element, such as the affine flag or skip flag associated with a given CU (similar to how the first aspect is applied as described in references). Figure 23 and Figure 24 The description of how the IBC flag and MIP flag are decoded.

[0209] As mentioned above, the applications described in this paper include applications to video codecs characterized by adaptive changes not only to the horizontal coding order but also to any coding order, as referenced below. Figure 27 Described.

[0210] Figure 27 The diagram is as shown in the reference. Figure 14 The flowchart (including a schematic diagram) describes the first aspect applied to the decoding of the MIP flag. Figure 27 The illustration shows the decoding of MIP flags signaled for a given CU 2650 at the decoder of a video codec characterized by adaptive changes in encoding order. The encoding order can be: top-to-bottom and left-to-right; top-to-bottom and right-to-left; bottom-to-top and left-to-right; and bottom-to-top and right-to-left. Figure 27 In this context, the following variables are defined as follows.

[0211] • mipFlag represents the MIP flag.

[0212] • codingInversionFlagH indicates the coding order of the CU 2650 in the horizontal direction (i.e., from left to right or from right to left).

[0213] • codingInversionFlagV indicates the coding order of the CU 2650 in the vertical direction (i.e., from top to bottom or from bottom to top).

[0214] • offsetMipFlag indicates that its increment generates an index for the CABAC context index used to read the MIP flag from the bitstream.

[0215] • decodeBin is a function call that reads the current binary symbol using the input CABAC context index.

[0216] • codingInversionFlagH indicates the horizontal coding order associated with the CU 2650. codingInversionFlagH=0 indicates that the CU 2650 is encoded from left to right, and therefore codingInversionFlagH=1 indicates that the CU 2650 is encoded from right to left.

[0217] • codingInversionFlagV indicates the vertical encoding order associated with the CU 2650. codingInversionFlagV=0 indicates that the CU 2650 is encoded from top to bottom, and therefore codingInversionFlagV=1 indicates that the CU 2650 is encoded from bottom to top.

[0218] Note that we assume the pixel at the top left of the CU 2650 has a position (0, 0).

[0219] For the position to the left or right of the CU 2650 (i.e., Figure 27 (At positions 2651, 2653, 2657, and 2658), the "reference axis" is defined as a vertical line (not shown) passing through the center of CU 2650. For positions above or below CU 2650 (i.e., Figure 27 Positions 2652, 2654, 2655, and 2656 in the diagram define the "reference axis" as a horizontal line (not shown) passing through the center of CU 2650. Therefore, the mirror image of position 2651 relative to its reference axis can be position 2653; the mirror image of position 2657 relative to its reference axis can be position 2658; the mirror image of position 2652 relative to its reference axis can be position 2655; and the mirror image of position 2654 relative to its reference axis can be position 2656.

[0220] refer to Figure 27 At position 2600, decoding of the MIP flag of CU 2650 can be triggered. At position 2601, the codingInversionFlagH and codingInversionFlagV of CU 2650 can be extracted. At position 2602, an ordered list of four locations surrounding CU 2650 can be created based on codingInversionFlagH and codingInversionFlagV. At 2620, the list `listCus`, which references the reserved CUs, is initialized to an empty list. Then, for i From 0 to 3, internal processes including steps 2603, 2604, 2605, and 2606 can be executed. At 2603, the CU overlap position... It can be placed into cuTemp (or referenced by cuTemp). At 2604, if cuTemp is empty (indicating that the referenced CU is unavailable), the process proceeds to 2605. Otherwise, skip 2605. At 2605, as The CU overlap position, mirrored relative to the reference axis, can be placed in cuTemp (or referenced by cuTemp). At 2606, cuTemp can be appended to listCus. At 2607, the increment idxCtx can be calculated from listCus. At 2608, the MIP flag of CU 2650 can be read from the bitstream using the CABAC context index offsetMipFlag + idxCtx. Note that steps highlighted by dashed box 2670 and step 2601 can be considered as... Figure 14 Specialization of steps 1401 and 1402 in the process.

[0221] Refer to step 2602 (where an ordered list can be created based on codingInversionFlagH and codingInversionFlagV). (), can be used in the following variations. In the variations, The relationship between the values ​​of codingInversionFlagH and codingInversionFlagV follows Table 1 or Table 2. In another variant, Any relationship between the values ​​of codingInversionFlagH and codingInversionFlagV is valid. In yet another variant, ordered lists... It can contain In this case, in steps 2620 and 2607, i From 0 all the way to n -1. For example. n =5.

[0222] Table 1: Functions used as codingInversionFlagH and codingInversionFlagV The position in the middle.

[0223] Table 2: Functions used as codingInversionFlagH and codingInversionFlagV The position in the middle.

[0224] Figure 28This is a flowchart 2800 of an example method for encoding video data. According to steps 2820 and 2830, method 2800 can be applied to encode video blocks of video data into a bitstream 2810. In step 2820, context information can be derived from the encoded data of neighboring video blocks located in the neighborhood of the video block. The derivation of context information can be based on the spatial location of neighboring video blocks relative to the video block. Then, in step 2830, using the context information, syntax elements can be encoded into the bitstream. The context information can be further derived based on the encoding order of neighboring video blocks. For example, if the encoding order has a predetermined pattern, the derivation of context information can be based on the encoding order.

[0225] In one aspect, context information can be derived by generating a list of blocks and calculating context information from the encoded data of the blocks in the list. In this aspect, if the encoded data is available for blocks adjacent to the video blocks and based on the encoding order, the list can be generated by adding the block to the list. In another aspect, context information can be derived as follows: for each block adjacent to the video blocks, if the encoded data is available for that block and based on the encoding order, context information is calculated from the encoded data of that block and combined with the previously calculated context information.

[0226] In another aspect, deriving context information based on the spatial location of neighboring video blocks relative to the video block (as in step 2820) may include balancing the context information derived from video blocks located in a first region of the video block's neighborhood with the context information derived from video blocks located in a second region of the video block's neighborhood. For example, the first region may include video blocks positioned horizontally relative to the video block, and the second region may include video blocks positioned vertically relative to the video block.

[0227] Figure 29 This is a flowchart 2900 of an example method for decoding video data. According to steps 2920 and 2930, method 2900 can be applied to video block 2910 for decoding video data from a bitstream. In step 2920, context information can be derived from the encoded data of neighboring video blocks located in the neighborhood of the video block. The derivation of the context information can be based on the spatial position of the neighboring video blocks relative to the video block. Then, in step 2930, using the context information, syntax elements can be decoded from the bitstream. The context information can be further derived based on the encoding order of the neighboring video blocks. Note that the aspects described herein regarding generating context information used to signal (or encode) syntax elements in the bitstream generally apply to generating context information used to decode syntax elements from a bitstream.

[0228] Any aspect presented in this article (e.g., regarding...) Figure 14-18(as described in 28-29) and their applications (e.g., as regarding Figure 19-27 (As described), the balanced generation of context information based on the local coding order can be directly applied to other coding modules.

[0229] Several aspects and embodiments have been described in this disclosure. These aspects and embodiments, across different claim classes and types, provide at least the following outputs and results (including all combinations): • According to any of the aspects described herein, syntax elements that enable the decoder to decode the encoded video data are encoded into the encoded video data.

[0230] • A bitstream including one or more of the stated syntax elements or their variations. The bitstream can be any dataset, whether transmitted, stored, or otherwise made available.

[0231] • Creation, transmission, reception, and / or decoding of bitstreams.

[0232] • An electronic device (e.g., a TV, set-top box, cellular phone, or tablet computer) that tunes (e.g., using a tuner) a channel to receive a bitstream or receives a bitstream via radio (e.g., using an antenna). The electronic device decodes the syntax elements from the bitstream and optionally displays (e.g., using a monitor, screen, or any other type of display) the resulting image.

[0233] Throughout this disclosure, various other general and specific outputs, results, implementations, and claims are also supported and considered.

[0234] This document describes various methods, each of which includes one or more steps or actions for implementing the method. Unless the correct operation of the method requires a specific order of steps or actions, the order and / or use of specific steps and / or actions can be modified or combined. Furthermore, terms such as "first" and "second" can be used in various embodiments to modify elements, components, steps, operations, etc., for example, "first decoding" and "second decoding." Unless specifically required, the use of such terms does not imply a modified order of operations. Therefore, in this example, the first decoding does not need to be performed before the second decoding and can occur, for example, before, during, or in a time period overlapping with the second decoding.

[0235] The various methods and other aspects described in this application can be used to modify the module, for example, such as Figure 2 and Figure 3The illustrated modules are video encoder 200 and video decoder 300. Furthermore, this aspect is not limited to specific standards (such as VVC or HEVC) and can be applied to, for example, other standards and recommendations, as well as any extensions of such standards and recommendations. Unless otherwise stated or technically excluded, the aspects described in this application may be used alone or in combination.

[0236] Various numerical values ​​are used in this application. Specific values ​​are for illustrative purposes only, and the aspects described are not limited to these specific values.

[0237] Various implementations involve decoding. As used herein, “decoding” can encompass all or part of a process performed, for example, on a received encoded sequence to produce a final output suitable for display. In various embodiments, such a process includes one or more processes typically performed by a decoder, such as entropy decoding, inverse quantization, inverse transform, and differential decoding. It will be clear, and is considered well understood by those skilled in the art, that the phrase “decoding process” is intended to specifically refer to a subset of operations or to refer to a broader decoding process, based on the context of the particular description.

[0238] Various implementation schemes involve encoding. In a manner similar to the discussion above regarding "decoding," the term "encoding," as used in this application, can encompass, for example, all or part of the processing performed on the input video data to produce an encoded bitstream. Furthermore, the terms "reconstruction" and "decoding" are used interchangeably, as are the terms "encoding" and "coded," and the terms "image," "picture," and "frame." Typically, but not necessarily, the term "reconstruction" is used on the encoder side, while the term "decoding" is used on the decoder side.

[0239] Note that the grammatical elements used in this article are descriptive terms. Therefore, the use of other grammatical element names is not excluded.

[0240] This disclosure has described various pieces of information that can be transmitted or stored, such as, for example, syntax. This information can be packaged or arranged in various ways, including those common in video standards, such as placing the information in SPS, PPS, NAL units, headers (e.g., NAL unit headers or segment headers), or SEI messages. Other methods are also available, including those common to system-level or application-level standards, such as signaling the information to one or more of the following: a. SDP (Session Description Protocol), a format for describing multimedia communication sessions for the purpose of session announcement and session invitation, such as SDP as described in RFC and used in conjunction with RTP (Real-Time Transport Protocol) transmission.

[0241] b. DASH MPD (Media Presentation Description) descriptors, such as those used in DASH and transmitted via HTTP. Descriptors are associated with a representation or set of representations to provide additional characteristics to the content representation.

[0242] c. RTP header extensions, such as those used during RTP streaming.

[0243] d. ISO Basic Media File Format, such as the ISO Basic Media File Format used in OMAF and using boxes as object-oriented building blocks defined by unique type identifiers and lengths (also referred to as 'atoms' in some specifications).

[0244] e. An HLS (HTTP Live Streaming) manifest delivered via HTTP. The manifest can be associated, for example, with a version of the content or a collection of versions of the content to provide characteristics of the version or collection of versions.

[0245] The implementations and aspects described herein can be implemented, for example, in methods or processes, apparatuses, software programs, data flows, or signals. Even if discussed only in the context of a single form of implementation (e.g., discussed only as a method), the features discussed can also be implemented in other forms (e.g., apparatuses or programs). Apparatuses can be implemented, for example, in suitable hardware, software, and firmware. Methods can be implemented, for example, in apparatuses, such as processors, which generally refer to processing devices, including, for example, computers, microprocessors, integrated circuits, or programmable logic devices. Processors also include communication devices, such as computers, cellular phones, portable / personal digital assistants (PDAs), and other devices that facilitate communication of information between end-users.

[0246] References to “an aspect,” “an embodiment,” or “an implementation,” and their variations, mean that a particular feature, structure, characteristic, etc., described in connection with that aspect, embodiment, or implementation is included in at least one embodiment. Therefore, the phrases “in an aspect,” “in an embodiment,” or “in an implementation,” and any other variations appearing throughout this application, do not necessarily refer to the same embodiment.

[0247] Furthermore, this application may refer to "determining" each piece of information. Determining information may include, for example, one or more of the following: estimated information, calculated information, predicted information, or information retrieved from memory.

[0248] Furthermore, this application may refer to "accessing" individual pieces of information. Accessing information may include, for example, receiving information, retrieving information (e.g., from memory), storing information, moving information, copying information, calculating information, determining information, predicting information, or estimating information, or one or more of these.

[0249] Furthermore, this application may refer to "receiving" individual pieces of information. Like "access," "receiving" is intended to be a broad term. Receiving information may include, for example, accessing information or retrieving information (e.g., from memory) one or more of them. Moreover, "receiving" is generally referred to in one manner or another during operations such as storing information, processing information, transmitting information, moving information, copying information, erasing information, calculating information, determining information, predicting information, or estimating information.

[0250] It should be understood that, for example, in the cases of “A / B,” “A and / or B,” and “at least one of A and B,” the use of any of the following “ / ,” “and / or,” and “at least one” is intended to cover selecting only the first listed option (A), or only the second listed option (B), or both options (A and B). As another example, in the cases of “A, B, and / or C” and “at least one of A, B, and C,” such wording is intended to cover selecting only the first listed option (A), or only the second listed option (B), or only the third listed option (C), or only the first and second listed options (A and B), or only the first and third listed options (A and C), or only the second and third listed options (B and C), or all three options (A, B, and C). As will be apparent to those skilled in the art and related fields, this can be extended to as many of the listed items as possible.

[0251] Furthermore, as used herein, the word "signal" refers, among other things, specifically to the corresponding decoder indicating something. For example, in some embodiments, the encoder signals the quantization parameters used for dequantization. In this way, in embodiments, the same parameters can be used on both the encoder and decoder sides. Thus, for example, the encoder can transmit (explicit signaling) specific parameters to the decoder so that the decoder can use the same specific parameters. Conversely, if the decoder already has specific parameters as well as other parameters, signaling (implicit signaling) can be used without transmission to simply allow the decoder to know and select specific parameters. Bit savings are achieved in various embodiments by avoiding the transmission of any actual data. It should be understood that signaling can be implemented in various ways. For example, in various embodiments, one or more syntax elements, flags, etc., are used to signal information to the corresponding decoder. Although the verb form of the word "signal" has been referred to above, the word "signal" can also be used as a noun herein.

[0252] As will be apparent to those skilled in the art, implementations can generate various signals formatted to carry information, such as information that can be stored or transmitted. This information may include, for example, instructions for performing a method, or data generated by one of the described implementations. For example, a signal may be formatted to carry a bitstream of a described embodiment. Such a signal may be formatted as, for example, electromagnetic waves (e.g., using the radio frequency portion of a spectrum) or baseband signals. Formatting may include, for example, encoding a data stream and modulating a carrier wave with the encoded data stream. The information carried by the signal may be, for example, analog or digital information. As is known, signals can be transmitted via various wired or wireless links. The signal may be stored on a processor-readable medium.

Claims

1. A method for decoding video data, comprising: Decoding video blocks of the video data from the bitstream, wherein the decoding of the video blocks includes: Context information is derived from the encoded data of neighboring video blocks located within the neighborhood of the video block, the derivation being based on the spatial position of the neighboring video blocks relative to the video block, and Use the context information to decode syntax elements from the bitstream.

2. The method according to claim 1, further comprising: Extract the encoding order of the adjacent video blocks, wherein, The context information is further derived based on the encoding order.

3. The method according to claim 2, wherein, The export of the context information includes: Generate a block list, wherein for each of the neighboring video blocks: If the encoded data is available for the block and based on the encoding order, then the block is added to the list; and Context information is calculated from the encoded data of the blocks in the list.

4. The method according to claim 2, wherein, The export of the context information includes: For each of the adjacent video blocks: If the encoded data is available for the block and based on the encoding order, then context information is calculated from the encoded data of the block. The derived context information includes context information calculated for the block.

5. The method according to any one of claims 2 to 4, wherein, If the encoding order has a predetermined pattern, the context information is derived based on the encoding order.

6. The method according to claim 2, wherein, The encoding order is a horizontal encoding order.

7. The method according to any one of claims 1 to 6, wherein, Deriving the context information based on the spatial location of the neighboring video blocks relative to the video block further includes: The context information derived from video blocks located in a first region of the neighborhood of the video block is balanced with the context information derived from video blocks located in a second region of the neighborhood of the video block.

8. The method according to claim 7, wherein, The first region includes a video block positioned horizontally relative to the video block, and the second region includes a video block positioned vertically relative to the video block.

9. A method for encoding video data, comprising: Encoding video blocks of the video data into a bitstream, wherein the encoding of the video blocks includes: Context information is derived from the encoded data of neighboring video blocks located within the neighborhood of the video block, the derivation being based on the spatial position of the neighboring video blocks relative to the video block, and The context information is used to encode the syntax elements into the bitstream.

10. The method of claim 9, further comprising: Extract the encoding order of the adjacent video blocks, wherein, The context information is further derived based on the encoding order.

11. An apparatus for decoding video data, comprising: At least one processor; and A memory storing instructions that, when executed by the at least one processor, cause the device to: Decoding video blocks of the video data from the bitstream, wherein the decoding of the video blocks includes: Context information is derived from the encoded data of neighboring video blocks located within the neighborhood of the video block, the derivation being based on the spatial position of the neighboring video blocks relative to the video block, and Use the context information to decode syntax elements from the bitstream.

12. The apparatus according to claim 11, wherein, The instruction further causes the device to: The encoding order of the neighboring video blocks is extracted, wherein the context information is further derived based on the encoding order.

13. The apparatus according to claim 12, wherein, The export of the context information includes: Generate a block list, wherein for each of the neighboring video blocks: If the encoded data is available for the block and based on the encoding order, then the block is added to the list; and Context information is calculated from the encoded data of the blocks in the list.

14. The apparatus according to claim 12, wherein, The export of the context information includes: For each of the adjacent video blocks: If the encoded data is available for the block and based on the encoding order, then context information is calculated from the encoded data of the block. The derived context information includes context information calculated for the block.

15. The apparatus according to any one of claims 12 to 14, wherein, If the encoding order has a predetermined pattern, the context information is derived based on the encoding order.

16. The apparatus according to any one of claims 11 to 15, wherein, Deriving the context information based on the spatial location of the neighboring video blocks relative to the video block further includes: The context information derived from video blocks located in a first region of the neighborhood of the video block is balanced with the context information derived from video blocks located in a second region of the neighborhood of the video block.

17. An apparatus for encoding video data, comprising: At least one processor; and A memory storing instructions that, when executed by the at least one processor, cause the device to: Encoding video blocks of the video data into a bitstream, wherein the encoding of the video blocks includes: Context information is derived from the encoded data of neighboring video blocks located within the neighborhood of the video block, the derivation being based on the spatial position of the neighboring video blocks relative to the video block, and The context information is used to encode the syntax elements into the bitstream.

18. The apparatus according to claim 17, wherein, The instruction further causes the device to: The encoding order of the neighboring video blocks is extracted, wherein the context information is further derived based on the encoding order.

19. A non-transitory computer-readable medium comprising instructions executable by at least one processor to perform a method for decoding video data, the method comprising: Decoding video blocks of the video data from the bitstream, wherein the decoding of the video blocks includes: Context information is derived from the encoded data of neighboring video blocks located within the neighborhood of the video block, the derivation being based on the spatial position of the neighboring video blocks relative to the video block, and Use the context information to decode syntax elements from the bitstream.

20. A non-transitory computer-readable medium comprising instructions executable by at least one processor to perform a method for encoding video data, the method comprising: Encoding video blocks of the video data into a bitstream, wherein the encoding of the video blocks includes: Context information is derived from the encoded data of neighboring video blocks located within the neighborhood of the video block, the derivation being based on the spatial position of the neighboring video blocks relative to the video block, and The context information is used to encode the syntax elements into the bitstream.

Images