Apparatus, method, and computer program for video coding and decoding

Abstract

10. The method of claim 1, further comprising: determining a number of units to be allocated to partitions and initialized as unallocated; displaying or inferring a number of specifically sized partitions to be allocated; displaying the sizes of the specifically sized partitions and accordingly marking the unallocated units to be allocated to partitions in a predefined scan order; displaying the number of units; iteratively assigning the number of units to partitions and accordingly marking the unallocated units to be allocated in a predefined scan order until the number of unallocated units is less than the number of units; and if the number of unallocated units is greater than 0, allocating the unallocated units to a last partition.

Description

Technical Field

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

Background Art

[0002] According to video coding standards and specifications, generally, an encoder can divide or partition a coded picture into subsets. In video coding, partitioning can be defined as dividing a picture or a sub-region of a picture into subsets (blocks) such that each element of the picture or the sub-region of the picture is present in exactly one of the subsets (blocks). For example, H.265 / HEVC introduced the concept of a coding tree unit (CTU) having a size of 64×64 pixels by default. A CTU may contain a single coding unit (CU) or may be recursively split into a number of smaller CUs of at least 8×8 pixels based on a quad-tree structure. H.265 / HEVC further approves a tile that is rectangular and contains integer CTUs, and a slice defined based on a slice segment that contains integer coding tree units that are continuously ordered in a tile scan and are included in a single NAL unit.

[0003] Versatile Video Coding (VVC) (MPEG-I Part 3), also known as ITU-T H.266, is a video compression standard developed by the Joint Video Experts Team (JVET) of the Moving Picture Experts Group (MPEG) (formally ISO / IEC JTC1 SC29 WG11) and the Video Coding Experts Group (VCEG) of the International Telecommunication Union (ITU), and is a successor to HEVC / H.265. The VVC partitioning scheme includes not only tiles but also bricks that can include one or more CTU rows within a tile. The introduction of bricks also affects the definition of slices.

[0004] As a result, a rather complex syntactic structure has been created to signal various options for tile and brick partitioning, which, however, is not optimal in many respects, particularly with regard to the bitrate required for said signaling. SUMMARY OF THE INVENTION

[0005] Here, in order to at least mitigate the above problems, an enhanced encoding method is introduced herein.

[0006] The scope of protection required for various embodiments of the present invention is defined by the independent claims. Embodiments and features described herein that do not fall within the scope of the independent claims should, if any, be construed as useful examples for understanding the various embodiments of the present invention.

[0007] A method according to a first aspect is to determine the number of units to be assigned to partitions and initialized as unassigned, display or infer the number of clearly sized partitions to be assigned, display the size of the clearly sized partitions, and accordingly mark the unassigned units to be assigned to the partitions in a predefined scan order, display the number of units, repeatedly assign the number of units to the partitions, and accordingly mark the unassigned units to be assigned in a predefined scan order until the number of unassigned units is less than the number of units, and if the number of unassigned units is greater than zero, assign the unassigned units to the last partition.

[0008] According to one embodiment, the partitions are one or more of the following: a tile column, a tile row, a brick row of one or more tile columns, a brick row of tiles, a grid column of a grid used to display sub-picture partitioning, and a grid row of a grid used to display sub-picture partitioning.

[0009] According to one embodiment, the units are one or more of the following: a rectangular block of samples of a picture, and a grid cell of a grid used to display sub-picture partitioning.

[0010] The apparatus according to the second aspect includes means for determining the number of units to be assigned to partitions and initialized as unassigned, means for displaying or inferring the number of clearly sized partitions to be assigned, means for displaying the size of the clearly sized partitions, and accordingly means for marking the unassigned units to be assigned to the partitions in a predefined scan order, means for displaying the number of units, means for repeatedly assigning the number of units to the partitions, and accordingly means for marking the unassigned units to be assigned in a predefined scan order until the number of unassigned units is less than the number of units, and means for assigning the unassigned units to the last partition if the number of unassigned units is greater than zero.

[0011] The method according to the third aspect includes determining the number of units to be assigned to partitions, determining the number of clearly sized partitions to be assigned, determining the sizes of the clearly sized partitions, and accordingly marking the unassigned units to be assigned to the partitions in a predefined scan order, determining the number of units, repeatedly assigning the number of units to the partitions, and accordingly marking the unassigned units to be assigned in a predefined scan order until the number of unassigned units is less than the number of units, and, if the number of unassigned units is greater than zero, assigning the unassigned units to the last partition.

[0012] According to one embodiment, determining the number of clearly sized partitions to be assigned includes decoding the number of clearly sized partitions to be assigned from a syntax structure, determining the sizes of the clearly sized partitions includes decoding the sizes of the clearly sized partitions from a syntax structure, and determining the number of units includes decoding the number of units from a syntax structure.

[0013] The apparatus according to the fourth aspect includes means for determining the number of units to be assigned to partitions, means for determining the number of clearly sized partitions to be assigned, means for determining the size of the clearly sized partitions, and, accordingly, means for marking unassigned units to be assigned to partitions in a predefined scan order, means for determining the number of units, means for repeatedly assigning the number of units to partitions, and, accordingly, means for marking unassigned units to be assigned in a predefined scan order until the number of unassigned units is less than the number of units, and means for assigning unassigned units to the last partition if the number of unassigned units is greater than zero.

[0014] A further aspect relates to an apparatus including at least one processor and at least one memory, wherein code is stored in the at least one memory, and when executed by the at least one processor, causes the apparatus to perform at least one of the above-described methods and one or more of the related embodiments.

[0015] For a better understanding of the present invention, reference will now be made, by way of example, to the accompanying drawings.

Brief Description of the Drawings

[0016]

Figure 1

Figure 2

Figure 3

Figure 4

Figures 5a-c

Figure 6

Figure 7

Figure 8

Figure 9

Figures 10a-c

Figure 11

Figure 12

Figure 13

Figure 14a

Figure 14b

Figure 15

DETAILED DESCRIPTION OF THE INVENTION

[0017] The following further details an appropriate apparatus and possible mechanisms for starting a viewpoint switch. In this regard, FIGS. 1 and 2 are first referred to, where FIG. 1 shows a block diagram of a video coding system according to an exemplary embodiment as a schematic block diagram of an exemplary apparatus or electronic device 50 that can incorporate a codec according to an embodiment of the present invention. FIG. 2 shows a layout of the apparatus according to an exemplary embodiment. The elements of FIGS. 1 and 2 are then described.

[0018] The electronic device 50 can be, for example, a mobile terminal or user equipment of a wireless communication system. However, it will be understood that embodiments of the present invention can be implemented within an electronic device or apparatus that may require encoding and decoding, or encoding or decoding, of video images.

[0019] The apparatus 50 can include a housing 30 for the incorporation and protection of the device. The apparatus 50 can further include a display 32 in the form of a liquid crystal display. In other embodiments of the present invention, the display can be any suitable display technology suitable for displaying images or video. The apparatus 50 can further include a keypad 34. In other embodiments of the present invention, any suitable data or user interface mechanism can be utilized. For example, the user interface can be implemented as a virtual keyboard or data entry system as part of a touch-sensitive display.

[0020] The device can include a microphone 36, or any suitable audio input section that can be a digital or analog signal input section. In an embodiment of the present invention, the device 50 can further include an audio output device that can be any one of earphones 38, a speaker, or an analog audio or digital audio output connection section. The device 50 can further include a battery (or in other embodiments of the present invention, the device may be powered by any suitable portable energy device such as a solar cell, a fuel cell, or a clockwork generator). The device can further include a camera that can record or capture images and / or videos. The device 50 can further include an infrared port for short-range line-of-sight communication with other devices. In other embodiments, the device 50 can further include any suitable short-range communication solution, for example, a Bluetooth (registered trademark) wireless connection, a USB / firewire wired connection, and the like.

[0021] The device 50 can include a controller 56, a processor, or a processor circuit for controlling the device 50. In an embodiment of the present invention, the controller 56 can be connected to a memory 58 that can store data in both the form of image and audio data, and / or can further store instructions for execution by the controller 56. The controller 56 can further be connected to a codec circuit 54 that executes the coding and decoding of audio and / or video data, or is suitable for assisting the coding and decoding executed by the controller.

[0022] The device 50 can further include a card reader 48 and a smart card 46, for example, a UICC and a UICC reader suitable for providing user information and providing authentication information for user authentication and authorization on a network.

[0023] Device 50 is connected to a controller and can include, for example, a wireless interface circuit 52 suitable for generating a wireless communication signal for communication with a cellular communication network, a wireless communication system, or a wireless local area network. Device 50 can further include an antenna 44 connected to the wireless interface circuit 52 for transmitting the radio frequency signal generated by the wireless interface circuit 52 to other devices and receiving radio frequency signals from other devices.

[0024] Device 50 can include a camera capable of recording or detecting individual frames, which are then passed to a codec 54 or the controller for processing. The device can receive video image data for processing from another device before transmission and / or storage. Device 50 can further receive images for coding / decoding wirelessly or via a wired connection. The structural elements of device 50 described above represent examples of means for performing corresponding functions.

[0025] With reference to FIG. 3, an example of a system in which embodiments of the present invention can be utilized is shown. System 10 includes a number of communication devices that can communicate through one or more networks. System 10 can include any combination of wired or wireless networks including, but not limited to, wireless cellular telephone networks (such as GSM, UMTS, CDMA networks, etc.), wireless local area networks (WLANs) defined by any of the IEEE 802.x standards, Bluetooth personal area networks, Ethernet local area networks, token ring local area networks, wide area networks, and the Internet.

[0026] System 10 can include both wired and wireless communication devices and / or devices 50 suitable for implementing embodiments of the present invention.

[0027] For example, the system shown in FIG. 3 shows a mobile phone network 11 and a representation of the Internet 28. The connection to the Internet 28 can include, but is not limited to, a long-range wireless connection, a short-range wireless connection, and various wired connections including, but not limited to, telephone lines, cable lines, power lines, and similar communication paths.

[0028] The exemplary communication devices shown in system 10 can 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 notebook computer 22. The apparatus 50 can be stationary or portable and carried by a person on the move. The apparatus 50 can also be disposed in a means of transportation including, but not limited to, an automobile, a truck, a taxi, a bus, a train, a ship, an airplane, a bicycle, a motorcycle, or a similar suitable means of transportation.

[0029] Embodiments can also be implemented in a set-top box, i.e., a digital TV receiver that may or may not have a display or wireless capabilities, in a tablet or (laptop) personal computer (PC) having encoder / decoder implemented hardware, software, or a combination, in various operating systems, and in a chipset, a processor, a DSP, and / or an embedded system that provides hardware / software based coding.

[0030] Some or additional devices can send and receive calls and messages and communicate with a service provider via a wireless connection 25 to a base station 24. The base station 24 can be connected to a network server 26 that enables communication between the mobile phone network 11 and the Internet 28. The system can include additional communication devices and various types of communication devices.

[0031] The communication device can 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 Message Service (MMS), electronic mail, Instant Message Service (IMS), Bluetooth, IEEE 802.11, and similar wireless communication technologies. The communication device involved in the implementation of various embodiments of the present invention can communicate using various media including, but not limited to, wireless, infrared, laser, cable connection, and any suitable connection.

[0032] 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 over a multiplex medium that can carry several logical channels. A channel can be used to carry an information signal, e.g., a bit stream, from one or several senders (or transmitters) to one or several receivers.

[0033] The MPEG - 2 Transport Stream (TS) specified in ISO / IEC 13818 - 1 or the equivalent ITU - T Recommendation H.222.0 is a format for multiplexing and streaming audio, video, and other media, as well as program metadata or other metadata. A Packet Identifier (PID) is used to identify an elementary stream (also known as a packetized elementary stream) within the TS. Thus, a logical channel within the MPEG - 2 TS can be considered to correspond to a specific PID value.

[0034] The available media file format standards include the ISO-based media file format (ISO / IEC 14496-12, sometimes abbreviated as ISOBMFF), and the file format of NAL unit structured video derived from ISOBMFF (ISO / IEC 14496-15).

[0035] A video codec consists of an encoder that converts the input video into a compressed representation suitable for storage / transmission, and a decoder that decompresses the compressed video representation and returns it to a displayable format. The video encoder and / or video decoder may also be separate from each other, i.e., they do not have to form a codec. Generally, the encoder discards some information of the original video sequence in order to represent the video in a more compact form (i.e., at a lower bitrate).

[0036] Many encoder implementations of typical hybrid video encoders, such as ITU-T H.263 and H.264, encode video information in two phases. First, the pixel values of a specific picture area (or "block") are predicted, for example, by means of motion compensation (finding and indicating 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 being encoded in a specified way). Second, the prediction error, i.e., the difference between the predicted block of pixels and the original block of pixels, is encoded. This is generally done by using a specified transform (e.g., discrete cosine transform (DCT) or a variant thereof) to transform the difference in pixel values, quantizing the coefficients, and entropy encoding the quantized coefficients. By changing the fidelity of the quantization process, the encoder can control the balance between the accuracy of the pixel representation (picture quality) and the size of the resulting encoded video representation (file size or transmission bitrate).

[0037] In temporal prediction, the source of prediction is a previously decoded picture (also known as a reference picture). In intra block copy (IBC; also known as intra block copy prediction), the prediction is applied in the same way as temporal prediction, but the reference picture is the current picture, and only previously decoded samples can be referenced in the prediction process. Inter-layer or inter-view prediction can be applied in the same way as temporal prediction, but the reference pictures are decoded pictures from different scalable layers or different views, respectively. In some cases, inter prediction can only refer to temporal prediction, while in other cases, inter prediction can refer to intra block copy, inter-layer prediction, and inter-view prediction together, provided that it is performed in the same or a similar process as temporal prediction. Inter prediction or temporal prediction is sometimes called motion compensation or motion compensation prediction.

[0038] Inter prediction, which may also be called temporal prediction, motion compensation, or motion compensation prediction, reduces temporal redundancy. In inter prediction, the source of prediction is a previously decoded picture. Intra prediction takes advantage of the high likelihood that adjacent pixels within the same picture are correlated. Intra prediction can be performed in the spatial domain or the transform domain, i.e., either sample values or transform coefficients can be predicted. Intra prediction is generally used in intra coding where inter prediction is not applicable.

[0039] One result of the coding procedure is a set of coding parameters such as motion vectors and quantized transform coefficients. Many parameters can be entropy coded more efficiently if they are first predicted from spatially or temporally adjacent parameters. For example, a motion vector can be predicted from spatially adjacent motion vectors, and only the difference with respect to the motion vector predictor can be coded. The prediction of coding parameters and intra prediction are sometimes collectively called in-picture prediction.

[0040] Figure 4 shows a block diagram of a video encoder suitable for utilizing embodiments of the present invention. Although Figure 4 shows an encoder with two layers, it will be understood that the presented encoder can be similarly extended to encode three or more layers. Figure 4 shows one embodiment of a video encoder including 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 can include similar elements for encoding incoming pictures. The encoder sections 500, 502 can include pixel predictors 302, 402, prediction error encoders 303, 403, and prediction error decoders 304, 404. Figure 4 further shows an embodiment of the pixel predictors 302, 402 including an inter predictor 306, 406, an intra predictor 308, 408, a mode selector 310, 410, a filter 316, 416, and a reference frame memory 318, 418. The pixel predictor 302 of the first encoder section 500 receives the base layer image 300 of the video stream to be encoded by both the inter predictor 306 (which determines the difference between the image and the motion-compensated reference frame 318) and the intra predictor 308 (which determines the prediction of an image block based only on the already processed portion of the current frame or picture). The outputs of both the inter predictor and the intra predictor are passed to the mode selector 310. The intra predictor 308 can have two or more intra prediction modes. Thus, each mode can perform an intra prediction and provide the predicted signal to the mode selector 310. The mode selector 310 further receives a copy of the base layer picture 300. Correspondingly, the pixel predictor 402 of the second encoder section 502 receives the enhancement layer image 400 of the video stream to be encoded by both the inter predictor 406 (which determines the difference between the image and the motion-compensated reference frame 418) and the intra predictor 408 (which determines the prediction of an image block based only on the already processed portion of the current frame or picture).The outputs of both the inter predictor and the intra predictor are passed to the mode selector 410. The intra predictor 408 can have two or more intra prediction modes. Thus, each mode can perform an intra prediction and provide the predicted signal to the mode selector 410. The mode selector 410 further receives a copy of the enhancement layer picture 400.

[0041] Depending on which encoding mode is selected to encode the current block, the output of the inter predictors 306, 406, or the output of one of the optional intra predictor modes, or the output of the surface encoder within the mode selector, is passed to the output section of the mode selectors 310, 410. The output of the mode selector is passed to the first addition device 321, 421. The first addition device can subtract the output of the pixel predictors 302, 402 from the base layer picture 300 / enhancement layer picture 400 to generate the first prediction error signals 320, 420, and the prediction error signals 320, 420 are input to the prediction error encoders 303, 403.

[0042] The pixel predictors 302, 402 further receive, from the preliminary reconstructors 339, 439, a combination of the predictive representation of the image blocks 312, 412 and the outputs 338, 438 of the prediction error decoders 304, 404. The preliminary reconstructed images 314, 414 may be passed to the intra predictors 308, 408 and the filters 316, 416. The filters 316, 416 that receive the preliminary representation can filter the preliminary representation and output the final reconstructed images 340, 440, and the final reconstructed images 340, 440 may be saved in the reference frame memories 318, 418. The reference frame memory 318 can be connected to the inter predictor 306 to be used as a reference image, and for the reference image, the future base layer picture 300 is compared in the inter prediction operation. Subject to the base layer being selected and indicated to be a source for interlayer sample prediction and / or interlayer motion information prediction of the enhancement layer according to some embodiments, the reference frame memory 318 can also be connected to the inter predictor 406 to be used as a reference image, and for the reference image, the future enhancement layer picture 400 is compared in the inter prediction operation. Moreover, the reference frame memory 418 can be connected to the inter predictor 406 to be used as a reference image, and for the reference image, the future enhancement layer picture 400 is compared in the inter prediction operation.

[0043] 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 base layer being selected and indicated to be a source for predicting the filtering parameters of the enhancement layer according to some embodiments.

[0044] The prediction error encoders 303 and 403 include conversion units 342 and 442, and quantizers 344 and 444. The conversion units 342 and 442 convert the first prediction error signals 320 and 420 into the transform domain. This conversion is, for example, a DCT conversion. The quantizers 344 and 444 quantize the transform domain signals, for example, DCT coefficients, to form quantized coefficients.

[0045] The prediction error decoders 304 and 404 receive the output from the prediction error encoders 303 and 403, perform a process opposite to that of the prediction error encoders 303 and 403 to generate decoded prediction error signals 338 and 438, and when the signals are combined with the predicted representations of the image blocks 312 and 412 by the second addition devices 339 and 439, generate pre-reconstructed images 314 and 414. The prediction error decoder can be considered to include an inverse quantizer 361 and 461 that inverse quantizes quantized coefficient values, for example, DCT coefficients, to reconstruct the transform signal, and an inverse transform unit 363 and 463 that performs an inverse transform on the reconstructed transform signal, where the output of the inverse transform unit 363 and 463 includes the reconstructed block. The prediction error decoder can further include a blocking filter that can filter the reconstructed block according to additional decoded information and filter parameters.

