Encoder, decoder and corresponding methods for simplified strip header syntax element indication

Abstract

The invention provides a method for decoding an image from a video code stream by decoding equipment. The code stream comprises a stripe header of a current stripe and data representing the current stripe, and the method comprises the following steps: if a condition is satisfied, acquiring a parameter used for deriving the number of blocks in the current stripe from the stripe header, the condition comprises that the strip address of the current strip is not the address of the last block in the image where the current strip is located; and reconstructing the current stripe through the number of blocks in the current stripe and the data representing the current stripe.

Description

[0001] This application is a divisional application. The application number of the original application is 202180015669.6, and the original application date is March 1, 2021. The entire contents of the original application are incorporated into this application by reference.

[0002] Cross-reference to related applications

[0003] This patent application claims priority to international patent application PCT / EP2020 / 055341 filed on February 28, 2020. The entire disclosure of the above international patent application is incorporated by reference into this application. Technical Field

[0004] Embodiments of the present application (the present application) generally relate to the field of image processing, and more specifically to simplifying slice header syntax element indication. Background Art

[0005] Video coding (video encoding and decoding) is widely used in digital video applications such as broadcast digital television, video transmission over the Internet and mobile networks, real-time conversation applications such as video chat and video conferencing, DVD and Blu-ray Discs, video content acquisition and editing systems, and camcorders for security applications.

[0006] Even if a video is relatively short, a large amount of video data is required to describe it, which can cause difficulties when the data is to be streamed or otherwise transmitted over a communication network with limited bandwidth capacity. Therefore, video data is often compressed before being transmitted over modern telecommunications networks. Since memory resources may be limited, the size of the video may also be an issue when storing the video in a storage device. Video compression devices typically encode the video data using software and / or hardware on the source side and then transmit or store the video data, thereby reducing the amount of data required to represent the digital video image. A video decompression device that decodes the video data then receives the compressed data on the destination side. With limited network resources and a growing demand for higher video quality, there is a need for improved compression and decompression techniques that can increase the compression ratio with little impact on image quality. Summary of the invention

[0007] Embodiments of the present application provide various devices and methods for encoding and decoding according to the independent claims.

[0008] This application provides:

[0009] A method for decoding an image from a video bitstream implemented by a decoding device. The bitstream includes a slice header of a current slice and data representing the current slice, and the method includes: if a condition is met, obtaining a parameter (such as um_tiles_in_slice_minus1) for deriving the number of tiles in the current slice from the slice header, wherein the condition includes: the slice address (such as slice_address) of the current slice is not the address of the last tile in the image where the current slice is located; and reconstructing the current slice using the number of tiles in the current slice and the data representing the current slice.

[0010] In the method described above, the slice address of the current slice being the address of the last block in the image may include determining that the number of blocks in the image minus the slice address of the current slice is equal to 1.

[0011] In the method described above, the stripe address of the current stripe is not the address of the last block in the image, including determining that the number of tiles in the image (eg, NumTilesInPic) minus the stripe address of the current stripe is greater than 1.

[0012] Therefore, according to the present application, whether the image header structure exists in the stripe header can be used to control whether the stripe address and the number of blocks exist in the stripe indication. If there is a single stripe in an image, the stripe address should be equal to the first block in the image, and the number of blocks in the stripe should be equal to the number of blocks in the image. Therefore, this can improve compression efficiency.

[0013] In the method described above, when the condition is not satisfied, the value of the parameter of the current stripe may be inferred as a default value.

[0014] In the method described above, the default value may be equal to 0.

[0015] In the method described above, the stripe address may be in units of blocks.

[0016] In the method described above, the condition may further include: determining that the current strip is in a raster scanning mode.

[0017] In the method described above, reconstructing the current stripe according to the number of blocks in the current stripe may include: determining a scanning order of coding tree units in the current stripe according to the number of blocks in the current stripe; and reconstructing the coding tree units in the current stripe according to the scanning order.

[0018] The present application also provides a method for encoding a video code stream implemented by an encoding device. The code stream includes a slice header of a current slice and data representing the current slice, and the method includes: if a condition is met, encoding a parameter in the slice header for deriving the number of blocks in the current slice, wherein the condition includes: the slice address of the current slice is not the address of the last block in the image where the current slice is located; and reconstructing the current slice through the number of blocks in the current slice and the data representing the current slice.

[0019] The present application also provides a device for decoding an image from a video code stream. The code stream includes a stripe header of a current stripe and data representing the current stripe, and the device includes: an acquisition unit, used to: if a condition is met, acquire a parameter for deriving the number of blocks in the current stripe from the stripe header, wherein the condition includes: the stripe address of the current stripe is not the address of the last block in the image where the current stripe is located; a reconstruction unit, used to reconstruct the current stripe through the number of blocks in the current stripe and the data representing the current stripe.

[0020] The present application also provides a device for encoding a decoded video code stream. The code stream includes a slice header of a current slice and data representing the current slice, and the device includes: an encoding unit, which is used to: if a condition is met, encode a parameter in the slice header for deriving the number of blocks in the current slice, wherein the condition includes: the slice address of the current slice is not the address of the last block in the image where the current slice is located; a reconstruction unit, which is used to reconstruct the current slice through the number of blocks in the current slice and the data representing the current slice.

[0021] The present application also provides an encoder, wherein the encoder comprises a processing circuit, and the processing circuit is used to execute the above-described method for encoding a video code stream.

[0022] The present application also provides a decoder, wherein the decoder comprises a processing circuit, and the processing circuit is used to execute the method for decoding a video code stream described above.

[0023] The present application also provides a computer program product including program codes. When the program codes are executed on a computer or a processor, the program codes are used to execute the above-described method for encoding a video code stream or the above-described method for decoding a video code stream.

[0024] The present application also provides a decoder. The decoder includes: one or more processors; a non-transitory computer-readable storage medium, coupled to the one or more processors and storing a program executed by the one or more processors, wherein when the program is executed by the one or more processors, the decoder is used to perform the method for decoding a video code stream described above.

[0025] The present application also provides an encoder. The encoder includes: one or more processors; a non-transitory computer-readable storage medium, coupled to the one or more processors and storing a program executed by the one or more processors, wherein when the program is executed by the one or more processors, the encoder is used to execute the method for encoding a video code stream described above.

[0026] The present application also provides a non-transitory computer-readable medium including program code. When the program code is executed by a computer device, the computer device executes the method for encoding a video code stream described above or the method for decoding a video code stream described above.

[0027] The present application also provides a non-transient storage medium including a video code stream. The code stream includes a stripe header of a current stripe and data representing the current stripe, the stripe header includes a stripe address of the current stripe; if a condition is met, the stripe header also includes a parameter for deriving the number of blocks in the current stripe from the stripe header, the condition including: the stripe address of the current stripe is not the address of the last block in the image where the current stripe is located.

[0028] The following drawings and description will describe one or more embodiments in detail. Other features, objects and advantages are apparent in the description, drawings and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The embodiments of the present application are described in more detail below with reference to the accompanying drawings.

[0030] Figure 1A The block diagram is an example of a video decoding system for implementing an embodiment of the present application.

[0031] Figure 1B A block diagram of another example of a video decoding system for implementing an embodiment of the present application.

[0032] Figure 2 A block diagram of an example of a video encoder for implementing an embodiment of the present application.

[0033] Figure 3 A block diagram of an exemplary structure of a video decoder for implementing an embodiment of the present application.

[0034] Figure 4 A schematic diagram of a video decoding device provided for one embodiment of the present application.

[0035] Figure 5 A simplified block diagram of an apparatus provided for one embodiment of the present application.

[0036] Figure 6 An example of dividing an image into CTUs is shown.

[0037] Figure 7 An example of a raster scan order is shown.

[0038] Figure 8 An example of tiles, strips and sub-images is shown.

[0039] Fig. 9 An example is shown of a raster scan order in an image composed of CTUs and a stripe in the image.

[0040] Fig.10 The example shows that the image is divided into 12 blocks and 3 strips.

[0041] Fig.11 A block diagram of an example of an LMCS architecture.

[0042] Fig.12 A block diagram of an exemplary structure of a content provision system 3100 for implementing content distribution services.

[0043] Fig.13 A block diagram of an exemplary structure of a terminal device.

[0044] Fig.14 A flowchart of a method for decoding a video stream is provided in accordance with an embodiment of the present application.

[0045] Fig.15 A flowchart of a method for decoding a video stream is provided in accordance with an embodiment of the present application.

[0046] Fig.16 A flowchart of a decoder for decoding a video stream is provided according to an embodiment of the present application.

[0047] Fig.17 A flowchart of an encoder for encoding a video stream is provided for one embodiment of the present application.

[0048] In the following, identical reference numerals refer to identical features or at least functionally equivalent features, unless explicitly stated otherwise. DETAILED DESCRIPTION

[0049] In the following description, reference is made to the accompanying drawings that constitute a part of the present application, which illustrate specific aspects of the embodiments of the present application or specific aspects of the embodiments of the present application that can be used by way of illustration. It should be understood that the embodiments of the present application can be used in other aspects and may include structural changes or logical changes not depicted in the drawings. Therefore, the following detailed description is not to be understood in a restrictive sense, and the scope of the present application is defined by the appended claims.

[0050] For example, it should be understood that the disclosure related to describing a method may also be applicable to a corresponding device or system for performing the method, and vice versa. For example, if one or more specific method steps are described, the corresponding device may include one or more units (e.g., functional units) to perform the described one or more method steps (e.g., one unit performs one or more steps, or multiple units perform one or more steps of multiple steps respectively), even if such one or more units are not explicitly described or shown in the drawings. On the other hand, for example, if a specific device is described according to one or more units (e.g., functional units), the corresponding method may include a step to perform the function of one or more units (e.g., one step performs the function of one or more units, or multiple steps perform the function of one or more units of multiple units respectively), even if such one or more steps are not explicitly described or shown in the drawings. In addition, it should be understood that, unless otherwise explicitly stated, the features of the various exemplary embodiments and / or aspects described herein may be combined with each other.

[0051] Video decoding (coding) generally refers to processing a sequence of images that form a video or video sequence. In the field of video coding, the terms "frame" and "picture / image" can be used as synonyms. Video decoding (or commonly referred to as decoding) includes two parts: video encoding and video decoding. Video encoding is performed on the source side and generally includes processing (for example, by compression) the original video image to reduce the amount of data required to represent the video image (thereby more efficiently storing and / or transmitting). Video decoding is performed on the destination side and generally includes inverse processing relative to the encoder to reconstruct the video image. The "decoding" of the video image (or commonly referred to as the image) involved in the embodiment should be understood as the "encoding" or "decoding" of the video image or the corresponding video sequence. The encoding part and the decoding part are also collectively referred to as codec (encoding and decoding).

[0052] In the case of lossless video coding, the original video image can be reconstructed, that is, the reconstructed video image has the same quality as the original video image (assuming no transmission loss or other data loss during storage or transmission). In the case of lossy video coding, further compression is performed by quantization, etc. to reduce the amount of data representing the video image, and the decoder side cannot fully reconstruct the video image, that is, the quality of the reconstructed video image is lower or worse than the quality of the original video image.

[0053] Several video coding standards belong to the group of "lossy hybrid video codecs" (i.e., combining spatial and temporal prediction in the sample domain with 2D transform coding in the transform domain for applying quantization). Each picture in a video sequence is usually segmented into a set of non-overlapping blocks, and decoding is usually performed at the block level. In other words, the encoder usually processes the video at the block (video block) level, i.e., encodes it, for example, by generating a prediction block by spatial (intra) prediction and / or temporal (inter) prediction, subtracting the prediction block from the current block (currently processed / to be processed block) to obtain a residual block, transforming the residual block in the transform domain and quantizing the residual block to reduce the amount of data to be transmitted (compressed), while the decoder applies the inverse processing relative to the encoder to the coded or compressed block to reconstruct the current block for representation. In addition, the encoder replicates the decoder processing cycle, so that the encoder and the decoder generate the same prediction (e.g., intra-frame prediction and inter-frame prediction) and / or reconstruction to process, i.e., decode, subsequent blocks.

[0054] In the following embodiment of the video decoding system 10, the video encoder 20 and the video decoder 30 are based on Figures 1A to 3 Give a description.

[0055] Figure 1A 1 is a schematic block diagram of an exemplary decoding system 10, for example, a video decoding system 10 (or simply a decoding system 10) that can utilize the techniques in the present application. The video encoder 20 (or simply an encoder 20) and the video decoder 30 (or simply a decoder 30) in the video decoding system 10 are two examples, i.e., devices that can be used to perform various techniques according to various examples described in the present application.

[0056] like Figure 1A As shown, the decoding system 10 includes a source device 12 for providing encoded image data 21 to a destination device 14 or the like for decoding the encoded image data 21 .

[0057] The source device 12 includes an encoder 20 and may additionally (ie, optionally) include an image source 16 , a pre-processor (or pre-processing unit) 18 (eg, an image pre-processor 18 ), and a communication interface or communication unit 22 .

[0058] The image source 16 may include or may be any type of image capture device such as a camera for capturing real-world images, and / or any type of image generation device such as a computer graphics processor for generating computer-animated images, or any type of other device for acquiring and / or providing real-world images, computer-generated images (e.g., screen content, virtual reality (VR) images), and / or any combination thereof (e.g., augmented reality (AR) images). The image source may be any type of memory / storage for storing any of the above images.

[0059] In order to distinguish the pre-processor 18 and the processing performed by the pre-processing unit 18 , the image or image data 17 may also be referred to as a raw image or raw image data 17 .

[0060] The preprocessor 18 is used to receive (raw) image data 17 and perform preprocessing on the image data 17 to obtain a preprocessed image 19 or preprocessed image data 19. The preprocessing performed by the preprocessor 18 may include trimming, color format conversion (e.g., from RGB to YCbCr), color adjustment or denoising, etc. It can be understood that the preprocessing unit 18 may be an optional component.

[0061] The video encoder 20 is used to receive the pre-processed image data 19 and provide the encoded image data 21 (hereinafter referred to as Figure 2 etc. provide more detailed description).

[0062] The communication interface 22 in the source device 12 can be used to receive the encoded image data 21 and send the encoded image data 21 (or data obtained after further processing of the encoded image data 21) to another device, such as the destination device 14 or any other device, through the communication channel 13 for storage or direct reconstruction.

[0063] The destination device 14 includes a decoder 30 (eg, a video decoder 30 ), and may additionally (ie, optionally) include a communication interface or communication unit 28 , a post-processor 32 (or a post-processing unit 32 ), and a display device 34 .

[0064] The communication interface 28 in the destination device 14 is used to receive the encoded image data 21 (or data obtained after further processing of the encoded image data 21) directly from the source device 12 or from any other source such as a storage device (such as an encoded image data storage device), and provide the encoded image data 21 to the decoder 30.

[0065] Communication interface 22 and communication interface 28 can be used to send or receive encoded image data 21 or encoded data 13 via a direct communication link (e.g., a direct wired or wireless connection) between source device 12 and destination device 14 or via any type of network (e.g., a wired network, a wireless network, or any combination thereof, or any type of private and public network, or any type of combination thereof).

[0066] For example, the communication interface 22 may be used to encapsulate the encoded image data 21 into a suitable format (eg, data packets), and / or process the encoded image data by any type of transmission coding or processing for transmission over a communication link or communication network.

[0067] For example, the communication interface 28 corresponding to the communication interface 22 may be used to receive the transmission data and process the transmission data using any type of corresponding transmission decoding or processing manner and / or decapsulation manner to obtain the encoded image data 21 .

