RU2787545C1 - Device, method and machine-readable media for video encoding and video decoding - Google Patents

Abstract

FIELD: video technology.

SUBSTANCE: invention relates to the field of encoding and decoding of a video signal. A video encoding method is proposed, which contains: determining the number of units to be assigned to partitions and initialized as unassigned; specifying or logically determining the number of partitions of an explicitly specified size to be assigned; specifying the sizes for partitions of an explicitly specified size and the corresponding marking of unassigned units as assigned to partitions in a predetermined scanning order; specifying the number of units; cyclic assignment of the said number of units to partitions and the corresponding marking of unassigned blocks as assigned in a predetermined scanning order until the number of unassigned blocks becomes less than the mentioned number of units; and the assignment of unassigned units to the last partition, if the number of unassigned units is greater than 0.

EFFECT: optimal signaling of various options for splitting into tiles and bricks, a rectangular area of the lines of the code tree unit (CTU) inside a specific tile in the image, which provides an increase in coding efficiency.

15 cl, 18 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 element of an image 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 multiple smaller coding units, CUs, with a minimum size of 8×8 pixels, based on a quadtree structure. 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 blocks that are sequential in tile scan order and are part of 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) from the Moving Picture Experts Group (MPEG) and the 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 rows of CTUs 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 tiling and bricking, which in many respects is not optimal. In particular, this concerns the bit rate required for such signaling.

The essence of the invention

[0005] Hereinafter, an improved coding method will be discussed that aims to at least partially solve the problems described above.

[0006] The scope of the present invention is defined by the independent claims. Embodiments of the present invention and features thereof not falling within the scope of the independent claims, if any, should be considered as examples useful in understanding the various embodiments of the present invention.

[0007] The method, in accordance with the first aspect of the present invention, includes determining the number of blocks to be assigned to sections and initialized as unassigned; an indication or logical determination of the number of partitions of an explicit size to be assigned; specifying sizes for explicitly sized partitions and appropriately marking unassigned blocks as assigned to partitions in a predetermined scan order; specifying the number of blocks; cyclically assigning said number of blocks to partitions and correspondingly marking unassigned blocks as assigned in a predetermined scan order until the number of unassigned blocks is less than said number of blocks; and assigning, if the number of unassigned blocks is greater than 0, unassigned blocks to the last partition.

[0008] 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, columns of a grid used to indicate splitting into sub-images , the string of the grid used to specify the split into sub-images.

[0009] In accordance with one of the embodiments of the present invention, the mentioned blocks are one or more of the following: rectangular blocks of image samples, cells of the grid used to indicate the partition into sub-images.

[0010] An apparatus according to a second aspect of the present invention includes means for determining a number of blocks to be assigned to partitions and initialized as unassigned; means for specifying or logically determining the number of explicitly sized partitions to be assigned; means for specifying sizes for partitions of an explicit size, and means for appropriately marking unassigned blocks as assigned to partitions in a predetermined scan order; means for indicating the number of blocks; means for cyclically assigning said number of blocks to partitions and means for appropriately marking unassigned blocks as assigned in a predetermined scan order until the number of unassigned blocks is less than said number of blocks; and assignment means, if the number of unassigned blocks is greater than 0, unassigned blocks to the last section.

[OOP] The method according to the third aspect of the present invention includes determining the number of blocks to be assigned to partitions; determining the number of explicitly sized partitions to be assigned; sizing partitions of an explicit size and appropriately marking unassigned blocks as assigned to partitions in a predetermined scan order; determining the number of blocks; cyclically assigning said number of blocks to partitions and correspondingly marking unassigned blocks as assigned in a predetermined scan order until the number of unassigned blocks is less than said number of blocks; and assigning, if the number of unassigned blocks is greater than 0, unassigned blocks to the last partition.

[0012] In accordance with one embodiment of the present invention, determining the number of explicit size partitions to be assigned includes decoding the number of explicit size partitions to be assigned from the syntax structure; determining the sizes of explicitly sized partitions includes decoding the sizes of the explicitly sized sections from the syntactic structure; and determining the number of blocks includes decoding the number of blocks from the syntax structure.

[0013] An apparatus according to a fourth aspect of the present invention includes means for determining the number of blocks to be assigned to partitions; means for determining the number of explicitly sized partitions to be assigned; means for sizing partitions of an explicit size, and means for appropriately marking unassigned blocks as assigned to partitions in a predetermined scan order; means for determining the number of blocks; means for cyclically assigning said number of blocks to partitions and means for appropriately marking unassigned blocks as assigned in a predetermined scan order until the number of unassigned blocks is less than said number of blocks; and assignment means, if the number of unassigned blocks is greater than 0, unassigned blocks to the last section.

[0014] 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 execution, by the device, at least the methods described above and one or more related embodiments of the present invention.

Brief description of the drawings

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

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

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

[0018] 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;

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

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

[0021] 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);

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

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

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

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

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

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

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

[0029] in FIG. 14a and 14b show flowcharts for an encoding and decoding method in accordance with yet another embodiment of the present invention; and

[0030] in FIG. 15 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 of the embodiments of the invention

[0031] The corresponding apparatus 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.

[0032] The 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.

[0033] 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 screen.

[0034] 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.

[0035] 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.

[0036] 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.

[0037] 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).

[0038] 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.

[0039] 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.

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

[0041] As an example, in FIG. 3 shows a mobile phone 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.

[0042] Examples of communication devices in system 10 include, but are not limited to, an electronic device or device 50, a combination of a personal digital assistant (PDA) and a mobile phone 14, a PDA 16, an 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.

[0043] Embodiments of the present invention may also be implemented in a set top box, ie. 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.

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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.

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

[0049] 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).

[0050] 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 area of the image (or "block of pixels"), 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 area), 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 pixel representation fidelity (image quality) and the size of the resulting encoded video representation (file size or bit rate).

[0051] The source of information for inter prediction are previously decoded pictures (called reference pictures). In intra block copying (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.

[0052] 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. Intrinsic prediction can be either spatial, or it can refer to the transformation itself, 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.

[0053] 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.

[0054] 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 .

[0055] 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 .

[0056] 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 may be used as a reference image against which the future refinement level image 400 is compared when performing inter prediction operations.

[0057] Provided that the base layer is selected as the 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.

[0058] 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.

[0059] 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.

[0060] 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.

[0061] Entropy encoding/decoding can be performed in many different ways. For example, context-dependent encoding/decoding may be used, 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 encoding/decoding, alternatively or in addition, may be performed using variable codeword length encoding schemes, such as Huffman encoding/decoding or Exponential Golomb encoding/decoding. The decoding of encoding parameters from an entropy-encoded bitstream, or from codewords, may be referred to as parsing.

[0062] 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).

[0063] 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.

[0064] 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.

[0065] 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 and ITU consortium to replace HEVC/H.265 standard.

[0066] This section provides key definitions, describes the structure of the bitstream and encoding, as well as 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, but rather, this description is provided as one example of a basis for implementing embodiments of the present invention in part or in full. When the VVC standard or draft versions of it are mentioned below, it is to be understood that the present description is in accordance with the draft VVC specification, and there may be changes in later draft versions or in the final version (or versions of VVC), in which case the description of embodiments of the present invention may be adjusted to match the final version (or versions) of the VVC standard.

[0067] 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.

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

[0069] Each syntax element can be described by the name and one form descriptor of its encoded representation. The convention that the names of syntax elements consist of lowercase letters with underscores may apply. 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.

[0070] 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 whose most significant bit 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.

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

[0072] 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 apply that variables beginning with a lowercase letter are used only in the context of their evaluation.

[0073] 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.

[0074] A flag is a variable, or a one-bit syntax element, having one of two possible values: 0 or 1.

[0075] 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.

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

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

[0078] Procedures for describing the decoding of syntax elements may be defined. A procedure can have an independent description and call. It may be specified that all syntax elements and variables named in uppercase letters relating to the current syntax structure and all syntax structures dependent on it are available in the procedure declaration and its invocation, and it may also be specified that the procedure declaration may have variables named in lower case, explicitly given 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.

[0079] 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 the modulo endowment (i.e., the remainder of the division).

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

[0081] 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.

[0082] 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).

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

- Green, blue and red components (GBR or RGB).

- Arrays representing other unspecified monochrome or 3-component color samples (eg YZX, also called XYZ).

[0083] 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.

[0084] 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.

[0085] 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.

[0086] Coding formats or standards may allow encoding arrays of samples as separate color planes in a bitstream, and accordingly decoding of separately encoded color planes from the bitstream can be performed. 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.

[0087] 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 element of the image or image sub-regions 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 N×N 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 N×N for some value of N, such that dividing the image component into coding tree blocks would be a split. A coding tree unit (CTU) can be defined as a luminance sample code tree block, two corresponding chrominance sample code tree blocks in the case of an image having three sample arrays, or a code tree block in a monochrome image or an image that is being coded. 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, or 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 maximum allowed size CU coding unit is usually called LCU (largest coding unit) or Code Tree Packet (CTU), while the image in the video is divided into non-overlapping LCUs.

[0088] In the HEVC standard, a CU coding unit consists of one or more prediction units (PU) defining a procedure for predicting samples in a coding block, as well as one or more transform units (TU) defining a procedure for encoding a prediction error. for samples in this coding block. Typically, a 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 associated prediction information that specifies 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).

