Encoders, decoders, and corresponding methods

Abstract

The decoding method includes the steps of: encountering, in a video bitstream, a tile end bit and a byte alignment bit having a first value, which indicate that a current coding tree block (CTB) is the last CTB in the tile; encountering, in the video bitstream, a CTB row end bit and a byte alignment bit having a first value, which indicate that waveform parallel processing (WPP) is enabled and that the current CTB is the last CTB in a CTB row but not the last CTB in the tile; and reconstructing multiple CTBs in the tile based on the tile end bit having the first value, the CTB row end bit having the first value, and the byte alignment bit.

Description

[Technical Field]

[0001] Generally, this disclosure describes techniques to support wavefront parallel processing (WPP) in video coding. More particularly, this disclosure prevents unnecessary duplication of bit and byte alignment in WPP. [Background technology]

[0002] The amount of video data required to render even a relatively short video can be considerable, which can pose challenges when the data is to be streamed or otherwise communicated across communication networks with limited bandwidth capacity. Therefore, video data is typically compressed before being communicated across modern telecommunications networks. Because memory resources may be limited, video size can also be an issue when the video is stored on a storage device. Video compression devices often use software and / or hardware at the source to code video data before transmission or storage, thereby reducing the amount of data needed to represent a digital video image. The compressed data is then received at the destination by a video decompression device, which decodes the video data. With limited network resources and an ever-increasing demand for higher video quality, improved compression and decompression techniques that improve compression ratios with little to no sacrifice in image quality are desirable. Summary of the Invention [Means for solving the problem]

[0003] A first aspect relates to a method performed by a video decoder for decoding a coded video bitstream, the method including the steps of: receiving, by the video decoder, a coded video bitstream, the coded video bitstream including a picture, the picture including one or more slices having one or more tiles, each tile including a plurality of coding tree blocks (CTBs); encountering, by the video decoder, in the coded video bitstream, a tile end bit and a byte alignment bit having a first value, the tile end bit and the byte alignment bit indicating that a current CTB from the plurality of CTBs is the last CTB in the tile; and encountering, by the video decoder, a CTB row end bit and a byte alignment bit having a first value, the CTB row end bit and the byte alignment bit indicating that the CTB row end bit and the byte alignment bit are used for waveform parallel processing. indicating that WPP (Wide Pixel Processing) is enabled and that a current CTB from the plurality of CTBs is the last CTB in a CTB row but not the last CTB in a tile; and reconstructing, by a video decoder, the plurality of CTBs in the tile based on the tile end bit having a first value, the CTB row end bit having a first value, and the byte alignment bit.

[0004] The method provides a technique for preventing duplication of signaling and byte alignment in WPP. By eliminating duplication of signaling and byte alignment in WPP, the number of bits used to signal the end of a row / tile and the number of bits used as padding are reduced. By reducing the number of bits required for WPP, the coder / decoder (also known as a "codec") in video coding is improved relative to current codecs. In practical terms, the improved video coding process provides users with a better user experience when video is transmitted, received, and / or viewed.

[0005] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the tile end bit is referred to as end_of_tile_one_bit.

[0006] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the CTB row end bit is referred to as end_of_subset_bit.

[0007] Optionally, in any of the preceding aspects, another implementation of the aspect provides that WPP is enabled by a flag located in the parameter set.

[0008] Optionally, in any of the preceding aspects, another implementation of the aspect provides that WPP is enabled by a flag referred to as entropy_coding_sync_enabled_flag.

[0009] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the first value is 1 when WPP is enabled.

[0010] Optionally, in any of the preceding aspects, another implementation of the aspect provides displaying an image generated based on the reconstructed plurality of CTBs.

[0011] A second aspect relates to a method for encoding a video bitstream, performed by a video encoder, the method including: partitioning, by the video encoder, a picture into one or more slices, each slice including one or more tiles, each tile including a plurality of coding tree blocks (CTBs); encoding, by the video encoder, a tile end bit having a first value and a byte alignment bit into the video bitstream when a current CTB from the plurality of CTBs is the last CTB in the tile; encoding, by the video encoder, a CTB row end bit having a first value and a byte alignment bit into the video bitstream when waveform parallel processing (WPP) is enabled and when the current CTB is the last CTB in a CTB row but not the last CTB in the tile; and storing, by the video encoder, the video bitstream for transmission to a video decoder.

[0012] The method provides a technique for preventing duplication of signaling and byte alignment in WPP. By eliminating duplication of signaling and byte alignment in WPP, the number of bits used to signal the end of a row / tile and the number of bits used as padding are reduced. By reducing the number of bits required for WPP, the coder / decoder (also known as a "codec") in video coding is improved relative to current codecs. In practical terms, the improved video coding process provides users with a better user experience when video is transmitted, received, and / or viewed.

[0013] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the tile end bit is referred to as end_of_tile_one_bit.

[0014] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the CTB row end bit is referred to as end_of_subset_bit.

[0015] Optionally, in any of the preceding aspects, another implementation of the aspect provides that WPP is enabled by a flag located in the parameter set.

[0016] Optionally, in any of the preceding aspects, another implementation of the aspect provides that WPP is enabled by a flag referred to as entropy_coding_sync_enabled_flag.

[0017] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the first value is 1 when WPP is enabled.

[0018] Optionally, in any of the preceding aspects, another implementation of the aspect provides transmitting the video bitstream to a video decoder.

[0019] A third aspect relates to a decoding device, the decoding device including: a receiver configured to receive a coded video bitstream; a memory coupled to the receiver, the memory storing instructions; and a processor coupled to the memory, executing the instructions to cause the decoding device to receive the coded video bitstream, the coded video bitstream including a picture, the picture including one or more slices having one or more tiles, each tile including a plurality of coding tree blocks (CTBs); and encountering, in the coded video bitstream, a tile end bit having a first value and a byte alignment bit, wherein the tile end bit having the first value and the byte alignment bit are aligned. and a processor configured to: encounter, in the coded video bitstream, a CTB row end bit having a first value and a byte alignment bit, wherein the byte alignment bit indicates that waveform parallel processing (WPP) is enabled and that the current CTB from the plurality of CTBs is the last CTB in a CTB row but not the last CTB in a tile; and reconstruct the plurality of CTBs in the tile based on the tile end bit having the first value, the CTB row end bit having the first value, and the byte alignment bit.

[0020] The decoding device provides a technique for preventing duplication of signaling and byte alignment in WPP. By eliminating duplication of signaling and byte alignment in WPP, the number of bits used to signal the end of a row / tile and the number of bits used as padding are reduced. By reducing the number of bits required for WPP, the coder / decoder (also known as a "codec") in video coding is improved relative to current codecs. In practical terms, the improved video coding process provides users with a better user experience when video is transmitted, received, and / or viewed.

[0021] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the tile end bit is referred to as end_of_tile_one_bit, the CTB row end bit is referred to as end_of_subset_bit, and the first value is 1.

[0022] A fourth aspect relates to an encoding device including: a memory including instructions; and a processor coupled to the memory, the processor configured to execute the instructions to cause the encoding device to partition a picture into one or more slices, each slice including one or more tiles, each tile including a plurality of coding tree blocks (CTBs), encode a tile end bit having a first value and a byte alignment bit into a video bitstream when a current CTB from the plurality of CTBs is the last CTB in the tile, encode a CTB row end bit having a first value and a byte alignment bit into the video bitstream when waveform parallel processing (WPP) is enabled and the current CTB is the last CTB in a CTB row but not the last CTB in the tile, and store the video bitstream for transmission to a video decoder.

[0023] The encoding device provides a technique for preventing duplication of signaling and byte alignment in WPP. By eliminating duplication of signaling and byte alignment in WPP, the number of bits used to signal the end of a row / tile and the number of bits used as padding are reduced. By reducing the number of bits required for WPP, the coder / decoder (also known as a "codec") in video coding is improved relative to current codecs. In practical terms, the improved video coding process provides users with a better user experience when video is transmitted, received, and / or viewed.

[0024] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the encoding device further includes a transmitter coupled to the processor, the transmitter configured to transmit the video bitstream to the video decoder.

[0025] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the tile end bit is referred to as end_of_tile_one_bit, the CTB row end bit is referred to as end_of_subset_bit, and the first value is 1.

[0026] A fifth aspect relates to a coding apparatus including: a receiver configured to receive a picture to be encoded or a bitstream to be decoded, a transmitter coupled to the receiver and configured to transmit the bitstream to a decoder or transmit a decoded image to a display, a memory coupled to at least one of the receiver or the transmitter and configured to store instructions, and a processor coupled to the memory and configured to execute the instructions stored in the memory to perform any of the methods disclosed herein.

[0027] The coding device provides a technique for preventing overlapping of signaling and byte alignment in WPP. By eliminating overlapping of signaling and byte alignment in WPP, the number of bits used to signal the end of a row / tile and the number of bits used as padding are reduced. By reducing the number of bits required for WPP, the coder / decoder (also known as a "codec") in video coding is improved relative to current codecs. In practical terms, the improved video coding process provides users with a better user experience when video is transmitted, received, and / or viewed.

[0028] Optionally, in any of the preceding aspects, another implementation of the aspect provides a display configured to display the image.

[0029] A sixth aspect relates to a system, the system including an encoder and a decoder in communication with the encoder, the encoder or decoder including a decoding device, encoding device, or coding apparatus disclosed herein.

[0030] The system provides a technique for preventing duplication of signaling and byte alignment in WPP. By eliminating duplication of signaling and byte alignment in WPP, the number of bits used to signal the end of a row / tile and the number of bits used as padding are reduced. By reducing the number of bits required for WPP, the coder / decoder (also known as a "codec") in video coding is improved relative to current codecs. In practical terms, the improved video coding process provides users with a better user experience when video is transmitted, received, and / or viewed.