[0046] The entropy encoders 330 and 430 receive the output of the prediction error encoders 303 and 403, perform appropriate entropy encoding / variable length encoding on the signal, and can provide an error detection and correction function. The output of the entropy encoders 330 and 430 can be inserted into the bitstream by, for example, a multiplexer 508.

[0047] Entropy coding / decoding can be performed in many ways. For example, context-based coding / decoding can be applied, and both the encoder and the decoder change the context state of the coding parameters based on the previously coded / decoded coding parameters. Context-based coding can be, for example, context adaptive binary arithmetic coding (CABAC) or context-based variable length coding (CAVLC) or any similar entropy coding. Entropy coding / decoding can alternatively or additionally be performed using a variable length coding scheme such as Huffman coding / decoding or exponential Golomb coding / decoding. The decoding of the coding parameters from the entropy-coded bitstream or codeword is sometimes referred to as syntax analysis.

[0048] The H.264 / AVC standard was developed by the Joint Video Team (JVT) of the Video Coding Experts Group (VCEG) of the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T) and the Moving Picture Experts Group (MPEG) of the International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC). The H.264 / AVC standard has been published by both standardization parents and is called ITU-T Recommendation H.264 and ISO / IEC International Standard 14496-10, and is also known as MPEG-4 Part 10 Advanced Video Coding (AVC). There are a number of versions of the H.264 / AVC standard that incorporate new extensions or features of this specification. These extensions include scalable video coding (SVC) and multi-view video coding (MVC).

[0049] Version 1 of the High Efficiency Video Coding (H.265 / HEVC, also known as HEVC) standard was developed by the Joint Collaborative Team on Video Coding (JCT-VC) of VCEG and MPEG. This standard has been published by both standardization bodies and is known as ITU-T Recommendation H.265 and ISO / IEC International Standard 23008-2, and is also known as MPEG-H Part 2 High Efficiency Video Coding (HEVC). Subsequent versions of H.265 / HEVC include extensions for scalable, multi-view, fidelity range, 3D, and screen content coding, which may be abbreviated as SHVC, MV-HEVC, REXT, 3D-HEVC, and SCC, respectively.

[0050] SHVC, MV-HEVC, and 3D-HEVC use a common base specification specified in Annex F of Version 2 of the HEVC standard. This common base includes high-level syntax and semantics that specify some of the characteristics of the layers of the bitstream, such as inter-layer dependencies, and decoding processes such as reference picture list construction that includes inter-layer reference pictures and picture order count derivation for multi-layer bitstreams. Annex F can also be used for potential future multi-layer extensions of HEVC. Even if video encoders, video decoders, encoding methods, decoding methods, bitstream structures, and / or embodiments can be described below with reference to specific extensions such as SHVC and / or MV-HEVC, it should be understood that they are generally applicable to multi-layer extensions of HEVC and, more generally still, to any multi-layer video coding scheme.

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

[0052] Some important definitions, bitstreams, and coding structures, concepts, and some extensions of H.264 / AVC, HEVC, and VVC are described in this section as an example of a video encoder, decoder, encoding method, decoding method, and bitstream structure that can implement embodiments. Aspects of various embodiments are not limited to H.264 / AVC, HEVC, VVC, or their extensions. Rather, one possible basic explanation that can partially or fully implement the present embodiment is given. Whenever any of VVC or its draft versions are referred to below, it should be understood that the description is consistent with the VVC draft specification, that changes may occur in later draft versions and the final version of VVC, and that the description and embodiments can be adjusted to be consistent with the final version of VVC.

[0053] Video coding standards can specify bitstream syntax and semantics, as well as the decoding process for a bitstream without errors. On the other hand, the encoding process may not be specified, but an encoder may be required to generate a compliant bitstream. The compliance of the bitstream and decoder can be verified using a Hypothetical Reference Decoder (HRD). The standard can include coding tools useful for dealing with transmission errors and losses, but the use of tools in encoding may be optional, and the decoding process for an incorrect bitstream may not be specified.

[0054] Syntax elements can be defined as elements of data represented in a bitstream. A syntax structure can be defined as zero or more syntax elements that exist together in a bitstream in a specific order.

[0055] Each syntax element can be described by a name and a descriptor of one of the ways of coded representation. A rule can be used that all syntax element names are composed of underscore characters and in lowercase. The decoding process of the video decoder can react according to the value of the syntax element and the value of the previously decoded syntax element.

[0056] When describing H.264 / AVC, HEVC, VCC, and exemplary embodiments, the following descriptors and / or descriptions can be used to specify the syntax analysis process of each syntax element. - u(n): Unsigned integer using n bits. If n is "v" in the syntax table, the number of bits varies according to the value of other syntax elements. The syntax analysis process of this descriptor is interpreted from the bitstream as the binary representation of an unsigned integer where the most significant bit is written first, and is specified by the next n bits. - ue(v): Exponential Golomb coded (also known as exponential Golomb coding) syntax element of an unsigned integer with the left bit at the beginning.

[0057] The exponential Golomb bit string can be converted to a code number (codeNum), for example, using the following table.

[0058] [Table 1]

[0059] In some cases, the syntax table can use other variable values derived from the syntax element values. A variable naming rule with a mix of lowercase and uppercase and no underscore characters can be used. Variables starting with an uppercase letter can be derived for the decoding of the current syntax structure and all dependent syntax structures. Variables starting with an uppercase letter can be used in the decoding process of subsequent syntax structures without referring to the original syntax structure of the variable. A rule can be used where variables starting with a lowercase letter can only be used within the context in which they are derived.

[0060] In some cases, "mnemonic" names of syntax element values or variable values are used interchangeably with their numerical values. Sometimes, "mnemonic" names are used without the associated numerical values.

[0061] A flag can be defined as a variable or a single-bit syntax element that can take one of two possible values, 0 and 1.

[0062] An array can be either a syntax element or a variable. Square brackets can be used for indexing arrays. One-dimensional arrays are sometimes called lists. Two-dimensional arrays are sometimes called matrices.

[0063] A function can be described by a name. The function name starts with an uppercase letter, contains a mix of lowercase and uppercase without underscore characters, and ends with a left and right parenthesis containing zero or more variable names (for definition) or values (for usage), separated by commas in the case of two or more variables.

[0064] 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 logarithm of x with base 2.

[0065] A process for specifying how to decode syntax elements can be specified. The process can have separate specifications and calls. It can be specified that all syntax elements and uppercase variables related to the current syntax structure and associated syntax structures are available in the process specification and call, and the process specification can also specify whether to have lowercase variables explicitly specified as input. Each process specification can explicitly specify one or more outputs, each of which can be a variable that can be either an uppercase variable or a lowercase variable.

[0066] Syntax, semantics, and processes can be described with arithmetic, logical, relational, bitwise, and assignment operators similar to those used in the C programming language. In particular, the operator / is used to denote integer division (by truncation), and the operator % is used to denote the modulus (i.e., the remainder of division).

[0067] The numbering and counting rules can start from 0. For example, "the first" corresponds to the 0th, "the second" corresponds to the 1st, and so on.

[0068] The basic units of the input to the encoder and the output of the decoder are generally pictures, respectively. The picture given as input to the encoder may also be called the source picture, and the picture decoded by the decoder may be called the decoded picture or the reconstructed picture.

[0069] The source picture and the decoded picture are each composed of one or more sample arrays, such as one of the following sets of sample arrays. - Luma (Y) only (monochrome). - Luma and two chroma components (YCbCr or YCgCo). - Green, blue, and red (also known as GBR or RGB). - An array representing other unspecified monochromatic or trichromatic sampling (e.g., also known as YZX, XYZ).

[0070] In the following, these arrays may be referred to as luma (or L or Y) and chroma, and the two chroma arrays may be referred to as Cb and Cr regardless of the actual color representation method in use. The actual color representation method in use can be indicated, for example, using a video user data information (VUI) syntax such as HEVC and can be displayed, for example, in a coded bitstream. A component can be defined as an array or a single sample from one of the three sample arrays (luma and two chromas), or as an array or a single sample of an array that constitutes a picture in a monochromatic format.

[0071] A picture can be defined as either a frame or a field. A frame contains a matrix of luma samples and, optionally, corresponding chroma samples. A field is a set of alternating sample lines of a frame when the source signal is interlaced and can be used as an encoder input. The chroma sample array may be absent (thus, monochromatic sampling may be used), or the chroma sample array may be subsampled when compared to the luma sample array.

[0072] Some chroma formats can be summarized as follows. - In monochromatic sampling, only one sample array exists, which can be nominally considered the luma array. - In 4:2:0 sampling, each of the two chroma arrays has half the height and half the width of the luma array. - In 4:2:2 sampling, each of the two chroma arrays has the same height as the luma array and half the width of the luma array. - In 4:4:4 sampling, when separate color planes are not used, each of the two chroma arrays has the same height and width as the luma array.

[0073] Coding formats or standards can enable encoding a sample array into a bitstream as separate color planes and separately decoding the separately encoded color planes from the bitstream. When separate color planes are used, each of them is processed separately (by an encoder and / or a decoder) as a picture with monochromatic sampling.

[0074] Partitioning can be defined as dividing a set into subsets such that each element of the set exists exactly in one of the subsets. In video coding, partitioning can be defined as dividing a picture or a sub-region of a picture into subsets such that each element of the picture or the sub-region of the picture exists exactly in one of the subsets. For example, in partitioning related to HEVC encoding and / or decoding, and / or VVC encoding and / or decoding, the following terms can be used. A coding block can be defined as an N×N block of samples for some value N such that the partitioning is the division of the coding tree block into coding blocks. A coding tree block (CTB) can be defined as an N×N block of samples for some value N such that the partitioning is the division of the component coding tree block into coding blocks. A coding tree unit (CTU) can be defined as the coding tree block of luma samples, two corresponding coding tree blocks of chroma samples of a picture having three sample arrays, or a monochrome picture, or the coding tree block of samples of a picture coded using three separate color planes and syntax structures used to code the samples. A coding unit (CU) can be defined as the coding block of luma samples, two corresponding coding blocks of chroma samples of a picture having three sample arrays, or a monochrome picture, or the coding block of samples of a picture coded using three separate color planes and syntax structures used to code the samples. The CU of the maximum allowable size can be named the LCU (largest coding unit) or the coding tree unit (CTU), and the video picture is divided into non-overlapping LCUs.

[0075] In HEVC, a coding unit (CU) consists of one or more prediction units (PUs) that define the prediction process for samples within the CU, and one or more transform units (TUs) that define the prediction error coding process for samples within the CU. Generally, a CU consists of a square block of samples having a size selectable from a predefined set of possible CU sizes. Each PU and TU can be further split into smaller PUs and TUs, respectively, to increase the granularity of the prediction process and the prediction error coding process. Each PU has prediction information associated with that PU (e.g., motion vector information for an inter prediction PU and intra prediction direction information for an intra prediction PU) that defines which type of prediction should be applied to the pixels within that PU.

[0076] Each TU can be associated with information (e.g., including DCT coefficient information) that describes the prediction error decoding process for samples within the TU. Whether prediction error coding is applied for each CU is generally signaled at the CU level. If there is no prediction error residual associated with a CU, it can be considered that there is no TU for that CU. The partitioning of an image into CUs and the partitioning of a CU into PUs and TUs are generally signaled in the bitstream, whereby the decoder can reproduce the intended structure of these units.

[0077] In the draft versions of H.266 / VVC, the following partitioning is applied. It should be noted that what is described here may further evolve until the standard is finalized in later draft versions of H.266 / VVC. Similar to HEVC, a picture is partitioned into coding tree units (CTUs), but the maximum CTU size has increased to 128×128. A coding tree unit (CTU) is first partitioned by a quadtree (also known as a quad tree) structure. Then, a quadtree leaf node can be further partitioned by a multi-type tree structure. The multi-type tree structure has four splitting types, namely, vertical binary splitting, horizontal binary splitting, vertical ternary splitting, and horizontal ternary splitting. A multi-type tree leaf node is called a coding unit (CU). Except when a CU is too large for the maximum transform length, CUs, prediction units (PUs), and transform units (TUs) have the same block size. The segmentation structure of a CTU is a quad tree with a nested multi-type tree using binary splits and ternary splits, i.e., the concept of separate CUs, PUs, and TUs is not used except when required for a CU with a size too large for the maximum transform length. A CU can have either a square or rectangular shape.

[0078] The basic unit for the output of encoders of some coding formats such as VVC, v, etc. and the input of decoders of some coding formats such as VVC is the network abstraction layer (NAL) unit. For transport over a packet-oriented network or storage in a structured file, the NAL unit can be encapsulated in a packet or a similar structure.

[0079] For a NAL unit stream in a transmission or storage environment that does not provide a framing structure, a byte stream format can be specified. The byte stream format separates NAL units from each other by attaching a start code before each NAL unit. To avoid misdetection of NAL unit boundaries, the encoder executes a byte-oriented start code emulation prevention algorithm that adds an emulation prevention byte to the NAL unit payload when a start code appears to be different. Start code emulation prevention can always be performed regardless of whether the byte stream format is used to enable direct gateway operations between packet-oriented systems and stream-oriented systems.

[0080] A NAL unit can be defined as a syntax structure that includes a byte indicating the type of the subsequent data and the data in the form of an RBSP with emulation prevention bytes inserted as necessary. The raw byte sequence payload (RBSP) can be defined as a syntax structure that includes an integer number of bytes encapsulated in a NAL unit. The RBSP has the form of a string of data bits that includes syntax elements, followed by an RBSP stop bit, and further followed by zero or more trailing bits equal to 0.

[0081] A NAL unit consists of a header and a payload. The NAL unit header indicates, in particular, the type of the NAL unit.

[0082] NAL units can be classified into video coding layer (VCL) NAL units and non-VCL NAL units. VCL NAL units are generally coded slice NAL units.

[0083] A non-VCL NAL unit can be, for example, one of the following types of sequence parameter set, picture parameter set, supplementary enhancement information (SEI) NAL unit, access unit delimiter, sequence end NAL unit, bitstream end NAL unit, or filler data NAL unit. Parameter sets may be required for the reconstruction of decoded pictures, while many of the other non-VCL NAL units are not required for the reconstruction of decoded sample values.

[0084] Some coding formats specify parameter sets that can carry parameter values required for the decoding or reconstruction of decoded pictures. Parameters can be defined as syntactic elements of the parameter set. A parameter set can be defined as a syntactic structure that contains parameters and can be referenced from another syntactic structure or activated by another syntactic structure, for example, using an identifier.

[0085] Several types of parameter sets are briefly described below. It should be understood that other types of parameter sets may exist and embodiments may be applied, but are not limited to the types of parameter sets described. Parameters that remain unchanged throughout the coded video sequence may be included in the sequence parameter set (SPS). In addition to the parameters that may be required by the decoding process, the sequence parameter set may optionally include video user data information (VUI), which may include parameters important for buffering, picture output timing, rendering, and resource reservation. The picture parameter set (PPS) includes such parameters that are likely not to change in several coded pictures. The picture parameter set may be able to include parameters that can be referenced by the coded picture segments of one or more coded pictures. The header parameter set (HPS) has been proposed to include such parameters that may change from picture to picture.

[0086] A bitstream can be defined as a sequence of bits, which in some coding formats or standards can be in the form of a NAL unit stream or byte stream that forms the representation of coded pictures and associated data that form one or more coded video sequences. Within the same logical channel, such as within the same file or the same connection of a communication protocol, a first bitstream can be followed by a second bitstream. An elementary stream (in the context of video coding) can be defined as a sequence of one or more bitstreams. In some coding formats or standards, the end of a first bitstream can be indicated by a specific NAL unit, which may be called a bitstream end (EOB) NAL unit and is the last NAL unit of the bitstream.

[0087] The bitstream portion can be defined as a contiguous subset of the bitstream. In certain situations, the bitstream portion may consist of one or more entire syntax structures, and may require that there be no incomplete syntax structures. In other situations, the bitstream portion can also include any contiguous section of the bitstream and can include incomplete syntax structures.

[0088] Phrases such as "along the bitstream" (e.g., the indication "along the bitstream") or "along the coded unit of the bitstream" (e.g., the indication "along the coded tile") can be used in the claims and the described embodiments to refer to transmission, signaling, or storage such that "out-of-band" data is respectively associated with but not included in the bitstream or the coded unit. Phrases such as decoding along the bitstream or decoding along the coded unit of the bitstream can refer to the decoding of the mentioned out-of-band data (which can be obtained from out-of-band transmission, signaling, or storage) respectively associated with the bitstream or the coded unit. For example, if the bitstream is included in a container file such as a file conforming to the ISO base media file format, and specific file metadata is stored in the file in a way that associates the metadata with the bitstream, such as in a box of the sample entry of the track containing the bitstream, a sample group of the track containing the bitstream, or a timecode metadata track related to the track containing the bitstream, the phrase "along the bitstream" can be used.

[0089] A coded video sequence (CVS) can be defined as a sequence of coded pictures in decoding order that is independently decodable and followed by another coded video sequence or the end of the bitstream. The coded video sequence can be specified to end when a particular NAL unit, sometimes called a sequence end (EOS) NAL unit, appears in the bitstream, additionally or alternatively.

[0090] An image can be split into separately encodable and decodable image segments (e.g., slices and / or tiles and / or tile groups). Such image segments can enable parallel processing. As used herein, a "slice" can refer to an image segment composed of a particular number of basic coding units processed in default coding or decoding order, while a "tile" can refer to an image segment defined as a rectangular image region along a tile grid. A tile group can be defined as a group of one or more tiles. Image segments can be coded as separate units within a bitstream, such as VCL NAL units of H.264 / AVC and HEVC and VVC. A coded image segment can include a header and a payload, and the header can include parameter values necessary for decoding the payload. The payload of a slice can sometimes be called slice data.

[0091] In HEVC, a picture can be partitioned into tiles, where a tile is rectangular and contains integer LCU. In HEVC, partitioning into tiles forms a regular grid, and the height and width of a tile differ from each other by at most 1 LCU. In HEVC, a slice is defined as an integer number of coding tree units that includes one 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 coding tree units that are consecutively ordered in a tile scan and are contained within a single NAL unit. The division of each picture into slice segments is partitioning. In HEVC, an independent slice segment is defined as a slice segment in which the values of the syntax elements of the slice segment header are not inferred from the values of the previous slice segment, and a dependent slice segment is defined as a slice segment in which the values of some syntax elements of the slice segment header are inferred from the values of the preceding independent slice segment in decoding order. In HEVC, a slice header is defined as the slice segment header of an independent slice segment that is either the current slice segment or an independent slice segment that precedes the current dependent slice segment, and a slice segment header is defined as part of a coded slice segment that contains data elements related to the first or all coding tree units represented within the slice segment. CUs are scanned in raster scan order within a tile or, if tiles are not used, within a picture. Within an LCU, CUs have a specific scan order.

[0092] As a result, video coding standards and specifications can enable an encoder to split a coded picture into coded slices and the like. Intra-picture prediction is generally disabled across slice boundaries. Thus, a slice can be regarded as a way to split a coded picture into independently decodable pieces. In H.264 / AVC and HEVC, intra-picture prediction can be disabled across slice boundaries. Thus, a slice can be regarded as a way to split a coded picture into independently decodable pieces, and therefore, a slice is often regarded as a basic unit of transmission. In many cases, the encoder can indicate in the bitstream which type of intra-picture prediction is stopped across slice boundaries, and the decoder operation takes this information into account when concluding, for example, which prediction sources are available. For example, if adjacent CUs are in different slices, samples from adjacent CUs can be regarded as unavailable for intra prediction.

