RU2790177C1 - Device and method for video encoding and video decoding - Google Patents

Abstract

FIELD: video encoding/decoding.

SUBSTANCE: invention relates to means for video encoding and decoding. A number of blocks to be assigned in sections is determined, which is one of the following: a width of an image in coding tree units (hereinafter – CTU), a height of an image in CTU, a number of CTU rows in a tile. A number of sections of an explicitly set size to be assigned is specified. Sizes of sections of an explicitly set size or a number of blocks in them are specified. A number of sections of an equal size to be assigned is logically obtained. The mentioned logical obtainment of the number of sections of an equal size to be assigned includes: determination of a number of blocks still to be assigned in sections by subtracting a number of blocks in sections of an explicitly set size from a number of blocks to be assigned in sections; assignment of sections to be sections of an explicitly set size in accordance with sizes or a number of blocks in sections of an explicitly set size and in accordance with a preset or specified scanning order, and assignment of sections to be sections of an equal size by dividing blocks still to be assigned in sections by a number of sections of an equal size in accordance with the preset or specified scanning order.

EFFECT: increase in the efficiency of video encoding.

11 cl, 14 dwg

Description

Technical field

[0001] The present invention relates to an apparatus, method, and computer program for video coding and video decoding.

Prerequisites for the creation of the invention

[0002] Video coding standards and specifications generally allow the encoder to divide the encoded image into subsets. In video coding, partitioning may refer to dividing an image, or image sub-region, into subsets (blocks) such that each image element, or image sub-region, is in only one subset (block). For example, the H.265/HEVC standard introduces the concept of a coding tree unit (CTU), which has a default size of 64×64 pixels. A CTU may either contain a single coding unit (CU) or may be recursively split into many smaller coding units, CUs, with a minimum size of 8×8 pixels, in a quadtree. In the H.265/HEVC standard, there are also tiles that are rectangular and contain an integer number of CTUs, as well as slices, which are defined based on slice segments containing an integer number of code tree packets, arranged sequentially in tile scan order, and included in one block NAL.

[0003] Versatile Video Coding (VVC) (MPEG-I Part 3), also known as ITU-T H.266, is a video coding standard being developed by the Joint Video Experts Team (JVET) Moving Picture Experts Group (MPEG) and Video Coding Experts Group (VCEG) of the International Telecommunication Union (ITU) and designed to replace the HEVC/H.265 standard. Partitioning schemes in the VVC standard include not only tiles, but also "bricks" (bricks), which can include one or more CTU lines within a tile. The introduction of bricks also affects the definition of slices.

[0004] As a result, a rather complex syntactic structure was created for signaling various options for splitting into tiles and bricks, which in many respects is not optimal. In particular, this concerns the bitrate required for such signaling.

The essence of the invention

[0005] Further in this document, an improved coding method will be discussed, designed to at least partially solve the problems described above.

[0006] In accordance with the first aspect of the present invention, the method includes encoding, in or along with the bitstream, specifying tile columns and specifying brick heights for one or more tile columns at the same time; logically obtaining, if rows of bricks are found that are on the same line throughout the image, potential rows of tiles; boolean getting or indicating whether a potential tile row boundary is a tile row boundary; and encoding one or more images into a bitstream using the specified tile columns, the specified or inferred tile rows, and the specified brick heights, wherein the one or more images are split into a grid of tiles following the specified tile columns and the specified or inferred tile rows, wherein In this tile in the grid of tiles includes an integer number of code tree packages and is broken into one or more bricks, and the brick contains an integer number of lines of code tree packages within the tile.

[0007] In accordance with the second aspect of the present invention, the method includes the following steps:

a) an indication of the number of partitions to be assigned;

b) determining the number of blocks to be assigned to partitions;

c) an indication of whether the number of blocks to be assigned is assigned evenly to said number of partitions; and if it's not,

d) an indication of the number of blocks to be assigned to the next section, and

e) repeat steps c) and d) until all blocks have been assigned to partitions.

[0008] According to one embodiment of the present invention, said repeated steps c) and d) are performed while the number of partitions still to be assigned remains greater than one.

[0009] In accordance with one embodiment of the present invention, the method further includes determining whether the number of blocks still to be assigned is divisible by the number of partitions still to be assigned; and if so, an indication of whether the number of blocks still to be assigned is evenly assigned to the number of partitions still to be assigned.

[0010] In accordance with one embodiment of the present invention, if it is logically obtained or indicated that the number of blocks still to be assigned is not assignable evenly to the number of partitions still to be assigned, or if the number of blocks still to be assigned , is not evenly divisible by the number of partitions still to be assigned, after step d) perform the following steps:

d1) reducing the number of blocks still to be assigned to partitions by the specified number; And

d2) decrease the number of partitions still to be assigned by one.

[0011] In accordance with one embodiment of the present invention, said sections are one or more of the following: columns of tiles, rows of tiles, rows of bricks in one or more columns of tiles, rows of bricks in a tile.

[0012] According to one embodiment of the present invention, said blocks are rectangular blocks of image samples.

[0013] In accordance with a third aspect of the present invention, the apparatus includes: encoding means, in or along with the bitstream, indicating tile columns and indicating brick heights for one or more tile columns simultaneously; means for logically deriving, in case of detecting lines of bricks that are on the same line throughout the entire image, potential lines of tiles; means for logically obtaining or indicating whether a potential tile row boundary is a tile row boundary; and means for encoding one or more images into a bitstream using specified tile columns, specified or logically derived tile rows and specified brick heights, wherein one or more images are divided into a grid of tiles following the specified tile columns and specified or logically derived tile rows, wherein the tile in the grid of tiles includes an integer number of code tree packages and is broken into one or more bricks, and the brick contains an integer number of lines of code tree packages within the tile.

[0014] According to a fourth aspect of the present invention, the apparatus includes: means for indicating the number of partitions to be assigned; means for determining the number of blocks to be assigned to partitions; means for indicating whether the number of blocks to be assigned is uniformly assigned to said number of partitions; means for indicating that said number of blocks to be assigned is not uniformly assigned to said number of partitions, the number of blocks to be assigned to the next partition, and means for repeating said specifying operations until all blocks have been assigned into sections.

[0015] According to a fifth aspect of the present invention, the method includes: decoding, from or along with the bitstream, specifying tile columns and specifying brick heights for one or more tile columns simultaneously; logical receipt, in case of detection of rows of bricks that are on the same line throughout the entire image, potential rows of tiles; boolean getting or indicating whether a potential tile row boundary is a tile row boundary; and decoding the one or more images from the bitstream using the specified tile columns, the specified or inferred tile rows, and the specified brick heights, wherein the one or more images are split into a grid of tiles following the specified tile columns and the specified or inferred tile rows, wherein In this tile in the grid of tiles includes an integer number of code tree packages and is broken into one or more bricks, and the brick contains an integer number of lines of code tree packages within the tile.

[0016] In accordance with the sixth aspect of the present invention, the method includes the following steps:

a) decoding an indication of the number of partitions to be assigned;

b) determining the number of blocks to be assigned to partitions;

c) determining whether the number of blocks to be assigned is assigned evenly to said number of partitions; and if it's not,

d) determining the number of blocks to be assigned to the next section, and

e) repeat steps c) and d) until all blocks have been assigned to partitions.

[0017] In accordance with a seventh aspect of the present invention, the apparatus includes: means for decoding, from or along with the bitstream, indicating tile columns and indicating brick heights for one or more tile columns simultaneously; means for logically deriving, in case of detecting lines of bricks that are on the same line throughout the entire image, potential lines of tiles; means for logically obtaining or indicating whether a potential tile-row boundary is a tile-row boundary; and means for decoding one or more images from the bitstream using said tile columns, said or inferred tile rows, and said brick heights, wherein the one or more images are split into a grid of tiles following said tile columns and said or inferred tile lines. , wherein the tile in the grid of tiles includes an integer number of code tree packages and is broken into one or more bricks, and the brick contains an integer number of lines of code tree packages within the tile.

[0018] According to an eighth aspect of the present invention, the apparatus includes: means for decoding an indication of the number of partitions to be assigned; means for determining the number of blocks to be assigned to partitions; means for determining whether the number of blocks to be assigned is uniformly assigned to said number of partitions; means for determining, in response to the fact that said number of blocks to be assigned is not uniformly assigned to said number of partitions, the number of blocks to be assigned to the next partition, and means for repeating said determination operations until all blocks have been assigned into sections.

[0019] Additional aspects of the present invention relate to devices including: at least one processor and at least one memory, wherein said at least one memory stores code that, when executed by said at least one processor, causes the device to execute , at least the methods described above and one or more related embodiments of the present invention.

Brief description of the drawings

[0020] For a more detailed understanding of the present invention, it will be described below using the examples shown in the attached drawings, where:

[0021] in FIG. 1 is a schematic illustration of an electronic device in which embodiments of the present invention are applied;

[0022] in FIG. 2 schematically illustrates user equipment suitable for use in embodiments of the present invention;

[0023] in FIG. 3 also schematically illustrates electronic devices in which embodiments of the present invention are applied and which are connected using wired and wireless network connections;

[0024] in FIG. 4 is a schematic illustration of an encoder suitable for implementing some of the embodiments of the present invention;

[0025] in FIG. 5a, 5b, 5c show examples of partitioning an image into code tree packets (CTUs), tiles, bricks, and slices;

[0026] in FIG. 6 shows the syntax for slicing, tiling, and bricking according to version 5 of the H.266/VVC draft (H.266/VVC Draft 5);

[0027] in FIG. 7 is a flowchart for an encoding method in accordance with one embodiment of the present invention;

[0028] in FIG. 8 shows a flowchart for an encoding method in accordance with another aspect of the present invention;

[0029] in FIG. 9 is a flowchart for an encoding method according to one embodiment of the present invention;

[0030] in FIG. 10a, 10b, 10c show examples of partitions into tiles and bricks;

[0031] in FIG. 11 is a schematic block diagram of a decoder suitable for implementing some of the embodiments of the present invention;

[0032] in FIG. 12 is a flowchart for a decoding method according to one embodiment of the present invention;

[0033] in FIG. 13 is a flowchart for a decoding method according to another embodiment of the present invention; And

[0034] in FIG. 14 is a schematic block diagram of an exemplary multimedia communications system in which various embodiments of the present invention may be implemented.

Detailed description of some embodiments of the invention

[0035] The corresponding device and possible mechanisms for initiating browsing port switching will be discussed in more detail below. To this end, let us first turn to Fig. 1 and 2. In FIG. 1 is a block diagram of a video coding system in accordance with one embodiment of the present invention in the form of a block diagram of a typical hardware or electronic device 50 that may include a codec in accordance with one embodiment of the present invention. In FIG. 2 shows a diagram of a device in accordance with one embodiment of the present invention. Next, the elements of FIG. 1 and 2.

[0036] Electronic device 50 may, for example, be a mobile terminal or user equipment of a wireless communication system. However, it should be understood that embodiments of the present invention may be implemented in any electronic device or apparatus that requires encoding and decoding, or only encoding, or only decoding of video images.

[0037] Device 50 may include a housing 30 to house and protect the device. The device 50 may also include a display 32 in the form of a liquid crystal display. In other embodiments of the present invention, said display may be made using any technology suitable for displaying images or video information. Device 50 may also include a keyboard 34. In other embodiments of the present invention, any suitable communications interface or user interface may be used. For example, the user interface may be implemented as a virtual keyboard or input system that is part of a touch display.

[0038] The device may include a microphone 36 or any other suitable audio input device, which may be a digital or analog signal input device. Device 50 may also include an audio output device, which in embodiments of the present invention may be any of the following: a headset 38, a speaker, or an analog or digital audio output connection. The device 50 may also include a battery (or in other embodiments of the present invention, the device may be powered by any suitable mobile energy device, such as a solar panel, fuel cell, or clockwork generator). The device may further include a camera capable of recording, or capturing, images and/or video information. The device 50 may also include an infrared port for communication with other devices in the near field of view. In other embodiments of the present invention, device 50 may include any suitable short range communication solutions, such as a Bluetooth wireless connection or a USB/Firewire wired connection.

[0039] The device 50 may include a controller 56, a processor, or data processing circuits for controlling the device 50. The controller 56 may be connected to a memory 58, which in various embodiments of the present invention may store data, both in the form of video information and audio information, and/or may also store instructions for execution in controller 56. Controller 56 may also be coupled to codec circuits 54 capable of encoding and decoding audio and/or video data, or to assist in encoding and decoding performed by the controller.

[0040] The device 50 may also include a card reader 48 and a smart card 46, such as a UICC card and a UICC card reader, to provide information about the subscriber, and to enable the provision of authentication information to authenticate and authorize the subscriber in the network.

[0041] Device 50 may include air interface circuits 52 associated with a controller that may be used to generate wireless communication signals, such as for communication with a cellular network, a wireless communication system, or a wireless local area network. The device 50 may also include an antenna 44 associated with the air interface circuits 52 for transmitting the RF signals generated in the air interface circuits 52 to another device (or devices), as well as for receiving RF signals from the other device (or devices).

[0042] The device 50 may include a camera capable of recording or registering individual frames, which are then transmitted to the codec 54 or controller for processing. The device may receive video image data from another device for processing before transmission and/or storage. Device 50 may also receive an image for encoding/decoding, either wirelessly or via a wired connection. The structural elements of the device 50 described above are examples of means for performing the respective functions.

[0043] Using FIG. 3 illustrates one example of a system in which various embodiments of the present invention may be used. System 10 includes a plurality of communication devices capable of communicating using one or more networks. System 10 may include any combination of wired and wireless networks, including, but not limited to, wireless cellular telephone network (eg, GSM, UMTS, CDMA, etc.), wireless local area network (WLAN ), for example, as defined in any of the IEEE 802.x standards, a Bluetooth personal area network, an Ethernet local area network, a token ring local area network, a wide area network, and the Internet.

[0044] System 10 may include both wired and wireless communication devices, and/or device 50 suitable for implementing embodiments of the present invention.

[0045] As an example, in FIG. 3 shows a mobile telephone network 11 and the Internet 28. Internet connection 28 may include, but is not limited to, long range wireless connections, short range wireless connections, and various wired connections including, but not limited to, telephone lines. , cable lines, power lines and similar communication channels.

[0046] Examples of communication devices in system 10 include, but are not limited to, electronic device 50, a combination of personal digital assistant (PDA) and mobile phone 14, PDA 16, integrated messaging device 18 (IMD ), desktop computer 20, laptop computer 22. Device 50 may be stationary or mobile when carried by a moving operator. Device 50 may also be placed on a vehicle, including, but not limited to, a car, truck, taxi, bus, train, boat, airplane, bicycle, motorcycle, or any similar suitable vehicle.

[0047] Embodiments of the present invention may also be implemented in a set top box, i. e. in a digital television receiver, which, optionally, may have the functionality of displaying video information and wireless communication, in tablet or (portable) personal computers (PCs), which include a hardware or software (or combined) implementation of an encoder and / or decoder, in various operating systems , in chipsets (chip sets), processors, DSPs and/or embedded systems providing hardware and/or software coding.

[0048] Some of these or other devices can both send and receive calls and messages, as well as communicate with telecom operators using a wireless connection 25 with a base station 24. Base station 24 can be connected to a network server 26 that provides communication between communication means 11 and the Internet 28. The system may include additional communication devices, as well as other types of communication devices.