[0031] A seventh aspect relates to means for coding, the means for coding including: receiving means configured to receive a picture to be encoded or to receive a bitstream to be decoded, transmitting means coupled to the receiving means, the transmitting means configured to transmit the bitstream to the decoding means or to transmit a decoded image to the display means, storage means coupled to at least one of the receiving means or the transmitting means, the storage means configured to store instructions, and processing means coupled to the storage means, the processing means configured to execute the instructions stored in the storage means to perform any of the methods disclosed herein.

[0032] The coding means provides a technique for preventing duplication of signaling and byte alignment in WPP. By eliminating duplication of signaling and byte alignment in WPP, the number of bits used to signal the end of a row / tile and the number of bits used as padding are reduced. By reducing the number of bits required for WPP, the coder / decoder (also known as a "codec") in video coding is improved relative to current codecs. In practical terms, the improved video coding process provides users with a better user experience when video is transmitted, received, and / or viewed.

[0033] For a more complete understanding of this disclosure, reference is now made to the following brief description, which is taken in conjunction with the accompanying drawings and detailed description, wherein like reference numerals represent like parts. [Brief explanation of the drawings]

[0034] [Figure 1] FIG. 1 is a block diagram illustrating an example coding system that may utilize video coding techniques. [Figure 2] 1 is a block diagram illustrating an example video encoder that may perform video coding techniques. [Figure 3]1 is a block diagram illustrating an example of a video decoder that may perform video coding techniques. [Figure 4] 1 illustrates an example video bitstream structured to achieve wavefront parallel processing. [Figure 5] 1 is an embodiment of a method for decoding a coded video bitstream. [Figure 6] 1 is an embodiment of a method for encoding a coded video bitstream. [Figure 7] 1 is a schematic diagram of a video coding device. [Figure 8] FIG. 1 is a schematic diagram of an embodiment of a means for coding; DETAILED DESCRIPTION OF THE INVENTION

[0035] While example implementations of one or more embodiments are provided below, it should be understood at the outset that the disclosed systems and / or methods may be implemented using any number of techniques, whether currently known or in existence. The disclosure should in no way be limited to the example implementations, drawings, and techniques illustrated below, including the example designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.

[0036] The following terms are defined as follows, unless used in a contrary context herein. In particular, the following definitions are intended to provide additional clarity to the present disclosure. However, terms may be explained differently in different contexts. Therefore, the following definitions should be considered supplemental and not limiting of any other definitions of the descriptions provided for such terms herein.

[0037] A bitstream is a sequence of bits containing video data compressed for transmission between an encoder and a decoder. An encoder is a device configured to employ an encoding process to compress video data into a bitstream. A decoder is a device configured to employ a decoding process to reconstruct video data from the bitstream for display. A picture is a complete image intended for full or partial display to a user at a corresponding instant in a video sequence. A reference picture is a picture containing reference samples that can be used when coding other pictures by reference according to inter-prediction. A coded picture is a representation of a picture coded according to inter-prediction or intra-prediction, contained within a single access unit in the bitstream, and including the complete set of coding tree units (CTUs) of the picture. A slice is a division of a picture containing an integer number of complete tiles or an integer number of contiguous complete CTU rows within a tile of the picture, where the slice and all subdivisions are contained exclusively within a single network abstraction layer (NAL) unit. A reference slice is a slice of a reference picture that contains reference samples or is used when coding other slices by reference according to inter prediction. A slice header is a part of a coded slice that contains data elements related to all tiles or CTU rows within tiles represented in the slice. An entry point is a bit position in the bitstream that contains the first bit of video data for the corresponding subset of the coded slice. An offset is the distance in bits between a known bit position and the entry point. A subset is a subdivision of a set such as a tile, CTU row, or CTU. A CTU is a subset of a slice. A coding tree unit (CTU) is a group of samples of a predefined size that can be partitioned by a coding tree. A CTU is a luma / chroma component per CTU. The image is divided into coding tree blocks (CTBs) of 64x64, 32x32, or 16x16 pixels, with larger pixel block sizes typically increasing coding efficiency. The CTBs are then divided into one or more coding units (CUs), so the CTU size is also the maximum coding unit size.

[0038] A CTU row is a group of CTUs that extend horizontally between the left and right slice boundaries. A CTB row is a group of CTBs that extend horizontally between the left and right slice boundaries. A CTU column is a group of CTUs that extend vertically between the top and bottom slice boundaries. A CTB column is a group of CTBs that extend vertically between the top and bottom slice boundaries. A CTB row end bit is a bit at the end of a CTB row. A byte alignment bit is a bit added as padding to the end of a data subset, CTU row, CTB row, tile, etc. Byte alignment bits can be used to account for or compensate for delays introduced by WPP. WPP is a mechanism for coding CTU rows in a slice with a delay that allows each row to be decoded in parallel by different threads. A slice address is an identifiable location within a slice or its subdivisions.

[0039] The following acronyms are used herein: Coding Tree Block (CTB), Coding Tree Unit (CTU), Coding Unit (CU), Coded Video Sequence (CVS), Joint Video Experts Team (JVET), Motion-Constrained Tile Set (MCTS), Maximum Transfer Unit (MTU), Network Abstraction Layer (NAL), Picture Order Count (POC), Raw Byte Sequence Payload (RBSP), Sequence Parameter Set (SPS), Sub-Picture Unit (SPU), Versatile Video Coding (VVC), and Working Draft (WD).

[0040] FIG. 1 is a block diagram illustrating an example coding system 10 that may utilize video coding techniques as described herein. As depicted in FIG. 1, coding system 10 includes a source device 12 that provides encoded video data to be subsequently decoded by a destination device 14. In particular, source device 12 may provide the video data to destination device 14 via a computer-readable medium 16. Source device 12 and destination device 14 may include any of a wide range of devices, including desktop computers, notebook (e.g., laptop) computers, tablet computers, set-top boxes, telephone handsets such as so-called “smart” phones, so-called “smart” pads, televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, or the like. In some cases, source device 12 and destination device 14 may be equipped for wireless communication.

[0041] The destination device 14 may receive the encoded video data to be decoded via a computer-readable medium 16. The computer-readable medium 16 may include any type of medium or device capable of moving encoded video data from the source device 12 to the destination device 14. In one example, the computer-readable medium 16 may include a communication medium to enable the source device 12 to transmit the encoded video data directly to the destination device 14 in real time. The encoded video data may be modulated according to a communication standard, such as a wireless communication protocol, and transmitted to the destination device 14. The communication medium may include any wireless or wired communication medium, such as the radio frequency (RF) spectrum or one or more physical transmission lines. The communication medium may form part of a packet-based network, such as a local area network, a wide area network, or a global network such as the Internet. The communication medium may include routers, switches, base stations, or any other equipment that may be useful for facilitating communication from the source device 12 to the destination device 14.

[0042] In some examples, the encoded data may be output from output interface 22 to a storage device. Similarly, the encoded data may be accessed from a storage device by an input interface. The storage device may include any of a variety of distributed or locally accessed data storage media, such as a hard drive, a Blu-ray disc, a digital video disc (DVD), a compact disc read-only memory (CD-ROM), flash memory, volatile or non-volatile memory, or any other suitable digital storage medium for storing encoded video data. In a further example, the storage device may correspond to a file server or another intermediate storage device that may store the encoded video generated by source device 12. Destination device 14 may access the stored video data from the storage device via streaming or download. The file server may be any type of server capable of storing encoded video data and transmitting the encoded video data to destination device 14. Exemplary file servers include a web server (e.g., for a website), a file transfer protocol (FTP) server, a network-attached storage (NAS) device, or a local disk drive. Destination device 14 may access the encoded video data through any standard data connection, including an Internet connection. This may include a wireless channel (e.g., a Wi-Fi connection), a wired connection (e.g., a digital subscriber line (DSL), a cable modem, etc.), or a combination of both, suitable for accessing encoded video data stored on a file server. The transmission of the encoded video data from the storage device may be a streaming transmission, a download transmission, or a combination thereof.

[0043] The techniques of this disclosure are not necessarily limited to wireless applications or settings. The techniques may be applied to video coding supporting any of a variety of multimedia applications, such as terrestrial television broadcast, cable television transmission, satellite television transmission, Internet streaming video transmission such as dynamic adaptive streaming over HTTP (DASH), digital video encoded on a data storage medium, decoding of digital video stored on a data storage medium, or other applications. In some examples, coding system 10 may be configured to support one-way or two-way video transmission to support applications such as video streaming, video playback, video broadcasting, and / or video telephony.

[0044] In the example of FIG. 1, source device 12 includes a video source 18, a video encoder 20, and an output interface 22. Destination device 14 includes an input interface 28, a video decoder 30, and a display device 32. According to this disclosure, video encoder 20 of source device 12 and / or video decoder 30 of destination device 14 may be configured to apply techniques for video coding. In other examples, the source device and destination device may include other components or arrangements. For example, source device 12 may receive video data from an external video source, such as an external camera. Similarly, destination device 14 may interface with an external display device rather than including an integrated display device.

[0045] The illustrated coding system 10 of FIG. 1 is merely an example. The techniques for video coding may be performed by any digital video encoding and / or decoding device. While the techniques of this disclosure are generally performed by a video coding device, the techniques may also be performed by a video encoder / decoder, typically referred to as a "codec." Moreover, the techniques of this disclosure may also be performed by a video preprocessor. The video encoder and / or decoder may be a graphics processing unit (GPU) or similar device.