[0093] In the draft version of VVC, namely VVC draft 5, the partitioning of a picture into slices, tiles, and bricks is defined as follows. Other draft versions of VVC can similarly define the partitioning of a picture into slices, tiles, and bricks.

[0094] A picture is split into one or more tile rows and one or more tile columns. The partitioning of a picture into tiles forms a tile grid that can be characterized by a list of tile column widths (in CTU units) and a list of tile row heights (in CTU units).

[0095] A tile is a sequence of coding tree units (CTUs) that encompasses a tile grid, i.e., one "cell" within a rectangular region of a picture. A tile is divided into one or more bricks, each of which consists of several CTU rows within the tile. A tile that is not partitioned into multiple bricks is also called a brick. However, a brick, which is a true subset of a tile, is not called a tile.

[0096] A slice contains several tiles of a picture or several bricks of a tile. A slice is a VCL NAL unit.

[0097] Two modes of a slice are supported, namely, the raster scan slice mode and the rectangular slice mode. In the raster scan slice mode, a slice contains a sequence of tiles in the tile raster scan of the picture. In the rectangular slice mode, a slice contains several bricks of a picture that collectively form a rectangular region of the picture. The bricks within a rectangular slice are in the order of the brick raster scan of the slice.

[0098] A brick scan can be defined as a specific sequential ordering of CTUs that partition a picture. The CTUs are sequentially ordered in a brick CTU raster scan, the bricks within a tile are sequentially ordered in a tile brick raster scan, and the tiles of a picture are sequentially ordered in a picture tile raster scan. For example, in a coding standard, it may be required that coded slice NAL units must be in an order that increases the CTU address in brick scan order for the first CTU of each coded slice NAL unit, where the CTU address can be defined to increase in a CTU raster scan within a picture. A raster scan can be defined as a mapping of a rectangular two-dimensional pattern to a one-dimensional pattern, such that the first entry of the one-dimensional pattern is from the first topmost row of the two-dimensional pattern scanned from left to right, and subsequently, similarly, the second row, third row, etc. of the pattern are scanned (downward) from left to right, respectively.

[0099] Figure 5a shows an example of a raster scan slice partitioning of a picture, where the picture is divided into 12 tiles and 3 raster scan slices. Figure 5b shows an example of a rectangular slice partitioning (18×12 CTUs) of a picture, where the picture is divided into 24 tiles (6 tile columns and 4 tile rows) and 9 rectangular slices. Figure 5c shows an example of a picture partitioned into tiles, bricks, and rectangular slices, where the picture is divided into 4 tiles (2 tile columns and 2 tile rows), 11 bricks (the top-left tile contains 1 brick, the top-right tile contains 5 bricks, the bottom-left tile contains 2 bricks, and the bottom-right tile contains 3 bricks), and 4 rectangular slices.

[0100] Partitioning into tiles, bricks, and rectangular slices is specified in the Picture Parameter Set (PPS). Figure 6 shows the syntax for displaying partitioning into tiles and bricks, which is performed in two phases. As a first phase, a tile grid (i.e., tile column width and tile row height) is provided, after which the displayed tiles are further partitioned into bricks.

[0101] There are two modes for indicating the tile grid, namely, uniform (indicated by the syntax element uniform_tile_spacing_flag having a value equal to 1) and explicit. In uniform tile spacing, the tiles have equal width except for the rightmost tile column that may exist, and equal height except for the bottommost tile row that may exist. In explicit tile spacing, the width and height of the columns and rows of tiles (respectively) are indicated (in CTU units) except for the rightmost column and bottommost row (respectively).

[0102] Similar to the way the tile grid is displayed, there are two modes for indicating the way the tiles are split into bricks, i.e., uniform or explicit brick spacing can be indicated for each tile. The signaling is similar to that for the tile rows.

[0103] When rectangular slices are used, the syntax element num_slices_in_pic_minus1 is included, followed by a syntax structure that provides the following for each slice. - The top-left brick index (except for the first slice which is assumed to have index 0), - The brick index of the difference between the bottom-right brick of the slice and the top-left brick index.

[0104] The semantics of the syntax elements in Figure 6 are specified as follows in VVC Draft 5.

[0105] A single_tile_in_pic_flag equal to 1 specifies that only one tile exists in each picture that refers to the PPS. A single_tile_in_pic_flag equal to 0 specifies that two or more tiles exist in each picture that refers to the PPS. Note - If there is no further brick splitting within a tile, the entire tile is called a brick. If a picture contains only a single tile without further brick splitting, it is called a single brick. It is a bitstream compliance requirement that the value of single_tile_in_pic_flag must be the same for all PPSs activated within the CVS.

[0106] A uniform_tile_spacing_flag equal to 1 specifies that tile column boundaries and, similarly, tile row boundaries are evenly distributed across the picture and are signaled using the syntax elements tile_cols_width_minus1 and tile_rows_height_minus1. A 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 picture and are signaled using the syntax elements num_tile_columns_minus1 and num_tile_rows_minus1 and a list of syntax element pairs tile_column_width_minus1[i] and tile_row_height_minus1[i]. If not present, the value of the uniform_tile_spacing_flag is assumed to be equal to 1.

[0107] When uniform_tile_spacing_flag is equal to 1, tile_cols_width_minus1 + 1 specifies the width of the tile columns in units of CTBs, excluding the tile column at the right end of the picture. The value of tile_cols_width_minus1 must be in the range from 0 to PicWidthInCtbsY - 1 (both ends included). If it does not exist, the value of tile_cols_width_minus1 is assumed to be equal to PicWidthInCtbsY - 1.

[0108] When uniform_tile_spacing_flag is equal to 1, tile_rows_height_minus1 + 1 specifies the height of the tile rows in units of CTBs, excluding the tile row at the bottom of the picture. The value of tile_rows_height_minus1 must be in the range from 0 to PicHeightInCtbsY - 1 (both ends included). If it does not exist, the value of tile_rows_height_minus1 is assumed to be equal to PicHeightInCtbsY - 1.

[0109] When uniform_tile_spacing_flag is equal to 0, num_tile_columns_minus1 + 1 specifies the number of tile columns that partition the picture. The value of num_tile_columns_minus1 must be in the range from 0 to PicWidthInCtbsY - 1 (both ends included). When single_tile_in_pic_flag is equal to 1, the value of num_tile_columns_minus1 is assumed to be equal to 0. Otherwise, when uniform_tile_spacing_flag is equal to 1, the value of num_tile_columns_minus1 is assumed as specified in the CTB raster scanning, tile scanning, and brick scanning processes.

[0110] num_tile_rows_minus1 + 1 specifies the number of tile rows that partition the picture when uniform_tile_spacing_flag is equal to 0. The value of num_tile_rows_minus1 shall be in the range from 0 to PicHeightInCtbsY - 1, inclusive. When single_tile_in_pic_flag is equal to 1, the value of num_tile_rows_minus1 is assumed to be 0. Otherwise, when uniform_tile_spacing_flag is equal to 1, the value of num_tile_rows_minus1 is assumed as specified in the CTB raster scanning, tile scanning, and slice scanning processes. 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 shall be greater than 1.

[0111] tile_column_width_minus1[i] + 1 specifies the width of the i-th tile column in units of CTBs.

[0112] tile_row_height_minus1[i] + 1 specifies the height of the i-th tile row in units of CTBs.

[0113] A brick_splitting_present_flag equal to 1 specifies that one or more tiles of the picture referenced by the PPS may be split into two or more bricks. A brick_splitting_present_flag equal to 0 specifies that the tiles of the picture referenced by the PPS are not split into two or more bricks.

[0114] A brick_split_flag[i] equal to 1 specifies that the i-th tile is split into two or more bricks. A brick_split_flag[i] equal to 0 specifies that the i-th tile is not split into two or more bricks. If it does not exist, the value of brick_split_flag[i] is assumed to be 0.

[0115] A uniform_brick_spacing_flag[i] equal to 1 specifies that the horizontal brick boundaries are evenly distributed across the i-th tile and signaled using the syntax element brick_height_minus1[i]. A uniform_brick_spacing_flag[i] equal to 0 specifies that the horizontal brick boundaries may or may not be evenly distributed across the i-th tile and signaled using the syntax element num_brick_rows_minus1[i] and a list of syntax elements brick_row_height_minus1[i][j]. If it does not exist, the value of uniform_brick_spacing_flag[i] is assumed to be 1.

[0116] brick_height_minus1[i] + 1, when uniform_brick_spacing_flag[i] is equal to 1, specifies the height of the brick rows, excluding the bottom brick of the i-th tile, in units of CTB. If it exists, the value of brick_height_minus1 shall be in the range from 0 to RowHeight[i] - 2 (inclusive). If it does not exist, the value of brick_height_minus1[i] is assumed to be equal to RowHeight[i] - 1.

[0117] num_brick_rows_minus1[i] + 1 specifies the number of bricks that partition the i-th tile when uniform_brick_spacing_flag[i] is equal to 0. If present, the value of num_brick_rows_minus1[i] must be in the range from 1 to RowHeight[i] - 1, inclusive. When brick_split_flag[i] is equal to 0, the value of num_brick_rows_minus1[i] is assumed to be 0. Otherwise, when uniform_brick_spacing_flag[i] is equal to 1, the value of num_brick_rows_minus1[i] is assumed as specified in the CTB raster scanning, tile scanning, and brick scanning processes.

[0118] brick_row_height_minus1[i][j] + 1 specifies the height of the j-th brick of the i-th tile in CTB units when uniform_tile_spacing_flag is equal to 0.

[0119] The following variables are derived. When uniform_tile_spacing_flag is equal to 1, the values of num_tile_columns_minus1 and num_tile_rows_minus1 are assumed. For each i in the range 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 assumed by calling the CTB raster scanning, tile scanning, and brick scanning processes, - A list RowHeight[j] for j in the range from 0 to num_tile_rows_minus1, inclusive, that specifies the height of the j-th tile row in CTB units. - A list CtbAddrRsToBs[ctbAddrRs] for ctbAddrRs in the range from 0 to PicSizeInCtbsY-1 (including both ends), which specifies the conversion from the CTB address of the CTB raster scan of the picture to the CTB address of the brick scan. - A list CtbAddrBsToRs[ctbAddrBs] for ctbAddrBs in the range from 0 to PicSizeInCtbsY-1 (including both ends), which specifies the conversion from the CTB address of the brick scan to the CTB address of the CTB raster scan of the picture. - A list BrickId[ctbAddrBs] for ctbAddrBs in the range from 0 to PicSizeInCtbsY-1 (including both ends), which specifies the conversion from the CTB address of the brick scan to the brick ID. - A list NumCtusInBrick[brickIdx] for brickIdx in the range from 0 to NumBricksInPic-1 (including both ends), which specifies the conversion from the brick index to the number of CTUs in the brick. - A list FirstCtbAddrBs[brickIdx] for brickIdx in the range from 0 to NumBricksInPic-1 (including both ends), which specifies the conversion from the brick ID to the CTB address of the first CTB of the brick scan.

[0120] A single_brick_per_slice_flag equal to 1 specifies that each slice referring to this PPS contains one brick. A single_brick_per_slice_flag equal to 0 specifies that the slices referring to this PPS can contain two or more bricks. If it does not exist, the value of the single_brick_per_slice_flag is assumed to be 1.

[0121] A rect_slice_flag equal to 0 specifies that the blocks within each slice are in raster scan order and the slice information is not signaled in the PPS. A rect_slice_flag equal to 1 specifies that the blocks within each slice enclose a rectangular region of the picture and the slice information is signaled in the PPS. When single_brick_per_slice_flag is equal to 1, rect_slice_flag is assumed to be equal to 1.

[0122] num_slices_in_pic_minus1 + 1 specifies the number of slices in each picture that refers to the PPS. The value of num_slices_in_pic_minus1 shall be in the range from 0 to NumBricksInPic - 1 (inclusive). If it does not exist and single_brick_per_slice_flag is equal to 1, the value of num_slices_in_pic_minus1 is assumed to be equal to NumBricksInPic - 1.

[0123] top_left_brick_idx[i] specifies the brick index of the brick placed at the upper left corner of the i-th slice. The value of top_left_brick_idx[i] shall not be equal to the value of top_left_brick_idx[j] when i is not equal to j. If it does not exist, the value of top_left_brick_idx[i] is assumed to be equal to i. The length of the top_left_brick_idx[i] syntax element is Ceil(Log2(NumBricksInPic)) bits.

[0124] bottom_right_brick_idx_delta[i] specifies the difference between the brick index of the brick placed at the bottom - right corner of the i - th slice 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 assumed to be equal to 0. The length of the bottom_right_brick_idx_delta[i] syntax element is Ceil(Log2(NumBricksInPic - top_left_brick_idx[i])) bits.

[0125] It is a bit - stream compliance requirement that a slice should contain only some complete tiles, or a contiguous sequence of complete bricks of one tile. The variables NumBricksInSlice[i] and BricksToSliceMap[j] that specify the number of bricks in the i - th slice and the mapping of bricks to slices are derived as follows. NumBricksInSlice[ i ] = 0 botRightBkIdx = 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[ botRightBkIdx ] && BrickRowBd[ j ] >= BrickRowBd[ top_left_brick_idx[ i ] ] && BrickRowBd[ j ] <= BrickColBd[ botRightBkIdx ] ) { NumBricksInSlice[ i ]++ BricksToSliceMap[ j ] = i } }

[0126] Thus, a rather complex syntax structure is intended to signal tile and brick partitioning. It is not optimal in many respects, for example, with respect to the number of syntax elements, the lines of syntax, the number of operation modes (i.e., separate uniform and explicit modes for both tiles and bricks, and separately indicated tile boundaries and brick boundaries), and the number of bits for signaling.

[0127] VVC Draft 6 supports sub - pictures (also known as sub - pictures). A sub - picture can be defined as a rectangular region of one or more slices within a picture, where one or more slices are complete. As a result, a sub - picture consists of one or more slices that collectively enclose a rectangular region of the picture. The slices of a sub - picture may be required to be rectangular slices. The partitioning of a picture into sub - pictures can be indicated in the SPS and / or decoded from the SPS. One or more of the following properties can be indicated (e.g., by the encoder), decoded (e.g., by the decoder), or inferred (e.g., by the encoder and / or decoder) for a sub - picture, either collectively or separately for each sub - picture. i) Whether the sub - picture is treated as a picture in the decoding process. In some cases, this property excludes in - loop filtering operations, which can be indicated / decoded / inferred separately. ii) Whether in - loop filtering operations are performed across sub - picture boundaries.

[0128] Next, an improved method for signaling tile and brick partitioning is introduced.

[0129] The method for encoding according to the first aspect shown in FIG. 7 includes encoding (700) a bitstream that includes the display of a tile column and the display of the block height of one or more tile columns at once, or encoding (700) the display of a tile column and the display of the block height of one or more tile columns at once in or along the bitstream; inferring (702) potential tile rows when detecting brick rows aligned through a picture; inferring or displaying (704) whether the boundaries of the potential tile rows are tile row boundaries; and encoding (706) one or more pictures into the bitstream using the displayed tile column, the displayed or inferred tile rows, and the displayed block height, wherein the one or more pictures are partitioned into a grid of tiles along the displayed tile column and the displayed or inferred tile rows, the tiles in the grid of tiles include integer coding tree units, are partitioned into one or more bricks, and the bricks include rows of integer coding tree units within the tile, including encoding (706).

[0130] The method for decoding according to the first aspect includes decoding, from and along the bitstream, the display of a tile column and the display of the block height of one or more tile columns at once; inferring potential tile rows when detecting brick rows aligned through a picture; inferring or decoding whether the boundaries of the potential tile rows are tile row boundaries; and decoding one or more pictures from the bitstream using the displayed tile column, the displayed or inferred tile rows, and the displayed block height, wherein the one or more pictures are partitioned into a grid of tiles along the displayed tile column and the displayed or inferred tile rows, the tiles in the grid of tiles include integer coding tree units, are partitioned into one or more bricks, and the bricks include rows of integer coding tree units within the tile, including decoding.

[0131] Accordingly, the tile columns and the brick heights for each tile column are represented by the encoder and / or decoded by the decoder, excluding the height of the tile rows. Potential tile row boundaries are presumed to be boundaries where brick boundaries are aligned (horizontally) through the picture. Accordingly, at a particular potential tile row boundary, it can be presumed that the potential tile row boundary is a tile row boundary. The presumption that a potential tile row boundary is a tile row boundary can be based on conclusions made from other information available in the syntax structure, or the lack of specific information from the syntax structure, e.g., the lack of a particular flag.

[0132] Alternatively, it can be indicated by the encoder and / or decoded by the decoder whether a potential tile row boundary is a tile row boundary. The indication can be based on, for example, one or more flags present in the syntax structure.

[0133] Accordingly, by only representing the tile columns and the brick heights for each tile column and presuming potential tile rows, partitioning can be signaled without signaling the height of the tile rows. As a result, the coding efficiency is improved and the bitrate required for such signaling is reduced.

[0134] In the following, some exemplary embodiments of a first aspect, namely, the syntax and semantics for representing tile columns and the brick heights for each tile column and excluding the height of the tile rows, are provided. The embodiments are equally applicable to encoding that generates a bitstream portion compliant with the syntax and semantics, and decoding that decodes the bitstream portion according to the syntax and semantics.

[0135] Example 1 of Syntax and Semantics

[0136] [Table 2]

[0137] A uniform_tile_col_spacing_flag equal to 1 specifies that tile column boundaries are evenly distributed across the picture and are signaled using the syntax element tile_cols_width_minus1. A uniform_tile_spacing_flag equal to 0 specifies that tile column boundaries may or may not be evenly distributed across the picture and are signaled using the list of syntax elements num_tile_columns_minus1 and tile_column_width_minus1[i]. If not present, the value of uniform_tile_col_spacing_flag is assumed to be equal to 1.

[0138] The semantics of tile_cols_width_minus1, num_tile_columns_minus1, and tile_column_width_minus1[i] are specified in exactly the same way as the semantics of the syntax elements with the same names in VVC draft 5.

[0139] When uniform_tile_col_spacing_flag is equal to 1, NumTileColsInPic is set equal to PicWidthInCtbsY / (tile_cols_width_minus1 + 1)+PicWidthInCtbsY % (tile_cols_width_minus1 + 1). Otherwise, NumTileColsInPic is set equal to num_tile_columns_minus1 + 1.

[0140] A uniform_brick_spacing_flag[i] equal to 1 specifies that the horizontal brick boundaries are evenly distributed across the i-th tile column and are signaled using the syntax element brick_height_minus1[i]. A uniform_brick_spacing_flag[i] equal to 0 specifies that the horizontal brick boundaries may or may not be evenly distributed across the i-th tile column and are signaled using the list of syntax elements num_brick_rows_minus1[i] and syntax element brick_row_height_minus1[i][j]. If not present, the value of uniform_brick_spacing_flag[i] is assumed to be equal to 1.

[0141] brick_height_minus1[i] + 1, when uniform_brick_spacing_flag[i] is equal to 1, specifies the height of the brick rows, excluding the bottommost brick of the i-th tile column, in units of CTB.

[0142] num_brick_rows_minus1[i] + 1, when uniform_brick_spacing_flag[i] is equal to 0, specifies the number of bricks partitioning the i-th tile column.

