Generating enhanced contextual information for video codecs that feature adaptive change of coding order

Abstract

Apparatuses and methods are disclosed, including techniques for encoding and decoding a video block of video data. Techniques disclosed include deriving contextual information from coding data of video blocks located within a neighborhood of the coded (or decoded) video block, where the deriving of contextual information is based on spatial locations of the neighboring video blocks relative to the video block; and then, using the contextual information, coding into (or decoding from) the bitstream a syntax element. Techniques disclosed further include deriving the contextual information based on a coding order of the neighboring video blocks.

Description

GENERATING ENHANCED CONTEXTUAL INFORMATION FOR VIDEOCODECS THAT FEATURE ADAPTIVE CHANGE OF CODING ORDERCROSS REFERENCE TO RELATED APPLICATIONS[1] This application claims the benefit of European Application No. 23306515.0, filed on September 13, 2023, which is incorporated herein by reference in its entirety.BACKGROUND[2] Context-based adaptive binary arithmetic coding (CABAC) is commonly used by hybrid block-based video codecs to context-code syntax elements taking into account their probabilistic distributions. Generally, contextual information is generated from video blocks in the neighborhood of a video block being coded based on which a syntax element (representing the video block) is context-coded. However, as implemented in recent video standards, the order in which the neighboring blocks are coded is not considered when generating the contextual information. Moreover, the neighboring blocks of which data are used to generate the contextual information are not spatially prioritized. Yet, depending on the semantic of the syntax element, considering the coding order and / or the spatial locations of the neighboring blocks when generating contextual information may be critical for coding efficiency.SUMMARY[3] Aspects disclosed in the present disclosure describe methods for encoding a video block of video data into a bitstream. The encoding of the video block comprises deriving contextual information from coding data of neighboring video blocks located within a neighborhood of the video block, where the deriving of the contextual information is based on spatial locations of the neighboring video blocks relative to the video block. And then coding into the bitstream a syntax element using the contextual information. Aspects disclosed in the present disclosure also describe methods for decoding a video block of video data from a bitstream. The decoding of the video block comprises deriving contextual information from coding data of neighboring video blocks located within a neighborhood of the video block, where the deriving of the contextual information is based on spatial locations of the neighboring video blocks relative to the video block. And then decoding from the bitstream a syntax element using the contextual information.[4] Aspects disclosed in the present disclosure describe an apparatus for encoding a video block of video data. The apparatus comprises at least one processor and memory storing instructions. The instructions, when executed by the at least one processor, cause the apparatus to code the video block into a bitstream. The encoding of the video block comprises deriving contextual information from coding data of neighboring video blocks located within a neighborhood of the video block, where the deriving of the contextual information is based on spatial locations of the neighboring video blocks relative to the video block. And then coding into the bitstream a syntax element using the contextual information. Aspects disclosed in the present disclosure also describe an apparatus for decoding a video block of video data. The apparatus comprises at least one processor and memory storing instructions. The instructions, when executed by the at least one processor, cause the apparatus to decode the video block from a bitstream. The decoding of the video block comprises deriving contextual information from coding data of neighboring video blocks located within a neighborhood of the video block, where the deriving of the contextual information is based on spatial locations of the neighboring video blocks relative to the video block. And then decoding from the bitstream a syntax element using the contextual information.[5] Further aspects disclosed in the present disclosure describe a non-transitory computer- readable medium comprising instructions executable by at least one processor to perform methods for encoding a video block of video data into a bitstream. The coding of the video block comprises deriving contextual information from coding data of neighboring video blocks located within a neighborhood of the video block, where the deriving of the contextual information is based on spatial locations of the neighboring video blocks relative to the video block; and coding into the bitstream a syntax element using the contextual information. Aspects disclosed in the present disclosure also describe a non-transitory computer-readable medium comprising instructions executable by at least one processor to perform methods for decoding a video block of video data into a bitstream. The decoding of the video block comprises deriving contextual information from coding data of neighboring video blocks located within a neighborhood of the video block, where the deriving of the contextual information is based on spatial locations of the neighboring video blocks relative to the video block. And then decoding from the bitstream a syntax element using the contextual information.[6] This Summary is provided to introduce a selection of concepts in a simplified form that is further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used tolimit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that solve any or all disadvantages noted in any part of this disclosure.BRIEF DESCRIPTION OF THE DRAWINGS[7] FIG. 1 is a block diagram of an example system, according to which aspects of the present embodiments can be implemented.[8] FIG. 2 is a block diagram of an example video encoder, according to which aspects of the present embodiments can be implemented.[9] FIG. 3 is a block diagram of an example video decoder, according to which aspects of the present embodiments can be implemented.

[0010] FIG. 4 is a diagram illustrating four coding orders, according to which aspects of the present embodiments can be implemented.

[0011] FIG. 5 is a diagram illustrating flipping of a coding tree unit, according to which aspects of the present embodiments can be implemented.

[0012] FIG. 6 is a diagram illustrating scanning orders of sub-blocks arising from a split, according to which aspects of the present embodiments can be implemented.

[0013] FIG. 7 is a diagram illustrating a flipping of a block and its reference samples, according to which aspects of the present embodiments can be implemented.

[0014] FIG. 8 is a diagram illustrating a rotation of a block and its reference samples, according to which aspects of the present embodiments can be implemented.

[0015] FIG. 9 is a diagram illustrating horizontal coding orders, according to which aspects of the present embodiments can be implemented.

[0016] FIG. 10 is a flowchart of an example method for decoding a SUCO flag, according to which aspects of the present embodiments can be implemented.

[0017] FIG. 11A-B is a flowchart of an example method for decoding a split type, according to which aspects of the present embodiments can be implemented.

[0018] FIG. 12 is a flowchart of an example method for decoding a coding mode flag, according to which aspects of the present embodiments can be implemented.

[0019] FIG. 13 is a flowchart of an example method for decoding an intra block copy (IBC) flag, according to which aspects of the present embodiments can be implemented.

[0020] FIG. 14 is a flowchart illustrating a first aspect of decoding a syntax element, according to which aspects of the present embodiments can be implemented.

[0021] FIG. 15 is a flowchart illustrating a second aspect of decoding a syntax element, according to which aspects of the present embodiments can be implemented.

[0022] FIG. 16 is a flowchart illustrating a variant of the first aspect of decoding a syntax element, according to which aspects of the present embodiments can be implemented.

[0023] FIG. 17 is a flowchart illustrating a third aspect of decoding a syntax element, according to which aspects of the present embodiments can be implemented.

[0024] FIG. 18 is a flowchart illustrating a fourth aspect of decoding a syntax element, according to which aspects of the present embodiments can be implemented.

[0025] FIG. 19 is a flowchart, including a diagram, illustrating an application of the third aspect (illustrated in FIG. 17) to the decoding of a split type, according to which aspects of the present embodiments can be implemented.

[0026] FIG. 20 is a flowchart, including a diagram, illustrating an application of the third aspect (illustrated in FIG. 17) to the decoding of a split type, according to which aspects of the present embodiments can be implemented.

[0027] FIG. 21 is a flowchart, including a diagram, illustrating an application of the fourth aspect (illustrated in FIG. 18) to the decoding of a split type, according to which aspects of the present embodiments can be implemented.

[0028] FIG. 22 is a flowchart, including a diagram, illustrating an application of the third aspect (illustrated in FIG. 17) to the decoding of an IBC flag, according to which aspects of the present embodiments can be implemented.

[0029] FIG. 23 is a flowchart, including a diagram, illustrating an application of the first aspect (illustrated in FIG. 14) to the decoding of an IBC flag, according to which aspects of the present embodiments can be implemented.

[0030] FIG. 24 is a flowchart, including a diagram, illustrating an application of the first aspect (illustrated in FIG. 14) to the decoding of a matrix-based intra-prediction (MIP) flag, according to which aspects of the present embodiments can be implemented.

[0031] FIG. 25 A-B is a flowchart, including a diagram, illustrating an application of the second aspect (illustrated in FIG. 15) to the decoding of an intra-prediction mode index, according towhich aspects of the present embodiments can be implemented.

[0032] FIG. 26A-C is a flowchart, including a diagram, illustrating an application of the second aspect (illustrated in FIG. 15) to the derivation of the most probable modes (MPMs) list, according to which aspects of the present embodiments can be implemented.

[0033] FIG. 27 is a flowchart, including a diagram, illustrating an application of the first aspect (illustrated in FIG. 14) to the decoding of an MIP flag, according to which aspects of the present embodiments can be implemented.

[0034] FIG. 28 is a flowchart of an example method for encoding video data, according to which aspects of the present embodiments can be implemented.

[0035] FIG. 29 is a flowchart of an example method for decoding video data, according to which aspects of the present embodiments can be implemented.DETAILED DESCRIPTION

[0036] Apparatuses and methods are presented herein for encoding and decoding of video data. According to aspects disclosed herein, enhanced contextual information, used for the signaling and decoding of syntax elements representing a video block of the video data, is generated. These aspects may be applicable to video codecs that feature adaptive block-level change of coding order (generally referred to herein as video codec(s)) - video codecs such as the hybrid block-based video coding and decoding systems described with respect to FIGS. 1-3. Various approaches for designing a video codec with an adaptive block-level change of coding order are described herein with respect to FIGS. 4-13. Aspects of generating contextual information are disclosed herein in reference to FIGS. 14-18 and 28-29. Therein contextual information can be generated based on the coding order of video blocks within the neighborhood of the video block being coded (or decoded) while spatially balancing the influence of the contextual information derived from these neighboring video blocks, as demonstrated by applications of these aspects disclosed herein in reference to FIGS. 19-27.

[0037] FIG. 1 illustrates a block diagram of an example system 100. System 100 can be embodied 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. Elements of system 100, singly or in combination,can be embodied in an integrated circuit, 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, the system 100 is communicatively coupled to other systems, or to other electronic devices, via, for example, a communications bus or through dedicated input and / or output ports.

[0038] The system 100 includes at least one processor 110 that can be configured to execute instructions loaded therein for implementing, for example, the various aspects described in this application. Processor 110 can include embedded memory, input and output interfaces, and various other circuitries as known in the art. The 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 can include non-volatile memory and / or volatile memory, such as EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, magnetic disk drives, and / or optical disk drives. The storage device 140 can be an internal storage device, an attached storage device, and / or a network accessible storage device, for example.

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

[0040] Program code that is to be loaded into processor 110 or into encoder / decoder 130 to perform the various aspects described in this application can be stored in a storage device 140 and subsequently loaded into memory 120 for execution by processor 110. In accordance with various embodiments, one or more of processor 110, memory 120, storage device 140, and encoder / decoder module 130 can store one or more of various items during the performance of the processes described in this application. Such stored items can include, but are not limited to, the input video, the decoded video or portions of the decoded video, the bitstream, matrices, variables, operational logic, and intermediate or final results from the processing of equations, formulas, operations.

[0041] In several embodiments, memory inside of the processor 110 and / or theencoder / decoder module 130 is used to store instructions and to provide working memory for processing functions that are needed during encoding or decoding. In other embodiments, however, memory external to the processing device (where, for example, the processing device can be either the processor 110 or the encoder / decoder module 130) can be used for one or more of these functions. The external memory can be the memory 120 and / or the storage device 140 that may comprise, for example, a dynamic volatile memory and / or a non-volatile flash memory. In several embodiments, an external non-volatile flash memory is used to store the operating system of a television. In at least one embodiment, a fast external dynamic volatile memory such as a RAM is used as working memory for video coding and decoding operations.

[0042] The input to the elements of system 100 can be provided through various input devices as indicated in block 105. Such input devices include, but are not limited to, (i) an RF portion that receives an RF signal transmitted, for example, 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 devices of block 105 have associated respective input processing elements as known in the art. For example, the RF portion can be associated with elements suitable for (i) selecting a desired frequency (also referred to as selecting a signal, or band-limiting a signal to a band of frequencies), (ii) down-converting the selected signal, (iii) band-limiting again to a narrower band of frequencies to select, for example, a signal frequency band which can be referred to as a channel in certain embodiments, (iv) demodulating the down converted and band-limited signal, (v) performing error correction, and (vi) demultiplexing to select the desired stream of data packets. The RF portion of various embodiments includes one or more elements that perform these functions, for example, frequency selectors, signal selectors, band-limiters, channel selectors, filters, downconverters, demodulators, error correctors, and demultiplexers. The RF portion can include a tuner that performs some of these functions, including, for example, down-converting the received signal to a lower frequency (for example, an intermediate frequency or a near-baseband frequency) or to a baseband. In one set-top box embodiment, the RF portion and its associated input processing element receive an RF signal transmitted over a wired (for example, cable) medium, and perform frequency selection by filtering, down-converting, and filtering again to a desired frequency band. Various embodiments rearrange the order of the above-described (and other) elements, remove some of these elements, and / or add other elements performing similar or different functions. Added elements can include inserting elements in between existing elements, for example,inserting amplifiers and an analog-to-digital converter. In various embodiments, the RF portion includes an antenna.