[0049] Communication devices may communicate using various data transmission technologies, including, but not limited to, code division multiple access (CDMA), global system for mobile communications (Global System for Mobile Communications, GSM), universal Universal Mobile Telecommunication System (UMTS), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Transmission Control Protocol/Internet Protocol (Transmission Control Protocol/Internet Protocol, TCP-IP), Short Messaging Service (SMS), Multimedia Messaging Service (MMS), Email, Instant Messaging Service (IMS), Bluetooth, IEEE 802.11, and any similar wireless technology. The communication device used in implementing various embodiments of the present invention may communicate using various communication media, including, without limitation, radio connections, infrared, laser, cable connections, or any other suitable connection.

[0050] In telecommunications and data networks, a "channel" can be understood to mean either a physical or a logical channel. A physical channel may be any physical medium, such as a wire, while a logical channel may be a logical connection over a multiplexed medium capable of carrying multiple logical channels. A channel may be used to transmit an information signal, such as a bitstream, from one or more senders (or transmitters) to one or more receivers.

[0051] The MPEG-2 transport stream (TS) as defined in ISO/TEC 13818-1, or equivalently in ITU-T Recommendation H.222.0, is a format for transmitting audio, video, and other media data, as well as program metadata or other metadata, in the multiplexed stream. To identify elementary streams (also called packetized elementary streams), packet identifiers (PIDs) are used. Therefore, each logical channel in the MPEG-2 TS stream can be considered to correspond to a particular PID value.

[0052] Existing standards for media file formats include the ISO Base Media File Format (ISO/TEC 14496-12, abbreviated as ISOBMFF) and the NAL Block Structured Video File Format (ISO/IEC 14496-15), which is derived from ISOBMFF.

[0053] The video codec consists of an encoder, by which the input video data is converted into a compressed representation suitable for storage and transmission, and a decoder, by which the compressed representation of the video data is decompressed, returning them to a form suitable for viewing by the user. The video encoder and/or video decoder may also be independent of each other, ie. it is not necessary to generate a codec. As a rule, in the encoder part of the information of the original video sequence is discarded in order to represent the video information in a more compact form (ie, with a lower bit rate).

[0054] Exemplary hybrid video encoders, for example, many of the ITU-T H.263 and H.264 encoder implementations encode video information in two steps. First, pixel values are predicted in a certain region (or "block") of the image, for example, using motion compensation mechanisms (finding an area in one of the pre-encoded video frames that closely matches the block of pixels currently being encoded, and pointing to this region) or using means of spatial prediction (using, in a given way, the pixel values around the encoded block of pixels). The prediction error is then encoded, i. e. the difference between the predicted block of pixels and the original block of pixels. Typically, this is done by transforming the difference of pixel values using a given transform (eg, Discrete Cosine Transform (DCT) or a variant thereof), quantizing its coefficients, and entropy encoding the quantized coefficients. By adjusting the granularity in the quantization procedure, the encoder can control the balance between the fidelity of the pixel representation (image quality) and the size of the resulting encoded video representation (file size or bit rate).

[0055] The source of information for inter prediction are previously decoded pictures (called reference pictures). In intra block copy (IBC), which is also called "intra block copy prediction", prediction is performed similarly to temporal prediction, but the reference picture in this case is the current picture itself, while during decoding, references are allowed only to previously decoded readings. Inter-layer or inter-view prediction can be performed similarly to temporal prediction, however, in this case, the reference will be, respectively, the decoded image from another scalable layer or from another angle. In some cases, extrinsic prediction is understood to mean purely temporal prediction, however, in other cases, extrinsic prediction can generically refer to both temporal prediction and any other types of prediction, namely, intrablock copy, interlayer, and interview prediction, if performed using the same procedure as temporal prediction, or a similar procedure. Inter-prediction or temporal prediction is sometimes referred to as motion compensation or motion-compensated prediction.

[0056] Inter-prediction, which may also be referred to as temporal prediction, motion compensation, or motion-compensated prediction, can reduce temporal redundancy. The source of information for external prediction are previously decoded images. For inter prediction, the fact that adjacent pixels in the same image are highly likely to be correlated is used. The internal prediction to be either spatial or related to the actual transformation, i.e. either pixel values or transform coefficients can be predicted. Intra prediction is typically used in intra coding when inter prediction is not applied.

[0057] One result of the encoding procedure is a set of encoding parameters such as motion vectors and transform coefficients. Entropy encoding of multiple parameters can be more efficient if they are first predicted based on spatially contiguous or temporally adjacent parameters. For example, a motion vector may be predicted based on spatially adjacent motion vectors, and only the difference relative to the motion vector prediction may be encoded. Coding parameter prediction and intra prediction may be collectively referred to as intra prediction.

[0058] FIG. 4 illustrates a block diagram of a video decoder suitable for applying embodiments of the present invention. In FIG. 4 illustrates an encoder for two levels, however, it should be understood that the illustrated encoder can be extended to encode more than two levels. In FIG. 4 illustrates one embodiment of a video encoder including a first encoder segment 500 for a base layer (coding) and a second encoder segment 502 for a refinement layer. Each of the segments, the first encoder segment 500 and the second encoder segment 502, may include similar elements for encoding incoming pictures. Encoder segments 500, 502 may include a pixel predictor 302, 402, a prediction error encoder 303, 403, and a prediction error decoder 304, 404. Also, in FIG. 4 shows one embodiment of a pixel predictor 302,402 including an inter predictor 306,406, an intra predictor 308,408, a mode selector 310,410, a filter 316,416, and a reference frame memory 318,418. The pixel predictor 302 in the first encoder segment 500 receives the base layer images 300 of the encoded video stream simultaneously in the inter predictor 306 (which determines the difference between this picture and the motion compensation reference frame 318) and in the intra predictor 308 (which determines the prediction for a block of image pixels , based only on the already processed parts of the current frame or image). The output from the inter predictor and from the intra predictor is passed to the mode selector 310 . The intra predictor 308 may have more than one intra prediction mode. Therefore, intra prediction can be performed in each of the modes, and the predicted signal can be provided to the mode selector 310. A copy of the base layer image 300 is also passed to the mode selector 310 . Accordingly, the pixel predictor 402 in the second encoder segment 502 receives the refinement level pictures 400 of the encoded video stream simultaneously in the inter predictor 406 (which determines the difference between this picture and the motion compensation reference frame 418) and the intra predictor 408 (which determines the prediction for the block image pixels, based only on the already processed parts of the current frame or image). The output from the inter predictor and from the intra predictor is passed to the mode selector 410 . Intra predictor 408 may have more than one intra prediction mode. Therefore, intra prediction can be performed in each of the modes, and the predicted signal can be provided to the mode selector 410. A copy of the refinement level image 400 is also passed to the mode selector 410 .

[0059] Depending on the encoding mode selected for encoding the current block of pixels, the output of the mode selector 310, 410 is the output of the inter prediction device 306, 406, the output of one of the optional intra prediction modes, or the output of the surface encoder from the mode selector. The output of the mode selector is provided to the first adder 321, 421. The first adder may subtract the output of the pixel predictor 302, 402 from the base level image 300 or the refinement level image 400, respectively, to generate a first prediction error signal 320, 420, which is fed to the input of the prediction error encoder 303, 403 .

[0060] Also, the pixel predictor 302, 402 receives from the pre-recovery device 339, 439 the combination of the predicted representation of the image block 312, 418 and the output data 338, 438 of the prediction error encoder 304, 404. The pre-restored image 314, 414 may be passed to an intra prediction device 308, 408 and a filter 316, 416. In the filter 316, 416 where this pre-representation is received, it may be filtered and a final reconstructed image 340, 440 may be output, which may be stored in memory 318, 418 reference frames. The reference frame memory 318 may be connected to the inter predictor 306 and used as a reference image against which the future base layer image 300 is compared when performing inter prediction operations. Provided that the base layer is selected as the source for inter-layer sample prediction and/or for inter-layer prediction of refinement layer motion information, and if this is also indicated accordingly, in accordance with some of the embodiments of the present invention, the reference frame memory 318 may be connected to the inter prediction device 406 and can be used as a reference image against which the future refinement level image 400 is compared when performing inter prediction operations. In this case, the reference frame memory 418 may be connected to the inter prediction device 406 and used as a reference image with which the future refinement level image 400 is compared when performing inter prediction operations.

[0061] Provided that the base layer is selected as a source for predicting the filter parameters of the refinement layer, and this is indicated accordingly, in accordance with some of the embodiments of the present invention, the filter parameters from the filter 316 of the first segment 500 of the encoder can be transmitted to the second encoder segment 502.

[0062] The prediction error encoder 303, 403 includes a transform block 342, 442 and a quantizer 344, 444. The transform block 342 transforms the first prediction error signal 320, 420 into a transform domain. Such a transformation is, for example, a DCT transformation. The quantizer 344, 444 quantizes the signal, such as the DCT coefficients, in the transform domain and generates the quantized coefficients.

[0063] The prediction error decoder 304, 404 receives the output from the prediction error encoder 303, 403 and performs the inverse procedures of the prediction error encoder 303, 403, resulting in a decoded prediction error signal 338, 438 that, when combined with the predicted representation of the image block 312, 412 in the second adder 339, 439 produces a preliminary reconstructed image 314, 414. The prediction error decoder can be thought of as having a dequantizer 361, 461 that dequantizes the quantized coefficient values, such as the DCT coefficients, and reconstructs the transformed signal, and also as including an inverse transform block 363, 463 that performs an inverse transform on the reconstructed transform signal, wherein the output of the inverse transform block 363, 463 contains the reconstructed block (or blocks). The prediction error decoder may also include a block filter that can filter the reconstructed block (or blocks) according to additional decoded information and filter parameters.

[0064] The entropy encoder 330, 430 receives the output from the prediction error encoder 303, 403 and may perform appropriate variable length encoding and/or entropy encoding of the signal to enable error detection and correction. The output of the entropy encoders 330, 430 may be input to the bit stream, for example, using a multiplexer 508.

[0065] Entropy encoding/decoding can be performed in many different ways. For example, context-sensitive encoding/decoding may be employed, in which both the encoder and the decoder change the context state of the encoding parameters depending on previously encoded/decoded encoding parameters. Examples of context-dependent coding are context-dependent binary arithmetic coding (context adaptive binary arithmetic coding, CABAC), context-dependent coding with variable length codeword (context-based variable length coding, CAVLC) or any similar entropy coding. Entropy coding/decoding, alternatively or in addition, may be performed using variable codeword length coding schemes, such as Huffman coding/decoding or Exponential Golomb coding/decoding. The decoding of encoding parameters from an entropy-encoded bitstream, or from codewords, may be referred to as parsing.

[0066] The H.264/AVC standard was developed by the Joint Video Team (JVT) of the Video Coding Experts Group (VCEG) of the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T). ) and the International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC) Moving Picture Experts Group (MPEG). The H.264/AVC standard was published by both parent organizations standardization and was named ITU-T Recommendation H.264 and International Standard ISO/IEC 14496-10, also known as Advanced Video Coding (AVC), MPEG-4 Part 10. Several versions of the H. 264/AVC, each with new extensions or elements added to the specification. extensions included scalable video coding (Scalable Video Coding, SVC) and multiview video coding (Multiview Video Coding, MVC).

[0067] The Joint Collaborative Team Video Coding (JCT-VC) of the VCEG and MPEG groups created the first version (version 1) of the High Efficiency Video Coding (HEVC) standard, H.265. The standard was published by both parent standards bodies and is currently named ITU-T Recommendation H.265 and International Standard ISO/IEC 23008-2, also known as High Efficiency Video Coding (HEVC), MPEG-H Part 2. Later versions of the H.265/HEVC standard included extensions to scalable multiview coding, fidelity range extension, 3D coding, and screen content coding, which are abbreviated SHVC, MV-HEVC, REXT, 3D-HEVC, and SCC, respectively.

[0068] The SHVC, MV-HEVC, and 3D-HEVC extensions use the common base specification described in Annex F of the second version of the HEVC standard. This common base includes, for example, high-level syntax and semantics, for example, defining part of the bitstream layer characteristics, such as inter-layer dependencies, as well as decoding procedures, such as building a reference picture list including inter-layer prediction reference pictures, as well as computing sequence numbers. images for multilevel streams. Annex F may also apply to future layered HEVC extensions that may come at a later date. In the description below, video encoder, video decoder, coding methods, decoding methods, bitstream structures and/or embodiments of the present invention may be discussed in terms of specific extensions such as SHVC and/or MV-HEVC, however, it should be understood that they, in generally applicable also to layered HEVC extensions, and even more generally to any layered video coding scheme.

[0069] Universal Video Coding (VVC) (MPEG-I Part 3), also known as ITU H.266, is a video compression standard being developed by the Joint Video Experts Team (JVET) of the MPEG Consortium and the ITU to replace the standard. HEVC/H.265.

[0070] This section provides key definitions, describes the structure of the bitstream and encoding, the basic concepts of the H.264/AVC, HEVC and VVC standards, as well as some of their extensions. They are used as an example of a video encoder, decoder, encoding method, decoding method, and bitstream structure in which embodiments of the present invention can be implemented. Aspects of the present invention are not limited to the H.264/AVC, HEVC or VVC standards, and their extensions, on the contrary, this description is provided as one example of a basis for partial or complete implementation of embodiments of the present invention. When reference is made to the VVC standard or draft versions thereof below, it is to be understood that this description corresponds to the specification of one of the VVC draft versions, and there may be changes in later draft versions or the final version (or versions of VVC), in which case the description of the embodiments of this inventions may be adjusted to conform to the final version (or versions) of the VVC standard.

[0071] Video coding standards may define the syntax and semantics of the bitstream, as well as the decoding procedure for error-free bitstreams, while the encoding procedure may not be defined, however, encoders may be required to generate bitstreams that comply with the standard. Compliance of the bitstream and decoder with the standard can be checked using a hypothetical reference decoder (Hypothetical Reference Decoder, HRD). The standard may include coding tools to help deal with errors and transmission loss, but the use of these tools in coding may be optional, and the decoding process for erroneous bitstreams may not be specified.

[0072] A syntax element may be a data element represented in a bitstream. A syntax structure may be referred to as zero or more syntax elements co-located in a bitstream in a given order.

[0073] Each syntax element can be described by the name and one form descriptor of its encoded representation. A convention may be used in which the names of syntax elements consist of lowercase letters with underscores. The behavior of the decoding procedure in the video decoder may be determined by the value of the syntax element and the values of previously decoded syntax elements.

[0074] When describing the H.264/AVCAVC, HEVC, and VCC standards, as well as various embodiments of the present invention, the following notation can be used to define the procedure for parsing syntax elements.

- u(n): unsigned integer using n bits. If n is equal to "v" in the syntax table, then the number of bits changes depending on the value of other syntax elements. The parsing procedure for this descriptor is determined by the next n bits in the bitstream, which are interpreted as the binary representation of an unsigned integer, the most significant bit of which comes first.

- ue(v): syntax element as an unsigned integer encoded with exponential Golomb code (exp-Golomb), where the most significant bit is on the left.

[0075] A bit string encoded with the exponential Golomb code can be converted to a code number (codeNum), for example, using the following table:

[0076] In some cases, the syntax tables may use the values of other variables calculated based on the values of the syntax elements. A variable naming convention that uses combinations of lowercase and uppercase letters without underscores may be used. Variables starting with an uppercase letter can be evaluated to decode the current syntax structure and all syntax structures dependent on it. Variables beginning with an uppercase letter may be used in the decoding process of subsequent syntactic structures without mentioning the original syntactic structure of the variable. A convention may be applied whereby variables beginning with a lowercase letter are used only in the context of their evaluation.