[0089] Similarly, each transform block may be associated with information describing a prediction error decoding procedure for values in that transform block (including, for example, information about DCT transform coefficients). Whether or not per-CU prediction error coding is applied is typically signaled in syntax elements at the coding block level. If there is no residual or prediction error associated with the CU, then it can be considered that there are no transform units, TUs, for the given coding unit. Information about dividing the image into coding units, CU, and 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.

[0090] 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/VVC 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 tree structures of many types, there are four types of partitions: vertical binary partition, horizontal binary partition, vertical ternary partition, and horizontal ternary partition. Such multitype tree leaves 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.

[0091] 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. For the purpose of transmission over packet data networks or storage in structured files, NAL units may be encapsulated in packets or similar structures.

[0092] 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, the 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.

[0093] The NAL block is a syntax structure containing an indication of the type of data following 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.

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

[0095]

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

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

[0098] 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.

[0099] Some of the parameter set types are described below, however, it should be understood that others may exist, and 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. A header parameter set (HPS) was introduced to include parameters that can change for each individual image.

[0100] A bitstream is a sequence of bits, which, in some formats or coding standards, may take the form of a stream of NAL units or a byte stream, which allows a 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 designated 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.

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

[0102] The expression "together with the bitstream" (e.g., "an indication along with the bitstream") or "together with the encoded block of the bitstream" (e.g., "an 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 data outside the baseband remains associated with, but not included in, the bitstream or coded block, respectively. The expression "decoding along with the bitstream", or "together with the encoded block of the bitstream", or similar expressions, may refer to the decoding of data arriving outside the base band, which is referenced (and which can be received by transmission, signaling or storage data outside the baseband) and which are associated with a bitstream or a coded block, respectively. For example, the phrase "together 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, for example, as boxes in a sample record for a track containing a bitstream, a group of samples for a track containing a bitstream, or a sync metadata track associated with a track containing a bitstream.

[0103] 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.

[0104] 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 in the present description refer to 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 in 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.

[0105] 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 blocks 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 blocks organized as a sequence, in tile scan order, and contained in one NAL block. 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, where the slice segment header is defined as part of an encoded slice segment including the data elements that refer to the first one. the 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.

[0106] Accordingly, video coding standards and specifications may allow the division, at the encoder, of an 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 with slice boundary crossings may be prohibited. Accordingly, slices can be thought of as a way of dividing an encoded picture into independently decodable parts, 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.

[0107] The following describes the partitioning of images into slices, tiles and bricks in the draft VVC standard (ie, version 5 of the VVC draft). In other versions of the VVC project, the partitioning of images into slices, tiles, and bricks can be defined in a similar way.

[0108] 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).

[0109] A tile is a sequence of Code Tree Units (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.

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

[0111] 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.

[0112] A brick scan order can be defined as the specific order of consecutive CTUs into which images are divided, where the CTUs within a brick are sequential in CTU raster scan order, the bricks in a tile are sequential in the tile brick raster scan order, and the tiles in the images are arranged sequentially in the order in which the raster of image tiles is scanned. It may be required, for example, in a coding standard, that coded slice NALs must be arranged in order of increasing CTU address in brick scan order for the first CTU of each coded slice NAL, it may be determined that the CTU address is increased in order scanning the CTU raster inside 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.

[0113] 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 (top left tile contains 1 brick, top right tile contains 5 bricks, bottom left tile contains 2 bricks, and the bottom right tile contains 3 bricks) and 4 rectangular slices.

[0114] 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.

[0115] There are two modes for specifying a grid of tiles: uniform (indicated using the syntax element uniform_tile_spacing_flag equal to 1) and explicit. With uniform tile spacing, they have the same width, with the possible exception of the rightmost column of tiles, and the same height, with the possible exception of the bottommost row of tiles. For an explicit tile spacing, the widths and heights of columns and rows of tiles (respectively) (in CTUs) are specified explicitly, with the exception of the rightmost column and the bottommost row (respectively).

[0116] 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.

[0117] When using rectangular slices, then for each slice, using a syntax structure including and following the syntax element num_slices_in_pic_minus1, indicate the following:

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

- Difference of serial numbers of the lower right brick of the slice and the upper left brick.

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

[0119] The flag single_tile_in_pic_flag equal to 1 specifies that there is only one tile in each image referring to this PPS. 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. Note: In the absence of additional bricking within a tile, the entire tile is referred to as 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.

[0120] The uniform_tile_spacing_flag 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_minus1 and tile_rows_height_minus1 syntax elements. The 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 using the num_tile_columns_minus1 and num_tile_rows_minus1 syntax elements, as well as the list of tile_column_width_minus1[i] and tile_row_height_minus1[i] syntax element pairs. If it is absent, the value of the uniform_tile_spacing_flag flag is set to 1.

[0121] The value of tile_cols_width_minus1 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_minus1 must be in the range 0 to PicWidthlnCtbsY - 1 inclusive. If it is absent, the value of tile_cols_width_minus1 is taken equal to PicWidthlnCtbsY - 1.

[0122] The value of tile_rows_height_minus1 plus 1 specifies 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_minus1 must be in the range 0 to PicHeightlnCtbsY 1 inclusive. If it is absent, the value of tile rows height minus 1 is taken equal to PicHeightlnCtbsY - 1.

[0123] The value of num_tile_columns_minus1 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_minus1 must be in the range from 0 to PicWidthlnCtbsY - 1 inclusive. If single_tile_in_pic_flag is 1, num_tile_columns_minus1 is set to 0. Otherwise, when uniform_tile_spacing_flag is 1, num_tile_columns_minus1 is set to the value specified in the CTB raster scan, tile scan, and brick scan procedure.

[0124] The value num_tile_columns_minus1 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 numtilerowsminus 1 must be in the range 0 to PicHeightlnCtbsY - 1 inclusive. If single_tile_in_pic_flag is 1, num_tile_columns_minus1 is set to 0. Otherwise, when uniform_tile_spacing_flag is 1, numtilerowsminus 1 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 minus 1+1) * (num_tile_columns_minus1+1). When single_tile_in_pic_flag is 0, NumTilesInPic must be greater than 1.

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

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

[0127] 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.

[0128] 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.

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

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

[0131] The value num_brick_rows_minus1 [i] plus 1 determines the number of bricks into which the i-th tile is divided when the flag uniform_brick_spacing_flag[i] is 0. If present, the value num_brick_rows_minus1[i] must be in the range from 1 to RowHeight[i ] - 1 inclusive. If brick_split_flag[i] is 0, then num_brick_rows_minus1[i] is set to 0. Otherwise, when uniform_brick_spacing_flag[i] is 1, num_brick_rows_minus1[i] is set to the value specified in CTB raster scan, tile scan, and brick scan. .

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

[0133] The following variables are calculated, and when the uniform_tile_spacing_flag flag is equal to 1, the values num_tile_columns_minus1 and num_tile_columns_minus1 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_minus1 [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_columns_minus1 inclusive, determines the height of the j-th row of tiles, measured in CTB,

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

- list CtbAddrBsToRs [ctbAddrBs] for ctbAddrBs in the range from 0 to PicSizelnCtbsY - 1 inclusive, defines the conversion from the CTB address when scanning bricks to the CTB address when scanning the CTB image raster,

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

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

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

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

[0135] A 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. The rect_slice_flag flag of 1 specifies that the bricks in all slices cover a rectangular area of the image, and the slice information is signaled in the PPS. When the single_brick_per_slice_flag is 1, the rect_slice_flag is set to 1.

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

[0137] The value of top_left_brick_idx[i] determines the serial number 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.

[0138] The bottom_right_brick_idx_delta[i] value defines the difference between the ordinal number 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.

[0139] For bitstream compatibility, a requirement is made 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:

[0140] So, a fairly complex syntactic structure has been created to signal the division into tiles and bricks. 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 the number of bits in the signaling.

[0141] Version 6 of the VVC project supports sub-images. A sub-image is a rectangular area of one or more slices within an image, said one or more slices must be complete. Accordingly, a sub-image consists of one or more slices that collectively cover a rectangular area of the image. The sub-image slices may be required to be rectangular. The splitting of an image into sub-images may be indicated in and/or decoded from the SPS. One or more of the following sub-image properties may be indicated (eg by an encoder) or decoded (eg by a decoder), or may be logically obtained (eg by an encoder and/or decoder), either together or for each sub-image individually: i) must whether the sub-image is processed as an image in the decoding procedure; in some cases this property excludes in-loop filtering operations - this can be separately specified/decoded/be obtained logically; ii) whether the in-loop filtering operations should be performed crossing sub-image boundaries or not.

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

[0143] The encoding method according to the first aspect of the present invention, which is shown in FIG. 7 includes: encoding (700) a bitstream including tile column indication and brick height indication for one or more tile columns at the same time, or encoding, within or with the bitstream, tile column indication and brick height indication for one or more columns tiles at the same time; logical determination (702), in case of detection of rows of bricks that are on the same line throughout the image, potential rows of tiles; a boolean determination (704) or an indication of 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 grid of tiles includes an integer number of code tree blocks and is broken into one or more bricks, and a brick contains an integer number of lines of code tree blocks within the tile.