[0046] Source device 12 and destination device 14 are merely examples of such coding devices, in which source device 12 generates coded video data for transmission to destination device 14. In some examples, source device 12 and destination device 14 may operate in a substantially symmetric manner, such that each of source and destination devices 12, 14 includes video encoding and decoding components. Thus, coding system 10 may support one-way or two-way video transmission between video devices 12, 14, e.g., for video streaming, video playback, video broadcasting, or video telephony.

[0047] Video source 18 of source device 12 may include a video capture device, such as a video camera, a video archive containing previously captured video, and / or a video feed interface for receiving video from a video content provider. As a further alternative, video source 18 may generate computer graphics-based data as the source video, or a combination of live video, archived video, and computer-generated video.

[0048] In some cases, when video source 18 is a video camera, source device 12 and destination device 14 may form a so-called cameraphone or videophone. However, as mentioned above, the techniques described in this disclosure may be applicable to video coding generally and may be applied to wireless and / or wired applications. In each case, captured, pre-captured, or computer-generated video may be encoded by video encoder 20. The encoded video information may then be output onto computer-readable medium 16 by output interface 22.

[0049] Computer-readable medium 16 may include transient media, such as a wireless broadcast or wired network transmission, or storage media (i.e., non-transitory storage media), such as a hard disk, flash drive, compact disc, digital video disc, Blu-ray® disc, or other computer-readable medium. In some examples, a network server (not shown) may receive encoded video data from source device 12, for example, via a network transmission, and provide the encoded video data to destination device 14. Similarly, a computing device of a media creation facility, such as a disc stamping facility, may receive encoded video data from source device 12 and produce a disc including the encoded video data. Thus, in various examples, computer-readable medium 16 may be understood to include one or more computer-readable media of various forms.

[0050] Input interface 28 of destination device 14 receives information from computer-readable medium 16. The information on computer-readable medium 16 may include syntax information defined by video encoder 20 that is also used by video decoder 30, including syntax elements that describe characteristics and / or processing of blocks and other coded units, e.g., group of pictures (GOPs). Display device 32 displays the decoded video data to a user and may include any of a variety of display devices, such as a cathode ray tube (CRT), a liquid crystal display (LCD), a plasma display, an organic light-emitting diode (OLED) display, or another type of display device.

[0051] Video encoder 20 and video decoder 30 may operate in accordance with a video coding standard, such as the High Efficiency Video Coding (HEVC) standard currently under development, and may conform to the HEVC Test Model (HM). Alternatively, video encoder 20 and video decoder 30 may operate in accordance with other proprietary or industry standards, such as the International Telecommunications Union Telecommunication Standardization Sector (ITU-T) H.264 standard, known as Moving Picture Expert Group (MPEG)-4 Part 10, Advanced Video Coding (AVC), H.265 / HEVC, or extensions of such standards. However, the techniques of this disclosure are not limited to any particular coding standard. Other examples of video coding standards include MPEG-2 and ITU-T H.263. 1, in some aspects, video encoder 20 and video decoder 30 may each be integrated with an audio encoder and decoder and may include appropriate multiplexer-demultiplexer (MUX-DEMUX) units or other hardware and software for handling the encoding of both audio and video in a common data stream or separate data streams. If applicable, the MUX-DEMUX units may conform to the ITU H.223 multiplexer protocol or other protocols such as the User Datagram Protocol (UDP).

[0052] Video encoder 20 and video decoder 30 may each be implemented as any of a variety of suitable encoder circuits, such as one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), discrete logic, software, hardware, firmware, or any combination thereof. When the techniques are implemented partially in software, a device may store instructions for the software on a suitable non-transitory computer-readable medium and execute the instructions in hardware using one or more processors to perform the techniques of this disclosure. Each of video encoder 20 and video decoder 30 may be included in one or more encoders or decoders, any of which may be integrated within the respective device as part of a combined encoder / decoder (codec). Devices including video encoder 20 and / or video decoder 30 may include integrated circuits, microprocessors, and / or wireless communication devices such as cellular telephones.

[0053] 2 is a block diagram illustrating an example of a video encoder 20 that may perform video coding techniques. Video encoder 20 may perform intra- and inter-coding of video blocks within video slices. Intra-coding relies on spatial prediction to reduce or remove spatial redundancy in video within a given video frame or picture. Inter-coding relies on temporal prediction to reduce or remove temporal redundancy in video within adjacent frames or pictures of a video sequence. Intra-mode (I-mode) may refer to any of several spatial-based coding modes. Inter-modes, such as unidirectional (also known as uni-prediction) prediction (P-mode) or bi-prediction (also known as bi-prediction) (B-mode), may refer to any of several temporal-based coding modes.

[0054] As shown in FIG. 2, video encoder 20 receives a current video block in a video frame to be encoded. In the example of FIG. 2, video encoder 20 includes a mode select unit 40, a reference frame memory 64, an adder 50, a transform processing unit 52, a quantization unit 54, and an entropy coding unit 56. Mode select unit 40, in turn, includes a motion compensation unit 44, a motion estimation unit 42, an intra-prediction (also known as intra prediction) unit 46, and a partitioning unit 48. For video block reconstruction, video encoder 20 also includes an inverse quantization unit 58, an inverse transform unit 60, and an adder 62. A deblocking filter (not shown in FIG. 2) may also be included to filter block boundaries and remove blocky artifacts from the reconstructed video. If desired, the deblocking filter will typically filter the output of adder 62. In addition to the deblocking filter, additional filters (in-loop or post-loop) may also be used. Such a filter is not shown for simplicity, but could filter the output of summer 50 (as an in-loop filter) if desired.

[0055] During the encoding process, video encoder 20 receives a video frame or slice to be coded. The frame or slice may be divided into multiple video blocks. Motion estimation unit 42 and motion compensation unit 44 perform inter-predictive coding of the received video block relative to one or more blocks in one or more reference frames to provide temporal prediction. Intra-prediction unit 46 may alternatively perform intra-predictive coding of the received video block relative to one or more neighboring blocks in the same frame or slice as the block to be coded to provide spatial prediction. Video encoder 20 may perform multiple coding passes, for example, to select an appropriate coding mode for each block of video data.

[0056] Moreover, partition unit 48 may partition blocks of video data into sub-blocks based on an evaluation of a previous partitioning scheme in a previous coding pass. For example, partition unit 48 may first partition a frame or slice into largest coding units (LCUs) and then partition each of the LCUs into sub-coding units (sub-CUs) based on a rate-distortion analysis (e.g., rate-distortion optimization). Mode selection unit 40 may further create a quadtree data structure that indicates the partitioning of the LCUs into sub-CUs. A leaf-node CU of the quadtree may include one or more prediction units (PUs) and one or more transform units (TUs).

[0057] This disclosure uses the term "block" to refer to either a CU, PU, ​​or TU in the context of HEVC, or similar data structures in the context of other standards (e.g., macroblocks and their sub-blocks in H.264 / AVC). A CU includes a coding node, a PU, and a TU associated with the coding node. The size of a CU corresponds to the size of the coding node and is square in shape. The size of a CU may range from 8x8 pixels to the size of a treeblock, having a maximum of 64x64 pixels or more. Each CU may include one or more PUs and one or more TUs. Syntax data associated with a CU may, for example, describe the partitioning of the CU into one or more PUs. The partitioning mode may differ between whether the CU is coded in skip or direct mode, intra-prediction mode, or inter-prediction (also known as inter-prediction) mode. A PU may be partitioned to be non-square in shape. Syntax data associated with a CU may also describe the partitioning of the CU into one or more TUs, for example, according to a quadtree. TUs can be square or non-square (eg, rectangular) in shape.

[0058] Mode select unit 40 may select one of the coding modes, intra or inter, based on the error result, for example, and provide the resulting intra- or inter-coded block to summer 50 to generate residual block data and to summer 62 to reconstruct the coded block for use as a reference frame. Mode select unit 40 also provides syntax elements such as motion vectors, intra-mode indicators, partition information, and other such syntax information to entropy coding unit 56.

[0059] Motion estimation unit 42 and motion compensation unit 44 may be highly integrated but are illustrated separately for conceptual purposes. Motion estimation performed by motion estimation unit 42 is the process of generating motion vectors that estimate motion for a video block. A motion vector may indicate, for example, the displacement of a PU of a video block within a current video frame or picture relative to a predictive block in a reference frame (or other coded unit) relative to a current block being coded within the current frame (or other coded unit). A predictive block is a block that is found to closely match a block to be coded in terms of pixel differences, which may be determined by sum of absolute difference (SAD), sum of square difference (SSD), or other difference metric. In some examples, video encoder 20 may calculate values ​​for sub-integer pixel locations of a reference picture stored in reference frame memory 64. For example, video encoder 20 may interpolate values ​​for quarter-pixel locations, eighth-pixel locations, or other fractional pixel locations of a reference picture. Thus, motion estimation unit 42 may perform motion searches for full-pixel and fractional-pixel locations and output motion vectors with fractional-pixel precision.

[0060] Motion estimation unit 42 calculates a motion vector for a PU of a video block in an inter-coded slice by comparing the position of the PU with the position of a predictive block of a reference picture. The reference pictures may be selected from a first reference picture list (List 0) or a second reference picture list (List 1), each of which identifies one or more reference pictures stored in reference frame memory 64. Motion estimation unit 42 sends the calculated motion vector to entropy coding unit 56 and motion compensation unit 44.

[0061] The motion compensation performed by motion compensation unit 44 may involve fetching or generating a predictive block based on the motion vector determined by motion estimation unit 42. Again, motion estimation unit 42 and motion compensation unit 44 may be functionally integrated in some examples. Upon receiving the motion vector for the PU of the current video block, motion compensation unit 44 may locate the predictive block to which the motion vector points within one of the reference picture lists. Adder 50 forms a residual video block by subtracting pixel values ​​of the predictive block from pixel values ​​of the current video block being coded to form pixel difference values, as discussed below. Generally, motion estimation unit 42 performs motion estimation on the luma component, and motion compensation unit 44 uses the motion vector calculated based on the luma component for both the chroma and luma components. Mode select unit 40 may also generate syntax elements associated with the video blocks and video slices for use by video decoder 30 in decoding the video blocks of the video slices.