[0077] In some cases, "mnemonic" names for the values of syntax elements or variables are used interchangeably with their numerical values. Sometimes "mnemonic" names are used without any corresponding numerical values.

[0078] A flag is a variable or one-bit syntax element that has one of two possible values: 0 or 1.

[0079] Arrays can be both syntax elements and variables. Array indices can use square brackets. A one-dimensional array can be called a list. A two-dimensional array may be called a matrix.

[0080] Functions may be described by their names. A convention may be used whereby function names begin with uppercase letters, contain a combination of lowercase and uppercase letters without underscores, and end with left and right brackets enclosing zero or more variable names (to be defined) or values (to be used), separated by commas (if there is more than one variable).

[0081] The Ceil(x) function can be defined as returning the smallest integer greater than or equal to x. The function Log2(x) can be defined as returning the logarithm of x to base 2.

[0082] Procedures can be defined for describing the decoding of syntax elements. A procedure can have an independent description and call. It may be specified that all uppercase syntax elements and variables relating to the current syntax structure and all syntax structures dependent on it are available in the procedure declaration and when it is called, and it may also be specified that the procedure declaration may have variables with name in lower case, explicitly specified as input. The declaration of any procedure may explicitly define one or more output variables, each of which may be either an uppercase variable or a lowercase variable.

[0083] Syntax, semantics, and procedures can be defined using arithmetic, logical, relational, bitwise, and assignment operators similar to those used in the C programming language. In particular, the / operator is used to indicate integer division (with rounding), and the operator % is used to indicate modulo division (i.e. taking the remainder of a division).

[0084] The numbering and counting conventions used may be zero-based, eg, "first" may be equivalent to 0, "second" may be equivalent to 1, and the like.

[0085] The elementary unit for input to the decoder and output from the decoder, respectively, is usually an image. The image supplied as input to the encoder may be referred to as the original image, and the image decoded by the decoder may be referred to as the decoded or reconstructed image.

[0086] The original and decoded images each consist of one or more arrays of samples, for example, one or more of the following sets of arrays of samples:

- only the luminance component (Y) (monochrome image),

- luma component and two chrominance components (YCbCr or YCgCo),

- components of green, blue and red (GBR or RGB),

- arrays representing other undefined monochrome or three-component color samples (eg YZX, also called XYZ).

[0087] Hereinafter, such arrays are referred to as luminance (or L, or Y) components and chrominance components, with the two chrominance arrays being referred to as Cb and Cr; regardless of the actual method used to represent color information. The actual color information representation method used may, for example, be indicated in the bitstream, for example, using the Video Usability Information (VUI) syntax in the HEVC standard or another standard. A component can be defined as an array of samples, or a single sample, from one of three report arrays (one luma and two chrominance), or as an array of samples, or a single sample, from an array forming a monochrome image.

[0088] An image can be defined as either a frame or a field. The frame includes an array of luma samples, and possibly also corresponding chrominance samples. A field is a set of alternating lines of samples in a frame and can be used as input to an encoder when the source signal is interlaced. Chroma sample arrays may be missing (and therefore monochrome values may be used), or chroma sample arrays may have a reduced resolution compared to luminance sample arrays.

[0089] Some of the chroma representation formats are briefly described below.

- When sampling in monochrome format, there is only one array of samples, which, by definition, is considered an array of brightness.

- When sampled at 4:2:0, each of the two chrominance arrays is half the height of the luma array and half its width.

- When sampling with a 4:2:2 format, each of the two chroma arrays has the same height as the luma array, but half the width.

- When sampling with a 4:4:4 format, if separate color planes are not used, each of the two chrominance arrays is the same height and width as the luma array.

[0090] Encoding formats or standards may allow arrays of samples to be encoded as separate color planes in a bitstream, and accordingly, individually encoded color planes from the bitstream may be decoded. If separate color planes are used, each of them is processed separately (in the encoder and/or decoder) as an image with a monochrome representation.

[0091] Partitioning is such a division of a set into subsets, in which each of the elements of the set is in only one of the subsets. In video coding, partitioning may refer to dividing an image, or image sub-region, into subsets such that each image element, or image sub-region, is in exactly one subset. For example, when splitting according to HEVC encoding and/or decoding and/or VVC encoding and/or decoding, the terms described below may be used. A coding block is a block of samples of size NxN, for some value of N, such that dividing the coding tree block into coding blocks is a split. A coding tree block (CTB) is a block of samples of size NxN, for some value of N, such that dividing the image component into coding tree blocks would be a split. A coding tree unit (CTU) is a luminance sample coding tree unit, two corresponding chrominance sample coding tree units in the case of an image having three sample arrays, or a coding tree block in a monochrome image, or an image that is encoded with using three separate color planes and syntactic structures used to encode samples. A coding unit (CU) is a luminance sample coding unit, two corresponding chrominance sample coding units for an image having three arrays of values, a monochrome image sample coding unit, or an image that is encoded using three separate color planes, and syntactic structures used to encode samples. The coding unit, CU, of the maximum allowable size is usually called LCU (largest coding unit, largest coding unit) or code tree packet (CTU), while the image in the video is divided into non-overlapping LCUs.

[0092] In the HEVC standard, each of the code blocks, CU, consists of one or more prediction units (PU) that define the procedure for predicting samples in the coding block, as well as one or more transform units (TU) that define a prediction error coding procedure for the samples in that coding block. Typically, a coding block, CU, consists of a square block of samples, the size of which is chosen from a predetermined set of allowable code block sizes. Each prediction block, PU, and transform unit, TU, may be partitioned into smaller prediction blocks and transform blocks in order to improve the accuracy of prediction procedures and prediction error coding, respectively. Each prediction block, PU, has prediction information associated with it that determines what type of prediction should be applied to the pixels of that prediction block (e.g., motion vector information in the case of an inter prediction block, or intra prediction direction information in the case of an intra prediction block). predictions).

[0093] Similarly, each transform block may be associated with information describing a procedure for decoding a prediction error for values in that transform block (including, for example, information about DCT transform coefficients). Whether or not prediction error coding is applied for each code block, CU, is typically signaled in syntax elements at the coding block level. If there is no residual or prediction error associated with a coding unit, CU, then it can be considered that there are no transform units, TU, for that coding unit. The information about dividing the image into coding units, CU, and about dividing the coding units into prediction units, PU, and transformation units, TU, signaled generally in the bit stream, allows the decoder to reproduce the given structure of these blocks.

[0094] The partitioning used in the draft H.266/VVC standard is described below. It should be noted that what is described here is subject to change in later versions of the H.266/WC draft until the standard is finalized. Images are split into CTUs similar to HEVC, but the maximum CTU size is increased to 128x128. The Code Tree Packet (CTU) is first split according to the quadtree structure. The vertices of the quadtree can then be further subdivided into tree structures of various types. Among these multi-type tree structures, there are four types of partitions: vertical binary partition, horizontal binary partition, vertical ternary partition, and horizontal ternary partition. Such multitype tree nodes are called coding units (CUs). The coding units, CU, the prediction units, PU, and the transform units, TU, have the same block size, unless the coding unit exceeds the maximum transform length. The segmentation structure of the CTU is a quadtree with nested multitype trees that use binary and ternary division, i.e. do not apply separate special block models CU, PU and TU, except when necessary for coding blocks with a size exceeding the maximum transformation length. The coding unit, CU, may be square or rectangular.

[0095] The unit of output from encoders in some coding formats, such as VVC, and input to a decoder, in some coding formats, such as VVC, is the Network Abstraction Layer (NAL) block. NAL units may be encapsulated in packets or similar structures for the purpose of transmission over packet data networks or storage in structured files.

[0096] The bitstream format for streams from NAL units may be defined for transmission or storage media that do not provide a frame structure. In such bitstream formats, NAL units are separated from each other by attaching a start code before each NAL unit. To avoid false detection of NAL unit boundaries, encoders run a start code emulation prevention byte algorithm that adds an emulation prevention byte to the NAL unit payload if the start code would otherwise be present. In order to provide transparent gateway communication between packet and streaming systems, start code emulation prevention must be performed in any case, regardless of whether the bitstream format is used or not.

[0097] A NAL unit is a syntax structure containing an indication of the type of data that follows it, and bytes containing this data in the form of RBSP, interleaved, if necessary, with emulation prevention bytes. A raw byte sequence payload (RBSP) sequence can be defined as a syntax structure that includes an integer number of bytes and is encapsulated in a NAL unit. The RBSP sequence may be either empty or in the form of a string of information bits containing syntax elements followed by an RBSP stop bit and zero or more subsequent bits equal to 0.

[0098] NAL units consist of a header and a payload. The NAL unit header indicates, among other information, the type of the NAL unit.

[0099]

[0100] NAL units can be divided into two categories: Video Coding Layer (VCL) NAL units and non-VCL NAL units. VCL NAL units are NAL units with standard slice coding.

[0101] A non-VCL NAL unit may, for example, be one of the following types: sequence parameter set, image parameter set, supplemental enhancement information (SEI) NAL unit, access unit delimiter, end of sequence NAL units, end of NAL unit bitstream, or NAL unit with filtering data. A set of parameters may be needed to recover decoded pictures, while many of the other types of non-VCL NAL units are not needed to recover decoded pictures.

[0102] In some coding formats, parameter sets are defined that may contain parameter values necessary for decoding or restoring decoded pictures. A parameter may be defined as a syntax element in a parameter set. A parameter set may be defined as a syntax structure that contains parameters and that can be referenced from other syntax structures, or that can be activated from other syntax structures, for example by an identifier.

[0103] Some of the parameter set types are described below, however, it should be understood that others may exist, and that embodiments of the present invention can be applied to, but are not limited to, the described parameter set types. A sequence parameter set (SPS) may include parameters that remain the same throughout the encoded video sequence. In addition to parameters that may be needed during the decoding process, the sequence parameter set may optionally include video usability information (VUI), including parameters important for buffering, image output timing, rendering, and resource reservation. A picture parameter set (PPS) contains parameters that are likely to be the same across multiple encoded pictures. The picture parameter set may include parameters that may be referenced from segments of one or more encoded pictures. The header parameter set (HPS) was introduced to include parameters that can change for each individual image.

[0104] A bitstream is a sequence of bits, which, in some formats or coding standards, may be in the form of a stream of NAL units or a stream of bytes, which allows you to get the representation of encoded images and associated data in the form of one or more encoded video sequences. In one logical channel, for example, in one file or one communication protocol connection, the first bit stream may be followed by the second bit stream. An elementary stream (in the context of video coding) is a sequence of one or more bit streams. In some formats or coding standards, the end of the first bitstream may be indicated by a special NAL unit, which may be called an end of bitstream (EOB) NAL unit, which is the last NAL unit of the bitstream.

[0105] A bitstream part is a contiguous subset of the bitstream. In some contexts, there may be a requirement that a portion of the bitstream consist of one or more complete syntax structures and not have incomplete syntax structures. In other contexts, a portion of a bitstream may include any contiguous portion of the bitstream and may include incomplete syntactic structures.

[0106] The expression “along with the bitstream” (e.g., “indication along with the bitstream”) or “along with the bitstream coding unit” (e.g., “indication along with the encoded tile”) can be understood, in the claims and in describing embodiments of the present invention as transmitting, signaling, or storing data outside the baseband such that the non-baseband data remains associated with, but not included in, the bitstream or code block, respectively. The expression "decoding along with the bitstream", or "alongside the bitstream coding block", or similar expressions, may refer to the decoding of non-baseband data that is referenced (and that can be obtained by transmission, signaling or storage data outside the baseband) and which are associated with a bitstream or a code block, respectively. For example, the phrase "along with the bitstream" can be used when the bitstream is contained in a container file, such as a file conforming to the ISO Base Media File Format, and the file's metadata is stored in the file in such a way that it is associated with the bitstream, such as in as boxes in a sample record for a track containing a bitstream, a group of samples for a track containing a bitstream, or a synchronized metadata track associated with a track containing a bitstream.

[0107] A coded video sequence (CVS) is a sequence of coded pictures in decoding order that is independently decodable and is followed by another coded video sequence or the end of a bitstream. An encoded video sequence, alternatively or additionally, may be defined as ending when a special NAL unit is encountered in the bitstream, which may be referred to as an end of sequence (EOS) NAL unit.

[0108] Images may be partitioned into independently encoded and decoded image segments (eg, slices and/or tiles and/or groups of tiles). Such image segments allow for parallel processing. Slices are herein referred to as image segments consisting of a given number of basic coding units that are processed in a default encoding or decoding order, while tiles are generally referred to as image segments defined as rectangular image areas arranged on a grid of tiles. A group of tiles is a group of one or more tiles. Image segments in a bitstream may be encoded as separate blocks, such as VCL NAL blocks in H.264/AVC, HEVC and VVC standards. The encoded picture segments may include a header and a payload, where the header contains parameter values needed to decode the payload. The payload of slices is called slice data.

[0109] In the HEVC standard, an image can be divided into tiles that are rectangular in shape and contain an integer number of LCUs. In the HEVC standard, tiling results in a regular grid in which the maximum difference between the height and width of the tiles is equal to one LCU. In the HEVC standard, a slice is defined as the integer number of code tree packets contained in one independent slice segment and all subsequent dependent slice segments (if present) that precede the next independent slice segment (if any) within one access block. In the HEVC standard, a slice segment is defined as an integer number of code tree packets organized as a sequence, in tile scan order, and contained in one NAL unit. Dividing each of the images into slice segments is a partition. In the HEVC standard, an independent slice segment is defined as a slice segment for which the values of the syntax elements in the slice segment header are not derived from the values of the previous slice segment, and a dependent slice segment is defined as a slice segment for which the values of some of the syntax elements in the slice segment header are derived from based on the values for the previous independent slice segment in decoding order. In the HEVC standard, a slice header is defined as the header of an independent slice segment that is current, or as a header of an independent slice segment that precedes the current dependent slice segment, and the slice segment header is defined as part of the encoded slice segment including the data elements that belong to the first block. (or all blocks) of the code tree represented (or represented) in the slice segment. The coding units, CUs, are scanned in LCU raster scan order in tiles, or in the overall image if no tiles are used. In an LCU, coding units, CUs, may have a predetermined scan order.

[0110] Accordingly, the video coding standard and specifications may allow the division, at the encoder, of the encoded image into encoded slices or similar elements. Intra-image prediction that crosses slice boundaries is generally not allowed. Therefore, slices can be thought of as a way of dividing an encoded image into independently decodable parts. In the H.264/AVC and HEVC standards, intra-picture prediction that crosses slice boundaries may be prohibited. Accordingly, slices can be thought of as a way of dividing an encoded picture into independently decodable portions, and hence slices are often considered to be elementary units of transmission. In many cases, encoders can indicate in the bitstream which types of intra slice boundary prediction are prohibited, and the decoder takes this information into account in its work, for example, inferring available prediction sources. For example, samples from adjacent coding blocks may be considered unavailable for intra prediction if these coding blocks are located in different slices.

[0111] The following describes the partitioning of images into slices, tiles and bricks in the draft VVC standard (ie, version 5 of the VVC draft).

[0112] The image is divided into one or more rows of tiles and one or more columns of tiles. Dividing the image into tiles forms a grid of tiles, which can be characterized by a list of tile column widths (in CTU) and a list of tile row heights (in CTU).

[0113] A tile is a sequence of code tree packets (CTUs) that covers one "cell" in a grid of tiles, i.e. rectangular area of the image. A tile is broken into one or more bricks, each of which consists of a set of CTU rows within that tile. A tile that is not divided into many bricks is also called a brick. However, a brick that is a true subset of a tile is not called a tile.