[0144] The decoding method according to the first aspect of the present invention includes decoding, from or with a bitstream, specifying tile columns and specifying brick heights for one or more tile columns simultaneously; logical determination, in case of detection of rows of bricks that are on the same line throughout the image, potential rows of tiles; logically determining 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 case, a tile in the grid of tiles includes an integer number of code tree blocks and is divided into one or more bricks, and the brick contains an integer number of lines of code tree blocks within the tile.

[0145] 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 obtained as the boundaries of bricks located 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. .

[0146] 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.

[0147] Therefore, by specifying only tile columns and brick heights for each tile column, as well as logically determining 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.

[0148] 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 generating a bitstream fragment according to the proposed syntax and semantics and decoding decoding a bitstream fragment according to the proposed syntax and semantics.

[0149] Syntax and semantics example 1:

[0150] 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_minus1 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_minus1 syntax element as well as the tile_column_width_minus1[i] syntax element list. If it is absent, the value of uniform_tile_col_spacing_flag is taken equal to 1.

[0151] The semantics of tile_cols_width_minus1, num_tile_columns_minus1 and tile_column_width_minus1[i] are defined identically to the semantics of the syntax elements with the same names in version 5 of the VVC project.

[0152] If the flag uniform_tile_col_spacing_flag is 1, NumTileColsInPic is set equal to PicWidthlnCtbsY / (tile_cols_width_minus1+1)+PicWidthlnCtbsY % (tile_cols_width_minus1+1). Otherwise, NumTileColsInPic is set to num_tile_columns_minus 1+1.

[0153] 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_minus1[i] syntax element. The uniform_brick_spacing_flag[i] flag of 0 specifies that horizontal brick boundaries are not necessarily evenly spaced across the i-th tile column and are signaled using the num_brick_rows_minus1 [i] syntax element and the brick_row_height_minus1[i] [j] syntax element list. If it is absent, the value of the uniform_brick_spacing_flag[i] flag is taken equal to 1.

[0154] The value of brick_height_minus1[i] plus 1 determines the height of the rows of bricks, excluding the bottom brick in the i-th column of tiles, measured in CTB when the flag uniform_brick_spacing_flag[i] is 1.

[0155] The value num_brick_rows_minus1 [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.

[0156] The value of brick_row_height_minus1[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.

[0157] Syntax and semantics example 2:

[0158] Example 2 is similar to example 1, however, in addition, the encoder indicates and/or the decoder decodes whether the current tile column's bricking is identical to the previous tile column.

[0159] 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_minus1[i-1] is present, brick_height_minus1[i] is set to brickheightminus 1 [i-1].

- When num_brick_rows_minus1[i-l] is present, num_brick_rows_minus1[i] is set to num_brick_rows_minus1[i-1] and brick_row_height_minus1[i][j] is set to brick_row_height_minus1[i-1][j] for each value] in the range of 0 up to num_brick_rows_minus1 [i] - 1 inclusive.

[0160] 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.

[0161] An encoding method in accordance with this second aspect of the 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.

[0162] 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.

[0163] 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 units (for example, when sections are columns of tiles), image height in CTU units (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 lines in a tile (for example, when sections are bricks of a tile).

[0164] According to 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.

[0165] 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.

[0166] Therefore, by specifying the number of blocks to be assigned to partitions 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 partitions are assigned to the remaining sections evenly.

[0167] 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. Thus, 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 (CTBs) to be assigned to the 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.

[0168] 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.

[0169] 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 parallel to the bitstream, the number of partitions, such as columns of tiles and/or rows of tiles, to be assigned is decoded, and the number of blocks, NU, such as code tree blocks (CTBs) to be assigned to the partitions, 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 with the bitstream that all remaining blocks still to be assigned should be assigned to the remaining section.

[0170] However, if NP>1, it is checked whether the number of blocks, NU, to be assigned is divisible without a 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 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.

[0171] 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 generating a bitstream fragment according to the proposed syntax and semantics and decoding decoding a bitstream fragment according to the proposed syntax and semantics.

[0172] 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.

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

[0174] The flag rem_tile_row_equal_flag[i], equal to 0, specifies that rows of tiles with serial numbers 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, equal to 1, determines that the rows of tiles with serial numbers in the range from 0 to i inclusive have equal height, measured in CTB, while tile_row_height_minus1 [j] is taken equal to remHeightlnCtbsY / (i+1) for each value ] in the range from 0 to i inclusive.

[0175] 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.

[0176] An exemplary implementation will be discussed below for another aspect of the present invention, i.e., syntax and semantics, including simultaneously 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 generating a bitstream fragment according to the proposed syntax and semantics and decoding decoding a bitstream fragment according to the proposed syntax and semantics.

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

[0178] The tile columns are indicated as follows:

- Specify the number of tile columns (num tile columns minus1).

- 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:

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

If the remaining width (measured in CTB) is divided without remainder by the number of tile columns still to be assigned, it is indicated whether the remaining tile columns have equal width (rem_tile_col_equal_flag[i]).

Если оставшиеся столбцы тайлов не имеют равную ширину, указывают ширину столбца тайла (tile_column_width_minus1[i]).

If the remaining tile columns are not of equal width, specify the tile column width (tile_column_width_minus1[i]).

[0179] The following is indicated in a loop that goes through the tile columns from left to right, for rectangular slices, and includes only one loop entry 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_jtrevious_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:

Указывают количество кирпичей в столбце тайлов (num_bricks_minus1[i]).

Specify the number of bricks in the tile column (num_bricks_minus1[i]).

В цикле, проходящем по кирпичам сверху снизу вверх, пока не будут пройдены все кирпичи столбца тайлов, или до тех пор, пока не будет указано, что все оставшиеся кирпичи в столбце тайлов имеют равную высоту, указывают следующее:

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

если оставшаяся высота (измеряемая в СТВ) делится на количество кирпичей, все еще подлежащих определению, указывают, имеют ли оставшиеся кирпичи равную высоту (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_minus1 [i] [j]).

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

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

[0181] The value num_tile_columns_minus1 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 num tile columns minus 1 must be in the range 0 to PicWidthlnCtbsY - 1 inclusive. When the flag single_tile_in_pic_flag is equal to 1, the value of num_tile_columns_minus1 is set to 0.

[0182] The flag rem_tile_col_equal_flag[i] equal to 0 specifies that the columns of tiles with serial numbers in the range from 0 to i inclusive do not have to have the same width, measured in CTB. The flag rem_tile_col_equal_flag[i] equal to 1 specifies that columns of tiles with serial numbers in the range 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.

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

[0184] Flag copy_previous_col_flag[i] equal to 0 specifies that num_bricks_minus1[i] is present. The copy_previous_col_flag[i] flag of 1 specifies all of the following:

- The value of num_bricks_minus1[i] is taken equal to num_bricks_minus1[i-1].

- The 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_minus1[i] inclusive, for which the value rem_brick_height_equal_flag[i-1][j] is present or received logically.

- The value of brick_height_minus1[i][j] is taken equal to brick height minus 1 [i-1] [j] for such values of j in the range from 0 to num bricks minus 1 [i] inclusive, for which the value of brick_height_minus1[i-1] [j] is present.

[0185] A copy_previous_col_flag[i] flag of 0 specifies that numbricksminus 1 [i] is present. The copy_previous_col_flag[i] flag of 1 specifies all of the following:

- The value num_bricks_minus1[i] is taken equal to num bricks minus1[i-1].

- The 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 numbricksminus 1 [i] inclusive, for which the value rem_brick_height_equal_flag[i-1][j] is present or received logically.

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

[0186] The flag rem_brick_height_equal_flag[i][j], equal to 0, specifies that bricks with serial numbers in the range from 0 to j inclusive in the i-th tile column do not necessarily have equal height, measured in CTB. The flag rem_brick_height_equal_flag[i][j] equal to 1 specifies that bricks with serial numbers in the range 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.

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

[0188] 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.

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

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

[0191] Lists colBrickHeight[i][j] for i in the range from 0 to num_tile_columns_minus1 inclusive and j in the range from 0 to num_bricks_minus1[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, which defines 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, which determines the location of the border of the j-th the rows of tiles measured in CTB, the NumTileRows value, and the NumTilesInPic value are obtained as follows:

[0192] When the single_tile_in_pic_flag flag is 0, NumTilesInPic must be greater than 1. A list tileColBd[i] for i in the range 0 to num tile columns minus 1+1 inclusive, specifying the location of the border of the i-th tile column, measured in CTB, is obtained in the following way:

[0193] As described below, the NumBricksInPic variable is calculated, which determines the number of bricks in the image referring to this PPS, and the lists BrickColBd[brickIdx], BrickRowBd [brickIdx], BrickWidth[brickIdx], BrickHeight[brickIdx] for brickIdx in the range from 0 to NumBricksInPic - 1 inclusive, defining the locations of vertical brick boundaries measured in CFI, the locations of horizontal brick boundaries measured in CFI, brick column widths measured in CFI, and brick column heights measured in CFI, and are logically obtained, 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_minus1[i].

[0194] 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) an indication or logical determination of 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) an indication or logical determination of the number of explicitly sized partitions to be assigned.

[0195] In accordance with one embodiment of the present invention, step d) includes the following steps: d1) specifying the number of blocks; d2) assigning that number of blocks to partitions cyclically until the number of unassigned blocks is less than the number of blocks; and d3) assigning, if the number of unassigned blocks is greater than 0, unassigned blocks to the last partition in a predetermined scan order.