[0143] brick_row_height_minus1[i][j] + 1, when uniform_tile_spacing_flag is equal to 0, specifies the height of the j-th brick of the i-th tile column in units of CTB.

[0144] Syntax and Semantics Example 2 Example 2 is similar to Example 1, but additionally, whether the partitioning of the bricks in the current tile column is the same as that in the previous tile column is signaled by the encoder and / or decoded by the decoder.

[0145] [Table 3]

[0146] The semantics of the syntax element are the same as those in Example 1, but the semantics of copy_previous_col_flag[i] are added as follows. copy_previous_col_flag[i] equal to 1 specifies all of the following. - uniform_brick_spacing_flag[i] is presumed to be equal to uniform_brick_spacing_flag[i-1]. - If brick_height_minus1[i-1] exists, brick_height_minus1[i] is presumed to be equal to brick_height_minus1[i-1]. - If num_brick_rows_minus1[i-1] exists, num_brick_rows_minus1[i] is presumed to be equal to num_brick_rows_minus1[i-1], and brick_row_height_minus1[i][j] is presumed to be equal to brick_row_height_minus1[i-1][j] for each value of j in the range from 0 to num_brick_rows_minus1[i]-1 (inclusive).

[0147] On the other hand, problems with syntax structures that do not reach the optimum of VVC draft 5 can be mitigated by a technique that can display and / or decode the tile column width, tile row height, or brick height in a pre-defined scan order by the encoder and / or by the decoder until the remaining tile columns, tile rows, or bricks (respectively) are each shown or decoded to have equal dimensions (respectively).

[0148] A method for encoding according to this second aspect is shown in FIG. 8, and this method includes: a) a step of displaying (800) the number of partitions to be assigned; b) a step of determining (802) the number of units to be assigned to the partitions; c) a step of displaying (804) whether the number of units to be assigned is evenly distributed to the number of said partitions; and if not, d) a step of displaying (806) the number of units to be assigned to the next partition; and e) a step of repeating (808) steps c) and d) until all units are assigned to partitions.

[0149] A method for decoding according to the second aspect includes: a) a step of decoding the number of partitions to be assigned; b) a step of determining the number of units to be assigned to the partitions; c) a step of decoding whether the number of units to be assigned is evenly distributed to the number of said partitions; and if not, d) a step of decoding the number of units to be assigned to the next partition; and e) a step of repeating steps c) and d) until all units are assigned to partitions.

[0150] According to one embodiment applicable to encoding and / or decoding, the number of units assigned to a partition is one of the following, namely, the picture width in CTU units (for example, when the partition is a tile column), the picture height in CTU units (for example, when the partition is a tile row, or when the partition is a block row displayed for one or more complete tile columns at a time), the number of CTU rows of a tile (for example, when the partition is a tile block).

[0151] According to one embodiment applicable to encoding and / or decoding, a partition is one or more of the following, namely, a tile column, a tile row, a block row.

[0152] According to one embodiment applicable to encoding and / or decoding, the unit is a rectangular block of samples of a picture. For example, the unit of the second aspect shown in FIG. 8 can be a coding tree block.

[0153] Thus, by indicating the number of units to be assigned to the partitions in a predefined scan order, a significant saving in the number of syntax elements required and the bitrate required for said signaling can be achieved, especially when the number of units not yet assigned should be evenly distributed among the remaining partitions.

[0154] FIG. 9 shows an example of how the method of FIG. 8 can be implemented according to one embodiment. Thus, first, the number of partitions such as tile columns and / or tile rows to be assigned is indicated (900), and the number NU of units such as coding tree blocks (CTBs) to be assigned to the partitions is determined (902). To create a loop for checking whether all units are assigned to one partition, it is checked whether the number NP of partitions to be assigned is greater than 1 (904). If not, i.e., if NP = 1, it is inferred or indicated that all remaining units not yet assigned must be assigned to the remaining partition (910).

[0155] However, when NP > 1, it is checked whether the number of units NU to be assigned can be evenly divided by the number of partitions NP (906). If so, it is determined whether the number of units NU can be evenly assigned to the remaining partitions (908). If so, it is inferred or indicated that all the remaining units NU that have not yet been assigned must be evenly assigned to the remaining partitions (910). If it is recognized that the number of units NU to be assigned cannot be evenly divided by the number of partitions NP (906), or if it is determined that the number of units NU cannot be evenly assigned to the remaining partitions (908), the number of units to be assigned to the next partition in the predefined scanning order is displayed (912). The number of units NU to be assigned is reduced by the displayed number of units to be assigned to the next partition (914), and the number of partitions NP to be assigned is reduced by 1 (916). Then, it loops back to check whether the number of partitions NP to be assigned is greater than 1 (904).

[0156] The method of FIG. 9 can be similarly implemented to decode according to one embodiment described below. First, the number of partitions such as the tile columns and / or tile rows to be assigned is decoded from or along the bitstream, and the number of units NU such as the coding tree block (CTB) units to be assigned to the partitions is determined. To create a loop for checking whether all units are assigned to one partition, it is checked whether the number of partitions NP to be assigned is greater than 1. If not, i.e., when NP = 1, it is inferred or decoded from or along the bitstream that all the remaining units that have not yet been assigned must be assigned to the remaining partitions.

[0157] However, when NP > 1, it is checked whether the number of units NU to be assigned is evenly divisible by the number of partitions NP. In the affirmative case, it is decoded from or along the bitstream whether the number of units NU is evenly assigned to the remaining partitions. If it is recognized that the number of units NU to be assigned is not evenly divisible by the number of partitions NP, or if it is decoded from or along the bitstream that the number of units NU is not evenly assigned to the remaining partitions, the number of units to be assigned to the next partition in the predefined scanning order is decoded from or along the bitstream. The number of units NU to be assigned is reduced by the number of units shown to be assigned to the next partition, and the number of partitions NP to be assigned is reduced by 1. Then, it loops back to check whether the number of partitions NP to be assigned is greater than 1.

[0158] In the following, an exemplary embodiment of the syntax and semantics for unified signaling of a second aspect, namely explicit / uniform tile / block partitioning, is provided. This embodiment is equally applicable to encoding that generates a bitstream portion compliant with the syntax and semantics, and decoding that decodes the bitstream portion according to the syntax and semantics.

[0159] In this example, the unified signaling is used to specify the tile column width and tile row height, while the block signaling remains unchanged when compared to VVC draft 5.

[0160] [Table 4]

[0161] A rem_tile_col_equal_flag[i] equal to 0 specifies that the tile column with indices in the range from 0 to i (both ends included) may or may not have equal widths in CTB units. A rem_tile_col_equal_flag[i] equal to 1 specifies that the tile column with indices in the range from 0 to i (both ends included) has equal widths in CTB units, and it is assumed that tile_column_width_minus1[j] is equal to remWidthInCtbsY / (i + 1) for each value of j in the range from 0 to i (both ends included).

[0162] A rem_tile_row_equal_flag[i] equal to 0 specifies that the tile row with indices in the range from 0 to i (both ends included) may or may not have equal heights in CTB units. A rem_tile_row_equal_flag[i] equal to 1 specifies that the tile row with indices in the range from 0 to i (both ends included) has equal heights in CTB units, and it is assumed that tile_row_height_minus1[j] is equal to remHeightInCtbsY / (i + 1) for each value of j in the range from 0 to i (both ends included).

[0163] The semantics of other syntax elements can be specified in exactly the same way as the semantics of the syntax elements with the same names in VVC draft 5.

[0164] In the following, exemplary embodiments of syntax and semantics are provided that include both further aspects, namely, the display of tile columns and the block heights per tile column, and the unified signaling of explicit / uniform tile / block partitioning. This embodiment is equally applicable to both encoding that generates a bitstream portion conforming to the syntax and semantics, and decoding that decodes the bitstream portion according to the syntax and semantics.

[0165] Exemplary embodiments of the encoding can be summarized as follows, but the exemplary embodiments can be adapted to decoding by replacing the term "display" with the term "decoding".

[0166] The tile columns are displayed as follows. - The number of tile columns is displayed (num_tile_columns_minus1). - Until all tile columns are traversed or until the remaining tile columns are displayed as having equal widths, the following is displayed in a loop that traverses the tile columns from right to left. o If the remaining width (in units of CTB) is evenly divisible by the number of tile columns that have not yet been specified, it is displayed whether the remaining tile columns have equal widths (rem_tile_col_equal_flag[i]). o If the remaining tile columns do not have equal widths, the tile column width is displayed (tile_column_width_minus1[i]).

[0167] The following is displayed in a loop that traverses the tile columns from left to right in a rectangular slice and includes only one loop entry that specifies the tile row height in a raster scan slice. - A flag when the tile column's brick partitioning is the same as the previous tile column's brick partitioning. The flag does not exist in the leftmost tile column (copy_previous_col_flag[i]). Note that this flag can be omitted in this exemplary embodiment or there are other alternatives discussed further below that can be used to achieve a similar function as achieved by the flag. - When the tile brick partitioning of a tile column is not the same as the tile brick partitioning of the previous tile column, the bricks of the tile column are displayed as follows. o The number of bricks in the tile column is displayed (num_bricks_minus1[i]). o The following is displayed in a loop that traverses the bricks from bottom to top until all bricks in the tile column are traversed or until the remaining bricks in the tile column are shown to have equal height. · If the remaining height (in CTB units) is divisible by the number of bricks for which the remaining height has not yet been specified, it is shown whether the remaining bricks have equal height (rem_brick_height_equal_flag[i][j]). · If the remaining bricks do not have equal height, the brick height is shown (brick_height_minus1[i][j]).

[0168] In this exemplary embodiment, the following syntax can be used.

[0169]

Table 5

[0170] num_tile_columns_minus1 + 1 specifies the number of tile columns that partition the picture when uniform_tile_spacing_flag is equal to 0. The value of num_tile_columns_minus1 must be in the range from 0 to PicWidthInCtbsY - 1 (inclusive). When single_tile_in_pic_flag is equal to 1, the value of num_tile_columns_minus1 is presumed to be 0.

[0171] A rem_tile_col_equal_flag[i] equal to 0 specifies that the tile column with indices in the range from 0 to i (both ends included) may or may not have an equal width in CTB units. A rem_tile_col_equal_flag[i] equal to 1 specifies that the tile column with indices in the range from 0 to i (both ends included) is presumed to have an equal width in CTB units. If it does not exist, the value of rem_tile_col_equal_flag[i] is presumed to be equal to 0.

[0172] tile_column_width_minus1[i] + 1 specifies the width of the i-th tile column in CTB units.

[0173] A copy_previous_col_flag[i] equal to 0 specifies the existence of num_bricks_minus1[i]. A copy_previous_col_flag[i] equal to 1 specifies all of the following. - num_bricks_minus1[i] is presumed to be equal to num_bricks_minus1[i - 1], - rem_brick_height_equal_flag[i][j] is presumed to be equal to rem_brick_height_equal_flag[i - 1][j] for all such values of j in the range from 1 to num_bricks_minus1[i] (both ends included) where the value of rem_brick_height_equal_flag[i - 1][j] exists or is presumed to exist, - brick_height_minus1[i][j] is presumed to be equal to brick_height_minus1[i - 1][j] for all such values of j in the range from 1 to num_bricks_minus1[i] (both ends included) where the value of brick_height_minus1[i - 1][j] exists.

[0174] A copy_previous_col_flag[i] equal to 0 specifies the presence of num_bricks_minus1[i]. A copy_previous_col_flag[i] equal to 1 specifies all of the following. - num_bricks_minus1[i] is presumed to be equal to num_bricks_minus1[i - 1], - rem_brick_height_equal_flag[i][j] is presumed to be equal to rem_brick_height_equal_flag[i - 1][j] for all such values of j in the range from 1 to num_bricks_minus1[i] (inclusive) where the value of rem_brick_height_equal_flag[i - 1][j] exists or is presumed to exist, - brick_height_minus1[i][j] is presumed to be equal to brick_height_minus1[i - 1][j] for all such values of j in the range from 1 to num_bricks_minus1[i] (inclusive) where the value of brick_height_minus1[i - 1][j] exists.

[0175] A rem_brick_height_equal_flag[i][j] equal to 0 specifies that the bricks with indices in the range from 0 to j (inclusive) within the i-th tile column may or may not have equal heights in CTB units. A rem_brick_height_equal_flag[i][j] equal to 1 specifies that the bricks with indices in the range from 0 to j (inclusive) within the i-th tile column are presumed to have equal heights in CTB units. If it does not exist, the value of rem_brick_height_equal_flag[i][j] is presumed to be equal to 0.

[0176] brick_height_minus1[i][j] + 1 specifies the height of the j-th brick within the i-th tile column in CTB units.

[0177] The semantics of other syntax elements can be specified in exactly the same way as the semantics of the syntax elements with the same name in VVC Draft 5.

[0178] The decoding process can use variables defined as follows or similarly.

[0179] A list of i in the range from 0 to num_tile_columns_minus1 (inclusive), colWidth[i], which specifies the width of the i-th tile column in units of CTB, is derived as follows. for( i = num_tile_columns_minus1, remWidthInCtbsY = PicWidthInCtbsY; i > 0 &&!rem_tile_col_equal_flag[ i ]; remWidthInCtbsY -= tile_column_width_minus1[ i ] + 1, i-- ) if( !rem_tile_col_equal_flag[ i ] ) colWidth[ i ] = tile_column_width_minus1[ i ] + 1 if( i > 0 ) for( j = i; j >= 0; j-- ) colWidth[ j ] = remWidthInCtbsY / ( i + 1 ) else colWidth

[0000] = remWidthInCtbsY

[0180] A list colBrickHeight[i][j] for i in the range from 0 to num_tile_columns_minus1 (including both ends) and j in the range from 0 to num_bricks_minus1[i] (including both ends), specifying the height of the j-th brick row within the i-th tile column in CTB units, a list RowHeight[j] for j in the range from 0 to NumTileRows - 1 (including both ends), specifying the height of the j-th tile row in CTB units, a list tileRowBd[j] for j in the range from 0 to NumTileRows (including both ends), specifying the location of the j-th tile row boundary in CTB units, the value NumTileRows, and the value of NumTilesInPic are derived as follows. for( i = 0; i <= num_tile_columns_minus1; i++ ) { for( j = num_bricks_minus1[ i ], remHeightInCtbsY = PicHeightInCtbsY; j > 0 &&!rem_brick_height_equal[ i ][ j ]; remHeightInCtbsY -= brick_height_minus1[ i ][ j ] + 1, j-- ) if( !rem_brick_height_equal_flag[ i ][ j ] ) colBrickHeight[ i ][ j ] = brick_height_minus1[ i ][ j ] + 1 if( j > 0 ) for( k = j; k >= 0; k-- ) colBrickHeight[ i ][ j ] = remHeightInCtbsY / ( j + 1 ) else colBrickHeight[ i ]

[0000] = remHeightInCtbsY } for( i = 0, tileRow = 0, currBrickBd = colBrickHeight

[0000]

[0000] , tileRowBd

[0000] = 0; i <= num_bricks_minus1

[0000] ; i++, currBrickBd += colBrickHeight

[0000] [ i ] ) { tileCol = 1 matchingBdFlag = 1 while( tileCol <= num_tile_columns_minus1 && matchingBdFlag ) brickIdxInCol = 0 brickBdInCol = colBrickHeight[ tileCol ]

[0000] while( brickBdInCol < currBrickBd && brickIdxInCol <= num_bricks_minus1[ tileCol ] ) { brickIdxInCol++ brickBdInCol += colBrickHeight[ tileCol ][ brickIdxInCol ] } if( brickBdInCol == currBrickBd ) tileCol++ else matchingBdFlag = 0 } if( matchingBdFlag ) { tileRowBd[ tileRow + 1 ] = currBrickBd RowHeight[ tileRow ] = currBrickBd - tileRowBd[ tileRow ] tileRow++ } } NumTileRows = tileRow NumTilesInPic = NumTileRows * ( num_tile_columns_minus1 + 1 )

[0181] When single_tile_in_pic_flag is equal to 0, NumTilesInPic should be greater than 1. The list tileColBd[i] for i in the range from 0 to num_tile_columns_minus1+1 (inclusive), which specifies the location of the i-th tile column boundary in units of CTB, is derived as follows. for( tileColBd

[0000] = 0, i = 0; i <= num_tile_columns_minus1; i++ ) tileColBd[ i + 1 ] = tileColBd[ i ] + colWidth[ i ]

[0182] The variable NumBricksInPic that specifies the number of bricks in the picture referring to the PPS, the lists BrickColBd[brickIdx], BrickRowBd[brickIdx], BrickWidth[brickIdx], and BrickHeight[brickIdx] for brickIdx in the range from 0 to NumBricksInPic-1 (inclusive), which specify the location of the vertical brick boundary in units of CTB, the location of the horizontal brick boundary in units of CTB, the width of the brick column in units of CTB, and the height of the brick column in units of CTB respectively, are derived. For each i in the range 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 as follows. for( i =0;i <= num_tile_columns_minus1; i++ ) colBrickIdx[ i ] = 0 for ( brickIdx = 0, i = 0; i < NumTilesInPic; i++ ) { tileX = i % ( num_tile_columns_minus1 + 1 ) tileY = i / ( num_tile_columns_minus1 + 1 ) do { BrickColBd[ brickIdx ] = tileColBd[ tileX ] BrickRowBd[ brickIdx ] = colBrickBd[ colBrickIdx[ tileX ] ] BrickWidth[ brickIdx ] = colWidth[ tileX ] BrickHeight[ brickIdx ] = colBrickHeight[ colBrickIdx[ tileX ] ] colBrickIdx[ tileX ]++ brickIdx++ while( tileRowBd[ tileY + 1 ] <= colBrickBd[ colBrickIdx[ tileX ] ] ) } NumBricksInPic = brickIdx

[0183] According to one embodiment, a method for encoding includes: a) determining the number of units to be assigned to partitions; b) displaying or inferring the number of explicitly sized partitions to be assigned; c) displaying the size of the explicitly sized partitions or the number of units; and d) displaying or inferring the number of evenly sized partitions to be assigned.

[0184] According to one embodiment of the encoding, step d) includes: d1) displaying the number of units; d2) repeatedly assigning the number of units to partitions until the number of unassigned units is less than the number of units; and d3) if the number of unassigned units is greater than 0, assigning the unassigned units to the last partition in a predefined scan order.

[0185] Thus, an encoding method according to the above-described embodiment, which can be implemented independently or in combination with one or more of the embodiments described herein, is shown in FIG. 14a. This method includes determining (1400) the number of units to be assigned to partitions and initialized as unassigned, displaying or inferring (1402) the number of clearly sized partitions to be assigned, displaying the size of the clearly sized partitions, and accordingly marking (1404) the unassigned units to be assigned to the partitions in a predefined scan order, displaying (1406) the number of units, repeatedly assigning the number of units to partitions and accordingly marking (1408) the unassigned units to be assigned to the partitions in a predefined scan order until the number of unassigned units is less than the number of units, and if the number of unassigned units is greater than 0, assigning (1410) the unassigned units to the last partition.

[0186] According to one embodiment, a method for decoding includes: a) determining the number of units to be assigned to partitions; b) decoding or inferring the number of clearly sized partitions to be assigned; c) decoding the size of the clearly sized partitions or the number of units of the clearly sized partitions; and d) decoding or inferring the number of evenly sized partitions to be assigned.