[0114] A slice contains either a set of image tiles or a set of tile bricks. A slice is a VCL NAL unit.

[0115] Two slice modes are supported, namely a raster scan slice mode and a rectangular slice mode. In raster-scan slice mode, a slice contains a sequence of tiles in the order in which the image's tiled raster was scanned. In rectangular slice mode, a slice contains a set of image bricks that together form a rectangular image area. The bricks in a rectangular slice are arranged in the order in which the slice's brick raster is scanned.

[0116] A brick scan order can be defined as the specific order of consecutive CTUs into which images are broken, where CTUs within a brick are sequential in CTU raster scan order, bricks in a tile are sequential in tile brick raster scan order, and tiles in images are arranged sequentially in the order of scanning the raster of image tiles. It may be required, for example, in an encoding standard, that coded slice NAL units must be arranged in ascending order of CTU address in brick scan order for the first CTU of each coded slice NAL unit, it may be determined that the CTU address is incremented in order to scan the CTU raster within the image. A raster can be defined as a mapping of a rectangular 2D structure onto a 1D structure such that the first entries in the 1D structure are from the top first row of the 2D structure, scanned from left to right, followed by the second, third, and so on. structure lines (in the downward direction), each of which is scanned from left to right.

[0117] In FIG. 5a shows an example of image slicing in raster scan mode, where the image is sliced into 12 tiles and 3 slices in raster scan mode. In FIG. 5b shows an example of partitioning an image into rectangular slices (with a size of 18×12 CTU), where the image is partitioned into 24 tiles (6 columns of tiles and 4 rows of tiles) and 9 rectangular slices. In FIG. 5c shows an example of splitting an image into tiles, bricks and rectangular slices, where the image is split into 4 tiles (2 columns of tiles and 2 rows of tiles), 11 bricks (the top left tile contains 1 brick, the top right tile contains 5 bricks, the bottom left tile contains 2 bricks, and the bottom right tile contains 3 bricks) and 4 rectangular slices.

[0118] Tiling, bricking, and rectangular slicing is specified in a Picture Parameter Set (PPS). In FIG. 6 shows the syntax for specifying tiling and bricking, which is performed in two stages: at the first stage, a grid of tiles is formed (i.e., the width of the columns of tiles and the height of the rows of tiles), and then these tiles are further broken into bricks.

[0119] There are two modes for setting the grid of tiles: uniform (indicated using the uniform_tile_spacing_flag syntax element equal to 1) and explicit. With uniform tile spacing, they have the same width, with the possible exception of the rightmost tile column, and the same height, with the possible exception of the bottommost row of tiles. In an explicitly specified tile step, the width and height of the columns and rows of tiles (respectively) (in CTU units) are specified explicitly, with the exception of the rightmost column and the bottommost row (respectively).

[0120] Similar to specifying a grid of tiles, there are two modes of specifying how a tile is broken into bricks, i. for each tile, either a uniform brick spacing or an explicitly specified brick spacing can be specified. Signaling is similar to tile lines.

[0121] When using rectangular slices, then for each slice, using a syntax structure (including and) following the syntax element num_slices_in_pic_minusl, indicate the following:

- index of the upper left brick (except for the first slice, for which the index is taken equal to 0),

- the difference between the indices of the lower right brick of the slice and the upper left brick.

[0122] The semantics of the syntax elements shown in FIG. 6 is defined in version 5 of the VVC project as follows:

[0123] The flag single_tile_in_pic_flag equal to 1 specifies that there is only one tile in each image referring to a given PPS set. The single_tile_in_pic_flag flag, equal to 0, specifies that there is more than one tile in each image that refers to this PPS set. Note: In the absence of additional bricking within a tile, the entire tile is called a brick. When an image contains only a single tile, with no bricking, it is considered a single brick. Bitstream compatibility requires that the value of single_tile_in_pic_flag be the same for all PPSs enabled within CVS.

[0124] A uniform_tile_spacing_flag of 1 specifies that the tile column boundaries as well as the tile row boundaries are evenly spaced across the image. They are signaled using the tile_cols_width_minusl and tile_rows_height_minusl syntax elements. A uniform_tile_spacing_flag of 0 specifies that tile column boundaries, as well as tile row boundaries, are not necessarily evenly spaced across the image. They are signaled by the syntax elements num_tile_columns_minusl and num_tile_rows_minusl and the list of pairs of syntax elements tile_column_width_minusl[i] and tile_row_height_minusl[i]. If it is absent, the value of the uniform_tile_spacing_flag flag is set to 1.

[0125] The value of tile_cols_width_minusl plus 1 specifies the width of the tile columns, excluding the rightmost column of tiles in the image, measured in CTB when the uniform_tile_spacing_flag flag is 1. The value of tile_cols_width_minusl must be in the range 0 to PicWidthInCtbsY - 1 inclusive. If it is absent, the value of tile_cols_width_minusl is taken equal to PicWidthInCtbsY - 1.

[0126] The value of tile_rows_height_minusl plus 1 determines the height of the rows of tiles, excluding the lowest row of tiles in the image, measured in CTB when the uniform_tile_spacing_flag flag is 1. The value of tile_rows_height_minusl must be in the range 0 to PicHeightInCtbsY - 1 inclusive. If it is absent, the tile_rows_height_minusl value is taken equal to PicHeightInCtbsY - 1.

[0127] The value of num_tile_columns_minusl plus 1 determines the number of tile columns into which the image is broken when the uniform_tile_spacing_flag flag is 0. The value of num_tile_columns_minusl must be in the range 0 to PicWidthInCtbsY - 1 inclusive. If single_tile_in_pic_flag is 1, then num_tile_columns_minusl is set to 0. Otherwise, when uniform_tile_spacing_flag is 1, num_tile_columns_minusl is set to the value specified in the CTB raster scan, tile scan, and brick scan procedure.

[0128] The value of num_tile_rows_minusl_plus 1 determines the number of tile rows into which the image is split when the uniform_tile_spacing_flag flag is 0. The value of num_tile_rows_minusl must be in the range 0 to PicHeightInCtbsY - 1 inclusive. If single_tile_in_pic_flag is 1, num_tile_rows_minusl is set to 0. Otherwise, when uniform_tile_spacing_flag is 1, num_tile_rows_minusl is set to the value specified in the CTB raster scan, tile scan, and brick scan procedure. The NumTilesInPic variable is set to (num_tile_columns_minusl + 1) * (num_tile_rows_minusl + 1). When single_tile_in_pic_flag is 0, NumTilesInPic must be greater than 1.

[0129] The value of tile_column_width_minusl[i] plus 1 specifies the width of the i-th tile column, measured in CTB.

[0130] The value of tile_row_height_minusl[i] plus 1 determines the height of the i-th row of tiles, measured in CTB.

[0131] The flag brick_splitting_present_flag equal to 1 specifies that one or more image tiles referring to this PPS can be split into two or more bricks. The brick_splitting_present_flag flag of 0 specifies that none of the image tiles referencing this PPS may be split into two or more bricks.

[0132] The flag brick_split_flag[i] equal to 1 specifies that the i-th tile is split into two or more bricks. The brick_split_flag[i] flag equal to 0 specifies that the i-th tile is not split into two or more bricks. In case of its absence, the brick_split_flag[i] value is taken equal to 0.

[0133] A uniform_brick_spacing_flag[i] flag of 1 specifies that the horizontal brick boundaries are evenly spaced across the i-th tile column and signaled using the brick_height_minusl[i] syntax element. The uniform_brick_spacing_flag[i] flag of 0 specifies that the horizontal brick boundaries are not necessarily evenly spaced over the i-th tile and are signaled using the num_brick_rows_minusl[i] syntax element and the brick_row_height_minusl[i][j] syntax element list. If it is absent, the value of the uniform_brick_spacing_flag[i] flag is taken equal to 1.

[0134] The brick_height_minusl[i] value plus 1 determines the height of the rows of bricks, excluding the bottom brick in the i-th tile, measured in CTB when the uniform_brick_spacing_flag[i] flag is 1. If present, the brick_height_minusl value must be in the range of 0 up to RowHeight[i] - 2 inclusive. If it is absent, the brick_height_minusl[i] value is taken equal to RowHeight[i] - 1.

[0135] The value of num_brick_rows_minusl[i] plus 1 determines the number of bricks into which the i-th tile is broken when the flag uniform_brick_spacing_flag[i] is 0. If present, the value of num_brick_rows_minusl[i] must be in the range from 1 to RowHeight[i ] - 1 inclusive. If the brick_split_flag[i] flag is equal to 0, the value of num_brick_rows_minusl[i] is taken equal to 0. Otherwise, when the brick_split_flag[i] flag is equal to 1, the value of num_brick_rows_minusl[i] is taken equal to that specified in the CTB raster scan procedure, tile raster scan and scanning a raster of bricks.

[0136] The value of brick_row_height_minusl[i][j] plus 1 specifies the height of the j-th brick in the i-th tile column, measured in CTB, when the uniform_tile_spacing_flag is 0.

[0137] The following variables are calculated, and when the uniform_tile_spacing_flag flag is equal to 1, the values num_tile_columns_minusl and num_tile_rows_minusl are obtained logically, and for each i in the range from 0 to NumTilesInPic - 1 inclusive, when the flag uniform_brick_spacing_flag[i] is equal to 1, the value num_brick_rows_minusl[i] are obtained logically by calling the CTB raster scan procedure, tile scan and brick scan:

- list RowHeight[j] for j in the range from 0 to num_tile_rows_minusl inclusive, defining the height of the j-th row of tiles, measured in CTB,

- list CtbAddrRsToBs[ctbAddrRs] for ctbAddrRs in the range from 0 to PicSizeInCtbsY - 1 inclusive, defining the conversion from the CTB address when scanning the CTB image raster to the CTB address when scanning bricks,

- list CtbAddrRsToBs[ctbAddrRs] for ctbAddrRs in the range from 0 to PicSizeInCtbsY - 1 inclusive, defining the conversion from the CTB address when scanning the CTB image raster to the CTB address when scanning bricks,

- the BrickId[ctbAddrBs] list for ctbAddrBs in the range from 0 to PicSizeInCtbsY - 1 inclusive, defining the conversion from the CTB address when scanning bricks to the brick identifier (ID),

- list NumCtusInBrick[brickIdx] for brickIdx in the range from 0 to NumBricksInPic - 1 inclusive, defining the conversion from the brick index to the number of CTUs in this brick,

- List FirstCtbAddrBs[brickIdx] for brickIdx in the range from 0 to NumBricksInPic - 1 inclusive, defining the conversion from brick ID to CTB address when scanning bricks for the first CTB inside the brick.

[0138] The flag single_brick_per_slice_flag equal to 1 specifies that each slice referring to a given PPS set contains one brick. The single_brick_per_slice_flag flag of 0 specifies that each slice referring to this PPS set may contain more than one brick. If it is absent, the value of single_brick_per_slice_flag is taken equal to 1.

[0139] The rect_slice_flag flag of 0 specifies that the bricks in all slices are arranged in raster scan order, and slice information is not signaled in the PPS set. The rect_slice_flag flag of 1 specifies that the bricks in all slices cover a rectangular area of the image, and slice information is signaled in the PPS set. When the single_brick_per_slice_flag is 1, the rect_slice_flag is set to 1.

[0140] The number num_slices_in_pic_minusl plus 1 determines the number of slices in each image referring to a given PPS set. The value of num_slices_in_pic_minusl must be between 0 and NumBricksInPic - 1 inclusive. When this value is absent and the single_brick_per_slice_flag is 1, the value of num_slices_in_pic_minusl is set to NumBricksInPic - 1.

[0141] The top_left_brick_idx[i] value specifies the index of the brick located in the upper left corner of the i-th slice. top_left_brick_idx[i] must not be equal to top_left_brick_idx[j] for any i that is not equal to j. When absent, top_left_brick_idx[i] is set to i. The length of the top_left_brick_idx[i] syntax element is Ceil(Log2(NumBricksInPic) bits.

[0142] The bottom_right_brick_idx_delta[i] value defines the difference between the index of the brick located in the lower right corner of the i-th slice and top_left_brick_idx[i]. When the single_brick_per_slice_flag is 1, the value of bottom_right_brick_idx_delta[i] is set to 0. The length of the bottom_right_brick_idx_delta[i] syntax element is Ceil(Log2(NumBricksInPic - top_left_brick_idx[i])) bits.

[0143] For bitstream compatibility, there is a requirement that a slice must include either a set of full tiles or a sequence of full bricks of the same tile. The variables NumBricksInSlice[i] and BricksToSliceMap[j], which determine the number of bricks in the i-th slice, as well as the correspondence of bricks to slices, are obtained as follows:

[0144] So, to signal the division into tiles and bricks, a rather complex syntactic structure has been created. It is suboptimal in many aspects, for example, in terms of the number of syntax elements, syntax lines, the number of modes of operation (i.e. separate uniform mode and explicit mode for both tiles and bricks, as well as a separate specification of the boundaries of tiles and bricks), and also with respect to signaling bit volume.

[0145] Improved methods for tiling and bricking signaling will be presented below.

[0146] An encoding method according to the first aspect of the present invention, which is illustrated in FIG. 7 includes encoding (700) a bitstream including specifying tile columns and specifying brick heights for one or more tile columns at the same time, or encoding, in or along with the bitstream, specifying tile columns and specifying brick heights for one or more tile columns simultaneously; logically obtaining (702), in case of detecting rows of bricks that are on the same line throughout the entire image, potential rows of tiles; logically getting (704) or indicating whether a potential tile row boundary is a tile row boundary; and encoding (706) one or more images into a bitstream using the specified tile columns, the specified or logically derived tile rows, and the specified brick heights, wherein the one or more images are split into a grid of tiles following the specified tile columns and the specified or logically derived rows tiles, wherein a tile in the tile grid includes an integer number of code tree packages and is broken into one or more bricks, and the brick contains an integer number of lines of code tree packages within the tile.

[0147] The decoding method according to the first aspect of the present invention includes decoding, from or along with the bitstream, indicating tile columns and indicating brick heights for one or more tile columns simultaneously; logical receipt, in case of detection of rows of bricks that are on the same line throughout the entire image, potential rows of tiles; logically deriving or decoding whether a potential tile-row boundary is a tile-row boundary; and decoding the one or more images from the bitstream using the specified tile columns, the specified or inferred tile rows, and the specified brick heights, wherein the one or more images are split into a grid of tiles following the specified tile columns and the specified or inferred tile rows, wherein In this tile in the grid of tiles includes an integer number of code tree packages and is broken into one or more bricks, and the brick contains an integer number of lines of code tree packages within the tile.

[0148] That is, the tile columns and brick heights for each tile column are specified by the encoder and/or decoded by the decoder. Potential tile row boundaries are logically derived as the boundaries of bricks that are on the same (horizontal) line throughout the image. That is, for a potential tile-row boundary, it can be concluded that this potential tile-row boundary is a valid tile-row boundary. The logical conclusion that a potential tile-row boundary is an actual tile-row boundary can be based on inferences drawn from other information available in the syntax structure, or based on the absence of some information in the syntax structure, such as the absence of some flag. .

[0149] Alternatively, whether a potential tilestring boundary is a real tilestring boundary may be indicated by the encoder and/or decoded by the decoder. Such an indication may be based, for example, on one or more flags present in the syntax structure.

[0150] Therefore, by specifying only tile columns and brick heights for each tile column, and logically deriving potential tile rows, splitting can be signaled without signaling tile row heights. As a result, the coding efficiency can be improved and the bit rate required for said signaling can be reduced.

[0151] Several exemplary embodiments for the first aspect of the present invention are discussed below, i.e. syntax and semantics for specifying tile columns and brick heights for each tile column, without tile row heights. Embodiments of the present invention are equally applicable to both encoding forming part of a bitstream according to the proposed syntax and semantics and decoding decoding part of the bitstream according to the proposed syntax and semantics.

[0152] Syntax and semantics example 1:

[0153] The uniform_tile_col_spacing_flag flag of 1 specifies that the tile column boundaries are evenly spaced across the image and is signaled using the tile_cols_width_minusl syntax element. The uniform_tile_spacing_flag of 0 specifies that tile column boundaries are not necessarily evenly spaced across the image and are signaled by the num_tile_columns_minusl syntax element as well as the tile_column_width_minusl[i] syntax element list. If it is absent, the value of uniform_tile_col_spacing_flag is taken equal to 1.

[0154] The semantics of tile_cols_width_minusl, num_tile_columns_minusl and tile_column_width_minusl[i] are defined identically to the semantics of the syntax elements with the same names in version 5 of the VVC project.

[0155] If the uniform_tile_col_spacing_flag is 1, NumTileColsInPic is set to PicWidthInCtbsY / (tile_cols_width_minusl + 1) + PicWidthInCtbsY % (tile_cols_width_minusl + 1). Otherwise, NumTileColsInPic is set to num_tile_columns_minusl + 1.

[0156] A uniform_brick_spacing_flag[i] flag of 1 specifies that the horizontal brick boundaries are evenly spaced across the i-th tile column and signaled using the brick_height_minusl[i] syntax element. The uniform_brick_spacing_flag[i] flag of 0 specifies that the horizontal brick boundaries are not necessarily evenly spaced over the i-th tile and are signaled using the num_brick_rows_minusl[i] syntax element and the brick_row_height_minusl[i][j] syntax element list. If it is absent, the value of the uniform_brick_spacing_flag[i] flag is taken equal to 1.

[0157] The value of brick_height_minusl[i] plus 1 determines the height of the rows of bricks, excluding the bottom brick in the i-th tile column, measured in CTB when uniform_brick_spacing_flag[i] is 1.

[0158] The value num brick_rows_minusl[i] plus 1 determines the number of bricks into which the i-th column of tiles is split when the flag uniform_brick_spacing_flag[i] is 0.

[0159] The value brick_row_height_minusl[i][j] plus 1 specifies the height of the j-th brick in the i-th tile column, measured in CTB, when the uniform_tile_spacing_flag is 0.

[0160] Syntax and semantics example 2:

[0161] Example 2 is similar to example 1, however, in addition, the encoder indicates and/or decoder decodes whether the current tile column is bricked identically to the previous tile column.

[0162] The semantics of the syntax elements are identical to Example 1, except for the introduction of the following semantics for copy_previous_col_flag[i].

The copy_previous_col_flag[i] flag of 1 specifies all of the following:

- the value of uniform_brick_spacing_flag[i] is taken equal to uniform_brick_spacing_flag[i-1],

- when brick_height_minusl[i-1] is present, brick_height_minusl[i] is set to brick_height_minusl[i-1],

- when num_brick_rows_minusl[i-1] is present, the value of num_brick_rows_minusl[i] is taken to be num_brick_rows_minusl[i-1] and the value of brick_row_height_minusl[i][j] is taken to be brick_row_height_minusl[i-1][j] for each value] in the range from 0 to num_brick_rows_minusl[i] - 1 inclusive.