[0044] Additionally, the USB and / or HDMI terminals can include respective interface processors for connecting system 100 to other electronic devices across USB and / or HDMI connections. It is to be understood that various aspects of input processing, for example, Reed- Solomon error correction, can be implemented, for example, within a separate input processing integrated circuit or within processor 110 as necessary. Similarly, aspects of USB or HDMI interface processing can be implemented within separate interface integrated circuits or within processor 110 as necessary. The demodulated, error corrected, and demultiplexed stream is provided to various processing elements, including, for example, processor 110, and encoder / decoder 130 operating in combination with the memory and storage elements to process the data stream as necessary for presentation on an output device.

[0045] Various elements of system 100 can be provided within an integrated housing. Within the integrated housing, the various elements can be interconnected and transmit data therebetween using a suitable connection arrangement 115, for example, an internal bus as known in the art, including the I2C bus, wiring, and printed circuit boards.

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

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

[0048] The system 100 can provide an output signal to various output devices, including adisplay device 165, an audio device (e.g., speaker(s)) 175, and other peripheral devices 185. The other peripheral devices 185 include, in various examples of embodiments, one or more of a stand-alone DVR, a disk player, a stereo system, a lighting system, and other devices that provide a function based on the output of the system 100. In various embodiments, control signals are communicated between the system 100 and the display device 165, the audio device 175, or the 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. The output devices can be communicatively coupled to system 100 via dedicated connections through respective interfaces 160, 170, and 180. Alternatively, the output devices can be connected to system 100 using the communication channel 190 via the communication interface 150. The display device 165 and the audio device 175 can be integrated in a single unit with the other components of system 100 in an electronic device, for example, a television. In various embodiments, the display interface 160 includes a display driver, for example, a timing controller (T Con) chip.

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

[0050] FIG. 2 illustrates a functional block diagram of an example video encoder 200. The video encoder 200 can be employed by the system 100 described in reference to FIG. 1. For example, the video encoder 200 can be an encoder that operates according to coding standards such as Advanced Video Coding (AVC, H.264 / MPEG-41 ISO / IEC 14496-10), High Efficiency Video Coding (HEVC, ITU-T H.265 | ISO / IEC 23008-2), or Versatile Video Coding (VVC, Standard ITU-T H.266, ISO / IEC 23090-3, 2020).

[0051] Prior to undergoing encoding, the video data can be pre-processed by a precoding processor (not shown). Such pre-processing can include applying a color model transform to the color components of the input video frames (e.g., conversion from RGB 4:4:4 to YCbCr 4:2:0) or mapping the color components of the input video frames to obtain a signal distribution that is more resilient to compression (for instance, applying a histogram equalizer and / or a denoising filter to one or more of the video frames’ color components). The pre-processing can also include associating metadata with the video data that can be attached to the coded video bitstream.

[0052] In the encoder 200, a video frame is encoded by the encoder elements as generally described below. A picture (frame) of the original video to be encoded is partitioned into coding units (namely, original blocks) by an image partitioner 202. Typically, a coding unit (CU) contains a luminance block and respective chroma blocks, and so, generally, operations described herein as applied to a CU are applied to the luminance block and to the respective chroma blocks. Following partition 202, each CU can be encoded using an intra-prediction mode or an inter-prediction mode. In an intra-prediction mode, a prediction of the CU is performed by an intra-predictor 260. In the intra-prediction mode, the content of a CU in a frame is predicted based on content from one or more other CUs of the same frame, using the other CUs’ reconstructed version (available from the adder 255 output). In an inter-prediction mode, motion estimation and motion compensation are performed by a motion estimator 275 and a motion compensator 270, respectively. In the inter-prediction mode, the content of a CU in a frame is predicted based on content from one or more other CUs of neighboring frames, using the other CUs’ reconstructed versions (available from the reference picture buffer 280). The encoder decides 205 which prediction result (one obtained through operations in the intraprediction mode 260 or one obtained through operations in the inter-prediction mode 270, 275) to use for encoding a CU, and indicates the selected prediction mode by a prediction mode flag, for example. The selected prediction result may then be enhanced (e.g., filtered) by a prediction enhancer 285, outputting a respective prediction block. Once a prediction block is generated for each CU, a respective residual block is calculated, for example, by subtracting 210 the predicted CU (i.e., prediction block) from the CU (i.e., original block).

[0053] A CU’s respective residual block or a partition thereof (i.e., a transform block) is then transformed into a coefficient block by a transformer 220 - that is, residual samples of the transform block are transformed into transform coefficients of the coefficient block. The resulting coefficient block is quantized by a quantizer 230. An entropy encoder 245 is next employed to entropy-encode the quantized coefficient block and respective coding parameters (e.g., syntax elements including motion vectors and other control data). Hence, the entropy- encoded quantized coefficient blocks and respective encoding parameters associated with each video frame of the original video are packed into the bitstream of the coded video data.

[0054] Along with the coding of the original video blocks, as described above, the encoder 200 reconstructs the coded original blocks to provide references for future predictions. Accordingly, quantized coefficient blocks (provided by the quantizer 230) are de-quantized, by an inverse quantizer 240, and then inverse transformed, by an inverse transformer 250, to reconstruct(decode) the residual blocks of respective original blocks. Adding 255 the reconstructed residual blocks to respective prediction blocks results in respective reconstructed original blocks. In-loop filters 265 can then be applied to the reconstructed picture (formed by the reconstructed original blocks), performing, for example, deblocking filtering and / or sample adaptive offset (SAO) filtering to reduce encoding artifacts. The filtered reconstructed picture can then be stored in the reference picture buffer 280, available for future predictions in an inter-prediction mode. Thus, the encoder 200 also performs decoding operations 240, 250 through which the encoded pictures (frames) are reconstructed. The reconstructed pictures can then be stored in the reference picture buffer 280 and be used to facilitate motion estimation 275 and compensation 270, as explained above.

[0055] FIG. 3 illustrates a functional block diagram of an example video decoder 300. The video decoder 300 can be employed by the system 100 described in reference to FIG. 1. Generally, operational aspects of the video decoder 300 are reciprocal to operational aspects of the video encoder 200. In the decoder 300, the bitstream of coded video data, generated by the video encoder 200, is first entropy-decoded by an entropy decoder 330, decoding from the bitstream the quantized coefficient blocks and various coding parameters. The quantized coefficient blocks are de-quantized, by an inverse quantizer 340, and then are inverse transformed, by an inverse transformer 350, to decode (reconstruct) respective residual blocks. Adding 355 the reconstructed residual blocks to respective prediction blocks results in respective reconstructed original blocks. Depending on the selected prediction mode, a predicted original block can be obtained 370 from an intra-predictor 360 or from a motion compensator 375 and may then be enhanced (e.g., filtered) by a prediction enhancer 390, generating a prediction block. In-loop filters 365 can be applied to the reconstructed picture (formed by the reconstructed original blocks), outputting a reconstructed (decoded) video frame. The filtered reconstructed picture is also stored in a reference picture buffer 380 to facilitate motion compensation 375.

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

[0057] Aspects disclosed herein are described in reference to video blocks (i.e., blocks) of avideo frame. However, the described aspects are similarly applicable to any region of the video frame to which coding tools may be applied to by an encoder 200 or by a decoder 300. Generally, aspects described herein may be applied to a video data region, formed by a video partition, of any shape or size. The video region may be a Coding Tree Unit (CTU) or a CU (for which an inter-prediction or an intra-prediction can be applied) or a partition thereof, including a luma component, F, and chroma components, Cr and Cb.

[0058] Aspects disclosed herein introduce techniques for generating enhanced contextual information, applicable to video codecs that feature an adaptive block-level change of coding order. Various approaches for designing a video codec with an adaptive block-level change of coding order that are built on top of the High Efficiency Video Coding (HEVC) standard are described herein with respect to FIGS. 4-8. Other approaches for designing a video codec with adaptive block-level change of horizontal coding order, implemented in the Essential Video Coding (EVC) standard, are next described with respect to FIGS. 9-13. Note that, for simplicity, only the luma component of a video block is referred to herein and / or illustrated in the figures; however, aspects described herein similarly applicable to the chroma components of the video blocks. Note also that availability of a CU generally referred to herein as the availability of coding data (e.g., a coding parameter) representing the CU.

[0059] An adaptive block-level change of coding order, mainly developed on top of the HEVC standard, can be divided into two categories. In the first category, all the CUs in a CTU share the same coding order. Thus, for a given CTU, the encoder tests several coding orders, and the coding order that yields the minimum rate-distortion cost is selected and signaled to the decoder (see, A. Zheng, et al., Adaptive block coding order for intra-prediction in HEVC, IEEE Transactions on Circuits and Systems for Video Technology, vol. 26, no. 11. November 2016, hereinafter “Zheng-1”; and A. Zheng, et al., Intra-prediction with adaptive CU processing order in HEVC, IEEE International Conference on Image Processing, 2014, hereinafter “Zheng-2”). In the second category, for a given CTU or CU that is to be split, the encoder tests several orders for scanning the sub-blocks resulting from this split, and the order that provides the minimum rate-distortion cost is selected and signaled to the decoder (see, L. Guo, et al., Hierarchical quadtree-based flexible block ordering in HEVC intra coding, Visual Communications and Image Processing, 2016, hereinafter “Guo”). Relative to the first category (where the coding order is determined at the CTU level, that is, where all the CUs in a CTU are required to follow the same coding order), the second category (where the coding order is determined at each split of a CTU or a CU) provides more flexibility in changing the codingorder. The two categories for adaptive block-level change of coding order are further described below.

[0060] FIG. 4 is a diagram illustrating four coding orders according to which blocks (e.g., CUs) of a CTU can be coded 400. Therein, in (a), the coding order is from top to bottom and from left to right (as in HEVC); in (b), the coding order is from bottom to top and from left to right; in (c), the coding order is from bottom to top and right to left; and, in (d), the coding order is from top to bottom and from right to left. The CUs, in each of these coding orders, are numbered according to the coding order and the gray dotted arrows indicate the sequential coding path (shown only for several of the first CUs in the CTU). In the first category, where the coding order is determined at the CTU level, the determined coding order is signaled for each CTU. Thus, on the encoder side, for a given CTU in the currently encoded frame (i.e., the current frame), these four coding orders are tested for all the CUs of the CTU, and the coding order that results in the minimum rate-distortion cost is used by the encoder and signaled to the decoder (e.g., via a fixed length code).

[0061] Changing the coding order at the CTU level can be implemented by a video codec following the HEVC standard as follows. On the encoder side, if an original CTU is to be encoded using a coding order for its CUs that is different from that defined in the HEVC standard (i.e., order (a) in FIG. 4), then, first, the original CTU and its reference samples are flipped such that the coding order of the CUs in the flipped CTU is according to order (a) (see, Zheng-1). Next, the flipped CTU can be encoded via the unmodified HEVC coding tools. Following reconstruction, the reconstructed flipped CTU can be flipped back, resulting in a reconstructed original CTU. On the decoder side, a similar flipping policy can be applied to a CTU to be decoded when the used coding order is different from that defined in the HEVC standard.

[0062] FIG. 5 is a diagram illustrating flipping of a CTU 500. In the example of FIG. 5, if an original CTU is to be encoded using the coding order for its CUs from bottom to top and from right to left, then the original CTU and its reference samples are flipped with respect to the horizontal axis and then with respect to the vertical axis to obtain a flipped CTU whose CUs are ordered in the same order as defined in the HEVC standard (i.e., order (a) in FIG. 4), as shown on the left part of FIG. 5. Note that, in the original CTU and in its flipped version, the CUs are numbered following their coding order. For example, a fourthly coded CU (i.e., CU=3) and its available reference samples, before and after the flipping, are shown on the right part of FIG. 5.