[0187] According to one embodiment of the coding, step d) includes: d1) decoding the number of units; d2) repeatedly assigning a single number of units to a partition until the number of unassigned units is less than the number of units; and d3) if the number of unassigned units is greater than 0, assigning the unassigned units to the last partition in a predefined scan order.

[0188] Thus, the decoding method according to the above embodiment, which can be implemented independently or in combination with one or more of the embodiments described herein, is shown in FIG. 14b. This method includes determining (1450) the number of units to be assigned to a partition, determining (1452) the number of explicitly sized partitions to be assigned, determining the size of the explicitly sized partitions and, accordingly, marking (1454) the unassigned units to be assigned to the partitions in a predefined scan order, determining (1456) the number of units, repeatedly assigning the number of units to the partitions and, accordingly, marking (1458) the unassigned units to be assigned to the partitions in a predefined scan order until the number of unassigned units is less than the number of units, and if the number of unassigned units is greater than 0, assigning (1460) the unassigned units to the last partition.

[0189] According to one embodiment of the encoding and / or decoding, this method includes - initially marking the number of units as unassigned, that is, initially marking the number of units as unassigned, for example, as part of or in relation to step a). - Mark unassigned units to be assigned, for example, as part of step b) and / or c) or in relation to step b) and / or c), according to the number of clearly sized partitions to be assigned and the sizes of the clearly sized partitions. - Further include marking unassigned units to be assigned, for example, as part of step d2) or in relation to step d2), each time a count unit is assigned to a partition.

[0190] Assigning units to partitions and / or marking unassigned units to be assigned can be done according to the scanning order. In one embodiment, the scanning order is predefined, for example, by a coding standard. The scanning order can be, for example, from left to right (e.g., for assigning CTU columns to tile columns) or from top to bottom (e.g., for assigning CTU rows to tile rows or CTU rows within a tile to blocks). In one embodiment, the encoder selects the scanning order from a list of predefined scanning orders and indicates the selected scanning order in or along the bitstream, for example, as an index to the list of predefined scanning orders. In one embodiment, the decoder decodes the scanning order, for example, an index to the list of predefined scanning orders, from or along the bitstream.

[0191] According to one embodiment of encoding and / or decoding, step c) further includes or is followed by the step of assigning the size or number of units to the clearly sized partitions.

[0192] The size of the clearly sized partition can be represented as the number of units to be assigned.

[0193] According to one embodiment applicable to encoding and / or decoding, the unit is one of the following, namely, CTB, CTU, CTU row, CTU column, grid cell (of the grid used to display sub-picture partitioning), grid row (of the grid used to display sub-picture partitioning), grid column (of the grid used to display sub-picture partitioning).

[0194] In embodiments of encoding and / or decoding, information regarding units not yet assigned to a partition can be maintained. Immediately after determining the number of units to be assigned to a partition, all units can be marked as unassigned. When a set of units is assigned to a partition, the set of units can be marked as assigned, or marking the set of units as "unassigned" can be removed or cancelled. Marking a unit as assigned or unassigned is represented, for example, by an array variable, and each unit to be assigned is represented by an entry in the array, and the value of the entry in the array indicates whether the corresponding unit has been assigned. In another example, the number of units not yet assigned, i.e., the number of remaining unassigned units, is maintained throughout the steps of the embodiment.

[0195] According to one embodiment applicable to encoding and / or decoding, the number of units to be assigned to a partition is one of the following, namely, the picture width in CTU units (e.g., when the partition is a tile column), the picture height in CTU units (e.g., when the partition is a tile row, or when the partition is a block row displayed at once for one or more complete tile columns), the number of CTU rows of a tile (e.g., when the partition is a tile block), the picture width of a grid column (of the grid used to display sub-picture partitioning), the picture height of a grid row (of the grid used to display sub-picture partitioning).

[0196] According to one embodiment applicable to encoding and / or decoding, a partition is one or more of the following, namely, a tile column, a tile row, a block row, a grid column (of the grid used to display sub-picture partitioning), a grid row (of the grid used to display sub-picture partitioning).

[0197] According to one embodiment applicable to encoding and / or decoding in which step d includes steps d1, d2, and d3 as described above, the following syntax or the like can be used.

[0198] [Table 6]

[0199] num_exp_tile_columns_minus1 + 1 specifies the number of explicitly provided tile column widths.

[0200] num_exp_tile_rows_minus1 + 1 specifies the number of explicitly provided tile row heights.

[0201] tile_column_width_minus1[i] + 1 specifies the width of the i-th tile column in units of CTBs for i in the range from 0 to num_exp_tile_columns_minus1 - 1 (inclusive). tile_column_width_minus1[num_exp_tile_columns_minus1] is used to derive the width of tile columns with indices greater than or equal to num_exp_tile_columns_minus1.

[0202] tile_row_height_minus1[i] + 1 specifies the height of the i-th tile row in units of CTBs for i in the range from 0 to num_exp_tile_rows_minus1 - 1 (inclusive). tile_row_height_minus1[num_exp_tile_rows_minus1] is used to derive the height of tile rows with indices greater than or equal to num_exp_tile_rows_minus1.

[0203] The brick_splitting_present_flag and brick_spit_flag[i] can be specified as described previously.

[0204] NumTilesInPic can be assumed to be equal to the number of tiles in the picture. NumTileColumns can be assumed to be equal to the number of tile columns in the picture. RowHeight[tileY] can be assumed to be equal to the number of CTU rows in the tileY-th tile row.

[0205] num_exp_brick_rows_minus1[i] + 1 specifies the number of explicitly provided brick row heights for the i-th tile. If not present, the value of num_exp_brick_rows_minus1[i] can be assumed to be equal to -1.

[0206] brick_row_height_minus1[i][j]+1 specifies the height of the j-th brick of the i-th tile in CTB units for j in the range from 0 to num_exp_brick_rows_minus1[i]-1 (inclusive). brick_row_height_minus1[i][num_exp_brick_rows_minus1] is used to derive the height of brick rows with indices greater than or equal to num_exp_brick_rows_minus1[i] of the i-th tile.

[0207] According to an exemplary embodiment that uses the above syntax to encode (or, respectively, to decode, as indicated in parentheses below), a tile column is specified as follows. - The number of explicitly provided tile column widths is indicated (or decoded) (num_exp_tile_columns_minus1). - The tile column widths are provided (or decoded and assigned) explicitly from left to right (tile_column_width_minus1[i]). - The last explicitly provided (or decoded) tile column width (tile_column_width_minus1[num_exp_tile_columns_minus1]) is repeated until additional tile columns of that width no longer fit within the picture boundary. - The remaining CTUs not yet assigned to a tile column are assigned to the rightmost tile column, if any.

[0208] Tile row heights and brick rows are specified in the same way as tile rows.

[0209] According to one embodiment applicable to the above syntax and encoding and / or decoding, a variable numTileColumns that specifies the number of tile columns, and a list colWidth[i] for i in the range from 0 to numTileColumns - 1 (including both ends) that specifies the width of the i-th tile column in units of CTBs are derived as follows. remainingWidthInCtbsY = PicWidthInCtbsY for( i = 0; i < num_exp_tile_columns_minus1; i++ ) { colWidth[ i ] = tile_column_width_minus1[ i ] + 1 remainingWidthInCtbsY -= colWidth[ i ] } uniformTileColWidth = tile_column_width_minus1[ num_exp_tile_columns_minus1 ] + 1 while( remainingWidthInCtbsY >= uniformTileColWidth ) { colWidth[ i++ ] = uniformTileColWidth remainingWidthInCtbsY -= uniformTileColWidth } if( remainingWidthInCtbsY > 0 ) colWidth[ i++ ] = remainingWidthInCtbsY numTileColumns = i

[0210] According to one embodiment applicable to the above syntax and encoding and / or decoding, the variable numTileRows that specifies the number of tile rows, and the list RowHeight[j] for j in the range from 0 to numTileRows - 1 (both ends included) that specifies the height of the j-th tile row in units of CTBs, are derived as follows. remainingHeightInCtbsY = PicHeightInCtbsY for( j = 0; j < num_exp_tile_rows_minus1; j++ ) { RowHeight[ j ] = tile_row_height_minus1[ j ] + 1 remainingHeightInCtbsY -= RowHeight[ j ] } uniformTileRowHeight = tile_row_height_minus1[ num_exp_tile_rows_minus1 ] + 1 while( remainingHeightInCtbsY >= uniformTileRowHeight ) { RowHeight[ j++ ] = uniformTileRowHeight remainingHeightInCtbsY -= uniformTileRowHeight } if( remainingHeightInCtbsY > 0 ) RowHeight[ j++ ] = remainingHeightInCtbsY numTileRows = j

[0211] In some embodiments, the following may apply. - The variable NumTilesInPic is set equal to numTileColumns * numTileRows. - The list tileColBd[i] for i in the range from 0 to numTileColumns (inclusive), which specifies the location of the i-th tile column boundary in units of CTB, is derived as follows. for( tileColBd

[0000] = 0, i = 0; i < numTileColumns; i++ ) tileColBd[ i + 1 ] = tileColBd[ i ] + colWidth[ i ] - The list tileRowBd[j] for j in the range from 0 to numTileRows (inclusive), which specifies the location of the j-th tile row boundary in units of CTB, is derived as follows. for( tileRowBd

[0000] = 0, j = 0; j < numTileRows; j++ ) tileRowBd[ j + 1 ] = tileRowBd[ j ] + RowHeight[ j ]

[0212] According to one embodiment applicable to the above syntax and encoding and / or decoding, a variable NumBricksInPic that specifies the number of bricks in a picture that references the PPS, lists BrickColBd[brickIdx], BrickRowBd[brickIdx], BrickWidth[brickIdx], and BrickHeight[brickIdx] for brickIdx in the range from 0 to NumBricksInPic - 1 (inclusive), which specify the location of the vertical brick boundary in units of CTB, the location of the horizontal brick boundary in units of CTB, the width of the brick in units of CTB, and the height of the brick in units of CTB, respectively, are derived as follows. for ( brickIdx = 0, i = 0; i < NumTilesInPic; i++ ) { tileX = i % numTileColumns tileY = i / numTileColumns if( !brick_split_flag[ i ] ) { BrickColBd[ brickIdx ] = tileColBd[ tileX ] BrickRowBd[ brickIdx ] = tileRowBd[ tileY ] BrickWidth[ brickIdx ] = colWidth[ tileX ] BrickHeight[ brickIdx ] = RowHeight[ tileY ] brickIdx++ } else { if( RowHeight[ tileY ] == 2 ) { rowHeight2

[0000] = rowHeight2

[0001] = 1 numBrickRows[ i ] = 2 } else { remainingHeightInCtbsY = RowHeight[ tileY ] for( j = 0; j < num_exp_brick_rows_minus1[ i ]; j++ ) { rowHeight2[ j ] = brick_row_height_minus1[ i ][ j ] + 1 remainingHeightInCtbsY -= rowHeight2[ j ] } uniformBrickRowHeight = brick_row_height_minus1[ i ][ num_exp_brick_rows_minus1 ] + 1 while( remainingHeightInCtbsY >= uniformBrickRowHeight ) { rowHeight2[ j++ ] = uniformBrickRowHeight remainingHeightInCtbsY -= uniformBrickRowHeight} if( remainingHeightInCtbsY > 0 ) rowHeight2[ j++ ] = remainingHeightInCtbsY numBrickRows[ i ] = j } for( rowBd2

[0000] = 0, j = 0; j < numBrickRows[ i ]; j++ ) rowBd2[ j + 1 ] = rowBd2[ j ] + rowHeight2[ j ] for( j = 0; j < numBrickRows[ i ]; j++ ) { BrickColBd[ brickIdx ] = tileColBd[ tileX ] BrickRowBd[ brickIdx ] = tileRowBd[ tileY ] + rowBd2[ j ] BrickWidth[ brickIdx ] = colWidth[ tileX ] BrickHeight[ brickIdx ] = rowHeight2[ j ] brickIdx++ } } } NumBricksInPic = brickIdx

[0213] According to one embodiment applicable to encoding and / or decoding, step d includes determining the number of units not yet assigned to a partition by reducing the number of units of a partition that is explicitly sized from the number of units to be assigned to the partition, and the method - assigning partitions to the explicitly sized partitions according to the unit size or number in the explicitly sized partitions and according to a predefined or displayed / decoded scan order, and - further comprising dividing units not yet assigned to partitions by the number of evenly sized partitions and assigning partitions to the evenly sized partitions according to a predefined and / or indicated / decoded scan order.

[0214] According to one embodiment applicable to encoding and / or decoding, the number of clearly sized partitions is indicated and / or decoded in a higher level syntax structure (e.g., SPS), while the size of the clearly sized partitions and / or the number of evenly sized partitions to be assigned can be indicated and / or decoded from a lower level syntax structure (e.g., PPS).

[0215] According to one embodiment, it is presumed that the number of clearly sized partitions is equal to 1 (e.g., predetermined in a coding standard).

[0216] According to one embodiment applicable to encoding and / or decoding, step d is - determining a set or list of partition sizes that can evenly divide the number of units not yet assigned, - presuming that the number of evenly sized partitions is equal to 1 if the number of items in the set or list is equal to 1, and - indicating and / or decoding an index (etc.) corresponding to an item in the set or list, where the index indicates the number of evenly sized partitions to be assigned.

[0217] According to one embodiment applicable to encoding and / or decoding, a set or list of partition sizes that can evenly divide the number of yet unassigned units is regulated by excluding partition sizes smaller than a threshold value, which can be predefined, for example, in a coding standard or can be presented / decoded. For example, the minimum tile column width of a CTU unit can be predefined or can be presented / decoded.

[0218] According to one embodiment, an index corresponding to an item of the set or list is coded with a fixed-length codeword, for example, u(v), and the length of the codeword is determined by the number of items of the set or list.

[0219] Indication of whether the boundary of a tile row is a potential tile row boundary In some embodiments, when horizontal block boundaries are aligned across a picture, a tile row boundary is inferred. This section presents one embodiment for signaling a tile row boundary. This embodiment can be applied together with an embodiment where a block boundary is presented in the syntax before a tile row boundary.

[0220] An embodiment can include one or more of the following steps (some of which have already been described previously). - A potential tile row boundary is inferred as a boundary where block boundaries are aligned (horizontally) through the picture. - Whether all aligned block boundaries form a tile row boundary is inferred by an encoder in and / or along the bitstream and / or decoded by a decoder from and / or along the bitstream. For example, a flag of the bitstream syntax can be used. - If not all aligned brick boundaries form tile row boundaries, for each aligned brick boundary, whether that boundary is a tile row boundary is indicated by the encoder in or along the bitstream and / or decoded by the decoder from or along the bitstream. For example, for each aligned brick boundary (except for aligned brick boundaries that are picture boundaries), a flag may be present in the bitstream syntax.

[0221] For example, the following syntax can be used.

[0222]

Table 7

[0223] NumAlignedBrickRows can be derived like NumTileRows in another embodiment.

[0224] The semantics of the presented syntax elements can be specified as follows.

[0225] An explicit_tile_rows_flag equal to 0 specifies that tile row boundaries are inferred each time a horizontal brick boundary is aligned across a picture. An explicit_tile_rows_flag equal to 1 specifies that the tile_row_flag[i] syntax element is present.

[0226] A tile_row_flag[i] equal to 0 specifies that the i-th such horizontal boundary where the horizontal brick boundary is aligned across the picture is not a tile row boundary. A tile_row_flag[i] equal to 1 specifies that the i-th such horizontal boundary where the horizontal brick boundary is aligned across the picture is a tile row boundary. The 0-th such horizontal boundary where the horizontal brick boundary is aligned across the picture is the top boundary of the picture.

[0227] Display of a tile sequence to be partitioned in exactly the same way as bricks In some exemplary embodiments, the syntax includes a display that the tile sequence is partitioned into bricks in exactly the same way as the previous tile sequence in loop entry order (e.g., scanning the tile sequence from left to right). It should be understood that the embodiments are equally applicable without the display or a similar display. For example, the scan order of the tile sequence can be from right to left, and as a result, the brick partitioning of the current tile sequence can be displayed as being copied from the tile sequence on the right. In another example, it is displayed or inferred that all tile sequences having equal widths have the same brick partitioning. In yet another example, the index of the tile sequence from which the brick partitioning is copied is displayed. It should also be understood that the embodiments are equally applicable if another method of determining the partitioning of the tile sequence into bricks is based on the previous display. This section presents some related embodiments.

[0228] In one embodiment, the encoder indicates in or along the bitstream whether all tile sequences having the same width (e.g., in CTB) have the same partitioning into bricks, and / or the decoder decodes from or along the bitstream. For example, a syntax element called same_brick_spacing_in_equally_wide_tile_cols_flag can be used.

[0229] In one embodiment, the encoder displays and / or the decoder decodes, in or along a bitstream, the number of adjacent tile columns in loop entry order (e.g., scanning tile columns from left to right) having the same brick partitioning. For example, a syntax element sometimes called num_tile_cols_with_same_brick_partitioning_minus1[i] can be u(v)-coded, where v is determined by the remaining tile columns for which the brick partitioning has not yet been displayed.

[0230] In one embodiment, the encoder indicates in or along the bitstream whether there is a syntax element (e.g., copy_previous_col_flag[i]) related to the indication that the tile columns are partitioned in exactly the same way as the blocks, and / or the decoder decodes from or along the bitstream. In one embodiment, the indication is a sequence level syntax structure such as an SPS. In another embodiment, the indication is a picture level syntax structure such as a PPS. In one embodiment, due to the absence of a syntax element related to the indication that the tile columns are partitioned in exactly the same way as the blocks, the block partitioning is, for example, pre-defined in the coding standard to be indicated and / or decoded one by one for all tile columns. In one embodiment, due to the absence of a syntax element related to the indication that the tile columns are partitioned in exactly the same way as the blocks, the block partitioning is indicated and / or decoded for one tile column and is assumed to be the same for all tile columns. In one embodiment, a method for handling the absence of a syntax element related to the indication that the tile columns are partitioned in exactly the same way as the blocks is indicated by the encoder in or along the bitstream, e.g., in the SPS, and / or decoded by the decoder from or along the bitstream, e.g., based on the SPS. This method can be indicated and / or decoded within a pre-defined set of processes, which can include, but are not limited to, i) block partitioning that is indicated and / or decoded one by one for all tile columns, and ii) block partitioning that is indicated and / or decoded for one tile column and is assumed to be the same for all tile columns.

[0231] In some embodiments, the number of units to be assigned to partitions is determined or estimated. The number of units is, for example, the number of CTU columns in a picture, the number of CTU rows in a picture, or the number of CTU rows in a tile. In decoding, the number of units to be assigned to partitions can be decoded based on the SPS and / or PPS. In some embodiments, it may be desirable to avoid parsing the syntax structure and dependencies between all syntax elements included in the same syntax structure, such as PPS, etc., that are sufficient to estimate the number of units. For example, the picture width of luma samples, the picture height of luma samples, and the CTU size can be included in the PPS, thereby enabling the estimation of the number of CTU columns and the number of CTU rows in the picture.

[0232] For example, the u(2)-coded syntax element log2_pps_ctu_size_minus5 can be included in the PPS. log2_pps_ctu_size_minus5 + 5 specifies the luma coding tree block size of each CTU. log2_pps_ctu_size_minus5 equal to 0, 1, or 2 specifies that the luma coding tree block size of each CTU is equal to 32×32, 64×64, or 128×128 luma samples, respectively. It may be required that log2_pps_ctu_size_minus5 be less than or equal to 2. It may be required that log2_pps_ctu_size_minus5 be equal to log2_ctu_size_minus5 specified in the SPS.