[0062] Intra prediction unit 46 may intra predict the current block as an alternative to inter prediction performed by motion estimation unit 42 and motion compensation unit 44, as described above. In particular, intra prediction unit 46 may determine an intra prediction mode to use to encode the current block. In some examples, intra prediction unit 46 may encode the current block using different intra prediction modes, e.g., during separate encoding passes, and intra prediction unit 46 (or, in some examples, mode selection unit 40) may select an appropriate intra prediction mode to use from the tested modes.

[0063] For example, intra prediction unit 46 may use a rate-distortion analysis to calculate rate-distortion values ​​for various tested intra prediction modes and select an intra prediction mode with the best rate-distortion characteristics from among the tested modes. The rate-distortion analysis generally determines the amount of distortion (or error) between a coded block and the original uncoded block that was coded to produce the coded block, as well as the bit rate (i.e., the number of bits) used to produce the coded block. Intra prediction unit 46 may calculate a ratio from the distortion and rate for various coded blocks to determine which intra prediction mode exhibits the best rate-distortion value for the block.

[0064] Additionally, intra-prediction unit 46 may be configured to code the depth blocks of the depth map using a depth modeling mode (DMM). Mode select unit 40 may determine whether an available DMM mode produces better coding results than the intra-prediction mode and other DMM modes, for example, using rate-distortion optimization (RDO). Data for texture images corresponding to the depth map may be stored in reference frame memory 64. Motion estimation unit 42 and motion compensation unit 44 may also be configured to inter-predict the depth blocks of the depth map.

[0065] After selecting an intra-prediction mode for the block (e.g., one of the intra-prediction mode or the DMM mode), intra-prediction unit 46 may provide information indicating the selected intra-prediction mode for the block to entropy coding unit 56. Entropy coding unit 56 may encode the information indicating the selected intra-prediction mode. Video encoder 20 may include configuration data within the transmitted bitstream, which may include multiple intra-prediction mode index tables and multiple modified intra-prediction mode index tables (also referred to as codeword mapping tables), definitions of coding contexts for various blocks, and an indication of the most likely intra-prediction mode, intra-prediction mode index table, and modified intra-prediction mode index table to use for each of the contexts.

[0066] Video encoder 20 forms a residual video block by subtracting the prediction data from mode select unit 40 from the original video block being coded. Summer 50 represents one or more components that perform this subtraction operation.

[0067] Transform processing unit 52 applies a transform, such as a discrete cosine transform (DCT) or a conceptually similar transform, to the residual block, producing a video block that includes residual transform coefficient values. Transform processing unit 52 may perform other transforms that are conceptually similar to the DCT. Wavelet transforms, integer transforms, subband transforms, or other types of transforms may also be used.

[0068] Transform processing unit 52 applies a transform to the residual block to produce a block of residual transform coefficients. The transform may convert the residual information from the pixel value domain to a transform domain, such as the frequency domain. Transform processing unit 52 may send the resulting transform coefficients to quantization unit 54. Quantization unit 54 quantizes the transform coefficients to further reduce the bit rate. The quantization process may reduce the bit depth associated with some or all of the coefficients. The degree of quantization may be modified by adjusting a quantization parameter. In some examples, quantization unit 54 may then perform a scan of a matrix including the quantized transform coefficients. Alternatively, entropy coding unit 56 may perform the scan.

[0069] Following quantization, entropy coding unit 56 entropy codes the quantized transform coefficients. For example, entropy coding unit 56 may perform context-adaptive variable length coding (CAVLC), context-adaptive binary arithmetic coding (CABAC), syntax-based context-adaptive binary arithmetic coding (SBAC), probability interval partitioning entropy (PIPE) coding, or another entropy coding technique. In the case of context-based entropy coding, the context may be based on neighboring blocks. Following entropy coding by entropy coding unit 56, the encoded bitstream may be transmitted to another device (e.g., video decoder 30) or archived for later transmission or retrieval.

[0070] Inverse quantization unit 58 and inverse transform unit 60 apply inverse quantization and inverse transform, respectively, to reconstruct the residual block in the pixel domain, e.g., for later use as a reference block. Motion compensation unit 44 may calculate a reference block by adding the residual block to a predictive block of one of the frames in reference frame memory 64. Motion compensation unit 44 may also apply one or more interpolation filters to the reconstructed residual block to calculate sub-integer pixel values ​​for use in motion estimation. Adder 62 adds the reconstructed residual block to the motion-compensated predictive block produced by motion compensation unit 44 to produce a reconstructed video block for storage in reference frame memory 64. The reconstructed video block may be used by motion estimation unit 42 and motion compensation unit 44 as a reference block for inter-coding blocks in subsequent video frames.

[0071] 3 is a block diagram illustrating one example of a video decoder 30 that may perform video coding techniques. In the example of FIG. 3, video decoder 30 includes an entropy decoding unit 70, a motion compensation unit 72, an intra prediction unit 74, an inverse quantization unit 76, an inverse transform unit 78, a reference frame memory 82, and an adder 80. Video decoder 30 may, in some examples, perform a decoding path that is generally inverse to the encoding path described with respect to video encoder 20 (FIG. 2). Motion compensation unit 72 may generate prediction data based on motion vectors received from entropy decoding unit 70, while intra prediction unit 74 may generate prediction data based on an intra prediction mode indicator received from entropy decoding unit 70.

[0072] During the decoding process, video decoder 30 receives an encoded video bitstream from video encoder 20, representing video blocks of an encoded video slice and associated syntax elements. Entropy decoding unit 70 of video decoder 30 entropy decodes the bitstream to generate quantized coefficients, motion vectors or intra-prediction mode indicators, and other syntax elements. Entropy decoding unit 70 forwards the motion vectors and other syntax elements to motion compensation unit 72. Video decoder 30 may receive syntax elements at the video slice level and / or the video block level.

[0073] When a video slice is coded as an intra-coded (I) slice, intra prediction unit 74 may generate predictive data for video blocks of the current video slice based on the signaled intra prediction mode and data from previously decoded blocks of the current frame or picture. When a video frame is coded as an inter-coded (e.g., B, P, or GPB) slice, motion compensation unit 72 produces predictive blocks for video blocks of the current video slice based on motion vectors and other syntax elements received from entropy decoding unit 70. The predictive blocks may be produced from one of the reference pictures in one of the reference picture lists. Video decoder 30 may construct the reference frame lists, List 0 and List 1, using a default construction technique based on reference pictures stored in reference frame memory 82.

[0074] Motion compensation unit 72 determines prediction information for video blocks of the current video slice by analyzing the motion vectors and other syntax elements, and uses the prediction information to produce a predictive block for the current video block being decoded. For example, motion compensation unit 72 uses some of the received syntax elements to determine the prediction mode (e.g., intra or inter prediction) used to code the video blocks of the video slice, the inter-prediction slice type (e.g., B slice, P slice, or GPB slice), construction information for one or more of the reference picture lists for the slice, a motion vector for each inter-coded video block of the slice, an inter-prediction status for each inter-coded video block of the slice, and other information for decoding video blocks in the current video slice.

[0075] Motion compensation unit 72 may also perform interpolation based on an interpolation filter. Motion compensation unit 72 may use an interpolation filter such as that used by video encoder 20 during the encoding of the video block to calculate interpolated values ​​for sub-integer pixels of the reference block. In this case, motion compensation unit 72 may determine the interpolation filter used by video encoder 20 from the received syntax element and use that interpolation filter to produce the predictive block.

[0076] Data for texture images corresponding to the depth maps may be stored in reference frame memory 82. Motion compensation unit 72 may also be configured to inter-predict depth blocks of the depth maps.

[0077] In one embodiment, the video decoder 30 includes a user interface (UI) 84. The user interface 84 is configured to receive input from a user (e.g., a network administrator) of the video decoder 30. Through the user interface 84, the user can manage or change settings in the video decoder 30. For example, the user can input or otherwise provide values ​​for parameters (e.g., flags) to control the configuration and / or operation of the video decoder 30 according to the user's preferences. The user interface 84 may be a graphical user interface (GUI) that allows the user to interact with the video decoder 30 through, for example, graphical icons, drop-down menus, check boxes, etc. In some cases, the user interface 84 may receive information from the user via a keyboard, mouse, or other peripheral device. In one embodiment, the user can access the user interface 84 via a smartphone, tablet device, personal computer located remotely from the video decoder 30, etc. As used herein, the user interface 84 may be referred to as an external input or external means.

[0078] With the above in mind, video compression techniques perform spatial (intra-picture) prediction and / or temporal (inter-picture) prediction to reduce or remove redundancy inherent in video sequences. For block-based video coding, video slices (i.e., video pictures, or portions of video pictures) may be partitioned into video blocks, which may also be referred to as tree blocks, coding tree blocks (CTBs), coding tree units (CTUs), coding units (CUs), and / or coding nodes. Video blocks in an intra-coded (I) slice of a picture are encoded using spatial prediction with respect to reference samples in neighboring blocks in the same picture. Video blocks in an inter-coded (P or B) slice of a picture may use spatial prediction with respect to reference samples in neighboring blocks in the same picture, or temporal prediction with respect to reference samples in other reference pictures. Pictures may be referred to as frames, and reference pictures may be referred to as reference frames.