[0063] In the case where the coding order is determined at a split level, the determined coding order is signaled at each split of a CTU or a CU. As described in Guo, several orders for scanning the sub-blocks arising from a split can be used. Guo proposes 8 different orders for scanning the four sub-blocks arising from a split, in the case where a given CTU or CU is split via quad tree (QT) exclusively, as illustrated in FIG. 6.

[0064] FIG. 6 is a diagram illustrating scanning orders of sub-blocks arising from a split 600. Thus, at the encoder end, for a given CTU or CU to be split via QT splitting, the order of scanning of the resulting four sub-blocks has to be determined. To that end, the encoder tests the 8 scanning orders shown in the example of FIG. 6, and the order yielding the minimum rate-distortion cost is retained and signaled to the decoder (e.g., via a fixed length code). In the HEVC standard, when using this adaptive change of coding (or scanning) order, if an 8 x 8 CU is split into 4 Prediction Units (PUs), the order for scanning these PUs is inherited from the coding order of the parent 8 x 8 CU. Likewise, if the residue of a CU is split into 4 Transform Units (TUs), the order for scanning these TUs is the same as the coding order of the parent CU.

[0065] Changing the coding order at the CTU or CU split level can be implemented by a video codec following the HEVC standard as follows. On the encoder side, for a given original CU, if the relative positioning of this original CU and its reference samples does not match that in HEVC, Guo suggests a method for reusing the HEVC intra-prediction mechanisms during the intra-prediction of an original block in this original CU. Specifically, both this original block and its reference samples are rotated or flipped such that the relative positioning of the rotated or flipped original block and its rotated or flipped reference samples matches that defined in the HEVC standard. Then, the rotated or flipped original block can be predicted via an unmodified HEVC intra-prediction tool. The predicted block is then rotated or flipped back, resulting in a predicted block that corresponds to the predicted original block. On the decoder side, a similar rotation or flipping policy can be applied to an original CU when the relative positioning of a block in this CU and its reference samples does not match that defined in the HEVC standard.

[0066] FIG. 7 is a diagram illustrating a flipping of a block and its reference samples 700. Therein, for an original CTU currently being encoded, original luma blocks are numbered following a coding order (see top-left part of FIG. 7). The original luma blocks numbered 0 to 8 (denoted in dark gray) are already reconstructed. However, the original luma blocksnumbered 9 to 21 (denoted in white) are not encoded yet. The original luma block that is to be next predicted and its reference samples (see bottom-left part of FIG. 7) are flipped with respect to the vertical axis to obtain a flipped original luma block and its flipped reference samples whose relative positioning matches that defined in the HEVC standard (see bottom-right part of FIG. 7).

[0067] FIG. 8 is a diagram illustrating a rotation of a block and its reference samples 800. Therein, for an original CTU currently being encoded, its original luma blocks are numbered following a coding order (see top-left part of FIG. 8). The original luma blocks numbered 0 to 8 (denoted in dark gray) are already reconstructed. However, the original luma blocks numbered 9 to 21 (denoted in white) are not encoded yet. The original luma block to be next predicted and its reference samples (see bottom-left part of FIG. 8) are rotated by 90 degrees clockwise to obtain a rotated original luma block and its rotated reference samples whose relative positioning matches that defined in the HEVC standard (see bottom-right part of FIG. 8).

[0068] Unlike the approach described in Zhang-1 and Zhang-2, the approach described in Guo is not limited to reusing the HEVC coding mechanism (as described above with reference to FIGS. 5 and 7). Indeed, Guo exploits the new arrangement of available reference samples that may appear around the current block to be predicted, depending on the history of splitting and changing of coding orders leading to the current block. More precisely, for a current block to be predicted, after a potential rotation / flipping of this block and its reference samples, if reference samples below or on the right side of the rotated / flipped current block are available, as shown in FIG. 8, the intra-prediction of the rotated / flipped current block become bilinear whenever possible. Otherwise (in the case where none of the reference samples below and on the right side of the rotated / flipped current block is available), the unaltered HEVC intraprediction is used. Another approach, similar to that proposed in Guo, also includes adaptively changing the coding order (see, I. Matsuda, et al., Interpolative intra-prediction by adapting processing order in block-based image coding, IEEE International Conference on Image Processing, 2013, hereinafter “Matsuda”). Even though the intra-prediction proposed by Matsuda exploits the new arrangement of available reference samples that may occur around the current block to be predicted, it differs slightly from that described in Guo as Matsuda also favors bilinear intra-prediction whenever possible.

[0069] An adaptive block-level change of horizontal coding order, as implemented in the EVC standard, is described next with respect to FIGS. 9-13.

[0070] In the EVC standard, via a process called Split Unit Coding Order (SUCO), the coding order can be signaled for a given split. Specifically, for a given frame, during the partitioning of a given CTU, if a CU is split via a vertical split, then a SUCO flag is signaled to indicate the horizontal order for coding (or scanning) the CUs arising from this split - that is, either left-to- right or right-to-left. Since three families of splits - quad tree (QT), binary tree (BT), and ternary tree (TT) - are defined in the EVC standard (as in the Versatile Video Coding (VVC) standard), a vertical split is defined as being either Vertical BT (BT_V) or Vertical TT (TT_V) or QT, as illustrated in FIG. 9.

[0071] FIG. 9 is a diagram illustrating horizontal coding orders 900. FIG. 9 demonstrates orders (either left to right or right to left) for coding the children CUs that result from three possible vertical splits of a given parent CU. As shown in the left part of FIG. 9, a given parent CU has a size denoted by W*H. A vertical split of that parent CU can be according to a vertical binary tree (denoted BT_V), according to a vertical ternary tree (denoted TT_V), or according to a quad tree (denoted QT). Similarly, in the EVC standard, a parent CU can be split according to a horizontal binary tree (BT_H) or a horizontal ternary tree (TT_H). Note that, although a given unit to be split is called a Split Unit (SU) in the EVC standard or in related literature (see, Y. Piao, et al., Split unit coding order for video coding, IEEE International Conference on Multimedia and Expo, 2021, hereinafter “Piao”), an SU is equivalent to a CU in the VVC standard. Note also that the SUCO process features a parametrized minimum CU size. This means that if the split of a parent CU gives rise to children CUs of sizes smaller than the SUCO’s minimum CU size, then the order for coding these children CUs is not signaled but inherited from the coding order of their parent CU, as described in Piao.

[0072] At the EVC encoder, full rate-distortion optimization applies to the SUCO process. Specifically, in a given CTU, for a given CU to be split via a vertical split (if the sizes of the CU children arising from the split are not smaller than the SUCO minimum CU size) the orders left-to-right and right-to-left for coding its children are tested, and the order that yields the minimum rate-distortion cost is kept and signaled to the decoder. Hence, SUCO can be viewed as a specialization of the proposition in Guo to a video codec featuring QT, BT, and TT split families where only horizontal (left-to-right or right-to-left) coding orders are allowed.

[0073] CAB AC is used by video codecs to context-code syntax elements taking under consideration their respective probabilistic distributions. CAB AC can be used to context-code a SUCO flag. When splitting a given CU via a vertical split, the SUCO flag is signaled by the encoder to indicate to the decoder the order in which CUs arising from the split were coded(i.e. , left-to-right or right-to-left). However, in addition to the SUCO condition for minimum CU size, many other conditions may cancel the need for signaling the SUCO flag for a CU. When signaled, the SUCO flag can be context-coded using CAB AC. FIG. 10 demonstrates the decoding of a signaled SUCO flag, associated with a CU to be potentially split, according to the ETM-7 decoder (i.e., the current version of the software model of the EVC standard).

[0074] FIG. 10 is a flowchart of an example method for decoding of a SUCO flag. FIG. 10 illustrates the decoding of the SUCO flag, of a given CU to be potentially split, at the ETM-7 decoder. Therein, the following variables are defined as follows.• widthCU x heightCU denote the size of the CU.• splitMode denotes the type of split applied to the CU, that is, splitMode G {NO_SPLIT, BT_H, BT_V, TT_H, TT_V, QT}, where NO_SPLIT indicates no split.• isBoundary is a flag, set to true if the CU overlaps a boundary of the current frame.• sucoFlag denotes the SUCO flag associated with the CU.• sucoFlagParent denotes the SUCO flag associated with the parent CU of the CU.• decodeBin is a function call that reads the current bin using the input CABAC context index.• idxCtxSucoFlag denotes the index whose incrementation yields a CABAC’s context index for decoding the SUCO flag. In ETM-7, idxCtxSucoFlag = 513.• logZMaxCuwh is a sequence parameter set (SPS) parameter denoting a logarithm basis 2 of the maximum CU luma height / width (a default value of 7 is set in the ETM- 7 encoding configuration).• logZDiffCtuSizeMaxSucoCbSize is an SPS parameter denoting the difference between the logarithm basis 2 of the maximum CU luma height / width and the logarithm basis 2 of the maximum luma height / width of a CU for which SUCO applies (a default value of 1 is set in the ETM-7 encoding configuration).• logZDiffMaxSucoMinSucoCbSize is an SPS parameter denoting the difference between log2MaxCuwh — log2DiffCtuSizeMaxSucoCbSize and the logarithm basis 2 of the minimum luma height / width of a CU for which SUCO applies (a default value of 2 is set in the ETM-7 encoding configuration).• logZminCuSize is an SPS parameter denoting a logarithm basis 2 of the minimum CU luma height / width (a default value of 2 is set in the ETM-7 encoding configuration).• sucoLogZMaxsize = min(log2MaxCuwh — log2DiffCtuSizeMaxSucoCbSize, 6)• isSmallerSucoMin = min(widthCU, heightCU) < 1 « max(sucoLog2Maxsize — log2DiffMaxSucoMinSucoCbSize, max(4, log2minCuSize)) .• isLargerSucoMax = max(widthCU, heightCU) > (1 « sucoLog2 Maxsize).• inNoSplitHor = splitMode == NO_SPLIT | | splitMode == BT_H | | splitMode = = TT_H.• isQtCond = splitMode ! = QT && widthCU < heightCU.

[0075] Referring to FIG. 10, at 1000, the decoding of a SUCO flag is triggered for a given CU to be potentially split. At 1001, a condition - depending on the size of the CU, whether the CU overlaps a boundary of the current frame, and the type of the split associated with the CU - determines whether to proceed to either 1002 or 1003. If the condition at 1001 is true, at 1002, the SUCO flag of the CU is not read from the bitstream but inherited from the SUCO flag of the parent CU of the given CU. If the condition at 1001 is false, the SUCO flag of this CU is read from the bitstream. To that end, at 1003, the incrementation idxCtx of the CABAC context index used to decode the SUCO flag is derived based on the size of the CU. At 1004, the SUCO flag of the CU is read from the bitstream using the CABAC ’s context index idxCtxSucoFlag + idxCtx.

[0076] The type of split associated with a CU to be potentially split - that is, the splitMode - can also be signaled. FIG. 11A-B demonstrates the decoding, by the ETM-7 decoder, of the signaled split type.

[0077] FIG. 11 A-B is a flowchart of an example method for decoding a split type. FIG. 11 A- B illustrates decoding of the split type for a given CU to be potentially split at the ETM-7 decoder. Therein, the following variables are defined as follows.• widthCU x heightCU denote the size of the CU.• splitMode denotes the type of split of the CU. Assuming “sps_btt_flag” is equal to 1 (i.e., BT and TT are used), splitMode E {NO_SPLIT, BT_H, BT_V, TT_H, TT_V}, where NO_SPLIT indicates no split.• checkSplitMode is a function call that sets the splitAllow array based on widthCU, heightCU, and whether this CU overlaps a boundary of the current frame, where splitAllow[i] , i E {NO_SPLIT, BT_H, BT_V, TT_H, TT_V}. The splitAllow arrayindicates whether the type of split i is allowed.• smaller[0] is a flag that is set to true if the CU above the given CU is available and its width is strictly smaller than widthCU.• smallerfl] is a flag that is set to true if the CU on the left side of the given CU is available and its height is strictly smaller than heightCU.• smaller[2] is a flag that is set to true if the CU on the right side of the given CU is available and its height is strictly smaller than heightCU.• decodeBin is a function call that reads the current bin using the input CABAC context index.• The idxCtxBttSplitFlag, idxCtxBttSplitDir, and idxCtxBttSplitType variables each denotes a different index whose incrementation yields a CABAC context index for respectively decoding the BttSplitFlag, BttSplitDir, and BttSplitType flags.