[0196] Thus, the encoding method according to the above embodiment of the present invention can be implemented either independently or in combination with one or more other embodiments of the present invention, in accordance with the illustration of FIG. 14a. The method includes:

determining (1400) the number of blocks to be assigned to sections and initialized as unassigned; an indication or logical determination (1402) of the number of explicitly sized partitions to be assigned; specifying (1404) sizes for partitions of an explicit size and appropriately marking unassigned blocks as assigned to partitions in a predetermined scan order; indicating (1406) the number of blocks; cyclically assigning (1408) said number of blocks to partitions and correspondingly marking unassigned blocks as assigned in a predetermined scan order until the number of unassigned blocks is less than said number of blocks; and assigning (1410), if the number of unassigned blocks is greater than 0, unassigned blocks to the last section.

[0197] In accordance with one embodiment of the present invention, a 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 sections of an explicitly given size or number of blocks in them; and d) decoding or inferring the number of explicitly sized partitions to be assigned.

[0198] In accordance with one embodiment of the present invention, in the case of decoding, step d) includes the following steps: d1) decoding the number of blocks; d2) assigning that single number of blocks to partitions cyclically until the number of unassigned blocks is less than the number of blocks; and d3) assigning, if the number of unassigned blocks is greater than 0, unassigned blocks to the last partition in a predetermined scan order.

[0199] Thus, the decoding method according to the above embodiment of the present invention can be implemented either independently or in combination with one or more other embodiments of the present invention, in accordance with the illustration of FIG. 14b. The method includes:

determining (1450) the number of blocks to be assigned to partitions; determining (1452) the number of explicitly sized partitions to be assigned; determining (1454) sizes for partitions of an explicit size and appropriately marking unassigned blocks as assigned to partitions in a predetermined scan order; determining (1456) the number of blocks; cyclically assigning (1458) said number of blocks to partitions and correspondingly marking unassigned blocks as assigned in a predetermined scan order until the number of unassigned blocks is less than said number of blocks; and assigning (1460), if the number of unassigned blocks is greater than 0, unassigned blocks to the last section.

[0200] In accordance with one embodiment of the present invention, for encoding and/or decoding, the method further includes:

marking said number of blocks initially as unassigned, or equivalently, said number of blocks initially not assigned, for example as part of or in connection with step a) ;

- marking unassigned blocks as assigned according to the number of explicitly sized partitions to be assigned and the sizes of explicitly sized partitions, for example, as part of steps b) and/or c), or in connection with them;

marking unassigned blocks as assigned whenever said number of blocks are assigned to a partition, for example as part of or in connection with step 62.

[0201] Assigning blocks to partitions and/or marking unassigned blocks as assigned may be performed in accordance with the scan order. In one embodiment of the present invention, the scan order is predetermined, for example, in a coding standard. Scanning may be performed, for example, from left to right (for example, to assign CTU columns to tile columns), or from top to bottom (for example, to assign CTU rows to tile rows, or CTU rows within a tile to bricks. In one embodiment of the present invention, the encoder may select a scan order from a list of predefined scan orders and indicate the selected scan order, for example, as a sequence number in the list of predefined scan orders, in or along with the bitstream.In one embodiment of the present invention, the decoder may decode the scan order, for example , a sequence number in a list of predefined scan orders, from or with a bitstream.

[0202] In accordance with one embodiment of the present invention, for encoding and/or decoding, step c) further includes or is followed by a step of assigning sizes, or number of blocks, into explicitly sized partitions.

[0203] The size of an explicit size partition may be indicated as the number of blocks to be assigned.

[0204] In accordance with one embodiment of the present invention applicable to encoding and/or decoding, said blocks are one of the following: CTB, CTU, CTU row, CTU column, grid cell (in the case of a grid used to indicate a partition into sub-images), grid row (in the case of a grid used to indicate a sub-image split), grid column (in the case of a grid used to indicate a sub-image split).

[0205] In embodiments of the present invention applicable to encoding and/or decoding, information about blocks that are still unassigned may be stored. Once the number of blocks to be assigned to sections has been determined, all of these blocks can be marked as unassigned. When a block set is assigned to one of the partitions, that block set may be marked as assigned, or the "unassigned" marking in that block set may be removed or omitted. Marking blocks as assigned or unassigned, for example, can be an array type variable, or similar, in which each block to be assigned is represented by a single array entry, and the value of that array entry indicates whether the corresponding block has been assigned or not. In another example, the number of blocks still to be assigned, ie. the number of remaining unassigned blocks is maintained throughout the steps of an embodiment of the present invention.

[0206] 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 CTUs (for example, when sections are columns of tiles), image height in CTUs (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), number of rows of CTUs in a tile (for example, when sections are bricks of a tile) , image width in grid columns (in the case of a grid used to indicate sub-image splitting), image height in grid rows (in the case of a grid used to specify sub-image splitting).

[0207] 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, grid columns (in the case of a grid used to specify a partition into sub-images), grid lines (in the case of the grid used to indicate sub-images).

[0208] In accordance with one embodiment of the present invention applicable to encoding and/or decoding, in which step d includes steps d1, d2 and d3 described above, the following, or similar, syntax may be used:

[0209] The value num_exp_tile_columns_minus1 plus 1 determines the number of explicitly provided tile column widths.

[0210] num_exp_tile_rows_minus1 plus 1 specifies the number of explicitly provided tile row heights.

[0211] The value of tile_column_width_minus1[i] plus 1 specifies the width of the i-th tile column, measured in CTB, for i in the range from 0 to num_exp_tile_columns_minus1 - 1 inclusive. The value tile_column_width_minus 1 [num_exp_tile_columns_minus1] is used to calculate the width of tile columns with index numbers greater than or equal to num_exp_tile_columns_minus1.

[0212] The value tile_row_height_minus1[i] plus 1 determines the height of the i-th row of tiles, measured in CTB, for i in the range from 0 to num_exp_tile_rows_minus1 - 1 inclusive. The value tile_row_height_minus1 [num_exp_tile_rows_minus1] is used to calculate the row height of tiles with serial numbers greater than or equal to num_exp_tile_rows_minus1.

[0213] The brick_splitting_present_flag and brick_spit_flag[i] flags may be defined as described above.

[0214] NumTilesInPic can be taken equal to the number of tiles in the image. NumTileColumns can be taken equal to the number of tile columns in the image. The RowHeight[tileY] value can be taken equal to the number of CTU rows in tile in the Yth tile row.

[0215] The value num_exp_brick_rows_minus1[i] plus 1 determines the number of explicitly provided brick row heights in the i-th tile. In case of its absence, the value num_exp_brick_rows_minus1[i] can be taken equal to -1.

[0216] The value of brick_row_height_minus1[i][j] plus 1 defines the height of the j-ro brick in the i-th tile, measured in CTB, for j in the range from 0 to num_exp_brick_rows_minus1[i] - 1 inclusive. The brick_row_height_minus1[i][num_exp_brick_rows_minus1] value is used to calculate the row height of bricks with serial numbers greater than or equal to num_exp_brick_rows_minus1[i] in the i-th tile.

[0217] In accordance with one embodiment of the present invention, where the above syntax is used for encoding (or, respectively, for decoding, which is given below in brackets), tile columns are defined as follows:

- Indicate (or decode) the number of explicitly provided tile column widths, (num_exp_tile_columns_minus1).

- Explicitly provide (or decode and assign) tile column widths, from left to right, (tile_column_width_minus1[i]).

- The last explicitly provided (or decoded) tile column width (tile_column_width_minus1 [num_exp_tile_columns_minus1]) is repeated until columns of that width no longer fit within the image borders.

- Remaining CTUs not assigned to any tile column, if any, are assigned to the rightmost tile column.

[0218] The heights of the rows of tiles and rows of bricks are set similarly to the rows of tiles.

[0219] In accordance with one embodiment of the present invention, applicable to the above syntax, and applicable to encoding and/or decoding, a numTileColumns variable specifying the number of tile columns, and a colWidth[i] list for i in the range from 0 to numTileColumns - 1 inclusive, which determines the width of the i-th column of tiles, measured in CTB, is calculated as follows:

[0220] In accordance with one embodiment of the present invention, applicable to the above syntax, and applicable to encoding and/or decoding, a numTileRows variable specifying the number of tile rows, and a RowHeight[j] list for] ranging from 0 to numTileRows - 1 inclusive, which determines the height of the j-th row of tiles, measured in CTB, is calculated as follows:

[0221] In some of the embodiments of the present invention, the following may apply:

- The NumTilesInPic variable is set to numTileColumns * numTileRows.

- The list tileColBd[i] for i in the range from 0 to numTileColumns inclusive, specifying the location of the border of the i-th tile column, measured in CTB, is obtained as follows:

- The list tileRowBd[j] for j in the range from 0 to numTileRows inclusive, defining the location of the border of the j-th row of tiles, measured in CTB, is calculated as follows:

[0222] In accordance with one of the embodiments of the present invention, applicable to the above syntax, and applicable to encoding and/or decoding, the NumBricksInPic variable determining the number of bricks in the image referring to this PPS, and the 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, locations of horizontal brick boundaries measured in CBM, brick widths , measured in STV, and the height of the bricks:

[0223] 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 the explicitly sized partitions from the number of blocks to be assignment to sections, the method further comprising:

- designating partitions as explicitly sized partitions according to the sizes or number of blocks in the explicitly sized partitions, and according to a predefined or specified/decoded scan order;