[0233] Display of sub-picture partitioning Note that many of the described embodiments for displaying slices, tiles, and / or brick partitioning are independent of how the sub-pictures are displayed. This section presents embodiments for displaying and / or decoding the partitioning of a picture into sub-pictures. Many of the embodiments in this section can be used independently of other embodiments, for example, to display slices, tiles, and / or brick partitioning, but this is not necessary.

[0234] According to one embodiment, the grid used for signaling sub-picture partitioning is displayed in or along the bitstream (e.g., in the SPS) or decoded from or along the bitstream (e.g., based on the SPS). The cells of the grid specify units according to which sub-picture boundaries are signaled. In other words, the sub-picture boundaries can only be placed at the boundaries of the displayed grid.

[0235] According to one embodiment, the grid is displayed and / or decoded in units of CTUs (or similar basic coding blocks of the codec).

[0236] According to one embodiment, the signaling includes providing information indicating the number of grid columns, the number of grid rows, the width of the grid columns (e.g., as the number of CTUs), and the height of the grid rows (e.g., as the number of CTUs). For example, the following syntax can be used.

[0237] [Table 8]

[0238] num_id_columns_minus1 specifies the number obtained by subtracting 1 from the number of columns for partitioning the picture. num_id_rows_minus1 specifies the number obtained by subtracting 1 from the number of rows for partitioning the picture. id_column_width_minus1[i] + 1 specifies the width of the i-th column in units of the coding tree block. id_row_height_minus1[i] + 1 specifies the height of the i-th row in units of the coding tree block. It can be inferred that the rightmost grid column consists of columns of coding tree blocks that cannot be assigned to other grid columns. It can be inferred that the bottommost grid row consists of coding tree blocks that cannot be assigned to other grid rows.

[0239] According to another example, the following syntax can be used.

[0240]

Table 9

[0241] When the above signal notification is used, all grid columns have equal widths, except for the rightmost grid column which can be inferred to consist of columns of coding tree blocks that cannot be assigned to other grid columns in some cases. All grid rows have equal heights, except for the bottommost grid row which can be inferred to consist of coding tree blocks that cannot be assigned to other grid rows in some cases. id_column_width_minus1 + 1 specifies the width of the grid column in units of the coding tree block. id_row_height_minus1 + 1 specifies the height of the grid row in units of the coding tree block.

[0242] According to one embodiment, the assignment of grid cells to sub-pictures is displayed in or along the bitstream (e.g., in the SPS) and / or decoded from or along the bitstream (e.g., based on the SPS).

[0243] In one embodiment, the assignment of grid cells to sub-pictures is indicated and / or decoded by a bottom-right grid cell index for each sub-picture (except for the last sub-picture where the bottom-right grid cell may be assumed to be the bottom-right grid cell of the grid). For example, the following syntax etc. can be used (and is considered to be added after the syntax presented above etc. or a similar syntax).

[0244] [Table 10]

[0245] num_subpics_minus2 + 2 specifies the number of sub - pictures within a picture. bottom_right_grid_idx_length - minus1 + 1 specifies the number of bits used to represent the syntax element bottom_right_grid_idx_delta[i]. When i is greater than 0, bottom_right_grid_idx_delta[i] specifies the difference between the grid index of the grid cell placed at the bottom - right corner of the i - th sub - picture and the grid index of the bottom - right corner of the (i - 1)-th sub - picture. bottom_right_grid_idx_delta[0] specifies the grid index of the bottom - right corner of the 0 - th sub - picture. The bottom - right corner of the last sub - picture is assumed to be the bottom - right cell of the grid. grid_idx_delta_sign_flag[i] equal to 1 indicates the positive sign of bottom_right_grid_idx_delta[i]. sign_bottom_right_grid_idx_delta[i] equal to 0 indicates the negative sign of bottom_right_grid_idx_delta[i]. The variables NumGridRows, NumGridCols, and NumGridCellsInPic can be assumed to be equal to the number of grid rows, grid columns, and grid cells within the picture, respectively. The variables TopLeftGridIdx[i], BottomRightGridIdx[i], NumGridCellsInSubpic[i], and GridCellsToSubpicMap[j] that specify the grid index of the grid cell placed at the top - left corner of the i - th sub - picture, the grid index of the grid cell placed at the bottom - right corner of the i - th sub - picture, the number of grid cells within the i - th sub - picture, and the mapping of grid cells to sub - pictures are derived as follows. for( j = 0; i == 0 && j < NumGridCellsInPic; j++ ) GridCellsToSubpicMap[ j ] = -1 NumGridCellsInSubPic[ i ] = 0 BottomRightGridIdx[ i ] = bottom_right_grid_idx_delta[ i ] ] +( ( i == 0 ) ? 0 : ( grid_idx_delta_sign_flag[ i ] ? BottomRightGridIdx[ i - 1 ] : -BottomRightGridIdx[ i-1 ] ) for( j = BottomRightGridIdx[ i ]; j >= 0; j-- ) { gridCol = j % NumGridCols; gridRow = j / NumGridCols; if( gridCol <= BottomRightGridIdx[ i ] ] % NumGridCols && gridRow <= BottomRightGridIdx[ i ] ] / NumGridCols && GridCellsToSubpicMap[ j ] == -1 ) { TopLeftGridIdx[ i ] = j NumGridCellsInSubpic[ i ]++ GridCellsToSubpicMap[ j ] = i } }

[0246] Display of tile partitioning as splitting of subpicture partitioning According to one embodiment that can be used together with or independently of other embodiments, the partitioning of a picture into sub-pictures is indicated in and / or along the bitstream, for example, in the SPS, and / or decoded from and / or along the bitstream, for example, based on the SPS, and the partitioning into tile columns, tile rows, and / or bricks is indicated in and / or along the bitstream, for example, in the PPS, and / or decoded from and / or along the bitstream, for example, based on the PPS, based on the sub-picture partitioning.

[0247] According to one embodiment, as follows, the encoder displays tile column boundaries in or along the bitstream, and / or the decoder decodes tile column boundaries from or along the bitstream. Since the vertical boundaries of rectangular slices coincide with the tile column boundaries, and since the sub-pictures consist of one or more entire rectangular slices, it can be determined that the tile column boundaries coincide with the vertical boundaries of the sub-pictures. Therefore, the vertical sub-picture boundaries are obtained (e.g., by the encoder) or decoded (e.g., by the decoder) and are determined to be the tile column boundaries. In addition, the encoder indicates in or along the bitstream, e.g., in the PPS, whether there are additional tile column boundaries (in addition to those determined from the vertical sub-picture boundaries), and / or the decoder decodes from or along the bitstream, e.g., based on the PPS. For example, the tile_col_splitting_present_flag can be indicated in or along the bitstream (e.g., by the encoder) and / or decoded from or along the bitstream (e.g., by the decoder). A tile_col_splitting_present_flag equal to 0 specifies that the tile column boundaries are the same as the obtained or decoded vertical sub-picture boundaries. A tile_col_splitting_present_flag equal to 1 specifies that there are additional tile columns in addition to those determined from the vertical sub-picture boundaries.

[0248] In one embodiment, when the encoder indicates (in addition to what is determined from the vertical sub-picture boundaries) that there are additional tile column boundaries in the bitstream or along it, for example, in the PPS, and / or when the decoder decodes from the bitstream or along it, for example, based on the PPS, the following applies. The vertical sub-picture boundaries that are not picture boundaries are ordered, for example, from left to right and indexed from 0 to NumSubPicCols - 2 (both ends included), where NumSubPicCols is the number of distinct vertical sub-picture boundaries that are not picture boundaries. The i-th sub-picture column can be defined to be bounded on the left by the right boundary of the (i - 1)-th sub-picture column if i is greater than 0 or by the left picture boundary if i is equal to 0, and on the right by the i-th sub-picture boundary if i is less than NumSubPicCols - 1 or by the right picture boundary if i is equal to NumSubPicCols - 1. Whether a sub-picture column is split into two or more tile columns is indicated by the encoder in the bitstream or along it, for example, in the PPS, and / or decoded by the decoder from the bitstream or along it, for example, based on the PPS. For example, tile_col_split_flag[i] can be indicated (e.g., by the encoder) in the bitstream or along it for each sub-picture column and / or decoded (e.g., by the decoder) from the bitstream or along it. A tile_col_split_flag[i] equal to 0 specifies that the i-th sub-picture column consists of exactly one tile column. A tile_col_split_flag[i] equal to 1 specifies that the i-th sub-picture column consists of two or more tile columns.

[0249] In one embodiment, when the encoder indicates in or along the bitstream, e.g., in the PPS, that the sub-picture column is split into two or more tile columns, and / or when the decoder decodes from or along the bitstream, e.g., based on the PPS, the tile columns within the sub-picture column are displayed in the same manner as in the draft VVC standard or any presented embodiment. For example, a syntax element indicating the number of tile columns within the sub-picture column can be indicated by the encoder in or along the bitstream, and / or can be decoded by the decoder from or along the bitstream. For example, the num_tile_cols_minus2[i] syntax element can be used, where num_tile_cols_minus2[i] + 2 specifies the number of tile columns in the i-th sub-picture column. The width of each tile column within the sub-picture column is indicated in or along the bitstream and / or decoded from or along the bitstream (except for the last tile column of the sub-picture column, whose width can be assumed to include all the remaining unallocated regions of the sub-picture). For example, tile_col_width_minus1[i][j] can be used, where tile_col_width_minus1[i][j] + 1 specifies the width of the j-th tile column in the i-th sub-picture column in units of CTUs.

[0250] The above embodiments can use, for example, the following syntax.

[0251] [Table 11]

[0252] According to one embodiment, as follows, the encoder displays tile row boundaries in or along the bitstream, and / or the decoder decodes tile row boundaries from or along the bitstream. The horizontal sub-picture boundaries can be arranged together with either the tile row boundaries or the block boundaries within the tile. Thus, the horizontal sub-picture boundaries are obtained (e.g., by the encoder) or decoded (e.g., by the decoder) and are determined to be either tile row boundaries or block boundaries.

[0253] In one embodiment, the encoder displays in or along the bitstream, e.g., in the PPS, whether the tile row boundaries match the horizontal sub-picture boundaries one-to-one (and vice versa), or whether there are additional tile row boundaries, or whether some of the horizontal sub-picture boundaries are block boundaries within the tile, and / or the decoder decodes from or along the bitstream, e.g., based on the PPS. For example, the tile_row_splitting_present_flag can be displayed in or along the bitstream (e.g., by the encoder) and / or decoded from or along the bitstream (e.g., by the decoder). A tile_row_splitting_present_flag equal to 0 specifies that the tile row boundaries are the same as the obtained or decoded horizontal sub-picture boundaries. A tile_col_splitting_present_flag equal to 1 specifies that there are additional tile rows in addition to those determined from the horizontal sub-picture boundaries, or that some of the horizontal sub-picture boundaries are block boundaries within the tile.

[0254] In one embodiment, the following applies when the encoder indicates in or along the bitstream, e.g., in the PPS, that there is an additional tile row boundary (in addition to those determined from the horizontal sub-picture boundaries), or that some of the horizontal sub-picture boundaries are block boundaries within a tile, and / or when the decoder decodes from or along the bitstream, e.g., based on the PPS. Horizontal sub-picture boundaries that are not picture boundaries are, for example, ordered from top to bottom and indexed from 0 to NumSubPicRows - 2 (inclusive), where NumSubPicRows is the number of distinct horizontal sub-picture boundaries that are not picture boundaries. The i-th sub-picture row can be defined to be bounded at the top by the lower boundary of the (i - 1)-th sub-picture row if i is greater than 0, or by the upper picture boundary if i is equal to 0, and at the bottom by the i-th sub-picture boundary if i is less than NumSubPicRows - 1, or by the lower picture boundary if i is equal to NumSubPicRows - 1. Whether a sub-picture row boundary is a tile row boundary or a block boundary is indicated by the encoder in or along the bitstream, e.g., in the PPS, and / or decoded by the decoder from or along the bitstream, e.g., based on the PPS. For example, tile_row_flag[i] can be indicated in or along the bitstream (e.g., by the encoder) for each sub-picture row, and / or decoded from or along the bitstream (e.g., by the decoder). A tile_row_flag[i] equal to 0 specifies that the i-th sub-picture row boundary is a block boundary within a tile. A tile_row_flag[i] equal to 1 specifies that the i-th sub-picture row boundary is a tile row boundary.Whether a sub-picture row contains data of two or more tile rows is indicated by the encoder in or along the bitstream, e.g., in the PPS, and / or decoded by the decoder from or along the bitstream, e.g., based on the PPS. For example, tile_row_split_flag[i] can be indicated in or along the bitstream (e.g., by the encoder) for each sub-picture row and / or decoded from or along the bitstream (e.g., by the decoder). A tile_row_split_flag[i] equal to 0 specifies that the i-th sub-picture row contains data of one tile row. A tile_row_split_flag[i] equal to 1 specifies that the i-th sub-picture row contains data of two or more tile rows.

[0255] In one embodiment, when the encoder indicates in or along the bitstream, e.g., in the PPS, that a sub-picture row contains data of two or more tile rows, and / or when the decoder decodes from or along the bitstream, e.g., based on the PPS, the tile rows within the sub-picture row are displayed as in the draft VVC standard or any presented embodiment. For example, a syntax element indicating the number of tile row boundaries within a sub-picture row can be indicated by the encoder in or along the bitstream, and / or can be decoded by the decoder from or along the bitstream. For example, the num_tile_rows_minus2[i] syntax element can be used, where num_tile_rows_minus2[i] + 2 specifies the number of tile row boundaries of the i-th sub-picture row. The height of each tile row within a sub-picture row is indicated in or along the bitstream, and / or decoded from or along the bitstream (except for the last tile row of the sub-picture row, whose height can be inferred to include all remaining unallocated areas of the sub-picture up to the next sub-picture row or the next tile row boundary within it, depending on the value of tile_row_flag[j] for j > i). For example, tile_row_height_minus1[i][j] can be used, where tile_row_height_minus1[i][j] + 1 specifies the height of the j-th tile row within the i-th sub-picture row in units of CTUs.

[0256] The above embodiments can use, for example, the following syntax.

[0257] [Table 12]

[0258] According to one embodiment of the encoding and / or decoding, if the sub-picture boundaries do not align with the tile row boundaries, the brick boundaries are presumed to align with the sub-picture boundaries. The encoder indicates in and / or along the bitstream, e.g., in the PPS, whether there are additional bricks (in addition to those determined from the sub-picture boundaries), and / or the decoder decodes from and / or along the bitstream, e.g., based on the PPS. For example, the brick_splitting_present_flag can be indicated in and / or along the bitstream (e.g., by the encoder), and / or decoded from and / or along the bitstream (e.g., by the decoder). The variable NumInferredBricksInPic is set according to the number of bricks inferred from the number of tiles in the displayed tile grid and further splitting of the tiles along the inferred brick boundaries. A brick_splitting_present_flag equal to 0 specifies that there are no brick boundaries other than those inferred from the sub-picture boundaries. A brick_splitting_present_flag equal to 1 specifies that there are brick boundaries not inferred from the sub-picture boundaries (i.e., the number of bricks is more than NumInferredBricksInPic).

[0259] In one embodiment, when an encoder indicates in or along the bitstream, e.g., in the PPS, that there is a block boundary that is not inferred from the sub-picture boundary and / or a decoder decodes from or along the bitstream, e.g., based on the PPS, the following applies. The inferred blocks can be indexed in a predefined scanning order. Whether an inferred candidate block is split into two or more blocks is indicated by the encoder in or along the bitstream, e.g., in the PPS, and / or decoded by the decoder from or along the bitstream, e.g., based on the PPS. For example, brick_split_flag[i] can be indicated in or along the bitstream (e.g., by the encoder) for each inferred candidate block and / or decoded from or along the bitstream (e.g., by the decoder). brick_split_flag[i] equal to 0 specifies that the i-th inferred candidate block consists of exactly one block. brick_split_flag[i] equal to 1 specifies that the i-th inferred candidate block consists of two or more blocks.

[0260] The above-described embodiments can use, for example, the following syntax.

[0261] [Table 13]

[0262] In one embodiment, when the encoder indicates in or along the bitstream, e.g., in the PPS, that a hypothesized candidate block is split into two or more blocks, and / or when the decoder decodes from or along the bitstream, e.g., based on the PPS, further splitting of the hypothesized candidate block is indicated in or along the bitstream (e.g., by the encoder) and / or decoded from or along the bitstream (e.g., by the decoder) as in the draft VVC standard or any presented embodiment. For example, a syntax element indicating the number of blocks within a hypothesized candidate block can be indicated by the encoder in or along the bitstream and / or decoded by the decoder from or along the bitstream. For example, the num_bricks_minus2[i] syntax element can be used, where num_bricks_minus2[i]+2 specifies the number of blocks within the i-th hypothesized candidate block. The height of each block within a hypothesized candidate block is indicated in or along the bitstream and / or decoded from or along the bitstream (except for the last block of the hypothesized candidate block, whose width can be assumed to include all remaining unallocated regions of the hypothesized candidate block). For example, brick_row_height_minus1[i][j] can be used, where brick_row_height_minus1[i][j]+1 specifies the height of the j-th block within the i-th hypothesized candidate block in units of CTUs.

[0263] Accordingly, the syntax and semantics for signaling tile and block partitioning according to an embodiment significantly save the number of syntax elements and syntax rows required to perform the signaling. As a result, the number of bits required to represent tile and block partitioning is significantly saved.

[0264] These advantages are illustrated in the following examples, and three different tiles and brick partitionings shown in FIGS. 10a, 10b, and 10c are used to compare the performance of the tile and brick partitioning according to VVC draft 5 and the tile and brick partitioning according to some embodiments.

[0265] FIGS. 10a and 10b present tile and brick partitionings that achieve the 6K effective equirectangular projection (ERP) scheme and the cubemap projection (CMP) scheme (respectively) described in clauses D.6.3 and D.6.4 (respectively) of the Omnidirectional Media Format (OMAF, ISO / IEC 23090-2). These schemes are recommended in the VR industry forum guidelines. The scheme presented in FIG. 10c is, in another way, equivalent to the scheme of FIG. 10b but uses a different picture aspect ratio.

[0266] The following properties are derived from embodiments that combine both VVC draft 5 and the display of tile columns and brick heights per tile column with a unified signaling of explicit / uniform tile / brick partitioning. - The number of syntax elements for displaying tile and brick partitioning - The number of syntax lines for displaying tile and brick partitioning - The number of bits required to display the tile and brick partitioning of the schemes included in the following figures - The bit savings in percentage provided by the embodiments when compared to VVC draft 5 for the schemes presented in the following figures.

[0267] The properties derived with a 128×128 luma CTB size are presented in the following table.

[0268]

Table 14

[0269] As a result, it can be seen that the number of syntax elements decreases from 13 to 7, and the number of required syntax lines decreases from 26 to 20. The bit savings provided by the embodiment for each of the tiles and brick partitionings of FIGS. 10a to 10c exceeds 50% when compared to VVC draft 5. It should also be noted that this proposal also makes the semantics and the derivation process shorter.