[0163] On the other hand, the problem of the non-optimal syntactic structure of version 5 of the VVC project can be partially solved with an approach in which tile column widths, tile row heights, or brick heights can be specified by the encoder and/or decoded by the decoder in a predetermined scan order, up to until it is indicated or decoded (respectively) that the remaining tile columns, tile rows, or bricks (respectively) are of equal size.

[0164] An encoding method in accordance with such a second aspect of the present invention is shown in FIG. 8, wherein the method includes the following steps: a) specifying (800) the number of partitions to be assigned; b) determining (802) the number of blocks to be assigned to partitions; c) indicating (804) whether the number of blocks to be assigned is assigned evenly to said number of partitions; and if not, d) indicating (806) the number of blocks to be assigned to the next partition, and e) repeating (808) steps c) and d) until all blocks have been assigned to partitions.

[0165] The decoding method according to the second aspect of the present invention includes the following steps: a) decoding the number of partitions to be assigned; b) determining the number of blocks to be assigned to partitions; c) decoding whether the number of blocks to be assigned is evenly assigned to said number of partitions; and if not, d) decoding the number of blocks to be assigned to the next partition, and e) repeating steps c) and d) until all blocks have been assigned to partitions.

[0166] In accordance with one embodiment of the present invention applicable to encoding and/or decoding, the number of blocks to be assigned to sections is one of the following: image width in CTU (for example, when sections are columns of tiles), height images per CTU (for example, when sections are rows of tiles, or when sections are rows of bricks specified for one or more full columns of tiles at the same time), the number of CTU rows in a tile (for example, when sections are bricks of a tile).

[0167] In accordance with one embodiment of the present invention applicable to encoding and/or decoding, said partitions are one or more of the following: tile columns, tile rows, brick rows.

[0168] In accordance with one embodiment of the present invention applicable to encoding and/or decoding, said blocks are rectangular blocks of image samples. For example, the block in the second aspect of the present invention illustrated in FIG. 8 may be a code tree block.

[0169] Therefore, by specifying the number of blocks to be assigned to sections in a predetermined scan order, the number of syntax elements and the bit rate required for said signaling can be significantly reduced, especially when the remaining blocks still to be assigned to sections, assigned to the remaining sections evenly.

[0170] In FIG. 9 shows an example of how the method shown in FIG. 8 may be implemented in accordance with one embodiment of the present invention. So, first, the number of partitions, such as columns of tiles and/or rows of tiles, to be assigned is indicated (900), and the number of blocks, NU, such as code tree blocks (CTB) to be assigned to partitions, is determined (902). To generate a verification loop that all blocks have been assigned to one of the partitions, it is checked (904) whether the number of partitions, NP, to be assigned is greater than one. If this is not the case, i.e. NP=1 logically obtain or indicate (910) that all remaining blocks still to be assigned should be assigned to the remaining section.

[0171] However, if NP>1, it is checked (906) whether the number of blocks, NU, to be assigned is divisible without remainder by the number of partitions, NP. If so, it is determined (908) whether the number of blocks, NU, should be assigned evenly to the remaining partitions. If so, logically get or indicate (910) that all remaining blocks still to be assigned, NU, should be assigned to the remaining section (or sections). If it is found that the number of blocks, NU, to be assigned is not evenly divisible by the number of partitions NP (906), or it is determined (908) that the number of blocks, NU, should not be distributed evenly to the remaining partitions, indicate (912) the number blocks to be assigned to the next section, in a predetermined scan order. The number of blocks, NU, to be assigned is reduced (914) by the specified number of blocks to be assigned to said next partition, and the number of partitions, NP, to be assigned is reduced by one (916). The loop then returns to checking if the number of partitions, NP, to be assigned is greater than one.

[0172] The method shown in FIG. 9 may be implemented similarly to decoding in accordance with one of the embodiments of the present invention described below. First, from the bitstream, or along with it, the number of sections, for example, columns of tiles and/or rows of tiles, to be assigned, and the number of blocks, NU, for example, code tree blocks (CTB), to be assigned to sections, is determined. To form a loop for checking that all blocks have been assigned to one of the partitions, it is checked whether the number of partitions, NP, to be assigned is greater than one. If this is not the case, i.e. NP=1, logically obtain, or decode, from or along with the bitstream, that all remaining blocks still to be assigned should be assigned to the remaining section.

[0173] However, if NP>1, it is checked whether the number of blocks, NU, to be assigned is divisible without remainder by the number NP of partitions. If so, decode, from or along with the bitstream, whether the number of blocks, NU, should be assigned evenly to the remaining partitions. If it is found that the number of blocks, NU, to be assigned is not evenly divisible by the number of partitions, NP, or if decoded, from or along with the bitstream, that the number of blocks, NU, is not to be distributed evenly into the remaining partitions, then decode , from or along with the bitstream, the number of blocks to be assigned to the next section, in a predetermined scan order. The number of blocks, NU, to be assigned is reduced by the specified number of blocks to be assigned to said next partition, and the number of partitions, NP, to be assigned is reduced by one. The loop then returns to checking if the number of partitions, NP, to be assigned is greater than one.

[0174] The following is an exemplary embodiment for the second aspect of the present invention, i.e. for the syntax and semantics of a unified signaling of an explicit or uniform partition into tiles and bricks. This embodiment of the present invention is equally applicable to both encoding forming part of the bitstream according to the proposed syntax and semantics and decoding decoding part of the bitstream according to the proposed syntax and semantics.

[0175] In this example, said unified signaling is used to set tile column widths and tile row heights, while brick signaling is identical to version 5 of the VVC project.

[0176] The flag rem_tile_col_equal_flag[i], equal to 0, specifies that the columns of tiles with indices in the range from 0 to i, inclusive, do not have to have the same width, measured in CTB.

The rem_tile_col_equal_flag[i] flag equal to 1 specifies that the tile columns with indices in the range from 0 to i inclusive have the same width, measured in CTB, while tile_column_width_minusl[j] is taken equal to remWidthInCtbsY / (i+1) for each value of j in the range from 0 to i inclusive.

[0177] The flag rem_tile_rowe_qual_flag[i], equal to 0, specifies that rows of tiles with indices in the range from 0 to i, inclusive, do not have to have equal height, measured in CTB.

The rem_tile_row_equal_flag[i] flag of 1 specifies that rows of tiles with indices ranging from 0 to i inclusive have equal height measured in CTB, with tile_row_height_minusl[j] set to remHeightInCtbsY / (i+1) for each value] in the range from 0 to i inclusive.

[0178] The semantics of the remaining syntax elements can be defined identically to the semantics of the identically named syntax elements in version 5 of the VVC project.

[0179] An exemplary implementation will be discussed below for another aspect of the present invention, i.e., syntax and semantics, including both specifying tile columns and brick heights for each tile column, as well as unified signaling of explicit or uniform tiling and bricking. . This embodiment of the present invention is equally applicable to both encoding forming part of the bitstream according to the proposed syntax and semantics and decoding decoding part of the bitstream according to the proposed syntax and semantics.

[0180] The following is a summary of this embodiment of the present invention, while it can be adapted for decoding by replacing the word "indication" with "decoding".

[0181] The tile columns are indicated as follows:

- indicate the number of tile columns (num_tile_columns_minusl);

- in a loop through the tile columns from left to right until all tile columns have been traversed, or until it is indicated that all remaining tile columns are of equal width, indicate:

- if the remaining width (measured in CTB) is divisible without remainder by the number of tile columns still to be assigned, indicate whether the remaining tile columns have equal width (rem_tile_col_equal_flag[i]),

- if the remaining tile columns do not have equal width, indicate the width of the tile column (tile_column_width_minusl[i]).

[0182] The following is indicated in a loop that iterates through tile columns from left to right, for rectangular slices, and includes only one entry in the loop body that determines the tile row heights for slices in raster scan mode:

- A flag indicating whether the tile column is split into bricks identical to the previous tile column. This flag is missing for the leftmost tile column (copy_previous_col_flag[i]). It should be noted that this flag may be omitted in this exemplary embodiment of the present invention, or there may be other alternatives described below that are suitable to achieve similar functionality to this flag.

- When the bricking of tiles in a tile column is not identical to the previous tile column, the bricks of the tile column are indicated as follows:

- indicate the number of bricks in the tile column (num_bricks_minusl[i]),

- in a loop through the bricks from top to bottom up until all the bricks of the tile column have been traversed, or until it is indicated that all remaining bricks in the tile column are of equal height, indicate the following:

если оставшаяся высота (измеряемая в СТВ) делится на количество кирпичей, все еще подлежащих определению, указывают, имеют ли оставшиеся кирпичи равную высоту (rem_brick_height_equal_flag[i][j]);

if the remaining height (measured in CTB) is divided by the number of bricks still to be determined, indicate whether the remaining bricks have the same height (rem_brick_height_equal_flag[i][j]);

если оставшиеся кирпичи не имеют равную высоту, указывают высоту кирпича (brick_height_minusl[i][j]).

if the remaining bricks do not have the same height, indicate the height of the brick (brick_height_minusl[i][j]).

[0183] In this embodiment of the present invention, the following syntax may be used.

[0184] The value of num_tile_columns_minusl plus 1 determines the number of tile columns into which the image is split when the uniform_tile_spacing_flag flag is 0. The value of num_tile_columns_minusl must be in the range 0 to PicWidthInCtbsY - 1 inclusive. When the flag single_tile_in_pic_flag is equal to 1, the value of num_tile_columns_minusl is set to 0.

[0185] The flag rem_tile_col_equal_flag[i], equal to 0, specifies that the columns of tiles with indices in the range from 0 to i, inclusive, do not have to have the same width, measured in CTB.

The rem_tile_col_equal_flag[i] flag of 1 specifies that tile columns with indices ranging from 0 to i inclusive are considered to have the same width, measured in CTB. When this flag is absent, rem_tile_col_equal_flag[i] is set to 0.

[0186] The value of tile_column_width_minusl[i] plus 1 specifies the width of the i-th tile column, measured in CTB.

[0187] The flag copy_previous_col_flag[i] equal to 0 determines that the value that_num_bricks_minusl[i] is present. The copy_previous_col_flag[i] flag of 1 specifies all of the following:

- the value of num_bricks_minusl[i] is taken equal to num_bricks_minusl[i-1],

- flag rem_brick_height_equal_flag[i][j] is taken equal to rem_brick_height_equal_flag[i-1][j] for all such values of j in the range from 0 to num_bricks_minusl[i] inclusive, for which the value rem_brick_height_equal_flag[i-1][j] is present or received logically,

- the brick_height_minusl[i][j] value is taken equal to brick_height_minusl[i-1][j] for such j values in the range from 0 to num_bricks_minusl[i] inclusive, for which the brick_height_minusl[i-1][j] value is present.

[0188] The flag copy_previous_col_flag[i] equal to 0 determines that the value num_bricks_minusl[i] is present. The copy_previous_col_flag[i] flag of 1 specifies all of the following:

- the value of num_bricks_minusl[i] is taken equal to num_bricks_minusl[i-1],

- flag rem_brick_height_equal_flag[i][j] is taken equal to rem_brick_height_equal_flag[i-1][j] for all such values of j in the range from 0 to num_bricks_minusl[i] inclusive, for which the value rem_brick_height_equal_flag[i-1][j] is present or obtained logically, - the brick_height_minusl[i]fj] value is taken equal to brick_height_minusl[i-1][j] for such j values in the range from 0 to num_bricks_minusl[i] inclusive, for which the brick_height_minusl[i-1][j] value is present .

[0189] The flag rem_brick_height_equal_flag[i][j] equal to 0 specifies that bricks with indices ranging from 0 to j inclusive in the i-th tile column do not necessarily have equal height, measured in CTB. The rem_brick_height_equal_flag[i][j] flag equal to 1 specifies that bricks with indices ranging from 0 to j inclusive in the i-th tile column are considered to have equal height, measured in CTB. When this flag is absent, rem_brick_height_equal_flag[i][j] is set to 0.

[0190] The value of brick_height_minusl[i][j] plus 1 determines the height of the j-th brick in the i-th tile column, measured in CTB.

[0191] The semantics of the remaining syntax elements can be defined identically to the semantics of the identically named syntax elements in version 5 of the VVC project.