assigning partitions as 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.

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

[0225] 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 predefined in the encoding standard).

[0226] 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 a sequence number (or similar information) corresponding to one of the elements of the set or list, whereby the sequence number indicates the number of partitions of equal size to be assigned.

[0227] 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, the minimum width of a tile column in the CTU may be predetermined or specified/decoded.

[0228] According to one embodiment of the present invention, the sequence number corresponding to an element of said set or list is encoded with a fixed length codeword, such as u(v), whereby 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

[0229] 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.

[0230] 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 derived as the boundaries of bricks that are on the same (horizontal) line in the entire image.

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

- if all brick boundaries on the same line do not form tile row boundaries, the encoder indicates, in or with the bitstream, and/or the decoder decodes, from or 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).

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

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

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

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

[0235] The flag tile_row_flag[i] equal to 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 a tile row border. The 0th horizontal border, where the horizontal borders of the bricks are on the same line across the width of the image, is the top border of the image.

Specifying tile columns. identically broken into bricks

[0236] In some of the embodiments of the present invention, the syntax includes indicating 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 logically determined, that all columns of tiles of equal width have the same bricking. In yet another example, the ordinal number of the tile column from which the bricking should 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.

[0237] In one embodiment of the present invention, the encoder indicates, in or with the bitstream, and/or the decoder decodes, from or 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.

[0238] In one embodiment of the present invention, the encoder indicates, in or with the bitstream, and/or the decoder decodes, from or with the bitstream, the number of contiguous tile columns, in loop entry order (e.g., tile column scan from left to right) having the same partition into bricks. For example, a syntax element named num_tile_cols_with_same_brick_partitioning_minus1[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.

[0239] In one of the embodiments of the present invention, the encoder may indicate, in or with the bitstream, and/or the decoder may decode, from or 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. In another of the embodiments of the present invention, such an indication may be in the syntactic structure at the image level, for example, in the PPS. 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 embodiment of the present invention, a method for handling the absence of syntax elements related to indicating that columns of tiles are identically bricked, indicates an encoder, in or with a bitstream, for example, in an SPS, and/or decodes a decoder, from bit stream or together with it, for example, from SPS. 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.

[0240] In some of the embodiments of the present invention, the number of blocks to be assigned to sections is determined, or logically obtained. The number of blocks can be, for example, the number of CTU columns in a picture, the number of CTU rows in a picture, or the number of CTU rows in a tile. When decoding, the number of blocks to be assigned to partitions may be decoded from the SPS and/or PPS. In some of the embodiments of the present invention, it may be desirable to eliminate parsing dependencies between syntax structures, and all syntax elements sufficient to logically determine the number of blocks are included in one syntax structure, for example, in a PPS. For example, the PPS can include image width in luminance samples, image height in luminance samples, and CTU size, which makes it possible to logically obtain the number of CTU columns in the image and the number of CTU rows in the image.

[0241] For example, the u(2) encoded syntax element log2_pps_ctu_size_minus5 may be included in the PPS. The value of log2_pps_ctu_size_minus5 plus 5 determines the size of the code tree block in each of the CTUs. A log2_pps_ctu_size_minus5 value of 0, 1, or 2 specifies that the luminance code tree block size in each CTU is 32x32, 64x64, or 128x128 luma samples, respectively. A log2_pps_ctu_size_minus5 value may be required to be less than or equal to 2. A log2_pps_ctu_size_minus5 value of log2_ctu_size_minus5 may be required to be specified in the SPS.

Specifying split into sub-images

[0242] It should be noted that many of the considered embodiments of the invention for indicating a partition into slices, tiles and / or bricks, does not depend on the method of specifying sub-images. This section presents embodiments of the present invention for specifying and/or decoding the partitioning of an image into sub-images. Many of the embodiments of the present invention in this section can be used independently of other embodiments of the invention, for example, to indicate a partition into slices, tiles and/or bricks, however this is not required.

[0243] In accordance with one embodiment of the present invention, the grid used in sub-picture split signaling is indicated in or with a bitstream (e.g., in SPS), or decoded, from or in conjunction with a bitstream (e.g., from SPS). The cells of this grid define the blocks according to which the boundaries of the sub-images are signaled. That is, the border of the sub-image can only be on the border of the specified grid.

[0244] In accordance with one embodiment of the present invention, the grid is indicated and/or decoded using the CTU as the elementary unit (or similar elementary coding units in the codec).

[0245] In accordance with one embodiment of the present invention, signaling includes indicating information about the number of grid columns, the number of grid rows, grid column widths (eg, measured in CTU counts), and grid row heights (eg, measured in CTU counts). For example, the following syntax might be used:

[0246] The value of num_Id_columns_minus1 specifies the number of columns into which the image is split, minus 1. The value of num_Id_rows_minus1 specifies the number of rows into which the image is split, minus 1. The value of Id_column_width_minus1[i] plus 1 specifies the width of the i-th column, measured in code tree blocks . The value of Id_row_height_minus1[i] plus one determines the height of the i-th row, measured in blocks of the code tree. The rightmost grid column can be thought of as consisting of code tree block columns not assigned to other grid columns. The bottommost grid row can be considered to consist of code tree blocks not assigned to the remaining grid rows.

[0247] According to yet another example, the following syntax may be used:

[0248] When the signaling described above is applied, all grid columns are of equal width, except possibly the rightmost grid column, which can be considered to be composed of code tree block columns not assigned to other grid columns. Likewise, all grid lines may be of equal height, except possibly for the bottommost grid line, which may be considered to be composed of code tree blocks not assigned to other grid lines. The value of Id_column_width_minus1 plus 1 specifies the width of the grid columns, measured in code tree blocks. The value of Id_row_height_minus1 plus one determines the height of the grid rows, measured in code tree blocks.

[0249] In accordance with one of the embodiments of the present assignment of grid cells to sub-images indicate, in or along with the bitstream (for example, in SPS), and / or decode, from or along with the bitstream (for example, from SPS) .

[0250] In one embodiment of the present invention, the assignment of grid cells to sub-pictures is indicated by and/or decoded from the lower right grid cell sequence number for each sub-picture (perhaps other than the last sub-picture, for which the lower right cell of a cell can be considered the lower right cell the entire grid). For example, the following syntax, or a similar one (which can be added after any of the above or similar syntaxes) may be used:

The value num_subpics_minus2 plus two determines the number of sub-images in the image. The value of bottom_right_grid_idx_length-minus1 plus one determines the number of bits used to represent the bottom right_grid_idx_delta[i] syntax element. The bottom right_grid_idx_delta[i] value, when i is greater than 0, defines the difference between the grid cell number located in the lower right corner of the i-th subimage and the grid cell number in the lower right corner of the (i - 1)th subimage. The bottom_right_grid_idx delta[0] value defines the ordinal number of the cell in the lower right corner of the 0th subimage. The lower right corner of the last sub-image is considered the lower right grid cell. A grid_idx_delta_sign_flag[i] flag of 1 indicates a positive bottom_right_grid_idx_delta[i] sign. The sign_bottom_right_grid_idx_delta[i] flag of 0 indicates the negative sign of bottom_right_grid_idx_delta[i]. The variables NumGridRows, NumGridCols, and NumGridCellsInPic can be logically defined to equal the number of grid rows, grid columns, and grid cells in the image, respectively. Variables TopLeftGridIdx[i], BottomRightGridIdx[i], NumGridCellsInSubpic[i] and GridCellsToSubpicMap[j], which determine the ordinal number of the grid cell located in the upper left corner of the i-th subimage, the ordinal number of the grid cell located in the lower right corner of i- th sub-image, the number of grid cells in the i-th sub-image, and the correspondence of grid cells to sub-images are calculated as follows:

Specifying a tiling as an additional division of a sub-image tiling

[0251] In accordance with one of the embodiments of the present invention, which can be used in conjunction with other variants of the invention or independently, the division of an image into sub-images is indicated, in or together with a bitstream, for example, in SPS, and / or decoded, from the bitstream or together with it, for example, from SPS, and the partitioning into columns of tiles, rows of tiles and / or bricks indicate, in or together with the bitstream, for example in PPS, and / or decode, from the bitstream or together with them, for example from PPS, on the basis of splitting into sub-images.

[0252] In accordance with one embodiment of the present invention, an encoder indicates tile-column boundaries, in or with the bitstream, and/or a decoder decodes tile-column boundaries, from or with the bitstream, as described below. Since the vertical borders of the rectangular slices coincide with the borders of the tile columns, and since the subimages consist of one or more complete rectangular slices, it can be concluded that the border of the tile columns coincides with the vertical border of the subimage. Thus, the vertical boundaries of the sub-images are received (eg, at an encoder) or decoded (eg, at a decoder) and inferred to be tile-column boundaries. In addition, the encoder indicates, in or with the bitstream, e.g. PPS, and/or the decoder decodes, in or out of the bitstream, e.g. PPS, whether there are additional tile column boundaries (in addition to those which have been inferred from the vertical borders of the sub-image). For example, the tile_col_splitting_present_flag flag may be specified, in or with the bitstream (eg, by an encoder) and/or decoded, from or with the bitstream (eg, by a decoder). The flag tile_col_splitting_present_flag equal to 0 specifies that the tile column boundaries are identical to the received or decoded sub-image vertical boundaries. The tile_col_splitting_present_flag flag of 1 specifies that there are additional tile columns in addition to the columns inferred from the subimage vertical borders.

[0253] In one embodiment of the present invention, when an encoder indicates, in or with a bitstream, such as in a PPS, and/or a decoder decodes, in or with a bitstream, such as in a PPS, that there are additional tile column borders (in addition to those inferred from sub-image vertical borders) apply as described below. The vertical borders of sub-images that are not image borders may be ordered, for example, from left to right, and numbered from 0 to NumSubPicCols - 2 inclusive, where NumSubPicCols is the number of individual vertical borders of sub-images that are not image borders, i-th column of sub-images may be defined as bordered on the left by the right border of the (i-1)th sub-image column when i is greater than 0, or by the left border of the image when i is 0, and to the right by the border of the i-th sub-image when i is less than NumSubPicCols - 1, or by the right boundary of the picture when i is equal to NumSubPicCols - 1. The encoder indicates, in or with the bitstream, for example in PPS, and/or the decoder decodes, in or with the bitstream, for example in PPS, whether the sub-picture column is divided into more than one column of tiles. For example, the tile_col_split_flag[i] flag may be specified, in or along with the bitstream (eg, by an encoder), and/or decoded, from or along with the bitstream (eg, by a decoder), for each subimage column. A tile_col_split_flag[i] flag of 0 indicates that the i-th subimage column consists of exactly one tile column. A tile_col_split_flag [i] flag of 1 indicates that the i-th sub-image column consists of more than one tile column.

[0254] In one embodiment of the present invention, when the encoder indicates, in or with the bitstream, such as in the PPS, and/or the decoder decodes, in or with the bitstream, such as in the PPS, that the sub-image column divided into more than one tile column, the tile columns in the sub-image column are indicated similarly to the draft VVC standard or any of the considered embodiments of the present invention. For example, an encoder may indicate, in or with the bitstream, and/or a decoder may decode, with or with the bitstream, a syntax element indicating the number of tile columns in a sub-image column. For example, the syntax element num_tile_cols_minus2[i] can be used, with the value num_tile_cols_minus2 [i] plus 2 specifying the number of tile columns in the i-th subimage column. The width of each tile column in a sub-image column is indicated, in or with the bitstream, and/or decoded, from or with the bitstream (with the exception of the last tile column in the sub-image column, whose width can be logically determined to contain all the remaining, as yet unallocated sub-image area). For example, the element tile_col_width_minus1[i][j] may be used, with the value tile_col_width_minus1[i][j] plus 1 specifying the width of the]-th column of tiles in the i-th column of sub-images measured in CTU.