[0270] Display of uncoded tiles or bricks In some applications, it may be reasonable to allocate the content to be encoded and / or decoded to tiles and / or bricks such that only a subset of the tiles and / or bricks is occupied. For example, in viewport-dependent streaming of 360-degree video, only a subset of independently coded picture regions such as tiles can be received. In another example, patch-based encoding of volumetric or point cloud video is applied, where the patches occupy only a subset of the tiles and / or bricks of the picture.

[0271] According to one embodiment of the encoding, an uncoded tile or brick is represented by a syntax structure on or along slice data in the bitstream. The syntax elements of the uncoded tile or brick are not encoded in the slice data. The uncoded tile or brick is reconstructed (e.g., into the decoded reference picture) using a predefined or instructed method such as setting the sample values reconstructed in the sample array to zero.

[0272] According to one embodiment of decoding, uncoded tiles or bricks are decoded from the syntax structure on the slice data from or along the bitstream. The syntax elements of the uncoded tiles or bricks are not decoded from the slice data. The uncoded tiles or bricks are decoded (e.g., into the decoded reference picture) using a predefined or instructed method such as setting the sample values reconstructed in the sample array to zero.

[0273] According to one embodiment applicable to encoding and / or decoding, the number of uncoded bricks is signaled and / or decoded for a tile column using a variable length codeword such as ue(v). The bricks within the tile column are traversed in a predefined scan order (e.g., from bottom to top). For each brick traversed, a flag is signaled and / or decoded to determine whether the brick is uncoded. If the brick is uncoded, the number of bricks left to be assigned as uncoded is decremented by one. The process continues until there are no bricks left to be assigned as uncoded.

[0274] FIG. 11 shows a block diagram of a video decoder suitable for use with an embodiment of the present invention. Although FIG. 11 shows the structure of a two-layer decoder, it will be understood that the decoding operation can be used similarly with a single-layer decoder.

[0275] Video decoder 550 includes a first decoder section 552 for the base layer and a second decoder section 554 for the prediction layer. Block 556 represents a demultiplexer for sending information regarding the base layer picture to the first decoder section 552 and information regarding the prediction layer picture to the second decoder section 554. Reference P’n represents the predicted representation of the image block. Reference D’n represents the reconstructed prediction error signal. Blocks 704, 804 indicate the preliminary reconstructed image (I’n). Reference R’n represents the final reconstructed image. Blocks 703, 803 indicate the inverse transform (T -1 ). Blocks 702, 802 indicate the inverse quantization (Q -1 ). Blocks 701, 801 indicate the entropy decoding (E -1 ). Blocks 705, 805 indicate the reference frame memory (RFM). Blocks 706, 806 indicate the prediction (P) (either inter-prediction or intra-prediction). Blocks 707, 807 indicate the filtering (F). Blocks 708, 808 can be used to obtain the preliminary reconstructed image (I’n) by combining the decoded prediction error information with the predicted base layer / prediction layer image. The preliminarily reconstructed and filtered base layer image can be the output 709 from the first decoder section 552, and the preliminarily reconstructed and filtered base layer image can be the output 809 from the first decoder section 554.

[0276] In this specification, the decoder should be interpreted as encompassing operational units such as players, receivers, gateways, demultiplexers, and / or decoders that can perform decoding operations.

[0277] FIG. 12 shows a flowchart of the operation of a decoder according to an embodiment of the present invention. The decoding operation of the embodiment is the same as the encoding operation in other respects except that the decoder decodes an instruction. Therefore, the decoding method includes decoding (1200) a bitstream portion including the display of a tile column and the display of the block height of one or more tile columns at a time, inferring (1202) potential tile rows when detecting block rows aligned through a picture, inferring or decoding (1204) whether the boundaries of the potential tile rows are tile row boundaries, and using the displayed tile column, the displayed or inferred tile row, and the displayed block height to decode (1206) one or more pictures from the bitstream, where one or more pictures are partitioned into a grid of tiles along the displayed tile column and the displayed or inferred tile row, the tiles in the grid of tiles include integer coding tree units, are partitioned into one or more blocks, and the blocks include rows of integer coding tree units within the tile, including decoding (1206).

[0278] FIG. 13 shows a flowchart of the operation of a decoder according to another embodiment of the present invention. The decoding method includes the steps of: a) decoding (1300) the indication of the number of partitions to be assigned; b) determining (1302) the number of units to be assigned to the partitions; c) determining (1304) whether the number of units to be assigned is evenly divisible by the number of partitions; and if not, d) determining (1306) the number of units to be assigned to the next partition; and e) repeating steps c) and d) (1308) until all units are assigned to the partitions.

[0279] Display of partitioning of a picture into rectangular slices Embodiments of an improved method for encoding and / or decoding a signal notification of a rectangular slice are presented in the following paragraphs. The embodiments can be applied together with or independently of embodiments of tile and block partitioning. The embodiments are based on the definitions and characteristics of tiles, blocks, and rectangular slices specified in VVC draft 5. In an embodiment, the number of bits required to display (e.g., display or derive the location, width, and height of a rectangular slice) a rectangular slice is reduced.

[0280] An encoding method according to a first aspect includes displaying or inferring the location of the top-left block of a rectangular slice in or along a bitstream, and determining from the location whether the rectangular slice includes one or more blocks of a tile, and, if the rectangular slice includes one or more blocks of a tile, displaying or inferring the number of blocks within the rectangular slice in or along the bitstream.

[0281] A decoding method according to a first aspect includes decoding or inferring the location of the top-left block of a rectangular slice from or along a bitstream, and determining from the location whether the rectangular slice includes one or more blocks of a tile, and, if the rectangular slice includes one or more blocks of a tile, decoding or inferring the number of blocks within the rectangular slice from or along the bitstream.

[0282] The location of a block can be, for example, a block index in a block scan of a picture.

[0283] In one embodiment applicable to encoding and / or decoding, if the location of the upper left block of a rectangular slice is not the upper left block of any tile, it is determined that the rectangular slice contains one or more blocks of the tile.

[0284] In one embodiment applicable to encoding and / or decoding, if the location of the upper left block of a rectangular slice is the upper left block of a tile and the tile contains a number of blocks, it is determined that the rectangular slice contains either the blocks of the tile or the complete tile. In one embodiment applicable to encoding, if it is determined that a rectangular slice can contain either the blocks of a tile or the complete tile, whether the rectangular slice contains the blocks of the tile or the complete tile is indicated in or along the bitstream. In one embodiment applicable to decoding, if it is determined that a rectangular slice can contain either the blocks of a tile or the complete tile, whether the rectangular slice contains the blocks of the tile or the complete tile is decoded from or along the bitstream.

[0285] In one embodiment applicable to encoding and / or decoding, it is presumed, displayed (as part of encoding), or decoded that a rectangular slice includes the bricks of a tile. For example, a variable called numDeltaValues is set equal to the number of bricks within the same tile following the location of the top left brick of the rectangular slice. If numDeltaValues is equal to 1, it is presumed that the rectangular slice contains exactly one brick. Otherwise, the variable numDeltaValues is used to derive the syntax element length of a first syntax element that represents the bottom right brick of the rectangular slice, or a second syntax element that represents the number of bricks of the rectangular slice, or a third syntax element that represents the height (in bricks) of the rectangular slice, or any similar syntax element. For example, the first, second, or third syntax element, or any similar syntax element, can be u(v)-coded and its length is Ceil(Log2(numDeltaValues)) bits.

[0286] In an exemplary embodiment, the following syntax is used.

[0287]

Table 15

[0288] The semantics of the syntax element can be specified as described previously, except that bottom_right_brick_idx_delta[i] specifies the difference between the brick index of the brick placed at the bottom right corner of the i-th slice and top_left_brick_idx[i]. If single_brick_per_slice_flag is equal to 1, the value of bottom_right_brick_idx_delta[i] is assumed to be equal to 0. If it does not exist, the value of bottom_right_brick_idx_delta[i] is assumed to be equal to 0. A variable numDeltaValues that specifies the number of values that bottom_right_brick_idx_delta[i] can have is derived as follows. if( BrickIdxInTile[ brIdx ] > 0 ) numDeltaValues = NumBricksInTile[ top_left_brick_idx[ i ] ] - BrickIdxInTile[ top_left_brick_idx[ i ] ] else numDeltaValues = NumBricksInPic - top_left_brick_idx[ i ]

[0289] The length of the bottom_right_brick_idx_delta[i] syntax element is Ceil(Log2(numDeltaValues)) bits. The variable NumBricksInTile[brickIdx] specifies the number of bricks in the tile that contains the brick with index brickIdx in the brick scan of the picture. The variable BrickIdxInTile[brickIdx] specifies the index of the brick within the tile that contains the brick when the brick is identified by index brickIdx in the brick scan of the picture.

[0290] In one embodiment applicable to encoding and / or decoding, the location of the upper left block of the rectangular slice is inferred. First, all block locations are marked as empty. The loop that assigns blocks to the rectangular slice is included in or along the bitstream, or is decoded from or along the bitstream. For each loop entry, the upper left block of the rectangular slice is inferred to be the next empty block location in a predefined, directed, or decoded scan order. For example, the block scan order within a picture can be predefined, for example, in a coding standard. The lower right block of the rectangular slice can be inferred, displayed, or decoded, for example, as described above, and the blocks that form a rectangle with the upper left and lower right blocks placed at the corners are marked as assigned. The same or a similar process is repeated for each loop entry.

[0291] In one embodiment applicable to encoding and / or decoding, when it is determined (as part of encoding or decoding), displayed (as part of encoding), or decoded (as part of decoding) that the rectangular slice contains a complete tile, the syntax element for displaying the lower right block of the rectangular slice is derived from one or more of the following. - A set of possible lower right block locations is derived. The set is the last block location within the tile, placed in or below the tile row containing the upper left block of the rectangular slice, and to the right or on the right side of the tile column containing the upper left block of the rectangular slice, and can include only those block locations that surround the set of empty tile locations of the rectangle (not yet assigned to any rectangular slice). - The entries of the set of possible lower right block locations are indexed or enumerated. - The length of the u(v)-encoded syntax element for displaying the bottom-right block of the rectangular slice is derived from the number of entries within the set of possible bottom-right block locations. If the number of entries numEnt is equal to 1, the bottom-right block index need not be displayed or decoded. Otherwise, the length of the syntax element is equal to Ceil(Log2(numEnt)) bits. - The syntax element for displaying the bottom-right block of the rectangular slice is an index into the enumerated set of possible bottom-right block locations.

[0292] The encoding method according to the second aspect is - Displaying or inferring the location of the top-left block of the rectangular slice in or along the bitstream, - Determining from the location whether the rectangular slice contains one or more blocks of the tile, - If the rectangular slice contains one or more blocks of the tile, inferring that the width of the rectangular slice is equal to one tile column, and in other cases, if the top-left block is in the rightmost tile column, inferring that the width of the rectangular slice is equal to one tile column, and otherwise, displaying the width of the rectangular slice of the tile column in or along the bitstream, - If the rectangular slice contains one or more blocks of the tile, displaying or inferring the number of blocks within the rectangular slice in or along the bitstream, and in other cases, if the top-left block is in the bottommost tile row, inferring that the height of the rectangular slice is equal to one tile row, and otherwise, displaying the height of the rectangular slice of the tile row in or along the bitstream.

[0293] The coding method according to the second aspect is - Decoding the location of the top-left block of the rectangular slice from or along the bitstream, or inferring the location of the top-left block of the rectangular slice, and - Determining from the location whether the rectangular slice contains one or more blocks of the tile, and - If the rectangular slice contains one or more blocks of the tile, inferring that the width of the rectangular slice is equal to one tile column, and in other cases, if the top-left block is in the rightmost tile column, inferring that the width of the rectangular slice is equal to one tile column, and if not, decoding the width of the rectangular slice of the tile column from or along the bitstream, and - If the rectangular slice contains one or more blocks of the tile, decoding the number of blocks within the rectangular slice from or along the bitstream or inferring the number of blocks within the rectangular slice, and in other cases, if the top-left block is in the bottommost tile row, inferring that the height of the rectangular slice is equal to one tile row, and if not, decoding the height of the rectangular slice of the tile row from or along the bitstream.

[0294] In one embodiment applicable to encoding and / or decoding and applicable to the first aspect and / or the second aspect, if the rectangular slice contains blocks of the tile, the tile contains two blocks, and it is determined, indicated, or decoded that the current block (i.e., the top-left block of the rectangular slice) is the topmost block of the tile or the current block is the bottommost block of the tile, the number of blocks within the rectangular slice is inferred to be equal to 1 (in terms of blocks).

[0295] In an exemplary embodiment, the following syntax is used.

[0296]

Table 16

[0297] The variables and semantics of the syntax elements can be specified as described previously, with the following additions. - tlBrickIdx can be specified as the next empty brick location in a predefined scan order, such as a brick scan within the picture, as described previously. tlBrickIdx is re-derived for each value of i, i.e., for each loop entry. - numFreeColumnsOnTheRight[brickIdx] is a variable that indicates the number of tile columns to the right of the brick with index brickIdx. - slice_width_minus1[i] + 1 specifies the width of the i-th rectangular slice within the tile column. If it does not exist, slice_width_minus1[i] is assumed to be equal to 0. - full_tiles_in_slice_flag[i] equal to 0 specifies that the i-th rectangular slice contains one or more bricks of a single tile. full_tiles_in_slice_flag[i] equal to 1 specifies that the i-th rectangular slice contains one or more complete tiles. If BrickIdxInTile[tlBrickIdx] is greater than 0 (i.e., the top-left brick of the rectangular slice is not the top-left brick of the tile), full_tiles_in_slice_flag[i] is assumed to be equal to 0. If slice_width_minus1[i] is greater than 0, or if BrickIdxInTile[tlBrickIdx] is equal to 0 and NumBricksInTile[tlBrickIdx] is equal to 1, full_tiles_in_slice_flag[i] is assumed to be equal to 1. - When full_tiles_in_slice_flag[i] is equal to 0, numFreeRowsBelow[brickIdx] is a variable that indicates the number of bricks in the tiles below the brick with index brickIdx within the same tile. Otherwise, numFreeRowsBelow[brickIdx] is a variable that indicates the number of tile rows below the tile containing the brick with index brickIdx. - When full_tiles_in_slice_flag[i] is equal to 0, slice_height_minus1[i]+1 specifies the height of the i-th rectangular slice within the brick. Otherwise, slice_height_minus1[i]+1 specifies the height of the i-th rectangular slice within the tile row. If it does not exist, slice_height_minus1[i] is assumed to be equal to 0.

[0298] In one embodiment 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 top-left brick location of the rectangular slice. By using the variables and syntax elements described above, the length of slice_width_minus1 is equal to Ceil(Log2(numFreeColumnsOnTheRight[tlBrickIdx]+1)).

[0299] In one 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 contains bricks of a single tile or a complete tile. By using the variables and syntax elements described above, the length of slice_height_minus1 is equal to Ceil(Log2(numDeltaValues) ), where numDeltaValues is derived as follows. if( full_tiles_in_slice_flag[ i ] == 0) numDeltaValues = NumBricksInTile[ tlBrickIdx ] - BrickIdxInTile[ tlBrickIdx ] else numDeltaValues = numFreeRowsBelow[ tlBrickIdx ] + 1

[0300] Embodiments of an improved method for encoding and / or decoding signaling of rectangular slices are presented in the following paragraphs. The embodiments can be applied together with, or independent of, embodiments of tile and brick partitioning. The embodiments are based on the definitions and characteristics of one or more of tiles, bricks, rectangular slices, and sub-pictures as specified in VVC draft 6. In an embodiment, the number of bits required to display (e.g., display or derive the location, width, and height of) a rectangular slice is reduced.

[0301] According to one embodiment, a unique rectangular slice is encoded for each sub-picture. The encoder indicates that a unique rectangular slice is encoded for each sub-picture for pictures within the display range, e.g., in the PPS, in or along the bitstream. The display range can be, for example, a picture that references a PPS that includes an indication that a unique rectangular slice is used for each sub-picture. The encoder omits explicit signaling of the boundaries of the rectangular slice. The encoder assumes that the boundaries of the rectangular slice are the same as the boundaries of the sub-picture.

[0302] According to one embodiment, the decoder decodes, from or along the bitstream, e.g., based on the PPS, the indication that each subpicture contains a unique rectangular slice in the picture within the display range. The display range can be, for example, the picture that refers to the PPS containing the display. The decoder omits decoding the explicit signaling of the boundaries of the rectangular slices. The decoder infers that the boundaries of the rectangular slices are the same as the boundaries of the subpicture.

[0303] Syntaxes such as the following can be used in the above-described embodiment. The single_slice_per_subpic_flag equal to 0 specifies that a subpicture can contain any number of rectangular slices, and the single_slice_per_subpic_flag equal to 1 specifies that each subpicture contains a unique rectangular slice.

[0304] [Table 17]

[0305] According to one embodiment, whether a subpicture consists of a single rectangular slice or it contains two or more rectangular slices, the encoder indicates in or along the bitstream, e.g., in the PPS, and / or the decoder decodes from or along the bitstream, e.g., based on the PPS. For example, a u(1) - coded syntax element, e.g., called subpic_split_flag[i], can indicate that (when equal to 0) the i - th subpicture consists of exactly one rectangular slice or (when equal to 1) the i - th subpicture consists of two or more rectangular slices.

[0306] According to one embodiment, the encoder displays and / or decodes partitioning a sub-picture into rectangular slices using brick indices within the sub-picture. The bricks within the sub-picture are indexed, for example, in a predefined scan order, such as the brick scan order within the sub-picture, i.e., the tile raster scan within the sub-picture as the major order and the brick raster scan within the tile as the minor order, starting, for example, from 0 and incrementing by 1. Since the range of values of the brick indices within the sub-picture is smaller than the range of values of the brick indices within the picture, the syntax elements for displaying the brick indices within the sub-picture may be shorter than the respective syntax elements of the brick indices within the picture, and thus, signaling may be more compact.

[0307] According to one embodiment, the following syntax, etc. can be used.

[0308]

Table 18

[0309] A rect_slice_splitting_present_flag equal to 0 specifies that there is exactly one rectangular slice per subpicture. A rect_slice_splitting_present_flag equal to 1 specifies that each subpicture may contain one or more rectangular slices. bottom_right_brick_idx_length_minus1 + 1 specifies the length of the bottom_right_brick_idx_delta[i] syntax element. The NumSubPics variable is derived to be equal to the number of subpictures in the picture, for example, based on the subpicture signal notification in the SPS. A subpic_split_flag[i] equal to 0 specifies that the i-th subpicture consists of exactly one rectangular slice. A subpic_split_flag[i] equal to 1 specifies that the i-th subpicture consists of two or more rectangular slices. num_slices_in_subpic_minus2[i] + 2 specifies the number of rectangular slices in the i-th subpicture. The bricks in the i-th subpicture are indexed in brick scan order. bottom_right_brick_idx_delta[i][j] and sign_bottom_right_brick_idx_delta[i][j] specify the signed delta values used to derive the brick index of the bottom-right brick of the j-th rectangular slice in the i-th subpicture, where j is greater than 0, or with reference to 0 (i.e., the upper-left corner of the i-th subpicture), or when j is equal to 0, with reference to the bottom-right brick of the (j - 1)-th rectangular slice of the i-th subpicture.The signed delta value can be defined to be equal to bottom_right_brick_idx_delta[i][j] when sign_bottom_right_brick_idx_delta[i][j] is equal to 1, and when sign_bottom_right_brick_idx_delta[i][j] is equal to 0 but the sign_bottom_right_brick_idx_delta[i][j] value can be assigned oppositely and defined similarly, it can be defined to be equal to -bottom_right_brick_idx_delta[i][j].

