AN APPARATUS, A METHOD AND A COMPUTER PROGRAM FOR VIDEO ENCODING AND DECODING.

Abstract

A method comprising: determining a number of drives to be allocated to partitions and initializing them as unallocated; indicating or inferring a number of explicitly sized partitions to be allocated; indicating sizes for the explicitly sized partitions and marking unallocated drives accordingly as allocated to partitions in a predefined scan order; indicating a drive count; iteratively allocating the drive count to partitions and marking unallocated drives accordingly as allocated in the predefined scan order until the number of unallocated drives is less than the drive count; and allocating, if the number of unallocated drives is greater than 0, the unallocated drives to a final partition.

Description

AN APPARATUS, A METHOD AND A COMPUTER PROGRAM FOR VIDEO ENCODING AND DECODING TECHNICAL FIELD The present invention relates to an apparatus, a method and a computer program for video encoding and decoding. BACKGROUND Video coding standards and specifications typically allow coders to divide, or subdivide, an encoded image into subsets. In video coding, a subdivision can be defined as a division of an image or a subregion of an image into subsets (blocks), such that each element of the image or subregion of the image is in exactly one of the subsets. (blocks). For example, H.265 / HEVC introduced a concept of a coding tree unit (CTU) that has a size of 64x64 pixels by default. A CTU can contain a single coding unit (CU) or can be recursively split into multiple smaller CUs, of at least 8x8 pixels, based on the quadtree structure. H.265 / HEVC also acknowledges pieces, which are rectangular and contain an integer number of CTUs, and slices, which are defined based on slice segments containing an integer number of coding tree units ordered consecutively in the scan. of part and are contained in a single NAL unit. Versatile Video Coding (VVC) (MPEG-I Part 3), also known as ITU-T H.266, is a video compression standard that was developed by the Joint Video Expert Team (JVET) of the Motion Picture Experts (MPEG), (officially ISO / IEC JTC1 SC29 WG11) and the Video Coding Experts Group (VCEG) of the International Telecommunication Union (ITU) to be the successor to HEVC / H.265 . The VVC subdivision scheme includes not only pieces, but also bricks, which can comprise one or more rows of CTUs within a piece. The introduction of bricks also affects the definition of cuts. As a consequence, a rather complex syntax structure has been created to signal the various options for tile and brick subdivision, which is sub-optimal in many respects, especially with respect to the QLizbLn / LZnZ / Β / ΥΙΛΙ bit rate required for such signalling. SUMMARY Now, to at least alleviate the above problems, an improved encoding method is introduced herein. The scope of protection sought for various embodiments of the invention is set forth by the independent claims. Embodiments and features, if any, described in this specification that do not fall within the scope of the independent claims are to be construed as useful examples for understanding the various embodiments of the invention. A method according to a first aspect comprises determining a number of drives to be allocated to partitions and which are initialized as unallocated; indicate or infer a number of explicitly sized partitions to be allocated; indicate sizes for partitions with explicit size and accordingly mark unallocated drives as assigned to partitions in a predefined scan order; indicate a count of units; repetitively allocate the drive count to partitions and mark unallocated drives as allocated accordingly in the predefined scan order until the number of unallocated drives is less than the drive count; and allocating, if the number of unallocated drives is greater than 0, the unallocated drives to a last partition. According to one embodiment, the partitions are one or more of the following: columns of pieces, rows of pieces, rows of bricks for one or more columns of pieces, rows of bricks for a piece, columns of grids for a grid used for indicate subimage subdivision, grid rows for the grid used to indicate subimage subdivision. According to one embodiment, the units are one or more of the following: rectangular blocks of samples of an image, grid cells for the grid used to indicate subimage subdivision. An apparatus according to a second aspect comprises means for determining a number of drives to be assigned to partitions and initializing as unallocated; means for indicating or inferring a number of explicitly sized partitions to be allocated; means to indicate sizes for explicitly sized partitions and means to mark unallocated drives as assigned to partitions accordingly in a scan order QLizbLn / LZnZ / Β / ΥΙΛΙ default; means for indicating a unit count; means for repetitively assigning the drive count to partitions and means for marking unassigned drives as assigned accordingly in the predefined scan order until the number of unassigned drives is less than the drive count; and means to allocate, if the number of unallocated drives is greater than 0, the unallocated drives to a last partition. A method according to a third aspect comprises determining a number of drives to be allocated to partitions; determining a number of explicitly sized partitions to be allocated; determine sizes for explicitly sized partitions and mark unallocated drives as assigned to partitions accordingly in a predefined scan order; determine a unit count; repetitively allocate the drive count to partitions and mark unallocated drives as allocated accordingly in the predefined scan order until the number of unallocated drives is less than the drive count; and allocating, if the number of unallocated drives is greater than 0, the unallocated drives to a last partition. According to one embodiment, determining a number of explicitly sized partitions to be allocated comprises decoding the number of explicitly sized partitions to be allocated from a syntax structure; determining sizes for the explicitly sized partitions comprises decoding the sizes for the explicitly sized partitions from the syntax structure; and determining a unit count comprises decoding the unit count from the syntax structure. An apparatus according to a fourth aspect comprises means for determining a number of units to be assigned to partitions; determining a number of explicitly sized partitions to be allocated; means for determining sizes for the explicitly sized partitions and means for marking unallocated drives as assigned to partitions accordingly in a predefined scan order; means for determining a unit count; means for repetitively assigning the drive count to partitions and means for marking unassigned drives as assigned accordingly in the predefined scan order until the number of unassigned drives is less than the drive count; and means to allocate, if the Ql bbl n / ι ΖηΖ / Ε / ΥΙΛΙ number of unallocated drives is greater than 0, the unallocated drives to a last partition. Additional aspects relate to apparatus comprising: at least one processor and at least one memory, said at least one memory stored with code therein, which when executed by said at least one processor, causes an apparatus to perform at least the following above methods and one or more of the embodiments related thereto. BRIEF DESCRIPTION OF THE DRAWINGS For a better understanding of the present invention, reference will now be made by way of example to the attached drawings in which: Figure 1 schematically shows an electronic device employing embodiments of the invention; Figure 2 schematically shows user equipment suitable for employing embodiments of the invention; Figure 3 further schematically shows electronic devices employing embodiments of the invention connected using wired and wireless network connections; Figure 4 schematically shows an encoder suitable for implementing embodiments of the invention; Figures 5a, 5b, 5c show some examples of subdivision of an image into coding tree units (CTUs), pieces, bricks and slices; Figure 6 shows the syntax structure for brick, piece and slice subdivision signaling according to H.266 / VVC Draft 5; Figure 7 shows a flowchart of a coding method in accordance with one aspect of the invention; Figure 8 shows a flowchart of a coding method in accordance with another aspect of the invention; Figure 9 shows a flowchart of a coding method according to an embodiment of the invention; Figures 10a, 10b, 10c show some examples of tile and brick subdivisions; Figure 11 shows a schematic diagram of a decoder suitable for implementing embodiments of the invention; Figure 12 shows a flowchart of a decoding method. QLizbLn / LZnZ / Β / ΥΙΛΙ according to one embodiment of the invention; Figure 13 shows a flowchart of a decoding method according to another embodiment of the invention; Figures 14a and 14b show flowcharts of an encoding and decoding method according to a further embodiment of the invention; and Figure 15 shows a schematic diagram of an example multimedia communication system within which various embodiments may be implemented. DETAILED DESCRIPTION OF SOME EXAMPLE EMBODIMENTS The following describes in additional detail suitable apparatus and possible mechanisms for initiating a point of view change. In this regard, reference is first made to Figures 1 and 2, where Figure 1 shows a block diagram of a video coding system according to an exemplary embodiment as a schematic block diagram of an apparatus or device. 50 electronic example, which may incorporate a codec in accordance with one embodiment of the invention. Figure 2 shows a layout of an apparatus according to an example embodiment. The elements of Figures 1 and 2 will be explained below. The electronic device 50 can be, for example, a mobile terminal or user equipment of a wireless communication system. However, it should be appreciated that embodiments of the invention may be implemented in any electronic device or apparatus that may be required to decode and encode, or encode or decode still video. The apparatus 50 may comprise a housing 30 to accommodate and protect the device. The apparatus 50 may further comprise a display 32 in the form of a liquid crystal display. In other embodiments of the invention the screen can be any screen technology suitable for displaying a photo or video. The apparatus 50 may further comprise a keypad 34. In other embodiments of the invention, any suitable user or data interface mechanism may be employed. For example, the user interface can be implemented as a virtual keyboard or data entry system as part of a touch screen. The apparatus may comprise a microphone 36 or any audio input QLizbLn / LZnZ / Β / ΥΙΛΙ which can be a digital or analog signal input. The apparatus 50 may further comprise an audio output device, which, in embodiments of the invention, may be any one of: a headphone 38, speaker, or a digital audio or analog audio output connection. The apparatus 50 may also comprise a battery (or in other embodiments of the invention, the device may be powered by any suitable mobile power device such as a solar cell, fuel cell, or automated generator). The apparatus may further comprise a camera that can record or capture photos and / or video. Apparatus 50 may further comprise an infrared port for short-range line-of-sight communication to other devices. In other embodiments, the apparatus 50 may further comprise any suitable short-range communication solution such as, for example, a wireless Bluetooth connection or a wired USB / firewire connection. Apparatus 50 may comprise a controller 56, processor, or processor circuitry for controlling apparatus 50. Controller 56 may be connected to memory 58 which, in embodiments of the invention, may store data in the form of both photo and audio data. and / or may also store instructions for implementation in controller 56. Controller 56 may further be connected to suitable codec circuitry 54 to perform encoding and decoding of audio and / or video data or assist in encoding and decoding carried out out by the controller. The apparatus 50 may further comprise a card reader 48 and a smart card 46, for example, a UICC and UICC reader for providing user information and be suitable for providing authentication information for user authentication and authorization in a network. The apparatus 50 may comprise radio interface circuitry 52 connected to the controller and suitable for generating wireless communication signals, for example, for communication with a cellular communication network, a wireless communication system or a wireless local area network. Apparatus 50 may further comprise an antenna 44 connected to radio interface circuitry 52 for transmitting radio frequency signals generated at radio interface circuitry 52 to other apparatus or apparatus and for receiving radio frequency signals from another apparatus. or appliances. Apparatus 50 may comprise a camera that can record or detect QLizbLn / LZnZ / Β / ΥΙΛΙ individual frames that are then passed to the code 54 or controller for rendering. The apparatus may receive the photo-video data for processing from another device prior to transmission and / or storage. The apparatus 50 may also receive, either wirelessly or via a wired connection, the photo for encoding / decoding. The structural elements of the apparatus 50 described above represent examples of means for performing a corresponding function. Referring to Figure 3, an example of a system within which embodiments of the present invention may be used is shown. System 10 comprises multiple communication devices that can communicate over one or more networks. System 10 may comprise any combination of wired or wireless networks including, but not limited to, a wireless cellular telephone network (such as a GSM, UMTS, CDMA, etc. network), a wireless local area network (WLAN) such as as defined by 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 . System 10 may include both wired and wireless communication devices and / or suitable apparatus 50 for implementing embodiments of the invention. For example, the system shown in Figure 3 shows a mobile phone network 11 and a representation of the Internet 28. Internet connectivity 28 can include, but is not limited to, long-range wireless connections, short-range wireless connections, and various other connections. wired including, but not limited to, telephone lines, cable lines, power lines, and similar communication paths. Example communication devices shown in system 10 may include, but are not limited to, an electronic device or appliance 50, a combination of a personal digital assistant (PDA) and mobile phone 14, a PDA 16, an integrated messaging device (IMD) 18, a desktop computer 20, a laptop computer 22. Apparatus 50 may be stationary or mobile when carried by an individual who is on the move. Apparatus 50 may also be located in a mode of transportation including, but not limited to, a car, truck, taxi, bus, train, boat, airplane, bicycle, etc. QLtzbLn / LZnZ / Β / ΥΙΛΙ a motorcycle or any similar suitable mode of transportation. The embodiments can also be implemented in a living room set-top box; i.e. a digital TV receiver, which may / may not have a display or wireless capabilities, on tablets or personal (laptop) computers (PCs), having hardware or software or a combination of encoder / decoder implementations, in various operating systems, and in chipsets, processors, DSPs, and / or embedded systems that offer hardware / software-based encoding. Some or additional devices can send and receive calls and messages and communicate with service providers through a wireless connection 25 to a base station 24 . The base station 24 can be connected to a network server 26 that allows communication between the mobile telephone network 11 and the internet 28. The system can include additional communication devices and communication devices of various types. Communication devices may communicate using various transmission technologies including, but not limited to, Code Division Multiple Access (CDMA), Global Systems for Mobile Communications (GSM), Universal Mobile Telecommunication System (UMTS), Code Division Multiple Access Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Transmission Control Protocol-Internet Protocol (TCP-IP), Short Message Service (SMS), Multimedia Messaging Service (MMS), Email, Service Image Messaging (IMS), Bluetooth, IEEE 802.11 and any similar wireless communication technology. A communications device involved in implementing various embodiments of the present invention may communicate using various means including, but not limited to, radio, infrared, laser, cable, and any suitable connections. In telecommunication and data networks, a channel can refer to either a physical channel or a logical channel. A physical channel can refer to a physical transmission medium such as a wire, while a logical channel can refer to a logical connection through a multiplexed medium, which can carry several logical channels. A channel can be used to carry an information signal, eg a bit stream, from one or more senders (or transmitters) to one or more receivers. QLizbLn / LZnZ / Β / ΥΙΛΙ An MPEG-2 Transport Stream (TS), specified in ISO / IEC 13818-1 or, equivalently, ITU-T recommendation H.222.0, is a format for carrying audio, video, and other media, as well as, program metadata or other metadata, in a multiplexed stream. A packet identifier (PID) is used to identify an elementary stream (also known as a packetized elementary stream) within the TS. Therefore, a logical channel within an MPEG-2 TS can be considered to correspond to a specific PID value. Available media file format standards include the ISO Base Media File Format (ISO / IEC 14496-12, which may be abbreviated ISOBMFF) and the NAL Unit Structured Video (ISO / IEC 14496-15), which is derived from the ISOBMFF. The video codec consists of an encoder that transforms the input video into a compressed representation suitable for storage / transmission and a decoder that can decompress the compressed video representation back into a viewable form. A video encoder and / or a video decoder may also be separate from each other, ie they need not form a codec. Typically, the encoder discards some information in the original video stream in order to render the video in a more compact (ie lower bit rate) form. Typical hybrid video encoders, eg, many ITU-T H.263 and H.264 encoder implementations, encode video information in two phases. Firstly, pixel values ​​are predicted in a certain image area (or block) for example by means of motion compensation (finding and indicating an area in one of the pre-encoded video frames that closely corresponds to the block being encoding) or by spatial means (using the pixel value around the block to be encoded in a specified way). Second, the prediction error, ie the difference between the predicted pixel block and the original pixel block, is encoded. This is typically done by transforming the difference into pixel values ​​using a specified transform (eg, Discrete Cosine Transform (DCT) or a variant thereof), quantizing the coefficients, and entropy coding the quantized coefficients. By varying the fidelity of the quantization process, the encoder can control the trade-off between the precision of the pixel representation (image quality) and the size of the image. QLizbLn / LZnZ / Β / ΥΙΛΙ resulting encoded video representation (file size or transmission bit rate). In temporal prediction, the forecast sources are previously decoded pictures (also known as reference pictures). In intra block copy (IBC; also known as intra block copy prediction), prediction is applied in a similar way to temporal prediction, but the reference picture is the current picture and only samples previously decoded in the frame can be referenced. prediction process. Inter-layer or inter-view prediction can be applied in a similar way to temporal prediction, but the reference image is a decoded image from another scalable layer or from another view, respectively. In some cases, interprediction may refer to temporal prediction alone, while in other cases, interprediction may collectively refer to temporal prediction and any of intrablock copy, interlayer prediction, and interprediction. of intervista with the condition that they are carried out with the same or similar process as the temporal prediction. Interprediction or temporal prediction can sometimes be referred to as motion compensation or motion compensated prediction. Interprediction, which may also be referred to as temporal prediction, motion compensation, or motion compensated prediction, reduces temporal redundancy. In inter prediction the prediction sources are previously decoded images. Intra prediction uses the fact that adjacent pixels within the same image are likely to be correlated. Intra prediction can be performed in the spatial or transform domain, ie sample values ​​or transform coefficients can be predicted. Intra prediction is typically exploited in intra coding, where inter prediction is not applied. An output of the encoding procedure is a set of encoding parameters, such as motion vectors and quantized transform coefficients. Many parameters can be entropy coded more efficiently if they are first predicted from spatially or temporally neighboring parameters. For example, a motion vector may be predicted from spatially adjacent motion vectors and only the difference relative to the motion vector predictor may be coded. The prediction of QLizbLn / LZnZ / Β / ΥΙΛΙ coding and intra-prediction parameters can be collectively referred to as intra-image prediction. Figure 4 shows a block diagram of a video encoder suitable for employing embodiments of the invention. Figure 4 presents an encoder for two layers, but it should be appreciated that the presented encoder could be similarly extended to encode more than two layers. Figure 4 illustrates an embodiment of a video encoder comprising a first encoder section 500 for a base layer and a second encoder section 502 for an enhancement layer. The first encoder section 500 and the second encoder section 502 may each comprise similar elements for encoding incoming images. The encoder sections 500, 502 may comprise a pixel predictor 302, 402, a prediction error encoder 303, 403 and a prediction error decoder 304, 404. Figure 4 also shows an embodiment of the pixel predictor 302, 402 as comprising an inter predictor 306, 406, an intra predictor 308, 408, a mode selector 310, 410, a filter 316, 416, and a memory 318, 418 reference frame. The pixel predictor 302 of the first encoder section 500 receives 300 base layer photos of a video stream to be encoded in both the inter predictor 306 (which determines the difference between the photo and a motion compensated reference frame 318 ) as in the intra predictor 308 (which determines a prediction for a photo block based only on the already processed parts of the current frame or image). The output of both the inter predictor and the intra predictor are passed to the mode selector 310. The intra predictor 308 may have more than one intra predict mode. Therefore, each mode can perform the intra prediction and provide the predicted signal to the mode selector 310. The mode selector 310 also receives a copy of the base layer image 300. Correspondingly, the pixel predictor 402 of the second encoder section 502 receives 400 enhancement layer photos of a video stream to be encoded in both the inter-predictor 406 (which determines the difference between the photo and a frame 418 of compensated motion reference) as well as in the intra predictor 408 (which determines a prediction for a photo block based only on the already processed parts of the current frame or image). The output of both the inter predictor and the intra predictor are passed to the mode selector 410. The intra predictor 408 may have more than one intra prediction mode. Therefore, QLizbLn / LZnZ / Β / ΥΙΛΙ each mode can perform intra prediction and provide the predicted signal to the mode selector 410. The mode selector 410 also receives a copy of the enhancement layer image 400. Depending on which encoding mode is selected to encode the current block, the output of the inter predictor 306, 406 or the output of one of the optional intra predictor modes or the output of a surface encoder within the mode selector is passed to the output of the mode selector 310, 410. The output of the mode selector is passed to a first summing device 321, 421. The first adding device may subtract the output of the pixel predictor 302, 402 from the base layer image 300 / enhancement layer image 400 to produce a first prediction error signal 320, 420 which is input to the encoder 303, 403 of prediction error. The pixel predictor 302, 402 additionally receives from a preliminary reconstructor 339, 439 the combination of the prediction representation of the photo block 312, 412 and the output 338, 438 of the prediction error decoder 304, 404. The preliminary reconstructed photo 314, 414 can be passed to the intra predictor 308, 408 and a filter 316, 416. The filter 316, 416 receiving the preliminary representation can filter the preliminary representation and output a final reconstructed photo 340, 440 which can be recorded in a reference frame memory 318, 418. Reference frame store 318 may be connected to interpredictor 306 to be used as the reference photo against which a future base layer image 300 is compared in interprediction operations. Subject to the base layer being selected and indicated to be the source for interlayer sample prediction and / or enhancement layer interlayer motion information prediction according to some embodiments, the reference frame memory 318 may also connected to inter-predictor 406 to be used as the reference photo against which future enhancement layer images 400 are compared in inter-prediction operations. In addition, reference frame store 418 may be connected to interpredictor 406 to be used as the reference photo against which a future enhancement layer image 400 is compared in interprediction operations. The filtering parameters from the filter 316 of the first encoder section 500 may be provided to the second encoder section 502 subject to the base layer being selected and indicated to be the source for QLizbLn / LZnZ / Β / ΥΙΛΙ predict enhancement layer filtering parameters according to some embodiments. The prediction error encoder 303, 403 comprises a transform unit 342, 442 and a quantizer 344, 444. The transform unit 342, 442 transforms the first prediction error signal 320, 420 to a transform domain. The transform is, for example, the DCT transform. The quantizer 344, 444 quantizes the transform domain signal, eg, the DCT coefficients, to form quantized coefficients. The prediction error decoder 304, 404 receives the output from the prediction error encoder 303, 403 and performs the opposite processes of the prediction error encoder 303, 403 to produce a decoded prediction error signal 338, 438 which, when combined with the prediction representation 312, 412 of the photo block in the second summing device 339, 439, produces the preliminarily reconstructed photo 314, 414 . The prediction error decoder can be considered to comprise a dequantizer 361, 461, which dequantizes the quantized coefficient values, eg, DCT coefficients, to reconstruct the transform signal and an inverse transform unit 363, 463, which performs the inverse transform to the reconstructed transform signal wherein the output of the inverse transform unit 363, 463 contains the reconstructed block or blocks. The prediction error decoder may also comprise a block filter that can filter the reconstructed block(s) according to additional decoded information and filter parameters. The entropy encoder 330, 430 receives the output of the prediction error encoder 303, 403 and may perform suitable entropy coding / variable length coding on the signal to provide error detection and correction capability. The outputs of the entropy encoders 330, 430 may be inserted into a bit stream, for example, by a multiplexer 508. Entropy encoding / decoding can be done in many ways. For example, context-based encoding / decoding can be applied, where both the encoder and decoder modify the context state of an encoding parameter based on previously encoded / decoded encoding parameters. Context-based encoding can be, for example, context-adaptive arithmetic binary encoding (CABAC) QLizbLn / LZnZ / Β / ΥΙΛΙ or context-based variable length encoding (CAVLC) or any similar entropy encoding. Entropy encoding / decoding may alternatively or additionally be performed using a variable length encoding scheme, such as Huffman encoding / decoding or Exp-Golomb encoding / decoding. The decoding of encoding parameters from an entropy encoded bit stream or codewords may be referred to as parsing. 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 Moving Picture Experts (MPEG) from the International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC). The H.264 / AVC standard was published by both major standards organizations, and is referred to as the ITU-T Recommendation H.264 and International Standard ISO / IEC 14496-10, also known as MPEG-4 Part 10 Advanced Video Coding. (AVC). There have been multiple versions of the H.264 / AVC standard, which integrate new extensions or features to the specification. These extensions include Scalable Video Coding (SVC) and Multiple View Video Coding (MVC). Version 1 of the High Efficiency Video Coding (H.265 / HEVC also known as HEVC) standard was developed by the Joint Collaborative Team - Video Coding (JCT-VC) of VCEG and MPEG. The standard was published by both major standards organizations, and is referred to as the ITU-T Recommendation H.265 and the International Standard ISO / IEC 23008-2, also known as MPEG-H Part 2 High Efficiency Video Coding (HEVC). ). Later versions of H.265 / HEVC include multi-view, range-fidelity, 3D, and screen content encoding extensions, which may be abbreviated SHVC, MV-HEVC, REXT, 3D-HEVC, and SCC, respectively. SHVC, MV-HEVC and 3D-HEVC use a common base specification, specified in Annex F of version 2 of the HEVC standard. This common base comprises, for example, high-level syntaxes and semantics that specify, for example, some of the characteristics of the bitstream layers, such as interlayer dependencies, as well as decoding processes, such as QLizbLn / LZnZ / Β / ΥΙΛΙ construction of reference picture list including interlayer reference pictures and image order count derivation for multilayer bitstream. Annex F can also be used in potentially subsequent multilayer extensions of HEVC. It is to be understood that even though a video encoder, video decoder, encoding methods, decoding methods, bitstream structures, and / or implementations may be described below with reference to specific extensions, such as SHVC and / or or MV-HEVC, are generally applicable to any multilayer extensions of HEVC, and even more generally to any multilayer video coding scheme. Versatile Video Coding (VVC) (MPEG-I Part 3), also known as ITU H.266, is a video compression standard being developed by the Joint Video Exploration Team (JVET) of the MPEG consortium and the ITU to make it a successor to HEVC / H.265. Some key definitions, encoding and bitstream structures, and concepts of H.264 / AVC, HEVC, VVC and some of their extensions are described in this section as an example of a video encoder, decoder, encoding method, decoding method and a bit stream structure, in which the embodiments may be implemented. Aspects of various embodiments are not limited to H.264 / AVC or HEVC or VVC or their extensions, but instead the description is provided for a possible basis on which the present embodiments may be partially or completely realized. Whenever reference is made below to VVC or any of its draft versions, it is necessary to understand that the description conforms to a VVC draft specification, that there may be changes in subsequent draft versions, and in the finalized version(s) of VVC, and that the descriptions and embodiments may be adjusted to fit the finalized version(s) of VVC. Video coding standards may specify the bitstream syntax and semantics, as well as the decoding process for error-free bitstreams, while the encoding process may not be specified, but encoders may be required to generate streams. of conforming bits. The conformance of the bit stream and decoder can be verified with the Hypothetical Reference Decoder (HRD). Standards may contain tools for QLizbLn / LZnZ / Β / ΥΙΛΙ encoding help to cope with errors and transmission losses, but the use of the tools in encoding may be optional and the decoding process for errored bitstreams may not have been specified. A syntax element can be defined as a data element represented in the bit stream. A syntax structure can be defined as zero or more syntax elements present together in the bit stream in a specified order. Each syntax element can be described as its name and a descriptor for its encoded representation method. A convention may be used where syntax element names comprise all lowercase letters with underlined characters. The decoding process of a video decoder may behave according to the value of the syntax element and the values ​​of previously decoded syntax elements. When describing H.264 / AVC, HEVC, VCC, and example embodiments, the following descriptors and / or description may be used to specify the parsing process for each syntax element. - u(n): unsigned integer using n bits. When n is v in the syntax table, the number of bits varies in a way that depends on the value of other syntax elements. The parsing process for this descriptor is specified by n next bits from the bit stream interpreted as a binary representation of an unsigned integer with the most significant bit written first. - ue(v): exponential-Golomb-encoded (also known as exp-Golomb-encoded) unsigned integer left-first bit-first syntax element. A Golomb-exponential bit string can be converted to a code number (codeNum), for example, using the following table: QLizbLn / LZnZ / Β / ΥΙΛΙ bit string codeNum 1 0 0 1 0 1 0 1 1 2 0 0 10 0 3 0 0 10 1 4 0 0 110 5 0 0 111 6 0001000 7 0001001 8 0001010 9 QLizbLn / LZnZ / Β / ΥΙΛΙ In some cases, syntax tables can use the values ​​of other variables derived from values ​​of syntax elements. A variable naming convention can be used where there is a mix of lowercase and uppercase letters with no underscores. Variables beginning with an uppercase letter can be derived for decoding of the current syntax structure and all dependent syntax structures. Variables beginning with an uppercase letter can be used in the decoding process for subsequent syntax structures without mentioning the variable's source syntax structure. A convention may be used whereby variables beginning with a lowercase letter may only be used within the context in which they are derived. In some cases, mnemonic names for syntax element values ​​or variable values ​​with their numeric values ​​are used interchangeably. Sometimes mnemonic names are used without any associated numerical value. A flag can be defined as a variable or a single-bit syntax element that can take one of two possible values: 0 and 1. Strings can be syntax elements or variables. Square brackets may be used for indexing the strings. A one-dimensional string can be referred to as a list. A two-dimensional array can be referred to as an array. Functions can be described by their names. A convention may be used in which function names start with an uppercase letter, contain a mix of uppercase and lowercase letters without any underscores, and end with left and right parentheses that include zero or more variable names (for definition). or values ​​(for your use) separated by commas (if there is more than one variable). The function Ceil( x ) can be defined to return the smallest integer greater than or equal to x. The function Log2( x ) can be defined to return the base-2 logarithm of x. Processes may be specified to describe the decoding of syntax elements. A process can have a separate specification and invocation. It can be specified that all uppercase syntax elements and variables belonging to the current syntax structure and dependent syntax structures are all available in the process specification and invocation, and it can also be specified that a process specification can also have a variable lowercase explicitly specified as input. Each process specification can explicitly specify one or more outputs, each of which can be a variable that can be either an uppercase variable or a lowercase variable. The syntax, semantics, and processes can be described with arithmetic, logical, relational, bitwise, and assignment operators that are similar to those used in the C programming language. Specifically, the / operator is used to indicate a division of integers (with truncation), and the % operator is used to indicate a modulus (ie, a remainder of a division). Numbering and counting conventions can start from 0, for example, the first is equivalent to order 0, the second is equivalent to order 1, etc. An elementary unit for input to an encoder and output to a decoder, respectively, is typically an image. An image given as input to an encoder may also be referred to as a source image, and an image decoded by a decoder may be referred to as a decoded image or a reconstructed image. The source and decoded pictures are each comprised of one or more sets of samples, such as the following sets of sample series: - Luma (Y) only (monochrome). - Luma and two chromas (YCbCr or YCgCo). - Green, Blue and Red (GBR, also known as RGB). - Strings representing other monochrome samples or unspecified other monochrome or triple stimulus color samples (eg, YZX, also known as XYZ). In the following, these series may be referred to as luma (or L or Y) and chroma, where the two chroma series may be referred to as Cb and Cr; regardless of the actual color rendering method in use. The actual color rendering method in use can be indicated, for example, in a message stream. QLizbLn / LZnZ / Β / ΥΙΛΙ bit-encoded, eg, using the HEVC Video Usability Information (VUI) syntax or the like. A component can be defined as a single swatch or array of one of three swatch arrays (luma and two chromas) or the array or single swatch of the array that makes up an image in monochrome format. An image can be defined as being a frame or a field. A frame comprises an array of luma samples and possibly the corresponding chroma samples. A field is a set of alternate sample rows of a frame and can be used as encoder input, when the source signal is interleaved. Chroma sample runs may be absent (and therefore monochrome sampling may be in use) or chroma sample runs may be undersampled when compared to luma sample runs. Some chroma formats can be summarized as follows: - In monochrome sampling there is only one series of samples, which can nominally be considered the luma series. - In 4:2:0 sampling, each of the two chroma signals is half the height and half the width of the luma series. - In 4:2:2 sampling, each of the two chroma series has the same height and half the width of the luma series. - In 4:4:4 sampling when no separate color planes are in use, each of the two chroma samples has the same height and width as the luma array. The coding standards or formats may allow series of samples to be encoded as separate color planes in the bit stream and to respectively decode coded color planes separately from the bit stream. When separate color planes are in use, each is separately processed (by the encoder and / or decoder) as a monochrome sampled image. A subdivision can be defined as a division of a set into subsets such that each element of the set is in exactly one of the subsets. In video coding, a subdivision can be defined as a division of an image or a subregion of an image into subsets such that each element of the image or subregion of the image is in Ql bbl n / ι ΖηΖ / Ε / ΥΙΛΙ exactly one of the subset. For example, in partitioning related to HEVC encoding and / or decoding, and / or VVC encoding and / or decoding, the following terms may be used. A coding block can be defined as a block of NxN samples for some value of N such that the division of a coding tree block into coding blocks is a subdivision. A coding tree block (CTB) can be defined as a block of NxN samples for some value of N such that the division of a component into coding tree blocks is a subdivision. A coding tree unit (CTU) can be defined as one coding tree block of luma samples, two corresponding coding tree blocks of chroma samples of an image having three series of samples, or one coding tree block of encoding samples of a monochrome image or an image that is encoded using three separate color planes and syntax structures used to encode the samples. A coding unit (CU) can be defined as a luma sample coding block, two corresponding chroma sample coding blocks of an image having three series of samples, or a monochrome or monochrome image sample coding block. an image that is encoded using three separate color planes and syntax structures used to encode the samples. A CU with the maximum size allowed can be named LCU (Largest Coding Unit) or Coding Tree Unit (CTU) and the video image is divided into non-overlapping LCUs. In HEVC, a CU consists of one or more prediction units (PU) that define the prediction process for the samples within the CU and one or more transform units (TU) that define the prediction error coding process for samples within the CU. the samples in said CU. Typically, a CU consists of a square block of samples with a size selectable from a predefined set of possible CU sizes. Each PU and TU may be further divided into smaller PU and TUs to increase the granularity of the prediction and error coding processes, respectively. Each PU has prediction information associated with it that defines what kind of a prediction is to be applied for pixels within that PU (for example, motion vector information for inter-predicted PUs and intra-prediction directionality information for intra-predicted PUs). planned). QLizbLn / LZnZ / Β / ΥΙΛΙ Each TU may be associated with information describing the prediction error decoding process for the samples within that TU (including, for example, DCT coefficient information). It is typically signaled at the CU level whether or not prediction error coding is applied for each CU. In the case that there is no residual prediction error associated with the CU, it can be considered that there is no TU for that CU. The division of the picture into CUs, and the division of the CUs into PU and TU are typically signaled in the bit stream which allows the decoder to reproduce the intended structure of these units. In a draft version of H.266 / VVC, the following subdivision applies. It is noted that what is described at this point may still evolve in later draft versions of H.266 / VVC until the standard is finalized. Images are subdivided into CTUs similar to HEVC, although the maximum CTU size has been increased to 128x128. A coding tree unit (CTU) is first subdivided into a quadtree structure (also known as a quadtree). The quaternary tree leaf nodes can then be further subdivided by a tree structure of multiple types. There can be four types of division in tree structure of multiple types, vertical binary division, horizontal binary division, vertical ternary division and horizontal ternary division. Tree leaf nodes of multiple types are called coding units (CUs). CU, PU, ​​and TU have the same block size, unless the CU is too large for the maximum transform length. A segmentation structure for a CTU is a quad tree with tree of multiple types nested using binary and ternary divisions, i.e. separate CU, PU and TU concepts are not used, except when necessary for CUs that are too large to fit. the maximum transform length. A CU can have a square or rectangular shape. An elementary unit for the output of encoders of some encoding formats, such as VVC, v and the input of decoders of some encoding formats, such as VVC is a Network Abstraction Layer (NAL) unit. For networks oriented to transport over packets or structured file storage, the NAL units may be encapsulated in packets or similar structures. A byte stream format can be specified for NAL unit streams for streaming or storage environments that do not provide QLizbLn / LZnZ / Β / ΥΙΛΙ framing structures. The byte stream format separates NAL units from each other by appending a start code in front of each NAL unit. To prevent false detection of NAL unit boundaries, encoders execute a byte-oriented start code shadowing prevention algorithm, which adds a shadow prevention byte to the NAL unit payload if an error has occurred. startup code otherwise. To enable easy gateway operation between packet-oriented and stream-oriented systems, startup code emulation prevention can always be performed regardless of whether or not the byte-stream format is in use. A NAL unit can be defined as a syntax structure containing an indication of the type of data to follow and bytes containing that data in the form of an RBSP interleaved as necessary with emulation prevention bytes. A Raw Byte Stream Payload (RBSP) can be defined as a syntax structure that contains an integer number of bytes that are encapsulated in a NAL unit. An RBSP is either empty or in the form of a string of data bits containing syntax elements followed by an RBSP stop bit and followed by zero or more subsequent 0 bits. NAL units consist of a header and payload. The NAL unit header indicates the type of the NAL unit among other things. NAL units can be categorized into Video Coding Layer (VCL) NAL units and non-VCL NAL units. The VCL NAL units are typically coded slice NAL units. A non-VCL NAL unit can be, for example, one of the following types: a sequence parameter set, an image parameter set, a complementary enhancement information (SEI) NAL unit, a unit delimiter access, an end-of-sequence NAL-unit, an end-of-bitstream NAL-unit or a padding-data NAL-unit. Parameter sets may be required for reconstruction of decoded images, while many of the other non-VLC NAL units are not required for reconstruction of decoded sample values. Some encoding formats specify parameter sets that may carry parameter values ​​necessary for decoding or reconstruction of decoded images. A parameter can be defined as a QLizbLn / LZnZ / Β / ΥΙΛΙ syntax element of a set of parameters. A parameter set can be defined as a syntax structure that contains parameters and from which it can be referenced and / or activated by another syntax structure, eg using an identifier. Some types of parameter sets are briefly described below, but it is necessary to understand that other types of parameter sets may exist and that embodiments may be applied to, but not limited to, the types of parameter sets described. Parameters that remain unchanged throughout an encoded video stream may be included in a Stream Parameter Set (SPS). In addition to parameters that may be required by the decoding process, the stream parameter set may optionally contain video usability information (VUI), which includes parameters that may be important for buffering, image output timing , representation and reservation of resources. A Picture Parameter Set (PPS) contains such parameters that are not likely to change across multiple encoded pictures. An image parameter set may include parameters that can be referenced by the coded picture segments of one or more coded images. A header parameter set (HPS) has been proposed to contain such parameters that change on a per-image basis. A bitstream can be defined as a sequence of bits, which can be, in some formats or encoding standards, in the form of a NAL unit stream or a byte stream, which forms the representation of encoded images and associated data that form one or more encoded video streams. A first bit stream may be followed by a second bit stream on the same logical channel, such as the same file or on the same communication protocol connection. An elementary stream (in the context of video coding) can be defined as a sequence of one or more bit streams. In some formats or coding standards, the end of the first bit stream may be indicated by a specific NAL unit, which may be referred to as the end of bit stream (EOB) NAL unit, and which is the last bit stream unit. END of the bit stream. A bitstream portion can be defined as a contiguous subset of a bitstream. In some contexts, a bitstream portion may be required to consist of one or more complete syntax structures and not bitstream structures. QLizbLn / LZnZ / Β / ΥΙΛΙ incomplete syntax. In other contexts, a bitstream portion may comprise any contiguous section of a bitstream and may contain incomplete syntax structure(s). The expression along the bitstream (for example, including along the bitstream) or along a coded unit of a bitstream (for example, indicating along a coded piece), may be used in the claims and in the described embodiments to refer to transmission, signaling, or storage in a way that out-of-band data is associated with, but not included within, the bitstream or coded unit, respectively. The expression decoding along the bit stream or along an encoded unit of a bit stream or the like, may refer to the decoding of so-called out-of-band data (which may be obtained from out-of-band transmission, signaling or storage). band) that are associated with the bit stream or coded unit, respectively. For example, the expression along 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 certain file metadata is stored in the file in a way that associates the metadata with the bitstream, such as boxes in the sample input for a track containing the bitstream, a sample group for the track containing the bitstream, or a track containing the bitstream. Timed metadata associated with the track containing the bitstream. A coded video sequence (CVS) can be defined as such a sequence of images encoded in decoding order that can be decoded independently and is followed by another encoded video sequence or at the end of the bitstream. An encoded video stream may additionally or alternatively be specified to end when a specific NAL unit, which may be referred to as an End of Sequence (EOS) NAL unit, appears in the bitstream. Photos can be split into photo segments that can be independently encoded and decoded (eg slices and / or pieces and / or groups of pieces). Such photo segments may enable parallel processing, slices in this description may refer to photo segments constructed of a number of basic encoding units which are processed in default encoding or decoding order, while pieces QLizbLn / LZnZ / Β / ΥΙΛΙ can refer to photo segments that have been defined as rectangular photo regions along a grid of parts. A part group can be defined as a group of one or more parts. The photo segments may be encoded as separate units in the bitstream, such as VCL NAL Units in H.264 / AVC and HEVC and VVC. The encoded picture segments may comprise a header and a payload, where the header contains parameter values ​​necessary to decode the payload. The payload of a slice can be referred to as slice data. In HEVC, an image can be subdivided into pieces, which are rectangular and contain an integer number of LCUs. In HEVC, the subdivision to pieces forms a regular grid, where the heights and widths of the pieces differ from each other by one LCU at most. In HEVC, a slice is defined to be an integer number of coding tree units contained in an independent sector segment and all subsequent dependent sector segments (if any) preceding the next independent sector segment (if any). ) within the same access unit. In HEVC, a slice segment is defined to be an integer number of coding tree units ordered consecutively in piecewise scanning and contained in a single NAL unit. Dividing each image into cut segments is a subdivision. In HEVC, an independent cut segment is defined to be a cut segment for which the values ​​of the cut segment header syntax elements are not inferred from the values ​​for a previous cut segment, and a segment A dependent break segment is defined to be a break segment for which the values ​​of some break segment header syntax elements are inferred from the values ​​for the preceding independent break segment in decoding order. In HEVC, a break header is defined to be the break segment header of the independent break segment that is a current break segment or is the independent break segment preceding a current dependent break segment, and a segment header A slice is defined to be a part of a coded slice containing the data elements belonging to the first or all of the encoding tree units represented in the slice. CUs are scanned in the row scan order of LCUs within parts or within an image, if the QLizbLn / LZnZ / Β / ΥΙΛΙ pieces are not in use. Within an LCU, the CUs have a specific scan order. Accordingly, video coding standards and specifications may allow encoders to split an encoded picture into encoded slices or the like. In-image prediction is typically disabled through the cutoff limits. Therefore, slices can be preserved as a way to split an encoded picture into independently decodable pieces. In H.264 / AVC and HEVC, in-picture prediction can be disabled via cutoff limits. Therefore, slices can be considered as a way to divide an encoded picture into independently decodable pieces, and slices are often considered as elementary units for transmission. In many cases, encoders can indicate in the bitstream which in-picture prediction types are turned off by the cutoff boundaries, and the decoder operation takes this information into account, for example, when concluding which prediction are available. For example, samples from a neighboring CU may be considered unavailable for intra prediction if the neighboring CU resides in a different slice. In a draft version of VVC, ie, VVC draft 5, the subdivision of images into slices, pieces and bricks is defined as follows. Other draft versions of VVC can define the subdivision of images to slices, pieces, and bricks in a similar way. An image is divided into one or more rows of tiles and one or more columns of tiles. Subdivision of an image into pieces forms a piece grid which may be characterized by a list of piece column widths (in CTUs) and a list of piece row heights (in CTUs). A piece is a sequence of coding tree units (CTUs) that cover a cell in the piece grid, that is, a rectangular region of an image. A tile is divided into one or more bricks, each of which consists of a number of rows of CTUs within the tile. A piece that is not subdivided into multiple bricks is also referred to as a brick. However, a brick that is a true subassembly of a piece is not referred to as a piece. A cut contains a number of pieces of an image or a number of QLizbLn / LZnZ / Β / ΥΙΛΙ one-piece bricks. A cut is a NAL unit of VCL. Two slice modes are supported, namely the row scan slice mode and the rectangular slice mode. In row scan slice mode, a slice contains a sequence of pieces in a row scan of pieces of an image. In rectangular slice mode, a slice contains a number of image bricks that collectively form a rectangular region of the image. The bricks within a rectangular cut are in the order of scanning by brick rows of the cut. A brick scan can be defined as a specific sequential ordering of CTUs subdividing an image in which CTUs are ordered consecutively in row scan of CTUs in a brick, bricks within a piece are ordered consecutively in one scan by rows of the tile bricks, and the tiles in an image are ordered consecutively in a row scan of the tile bricks. For example, it may be required in an encoding standard, that coded break NAL units shall be in the order of increasing CTU address in scan order per brick for the first CTU of each coded break NAL unit, where the CTU address may be defined to be growing in CTU row scanning within a picture. Row scanning can be defined as a mapping from a rectangular two-dimensional pattern to a one-dimensional pattern such that the first entries in the one-dimensional pattern are from the top first row of the two-dimensional pattern scanned from left to right, similarly followed by the second. , third etc., rows of the pattern (going down) each scanned from left to right. Figure 5a shows an example of row-scan slice subdivision of an image, where the image is divided into 12 pieces and 3 row-scan slices. Figure 5b shows an example of rectangular slice subdivision of an image (with 18 by 12 CTUs), where the image is divided into 24 pieces (6 columns of pieces and 4 rows of pieces) and 9 rectangular slices. Figure 5c shows an example of an image subdivided into pieces, bricks and rectangular slices, where the image is divided into 4 pieces (2 columns of pieces and 2 rows of pieces), 11 bricks (the upper left piece contains 1 brick, the upper right piece contains 5 bricks, lower left piece contains 2 bricks, and lower right piece contains 3 bricks), and 4 rectangular cutouts. QLtzbLn / LZnZ / Β / ΥΙΛΙ The subdivision to pieces, bricks, and rectangular slices is specified in the Image Parameter Set (PPS). Figure 6 shows the syntax for indicating the subdivision to tiles and bricks, which is carried out in two phases: a tile grid (i.e. tile column widths and tile row heights) is provided as the first phase. , and later the indicated pieces are further subdivided into bricks. There are two modes of tile grid indication: uniform (indicated with the syntax element uniform_t¡le_spacing flag which has a value equal to 1) and explicit. In uniform tile spacing, tiles are equal in width with the possible exception of the rightmost column of tiles and equal in height with the possible exception of the bottommost row of tiles. In explicit tile spacing, the widths and heights of tile columns and rows (respectively) are indicated (in CTUs) except for the rightmost column and bottommost row (respectively). Similar to how a tile grid is indicated, there are two ways to indicate how a tile is divided into bricks, i.e. you can indicate uniform or explicit brick spacing per tile. The signaling is similar to that for rows of pieces. When rectangular slices are in use, the following is provided for each slice using the syntax structure that includes and follows the num_slices_in_pic_minus1 syntax element: The top left brick index (except for the first cut which is inferred to have index 0) The differential brick index of the lower right brick of the cut in relation to the upper left brick index. The semantics of the syntax elements in Figure 6 have been specified as follows in VVC draft 5: single_tile_in_pic_flag equal to 1 specifies that there is only one tile in each image that references the PPS. single_tile_in_pic_flag equal to 0 specifies that there is more than one tile in each image that references the PPS. NOTE - In the absence of additional brick division within a tile, the entire tile is referred to as a brick. When an image contains only a single piece without additional brick division, it is called as a single brick. It is a conformance requirement of the bit stream that the value of QLizbLn / LZnZ / Β / ΥΙΛΙ single_tile_in_pic_flag must be the same for all PPS that are enabled within a CVS. uniform_tile_spacing_flag equal to 1 specifies that tile column boundaries and, likewise, tile row boundaries are evenly distributed across the image and flagged using the syntax elements tile_cols_width_m¡nus1 and tile_rows_height_m¡nus1. uniform_tile_spac¡ng_flag equal to 0 specifies that tile column boundaries and similarly tile row boundaries may or may not be evenly distributed across the image and flagged using the num_tile_columns_minus1 and num_tile_rows_minus1 syntax elements and a list of tile_column_width_minus1 [ i ] and tile_row_height_minus1 [ i ] syntax element pairs. When not present, the value of uniform_tile_spac¡ng_flag is inferred to be equal to 1. tile_cols_width_minus1 plus 1 specifies the width of tile columns excluding the rightmost tile column of the image in units of CTB when uniform_tile_spacing_flag is equal to 1. The value of tile_cols_width_minus1 must be in the range 0 to PicWidthlnCtbsY - 1, inclusive. When not present, the value of tile_cols_width_minus1 is inferred to be equal to PicWidthlnCtbsY - 1. tile_rows_height_minus1 plus 1 specifies the height of tile rows excluding the bottom tile row of the image in CTB units when uniform_tile_spacing_flag equals 1. The value of tile_rows_height_minus1 must be in the range 0 to PicHeightlnCtbsY - 1, inclusive. When not present, the value of tile_rows_height_minus1 is inferred to be equal to PicHeightlnCtbsY - 1. num_tile_columns_minus1 plus 1 specifies the number of tile columns that subdivide the image when uniform_tile_spacing_flag equals 0. The value of num_tile_columns_minus1 must be in the range 0 to PicWidthlnCtbsY - 1, inclusive. If single_tile_in_pic_flag equals 1, the value of num_tile_columns_minus1 is inferred to be equal to 0. Otherwise, when uniform_tile_spac¡ng_flag equals 1, the value of num_tile_columns_minus1 is inferred as specified in CTB row scan, scan by rows and the scanning process by bricks. num_tile_rows_minus1 plus 1 specifies the number of tile rows that QLizbLn / LZnZ / Β / ΥΙΛΙ subdivides the image when uniform_tile_spacing_flag equals 0. The value of num_tile_rows_minus1 must be in the range 0 to PicHeightlnCtbsY - 1, inclusive. If single_tile_in_pic_flag is equal to 1, the value of num_tile_iOws_minus1 is inferred to be equal to 0. Otherwise, when uniform_tile_spacing_flag is equal to 1, the value of num_tile_rows_minus1 is inferred as specified by the CTB row scan , row scanning, and the brick scanning process. The NumTilesInPic variable is set equal to ( num_tile_columns_minus1 + 1 ) * (num_tile_rows_minusl + 1 ). When single_tile_in_pic_flag is equal to 0, NumTilesInPic must be greater than 1. tile_column_width_minus1 [ i ] plus 1 specifies the width of the tile column of order i in units of CTB. tile_row_height_minus1 [ i ] plus 1 specifies the height of the tile row of order i in units of CTB. brick_splitting_present_flag equal to 1 specifies that one or more pieces of images that reference the PPS may be split into two or more bricks. brick_splitt¡ng_present_flag equal to 0 specifies that no pieces of images that reference the PPS are split into two or more bricks. brick_split_flag[ i ] equals 1 specifies that the piece of order i is split into two or more bricks. brick_split_flag[ i ] equals 0 specifies that the piece of order i is not split into two or more bricks. When not present, the value of brick_split_flag[ i ] is inferred to be equal to 0. uniform_brick_spacing_flag[ i ] equals 1 specifies that the horizontal brick boundaries are evenly distributed across the tile of order i and are flagged using the brick_height_minus1 [ i ] syntax element. uniform_brick_spac¡ng_flag[ i ] equals 0 specifies that the horizontal brick boundaries may or may not be evenly distributed across the tile of order i and flagged using the syntax element num_bñck_rows_minus1 [ i ] and a list of bñck_row_height_minus1 syntax elements [i][j]. When not present, the value of uniform_brick_spacing_flag[i] is inferred to be equal to 1. brick_height_minus1[ i ] plus 1 specifies the height of the brick rows excluding the bottom brick in tile of order i in CTB units when uniform_brick_spac¡ng_flag[ i ] equals 1. When present, the value of brick_height_minus1 must be in the range 0 to RowHeight[ i ] - 2, inclusive. When not present, the value of brick_height_minus1 [ i ] is inferred to be equal to QLizbLn / LZnZ / Β / ΥΙΛΙ a RowHeight[ i ] - 1. num_brick_rows_minus1 [ i ] plus 1 specifies the number of bricks that subdivide the piece of order i when uniform_brick_spac¡ng_flag[ i ] equals 0. When present, the value of num_brick_rows_minus1 [ i ] must be in the range 1 to RowHeight [ i ] - 1, inclusive. If brick_split_flag[ i ] equals 0, the value of num_brick_rows_minus1 [ i ] is inferred to be equal to 0. Otherwise, when uniform_brick_spac¡ng_flag[ i ] equals 1, the value of num_brick rowS—minusl [ i ] is inferred as specified in the CTB row scan, piece scan, and brick scan process. brick_row_height_minus1[ i ][ j ] plus 1 specifies the height of the brick of order j in the tile of order i in units of CTB when uniform_tile_spacing_flag equals 0. The following variables are derived, and, when uniform_tile_spac¡ng_flag is equal to 1, the values ​​of num_tile_columns_minus1 and num_tile_rows_minus1 are inferred, and, for each i ranging from 0 to NumTilesInPic - 1, inclusive, when uniform_brick_spac¡ng_flag[ i ] is equal to 1, the value of num_brick_rows_minus1 [ i ] is inferred, invoking the CTB row scan, piece scan, and brick scan process: the RowHeight[ j ] list for j ranging from 0 to num_tile_rows_minus1, inclusive, specifying the row height of tiles of order j in units of CTB, the CtbAddrRsToBs[ ctbAddrRs ] list for ctbAddrRs ranging from 0 to PicSizelnCtbsY - 1 , inclusive, which specifies the conversion of a CTB address in the CTB row scan of an image to a CTB address in the brick scan, the list CtbAddrBsToRs[ ctbAddrBs ] for ctbAddrBs ranging from 0 to PicSizelnCtbsY - 1, inclusive, which specifies the conversion of a CTB address in the brick scan to a CTB address in the CTB row scan of an image, the list Brickld[ ctbAddrBs ] for ctbAddrBs ranging from 0 to PicSizelnCtbsY - 1, inclusive , which specifies conversion from a CTB address in brick scan to a brick ID, the list NumCtuslnBrick[ brickldx ] to brickldx ranging from 0 to NumBricksInPic - 1, inclusive, which specifies conversion from an index of QLizbLn / LZnZ / Β / ΥΙΛΙ brick to the number of CTUs in the brick, the list FirstCtbAddrBs[ brickldx ] for brickldx ranging from 0 to NumBricksInPic - 1, inclusive, specifying the conversion from a brick ID to the CTB address in brick exploration of the first CTB in the brick. single_brick_per_slice_flag equal to 1 specifies that each slice referred to by this PPS includes one brick. single_brick_per_slice_flag equal to 0 specifies that a slice referencing this PPS can include more than one brick. When not present, the value of single_brick_per_slice_flag is inferred to be equal to 1. rect_slice_flag equal to 0 specifies that the bricks within each slice are in row scan order and slice information is not flagged in PPS. rect_slice_flag equal to 1 specifies that the bricks within each slice cover a rectangular region of the image and the slice information is flagged in the PPS. When single_brick_per_slice_flag is equal to 1, rect_slice_flag is inferred to be equal to 1. num_slices_in_pic_minus1 plus 1 specifies the number of slices in each image that references the PPS. The value of num_slices_in_p¡c_minus1 must be in the range 0 to NumBricksInPic - 1, inclusive. When not present and single_brick_per_slice_flag is equal to 1, the value of num_slices_in_p¡c_m¡nus1 is inferred to be equal to NumBricksInPic - 1. top_left_brick idx[ i ] specifies the brick index of the brick located in the top left corner of the i order break. The value of top_left_brick_idx[ i ] must not be equal to the value of top_left_brick_idx[ j ] for any i not equal to j. When not present, the value of top_left_bhck_idx[ i ] is inferred to be equal to i. The length of the syntax element top_left_brick_idx[ i ] is Ceil( Log2( NumBricksInPic) bits. bottom_right_brick_idx_delta[ i ] specifies the difference between the brick index of the brick located in the bottom right corner of the order cut i and top_left_bñck_idx[ i ]. When single_brick_per_slice_flag is equal to 1, the value of bottom_right_br¡ck_¡dx_delta[ i ] is inferred to be equal to 0. The length of the syntax element bottom_right_br¡ck_¡dx_delta[ i ] is Ceil( Log2( NumBricksInPic top_left_bñck_idx[ i ] ) ) bits. It is a bitstream conformance requirement that a slice must include a number of whole pieces or only a consecutive sequence of QLizbLn / LZnZ / Β / ΥΙΛΙ one piece complete bricks. The variables NumBrickslnSlice[ i ] and BricksToSliceMap[ j ], which specify the number of bricks in slice of order i and the mapping of bricks to slices, are derived as follows: NumBrickslnSlice[ i ] = 0 botRightBkldx = top_left_brick_idx[ i ] + bottom_right_bñck_idx_delta[ i ] for( j = 0; j < NumBricksInPic; j++) {if( BrickColBd[ j ] >= BrickColBd[ top_left_brick_idx[ i ] ] && BrickColBd[ j ] <= BrickColBd[ botRightBkldx ] && BrickRowBd[ j ] >= BrickRowBd[ top_left_brick_idx[ i ] ] && BrickRowBd[ j ] <= BrickColBd[ botRightBkldx ]) { NumBrickslnSlice[ i ]++ BricksToSliceMap[ j ] = i} } Therefore, a rather complex syntax structure is intended to signal the subdivision of piece and brick. It is suboptimal in many respects, for example, in terms of number of syntax elements, lines in syntax, number of modes of operation (i.e., separate uniform and explicit modes for both pieces and bricks, and indicated brick and piece limits of separately) and signaling bit count. VVC draft 6 supports subimages (also known as subimages). A subimage can be defined as a rectangular region of one or more slices within an image, where the one or more slices are complete. Consequently, a subimage consists of one or more slices that collectively cover a rectangular region of an image. Slices of a subimage may be required to be rectangular slices. The subdivision of an image to subimages can be indicated in and / or decoded from an SPS. One or more of the following properties may be indicated (eg by an encoder) or decoded (eg by a decoder) or inferred (eg by an encoder and / or decoder) for the subpictures collectively or for each subpicture individually : i) whether or not a sub-picture is treated as a picture in the decoding process; in some cases, this property excludes loop filter operations, which can be indicated / decoded / inferred separately; ii) whether or not loop filtering operations are performed through QLizbLn / LZnZ / Β / ΥΙΛΙ of the subimage boundaries. Improved methods are now introduced to signal the subdivision of brick and tile. The method for encoding according to a first aspect, shown in Figure 7, comprises encoding (700) a bit stream comprising an indication of columns of pieces and an indication of brick heights for one or more columns of pieces. at a time, or encoding into or along a bitstream an indication of tile columns and an indication of brick heights for one or more tile columns at a time; infer (702), upon detecting rows of bricks aligned across an image, rows of potential pieces; infer (704) that or indicate whether a limit of a row of potential pieces is a limit of a row of pieces; and encoding (706) one or more images into the bitstream using the indicated tile columns, indicated or inferred tile rows, and indicated brick heights, wherein the one or more images are subdivided into a tile grid. Along the indicated tile columns and the indicated or inferred tile rows, a tile in the tile grid comprises an integer number of code tree units and is subdivided into one or more bricks, wherein a brick comprises a integer number of rows of coding tree units within a part. The method for decoding according to a first aspect comprises decoding, from or along a bit stream, an indication of columns of pieces and an indication of brick heights for one or more columns of pieces at a time; infer, after detecting rows of bricks aligned across an image, rows of potential bricks; infer that or decode whether a limit of a row of potential pieces is a limit of a row of pieces; and decoding one or more images from the bitstream using the indicated tile columns, indicated or inferred tile rows, and indicated brick heights, wherein the one or more images are subdivided into a tile grid along Along the columns of indicated pieces and the rows of indicated or inferred pieces, a piece in the piece grid comprises an integer number of coding tree units and is subdivided into one or more bricks, where a brick comprises an integer number of rows of coding tree units within a part. Therefore, the tile columns and brick heights at the tile-column level are indicated by an encoder and / or decoded by a decoder, QLizbLn / LZnZ / Β / ΥΙΛΙ excluding piece row heights. Potential piece row boundaries are inferred to be where the brick boundaries are aligned (horizontally) across the image. Therefore, for a certain potential tile limit, it can be inferred that said potential tile limit is a tile limit. The inference that a potential piece row boundary is a piece row boundary may be based on conclusions made from other information available in the syntax structure, or from the absence of certain information from the syntax structure, e.g. example, the absence of a particular flag. Alternatively, it may be indicated by an encoder and / or decoded by a decoder whether a potential tile row boundary is a tile row boundary. The indication may be based, for example, on one or more flags present in the syntax structure. Thus, by indicating only the tile columns and brick heights at the tile-column level and inferring the potential tile rows, subdivision can be flagged without flagging tile row heights. As a result, the coding efficiency is improved and the bit rate required for such signaling is reduced. Several illustrative embodiments for the first aspect are provided below, ie for the syntax and semantics for indicating tile columns and brick heights at the tile-column level and excluding tile row heights. The embodiments are equally applicable to encoding that generates a bitstream portion that is syntax and semantic compliant and to decoding that decodes a bitstream portion that is syntax and semantic compliant. Example 1 of syntax and semantics: QLizbLn / LZnZ / Β / ΥΙΛΙ pie parameter set rbsp() {Descriptor if( Isingle tile in pie flag ) {uniform tile col spacing flag u(D if( uniform tile col spacing flag ) tile_cols_width_minus1 ue(v) else {num tile columns minusl ue(v) for( i = 0; i < num tile columns minusl; i++ ) tile column width minus1[¡] ue(v) pie parameter set rbsp() {Descriptor for( i = 0; i < NumTileColsInPic; i++ ) {uniform brick spacing flag[ i ] u(1) if( uniform brick spacing flaqf i ] ) brick height minuslfi] ue(v) else {num brick rows minuslfi] ue(v) for( j = 0; j < num brick rows minusl [ i ]; j++ ) brick row height minusl [ i ][j] ue(v)}} QLizbLn / LZnZ / Β / ΥΙΛΙ un¡form_tile_col_spac¡ng_flag equal to 1 specifies that tile column boundaries are evenly distributed across the image and are flagged using the tile_cols_width_minus1 syntax element. uniform_tile_spacing_flag equal to 0 specifies that tile column boundaries may or may not be evenly distributed across the image and are flagged using the num_tile_columns_minus1 syntax element and a list of tile_column_width_minus1 [ i ] syntax elements. When not present, the value of uniform_tile_col_spac¡ng_flag is inferred to be equal to 1. The semantics of tile_cols_width_minus1, num_tile_columns_minus1, and tile_column_width_minus1 [ i ] are specified identically to the semantics of syntax elements with the same name in VVC draft 5. If uniform_tile_col_spacing_flag is equal to 1, NumTileColsInPic is set equal to PicWidthlnCtbsY / (tile_cols_width_minus1 + 1) + PicWidthlnCtbsY % (tile_cols_width_minus1 + 1). Otherwise, NumTileColsInPic is set equal to num_tile_columns_minus1 + 1. uniformbhckspacingflagf i ] equals 1 specifies that the horizontal brick boundaries are evenly distributed across the column of tiles of order i and are flagged using the syntax element br¡ck_height_m¡nus1 [ i ]. uniform_br¡ck_spacing_flag[ i ] equals 0 specifies that the horizontal brick boundaries may or may not be evenly distributed across the column of tiles of order i and flagged using the syntax element num_brick_rows_minus1 [ i ] and a list of elements of syntax brick_row_height_minus1 [ i ][ j ]. When not present, the value of uniform_brick_spacing_flag[¡] is inferred to be equal to 1. brick height minusl [ i ] plus 1 specifies the height of the brick rows excluding the bottom brick in the brick column of order i in units of CTB when uniform_brick_spacing_flag[ i ] equals 1. num_brick_rows_minus1 [ i ] plus 1 specifies the number of bricks that subdivide the tile column of order i when uniform_brick_spacing_flag[ i ] 5 equals 0. brick_row_height_minus1 [ i ][ j ] plus 1 specifies the height of the brick of order j in the tile column of order i in units of the CTBs when un¡form_tile_spacing_flag is equal to 0. Syntax and Semantics Example 2 Example 2 is like Example 1, but it is additionally indicated by an encoder and / or decoded by a decoder if the subdivision of a current tile column to bricks is identical to that of the previous tile column. QLizbLn / LZnZ / Β / ΥΙΛΙ pie parameter set rbsp() {Descriptor if( Isingle tile in pie flag ) {uniform tile col spacing flag u(1) if( uniform tile col spacing flag ) tile cois width minusl ue(v) else {num tile columns minusl ue( v) for( i = 0; i < num_tile_columns_minus1; i++ ) tile column width minusl Π1 ue(v)} for( i = 0; i < NumTileColsInPic; i++ ) {¡f( ¡ > 0 ) copy previous col flag [ i ] u(1) if( i = = 0 | | Icopy previous col flag[ i ] ) {uniform brick spacing flag[ i ] u(1) if( uniform brick spacing flagf i ] ) brick height minuslji] ue( v) else {num brick rows minuslji] ue(v) for( j = 0; j < num brick rows minusl [ i ]; j++) brick row height minusl [ i ][ j ] ue(v)}}} The semantics of the syntax elements are identical to, for example, 15 1 with the following addition of the semantics for copy_previous_col_flag[ i ]: copy_previous_col_flag[ i ] equals 1 specifies all of the following: - un¡form_brick_spacing_flag[ i ] is inferred to be equal to uniform_brick_spacing_flag[ i - 1 ]. - When brick_height_minus1[ i - 1 ] is present, brick_height_minus1 [ i ] is inferred to be equal to brick_height_minus1 [ i - 1 ]. - When num_brick_rows_minus1 [ i - 1 ] is present, num_brick_rows_minus1 [ i ] is inferred to be equal to num_brick_rows_minus1 [ i - 1 ] and brick_row_height_minus1[ i ][ j ] is inferred to be equal to brick—row height—minusl [ i - 1 ][ j ] for each value of j in the interval 0 to num_br¡ck_rows_minus1 [ i ] — 1, inclusive. On the other hand, the suboptimal syntax structure problem of VVC draft 5 can be alleviated by an approach where tile column widths, tile row heights or brick heights can be indicated by an encoder and / or decoded by a decoder in some predefined scan order, until the tile columns, tile rows, or remaining bricks (respectively) are indicated or decoded (respectively) to have equal dimension. The method for coding according to this second aspect is shown in Figure 8, where the method comprises the steps of a) indicating (800) a number of partitions to be allocated; b) determining (802) a number of drives to be allocated to the partitions; c) indicating (804) whether the number of units to be allocated is equally allocated to said number of partitions; and, if not, d) indicating (806) a number of drives to be assigned to a next partition, and e) repeating (808) steps c) and d) until all drives have been assigned to a partition. A method for decoding according to the second aspect comprises the steps of a) decoding a number of partitions to be allocated; b) determining a number of drives to be allocated to the partitions; c) decoding whether the number of units to be allocated is equally allocated to said number of partitions; and, if not, d) decoding a number of drives to be assigned to a next partition, and e) repeating steps c) and d) until all drives have been assigned to a partition. According to an embodiment applicable to encoding and / or decoding, the number of units to be allocated to the partitions is one of the following: the image width in the CTUs (for example, when the partitions Ql bbl n / ι ΖηΖ / Ε / ΥΙΛΙ are columns of tiles), the image height in the CTUs (for example, when the partitions are rows of tiles, or when the partitions are rows of bricks indicated by one or more columns of whole pieces at once), the number of CTU rows in a piece (for example, when the partitions are bricks of the piece). According to an embodiment applicable to encoding and / or decoding, the partitions are one or more of the following: columns of pieces, rows of pieces, rows of bricks. According to an embodiment applicable to encoding and / or decoding, the units are rectangular blocks of samples of an image. For example, a unit in the second aspect shown in Figure 8 may be a code tree block. Therefore, by indicating the number of drives to be allocated to partitions in a predefined scan order, significant savings can be achieved in the number of required syntax elements and in the bit rate required for such signalling, especially if the number of drives that are yet to be allocated must be allocated equally to the remaining partitions. Figure 9 shows an example of how the method of Figure 8 can be implemented according to one embodiment. Therefore, first of all, a number of partitions, such as columns of pieces and / or rows of pieces, to be allocated, is indicated (900) and a number of NU units is determined (902), such as units number of coding tree blocks (CTBs), which are to be allocated to the partitions. To create a loop to check that all drives have been allocated to a partition, it is checked (904), whether the number of NP partitions to be allocated is greater than one. If not, ie NP=1, it is inferred or indicated (910) that all remaining drives to be allocated must still be allocated to the remaining partition. However, if NP>1, it is checked (906), whether the number of NU units to be allocated is evenly divisible by the number of partitions NP. If so, it is determined (908) whether the number of NU units should be equally allocated to the remaining partitions. If so, it is inferred or indicated (910) that all remaining units to be allocated yet NU must be equally allocated to the remaining partition(s). If it is observed that the number of NU units to be assigned is not QLizbLn / LZnZ / Β / ΥΙΛΙ equally divisible by the number of NP partitions (906) or it is determined (908) that the number of NU units should not be equally allocated to the remaining partitions, a number is indicated (912) of drives to be assigned to the next partition in the predefined scan order. The number of NU units to be allocated is reduced (914) by the indicated number of units to be allocated to said next partition, and the number of NP partitions to be allocated is reduced by one (916). Next, the loop is repeated to check (904), whether the number of partitions NP to be allocated is greater than one. The method of Figure 9 can be similarly implemented for decoding according to an embodiment described below. First, a number of partitions, such as piece columns and / or piece rows, to be allocated from or along a bitstream is decoded, and a number of NU units, such as block units, is determined. code tree (CTB), to be assigned to partitions. To create a loop to check that all drives have been allocated to a partition, it checks if the number of NP partitions to be allocated is greater than one. If not, ie NP=1, it is inferred or decoded from or along the bitstream that all remaining units to be allocated are yet to be allocated to the remaining partition. However, if NP>1, it checks whether the number of NU units to be allocated is evenly divisible by the number of NP partitions. If so, it is decoded from or along the bitstream whether the number of NUs should be equally allocated to the remaining partitions. If it is observed that the number of NU units to be allocated is not evenly divisible by the number of NP partitions or is decoded from or along the bit stream that the number of NU units should not be equally allocated to the remaining partitions, a number of drives are decoded to be allocated to the next partition in the predefined scan order from or along the bitstream. The number of NU units to be allocated is reduced by the indicated number of units to be allocated to that next partition, and the number of NP partitions to be allocated is reduced by one. Next, the loop is repeated to check if the number of NP partitions to be allocated is greater than one. An illustrative embodiment is provided below for the second QLizbLn / LZnZ / Β / ΥΙΛΙ aspect, ie for the syntax and semantics for unified explicit / uniform piece / brick subdivision signaling. The embodiment is equally applicable to encoding that generates a bitstream portion that complies with the syntax and semantics and decoding that decodes a bitstream portion that conforms to the syntax and semantics. In this example, unified marking is used to specify a tile column width and tile row heights, while brick marking remains unchanged when compared to the draft QLizbLn / LZnZ / Β / ΥΙΛΙ by VVC. pie parameter set rbsp() {Descriptor if( Isingle tile in pie flag ) {num tile columns minusl ue(v) num tile rows minusl ue(v) for( i = num_tile_columns_minus1, remWidthlnCtbsY = PicWidthlnCtbsY; i > 0 && !rem_tile_col _equal_flag[ i ]; remWidthlnCtbsY -= tile column width minusl [ i ] + 1, i- -){if( remWidthlnCtbsY % (i + 1 ) = = 0 ) rem tile col equal flag[ i ] u(1) if( !rem tile col equal flag( i 1) tile column width minus1[¡] ue(v)} for( i = num_tile_rows_minus1, remHeightlnCtbsY PicHeightlnCtbsY; i > 0 && !rem_tile_row_equal_flag[ i ]; remHeightlnCtbsY -= tile row height minusl [ i ] + 1, i—) {if( remHeightlnCtbsY % (i + 1 ) = = 0 ) rem tile row equal flag[ i ] u(1) if( !rem tile row equal flag[ i ]) tile row height minus1[¡] ue(v)} brick splitting present flag u(1) for( i = 0; brick_splitting_present_flag && i < NumTilesInPic; i++ ) {brick split flag[ i ] u(1) if( brick split flag[ i ]) {uniform brick spacing flagf i ] u(1) if( uniform brick spacing flag[ i ] ) brick height minuslf¡1 ue(v) else {num brick rows minuslfi] ue(v) for( ¡ = 0; ¡ < num brick rows minusl Γ i 1; ++ ) pie parameter set rbsp() {Descriptor brick row height minusl Γ ¡ 1Γ ¡ 1 ue(v)}}} QLizbLn / LZnZ / Β / ΥΙΛΙ rem_tile_col_equal_flag[ i ] equals 0 specifies that tile columns with indexes in the range 0 to i, inclusive, may or may not have equal width in CTB units. rem_tile_col_equal_flag[ i ] equals 1 specifies that tile columns with index in the range 0 to i, inclusive, have an equal width in CTB units, and tile_column_width_minus1 [ j ] is inferred to be equal to remWidthlnCtbsY / ( i + 1 ) for each value of j in the interval 0 to i, inclusive. rem_tile_row_equal_flag[ i ] equals 0 specifies that tile rows with index in the range 0 to i, inclusive, may or may not have equal height in CTB units. rem_tile_row_equal_flag[ i ] equals 1 specifies that tile rows with index in the range 0 to i, inclusive, have an equal height in CTB units, and tile_row_height_minus1 [ j ] is inferred to be equal to remHeightlnCtbsY / (i + 1 ) for each value of j in the interval 0 to i, inclusive. The semantics of other syntax elements can be specified identically to the semantics of syntax elements of the same name in VVC draft 5. An illustrative embodiment is provided below for a further aspect, ie for syntax and semantics including both indicating tile columns and brick heights at tile-column level and unified explicit / uniform tile / brick subdivision signaling. The embodiment is equally applicable to encoding that generates a bitstream portion that complies with the syntax and semantics and decoding that decodes a bitstream portion that conforms to the syntax and semantics. The illustrative embodiment for encoding can be summarized as follows, while the illustrative embodiment can be adapted for decoding by substituting the expression that indicates for the expression that decodes. Columns of pieces are indicated as follows: - The number of tile columns (num_tile_columns_minus1) is indicated. - The following is indicated in a loop traversing tile columns from right to left until all tile columns have been traversed or until the remaining tile columns are of equal width: o If the remaining width (in CTB units) is evenly divisible by the number of tile columns yet to be specified, then flag whether the remaining tile columns have equal width (rem_tile_col_equal_flag[ i ]). o If the remaining tile columns do not have equal width, the tile column width is given (tile_column_width_m¡nus1 [ i ]). The following is indicated in a loop that traverses columns of parts from left to right for rectangular cuts and only includes a loop input specifying the part row heights for row scan cuts: - A flag if the brick subdivision of the tile column is identical to that of the previous tile column. The flag is not present for the leftmost column of pieces (copy_previous_col_flag[ i ]). It is noted that this flag could be omitted in this illustrative embodiment or that there are other alternatives discussed further below that can be used to achieve similar functionality for the flag. - When the subdivision of the piece brick in the piece column is not identical to that of the previous piece column, the bricks in the piece column are indicated as follows: o The number of bricks is indicated in the column of pieces (num_bricks_minus1 [¡]). o The following is indicated in a loop traversing bricks from bottom to top until all bricks in the column of pieces have been traversed or until the remaining bricks in the column of pieces are indicated to be of equal height: If the remaining height (in CTB units) is divisible by the number of bricks yet to be specified, then flag whether the remaining bricks have equal height (rem_brick_height_equal_flag[ i ][ j ]). If the remaining bricks do not have equal height, the brick height (brick_height_m¡nus1 [ i ][ j ]) is given. The following syntax may be used in this illustrative embodiment: QLizbLn / LZnZ / Β / ΥΙΛΙ pie parameter set rbsp() {Descriptor if( Isingle, tile, ,in_pie. flag ) { pie parameter set rbsp() {Descriptor num tile columns minusl ue(v) for( i = num_tile_columns_minus1, remWidthlnCtbsY = PicWidthlnCtbsY; i > 0 && !rem_tile_col_equal_flag[ i ]; remWidthlnCtbsY -= tile column width minusl [ i ] + 1, i - -){if( remWidthlnCtbsY % (i + 1 ) = = 0 ) rem tile col equal flag[ i ] u(1) if( !rem tile col equal flagf i 1) tile column width minus1[i] ue(v )} single brick per slice flag u(D if( Isingle brick per slice flag ) rect slice flag u(1) for( i = 0; i <= num tile columns minusl * rect slice flag; i++ ){¡f( ¡ > 0 ) copy previous col flag[ i ] u(1) if( i = = 0 | | Icopy previous col flag[ i ] ) {num bricks minuslíi] ue(v) for( j = num_bhcks_minus1 [ i ], remHeightlnCtbsY = PicHeightlnCtbsY; j > 0 && !rem_brick_height_equal[ i ][ j ]; remHeightlnCtbsY-= brick height minusl [ i ][ j ] +1, j--){if( remHeightlnCtbsY % (j + 1 ) = = 0 ) rem brick height equal flagf i ][ j ] u(1) if( Irem brick height equal flag[ i ][ j ]) brick height minusl [ i ][ j ] ue(v)}}} QLizbLn / LZnZ / Β / ΥΙΛΙ num_tile_columns_minus1 plus 1 specifies the number of tile columns that subdivide the image when uniform_tile_spac¡ng_flag equals 0. The value of num_tile_columns_minus1 must be in the range 0 to 5 PicWidthlnCtbsY - 1, inclusive. When single_tile_in_pic_flag is equal to 1, the value of num_tile_columns_minus1 is inferred to be equal to 0. rem_tile_col_equal_flag[ i ] equals 0 specifies that tile columns with indexes in the range 0 to i, inclusive, may or may not have equal width in CTB units. rem_tile_col_equal_flag[ i ] equals 1 specifies that the 10 tile columns with index in the range 0 to i, inclusive, are inferred to have equal width in CTB units. When not present, the value of rem_tile_col_equal_flag[ i ] is inferred to be equal to 0. tile_column_width_minus1 [ i ] plus 1 specifies the width of the tile column of order i in units of CTB. copy_previous_col_flag[ i ] equals 0 specifies that num_bricks_minus1 [ i ] is present. copy_previous_col_flag[ i ] equals 1 specifies all of the following: - num_bricks_minus1 [ i ] is inferred to be equal to num_bricks_minus1 [ i - 1 ], - rem_brick_height_equal_flag[ i ][ j ] is inferred to be equal to rem_brick_height_equal_flag[ i - 1 ][ j ] for all such values ​​of j in the range 1 to num_bricks_minus1 [ i ], inclusive, for which the value of rem_brick_height_equal_flag[ i - 1 ][ j ] is present or inferred. - brick_height_minus1 [ i ][ j ] is inferred to be equal to brick_height_minus1 [ i - 1 ][ j ] for all such values ​​of j in the interval 1 to num_bricks_minus1 [ i ], inclusive, for which the value of brick_height_minus1 [ i - 1 ][ j ]. copy_Prev>ous_col_flag[ i ] equals 0 specifies that num_bricks_minus1 [ i ] is present. copy_previous_col_flag[ i ] equals 1 specifies all of the following: - num_bricks_minus1 [ i ] is inferred to be equal to num_bricks_minus1 [ i - 1 ], - rem_brick_height_equal_flag[ i ][ j ] is inferred to be equal to rem_brick_height_equal_flag[ i - 1 ][ j ] for all such values ​​of j in the range 1 to num_bricks_minus1[ i ], inclusive, for which the value of rem_brick_height_equal_flag[ i - 1 ][ j ] is present or inferred. - brickheightminusl [ i ][ j ] is inferred to be equal to brickheightminusl [ i - 1 ][ j ] for all such values ​​of j in the interval from 1 to num_bricks_minus1 [ i ], inclusive, for which the value of is present brick_height_minus1[ i - 1 ][ j ]. rem_brick_height_equal_flag[ i ][ j ] equals 0 specifies that bricks with index in the range 0 to j, inclusive, within which column of order i tiles may or may not have equal height in CTB units. rem_brick_height_equal_flag[ i ][ j ] equals 1 specifies that bricks with index in the range 0 to j, inclusive, within the column of order i tiles are inferred to have equal height in CTB units. When not present, the value of rem_brick_height_equal_flag[ i ][ j ] is inferred to be equal to 0. brick_height_minus1 [ i ][ j ] plus 1 specifies the height of the brick of order j within the brick column of order i in units of CTB. The semantics of other syntax elements can be specified identically to the semantics of syntax elements with the same names in the QLizbLn / LZnZ / Β / ΥΙΛΙ draft 5 of VVC. The decoding process may use variables defined as follows or similar to the following: The list colWidth[ i ] for i ranging from 0 to num_tile_columns_minus1, inclusive, specifying the width of the tile column of order i in units of CTB, is derived as follows: for( i = num_tile_columns_minus1, remWidthlnCtbsY = PicWidthlnCtbsY; i > 0 && !rem_t¡le_col_equal_flag[ i ]; remWidthlnCtbsY -= tile_column_width_minus1 [ i ] + 1, i— ) if( !rem_tile_col_equal_flag[ i ]) colWidth[ i ] = tile_column_width_minus1 [ i ] + 1 if( i > 0 ) for( j = i;j >= 0; j - - ) colWidth[ j ] = remWidthlnCtbsY / ( i + 1 ) else colWidth[ 0 ] = remWidthlnCtbsY The colBrickHeight[ i ][ j ] lists for i ranging from 0 to num_tile_columns_minus1, inclusive, and j ranging from 0 to num_bricks_minus1 [ i ], inclusive, specifying the height of the row of bricks of order j in CTB units within from column of tiles of order i, the list RowHeight[ j ] for j ranging from 0 to NumTileRows - 1, inclusive, specifying the row height of tiles of order j in units of CTB, the list tileRowBd[ j ] for j ranging from 0 to NumTileRows, inclusive, specifying the location of the tile row boundary of order j in CTB units, the NumTileRows value, and the NumTilesInRic value are derived as follows: for( i = 0, i <= num_tile_columns_minus1; i++ ) {for( j = num_bhcks_minus1 [ i ], remHeightlnCtbsY = PicHeightlnCtbsY; j > 0 && !rem_brick_height_equal[ i ][ j ]; remHeightlnCtbsY -= brick_height_minus1 [ i ][ j ] + 1, j— ) if( !rem_brick_height_equal_flag[ i ][ j ]) colBrickHeight[ i ][ j ] = brick_height_minus1 [ i ][ j ] + 1 if(j>0) for(k=j; k >= 0; k- - ) colBrickHeight[ i ][ j ] = remHeightlnCtbsY / (j + 1 ) QLtzbLn / LZnZ / Β / ΥΙΛΙ else colBrickHeight[ i ][ 0 ] = remHeightlnCtbsY} for( i = 0, tileRow = 0, currBrickBd = colBrickHeight[ 0 ][ 0 ], tileRowBd[ 0 ] = 0; i <= num_bricks_minus1 [ 0 ]; i++, currBrickBd += colBrickHeight[ 0 ][ i ]) {tileCol = 1 matchingBdFlag = 1 while( tileCol <= num_tile_columns_minus1 && matchingBdFlag ) bhckldxInCol = 0 bhckBdlnCol = colBrickHeight[ tileCol ][ 0 ] whi le( brickBdlnCol < currBrickBd && brickldxInCol <= num_bricks_minus1 [ tileCol ]) {brickldxlnCol++ brickBdlnCol += colBrickHeight[ tileCol ][ brickldxInCol ]} if( brickBdlnCol = = currBrickBd ) tileCol++ else matchingBdFlag = 0} if( matchingBdFlag ) {ti leRowBd[ tileRow + 1 ] = currBrickBd RowHeight[ tileRow ] = currBrickBd - tileRowBd[ tileRow ] tileRow++}} NumTileRows = tileRow NumTilesInPic = NumTileRows * ( num_tile_columns_minus1 + 1 ) When single_tile_in_pic_flag is equal to 0, NumTilesInPic must be greater than 1. The list tileColBd[ i ] for i ranging from 0 to num_tile_columns_minus1 + 1, inclusive, specifying the location of the tile column limit of order i in CTB units , is derived as follows: for( tileColBd[ 0 ] = 0, i = 0; i <= num_tile_columns_minus1; i++ ) QLizbLn / LZnZ / Β / ΥΙΛΙ tileColBd[ i + 1 ] = tileColBd[ i ] + colW¡dth[ i ] The NumBricksInPic variable, which specifies the number of bricks in an image that references the PPS, and the lists BrickColBd[ brickldx ], BrickRowBd[ brickldx ], BrickWidth[ brickldx ], and BrickHeight[ brickldx ] for brickldx ranging from 0 to NumBricksInPic - 1, inclusive, which specify the locations of the vertical brick boundaries in CTB units, derive the locations of the horizontal brick boundaries in CTB units, the widths of the brick columns in CTB units, and the heights of brick columns in CTB units, and for each i ranging from 0 to NumTilesInPic - 1, inclusive, when uniform_brick_spac¡ng_flag[ i ] equals 1, the value of num_brick_rows_minus1 [ i ] is inferred, as follows: for( i = 0; i <= num_tile_columns_minus1; i++ ) colBrickldx[ i ] = 0 for ( brickldx = 0, i = 0; i < NumTilesInPic; i++ ) {tileX = i % ( num_tile_columns_minus1 + 1 ) tileY = i / ( num_tile_columns_minus1 + 1 ) do { BrickColBd[ brickldx ] = tileColBd[ tileX ] BrickRowBd[ brickldx ] = colBrickBd[ colBrickldx[ tileX ] ] BrickWidthf brickldx ] = colWidth[ tileX ] BrickHeight[ brickldx ] = colBrickHeight[ colBrickldx[ tileX ] ] colBrickldx[ tileX ]++ brickldx++ while( tileRowBd[ tileY + 1 ] <= colBrickBd[ colBrickldx[ tileX ] ] )} NumBricksInPic = brickldx According to one embodiment, a method for encoding comprises the steps of a) determining a number of drives to be allocated to partitions; b) indicate or infer a number of explicitly sized partitions to be allocated; c) indicate sizes, or numbers of drives in, the explicitly sized partitions; and d) indicate or infer a number of equally sized partitions to be allocated. According to an embodiment for encoding, step d) comprises the steps of d1) indicating a unit count; d2) assign unit count partitions QLizbLn / LZnZ / Β / ΥΙΛΙ repetitively until the number of unallocated drives is less than the drive count; and d3) if the number of unallocated drives is greater than 0, allocating the unallocated drives to a last partition in a predefined scan order. Thus, illustrated in Figure 14a is the coding method according to the above embodiment, which can be implemented independently or in combination with one or more of the embodiments described herein. The method comprises determining (1400) a number of drives to be assigned to the partitions and initializing them as unallocated; indicating or inferring (1402) a number of explicitly sized partitions to be allocated; indicate (1404) sizes for the partitions with explicit size and accordingly mark unallocated drives as assigned to partitions in a predefined scan order; indicate (1406) a unit count; allocating (1408) repetitively the drive count to partitions and marking unallocated drives as allocated accordingly in the predefined scan order until the number of unallocated drives is less than the drive count; and allocate (1410), if the number of unallocated drives is greater than 0, the unallocated drives to a last partition. According to one embodiment, a method for decoding comprises the steps of a) determining a number of drives to be allocated to partitions; b) decode or infer a number of explicitly sized partitions to be allocated; c) decode sizes, or numbers of drives in, the explicitly sized partitions; and d) decoding or inferring a number of equally sized partitions to be allocated. According to one embodiment for decoding, step d) comprises the steps of d1) decoding a count of units; d2) allocate the single drive count to partitions repetitively until the number of unallocated drives is less than the drive count; d3) if the number of unallocated drives is greater than 0, allocate the unallocated drives to a last partition in a predefined scan order. Therefore, the decoding method according to the above embodiment, which can be implemented independently or in combination with one or more of the embodiments described herein, is illustrated in Figure 14b. The method comprises determining (1450) a number of units that QLizbLn / LZnZ / Β / ΥΙΛΙ are to be assigned to partitions; determining (1452) a number of explicitly sized partitions to be allocated; determining (1454) sizes for the explicitly sized partitions and marking unallocated drives as allocated to partitions accordingly in a predefined scan order; determining (1456) a unit count; allocating (1458) repetitively the drive count to partitions and marking unallocated drives as allocated accordingly in the predefined scan order until the number of unallocated drives is less than the drive count; and allocate (1460), if the number of unallocated drives is greater than 0, the unallocated drives to a last partition. According to an embodiment for encoding and / or decoding, the method further comprises: - marking the number of units initially as unallocated, or equivalently initializing the number of units as unallocated, eg as part of or connected to step a); - marking unallocated drives as allocated according to the number of explicitly sized partitions to be allocated and the sizes for the explicitly sized partitions, eg as part of or connected to steps b) and / or c); - mark unassigned units as assigned whenever counting units are assigned to a partition, eg as part of or connected to stage d2. Assigning drives to partitions and / or marking unassigned drives as assigned can take place according to a scan order. In one embodiment, the scan order is predefined, eg, in a coding standard. The scan order can be, for example, from left to right (for example, to assign CTU columns to part columns), or from top to bottom (for example, to assign CTU rows to part rows, or of CTU inside a piece to bricks). In one embodiment, an encoder selects the scan order from a list of predefined scan orders and indicates the selected scan order, eg, as an index to the list of predefined scan orders, in or along the bitstream. . In one embodiment, a decoder decodes the scan order, eg, an index to a list of predefined scan orders, from or along the QLizbLn / LZnZ / Β / ΥΙΛΙ bit stream. According to an embodiment for encoding and / or decoding, step c) additionally comprises or is followed by a step of assigning the sizes or the numbers of drives to the explicitly sized partitions. A size of an explicitly sized partition can be specified as a number of drives to be allocated. According to an embodiment applicable to encoding and / or decoding, a unit is one of the following: a CTB, a CTU, a CTU row, a CTU column, a grid cell (for a grid used to indicate subdivision of subimage), a row of grids (for a grid used to indicate subimage subdivision), a column of grids (for a grid used to indicate subimage subdivision). In the embodiments for encoding and / or decoding, the information may be maintained on the drives that are not yet assigned to partitions. Immediately after determining a number of drives to be assigned to partitions, all drives can be marked as unallocated. When a drive pool is assigned to a partition, the drive pool can be marked as allocated or the drive pool can be removed or unmarked as unassigned. Marking units as allocated or unallocated can be represented, for example, by a sign variable or the like, where each unit to be allocated is represented by an entry in the string, and the value of the string entry is indicative of whether whether or not the corresponding unit has been assigned. In another example, the number of units yet to be allocated, ie the number of unallocated units remaining, is maintained through the stages of implementations. According to an embodiment applicable to encoding and / or decoding, the number of units to be allocated to the partitions is one of the following: the image width in the CTUs (for example, when the partitions are columns of pieces) , the image height in the CTUs (for example, when the partitions are rows of tiles, or when the partitions are rows of bricks indicated by one or more columns of whole tiles at a time), the number of rows of CTUs in a tile (for example, when the partitions are tile bricks), the image width in grid columns (for a grid used to indicate sub-image subdivision), the image height in grid rows QLizbLn / LZnZ / Β / ΥΙΛΙ grids (for a grid used to indicate subimage subdivision). According to an embodiment applicable to encoding and / or decoding, partitions are one or more of the following: tile columns, tile rows, brick rows, grid columns (for a grid used to indicate subimage subdivision) , grid rows (for a grid used to indicate subimage subdivision). According to an embodiment applicable to encoding and / or decoding wherein stage d comprises stages d1, d2 and d3 as described QLizbLn / LZnZ / Β / ΥΙΛΙ above, the following or similar syntax can be used: num exp tile columns minusl ue(v) num exp tile rows minusl ue(v) for( ¡ = 0; i <= num exp tile columns minusl; i++ ) tile column width minus1|i| ue(v) for( i = 0; i <= num exp tile rows minusl; i++ ) tile row height minus1[¡] ue(v) brick splitting present flag u(1) for( i = 0; brick splitting present flag && i < NumTilesInPic; i++ ) {if( RowHeightf i / NumTileColumns ] > 1 ) brick split flag[ i ] u(1) if( brick split flag[ i ]) {if( RowHeight[ i / NumTileColumns ] > 2 ) num exp brick rows minuslfi] ue(v) for( j = 0; j <= num exp brick rows minusl [ i ]; j++ ) brick row height minusl [ i ][j] ue(v)}} num_exp_tile_columns_minus1 plus 1 specifies the number of tile column widths explicitly provided. num_exp_tile_rows_minus1 plus 1 specifies the number of tile row heights explicitly provided. tile_column_width_minus1 [ i ] plus 1 specifies the tile column width of order i in units of CTB for i in the range 0 to num_exp_tile_columns_minus1 - 1, inclusive. tile_column_width_minus1 [ num_exp_tile_columns_minus1 ] is used to derive the width of tile columns with index greater than or equal to num_exp_tile_columns_minus1. tile_row_height_minus1 [ i ] plus 1 specifies the height of the tile row of order i in units of CTB for i in the range 0 to num_exp_tile_rows_minus1 - 1, inclusive. tile_row_height_minus1 [ num_exp_tile_rows_minus1 ] is used to derive the height of tile rows with index greater than or equal to num_exp_tile_rows_minus1. brick_splitt¡ng_present_flag and brick_spit_flag[ i ] can be specified as described above. NumTilesInPic can be inferred to equal the number of tiles in the image. NumTileColumns can be inferred to be equal to the number of tile columns in the image. RowHeight[ tileY ] can be inferred to be equal to the number of CTU rows in the tile of tile row of order Y. num_exp_brick_rows_minus1 [ i ] plus 1 specifies the number of brick row heights given explicitly in the piece of order i. When not present, the value of num_exp_brick_rows_minus1 [ i ] can be inferred to be equal to -1. brick row height minusl [ i ][ j ] plus 1 specifies the height of the brick of order j in the piece of order i in units of CTB for j in the range 0 to num_exp_bhck_rows_minus1[ i ] - 1, inclusive. brick_row_height_minus1 [ i ][ num_exp_brick_rows_minus1 ] is used to derive the height of brick rows with index greater than or equal to num_exp_bhck_rows_minus1 [ i ] in piece of order i. According to an exemplary embodiment using the above syntax for encoding (or respectively for decoding, as indicated in the parentheses below), the piece columns are specified as follows: - The number of widths is indicated (or decoded) tile column explicitly provided (num_exp_tile_columns_minus1) - The left-to-right column widths are explicitly provided (or decoded and assigned) (tile_column_width_minus1 [ i ]). - The last tile column width (tile_column_width_minus1 [ num_exp_tile_columns_minus1 ]) explicitly provided (or decoded) is repeated until no tile columns more than that width fit within the image boundaries. - The remaining CTUs not yet assigned to any piece column, if any, are assigned to the rightmost piece column. Tile row heights and brick rows are specified similarly to tile rows. According to an embodiment applicable to the above syntax and to the QLizbLn / LZnZ / Β / ΥΙΛΙ encoding and / or decoding, the variable numTileColumns, which specifies the number of tile columns, and the list colWidth[ i ] for i which ranges from 0 to numTileColumns - 1, inclusive, which specifies the width of the piece with column of order i in units of CTB, are derived as follows: remainingWidthlnCtbsY = PicWidthlnCtbsY for( i = 0; i < num_exp_tile_columns_minus1; i++ ) {colWidth[ i ] = tile_column_width_minus1 [ i ] + 1 remainingWidthlnCtbsY -= colWidth[ i ]} uniformTileColWidth = tile_column_width_minus1 [ num_exp_tile_columns_minus1 ] + 1 while( remainingWidthlnCtbsY >= uniformTileColWidth ) {colWidth[ i++ ] = uniformTileColWidth remainingWidthlnCtbsY -= uniform TileColWidth} if( remainingWidthlnCtbsY > 0 ) colWidth[ i++ ] = remainingWidthlnCtbsY numTileColumns = i According to an embodiment applicable to the above syntax, and encoding and / or decoding, the variable numTileRows, which specifies the number of tile rows, and the RowHeight[ j ] list for j which ranges from 0 to numTileRows - 1, inclusive, which specifies the row height of pieces of order j in units of CTB, are derived as follows: remainingHeightlnCtbsY = PicHeightlnCtbsY for( j = 0; j < num_exp_tile_rows_minus1; j++ ) { RowHeight[ j ] = tile_row_height_minus1 [ j ] + 1 remainingHeightlnCtbsY -= RowHeight[ j ]} uniformTileRowHeight = tile_row_height_minus1 [ num_exp_tile_rows_minus1 ] + 1 while( remainingHeightlnCtbsY >= uniformTileRowHe ight) { RowHeight[ j++ ] = uniformTileRowHeight remainingHeightlnCtbsY -= uniformTileRowHeight} QLizbLn / LZnZ / Β / ΥΙΛΙ if( remainingHeightlnCtbsY > 0 ) RowHeight[ j++ ] = remainingHeightlnCtbsY numTileRows = j In some embodiments, the following may apply: - The NumTilesInPic variable is set equal to numTileColumns * numTileRows. - The list tileColBd[ i ] for i ranging from 0 to numTileColumns, inclusive, specifying the location of the tile column boundary of order i in units of CTB, is derived as follows: for( tileColBd[ 0 ] = 0, i = 0; i < numTileColumns; i++ ) tileColBd[ i + 1 ] = tileColBd[ i ] + colWidth[ i ] - The list tileRowBd[ j ] for j ranging from 0 to numTileRows, inclusive, specifying the location of the tile row boundary of order j in units of CTB, is derived as follows: for( tileRowBd[ 0 ] = 0, j = 0; j < numTileRows; j++ ) tileRowBd[ j + 1 ] = tileRowBd[ j ] + RowHeight[ j ] According to an embodiment applicable to the above syntax, and to encoding and / or decoding, the variable NumBricksInPic, which specifies the number of bricks in an image that references the PPS, and the lists BrickColBd[ brickldx ], BrickRowBd[ brickldx ], BrickWidth[ brickldx ], and BrickHeight[ brickldx ] for brickldx ranging from 0 to NumBricksInPic - 1, inclusive, specifying the locations of the vertical brick boundaries in CTB units, the locations of the horizontal brick boundaries in CTB units , the brick widths in CTB units and the brick heights in CTB units, are derived as follows: for ( brickldx = 0, i = 0; i < NumTilesInPic; i++ ) {tileX = i % numTileColumns tileY = i / numTileColumns if( !brick_split_flag[ i ]) { BrickColBd[ brickldx ] = tileColBd[ tileX ] BrickRowBd[ brickldx ] = tileRowBd[ tileY ] BrickWidth[ brickldx ] = colWidth[ tileX ] BrickHeight[ brickldx ] = RowHeight[ tileY ] brickldx++} else { QLizbLn / LZnZ / Β / ΥΙΛΙ if( RowHeight[ tileY ] = = 2 ) {rowHeight2[ 0 ] = rowHeight2[ 1 ] = 1 numBrickRows[ i ] = 2} else {remainingHeightlnCtbsY = RowHeight[ tileY ] for( j = 0; j < num_exp_brick_rows_minus1 [ i ]; j++ ) {rowHeight2[ j ] = brick_row_height_m¡nus1 [ i ][ j ] + 1 remainingHeightlnCtbsY -= rowHeight2[ j ]} uniformBrickRowHeight = brick_row_height_minus1 [ i ][ num_exp_brick_row s_minus1 ] + 1 while( remainingHeightlnCtbsY >= uniformBrickRowHeight) {rowHeight2[ j++ ] = uniformBrickRowHeight remainingHeightlnCtbsY -= uniformBrickRowHeight} if( remainingHeightlnCtbsY > 0 ) rowHeight2[ j++ ] = remainingHeightlnCtbsY numBrickRows[ i ] = j} for( rowBd2[ 0 ] = 0, j = 0; j < numBrickRows[ i ]; j++ ) rowBd2[ j + 1 ] = rowBd2[ j ] + rowHeight2[ j ] for( j = 0; j < numBrickRows[ i ] ; j++ ) { BrickColBd[ brickldx ] = tileColBd[ tileX ] BrickRowBd[ brickldx ] = tileRowBd[ tileY ] + rowBd2[ j ] BrickWidth[ brickldx ] = colWidth[ tileX ] BrickHeight[ brickldx ] = rowHeight2[ j ] brickldx++ Ql bbl n / ι ΖηΖ / Ε / ΥΙΛΙ NumBricksInPic = brickldx According to an embodiment applicable to encoding and / or decoding, step d comprises determining the number of drives still to be allocated to the partitions by reducing the number of drives in the partitions with explicit size of the number of drives to be allocated to the partitions. partitions, and the method further comprises: - allocate partitions to the explicitly sized partitions according to the sizes for or the number of drives in the explicitly sized partitions and according to a predefined indicated / decoded scan order; - allocating partitions to the equally sized partitions by dividing the drives yet to be assigned to the partitions by the number of equally sized partitions and according to an indicated / decoded predefined scan order. According to an embodiment applicable to encoding and / or decoding, the number of explicitly sized partitions is indicated in and / or decoded from a higher-level syntax structure (eg, SPS), while the sizes for the Explicitly sized partitions and / or a number of equally sized partitions to be allocated may be indicated in and / or decoded from a lower level syntax structure (eg PPS). According to one embodiment, the number of explicitly sized partitions is inferred (eg predetermined in an encoding rule) to be equal to 1. According to an embodiment applicable to encoding and / or decoding, stage d comprises: - determining a set or a list of partition sizes into which the number of drives yet to be allocated can be equally divided; - if the number of elements in the set or list is equal to 1, infer the number of partitions with equal size to be equal to 1; - indicate and / or decode an index (or the like) that corresponds to an element in the array or list, where the index is indicative of the number of equally sized partitions to be allocated. According to an embodiment applicable to encoding and / or decoding, the set or list of partition sizes to which the number of drives yet to be allocated can be divided equally is restricted, excluding partition sizes smaller than a threshold. , where the threshold may be predefined, eg in a coding standard, or indicated / decoded. For example, a minimum piece column width may be predefined or indicated / decoded in the CTUs. QLizbLn / LZnZ / Β / ΥΙΛΙ According to one embodiment, the index corresponding to an element in the array or list is encoded with a fixed-length codeword, for example u(v), where the length of the codeword is determined by the number of elements in the set or list. Indicating Whether a Tile Row Boundary Is a Potential Tile Row Boundary In some embodiments, a tile row boundary is inferred when horizontal brick boundaries are aligned across the image. This section presents an embodiment for signaling part row boundaries. The implementation can be applied in conjunction with any implementation where the brick boundaries are indexed before the row part boundaries in the syntax. The embodiment may comprise one or more of the following steps (some of which have already been described above): - Potential piece row boundaries are inferred to be where the brick boundaries are aligned (horizontally) across the image. - Inferred by an encoder at or along the bitstream and / or decoded by a decoder from or along the bitstream if all aligned brick boundaries form tile row boundaries. For example, a flag can be used in the bitstream syntax. - If all aligned brick boundaries do not form tile row boundaries, it is indicated by an encoder at or along the bitstream and / or decoded by a decoder from or along the bitstream for each boundary of aligned brick if that boundary is a tile row boundary. For example, a flag may be present in the bitstream syntax for each aligned brick boundary (excluding aligned brick boundaries which are image boundaries). QLizbLn / LZnZ / Β / ΥΙΛΙ For example, the following syntax can be used: pie parameter set rbsp() {Descriptor if( rect if ¡ce flag ) {explicit tile rows flag u(1) if( explicit tile rows flag ) for( i = 1; i < NumAlignedBrickRows; i++ ) tile row flag[ i ] u(1)} NumAlignedBrickRows may be derived as NumTileRows in another embodiment. The semantics of the presented syntax elements can be specified as follows: explicit_tile_rows_flag equal to 0 specifies that a tile row boundary is inferred whenever horizontal brick boundaries are aligned across the image. explicit_tile_rows_flag equal to 1 specifies that tile_row_flag[ i ] syntax elements are present. tile_row_flag[ i ] equals 0 specifies that such horizontal boundary of order i where horizontal brick boundaries are aligned across an image is not a tile row boundary. tile_row_flag[ i ] equals 1 specifies that such horizontal boundary of order i where horizontal brick boundaries are aligned across an image is a tile row boundary. Such a horizontal boundary of order 0 where horizontal brick boundaries are aligned across an image is the upper boundary of the image. Indicate columns of pieces so that they are subdivided identically to bricks In some example embodiments, the syntax comprises an indication that a column of pieces is subdivided into bricks identically to the previous column of pieces in loop input order (eg, scanning columns of pieces from left to right). It is necessary to understand that the embodiments apply similarly without the indication or without any similar indication. For example, the scanning order of the tile columns may be from right to left, and accordingly, it may be indicated that the brick subdivision of a current tile column is copied from the tile column on the right side. In another example, all columns of tiles with equal width are indicated or inferred to have the same brick subdivision. In yet another example, an index of a tile column is indicated from which the brick subdivision is copied. It is also necessary to understand that the embodiments similarly apply when there is another way to complete the subdivision of a column of pieces to bricks based on the above indications. This section presents some related embodiments. In one embodiment, the encoder indicates in or along the bitstream and / or the decoder decodes from or along the bitstream, whether all columns of pieces having the same width (eg in CTB) have the same width. same brick subdivision. For example, a syntax element named same_brick_spacing_¡n_equally_w¡de_tile_cols_flag can be used. QLizbLn / LZnZ / Β / ΥΙΛΙ In one embodiment, the encoder indicates in or along the bitstream and / or the decoder decodes from or along the bitstream, the number of columns of adjacent pieces in loop entry order (eg, scanning columns of pieces from left to right) that have the same brick subdivision. For example, a syntax element, which can be named, for example, num_tile_cols_w¡th_same_br¡ck_part¡t¡oning_m¡nus1 [ i ], can be encoded with u(v), where v is determined by the remaining tile columns for the no brick subdivision has yet been indicated. In one embodiment, an encoder may indicate into or along the bitstream and / or a decoder may decode from or along the bitstream, if the column indication related syntax element(s) is present. pieces that are subdivided identically to bricks (for example copy_previous_col_flag[ i ]). In one embodiment, the indication is in a sequence level syntax structure, such as SPS. In another embodiment, the indication is in a picture level syntax structure, such as PPS. In one embodiment, it is predefined, for example, in a coding standard, that the absence of the syntax element(s) related to indicating columns of pieces that subdivide identically to bricks causes the brick subdivision to be indicated and / or decoded. for all columns of pieces one by one. In one embodiment, it is predefined, for example, in a coding standard that the absence of the syntax element(s) related to indicating columns of pieces that subdivide identically to bricks causes the brick subdivision to be indicated and / decoded for a column of pieces and it is inferred that it is the same for all the columns of pieces. In one embodiment, the method for processing the absence of syntax element(s) related to the indication of columns of pieces that subdivide identically to bricks is indicated by an encoder in or along the bitstream, for example, in SPS, and / or is decoded by a decoder from or along the bit stream, eg from SPS. The method may be indicated and / or decoded among a pre-defined set of processes, which may comprise, but may not be limited to, i) the brick subdivision to be indicated and / or decoded for all tile columns one by one, and i¡) the brick subdivision to be indicated and / or decoded for a column of pieces and inferred to be the same for all columns of pieces. QLizbLn / LZnZ / Β / ΥΙΛΙ In some embodiments, the number of drives to be allocated to the partitions is determined or inferred. The number of units can be, for example, the number of CTU columns in an image, the number of CTU rows in an image, or the number of CTU rows in a part. In decoding, the number of units to be allocated to partitions can be decoded from the SPS and / or from the PPS. In some embodiments, it may be desirable to avoid parsing the dependency between syntax structures and all syntax elements that are sufficient to infer the number of units are included in the same syntax structure, such as PPS. For example, the image width in luma samples, the image height in luma samples, and the CTU size can be included in the PPS, making it possible to infer the number of CTU columns in an image and the number of CTU rows in an image. For example, a syntax element encoded by u(2) Iog2_pps_ctu_size_minus5 may be included in the PPS. Iog2_pps_ctu_size_minus5 plus 5 specifies the coding tree block size of each CTU. Iog2_pps_ctu_size_minus5 equals 0, 1, or 2 specifies that the luma coding tree block size of each CTU is equal to 32x32, 64x64, or 128x128 luma samples, respectively. Iog2_pps_ctu_size_minus5 may be required to be less than or equal to 2. Iog2_pps_ctu_size_minus5 may be required to be equal to Iog2_ctu_size_minus5 specified in the SPS. Indicate subimage subdivision It is noted that many embodiments described for indicating cut, piece and / or brick subdivision are independent of how the subimages are indicated. This section presents embodiments for indicating and / or decoding the subdivision of an image to subimages. Many of the embodiments in this section may not need to be used independently of other embodiments, for example, to indicate cut, piece, and / or brick subdivision. According to one embodiment, a grid used when signaling the sub-picture subdivision in or along the bitstream (eg, in SPS) is indicated or decoded from or along the bitstream (eg, to from the SPS). The grid cells specify the units according to which the subimage boundaries are marked. In other words, a subimage boundary can only be located on a boundary of the indicated grid. QLizbLn / LZnZ / Β / ΥΙΛΙ According to one embodiment, a grid is indicated and / or decoded in CTU units (or similar elementary coding blocks of the codec). According to one embodiment, the signage comprises an informational element indicating the number of grid columns, the number or rows of grids, the widths of the grid columns (eg, as CTU counts), and the heights of grids. grid rows (for example, CTU counts). For example, the following syntax can be used: QLizbLn / LZnZ / Β / ΥΙΛΙ seg parameter set rbsp() {Descriptor subpics present flag u(1) if( subpics present flag ) {num id columns minusl ue(v) n u mi dr o ws_m i n u s 1 ue(v) for( i = 0; i < num id columns minusl; i++ ) id column width minusiri] ue(v) for( i = 0; i < num id rows minusl; i++ ) id row height minus1[¡] ue(v) num id columns minusl specifies the number of columns that subdivide the image minus one, num id rows minusl specifies the number of rows that subdivide the image minus one, id column width minusl Γ i 1 plus one specifies the width of the column of order i in units of encoding tree blocks, id row heiqht minusl [ i 1 plus one specifies the height of the row of order i in units of encoding tree blocks. The rightmost grid column can be inferred to consist of the coding tree block columns that are not mapped to other grid columns. The lowest grid row can be inferred to consist of the coding tree blocks that are not assigned to other grid rows. According to another example, the following syntax can be used: seq parameter set rbsp() {Descriptor subpics present flag u(1) if( subpics present flag ) {id column width minusl ue(v) id row height minusl ue(v) When the above signaling is in use, all grid columns are equal in width, except potentially the rightmost column, which can be inferred to consist of the coding tree block columns that are not assigned to other columns. of grids. Similarly, all grid rows are equal in height, except potentially the lowest grid row, which can be inferred to consist of those coding tree blocks that are not assigned to other grid rows. ¡d_column_width_minus1 plus one specifies the width of the grid columns in units of codetree blocks. ¡d_row_height_minus1 plus one specifies the height of the grid rows in units of codetree blocks. According to one embodiment, the assignment of the grid cells to subpictures is indicated in or along the bitstream (eg in the SPS) and / or decoded from or along the bitstream (eg in the SPS). example, from the SPS). In one embodiment, the assignment of grid cells to subpictures is indicated by and / or decoded from the bottom right gridcell index for each subpicture (potentially far from the last subpicture for which the bottom gridcell can be inferred). right to be the bottom right grid cell of the grid). For example, the following or similar syntax may be used (and considered to be appended after any preceding or similar syntax is presented): QLizbLn / LZnZ / Β / ΥΙΛΙ num subpics minus2 ue(v) bottom right grid idx length minusl ue(v) for( i = 0; i <= num subpics minus2; i++ ) {bottom right grid idx deltaf i ] u(v) grid idx delta sign flag[ i ] u(1)}} num_subpics_minus2 plus two specifies the number of subpictures within an image, bottom right gridjdxjength-minusl plus 1 specifies the number of bits used to represent the bottom_right_grid_¡dx_delta[ i ] syntax element. bottom_hght_ghd_¡dx_delta[ i ] when i is greater than 0 specifies the difference between the grid index of the grid cell located in the bottom right corner of the subimage of order i and the grid index of the bottom right corner of the subimage of order i . order ( i - 1 ). bottom_right_grid_idx_delta[ 0 ] specifies the grid index of the bottom right corner of the subimage of order 0. The bottom right corner of the last subimage is inferred to be the bottom right cell of the grid. grid_idx_delta_s¡gn_flag[ i ] equals 1 indicates a positive sign for bottom_right_grid_idx_delta[ i ]. sign_bottom_right_gr¡d_idx_delta[ i ] equals 0 indicates a negative sign for bottom_right_gr¡d_idx_delta[ i ]. The variables NumGridRows, NumGridCols, and NumGridCellsInPic can be inferred to equal the counts of grid rows, grid columns, and grid cells in the image, respectively. The variables TopLeftGridldx[ i ], BottomRightGridldx[ i ], NumGridCellslnSubpic[ i ], and GridCellsToSubpicMap[ j ], which specify the grid index of the grid cell located in the upper-right corner of the subimage of order i, the grid index From the grid cell located in the lower right corner of the subimage of order i, the number of grid cells in the subimage of order i and the mapping of grid cells to subimages are derived as follows: for( j = 0; i = = 0 && j < NumGridCellsInPic; j++ ) GridCellsToSubpicMap[ j ] = -1 NumGridCellslnSubPic[ i ] = 0 BottomRightGridldx[ i ] = bottom right grid idx delta[ ¡]]+((i = = 0)?0: ( grid_idx_delta_sign_flag[ i ] ? BottomRightGridldx[ i - 1 ] : -BottomRightGridldx[ i-1 ] ) for( j = BottomRightGridldx[ i ]; j >= 0; j— ) {gridCol = j % NumGridCols; gridRow = j / NumGridCols; if( gridCol <= BottomRightGridldx[ i ] ] % NumGridCols && gridRow <= BottomRightGridldx[ i ] ] / NumGridCols &&GridCellsToSubpicMap[ j ] = = -1 ) { TopLeftGridldx[ i ] = j NumGridCellslnSubpic[ i ]++ GridCellsToSubpicMap[ j ] = i}} Indicate part subdivision as a division of a subimage subdivision According to one embodiment, which may be used in conjunction with or independently of other embodiments, the subdivision of an image to QLizbLn / LZnZ / Β / ΥΙΛΙ subpictures are indicated in or along the bitstream, eg in an SPS, and / or decoded from or along the bitstream, eg from an SPS , and the subdivision to columns of pieces, rows of pieces, and / or bricks is indicated in or along the bitstream, for example, in a PPS, and / or is decoded from or along the bitstream eg from a PPS, based on the subimage subdivision. According to one embodiment, an encoder indicates piece column boundaries in or along the bitstream and / or a decoder decodes the piece column boundaries from or along the bitstream as follows. Since the vertical boundaries of the rectangular slices coincide with the column boundaries of pieces and since the subimages consist of one or more integer rectangular slices, a column boundary of pieces can be concluded to coincide with a vertical boundary of a subimage. Therefore, the vertical subpicture boundaries are obtained (eg by an encoder) or decoded (eg by a decoder) and are concluded to be piece column boundaries. Additionally, an encoder indicates in or along the bitstream, eg in a PPS, and / or a decoder decodes from or along the bitstream, eg in a PPS, if there are boundaries. of additional pieces column (in addition to those concluded from the vertical subimage boundaries). For example, tile_col_splitting_present_flag may be indicated in or along the bitstream (eg by an encoder) and / or decoded from or along the bitstream (eg by a decoder). tile_col_splitting_present_flag equals 0 specifies that the tile column boundaries are the same as the obtained or decoded vertical subimage boundaries. tile_col_splitting_present_flag equals 1 specifies that there are additional tile columns in addition to those concluded from the vertical subimage boundaries. In one embodiment, when an encoder signals into or along the bitstream, eg, into a PPS, and / or a decoder decodes from or along the bitstream, eg, from a PPS, that there are additional piece column boundaries (in addition to those concluded from the vertical subimage boundaries) the following applies. Vertical subimage boundaries that are not image boundaries can be ordered, for example, from left to right and indexed from 0 to NumSubPicCols - 2, inclusive, where NumSubPicCols QLizbLn / LZnZ / Β / ΥΙΛΙ is the number of distinct vertical subimage boundaries that are not image boundaries. The subimage column of order i can be defined to be left bounded by the right boundary of the subimage column of order (i - 1) when i is greater than 0 or the left image boundary when i equals 0, and to the right by the subpicture boundary of order i when i is less than NumSubPicCols - 1 or the rightimage boundary when i equals NumSubPicCols - 1. An encoder indicates in or along the bitstream, for example, in a PPS, and / or a decoder decodes from or along the bitstream, eg from a PPS, if a column of subpictures is divided into more than one column of pieces. For example, tile_col_split_flag[ i ] may be indicated in or along the bitstream (eg by an encoder) and / or decoded from or along the bitstream (eg by a decoder) for each column. of subimages. tile_col_split_flag[ i ] equals 0 specifies that the column of subimages of order i consists of exactly one column of tiles. tile_col_split_flag[ i ] equals 1 specifies that the column of subimages of order i consists of more than one column of tiles. In one embodiment, when an encoder signals into or along the bitstream, eg, into a PPS, and / or a decoder decodes from or along the bitstream, eg, from a PPS, that a column of subimages is divided into more than one column of pieces, the columns of pieces within the column of subimages are denoted similar to the VVC draft standard or any presented embodiment. For example, an encoder may indicate in or along the bitstream and / or a decoder may decode from or along the bitstream a syntax element indicative of the number of columns of pieces within the subimage column. For example, the syntax element num_tile_cols_minus2[ i ] can be used, where num_tile_cols_minus2[ i ] plus 2 specifies the number of tile columns in the subimage column of order i. The width of each column of pieces within a column of subpictures in or along the bitstream is indicated and / or decoded from or along the bitstream (except the last column of pieces in the column of subpictures , whose width can be inferred to contain all of the remaining unassigned area of ​​the subimage). For example, you can use tile_col_width_minus1 [ i ][ j ], where tile_col_width_minus1 [ i ][ j ] plus 1 specifies the width of the column of tiles of order j within the column of subimages of order i in QLizbLn / LZnZ / Β / ΥΙΛΙ CTU units. The above-described embodiments may use, for example, the following syntax or the like: QLtzbLn / LZnZ / Β / ΥΙΛΙ tile col splitting present flag u(1) for( i = 0; tile col splitting present flag && i < NumSubPicCols; i++ ) {tile col split flagf i ] u(1) if( tile col split flag[ i ]) {num tile cois minus2[ i ] ue(v) for( j = 0; j <= num tile cois minus2[ i ]; j++ ) tile col width minus1[ i ][ j ] ue(v)}} According to one embodiment, an encoder indicates piece row boundaries in or along the bitstream and / or a decoder decodes the piece row boundaries from or along the bitstream as follows. A horizontal subimage boundary can be collocated with a tile row boundary or a brick boundary within a tile. Therefore, horizontal subpicture boundaries are obtained (eg by an encoder) or decoded (eg by a decoder) and are concluded to be the tile row boundaries or brick boundaries. In one embodiment, an encoder signals into or along the bitstream, eg, into a PPS, and / or a decoder decodes from or along the bitstream, eg, from a PPS, if tile row boundaries coincide one-to-one with horizontal subimage boundaries (and vice versa), or if there are additional tile row boundaries or some horizontal subimage boundaries are brick boundaries within the tile(s). For example, tile_row_splitting_present_flag may be indicated in or along the bitstream (eg by an encoder) and / or decoded from or along the bitstream (eg by a decoder). tile_row_splitting_present_flag equals 0 specifies that the tile row boundaries are the same as the obtained or decoded horizontal subimage boundaries. tile_col_spl¡tt¡ng_present_flag equals 1 specifies that there are additional tile rows in addition to those concluded from the horizontal subimage boundaries or that some horizontal subimage boundaries are brick boundaries within the tile(s). In one embodiment, when an encoder signals into or along the bitstream, eg, into a PPS, and / or a decoder decodes from or along the bitstream, eg, from a PPS, that there are additional tile row boundaries (other than those concluded from horizontal subpicture boundaries) or that some horizontal subpicture boundaries are brick boundaries within the tile(s), the following applies. Horizontal subpicture boundaries that are not picture boundaries may be ordered, for example, from top to bottom and indexed from 0 to NumSubPicRows - 2, inclusive, where NumSubPicRows is the number of distinct horizontal subpicture boundaries that are not picture boundaries. The row of subimages of order i can be defined to be bounded at the top by the lower boundary of the row of subimages of order (i - 1) when i is greater than 0 or the upper image boundary when i equals 0 , and at the bottom by the subimage boundary of order i when i is less than NumSubPicRows - 1 or the lower image boundary when i equals NumSubPicRows - 1. An encoder indicates into or along the bitstream, for For example, in a PPS, and / or a decoder decodes from or along the bit stream, for example, from a PPS, if a sub-picture row boundary is a piece row boundary or a brick. For example, tile_row_flag[ i ] may be indicated in or along the bitstream (eg by an encoder) and / or decoded from or along the bitstream (eg by a decoder) for each row. of subimages. tile_row_flag[ i ] equals 0 specifies that the row boundary of subpictures of order i is a brick boundary within the tile(s). tile_row_flag[ i ] equals 1 specifies that the row boundary of subpictures of order i is a tile row boundary. An encoder indicates in or along the bitstream, eg in a PPS, and / or a decoder decodes from or along the bitstream, eg in a PPS, whether a row of subpictures contains data for more than one row of parts. For example, tile_row_split_flag[ i ] may be indicated in or along the bitstream (eg by an encoder) and / or decoded from or along the bitstream (eg by a decoder) for each row. of subimages. tile_row_split_flag[ i ] equals 0 specifies that the row of subimages of order i contains data for one row of tiles. tile_row_split_flag[ i ] equals 1 specifies that the row of subimages of order i contains data for more than one row of tiles. In one embodiment, when an encoder signals into or along the bitstream, eg, into a PPS, and / or a decoder decodes from or along the bitstream, eg, from a PPS, than a row of subimages QLizbLn / LZnZ / Β / ΥΙΛΙ contains data for more than one row of pieces, the rows of pieces within the row of subimages are denoted similar to the VVC draft standard or any presented embodiment. For example, an encoder may indicate at or along the bitstream and / or a decoder may decode from or along the bitstream a syntax element indicative of the number of row boundaries of pieces within the row of bits. subimages. For example, the syntax element num_tile_rows_minus2[ i ] can be used, where num_tile_rows_minus2[ i ] plus 2 specifies the number of tile row boundaries in the subimage row of order i. The height of each row of pieces within a subpicture row is indicated in or along the bitstream and / or decoded from or along the bitstream (except the last row of pieces in the subpicture row , whose height can be inferred to contain all of the remaining, not-yet-assigned area up to the next tile row boundary on or within the next subimage row or rows, depending on the value of tile_row_flag[ j ] with j greater than i). For example, tile_row_height_minus1 [ i ][ j ] can be used, where tile_row_height_minus1 [ i ][ j ] plus 1 specifies the height of the tile row of order j within the subimage row of order i in CTU units. QLizbLn / LZnZ / Β / ΥΙΛΙ The above-described embodiments may use, for example, the following syntax or the like: tile row splitting present flag u(1) for( i = 0; tile_row_splitting_present_flag && i < NumSubPicRows; i++ ) {tile row flag[ i ] u(1) tile row split flag[ i ] u(1) if( tile row split flag[ i ]) {num tile rows minus2[ i ] ue(v) for( j = 0; j <= num tile rows minus2[ i ]; j++ ) tile row height minusl Γ ¡ 1Γ i 1 ue(v)}} According to one embodiment for encoding and / or decoding, when a sub-image boundary does not collocate with a tile row boundary, a brick boundary is inferred to collocate with a sub-image boundary. An encoder indicates in or along the bitstream, eg in a PPS, and / or a decoder decodes from or along the bitstream, eg in a PPS, if there are additional bricks ( in addition to those concluded from subimage boundaries). For example, brick_splitting_present_flag may be indicated in or along the bitstream (eg by an encoder) and / or decoded from or along the bitstream (eg by a decoder). The NumlnferredBricksInPic variable is set according to the number of bricks inferred from the number of pieces in the indicated piece grid, and the further division of the pieces along the inferred brick boundaries. brick_splitting_present_flag equals 0 specifies that there are no brick boundaries other than those inferred from subimage boundaries, brick splitting present flag equals 1 specifies that there are brick boundaries that are not inferred from subimage boundaries. subpicture (ie the number of bricks is greater than NumlnferredBricksInPic). In one embodiment, when an encoder signals into or along the bitstream, eg, into a PPS, and / or a decoder decodes from or along the bitstream, eg, from a PPS, Since there are brick boundaries that are not inferred from the subimage boundaries, the following applies. The bricks that were inferred can be indexed in a predefined scan order. An encoder indicates in or along the bitstream, eg in a PPS and / or a decoder decodes from or along the bitstream, eg in a PPS, whether a candidate brick is split inferred in more than one brick. For example, brick_split_flag[ i ] may be flagged into or along the bitstream (eg by an encoder) and / or decoded from or along the bitstream (eg by a decoder) for each brick. inferred candidate. brick_split_flag[ i ] equals 0 specifies that the inferred candidate brick of order i consists of exactly one brick. brick_split_flag[ i ] equals equals 1 specifies that the inferred candidate brick of order i consists of more than one brick. QLizbLn / LZnZ / Β / ΥΙΛΙ The above-described embodiments may use, for example, the following syntax or the like: brick splitting present flag u(1) for( i = 0; brick_splitting_present_flag && i < NumlnferredBricksInPic; i++ ) {brick split flag[ i ] u(1) if( brick split flagf i ]) {num brick rows minus2[ i ] ue (v) for( j = 0; j <= num brick rows minus2[ i ]; j++ ) brick row height minusl [ i ][ j ] ue(v)}} In one embodiment, when an encoder signals into or along the bitstream, eg, into a PPS, and / or a decoder decodes from or along the bitstream, eg, from a PPS, that an inferred candidate brick is split into more than one brick, further splitting of the inferred candidate bricks in or along the bitstream is indicated (for example, by an encoder) and / or decoded from or along of the bit stream (eg, by a decoder) in a manner similar to the VVC draft standard or any presented embodiment. For example, an encoder may indicate in or along the bitstream and / or a decoder may decode from or along the bitstream a syntax element indicative of the number of bricks within the inferred candidate brick. For example, the syntax element num_bricks_minus2[ i ] can be used, where num_bricks_minus2[ i ] plus 2 specifies the number of bricks in the inferred candidate brick of order i. The height of each brick within an inferred candidate brick in or along the bitstream is indicated and / or decoded from or along the bitstream (except the last brick of the inferred candidate brick, whose width can be inferred containing all of the remaining, as yet unallocated area of ​​the inferred candidate brick). For example, brick_row_height_minus1[ i ][ j ] can be used, where brick row height minusl [ i ][ j ] plus 1 specifies the height of the brick of order j within the inferred candidate brick of order i in CTU units. Therefore, the syntax and semantics for signaling the brick and tile subdivision according to the embodiments provide significant savings in the number of syntax elements and syntax lines needed to perform the signaling. As a result, significant savings are achieved in the number of bits required to indicate piece and brick subdivision. These benefits are illustrated by the following example, where three different tile and brick subdivisions, shown in Figures 9a, 9b and 9c, are used to compare tile and brick subdivision performance according to VVC draft 5 and the subdivision of piece and brick according to some embodiments. Figures 10a and 10b present the tile and brick subdivisions that achieve the 6K Effective Equirectangular Projection (ERP) and Cube Map Projection (CMP) schemes (respectively) described in the Format. Omnidirectional Media QLizbLn / LZnZ / Β / ΥΙΛΙ (OMAF, ISO / IEC 23090-2) articles D.6.3 and D.6.4 (respectively). These schemes have been recommended in the VR Industry Forum Guidelines. The scheme presented in Figure 10c is otherwise equivalent to that of Figure 10b, but uses a different image aspect ratio. The following properties were derived from VVC Draft 5 and the realization combining both the indication of tile columns and tile-column level brick heights and explicit / uniform tile / brick subdivision unified marking: - The number of syntax elements to indicate brick and tile subdivision - The number of syntax lines to indicate brick and tile subdivision - The number of bits required to indicate the subdivision of piece and brick for the schemes included in the figure below - The percentage bit count savings provided by the implementation when compared to VVC draft 5 for the schemes presented in the figure below. QLtzbLn / LZnZ / B / YIAI The derived properties with luma CTB size of 128x128 are presented in the table below. 6K Effective ERP 6K Effective CMP 3x6 Piece Grid 6" Grid 6K Effective CMP 3 Pieces # of Syntax Elements # of Syntax Lines # of Bits # of Bit Savers # of Bits # of Bit Savers # of Bits # of Bit Savers VVC Draft 5 13 26 74 54 84 Proposal 7 20 33 55% 24 56% 28 67% Consequently, it can be seen that the number of syntax elements is reduced from 13 to 7 and the number of required syntax lines is reduced from 26 to 20. The bit save count provided by the implementation for each of the subdivision of piece and brick of Figures 10a - 10c is more than 50% when compared to VVC draft 5. It is also observed that with the proposal, the semantics and derivation processes also become shorter. Indicate pieces or bricks not coded In some applications, it might be reasonable to assign the content to be encoded and / or decoded to pieces and / or bricks in a way that only a subset of pieces and / or bricks are occupied. For example, in 360 degree video viewing port-dependent streaming, only a subset of independently coded image regions, such as pieces, can be received. In another example, a dot or volumetric cloud video patch-based encoding is applied, and the patches occupy only a subset of the image pieces and / or bricks. According to one embodiment for encoding, unencoded pieces or bricks are indicated in a syntax structure above slice data in or along a bit stream. Syntax elements are not coded for parts or bricks not coded in the cutting data. Uncoded pieces or bricks are reconstructed (eg, into a decoded reference image) using a predefined or indicated method, such as setting the reconstructed sample values ​​to 0 in the sample series. According to one embodiment for decoding, unencoded pieces or bricks are decoded from a syntax structure prior to slice data from or along a bit stream. Syntax elements for uncoded parts or bricks are not decoded from the cutting data. Uncoded pieces or bricks are decoded (eg, into a decoded reference picture) using a predefined or indicated method, such as setting the reconstructed sample values ​​to 0 in the sample strings. According to one embodiment, applicable to encoding and / or decoding, the number of unencoded and / or decoded bricks for a column of pieces is indicated, for example, using a variable length codeword, such as ue(v ). The bricks in the column of pieces are traversed in a predefined exploration order (for example, from bottom to top). For each brick traversed, a flag is indicated and / or decoded to conclude whether or not the brick is unencrypted. If the brick is uncoded, the number of bricks left to be assigned as uncoded is reduced by 1. The process continues until there are no bricks left to be assigned as uncoded. Figure 11 shows a block diagram of a video decoder suitable for employing embodiments of the invention. Figure 11 depicts a structure of a two layer decoder, but it should be appreciated that the decoding operations can be similarly employed in a single layer decoder. The video decoder 550 comprises a first decoder section 552 for a base layer and a second decoder section 554 for a predicted layer. Block 556 illustrates a demultiplexer to deliver information Ql bbl n / ι ΖηΖ / Ε / ΥΙΛΙ with respect to base layer pictures to the first decoder section 552 and for delivering information regarding predicted layer pictures to the second decoder section 554. The reference P'n establishes an expected representation of a photo block. Reference D'n establishes a reconstructed prediction error signal. Blocks 704, 804 illustrate preliminary reconstructed photos (l'n). The R'n reference establishes a final reconstructed photo. Blocks 703, 803 illustrate the inverse transform (T-1). Blocks 702, 802 illustrate reverse quantization (Q-1). Blocks 701,801 illustrate entropy decoding (E'1). Blocks 705, 805 illustrate a reference frame memory (RFM). Blocks 706, 806 illustrate prediction (P) (either inter- or intra-prediction). Blocks 707, 807 illustrate seepage (F). Blocks 708, 808 may be used to combine decoded prediction error information with predicted base layer / predicted layer photos to obtain the preliminary reconstructed photos (l'n). The preliminarily reconstructed and filtered base layer photos may be output 709 from the first decoder section 552 and the preliminarily reconstructed and filtered base layer photos may be output 809 from the first decoder section 554. In this document, decoder should be interpreted as covering any operational unit that can perform decoding operations, such as a player, receiver, gateway, demultiplexer and / or decoder. Figure 12 shows a flow diagram of the operation of the decoder according to one embodiment of the invention. The decoding operations of the embodiments are otherwise similar to the encoding operations, except that the decoder decodes the indications therefrom. Thus, the decoding method comprises decoding (1200) a bit stream portion comprising an indication of tile columns and an indication of brick heights for one or more tile columns at a time; infer (1202), upon detecting rows of bricks aligned across an image, rows of potential pieces; infer (1204) that or decode an indication of whether a potential tile row boundary is a tile row boundary; and decoding (1206) one or more images from the bitstream using the indicated tile columns, indicated or inferred tile rows, and indicated brick heights, where QLizbLn / LZnZ / Β / ΥΙΛΙ the one or more images are subdivided into a tile grid along indicated tile columns and indicated or inferred tile rows, a tile in the tile grid comprises an integer number of units codetree unit and is subdivided into one or more bricks, where a brick comprises an integer number of codetree unit rows within a piece. Figure 13 shows a flowchart of the operation of the decoder according to another embodiment of the invention. The decoding method comprises the steps of a) decoding (1300) an indication of a number of partitions to be allocated; b) determining (1302) a number of drives to be allocated to the partitions; c) determining (1304) whether the number of units to be allocated is equally allocated to said number of partitions; and, if not, d) determining (1306) a number of drives to be assigned to a next partition, and e) repeating (1308) steps c) and d) until all drives have been assigned to a partition. Indicate subdivision of an image to rectangular slices Embodiments for improved methods for rectangular slice encoding and / or decoding signaling are introduced in the following paragraphs. The embodiments may be applied together with or independently of the brick and tile subdivision embodiments. The realizations are based on definitions and characteristics of pieces, bricks and rectangular cuts as specified in VVC draft 5. With the embodiments, the bit count required to indicate rectangular slices (eg, indicate or derive the location, width, and height of rectangular slices) is reduced. An encoding method according to a first aspect comprises indicating, in or along a bit stream, or inferring a location of a top left brick of a rectangular slice; conclude from the location whether the rectangular cut comprises one or more one-piece bricks; if the rectangular cut comprises one or more bricks in one piece, indicate, in or along the bit stream, or infer the number of bricks in the rectangular cut. A decoding method according to a first aspect comprises decoding, from or along a bit stream, or inferring a location of a top left brick of a rectangular slice; conclude from the location whether the rectangular cut comprises one or more one-piece bricks; if the rectangular cut comprises one or more one-piece bricks, decode, from or QLizbLn / LZnZ / Β / ΥΙΛΙ along the bitstream, or infer the number of bricks in the rectangular slice. The location of a brick can be, for example, a brick index in the brick scan of an image. In an embodiment applicable to encoding and / or decoding, when the location of the upper left brick of the rectangular cut is not the upper left brick of any piece, it is concluded that the rectangular cut comprises one or more bricks of one piece. In an embodiment applicable to encoding and / or decoding, when the location of the upper left brick of the rectangular cut is the upper left brick of a piece and the piece comprises multiple bricks, it is concluded that the rectangular cut can comprise any of bricks from a piece or complete pieces. In an embodiment applicable to encoding, if it is concluded that the rectangular slice may comprise either one-piece or whole-piece bricks, it is indicated in or along the bitstream whether the rectangular slice comprises one-piece or whole-piece bricks. In an embodiment applicable to decoding, if it is concluded that the rectangular slice may comprise either one-piece bricks or whole pieces, it is decoded from or along the bitstream whether the rectangular slice comprises one-piece bricks or whole pieces. . In an embodiment applicable to encoding and / or decoding, it is inferred or indicated (as part of the encoding) or decoded that the rectangular slice comprises one-piece bricks, a variable, for example, called numDeltaValues, is set equal to the number of bricks after the location of the upper left brick of the rectangular cut and within the same piece. If numDeltaValues ​​is equal to 1, it is inferred that the rectangular cut contains exactly one brick. Otherwise, the numDeltaValues ​​variable is used when deriving the syntax element length for a first syntax element indicating the lower right brick of the rectangular cut or for a second syntax element indicating the number of bricks in the rectangular cut or for a third syntax element indicating the height (in bricks) of the rectangular cut or any similar syntax element. For example, the first or second or third syntax element or any similar syntax element can be encoded by u(v) and its length is Ceil( Log2( numDeltaValues ​​) ) bits. In an example embodiment, the following syntax is used: QLizbLn / LZnZ / Β / ΥΙΛΙ pie parameter set rbsp() {Descriptor if( rect slice flag && ¡single brick per slice flag ) {num slices in pie minusl ue(v) for( ¡ = 0; i <= num slices in pie minusl; i++ ) {if (i > 0 ) top left brick idx[ i ] u(v) if( numDeltaValues ​​> 0 ) bottom right brick idx deltaf i ] u(v)}} QLizbLn / LZnZ / Β / ΥΙΛΙ The syntax element semantics can be specified as described above, except that bottom_right_br¡ck_idx_delta[ i ] specifies the difference between the brick index of the brick located in the bottom right corner of the order break i and top_left_brick_idx[ i ]. When single_brick_per_sl¡ce_flag is equal to 1, the value of bottom_right_brick_idx_delta[ i ] is inferred to be equal to 0. When not present, the value of bottom_right_br¡ck_¡dx_delta[ i ] is inferred to be equal to 0. The variable numDeltaValues, which specifies the number of values ​​that bottom_right_br¡ck_idx_delta[ i ] can have, is derived as follows: if( BrickldxlnTile[ brldx ] > 0 ) numDeltaValues ​​= NumBrickslnTile[ top_left_brick_idx[ i ] ] - BhckldxlnTile[ top_left_brick_idx[ i ] ] else numDeltaValues ​​= NumBricksInPic - top_left_brick_idx[ i ] The length of the bottom_right_br¡ck_¡dx_delta[ i ] syntax element is Ceil( Log2( numDeltaValues ​​)) bits. The NumBrickslnTile[ brickldx ] variable specifies the number of bricks in the tile that contains the brick with index brickldx in the brick scan of an image. The BrickldxlnTile[ brickldx ] variable specifies the index of the brick within the tile containing the brick, when the brick is identified by the brickldx index in the brick scan of an image. In an embodiment applicable to encoding and / or decoding, a location of a top left brick is inferred from a rectangular slice. At the start, all brick locations are marked as empty. A loop of assigning bricks to rectangular slices is included in or along the bitstream or is decoded from or along the bitstream. For each loop input, the top left brick of a rectangular slice is inferred to be the next empty brick location in a predefined, indicated, or decoded scan order. For example, it can be predefined, for example, in a coding rule that is used in the brick scan order within the image. The lower right brick of a rectangular cut can be inferred, indicated or decoded, for example, as described above, and the bricks that make up the rectangle enclosed by the upper left brick and the lower right brick are marked as assigned. The same or similar process is repeated for each loop entry. In an embodiment 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 comprises pieces complete, the syntax element to indicate the lower right brick of the rectangular cut is derived from one or more of the following: - It derives a set of possible lower right brick locations. The set can comprise only those brick locations that are the last brick locations within a tile, are located on or below the row of tiles containing the top left brick of the rectangular cut, are located on or to the right of the column of tiles containing the top left brick of the rectangular cut, and enclose a rectangular set of empty tile locations (not yet assigned to any rectangular cut). - Entries in the lower right set of possible brick locations are indexed or listed. - The length of the syntax element encoded by u(v) to indicate the lower right brick of the rectangular cut is derived from the number of entries in the set of possible lower right brick locations. If the number of numEnt entries is equal to 1, the lower right brick index need not be given. Otherwise, the length of the syntax element is equal to Ceil( Log2( numEnt) ) bits. - The syntax element to indicate the lower right brick of the rectangular cut is an index to the enumerated set of possible lower right brick locations. An encoding method according to a second aspect comprises QLizbLn / LZnZ / Β / ΥΙΛΙ - indicate, in or along a bit stream, or infer a location of a top left brick of a rectangular slice; - conclude from the location if the rectangular cut comprises one or more bricks in one piece; - if the rectangular cut comprises one or more one-piece bricks, infer a width of the rectangular cut that is equal to one piece column, otherwise if the top left brick is in the rightmost column of pieces, infer the width of the rectangular cut that is equal to a column of pieces, and otherwise indicating, in or along the bitstream, the width of the rectangular cut in columns of pieces; - if the rectangular cut comprises one or more bricks in one piece, indicate, in or along the bit stream, or infer the number of bricks in the rectangular cut; otherwise, if the top left brick is in the bottommost row of tiles, infer the height of the rectangular cut that is equal to one row of tiles, and otherwise indicate, in or along the bitstream, the height of the rectangular cut into rows of pieces. A decoding method according to a second aspect comprises - decode, from or along a bit stream, or infer a location of a top left brick of a rectangular slice; - conclude from the location if the rectangular cut comprises one or more bricks in one piece; - if the rectangular cut comprises one or more one-piece bricks, infer a width of the rectangular cut that is equal to one piece column, otherwise if the top left brick is in the rightmost column of pieces, infer the width of the rectangular slice that is equal to one column of pieces, and otherwise decoding, from or along the bit stream, the width of the rectangular slice in columns of pieces; - if the rectangular cut comprises one or more bricks in one piece, decode, from or along the bit stream, or infer the number of bricks in the rectangular cut; otherwise if the top left brick is in the bottommost row of tiles, infer the height of the rectangular cut which is equal to one row of tiles, and otherwise decode, from or along the bit stream, the height of the rectangular cut in rows of pieces. QLizbLn / LZnZ / Β / ΥΙΛΙ In an embodiment applicable to encoding and / or decoding and applicable to the first aspect and / or second aspect, the number of bricks in a rectangular cut is inferred to be equal to 1 (in bricks), when completed or indicated or decoded that the rectangular cut contains one-piece bricks and the piece contains two bricks and the current brick (i.e., the top left brick of a rectangular cut) is the top brick in the piece, or the current brick is the bottommost brick one piece. QLizbLn / LZnZ / Β / ΥΙΛΙ In an example embodiment, the following syntax is used: Descriptor if( Isingle brick per slice flaq ) {num slices in pie minusl ue(v) for( i = 0; i < num slices_in_pic_minus1; i++ ) {if( BrickldxlnTile[ tlBrickldx ] = = 0 && numFreeColumnsOnTheRightf tlBrickldx] > 1 ) s high school width minus1[¡] u(v) if( slice_w¡dth_m¡nus1[ i ] = = 0 && BrickldxlnTile[ tlBrickldx ] = = 0 && NumBricksInTilef tlBrickldx ] > 1 ) full tiles in slice flag[ i ] u(1) if ( numFreeRowsBelowf tlBrickldx l > 1 ) {slice height minuslji] u(v)}} The variables and semantics of the syntax elements can be specified as described above with the following additions: - tiBrickldx can be specified as the next empty brick location in a predefined scan order, such as brick scanning in an image, as described above. tlBrickldx is derived again for each value of i, that is, for each loop input. - numFreeColumnsOnTheRight[ brickldx ] is a variable indicating the number of brick columns to the right of the brick with index brickldx. - slice_width_minus1 [ i ] plus 1 specifies the width of the rectangular slice of order i in columns of pieces. When not present, slice_width_minus1 [ i ] is inferred to be equal to 0. - full_tiles_in_sl¡ce_flag[ i ] equals 0 specifies that the rectangular slice of order i contains one or more single-piece bricks. full_tiles_in_slice_flag[ i ] equals 1 specifies that the rectangular slice of order i contains one or more full tiles. full_tiles_in_slice_flag[ i ] is inferred to equal 0, when BrickldxlnTile[ tlBrickldx ] is greater than 0 (ie when the top left brick of the rectangular slice is not a top left brick of some tile). full_tiles_in_slice_flag[ i ] is inferred to equal 1, when slice_width_minus1 [ i ] is greater than 0 or when BrickldxlnTile[ tlBrickldx ] equals 0 and NumBrickslnTile[ tlBrickldx ] equals 1. - If full_tiles_¡n_sl¡ce_flag[ i ] is equal to 0, numFreeRowsBelow[ brickldx ] is a variable indicating the number of bricks in a tile below the brick with index brickldx in the same tile. Otherwise, numFreeRowsBelow[ brickldx ] is a variable indicating the number of tile rows below the tile that contains the brick with index brickldx. - If full_tiles_in_slice_flag[ i ] equals 0, then slice_height_minus1 [ i ] plus 1 specifies the height of the ith-order rectangular slice in bricks. Otherwise, slice_height_minus1[ i ] plus 1 specifies the height of the rectangular slice of order i in rows of pieces. When not present, slice_height_minus1[ i ] is inferred to be equal to 0. In an embodiment applicable to encoding and / or decoding, the slice width syntax element (eg slice_width_minus1) is derived from the number of possible values ​​based on the location of the top left brick of the rectangular slice. Using the above variables and syntax elements, the length of slice_width_minus1 is equal to Ceil( Log2( numFreeColumnsOnTheRight[ tlBrickldx ] + 1 ) ). In one embodiment applicable to encoding and / or decoding, the slice-length-height syntax element (eg, slice_height_minus1) is derived from the number of possible values ​​based on the top-left brick location of the rectangular slice and whether the rectangular cut includes bricks in a single piece or complete pieces. Using the above variables and syntax elements, the length of slice_height_minus1 is equal to Ceil( Log2( numDeltaValues ​​)), where numDeltaValues ​​is derived as follows: if( full_tiles_in_slice_flag[ i ] = = 0) numDeltaValues ​​= NumBrickslnTile[ tlBrickldx ] - BrickldxlnTile [ tlBrickldx ] else numDeltaValues ​​= numFreeRowsBelow[ tlBrickldx ] + 1 Embodiments for improved methods for signaling are introduced QLizbLn / LZnZ / Β / ΥΙΛΙ encoding and / or decoding of rectangular slices in the following paragraphs. The embodiments may be applied together with or independently of the brick and tile subdivision embodiments. The embodiments are based on definitions and characteristics of one or more of pieces, bricks, rectangular slices and subimages as specified in VVC draft 6. With the embodiments, the bit count required to indicate rectangular slices (eg, indicate or derive the location, width, and height of rectangular slices) is reduced. According to one embodiment, one and only one rectangular slice per subimage is encoded. An encoder indicates in or along the bitstream, eg in a PPS, that for pictures in the scope of the indication, one and only one rectangular slice per sub-picture is encoded. The scope of the indication can be, for example, images referencing a PPS that contains the indication of one and only one rectangular slice per subimage being used. The encoder omits explicit flagging of rectangular slice boundaries. The encoder infers the boundaries of rectangular slices that are the same as the boundaries of the subimages. According to one embodiment, a decoder decodes from or along the bit stream, eg from a PPS, which an indication that each sub-picture comprises one and only one rectangular slice in the pictures in the scope of the indication. The scope of the indication can be, for example, images referencing a PPS containing the indication. The decoder omits the explicit marking of the boundaries of rectangular slices. The decoder infers the boundaries of rectangular slices to be the same as the boundaries of the subimages. The following or similar syntax may be used, with the embodiments described above, where single_slice_per_subpic_flag equals 0 specifies that subimages can contain any number of rectangular slices, and single_slice_per_subpic_flag equals 1 specifies that each subimage contains one and only one rectangular slice: QLtzbLn / LZnZ / Β / ΥΙΛΙ pie parameter set rbsp() {Descriptor ... single tile in pie flag u(1) if( Isingle tile in_pic flag ) {single brick per slice flag u(1) pie parameter set rbsp() {Descriptor if( Isingle black per slice flag ) rect slice flag u(1) if( rect slice flag && Isingle black per slice flag ) {single slice per subpic flag u(1) if( Isingle slice per subpic flag ) {num slices in pie minusl ue(v) bottom right brick idx length minusl ue(v) for( i = 0; i < num slices in pie minusl; i++ ) {bottom right brick idx deltaf i ] u(v ) sign bottom right brick idx delta[ i ] u(1)}}}}} According to one embodiment, an encoder signals into or along the bitstream, eg into a PPS, and / or a decoder decodes from or along the bitstream, eg from a PPS. , if a subimage consists of one and only one rectangular slice or if it contains more than one rectangular slice. For example, a syntax element encoded with u(1), for example called subpic_split_flag[ i ], can indicate (when equal to 0) that the subpicture of order i consists of exactly one rectangular slice or (when equal to 1 ) that the subimage of order i consists of more than one rectangular slice. According to one embodiment, an encoder indicates and / or decodes the subdivision of a subimage into rectangular slices using brick indices within the subimage. Bricks within the subimage are indexed, for example, starting from 0 and incremented by 1 in a predefined scan order, such as the brick scan order within the subimage, i.e. part row scan within the subimage as a major order, and scanning by brick rows within a piece as a minor order. Since the range of values ​​of brick indices within a subimage is smaller than the range of values ​​of brick indices within an image, the syntax elements for indicating brick indices within a subimage are likely to be shorter. than the respective syntax elements for brick indices within an image, and thus signaling is likely to become more compact. According to one embodiment, the following syntax or the like may be used. • • single brick per slice flag u(1) • if( isingle brick per slice flag && NumSubPics = = 1 ) • rect slice flag u(1) • if( rect slice flag && Isingle brick per slice flag ) {• rect slice splitting present flag u(1) • if( rect slice splitting present flag ) {• bottom right brick idx length minusl ue(v) • for( i = 0; i < NumSubPics; i++ ) {• subpic split flagf i ] u( 1) • if( subpic split flagf i ]) {• num slices in subpic minus2[ i ] ue(v) • for( j = 0; j <= num slices in subpic minus2; i++ ) {• bottom right brick idx deltaf i ][ j ] u(v) • sign bottom right brick idx deltaf i ]H 1 u(1) •} •} •} •} •} • QLizbLn / LZnZ / Β / ΥΙΛΙ rect_slice_splitting_present_flag equal to 0 specifies that there is exactly one rectangular slice in each subimage. rect_slice_splitt¡ng_present_flag equal to 1 specifies that each subimage can contain one or more rectangular slices. bottom_nght_br¡ck_¡dx_length_minus1 plus 1 specifies the length of the bottom_right_bñck_¡dx_delta[ i ] syntax element. The NumSubPics variable is derived to be equal to the number of subpictures within a picture, eg, based on subpicture flagging in an SPS. subpic_split_flag[ i ] equals 0 specifies that the subimage of order i consists of exactly one rectangular slice. subpic_split_flag[ i ] equals 1 specifies that the subpicture of order i consists of more than one rectangular slice. num_slices_in_subpic_minus2[ i ] plus 2 specifies the number of rectangular slices within the subimage of order i. The bricks within the subimage of order i are indexed in brick scan order. bottom_right_brick_idx_delta[ i ][ j ] and sign_bottom_right_br¡ck_¡dx_delta[ i ][ j ] specify a signed delta value that is used to derive the brick index of the bottom right brick of the order j slice within the order subimage i relative to the lower right brick of the rectangular slice of order (j 1) of the subimage of order i, when j is greater than 0, or relative to 0 (i.e., the upper left corner of the subimage of order i) , when j equals 0. The signed delta value can be defined to equal bottom_right_brick_¡dx_delta[ i ][ j ], when sign_bottom_ñght_br¡ck_¡dx_delta[ i ][ j ] equals 1, and -bottom_right_brick_idx_delta[ i ][ j ], when sign_bottom_r¡ght_brick_¡dx_delta[ i ][ j ] equals 0, but could be defined analogously with the opposite assignment of the values ​​of sign_bottom_ñght_br¡ck_¡dx_delta[ i ][ j ]. Indicate uncoded rectangular cuts In some applications, it might be reasonable to assign the content to be encoded and / or decoded to rectangular slices in a way that only a subset of rectangular slices is occupied. For example, in streaming dependent on the 360 ​​degree video viewing port, only a subset of rectangular slices can be received. In another example, a dot or volumetric cloud video patch-based encoding is applied, and the patches occupy only a subset of the rectangular slices of the image. According to one embodiment for encoding, unencoded rectangular slices are indicated in or along a bitstream, eg in PPS. Uncoded rectangular slices are not encoded as VCL NAL units in the bitstream. Uncoded rectangular slices are reconstructed (eg, into a decoded reference image) using a predefined or indicated method, such as setting the reconstructed sample values ​​to 0 in the sample series. According to one embodiment for decoding, uncoded rectangular slices are decoded from or along a bit stream, eg from PPS. Uncoded rectangular slices are not decoded from VCL NAL units from the bitstream. Instead, uncoded rectangular slices (eg, into a decoded reference picture) are decoded using a predefined or indicated method, such as setting the decoded sample values ​​to 0 in the sample strings. According to an embodiment applicable to encoding and / or decoding, a flag is indicated and / or decoded for each rectangular slice, the flag being indicative of whether or not the rectangular slice is unencrypted. According to one embodiment, the number of rectangular cuts is indicated Ql bbl Π / l ΖΠ7 / Ε / ΥΙΛΙ not encoded and / or is decoded using a variable length code word, such as ue(v). Rectangular slices are traversed in a predefined scan order (in a reverse row-scan order of the top left CTUs of rectangular slices). For each rectangular slice traversed, a flag is flagged and / or decoded to conclude whether or not the rectangular slice is uncoded. If the rectangular slice is uncoded, the number of rectangular slices left to be assigned as uncoded is reduced by 1. The process is continued until there are no rectangular slices left to be assigned as uncoded. Figure 15 is a graphical representation of an example multimedia communication system in which various embodiments may be implemented. A data source 1510 provides a source signal in an analog, uncompressed digital, or compressed digital format, or any combination of these formats. An encoder 1520 may include or be connected to preprocessing, such as data format conversion and / or filtering of the source signal. Encoder 1520 encodes the source signal into an encoded media bitstream. It should be noted that a bit stream to be decoded can be received directly or indirectly from a remote device located on virtually any type of network. Additionally, the bit stream can be received from local hardware or software. Encoder 1520 may encode more than one media type, such as audio and video, or more than one encoder 1520 may be required to encode different media types of the source signal. Encoder 1520 may also output synthetically produced input, such as graphics and text, or may produce synthetic media encoded bitstreams. In the following, only the processing of an encoded media bit stream of one media type is considered to simplify the description. It should be noted, however, that streaming services typically comprise several streams (typically at least one stream of audio, video and text captioning). It should also be noted that the system may include many encoders, but only one encoder 1520 is shown in the figure to simplify the description without lack of generality. It should further be understood that, although the text and examples contained herein may specifically describe an encoding process, one skilled in the art would understand the same concepts and principles to apply. QLizbLn / LZnZ / Β / ΥΙΛΙ also apply to the corresponding decoding process and vice versa. The encrypted media bitstream may be transferred to a storage 1530. The storage 1530 may comprise any type of mass memory for storing the encrypted media bitstream. The format of the encoded media bitstream in storage 1530 may be any elementary independent bitstream format, or one or more encoded media bitstreams may be encapsulated in a container file, or the encoded media bitstream may be encapsulated. media encoded in a segment format suitable for DASH (or similar streaming system) and stored as a sequence of segments. If one or more media bitstreams are encapsulated in a container file, a file generator (not shown in the figure) can be used to store the one or more media bitstreams in the file and create media format metadata. file, which can also be stored in the file. Encoder 1520 or storage 1530 may comprise the file generator, or the file generator is operatively connected to either encoder 1520 or storage 1530. Some systems operate live, ie bypass storage and transfer media bit streams encoded from encoder 1520 directly to sender 1540. The encoded media bitstream can then be transferred to sender 1540, also referred to as the server, as needed. The format used in the transmission may be an elementary self-contained bitstream format, a packet stream format, a segment format suitable for DASH (or a similar streaming system), or one or more bitstreams. of encrypted media can be encapsulated in a container file. The encoder 1520, storage 1530, and server 1540 may reside on the same physical device or may be included on separate devices. The encoder 1520 and server 1540 can operate with live, real-time content, in which case the encoded media bitstream is typically not stored permanently, but instead is buffered for small amounts of time. periods of time in content encoder 1520 and / or server 1540 to smooth out variations in processing delay, transfer delay, and encoded media bit rate. The 1540 server sends the encoded media bitstream using a stack QLizbLn / LZnZ / Β / ΥΙΛΙ communication protocol. The stack may include, but is not limited to, one or more of Real-Time Transport Protocol (RTP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), Transmission Control Protocol (TCP), and Internet Protocol (IP). When the communication protocol stack is packet-oriented, the server 1540 encapsulates the encoded media bit stream into packets. For example, when using RTP, server 1540 encapsulates the encoded media bitstream into RTP packets according to an RTP payload format. Typically, each media type has a specialized RTP payload format. It should again be noted that a system may contain more than one 1540 server, but for the sake of simplicity the following description only considers one 1540 server. If the media content is encapsulated in a container file for storage 1530 or for inputting data to sender 1540, sender 1540 may comprise or be operatively connected to a send file parser (not shown in the figure). In particular, if the container file is not transmitted as such, but at least one of the contained encoded media bit streams is encapsulated for transport via a communication protocol, a send file parser locates appropriate parts of the bit stream. media bits encoded to be transmitted over the communication protocol. The delivery file parser can also help create the correct format for the communication protocol, such as packet headers and payloads. The media container file may contain encapsulation instructions, such as token tracks in the ISOBMFF, for encapsulation of the at least one of the media bitstream contained in the communication protocol. Server 1540 may or may not be connected to a gateway 1550 through a communication network, which may be, for example, a combination of a CDN, the Internet, and / or one or more access networks. The gateway may also or alternatively be referred to as an intermediate switchboard. For DASH, the gateway can be an edge server (of a CDN) or a web intermediary. It is noted that the system can comprise, in general, any number of gateways or the like, but for the sake of simplicity, the following description only considers one gateway 1550. The gateway 1550 can perform different types of QLizbLn / LZnZ / Β / ΥΙΛΙ functions, such as a translation of a packet flow according to one communication protocol stack to another communication protocol stack, joining and forking of data streams, and data flow manipulation of according to downlink and / or receiver capabilities, such as controlling the bit rate of the forwarded stream according to prevailing downlink network conditions. Gateway 1550 may be a server entity in various embodiments. The system includes one or more receivers 1560, which typically can receive, demodulate, and decapsulate the transmitted signal into an encoded media bitstream. The encoded media bitstream may be transferred to a recording storage 1570. The recording storage 1570 may comprise any type of mass memory for storing the encoded media bitstream. Record storage 1570 may alternatively or additionally comprise computer memory, such as random access memory. The format of the encoded media bitstream in recording storage 1570 may be an elementary independent 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, a container file is typically used and receiver 1560 comprises or is connected to a container file generator that produces a wrapper file from input streams. Some systems operate live, i.e. they bypass the recording storage 1570 and transfer the encoded media bitstream from the receiver 1560 directly to the decoder 1580. In some systems, only the most recent part of the recorded stream, for example, the extract The most recent 10 minute data of the recorded stream is kept in the recording storage 1570, while any previous recorded data is discarded from the recording storage 1570. The encoded media bitstream may be transferred from the recording storage 1570 to the decoder 1580. If there were many encoded media bitstreams, such as an audio stream and a video stream, associated with each other and encapsulated in a file of container or a single media bitstream is encapsulated in a container file, for example, for easier access, a file parser (not shown in the figure) is used to QLtzbLn / LZnZ / Β / ΥΙΛΙ decapsulate each encoded media bitstream from the wrapper file. The recording storage 1570 or a decoder 1580 may comprise the file parser, or the file parser is connected to either the recording storage 1570 or the decoder 1580. It should also be noted that the system may include many decoders, but at this point only a 1570 decoder is discussed to simplify the description without lack of generality The encoded media bitstream may be further processed by a decoder 1570, whose output is one or more uncompressed media. Finally, a 1590 renderer can play uncompressed media streams with a speaker or display, for example. Receiver 1560, record storage 1570, decoder 1570, and renderer 1590 may reside on the same physical device or may be included on separate devices. In the above, some embodiments have been described with reference to and / or using the terminology of VVC / H.266. It needs to be understood that the embodiments can be similarly performed with any video encoder and / or video decoder. In the above, some exemplary embodiments have been described with reference to specific syntax structures and / or syntax elements. It needs to be understood that embodiments with other syntax structures and / or syntax elements can be similarly performed. For example, when embodiments have been described with reference to syntax elements in the PPS syntax, it is necessary to understand that the embodiments with the same or similar syntax elements may be realized in other syntax structures, such as SPS. In the above, some embodiments have been described with reference to the term indicating. It is necessary to understand that the expression it indicates can be understood as encoding or generating one or more syntax elements in one or more syntax structures in or along a bit stream. In the above, some embodiments have been described with reference to the term decoding. It needs to be understood that the term decoding can be understood as decoding or parsing one or more syntax elements of one or more syntax structures from or along a stream of data. QLizbLn / LZnZ / Β / ΥΙΛΙ bits. In the above, when exemplary embodiments have been described with reference to an encoder, it is necessary to understand that the resulting bitstream and the decoder may have corresponding elements in them. Similarly, when exemplary embodiments have been described with reference to a decoder, it is necessary to understand that the encoder may have structure and / or software for generating the bit stream to be decoded by the decoder. For example, some embodiments related to generating a prediction block as part of the coding have been described. Similar embodiments can be made by generating a prediction block as part of decoding, with the difference that encoding parameters, such as horizontal offset and vertical offset, are decoded from the bitstream other than that determined by the encoder. The above-described embodiments of the invention describe the codec in terms of separate encoder and decoder apparatus to aid understanding of the processes involved. However, it should be appreciated that the apparatus, structures and operations may be implemented as a single codec apparatus / structure / operation. Additionally, it is possible that the encoder and decoder may share some or all of the common elements. Although the above examples describe embodiments of the invention that operate in a codec in an electronic device, it should be appreciated that the invention, as defined in the claims, can be implemented as part of any video codec. Thus, for example, embodiments of the invention may be implemented in a video codec that may implement video encoding over fixed or wired communication paths. Therefore, the user equipment may comprise a video codec, such as those described in the above embodiments of the invention. It should be appreciated that the term "user equipment" is intended to cover any suitable type of wireless user equipment, such as mobile phones, portable data processing devices or portable web browsers. Additional elements of a public land mobile network (PLMN) may also comprise video codecs as described above. QLizbLn / LZnZ / Β / ΥΙΛΙ In general, the various embodiments of the invention may be implemented in hardware or special purpose circuitry, software, logic, or any combination thereof. For example, some 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, although the invention is not limited thereto. Although various aspects of the invention may be illustrated and described as block diagrams, flow charts, or using some other graphical representation, it is well understood that these blocks, apparatus, systems, techniques, or methods described herein may be implemented in, as non-limiting examples, special purpose hardware, software, firmware, circuitry or logic, general purpose hardware or controller or other computing devices, or some combination thereof. Embodiments of this invention may be implemented by computer software executable by a data processor of the mobile device, such as in the processor entity, or by hardware, or by a combination of software and hardware. In addition, in this regard, it should be noted that any blocks in the logic flow, as in the figures, may represent program steps, or interconnected logic circuits, blocks, and functions, or a combination of program steps and logic circuits, blocks, and functions. logic. Software may be stored on such physical media as memory chips, or processor-implemented memory blocks, magnetic media such as a hard drive or floppy disk, and optical media such as, for example, DVDs and data variants of them. themselves, CD. The memory may be of any type appropriate to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory, and removable memory. Data processors may be of any type appropriate to the local technical environment, and may include one or more of general-purpose computers, special-purpose computers, microprocessors, digital signal processors (DSPs), and processors based on multi-core processor architecture. nuclei, as non-limiting examples. QLizbLn / LZnZ / Β / ΥΙΛΙ Embodiments of the inventions can be practiced in various components such as integrated circuit modules. Integrated circuit design is generally a highly automated process. Complex and powerful software tools are available to convert a logic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate. Programs, such as those provided by Sypnopsys, Inc. of Mountain View, California and Cadenee Design of San Jose, California, automatically route leads and place components on a semiconductor chip using well-established design rules as well as libraries of pre-stored design modules. . Once the design for a semiconductor circuit has been completed, the resulting design, in a standard electronic format (eg, Opus, GDSII, or the like) can be transmitted to a semiconductor manufacturing facility or fab for fabrication. The foregoing description has provided by way of illustrative and non-limiting examples a complete and informative description of the illustrative embodiment of this invention. However, various modifications and adaptations may become apparent to those skilled in the art in view of the foregoing description, when read in conjunction with the accompanying drawings and the appended claims. However, all such modifications and the like of the teachings of this invention will still fall within the scope of this invention.

Claims

1. A method comprising determining a number of drives to be allocated to partitions and initializing them as unallocated; indicating or inferring a number of explicitly sized partitions to be allocated; indicating sizes for the explicitly sized partitions and marking unallocated drives accordingly as allocated to partitions in a predefined scan order; indicating a drive count; iteratively allocating the drive count to partitions and marking unallocated drives accordingly as allocated in the predefined scan order until the number of unallocated drives is less than the drive count; and allocating the unallocated drives to a final partition when the number of unallocated drives is greater than 0.

2. The method according to claim 1, wherein the partitions are one or more of the following: columns of pieces; rows of pieces, rows of bricks of one or more columns of pieces; rows of bricks of one piece; columns of grids for a grid used to indicate sub-image subdivision; and rows of grids for the grid used to indicate sub-image subdivision.

3. The method according to claim 1 or 2, wherein the units are one or more of the following: rectangular blocks of samples from an image; and grid cells for the grid used to indicate sub-image subdivision.

4. An apparatus comprising means for determining a number of units to be allocated to partitions and initialized as unallocated; means for indicating or inferring a number of explicitly sized partitions to be allocated; means for indicating sizes for the explicitly sized partitions and means for marking unallocated units accordingly as allocated to partitions in a predefined scan order; means for indicating a unit count; means for repeatedly allocating the unit count to partitions and means for marking unallocated units accordingly as allocated in the predefined scan order until the number of unallocated units is less than the unit count; and means for allocating the unallocated units to a final partition when the number of unallocated units is greater than 0.

5. The apparatus according to claim 4, wherein the partitions are one or more of the following: columns of pieces; rows of pieces, rows of bricks of one or more columns of pieces; rows of bricks of one piece; columns of grids for a grid used to indicate sub-image subdivision; and rows of grids for the grid used to indicate sub-image subdivision.

6. The apparatus according to claim 4 or 5, wherein the units are one or more of the following: rectangular blocks of sample images and grid cells for the grid used to indicate sub-image subdivision.

7. A method comprising: determining a number of drives to be allocated to partitions; determining a number of explicitly sized partitions to be allocated; determining sizes for the explicitly sized partitions and marking unallocated drives accordingly as allocated to partitions in a predefined scan order; determining a drive count; repeatedly allocating the drive count to partitions and marking unallocated drives accordingly as allocated in the predefined scan order until the number of unallocated drives is less than the drive count; and allocating the unallocated drives to a final partition when the number of unallocated drives is greater than 0.

8. The method according to claim 7, wherein determining a number of explicitly sized partitions to be allocated comprises decoding the number of explicitly sized partitions to be allocated from a syntax structure; determining sizes for the explicitly sized partitions comprises decoding the sizes for the explicitly sized partitions from the syntax structure; and determining a unit count comprises decoding the unit count from the syntax structure.

9. The method according to claim 7 or 8, wherein the partitions are one or more of the following: columns of pieces; rows of pieces; rows of bricks of one or more columns of pieces; rows of bricks of one piece; columns of grids for a grid used to indicate sub-image subdivision; and rows of grids for the grid used to indicate sub-image subdivision.

10. The method according to any of claims 7-9, wherein the units are one or more of the following: rectangular blocks of samples from an image; and grid cells for the grid used to indicate sub-image subdivision.

11. An apparatus comprising means for determining a number of drives to be allocated to partitions; means for determining a number of explicitly sized partitions to be allocated; means for determining sizes for the explicitly sized partitions and means for marking unallocated drives accordingly as allocated to partitions in a predefined scan order; means for determining a drive count; means for repeatedly allocating the drive count to partitions and means for marking unallocated drives accordingly as allocated in the predefined scan order until the number of unallocated drives is less than the drive count; and means for allocating the unallocated drives to a final partition when the number of unallocated drives is greater than 0.

12. The apparatus according to claim 11, wherein the partitions are one or more of the following: columns of pieces; rows of pieces; rows of bricks of one or more columns of pieces; rows of bricks of one piece; columns of grids for a grid used to indicate sub-image subdivision; and rows of grids for the grid used to indicate sub-image subdivision.

13. The apparatus according to claim 11 or 12, wherein the units are one or more of the following: rectangular blocks of sample images, grid cells for the grid used to indicate sub-image subdivision.

14. A computer program product comprises at least one non-transient, computer-readable storage medium having computer-executable program code instructions stored thereon, the computer-executable program code instructions comprising program code instructions configured, after execution, to: determine a number of drives to be partitioned and initialized as unallocated; indicate or infer a number of explicitly sized partitions to be allocated; indicate sizes for the explicitly sized partitions and mark unallocated drives accordingly as partitioned in a predefined scan order; indicate a drive count;repeatedly assign the unit count to partitions and mark unassigned units as assigned in the predefined scan order until the number of unassigned units is less than the unit count; and assign the unassigned units to a final partition when the number of unassigned units is greater than 0.

15. A computer program product comprises at least one non-transient, computer-readable storage medium having computer-executable program code instructions stored thereon, the computer-executable program code instructions comprising program code instructions configured, after execution, to: determine a number of drives to be allocated to partitions; determine a number of explicitly sized partitions to be allocated; determine sizes for the explicitly sized partitions and mark unallocated drives accordingly as allocated to partitions in a predefined scan order; determine a drive count; repeatedly allocate the drive count to partitions and mark unallocated drives accordingly as allocated in the predefined scan order until the number of unallocated drives is less than the drive count;and assign the unallocated units to a final partition when the number of unallocated units is greater than 0.;

Images