[0255] In the above embodiments of the present invention, for example, the following syntax, or similar to it, can be used:

[0256] In accordance with one embodiment of the present invention, an encoder indicates tile line boundaries, in or with a bitstream, and/or a decoder decodes tile line boundaries, from or with a bitstream, as described below. The horizontal border of a subimage can match either the border of a row of tiles, or the border of a brick within a tile. Thus, the horizontal boundaries of the sub-image are received (eg, at the encoder) or decoded (eg, at the decoder) and inferred to be either a tile-row or a brick boundary.

[0257] In one embodiment of the present invention, when the encoder indicates, in or with the bitstream, for example, in PPS, and / or the decoder decodes, from or with the bitstream, for example, from PPS, whether the boundaries match tile lines are one to one with horizontal subimage borders (and vice versa), or there are additional tileline borders, or some horizontal subimage borders are brick borders within a tile (or tiles). For example, the tile_row_splitting_present_flag flag may be specified, in or with the bitstream (eg, by an encoder) and/or decoded, from or with the bitstream (eg, by a decoder). The tile_row_splitting_present_flag flag of 0 specifies that the tile row boundaries are identical to the received or decoded horizontal sub-image boundaries. The tile_row_splitting_present_flag flag of 1 specifies that there are additional tile rows in addition to those inferred from the subimage's horizontal boundaries, or that some of the subimage's horizontal boundaries are brick tile (or tiles) boundaries.

[0258] In one embodiment of the present invention, when an encoder indicates, in or with a bitstream, such as a PPS, and/or a decoder decodes, from or with a bitstream, such as a PPS, that there are additional the boundaries of the rows of tiles (in addition to those inferred from the horizontal boundaries of the sub-image), or that some of the horizontal boundaries of the sub-images are the boundaries of bricks within a tile (or tiles), apply as described below. The horizontal sub-image borders that are not image borders may be ordered, for example, from top to bottom, and numbered from 0 to NumSubPicRows - 2 inclusive, where NumSubPicRows is the number of individual horizontal sub-image borders that are not image borders, the i-th row of sub-images can be defined as bordered at the top by the bottom border of (i-1)-oft the sub-image row when i is greater than 0, or by the top border of the image when i is 0, and from the bottom by the border of the i-th sub-image when i is less than NumSubPicRows - 1, or by the bottom border images when i is equal to NumSubPicRows - 1. The encoder indicates, in or along with the bitstream, for example, in PPS, and/or the decoder decodes, from or together with the bitstream, for example, in PPS, whether the sub-picture line boundary is a line boundary tiles or brick border. For example, the tile_row_flag[i] flag may be specified, in or with the bitstream (eg, by an encoder), and/or decoded, from or with the bitstream (eg, by a decoder), for each sub-image column. The flag tile_row_flag[i] equal to 0 specifies that the boundary of the i-th row of subimages is the boundary of a brick within a tile (or tiles). The flag tile_row_flag[i] equal to 1 specifies that the boundary of the i-th row of sub-images is the boundary of a row of tiles. The encoder indicates, in or with the bitstream, eg in PPS, and/or the decoder decodes, in or with the bitstream, eg in PPS, whether the sub-image row contains data for more than one tile row. For example, the flag tile_row_split_flag[i] may be specified, in or along with the bitstream (eg, by an encoder), and/or decoded, from or along with the bitstream (eg, by a decoder), for each row of subimages. The tile_row_split_flag [i] flag equal to 0 specifies that the i-th subimage row contains data for one tile row. The tile_row_split_flag[i] flag equal to 1 specifies that the i-th subimage row contains data for more than one tile row.

[0259] In one embodiment of the present invention, when the encoder indicates, in or along with the bitstream, for example, in PPS, and/or the decoder decodes, from or in conjunction with the bitstream, for example, from PPS, that the sub-image string contains data for more than one tile row, the tile rows in the sub-image row are indicated similarly to the draft VVC standard or any of the considered embodiments of the present invention. For example, the encoder may indicate, in or with the bitstream, and/or the decoder may decode, with or with the bitstream, a syntax element indicating the number of tile line boundaries in the subimage line. For example, the syntax element num_tile_rows_minus2[i] may be used, with the value num_tile_rows_minus2 [i] plus 2 specifying the number of tile row borders in the i-th subimage row. The height of each tile row in the sub-image row is indicated, in or with the bitstream, and/or decoded, from or with the bitstream (except for the last tile row in the sub-image row, whose height can be logically determined to contain all the remaining, the yet unallocated area up to the next tile row boundary in the next row (or rows) of subimages, depending on the value of tile_row_flag[j], where j is greater than i). For example, the element tile_row_height_minus1[i][j] may be used, with the value tile_row_height_minus1[i][j] plus 1 specifying the height of the j-th row of tiles in the i-th row of sub-images, measured in CTU.

[0260] In the above embodiments of the present invention, for example, the following syntax, or similar to it, can be used:

[0261] In accordance with one embodiment of the present invention applicable to encoding and/or decoding, when the sub-image boundary does not coincide with the tile-row boundary, it is logically concluded that the sub-image boundary coincides with the brick boundary. The encoder indicates, in or with the bitstream, e.g. PPS, and/or the decoder decodes, in or with the bitstream, e.g. PPS, whether there are additional bricks (in addition to those that have been inferred based on sub-image boundaries). For example, the brick_splitting_present_flag flag may be specified, in or with the bitstream (eg, by an encoder), and/or decoded, from or with the bitstream (eg, by a decoder). The NumInferredBricksInPic variable is set according to the number of bricks, logically derived from the number of tiles in the specified grid of tiles, and an additional division of tiles along the logically derived brick boundaries. The brick_splitting_present_flag flag of 0 specifies that there are no brick boundaries other than those that have been logically determined based on the sub-image boundaries. The brick_splitting_present_flag flag of 1 specifies that there are brick boundaries that are not logically determined based on the sub-image boundaries (i.e. the number of bricks is greater than NumInferredBricksInPic).

[0262] In one embodiment of the present invention, when the encoder indicates, in or with the bitstream, such as in the PPS, and/or the decoder decodes, in or with the bitstream, such as in the PPS, that there are boundaries bricks that are not logically defined based on sub-image boundaries apply as described below. The logically obtained bricks can be numbered in a predetermined scan order. The encoder indicates, in or with the bitstream, eg in PPS, and/or the decoder decodes, in or with the bitstream, eg in PPS, whether the logically obtained potential brick is divided into more than one brick. For example, a brick_split_flag[i] flag may be specified, in or with the bitstream (eg, by an encoder), and/or decoded, from or with the bitstream (eg, by a decoder), for each logically derived candidate brick. The flag brick_split_flag[i] equal to 0 specifies that the i-th logically obtained potential brick consists of exactly one brick. The brick_split_flag[i] flag equal to 1 specifies that the i-th logically obtained potential brick consists of more than one brick.