[0079] Spatial or temporal prediction results in a predictive block for the block to be coded. Residual data represents pixel differences between the original block to be coded and the predictive block. Inter-coded blocks are coded according to a motion vector that points to a block of reference samples forming the predictive block, and residual data that indicates the difference between the coded block and the predictive block. Intra-coded blocks are coded according to an intra-coding mode and the residual data. For further compression, the residual data may be transformed from the pixel domain to a transform domain, resulting in residual transform coefficients, which may then be quantized. The quantized transform coefficients, initially arranged in a two-dimensional array, may be scanned to produce a one-dimensional vector of transform coefficients, and entropy coding may be applied to achieve even more compression.

[0080] Image and video compression has experienced rapid growth, leading to a variety of coding standards. Such video coding standards include Advanced Video Coding (AVC), also known as ITU-T H.261, International Organization for Standardization / International Electrotechnical Commission (ISO / IEC) MPEG-1 Part 2, ITU-T H.262 or ISO / IEC MPEG-2 Part 2, ITU-T H.263, ISO / IEC MPEG-4 Part 2, ITU-T H.264 or ISO / IEC MPEG-4 Part 10, and High Efficiency Video Coding (HEVC), also known as ITU-T H.265 or MPEG-H Part 2. AVC includes extensions such as Scalable Video Coding (SVC), Multiview Video Coding (MVC) and Multiview Video Coding plus Depth (MVC+D), and 3D AVC (3D-AVC). HEVC includes extensions such as Scalable HEVC (SHVC), Multiview HEVC (MV-HEVC), and 3D HEVC (3D-HEVC).

[0081] There is also an emerging video coding standard named Versatile Video Coding (VVC) being developed by the ITU-T / ISO / IEC Joint Video Experts Team (JVET). The VVC standard has several working drafts, but one working draft (WD) of VVC in particular is referenced here: B. Bross, J. Chen, and S. Liu, "Versatile Video Coding (Draft 5)," JVET-N1001-v3, 13th JVET Meeting, March 27, 2019 (VVC Draft 5).

[0082] The description of the techniques disclosed herein is based on the developing video coding standard, Versatile Video Coding (VVC) by the ITU-T and ISO / IEC Joint Video Experts Team (JVET), although the techniques also apply to other video codec specifications.

[0083] A picture partitioning scheme in HEVC is discussed.

[0084] HEVC includes four different picture partitioning schemes: regular slice, dependent slice, tile, and wavefront parallel processing (WPP), which can be applied for maximum transfer unit (MTU) size adaptation, parallel processing, and reduced end-to-end delay.

[0085] Regular slices are similar to those in H.264 / AVC: each regular slice is encapsulated in its own Network Abstraction Layer (NAL) unit, and intra-picture prediction (intra-sample prediction, motion information prediction, coding mode prediction) and entropy coding dependencies across slice boundaries are disabled. Therefore, regular slices can be reconstructed independently from other regular slices in the same picture (although there may still be interdependencies due to loop filtering operations).

[0086] Regular slices are the only tool that can be used for parallelization that is also available in H.264 / AVC in a substantially identical form. Parallelization based on regular slices does not employ much inter-processor or inter-core communication (except for inter-processor or inter-core data sharing for motion compensation when decoding predictively coded pictures, which is typically much heavier than inter-processor or inter-core data sharing due to intra-picture prediction). However, for the same reason, the use of regular slices can incur significant coding overhead due to the bit cost of slice headers and the lack of prediction across slice boundaries. Furthermore, due to the intra-picture independence of regular slices and because each regular slice is encapsulated within its own NAL unit, regular slices also serve as an important mechanism for bitstream partitioning to meet MTU size requirements (in contrast to other tools mentioned below). In many cases, the goals of parallelization and MTU size compliance place contradictory demands on slice layout within a picture. The realization of this situation led to the development of the parallelization tools mentioned below.

[0087] Dependent slices have short slice headers and allow for bitstream partitioning at treeblock boundaries without breaking any intra-picture prediction. Essentially, dependent slices provide fragmentation of normal slices into multiple NAL units, which provides reduced end-to-end delay by allowing parts of a normal slice to be sent before the coding of the entire normal slice is complete.

[0088] In WPP, a picture is partitioned into a single row of coding treeblocks (CTBs). Entropy decoding and prediction are enabled using data from CTBs in other partitions. Parallel processing is enabled through parallel decoding of CTB rows, where the start of decoding of a CTB row is delayed by two CTBs to ensure that data associated with the CTBs above and to the right of the target CTB is available before the target CTB is decoded. Using this staggered start (which looks like a wavefront when represented diagrammatically), parallelization is possible using up to the same number of processors / cores as the picture contains CTB rows. Because intra-picture prediction between adjacent treeblock rows within a picture is allowed, the inter-processor / inter-core communication required to enable intra-picture prediction can be significant. WPP partitioning does not result in the creation of additional NAL units compared to when it is not applied, and therefore WPP is not a tool for MTU size adaptation. However, when MTU size adaptation is employed, regular slices can be used with WPP, with some coding overhead.

[0089] Tiles define horizontal and vertical boundaries that partition a picture into tile columns and rows. Before decoding the top-left CTB of the next tile in the picture's tile raster scan order, the scan order of the CTBs is changed to be local within the tile (in the tile's CTB raster scan order). Like regular slices, tiles break intra-picture prediction dependencies and entropy decoding dependencies. However, they are not required to be contained within individual NAL units (similar to WPP in this respect), and therefore tiles cannot be used for MTU size adaptation. Each tile can be processed by one processor / core, and the inter-processor / inter-core communication required for intra-picture prediction between processing units decoding adjacent tiles is limited to conveying a slice header that is shared when a slice spans more than one tile, and sharing related to loop filtering of reconstructed samples and metadata. When a slice contains more than one tile or WPP segment, the entry point byte offset for each tile or WPP segment other than the first one in the slice is signaled in the slice header.

[0090] For simplicity, constraints on the application of four different picture partitioning schemes are specified in HEVC. A given coded video sequence cannot contain both tiles and wavefronts for most of the profiles specified in HEVC. For each slice and tile, one or both of the following conditions should be met: 1) all coded treeblocks in a slice belong to the same tile; 2) all coded treeblocks in a tile belong to the same slice. Finally, a wavefront segment contains exactly one CTB row; when WPP is in use, if a slice starts within a CTB row, it should end within the same CTB row.

[0091] The picture partitioning scheme in VVC is discussed.

[0092] As noted above, HEVC includes four different picture partitioning schemes: slice, tile, and brick, and wavefront parallel processing (WPP), which can be applied for maximum transfer unit (MTU) size adaptation, parallel processing, and reduced end-to-end delay.

[0093] Tiles in VVC are similar to tiles in HEVC. Tiles define horizontal and vertical boundaries that partition a picture into tile columns and rows. In VVC, the concept of a tile is further refined by allowing tiles to be further divided horizontally to form bricks. Tiles that are not further divided are also considered bricks. The scan order of the CTBs is changed to be local within a brick (in the CTB raster scan order of the brick) before decoding the top-left CTB of the next brick in the brick raster scan order of the picture.

[0094] A slice in VVC contains one or more bricks. Each slice is encapsulated in its own NAL unit, and intra-picture prediction (intra-sample prediction, motion information prediction, coding mode prediction) and entropy coding dependencies across slice boundaries are disabled. Therefore, regular slices can be reconstructed independently from other regular slices in the same picture (although they may still have interdependencies due to loop filtering operations). VVC defines two types of slices: rectangular slices and raster scan slices. A rectangular slice contains one or more bricks that occupy a rectangular area in a picture. A raster scan slice contains one or more bricks that are in the raster scan order of the bricks in the picture.

[0095] The WPP feature in VVC is similar to that in HEVC, except that the VVC WPP has a latency of one CTU while the HEVC WPP has a latency of two CTUs. For HEVC WPP, a new decoding thread can start decoding the first CTU in its assigned CTU row after the previous CTU row has already decoded its first two CTUs, while for VVC WPP, a new decoding thread can start decoding the first CTU in its assigned CTU row after the previous CTU row has already decoded its first CTU.

[0096] The signaling of rectangular slices is discussed.

[0097] The structure of rectangular slices is signaled in the picture parameter set (PPS) by describing the number of rectangular slices in a picture. For each slice, a set of top-left brick indices and a difference value for deriving the bottom-right brick index are signaled to describe the slice's position in the picture and its size (i.e., in units of bricks). For raster scan slices, that information is signaled in the slice header using the index of the first brick in the raster scan slice and the number of bricks in the slice.

[0098] The portion of the PPS syntax table presented below contains syntax elements that describe the signaling of tile, brick, and rectangular slice information within a PPS.

[0099] [Table 1]

[0100] single_brick_per_slice_flag equal to 1 specifies that each slice referencing this PPS contains one brick. single_brick_per_slice_flag equal to 0 specifies that slices referencing this PPS may contain more than one brick. When not present, the value of single_brick_per_slice_flag is inferred to be equal to 1.

[0101] rect_slice_flag equal to 0 specifies that the bricks in each slice are in raster scan order and slice information is not signaled in the PPS. rect_slice_flag equal to 1 specifies that the bricks in each slice cover a rectangular area of ​​the picture and slice information is signaled in the PPS. When single_brick_per_slice_flag is equal to 1, rect_slice_flag is inferred to be equal to 1.

[0102] num_slices_in_pic_minus1 plus 1 specifies the number of slices in each picture that refer to the PPS. The value of num_slices_in_pic_minus1 shall be in the range 0 to NumBricksInPic - 1, inclusive. When not present and single_brick_per_slice_flag is equal to 1, the value of num_slices_in_pic_minus1 is inferred to be equal to NumBricksInPic - 1.