[0068] Both the communication interface 22 and the communication interface 28 can be configured as Figure 1A The unidirectional communication interface indicated by the arrow of the communication channel 13 pointing from the source device 12 to the destination device 14, or is configured as a bidirectional communication interface, and can be used to send and receive messages, etc. to establish a connection, confirm and exchange any other information related to the communication link and / or data transmission (such as encoded image data transmission), etc.

[0069] The decoder 30 is used to receive the encoded image data 21 and provide decoded image data 31 or decoded image 31 (hereinafter referred to as Figure 3 or Figure 5 etc. provide more detailed description).

[0070] The post-processor 32 in the destination device 14 is used to post-process the decoded image data 31 (also referred to as reconstructed image data) (e.g., decoded image 31) to obtain post-processed image data 33 (e.g., post-processed image 33). The post-processing performed by the post-processing unit 32 may include color format conversion (e.g., from YCbCr to RGB), color adjustment, cropping or resampling, or any other processing to provide the decoded image data 31 for display by the display device 34, etc.

[0071] The display device 34 in the destination device 14 is used to receive the post-processed image data 33 so as to display the image to a user or viewer, etc. The display device 34 can be or include any type of display for representing the reconstructed image, such as an integrated or external display or display screen. For example, the display can include a liquid crystal display (LCD), an organic light emitting diode (OLED) display, a plasma display, a projector, a micro LED display, a liquid crystal on silicon (LCoS) display, a digital light processor (DLP), or any other type of display.

[0072] Although Figure 1A The source device 12 and the destination device 14 are shown as separate devices, but the device embodiments may also include both devices or the functions of both devices, that is, the source device 12 or the corresponding functions and the destination device 14 or the corresponding functions. In these embodiments, the source device 12 or the corresponding functions and the destination device 14 or the corresponding functions may provide the same hardware and / or software or be implemented by separate hardware and / or software or any combination thereof.

[0073] It is obvious to those skilled in the art based on the description that Figure 1A The presence and (precise) functional division of different units or functions within the source device 12 and / or destination device 14 shown may vary depending on the actual device and application.

[0074] The encoder 20 (eg, video encoder 20) or the decoder 30 (eg, video decoder 30) or both the encoder 20 and the decoder 30 may be configured to: Figure 1B The processing circuit shown in the figure is implemented. The processing circuit includes one or more microprocessors, one or more digital signal processors (DSP), one or more application-specific integrated circuits (ASIC), one or more field-programmable gate arrays (FPGA), one or more discrete logic, one or more hardware, one or more video decoding dedicated processors or any combination thereof. The encoder 20 can be implemented by the processing circuit 46 to include reference Figure 2 The various modules described in the encoder 20 of FIG. 1 and / or any other encoder system or subsystem described herein. The decoder 30 may be implemented by the processing circuit 46 to include reference Figure 3 The various modules described in the decoder 30 in the embodiment and / or any other decoder system or subsystem described herein. The processing circuit can be used to perform the various operations discussed below. Figure 5 As shown, if the above-mentioned technology is partially implemented in software, a device can store the instructions of the software in a suitable non-transitory computer-readable storage medium, and can execute these instructions in hardware through one or more processors to perform the technology in this application. The video encoder 20 or the video decoder 30 can be integrated into a single device as part of a combined encoder / decoder (codec), for example, Figure 1B shown.

[0075] Source device 12 and destination device 14 may include any of a variety of devices, including any type of handheld or fixed device, such as a notebook or laptop computer, a mobile phone, a smart phone, a tablet or a tablet computer, a camera, a desktop computer, a set-top box, a television, a display device, a digital media player, a video game console, a video streaming device (such as a content service server or a content distribution server), a broadcast receiver device, a broadcast transmitter device, etc., and may not use or use any type of operating system. In some cases, source device 12 and destination device 14 can be used for wireless communication. Therefore, source device 12 and destination device 14 can be wireless communication devices.

[0076] In some cases, Figure 1A The video decoding system 10 shown is only one example, and the techniques in the present application can be applied to video decoding settings (e.g., video encoding or video decoding) that do not necessarily include any data communication between the encoding device and the decoding device. In other examples, data is retrieved from a local memory, streamed over a network, and so on. The video encoding device can encode the data and store the data in a memory, and / or the video decoding device can retrieve the data from the memory and decode the data. In some examples, the encoding and decoding are performed by devices that do not communicate with each other but only encode the data to the memory and / or retrieve the data from the memory and decode the data.

[0077] For ease of description, this document (for example) refers to the reference software of High-Efficiency Video Coding (HEVC) developed by the Joint Collaboration Team on Video Coding (JCT-VC) of the ITU-T Video Coding Experts Group (VCEG) and the ISO / IEC Motion Picture Experts Group (MPEG) or the next generation video coding standard, namely Versatile Video Coding (VVC), to describe the embodiments of the present application. Those skilled in the art understand that the embodiments of the present application are not limited to HEVC or VVC.

[0078] Encoders and encoding methods

[0079] Figure 2 FIG. 2 is a schematic block diagram of an exemplary video encoder 20 for implementing the techniques in the present application. Figure 2 In the example of , the video encoder 20 includes an input terminal 201 (or an input interface 201), a residual calculation unit 204, a transform processing unit 206, a quantization unit 208, an inverse quantization unit 210, an inverse transform processing unit 212, a reconstruction unit 214, a loop filter unit 220, a decoded picture buffer (DPB) 230, a mode selection unit 260, an entropy coding unit 270, and an output terminal 272 (or an output interface 272). The mode selection unit 260 may include an inter-frame prediction unit 244, an intra-frame prediction unit 254, and a segmentation unit 262. The inter-frame prediction unit 244 may include a motion estimation unit and a motion compensation unit (not shown). Figure 2 The illustrated video encoder 20 may also be referred to as a hybrid video encoder or a hybrid video codec-based video encoder.