[0263] In the above embodiments of the present invention, for example, the following syntax, or similar to it, can be used:

[0264] In one of the embodiments of the present invention, when the encoder indicates, in or with the bitstream, for example, in PPS, and / or the decoder decodes, from or with the bitstream, for example, from PPS, that the logically obtained potential brick is divided into more than one brick, further division of the logically obtained potential brick is indicated, in or along with the bitstream (for example, using an encoder), and/or decoded, from or along with the bitstream (for example, using a decoder ) similar to the draft VVC standard or any of the considered embodiments of the present invention. For example, an encoder may indicate, in or with the bitstream, and/or a decoder may decode, from or with the bitstream, a syntax element indicating the number of bricks in a logically derived potential brick. For example, the syntax element num_bricks_minus2[i] can be used, with the value num_bricks_minus2[i] plus 2 specifying the number of bricks in the i-th logically obtained potential brick. The height of each brick in a logically derived potential brick is indicated, in or with the bitstream, and/or decoded, from or with the bitstream (with the exception of the last brick in the logically derived potential brick, whose width is logically derived as containing all the remaining, unallocated area of a logically obtained potential brick). For example, the element brick_row_height_minus1[i][j] can be used, while the value of brick_row_height_minus1[i][j] plus 1 determines the height of the j-th brick in the i-th logically obtained potential brick, measured in CTU.

[0265] 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.

[0266] 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.

[0267] FIG. 10a and 10b show tile and brick partitions that provide the implementation of equirectangular projection (ERP) and cubemap projection (CMP) with an effective resolution of 6K (respectively), which are 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. 10 s is practically equivalent to the circuit in FIG. 10b, however, a different aspect ratio of the image is used there.

[0268] For version 5 of the VVC project and an embodiment of the present invention that combines the indication of tile columns 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 to indicate the division into tiles and bricks

- Number of syntax lines for specifying tiling and bricking

- The number of bits required to indicate the tiling and bricking for the schemes shown in the drawing below

- Percentage bit savings provided by said embodiment of the present invention compared to version 5 of the VVC draft for the circuits shown in the drawing below.

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

[0270] 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-10s 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

[0271] 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, patch-based 3D video or point cloud video encoding may be used, where the patches occupy only a subset of the tiles and/or bricks of the image.

[0272] In accordance with one embodiment of the present invention applicable to encoding, unencoded tiles or bricks are indicated in the syntactic structure prior to slice data, in or along with the bitstream. 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.

[0273] In accordance with one embodiment of the present invention applicable to decoding, uncoded tiles or bricks are decoded from the syntactic 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.