[0103] top_left_brick_idx[ i ] specifies the brick index of the brick located in the top-left corner of the i-th slice. For any i not equal to j, the value of top_left_brick_idx[ i ] shall not be equal to the value of top_left_brick_idx[ j ]. When absent, the value of top_left_brick_idx[ i ] is inferred to be equal to i. The length of the top_left_brick_idx[ i ] syntax element is Ceil( Log2( NumBricksInPic ) bits.

[0104] bottom_right_brick_idx_delta[ i ] specifies the difference between the brick index of the brick located in the bottom-right corner of the i-th slice and top_left_brick_idx[ i ]. When single_brick_per_slice_flag is equal to 1, the value of bottom_right_brick_idx_delta[ i ] is inferred to be equal to 0. The length of the bottom_right_brick_idx_delta[ i ] syntax element is Ceil( Log2( NumBricksInPic - top_left_brick_idx[ i ] ) ) bits.

[0105] It is a bitstream-compliant requirement that a slice shall contain either several complete tiles, or only a contiguous sequence of complete bricks of one tile.

[0106] The variables NumBricksInSlice[ i ] and BricksToSliceMap[ j ], which specify the number of bricks in the i th slice and the mapping of bricks to slices, are derived as follows:

[0107]

number

[0108] The signaling of WPP in VVC is discussed.

[0109] The signaling method for WPP in VVC is described in the syntax tables and semantics of PPS, slice header, and slice data.

[0110] As represented in the PPS syntax table section below, a flag in the PPS called entropy_coding_sync_enabled_flag specifies whether WPP is used for coding pictures that reference the PPS.

[0111] [Table 2]

[0112] When WPP is enabled for coding of a picture, the slice headers of all slices of the picture contain information about the entry points (i.e., offsets from the beginning of the slice payload data) used to access each subset of CTU rows for processing according to the WPP method. This information is signaled as shown in the slice header syntax table below.

[0113] [Table 3]

[0114] When WPP is enabled, each CTU row is called a data subset in the slice data payload. At the end of each data subset, a bit called end_of_subset_one_bit is signaled to indicate the end of the data subset. Furthermore, to ensure that the size of the data subset is a multiple of a byte (i.e., 8 bits), byte alignment is performed to add a byte alignment bit at the end of each data subset. The signaling of end_of_subset_one_bit and the byte alignment at the end of each subset are represented in the slice data syntax table below.

[0115] [Table 4]

[0116] Some of the challenges of using WPP and bricks are discussed.

[0117] First, when a slice contains multiple bricks and WPP is enabled for coding of a picture containing the slice, each CTU row of each brick in the slice is a data subset. At the end of each data subset, either the syntax element end_of_subset_one_bit is signaled to indicate the end of the CTU row, or the syntax element end_of_brick_one_bit is signaled to indicate the end of the CTU of the brick. However, it is not necessary to signal both syntax elements. Similarly, at the end of each data subset, there should be byte alignment, but it is not necessary for it to overlap.

[0118] When tiles, bricks, and WPP are used together, implementing WPP can be more complex, given that a slice may contain one or more tiles, and each tile may contain one or more bricks.

[0119] In order to solve the problems described above, the present disclosure provides the following aspects (each of which can be applied individually, and some of which can be applied in combination):

[0120] A first solution includes a method for decoding a video bitstream. In one embodiment, the video bitstream includes at least one picture including multiple slices, each slice including multiple bricks, and each brick of the multiple bricks including multiple coding tree blocks (CTUs). The method includes analyzing a parameter set to determine whether wavefront parallelism is enabled for a current picture and / or for a current slice. The method includes analyzing slice data of the current slice to obtain bricks and CTUs within each brick. The method further includes analyzing a current CTU within the brick and determining a position of the current CTU. In addition, the method includes signaling a bit to indicate the end of a CTU row and signaling a byte alignment bit when all of the following conditions are met: WPP is enabled for coding of the current slice, the current CTU is not the last CTU of the current brick, and the next CTU in brick decoding order is not the first CTU of a CTU row within the current brick. The method includes signaling a bit to indicate the end of a brick when the current CTU is the last CTU in the current brick, and signaling a byte alignment bit when the current brick is the last CTU in the current brick but is not the last CTU of the current slice.

[0121] A second solution includes a method for encoding a video bitstream, the video bitstream including at least one picture including a plurality of slices, each slice of the plurality of slices including a plurality of tiles and bricks, each tile including one or more bricks, when WPP is enabled for encoding the current picture, the method includes constraining each slice of the current picture to include only one tile and each tile to include only one brick.

[0122] A second alternative solution includes a method for encoding a video bitstream. The video bitstream includes at least one picture including a plurality of slices, each slice including a plurality of tiles and bricks, and each tile including one or more bricks. The method includes, when WPP is enabled for encoding the current picture, constraining each tile of the current picture to include only one brick. That is, when the value of entropy_coding_sync_enabled_flag is equal to 1, the value of brick_splitting_present_flag shall be equal to 0.

[0123] A second alternative solution includes a method for encoding a video bitstream. The video bitstream includes at least one picture including a plurality of slices, each slice of the plurality of slices including a plurality of tiles and bricks, and each tile including one or more bricks. The method includes, when WPP is enabled for encoding the current picture, constraining each slice of the current picture to include only one brick. That is, when the value of entropy_coding_sync_enabled_flag is equal to 1, the value of a variable NumBricksInCurrSlice shall be equal to 1.

[0124] 4 illustrates a video bitstream 400 configured to implement a WPP 450. As used herein, the video bitstream 400 may also be referred to as a coded video bitstream, a bitstream, or variations thereof. As shown in FIG. 4, the bitstream 400 includes a sequence parameter set (SPS) 402, a picture parameter set (PPS) 404, a slice header 406, and image data 408.

[0125] The SPS 402 contains data that is common to all pictures in a sequence of pictures (SOP). In contrast, the PPS 404 contains data that is common to the entire picture. The slice header 406 contains information about the current slice, such as the slice type and which reference pictures are used. The SPS 402 and PPS 404 may be collectively referred to as parameter sets. The SPS 402, PPS 404, and slice header 406 are types of Network Abstraction Layer (NAL) units. An NAL unit is a syntax structure that contains an indication of the type of data (e.g., coded video data) that follows. NAL units are classified into video coding layer (VCL) and non-VCL NAL units. VCL NAL units contain data representing values ​​of samples in a video picture, and non-VCL NAL units contain any associated additional information such as parameter sets (important header data that may apply to multiple VCL NAL units) and supplemental enhancement information (timing information and other supplemental data that may improve the usability of the decoded video signal but is not necessary for decoding the values ​​of samples in a video picture). Those skilled in the art will understand that bitstream 400 may contain other parameters and information in actual applications.

[0126] The image data 408 in Figure 4 includes data associated with the image or video being encoded or decoded. The image data 408 may simply be referred to as the payload, or the data carried within the bitstream 400. The image data 408 may be partitioned into one or more pictures, such as picture 410, picture 412, and picture 414. Although three pictures 410-414 are depicted in Figure 4, in an actual application, there may be more or fewer pictures.

[0127] In one embodiment, pictures 410-414 are each partitioned into slices, such as slice 416, slice 418, and slice 420. Although three slices (e.g., slices 416-420) are shown, more or fewer slices may be present in an actual application. In one embodiment, slices 416-420 are each partitioned into tiles, such as tile 422, tile 424, and tile 426. Although three tiles (e.g., tiles 422-426) are shown, more or fewer tiles may be present in an actual application. In one embodiment, tiles 422-426 are each partitioned into CTBs, such as CTB 428 and CTB 430. Although 40 CTBs (e.g., CTBs 428-430) are shown, more or fewer CTBs may be present in an actual application.

[0128] The WPP 450 may be employed to encode and / or decode the slices (e.g., slices 416-420). Thus, the WPP 450 may be employed by an encoder (e.g., video encoder 20) or a decoder (e.g., video decoder 30).

[0129] In one embodiment, WPP 450 is applied to tile 424, which is a partition of slice 416, which is a partition of picture 410. A tile includes multiple CTBs, such as CTB 428 and CTB 430. Each CTB (e.g., CTBs 428-430) is a group of samples of a predefined size that can be partitioned into coding blocks by a coding tree. CTBs 428 and 430 may be arranged in CTB rows 460, 462, 464, 466, and 468 and CTB columns 470, 472, 474, 476, 478, 480, 482, and 484. CTB rows 460-468 are groups of CTBs 428-430 that extend horizontally between the left boundary of tile 424 and the right boundary of tile 424. CTB columns 470-484 are groups of CTBs 428-430 that extend vertically between the top boundary of tile 424 and the bottom boundary of tile 424. In one embodiment, WPP 450 is applied to slices (e.g., slice 416) instead of tiles (e.g., 424). That is, tiles are optional in some embodiments.

[0130] The WPP 450 may employ multiple computational threads operating in parallel to code the CTBs 428-430. In the depicted example, the CTB 428 (shaded) has been coded, but the CTB 430 (unshaded) has not yet been coded. For example, a first thread may begin coding the CTB row 460 at a first time. In VVC, once one CTB 428 in the first CTB row 460 is coded, a second thread may begin coding the CTB row 462. Once one CTB 428 in the second CTB row 462 is coded, a third thread may begin coding the CTB row 464. Once one CTB 428 in the third CTB row 464 is coded, a fourth thread may begin coding the CTB row 466. Once one CTB 428 in the fourth CTB row 466 is coded, the fifth thread may begin coding the fifth CTB row 468. This results in the pattern depicted in FIG. 4. Additional threads may be employed as needed; that is, the process of starting a new CTB row after a CTB in the previous row is coded may be repeated. This mechanism produces a pattern that has a wavefront-like appearance, hence the name WPP 450. Some video coding mechanisms code a current CTB 430 based on coded CTBs 428 located above or to the left of the current CTB 430. In VVC, WPP 450 leaves one CTB 430 coding delay between launching each thread to ensure that any current CTB 430 to be coded has already been coded when it arrives. In HEVC, WPP 450 leaves two CTB 430 coding delays between launching each thread to ensure that any current CTB 430 to be coded has already been coded when it arrives.

[0131] The CTBs 428 are coded in a bitstream (e.g., bitstream 400) within CTB rows 460-468. Thus, each CTB row 460-468 may be an independently addressable subset of a tile 424 in bitstream 400. For example, each CTB row 460-468 may be addressed at an entry point 486. The entry point 486 is the bit position in bitstream 400 that contains the first bit of video data for the corresponding subset of tile 424 after the tile 424 is coded. When WPP 450 is employed, the entry point 486 is the bit position that contains the first bit of the corresponding CTB row 460-468. Thus, the number of entry points (NumEntryPoints) 488 is the number of entry points 486 for the CTB rows 460-468.

[0132] Using tile 424 in FIG. 4 as an example, the encoder adds a CTB row end bit at the end of each CTB row 460-468 in WPP. The CTB row end bit signals the end of CTB rows 460-468 to the decoder. The encoder then performs byte alignment and adds the byte alignment bit as padding. In addition, the encoder also adds a tile end bit at the end of CTB row 468 in WPP. The tile end bit signals the end of tile 424 to the decoder. The encoder then performs byte alignment and adds the byte alignment bit as padding. Because the end of CTB row 468 is also the end of tile 424, the encoder in WPP encodes the CTB row end bit and tile end bit after the last CTB 430 in CTB row 468 is coded, performing byte alignment twice. Therefore, there is duplication of signaling and byte alignment in WPP.

[0133] Techniques for preventing overlapping of signaling and byte alignment in WPP are disclosed herein. By eliminating overlapping of signaling and byte alignment in WPP, the number of bits used to signal the end of a tile and the number of bits used as padding are reduced. By reducing the number of bits required for WPP, coders / decoders (also known as "codecs") in video coding are improved relative to current codecs. In practical terms, the improved video coding process provides users with a better user experience when video is transmitted, received, and / or viewed.

[0134] Unlike the WPP described above, the present disclosure only signals the end of a tile bit after the last CTB 430 in a CTB row 468 is coded, and performs byte alignment only once. In doing so, the number of signaling bits and the number of bits used as padding are reduced relative to the WPP.

[0135] 5 is one embodiment of a method 500 for decoding a coded video bitstream performed by a video decoder (e.g., video decoder 30). Method 500 may be performed after receiving a decoded bitstream directly or indirectly from a video encoder (e.g., video encoder 20). Method 500 improves the decoding process by reducing the number of signaling bits and bits used as padding following the coding of the last CTB (e.g., CTB 430) in the last CTB row (e.g., CTB row 468) of a tile (e.g., tile 424). Thus, in practical terms, codec performance is improved, which leads to a better user experience.

[0136] At block 502, a video decoder receives a coded video bitstream (e.g., bitstream 400). In one embodiment, the coded video bitstream includes a picture (e.g., picture 410). In one embodiment, the picture includes one or more slices (e.g., slices 416-420) having one or more tiles (e.g., tiles 422-426). In one embodiment, each tile includes multiple coding tree blocks (e.g., CTBs 428-430).

[0137] In block 504, the video decoder encounters, in the coded video bitstream, an end of tile bit and a byte alignment bit having a first value. In one embodiment, the end of tile bit is referred to as end_of_tile_one_bit. In one embodiment, the first value is 1. In one embodiment, the byte alignment bit is a result of a bit alignment process performed by an encoder (e.g., video encoder 20). In one embodiment, the end of tile bit and the byte alignment bit having the first value indicate that a current CTB (e.g., CTB 430) from multiple CTBs (e.g., CTBs 428-430) is the last CTB in a tile (e.g., tile 424).

[0138] In block 506, the video decoder encounters a CTB row end bit and a byte alignment bit in the coded video bitstream having a first value. In one embodiment, the CTB row end bit is referred to as end_of_subset_bit. In one embodiment, the first value is 1. In one embodiment, the byte alignment bit is a result of a bit alignment process performed by an encoder (e.g., video encoder 20). In one embodiment, the CTB row end bit and the byte alignment bit having the first value indicate that WPP is enabled and that a current CTB (e.g., CTB 430) from multiple CTBs (e.g., CTBs 428-430) is the last CTB in a CTB row (e.g., CTB rows 460-466) but is not the last CTB in a tile (e.g., tile 424).

[0139] At block 508, the video decoder reconstructs the plurality of CTBs in the tile based on the tile end bit having the first value, the CTB row end bit having the first value, and the byte alignment bit. In one embodiment, an image is generated based on the reconstructed plurality of CTBs. In one embodiment, the image may be displayed for a user of an electronic device (e.g., a smartphone, a tablet, a laptop, a personal computer, etc.).

[0140] 6 is one embodiment of a method 600 for encoding a video bitstream performed by a video encoder (e.g., video encoder 20). Method 600 may be performed when a picture (e.g., from a video) is to be encoded into a video bitstream and then transmitted to a video decoder (e.g., video decoder 30). Method 600 improves the encoding process by reducing the number of signaling bits and the number of bits used as padding following the coding of the last CTB (e.g., CTB 430) in the last CTB row (e.g., CTB row 468) of a tile (e.g., tile 424). Thus, in practical terms, codec performance is improved, which leads to a better user experience.

[0141] In block 602, the video encoder partitions a picture (e.g., picture 410) into one or more slices (e.g., slices 416-420). In one embodiment, each slice includes one or more tiles (e.g., tiles 422-426). In one embodiment, each tile includes multiple coding tree blocks (e.g., CTBs 428-430).

[0142] In block 604, the video encoder encodes a tile end bit having a first value and a byte alignment bit into the video bitstream when a current CTB from the plurality of CTBs is the last CTB in the tile. In one embodiment, the tile end bit is referred to as end_of_tile_one_bit. In one embodiment, the first value is 1. In one embodiment, the byte alignment bit is a result of a bit alignment process performed by an encoder (e.g., video encoder 20). In one embodiment, the tile end bit having the first value and the byte alignment bit indicate that a current CTB (e.g., CTB 430) from the plurality of CTBs (e.g., CTBs 428-430) is the last CTB in a tile (e.g., tile 424).

[0143] In block 606, the video encoder encodes a CTB row end bit having a first value and a byte alignment bit into the video bitstream when WPP is enabled and the current CTB is the last CTB in a CTB row but not the last CTB in a tile. In one embodiment, the CTB row end bit is referred to as end_of_subset_bit. In one embodiment, the first value is 1. In one embodiment, the byte alignment bit is a result of a bit alignment process performed by an encoder (e.g., video encoder 20). In one embodiment, the CTB row end bit having the first value and the byte alignment bit indicate that WPP is enabled and that a current CTB (e.g., CTB 430) from the plurality of CTBs (e.g., CTBs 428-430) is the last CTB in a CTB row (e.g., CTB rows 460-466) but is not the last CTB in a tile (e.g., tile 424).

[0144] The video encoder stores the video bitstream for transmission to the video decoder at block 608. In one embodiment, the video encoder transmits the video bitstream to the video decoder.

[0145] To implement the embodiments disclosed herein, the following syntax and semantics may be adopted. The following description is relative to the base text, which is the latest VVC draft specification. In other words, only the differences are described, but text in the base text that is not mentioned below applies as is. Text that is added to the base text is shown in bold, and text that is removed is shown in italics.

[0146] 7 is a schematic diagram of a video coding device 700 (e.g., video encoder 20 or video decoder 30) according to one embodiment of the disclosure. The video coding device 700 is suitable for performing the disclosed embodiments as described herein. The video coding device 700 includes an ingress port 710 and a receiver unit (Rx) 720 for receiving data, a processor, logic unit, or central processing unit (CPU) 730 for processing data, a transmitter unit (Tx) 740 and an egress port 750 for transmitting data, and a memory 760 for storing data. The video coding device 700 may also include optical-to-electrical (OE) components and electrical-to-optical (EO) components coupled to the ingress port 710, the receiver unit 720, the transmitter unit 740, and the egress port 750 for the egress or ingress of optical or electrical signals.

[0147] The processor 730 is implemented by hardware and software. The processor 730 may be implemented as one or more CPU chips, cores (e.g., as a multi-core processor), field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and digital signal processors (DSPs). The processor 730 communicates with the ingress port 710, the receiver unit 720, the transmitter unit 740, the egress port 750, and the memory 760. The processor 730 includes a coding module 770. The coding module 770 performs the disclosed embodiments described above. For example, the coding module 770 performs, processes, prepares, or provides various codec functions. Thus, the inclusion of the coding module 770 provides significant improvements to the functionality of the video coding device 700 and affects the conversion of the video coding device 700 to different states. Alternatively, the coding module 770 is implemented as instructions stored in the memory 760 and executed by the processor 730.

[0148] Video coding device 700 may also include input and / or output (I / O) devices 780 for communicating data to and from a user. I / O devices 780 may include output devices such as a display for displaying video data, speakers for outputting audio data, etc. I / O devices 780 may also include input devices such as a keyboard, mouse, trackball, etc., and / or corresponding interfaces for interacting with such output devices.

[0149] Memory 760 may include one or more disks, tape drives, and solid-state drives, and may be used as overflow data storage devices for storing programs when such programs are selected for execution, and for storing instructions and data read during program execution. Memory 760 may be volatile and / or non-volatile, and may be read-only memory (ROM), random access memory (RAM), ternary content-addressable memory (TCAM), and / or static random access memory (SRAM).

[0150] 8 is a schematic diagram of one embodiment of a means for coding 800. In one embodiment, the means for coding 800 is implemented within a video coding device 802 (e.g., video encoder 20 or video decoder 30). The video coding device 802 includes a means for receiving 801. The means for receiving 801 is configured to receive pictures to be encoded or a bitstream to be decoded. The video coding device 802 includes a means for transmitting 807 coupled to the means for receiving 801. The means for transmitting 807 is configured to transmit the bitstream to a decoder or transmit decoded images to a display means (e.g., one of the I / O devices 780).

[0151] The video coding device 802 includes a storage means 803. The storage means 803 is coupled to at least one of the receiving means 801 or the transmitting means 807. The storage means 803 is configured to store instructions. The video coding device 802 also includes a processing means 805. The processing means 805 is coupled to the storage means 803. The processing means 805 is configured to execute the instructions stored in the storage means 803 in order to perform the methods disclosed herein.

[0152] It should also be understood that the steps of the example methods described herein are not required to be performed in the order described, and the order of steps in such methods should be understood to be merely exemplary. Likewise, additional steps may be included in such methods, and certain steps may be omitted or combined in methods consistent with various embodiments of the present disclosure.

[0153] While several embodiments have been provided in this disclosure, it should be understood that the disclosed systems and methods may be embodied in many other specific forms without departing from the spirit or scope of the disclosure. The examples should be considered illustrative and not limiting, and the intention is not to be limited to the details provided herein. For example, various elements or components may be combined or integrated in another system, or certain features may be omitted or not implemented.

[0154] Additionally, techniques, systems, subsystems, and methods described and illustrated as individually or separately in various embodiments may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of the present disclosure. Other items depicted or discussed as coupled or directly coupled or in communication with each other may also be indirectly coupled or communicate through some interface, device, or intermediate component, whether electrically, mechanically, or otherwise. Other examples of changes, substitutions, and alterations are ascertainable by those skilled in the art and could be made without departing from the spirit and scope of the present disclosure. [Explanation of symbols]

[0155] 10 Coding Systems 12 Source devices, video devices 14 Destination Device 16 Computer-Readable Medium 18 Video Sources 20 Video Encoder 22 Output Interface 28 Input Interface 30 Video Decoder 32 Display Devices 40 Mode Selection Unit 42 Motion Estimation Unit 44 Motion Compensation Unit 46 intra prediction units 48 division units 50 Adder 52 Conversion Processing Unit 54 quantization units 56 Entropy coding unit, Entropy coding unit 58 Inverse Quantization Unit 60 Reverse conversion unit 62 Adder 64 Reference Frame Memory 70 Entropy Decoding Unit 72 Motion Compensation Unit 74 intra prediction units 76 Inverse Quantization Unit 78 Reverse conversion unit 80 Adder 82 Reference Frame Memory 84 User Interface (UI) 400 Video Bitstream 402 Sequence Parameter Set (SPS) 404 Picture Parameter Set (PPS) 406 slice header 408 Image Data 410 Pictures 412 Pictures 414 Pictures 416 slices 418 slices 420 slices 422 tiles 424 tiles 426 tiles 428 CTB 430 CTB 450 WPP 486 entry point 700 Video Coding Device 710 Inlet Port 720 Receiver Unit (Rx) 730 Processor, Logic Unit, Central Processing Unit (CPU) 740 Transmitter Unit (Tx) 750 outlet port 760 memory 770 Coding Module 780 Input and / or Output (I / O) Devices 800 Means to Code 801 Receiving means 802 Video Coding Device 803 Memory means 805 Processing means 807 Transmission Method

Claims

1. 1. A method of decoding performed by a video decoder according to Versatile Video Coding (VVC), comprising: receiving, by the video decoder, a coded video bitstream, the coded video bitstream including a parameter set and coded data representing a picture, the picture including one or more slices, each slice having only one tile, each tile including only one brick, each brick including multiple coding tree blocks (CTBs); analyzing, by the video decoder, the parameter set to determine whether wavefront parallelism is enabled for a current picture and / or for a current slice; analyzing, by the video decoder, slice data of the current slice to obtain bricks and a CTB within each brick; analyzing, by the video decoder, an end-of-brick bit and a byte alignment bit in the coded video bitstream, the end-of-brick bit having a first value, wherein the end-of-brick bit having the first value indicates that a current CTB from the plurality of CTBs is the last CTB in a brick, regardless of whether wavefront parallel processing (WPP) is enabled; analyzing, by the video decoder, a CTB row end bit having the first value and the byte alignment bit in the coded video bitstream, wherein the CTB row end bit having the first value indicates that wavefront parallel processing (WPP) is enabled and that the current CTB from the plurality of CTBs is the last CTB in a CTB row but is not the last CTB in the brick; reconstructing, by the video decoder, the plurality of CTBs in the brick based on the brick end bit having the first value, the CTB row end bit having the first value, and the byte alignment bit; A method comprising:

2. The method of claim 1 , wherein the end-of-brick bit is referred to as end_of_brick_one_bit.

3. The method of claim 1 or 2, wherein the CTB row end bit is referred to as end_of_subset_bit.

4. The method of claim 1 , wherein the WPP is enabled by a flag located in the parameter set.

5. The method of claim 4 , wherein the WPP is enabled by a flag referred to as entropy_coding_sync_enabled_flag.

6. The method of claim 4 , wherein the first value is 1 when the WPP is enabled.

7. The method of claim 1 , further comprising the step of displaying an image generated based on the reconstructed plurality of CTBs.

8. 1. A method of encoding performed by a video encoder according to Versatile Video Coding (VVC), comprising: partitioning, by the video encoder, a picture into one or more slices, where each slice includes only one tile, each tile includes only one brick, and each brick includes multiple coding tree blocks (CTBs); encoding, by the video encoder, a set of parameters for determining whether wavefront parallelism is enabled for a current picture and / or for a current slice; encoding, by the video encoder, slice data of the current slice to obtain bricks and a CTB within each brick; encoding, by the video encoder, an end-of-brick bit having a first value and a byte alignment bit into a video bitstream when a current CTB from the plurality of CTBs is the last CTB in a brick, regardless of whether wavefront parallel processing (WPP) is enabled; When wavefront parallel processing (WPP) is enabled and the current CTB is the last CTB in a CTB row but not the last CTB in the brick, encoding, by the video encoder, a CTB row end bit having the first value and a byte alignment bit into the video bitstream; A method comprising:

9. The method of claim 8 , wherein the end-of-brick bit is referred to as end_of_brick_one_bit.

10. The method of claim 8 or 9, wherein the CTB row end bit is referred to as end_of_subset_bit.

11. The method of claim 8 , wherein the WPP is enabled by a flag located in the parameter set.

12. The method of claim 11 , wherein the WPP is enabled by a flag named entropy_coding_sync_enabled_flag.

13. The method of claim 11 , wherein the first value is 1 when the WPP is enabled.

14. The method of claim 8 , further comprising transmitting the video bitstream to a video decoder.

15. 1. A decoding device, comprising: a receiver configured to receive the coded video bitstream; a memory coupled to the receiver, the memory storing instructions; a processor coupled to the memory, the processor configured to execute the instructions to cause the decoding device to perform the method of any one of claims 1 to 7; a decryption device including:

16. 1. A coding device, comprising: a memory containing instructions; a processor coupled to the memory, the processor configured to execute the instructions to cause the encoding device to perform the method of any one of claims 8 to 14; An encoding device including:

17. A decoder comprising: one or more processors; a non-transitory computer-readable storage medium coupled to the processor and storing programming for execution by the processor, the programming, when executed by the processor, configuring the decoder to perform the method of any one of claims 1 to 7; and A decoder containing

18. 1. An encoder comprising: one or more processors; a non-transitory computer-readable storage medium coupled to the processor and storing programming for execution by the processor, the programming, when executed by the processor, configuring the encoder to perform the method of any one of claims 8 to 14; and Encoder including.

19. An encoder; a decoder in communication with the encoder, 16. A system, wherein the decoder comprises the decoding device of claim 15.

20. An encoder; a decoder in communication with the encoder, 17. A system, wherein the encoder comprises the encoding device of claim 16.

21. receiving means configured to receive a bitstream to be decoded; transmitting means coupled to said receiving means, said transmitting means configured to transmit said bitstream to said decoding means; a storage means coupled to at least one of the receiving means or the transmitting means, the storage means configured to store instructions; processing means coupled to said storage means, said processing means being configured to execute the instructions stored in said storage means to perform the method of any one of claims 1 to 7; A means for coding, including

22. receiving means configured to receive a picture to be encoded; transmitting means coupled to said receiving means, said transmitting means being configured to transmit said pictures to said encoding means; a storage means coupled to at least one of the receiving means or the transmitting means, the storage means configured to store instructions; processing means coupled to said storage means, said processing means being configured to execute the instructions stored in said storage means to perform the method of any one of claims 8 to 14; A means for coding, including

23. A decoder comprising processing circuitry for carrying out the method of any one of claims 1 to 7.

24. An encoder comprising processing circuitry for carrying out the method of any one of claims 8 to 14.

25. 8. A computer program comprising a program code for performing the method according to any one of claims 1 to 7 when the computer program is run on a computer or processor.

26. 15. A computer program comprising a program code for performing the method according to any one of claims 8 to 14 when the computer program is run on a computer or processor.

27. A non-transitory computer readable medium carrying program code which, when executed by a computing device, causes said computing device to perform the method of any one of claims 1 to 7.

28. A non-transitory computer readable medium carrying program code which, when executed by a computing device, causes the computing device to perform the method of any one of claims 8 to 14.

Images