[0080] The residual calculation unit 204, the transform processing unit 206, the quantization unit 208 and the mode selection unit 260 may constitute a forward signal path of the encoder 20, and the inverse quantization unit 210, the inverse transform processing unit 212, the reconstruction unit 214, the buffer 216, the loop filter 220, the decoded picture buffer (DPB) 230, the inter-frame prediction unit 244 and the intra-frame prediction unit 254 may constitute a backward signal path of the video encoder 20, wherein the backward signal path of the video encoder 20 corresponds to the decoder (see Figure 3The inverse quantization unit 210, the inverse transform processing unit 212, the reconstruction unit 214, the loop filter 220, the decoded picture buffer (DPB) 230, the inter-frame prediction unit 244 and the intra-frame prediction unit 254 also constitute the “built-in decoder” of the video encoder 20.

[0081] Images and image segmentation (images and blocks)

[0082] The encoder 20 may be configured to receive an image 17 (or image data 17) via an input terminal 201 or the like. The image 17 may be an image in a sequence of images constituting a video or a video sequence. The received image or image data may also be a pre-processed image 19 (or pre-processed image data 19). For simplicity, the following description uses image 17. Image 17 may also be referred to as a current image or an image to be decoded (particularly in video decoding in order to distinguish the current image from other images (e.g., previously encoded and / or decoded images) in the same video sequence (i.e., a video sequence that also includes the current image)).

[0083] A (digital) image is or can be considered as a two-dimensional array or matrix consisting of samples with intensity values. The samples in the array can also be called pixels (pixel / pel) (short for picture elements). The number of samples in the array or image in the horizontal and vertical directions (or axes) defines the size and / or resolution of the image. In order to represent color, three color components are usually used, that is, the image can be represented as or can include three sample arrays. In the RGB format or color space, an image includes corresponding red, green and blue sample arrays. However, in video decoding, each pixel is usually represented in a brightness and chrominance format or color space, such as YCbCr, including a brightness component represented by Y (sometimes also represented by L) and two chrominance components represented by Cb and Cr. The brightness (luminance, abbreviated as luma) component Y represents the brightness or grayscale intensity (for example, the two are the same in grayscale images), while the two chrominance (chrominance, abbreviated as chroma) components Cb and Cr represent the chrominance or color information components. Thus, an image in YCbCr format includes a luma sample array consisting of luma sample values ​​(Y) and two chroma sample arrays consisting of chroma values ​​(Cb and Cr). An image in RGB format can be converted or transformed into YCbCr format and vice versa. This process is also called color conversion or conversion. If the image is black and white, the image may include only a luma sample array. Accordingly, for example, the image may be a luma sample array in black and white format or a luma sample array and two corresponding chroma sample arrays in 4:2:0, 4:2:2 and 4:4:4 color formats.

[0084] An embodiment of the video encoder 20 may include an image segmentation unit ( Figure 2 ), for partitioning the image 17 into a plurality of (usually non-overlapping) image blocks 203. These blocks may also be referred to as root blocks, macroblocks (in H.264 / AVC), or coding tree blocks (CTB) or coding tree units (CTU) (in H.265 / HEVC and VVC). The image partitioning unit may be used to use the same block size for all images in a video sequence and a corresponding grid of defined block sizes, or to vary the block size between images or subsets or groups of images, and to partition each image into a plurality of corresponding blocks.

[0085] In other embodiments, the video encoder may be configured to directly receive the block 203 in the image 17, for example, one, several or all blocks constituting the image 17. The image block 203 may also be referred to as a current image block or an image block to be decoded.

[0086] Similar to the image 17, the image block 203 is also or can be regarded as a two-dimensional array or matrix composed of samples with intensity values ​​(sample values), but the size of the image block 203 is smaller than that of the image 17. In other words, according to the color format applied, the block 203 may include (for example) one sample array (such as a brightness array in the case of the black and white image 17 or a brightness array or a chrominance array in the case of a color image) or three sample arrays (such as one brightness array and two chrominance arrays in the case of the color image 17) or any other number and / or type of arrays. The number of samples of the block 203 in the horizontal direction and the vertical direction (or axis) defines the size of the block 203. Accordingly, a block can be an M×N (M columns×N rows) sample array, or an M×N transform coefficient array, and so on.

[0087] Figure 2 The illustrated embodiment of the video encoder 20 may be used to encode the image 17 block by block, for example, encoding and prediction are performed in blocks 203 .

[0088] Figure 2 The illustrated embodiment of the video encoder 20 may also be used to partition and / or encode a picture by slices (also referred to as video slices). A picture may be partitioned into or encoded by one or more (usually non-overlapping) slices, each of which may include one or more blocks (e.g., CTUs).

[0089] Figure 2The illustrated embodiment of the video encoder 20 may also be used to segment and / or encode an image by tile groups (also referred to as video tile groups) and / or tiles (also referred to as video tiles). An image may be segmented into or encoded by one or more (usually non-overlapping) tile groups; each tile group may include one or more blocks (e.g., CTUs) or one or more tiles, etc.; each tile may be rectangular, etc., and may include one or more complete or partial blocks (e.g., CTUs), etc.

[0090] Residual calculation

[0091] The residual calculation unit 204 can be used to calculate the residual block 205 (also referred to as residual 205) based on the image block 203 and the prediction block 265 (a more detailed description of the prediction block 265 is provided later) in the following manner to obtain the residual block 205 in the sample domain: for example, subtracting the sample value of the prediction block 265 from the sample value of the image block 203 sample by sample (pixel by pixel).

[0092] Transform

[0093] The transform processing unit 206 may be used to apply a transform such as discrete cosine transform (DCT) or discrete sine transform (DST) on the sample values ​​of the residual block 205 to obtain a transform coefficient 207 in the transform domain. The transform coefficient 207 may also be referred to as a transform residual coefficient and represents the residual block 205 in the transform domain.

[0094] The transform processing unit 206 can be used to apply an integer approximation of DCT / DST (e.g., a transform specified for H.265 / HEVC). Compared to an orthogonal DCT transform, this integer approximation is typically scaled by a certain factor. In order to maintain the norm of the residual block processed by the forward transform and the inverse transform, other scaling factors are applied as part of the transform process. The scaling factor is typically selected based on certain constraints, such as the scaling factor being a power of 2 for the shift operation, the bit depth of the transform coefficients, a trade-off between precision and implementation cost, etc. For example, a specific scaling factor is specified for the inverse transform through the inverse transform processing unit 212, etc. (and the video decoder 30 for the corresponding inverse transform through the inverse transform processing unit 312, etc.); accordingly, the encoder 20 can specify a corresponding scaling factor for the forward transform through the transform processing unit 206, etc.

[0095] Embodiments of the video encoder 20 (and accordingly, the transform processing unit 206) may be configured to output transform parameters (e.g., one or more transform types) directly or after encoding or compression through the entropy coding unit 270, such that the video decoder 30 may receive and use the transform parameters for decoding, and so on.

[0096] Quantification

[0097] The quantization unit 208 may be used to quantize the transform coefficients 207 by applying scalar quantization or vector quantization, etc., to obtain quantized coefficients 209 . The quantized coefficients 209 may also be referred to as quantized transform coefficients 209 or quantized residual coefficients 209 .

[0098] The quantization process may reduce the bit depth associated with some or all of the transform coefficients 207. For example, an n-bit transform coefficient may be rounded down to an m-bit transform coefficient during quantization, where n is greater than m. The degree of quantization may be modified by adjusting a quantization parameter (QP). For example, for scalar quantization, different degrees of scaling may be performed to achieve finer or coarser quantization. A smaller quantization step size corresponds to a finer quantization, while a larger quantization step size corresponds to a coarser quantization. A suitable quantization step size may be represented by a quantization parameter (QP). For example, a quantization parameter may be an index of a set of predefined suitable quantization step sizes. For example, a smaller quantization parameter may correspond to fine quantization (a smaller quantization step size), a larger quantization parameter may correspond to coarse quantization (a larger quantization step size), and vice versa. Quantization may include dividing by a quantization step size, and corresponding inverse quantization and / or dequantization performed by an inverse quantization unit 210 or the like may include multiplying by a quantization step size. Embodiments according to some standards such as HEVC may be used to determine a quantization step size using a quantization parameter. In general, a quantization step size may be calculated according to a quantization parameter by a fixed-point approximation of an equation including division. Additional scaling factors may be introduced for quantization and dequantization to recover the norm of the residual block that may be modified due to the scaling used in the fixed-point approximation of the equations for the quantization step size and the quantization parameter. In an exemplary implementation, the scaling of the inverse transform and dequantization may be combined. Optionally, a custom quantization table may be used and signaled by the encoder to the decoder in a bitstream or the like. Quantization is a lossy operation, where the larger the quantization step size, the greater the loss.

[0099] Embodiments of the video encoder 20 (correspondingly, the quantization unit 208 ) may be configured to directly output a quantization parameter (QP) or output the quantization parameter after encoding through the entropy coding unit 270 , so that the video decoder 30 may receive and use the quantization parameter for decoding, and so on.

[0100] Dequantization

[0101] The inverse quantization unit 210 is configured to apply the inverse quantization of the quantization unit 208 to the quantized coefficients to obtain dequantized coefficients 211 by, for example, applying an inverse quantization scheme opposite to the quantization scheme applied by the quantization unit 208 according to or using the same quantization step size as the quantization unit 208. The dequantized coefficients 211 may also be referred to as dequantized residual coefficients 211, which correspond to the transform coefficients 207, but are generally different from the transform coefficients due to losses caused by quantization.

[0102] Inverse Transform

[0103] The inverse transform processing unit 212 is used to apply an inverse transform opposite to the transform applied by the transform processing unit 206, such as an inverse discrete cosine transform (DCT) or an inverse discrete sine transform (DST) or other inverse transforms to obtain a reconstructed residual block 213 (or a corresponding dequantized coefficient 213) in the sample domain. The reconstructed residual block 213 may also be referred to as a transform block 213.

[0104] reconstruction

[0105] The reconstruction unit 214 (e.g., an adder or summer 214) is used to add the transform block 213 (i.e., the reconstructed residual block 213) to the prediction block 265 to obtain the reconstructed block 215 in the sample domain by, for example, adding the sample values ​​of the reconstructed residual block 213 and the sample values ​​of the prediction block 265 sample by sample.

[0106] Filtering

[0107] The loop filter unit 220 (or simply "loop filter" 220) is used to filter the reconstructed block 215 to obtain a filtered block 221, or generally to filter the reconstructed samples to obtain filtered samples. For example, the loop filter unit is used to smoothly perform pixel transitions or otherwise improve video quality. The loop filter unit 220 may include one or more loop filters, such as a deblocking filter, a sample-adaptive offset (SAO) filter, or one or more other filters, such as a bilateral filter, an adaptive loop filter (ALF), a sharpening or smoothing filter, a collaborative filter, or any combination thereof. Although the loop filter unit 220 is Figure 2 2 is shown as an in-loop filter, but in other configurations, the loop filter unit 220 may be implemented as a post-loop filter. The filtered block 221 may also be referred to as a filtered reconstructed block 221.

[0108] An embodiment of the video encoder 20 (correspondingly, the loop filter unit 220) can be used to directly output or output loop filter parameters (such as sample adaptive offset information) after encoding through the entropy coding unit 270, so that the decoder 30 can receive and use the same loop filter parameters or the corresponding loop filter for decoding, and so on.

[0109] Decode image buffer

[0110] The decoded picture buffer (DPB) 230 may be a memory for storing reference images or generally storing reference picture data, which are used by the video encoder 20 to encode video data. The DPB 230 may be formed by any of a variety of storage devices, such as a dynamic random access memory (DRAM), including synchronous DRAM (SDRAM), magnetoresistive RAM (MRAM), resistive RAM (RRAM) or other types of storage devices. The decoded picture buffer (DPB) 230 may be used to store one or more filtered blocks 221. The decoded picture buffer 230 may also be used to store other previously filtered blocks (e.g., previously filtered reconstructed blocks 221) in the same current image or a different image (e.g., a previously reconstructed image), and may provide a previously completely reconstructed (i.e., decoded) image (and corresponding reference blocks and samples) and / or a partially reconstructed current image (and corresponding reference blocks and samples) for inter-frame prediction, etc. The decoded picture buffer (DPB) 230 may also be used to store one or more unfiltered reconstructed blocks 215 or generally unfiltered reconstructed samples if the reconstructed blocks 215 are not filtered by the loop filter unit 220, etc., or to store any other blocks or samples obtained after further processing of the reconstructed blocks or samples.

[0111] Mode selection (segmentation and prediction)

[0112] The mode selection unit 260 includes a segmentation unit 262, an inter-frame prediction unit 244, and an intra-frame prediction unit 254, and is used to receive or obtain original image data such as the original block 203 (the current block 203 in the current image 17) and reconstructed image data (such as filtered and / or unfiltered reconstructed samples or blocks in the same (current) image and / or one or more previously decoded images) from the decoded image buffer 230 or other buffers (such as line buffers, not shown in the figure). The reconstructed image data is used as reference image data for prediction such as inter-frame prediction or intra-frame prediction to obtain a prediction block 265 or a prediction value 265.

[0113] The mode selection unit 260 can be used to determine or select a segmentation method for the current block prediction mode (including non-segmentation) and determine or select a prediction mode (such as intra-frame or inter-frame prediction mode), and generate a corresponding prediction block 265, which is used to calculate the residual block 205 and reconstruct the reconstructed block 215.

[0114] Embodiments of the mode selection unit 260 may be used to select a partitioning scheme and a prediction mode (e.g., selected from those modes supported or available by the mode selection unit 260). The partitioning scheme and the prediction mode provide the best match or minimum residual (minimum residual means better compression in transmission or storage), or provide minimum signaling overhead (minimum signaling overhead means better compression in transmission or storage), or consider or balance both of the above. The mode selection unit 260 may be used to determine the partitioning scheme and the prediction mode according to rate distortion optimization (RDO), that is, to select the prediction mode that provides the minimum rate distortion. The terms "best", "minimum", "optimal", etc. in this document do not necessarily mean "best", "minimum", "optimal", etc. in general, but may also refer to situations where termination or selection criteria are met, for example, values ​​exceeding or below a threshold or other constraints may result in a "suboptimal selection", but will reduce complexity and processing time.

[0115] In other words, the segmentation unit 262 can be used to segment the block 203 into smaller block partitions or sub-blocks (forming blocks again) in the following manner: for example, iteratively using quad-tree (quad-tree, QT) segmentation, binary-tree (binary-tree, BT) segmentation or triple-tree (triple-tree, TT) segmentation or any combination thereof; and for performing prediction on each block partition or sub-block, etc., wherein the mode selection includes selecting a tree structure of the partitioned block 203, and the prediction mode is applied to each block partition or sub-block.

[0116] The segmentation (eg, performed by segmentation unit 260) and prediction processes (performed by inter-prediction unit 244 and intra-prediction unit 254) performed by exemplary video encoder 20 are described in detail below.

[0117] segmentation

[0118] The segmentation unit 262 can segment (or divide) the current block 203 into smaller partitions, such as square or rectangular blocks. These blocks (also referred to as sub-blocks) can be further segmented into even smaller partitions. This is also called tree segmentation or hierarchical tree segmentation. The root block at root tree level 0 (hierarchical level 0, depth 0) etc. can be recursively segmented into two or more blocks of the next lower tree level, such as nodes of tree level 1 (hierarchical level 1, depth 1). These blocks can be segmented again into two or more blocks of the next lower level, such as tree level 2 (hierarchical level 2, depth 2), etc., until the segmentation ends (because the end criteria are met, such as reaching the maximum tree depth or the minimum block size). Blocks that are not further segmented are also referred to as leaf blocks or leaf nodes of the tree. A tree segmented into two partitions is called a binary tree (binary-tree, BT), a tree segmented into three partitions is called a ternary tree (ternary-tree, TT), and a tree segmented into four partitions is called a quadtree (quad-tree, QT).

[0119] As described above, the term "block" used in this document may be a portion of an image, in particular a square or rectangular portion. With reference to HEVC and VVC, etc., a block may be or may correspond to a coding tree unit (CTU), a coding unit (CU), a prediction unit (PU), and a transform unit (TU), and / or to a plurality of corresponding blocks, for example, a coding tree block (CTB), a coding block (CB), a transform block (TB), or a prediction block (PB).

[0120] For example, a coding tree unit (CTU) may be or may include 1 CTB consisting of luminance samples in an image with 3 sample arrays and 2 corresponding CTBs consisting of chrominance samples in the image, or may be or may include 1 CTB consisting of samples in a black and white image or an image decoded using 3 separate color planes and syntax structures. These syntax structures are used to decode the above samples. Correspondingly, a coding tree block (CTB) may be an N×N sample block, where N may be set to a certain value so that a component is divided into multiple CTBs, which is a partitioning method. A coding unit (CU) may be or may include 1 coding block consisting of luminance samples in an image with 3 sample arrays and 2 corresponding coding blocks consisting of chrominance samples in the image, or may be or may include 1 coding block consisting of samples in a black and white image or an image decoded using 3 separate color planes and syntax structures. These syntax structures are used to decode the above samples. Correspondingly, a coding block (CB) may be an M×N sample block, where M and N may be set to a certain value so that one CTB is divided into multiple coding blocks. This is a segmentation method.

[0121] In an embodiment, for example according to HEVC, a coding tree unit (CTU) can be divided into multiple CUs by a quadtree structure represented as a coding tree. Whether to use inter-frame (temporal) prediction or intra-frame (spatial) prediction to decode the image area is determined at the CU level. Each CU can be further divided into 1, 2 or 4 PUs according to the PU partition type. The same prediction process is performed within a PU, and relevant information is sent to the decoder in units of PUs. After the residual block is obtained by the prediction process according to the PU partition type, the CU can be divided into transform units (TUs) according to other quadtree structures similar to the coding tree of the CU.

[0122] In an embodiment, for example, according to the latest video coding standard currently under development called Versatile Video Coding (VVC), a combined quad-tree and binary tree (QTBT) segmentation is used to segment coding blocks, etc. In the QTBT block structure, a CU can be a square or a rectangle. For example, a coding tree unit (CTU) is first segmented by a quadtree structure. The quad tree leaf nodes are further segmented by a binary tree or a ternary / triple tree structure. The segmented leaf nodes are called coding units (CUs), and this segmentation is used for prediction and transform processing without any further segmentation. This means that CU, PU, ​​and TU have the same block size in the QTBT coding block structure. At the same time, multiple segmentations such as ternary tree segmentation can be used with the QTBT block structure.

[0123] In one example, mode select unit 260 in video encoder 20 may be used to perform any combination of the segmentation techniques described herein.

[0124] As described above, the video encoder 20 is used to determine or select the best or optimal prediction mode from a (eg, predetermined) prediction mode set. The prediction mode set may include intra-frame prediction mode and / or inter-frame prediction mode, etc.

[0125] Intra-frame prediction

[0126] The intra-frame prediction mode set may include 35 different intra-frame prediction modes, for example, non-directional modes or directional modes such as the DC (or mean) mode and the planar mode defined in HEVC, etc., or may include 67 different intra-frame prediction modes, for example, non-directional modes or directional modes such as the DC (or mean) mode and the planar mode defined in VVC, etc.

[0127] The intra prediction unit 254 is configured to generate an intra prediction block 265 using reconstructed samples of neighboring blocks in the same current image according to an intra prediction mode in the intra prediction mode set.

[0128] The intra-frame prediction unit 254 (or generally referred to as the mode selection unit 260) is also used to output the intra-frame prediction parameters (or generally referred to as information representing the selected intra-frame prediction mode of the block) to the entropy coding unit 270 in the form of syntax elements 266 to include the intra-frame prediction parameters in the encoded image data 21, so that the video decoder 30 can receive and use the prediction parameters for decoding, etc.

[0129] Inter prediction

[0130] The set of (possible) inter-frame prediction modes depends on the available reference image (i.e. at least part of the decoded image stored in DPB230, etc. as mentioned above) and other inter-frame prediction parameters, for example, whether the entire reference image or only a part of the reference image (e.g. a search window area around the area of ​​the current block) is used to search for the best matching reference block, and / or for example, whether pixel interpolation is performed, such as half / half-pixel interpolation and / or quarter-pixel interpolation.

[0131] In addition to the above-mentioned prediction modes, skip mode and / or direct mode may also be used.

[0132] The inter-frame prediction unit 244 may include a motion estimation (ME) unit and a motion compensation (MC) unit (both in Figure 2 ). The motion estimation unit may be configured to receive or acquire an image block 203 (a current image block 203 in a current image 17) and a decoded image 231, or at least one or more previously reconstructed blocks (e.g., reconstructed blocks in one or more other / different previously decoded images 231) for motion estimation. For example, a video sequence may include a current image and a previously decoded image 231, or in other words, the current image and the previously decoded image 231 may be part of or constitute an image sequence, which image sequence constitutes a video sequence.

[0133] For example, the encoder 20 may be configured to select a reference block from a plurality of reference blocks of the same or different images in a plurality of other images, and provide the reference image (or reference image index) and / or the offset (spatial offset) between the position (x coordinate, y coordinate) of the reference block and the position of the current block as an inter-frame prediction parameter to the motion estimation unit. This offset is also referred to as a motion vector (MV).

[0134] The motion compensation unit is used to obtain (e.g., receive) inter-frame prediction parameters and perform inter-frame prediction based on or using the inter-frame prediction parameters to obtain an inter-frame prediction block 265. The motion compensation performed by the motion compensation unit may include extracting or generating a prediction block based on a motion / block vector determined by motion estimation, and may also include performing interpolation to achieve sub-pixel accuracy. Interpolation filtering can generate other pixel samples based on known pixel samples, thereby potentially increasing the number of candidate prediction blocks that can be used to decode the image block. When receiving a motion vector corresponding to a PU of a current image block, the motion compensation unit may locate the prediction block pointed to by the motion vector in one of the reference image lists.

[0135] The motion compensation unit may also generate syntax elements associated with blocks and video slices for use by the video decoder 30 when decoding image blocks in the video slices. In addition to or as an alternative to slices and corresponding syntax elements, partition groups and / or partitions and corresponding syntax elements may be generated or used.

[0136] Entropy Coding

[0137] The entropy coding unit 270 is used to apply or not apply an entropy coding algorithm or scheme (e.g., a variable length coding (VLC) scheme, a context adaptive VLC (CAVLC) scheme, an arithmetic coding scheme, binarization, context adaptive binary arithmetic coding (CABAC), syntax-based context-adaptive binary arithmetic coding (SBAC), probability interval partitioning entropy (PIPE) coding or other entropy coding methods or techniques) to (uncompressed) quantized coefficients 209, inter-frame prediction parameters, intra-frame prediction parameters, loop filter parameters and / or other syntax elements to obtain encoded image data 21 that can be output through an output terminal 272 in the form of an encoded bitstream 21, etc., so that the video decoder 30 can receive and use these parameters for decoding, etc. The encoded bitstream 21 can be sent to the video decoder 30, or stored in a memory for later transmission or retrieval by the video decoder 30.

[0138] Other structural variations of the video encoder 20 may be used to encode the video stream. For example, a non-transform based encoder 20 may directly quantize the residual signal for certain blocks or frames without the transform processing unit 206. In another implementation, the encoder 20 may include a quantization unit 208 and an inverse quantization unit 210 combined into a single unit.

[0139] Decoder and decoding method

[0140] Figure 33 is an example of a video decoder 30 for implementing the technology in the present application. The video decoder 30 is used to receive the encoded image data 21 (e.g., the encoded code stream 21) encoded by the encoder 20 (e.g., to obtain a decoded image 331. The encoded image data or code stream includes information for decoding the encoded image data, such as data representing image blocks of encoded video slices (and / or partition groups or partitions) and related syntax elements.

[0141] exist Figure 3 In the example of , decoder 30 includes entropy decoding unit 304, inverse quantization unit 310, inverse transform processing unit 312, reconstruction unit 314 (e.g., summer 314), loop filter 320, decoded picture buffer (DPB) 330, mode application unit 360, inter prediction unit 344 and intra prediction unit 354. Inter prediction unit 344 may be or may include a motion compensation unit. In some examples, video decoder 30 may perform substantially the same as reference Figure 2 The encoding process described in the video encoder 100 is the inverse of the decoding process.

[0142] As described with reference to the encoder 20, the inverse quantization unit 210, the inverse transform processing unit 212, the reconstruction unit 214, the loop filter 220, the decoded picture buffer (DPB) 230, the inter prediction unit 344, and the intra prediction unit 354 also constitute the “built-in decoder” of the video encoder 20. Accordingly, the inverse quantization unit 310 may be functionally identical to the inverse quantization unit 110, the inverse transform processing unit 312 may be functionally identical to the inverse transform processing unit 212, the reconstruction unit 314 may be functionally identical to the reconstruction unit 214, the loop filter 320 may be functionally identical to the loop filter 220, and the decoded picture buffer 330 may be functionally identical to the decoded picture buffer 230. Therefore, the explanations made with respect to the corresponding units and functions of the video encoder 20 apply correspondingly to the corresponding units and functions of the video decoder 30.

[0143] Entropy decoding

[0144] The entropy decoding unit 304 is used to parse the code stream 21 (or generally referred to as the encoded image data 21) and perform entropy decoding on the encoded image data 21 to obtain the quantized coefficients 309 and / or the decoded encoding parameters ( Figure 3The entropy decoding unit 304 may be used to apply a decoding algorithm or scheme corresponding to the coding scheme described with reference to the entropy coding unit 270 in the encoder 20. The entropy decoding unit 304 may also be used to provide the inter-frame prediction parameters, intra-frame prediction parameters and / or other syntax elements to the mode application unit 360, and to provide other parameters to other units in the decoder 30. The video decoder 30 may receive syntax elements at the video slice level and / or the video block level. In addition to or as an alternative to the slices and the corresponding syntax elements, the block groups and / or blocks and the corresponding syntax elements may be received and / or used.

[0145] Dequantization

[0146] The inverse quantization unit 310 may be configured to receive a quantization parameter (QP) (or generally referred to as information related to inverse quantization) and quantized coefficients from the encoded image data 21 (e.g., parsed and / or decoded by the entropy decoding unit 304, etc.), and inverse quantize the decoded quantized coefficients 309 according to the quantization parameters to obtain dequantized coefficients 311. The dequantized coefficients 311 may also be referred to as transform coefficients 311. The inverse quantization process may include determining a degree of quantization using a quantization parameter determined by the video encoder 20 for each video block in a video slice (or partition or group of partitions), and also determining a degree of inverse quantization that needs to be applied.

[0147] Inverse Transform

[0148] The inverse transform processing unit 312 may be configured to receive the dequantized coefficients 311 (also referred to as transform coefficients 311) and transform the dequantized coefficients 311 to obtain a reconstructed residual block 213 in the sample domain. The reconstructed residual block 213 may also be referred to as a transform block 313. The transform may be an inverse transform, such as an inverse DCT, an inverse DST, an inverse integer transform, or a conceptually similar inverse transform process. The inverse transform processing unit 312 may also be configured to receive transform parameters or corresponding information from the encoded image data 21 (e.g., parsed and / or decoded by the entropy decoding unit 304, etc.) to determine the transform to be applied to the dequantized coefficients 311.

[0149] reconstruction

[0150] The reconstruction unit 314 (eg, adder or summer 314 ) may be configured to add the reconstructed residual block 313 to the prediction block 365 to obtain the reconstructed block 315 in the sample domain by, for example, adding sample values ​​of the reconstructed residual block 313 to sample values ​​of the prediction block 365 .

[0151] Filtering

[0152] The loop filter unit 320 (in or after the decoding loop) is used to filter the reconstructed block 315 to obtain a filtered block 321, so as to smoothly perform pixel conversion or otherwise improve video quality, etc. The loop filter unit 320 may include one or more loop filters, such as a deblocking filter, a sample-adaptive offset (SAO) filter, or one or more other filters, such as a bilateral filter, an adaptive loop filter (ALF), a sharpening or smoothing filter, a collaborative filter, or any combination thereof. Although the loop filter unit 320 is in Figure 3 3. Although shown as an in-loop filter in FIG. 3, in other configurations, the loop filter unit 320 may be implemented as a post-loop filter.

[0153] Decode image buffer

[0154] The decoded video block 321 in one picture is then stored in a decoded picture buffer 330, which stores the decoded picture 331 as a reference picture for subsequent motion compensation and / or output or display of other pictures.

[0155] The decoder 30 is used to output the decoded image 331 through an output terminal 332 or the like, so as to be presented to a user or for the user to view.

[0156] predict

[0157] The inter-frame prediction unit 344 may be functionally identical to the inter-frame prediction unit 244 (particularly the motion compensation unit), and the intra-frame prediction unit 354 may be functionally identical to the intra-frame prediction unit 254, and performs partitioning or segmentation decisions and performs predictions according to the segmentation mode and / or prediction parameters or corresponding information received from the coded image data 21 (e.g., parsed and / or decoded by the entropy decoding unit 304, etc.). The mode application unit 360 may be configured to perform prediction (intra-frame or inter-frame prediction) by block according to the reconstructed image, block or corresponding sample (filtered or unfiltered) to obtain a prediction block 365.

[0158] When the video slice is decoded as an intra-coded (I) slice, the intra-prediction unit 354 in the mode application unit 360 is used to generate a prediction block 365 for the image block in the current video slice based on the indicated intra-prediction mode and data from a previously decoded block in the current image. When the video image is decoded as an inter-coded (i.e., B or P) slice, the inter-prediction unit 344 (e.g., a motion compensation unit) in the mode application unit 360 is used to generate a prediction block 365 for the video block in the current video slice based on the motion vector and other syntax elements received from the entropy decoding unit 304. For inter-prediction, these prediction blocks can be generated from one of the reference pictures in one of the reference picture lists. The video decoder 30 can construct reference frame list 0 and list 1 using a default construction technique based on the reference pictures stored in the DPB 330. The same or similar processes may be applied to or by embodiments using partition groups (e.g., video partition groups) and / or partitions (e.g., video partitions) in addition to or as an alternative to slices (e.g., video slices), e.g., video may be decoded using I, P, or B partition groups and / or partitions.

[0159] The mode application unit 360 is used to determine prediction information for a video block in a current video slice by parsing motion vectors or related information and other syntax elements, and use the prediction information to generate a prediction block for the current video block being decoded. For example, the mode application unit 360 uses some of the received syntax elements to determine a prediction mode (e.g., intra-frame or inter-frame prediction) for decoding a video block in a video slice, an inter-frame prediction slice type (e.g., B slice, P slice, or GPB slice), construction information of one or more reference picture lists for the slice, motion vectors for each inter-frame encoded video block of the slice, inter-frame prediction status for each inter-frame decoded video block of the slice, and other information to decode the video block in the current video slice. In addition to slices (e.g., video slices) or as an alternative to slices, the same or similar process can be applied to or by embodiments using block groups (e.g., video block groups) and / or blocks (e.g., video blocks), for example, video can be decoded using I, P, or B block groups and / or blocks.

[0160] Figure 3 The illustrated embodiment of the video decoder 30 may be used to partition and / or decode a picture by slices (also referred to as video slices). A picture may be partitioned into or decoded by one or more (usually non-overlapping) slices, each of which may include one or more blocks (e.g., CTUs).

[0161] Figure 3The illustrated embodiment of the video decoder 30 may be used to segment and / or decode an image by partition groups (also referred to as video partition groups) and / or by blocks (also referred to as video blocks). An image may be segmented into or decoded by one or more (usually non-overlapping) partition groups; each partition group may include one or more blocks (e.g., CTUs) or one or more partitions, etc.; each partition may be rectangular, etc., and may include one or more complete or partial blocks (e.g., CTUs), etc.

[0162] Other variations of the video decoder 30 may be used to decode the encoded image data 21. For example, the decoder 30 may generate an output video stream without the loop filter unit 320. For example, a non-transform based decoder 30 may directly dequantize the residual signal for certain blocks or frames without the inverse transform processing unit 312. In another implementation, the video decoder 30 may include the dequantization unit 310 and the inverse transform processing unit 312 combined into a single unit.

[0163] It should be understood that the processing result of the current step can be further processed and then output to the next step in the encoder 20 and the decoder 30. For example, after interpolation filtering, motion vector derivation or loop filtering, more operations such as clipping or shifting can be performed on the processing results of interpolation filtering, motion vector derivation or loop filtering.

[0164] It should be noted that more operations can be applied to the derived motion vector of the current block (including but not limited to the control point motion vector of the affine mode, the sub-block motion vector of the affine mode, the planar mode, the ATMVP mode, the temporal motion vector, etc.). For example, the value of the motion vector is constrained within a predefined range according to the representation bit of the motion vector. If the representation bit of the motion vector is bitDepth, the range is –2^(bitDepth–1) to 2^(bitDepth–1)–1, where “^” represents a power. For example, if bitDepth is set to 16, the range is –32768 to 32767; if bitDepth is set to 18, the range is –131072 to 131071. For example, the value of the derived motion vector (e.g., the MV of 4 4×4 sub-blocks in an 8×8 block) is constrained so that the maximum difference between the integer parts of the 4 4×4 sub-block MVs does not exceed N pixels, for example, not more than 1 pixel. Two methods for constraining motion vectors according to bitDepth are provided here.

[0165] Method 1: Remove the most significant bit (MSB) of the overflow by smoothing

[0166] ux = (mvx + 2 bitDepth ) % 2 bitDepth (1)

[0167] mvx = (ux >= 2 bitDepth–1 ) ? (ux – 2 bitDepth ) : ux (2)

[0168] uy = (mvy + 2 bitDepth ) % 2 bitDepth (3)

[0169] mvy = (uy >= 2 bitDepth–1 ) ? (uy – 2 bitDepth ) : uy (4)

[0170] Among them, mvx is the horizontal component of the motion vector of an image block or sub-block, mvy is the vertical component of the motion vector of an image block or sub-block, and ux and uy represent intermediate values.

[0171] For example, if the value of mvx is –32769, the value obtained by using formulas (1) and (2) is 32767. In computer systems, decimal numbers are stored in two's complement form. The two's complement of –32769 is 1,0111,1111,1111,1111 (17 bits), and then the MSB is discarded, so the two's complement obtained is 0111,1111,1111,1111 (32767 in decimal), which is the same as the output result obtained by using formulas (1) and (2).

[0172] ux = (mvpx + mvdx + 2 bitDepth ) % 2 bitDepth (5)

[0173] mvx = (ux >= 2 bitDepth–1 ) ? (ux – 2 bitDepth ) : ux (6)

[0174] uy = (mvpy + mvdy + 2 bitDepth ) % 2 bitDepth (7)

[0175] mvy = (uy >= 2 bitDepth–1 ) ? (uy – 2 bitDepth ) : uy (8)

[0176] These operations can be performed in the process of summing mvp and mvd, as shown in equations (5) to (8).

[0177] Method 2: Remove the overflowed MSB by clipping the value

[0178] vx=Clip3(–2 bitDepth–1 ,2 bitDepth–1 –1,vx)

[0179] vy=Clip3(–2 bitDepth–1 ,2 bitDepth–1 –1,vy)

[0180] Where vx is the horizontal component of the motion vector of an image block or sub-block, vy is the vertical component of the motion vector of an image block or sub-block, x, y and z correspond to the three input values ​​of the MV clipping process, and the function Clip3 is defined as follows:

[0181]

[0182] Figure 4 A schematic diagram of a video decoding device 400 provided in accordance with an embodiment of the present application. The video decoding device 400 is suitable for implementing the disclosed embodiments described herein. In one embodiment, the video decoding device 400 may be a decoder (e.g. Figure 1A 30) or an encoder (e.g. Figure 1A 20 in the video encoder).

[0183] The video decoding device 400 includes an inlet port 410 (or input port 410) and a receiving unit (Rx) 420 for receiving data, a processor, a logic unit or a central processing unit (CPU) 430 for processing the data, a transmitting unit (Tx) 440 and an outlet port 450 (or output port 450) for transmitting the data, and a memory 460 for storing the data. The video decoding device 400 may also include an optical-to-electrical (OE) component and an electrical-to-optical (EO) component coupled to the inlet port 410, the receiving unit 420, the transmitting unit 440 and the outlet port 450, which are used as an outlet or an inlet of an optical signal or an electrical signal.

[0184] The processor 430 is implemented by hardware and software. The processor 430 can be implemented as one or more CPU chips, one or more cores (e.g., multi-core processors), one or more FPGAs, one or more ASICs, and one or more DSPs. The processor 430 communicates with the input port 410, the receiving unit 420, the sending unit 440, the output port 450, and the memory 460. The processor 430 includes a decoding module 470. The decoding module 470 implements the disclosed embodiments described above. For example, the decoding module 470 performs, processes, prepares, or provides various decoding operations. Therefore, the inclusion of the decoding module 470 provides substantial improvements to the functions of the video decoding device 400 and affects the conversion of the video decoding device 400 to different states. Optionally, the decoding module 470 is implemented with instructions stored in the memory 460 and executed by the processor 430.

[0185] The memory 460 may include one or more disks, one or more tape drives, and one or more solid-state hard disks, and may be used as an overflow data storage device to store programs when they are selected for execution and to store instructions and data read during the execution of the programs. For example, the memory 460 may be volatile and / or non-volatile, and may be a read-only memory (ROM), a random access memory (RAM), a ternary content-addressable memory (TCAM), and / or a static random-access memory (SRAM).

[0186] Figure 5 A simplified block diagram of an apparatus 500 is provided for an exemplary embodiment. The apparatus 500 may be used as Figure 1A The source device 12 and / or destination device 14 in.

[0187] The processor 502 in the device 500 may be a central processing unit. Alternatively, the processor 502 may be any other type of device or devices that are currently available or will be developed in the future and are capable of operating or processing information. Although the disclosed implementations may be implemented using a single processor such as the processor 502 shown in the figure, using multiple processors may improve speed and efficiency.

[0188] In one implementation, the memory 504 in the apparatus 500 may be a read only memory (ROM) device or a random access memory (RAM) device. Any other suitable type of storage device may be used as the memory 504. The memory 504 may include code and data 506 accessed by the processor 502 via a bus 512. The memory 504 may also include an operating system 508 and an application 510, wherein the application 510 includes at least one program that enables the processor 502 to perform the method described herein. For example, the application 510 may include application 1 to application N, and also include a video decoding application that performs the method described herein.

[0189] The apparatus 500 may also include one or more output devices, such as a display 518. In one example, the display 518 may be a touch-sensitive display that combines a display with a touch-sensitive element that can be used to sense touch input. The display 518 may be coupled to the processor 502 via the bus 512.

[0190] Although the bus 512 in the device 500 is described herein as a single bus, the bus 512 may include multiple buses. In addition, the auxiliary memory 514 may be directly coupled to other components in the device 500 or may be accessed through a network, and may include a single integrated unit (e.g., one memory card) or multiple units (e.g., multiple memory cards). Therefore, the device 500 may be implemented in a variety of configurations.

[0191] Parameter Set

[0192] Parameter sets are basically similar and have the same basic design goals, namely to increase bit rate, enhance error resistance and provide system layer interface. The parameter sets in HEVC (H.265) are hierarchical, including Video Parameter Set (VPS), Sequence Parameter Set (SPS) and Picture Parameter Set (PPS), which are similar to the corresponding parameter sets in AVC and VVC. Each slice references an activated PPS, SPS and VPS to access information for decoding the slice. The PPS includes information applicable to all slices in the image, so all slices in the image must reference the same PPS. Strips in different images can also reference the same PPS. Similarly, the SPS includes information applicable to all images in the same coded video sequence.

[0193] Although different images may have different PPSs, many or all images in a coded video sequence usually refer to the same PPS. Reusing parameter sets can avoid sending common information multiple times, thus improving the bit rate. Reusing parameter sets can make the parameter set content carry over a more reliable external communication link or make the parameter set content often repeated in the bitstream to ensure that it will not be lost, so it is more robust.

[0194] Parameter Set

[0195] Parameter sets are basically similar and have the same basic design goals, namely to increase bit rate, enhance error resistance and provide system layer interface. The parameter sets in HEVC (H.265) are hierarchical, including Video Parameter Set (VPS), Sequence Parameter Set (SPS) and Picture Parameter Set (PPS), which are similar to the corresponding parameter sets in AVC and VVC. Each slice references an activated PPS, SPS and VPS to access information for decoding the slice. The PPS includes information applicable to all slices in the image, so all slices in the image must reference the same PPS. Strips in different images can also reference the same PPS. Similarly, the SPS includes information applicable to all images in the same coded video sequence.

[0196] Although different images may have different PPSs, many or all images in a coded video sequence usually refer to the same PPS. Reusing parameter sets can avoid sending common information multiple times, thus improving the bit rate. Reusing parameter sets can make the parameter set content carry over a more reliable external communication link or make the parameter set content often repeated in the bitstream to ensure that it will not be lost, so it is more robust.

[0197] Sequence Parameter Set (SPS)

[0198] The SPS includes parameters applicable to one or more layers in a coded video sequence and does not change with changes in the image in the coded video sequence. Specifically, the SPS includes information indicating a sub-image.

[0199] Some parts of the table below show a snapshot of a portion of the indication of a sub-image in the SPS in ITU JVET-Q2001-v11, download link below:

[0200] http: / / phenix.it-sudparis.eu / jvet / doc_end_user / documents / 17_Brussels / wg11 / JVET-Q2001-v11.zipIn the rest of this application, the prior art document is referred to as VVC Draft 8 for simplicity.

[0201]

[0202]

[0203] Some syntax elements in SPS indicate the location information and control flags of each sub-image. The location information of the i-th sub-image includes:

[0204] subpic_ctu_top_left_x[i] represents the horizontal component of the top-left coordinate of sub-image i in the image; or

[0205] subpic_ctu_top_left_y[i] represents the vertical component of the top-left coordinate of sub-image i in the image; or

[0206] subpic_width_minus1[i], which is the width of subpicture i in the image; or

[0207] subpic_height_minus1[i]: indicates the height of sub-image i in the image.

[0208] Some syntax elements indicate the number of sub-pictures within a picture, for example sps_num_subpics_minus1.

[0209] The image is divided into one or more tile rows and one or more tile columns. A tile is a sequence of CTUs covering a rectangular area of ​​the image. The CTUs in a tile are scanned in raster scan order within the tile.

[0210] A slice consists of an integer number of complete tiles in a picture or an integer number of consecutive complete CTU rows within a tile in a picture. Therefore, each vertical slice boundary is always also a vertical tile boundary. The horizontal boundaries of a slice may not be tile boundaries, but instead consist of horizontal CTU boundaries within a tile; this occurs when a tile is divided into multiple rectangular strips, each of which consists of an integer number of consecutive complete CTU rows within the tile.

[0211] Two striping modes are supported, namely raster scan striping mode and rectangular striping mode. In raster scan striping mode, a strip consists of a series of complete blocks under the block raster scan in the image. In rectangular striping mode, a strip consists of multiple complete blocks, which together constitute a rectangular area in the image; or, a strip consists of multiple consecutive complete CTU rows in a block, which together constitute a rectangular area in the image. The blocks in a rectangular strip are scanned in the rectangular area corresponding to the strip in the block raster scan order.

[0212] A sub-image consists of one or more strips that together cover a rectangular area of ​​the image. Therefore, each sub-image boundary is still a strip boundary, and each vertical sub-image boundary is still a vertical block boundary.

[0213] Each sub-image and tile should satisfy one or both of the following conditions:

[0214] – All CTUs in a sub-image belong to the same block;

[0215] – All CTUs in a partition belong to the same sub-image.

[0216] Split images into CTUs, slices, blocks, and sub-images.

[0217] Split the image into CTUs:

[0218] The image is divided into a series of coding tree units (CTUs). The term "coding tree block (CTB)" is sometimes used interchangeably. The concept of CTU is the same as in HEVC. For an image with 3 sample arrays, 1 CTU consists of 1 N×N luma sample block and 2 corresponding chroma sample blocks. Figure 6 An example of dividing a picture into CTUs is shown. The size of CTUs within a frame must be the same, except for CTUs located at picture boundaries (incomplete CTUs may exist).

[0219] Split the image into blocks:

[0220] When blocking is used, the image is divided into rectangular CTU groups separated by vertical and / or horizontal boundaries. The vertical and horizontal blocking boundaries intersect the image from top to bottom and from the left edge of the image to the right edge of the image, respectively. The codestream includes indications related to the positions of the horizontal and vertical blocking boundaries.

[0221] Figure 7 The example of dividing the image into 9 blocks is shown. In this example, the block boundaries are marked with bold dashed lines. In other words, Figure 7 The block-based raster scan order of a CTU with 9 blocks of different sizes in an image is shown. It should be noted that the block boundaries are marked with bold dashed lines.

[0222] When there is more than one block in the image, the scanning order of CTU is changed. The rules for scanning CTU are as follows:

[0223] 1. The blocks are scanned from left to right and from top to bottom in a raster scan order, which is referred to as the block scan order in this application. This means that starting from the top left block, all blocks in the same block row are first scanned from left to right. Then, starting from the first block in the second block row (the next block row below), all blocks in the second block row are scanned from left to right. The above process is repeated until all blocks are scanned.

[0224] 2. Within a block, scan CTUs in raster scan order. Within a CTU row, scan CTUs from left to right and CTU rows from top to bottom. Figure 7 The example shows the scanning order of CTU when there is block. The numbers in CTU indicate the scanning order.

[0225] Blocking allows image segmentation so that each block can be decoded independently of other blocks in the same image, where decoding refers to entropy decoding, residual decoding, and predictive decoding. In addition, using blocks, the image can be divided into regions of similar size. Therefore, the blocks in the image are processed in parallel with each other, which is suitable for multi-core processing environments where each processing core is identical.

[0226] The terms "processing order" and "scanning order" are used in this application as follows:

[0227] Processing refers to encoding or decoding of CTUs in an encoder or decoder. Scanning order refers to indexing specific partitions within a picture. The CTU scanning order within a tile refers to how CTUs within a tile are indexed, which may be different from the order in which they are processed.

[0228] Split an image into strips:

[0229] Striping can realize image segmentation, so that each stripe can be decoded independently of other stripes in the same image, where decoding refers to entropy decoding, residual decoding, and predictive decoding. The difference from block segmentation is that stripes can have more arbitrary shapes (there are more segmentation possibilities), and the purpose of strip segmentation is not parallel processing, but to enhance error resistance and improve packet size matching in the transmission environment.

[0230] A slice can include a complete image or its parts. In HEVC, a slice includes multiple consecutive CTUs arranged in the processing order of the image. A slice is identified by its starting CTU address, which is indicated in the slice header or picture parameter set or other unit.

[0231] In VVC draft 8, a slice consists of an integer number of complete blocks in a picture or an integer number of consecutive CTU rows within a block in a picture. Therefore, each vertical slice boundary is always also a vertical block boundary. The horizontal boundary of a slice may not be a block boundary, but include a horizontal CTU boundary within a block; this occurs when a block is divided into multiple rectangular strips, each of which includes an integer number of consecutive complete CTU rows within the block.

[0232] In some examples, there are two stripe modes, namely raster scan stripe mode and rectangular stripe mode. In raster scan stripe mode, a stripe includes a series of blocks under a block raster scan in an image. In rectangular stripe mode, a stripe includes multiple blocks, which together constitute a rectangular area in the image; or, a stripe includes multiple consecutive CTU rows in a block, which together constitute a rectangular area in the image. The blocks in a rectangular stripe are scanned in a rectangular area corresponding to the stripe in a block raster scan order.

[0233] All slices in a picture together constitute the entire picture, that is, all CTUs in a picture must be included in one of the slices in the picture. Similar rules apply to blocks and sub-pictures.

[0234] Split an image into sub-images:

[0235] A sub-image is a rectangular partition of an image. A sub-image can be an entire image or a portion of an image. Sub-images enable image segmentation so that each sub-image can be decoded independently of other sub-images in the entire video sequence. In VVC draft 8, this also applies when indicated in the bitstream. That is, when subpic_treated_as_pic_flag[i] indicates true for sub-image i, sub-image i can be decoded independently of other sub-images in the entire video sequence.

[0236] The difference between a sub-picture and a block or slice is that a sub-picture produces an independently decodable video sequence within the video sequence, whereas for blocks and slices, independent decoding is only guaranteed within a single picture of the video sequence.

[0237] In VVC draft 8, a sub-image consists of one or more strips that together cover a rectangular area in the image. Therefore, each sub-image boundary is always a stripe boundary, and each vertical sub-image boundary is always a vertical block boundary.

[0238] Figure 8 An example of a block, a strip, and a sub-image is provided. In other words, Figure 8 An example is shown in which an image includes 4 blocks, ie, 2 block columns and 2 block rows, 4 rectangular strips and 3 sub-images. Sub-image 1 includes 2 strips.

[0239] exist Figure 8 In the example shown, the picture is partitioned into 216 CTUs, 4 blocks, 4 slices, and 3 sub-pictures. The value of sps_num_subpics_minus1 is 2, and the position-dependent syntax elements have the following values:

[0240] For sub-image 0,

[0241] subpic_ctu_top_left_x[0] is not indicated but is inferred to be 0;

[0242] subpic_ctu_top_left_y[0] is not indicated but is inferred to be 0;

[0243] The value of subpic_width_minus1[0] is 8;

[0244] The value of subpic_height_minus1[0] is 11.

[0245] For sub-image 1,

[0246] The value of subpic_ctu_top_left_x[1] is 9.

[0247] The value of subpic_ctu_top_left_y[1] is 0;

[0248] The value of subpic_width_minus1[1] is 8;

[0249] The value of subpic_height_minus1[1] is 5.

[0250] For sub-image 2,

[0251] The value of subpic_ctu_top_left_x[2] is 9.

[0252] The value of subpic_ctu_top_left_y[2] is 6.

[0253] subpic_width_minus1[2] is not indicated but is inferred to be 8;

[0254] subpic_height_minus1[2] is not indicated but is inferred to be 5.

[0255] Instruction block

[0256] The following table illustrates the indication of the partition size and coordinates of the partitions within a picture, from the picture parameter set RBSP syntax table in VVC draft 8.

[0257]

[0258] The information of the partitioning (the address and size of each partition) is usually included in the parameter set. In the above example, an indication (no_pic_partition_flag) is first included in the codestream to indicate whether the picture is partitioned into slices and blocks. If the indication is true (indicating that the picture is not partitioned into slices or blocks), it is inferred that the picture is partitioned into only one slice and only one block, whose boundaries are aligned with the picture boundaries. Otherwise (no_pic_partition_flag is false), the block partitioning information is included in the codestream.

[0259] The syntax element tile_column_width_minus1[i] indicates the width of the i-th tile column. The syntax element tile_row_height_minus1[i] indicates the height of the i-th tile row.

[0260] The tile row height and tile column width can be explicitly indicated in the codestream or inferred. The syntax elements num_exp_tile_columns_minus1 and num_exp_tile_rows_minus1 indicate the number of tile columns and tile rows whose width and height are explicitly indicated, respectively. The width and height of the remaining tile columns and tile rows are inferred according to the function.

[0261] The index of the blocks follows the "block scanning order in the image". The blocks in the image are sorted (scanned) in raster scan order. The first block in the upper left corner of the image is the 0th block. The index increases from left to right in each block row. After the last block in the block row is scanned, the leftmost block of the next block row (the block row after the current block row) is scanned.

[0262] Indicator strip:

[0263] The following table illustrates the indication of block size and coordinates in rectangular strips within a picture, from the picture parameter set RBSP syntax table in VVC draft 8.

[0264]

[0265]

[0266] In VVC Draft 8, there is the following relationship between slices and blocks. A slice includes one or more complete blocks, or a block includes one or more complete slices. Therefore, the stripe coordinates and size are indicated according to the block segmentation. In VVC Draft 8, the block segmentation is first indicated in the image parameter set. After that, the stripe segmentation information is indicated by the block mapping information.

[0267] In the above table, the syntax element num_slices_in_pic_minus1 indicates the number of slices within the picture. Tile_idx_delta[i] indicates the difference between the tile index of the first tile in the (i+1)th slice and the i-th slice. For example, the first tile of the first slice within the picture has an index of 0. If the tile index of the first tile of the second slice within the picture is 5, then Tile_idx_delta[0] is equal to 5. In this case, the tile index is used as the address of the slice, that is, the index of the first tile in the slice is the starting address of the slice.

[0268] slice_width_in_tiles_minus1[i] and slice_height_in_tiles_minus1[i] represent the width and height of the i-th slice within the picture in units of the number of tiles.

[0269] In the above table, if slice_width_in_tiles_minus1[i] and slice_height_in_tiles_minus1[i] are both equal to 0 (indicating that the height and width of the i-th slice are at most 1 tile), the syntax element num_exp_slices_in_tile[i] may be included in the bitstream. This syntax element indicates the number of slices in a tile.

[0270] As described above, according to VVC draft 8, a slice may include multiple complete tiles, or a tile may include multiple complete slices, prohibiting other alternatives. According to the syntax table above, the number of tiles within the slice is first indicated (by including slice_width_in_tiles_minus1[i] and slice_height_in_tiles_minus1[i]). In addition, if the number of tiles within the slice is equal to 1 according to the indication, the number of slices within the tile is indicated (by num_exp_slices_in_tile[i]). Therefore, if slice_width_in_tiles_minus1[i] and slice_height_in_tiles_minus1[i] are both equal to 1, the actual size of the slice may be equal to or less than 1 tile.

[0271] The syntax element single_slice_per_subpic_flag, when true, indicates that each sub-picture of all sub-pictures of a slice has one and only one slice (ie, a sub-picture cannot be divided into more than one slice).

[0272] According to an alternative indication method, slice mapping (slice start address and slice size) is indicated according to the following steps in VVC draft 8.

[0273] 1. First, the tile segmentation map is indicated in the bitstream, where the index (which can be called tileIdx) is used to index all tiles in the image (in the order of tile scanning in the image). After this step, the index, coordinates and size of each tile are known.

[0274] 2. Indicates the number of slices in the picture. In one example, the number of slices may be indicated by the syntax element num_slices_in_pic_minus1.

[0275] 3. For the first stripe in the image, only the width and height of the stripe in number of tiles are indicated. The starting address of the first stripe is not explicitly indicated but is inferred to be tileIdx 0 (the first tile in the image is the first tile in the first stripe within the image).

[0276] 4. If the width and height of the first slice are both equal to 1 tile, and if there are more than 1 CTU row in the tiles included in the first slice, then the syntax element num_exp_slices_in_tile[0] is indicated, which indicates the number of slices included in the tile (referred to as numSlicesInTile[0]).

[0277] 5. For each slice from the second slice to the last slice in the picture (including the second slice but excluding the last slice), explicitly indicate the width and height of the slice in units of the number of tiles. The starting address of the slice can be explicitly indicated by the syntax element tile_idx_delta[i], where i is the index of the slice. If the starting address is not explicitly indicated (for example, if the order of indication of the slices is such that the starting position of the next slice can be inferred from the starting position, width and height of the current slice), the starting address of the slice is inferred according to the function.

[0278] 6. If the width and height of the nth slice (n is between 2 and the number of slices in the picture minus 1) are both equal to 1 tile, and if there are more than 1 CTU row in the tile included in the first slice, the syntax element num_exp_slices_in_tile[n] is indicated, which indicates the number of slices included in the tile.

[0279] 7. For the last stripe in the image, the width and height of the stripe are not explicitly indicated, but inferred based on the number of tiles in the image width, the number of tiles in the image height, and the start address of the last stripe. The start address of the last stripe can be explicitly indicated or inferred. The width and height of the last stripe in the image can be inferred based on the following two formulas, which are from Section 6.5.1 in VVC draft 8.

[0280] slice_width_in_tiles_minus1[i]=NumTileColumns–1–tileX

[0281] slice_height_in_tiles_minus1[i]=NumTileRows–1–tileY

[0282] As can be seen from the steps explained above, the width and height of the last stripe are not indicated. It is desirable not to include the width and height of the last stripe in the bitstream, because if the starting address of the stripe is known, it is easy to infer the width and height of the stripe. Therefore, by not including redundant information in the bitstream, efficient compression is achieved.

[0283] The variables tileX, tileY, NumTileColumns, and NumTileRows in the above equation are explained later.

[0284] Section 6.5.1 of VVC draft 8

[0285] 6.5.1CTB raster scanning, block scanning and sub-image scanning process

[0286] For rectangular slices, the list NumCtusInSlice[i] (i ranges from 0 to num_slices_in_pic_minus1 (inclusive)) represents the number of CTUs in the i-th slice, the list SliceTopLeftTileIdx[i] (i ranges from 0 to num_slices_in_pic_minus1 (inclusive)) represents the index of the top left tile in the slice, and the matrix CtbAddrInSlice[i][j] (i ranges from 0 to num_slices_in_pic_minus1 (inclusive), j ranges from 0 to NumCtusInSlice[i]–1 (inclusive)) represents the image raster scan address of the j-th CTB in the i-th slice, which are derived as follows:

[0287]

[0288]

[0289] Also, for completeness, nearly identical content is referenced in Recommendation ITU-T H.266 (ISO / IEC 23090-3:2020) Generic Video Coding, referenced via http: / / handle.itu.int / 11.1002 / 1000 / 14336, dated August 29, 2020.

[0290] When rect_slice_flag is equal to 1, the list NumCtusInSlice[i] (i ranges from 0 to num_slices_in_pic_minus1 (inclusive)) represents the number of CTUs in the i-th slice, the list SliceTopLeftTileIdx[i] (i ranges from 0 to num_slices_in_pic_minus1 (inclusive)) represents the tile index of the tile including the first CTU in the slice, the matrix CtbAddrInSlice[i][j] (i ranges from 0 to num_slices_in_pic_minus1 (inclusive), j ranges from 0 to NumCtusInSlice[i]–1 (inclusive)) represents the image raster scan address of the j-th CTB in the i-th slice, and the variable NumSlicesInTile[i] represents the number of slices in the tile including the i-th slice. These four are derived as follows:

[0291]

[0292]

[0293]

[0294] Reference is now made to the text in VVC Draft 8 mentioned above.

[0295] The above step-by-step description of slice mapping indication within an image is an example of indication in VVC draft 8. More specifically, the above description describes the case where rectangular slices are used, the number of slices in each sub-image is not indicated as 1, there are more than 1 partitions in the image, and the number of CTU rows in the partitions is greater than 1. If some of the parameters are changed, other indication modes of slice mapping can be used. For example, if only 1 slice is indicated per sub-image, the width and height of the slice will not be explicitly indicated in the codestream, but will be inferred from the corresponding sub-image width and height.

[0296] Section 6.5.1 of VVC draft 8 details the scanning order of CTUs within slice i, where i is the slice index. The matrix CtbAddrInSlice[i][n] is the output of this section and represents the scanning order of CTUs within slice i, where n is a CTU index between 0 and the number of CTUs in slice i. The value of CtbAddrInSlice[i][n] represents the address of the nth CTU in slice i (in raster scan order in the image).

[0297] Fig. 9 An example is shown of a raster scan order in an image including a CTU (CTU raster scan order in image) and a stripe in the image (stripe 5, i.e., the fifth stripe in the image). In other words, Fig. 9 The raster scan order of CTUs within a picture is shown, where the picture includes 1 tile and 1 sub-picture.

[0298] According to the example, the value of CtbAddrInSlice looks like this:

[0299] CtbAddrInSlice[4][0]=27,

[0300] CtbAddrInSlice[4][1]=28,

[0301] CtbAddrInSlice[4][2]=29,

[0302] CtbAddrInSlice[4][3]=30,

[0303] CtbAddrInSlice[4][4]=37,

[0304] CtbAddrInSlice[4][5]=38,

[0305] CtbAddrInSlice[4][6]=39,

[0306] CtbAddrInSlice[4][7]=40.

[0307] Terms used in this application:

[0308] "Block scanning order in an image" explained in this application

[0309] "CTU scanning order within a block" explained in this application

[0310] "CTU scanning order within a slice" explained in this application

[0311] · "CTU raster scan order in the image" as explained in this application

[0312] · "Block - based scan order of CTUs within an image"

[0313] · "Scan order" means indexing X in Y in ascending order of the index.

[0314] · "Processing" means decoding or encoding in an encoder or decoder. Thus, the processing order means the order in which X (e.g., CTU) is processed in the encoder or decoder.

[0315] In VVC Draft 8, when there is more than 1 block per image, the slice indication is as follows:

[0316] 1. Determine the starting block address of the slice in units of the number of blocks using explicit indication or inference.

[0317] 2. For each slice except the last slice, indicate the number of blocks included in the slice.

[0318] a. If it is determined that the slice includes only 1 block, indicate the number of slices included within the block.

[0319] 3. For the last slice in the image, if it is determined that the slice includes at least 1 complete block, infer the number of blocks in the slice.

[0320] In other words, in VVC Draft 8, if both the width and height of the last slice in the image are greater than or equal to 1 block, the size of the last slice is inferred rather than indicated.

[0321] This can be seen from Table 1, where if slice_width_in_tiles_minus1[i] and slice_height_in_tiles_minus1[i] (representing the width and height of the i - th slice in units of the number of blocks respectively) are less than num_slices_in_pic_minus1 (because of the for loop "for(i = 0; i < num_slices_in_pic_minus1; i++)"), then both are included in the bitstream. Thus, when i is equal to num_slices_in_pic_minus1, i.e., in the case of the last slice, the width and height of the slice are not indicated.

[0322] Luma mapping with chroma scaling (LMCS):

[0323] In VVC, a coding tool called lumamapping with chroma scaling (LMCS) is added as a new processing block before the loop filter. LMCS mainly consists of two parts: (1) in-loop mapping of the luma component based on an adaptive piecewise linear model, and (2) for the chroma components, luma-dependent chroma residual scaling is applied. Fig.11 The LMCS architecture from the decoder perspective is shown. Fig.11 The light blue shaded blocks in represent processing in the mapped domain; these blocks include inverse quantization, inverse transform, luma intra prediction, and summation of luma prediction and luma residual. Fig.11 The non-shaded blocks in represent processing in the original (i.e., non-mapped) domain; these blocks include loop filters (such as deblocking filtering, ALF, and SAO), motion compensated prediction, chroma intra-frame prediction, chroma prediction and chroma residual addition, and the decoded image is stored as a reference image. Fig.11 The light yellow shaded blocks in the figure are new LMCS functional blocks, including forward and reverse mapping of luma signals and luma-dependent chroma scaling processes. Like most other tools in VVC, LMCS can be enabled / disabled at the sequence level via the SPS flag.

[0324] Slice header: A portion of a coded slice that includes data elements related to all partitions or to a row of CTUs within a partition represented in the slice.

[0325] Strip Header:

[0326] Table 3

[0327]

[0328]

[0329] Table 3 exemplifies a part of the slice header syntax structure in VVC Draft 8. Each row including "..." indicates that some rows in the table are omitted.

[0330] In the slice header, the syntax elements represent the following:

[0331] picture_header_in_slice_header_flag indicates whether the picture header syntax structure exists in the slice header. If the picture header syntax structure does not exist in the slice header, the picture header syntax structure must be included in the picture header, and the picture header must be included in the codestream.

[0332] slice_address indicates the chunk index of the first chunk in the slice.

[0333] num_tiles_in_slice_minus1 indicates the number of tiles included in the slice.

[0334] Fig.10 The example shows that the image is divided into 12 blocks and 3 strips. Or, in other words, Fig.10 It is shown that an image including 18×12 luminance CTUs is partitioned into 12 tiles and 3 raster scan strips.

[0335] exist Fig.10 In the example shown, the slice address and syntax element num_tiles_in_slice_minus1 have the following values ​​for each slice in the picture:

[0336] Strip 1

[0337] o slice_address = 0, the starting address of the slice is block index 0.

[0338] o num_tiles_in_slice_minus1=1, the slice includes 2 tiles.

[0339] Strip 2

[0340] o slice_address=2, the starting address of the slice is block index 2.

[0341] o num_tiles_in_slice_minus1=5, the slice includes 5 tiles.

[0342] Strip 3

[0343] o slice_address=7, the starting address of the slice is block index 7.

[0344] o nnum_tiles_in_slice_minus1=4, the slice includes 5 tiles.

[0345] slice_lmcs_enabled_flag equal to 1 indicates that luma mapping with chroma scaling is enabled for the current slice. slice_lmcs_enabled_flag equal to 0 indicates that luma mapping with chroma scaling is not enabled for the current slice. When slice_lmcs_enabled_flag is not present, slice_lmcs_enabled_flag is inferred to be 0.

[0346] The starting block in a slice (the address of the slice in the image) and the number of blocks in the image can be indicated in two ways. When rect_slice_flag is equal to 1, indicating that the slice in the image is rectangular, the indication mechanism in Table 1 is used. Table 1 represents a part of the image parameter set. In this mechanism, the addresses and sizes of all slices in the image are indicated in the image parameter set before the first slice of the image in the codestream. It should be noted that the codestream has the order in which the information (image parameter set, slices in the image, syntax elements in the syntax structure, etc.) is included in the codestream (or parsed from the codestream).

[0347] If rect_slice_flag is equal to 0, indicating that the slices in the picture do not need to be rectangular, the slice_address and the syntax element num_tiles_in_slice_minus1 in the slice header indicate the address and size of the slice.

[0348] Image header:

[0349] 7.3.2.6 Image Header RBSP Syntax

[0350]

[0351] The above table shows the picture header syntax according to VVC draft 8. The above table includes the picture header structure and rbsp_trailing_bits(), which are padding bits to make the number of bits in the picture header equal to a multiple of 8.

[0352] Image header structure:

[0353] 7.3.2.7 Image header structure syntax

[0354]

[0355]

[0356] The picture header structure includes syntax elements applicable to all slices in the picture. Some syntax elements included in the picture header structure are shown in the table above. For example, ph_lmcs_enabled_flag indicates whether the luma mapping with chroma scaling (LMCS) coding tool is enabled for the slices in the picture.

[0357] ph_lmcs_enabled_flag equal to 1 indicates that luma mapping with chroma scaling is enabled for all slices associated with the PH. ph_lmcs_enabled_flag equal to 0 indicates that luma mapping with chroma scaling is disabled for one or more or all slices associated with the PH. When ph_lmcs_enabled_flag is not present, the value of ph_lmcs_enabled_flag is inferred to be 0.

[0358] As mentioned above, the picture header structure can be present in either the slice header or the picture header. According to VVC draft 8, the picture header must be in the slice header or in the picture header of the picture. If the picture header structure is in the picture header, all slices in the picture that reference the picture header must not include the picture header structure. The reverse is also true, if the picture header structure is not in the picture header, and therefore the picture header is not included in the codestream corresponding to a particular picture, then the picture header structure must be in the slice header of the slice in the picture.

[0359] In addition, there is another restriction in VVC Draft 8, that is, if the picture header structure is in the slice header, the picture must include only one slice (that is, the picture cannot be divided into multiple slices).

[0360] The current VVC draft 8 is not efficient because in some cases, redundant slice_adress and num_tiles_in_slice_minus1 are included in the bitstream. Including redundant slice_adress and num_tils_in_slice_minus1 in the bitstream increases the bitstream because each slice header of the picture can include this syntax element, so the compression efficiency is reduced.

[0361] Embodiment 1:

[0362] According to one embodiment, whether slice_address and the syntax element num tils in slice minus1 are present in the slice header is controlled depending on whether the picture header structure is present in the slice header.

[0363]

[0364]

[0365] The present application can be implemented as shown in the above table. According to the present application, when the condition in line 6 is true, slice_address is included in the stripe header. In other words, slice_address is included in the stripe header in the following cases:

[0366] The number of tiles in the image is greater than 1, non-rectangular slices are used (rect_slice_flag=0) and the image header structure is not present in the slice header;

[0367] or,

[0368] (rect_slice_flag=1) The number of slices in the current sub-image is greater than 1.

[0369] Otherwise, slice_address is not included in the slice header and its value can be inferred to be 0.

[0370] Additionally or alternatively, whether the syntax element num_tiles_in_slice_minus1 is present in the slice header may be controlled by whether the picture header structure is present in the slice header. For example, if the picture header structure is in the slice header, num_tiles_in_slice_minus1 is not included in the slice header.

[0371] The 10th row in the above table shows an implementation of the present application, in which num_tiles_in_slice_minus1 is included in the slice header in the following cases:

[0372] rect_slice_flag is equal to 0, the number of tiles in the picture is greater than 1 and picture_header_in_slice_header_flag is equal to 0.

[0373] Otherwise, num_tiles_in_slice_minus1 is not included in the slice header and its value can be inferred to be the number of tiles in the image minus 1.

[0374] As mentioned above, there is a codestream conformance requirement in VVC draft 8, which restricts the picture header structure to be included in the slice header. According to VVC draft 8, if there is one slice per picture, the picture header structure can be included in the slice header.

[0375] According to the present application, whether the picture header structure is present in the slice header is used to control whether the slice_address and the number of blocks are present in the slice indication, because if there is a single stripe in the picture, the stripe address must be equal to the first block in the picture, and the number of blocks in the stripe must be equal to the number of blocks in the picture.

[0376] Embodiment 2:

[0377]

[0378]

[0379] Additionally or alternatively, whether num_tiles_in_slice_minus1 is present in the slice header is controlled by the difference between the number of tiles in the picture (eg NumTilesInPic in the table above) and the slice address.

[0380] More specifically, if the difference between the number of tiles in the picture and the slice address is less than a threshold, num_tiles_in_slice_minus1 is not included in the slice header and its value is inferred to be a predefined number. For example, if the difference between NumTilesInPic and slice_address is less than or equal to 1, num_tiles_in_slice_minus1 is not included in the bitstream and its value is inferred to be 0 (indicating that there is one tile in the current slice).

[0381] slice_address indicates the slice address of the slice. When slice_address does not exist, the value of slice_address is inferred to be 0.

[0382] If rect_slice_flag is equal to 0, the following applies:

[0383] The stripe address is the raster scan block index of the first block in the stripe.

[0384] The length of slice_address is Ceil(Log2(NumTilesInPic)) bits.

[0385] The value range of slice_address should be 0 to NumTilesInPic–1 (inclusive).

[0386] Otherwise (rect_slice_flag is equal to 1), the following applies:

[0387] The slice address is the sub-picture level slice index of the current slice, ie, SubpicLevelSliceIdx[j], where j is the picture level slice index of the current slice.

[0388] The length of slice_address is Ceil(Log2(NumSlicesInSubpic[CurrSubpicIdx])) bits.

[0389] The value range of slice_address shall be from 0 to NumSlicesInSubpic[CurrSubpicIdx]–1 (inclusive).

[0390] The requirement for codestream consistency is that the following constraints apply:

[0391] If rect_slice_flag is equal to 0 or sps_subpic_info_present_flag is equal to 0, the value of slice_address shall not be equal to the value of slice_address of any other coded slice NAL unit of the same coded picture.

[0392] Otherwise, the pair of subpic_id and slice_address values ​​shall not be equal to the pair of subpic_id and slice_address values ​​of any other coded slice NAL unit of the same coded picture.

[0393] The shape of the slices in a picture shall be such that each CTU, when decoded, shall have its entire left and entire top borders include the picture boundary or include the boundaries of one or more previously decoded CTUs.

[0394] num_tiles_in_slice_minus1+1, when present, indicates the number of tiles in the slice. The value of num_tiles_in_slice_minus1 shall be in the range of 0 to NumTilesInPic–1, inclusive. When num_tiles_in_slice_minus1 is not present, the value of num_tiles_in_slice_minus1 is inferred to be 0.

[0395] The variable NumCtusInCurrSlice represents the number of CTUs in the current slice, and the list CtbAddrInCurrSlice[i] (i ranges from 0 to NumCtusInCurrSlice–1 (including the end value)) represents the image raster scan address of the i-th CTB in the slice. The two are derived as follows:

[0396]

[0397]

[0398] Embodiment 3:

[0399]

[0400] Additionally or alternatively, slice_lmcs_enabled_flag is present in the slice header depending on whether the picture header structure is present in the slice header. An exemplary implementation is included in row 15 of the above table.

[0401] More specifically, if the picture header structure is included in the slice header, slice_lmcs_enabled_flag is not included in the slice. In addition, when slice_lmcs_enabled_flag is not included in the slice, the value of slice_lmcs_enabled_flag can be inferred according to the following rules:

[0402] The value of slice_lmcs_enabled_flag is inferred from ph_lmcs_enabled_flag.

[0403] Alternatively or additionally, when slice_lmcs_enabled_flag is not present in the slice header, the value of slice_lmcs_enabled_flag may be inferred according to the following rules:

[0404] When picture_header_in_slice_header_flag is equal to 1 (the picture header structure is included in the slice header), the value of slice_lmcs_enabled_flag is inferred to be ph_lmcs_enabled_flag.

[0405] Alternatively or additionally, when slice_lmcs_enabled_flag is not present in the slice header, the value of slice_lmcs_enabled_flag may be inferred according to the following rules:

[0406] When picture_header_in_slice_header_flag is equal to 0, the value of picture_header_in_slice_header_flag is inferred to be 0.

[0407] The above embodiments can be implemented by replacing the conditions "!rect_slice_flag&&NumTilesInPic>1" in lines 6 and 10 with "!rect_slice_flag". In some exemplary implementations, if the value of rect_slice_flag is equal to 0, indicating that the strip in the image is not necessarily rectangular, the value of the NumTilesInPic syntax element must be greater than 0 (for example, the number of tiles in the strip must be greater than 1). In other words, if the number of tiles in the image is greater than 1, the value of rect_slice_flag can only be equal to 0. In this implementation, the condition "!rect_slice_flag&&NumTilesInPic>1" and the condition "!rect_slice_flag" will produce the same result. Therefore, the conditions (in lines 6 and 10 in all the above embodiments), including part of the condition "!rect_slice_flag&&NumTilesInPic>1", can be replaced with "!rect_slice_flag".

[0408] The above embodiment can be implemented by replacing the condition “!rect_slice_flag&&NumTilesInPic>1” in lines 6 and 10 with “!rect_slice_flag”. In some exemplary implementations, if the value of rect_slice_flag is equal to 0, it means that each slice in the image includes one or more tiles, and if picture_header_in_slice_header_flag is equal to 0, it means that the number of slices in the image is greater than 1, so if picture_header_in_slice_header_flag is equal to 0 and rect_slice_flag is equal to 0, NumTilesInPic must be greater than 1.

[0409] The following explains the application of the encoding method and the decoding method shown in the above embodiments and the system using these applications.

[0410] Fig.14 A flowchart of a method for decoding a video stream is provided in accordance with an embodiment of the present application. Fig.14The method shown is a method for decoding an image from a video code stream implemented by a decoding device. The code stream includes a slice header of a current stripe and data representing the current stripe, and the method includes: if a condition is met, obtaining (step 1601) a parameter for deriving the number of blocks in the current stripe from the slice header, wherein the condition includes: the stripe address of the current stripe is not the address of the last block in the image where the current stripe is located; reconstructing (step 1603) the current stripe through the number of blocks in the current stripe and the data representing the current stripe.

[0411] Fig.15 A flowchart of another method for encoding a video stream is provided for one embodiment of the present application. Fig.15 The method shown is a method for encoding a video code stream implemented by an encoding device. The code stream includes a slice header of a current slice and data representing the current slice, and the method includes: if a condition is met, encoding a parameter in the slice header for deriving the number of blocks in the current slice (step 1701), wherein the condition includes: the slice address of the current slice is not the address of the last block in the image where the current slice is located; reconstructing (step 1703) the current slice through the number of blocks in the current slice and the data representing the current slice.

[0412] Fig.16 A device for decoding a video code stream, namely a decoder (30), is shown according to an embodiment of the present application. Fig.16 The device shown is a device (30) for decoding an image from a video code stream. The code stream includes a slice header of a current slice and data representing the current slice, and the device includes: an acquisition unit (3001) for: if a condition is met, acquiring a parameter for deriving the number of blocks in the current slice from the slice header, wherein the condition includes: the slice address of the current slice is not the address of the last block in the image where the current slice is located; a reconstruction unit (3003) for reconstructing the current slice using the number of blocks in the current slice and the data representing the current slice.

[0413] Fig.17 A device for encoding a video code stream, namely an encoder (20), provided in one embodiment of the present application is shown. Fig.17The device shown is a device (20) for encoding a decoded video code stream. The code stream includes a slice header of a current slice and data representing the current slice, and the device includes: an encoding unit (2001) for encoding a parameter in the slice header for deriving the number of blocks in the current slice if a condition is satisfied, wherein the condition includes: the slice address of the current slice is not the address of the last block in the image where the current slice is located; and a reconstruction unit (2003) for reconstructing the current slice using the number of blocks in the current slice and the data representing the current slice.

[0414] Fig.16 The video decoding device shown may be Figure 1A , Figure 1B and Figure 3 The decoder 30 and Fig.13 The video decoder 3206 shown in FIG. 3204 may also be included therein. In addition, the decoding device may be included in Figure 4 The video decoding device 400 shown, Figure 5 The device 500 and Fig.12 In the terminal device 3106 shown. Fig.17 The encoding device shown may be Figure 1A , Figure 1B and Figure 3 The encoder 20 shown in FIG. 1 may also be included therein. In addition, the encoding device may be included in Figure 4 The video decoding device 400 shown, Figure 5 The device 500 and Fig.12 In the capture device 3102 shown.

[0415] The present application discloses the following further features. Fig.12 31 is a block diagram of a content supply system 3100 for implementing a content distribution service. The content supply system 3100 includes a capture device 3102, a terminal device 3106, and optionally a display 3126. The capture device 3102 communicates with the terminal device 3106 via a communication link 3104. The communication link may include the communication channel 13 described above. The communication link 3104 includes, but is not limited to, Wi-Fi, Ethernet, cable, wireless (3G / 4G / 5G), USB, or any combination thereof.

[0416] Capture device 3102 is used to generate data, and data can be encoded by the coding method shown in the above embodiment. Optionally, capture device 3102 can distribute data to a streaming media server (not shown in the figure), and the server encodes the data and sends the encoded data to terminal device 3106. Capture device 3102 includes but is not limited to a camera, a smart phone or a tablet computer, a computer or a notebook computer, a video conferencing system, a PDA, a vehicle-mounted device or any combination thereof. For example, capture device 3102 may include source device 12 described above. When data includes video, the video encoder 20 included in capture device 3102 can actually perform video encoding. When data includes audio (i.e., sound), the audio encoder included in capture device 3102 can actually perform audio encoding. For some actual scenes, capture device 3102 distributes encoded video data and encoded audio data by multiplexing encoded video data and encoded audio data together. For other actual scenes, for example, in a video conferencing system, encoded audio data and encoded video data are not multiplexed. The capture device 3102 distributes the encoded audio data and the encoded video data to the terminal device 3106 .

[0417] In the content supply system 3100, the terminal device 310 receives and regenerates the encoded data. The terminal device 3106 may be a device having data receiving and recovery capabilities, such as a smart phone or tablet computer 3108, a computer or laptop computer 3110, a network video recorder (NVR) / digital video recorder (DVR) 3112, a television 3114, a set top box (STB) 3116, a video conferencing system 3118, a video surveillance system 3120, a personal digital assistant (PDA) 3122, a vehicle-mounted device 3124, or a combination thereof, or a device capable of decoding the above-mentioned encoded data. For example, the terminal device 3106 may include the destination device 14 described above. When the encoded data includes video, the video decoder 30 included in the terminal device preferentially performs video decoding. When the encoded data includes audio, the audio decoder included in the terminal device preferentially performs audio decoding processing.

[0418] For a terminal device with a display, such as a smartphone or tablet 3108, a computer or laptop 3110, a network video recorder (NVR) / digital video recorder (DVR) 3112, a TV 3114, a personal digital assistant (PDA) 3122, or a vehicle-mounted device 3124, the terminal device can feed the decoded data to its display. For a terminal device without a display, such as an STB 3116, a video conferencing system 3118, or a video surveillance system 3120, an external display 3126 is connected therein to receive and display the decoded data.

[0419] When each device in the system performs encoding or decoding, the image encoding device or the image decoding device as shown in the above-mentioned embodiments can be used.

[0420] Fig.13 31 is a schematic diagram of an exemplary structure of the terminal device 3106. After the terminal device 3106 receives the stream from the capture device 3102, the protocol processing unit 3202 analyzes the transmission protocol of the stream. The protocol includes but is not limited to Real Time Streaming Protocol (RTSP), Hyper Text Transfer Protocol (HTTP), HTTP Live streaming protocol (HLS), MPEG-DASH, Real-time Transport Protocol (RTP), Real-time Messaging Protocol (RTMP), or any combination thereof, etc.

[0421] After the protocol processing unit 3202 processes the stream, a stream file is generated. The file is output to the demultiplexing unit 3204. The demultiplexing unit 3204 can divide the multiplexed data into encoded audio data and encoded video data. As mentioned above, for other actual scenes, for example, in a video conferencing system, the encoded audio data and the encoded video data are not multiplexed. In this case, the encoded data is not sent to the video decoder 3206 and the audio decoder 3208 by the demultiplexing unit 3204.

[0422] Through the demultiplexing process, a video elementary stream (ES), an audio ES, and optional subtitles are generated. The video decoder 3206 includes the video decoder 30 described in the above embodiment, and decodes the video ES through the decoding method shown in the above embodiment to generate a video frame, and feeds this data to the synchronization unit 3212. The audio decoder 3208 decodes the audio ES to generate an audio frame, and feeds this data to the synchronization unit 3212. Optionally, the video frame can be stored in a buffer ( Fig.13 Similarly, the audio frame may be stored in a buffer (not shown) before being sent to the synchronization unit 3212. Fig.13 (not shown).

[0423] The synchronization unit 3212 synchronizes the video frames and the audio frames and provides the video / audio to the video / audio display 3214. For example, the synchronization unit 3212 synchronizes the presentation of the video information and the audio information. The information may be coded in syntax using timestamps associated with the presentation of the decoded audio and visual data and timestamps associated with the transmission of the data stream itself.

[0424] If subtitles are included in the stream, the subtitle decoder 3210 decodes the subtitles, synchronizes the subtitles with the video frames and the audio frames, and provides the video / audio / subtitles to the video / audio / subtitle display 3216.

[0425] The present application is not limited to the above-mentioned system, and the image encoding device or the image decoding device in the above-mentioned embodiments may be included in other systems such as automobile systems.

[0426] Mathematical operators

[0427] The mathematical operators used in this application are similar to those used in the C programming language. However, this application accurately defines the results of integer division and arithmetic shift operations, and also defines other operations, such as power operations and real-valued division. Numbering and counting specifications usually start from 0, for example, "first" is equivalent to the 0th, "second" is equivalent to the 1st, and so on.

[0428] Arithmetic operators

[0429] The arithmetic operators are defined as follows:

[0430] +Addition

[0431] – Subtraction (binary operator) or negation (unary prefix operator)

[0432] *Multiplication operations, including matrix multiplication

[0433] xy exponentiation, representing x raised to the power of y. Depending on the context, this notation is used as a superscript, not as an exponentiation.

[0434] / Integer division, truncated toward 0. For example, 7 / 4 and –7 / –4 truncate to 1, and –7 / 4 and 7 / –4 truncate to –1.

[0435] ÷ division operation without truncation or rounding.

[0436] Divide "x" / "y" without truncation or rounding.

[0437] The cumulative sum of the function f(i) for all integer values ​​of i from x to y (inclusive).

[0438] The x%y modulo operation represents the remainder when x is divided by y, where x and y are both integers and x>=0 and y>0.

[0439] Logical operators

[0440] The logical operators are defined as follows:

[0441] x&&y Boolean logic "AND" operation of x and y

[0442] x||y Boolean logical "OR" operation of x and y

[0443] ! Boolean logic "not" operation

[0444] x? y:z If x is true or not equal to 0, find the value of y; otherwise, find the value of z.

[0445] Relational operators

[0446] The relational operators are defined as follows:

[0447] > greater than

[0448] > = greater than or equal to

[0449] <

[0450] <=less than or equal to

[0451] == is equal to

[0452] ! = not equal to

[0453] When a relational operator is applied to a syntax element or variable that has been assigned the value "na" (not applicable), the value "na" is considered a different value for the syntax element or variable. The value "na" is considered not equal to any other value.

[0454] Bitwise Operators

[0455] The bitwise operators are defined as follows:

[0456] & Bitwise AND operation. When operating on integer arguments, it operates on the two's complement representation of the integer values. When operating on binary arguments, if it has fewer bits than the other argument, the shorter argument is extended by adding more significant bits equal to 0.

[0457] | Bitwise OR operation. When operating on integer arguments, it operates on the two's complement representation of the integer values. When operating on binary arguments, if it has fewer bits than the other argument, the shorter argument is extended by adding more significant bits equal to 0.

[0458] ^ Bitwise XOR operation. When operating on integer arguments, it operates on the two's complement representation of the integer values. When operating on binary arguments, if it has fewer bits than the other argument, the shorter argument is extended by adding more significant bits equal to 0.

[0459] x >> y shifts x arithmetically right by y bit positions in its two's complement integer representation. This function is defined only when y is a non - negative integer value. The result of the right shift is that the bit shifted into the most significant bit (MSB) is equal to the MSB of x before the shift operation.

[0460] x << y shifts x arithmetically left by y bit positions in its two's complement integer representation. This function is defined only when y is a non - negative integer value. The result of the left shift is that the bit shifted into the least significant bit (LSB) is equal to 0.

[0461] Assignment operators

[0462] The definitions of arithmetic operators are as follows:

[0463] = Assignment operator

[0464] ++ Increment, i.e., x++ is equivalent to x = x + 1; when used as an array subscript, the value of the variable is evaluated before the increment operation.

[0465] –– Decrement, i.e., x–– is equal to x = x - 1; when used as an array subscript, the value of the variable is evaluated before the decrement operation.

[0466] += Add a specified value, i.e., x += 3 is equivalent to x = x + 3, and x += (-3) is equivalent to x = x + (-3).

[0467] –= Subtract a specified value, i.e., x -= 3 is equivalent to x = x - 3, and x -= (-3) is equivalent to x = x - (-3).

[0468] Range notation

[0469] The following notation is used to indicate the range of values:

[0470] x=y..zx takes integer values ​​from y to z (including y and z), where x, y and z are integers and z is greater than y.

[0471] Mathematical functions

[0472] The mathematical function is defined as follows:

[0473] Abs(x)={■("x"&";"&"x>=0"@-"x"&";"&"x<0")┤

[0474] Asin(x) is the trigonometric inverse sine function. It operates on the parameter x. When x is in the range of –1.0 to 1.0 (inclusive), the output value is in the range of –π÷2 to π÷2 (inclusive) and the unit is radians.

[0475] Atan(x) is the trigonometric inverse tangent function that operates on the argument x and produces an output value in the range of –π÷2 to π÷2 (inclusive) expressed in radians.

[0476] Atan2(y,x)={■("Atan"("y" / "x")&";"&"x>0"@■("Atan"("y" / "x")+"π"@"Atan"("y" / "x")-π)&■(";" @";")&■("x<0&&y>=0"@"x<0&&y<0")@■(+"π" / "2"@-"π" / "2")&■(";"@";")&■("x==0&&y>=0"@"Other"))┤

[0477] Ceil(x) is the smallest integer greater than or equal to x.

[0478] Clip1Y(x)=Clip3(0,(1< <BitDepthY)–1,x)

[0479] Clip1C(x)=Clip3(0,(1< <BitDepthC)–1,x)

[0480] Clip3(x,y,z)={■("x"&";"&"z<x"@"y"&";"&"z> y"@"z"&";"&"other")┤.

[0481] Cos(x) is the trigonometric cosine function, which operates on the parameter x in radians.

[0482] Floor(x) is the largest integer less than or equal to x.

[0483] GetCurrMsb(a,b,c,d)={■("c"+"d"&";"&"b"-"a>=d / 2"@"c"-"d"&";"&"a"-"b>d / 2"@"c"&";"&"other")┤

[0484] Ln(x) returns the natural logarithm of x (base e logarithm, where e is the base constant 2.718281828…).

[0485] Log2(x) is the base 2 logarithm of x.

[0486] Log10(x) is the base 10 logarithm of x.

[0487] Min(x,y)={■("x"&";"&"x<=y"@"y"&";"&"x>y")┤

[0488] Max(x,y)={■("x"&";"&"x>=y"@"y"&";"&"x <y")┤

[0489] Round(x)=Sign(x)*Floor(Abs(x)+0.5)

[0490] Sign(x)={■("1"&";"&"x>0"@"0"&";"&"x==0"@-"1"&";"&"x<0")┤

[0491] Sin(x) trigonometric sine function, operates on parameter x, in radians.

[0492] Sqrt(x)=√("x")

[0493] Swap(x,y)=(y,x)

[0494] Tan(x) is the trigonometric tangent function that operates on the parameter x in radians.

[0495] Operation priority order

[0496] When parentheses are not used to explicitly indicate the order of precedence in an expression, the following rules apply:

[0497] – Operations with higher priority are evaluated before any operations with lower priority.

[0498] – Operations of the same priority are evaluated from left to right.

[0499] The following table describes the priority of operations from highest to lowest. The higher the position in the table, the higher the priority.

[0500] For operators that are also used in the C programming language, the operator precedence order in this specification is the same as the precedence order in the C programming language.

[0501] Table: Operation priority is sorted from highest (top of table) to lowest (bottom of table)

[0502]

[0503] Text description of the logical operation

[0504] In the text, the following logical operation statements are described in mathematical form:

[0505]

[0506] It can be described in the following way:

[0507] ...as follows / ...the following applies:

[0508] – If condition 0 then statement 0

[0509] – Else If Condition 1 Then Statement 1

[0510] –

[0511] …

[0512] – Otherwise (suggestive explanation about the remaining conditions), then statement n

[0513] Each "if ... else, if ... else, ..." statement in the text is introduced with "... as follows" or "... the following applies" followed by "if ...". The last condition of "if ... else, if ... else, ..." always has an "otherwise, ...". Statements with "if ... else, if ... else" in the middle can be identified by matching "... as follows" or "... the following applies" with the ending "otherwise ...".

[0514] In the text, the following logical operation statements are described in mathematical form:

[0515]

[0516] It can be described in the following way:

[0517] ...as follows / ...the following applies:

[0518] – Statement 0 if all of the following are true:

[0519] –Condition 0a

[0520] – Condition 0b

[0521] – Otherwise, if one or more of the following conditions are met, then statement 1:

[0522] –Condition 1a

[0523] – Condition 1b

[0524] –

[0525] …

[0526] – Otherwise, statement n

[0527] In the text, the following logical operation statements are described in mathematical form:

[0528] if(condition 0)

[0529] statement 0

[0530] if(condition 1)

[0531] statement 1

[0532] It can be described in the following way:

[0533] When condition 0, statement 0

[0534] When condition 1, statement 1.

[0535] Although the embodiments of the present application are mainly described according to video decoding, it should be noted that the embodiments of the decoding system 10, the encoder 20 and the decoder 30 (respectively, the system 10) and other embodiments described herein can also be used for still image processing or decoding, that is, processing or decoding a single image in video decoding that is independent of any previous or continuous images. In general, if the image processing decoding is limited to a single image 17, only the inter-frame prediction unit 244 (encoder) and 344 (decoder) are not available. All other functions (also referred to as tools or techniques) of the video encoder 20 and the video decoder 30 can also be used for still image processing, for example, residual calculation 204 / 304, transformation 206, quantization 208, inverse quantization 210 / 310, (inverse) transformation 212 / 312, segmentation 262 / 362, intra-frame prediction 254 / 354 and / or loop filtering 220 / 320, entropy coding 270 and entropy decoding 304.

[0536] Embodiments of encoders 20 and decoders 30, etc. and the functions described herein with reference to encoders 20 and decoders 30, etc. can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, these functions can be stored as one or more instructions or codes in a computer-readable medium or sent via a communication medium and executed by a hardware-based processing unit. Computer-readable media can include computer-readable storage media corresponding to tangible media (e.g., data storage media), or any communication media that facilitates sending a computer program from one place to another according to a communication protocol, etc. In this way, computer-readable media can generally correspond to (1) non-transient tangible computer-readable storage media, or (2) communication media such as signals or carrier waves. Data storage media can be any available media accessed by one or more computers or one or more processors to retrieve instructions, codes, and / or data structures for implementing the techniques described in the present application. A computer program product can include a computer-readable medium.

[0537] As an example and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory or any other medium that can be used to store the required program code in the form of instructions or data structures and can be accessed by a computer. In addition, any connection can be appropriately referred to as a computer-readable medium. For example, if the instructions are transmitted from a website, server or other remote source via a coaxial cable, optical fiber cable, twisted pair and digital subscriber line (DSL), or wireless technologies such as infrared, radio and microwave, then the coaxial cable, optical fiber cable, twisted pair and DSL, or wireless technologies such as infrared, radio and microwave are also included in the definition of the above medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carriers, signals or other transient media, but rather involve non-transient tangible storage media. Disks and optical disks used herein include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs) and blue-ray discs, wherein disks generally reproduce data magnetically, while optical discs reproduce data optically using lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0538] Instructions can be executed by one or more processors such as one or more digital signal processors (DSP), one or more general-purpose microprocessors, one or more application specific integrated circuits (ASIC), one or more field programmable logic arrays (FPGA) or other equivalent integrated or discrete logic circuits. Therefore, the term "processor" used herein may refer to any of the above structures or any other structure suitable for implementing the techniques described herein. In addition, in some aspects, the various functions described herein may be provided in dedicated hardware and / or software modules for encoding and decoding, or incorporated into a combined codec. In addition, these techniques may be fully implemented in one or more circuits or logic elements.

[0539] The technology in this application can be implemented in a variety of devices or apparatuses, including wireless handsets, integrated circuits (ICs), or a group of ICs (e.g., chipsets). The various components, modules, or units described in this application are intended to emphasize the functional aspects of the apparatus for performing the disclosed technology, but do not necessarily need to be implemented by different hardware units. In fact, as described above, the various units can be combined in a codec hardware unit in combination with appropriate software and / or firmware, or provided by a collection of interoperable hardware units including one or more processors as described above.

[0540] This application discloses the following 21 aspects.

[0541] 1. An aspect of a method for decoding a video or image code stream implemented by a decoding device, wherein the code stream includes data representing a current slice, the method comprising: if an existence condition is satisfied, obtaining a slice address of the current slice from a slice header of the code stream, wherein the existence condition includes that a picture header syntax structure does not exist in the slice header; and reconstructing the current slice according to the slice address of the current slice.

[0542] 2. An aspect of the method according to aspect 1, wherein the picture header syntax structure not existing in the slice header comprises being equal to a syntax element being false, wherein the syntax element being false indicates that the picture header syntax structure does not exist in the slice header.

[0543] 3. An aspect of the method according to aspect 1 or 2, wherein, when the existence condition is not satisfied, the value of the stripe address of the current stripe is inferred to be 0.

[0544] 4. An aspect of a method for decoding a video or image bitstream implemented by a decoding device, wherein the bitstream includes data representing a current slice, the method comprising: if a condition exists, obtaining a parameter for deriving the number of blocks in the current slice from a slice header of the bitstream, wherein the condition exists includes that an image header syntax structure does not exist in the slice header; and reconstructing the current slice according to the number of blocks in the current slice.

[0545] 5. An aspect of the method according to aspect 4, wherein the picture header syntax structure does not exist in the slice header comprises a syntax element being false, wherein the syntax element being false indicates that the picture header syntax structure does not exist in the slice header.

[0546] 6. An aspect of the method according to aspect 4 or 5, wherein, when the existence condition is not satisfied, the value of the parameter of the current strip is inferred to be the total number of blocks in the image where the current strip is located minus 1.

[0547] 7. An aspect of a method for decoding a video or image code stream implemented by a decoding device, wherein the code stream includes data representing a current stripe, the method comprising: if an existence condition is met, obtaining a parameter for deriving the number of blocks in the current stripe from a stripe header of the code stream, wherein the existence condition includes that the stripe address of the current stripe is not the address of the last block in the image where the current stripe is located; and reconstructing the current stripe according to the number of blocks in the current stripe.

[0548] 8. An aspect of the method according to aspect 7, wherein the stripe address of the current stripe is the address of the last block in the image and includes the number of blocks in the image minus the stripe address of the current stripe being equal to 1.

[0549] 9. An aspect of the method according to aspect 7 or 8, wherein, when the existence condition is not satisfied, the value of the parameter of the current slice is inferred as a default value.

[0550] 10. An aspect of the method according to aspect 9, wherein the default value is equal to 0.

[0551] 11. An aspect of a method for decoding a video or image bitstream implemented by a decoding device, wherein the bitstream includes data representing a current slice, the method comprising: if an existence condition is met, obtaining a parameter for deriving the number of blocks in the current slice from a slice header of the bitstream, wherein the existence condition includes that the slice address of the current slice is not the address of the last block in the image where the current slice is located and that an image header syntax structure does not exist in the slice header; and reconstructing the current slice according to the number of blocks in the current slice.

[0552] 12. An aspect of the method according to aspect 11, wherein, when the slice address of the current slice is the address of the last block in the image, the value of the parameter is inferred to be a first default value, or when the image header syntax structure exists in the slice header, the value of the parameter is inferred to be a second default value.

[0553] 13. An aspect of a method for decoding a video or image bitstream implemented by a decoding device, wherein the bitstream includes data representing a current slice, the method comprising: if a condition exists, obtaining a parameter (e.g., slice_lmcs_enabled_flag) from a slice header of the bitstream for indicating whether luminance mapping with chroma scaling is enabled for the current slice, wherein the condition exists including that an image header syntax structure does not exist in the slice header; and reconstructing the current slice according to the number of blocks in the parameter.

[0554] 14. An aspect of the method of clause 13, wherein the picture header syntax structure not being present in the slice header comprises being equal to a syntax element being false, the syntax element being false indicating that the picture header syntax structure is not present in the slice header.

[0555] 15. An aspect of a method for encoding a video or image into a bitstream implemented by an encoding device, wherein the bitstream includes data representing a current slice, and the method includes: if an existence condition is met, including a slice address of the current slice into the bitstream according to a slice header of the bitstream, wherein the existence condition includes that an image header syntax structure does not exist in the slice header; and reconstructing the current slice according to the slice address of the current slice.

[0556] 16. An aspect of a decoder (30), wherein the decoder (30) comprises a processing circuit for performing the method according to any one of aspects 1 to 15.

[0557] 17. An aspect of a computer program product comprising a program code, wherein when the program code is executed on a computer or a processor, the program code is used to perform the method according to any of the above aspects.

[0558] 18. An aspect of a decoder, wherein the decoder comprises:

[0559] One or more processors; a non-transitory computer-readable storage medium coupled to the one or more processors and storing a program executed by the one or more processors, wherein, when the program is executed by the one or more processors, the decoder is used to execute the method described in any one of aspects 1 to 15 above.

[0560] 19. An aspect of a non-transitory computer-readable medium comprising a program code, wherein when the program code is executed by a computer device, the computer device is caused to perform the method according to any one of aspects 1 to 15 above.

[0561] 20. An aspect of an encoded code stream for a video signal by including a plurality of syntax elements, wherein the plurality of syntax elements include picture_header_in_slice_header_flag, and a flag (eg, slice_lmcs_enabled_flag) is conditionally indicated in a slice header based on a value of picture_header_in_slice_header_flag.

[0562] 21. An aspect of a non-transitory recording medium, wherein the non-transitory recording medium includes an encoded code stream decoded by an image decoding device, the code stream being generated by dividing a frame in a video signal or an image signal into a plurality of blocks, the code stream including a plurality of syntax elements, the plurality of syntax elements including rect_slice_flag or sps_num_subpics_minus1, and a flag (e.g., slice_lmcs_enabled_flag) being conditionally indicated in a slice header based on a value of picture_header_in_slice_header_flag.

Claims

1. A method for decoding an image from a video code stream implemented by a decoding device, characterized in that: The code stream includes a slice header of a current slice and data representing the current slice, and the method includes: If the condition is met, obtaining a parameter for deriving the number of blocks in the current stripe from the stripe header, wherein the condition includes: the stripe address of the current stripe is not the address of the last block in the image where the current stripe is located; The current stripe is reconstructed using the number of blocks in the current stripe and the data representing the current stripe.

2. The method according to claim 1, characterized in that The stripe address of the current stripe being the address of the last block in the image includes determining that the number of blocks in the image minus the stripe address of the current stripe is equal to 1.

3. The method according to claim 1, characterized in that The stripe address of the current stripe is not an address of a last block in the image includes determining that a number of blocks in the image minus the stripe address of the current stripe is greater than one.

4. The method according to any one of claims 1 to 3, characterized in that When the condition is not satisfied, the value of the parameter of the current slice is inferred to be a default value.

5. The method according to claim 4, characterized in that The default value is equal to 0.

6. The method according to any one of claims 1 to 5, characterized in that The stripe address is in blocks.

7. The method according to any one of claims 1 to 6, characterized in that The condition also includes: determining that the current strip is in raster scanning mode.

8. The method according to any one of claims 1 to 7, characterized in that The reconstructing the current stripe by using the number of blocks in the current stripe comprises: determining a scanning order of coding tree units in the current stripe by using the number of blocks in the current stripe; and reconstructing the coding tree units in the current stripe by using the scanning order.

9. A device for decoding an image from a video code stream, characterized in that: The code stream includes a slice header of a current slice and data representing the current slice, and the device includes: an acquisition unit, configured to: if a condition is satisfied, acquire from the stripe header a parameter for deriving the number of blocks in the current stripe, wherein the condition includes: a stripe address of the current stripe is not an address of the last block in the image where the current stripe is located; A reconstruction unit is used to reconstruct the current stripe according to the number of blocks in the current stripe and the data representing the current stripe.

10. A decoder (30), characterized in that The decoder (30) comprises a processing circuit for performing a method according to any one of claims 1 to 8.

11. A computer program product comprising program code, characterized in that When the program code is executed on a computer or a processor, the program code is used to execute the method according to any one of claims 1 to 8.

12. A decoder, characterized in that: The decoder comprises: one or more processors; A non-transitory computer-readable storage medium, coupled to the one or more processors and storing a program executed by the one or more processors, wherein when the program is executed by the one or more processors, the decoder is used to perform the method according to any one of claims 1 to 8.

13. A non-transitory computer-readable medium comprising a program code, characterized in that: When the program code is executed by a computer device, the computer device is caused to execute the method according to any one of claims 1 to 8.

Images