[0192] In the decoding procedure, variables corresponding to the description below or similar to it can be used.

[0193] The list colWidth[i] in the range from 0 to num_tile_columns_minusl inclusive, defining the width of the i-th tile column, measured in CTB, is obtained as follows:

[0194] Lists colBrickHeight[i][j] for i in the range from 0 to num_tile_columns_minusl inclusive and j in the range from 0 to num_bricks_minusl[i] inclusive, defining the height of the j-th row of bricks, measured in CTB, in the i-th column tile, the RowHeight[j] list for j in the range from 0 to NumTileRows - 1 inclusive, defining the height of the j-th row of tiles, measured in CTB, the tileRowBd[j] list for j in the range from 0 to NumTileRows inclusive, defining the location of the border j- th row of tiles, measured in CTB, the NumTileRows value and the NumTilesInPic value are obtained as follows:

[0195] When the single_tile_in_pic_flag flag is 0, NumTilesInPic must be greater than 1. The list tileColBd[i] for i in the range 0 to num_tile_columns_minusl + 1 inclusive, specifying the location of the border of the i-th tile column, measured in CTB, is obtained as follows:

[0196] As described below, a NumBricksInPic variable is calculated that determines the number of bricks in an image referring to a given PPS set, and lists BrickColBd[brickIdx], BrickRowBd[brickIdx], BrickWidth[brickIdx], BrickHeight[brickIdx] for brickIdx in the range from 0 to NumBricksInPic - 1, inclusive, specifying the locations of vertical brick boundaries measured in CBM, horizontal brick boundary locations measured in CBM, brick column widths measured in CBM, and brick column heights measured in CBM, and are logically derived, for each i in the range from 0 to NumTilesInPic - 1 inclusive, when uniform_brick_spacing_flag[i] is 1, the value is num brick_rows_minusl[i].

[0197] In accordance with one embodiment of the present invention, the encoding method includes the following steps: a) determining the number of blocks to be assigned to partitions; b) specifying or booleaning the number of explicitly sized partitions to be assigned; c) an indication of the size of partitions of an explicitly specified size or number of blocks in them; and d) specifying or booleaning the number of partitions of equal size to be assigned.

[0198] In accordance with one embodiment of the present invention, the decoding method includes the following steps: a) determining the number of blocks to be assigned to partitions; b) decoding or inferring the number of explicitly sized partitions to be assigned; c) decoding the sizes of partitions of an explicit size or number of blocks in them; and d) decoding or inferring the number of partitions of equal size to be assigned.

[0199] In accordance with one embodiment of the present invention applicable to encoding and/or decoding, the number of blocks to be assigned to partitions is one of the following: image width in CTU (for example, when partitions are columns of tiles), height images per CTU (for example, when sections are rows of tiles, or when sections are rows of bricks specified for one or more full columns of tiles at the same time), the number of CTU rows in a tile (for example, when sections are bricks of a tile).

[0200] In accordance with one embodiment of the present invention applicable to encoding and/or decoding, said partitions are one or more of the following: tile columns, tile rows, brick rows.

[0201] In accordance with one embodiment of the present invention applicable to encoding and/or decoding, step d includes: determining the number of blocks still to be assigned to partitions by subtracting the number of blocks in explicit size partitions from the number of blocks, to be assigned to sections, the method further comprising:

- assignment of partitions to partitions of explicit size in accordance with the sizes or number of blocks in partitions of explicit size, and in accordance with a predetermined or specified/decoded scan order;

assigning partitions to partitions of equal size by dividing the blocks still to be assigned to partitions by the number of partitions of equal size, and according to a predetermined or specified/decoded scan order.

[0202] In accordance with one embodiment of the present invention applicable to encoding and/or decoding, the number of explicit size sections are indicated and/or decoded from a high-level syntactic structure (e.g., SPS set), while the sizes of explicit size sections and /or the number of sections of equal size to be assigned may be indicated and/or decoded from a low-level syntactic structure (eg, PPS set).

[0203] In accordance with one embodiment of the present invention, it is logically obtained that the number of explicit size partitions is 1 (for example, this may be predetermined in the encoding standard).

[0204] In accordance with one embodiment of the present invention applicable to encoding and/or decoding, step d includes:

- defining a set or list of partition sizes over which the number of blocks still to be assigned to partitions can be evenly distributed;

- if the number of elements in said set or list is 1, the logical conclusion is that the number of partitions of equal size is 1;

- indicating and/or decoding an index (or similar information) corresponding to an element of a set or list, wherein the index indicates the number of partitions of equal size to be assigned.

[0205] In accordance with one embodiment of the present invention applicable to encoding and/or decoding, the set or list of partition sizes into which said number of blocks still to be assigned can be evenly distributed is limited by excluding partition sizes smaller than a threshold , wherein the threshold may be predetermined, for example, in a coding standard, or specified/decoded. For example, predefined, or specified/decoded, may be the minimum width of a tile column in a CTU.

[0206] According to one embodiment of the present invention, an index corresponding to an element of said set or list is encoded with a fixed length codeword, such as u(v), where the length of the codeword is determined by the number of elements in the set or list.

Specifying whether a potential tile row boundary is a tile row boundary

[0207] In some of the embodiments of the present invention, the border of a row of tiles is obtained logically when the horizontal borders of the bricks are on the same line throughout the entire image. This section presents an embodiment of the present invention for tile line boundary signaling. This embodiment of the present invention can be used in conjunction with any embodiments of the invention in which, in syntax, brick boundaries indicate before tile row boundaries.

[0208] This embodiment of the present invention may include one or more of the following steps (some of which have already been described above):

- Potential tile row boundaries are logically obtained as the boundaries of bricks that are on the same (horizontal) line in the entire image.

- The encoder indicates, in or along with the bitstream, and/or the decoder decodes, from or along with the bitstream, whether all co-lined brick boundaries form tile row boundaries. For example, a flag may be used in bitstream syntax.

- If all co-linear brick boundaries form tile-row boundaries, the encoder indicates, in or along with the bitstream, and/or the decoder decodes, from or along with the bitstream, whether this boundary is a tile-row boundary. For example, in the bitstream syntax, there may be a flag for each boundary of the bricks that are in line (with the exception of the boundaries of the bricks that are in line, which are the boundaries of the image).

[0209] For example, the following syntax may be used:

[0210] The value of NumAlignedBrickRows can be calculated similarly to NumTileRows in other embodiments of the present invention.

[0211] The semantics of the presented syntax elements can be determined as described below.

[0212] The flag explicit_tile_rows_flag equal to 0 specifies that a tile row boundary is logically obtained whenever the horizontal brick boundaries are on the same line throughout the entire image. An explicit_tile_rows_flag flag of 1 specifies that the tile_row_flag[i] syntax element is present.

[0213] The tile_row_flag[i] flag of 0 specifies that the i-th horizontal border, where the horizontal borders of the bricks are on the same line across the width of the image, is not a tile row border. The tile_row_flag[i] flag equal to 1 specifies that the i-th horizontal border, where the horizontal borders of the bricks are on the same line across the width of the image, is the border of the tile row. The 0th horizontal border, where the horizontal borders of the bricks are in line across the width of the image, is the top border of the image.

Specifying tile columns. the division of which into bricks is the same

[0214] In some of the embodiments of the present invention, the syntax includes an indication that the tile column is bricked identically to the previous tile column, in loop entry order (eg, scanning the tile columns from left to right). It is to be understood that embodiments of the present invention may be equally applicable without such indication or with any similar indication. For example, scanning of tile columns can be performed from left to right, and therefore it can be specified that the bricking of the current tile column should be copied from the tile column on the right. In another example, it may be specified, or inferred, that all columns of tiles of equal width have the same bricking. In yet another example, the index of the tile column from which the bricking is to be copied is specified. It should also be understood that embodiments of the present invention that use other methods of inferring the bricking of a column of tiles into bricks based on the foregoing indications can be equally applied. This section presents some of the relevant embodiments of the invention.

[0215] In one embodiment of the present invention, the encoder indicates, in or along with the bitstream, and/or the decoder decodes, from or along with the bitstream, whether all tile columns have the same width (e.g., in CTB) , the same partition into bricks. For example, a syntax element named same_brick_spacing_in_equally_wide_tile_cols_flag could be used.

[0216] In one embodiment of the present invention, the encoder indicates, in or along with the bitstream, and/or the decoder decodes, from or along with the bitstream, the number of contiguous tile columns, in order of input into the loop (e.g., column scan tiles from left to right) that have the same bricking. For example, a syntax element named num_tile_cols_with_same_brick_partitioning_minusl[i] could be encoded in the format u(v), where v is the number of remaining tile columns for which no bricking has yet been specified.

[0217] In one embodiment of the present invention, an encoder may indicate, in or along with the bitstream, and/or a decoder may decode, from or along with the bitstream, whether there are syntax elements related to indicating that the columns tiles are bricked identically (for example, the copy_previous_col_flag[i] flag). In one of the embodiments of the present invention, such an indication is in the syntactic structure at the sequence level, for example, in the SPS set. In yet another embodiment of the present invention, such an indication may be in an image layer syntax structure, such as in a PPS set. In one embodiment of the present invention, it may be predetermined, for example in an encoding standard, that the absence of syntax elements relating to indicating that columns of tiles are bricked identically may cause bricking to be indicated and/or decoded for all columns. tiles separately. In one of the embodiments of the present invention, it may be predetermined, for example, in an encoding standard, that the absence of syntax elements related to indicating that columns of tiles are identically bricked may cause bricking to be indicated and/or decoded for one column. tiles and the logical conclusion that it is the same for all columns of tiles. In one of the embodiments of the present invention, a method for handling the absence of syntax elements related to indicating that columns of tiles are identically bricked, indicates the encoder, in or along with the bitstream, for example, in the SPS set, and / or decodes the decoder, from the bitstream or along with it, for example, from the SPS set. Said method may be specified and/or decoded as part of a predetermined set of procedures, which may include, but is not limited to: i) specifying and/or decoding the bricking for all columns of tiles individually, and ii) specifying and/or decoding the bricking on bricks for one column of tiles and the logical conclusion that it is the same for all columns of tiles.

[0218] Thus, the syntax and semantics for tiling and brick signaling, in accordance with embodiments of the present invention, provide a significant reduction in the number of syntax elements and syntax lines needed to implement said signaling. The result is a significant savings in the number of bits required to specify the tiling and bricking.

[0219] These advantages are illustrated in the following example, where the three different tilings and bricks shown in FIG. 9a, 9b and 9c are used to compare the performance of tiling and bricking according to version 5 of the VVC project and tiling and bricking in accordance with some of the embodiments of the present invention.

[0220] In FIG. Figures 10a and 10b show tiling and bricking that provide the implementation of equirectangular projection (ERP) and cubemap projection (CMP) with effective 6K resolution (respectively) as described in clauses D.6.3 and D.6.4 (respectively) Omnidirectional Media Format (OMAF, ISO/IEC 23090-2). These diagrams are provided in the VR Industry Forum Guidelines. The scheme shown in Fig. 10c is practically equivalent to the circuit in FIG. 10b, however, a different aspect ratio of the image is used there.

[0221] For version 5 of the VVC project and an embodiment of the present invention, combining the indication of columns of tiles and brick heights for each column of tiles, and unified signaling of explicit or uniform tiling and bricking, the following characteristics were obtained: - the number of syntax elements for specifying splitting into tiles and bricks,

- the number of syntax lines for specifying the division into tiles and bricks,

- the number of bits required to indicate the division into tiles and bricks for the schemes shown in the drawing below,

- bit savings in percentage provided by the mentioned embodiment of the present invention, compared with version 5 of the VVC draft for the circuits shown in the drawing below.

[0222] The characteristics obtained with a luminance CTB block size of 128×128 are shown in the table below.

[0223] Accordingly, it can be seen that the number of syntax elements has been reduced from 13 to 7, and the number of required syntax lines has been reduced from 26 to 20. The bit savings provided by the proposed embodiment of the present invention for each of the tiling and bricking in FIG. 10a-10c is more than 50% compared to version 5 of the VVC project. It should also be noted that the semantics and calculation procedures can be reduced by the present invention.

Specifying uncoded tiles or bricks

[0224] In some applications, it is desirable to be able to assign content to be encoded and/or decoded to tiles and/or bricks such that only a subset of tiles and/or bricks are occupied. For example, when streaming 360-degree video depending on the viewport, only a subset of independently encoded image areas, such as tiles, can be received. In another example, coding of volumetric video (volumetric) or point cloud video (point cloud) based on patches (patch-based) can be used, where patches occupy only a subset of tiles and / or bricks of the image.

[0225] In accordance with one of the embodiments of the present invention, used for encoding, unencoded tiles or bricks indicate in the syntactic structure before the slice data, in the bitstream, or along with it. For non-encoded tiles or bricks, no syntax elements are encoded into the slice data. Uncoded tiles or bricks are reconstructed (for example, into a decoded reference image) using a predetermined or specified method, for example, setting the values of the reconstructed samples in the sample arrays to 0.

[0226] In accordance with one embodiment of the present invention applicable to decoding, uncoded tiles or bricks are decoded from the syntax structure preceding the slice data, from or along with the bitstream. For non-encoded tiles or bricks, no syntax elements are decoded from these slices. Uncoded tiles or bricks are decoded (eg, into a decoded reference image) using a predetermined or specified method, for example, setting the values of the reconstructed samples in the sample arrays to 0.

[0227] In accordance with one of the embodiments of the present invention, used for encoding and/or decoding, the number of uncoded bricks is indicated for individual columns of tiles, for example, using a word of variable length in the format ue(v). Bricks in a tile column pass in a predefined scan order (e.g. from bottom to top). For each brick passed, a flag is indicated and/or decoded, allowing one to conclude whether the brick is uncoded or not. If a brick is not coded, the number of bricks remaining to be assigned as non-coded is reduced by 1. The procedure continues until there are no bricks left that can be assigned as non-coded.

[0228] FIG. 11 illustrates a block diagram of a video decoder suitable for applying embodiments of the present invention. In FIG. 11 shows the structure of a two-layer decoder, however, it should be understood that the same decoding operations can be similarly applied in a single-layer decoder.

[0229] The video decoder 550 includes a first decoder section 552 for the base layer and a second decoder section 554 for the predictive layer. Block 556 illustrates a demultiplexer for providing base layer image information to a first decoder section 552 and also for providing predictive layer image information to a second decoder section 554. P'n are the predicted representations of a block of image pixels. D'n denotes recovered prediction error signals. Blocks 704, 804 illustrate previously reconstructed images (I'n). R'n denotes the final reconstructed image. Blocks 703, 803 illustrate the inverse transformation (T ^-1 ). Blocks 702, 802 illustrated inverse quantization (Q ^-1 ). Blocks 701, 801 illustrate entropy decoding (E ^-1 ). Blocks 705, 805 illustrate the reference frame memory (RFM). Blocks 706, 806 illustrate prediction (P) (either intra or inter prediction). Blocks 707, 807 illustrate filtering (F). Blocks 708, 808 may be used to combine the decoded prediction error information with the baseline or predictive level predicted pictures, resulting in pre-recovered pictures (I'n). The pre-restored and filtered base layer images may be output (709) from the first decoder section 552, and the pre-restored and filtered predictive-view images may be output (809) from the second decoder section 554.

[0230] Here, a decoder is understood to mean any functional unit capable of performing decoding operations, such as a player, receiver, gateway, demultiplexer, and/or decoder.

In FIG. 12 is a flow diagram of a decoder in accordance with one embodiment of the present invention. The decoding operations in the embodiments of the present invention are essentially the same as the encoding operations, except that the decoder decodes the indications from or along with the bitstream. So, the decoding method includes: decoding (1200) part of the bitstream, including the indication of columns of tiles and the indication of brick heights for one or more columns of tiles at the same time; logically obtaining (1202), in case of detecting lines of bricks that are on the same line throughout the entire image, potential lines of tiles; logically getting (1204) or decoding an indication of whether a potential tile-row boundary is a tile-row boundary; and decoding (1206) one or more images from the bitstream using the specified tile columns, the specified or logically derived tile rows, and the specified brick heights, wherein the one or more images are split into a tile grid following the specified tile columns and the specified or logically derived rows tiles, wherein a tile in the tile grid includes an integer number of code tree packages and is broken into one or more bricks, and the brick contains an integer number of lines of code tree packages within the tile.

[0231] In FIG. 13 is a flow diagram of a decoder in accordance with yet another embodiment of the present invention. The decoding method includes the following steps: a) decoding (1300) an indication of the number of partitions to be assigned; b) determining (1302) the number of blocks to be assigned to partitions; c) determining (1304) whether the number of blocks to be assigned is uniformly assigned to said number of partitions; and if not, d) determining (1306) the number of blocks to be assigned to the next partition, and e) repeating (1308) steps c) and d) until all blocks have been assigned to partitions.