[0078] Referring to FIG. 11 A, at 1100, for a given CU to be potentially split, the decoding of its associated type of split is triggered. At 1101, if widthCU and heightCU are strictly smaller 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, based on widthCU and heightCU, the splitAllow array is determined. The array elements, splitAllow[i] for i E {NO_SPLIT, BT_H, BT_V, TT_H, TT_V}, indicate whether the respective split types are 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 widthCU, heightCU, and the size of neighboring available CUs, the incrementation idxCtx of the CABAC context index used to decode the flag at 1106 is computed. 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 FIG. 1 IB). Otherwise, the process proceeds to 1102.

[0079] Referring to FIG. 11B, at 1108, if, within the pair of split families BT and TT, both vertical and horizontal splits are allowed, the process proceeds to 1110. Otherwise, the process proceeds to 1109. At 1109, the flag bttSplitDir is inferred from splitAllow. At 1110, the incrementation idxCtx of the CABAC context index used to decode 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. From either 1109 or 1111, the process proceeds to 1112. At 1112, if at least one of the two conditions (that is, 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 inside the 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 inside the 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. From either 1113 or 1114, the process proceeds to 1115. At 1115, if bttSplitType is true, the process proceeds to 1117. Otherwise, it proceeds to 1116. At 1116, within the BT family of splits, splitMode is defined based on bttSplitDir. At 1117, within the TT family of splits, splitMode is defined based on bttSplitDir.

[0080] Flags of coding modes associated with a CU can be signaled using a unified process. FIG. 12 shows the signaling of a coding mode flag - that is, a modeFlag - of a given CU at the ETM-7 decoder.

[0081] FIG. 12 is a flowchart of an example method for decoding a coding mode flag. FIG. 12 illustrates a unified process for decoding the mode flag of a given CU at the ETM-7 decoder. Therein, the following variables are defined as follows.• modeFlag denotes the coding mode flag of the CU.• nevlnfo[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.• nevlnfo[l] is a flag that is set to true if the CU on the left side of the given CU is available and the modeFlag of the “left” CU is set to to 1.• nevlnfo[2] is a flag that is set to true if the CU on the right side of the given CU is available and the modeFlag of the “right” CU is equal to 1.• sps_cm_init_flag a flag that is set to true if the CABAC context models have already been initialized.• idxCtxBase denotes the index whose incrementation yields a CABAC context index for decoding the modeFlag. The value of idxCtxBase depends on the semantic of the mode flag.• limit is the maximum value of the incrementation idxCtx of the CABAC context index used to decode modeFlag.• decodeBin is a function call that reads the current bin using the input CABAC contextindex.

[0082] In reference to FIG. 12, at 1200, for the given CU, the decoding of the coding mode flag, modeFlag, is triggered. At 1201, nevlnfo is defined from the modeFlag of each of 3 neighboring CUs. From 1202 to either 1204 or 1205, the incrementation idxCtx of the CABAC context index, used to decode modeFlag at 1206, is computed based on the nevlnfo. At 1206, the mode flag modeFlag of the CU is read from the bitstream using the CABAC context index idxCtxBase + idxCtx.

[0083] An intra block copy (IBC) flag for a given CU can be signaled and decoded, using the unified process, as illustrated in FIG. 13 (derived from FIG. 12). In this case, it is assumed that the skip flag of this given CU has already been decoded and that that decoded skip flag indicates that the prediction mode is not the skip mode. Also, it is assumed that the flag indicating if this given CU is predicted in an intra-prediction mode or an inter-prediction mode has been decoded and that that decoded flag indicates that intra-prediction mode was used to predict the given CU.

[0084] FIG. 13 is a flowchart of an example method for decoding an IBC flag. FIG. 13 illustrates decoding the IBC flag - that is, ibcFlag - of a given CU at the ETM-7 decoder. Therein, the following variables are defined as follows.• ibcFlag denotes the IBC flag of the CU.• nevlnfo[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.• nevlnfo[l] is a flag that is set to 1 if the CU on the left side of the given CU is available and the ibcFlag of the “left” CU is set to 1.• nevlnfo[2] is a flag that is set to 1 if the CU on the right side of the given CU is available and the ibcFlag of the “right” CU is set to 1.• sps_cm_init_flag is a flag that is set to 1 if the CABAC context models have already been initialized.• isIbcAllowed is a flag that is set to true if, given some available information, IBC is allowed for the CU.• idxCtxIbcFlag denotes the index whose incrementation yields a CABAC context index for decoding ibcFlag.• decodeBin is a function call that reads the current bin using the input CABAC context index.

[0085] The steps of FIG. 13 are like those of FIG. 12, except for the added condition in step 1306. Hence, just as the process illustrated in FIG. 13 can be derived from the unified process illustrated in FIG. 12, for a given CU, the decoding of a skip flag, a prediction mode flag, and an affine flag can also be expressed via specializations of that unified process. Note that at the ETM-7 decoder, for a given CU, the collection of the CAB AC context index for signaling the IBC flag (that is, from 1301 to either 1304 or 1305 in FIG. 13) and the collections of the CABAC context indices for signaling the skip flag, the prediction mode flag, and the affine flag can be performed simultaneously. Then, each of these flags (i.e., IBC flag, the skip flag, the prediction mode flag, and the affine flag) can be decoded if needed.

[0086] As demonstrated above, contextual information generated according to the EVC standard ignores the local coding order. In EVC, when signaling a syntax element associated with the coding of a given CU, there exists no link between contextual information derived from neighboring CUs (e.g., used to compute a CABAC context index for the syntax element) and these CUs coding order. Yet, depending on the semantic of the syntax element being signaled, such a link may be critical for coding efficiency. For instance, in FIGS. 11-13, information of interest is extracted from the given CU’s neighboring CUs (i.e., the “above” CU, the “left” CU, and the “right” CU) if they are available; and, none of these neighboring CUs are prioritized based on their coding order or otherwise. Specifically, in FIG. 13, for a given CU, the incrementation of the IBC flag CABAC context index (i.e., idxCtxlbcFlag) by idxlnt depends on nevlnfo[0], nevlnfo[l], and nevlnfo[2], derived at 1302 - meaning that only the local frequency of the selection of the IBC flag matters, regardless of the local coding order.

[0087] Additionally, the generation of contextual information according to the EVC standard may be unbalanced. In EVC, when signaling a syntax element (e.g., an IBC flag, a skip flag, or an affine flag) because the same information is picked from the “above” CU if available, the “left” CU if available, and the “right” CU if available, and is merged indifferently to create the syntax element’s CABAC context index, in some cases, the “left” and “right” CUs (i.e., horizontally neighboring CUs) dominate the created CABAC context index. Depending on the semantic of the syntax element to be signaled, this lack of balance between the horizontally neighboring CUs and the “above” CU may degrade coding efficiency.

[0088] Aspects disclosed herein address the above mentioned shortcomings of EVC by accounting for local coding order when extracting contextual information from neighboringCUs and / or by spatially balancing the influence of contextual information derived from the neighboring CUs. For example, for a given type of contextual information (e.g., whether a neighboring CU is coded using a certain coding parameter), the spatial balancing may prevent contextual information derived from a first group of CUs located at respective spatial positions from dominating the same type of contextual information derived from a second group of CUs located at other respective spatial positions; the first group may include neighboring CUs horizontally positioned relative to a given CU to be coded (e.g., on the left and on the right sides of the CU) and the second group may include neighboring CUs vertically positioned relative to the given CU (e.g., above and below the CU).

[0089] Hence, aspects of generating contextual information, used for the coding or decoding of a syntax element associated with a given CU being coded or decoded (i.e., a current CU), are presented herein in reference to FIGS. 14-18. In these aspects, for a current CU (i.e., a current block), the coding order of neighboring CUs (i.e., neighboring blocks) from which contextual information is derive may be considered; and the influence of contextual information derived from different neighboring CUs may be balanced. In various variants, different combinations of these aspects may be applied.

[0090] In a first aspect, contextual information is generated as follows. First, the coding order of blocks in a neighborhood of the current block (so-called the local coding order) is extracted, and then, these blocks are prioritized based on their availability, balancing requirements, the extracted coding order, other factors, or a combination thereof. The local coding order may comprise orders such as left-to-right, right-to-left, top-to-bottom and / or bottom-to-top. Second, contextual information relevant to the signaling of a syntax element may be derived from all or a subset of the prioritized blocks, optionally, based on the local coding order. According to aspects, the prioritization of the neighboring blocks is performed to balance the influence of contextual information derived from neighboring blocks located in different spatial regions relative to the current CU.

[0091] FIG. 14 is a flowchart illustrating the first aspect of decoding a syntax element. In the example of FIG. 14, at 1400, the decoding of a syntax element (e.g., a flag) may be triggered. At 1401, coding order information, infOrderCoding, reflecting the coding order of blocks in the region of the current block (i.e., neighboring blocks) can be extracted. At 1402, for each block of the neighboring blocks, the following inner process may be applied. Based on the availability of the block and based on balancing requirements, the extracted coding order, other factors, or a combination thereof it is decided whether to add the block to (or refer to it in) alist of relevant blocks, accessedBlocks array. At 1403, optionally, based on the coding order, coding data of blocks stored in (or referred to by) the accessedBlocks array can be used to compute contextual information, infCtx, that is relevant to the decoding of the syntax element. At 1404, the syntax element can be decoded using the computed infCtx.

[0092] In a second aspect, contextual information is generated as follows. First, the local coding order of blocks in a neighborhood of the current block is extracted. Then, traversing through the neighboring blocks, optionally, according to the local coding order, for each block it is decided, based on the block’s availability, balancing requirements, the extracted coding order, other factors, or a combination thereof, whether to derive from the block contextual information relevant to the signaling of a syntax element.

[0093] FIG. 15 is a flowchart illustrating the second aspect of decoding a syntax element. In the example of FIG. 15, at 1500, the decoding of a syntax element (e.g., a flag) may be triggered. At 1501, information, infOrder Coding, representing the coding order in the region of the current block (i.e., neighboring blocks) can be extracted. At 1502, the neighboring blocks are traversed, optionally, according to the extracted coding order; for each block of the neighboring blocks, the following inner process may be applied. Based on the availability of the block and based on balancing requirements, the extracted coding order, other factors, or a combination thereof, it can be decided whether contextual information relevant to decoding the syntax element should be derived from coding data of this block. The derived contextual information is gathered in infCtx. At 1503, the syntax element may be decoded using the computed infCtx.

[0094] FIG. 16 is a flowchart illustrating a variant of the first aspect of decoding a syntax element, where it is demonstrated that the order of the steps described with respect to the first aspect can be changed. In the example of FIG. 16, blocks in the region of the current block can be prioritized before extracting the coding order of blocks in that region. Accordingly, at 1600, the decoding of a syntax element (e.g., a flag) may be triggered. At 1601, for each block of the neighboring blocks, the following inner process can be applied. Based on the availability of the block and based on balancing requirements, other factors, or a combination thereof it is decided whether to add the block to (or refer to it in) a list of relevant blocks, accessedBlocks array. At 1602, information, infOrder Coding, reflecting coding order of the neighboring blocks can be extracted. At 1603, based on the coding order, coding data of blocks stored in (or referred to by) the accessedBlocks array can be used to compute contextual information, infCtx, that is relevant to the decoding of the syntax element. At 1604, the syntax element can be decodedusing the computed infCtx.

[0095] In a third aspect, the process of extracting local coding order or the process of prioritizing the neighboring blocks may not be carried out, for example, as illustrated in FIG.17.

[0096] FIG. 17 is a flowchart illustrating the third aspect of decoding a syntax element. FIG. 17 demonstrates the case where the extraction of local coding order is not performed. At 1700, the decoding of a syntax element (e.g., a flag) may be triggered. At 1701, for each block of the neighboring blocks, the following inner process may be applied. Based on the availability of the block and based on balancing requirements and / or other factors it is decided whether to add the block to (or refer to it in) a list of relevant blocks, accessedBlocks array. At 1702, coding data of blocks stored in (or referred to by) the accessedBlocks array can be used to compute contextual information, infCtx, that is relevant to the decoding of the syntax element. At 1703, the syntax element can be decoded using the computed infCtx.

[0097] In a fourth aspect, the relevance of the local coding order is evaluated before potentially using it for the process of generating contextual information (e.g., as described with respect to FIGS. 14 and 15). For example, the local coding order may have a predetermined pattern (where all or the majority of the 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).

[0098] FIG. 18 is a flowchart illustrating the fourth aspect of decoding a syntax element. In the example of FIG. 18, at 1800, the decoding of a syntax element (e.g., a flag) may be triggered. At 1801, information, infOrderCoding, representing the coding order of blocks in a region of the current block (i.e., neighboring blocks) can be extracted. At 1802, if the extracted coding order is viewed as relevant for the subsequent steps, the process proceeds to step 1803. Otherwise, the process proceeds to step 1805. At 1803, for each block ofthe neighboring blocks, the following inner process may be applied. Based on the availability of the block and based on balancing requirements, the extracted coding order, other factors, or a combination thereof, it is decided whether to add the block to (or refer to it in) a list of relevant blocks, accessedBlocks array. Then, at 1804, optionally, based on the coding order, coding data of blocks stored in (or referred to by) the accessedBlocks array can be used to compute contextual information, infCtx, that is relevant to the decoding of the syntax element. Alternatively, at 1805, for each block of the neighboring blocks, the following inner process may be applied.Based on the availability of the block and based on balancing requirements and / or other factors, it is decided whether to add the block to (or refer to it in) a list of relevant blocks, accessedBlocks array. Then, at 1806, coding data of blocks stored in (or referred to by) the accessedBlocks array can be used to compute contextual information, infCtx, that is relevant to the decoding of the syntax element. From either 1804 or 1806, the process proceeds to 1807. At 1807, the syntax element may be decoded using the computed infCtx.

[0099] Applications of the disclosed herein aspects and variants, applied to a video codec (e.g., following the VVC standard or the ECM standard), are next described. Specifically, applications of the first aspect are described in reference to FIGS. 23, 24, and 27; applications of the second aspect are described in reference to FIGS. 25 and 26; applications of the third aspect are described in reference to FIGS. 19, 20, and 22; and an application of the fourth aspect is described in reference to FIG. 21.

[0100] FIG. 19 is a flowchart, including a diagram, illustrating an application of the third aspect (as described in reference to FIG. 17) to the decoding of a split type. FIG. 19 illustrates the decoding of the split type, signaled for a given CU 1950 to be potentially split, at the decoder of a video codec that features adaptive change of horizontal coding order. Therein, the following variables are defined as follows.• canSpl[i] is a flag that is set to true if the split type indexed by i is allowed for the CU 1950, where i E {NO_SPLIT, QT, BT_H, BT_V, TT_H, TT_V}, for example.• ctxSplit denotes the incrementation of the CAB AC context index of the split flag.• ctxQtSplit denotes the incrementation of the CABAC context index of the QT flag.• ctxBttHV denotes the incrementation of the CABAC context index of the flag indicating vertical split belonging to the family of BT or TT.• ctxBttH12 and ctxBttV12 each denotes the incrementation of the CABAC context index of the flag being optionally read after the flag indicating vertical split BT / TT.Note that the pixel at the top-left of the CU 1950 is assumed to have the position (0, 0). Also note that the CU 1950 may be a CTU instead of a CU.

[0101] Referring to FIG. 19, at 1900, the decoding of the split type of the CU 1950 may be triggered. At 1901, the flags that indicate whether respective split types are allowed for the CU 1950 can be set and stored in the canSpl array. At 1902, the CU on the left side of the given CU 1950, which may be the one overlapping position 1951, can be put into (or referred to 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 on the right side of the given CU 1950, which may be the one overlapping position 1953, may be put into (or referred to by) cuBorder. At 1905, the CU above the CU 1950, which may be the one overlapping position 1952, may be put into (or referred to by) cuAbove. As a result of steps 1902-1905, cuBorder contains at most one horizontal (the left or right) CU, depending on their availability, and cuAbove contains at most one vertical (the above) CU; and so, contextual information computed in step 1906 from these neighboring CUs is balanced. At 1906, the incrementations of CAB AC context indices ctxSplit, ctxQtSplit, ctxBttHV, ctxBttH12, and ctxBttV12 can be computed based on contextual information derived from the CUs stored in (or referred to by) cuAbove and cuBorder, and based on canSpl (e.g., as in VVC or ECM-9.0). At 1907, the split type of the CU 1950 may be decoded by reading the needed flags with the incrementations calculated at 1906 (e.g., as done in VVC or ECM-9.0). Note that the steps highlighted by the dashed-box 1970 may be viewed as a specialization of step 1701 in FIG. 17.

[0102] FIG. 20 is a flowchart, including a diagram, illustrating an application of the third aspect (as described in reference to FIG. 17) to the decoding of a split type. FIG. 20 illustrates the decoding of the split type, signaled for a given CU 2050 to be potentially split, at the decoder of a video codec that features adaptive change of horizontal coding order. Therein, the following variables are defined as follows.• canSpl [i] is a flag that is set to true if the split type indexed by i is allowed for the CU 2050, where i E {NO_SPLIT, QT, BT_H, BT_V, TT_H, TT_V}, for example.• ctxSplit denotes the incrementation of the CABAC context index of the split flag.• ctxQtSplit denotes the incrementation of the CABAC context index of the QT flag.• ctxBttHV denotes the incrementation of the CABAC context index of the flag indicating vertical split belonging to the family of BT or TT.• ctxBttH12 and ctxBttV12 each denotes the incrementation of the CABAC context index of the flag being optionally read after the flag indicating vertical split BT / TT.Note that the pixel at the top-left of the CU 2050 is assumed to have the position (0, 0). Also note that the CU 2050 may be a CTU instead of a CU.

[0103] Referring to FIG. 20, at 2000, the decoding of the split type of the CU 2050 may be triggered. At 2001, the flags that indicate whether respective split types are allowed for the CU 2050 can be set and stored in the canSpl array. At 2002, the CU on the right side of the given CU 2050, which may be the one overlapping position 2053, can be put into (or referred to by)cuBorder. At 2003, if cuBorder is NULL (indicating that the referenced CU is unavailable), the process proceeds to 2004. Otherwise, 2004 is skipped. At 2004, the CU on the left side of the given CU 2050, which may be the one overlapping position 2051, can be put into (or referenced by) cuBorder. At 2005, the CU above the given CU 2050, which may be the one overlapping position 2052, can be put into (or referenced by) cuAbove. As a result of steps 2002-2005, cuBorder contains at most one horizontal (the left or right) CU, depending on their availability, and cuAbove contains at most one vertical (the above) CU; and so, contextual information computed in step 2006 from these neighboring CUs is balanced. At 2006, the incrementations of CAB AC context indices ctxSplit, ctxQtSplit, ctxBttHV, ctxBttH12, and ctxBttV12 can be calculated based on contextual information derived from the CUs stored in (or referred to by) cuAbove and cuBorder, and based on canSpl (e.g., as in VVC or ECM-9.0). At 2007, the split type of the CU 2050 may be decoded by reading the needed flags with the incrementations calculated at 2006 (e.g., as done in VVC or ECM-9.0). Note that the steps highlighted by the dashed-box 2070 may be viewed as a specialization of step 1701 in FIG. 17.

[0104] FIG. 21 is a flowchart, including a diagram, illustrating an application of the fourth aspect (as described in reference to FIG. 18) to the decoding of the split type. FIG. 21 illustrates the decoding of the split type, signaled for a given CU 2150 to be potentially split, at the decoder of a video codec that features adaptive change of horizontal coding order. Therein, the following variables are defined as follows.• canSpl [i] is a flag that is set to true if the split type indexed by i is allowed for the CU 2150, where i E {NO_SPLIT, QT, BT_H, BT_V, TT_H, TT_V}, for example.• ctxSplit denotes the incrementation of the CABAC context index of the split flag.• ctxQtSplit denotes the incrementation of the CABAC context index of the QT flag.• ctxBttHV denotes the incrementation of the CABAC context index of the flag indicating vertical split belonging to the family of BT or TT.• ctxBttH12 and ctxBttV12 each denotes the incrementation of the CABAC context index of the flag being optionally read after the flag indicating vertical split BT / TT.• codinglnversionFlagSet is an array of flags, each denoted codinglnversionFlag and indicating a coding order associated with an available neighboring CU. codinglnversionFlag = 0 may indicate that its associated CU is coded from left-to- right, and so codinglnversionFlag = 1 indicates that its associated CU is coded from right-to-left.Note that the pixel at the top-left of CU 2150 is assumed to have the position (0, 0). Also notethat the CU 2150 may be a CTU instead of a CU. Additionally, although codinglnversionFlagSet may be needed also by steps 2108 and 2110, for readability, codinglnversionFlagSet is shown as being fed only into 2103 and 2111 only.

[0105] Referring to FIG. 21, at 2100, the decoding of the split type of the CU 2150 may be triggered. At 2101, the flags indicating whether respective split types are allowed for the CU 2150 can be set and stored in the canSpl array. At 2102, codinglnversionFlagSet can be extracted from available neighboring CUs. Based on the extracted codinglnversionFlagSet, the relevancy of the coding order is examined at 2103. To that end, it may be determined whether the coding order represents a predetermined pattern. For example, at 2103, if at least one neighboring CU is available and all the flags in the codinglnversionFlagSet are equal (e.g., having a pattern of left-to-right order), the process proceeds to the steps from 2108 to 2111 where the coding order is used. Otherwise, the process proceeds to the steps from 2104 to 2107 where the coding order is not used. Note that steps 2102 and 2103 may be viewed as a specialization of steps 1801 and 1802, shown in FIG. 18. And, the steps highlighted by the dashed-box on the left 2170 and the dashed-box on the right 2180 may respectively be viewed as specializations of steps 1805 and 1803, shown in FIG. 18.

[0106] Accordingly, in the case where coding order is not used (where at step 2103, not all the flags in the codinglnversionFlagSet are equal), at 2104, the CU on the left side of the given CU 2150, which may be the one overlapping position 2151, can be put into (or referred to by) cuBorder. At 2105, if cuBorder is NULL (indicating that the referenced CU is unavailable), the process proceeds to 2106. Otherwise, 2106 is not executed. At 2106, the CU on the right side of the given CU 2150, which may be the one overlapping position 2153, can be put into (or referred to by) cuBorder. At 2107, the CU above the given CU 2150, which may be the one overlapping position 2154, can be put into (or referred to by) cuAbove.

[0107] Alternatively, in the case where coding order is used (where at step 2103 all the flags in the codinglnversionFlagSet are equal), the CUs that are used to compute contextual information are determined based on their availability and based on positions Po, Pi, and P2, defined using the codinglnversionFlagSet (as shown at the bottom of FIG. 21). Thus, at 2108, the CU on the “border” side of the given CU 2150, which may be the one overlapping position Po, depending on the flag value of codinglnversionFlagSetfO] (or any flag in this set) can be put into (or referred to by) cuBorder. At 2109, if cuBorder is NULL (indicating that the referenced CU is unavailable), the process proceeds to 2110. Otherwise, 2110 is skipped. At2110, the CU on the “opposite” side of the CU 2150, which may be the one overlapping position Pi, can be put into (or referred to by) cuB order. At 2111, the CU above the given CU 2150, which may be the one overlapping position P2, can be put into (or referred to by) cuAbove.

[0108] Hence, based on the relevancy of the coding order determined in step 2103, CUs from the neighborhood of the given CU 2150 are prioritized (or selected) to be used via cuBorder and cuAbove so that contextual information derived from these CUs is spatially balanced. Accordingly, at 2112, the incrementations of CABAC context indices ctxSplit, ctxQtSplit, ctxBttHV, ctxBttH12 , and ctxBttV12 can be computed based on contextual information derived from the CUs stored in (or referred to by) cuAbove and cuBorder, and based on canSpl (e.g., as in VVC or ECM-9.0). At 2113, the split type of the CU 2150 may be decoded by reading the needed flags with the incrementations calculated at 2112 (e.g., as in VVC or ECM-9.0).

[0109] FIG. 21 can be used to illustrate other variants by differently defining the codinglnversionFlagSet extracted in step 2102. For example, codinglnversionFlagSet may contain a single (Boolean) flag, which may be the codinginver sionFlag of the CU scanned just before moving to the given CU 2150 following the coding order. In another example, codinglnversionFlagSet may contain a single (Boolean) flag, which may be the codinglnversionFlag of the CU scanned just before moving to the given CU 2150, provided that this previously scanned CU and the given CU belong to the same CTU.

[0110] FIG. 22 is a flowchart, including a diagram, illustrating an application of the third aspect (as described in reference to FIG. 17) to the decoding of the IBC flag. FIG. 22 illustrates the decoding of the IBC flag, signaled for a given CU 2250, at the decoder of a video codec that features adaptive change of horizontal coding order. Therein, the following variables are defined as follows.• ibcFlag denotes the IBC flag.• offsetlbcFlag denotes the index whose incrementation yields a CABAC context index for reading the IBC flag from the bitstream.• decodeBin is a function call that reads the current bin using the input CABAC context index.Note that the pixel at the top-left of the CU 2250 is assumed to have the position (0, 0).[I ll] Referring to FIG. 22, at 2200, the decoding of the IBC flag of the CU 2250 may betriggered. At 2201, the CU on the left side of the given CU 2250, which may be the one overlapping position 2251, can be put into (or referred to by) cuBorder. At 2202, if cuBorder is NULL (indicating that the referenced CU is unavailable), the process proceeds to 2203. Otherwise, 2203 is skipped. At 2203, the CU on the right side of the given CU 2250, which may be the one overlapping position 2253, can be put into (or referred to by) cuBorder. At 2204, the CU above the given CU 2250, which may be the one overlapping position 2252, can be put into (or referred to by) cuAbove. At 2205, the incrementation idxCtx can be calculated based on contextual information derived from the CUs stored in (or referred to by) cuAbove and cuBorder. At 2206, the IBC flag of the CU 2250 may be read from the bitstream using the CABAC context index offsetlbcFlag + idxCtx. Note that the steps highlighted by the dashed- box 2270 may be viewed as a specialization of step 1701 in FIG. 17.

[0112] FIG. 23 is a flowchart, including a diagram, illustrating an application of the first aspect (as described in reference to FIG. 14) to the decoding of the IBC flag. FIG. 23 illustrates decoding of IBC flag, signaled for a given CU 2350, at the decoder of a video codec that features adaptive change of horizontal coding order. Therein, the following variables are defined as follows.• ibcFlag denotes the IBC flag.• offsetlbcFlag denotes the index whose incrementation yields a CABAC context index for reading the IBC flag from the bitstream.• decodeBin is a function call that reads the current bin using the input CABAC context index.• codinglnversionFlag indicates coding order associated with the CU 2350. codinglnversionFlag = 0 may indicate that the CU 2350 is coded from left-to-right, and so codinglnversionFlag = 1 indicates that the CU 2350 is coded from right-to-left.Note that even though codinglnversionFlag may be needed also by step 2304, for readability, codinglnversionFlag is shown as fed to steps 2302 and 2305 only. Note also that the pixel at the top-left of CU 2350 is assumed to have the position (0, 0).

[0113] In reference to FIG. 23, at 2300, the decoding of the IBC flag of the CU 2350 may be triggered. At 2301, the codinglnversionFlag of the CU 2350 can be extracted. Next, the CUs that are used to compute contextual information are determined based on their availability and based on positions Po, Pi, and P2, defined using the codinglnversionFlag (as shown at the bottom of FIG. 23). To that end, at 2302, the CU on the “border” side of the given CU 2350,which may be the one overlapping position Po, can be put into (or referred to by) cuB order. At 2303, if cuBorder is NULL (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 the given CU 2350, which may be the one overlapping position Pi, can be put into (or referred to by) cuBorder. At 2305, the CU above the given CU 2350, which may be the one overlapping position P2, can be put into (or referred to by) cuAbove. At 2306, the incrementation idxCtx can be calculated from contextual information derived from CUs stored in (or referred to by) cuAbove and cuBorder. At 2307, the IBC flag of the CU 2350 may be read from the bitstream using the CABAC context index offsetlbcFlag + idxCtx. Note that steps 2301 and the steps highlighted by the dashed-box 2370 may respectively be viewed as specializations of steps 1401 and 1402 in FIG. 14.

[0114] FIG. 24 is a flowchart, including a diagram, illustrating an application of the first aspect (as described in reference to FIG. 14) to the decoding of an MIP flag. FIG. 24 illustrates decoding the MIP flag, signaled for a given CU 2450, at the decoder of a video codec that features adaptive change of horizontal coding order. Therein, the following variables are defined as follows.• mipFlag denotes the MIP flag.• offsetMipFlag denotes the index whose incrementation yields a CABAC context index for reading the MIP flag from the bitstream.• decodeBin is a function call that reads the current bin using the input CABAC context index.• codinglnversionFlag indicates coding order associated with the CU 2450. codinglnversionFlag = 0 may indicate that the CU 2450 is coded from left-to-right, and so codinglnversionFlag = 1 indicates that the CU 2450 is coded from right-to-left.Note that, although codinglnversionFlag may be needed also by 2404, for readability, codinglnversionFlag is shown as fed to steps 2402 and 2405 only. Note that the pixel at the top-left of CU 2450 is assumed to have the position (0, 0).

[0115] In reference to FIG. 24, at 2400, the decoding of the MIP flag of the CU 2450 may be triggered. At 2401, the codinglnversionFlag of the CU 2450 can be extracted. Next, the CUs that are used to compute contextual information are determined based on their availability and based on positions Po, Pi, and P2, defined using the codinglnversionFlag (as shown at the bottom of FIG. 24). To that end, at 2402, the CU on the “border” side of the given CU 2450,which may be the one overlapping position Po, can be put into (or referred to by) cuB order. At 2403, if cuBorder is NULL (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 the given CU 2450, which may be the one overlapping position Pi, can be put into (or referred to by) cuBorder. At 2405, the CU above the given CU 2450, which may be the one overlapping position P2, can be put into (or referred to by) cuAbove. At 2406, the incrementation idxCtx can be calculated from contextual information derived from CUs stored in (or referred to by) cuAbove and cuBorder. At 2407, the MIP flag of the CU 2450 can be read from the bitstream using the CABAC context index offsetMipFlag + idxCtx. Note that steps 2401 and 2470 may respectively be viewed as specializations of steps 1401 and 1402 in FIG. 14.

[0116] FIG. 25 A-B is a flowchart, including a diagram, illustrating an application of the second aspect (as described in reference to FIG. 15) to the decoding of an intra-prediction mode index. FIG. 25 illustrates decoding the intra-prediction mode index, signaled for the luma component of a given PU 2550, at the decoder of a video codec that features adaptive change of horizontal coding order. Therein, the following variables are defined as follows.• ipredMode denotes the index of the intra-prediction mode associated with the luma component of the PU 2550.• borderlntraDir denotes the index of the intra-prediction mode in luma.• abovelntraDir denotes the index of the intra-prediction mode in luma.• codinglnversionFlag indicates coding order associated with the PU 2550. codinglnversionFlag = 0 may indicate that the PU 2550 is coded from left-to-right, and so codinglnversionFlag = 1 indicates that the PU 2550 is coded from right-to-left.The two double-slashes and the two double-horizontal-lines indicate respective connection points between the two flowchart parts of FIG. 25 A and of FIG. 25B. Note that the pixel at the top-left of the PU 2550 is assumed to have the position (0, 0). Also note that although codinglnversionFlag may be required also by 2504, for readability, codinglnversionFlag is shown as being fed to 2502 and 2508 only. In some video codecs (such as those following the VVC standard) a CU contains a PU, so that the CU and its PU are equivalent with respect to the decoding process.

[0117] In reference to FIG. 25A-B, at 2500, the decoding of the index ipredMode of the intraprediction mode in luma of the PU 2550 may be triggered. Note that 2500 is assumed to begin from the point where, if needed, the MIP flag has already been read from the bitstream, and itis equal to 0, and, if needed, the flags related to multiple reference lines (MRL) and intra subpartition (ISP) have already been read from the bitstream. At 2501, the codinglnversionFlag of the PU 2550 can be extracted. Next, the CUs that are used to compute contextual information are determined based on their availability and based on positions Po, Pi, and P2, defined using the codinglnversionFlag (as shown at the bottom of FIG. 25B). At 2502, the PU on the “bottom-border” side of the given PU 2550, which may be the one overlapping position Po, can be put into (or referred to by) puBorder. At 2503, if puBorder is NULL (indicating that the referenced PU is not available) or the referenced PU is not predicted using intra-prediction mode, the process proceeds to steps 2504 to 2506. Otherwise, the process proceeds to 2507. At 2504, the PU on the “opposite-bottom” side of the given PU 2550, which may be the one overlapping position Pi, can be put into (or referred to by) puBorder. At 2505, if puBorder is NULL (indicating that the referenced PU is not available) or the referenced PU is not predicted using intra-prediction mode, then the process proceeds to 2506. Otherwise, the process proceeds to 2507. At 2506, borderlntraDir can be set to the PLANARJDX index (representing the PLANAR mode). At 2507, borderlntraDir can be set to the intra-prediction mode index selected to predict the luma component of the PU stored in (or referred to by) the puBorder.

[0118] Possibly, in parallel to the steps 2502-2507, steps 2508-2511 may be performed. At 2508, the PU on the “above-opposite” side of the given PU 2550, which may be the one overlapping position P2, can be put into (or referred to by) the puAbove. At 2509, if puAbove is NULL (indicating that the referenced PU is not available) or the referenced PU is not predicted using intra-prediction mode or the referenced PU and the PU 2550 do not belong to the same CTU, the process proceeds to 2510. Otherwise, the process proceeds to 2511. At 2510, abovelntraDir can be set to PLANARJDX. At 2511, abovelntraDir can be set to the intraprediction mode index selected to predict the luma component of the PU stored in (or referred to by) the puAbove.

[0119] Next, at 2512, the list of most probable modes (MPMs) of the PU 2550 can be filled using borderlntraDir and abovelntraDir. Then, ipredMode of the PU 2550 may be decoded using the filled list of MPMs (e.g., as in VVC). Note that, step 2501 and the steps highlighted by the dashed-box 2570 may respectively be viewed as specializations of steps 1501 and 1502 in FIG. 15.

[0120] FIG. 26A-C is a flowchart, including a diagram, illustrating an application of the second aspect (as described in reference to FIG. 15) to the derivation of the MPMs list. FIG. 26A-Cillustrates the derivation of the list of MPMs of a given PU 5050 at the decoder of a video codec that features adaptive change of horizontal coding order. The derived list of MPMs will be then used to decode the index of the intra-prediction mode that is to be used for the prediction of the luma component of the PU 5050. In FIG. 26A-C, the following variables are defined as follows.• spatiallpm[i] denotes an index of the intra-prediction mode used to predict the luma component of a respective PU that is a neighbor of the given PU 5050, with priority rank i. where i E [0, numCand — 1],• arrayReserved[i] denotes an index of the intra-prediction mode used to predict the luma component of a respective PU that is a neighbor of the given PU 5050, with priority rank i, where i E [0, nb Reserved — 1], The indices in arrayReserved are set aside, to be later appended to the indices in spatiallpm.• includeModefi] denotes a flag that if set to true indicates that the intra-prediction mode index i already exists in spatiallpm.• isIdxModeValid denotes the priority of spatialIpm[numCand] based on, among other, heightPU , widthPU , spatialIpm[numCand] , and the availabilities of the reference samples around the PU 5050. Here, the priority means whether spatialIpm[numCand] must be set aside to be later appended to spatiallpm.• codinglnversionFlag indicates coding order associated with the PU 5050. codinglnversionFlag = 0 may indicate that the PU 5050 is coded from left-to-right, and so codinglnversionFlag = 1 indicates that the PU 5050 is coded from right-to-left.Note that the pixel at the top-left of the PU 5050 is assumed to have the position (0, 0).

[0121] In reference to FIG. 26A, at 5000, the derivation of the list of MPMs of the PU 5050 may be triggered. At 5001, spatialIpm[0] is set to PLANARJDX and nbReserved is set to 0. Additionally, all the values of the includeMode array are initialized to false, apart from includeMode[PLANAR_IDX] which is initialized to true (indicating that, at this point, only the PLANARJDX mode exists in spatiallpm). At 5002, the codinglnversionFlag of the PU 5050 may be extracted. At 5003, an ordered list £ of 6 positions around the PU 5050 may be defined depending on, among others, codinglnversionFlag. At 5004, spatiallpm and arrayReserved may be filled by running the steps highlighted by the dashed-box 4090 (steps 4000 to 4011 in FIG. 26B) for i from 0 to 5 with £[i] as an input position.

[0122] As shown in FIG. 26B, at 4000, the PU overlapping input position P (i.e., £[i]) can be put into (or referred to by) puNeighbor. At 4001, if puNeighbor is NULL (indicating that the referenced PU is not available), the process proceeds to 4011. Otherwise, the process proceedsto the steps from 4002 to 4010. At 4002, isFound is initialized to false. At 4003, if the luma component of the PU stored in (or referred to by) puNeighbor is predicted in intra-prediction mode, the process advances to 4004. Otherwise, 4004 is skipped. At 4004, spatialIpm[numCand] may be set to the index of the intra-prediction mode used to predict the luma component of the PU stored in (or referred to by) puNeighbor. Then, isFound may be set to true. At 4005, if the luma component of the PU stored in (or referred to by) puNeighbor is predicted using inter-prediction mode or IBC prediction mode, then the process proceeds to 4006. Otherwise, 4006 is skipped. At 4006, first, a PU for which an intra-prediction mode is used is searched by starting from the PU stored in (or referred to by) puNeighbor, following the motion vector provided by the inter-prediction mode or IBC mode of that PU, and ending at a PU in a reference frame for which an intra-prediction mode is used; then, second, spatialIpm[numCand] is set with the index of the intra-prediction mode used to predict the luma 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 an intra-prediction mode that is used to predict the luma component of a PU neighboring the given PU 5050 and that spatialIpm[numCand] does not already exist in spatiallpm) 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 may be a function of, among other, heightPU, widthPU, spatialIpm[numCand], and the availabilities of the reference samples around the PU 5050. Thus, 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, setting aside spatialIpm[numCand] to be later appended to spatiallpm . At 4010, includeMode[spatialIpm[numCand]] can be set to true and numCand+= 1, indicating that spatialIpm[numCand] gets the effective priority of rank numCand — 1 for later constructing the list of MPMs of the PU 5050.

[0123] Referring back to FIG. 26A, at 5005, the filling of spatiallpm can be continued. For instance, indices of intra-prediction modes derived via Decoder Side Intra Mode Derivation (DIMD) can be appended to spatiallpm and numCand can be incremented accordingly. For instance, indices of prediction modes from non-adjacent neighboring PUs can be appended to spatiallpm and numCand can be incremented accordingly. This may mean that, for each position in a list of positions that are not adjacent to the PU 5050, the process 4090 shown inFIG. 26B is run using this position as input. For instance, for each index of intra-prediction mode in arrayReserved, this index can be appended to spatiallpm if it does not already exist in spatiallpm, and numCand may be incremented accordingly. At 5006, the list of MP Ms of the PU 5050 may be created from spatiallpm (e.g., as done in ECM-9.0). Notably, the first numCand indices stored in spatiallpm may become the first numCand MPMs. Note that step 5002 and the steps that are highlighted by the dashed-box 5070 may respectively be viewed as specializations of steps 1501 and 1502 in FIG. 15.

[0124] In FIG. 26A-C it is assumed, for clarity, that none of the PUs around PU 5050 is predicted via either Simplified Geometric Partition Mode (SGPM) or Template-based Intra Mode Derivation (TIMD) or Template-based Multiple Reference Line (TMRL). Nonetheless, FIG. 26A-C can be straightforwardly adapted to the case of a PU around PU 5050 predicted via either SGPM or TIMD or TMRL.

[0125] Referring to FIG. 26C, various variants may be applied with respect to the step 5003 of defining an ordered list £ of 6 positions around the given PU 5050. In a first variant, £ may include positions [(5051), (5052), (5053), (5054), (5055), (5058)] if the codinglnversionFlag of the PU 5050 is equal to 0. Otherwise (i.e., if the codinglnversionFlag of the PU 5050 is equal to 1), £ may include positions[(5056), (5057), (5054), (5053), (5058), (5055)] . In a second variant, £ may include positions [(5051), (5052), (5053), (5054), (5055), (5056)] if the codinglnversionFlag of the PU 5050 is equal to 0. Otherwise (i.e., if the codinglnversionFlag of PU 5050 is equal to 1, £ may include positions [(5056), (5057), (5054), (5053), (5058), (5051)] . In a third variant, any relationship between £ and the codinglnversionFlag of the PU 5050 may be valid. In a fourth variant, the ordered list £ may include n £ N’ positions. In this case, in 5004, i may go from 0 to n — 1. In a fifth variant, the order of the steps in the flowchart of FIG. 26A-B may be changed. For instance, step 5001 may be placed between steps 5003 and 5004. In a sixth variant, in FIG. 26A, at 5005, another list of positions that may be adjacent / non-adjacent to the PU 5050 may be defined, optionally depending on the codinglnversionFlag of the PU 5050. For each position in this other list, the process highlighted by the dashed-box 4090 in FIG. 26B may be run using this position as input.

[0126] Aspects described herein can be applied to the signaling and decoding of any given syntax element (e.g., a flag or an index), as demonstrated by the applications described above in reference to FIGS. 19-26. For instance, the first aspect (described in reference to FIG. 14)can be applied to the decoding of any syntax element such as the affine flag or the skip flag associated with given CU (similarly to the way the first aspect is applied to the decoding of the IBC flag and the MIP flag as respectively described in reference to FIG. 23 and FIG. 24).

[0127] As mentioned above, the applications of aspects described herein include applications of the aspects to a video codec that feature adaptive change of not only horizontal coding order but any coding order, as described below in reference to FIG. 27.

[0128] FIG. 27 is a flowchart, including a diagram, illustrating an application of the first aspect (as described in reference to FIG. 14) to the decoding of an MIP flag. FIG. 27 illustrates the decoding of the MIP flag, signaled for a given CU 2650, at the decoder of a video codec that features adaptive change of any coding order. The coding orders 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. In FIG. 27, the following variables are defined as follows.• mipFlag denotes the MIP flag.• codinglnversionFlagH indicates the coding order of the CU 2650 in the horizontal direction (i.e., left-to-right or right-to-left).• codinglnversionFlagV indicates the coding order of the CU 2650 in the vertical direction (i.e., top-to-bottom or bottom-to-top).• offsetMipFlag denotes the index whose incrementation yields a CABAC context index for reading the MIP flag from the bitstream.• decodeBin is a function call that reads the current bin using the input CABAC context index.• codinglnversionFlagH indicates horizontal coding order associated with the CU 2650. codinglnversionFlagH = 0 may indicate that the CU 2650 is coded from left- to-right, and so codinglnversionFlagH = 1 indicates that the CU 2650 is coded from right-to-left.• codinglnversionFlagV indicates vertical coding order associated with the CU 2650. codinglnversionFlagV = 0 may indicate that the CU 2650 is coded from top-to- bottom, and so codinglnversionFlagV = 1 indicates that the CU 2650 is coded from bottom-to-top.Note that the pixel at the top-left of the CU 2650 is assumed to have the position (0, 0).

[0129] For a position on the left side of the CU 2650 or on its right side (i.e., positions 2651, 2653, 2657, and 2658 in FIG. 27), a “reference axis” is defined as the vertical line crossing thecenter of the CU 2650 (not shown). For a position above the CU 2650 or below it (i . e. , positions 2652, 2654, 2655, and 2656 in FIG. 27), a “reference axis” is defined as the horizontal line crossing the center of the CU 2650 (not shown). Hence, the mirror of position 2651 with respect to its reference axis can be position 2653; the mirror of position 2657 with respect to its reference axis can be position 2658; the mirror of position 2652 with respect to its reference axis can be position 2655; and the mirror of position 2654 with respect to its reference axis can be position 2656.

[0130] Referring to FIG. 27, at 2600, the decoding of the MIP flag of the CU 2650 may be triggered. At 2601, the codinglnversionFlagH and codinglnversionFlagV of the CU 2650 can be extracted. At 2602, an ordered list £ of 4 positions around the CU 2650 can be created depending on codinglnversionFlagH and codinglnversionFlagV. At 2620, a list listCus of references to retained CUs is initialized to an empty list. Then, for i from 0 to 3, the inner process including steps 2603, 2604, 2605, and 2606 can be run. At 2603, the CU overlapping position £[i] can be put into (or referred to by) cuTemp. At 2604, if cuTemp is NULL (indicating that the referenced CU is not available), then the process proceeds to 2605. Otherwise, 2605 is skipped. At 2605, the CU overlapping position that is the mirror of £[i] with respect to the reference axis can be put into (or referred to by) cuTemp. At 2606, cuTemp can be appended to listCus. At 2607, the incrementation idxCtx can be calculated from listCus. At 2608, the MIP flag of the CU 2650 can be read from the bitstream using the CABAC context index offsetMipFlag + idxCtx. Note that, step 2601 and the steps highlighted by the dashed- box 2670 may respectively be viewed as specializations of steps 1401 and 1402 in FIG. 14.

[0131] Referring to step 2602 (where, depending on codinglnversionFlagH and codinglnversionFlagV, an ordered list £ can be created), the following variants can be used. In a variant, the relationship between £ and the values of codinglnversionFlagH and codinglnversionFlagV follow Table 1 or Table 2. In another variant, any relationship between £ and the values of codinglnversionFlagH and codinglnversionFlagV is valid. In yet another variant, the ordered list £ may contain n £ N’ positions. In this case, in steps 2620 and 2607, i may go from 0 to n — 1. For instance, n = 5.

[0132] Table 1: Positions in £ as a function of codinglnversionFlagH and codinglnversionFlagV.

[0133] Table 2: Positions in £ as a function of codinglnversionFlagH and codinglnversionFlagV.

[0134] FIG. 28 is a flowchart of an example method for encoding video data 2800. The method 2800 may be applied to the coding of a video block, of the video data, into a bitstream 2810, according to steps 2820 and 2830. In step 2820, contextual information can be derived from coding data of neighboring video blocks located within a neighborhood of the video block. The deriving of the contextual information can be based on spatial locations of the neighboring video blocks relative to the video block. Then, in step 2830, using the contextual information, a syntax element can be coded into the bitstream. The contextual information can be further derived based on a coding order of the neighboring video blocks. For example, the deriving of the contextual information can be based on the coding order, if the coding order has a predetermined pattern.

[0135] In an aspect, the contextual information can be derived by generating a list of blocks and by computing contextual information from coding data of blocks in the list. In this aspect, the list can be generated by adding a block of the neighboring video blocks to the list, if coding data are available for the block and based on the coding order. In another aspect, the contextual information can be derived as follows: for each block of the neighboring video blocks, if coding data are available for the block and based on the coding order, then contextual information is computed from coding data of the block and is combined with previously computed contextual information.

[0136] In yet another aspect, the deriving of contextual information based on spatial locations of the neighboring video blocks relative to the video block (as in step 2820) can include balancing contextual information derived from video blocks located within a first region of the neighborhood of the video block with contextual information derived from video blocks located within a second region of the neighborhood of the video block. For example, the first region can include video blocks horizontally positioned relative to the video block and the second region can include video blocks vertically positioned relative to the video block.

[0137] FIG. 29 is a flowchart of an example method for decoding video data 2900. The method 2900 may be applied to the decoding of a video block, of the video data, from a bitstream 2910, according to steps 2920 and 2930. In step 2920, contextual information can be derived from coding data of neighboring video blocks located within a neighborhood of the video block. The deriving of the contextual information can be based on spatial locations of the neighboring video blocks relative to the video block. Then, in step 2930, using the contextual information, a syntax element can be decoded from the bitstream. The contextual information can be further derived based on a coding order of the neighboring video blocks. Note that aspects described herein with respect to generating contextual information that is used to signal (or code) a syntax element into the bitstream are generally applicable for generating contextual information that is used to decode a syntax element from the bitstream.

[0138] Any of the aspects presented herein (e.g., as described with respect to FIGS. 14-18 and 28-29) and their applications (e.g., as described with respect to FIGS. 19-27), wherein balanced generation of contextual information based on local coding order is performed, can be straightforwardly adapted to other coding modules.

[0139] We have described several aspects and embodiments in the present disclosure. These aspects and embodiments provide at least the following outputs and results, including all combinations, across different claim categories and types:• Encoding, into coded video data, syntax elements that can enable the decoder to decode the coded video data, according to any of the aspects described herein.• A bitstream that includes one or more of the described syntax elements, or variations thereof. A bitstream can be any set of data whether transmitted, stored, or otherwise made available.Creating, transmitting, receiving, and / or decoding of the bitstream.• An electronic device (e.g., a TV, a set-top box, a cell phone, or a tablet) that tunes (e.g., using a tuner) a channel to receive the bitstream or that receives (e.g., using an antenna) the bitstream over the air. 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) a resulting image.Various other generalized, as well as particularized, outputs, results, implementations, and claims are also supported and contemplated throughout this disclosure.

[0140] Various methods are described herein, and each of the methods comprises one or more steps or actions for achieving the described method. Unless a specific order of steps or actions is required for the proper operation of the method, the order and / or use of specific steps and / or actions can be modified or combined. Additionally, terms such as “first”, “second”, etc. can be used in various embodiments to modify an element, component, step, operation, etc., for example, a “first decoding” and a “second decoding”. Use of such terms does not imply an ordering to the modified operations unless specifically required. So, in this example, the first decoding need not be performed before the second decoding, and can occur, for example, before, during, or in an overlapping time period with the second decoding.

[0141] Various methods and other aspects described in this application can be used to modify modules, for example, the modules of the video encoder 200 and the video decoder 300 as shown in FIG. 2 and FIG. 3. Moreover, the present aspects are not limited to a specific standard (such as VVC or HEVC) and can be applied, for example, to other standards and recommendations, as well as extensions of any such standards and recommendations. Unless indicated otherwise, or technically precluded, the aspects described in this application can be used individually or in combination.

[0142] Various numeric values are used in the present application. The specific values are for example purposes and the aspects described are not limited to these specific values.

[0143] Various implementations involve decoding. “Decoding,” as used in this application, can encompass all or part of the processes performed, for example, on a received encoded sequence in order to produce a final output suitable for display. In various embodiments, such processes include one or more of the processes typically performed by a decoder, for example, entropy decoding, inverse quantization, inverse transformation, and differential decoding. Whether the phrase “decoding process” is intended to refer specifically to a subset of operations or generally to the broader decoding process will be clear based on the context of the specificdescriptions and is believed to be well understood by those skilled in the art.

[0144] Various implementations involve encoding. In an analogous way to the above discussion about “decoding”, “encoding” as used in this application can encompass all or part of the processes performed, for example, on an input video data in order to produce an encoded bitstream. Additionally, the terms “reconstructed” and “decoded” can be used interchangeably, the terms “encoded” or “coded” can be used interchangeably, and the terms “image,” “picture,” and “frame” can be used interchangeably. Usually, but not necessarily, the term “reconstructed” is used on the encoder side while the term “decoded” is used on the decoder side.

[0145] Note that the syntax elements as used herein are descriptive terms. As such, they do not preclude the use of other syntax element names.

[0146] This disclosure has described various pieces of information, such as for example syntax, that can be transmitted or stored, for example. This information can be packaged or arranged in a variety of manners, including, for example, manners that are common in video standards such as putting the information into an SPS, a PPS, aNAL unit, a header (for example, aNAL unit header, or a slice header), or an SEI message. Other manners are also available, including, for example, manners common for system level or application level standards such as signaling the information into one or more of the following: a. SDP (session description protocol), a format for describing multimedia communication sessions for the purposes of session announcement and session invitation, for example, as described in RFCs and used in conjunction with RTP (Real-time Transport Protocol) transmission. b. DASH MPD (Media Presentation Description) Descriptors, for example, as used in DASH and transmitted over HTTP. A descriptor is associated with a Representation or collection of Representations to provide additional characteristics to the content Representation. c. RTP header extensions, for example, as used during RTP streaming. d. ISO Base Media File Format, for example, as used in OMAF and using boxes which are object-oriented building blocks defined by a unique type identifier and length (also known as 'atoms' in some specifications). e. HLS (HTTP live Streaming) manifest transmitted over HTTP. A manifest can be associated, for example, with a version or collection of versions of content to provide the characteristics of the version or collection of versions.

[0147] The implementations and aspects described herein can be implemented in, for example,a method or a process, an apparatus, a software program, a data stream, or a signal. Even if only discussed in the context of a single form of implementation (for example, discussed only as a method), the implementation of features discussed can also be implemented in other forms (for example, an apparatus or program). An apparatus can be implemented in, for example, appropriate hardware, software, and firmware. The methods can be implemented in, for example, an apparatus, for example, a processor, which refers to processing devices in general, including, for example, a computer, a microprocessor, an integrated circuit, or a programmable logic device. Processors also include communication devices, for example, computers, cell phones, portable / personal digital assistants (PDAs), and other devices that facilitate communication of information between end-users.

[0148] Reference to “one / an aspect” or “one / an embodiment” or “one / an implementation,” as well as other variations thereof, means that a particular feature, structure, characteristic, and so forth described in connection with the aspect / embodiment / implementation is included in at least one embodiment. Thus, the appearances of the phrase “in one / an aspect” or “in one / an embodiment” or “in one / an implementation,” as well any other variations, appearing in various places throughout this application, are not necessarily all referring to the same embodiment.

[0149] Additionally, this application can refer to “determining” various pieces of information. Determining the information can include one or more of, for example, estimating the information, calculating the information, predicting the information, or retrieving the information from memory.

[0150] Further, this application may refer to “accessing” various pieces of information. Accessing the information can include one or more of, for example, receiving the information, retrieving the information (for example, from memory), storing the information, moving the information, copying the information, calculating the information, determining the information, predicting the information, or estimating the information.

[0151] Additionally, this application may refer to “receiving” various pieces of information. Receiving is, as with “accessing,” intended to be a broad term. Receiving the information can include one or more of, for example, accessing the information, or retrieving the information (for example, from memory). Further, “receiving” is typically involved, in one way or another, during operations, for example, storing the information, processing the information, transmitting the information, moving the information, copying the information, erasing the information, calculating the information, determining the information, predicting theinformation, or estimating the information.

[0152] It is to be appreciated that the use of any of the following “ / ”, “and / or”, and “at least one of’, for example, in the cases of “A / B”, “A and / or B” and “at least one of A and B,” is intended to encompass the selection of the first listed option (A) only, or the selection of the second listed option (B) only, or the selection of both options (A and B). As a further example, in the cases of “A, B, and / or C” and “at least one of A, B, and C”, such phrasing is intended to encompass the selection of the first listed option (A) only, or the selection of the second listed option (B) only, or the selection of the third listed option (C) only, or the selection of the first and the second listed options (A and B) only, or the selection of the first and third listed options (A and C) only, or the selection of the second and third listed options (B and C) only, or the selection of all three options (A and B and C). This can be extended, as is clear to one of ordinary skill in this and related arts, for as many items as are listed.

[0153] Also, as used herein, the word “signal” refers to, among other things, indicating something to a corresponding decoder. For example, in certain embodiments the encoder signals a quantization parameter for de-quantization. In this way, in an embodiment the same parameter is used at both the encoder side and the decoder side. Thus, for example, an encoder can transmit (explicit signaling) a particular parameter to the decoder so that the decoder can use the same particular parameter. Conversely, if the decoder already has the particular parameter as well as others, then signaling can be used without transmitting (implicit signaling) to simply allow the decoder to know and select the particular parameter. By avoiding transmission of any actual data, a bit savings is realized in various embodiments. It is to be appreciated that signaling can be accomplished in a variety of ways. For example, one or more syntax elements, flags, and so forth are used to signal information to a corresponding decoder in various embodiments. While the preceding relates to the verb form of the word “signal”, the word “signal” can also be used herein as a noun.

[0154] As will be evident to one of ordinary skill in the art, implementations can produce a variety of signals formatted to carry information that can be, for example, stored or transmitted. The information can include, for example, instructions for performing a method, or data produced by one of the described implementations. For example, a signal can be formatted to carry the bitstream of a described embodiment. Such a signal can be formatted, for example, as an electromagnetic wave (for example, using a radio frequency portion of spectrum) or as a baseband signal. The formatting can include, for example, encoding a data stream and modulating a carrier with the encoded data stream. The information that the signal carries canbe, for example, analog or digital information. The signal can be transmitted over a variety of different wired or wireless links, as is known. The signal can be stored on a processor-readable medium.

Claims

CLAIMS1. A method for decoding video data, comprising: decoding, from a bitstream, a video block of the video data, the decoding of the video block comprises: deriving contextual information from coding data of neighboring video blocks located within a neighborhood of the video block, the deriving is based on spatial locations of the neighboring video blocks relative to the video block, and decoding from the bitstream a syntax element using the contextual information.

2. The method according to claim 1, further comprising: extracting a coding order of the neighboring video blocks, wherein the contextual information is further derived based on the coding order.

3. The method according to claim 2, wherein the deriving of the contextual information comprises: generating a list of blocks, wherein for each block of the neighboring video blocks: if coding data are available for the block and based on the coding order, adding the block to the list; and computing contextual information from coding data of blocks in the list.

4. The method according to claim 2, wherein the deriving of the contextual information comprises: for each block of the neighboring video blocks: if coding data are available for the block and based on the coding order, computing contextual information from coding data of the block, wherein the derived contextual information comprises the contextual information computed for the block.

5. The method according to any one of claims 2 to 4, wherein the deriving of the contextual information is based on the coding order, if the coding order has a predetermined pattern.

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

7. The method according to any one of claims 1 to 6, wherein the deriving of contextual information based on spatial locations of the neighboring video blocks relative to the video block further comprises: balancing contextual information derived from video blocks located within a first region of the neighborhood of the video block with contextual information derived from video blocks located within a second region of the neighborhood of the video block.

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

9. A method for encoding video data, comprising: coding, into a bitstream, a video block of the video data, the coding of the video block comprises: deriving contextual information from coding data of neighboring video blocks located within a neighborhood of the video block, the deriving is based on spatial locations of the neighboring video blocks relative to the video block, and coding into the bitstream a syntax element using the contextual information.

10. The method according to claim 9, further comprising: extracting a coding order of the neighboring video blocks, wherein the contextual information is further derived based on the coding order.

11. An apparatus for decoding video data, comprising: at least one processor; and memory storing instructions that, when executed by the at least one processor, cause the apparatus to: decode, from a bitstream, a video block of the video data, the decoding of the video block comprises: deriving contextual information from coding data of neighboring video blocks located within a neighborhood of the video block, the derivingis based on spatial locations of the neighboring video blocks relative to the video block, and decoding from the bitstream a syntax element using the contextual information.

12. The apparatus according to claim 11, wherein the instructions further cause the apparatus to: extract a coding order of the neighboring video blocks, wherein the contextual information is further derived based on the coding order.

13. The apparatus according to claim 12, wherein the deriving of the contextual information comprises: generating a list of blocks, wherein for each block of the neighboring video blocks: if coding data are available for the block and based on the coding order, adding the block to the list; and computing contextual information from coding data of blocks in the list.

14. The apparatus according to claim 12, wherein the deriving of the contextual information comprises: for each block of the neighboring video blocks: if coding data are available for the block and based on the coding order, computing contextual information from coding data of the block, wherein the derived contextual information comprises the contextual information computed for the block.

15. The apparatus according to any one of claims 12 to 14, wherein the deriving of the contextual information is based on the coding order, if the coding order has a predetermined pattern.

16. The apparatus according to any one of claims 11 to 15, wherein the deriving of contextual information based on spatial locations of the neighboring video blocks relative to the video block further comprises: balancing contextual information derived from video blocks located within a firstregion of the neighborhood of the video block with contextual information derived from video blocks located within a second region of the neighborhood of the video block.

17. An apparatus for encoding video data, comprising: at least one processor; and memory storing instructions that, when executed by the at least one processor, cause the apparatus to: code, into a bitstream, a video block of the video data, the coding of the video block comprises: deriving contextual information from coding data of neighboring video blocks located within a neighborhood of the video block, the deriving is based on spatial locations of the neighboring video blocks relative to the video block, and coding into the bitstream a syntax element using the contextual information.

18. The apparatus according to claim 17, wherein the instructions further cause the apparatus to: extract a coding order of the neighboring video blocks, wherein the contextual information is further derived based on the coding 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, from a bitstream, a video block of the video data, the decoding of the video block comprises: deriving contextual information from coding data of neighboring video blocks located within a neighborhood of the video block, the deriving is based on spatial locations of the neighboring video blocks relative to the video block, and decoding from the bitstream a syntax element using the contextual information.

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: coding, into a bitstream, a video block of the video data, the coding of the video block comprises: deriving contextual information from coding data of neighboring video blocks located within a neighborhood of the video block, the deriving is based on spatial locations of the neighboring video blocks relative to the video block, and coding into the bitstream a syntax element using the contextual information.

Images