[0274] In accordance with one embodiment of the present invention applicable to encoding and/or decoding, the number of unencoded bricks is indicated for individual columns of tiles, for example, using a variable length word in the format ue(v). Bricks in a tile column pass in a predefined scan order (eg 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 left to be labeled as non-coded is reduced by 1. The procedure continues until there are no bricks left that can be labeled as non-coded.

[0275] 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.

[0276] 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 transform (T ^-1 ). Blocks 702, 802 illustrate 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 predicted baseline or predictive level images, resulting in pre-restored images (RP). 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.

[0277] 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.

[0278] 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. Thus, the decoding method includes:

decoding (1200) a fragment of the bitstream, including the indication of tile columns and the indication of brick heights for one or more tile columns at the same time; logical determination (1202), in case of detecting rows of bricks that are on the same line throughout the image, potential rows of tiles; logically determining (1204) or decoding an indication 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 grid of tiles following the specified tile columns and the specified or logically derived rows tiles, wherein the tile in the tile grid includes an integer number of code tree blocks and is broken into one or more bricks, and the brick contains an integer number of lines of code tree blocks within the tile.

[0279] FIG. 13 is a flowchart 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

[0280] 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.

[0281] An encoding method according to a first aspect of the present invention includes specifying, in or with a bitstream, or logically determining the top left brick of a rectangular slice. conclusion, on

location-based, whether the rectangular slice includes one or more brick tiles; if the rectangular slice includes one or more tile bricks, an indication, in or with the bitstream, or a boolean definition of the number of bricks in the rectangular slice.

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

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

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

[0285] 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 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.

[0286] In one embodiment of the present invention applicable to encoding and/or decoding, if it is logically determined 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, said first, second, or third syntax element, or any similar syntax element, may be encoded in u(v) format, and its length may be Ceil(Log2(numDeltaValues)) bits.

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

[0288] 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 ordinal number 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 not present, the value of bottom_right_brick_idx_delta[i] is set to 0. The numDeltaValues variable, which specifies the number of values that bottom_right_brick_idx_delta[i] can take, is calculated as follows:

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

[0290] 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 bricks assignment cycle to rectangular slices is included in or with the bitstream, or decoded from or with the bitstream. At 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 a coding 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 logically determined, indicated or decoded, for example, as described above, and the bricks forming a rectangle with the top left brick and the bottom right brick at the corners are marked as assigned. The same, or a similar, procedure is performed each time the loop is entered.

[0291] 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 lower right brick's ordinal 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 a serial number in a numbered set of possible bottom right brick locations.

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

- an indication, in the bitstream or together with it, or a logical determination of the location of the upper left brick of a 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 with the bitstream, of the width of the rectangular slice in tile columns;

- if the rectangular slice contains one or more tile bricks, an indication, in or with the bitstream, or a logical determination of 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, specifying, in or with the bitstream, the height of the rectangular slice in tile rows .

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

- decoding, from or along with the bit stream, or logical determination of the location of the upper left brick of a 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 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 with the bitstream, or logical determination of 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 with the bitstream, the height of the rectangular slice in tile rows .

[0294] 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.

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

[0296] 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 image brick scanning as described previously. The value of tlBrickIdx is recalculated for each value of i, that is, each time the loop is entered.

- The numFreeColumnsOnTheRight[brickIdx] variable is a variable that specifies the number of tile columns to the right of the brick with the brickIdx serial number.

- The value of slice_width_minus1[i] plus 1 determines the width of the i-th rectangular slice in tile columns. If it is absent, the value of slice_width_minus1[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 full_tiles_in_slice_flag[i] flag of 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 BrickIdxlntile[tlBrickIdx] is greater than 0 (i.e. 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 slicewidthminus 1 [i] is greater than 0 or when BrickIdxlntile[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 number brickIdx in the same tile. Otherwise, numFreeRowsBelowfbrickIdx] is a variable that specifies the number of tile rows under the tile containing the brick with index number brickIdx.

- If full_tiles_in_slice_flag [i] is 0, slice_height_minus1[i] plus 1 specifies the height of the i-th rectangular slice in bricks. Otherwise, slice_height_minus1[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_minus1[i] is taken equal to 0.

[0297] 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_minus1) 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 minus 1 is obtained as equal to Ceil(Log2(numFreeColumnsOnTheRight[tlBrickIdx]+1)).

[0298] 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_minus 1) is calculated based on the number of possible values based on the location of the top left brick of the rectangular slice, and that contains whether a rectangular slice is single tile bricks or full tiles. Using the variables and syntax elements described above, the length of slice_height_minus1 is calculated to be equal to Ceil(Log2(numDeltaValues)), where numDeltaValues is calculated as follows:

[0299] 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, rectangular slices and sub-images adopted in version 6 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.

[0300] According to one embodiment of the present invention, one and only one rectangular slice is encoded for each sub-image. The encoder indicates, in or together with the bitstream, for example in PPS, that one and only one rectangular slice for each sub-picture is encoded for the pictures in the scope of this indication. Said scope of the indication may, for example, include images referring to a PPS containing an indication that one and only one rectangular slice is used for each sub-image. The encoder omits explicit signaling of rectangular slice boundaries. The encoder logically concludes that the boundaries of the rectangular slices coincide with the boundaries of the sub-images.

[0301] In accordance with one of the embodiments of the present invention, the decoder decodes, from or together with the bitstream, for example, from PPS, an indication that each sub-image contains one and only one rectangular slice for all images in the scope of this indication . Said scope of the indication may, for example, include images referring to a PPS containing said indication. The decoder omits explicit signaling of rectangular slice boundaries. The decoder logically concludes that the boundaries of the rectangular slices coincide with the boundaries of the sub-images.

[0302] In the embodiments of the present invention described above, the following, or similar, syntax may be used, where the single_slice_per_subpic_flag flag of 0 specifies that sub-images can contain any number of rectangular slices, and the single_slice_per_subpic_flag of 1 specifies that each sub-image contains one and only one rectangular slice:

[0303] In accordance with one embodiment of the present invention, the encoder indicates, in or along with the bitstream, for example, in PPS, and / or the decoder decodes, from or together with the bitstream, for example, in PPS, whether the sub-image consists of one and only one rectangular slice, or it contains more than one rectangular slice. For example, a syntax element encoded in u(1) format, for example named subpic_split_flag[i], may indicate (when it is 0) that the i-th subpicture consists of exactly one rectangular slice, or (when it is 1 ), that the i-th subimage consists of more than one rectangular slice.

[0304] In accordance with one embodiment of the present invention, the encoder indicates and/or decoder decodes the division of the sub-image into rectangular slices using the ordinal numbers of bricks in the sub-image. The bricks within the sub-image are numbered, for example, starting from 0 and in increments of 1, in a predetermined scanning order, for example, in the order in which the bricks in the sub-image were scanned, i.e. scanning a raster of tiles in a sub-image is the primary order, and scanning a raster of bricks in a tile is a secondary order. Because the range of brick sequence numbers within the sub-image is smaller than the range of brick sequence numbers in the image, syntax elements for indicating brick sequence numbers within the sub-image are likely to be shorter than the corresponding syntax elements for brick sequence numbers in the image, and hence signaling with more likely to be more compact.

[0305] In accordance with one embodiment of the present invention, the following, or similar, syntax may be used:

[0306] The flag rect_slice_splitting_present_flag equal to 0 specifies that there is exactly one rectangular slice in each sub-image. The rect_slice_splitting_present_flag flag of 1 specifies that each sub-image has one or more rectangular slices. The value of bottom_right_brick_idx_length_minus1 plus 1 determines the length of the bottom_right_brick_idx_delta[i] syntax element. The variable NumSubPics is obtained as equal to the number of sub-pictures in the picture, for example, based on the sub-picture signaling in the SPS. The flag subpic_split_flag[i] equal to 0 specifies that the i-th sub-picture consists of exactly one rectangular slice. The flag subpic_split_flag[i] equal to 1 specifies that the i-th sub-picture consists of one or more rectangular slices. The value num_slices_in_subpic_minus2[i] plus 2 specifies the number of rectangular slices in the i-th sub-image. The bricks in the i-th sub-image are numbered in the brick-scanning order, bottom_right_brick_idx_delta[i][j] and sign_bottom_right_brick_idx_delta[i][j] define a difference value, signed, which is used to calculate the ordinal number of the bottom right brick of the j-th rectangular slice in i th sub-image relative to the lower right brick (j-l)-th rectangular slice of the i-th sub-image when j is greater than 0, or relative to 0 (i.e., upper left corner of the i-th sub-image) when j is 0. This is the difference value, signed can be defined to bottom_right_brick_idx_delta[i][j] when sign_bottom_right_brick_idx_delta[i][j] is 1 and bottom_right_brick_idx_delta[i][j], sign_bottom_right_brick_idx_delta[i][j] are 0, but can also be defined with setting reverse values of sign_bottom_right_brick_idx_delta[i][j].

Notation of uncoded rectangular slices

[0307] 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, patch-based 3D video or point cloud video encoding may be applied, where the patches occupy only a subset of rectangular image slices.

[0308] In accordance with one embodiment of the present invention, for encoding, uncoded rectangular slices are indicated in or along with a bitstream, for example, in a PPS. 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.

[0309] In accordance with one embodiment of the present invention, for decoding, uncoded rectangular slices are decoded from or along with a bitstream, such as from a PPS. 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.

[0310] 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.

[0311] 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.

[0312] FIG. 15 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 ease 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.

[0313] 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. The encoder 1520 and/or storage 1530 may include a file generator, or the file generator 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 encoder 1520 directly to the transmitter 1540. The encoded media bitstream is then transmitted, when necessary, 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.

[0314] The 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.

[0315] If the media data is encapsulated in a container file for storage 1530 or for input to transmitter 1540, transmitter 1540 may include a "transfer file parser" (not shown) or may be operatively associated with a similar element. 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 corresponding pieces 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.

[0316] 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. 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.

[0317] 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 includes (or is associated with a similar container file generator) generating a container file based on 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.

[0318] 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 1570 encoder is shown.

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

[0320] The above part of the embodiments of the present invention has been described on the example of the VVC/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.

[0321] 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 the 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 in the SPS.

[0322] 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 with a bitstream.

[0323] 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 together with a bitstream.

[0324] In the above description, where embodiments of the present 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.

[0325] 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.

[0326] 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.

[0327] 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.

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

[0329] 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.

[0330] Embodiments of the present invention may be implemented by software executed by a data processor of a mobile device, such as a processing 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.

[0331] 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.

[0332] 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.

[0333] 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.

[0334] In the foregoing, by way of illustrative and non-limiting examples, a complete and informative description of one embodiment of the present invention has been provided. However, in light of the foregoing description taken 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 are within its scope.

Claims (53)

1. A video encoding method, comprising: determining the number of blocks to be assigned to sections and initialized as unassigned; an indication or logical determination of the number of partitions of an explicit size to be assigned; specifying sizes for explicitly sized partitions and appropriately marking unassigned blocks as assigned to partitions in a predetermined scan order; specifying the number of blocks; cyclically assigning said number of blocks to partitions and correspondingly marking unassigned blocks as assigned in a predetermined scan order until the number of unassigned blocks is less than said number of blocks; and if the number of unassigned blocks is greater than 0, assign the unassigned blocks to the last section. 2. The method of claim 1, wherein said sections are one or more of the following: tile columns; tile lines; rows of bricks of one or more tile columns; rows of tile bricks; the columns of the grid used to indicate the split into sub-images; and a grid string used to specify the split into sub-images. 3. The method according to claim 1 or 2, wherein said blocks are one or more of the following: rectangular blocks of image samples and grid cells used to indicate sub-image partitioning. 4. Device for video encoding, containing: means for determining the number of blocks to be assigned to sections and initialized as unassigned; means for specifying or logically determining the number of explicitly sized partitions to be assigned; means for specifying sizes for partitions of an explicit size, and means for appropriately marking unassigned blocks as assigned to partitions in a predetermined scan order; means for indicating the number of blocks; means for cyclically assigning said number of blocks to partitions and means for appropriately marking unassigned blocks as assigned in a predetermined scan order until the number of unassigned blocks is less than said number of blocks; and means of assigning unassigned blocks to the last partition when the number of unassigned blocks is greater than 0. 5. The device according to claim 4, in which the mentioned sections are one or more of the following: columns of tiles; tile lines; rows of bricks of one or more columns of tiles; rows of tile bricks; the columns of the grid used to indicate the split into sub-images; and a grid string used to specify the split into sub-images. 6. An apparatus according to claim 4 or 5, wherein said blocks are one or more of the following: rectangular blocks of image samples and grid cells used to indicate sub-image partitioning. 7. Video decoding method, comprising: determining the number of blocks to be assigned to sections; determining the number of explicitly sized partitions to be assigned; sizing partitions of an explicit size and appropriately marking unassigned blocks as assigned to partitions in a predetermined scan order; determining the number of blocks; cyclically assigning said number of blocks to partitions and correspondingly marking unassigned blocks as assigned in a predetermined scan order until the number of unassigned blocks is less than said number of blocks; and assignment of unassigned blocks to the last partition when the number of unassigned blocks is greater than 0. 8. The method according to claim 7, in which determining the number of explicit size partitions to be assigned includes decoding the number of explicit size partitions to be assigned from the syntax structure; determining the sizes of explicitly sized partitions includes decoding the sizes of the explicitly sized sections from the syntactic structure; and determining the number of blocks includes decoding the number of blocks from the syntax structure. 9. The method of claim 7 or 8, wherein said sections are one or more of the following: tile columns; tile lines; rows of bricks of one or more columns of tiles; rows of tile bricks; the columns of the grid used to indicate the split into sub-images; and a grid string used to specify the split into sub-images. 10. The method according to any one of paragraphs. 7-9, wherein said blocks are one or more of the following: rectangular blocks of image samples and grid cells used to indicate sub-image partitioning. 11. Device for video decoding, containing: means for determining the number of blocks to be assigned to partitions; means for determining the number of explicitly sized partitions to be assigned; means for sizing partitions of an explicit size and means for appropriately marking unassigned blocks as assigned to partitions in a predetermined scan order; means for determining the number of blocks; means for cyclically assigning said number of blocks to partitions and means for appropriately marking unassigned blocks as assigned in a predetermined scan order until the number of unassigned blocks is less than said number of blocks; and means of assigning unassigned blocks to the last partition when the number of unassigned blocks is greater than 0. 12. The device according to claim 11, in which the said sections are one or more of the following: tile columns; tile lines; rows of bricks of one or more columns of tiles; rows of tile bricks; the columns of the grid used to indicate the split into sub-images; and a grid string used to specify the split into sub-images. 13. The apparatus of claim 11 or 12, wherein said blocks are one or more of the following: rectangular blocks of image samples and grid cells used to indicate sub-image partitioning. 14. A computer-readable medium that stores executable computer program code instructions configured so that, when executed by a video encoding device: determine the number of blocks to be assigned to sections and initialized as unassigned; specify or logically determine the number of explicitly sized partitions to be assigned; specify sizes for partitions of an explicit size, and accordingly mark unassigned blocks as assigned to partitions in a predetermined scan order; specify the number of blocks; cyclically assign said number of blocks to partitions and accordingly mark unassigned blocks as assigned in a predetermined scan order until the number of unassigned blocks is less than said number of blocks; and assign unassigned blocks to the last partition when the number of unassigned blocks is greater than 0. 15. A computer-readable medium that stores executable computer program code instructions configured so that, when executed by a video decoding device: determine the number of blocks to be assigned to partitions; determine the number of explicitly sized partitions to be assigned; determine sizes for partitions of an explicit size, and accordingly mark unassigned blocks as assigned to partitions in a predetermined scan order; determine the number of blocks; cyclically assign said number of blocks to partitions and accordingly mark unassigned blocks as assigned in a predetermined scan order until the number of unassigned blocks is less than said number of blocks; and assign unassigned blocks to the last partition when the number of unassigned blocks is greater than 0.

Images