Specifying the division of the image into rectangular slices

[0232] The following paragraphs present embodiments of the present invention for improved methods for encoding and/or decoding rectangular slice signaling. These embodiments of the present invention may be used in conjunction with or independently of the tiling and bricking embodiments. These embodiments of the present invention are based on the definitions and properties of tiles, bricks and rectangular slices adopted in version 5 of the VVC project. With the proposed embodiments of the present invention, the number of bits required to indicate rectangular slices (eg, indicate or obtain the location, width, and height of rectangular slices) can be reduced.

[0233] The encoding method, in accordance with the first aspect of the present invention, includes specifying, in or along with the bitstream, or logically obtaining the top left brick of a rectangular slice. determining, based on location, whether the rectangular slice includes one or more brick tiles; if the rectangular slice includes one or more tile bricks, specifying, in or along with the bitstream, or logically getting the number of bricks in the rectangular slice.

[0234] The decoding method according to the first aspect of the present invention includes decoding, from or along with a bitstream, or logically deriving a top left brick of a rectangular slice; determining, based on location, whether the rectangular slice includes one or more brick tiles; if the rectangular slice includes one or more tile bricks, decode, from or along with the bitstream, or logically obtain the number of bricks in the rectangular slice.

[0235] The location of the brick may be, for example, the index of the brick in the order in which the bricks of the image were scanned.

[0236] In one embodiment of the present invention applicable to encoding and/or decoding, when the top left brick location of a rectangular slice is not the top left brick of any tile, the rectangular slice is determined to contain one or more tile bricks.

[0237] In one embodiment of the present invention applicable to encoding and/or decoding, when the location of the top left brick of a rectangular slice is the top left brick of any tile, and the tile contains a plurality of bricks, it is concluded that the rectangular slice may include either bricks tiles, or full tiles. In one embodiment of the present invention applicable to encoding, if it is concluded that a rectangular slice can contain either tile bricks or full tiles, it indicates, in or along with the bitstream, whether the rectangular slice contains tile bricks or full tiles. In one embodiment of the present invention applicable to decoding, if it is concluded that a rectangular slice can contain either tile bricks or full tiles, it is decoded, from or along with the bitstream, whether the rectangular slice contains tile bricks or full tiles.

[0238] In one embodiment of the present invention applicable to encoding and/or decoding, if it is logically obtained or indicated (as part of encoding) or decoded that a rectangular slice contains tile bricks, a variable, for example, named numDeltaValues is set to the number bricks that follow the location of the top left brick of the rectangular slice and are in the same tile. If numDeltaValues is 1, it is concluded that the rectangular slice contains exactly one brick. Otherwise, the variable numDeltaValues is used to calculate the length of the first syntax element indicating the bottom right brick of the rectangular slice, or the second syntax element indicating the number of bricks in the rectangular slice, or the third syntax element indicating the height (in bricks) of the rectangular slice, or any similar syntactic element. For example, the first, second, or third syntax element, or any similar syntax element, may be encoded in u(v) format, and its length may be Ceil ((numDeltaValues)) bits.

[0239] In one embodiment of the present invention, the following syntax is used:

[0240] The semantics of the syntax elements can be determined in accordance with the previous description, except that the value of bottom_right_brick_idx_delta[i] defines the difference between the index of the brick located in the lower right corner of the i-th slice and top_left_brick_idx[i]. When the single_brick_per_slice_flag flag is 1, the value of bottom_right_brick_idx_delta[i] is set to 0. If it is absent, the value of bottom_right_brick_idx_delta[i] is set to 0. The variable numDeltaValues, which specifies the number of values that bottom_right_brick_idx_delta[i] can take, is calculated as follows:

[0241] The length of the bottom_right_brick_idx_delta[i] syntax element is Ceil(Log2(numDeltaValues)) bits. The NumBricksIntile[brickIdx] variable defines the number of bricks in a tile containing a brick with index brickIdx when scanning image bricks. The BrickIdxIntile[brickIdx] variable defines the index of a brick within the tile containing that brick, when the brick has index brickIdx when scanning the image's bricks.

[0242] In one embodiment of the present invention applicable to encoding and/or decoding, the location of the top left brick of the rectangular slice is obtained logically. First, all brick locations are marked as free. The brick-to-rectangular slices assignment loop is turned on, in or along with the bitstream, or decoded from, or along with the bitstream. On each entry into the loop, the top left brick of the rectangular slice is considered to be the next free brick location in the predetermined, specified, or decoded scan order. For example, it may be predetermined, for example in an encoding standard, that the order in which the bricks in the image are scanned is used. The bottom right brick of a rectangular slice can be inferred, specified, or decoded, for example, as described above, and the bricks forming a rectangle with the top left brick and bottom right brick at the corners are marked as assigned. The same, or similar, procedure is performed each time the loop is entered.

[0243] In one embodiment of the present invention applicable to encoding and/or decoding, when it is concluded (as part of encoding or decoding) or indicated (as part of encoding) or decoded (as part of decoding) that a rectangular slice includes full tiles , a syntax element for pointing to the bottom right brick of a rectangular slice is computed based on one or more of the following:

- Get a set of possible locations for the bottom right brick. This set can only include brick locations that are the last brick locations within a tile, are located in or below a row of tiles containing the top left brick of a rectangular tile, are located in a tile column or to the right of a tile column containing the top left brick of a rectangular tile, and include a rectangular set of free tile locations (not yet assigned to any rectangular slices).

- The entries in the set of possible locations of the lower right brick are indexed, or numbered.

- The length of the u(v)-encoded syntax element to point to the bottom right brick of the rectangular slice is calculated based on the number of entries in the set of possible bottom right brick locations. If the number of numEnt entries is 1, the index of the bottom right brick does not need to be specified or decoded. Otherwise, the length of this syntax element is Ceil(Log2(numEnt)) bits.

- The syntax element for pointing to the bottom right brick of a rectangular slice is an index into a numbered set of possible bottom right brick locations.

[0244] The encoding method according to the second aspect of the present invention includes:

- specifying, in or along with the bitstream, or logically obtaining the location of the top left brick of the rectangular slice;

- inferring, based on location, whether a rectangular slice includes one or more tile bricks;

- if the rectangular slice contains one or more tile bricks, the logical conclusion that the width of the rectangular slice is equal to one column of tiles, otherwise, if the top left brick is in the rightmost column of tiles, the logical conclusion that the width of the rectangular slice is one tile column, and otherwise, an indication, in or along with the bitstream, of the width of the rectangular slice in tile columns;

- if the rectangular slice contains one or more tile bricks, indicating, in or along with the bitstream, or logically getting the number of bricks in the rectangular slice; otherwise, if the top-left brick is in the bottommost tile row, the logical conclusion that the height of the rectangular slice is one tile row, and otherwise, an indication, in or along with the bitstream, of the height of the rectangular slice in tile rows .

[0245] The decoding method according to the second aspect of the present invention includes:

- decoding, from or along with the bitstream, or logically deriving the location of the top left brick of the rectangular slice;

- inferring, based on location, whether a rectangular slice includes one or more tile bricks;

- if the rectangular slice contains one or more tile bricks, the logical conclusion that the width of the rectangular slice is equal to one column of tiles, otherwise, if the top left brick is in the rightmost column of tiles, the logical conclusion that the width of the rectangular slice is one tile column, and otherwise, decoding, from or along with the bitstream, the width of the rectangular slice in tile columns;

- if the rectangular slice includes one or more tile bricks, decoding, from or along with the bitstream, or logically deriving the number of bricks in the rectangular slice; otherwise, if the top-left brick is in the bottommost tile row, the logical conclusion that the height of the rectangular slice is one tile row, and otherwise, decoding, from or along with the bitstream, the height of the rectangular slice in the tile rows .

[0246] In one embodiment of the present invention applicable to encoding and/or decoding and applicable to the first aspect and/or the second aspect, the number of bricks in a rectangular slice is taken to be 1 (in bricks) when concluded or indicated or decoded that the rectangular slice contains the bricks of the tile, and either the tile contains two bricks and the current brick (i.e., the top left brick of the rectangular slice) is the topmost brick of the tile, or the current brick is the bottommost brick of the tile.

[0247] In one embodiment of the present invention, the following syntax is used:

[0248] Variables and semantics of syntax elements can be defined in accordance with the previous description, with the following additions:

- The tlBrickIdx variable can be defined as the next free brick location in a predefined scan order, such as scanning the image bricks as described previously. The value of tlBrickIdx is recalculated for each value of i, that is, each time the loop is entered.

The variable numFreeColumnsOnTheRight[brickIdx] is a variable that specifies the number of tile columns to the right of the brick at index brickIdx.

- The value of slice_width_minusl[i] plus 1 determines the width of the i-th rectangular slice in tile columns. If it is absent, the value of slice_height_minusl[i] is taken equal to 0.

- The flag full_tiles_in_slice_flag[i] equal to 0 specifies that the i-th rectangular slice contains one or more bricks of the same tile. The flag full_tiles_in_slice_flag[i] equal to 1 specifies that the i-th rectangular slice contains one or more full tiles.

The value of full_tiles_in_slice_flag[i] is set to 0 when BrickIdxIntile[tlBrickIdx] is greater than 0 (ie, when the top left brick of a rectangular slice is not the top left brick of any of the tiles). The full_tiles_in_slice_flag[i] flag is set to 1 when slice_width_minusl[i] is greater than 0, or when BrickIdxIntile[tlBrickIdx] is 0 and NumBricksIntile[tlBrickIdx] is 1.

- If the full_tiles_in_slice_flag[i] flag is 0, numFreeRowsBelow[brickIdx] is a variable indicating the number of bricks in the tile below the brick with index brickIdx in the same tile. Otherwise, numFreeRowsBelow[brickIdx] is a variable indicating the number of tile rows below the tile containing the brick at index brickIdx.

- If the full_tiles_in_slice_flag[i] flag is 0, the value of slice_height_minusl[i] plus 1 determines the height of the i-th rectangular slice in bricks. Otherwise, slice_height_minusl[i] plus 1 specifies the height of the i-th rectangular slice in the tile rows. If it is absent, the value of slice_height_minusl[i] is taken equal to 0.

[0249] In one embodiment of the present invention applicable to encoding and/or decoding, the length of the slice width syntax element (e.g., slice_width_minusl) is calculated based on the number of possible values based on the location of the top left brick of the rectangular slice. Using the variables and syntax elements described above, the length of slice_width_minusl is obtained as equal to Ceil(Log2(numFreeColumnsOnTheRight[tlBrickIdx] + 1)).

[0250] In one embodiment of the present invention applicable to encoding and/or decoding, the length of the slice height syntax element (e.g., slice_height_minusl) is calculated based on the number of possible values based on the location of the top left brick of the rectangular slice, and whether it contains rectangular slice bricks of one tile or full tiles. Using the variables and syntax elements described above, the length of slice_height_minusl is calculated to be equal to Ceil(Log2(numDeltaValues)), where numDeltaValues is calculated as follows:

Specifying Uncoded Rectangular Slices

[0251] In some applications, it is desirable to be able to assign content to be encoded and/or decoded to rectangular slices such that only a subset of the rectangular slices is occupied. For example, when streaming 360-degree video depending on the viewport, only a subset of rectangular slices can be received. In another example, coding of volumetric video (volumetric) or point cloud video (point cloud) on the basis of patches (patch-based) can be used, where the patches occupy only a subset of rectangular slices of the image.

[0252] In accordance with one embodiment of the present invention, for encoding, uncoded rectangular slices are indicated in or along with the bitstream, for example, in a PPS set. Uncoded rectangular slices are not encoded into the bitstream as VCL NAL units. Uncoded rectangular slices are reconstructed (eg, into a decoded reference picture) using a predetermined or specified method, for example, setting the values of the reconstructed samples in the sample arrays to 0.

[0253] According to one embodiment of the present invention, for decoding, uncoded rectangular slices are decoded from or along with a bitstream, such as from a PPS set. Uncoded rectangular slices are not decoded from the bitstream as VCL NAL units. Instead, the uncoded rectangular slices are decoded (eg, into a decoded reference picture) using a predetermined or specified method, eg, setting the values of the decoded samples in the sample arrays to 0.

[0254] In accordance with one embodiment of the present invention applicable to encoding and/or decoding, for each rectangular slice, a flag is indicated and/or decoded that indicates whether the rectangular slice is unencoded or not.

[0255] In accordance with one embodiment of the present invention, the number of uncoded rectangular slices is indicated and/or decoded using a variable length codeword, such as in ue(v) format. The rectangular slices are traversed in a predetermined scan order (eg, in reverse order of the raster scan of the top left CTUs of the rectangular slices). For each traversed rectangular slice, a flag is indicated and/or decoded to determine whether the rectangular slice is uncoded or not. If the rectangular slice is not encoded, the number of rectangular slices remaining to be designated as unencoded is reduced by 1. The procedure continues until there are no remaining rectangular slices that can be designated as unencoded.

[0256] FIG. 14 is a graphical representation of an exemplary multimedia communication system in which various embodiments of the present invention may be implemented. In accordance with the illustration of FIG. 8, data source 1510 provides the original signal in analog, uncompressed digital, or compressed digital format, or any combination of these formats. The encoder 1520 may include, or be connected to, pre-processing means such as data format conversion and/or source signal filtering means. An encoder 1520 encodes the original signal into an encoded media bitstream. It should be noted that the bitstream to be encoded may be received, directly or indirectly, from a remote device located on virtually any type of network. Also, the bit stream may be received from local hardware or software. Encoder 1520 may be capable of encoding more than one type of media, such as audio and video, or more than one encoder 1520 may be required to encode different types of source signal. The encoder 1520 may also receive synthetic input, such as graphics or text, or may be capable of generating encoded synthesized media bitstreams. Below, for simplicity of description, processing of only one encoded bitstream containing the same type of multimedia data will be considered. However, it should be noted that typically real-time broadcast services include multiple streams (typically at least one audio stream, a video stream, and a subtitle text stream). Also, it should be noted that the system may include multiple encoders, however, in FIG. 8, for simplicity of description, without loss of generality, only one encoder 1520 is shown. The description and examples in this document describe the encoding procedure, however, those skilled in the art should understand that the same principles and ideas apply to the corresponding procedure. decoding and vice versa.

