AN APPARATUS AND METHOD FOR VIDEO ENCODING AND DECODING

Abstract

A method for encoding or decoding video comprising determining a number of units to be allocated to partitions; indicating or inferring a number of explicitly sized partitions to be allocated; indicating sizes for or a number of units in the explicitly sized partitions; and indicating or inferring a number of equally sized partitions to be allocated.

Description

AN APPARATUS AND METHOD 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 a coded image to be divided, or subdivided, into subsets. In video coding, an image or a subregion of an image can be subdivided into subsets (blocks) such that each element of the image or image subregion is located in exactly one of the subsets (blocks). For example, H.265 / HEVC introduced the concept of a coding tree unit (CTU), which has a default size of 64x64 pixels. A CTU can contain a single coding unit (CU) or can be recursively split into multiple smaller CUs, at least 8x8 pixels, based on the quad-tree structure.265 / HEVC also performs piece acknowledgments, which are rectangular and contain an integer number of CTUs, and slices, which are defined based on slice segments that contain an integer number of coding tree units ordered consecutively in the piece scan and are contained in a single NAL unit. Versatile Video Coding (VVC) (MPEG-1 Part 3), also known as ITU-T H.266, is a video compression standard being developed by the Mixed Video Expert Team (JVET) of the Moving Picture Experts Group (MPEG) (officially ISO / IEC JTC1 SC29 WG11) and the Video Coding Expert Group (VCEG) of the International Telecommunication Union (ITU) to succeed 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 piece and brick subdivision, which is suboptimal in many respects, especially with regard to the rate of "LQfrLn / Lznz / e / YiAi" bits required for such signaling. Summary Now, to at least alleviate the above problems, an improved coding method is introduced in this document. A method according to a first aspect comprises encoding, in or along a bitstream, an indication of piece columns and an indication of brick heights for one or more piece columns at a time; inferring, after detecting brick rows aligned across an image, potential piece rows; inferring or indicating whether a boundary of a potential piece row is a boundary of a piece row;and encoding one or more images in the bitstream using the specified piece columns, specified or inferred piece rows, and specified brick heights, wherein the one or more images are subdivided into a piece grid along the specified piece columns and specified or inferred piece rows, a piece in the piece grid comprising an integer number of encoding tree units and is subdivided into one or more bricks, wherein a brick comprises an integer number of rows of encoding tree units within a piece. A method according to a second aspect comprises the stages of a) indicate a number of partitions to be assigned; b) determine a number of units to be allocated to the partitions; c) indicate whether the number of units to be allocated is distributed equally among that number of partitions; and if not, d) indicate a number of units to be assigned to the next partition, and e) Repeat steps c) and d) until all units have been assigned to a partition. According to one realization, this repetition of steps c) and d) is carried out as long as the number of partitions yet to be assigned is greater than one. According to one embodiment, the method further comprises determining whether the number of units yet to be allocated is divisible by the number of partitions yet to be allocated; and, if so, indicating whether the number of units yet to be allocated is allocated equally to the number of partitions yet to be allocated. «LQfrLn / Lznz / e / YiAi According to one realization, if it is inferred or indicated that the number of units yet to be allocated has not been allocated equally to the number of partitions yet to be allocated, or the number of units yet to be allocated is not equally divisible by the number of partitions yet to be allocated, step d) is followed by steps d1) reducing the number of units yet to be allocated to partitions by the indicated number; and d2) decreasing the number of partitions yet to be allocated by one. According to one embodiment, 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. According to one embodiment, the units are rectangular blocks of samples from an image. An apparatus according to a third aspect comprises means for encoding, in or along a bit stream, an indication of piece columns and an indication of brick heights for one or more piece columns at a time; means for inferring, after detecting rows of bricks aligned across an image, potential piece rows; means for inferring or indicating whether a boundary of a potential piece row is a boundary of a piece row;and means for encoding one or more images in the bitstream using the specified piece columns, specified or inferred piece rows, and specified brick heights, wherein the one or more images are subdivided into a piece grid along the specified piece columns and specified or inferred piece rows, a piece in the piece grid comprising an integer number of encoding tree units and is subdivided into one or more bricks, wherein a brick comprises an integer number of rows of encoding tree units within a piece. An apparatus according to a fourth aspect comprises means for indicating a number of partitions to be allocated; means for determining a number of units to be allocated to the partitions; means for indicating whether the number of units to be allocated is allocated equally to said number of partitions; means for indicating, in response to said number of units to be allocated not being allocated equally to said number of partitions, a number of units to be allocated to a subsequent partition; and means for repeating said indicating operations until all units have been allocated to a partition. A method according to a fifth aspect comprises decoding, from or along a bitstream, an indication of piece columns and an indication of brick heights for one or more piece columns at a time; inferring, after detecting brick rows aligned across an image, potential piece rows; inferring or indicating whether a boundary of a potential piece row is a boundary of a piece row;and decoding one or more images from the bitstream using the specified piece columns, specified or inferred piece rows, and specified brick heights, wherein the one or more images are subdivided into a piece grid along the specified piece columns and specified or inferred piece rows, a piece in the piece grid comprising an integer number of encoding tree units and is subdivided into one or more bricks, wherein a brick comprises an integer number of rows of encoding tree units within a piece. A method according to a sixth aspect comprises the stages of a) decode an indication of a number of partitions to be assigned; b) determine a number of units to be allocated to the partitions; c) determine whether the number of units to be allocated is distributed equally among that number of partitions; and if not, d) determine a number of units to be allocated to a subsequent partition, and e) Repeat steps c) and d) until all units have been assigned to a partition. An apparatus according to a seventh aspect comprises means for decoding, from or along a bit stream, an indication of piece columns and an indication of brick heights for one or more piece columns at a time; means for inferring, after detecting rows of bricks aligned across an image, potential piece rows; means for inferring or indicating whether a boundary of a potential piece row is a boundary of a piece row;and means for decoding one or more images from the bitstream using the specified piece columns, specified or inferred piece rows, and specified brick heights, wherein the one or more images are subdivided into a grid of "LQfrLn / Lznz / e / YiAi" pieces along the specified piece columns and specified or inferred piece rows, a piece in the piece grid comprising an integer number of encoding tree units and is subdivided into one or more bricks, wherein a brick comprises an integer number of rows of encoding tree units within a piece. An apparatus according to an eighth aspect comprises means for decoding an indication of a number of partitions to be allocated; means for determining a number of units to be allocated to the partitions; means for determining whether the number of units to be allocated is allocated equally to said number of partitions; means for determining, in response to said number of units to be allocated not being allocated equally to said number of partitions, a number of units to be allocated to a subsequent partition; and means for repeating said determination operations until all the units have been allocated to a partition. Additional aspects relate to devices comprising: at least one processor and at least one memory, said at least one memory being stored with code therein, which when executed by said at least one processor, causes an device to perform at least the 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 accompanying drawings in which: Figure 1 schematically shows an electronic device employing the embodiments of the invention; Figure 2 schematically shows a user team suitable for employing the embodiments of the invention; Figure 3 schematically shows further electronic devices employing embodiments of the invention connected using wired and wireless network connections; Figure 4 schematically shows an encoder suitable for implementing the embodiments of the invention; Figures 5a, 5b, 5c show some examples of subdividing an image into encoding tree units (CTUs), pieces, bricks, and slices; OLQfrLn / Lznz / e / viAi Figure 6 shows the syntax structure for cut, piece, and brick subdivision signaling in accordance with H.266 / VVC Draft 5; Figure 7 shows a flowchart of a coding method according to one aspect of the invention; Figure 8 shows a flowchart of a coding method according to 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 piece 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 according to an embodiment of the invention; Figure 13 shows a flowchart of a decoding method according to another embodiment of the invention; and Figure 14 shows a schematic diagram of an example multimedia communication system within which various implementations can be implemented. DETAILED DESCRIPTION OF SOME EXAMPLE IMPLEMENTATIONS The following describes in further detail a suitable apparatus and possible mechanisms for initiating a viewpoint change. In this regard, reference is first made to Figures 1 and 2, where Figure 1 shows a block diagram of a video encoding system according to an example embodiment, as an illustrative schematic block diagram of an electronic apparatus or device, which may incorporate a codec according to an 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 could be, for example, a mobile terminal or user equipment of a wireless communication system. However, it should be appreciated that the embodiments of the invention can be implemented in any electronic device or apparatus that may require decoding and encoding, or encoding and decoding, video images. «LQfrLn / Lznz / e / YiAi The apparatus 50 may comprise a housing 30 for incorporating and protecting 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 display may be any display technology suitable for displaying a photograph or video. The apparatus 50 may further comprise a numeric keypad 34. In other embodiments of the invention, any suitable data or user interface mechanism may be employed. For example, the user interface may be implemented as a virtual keyboard or data input system as part of a touchscreen. The apparatus may comprise a microphone 36 or any suitable audio input, which may 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, a loudspeaker, or an analog or digital 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 automatic generator). The apparatus may further comprise a camera capable of recording or capturing photographs and / or video. The apparatus 50 may further comprise an infrared port for short-range line-of-sight communication with other devices.In other embodiments, the device 50 may additionally comprise any suitable short-range communication solution such as, for example, a wireless Bluetooth connection or a wired USB / firewire connection. The apparatus 50 may comprise a controller 56, processor, or processor circuitry for controlling the apparatus 50. The controller 56 may be connected to memory 58, which in embodiments of the invention may store data in the form of both photos and audio data and / or may also store instructions for implementation in the controller 56. The controller 56 may further be connected to codec circuitry 54 suitable for carrying out encoding and decoding of audio and / or video data or assisting in the encoding and decoding carried out by the controller. The device 50 may additionally comprise a card reader 48 and a smart card 46, for example, a UICC and LUCO reader to provide user information and be suitable for providing "LQfrLn / Lznz / e / YiAi" authentication information for user authentication and authorization on 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 communications network, a wireless communications system, or a wireless local area network. The apparatus 50 may further comprise an antenna 44 connected to the radio interface circuitry 52 for transmitting radio frequency signals generated in the radio interface circuitry 52 to another apparatus or apparatuses and for receiving radio frequency signals from another apparatus or apparatuses. The apparatus 50 may comprise a camera capable of recording or detecting individual frames, which are then passed to the codec 54 or controller for processing. The apparatus may receive video or photo 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. Figure 3 shows an example of a system within which the embodiments of the present invention may be used. System 10 comprises multiple communication devices that can communicate through one or more networks. System 10 may comprise any combination of wired or wireless networks, including, but not limited to, a wireless cellular network (such as a GSM, UMTS, CDMA, etc. network), a wireless local area network (WLAN) 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 the apparatus 50 suitable for implementing the embodiments of the invention. For example, the system shown in Figure 3 shows a mobile phone network 11 and an internet representation 28. Internet connectivity 28 may include, but is not limited to, long-range wireless connections, short-range wireless connections and various wired connections that include, but are not limited to, telephone lines, cable lines, power lines and similar communication routes. The example communication devices shown in system 10 may include, but are not limited to, an electronic device or apparatus 50, a combination of a personal digital assistant (PDA) and a mobile phone 14, a PDA 16, an integrated messaging device (IMD) 18, a desktop computer 20, and a laptop computer 22. The apparatus 50 may be fixed or mobile when carried by an individual who is in motion. The apparatus 50 may also be located in a mode of transport that includes, but is not limited to, a car, a truck, a taxi, a bus, a train, a boat, an airplane, a bicycle, a motorcycle, or any similar suitable mode of transport. The implementations can also be implemented in a living room set-top box; that is, a digital TV receiver, which may / may not have a screen or wireless capabilities, in tablets or personal computers (laptops) (PCs), which have hardware or software or combination of the encoder / decoder implementations, in various operating systems, and in chipsets, processors, DSPs and / or embedded systems that offer hardware / software-based encoding. Some devices or add-ons can send and receive calls and messages and communicate with service providers via a wireless connection to a base station. The base station can connect to a network server that enables communication between the mobile network and the internet. The system may include additional communication devices and various types of communication devices. Communication devices may communicate using various transmission technologies including, but not limited to, Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), 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, Picture Messaging Service (IMS), Bluetooth, IEEE 802.11, and any similar wireless communication technology. A communication 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 other suitable connection. In telecommunications 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 across a multiplexed medium, which can carry multiple logical channels. A channel can be used to carry an information signal, for example, a bit stream, from one or more transmitters to one or more receivers. An MPEG-2 transport stream (TS), specified in ISO / IEC 13818-1 or equivalently the ITU-T H.222.0 recommendation, 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 packed 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 as ISOBMFF) and the file format for NAL unit structured video (ISO / IEC 14496-15), which is derived from ISOBMFF. A video codec consists of an encoder that transforms the input video into a compressed representation suitable for storage or transmission, and a decoder that decompresses the compressed video representation back into a viewable form. A video encoder and / or a video decoder can also be separate components; that is, they do not necessarily form a single codec. Typically, the encoder discards some information from the original video stream to represent the video in a more compact form (i.e., at a lower bit rate). Typical hybrid video encoders, such as many ITU-T H.263 and H.264 encoder implementations, encode video information in two stages. First, pixel values ​​are predicted for a certain area (or block) of the image, for example, by motion compensation (finding and specifying an area in one of the previously encoded video frames that closely corresponds to the block being encoded) or by spatial means (using the pixel values ​​around the block to be encoded in a specified manner). Second, the prediction error—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 (e.g., Discrete Cosine Transform (DCT) or a variant thereof), quantizing the coefficients, and encoding the quantized coefficients by entropy. By varying the fidelity of the quantization process, the encoder can control the balance between the accuracy of the pixel representation (image quality) and the size of the resulting encoded video representation (file size or transmission bitrate). In time-based prediction, the prediction sources are previously decoded images (also known as reference images). In intra-block copy (IBC; also known as intra-block copy prediction), prediction is applied similarly to time-based prediction, but the reference image is the current image, and only previously decoded samples can be referenced during the prediction process. Inter-layer or inter-view prediction can be applied similarly to time-based prediction, but the reference image is a decoded image from another scalable layer or view, respectively.In some cases, interprediction may refer only to time prediction, while in others, intraprediction may collectively refer to time prediction and any intra-block copy, inter-layer prediction, or inter-view prediction, provided they are performed using the same or a similar process to time prediction. Interprediction or time prediction may sometimes be called motion compensation or motion-compensated prediction. Interprediction, also known as temporal prediction, motion compensation, or motion-compensated prediction, reduces temporal redundancy. In interprediction, the prediction sources are previously decoded images. Intraprediction utilizes the fact that adjacent pixels within the same image are likely to be correlated. Intraprediction can be performed in the spatial domain or the LQfrLn / Lznz / e / YiAi transform domain; that is, sample values ​​or transform coefficients can be predicted. Intraprediction is typically leveraged in intracoding, where interprediction is not applied. One result of the encoding procedure is a set of encoding parameters, such as motion vectors and quantized transform coefficients. Many parameters can be encoded more efficiently by entropy if they are first predicted from spatially or temporally neighboring parameters. For example, a motion vector can be predicted from spatially adjacent motion vectors, and only the difference relative to the motion vector predictor can be encoded. The prediction of encoding parameters and intra-prediction can be collectively referred to as within-image prediction. Figure 4 shows a block diagram of a video encoder suitable for employing the embodiments of the invention. Figure 4 presents an encoder for two layers, but it should be appreciated that the presented encoder could be similarly enlarged 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. Each of the first encoder section 500 and the second encoder section 502 may 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 implementation of the pixel predictor 302, 402 comprising an inter-predictor 306, 406, an intra-predictor 308, 408, a mode selector 310, 410, a filter 316, 416, and a reference frame memory 318, 418. The pixel predictor 302 in the first encoder section 500 receives 300 base-layer photos from 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) and the intra-predictor 308 (which determines a prediction for a photo block based only on the already processed portions of the current frame or image). The output of both the inter-predictor and the intra-predictor is passed to the mode selector 310. The intra predictor 308 can have more than one intra prediction mode. Therefore, each mode can perform intra prediction and provide the predicted signal to the mode selector 310.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 from a video stream to be encoded in both the inter-predictor 406 (which determines the difference between the photo and a motion-compensated reference frame 418) and the intra-predictor 408 (which determines a prediction for a photo block based only on the already processed portions of the current frame or image). The output of both the inter-predictor and the intra-predictor is passed to mode selector 410. Intra-predictor 408 can have more than one intra-prediction mode. Therefore, each mode can perform the intra-prediction and provide the predicted signal to mode selector 410. 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 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 mode selector 310, 410. The mode selector output is then passed to a first summing device 321, 421. The first summing device can subtract the output of pixel predictor 302, 402 from the base layer image 300 / enhance layer image 400 to produce a first prediction error signal 320, 420, which is fed to the prediction error encoder 303, 403. 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, which receives the preliminary representation, can filter the preliminary representation and output a final reconstructed photo 340, 440 that can be written to a reference frame memory 318, 418. The reference frame memory 318 can be connected to the inter-predictor 306 for use as the reference photo against which a future base layer image 300 is compared in inter-prediction operations.Subject to the selection of the base layer and the indication that it is a source for inter-layer sample prediction and / or inter-layer motion information prediction of the enhancement layer according to some realizations, the memory «LQfrLn / Lznz / e / YiAi. Reference frame 318 can also be connected to interpredictor 406 for use as the reference image against which future enhancement layer images 400 are compared in interprediction operations. Additionally, reference frame memory 418 can be connected to interpredictor 406 for use as the reference image 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 can be provided to the second encoder section 502 subject to the selection of the base layer and the indication that it is the source for predicting the filtering parameters of the enhancement layer according to some realizations. 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 into a transform domain. The transform is, for example, the DCT transform. The quantizer 344, 444 quantizes the transform domain signal, for example, 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 may be considered to comprise a dequantizer 361, 461, which dequantizes the quantized coefficient values, e.g., DCT coefficients, to reconstruct the transform signal, and an inverse transform unit 363, 463, which performs the inverse transform on 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 or blocks according to additional decoded information and filter parameters. The 330, 430 entropy encoder receives the error prediction output of the 303, 403 encoder and can perform entropy coding / LQfrLn / Lznz / e / YiAi encoding of suitable variable length on the signal to provide error detection and correction capability. The outputs of the 330, 430 entropy encoders can be inserted into a bit stream, for example, by a 508 multiplexer. Entropy encoding / decoding can be performed 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 binary arithmetic (CABAC) or context-based variable-length encoding (CAVLC), or any similar entropy encoding. Entropy encoding / decoding can also be performed, alternatively or additionally, using a variable-length encoding scheme, such as Huffman encoding / decoding or Exp-Golomb encoding / decoding. Decoding encoding parameters from an entropy-encoded bitstream or codeword can be referred to as analysis. The H.264 / AVC standard was developed by the Joint Video Team (JVT) of the Video Coding Expert Group (VCEG) of the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T) and the Moving Picture Expert Group (MPEG) of the International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC). The H.264 / AVC standard was published by both major standards organizations and is designated as 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 incorporate new extensions or features into the specification. These extensions include Scalable Video Coding (SVC) and Multi-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 designated as ITU-T Recommendation H.265 and International Standard ISO / IEC 23008-2, also known as MPEG-H Part 2 High Efficiency Video Coding. Efficiency (HEVC). Later versions of H.265 / HEVC include scalable, multiview, range-fidelity, three-dimensional, and screen content encoding extensions that can be abbreviated as SHVC, MV-HEVC, REXT, 3DHEVC, and SCC, respectively. SHVC, MV-HEVC, and 3D-HEVC use a common base specification, defined in Annex F of version 2 of the HEVC standard. This common base comprises, for example, high-level syntax and semantics that specify some of the characteristics of the bitstream layers, such as inter-layer dependencies, as well as decoding processes, such as the construction of a reference image list that includes inter-layer reference images and the derivation of the image order count for multi-layer bitstreams. Annex F may also be used in potentially future multi-layer extensions of HEVC.It should be understood that even though a video encoder, a video decoder, encoding methods, decoding methods, bitstream structures and / or realizations may be described below with reference to specific extensions, such as SHVC and / or MV-HEVC, they are generally applicable to any multi-layer extensions of HEVC, and even more generally to any multi-layer video encoding scheme. Versatile Video Coding (VVC) (MPEG-I Part 3), also known as ITU H.266, is a video compression standard being developed by the Mixed Video Exploration Team (JVET) of the MPEG consortium and the ITU to be a successor to HEVC / H.265. Some key definitions, bitstream and encoding 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 bitstream structure, on which the implementations may be based. The aspects of the various implementations are not limited to H.264 / AVC, HEVC, or VVC or their extensions; rather, the description is provided as a possible basis on which the present implementations may be partially or fully realized. Whenever VVC or any of its draft versions are referenced below, it should be understood that the description conforms to the draft VVC specification, which may change in subsequent draft versions. PLQbLn / Lznz / e / Yi / u later and in the final version or versions of VVC, and that the descriptions and realizations can be adjusted to suit the final version or versions 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 itself may not be specified; instead, it may simply be required that encoders generate compliant bitstreams. Bitstream and decoder compliance can be verified using the Hypothetical Reference Decoder (HRD). Standards may contain encoding tools that help address errors and transmission losses, but the use of these tools in encoding may be optional, and the decoding process for erroneous bitstreams may not have been specified. A syntax element can be defined as a data element represented in the bitstream. A syntax structure can be defined as zero or more syntax elements present together in the bitstream in a specified order. Each syntax element can be described by its name and a descriptor for its encoded representation method. A convention can be used where syntax element names comprise all lowercase letters with underscored characters. The decoding process of a video decoder can 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 realizations, the following descriptors and / or descriptions may be used to specify the parsing process for each syntax element. u(n): an unsigned integer that uses 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 the following n bits from the bitstream interpreted as a binary representation of an unsigned integer with the most significant bit written first. ue(v): exponential Golomb-encoded integer syntax element (also known as exp-Golomb encoded) «LQfrLn / Lznz / e / YiAi with the leftmost bit first. An exponential Golomb bit string can be converted to a code number (codeNum), for example, using the following table: «LQfrLn / Lznz / e / YiAi 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 In some cases, syntax tables may use the values ​​of other variables derived from the values ​​of syntax elements. A variable naming convention may be used that mixes lowercase and uppercase letters and does not include any underscores. Variables beginning with an uppercase letter may be derived for decoding the current syntax structure and all dependent syntax structures. Variables beginning with an uppercase letter may be used in the decoding process for subsequent syntax structures without referencing the variable's source syntax structure. A convention may be used where variables beginning with a lowercase letter can only be used within the context in which they are derived. In some cases, mnemonic names are used interchangeably with numeric values ​​for syntax element values ​​or variable values. Occasionally, mnemonic names are used without any associated numeric value. A flag can be defined as a single-bit variable or syntax element that can take one of two possible values: 0 and 1. Arrays can be syntax elements or variables. Square brackets can be used for array indexing. A one-dimensional array 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 can be used in which function names begin with a capital letter, contain a mixture of lowercase and uppercase letters without any underscores, and end with left and right parentheses that include zero or more variable names (by definition) or values ​​(for 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 can 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 can belong to the current syntax structure, and dependent syntax structures are available in the process specification and invocation. It can also be specified that a procedure specification can have a lowercase variable 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 uppercase or lowercase. 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. In particular, the / operator is used to indicate integer division (with truncation), and the % operator is used to indicate a modulo (i.e., a remainder of a division). Numbering and counting conventions can start from 0, for example, the first is equivalent to position 0, the second is equivalent to position 1, etc. An elementary unit for the input to an encoder and the output of a decoder, respectively, is typically an image. An image given as input to an encoder may also be called a source image, and an image decoded by a decoder may be called a decoded image or a reconstructed image. The source and decoded images each comprise one or more sets of samples, such as the following sets of sample matrices: «LQfrLn / Lznz / e / YiAi Luma (Y) only (monochrome). Luma and two chromas (YCbCr or YCgCo). Green, Blue and Red (GBR, also known as RGB). Arrays representing other monochrome sampling or other unspecified monochrome or triple stimulus color sampling (e.g., YZX, also known as XYZ). These matrices can then be referred to as luma (or L or Y) and chroma, where the two chroma matrices can 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 bitstream encoded using the HEVC Video Usability Information (VUI) syntax or similar. A component can be defined as a matrix or a single sample of one of the three sample matrices (luma and two chromas), or the matrix or a single sample of the matrix that makes up an image in monochrome format. An image can be defined as either 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 alternating rows of samples from a frame and can be used as the encoder input when the source signal is interlaced. The chroma sample arrays may be absent (and therefore monochrome sampling may be used) or the chroma sample arrays may be undersampled compared to the luma sample arrays. Some chroma keying formats can be summarized as follows: In monochrome sampling there is only one sample array, which can be nominally considered the luma array. In 4:2:0 sampling, each of the two chroma matrices has half the height and half the width of the luma matrix. In 4:2:2 sampling, each of the two chroma matrices has the same height and half the width of the luma matrix. In 4:4:4 sampling when separate color planes are not in use, each of the two chroma samples has the same height and width as the luma array. The encoding formats or standards may allow encoding arrays of LQfrLn / Lznz / e / YiAi samples as separate color planes in the bitstream and decoding color planes separately from the bitstream. When separate color planes are in use, each one is processed separately (by the encoder and / or decoder) as a monochrome-sampled image. Partitioning can be defined as dividing a set into subsets such that each element of the set is in exactly one of the subsets. In video coding, an image or a subregion of an image can be subdivided into subsets such that each element of the image or image subregion is in exactly one of the subsets. For example, in subdivision related to HEVC encoding and / or decoding, and / or VVC encoding and / or decoding, the following terms can be used. An encoding block can be defined as an NxN block of samples for some value of N, such that dividing an encoding tree block into encoding blocks is partitioning.A coding tree block (CTB) can be defined as an NxN block of samples for some value of N, such that dividing a component into coding tree blocks is a partitioning. A coding tree unit (CTU) can be defined as a luma sample coding tree block, two corresponding chroma sample coding tree blocks of an image having three sample arrays, or a sample coding tree block of a monochrome image or an image 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 that has three sample arrays, or a sample coding block of a monochrome image or an image that is encoded using three separate color planes and syntax structures used to encode the samples. A CU of the maximum allowed size may be named an 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 (PUs) that define the prediction process for the samples within the CU and one or more transform units (TUs) that define the prediction error coding process for the samples in that 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 can be further divided into smaller PUs and TUs to increase the granularity of the prediction and error coding processes, respectively. Each PU has associated prediction information that defines what kind of prediction is to be applied to the pixels within that PU (e.g., motion vector information for inter-predicted PUs and intra-prediction directionality information for intra-predicted PUs). Each TU can be associated with information describing the prediction error decoding process for the samples within that TU (including, for example, DCT coefficient information). Typically, it is signaled at the CU level whether or not prediction error encoding is applied to each CU. If 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 CUs into PUs and TUs, is typically signaled in the bitstream that allows the decoder to reproduce the intended structure of these units. In a draft version of H.266 / VVC, the following subdivision is applied. Note that what is described here may still evolve in later draft versions of H.266 / VVC until the standard is finalized. Images are subdivided into CTUs similarly to HEVC, although the maximum CTU size has been increased to 128x128. A coding tree unit (CTU) is first subdivided into a quad-tree structure (also known as a quad tree). The leaf nodes of the quad-tree can then be further subdivided into a multi-type tree structure. There are four types of splits in the multi-type tree structure: vertical binary split, horizontal binary split, vertical ternary split, and horizontal ternary split. The leaf nodes of the multi-type tree are called coding units (CUs).The 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 a nested multi-type tree that uses binary and ternary splits; that is, the concepts of separate CU, PU, ​​and TU are not in use except when necessary for CUs that are too large for the maximum transform length. A CU can be square or rectangular. A basic unit for the output of encoders in some encoding formats, such as VVC, and the input of decoders in some encoding formats, such as VVC, is a Network Abstraction Layer (NAL) unit. For networks oriented towards packet transport or structured file storage, NAL units can be encapsulated in packets or similar structures. A bytestream format can be specified for NAL unit streams in transmission or storage environments that do not provide frame alignment structures. The bytestream format separates NAL units from one another by appending a start code to the beginning of each NAL unit. To prevent false detection of NAL unit boundaries, encoders run a byte-oriented start code emulation prevention algorithm, which adds an emulation prevention byte to the NAL unit payload if a start code would otherwise have occurred. To enable simple gateway operation between packet-oriented and stream-oriented systems, start code emulation prevention can be performed regardless of whether the bytestream format is in use. A NAL unit can be defined as a syntax structure containing an indication of the data type to be followed and bytes containing that data in the form of a RBSP interleaved as needed with emulation prevention bytes. A raw byte sequence payload (RBSP) can be defined as a syntax structure containing an integer number of bytes encapsulated within an 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 then by zero or more subsequent bits equal to 0. NAL drives consist of a header and payload. The NAL drive header indicates the type of NAL drive, among other things. NAL units can be categorized into Video Coding Layer (VCL) NAL units and non-VCL NAL units. VCL NAL units are typically cut-code NAL units. A non-VLC NAL unit can be, for example, one of the following types: a sequence parameter set, an image parameter set, a Supplementary Enhancement Information (SEI) NAL unit, an access unit delimiter, an end-of-sequence NAL unit, an end-of-bitstream NAL unit, or a padding data NAL unit. Parameter sets may be required for reconstructing decoded images, while many of the other non-VLC NAL units are not required for reconstructing decoded sample values. Some encoding formats specify parameter sets that can hold parameter values ​​necessary for decoding or reconstructing decoded images. A parameter can be defined as a syntax element within a parameter set. A parameter set can be defined as a syntax structure containing parameters that can be referenced from or activated by another syntax structure, for example, using an identifier. Some types of parameter sets are briefly described below, but it is important to understand that other types of parameter sets may exist and that the implementations described may apply, but are not limited to, the types of parameter sets described. Parameters that remain unchanged throughout an encoded video sequence may be included in a sequence parameter set (SPS). In addition to parameters that may be required by the decoding process, the sequence parameter set may optionally contain video usability information (VUI), which includes parameters that may be important for buffering, image output timing, rendering, and resource allocation. An image parameter set (PPS) contains such parameters that are unlikely to change across multiple encoded images.An image parameter set can include parameters that can be referenced by the photo-coded segments of one or more encoded images. A header parameter set (HPS) has been proposed that contains such parameters, which can change on a per-image basis. A bitstream can be defined as a sequence of bits, which in some encoding formats or standards may be in the form of a stream of NAL units or a stream of bytes, that forms the representation of encoded images and associated data, comprising one or more encoded video sequences. A first bitstream can be followed by a second bitstream on the same logical channel, such as the same file or the same communication protocol connection. An elementary stream (in the context of video encoding) can be defined as a sequence of one or more bitstreams. In some encoding formats or standards, the end of the first bitstream can be indicated by a specific NAL unit, which may be referred to as the end of the bitstream NAL unit (EOB) and is the last NAL unit in the bitstream. 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 non-incomplete syntax structures. In other contexts, a bitstream portion may comprise any contiguous section of a bitstream and may contain one or more incomplete syntax structures. The expression "along the bitstream" (e.g., meaning along the bitstream) or "along an encoded unit of a bitstream" (e.g., meaning along an encoded unit) may be used in the claims and embodiments described to refer to transmission, signaling, or storage such that out-of-band data is associated with, but not included within, the bitstream or encoded unit, respectively. The expression "decoding along the bitstream" or "along an encoded unit of a bitstream," or the like, may refer to the decoding of referred out-of-band data (which may be obtained from out-of-band transmission, signaling, or storage) that is associated with the bitstream or encoded 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 such a way as to associate the metadata with the bitstream, such as frames in the sample entry for a track containing the bitstream, a group of samples for the track containing the bitstream, or a timed metadata track associated with the track containing the bitstream. A coded video sequence (CVS) can be defined as a sequence of images encoded in a decoding order of this type that can be decoded independently and is followed by another sequence of coded video or the end of the bitstream. A coded video sequence can be specified, additionally or alternatively, to end when a specific NAL unit, which can be referred to as an end-of-sequence (EOS) NAL unit, appears in the bitstream. Photos can be divided into independently encoding and decoding photo segments (e.g., slices, pieces, and / or groups of pieces). Such photo segments can enable parallel processing. Slices in this description can refer to photo segments constructed from a certain number of basic encoding units that are processed in the default encoding or decoding order, while pieces can refer to photo segments defined as rectangular regions along a piece grid. A group of pieces can be defined as a group of one or more pieces. Photo segments can be encoded as separate units in the bitstream, such as VCL NAL Units in H.264 / AVC and HEVC and VVC. Encoded photo segments can comprise a header and a payload, where the header contains parameter values ​​necessary to decode the payload.The payload of a cut can be referred to as cut data. In HEVC, an image can be subdivided into pieces, which are rectangular and contain an integer number of LCUs. In HEVC, the subdivision into pieces forms a regular grid, where the heights and widths of the pieces differ from each other by at most one LCU. In HEVC, a slice is defined as an integer number of encoding tree units contained within an independent slice segment and all subsequent dependent slice segments (if any) that precede the next independent slice segment (if any) within the same access unit. In HEVC, a slice segment is defined as an integer number of encoding tree units ordered consecutively in row-by-row scanning and contained within a single NAL unit. Dividing each image into slice segments is a subdivision.In HEVC, an independent cut segment is defined as a cut segment for which the values ​​of the syntax elements of the cut segment header are not inferred from the values ​​for a previous cut segment, and a dependent cut segment is defined as a cut segment for which the values ​​of some syntax elements of the cut segment header are inferred from the values ​​for the preceding independent cut segment in decoding order.In HEVC, a slice header is defined as the slice segment header of the independent slice segment that is a current slice segment, or as the independent slice segment that precedes a current dependent slice segment. A slice segment header is defined as a portion of an encoded slice segment that contains the data elements belonging to the first or all encoding tree units represented in the slice segment. Units are scanned in the row-scan order of the LCUs within parts or within an image if the parts are not in use. Within an LCU, the unit scans have a specific order. Therefore, video coding standards and specifications may allow encoders to divide an encoded image into coded slices or similar units. In-image prediction is typically disabled across slice boundaries. Thus, slices can be retained as a way to divide an encoded image into independently decodable pieces. In H.264 / AVC and HEVC, in-image prediction can be disabled across slice boundaries. Therefore, slices can be considered a way to divide an encoded image into independently decodable pieces, and slices are often considered elementary units for transmission.In many cases, encoders can indicate in the bitstream which types of in-image prediction are disabled across slice boundaries, and the decoder operation takes this information into account, for example, when determining which prediction sources are available. For instance, samples from a neighboring CU might be considered unavailable for in-image prediction if the neighboring CU resides in a different slice. In the latest version of VVC, namely VVC draft 5, the subdivision of images into slices, pieces, and bricks is defined as follows. An image is divided into one or more rows of pieces and one or more columns of pieces. The subdivision of an image into pieces forms a grid of pieces that can be characterized by a list of column widths of pieces (in CTUs) and a list of row heights of pieces (in CTUs). A piece is a sequence of encoding tree units (CTUs) that covers a cell in the piece grid, i.e., a rectangular region of an image. A piece is divided into one or more bricks, each of which consists of a number of rows of CTUs within the piece. A piece that is not subdivided into multiple bricks is also referred to as a brick. However, a brick that is a true subset of a piece is not referred to as a piece. A slice contains a number of pieces of an image or a number of bricks of a piece. A slice is a unit of NAL in VCL. Two slice modes are supported: row-scan slice mode and rectangular slice mode. In row-scan slice mode, a slice contains a sequence of parts in a row-scanned sequence of parts from an image. In rectangular slice mode, a slice contains a number of bricks from an image that collectively form a rectangular region of the image. The bricks within a rectangular slice are arranged in the row-scanned sequence of bricks in the slice. A brick scan can be defined as a specific sequential ordering of the CTUs that subdivide an image, in which the CTUs are ordered consecutively in a row scan of the CTUs within a brick, the bricks within a piece are ordered consecutively in a row scan of the bricks within the piece, and the pieces in an image are ordered consecutively in a row scan of the pieces within the image. It may be required, for example, in an encoding standard, that the coded slice NAL units must be in increasing CTU direction order in brick scan order for the first CTU of each coded slice NAL unit, where the CTU direction can be defined as increasing in a row scan of the CTUs within an image.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, followed similarly by the second, third, etc., rows of the pattern (going down) each scanned from left to right. Figure 5a shows an example of row-based scan-slice subdivision of an image, where the image is divided into 12 pieces and 3 row-based scan-slices. Figure 5b shows an example of rectangular "LQfrLn / Lznz / e / YiAi" slice subdivision of an image (with 18 by 12 CTU), 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, the lower left piece contains 2 bricks, and the lower right piece contains 3 bricks), and 4 rectangular slices. The subdivision into pieces, bricks, and rectangular cuts is specified in the Picture Parameter Set (PPS). Figure 6 shows the syntax for indicating the subdivision into pieces and bricks, which is carried out in two phases: a grid of pieces (i.e., piece column widths and piece row heights) is provided as the first phase, and subsequently the specified pieces are further subdivided into bricks. There are two ways to specify tile spacing: uniform (indicated by the syntax element uniform_tile_spacing_flag, which has a value of 1) and explicit. In uniform tile spacing, tiles have the same width, with the possible exception of the rightmost tile column, and the same height, with the possible exception of the bottom tile row. In explicit tile spacing, the widths and heights of the tile columns and rows (respectively) are specified (in the CTUs), except for the rightmost column and the bottom row (respectively). Similar to how a grid of pieces is indicated, there are two ways to indicate how a piece is divided into bricks; that is, the uniform or explicit brick spacing can be indicated per piece. The labeling is similar to that used 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 syntax element num_slices_in_pic_minus1: 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: "LQfrLn / Lznz / e / YiAi 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 single tile. When an image contains only one tile without additional brick division, it is referred to as a single tile. It is a bitstream compliance requirement that the value of single_tile_in_pic_flag must be the same for all PPSs that are triggered within a CVS." `uniform_tile_spacing_flag` equal to 1 specifies that tile column boundaries and, similarly, tile row boundaries are evenly distributed across the image and are signaled using the syntax elements `tile_cols_width_minus1` and `tile_rows_height_minus1`. `uniform_tile_spacing_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 are signaled using the syntax elements `num_tile_columns_minus1` and `num_tile_rows_minus1` and a list of pairs of syntax elements `tile_column_width_minus1[i]` and `tile_row_height_minus1[i]`. When not present, the value of `uniform_tile_spacing_flag` is inferred to be 1. `tile_cols_width minus plus 1` specifies the width of tile columns, excluding the rightmost tile column in the image, in CTB units when `uniform_tile_spacing_flag` equals 1. The value of `tile_cols_width_minus1` must be in the range of 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 in the image in CTB units when uniform_tile_spacing_flag is equal to 1. The value of tile_rows_height_minus1 must be in the range of 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 is equal to 0. The value of num_tile_columns_minus1 must be in the range of 0 to PicWidthlnCtbsY - 1, inclusive. If single_tile_in_pic_flag is equal to 1, the value of num_tile_columns_minus1 is inferred to be 0. Otherwise, when uniform_tile_spacing_flag is equal to 1, the value of num_tile_columns_minus1 is inferred as specified in CTB row scanning, tile scanning, and brick scanning. `num_tile_rows_minus1 plus 1` specifies the number of tile rows that subdivide the image when `uniform_tile_spacing_flag` equals 0. The value of `num_tile_rows_minus1` must be in the range of 0 to `PicHeightlnCtbsY` - 1, inclusive. If `single_tile_in_pic_flag` equals 1, the value of `num_tile_rows_minus1` is inferred to be 0. Otherwise, when `uniform_tile_spacing_flag` equals 1, the value of `num_tile_rows_minus1` is inferred as specified in CTB row scanning, tile scanning, and brick scanning. The variable `NumTilesInPic` is set equal to (`num_tile_columns_minus1 + 1`) * (`num_tile_rows_minus1 + 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 column of pieces of order i in CTB units. tile_row_height_minus1[ i ] plus 1 specifies the height of the row of pieces of order i in CTB units. brick_splitting present_flag equal to 1 specifies that one or more pieces of images referencing the PPS can be split into two or more bricks. brick_splitting_present_flag equal to 0 specifies that no piece of the images referencing the PPS is split into two or more bricks. `brick_split_flag[i]` equal to 1 specifies that the piece of order i is split into two or more bricks. `brick_split_flag[i]` equal to 0 specifies that the row 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 0. `uniform_brick_spacing_flag[i]` equal to 1 specifies that horizontal brick boundaries are evenly distributed across the i-th row and are signaled using the syntax element `brick_height_minus1[i]`. `uniform_brick_spacing_flag[i]` equal to 0 specifies that horizontal brick boundaries may or may not be evenly distributed across the i-th brick and are signaled using the syntax element `num_brick_rows_minus1[i]` and a list of syntax elements `brick_row_height_minus1[i][j]`. When not present, the value of `uniform_brick_spacing_flag[i]` is inferred to be 1. brick_height_minus1[i] plus 1 specifies the height of the brick rows excluding the bottom brick in the i-th row in CTB units when uniform_brick_spacing_flag[i] is equal to 1. When present, the value of brick_height_minus1 shall be in the range of 0 to RowHeight[i] - 2, inclusive. When not present, the value of brick_height_minus1[i] is inferred to be equal to RowHeight[i] - 1. num_brick_rows_minus1[i] plus 1 specifies the number of bricks that subdivide the i-th row when uniform_brick_spacing_flag[i] equals 0. When present, the value of num_brick_rows_minus1[i] must be in the range of 1 to RowHeight[i] - 1, inclusive. If bnck_split_flag[i] equals 0, the value of num_brick_rows_minus1[i] is inferred to be 0. Otherwise, when uniform_brick_spacing_flag[i] equals 1, the value of num_brick_rows_minus1[i] is inferred as specified in CTB row scanning, piece scanning, and brick scanning. brick_row_height_minus1[ i ][ j ] plus 1 specifies the height of the brick of order j in the row of order i in CTB units when uniform_tile_spacing_flag is equal to 0. The following variables are derived, and, when uniform_tile_spacing_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_spacing_flag[ i ] is equal to 1, the value of num_brick_rows_minus1 [ i ] is inferred, by invoking CTB row scanning, piece scanning, and brick scanning: - the list RowHeight[ j ] for j ranging from 0 to num_tile_rows_minus1 inclusive, specifying the height of the row of pieces of order j in CTB units, - the list CtbAddrRsToBs[ ctbAddrRs ] for ctbAddrRs ranging from 0 to PicSizelnCtbsY - 1 inclusive, specifying the conversion of a CTB address in the row-by-row scanning order of an image to a CTB address in the brick-by-brick scanning, - the list CtbAddrBsToRs[ ctbAddrBs ] for ctbAddrBs ranging from 0 to PicSizelnCtbsY - 1 inclusive, specifying the conversion of a CTB address "LQfrLn / Lznz / e / YiAi" in brick scanning to a CTB address in CTB row scanning of an image, - the Brickld[ ctbAddrBs ] list for ctbAddrBs ranging from 0 to PicSizelnCtbsY - 1 inclusive, specifying the conversion of a CTB address in brick scanning to a brick ID, - the NumCtuslnBrick[ brickldx ] list for brickldx ranging from 0 to numBricksInPic - 1 inclusive, which specifies the conversion of a brick index to the number of CTUs in the brick, - the FirstCtbAddrBs[ brickldx ] list for brickldx ranging from 0 to numBricksInPic - 1 inclusive, specifying the conversion of a brick ID to the CTB address in brick scanning for the first CTB in the brick. `single_brick_per_slice_flag` equal to 1 specifies that each slice referencing 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 1. rect_slice_flag equal to 0 specifies that the bricks within each slice are in row-by-row scan order and slice information is not flagged in the PPS. rect_slice_flag equal to 1 specifies that the bricks within each slice cover a rectangular region of the image and 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_pic_minus1` must be in the range of 0 to `numBricksInPic - 1`, inclusive. When it is not present and `single_brick_per_slice_flag` is equal to 1, the value of `num_slices_in_pic_minus1` is inferred to be equal to `numBricksInPic - 1`. `top_left_brick_idx[i]` specifies the brick index of the brick located in the top-left corner of the cut of order i. 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_brick_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 index of the brick located in the bottom right corner of the slice of order i and top_left_brick_idx[i]. When single_brick_per_slice_flag is equal to 1, the value of bottom_high_brick_idx_delta[i] is inferred to be equal to 0. The length of the syntax element bottom_high_brick_idx_delta[i] is Ceil( Log2( NumBricksInPic top_left_brick_idx[i])) bits. It is a requirement of bitstream conformity that a cut must include either a number of complete pieces or only a consecutive sequence of complete bricks of a piece. The variables NumBrickslnSlice[i] and BricksToSliceMap[j], which specify the number of bricks in the i-th cut and the mapping of bricks to cuts, are derived as follows: NumBrickslnSlice[i] = 0 botRightBkldx = top_left_brick_idx[i] + bottom_right_brick_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 ]++ BhcksToSliceMap[ j ] = i}} Therefore, a rather complex syntax structure is intended to signal the piece and brick subdivision. It is suboptimal in many respects, for example, in terms of the 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 piece and brick boundaries indicated separately), and bit count in the signaling. Improved methods are now being introduced to signal the subdivision of piece and brick. The method for encoding according to a first aspect, shown in Figure 7, comprises encoding (700) a bitstream comprising a piece column indication and a brick height indication for one or more piece columns at a time, or encoding along a bitstream a piece column indication and a brick height indication «LQfrLn / Lznz / e / YiAi» for one or more piece columns at a time; inferring (702), after detecting brick rows aligned across an image, potential piece rows; inferring (704) that or indicating whether a boundary of a potential piece row is a boundary of a piece row;and encoding (706) one or more images in the bitstream using the specified piece columns, specified or inferred piece rows, and specified brick heights, wherein the one or more images are subdivided into a piece grid along the specified piece columns and specified or inferred piece rows, a piece in the piece grid comprising an integer number of encoding tree units and is subdivided into one or more bricks, wherein a brick comprises an integer number of rows of encoding tree units within a piece. The method for decoding according to a first aspect comprises decoding, from or along a bit stream, an indication of piece columns and an indication of brick heights for one or more piece columns at a time; inferring, after detecting brick rows aligned across an image, potential piece rows; inferring or decoding whether a boundary of a potential piece row is a boundary of a piece row;and decoding one or more images from the bitstream using the specified piece columns, specified or inferred piece rows, and specified brick heights, wherein the one or more images are subdivided into a piece grid along the specified piece columns and specified or inferred piece rows, a piece in the piece grid comprising an integer number of encoding tree units and is subdivided into one or more bricks, wherein a brick comprises an integer number of rows of encoding tree units within a piece. Therefore, piece columns and brick heights at the piece-column level are indicated by an encoder and / or decoded by a decoder, excluding piece row heights. Potential piece row boundaries are inferred to be those where brick boundaries are (horizontally) aligned across the image. Thus, for a given potential piece row boundary, it can be inferred that such a potential piece row boundary is a piece row boundary. The inference that a potential piece row boundary is a piece row boundary can be based on conclusions drawn from other information available in the syntax structure, or from the absence of certain information from the syntax structure, for example, the absence of a particular flag "LQfrLn / Lznz / e / YiAi". Alternatively, it can be indicated by an encoder and / or decoded by a decoder whether a potential piece row boundary is a piece row boundary. The indication can be based, for example, on one or more flags present in the syntax structure. Therefore, by indicating only the column heights and brick heights at the column-piece level and inferring the potential row heights, the subdivision can be signaled without signaling the row heights. As a result, coding efficiency is improved and the bit rate required for such signaling is reduced. The following are several example realizations for the first aspect, namely, the syntax and semantics for specifying brick columns and brick heights at the brick-column level and excluding brick row heights. These realizations are equally applicable to the encoding that generates a portion of the bitstream conforming to the syntax and semantics, and to the decoding that decodes a portion of the bitstream in accordance with the syntax and semantics. Example 1 of syntax and semantics: «LQfrLn / Lznz / e / YiAi 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 minusl; i++ ) tile column width minuslfi] ue(v)} for( i = 0; i < NumTileColsInPic; i++ ) { uniform brick spacing flag[ i ] u(1) if( uniform brick spacing flagf i ] ) brick height minus1[¡] ue(v) else { num brick rows minusl [ i ] ue(v) for( j = 0; j < num brick rows minusl [ i ]; j++ ) brick row height minusl [ i 1[ ¡ ] ue(v)}} "LQfrLn / Lznz / e / YiAi uniform_tile_col_spacing_flag equal to 1 specifies that tile column boundaries are evenly distributed across the image and are signaled using the syntax element tile_cols_width_minus1. uniform_tile_spacing_flag equal to 0 specifies that tile column boundaries may or may not be evenly distributed across the image and are signaled using the syntax element num_tile_columns_minus1 and a list of syntax elements tile_column_width_minus1[i]. When not present, the value of uniform_tile_col_spacing_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 the syntax elements with the same name in VVC Draft 5. If form_tile_col_spac¡ng_flag is equal to 1, NumTileColsInPic is set to 15 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. `uniform_brick_spacing_flag[i]` equal to 1 specifies that horizontal brick boundaries are evenly distributed across the column of pieces of order i and are signaled using the syntax element `brick_height_minus1[i]`. `uniformbrickspacingflag[i]` equal to 0 specifies that horizontal brick boundaries may or may not be evenly distributed across the column of pieces of order i and are signaled using the syntax element `num_brick_rows_minus1[i]` and a list of syntax elements `brick_row_height_minus1[i][j]`. When not present, the value of `uniform_brick_spacing_flag[i]` is inferred to be 1. brick_height_minus1[i] plus 1 specifies the height of the brick rows excluding the bottom brick in the column of pieces of order i in CTB units when uniform_brick_spacing_flag[i] equals 1. num_brick_rows_minus1 [ i ] plus 1 specifies the number of bricks that subdivide the column of pieces of order i when uniform_brick_spacing_flag[ i ] is equal to 0. brick_row_height_minus1 [ i ][ j ] plus 1 specifies the height of the brick of order j in the column of pieces of order i in CTB units when uniform_tile_spacing_flag is equal to 0. Example 2 of syntax vs semantics Example 2 is like Example 1 but is additionally indicated by an encoder and / or decoded by a decoder if the subdivision of a column «LQfrLn / Lznz / e / YiAi» of current pieces to bricks is identical to that of the previous piece column. 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 minusl; i-ι—i-) tile column width minusl[i] ue(v)} for( i = 0; i < NumTileColsInPic; i++ ) { if( i > 0 ) copy previous col flagf i ] u(1) if ( i = = 0 | | icopy previous col flagf i ] ) { uniform brick spacing flagf i ] u(1) if( uniform brick spacing flagf i 1) brick height minusl f i ] ue(v) else { num brick rows minuslfi] ue(v) for( j = 0; j < num brick rows minus1[ i ]; j++ ) brick row height minus1[¡][¡] ue(v)}}} «LQfrLn / Lznz / e / YiAi La semántica de los elementos de sintaxis es idéntica a la de, por ejemplo, 1 con la siguiente adición de la semántica para copy_previous_col_flag[ i ]: copy_previous_col_flag[ i ] equal to 1 specifies all of the following: uniform_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_minus1 [ i - 1 ][ j ] for every value of j in the interval from 0 to num_brick_rows_minus1 [ i ] - 1, inclusive. Furthermore, the problem of the suboptimal syntax structure of VVC draft 5 can be alleviated by an approach where the piece column width, piece row heights, or brick heights can be indicated by an encoder and / or decoded by a decoder in a certain predefined scan order, until it is indicated or decoded (respectively) that the remaining piece columns, piece rows, or bricks (respectively) have the same 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 units to be allocated to the partitions; c) indicating (804) whether the number of units to be allocated is allocated equally to that number of partitions; and if not, d) indicating (806) a number of units to be allocated to a subsequent partition, and e) repeating (808) steps c) and d) until all units have been allocated 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 units to be allocated to the partitions; c) decoding whether the number of units to be allocated is allocated equally to that number of partitions; and if not, d) decoding a number of units to be allocated to a subsequent partition, and e) repeating steps c) and d) until all units have been allocated to a partition. According to an embodiment applicable to encoding and / or decoding, the number of units to be assigned to partitions is one of the following: the image width in CTUs (e.g., when partitions are columns of pieces), the image height in CTUs (e.g., when partitions are rows of pieces, or when partitions are rows of bricks indicated for one or more columns of complete pieces at a time), the number of CTU rows in a piece (e.g., when partitions are bricks of the piece). According to an embodiment applicable to encoding and / or decoding, partitions are one or more of the following: columns of pieces, rows of pieces, rows of bricks. According to one embodiment applicable to encoding and / or decoding, the units are rectangular blocks of image samples. For example, a unit in the second aspect shown in Figure 8 could be an encoding tree block. Therefore, by specifying the number of units to be allocated to the partitions in a predefined scan order, significant savings can be achieved in the number of syntax elements required and in the bit rate required for such signaling, especially if the number of units yet to be allocated must be assigned equally to the remaining partitions. Figure 9 shows an example of how the method in Figure 8 can be implemented according to one embodiment. Therefore, first, (900) specifies a number of partitions, such as part columns and / or part rows, to be allocated, and (902) specifies a number of NU units, such as encoding tree block (CTB) units, to be allocated to the partitions. To create a loop to check that all units have been allocated to a partition, (904) checks whether the number of partitions NP to be allocated is greater than one. If not, i.e., NP=1, it is inferred or specified (910) that all remaining units yet to be allocated should be allocated to the remaining partition. However, if NP>1, check (906) whether the number of NU units to be allocated is evenly divisible by the number of NP partitions. If so, check (908) whether the number of NU units should be allocated evenly to the remaining partitions. If so, check (910) that all remaining unallocated NU units should be allocated evenly to the remaining partition(s). If it is found that the number of NU units to be allocated is not evenly divisible by the number of NP partitions (906), or check (908) that the number of NU units should not be allocated evenly to the remaining partitions, check (912) to indicate a number of units to be allocated to the next partition in the predefined scan order.The number of NU units to be allocated is reduced (914) by the specified number of units to be allocated to the next partition, and the number of NP partitions to be allocated is decreased by one (916). The loop is then repeated to check (904) if the number of NP partitions to be allocated is greater than one. The method in Figure 9 can be implemented similarly for decoding according to the embodiment described below. First, a number of partitions, such as piece columns and / or piece rows, to be allocated from oa along a bitstream are decoded, and a number of units NU, such as encoding tree block (CTB) units, to be allocated to the partitions are determined. To create a loop to check that all units have been allocated to a partition, it is checked whether the number of partitions NP to be allocated is greater than one. If not, i.e., NP=1, it is inferred or decoded from oa along the bitstream that all remaining unallocated units should be allocated to the remaining partition. However, if NP>1, it is checked whether the number of NU units to be allocated is evenly divisible by the number of partitions NP. If so, it is decoded from oa along the bitstream to determine if the number of NU units should be allocated evenly 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 partitions NP, or if it is decoded from "LQfrLn / Lznz / e / YiAi oa along the bitstream that the number of NU units should not be allocated evenly to the remaining partitions, a number of units to be allocated to the next partition in the predefined scan order is decoded from oa along the bitstream.The number of NU units to be allocated is reduced by the specified number of units to be allocated to the next partition, and the number of NP partitions to be allocated is decreased by one. The loop is then repeated to check if the number of NP partitions to be allocated is greater than one. The following is an illustrative implementation for the second aspect, namely, the syntax and semantics for unified explicit / uniform brick / piece subdivision signaling. This implementation is equally applicable to encoding, which generates a bitstream portion conforming to the syntax and semantics, and to decoding, which decodes a bitstream portion in accordance with the syntax and semantics. In this example, unified signage is used to specify piece column width and piece row heights, while the signage for "LQfrLn / Lznz / e / YiAi bricks" remains unchanged compared to VVC Draft 5. 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( Irem tile col equal flagf i ]) tile column width minuslfi] 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( Irem tile row equal flagf i 1) tile row height minuslfi] ue(v)} brick splitting present flag u(1) for( i = 0; bñck_splitt¡ng_present_flag && i < NumTilesInPic; i++) { brick split flagf i ] u(1) if( brick split flag[ i ] ) { uniform brick spacing flagf i ] u(1) if( uniform brick spacing flagf i ] ) brick height minuslfi] ue(v) else { num brick rows minus1| i | ue(v) for( ¡ = 0; ¡ < num brick rows minus1[¡ ]; j++) brick row height minusir i 1Γ i I ue(v)}}} "LQfrLn / Lznz / e / YiAi rem_tile_col_equal_flag[ i ] equal to 0 specifies that columns of pieces with index in the range of 0 to i, inclusive, may or may not have equal width in CTB units. rem_tile_col_equal_flag[ i ] equal to 1 specifies that columns of pieces with index in the range of 0 to i, inclusive, have 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 range of 0 to i, inclusive. rem_tile_row_equal_flag[ i ] equal to 0 specifies that tile rows with index in the range from 0 to i, inclusive, may or may not have equal height in CTB units. rem_tile_row_equal_flag[ i ] equal to 1 specifies that tile rows with index in the range from 0 to i, inclusive, have 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 range from 0 to i, inclusive. The semantics of other syntax elements can be specified identically to the semantics of the syntax elements of the same name in VVC Draft 5. The following is an illustrative implementation for an additional aspect, namely, for the syntax and semantics that includes both indicating brick columns and brick heights at the brick-column level, as well as the unified signaling of explicit / uniform brick / piece subdivision. The implementation is equally applicable to the encoding that generates a bitstream portion conforming to the syntax and semantics, and to the decoding that decodes a bitstream portion in accordance with the syntax and semantics. The illustrative realization for encoding can be summarized as follows, while the illustrative realization can be adapted for decoding by substituting the term indicate with the term decode. The parts columns are indicated as follows: The number of tile columns is indicated (num_tile_columns_minus1). The following is indicated in a loop that traverses columns of pieces from right to left until all columns of pieces have been traversed or until it is indicated that the remaining columns of pieces have an equal width: or If the remaining width (in CTB units) is equally divisible by the number of columns of pieces yet to be specified, it is indicated whether the remaining columns of pieces have equal width (rem_tile_col_equal_flag[ i ]). or If the remaining columns of pieces do not have equal width, the column width of pieces is indicated (tile_column_width_minus1 [ 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 that specifies the row heights of parts for row-by-row scan cuts: A flag is displayed if the brick subdivision of the column of pieces is identical to that of the previous column of pieces. The flag is not present for the leftmost column of pieces (copy_previous_col_flag[i]). Note that this flag could be omitted in this illustrative embodiment, or that there are other alternatives, further discussed below, that can be used to achieve similar functionality to that achieved by the flag. When the brick subdivision of the pieces column is not identical to that of the previous pieces column, bricks from the pieces column are indicated as follows: o The number of bricks is indicated in the pieces column (num_bricks_minus1 [ i ]). The following is indicated in a loop that passes through bricks from bottom to top until all the bricks in the column of pieces have been passed through or until it is indicated that the bricks in columns of «LQfrLn / Lznz / e / YiAi» remaining pieces have an equal height: If the remaining height (in CTB units) is divisible by the number of bricks yet to be specified, it is indicated whether the remaining bricks have an equal height (rem_brick_height_equal_flag[ i ][j ])- If the remaining bricks do not have equal height, the brick height is indicated (brick_height_minus1 [ i ][ j ]). «LQfrLn / Lznz / e / YiAi The following syntax can be used in this illustrative implementation: pie parameter set rbsp() { Descriptor if( Isingle tile in_pic flag ) { 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 minus1[¡] + 1, i--){ if( remWidthlnCtbsY % (i + 1 ) = = 0 ) rem tile col equal flag[ i ] u(1) if( Irem tile col equal flagf i ] ) tile column width minusl[i 1 ue(v)} single brick per slice flag u(1) if( Isingle brick per slice flag ) rect slice flag u(1) for( i = 0; i <= num tile columns minusl * rect slice flag; i++ ){ if( i > 0 ) copy previous col flag[ i ] u(1) if( i = = 0 | | Icopy previous col flag[ i ]) { num bricks minusini ue(v) for( j = num_bricks_minus1 [ i ], remHeightlnCtbsY = PicHeightlnCtbsY; j > 0 && !rem_brick_height_equal[ i ][ j ];remHeightlnCtbsY -= brick height minusl[ i ][ j ] + 1, i- - ) { ¡f( remHeightlnCtbsY % (j + 1 ) = = 0 ) rem brick height equal flagf i ][ ¡ ] u(1) if( Irem brick height equal flagf i ][ ¡ ] ) brick height minusl [ i ][ j ] ue(v)}}}; num_tile_columns_minus1 plus 1 specifies the number of tile columns that subdivide the image when uniform_tile_spacing_flag is equal to 0. The value of num_tile_columns_minus1 must be in the range of 0 to 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]` equal to 0 specifies that columns of parts with indexes in the range of 0 to i, inclusive, may or may not have equal width in CTB units. `rem_tile_col_equal_flag[i]` equal to 1 specifies that columns of parts with indexes in the range of 0 to i, inclusive, are assumed to have equal width in CTB units. When not present, the value of `rem_tile_col_equal_flag[i]` is assumed to be 0. tile_column_width_minus1 [ i ] plus 1 specifies the width of the column of pieces of order i in CTB units. `copy_previous_col_flag[i]` equals 0 and specifies that `num_bricks_minus1[i]` is present. `copy_previous_col_flag[i]` equals 1 and 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 interval from 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[i1][j]` for all such values ​​of j in the interval from 1 to `num_bricks_minus1[i]`, inclusive, for which the value of `brick_height_minus1[i1][j]` is present. `copy_previous_col_flag[i]` equal to 0 specifies that `num_bricks_minus1[i]` is present. `copy_previous_col_flag[i]` equal to 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 interval from 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][j] for all such values ​​of j in the range from 1 to num_bricks_minus1[i], inclusive, for which the value of brick_height_minus1[i][j] is present equal to 0 specifies that bricks with index in the range from 0 to j, inclusive, within the column of pieces of order i may or may not have an equal height in CTB units. rem_brick_height_equal_flag[ i ][ j ] equal to 1 specifies that bricks with index in the range 0 aj, inclusive, within the column of pieces of order i 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 column of pieces of order i in CTB units. The semantics of other syntax elements can be specified identically to the semantics of syntax elements with the same names in VVC draft 5. The decoding process can use variables defined as follows or similarly to the following: The colWidth[i] list for i, ranging from 0 to num_tile_columns_minus1 inclusive, which specifies the width of the column of parts of order i in CTB units, is derived as follows: for( i = num_tile_columns_minus1, remWidthlnCtbsY = PicWidthlnCtbsY; i > 0 && !rem_tile_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 = ¡; j >= 0; j- - ) colWidth[ j ] = remWidthlnCtbsY / (i + 1 ) else colWidth[ 0 ] = remWidthlnCtbsY The lists colBrickHeight[ i ][ j ] 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 brick row of order j in CTB units within the tile column of order i, the list RowHeight[ j ] for j ranging from 0 to numTileRows - 1 inclusive, specifying the height of the tile row of order j in CTB units, 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 NumTilesInPic value are derived as follows: for( i = 0, i <= num_tile_columns_minus1; i++ ) { for( j = num_bricks_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 >= O; k— ) colBrickHeight[ i ][ j ] = remHeightlnCtbsY / (j + 1 ) else colBrickHeight[ i ][ 0 ] = remHeightlnCtbsY} for( i = 0, tileRow = 0, currBrickBd = colBhckHeight[ 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 ) brickldxInCol = 0 brickBdlnCol = colBrickHeight[ tileCol ][ 0 ] while( brickBdlnCol < currBrickBd && brickldxInCol <= num_bricks_minus1 [ tileCol ]) { br¡ckldxlnCol++ brickBdlnCol += colBrickHeight[ tileCol ][ brickldxInCol ]} if( brickBdlnCol = = currBrickBd ) tileCol++ else «LQfrLn / Lznz / e / YiAi matchingBdFlag = 0} if( matchingBdFlag ) { tileRowBd[ 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, which specifies the location of the column boundary for pieces of order i in CTB units, is derived as follows: for( tileColBd[ 0 ] = 0, i = 0; i <= num_tile_columns_minus1; i-+ ) tileColBd[ i + 1 ] = tileColBd[ i ] + colWidth[ i ] The variable NumBricksInPic, which specifies the number of bricks in a picture referencing the PPS, and the lists BrickCoIBdf brickldx, BrickRowBd[bhckldx], BrickWidth[brickldx], and BrickHeightf brickldx for brickldx ranging from 0 to numBricksInPic - 1 inclusive, which specify the locations of the vertical brick boundaries in CTB units, the locations of the horizontal brick boundaries in CTB units, the widths of the brick columns in CTB units, and the heights of the brick columns in CTB units are derived, and for each i ranging from 0 to numTilesInPic - 1 inclusive, when uniform_brick_spacing_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++ ) colBhckldx[ 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 ] ] BrickWidth[ brickldx ] = colWidthf tileX ] «LQfrLn / Lznz / e / YiAi BrickHeight[ brickldx ] = colBrickHeight[ colBrickldx[ tileX ] ] colBrickldx[ tileX ]++ brickldx++ while( tileRowBd[ tileY + 1 ] <= colBrickBd[ colBrickldx[ tileX ] ] )} NumBricksInPic = brickldx According to one embodiment, a method for coding comprises the steps of a) determining a number of units to be allocated to partitions; b) indicating or inferring a number of explicitly sized partitions to be allocated; c) indicating sizes for or a number of units in the explicitly sized partitions; and d) indicating or inferring a number of equally sized partitions to be allocated. According to one embodiment, a method for decoding comprises the steps of a) determining a number of units to be allocated to partitions; b) decoding or inferring a number of explicitly sized partitions to be allocated; c) decoding sizes for or a number of units in the explicitly sized partitions; and d) decoding or inferring a number of equally sized partitions to be allocated. According to an embodiment applicable to encoding and / or decoding, the number of units to be assigned to partitions is one of the following: the image width in CTUs (e.g., when partitions are columns of pieces), the image height in CTUs (e.g., when partitions are rows of pieces, or when partitions are rows of bricks indicated for one or more columns of complete pieces at a time), the number of CTU rows in a piece (e.g., when partitions are bricks of the piece). According to an embodiment applicable to encoding and / or decoding, 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, step d comprises determining the number of units yet to be allocated to partitions by reducing the number of units in partitions with explicit size from the number of units to be allocated to partitions, and the method further comprises: assign partitions to explicitly sized partitions according to the «LQfrLn / Lznz / e / YiAi sizes for or the number of units in the explicitly sized partitions and according to a predefined or indicated / decoded scan order; Assign partitions to equally sized partitions by dividing the units yet to be assigned to partitions by the number of equally sized partitions and according to a predefined or indicated / decoded 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 (e.g., SPS), whereas 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 (e.g., PPS). According to one realization, it is inferred (for example, predetermined in a coding standard) that the number of partitions with explicit size is equal to 1. According to an embodiment applicable to encoding and / or decoding, stage d comprises: determine a set or list of partition sizes into which the number of units yet to be allocated can be divided equally; If the number of elements in the set or list is equal to 1, infer the number of equally sized partitions to equal 1; to indicate and / or decode an index (or similar) that corresponds to an element in the set or list, where the index is indicative of the number of equally sized partitions to be assigned. According to an embodiment applicable to encoding and / or decoding, the set or list of partition sizes into which the number of units yet to be allocated can be divided equitably is restricted by excluding partition sizes smaller than a threshold, where the threshold can be predefined, for example, in an encoding standard or specified / decoded. For example, a minimum column width of parts in CTUs can be predefined or specified / decoded. According to one embodiment, the index corresponding to an element in the set 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. Indicate whether a boundary of a parts row is a boundary of the potential parts row In some implementations, a tile row boundary is inferred when horizontal brick boundaries are aligned across the image. This section presents an implementation for signaling tile row boundaries. This implementation can be applied in conjunction with any implementation where brick boundaries are indicated before tile row boundaries in the syntax. The implementation may comprise one or more of the following stages (some of which have already been described above): Potential row piece boundaries are inferred to be those where brick boundaries are (horizontally) aligned across the image. It is inferred by an encoder in oa along the bitstream and / or decoded by a decoder from oa along the bitstream if all aligned brick boundaries form brick row boundaries. For example, a flag can be used in the bitstream syntax. If all aligned brick boundaries do not form piece row boundaries, this is indicated by an encoder in oa along the bitstream and / or decoded by a decoder from oa along the bitstream for each aligned brick boundary if that boundary is a piece row boundary. For example, a flag may be present in the bitstream syntax for each aligned brick boundary (excluding aligned brick boundaries that are image boundaries). «LQfrLn / Lznz / e / YiAi For example, the following syntax can be used: pie parameter set rbsp() { Descriptor if( rect slice flag ) { explicit tile rows flag u(1) if( explicit tile rows flag ) for( i = 1; i < NumAlignedBrickRows; i++ ) tile row skinny i ] u(1)} NumAlignedBrickRows can be derived as NumTileRows in another realization. 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 and specifies that the horizontal boundary of order i of this type where horizontal brick boundaries are aligned across an image is not a tile row boundary. `tile_row_flag[i]` equals 1 and specifies that the horizontal boundary of order i of this type where horizontal brick boundaries are aligned across an image is a tile row boundary. The horizontal boundary of order 0 of this type where horizontal brick boundaries are aligned across an image is the top boundary of the image. Specify columns of pieces so that they are subdivided identically into bricks In some example implementations, the syntax includes an indication that a column of parts is subdivided into bricks identically to the previous column of parts in the loop's entry order (e.g., scanning columns of parts from left to right). It should be understood that the implementations apply similarly without this indication or any similar indication. For example, the scanning order of the columns of parts might be from right to left, and, consequently, it might be indicated that the brick subdivision of a current column of parts is copied from the column of parts on the right. In another example, it is indicated or inferred that all columns of parts with the same width have the same brick subdivision. In yet another example, an index of a column of parts is specified from which the brick subdivision is copied.It is also necessary to understand that the embodiments apply similarly when there is another way to complete the subdivision of a column of bricks based on the above indications. This section presents some related embodiments. In one implementation, the encoder indicates at oa along the bitstream and / or the decoder decodes from oa along the bitstream whether all columns of bricks that have the same width (e.g., in CTB) have the same block subdivision. For example, a syntax element called same_brick_spacing_in_equally_wide_tile_cols_flag can be used. «LQfrLn / Lznz / e / YiAi In one embodiment, the encoder indicates at oa along the bitstream and / or the decoder decodes from oa along the bitstream the number of adjacent tile columns in the looped entry order (e.g., scanning tile columns from left to right) that have the same brick subdivision. For example, a syntax element, which may be named, for example, num_tile_cols_with_same_brick_partitioning_minus1[i], may be encoded by u(v), where v is determined by the remaining tile columns for which no brick subdivision has yet been indicated. In one embodiment, an encoder can indicate in oa along the bitstream and / or a decoder can decode from oa along the bitstream whether the syntax element(s) related to indicating columns of pieces that are identically subdivided into bricks (e.g., copy_previous_col_flag[i]) is present. In one embodiment, the indication is in a sequence-level syntax structure, such as SPS. In another embodiment, the indication is in an image-level syntax structure, such as PPS. In one embodiment, it is predefined, for example, in an encoding standard, that the absence of the syntax element(s) related to indicating columns of pieces that are identically subdivided into 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 an encoding standard, that the absence of a syntax element or elements related to indicating columns of pieces that are identically subdivided into bricks causes 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. In one embodiment, the method for processing the absence of a syntax element or elements related to indicating columns of pieces that are identically subdivided into bricks is indicated by an encoder in oa along the bitstream, for example, in SPS, and / or decoded by a decoder from oa along the bitstream, for example, from SPS.The method can be indicated and / or decoded from a predefined set of processes, which may include, but may not be limited to: a) the brick subdivision that is indicated and / or decoded for all columns of pieces one by one, and i) the brick subdivision that is indicated and / or decoded for one column of pieces and is inferred to be the same for all columns of pieces. «LQfrLn / Lznz / e / YiAi Therefore, the syntax and semantics for signaling the piece and brick subdivision according to the implementations provide significant savings in the number of syntax elements and syntax lines required to perform the signaling. As a result, significant savings are achieved in the number of bits required to indicate the piece and brick subdivision. These benefits are illustrated by the following example, where three different piece and brick subdivisions, shown in Figures 9a, 9b and 9c, are used to compare the performance of piece and brick subdivision according to VVC Draft 5 and piece and brick subdivision according to the realizations. Figures 10a and 10b present the piece and brick subdivisions achieved by the 6K Effective Equirectangular Projection (ERP) and Cube Map Projection (CMP) schemes, respectively, as described in the Omnidirectional Media Format (OMAF, ISO / IEC 23090-2) articles D.6.3 and D.6.4. These schemes have been recommended in the VR Industry Forum Guidelines. The scheme presented in Figure 10c is otherwise equivalent to that in Figure 10b, but uses a different image aspect ratio. The following properties were derived from VVC draft 5 and the implementation that combines both indicating piece columns and brick heights at the piece-column level and unified explicit / uniform piece / brick subdivision signaling: The number of syntax elements to indicate piece and brick subdivision The number of syntax lines to indicate piece and brick subdivision The number of bits required to indicate the piece and brick subdivision 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. «LQfrLn / Lznz / e / YiAi The derived properties with a luma CTB size of 128x128 are presented in the table below. Effective 6K ERP Effective 3x6 CMP Piece Grid Effective 6x3 CMP Piece Grid de6K de 6K No. of syntax elements No. of syntax lines No. of bits No. of saving bits No. of bits No. of bit saving No. of bits No. of bit saving VVC erase 5 13 26 74 54 84 Proposal 7 20 33 55 % 24 56 % 28 67% Consequently, it can be observed 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 savings provided by the implementation for each of the piece and brick subdivisions in Figures 10a–10c is more than 50% compared to VVC Draft 5. It is also observed that, with the proposal, the semantics and derivation processes also become shorter. Indicate uncoded pieces or bricks In some applications, it might be reasonable to assign the content to be encoded and / or decoded to pieces and / or bricks so that only a subset of pieces and / or bricks are used. For example, in continuous streaming dependent on the 360-degree video viewport, only a subset of independently encoded image regions, such as pieces, can be received. In another example, volumetric or point-based cloud video patch encoding is applied, and the patches occupy only a subset of the image pieces and / or bricks. According to one implementation for encoding, unencoded pieces or bricks are indicated in a syntax structure above the slice data along a bitstream. Syntax elements for unencoded pieces or bricks are not encoded in the slice data. The unencoded pieces or bricks are reconstructed (for example, in a decoded reference image) using a predefined or specified method, such as setting the reconstructed sample values ​​to 0 in the sample arrays. According to one implementation for decoding, uncoded pieces or bricks are decoded from a syntax structure above the slice data along a bitstream. Syntax elements for uncoded pieces or bricks are not decoded from the slice data. The uncoded pieces or bricks are decoded (for example, in a decoded reference image) using a predefined or specified method, such as setting the reconstructed sample values ​​to 0 in the sample arrays. According to an applicable embodiment of encoding and / or decoding, the number of uncoded bricks for a column of pieces is indicated and / or decoded, for example, using a variable-length codeword such as ue(v). The bricks in the column of pieces are traversed in a predefined scan order (for example, from bottom to top). For each brick traversed, a flag is indicated and / or decoded to determine whether the brick is uncoded or not. If the brick is uncoded, the number of remaining bricks to be assigned as uncoded is decreased by 1. The process continues until no bricks remain to be assigned as uncoded. Figure 11 shows a block diagram of a video decoder suitable for employing the embodiments of the invention. Figure 11 represents a two-layer decoder structure, but it should be appreciated that the decoding operations can be employed similarly 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 pre-layer. Block 556 illustrates a demultiplexer for delivering information about base layer images to the first decoder section 552 and for delivering information about pre-layer images to the second decoder section 554. Reference P'n establishes a pre-representation of a photo block. Reference D'n establishes a reconstructed prediction error signal. Blocks 704 and 804 illustrate preliminary reconstructed photos (l'n). Reference R'n establishes a final reconstructed photo. Blocks 703 and 803 illustrate the inverse transform (T-1). Blocks 702 and 802 illustrate inverse quantization (Q-1). Blocks 701 and 801 illustrate entropy decoding (E-1). Blocks 705, 805 illustrate a reference frame memory (RFM).Blocks 706 and 806 illustrate prediction (P) (either inter-prediction or intra-prediction). Blocks 707 and 807 illustrate filtering (F). Blocks 708 and 808 can be used to combine error information from the decoded prediction with predicted base layer / predicted layer photos to obtain the preliminary reconstructed photos (l'n). The preliminary reconstructed and filtered base layer photos can be output 709 from the first decoder section 552, and the preliminary reconstructed and filtered base layer photos can be output 809 from the first decoder section 554. In this document, the term "decoder" should be interpreted to cover any operational unit that can perform decoding operations, such as a player, receiver, gateway, demultiplexer, and / or decoder. Figure 12 shows a flowchart of the decoder operation 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 indications of. Therefore, the decoding method comprises decoding (1200) a bitstream portion comprising an indication of piece columns and an indication of brick heights for one or more piece columns at a time; inferring (1202), after detecting brick rows aligned across an image, potential piece rows; inferring (1204) whether or not a potential piece row boundary is a piece row boundary;and decoding (1206) one or more images from the bitstream using the specified piece columns, specified or inferred piece rows, and specified brick heights, wherein the one or more images are subdivided into a piece grid along the specified piece columns and specified or inferred piece rows, a piece in the piece grid comprising an integer number of encoding tree units and is subdivided into one or more bricks, wherein a brick comprises an integer number of rows of encoding tree units within a piece. Figure 13 shows a flowchart of the decoder operation 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 units to be allocated to the partitions; c) determining (1304) whether the number of units to be allocated is allocated equally to said number of partitions; «LQfrLn / Lznz / e / YiAi and if not, d) determine (1306) a number of units to be allocated to a subsequent partition, and e) repeat (1308) steps c) and d) until all units have been allocated to a partition. Indicate the subdivision of an image into rectangular sections The following paragraphs introduce implementations for improved methods for encoding and / or decoding rectangular cuts. These implementations can be applied in conjunction with or independently of the implementations for piece and brick subdivision. The implementations are based on definitions and characteristics of piece, brick, and rectangular cuts as specified in VVC Draft 5. With these implementations, the bit count required to indicate rectangular cuts (e.g., indicating or deriving the location, width, and height of rectangular cuts) is reduced. A coding method according to a first aspect comprises indicating, in or along a bit stream, or inferring a location of an upper left brick of a rectangular cut; concluding 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, indicating, in or along the bit stream, or inferring the number of bricks in the rectangular cut. A decoding method according to a first aspect comprises decoding, from oa along a bit stream, or inferring a location of an upper left brick of a rectangular cut; concluding 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, decoding, from oa along the bit stream, or inferring the number of bricks in the rectangular cut. 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 top left brick of the rectangular cut is not the top left brick of any piece, it is concluded that the rectangular cut comprises one or more bricks of a 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 may comprise single-piece bricks or complete pieces. In an embodiment applicable to encoding, if it is concluded that the rectangular cut may comprise single-piece bricks or complete pieces, it is indicated in oa along the bitstream whether the rectangular cut comprises single-piece bricks or complete pieces. In an embodiment applicable to decoding, if it is concluded that the rectangular cut may comprise single-piece bricks or complete pieces, it is decoded from oa along the bitstream whether the rectangular cut comprises single-piece bricks or complete pieces. In an embodiment applicable to encoding and / or decoding, where it is inferred or indicated (as part of the encoding) or decoded that the rectangular cut comprises one-piece bricks, a variable, for example, named numDeltaValues, is set equal to the number of bricks beyond the location of the top-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 variable numDeltaValues ​​is used when deriving the length of a syntax element for a first syntax element indicating the bottom-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. «LQfrLn / Lznz / e / YiAi In an example implementation, the following syntax is used: pie parameter set rbsp() { Descriptor if(rect slice flag && Isingle brick per slice flag ) { num slices in pie minusl ue(v) for( i = 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 delta[ i ] U(v)}} The semantics of syntax elements can be specified as described above, except that `bottom_right_brick_idx_delta[i]` specifies the difference between the brick index of the brick located in the bottom-right corner of the i-th cut and `top_left_brick_idx[i]`. When `single_brick_per_slice_flag` is equal to 1, the value of `bottom_right_brick_idx_delta[i]` is inferred to be 0. When it is not present, the value of `bottom_right_brick_idx_delta[i]` is inferred to be 0. The variable `numDeltaValues`, which specifies the number of values ​​that `bottom_right_brick_idx_delta[i]` can have, is derived as follows: if( BrickldxlnTile[ brldx ] > 0 ) numDeltaValues ​​= NumBrickslnT¡le[ top_left_brick_idx[ i ] ] - BrickldxInTilef top_left_brick_idx[ i ] ] else numDeltaValues ​​= NumBricksInPic - top_left_brick_idx[ i ] The length of the syntax element `bottom_nght_brick_idx_delta[i]` is Ceil(Log2(numDeltaValues)) bits. The variable `NumBrickslnTile[brickldx]` specifies the number of bricks in the tile containing the brick with index brickldx during an image brick scan. The variable `BrickldxlnTile[brickldx]` specifies the index of the brick within the tile containing the brick when the brick is identified by index brickldx during an image brick scan. In an embodiment applicable to encoding and / or decoding, the location of an upper-left brick within a rectangular cut is inferred. Initially, all brick locations are marked as vacant. A brick-to-rectangular-cut assignment loop is either included in or decoded from the bitstream. For each loop entry, the upper-left brick within a rectangular cut is inferred to be the next vacant brick location in a predefined, indicated, or decoded scan order. For example, the brick scan order within the image can be predefined in an encoding standard.The bottom right brick of a rectangular cut can be inferred, indicated, or decoded, for example, as described above, and the bricks that form the rectangle enclosed by the top left and bottom right bricks are marked as assigned. The same or a 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 cut comprises complete pieces, the syntax element for «LQfrLn / Lznz / e / YiAi» to indicate the lower right brick of the rectangular cut is derived from one or more of the following: A set of possible lower right brick locations is derived. The set can only include those brick locations that are the last brick locations within a piece, are located on or below the row of pieces containing the upper left brick of the rectangular cut, are located on or to the right of the column of rows containing the upper left brick of the rectangular cut, and enclose a rectangular set of vacant piece locations (not yet assigned to any rectangular cut). The entries in the set of possible lower right brick locations are indexed or listed. The length of the syntax element encoded by u(v) to indicate the bottom right brick of the rectangular cut is derived from the number of entries in the set of possible bottom right brick locations. If the number of entries numEnt is equal to 1, the bottom right brick index does not need to be indicated or decoded. Otherwise, the length of the syntax element is equal to Ceil( Log2( numEnt)) bits. The syntax element to indicate the bottom right brick of the rectangular cut is an index to the enumerated set of possible bottom right brick locations. A coding method according to a second aspect comprises indicating, in or along a bit stream, or inferring a location of an upper left brick from a rectangular cut; 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, infer that the width of the rectangular cut is equal to one column of pieces; otherwise, if the top left brick is in the rightmost column of pieces, infer that the width of the rectangular cut is equal to one column of pieces; and otherwise, indicate, in or along the bit stream, the width of the rectangular cut in the columns of pieces; If the rectangular cut comprises one or more one-piece bricks, indicate, in or along the bit stream, or infer the number of bricks in the rectangular cut «LQfrLn / Lznz / e / YiAi»; otherwise, if the top left brick is in the lowest row of pieces, infer that the height of the rectangular cut is equal to one row of pieces, and otherwise indicate, in or along the bit stream, the height of the rectangular cut in rows of pieces. A decoding method according to a second aspect comprises decoding, from or along a bit stream, or inferring a location of an upper left brick from a rectangular cut; 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, infer that the width of the rectangular cut is equal to one column of pieces; otherwise, if the top left brick is in the rightmost column of pieces, infer that the width of the rectangular cut is equal to one column of pieces, and, if necessary, decode, from this along the bit stream, the width of the rectangular cut in the columns of pieces; If the rectangular cut comprises one or more one-piece bricks, decode, from oa along the bitstream, or infer the number of bricks in the rectangular cut; otherwise, if the top left brick is in the lowest row of pieces, infer that the height of the rectangular cut is equal to one row of pieces, and, otherwise, decode, from oa along the bitstream, the height of the rectangular cut in rows of pieces. In an embodiment applicable to encoding and / or decoding and applicable to the first aspect and / or the second aspect, the number of bricks in a rectangular cut is inferred to be equal to 1 (in bricks), when it has been concluded 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 of the piece, or the current brick is the bottom brick of a piece. «LQfrLn / Lznz / e / YiAi In an example implementation, the following syntax is used: Descriptor if( !single_brick_per_slice_flag ) { num_slices_in_pic_minus1 ue(v) for( i = 0; i < num_sl¡ces_in_p¡c_m¡nus1; i++ ) { if( BrickldxlnTile[ tlBrickldx ] 0 && numFreeColumnsOnTheRight[ tlBrickldx ] > 1 ) slice_width_minus1[ i ] u(v) if( slice_width_minus1 [ i ] = = 0 && BrickldxlnTile[ tlBrickldx ] = = 0 && NumBrickslnT¡le[ tlBrickldx ] > 1 ) full_tiles_in_slice_flag[ i ] u(1) if( numFreeRowsBelow[ tlBrickldx ] > 1 ) { slice_height_minus1[ i ] u(v)}}} «LQfrLn / Lznz / e / YiAi The variables and semantics of syntax elements can be specified as described above with the following additions: tlBrickldx can be specified as the next vacant brick location in a predefined scan order, such as brick scanning in an image, as described above. tlBrickldx is re-derived for each value of i, that is, for each loop entry. `numFreeColumnsOnTheRight[ brickldx ]` is a variable that indicates 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 cut of order i in the brick columns. When not present, `slice_width_minus1[ i ]` is inferred to be equal to 0. `full_tiles_in_slice_flag[i]` equal to 0 specifies that the rectangular slice of order i contains one or more single-piece bricks. `full_tiles_in_slice_flag[i]` equal to 1 specifies that the rectangular slice of order i contains one or more whole pieces. `full_tiles_in_slice_flag[i]` is inferred to be equal to 0 when `BrickldxlnTile[tlBrickldx]` is greater than 0 (i.e., when the top-left brick of the rectangular slice is not a top-left brick of any piece). `full_tiles_in_slice_flag[i]` is inferred to be equal to 1 when `slice_width_minus1[i]` is greater than 0 or when `BrickldxlnTile[tlBrickldx]` is equal to 0 and `NumBrickslnTile[tlBrickldx]` is equal to 1. If full_tiles_in_slice_flag[i] is equal to 0, numFreeRowsBelow[brickldx] is a variable that indicates the number of bricks in a tile below the brick with index brickldx in the same tile. Otherwise, numFreeRowsBelow[brickldx] is a variable that indicates the number of tile rows below the tile containing the brick with index brickldx. If full_tiles_in_slice_flag[i] is equal to 0, slice_height_minus1[i] plus 1 specifies the height of the rectangular cut of order i in bricks. Otherwise, slice_height_minus1[i] plus 1 specifies the height of the rectangular cut of order i in rows of pieces. When not present, slice_height_minus1[i] is inferred to be equal to 0. In an implementation applicable to encoding and / or decoding, the length of the slice width syntax element (e.g., slice_width_minus1) is derived from the number of possible values ​​based on the location of the top-left brick in the rectangular slice. Using the variables and syntax elements above, the length of slice_width_minus1 is equal to Ceil( Log2( numFreeColumnsOnTheRightf tlBrickldx ] + 1 )). In an embodiment applicable to encoding and / or decoding, the length of the slice height syntax element (e.g., 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 slice comprises single-piece bricks or full-length bricks. Using the variables and syntax elements above, the length of slice_height_minus1 is equal to Ceil( Log2( numDeltaValues ​​)), where numDeltaValues ​​is derived as follows: if( full_tiles_¡n_sl¡ce_flag[ i ] = = 0) numDeltaValues ​​= NumBricksInTilef tlBrickldx ] - BrickldxInTilef tlBrickldx ] else numDeltaValues ​​= numFreeRowsBelowf tlBrickldx ] + 1 Indicate uncoded rectangular cuts In some applications, it might be reasonable to assign the content to be encoded and / or decoded to rectangular slices so that only a subset of those rectangular slices are used. For example, in continuous streaming dependent on the 360-degree video view port, only a subset of rectangular slices can be received. In another example, volumetric or point-based cloud video patch encoding is applied, and the patches occupy only a subset of the rectangular image slices. According to one implementation for encoding, unencoded rectangular slices "LQfrLn / Lznz / e / YiAi" are indicated along a bitstream, for example, in PPS. The unencoded rectangular slices are not encoded as VCL NAL units in the bitstream. The unencoded rectangular slices are reconstructed (for example, in a decoded reference image) using a predefined or specified method, such as setting the reconstructed sample values ​​to 0 in the sample arrays. According to one implementation for encoding, unencoded rectangular slices are decoded from a bitstream, for example, from PPS. Unencoded rectangular slices are not decoded from VCL NAL units from the bitstream. Instead, unencoded rectangular slices (for example, in a decoded reference image) are decoded using a predefined or specified method, such as setting the decoded sample values ​​to 0 in the sample arrays. According to an embodiment applicable to encoding and / or decoding, a flag is indicated and / or decoding is performed for each rectangular cut, the flag indicating whether the rectangular cut is encoded or not. According to one embodiment, the number of uncoded rectangular slices is indicated and / or decoded using a variable-length codeword, such as ue(v). The rectangular slices are traversed in a predefined scan order (in a reverse row scan order of the upper-left CTU of the rectangular slices). For each traversed rectangular slice, a flag is indicated and / or decoded to determine whether the rectangular slice is uncoded. If the rectangular slice is uncoded, the number of remaining rectangular slices to be assigned as uncoded decreases by 1. The process continues until no rectangular slices remain to be assigned as uncoded. Figure 14 is a graphical representation of an example multimedia communication system in which various implementations can be carried out. A data source (1510) provides a source signal in an analog, uncompressed digital, or compressed digital format, or any combination thereof. An encoder (1520) may include or be connected to preprocessing, such as data format conversion and / or filtering of the source signal. The encoder (1520) encodes the source signal into a stream of encoded media bits. It should be noted that a bitstream to be decoded can be received directly or indirectly from a remote device located on virtually any type of network. Additionally, the bitstream can be received from local hardware or software.The 1520 encoder can encode more than one type of media, such as audio and video, or more than one 1520 encoder may be required to encode different media types from the source signal. The 1520 encoder can also receive synthetically produced input, such as graphics and text, or it can produce encoded bitstreams of synthetic media. For simplicity, only the processing of one bitstream of encoded media of one type is considered here. It should be noted, however, that real-time broadcast services typically comprise several streams (typically at least one audio stream, one video stream, and one text subtitle stream). It should also be noted that the system may include many encoders, but only one 1520 encoder is shown in the figure for simplicity without sacrificing generality.It should be further understood that, although the text and examples contained in this document may specifically describe a coding process, a subject matter expert would understand that the same concepts and principles also apply to the corresponding decoding process and vice versa. The encoded media bitstream can be transferred to 1530 storage. The 1530 storage can comprise any type of mass storage for storing the encoded media bitstream. The format of the encoded media bitstream in the 1530 storage can be an elementary standalone bitstream format, or one or more encoded media bitstreams can be encapsulated in a container file, or the encoded media bitstream can be encapsulated in a segment format suitable for DASH (or a similar continuous-stream delivery 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 file format metadata, which can also be stored in the file.Encoder 1520 or storage 1530 may comprise the file generator, or the file generator may be operatively connected to either encoder 1520 or storage 1530. Some systems operate live, that is, they bypass storage and transfer encoded media bitstreams from encoder 1520 directly to sender 1540. The encoded media bitstream may then be transferred to sender 1540, also referred to as the server, as required. The format used in transmission may be an elementary standalone bitstream format, a packet stream format, a segment format suitable for DASH (or a similar streaming delivery system), or one or more encoded media bitstreams may be encapsulated in a container file.The 1520 encoder, 1530 storage, and 1540 server can reside on the same physical device or be housed on separate devices. The 1520 encoder and 1540 server can operate with live, real-time content, in which case the encoded media bitstream is typically not permanently stored but instead buffered for short periods in the 1520 content encoder and / or the 1540 server to smooth out variations in processing delay, transfer delay, and encoded media bitrate. The 1540 server sends the encoded media bitstream using a communication protocol stack. The stack can include, but is not limited to, one or more of the 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 1540 server encapsulates the encoded media bitstream into packets. For example, when using RTP, the 1540 server encapsulates the RTP-encoded media bitstream according to an RTP payload format. Typically, each media type has a specialized RTP payload format. It should be noted again that a system can contain more than one 1540 server, but for simplicity, the following description considers only one 1540 server. If the media content is encapsulated in a container file for storage (1530) or for introducing data to the sender (1540), the sender (1540) may comprise or be operationally connected to a forward file parser (not shown in the figure). In particular, if the container file is not transmitted as such, but at least some of the contained encoded media bitstream is encapsulated for transport over a communication protocol, a forward file parser locates appropriate portions of the encoded media bitstream for transmission over the communication protocol. The forward file parser may also assist in creating the correct format for the communication protocol, such as packet headers and payloads.The multimedia container file may contain encapsulation instructions, such as hint tracks in ISOBMFF, for encapsulating at least one of the media bit streams contained in the communication protocol. Server 1540 may or may not be connected to a gateway 1550 via a communication network, which could be, for example, a combination of a CDN, the Internet, and / or one or more access networks. The gateway may also be referred to as an intermediate PBX. For DASH, the gateway can be an edge server (of a CDN) or a web broker. Note that the system can generally comprise any number of gateways or similar devices, but for simplicity, the following description considers only a gateway 1550.The 1550 gateway can perform various functions, such as translating a packet flow from one communication protocol stack to another, joining and branching data flows, and manipulating data flows according to downlink and / or receiver capabilities, such as controlling the bit rate of the forwarded flow based on the prevailing downlink network conditions. The 1550 gateway can function as a server in various implementations. The system includes one or more 1560 receivers, which can typically receive, demodulate, and decapsulate the transmitted signal in a coded media bitstream. The coded media bitstream can be transferred to a 1570 recording storage device. The 1570 recording storage device can comprise any type of mass storage for storing the coded media bitstream. Alternatively or additionally, the 1570 recording storage device can comprise computer memory, such as random access memory. The format of the coded media bitstream in the 1570 recording storage device can be an elementary standalone bitstream format, or one or more coded media bitstreams can 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 the receiver 1560 comprises or is connected to a container file generator that produces a container file from the input streams. Some systems operate live, that is, 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 portion of the recorded stream, for example, the most recent 10-minute extract of the recorded stream, is kept in the recording storage 1570, while any earlier recorded data is discarded from the recording storage 1570. The encoded media bitstream can be transferred from the recording storage 1570 to the decoder 1580. If there are many encoded media bitstreams, such as an audio stream and a video stream, associated with each other and encapsulated in a container file, or if a single media bitstream is encapsulated in a container file, for example, for easier access, a file analyzer (not shown in the figure) is used to decapsulate each encoded media bitstream from the container file. The recording storage 1570 or a decoder 1580 may comprise the file analyzer, or the file analyzer may be connected to either the recording storage 1570 or the decoder 1580. It should also be noted that the system may include many decoders, but only one decoder 1570 is discussed here to simplify the description while maintaining generality. The encoded media bitstream can be further processed by a 1570 decoder, the output of which is one or more uncompressed media. Finally, a 1590 renderer can reproduce the uncompressed media streams to a speaker or display, for example. The 1560 receiver, the 1570 recording storage, the 1570 decoder, and the 1590 renderer can reside on the same physical device or can be contained in separate devices. The above describes some implementations with reference to and / or using VVC / H.266 terminology. It is important to understand that these implementations can be carried out similarly with any video encoder and / or video decoder. The preceding text describes some example realizations with "LQfrLn / Lznz / e / YiAi" referencing specific syntax structures and / or syntax elements. It is important to understand that these realizations can be similarly implemented with other syntax structures and / or syntax elements. For example, when realizations are described referencing syntax elements in PPS syntax, it is important to understand that similar or identical realizations can be implemented with the same syntax elements in other syntax structures, such as SPS. In the preceding paragraphs, some realizations with reference to the term "indicate" have been described. It is necessary to understand that the term "indicate" can be understood as encoding or generating one or more syntax elements in one or more syntax structures along a bitstream. In the preceding sections, several realizations related to the term "decode" have been described. It is important to understand that the term "decode" can be understood as decoding or analyzing one or more syntax elements of one or more syntax structures from or along a bitstream. In the preceding text, when example implementations have been described with reference to an encoder, it is necessary to understand that the resulting bitstream and the decoder may contain corresponding elements. Similarly, when example implementations have been described with reference to a decoder, it is necessary to understand that the encoder may have a structure and / or software program to generate the bitstream to be decoded by the decoder. For example, some implementations have been described related to generating a prediction block as part of the encoding. Implementations generating a prediction block as part of the decoding can be carried out similarly, with the difference that the encoding parameters, such as horizontal and vertical shifts, are decoded from the bitstream determined by the encoder. The embodiments of the invention described above describe the codec in terms of a separate encoder and decoder apparatus to aid in understanding the processes involved. However, it should be appreciated that the apparatus, structures, and operations can be implemented as a single encoder-decoder apparatus / structure / operation. Additionally, it is possible for the encoder and decoder to share some or all of the common elements. «LQfrLn / Lznz / e / YiAi Although the preceding examples describe embodiments of the invention operating within 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. Therefore, for example, the embodiments of the invention can be implemented in a video codec capable of encoding video over fixed or wired communication paths. Therefore, the user equipment may comprise a video codec such as those described in prior 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 include video codecs as described above. In general, the various embodiments of the invention can be implemented in special-purpose hardware or 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 can be executed by a controller, microprocessor, or other computing device, although the invention is not limited to this. Although various aspects of the invention may be illustrated and described as block diagrams, flowcharts, or using some other graphical representation, it is well understood that these blocks, devices, systems, techniques, or methods described herein may be implemented in, by way of non-limiting examples, special-purpose hardware, software, firmware, circuitry or logic, general-purpose hardware or controller, or other computing devices, or some combination thereof. The embodiments of this invention can be implemented by computer software executable by a data processor of the mobile device, such as in the processor unit, or by hardware, or by a combination of software and hardware. Furthermore, it should be noted that any blocks of the logic flow, as in the figures, can represent program stages, or interconnected circuits, logic blocks and functions, or a combination of program stages and circuits, logic blocks and functions. The software can be stored on physical media such as memory chips, or memory blocks implemented in the processor, magnetic media such as hard disks or floppy disks, and optical media such as, for example, DVDs and data variants thereof, CDs. Memory can be of any type suitable to the local technical environment and can be implemented using any appropriate 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 can be of any type suitable to the local technical environment and may include one or more general-purpose computers, special-purpose computers, microprocessors, digital signal processors (DSPs), and processors based on multi-core processor architectures, as non-limiting examples. The implementations of the inventions can be put into practice 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 for etching and forming on a semiconductor substrate. Programs, such as those provided by Synopsys, Inc. of Mountain View, California, and Cadenee Design of San Jose, California, automatically route conductors and place components on a semiconductor chip using well-established design rules and libraries of pre-stored design modules. Once the design for a semiconductor circuit is complete, the resulting design, in a standardized electronic format (e.g., Opus, GDSII, or similar), can be transmitted to a semiconductor manufacturing facility, or fab, for fabrication. The foregoing description has provided, by means 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 when the foregoing description is read in conjunction with the accompanying drawings and appended claims. Nevertheless, all such modifications and similar teachings of this invention will still fall within the scope of this invention.

Claims

1. A method for coding comprising determining a number of units to be allocated to partitions; indicating or inferring a number of explicitly sized partitions to be allocated; indicating sizes for or a number of units in the explicitly sized partitions; and indicating or inferring a number of equally sized partitions to be allocated.

2. An apparatus comprising means for determining a number of units to be allocated to partitions; means for indicating or inferring a number of explicitly sized partitions to be allocated; means for indicating sizes for or a number of units in explicitly sized partitions; and means for indicating or inferring a number of equally sized partitions to be allocated.

3. The apparatus according to claim 2, wherein the number of units to be assigned to the partitions is one of the following: the image width in encoding tree units (CTUs), the image height in CTUs, the number of CTU rows in a piece.

4. The apparatus according to any of claims 2-3, wherein said means for indicating or inferring a number of equally sized partitions to be allocated further comprises means for determining the number of units yet to be allocated to the partitions by reducing the number of units in explicitly sized partitions from the number of units to be allocated to the partitions; means for allocating partitions to explicitly sized partitions according to the sizes for or the number of units in explicitly sized partitions and according to a predefined or indicated scan order; and means for allocating partitions to equally sized partitions by dividing the units yet to be allocated to the partitions by the number of equally sized partitions and according to a predefined or indicated scan order.

5. The apparatus according to any of claims 2-4, further comprising means for indicating the number of explicitly sized partitions in a higher-level syntax structure; and means for indicating sizes for the explicitly sized partitions and / or an equal number of equally sized partitions in a lower-level syntax structure.

6. A method for decoding comprising determining a number of units to be allocated to partitions; decoding or inferring a number of explicitly sized partitions to be allocated; decoding sizes for or a number of units in the explicitly sized partitions; and decoding or inferring a number of equally sized partitions to be allocated.

7. An apparatus comprising means for determining a number of units to be allocated to partitions; means for decoding or inferring a number of explicitly sized partitions to be allocated; means for decoding sizes for, or a number of units in, explicitly sized partitions; and means for decoding or inferring a number of equally sized partitions to be allocated. «LQfrLn / Lznz / e / YiAi 8. The apparatus according to claim 7, wherein the number of units to be allocated to the partitions is one of the following: the image width in encoding tree units (CTUs), the image height in CTUs, the number of CTU rows in a piece.

9. The apparatus 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.

10. The apparatus according to any of claims 7-9, wherein said means for decoding or inferring a number of equally sized partitions to be allocated further comprises means for determining the number of units yet to be allocated to the partitions by reducing the number of units in the explicitly sized partitions from the number of units to be allocated to the partitions; means for allocating partitions to the explicitly sized partitions according to the sizes for or the number of units in the explicitly sized partitions and according to a predefined or decoded scan order; and means for allocating partitions to the equally sized partitions by dividing the units yet to be allocated to the partitions by the number of equally sized partitions and according to a predefined or decoded scan order.

11. The apparatus according to any of claims 7-10, further comprising means for decoding the number of explicitly sized partitions from a higher-level syntax structure; and means for decoding sizes for the explicitly sized partitions and / or an equal number of equally sized partitions from a lower-level syntax structure.

12. The apparatus according to any of claims 7-11, further comprising means for inferring that the number of partitions with explicit size is «LQfrLn / Lznz / e / YiAi equal to 1.

13. The apparatus according to claim 12, wherein said means for decoding or inferring a number of equally sized partitions to be allocated further comprises means for determining a set or list of partition sizes into which the number of units yet to be allocated can be equally divided; means for inferring, when the number of elements in the set or list is equal to 1, the number of equally sized partitions to be equal to 1; and means for indicating an index corresponding to an element in the set or list, wherein the index is indicative of the number of equally sized partitions to be allocated.

14. The apparatus according to claim 13, further comprising means for restricting the set or list of partition sizes into which the number of units yet to be allocated can be divided equally, excluding partition sizes smaller than a threshold, wherein the threshold is predefined or decoded.

15. The apparatus according to claim 13 or 14, further comprising means for decoding the index corresponding to an element in the set or list with a fixed-length codeword, wherein the length of the codeword is determined by the number of elements in the set or list.

Images