[0310] Display of non-coded rectangular slices In some applications, it may be appropriate to assign the content to be encoded and / or decoded to rectangular slices such that only a subset of the rectangular slices is occupied. For example, in viewport-dependent streaming of 360-degree video, only a subset of the rectangular slices can be received. In another example, patch-based encoding of volumetric or point cloud video is applied and the patches occupy only a subset of the rectangular slices of the picture.

[0311] According to one embodiment of the encoding, the non-coded rectangular slices are indicated in or along the bitstream, e.g., in the PPS. The non-coded rectangular slices are not encoded into the bitstream as VCL NAL units. The non-coded rectangular slices are reconstructed (e.g., into the decoded reference picture) using a predefined or indicated method such as setting the sample values reconstructed in the sample array to 0.

[0312] According to one embodiment of decoding, an uncoded rectangular slice is decoded from or along a bitstream, for example, based on the PPS. The uncoded rectangular slice is not decoded from a VCL NAL unit in the bitstream. Instead, the uncoded rectangular slice is decoded (e.g., into a decoded reference picture) using a predefined or indicated method such as setting the sample values decoded in the sample array to 0.

[0313] According to one embodiment applicable to encoding and / or decoding, a flag is displayed and / or decoded for each rectangular slice, and the flag indicates whether the rectangular slice is uncoded.

[0314] According to one embodiment, the number of uncoded rectangular slices is displayed and / or decoded using a variable length codeword such as ue(v). The rectangular slices are traversed in a predefined scan order (in the reverse raster scan order of the top-left CTU of the rectangular slice). For each traversed rectangular slice, the flag is displayed and / or decoded to determine whether the rectangular slice is uncoded. If the rectangular slice is uncoded, the number of rectangular slices left to be assigned as uncoded is decreased by 1. This process continues until the number of rectangular slices left to be assigned as uncoded is zero.

[0315] FIG. 15 is a graphical representation of an exemplary multimedia communication system that can implement various embodiments. Data source 1510 provides source signals in analog, uncompressed digital, or compressed digital formats, or any combination of these formats. Encoder 1520 can include or be associated with preprocessing such as data format conversion and / or filtering of the source signal. Encoder 1520 encodes the source signal into an encoded media bitstream. Note that the bitstream to be decoded can be received directly or indirectly from a remote device located within virtually any type of network. Additionally, the bitstream can be received from local hardware or software. Encoder 1520 may be able to encode two or more media types such as audio and video, or two or more encoders 1520 may be required to encode source signals of different media types. Encoder 1520 can also obtain synthetically created inputs such as graphics and text and may be able to generate an encoded bitstream of the synthetic media. In the following, only the processing of one encoded media bitstream of one media type is considered for simplicity of explanation. However, in general, real-time broadcast services will note that they include several streams (generally, at least one audio, video, and text subtitle stream). Note that the system can include many encoders, but in the figure, only one encoder 1520 is shown for simplicity of explanation without loss of generality. It should be further understood that the text and examples included herein may specifically illustrate the encoding process, but those skilled in the art will understand that the same concepts and principles apply to the corresponding decoding process and vice versa.

[0316] The encoded media bitstream can be transferred to storage 1530. Storage 1530 can include any type of mass memory for storing the encoded media bitstream. The format of the encoded media bitstream within storage 1530 can be a basic self - contained bitstream format, or one or more encoded media bitstreams can be encapsulated in a container file, or the encoded media bitstream can be suitable for DASH (or a similar streaming system) and encapsulated in a segment format 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 a file and create file format metadata, which can further be stored in the file. The encoder 1520 or the storage 1530 can include the file generator, or the file generator can be operably attached to either the encoder 1520 or the storage 1530. Some systems operate "live", i.e., omit storage and transfer the encoded media bitstream from the encoder 1520 directly to the sender 1540. The encoded media bitstream can then be transferred to the sender 1540, also called a server as needed. The format used for transmission can be a basic self - contained bitstream format, a packet stream format, a segment format suitable for DASH (or a similar streaming system), or one or more encoded media bitstreams can be encapsulated in a container file. The encoder 1520, the storage 1530, and the server 1540 can be present on the same physical device or can be included in separate devices.Encoder 1520 and server 1540 can operate on live real-time content, in which case the encoded media bitstream is generally not stored permanently, but rather is buffered for a short period of time in content encoder 1520 and / or server 1540 to smooth out processing delays, transfer delays, and variations in the encoded media bit rate.

[0317] Server 1540 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). If the communication protocol stack is packet-oriented, server 1540 encapsulates the encoded media bitstream into packets. For example, if RTP is used, server 1540 encapsulates the encoded media bitstream into RTP packets according to the RTP payload format. Generally, each media type has a dedicated RTP payload format. The system can include more than one server 1540, but for simplicity, it should be noted again that the following description considers only one server 1540.

[0318] When media content is encapsulated into a container file for storage 1530 or for input to the sender 1540, the sender 1540 can include, or can be operably attached to, a "transmission file parser" (not shown in the figure). In particular, when the container file is not sent as such, but at least one of the encoded media bitstreams contained therein is encapsulated for transfer via a communication protocol, the transmission file parser searches for the appropriate portions of the encoded media bitstreams to be carried via the communication protocol. The transmission file parser can also be useful in creating the correct format of the communication protocol, such as packet headers and payloads. The multimedia container file can include encapsulation instructions, such as hint tracks in ISOBMFF, to encapsulate at least one of the included media bitstreams based on a communication protocol.

[0319] The server 1540 may or may not be connected to the gateway 1550 through a communication network that can be, for example, a combination of a CDN, the Internet, and / or one or more access networks. The gateway may also or alternatively be called a middlebox. In DASH, the gateway can be an edge server (of the CDN) or a web proxy. The system can generally include any number of gateways, etc., but for simplicity, it should be noted that the following description considers only one gateway 1550. The gateway 1550 can perform various types of functions, such as conversion of a packet stream by one communication protocol stack to another communication protocol stack, merging and forking of data streams, and control of the bitrate of the transfer stream according to the current downlink network state, and operation of the data stream according to the downlink and / or receiver capabilities, etc. The gateway 1550 can be a server entity in various embodiments.

[0320] The system generally includes one or more receivers 1560 that can receive, demodulate, and decapsulate the transmitted signal into an encoded media bitstream. The encoded media bitstream can be transferred to a recording storage 1570. The recording storage 1570 can include any type of mass memory for storing the encoded media bitstream. The recording storage 1570 can alternatively or additionally include computational memory such as random access memory. The format of the encoded media bitstream within the recording storage 1570 can be a basic self - contained bitstream format, or one or more encoded media bitstreams can be encapsulated in a container file. If there are multiple encoded media bitstreams, such as related audio and video streams, a container file is generally used, and the receiver 1560 includes or is attached to a container file generator that generates the container file from the input stream. Some systems operate "live", i.e., omit the recording storage 1570 and transfer the encoded media bitstream from the receiver 1560 directly to a decoder 1580. In some systems, only the most recent portion of the recorded stream, e.g., only the most recent 10 - minute excerpt of the recorded stream, is maintained in the recording storage 1570, while the previous recorded data is discarded from the recording storage 1570.

[0321] The encoded media bitstream can be transferred from the recording storage 1570 to the decoder 1580. There can be many encoded media bitstreams, such as an audio stream and a video stream that are related to each other and encapsulated in a container file, or a single media bitstream can be encapsulated in a container file, for example, for easier access. A file parser (not shown in the figure) is used to unpack each encoded media bitstream from the container file. The recording storage 1570 or the decoder 1580 can include a file parser, or the file parser can be attached to either the recording storage 1570 or the decoder 1580. The system can include many decoders, but it should also be noted that here only one decoder 1570 is discussed for simplicity of explanation without loss of generality.

[0322] The encoded media bitstream can be further processed by the decoder 1570, and the output of the decoder is one or more uncompressed media streams. Finally, the renderer 1590 can play the uncompressed media stream, for example, by a loudspeaker or a display. The receiver 1560, the recording storage 1570, the decoder 1570, and the renderer 1590 may be present on the same physical device or may be included in separate devices.

[0323] In the above, some embodiments have been described with reference to and / or using the terms of VVC / H.266. It should be understood that the embodiments can be implemented using any video encoder and / or video decoder as well.

[0324] In the above, several exemplary embodiments have been described with reference to specific syntax structures and / or syntax elements. It should be understood that the embodiments can be similarly implemented using other syntax structures and / or syntax elements. For example, if an embodiment is described with reference to the syntax elements of the PPS syntax, it should be understood that the embodiment can be implemented using the same or similar syntax elements of another syntax structure such as the SPS.

[0325] In the above, several embodiments have been described with reference to the term "display". It should be understood that the term "display" can be understood as the encoding or generation of one or more syntax elements in one or more syntax structures in or along a bitstream.

[0326] In the above, several embodiments have been described with reference to the term "decoding". It should be understood that the term "decoding" can be understood as the decoding or parsing of one or more syntax elements from one or more syntax structures from or along a bitstream.

[0327] In the above, when an exemplary embodiment is described with reference to an encoder, it should be understood that the resulting bitstream and decoder can have corresponding elements therein. Similarly, when an exemplary embodiment is described with reference to a decoder, it should be understood that the encoder can have a structure and / or computer program for generating the bitstream to be decoded by the decoder. For example, some embodiments have been described in relation to generating a prediction block as part of encoding. The embodiments can be similarly implemented by generating a prediction block as part of decoding, with a difference that coding parameters such as horizontal and vertical offsets are decoded from the bitstream rather than determined by the encoder.

[0328] The above-described embodiments of the present invention have described the codec in terms of separate encoder and decoder devices to assist in the understanding of the required processes. However, it will be understood that the apparatus, structure, and operation may be implemented as a single encoder-decoder apparatus / structure / operation. Further, it is possible for the coder and decoder to share some or all common elements.

[0329] The above example has described that the embodiments of the present invention operate within a codec in an electronic device, but it will be understood that the present invention as defined in the claims may be implemented as part of any video codec. Thus, for example, embodiments of the present invention may be implemented in a video codec capable of performing video coding via a fixed or wired communication path.

[0330] Accordingly, the user equipment can include a video codec such as those described in the above-described embodiments of the present invention. It should be understood that the term user equipment is intended to encompass any suitable type of wireless user equipment such as a mobile phone, a portable data processing device, or a portable web browser.

[0331] Furthermore, elements of a public land mobile network (PLMN) can include a video codec as described above.

[0332] In general, various embodiments of the present invention can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. For example, one aspect can be implemented in hardware, while other aspects can be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device, but the present invention is not limited thereto. Although various aspects of the present invention can be illustrated and described as the use of block diagrams, flowcharts, or other graphical representations, these blocks, devices, systems, techniques, or methods described herein can be implemented, by way of non-limiting example, in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or a controller or other computing device, or a combination thereof.

[0333] Embodiments of the present invention can be implemented by computer software executable by a data processor of a mobile device, such as within a processor entity, or by hardware, or by a combination of software and hardware. Further in this regard, it should be noted that any block of the logic flow as illustrated in the figures can represent a program step, or interconnected logic circuits, blocks, and functions, or a combination of program steps and logic circuits, blocks, and functions. Software can be stored in a physical medium, such as a memory chip, or a memory block implemented within a processor, a magnetic medium such as a hard disk or a floppy disk, and an optical medium such as, for example, a DVD and its data variants, a CD.

[0334] The memory can be of any type suitable for the local technical environment and may be implemented using any suitable data storage technology such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The data processor can be of any type suitable for the local technical environment and can include, by way of non-limiting example, one or more of a general-purpose computer, a dedicated computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture.

[0335] Embodiments of the present invention can be practiced with various components such as integrated circuit modules. The design of integrated circuits is generally a highly automated process. Sophisticated and powerful software tools are available to convert a logic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate.

[0336] Programs provided by Synopsys, Inc. of Mountain View, California, and Cadence Design of San Jose, California, use well-established design rules and a library of pre-stored design modules to automatically route conductors and place components on a semiconductor chip. After the design of the semiconductor circuit is complete, the resulting design in a standard electronic format (e.g., Opus, GDSII, etc.) can be sent to a semiconductor manufacturing facility or "fab" for manufacturing.

[0337] The foregoing description has provided a complete and helpful explanation of exemplary embodiments of the present invention by way of illustrative and non-limiting examples. However, various changes and modifications will become apparent to those skilled in the art when read in conjunction with the accompanying drawings and the appended claims. However, all such and similar changes to the teachings of the present invention will still fall within the scope of the present invention.

Claims

1. determining the number of units to be assigned to partitions and initialized as unassigned; displaying the number of partitions of a clearly sized partition to be assigned; when the number of the clearly sized partitions displayed is 0, displaying the number of units to be used as the uniform size of the partitions; when the number of the clearly sized partitions displayed is greater than 0, displaying the size of the clearly sized partitions, and accordingly, marking the unassigned units to be assigned to the partitions in a predefined scan order; setting the number of the units to be equal to the last size of the size of the clearly sized partitions; repeatedly assigning the number of the units to the partitions, and accordingly, marking the unassigned units to be assigned in the predefined scan order until the number of the unassigned units becomes less than the number of the units; when the number of the unassigned units is greater than 0, assigning the unassigned units to the last partition A method comprising.

2. The method according to claim 1, wherein the partitions are one or more of the following, namely, a tile column, a tile row, a block row of one or more tile columns, a block row of tiles, a grid column of a grid used to display sub-picture partitioning, and one or more of the grid rows of the grid used to display sub-picture partitioning.

3. The method according to claim 1 or 2, wherein the units are one or more of the following, namely, a rectangular block of samples of a picture, and one or more of the grid cells of a grid used to display sub-picture partitioning.

4. Means for determining the number of units to be assigned to partitions and initialized as unassigned; Means for displaying the number of explicitly sized partitions to be assigned; Means for displaying the number of units to be used as the uniform size of the partitions when the number of the displayed explicitly sized partitions is zero; When the number of the displayed explicitly sized partitions is greater than zero, means for displaying the size of the explicitly sized partitions, and accordingly, means for marking the unassigned units to be assigned to the partitions in a predefined scan order, and means for setting the number of the units to be equal to the last size of the size of the explicitly sized partitions; Means for repeatedly assigning the number of the units to the partitions, and accordingly, means for marking the unassigned units to be assigned in the predefined scan order until the number of the unassigned units becomes less than the number of the units; When the number of the unassigned units is greater than zero, means for assigning the unassigned units to the last partition; An apparatus comprising the same.

5. The apparatus according to claim 4, wherein the partitions are one or more of the following: a tile column, a tile row, a brick row of one or more tile columns, a brick row of tiles, a grid column of a grid used for displaying sub-picture partitioning, and one or more of the grid rows of the grid used for displaying sub-picture partitioning.

6. The apparatus according to claim 4 or 5, wherein the units are one or more of the following: a rectangular block of samples of a picture, and a grid cell of a grid used for displaying sub-picture partitioning.

7. Determining the number of units to be assigned to partitions; Determining the number of explicitly sized partitions to be assigned; When the number of the determined explicitly sized partitions is 0, determining the number of units to be used as the uniform size of the partitions; When the number of the determined explicitly sized partitions is greater than 0, determining the size of the explicitly sized partitions, and accordingly, marking the unassigned units to be assigned to the partitions in a predefined scan order; setting the number of the units to be equal to the last size of the size of the explicitly sized partitions; Repeatedly assigning the number of the units to the partitions, and accordingly, marking the unassigned units to be assigned in the predefined scan order until the number of the unassigned units becomes less than the number of the units; When the number of the unassigned units is greater than 0, assigning the unassigned units to the last partition; A method comprising: **Claim 8** The step of determining the number of explicitly sized partitions to be assigned includes decoding the number of the explicitly sized partitions to be assigned from a syntax structure; The step of determining the size of the explicitly sized partitions includes decoding the size of the explicitly sized partitions from the syntax structure; The method according to claim 7, wherein the step of determining the number of units includes decoding the number of the units from the syntax structure. **Claim 9** The method according to claim 7 or 8, wherein the partition is one of the following, namely, a tile column, a tile row, a brick row of one or more tile columns, a brick row of tiles, a grid column of a grid used to display sub-picture partitioning, and one or more of the grid rows of the grid used to display sub-picture partitioning.

10. The method according to any one of claims 7 to 9, wherein the unit is one of the following, namely, a rectangular block of samples of a picture, and one or more of the grid cells of a grid used to display sub-picture partitioning.

11. Means for determining the number of units to be assigned to a partition, Means for determining the number of clearly sized partitions to be assigned, Means for determining the number of units to be used as the uniform size of the partition when the determined number of clearly sized partitions is zero, When the determined number of clearly sized partitions is greater than zero, means for determining the size of the clearly sized partition, and accordingly, means for marking unassigned units to be assigned to the partition in a predefined scan order, and means for setting the number of the units to be equal to the last size of the size of the clearly sized partition, Means for repeatedly assigning the number of the units to the partition, and accordingly, means for marking unassigned units to be assigned in the predefined scan order until the number of unassigned units is less than the number of the units, An apparatus comprising means for assigning the unassigned units to the last partition when the number of unassigned units is greater than zero.

12. The apparatus according to claim 11, wherein the partition is one or more of the following, namely, a tile column, a tile row, a brick row of one or more tile columns, a brick row of tiles, a grid column of a grid used to display sub-picture partitioning, and one or more of the grid rows of the grid used to display sub-picture partitioning.

13. The apparatus according to claim 11 or 12, wherein the unit is one or more of the following, namely, a rectangular block of samples of a picture, and one or more of the grid cells of a grid used to display sub-picture partitioning.

14. A computer program having computer-executable program code instructions, the computer-executable program code instructions including program code instructions which, when executed, determine the number of units to be assigned to partitions and initialized as unassigned, display the number of explicitly sized partitions to be assigned, when the number of the displayed explicitly sized partitions is 0, display the number of units used as the uniform size of the partitions, when the number of the displayed explicitly sized partitions is greater than 0, display the size of the explicitly sized partitions, and accordingly, mark the unassigned units to be assigned to the partitions in a predefined scan order, set the number of the units to be equal to the last size of the size of the explicitly sized partitions, repeatedly assign the number of the units to the partitions, and accordingly, mark the unassigned units to be assigned in the predefined scan order until the number of the unassigned units is less than the number of the units, When the number of the unassigned units is greater than 0, assign the unassigned units to the last partition A computer program configured as such.

15. A computer program having computer-executable program code instructions, wherein the computer-executable program code instructions include program code instructions which, when executed, Determine the number of units to be assigned to partitions, Determine the number of clearly sized partitions to be assigned, When the number of the determined clearly sized partitions is 0, determine the number of units to be used as the uniform size of the partitions, When the number of the determined clearly sized partitions is greater than 0, determine the size of the clearly sized partitions, and accordingly, mark the unassigned units to be assigned to the partitions in a predefined scan order, set the number of the units to be equal to the last size of the size of the clearly sized partitions, Repeatedly assign the number of the units to the partitions, and accordingly, mark the unassigned units to be assigned in the predefined scan order until the number of the unassigned units is less than the number of the units, When the number of the unassigned units is greater than 0, assign the unassigned units to the last partition A computer program configured as such.

Images