[0257] The encoded media bitstream may be transferred to storage 1530. Storage 1530 may include any type of mass storage device for storing the encoded media bitstream. The format of the encoded media bitstream in storage 1530 may be an elementary standalone bitstream format, or one or more encoded media bitstreams may be encapsulated in a container file, or the encoded media may be encapsulated in a Segment format suitable for DASH or a similar system. streaming) and stored as a sequence of segments. If one or more media bitstreams are encapsulated in a container file, a file builder (not shown) can be used to save the one or more media bitstreams to a file and to generate file format metadata that is also saved to the file. Encoder 1520 and/or storage 1530 may include a file builder, or the file builder may be operatively coupled to encoder 1520 and/or storage 1530. Some systems operate on the fly, that is, do not use memory and transmit an encoded media bitstream from the encoder. 1520 directly to the transmitter 1540. The encoded media bitstream is then transmitted, when needed, to the transmitter 1540, also referred to as the server. The format used in transmission may be an elementary standalone bitstream format, a packet stream format, a Segment format suitable for DASH or a similar streaming system, or one or more encoded media bitstreams may be encapsulated in a container file. The encoder 1520, store 1530, and transmitter 1540 may reside on the same physical device, or they may be part of separate devices. The encoder 1520 and the server 1540 may operate on real-time data, in which case the encoded media bitstream is typically not permanently stored but buffered for short periods of time in the video encoder 1520 and/or server 230 to smooth out fluctuations. processing delays, transmission delays, and encoded media bitrate.

[0258] Server 1540 transmits an encoded media bitstream using a communication protocol stack. The stack may include, but is not limited to, one or more of the following: Real Time Transfer Protocol (RTP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), Transmission Control Protocol (TCP) ) and the Internet Protocol (IP). When the communication protocol stack is packetized, the server 1540 encapsulates the encoded media bitstream into packets. For example, when the RTP protocol is used, the server 1540 encapsulates the encoded media bitstream into RTP packets according to the RTP protocol payload format. Typically, each media type has a separate RTP payload format. It should again be noted that the system may contain more than one server 1540, but for simplicity, only one server 1540 is considered in the following description.

[0259] If the media data is encapsulated in a container file for storage 1530 or for input to transmitter 1540, transmitter 1540 may include or be operatively associated with a "transfer file parser" (not shown). In particular, if the container file itself is not transmitted, but at least one encoded media bitstream contained therein is encapsulated for transmission over a communication protocol, the parser of the transmitted file finds the corresponding portions of the encoded media bitstream to be transmitted over the communication protocol. The file transfer parser can also be useful in generating the correct format for the communication protocol, such as packet headers and payloads. The media container file may contain encapsulation instructions, such as hint tracks in ISOBMFF, used to encapsulate at least one encoded media bitstream into a communication protocol.

[0260] The server 1540 may optionally be connected to the gateway 1550 over a communications network, which may be, for example, a combination of a CDN, the Internet, and/or one or more access networks. In addition or alternatively, the gateway may be referred to as an intermediate node. In the case of DASH, the gateway can be an edge server (CDNs) or a web proxy. It should be noted that, in general, a system may include any number of gateways or the like, however, for simplicity, only one gateway 1550 is considered in the description below. Gateway 1550 may perform various types of functions, for example, broadcasting a packet stream corresponding to one into another communication protocol stack, merging and forking data streams, and manipulating the data streams according to the capabilities of the downlink and/or the receiver, for example, controlling the data bit rate of the redirected stream according to the prevailing network conditions in the downlink. Gateway 1550 in various embodiments of the present invention may be a server entity.

[0261] The system includes one or more receivers 1560 that are generally capable of receiving, demodulating, and/or decapsulating a transmitted signal to obtain an encoded media bitstream. The encoded media bitstream may be transferred to recording storage 1570. Recording storage 1570 may include any type of mass storage device for storing the encoded media bitstream. Write storage 1570 may additionally or alternatively include computational memory, such as random access memory. The format of the encoded media bitstream in recording storage 1570 may be an elementary standalone bitstream format, or one or more encoded media bitstreams may be encapsulated in a container file. If there are multiple encoded media bitstreams, such as an audio stream and a video stream, associated with each other, then a container file is typically used, and the receiver 1560 comprises (or is associated with a similar container file generator) generating a container file based on the input streams. . Some systems operate on the fly, that is, transmit the encoded media bitstream from the receiver 1560 directly to the decoder 1580, without using the recording store 1570. In some systems, the recording store 1570 stores only the latest part of the recorded stream, for example, the last minute fragment of the recorded stream, while all previously recorded data is deleted from the recording storage 1570.

[0262] The encoded media bitstream from the recording storage 1570 may be passed to the decoder 1580. If there are multiple encoded media bitstreams, such as an audio stream and a video stream, associated with each other and encapsulated in a container file, or a single bitstream that is encapsulated in container file, for example, for easier access, a file analyzer (not shown) is used to decapsulate all encoded media bitstreams from the container file. Recording store 1570 or decoder 1580 may have a file parser in its composition, or the file parser may be associated with recording store 1570 or decoder 1580. Also, it should be noted that the system may include multiple decoders, however, in this document, for simplicity of description , without loss of generality, only one 1580 decoder is shown.

[0263] The encoded media bitstream may be further processed by a decoder 1580, which outputs one or more uncompressed media streams. Finally, the renderer 1590 may render uncompressed media streams, such as through a speaker or display. Receiver 1560, record store 1570, decoder 1580, and renderer 1590 may reside on the same physical device, or they may be on separate devices.

[0264] The above part of the embodiments of the present invention has been described on the example of the WC/H.266 standard and/or using appropriate terminology. It is to be understood that embodiments of the present invention may be similarly implemented with any video encoders and/or video decoders.

[0265] Above, some of the embodiments of the present invention have been described with reference to specific syntax structures and/or syntax elements. It should be understood that embodiments of the present invention may similarly be implemented using other syntax structures and/or syntax elements. For example, when embodiments of the present invention are described with reference to syntax elements in a PPS syntax, it should be understood that embodiments of the present invention may be implemented using the same or similar syntax elements in other syntax structures, such as the SPS.

[0266] Above, some of the embodiments of the present invention are described using the term "indication". It should be understood that the term "indication" can be understood as encoding or generating one or more syntax elements in one or more syntax structures, in or along with a bitstream.

[0267] Above, some of the embodiments of the present invention are described using the term "decoding". It should be understood that the term "decoding" can be understood as decoding or parsing one or more syntax elements from one or more syntax structures, from or along with a bitstream.

[0268] In the above description, where embodiments of the invention have been described with reference to an encoder, it is to be understood that the resulting stream and decoder may also include corresponding elements. Likewise, where embodiments of the present invention have been described with reference to a decoder, it is to be understood that the encoder may have a structure and/or a computer program for generating a bitstream decoded by the decoder. For example, part of the embodiments of the present invention has been described in connection with generating a prediction block as part of the encoding. Embodiments of the present invention can be similarly implemented with generating a prediction block as part of the decoding, with the difference that encoding parameters such as horizontal offset and vertical offset are decoded from the bitstream rather than determined by the encoder.

[0269] In the above embodiments of the present invention, the codec is described on the example of separate encoding and decoding devices - to simplify the understanding of the procedures used. However, it is to be understood that the device, structures, and operations may be implemented as a single device/structure/encode/decode operation. It is also allowed that the encoder and decoder may share some of the common elements, or that all elements may be common.

[0270] The examples discussed above describe the operation of embodiments of the present invention in an electronic device codec, however, it should be understood that the present invention, as defined by the appended claims, may be implemented as part of any video codec. Thus, for example, embodiments of the present invention may be implemented in a video codec in which video coding may be implemented over fixed, or wired, communication channels.

[0271] Accordingly, the user equipment may include a video codec, for example, similar to those discussed in the above description of the present invention. It is to be understood that the term "user equipment" is used to encompass any suitable type of wireless user equipment, such as mobile phones, portable data processing devices, or portable web browsers.

[0272] In this case, the elements of the public land mobile network (PLMN) may also include video codecs in accordance with the previous description.

[0273] In general, various embodiments of the present invention may be implemented in hardware or special-purpose circuitry, software, logic, or any combination thereof. For example, some of the aspects may be implemented in hardware, while other aspects may be implemented in firmware or software that may be executed by a controller, microprocessor, or other computing device, without limiting the present invention to those listed. Various aspects of the present invention are capable of being illustrated and described by block diagrams, flowcharts, or some other pictorial representation, but it should be understood that the blocks, devices, systems, methods, or methods described herein may be implemented, by way of non-limiting examples, as hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller, or other computing devices, or some combination thereof.

[0274] Embodiments of the present invention may be implemented by software executed by a data processor of a mobile device, such as a processor element, or by hardware, or by a combination of software and hardware. Also in this regard, it should be noted that any flow blocks illustrated in the drawings may represent program steps or related logics, blocks and functions, or a combination of program steps and logics, blocks and functions. The software may be stored on physical media such as memory chips or memory blocks implemented within the processor, magnetic media such as a hard disk drive or floppy disk, and optical media such as DVDs and their data storage variants, CDs.

[0275] The memory may be of any type appropriate to the local technical environment, and may be implemented using any suitable storage technology, such as semiconductor storage devices, magnetic storage devices and systems, optical storage devices and systems, non-removable or removable memory. Data processors may be of any type appropriate to the local technical environment and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), processors based on multi-core architecture as non-limiting examples.

[0276] Embodiments of the present invention may be practiced in various components, such as integrated circuit modules. The process of developing integrated circuits, in general, is highly automated. Sophisticated and powerful software tools exist for converting logic-level designs into semiconductor circuit designs, ready to be etched and molded onto a semiconductor substrate.

[0277] Programs such as those supplied by Synopsys, Inc (Mountain View, CA) or Cadence Design (San Jose, CA) automatically route conductors and position components on a semiconductor chip using generally accepted design rules, as well as using libraries of pre-saved project modules. Upon completion of the development of a semiconductor circuit, the resulting design, in a standardized electronic format (for example, Opus, GDSII, etc.), can be transferred to a semiconductor manufacturer for the manufacture of a microcircuit.

[0278] In the foregoing, a complete and informative description of one embodiment of the invention has been presented as illustrative and non-limiting examples. However, in light of the foregoing description, in conjunction with the accompanying drawings, various modifications and improvements may be apparent to those skilled in the relevant arts. However, any such or similar modifications of the invention remain within its scope.

Claims (53)

1. An encoding method, comprising: determining the number of blocks to be assigned to partitions, wherein the number of blocks to be assigned to partitions is one of the following: image width in code tree packets (CTU), image height in CTU, number of CTU lines in a tile; specifying the number of explicitly sized partitions to be assigned; specifying the sizes of sections of an explicitly specified size or number of blocks in them; And logically getting the number of partitions of equal size to be assigned, wherein said logical derivation of the number of equally sized partitions to be assigned includes: determining the number of blocks still to be assigned to the partitions by subtracting the number of blocks in the explicit size partitions from the number of blocks to be assigned to the partitions; assigning partitions to explicitly sized partitions in accordance with the sizes or number of blocks in the explicitly sized partitions and in accordance with a predetermined or specified scan order; And assigning partitions to partitions of equal size by dividing blocks still to be assigned to partitions by the number of partitions of equal size and according to a predetermined or specified scan order. 2. An encoding device, comprising: means for determining the number of blocks to be assigned to partitions, wherein the number of blocks to be assigned to partitions is one of the following: image width in code tree packets (CTU), image height in CTU, number of CTU lines in a tile; means for specifying the number of explicitly sized partitions to be assigned; means of specifying the sizes of partitions of an explicitly specified size or the number of blocks in them; And means of logically obtaining the number of partitions of equal size to be assigned, wherein said means of logically deriving the number of equally sized partitions to be assigned include: means for determining the number of blocks still to be assigned to the partitions by subtracting the number of blocks in the explicitly sized partitions from the number of blocks to be assigned to the partitions; means for assigning partitions to explicitly sized partitions in accordance with the sizes or number of blocks in the explicitly sized partitions and in accordance with a predetermined or specified scan order; And means for assigning partitions to partitions of equal size by dividing the blocks still to be assigned to partitions by the number of partitions of equal size and in accordance with a predetermined or specified scan order. 3. The device according to claim 2, further comprising: means for specifying the number of sections of an explicit size in a high-level syntactic structure; And means for specifying the sizes of sections of an explicit size and/or the number of sections of equal size in a low-level syntactic structure. 4. A decoding method, comprising: determining the number of blocks to be assigned to partitions, wherein the number of blocks to be assigned to partitions is one of the following: image width in code tree packets (CTU), image height in CTU, number of CTU lines in a tile; decoding the number of explicitly sized partitions to be assigned; decoding the sizes of sections of an explicitly specified size or number of blocks in them; And logically getting the number of partitions of equal size to be assigned, wherein said logical derivation of the number of equally sized partitions to be assigned includes: determining the number of blocks still to be assigned to the partitions by subtracting the number of blocks in the explicit size partitions from the number of blocks to be assigned to the partitions; assigning partitions to explicitly sized partitions in accordance with the sizes or number of blocks in the explicitly sized partitions and in accordance with a predetermined or specified scan order; And assigning partitions to partitions of equal size by dividing blocks still to be assigned to partitions by the number of partitions of equal size and according to a predetermined or specified scan order. 5. A decoding device, comprising: means for determining the number of blocks to be assigned to partitions, wherein the number of blocks to be assigned to partitions is one of the following: image width in code tree packets (CTU), image height in CTU, number of CTU lines in a tile; means for decoding the number of explicitly sized partitions to be assigned; means for decoding the sizes of sections of an explicitly specified size or number of blocks in them; And means of logically obtaining the number of partitions of equal size to be assigned, wherein said means of logically deriving the number of equally sized partitions to be assigned include: means for determining the number of blocks still to be assigned to the partitions by subtracting the number of blocks in the explicitly sized partitions from the number of blocks to be assigned to the partitions; means for assigning partitions to explicitly sized partitions in accordance with the sizes or number of blocks in the explicitly sized partitions and in accordance with a predetermined or specified scan order; And means for assigning partitions to partitions of equal size by dividing the blocks still to be assigned to partitions by the number of partitions of equal size and in accordance with a predetermined or specified scan order. 6. The apparatus of claim 5, wherein said partitions are one or more of the following: tile columns, tile rows, brick rows. 7. The device according to claim 5 or 6, further comprising: means for decoding the number of explicitly sized partitions from the high-level syntactic structure; And means for decoding the sizes of sections of an explicitly specified size and/or the number of sections of equal size from the low-level syntactic structure. 8. The device according to any one of paragraphs. 5-7, further comprising: a means of inferring that the number of partitions of an explicit size is 1. 9. The apparatus of claim 8, wherein said means for logically deriving the number of partitions of equal size to be assigned further comprises: means for determining a set or list of partition sizes over which the number of blocks still to be assigned to partitions can be evenly distributed; means for inferring that the number of partitions of equal size is 1 if the number of elements in said set or list is 1; And means for specifying an index corresponding to an element of said set or list, wherein the index indicates the number of partitions of equal size to be assigned. 10. The device according to claim 9, further comprising: means for limiting a set or list of partition sizes over which said number of blocks still to be assigned can be uniformly distributed by excluding partition sizes smaller than a threshold, the threshold being predetermined or decoded. 11. The device according to claim 9 or 10, further comprising: means for decoding an index corresponding to an element of said set or list using a fixed length codeword, wherein the length of the codeword is determined by the number of elements in the set or list.

Images