Canvas size scalable video coding

Abstract

To provide methods and systems for canvas size scalability across the same or different bitstream layers of a video coded bitstream.SOLUTION: Offset parameters for a conformance window, a reference region of interest (ROI) in a reference layer, and a current ROI in a current layer are received. Widths and heights of the current ROI and the reference ROI are calculated on the basis of the offset parameters, and are used to generate width and height scaling factors to be used by a reference picture resampling unit to generate an output picture on the basis of the current ROI and the reference ROI.SELECTED DRAWING: Figure 5

Description

[Technical field]

[0001] [Related Applications] This application claims the benefit of priority to U.S. Provisional Application Nos. 62 / 883,195, filed August 6, 2019, 62 / 902,818, filed September 19, 2019, and 62 / 945,931, filed December 10, 2019.

[0002] [Technical field] FIELD OF THE DISCLOSURE This disclosure relates generally to images. More specifically, embodiments of the present invention relate to surface size scalable video coding. [Background technology]

[0003] As used herein, the term "dynamic range (DR)" may relate to the ability of the human visual system (HVS) to perceive a range of intensities (e.g., luminance, luma) in an image, e.g., from darkest gray (black) to brightest white (highlight). In this scene, DR relates to "scene-referred" intensity. DR may also relate to the ability of a display device to properly or approximately render an intensity range of a particular width. In this scene, DR relates to "display-referred" intensity. At any point in the description herein, unless it is explicitly specified that a particular scene has a particular importance, it should be presumed that the terms may be used in either scene, e.g., synonymously.

[0004] As used herein, the term "high dynamic range (HDR)" refers to a DR width that spans 14-15 times or more the magnitude of the human visual system (HVS). In fact, the DR that humans can simultaneously perceive in a wide range of intensity ranges may be omitted in some way in relation to HDR.

[0005] In practice, an image includes one or more color components (e.g., luma Y and chroma Cb and Cr), with each color component represented with n bits of precision per pixel (e.g., n=8). Using non-linear luminance coding, images with n≦8 (e.g., color 24-bit JPEG images) are considered to be standard dynamic range (SDR) images, while images with n>8 may be considered to be extended dynamic range images. HDR images may be stored and distributed using high-definition (e.g., 16-bit) floating-point formats, such as the OpenEXR file format developed by Industrial Light and Magic.

[0006] Currently, the delivery of video high dynamic range content such as Dolby Laboratories' Dolby Vision or HDR10 in Blue-Ray® is limited to 4K resolution (e.g., 4096×2160, or 3840×2160, etc.) and 60 frames per second (fps) due to the capabilities of many playback devices. In future versions, content with up to 8K resolution (e.g., 7680×4320) and 120 pfs is expected to be available for delivery and playback. To simplify the HDR playback content ecosystem such as Dolby Vision, it is desirable for future content types to be compatible with existing playback devices. Ideally, content creators should be able to adopt and deliver future HDR technologies without having to derive and deliver special versions of content (such as HDR10 or Dolby Vision) that are compatible with existing HDR devices. As recognized by the inventors herein, improved techniques for scalable delivery of video content, particularly HDR content, are desired.

[0007] The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Thus, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section. Similarly, problems identified with one or more of the approaches should not be assumed to have been recognized in any prior art under this section, unless otherwise indicated. [Brief description of the drawings]

[0008] Embodiments of the present invention are illustrated by way of example, and not by way of limitation, in the accompanying drawings, in which like reference symbols represent similar elements and in which:

[0009] [Figure 1] 1 illustrates an example process for a video delivery pipeline.

[0010] [Figure 2A] 4 shows an example of a picture sub-region for defining a display area of ​​an input content according to a resolution of a target display.

[0011] [Figure 2B] 2B illustrates an example of boundary spanning restrictions in tile representations, according to an embodiment, for the picture region of FIG. 2A.

[0012] [Figure 2C] 1 illustrates an example of layer-adaptive slice addressing, according to an embodiment.

[0013] [Diagram 3] 1 shows an example of spatial expansion possibilities according to the prior art.

[0014] [Figure 4] 1 illustrates an example of drawing surface extensibility, according to an embodiment.

[0015] [Diagram 5] 1 illustrates examples of base layer and enhancement layer pictures and corresponding adaptation windows, according to an embodiment.

[0016] [Figure 6A] 4 illustrates an exemplary process flow for supporting surface size scalability, according to an embodiment of the present invention. [Figure 6B] 4 illustrates an exemplary process flow for supporting surface size scalability, according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0017] Exemplary embodiments relating to drawing surface size scalability for video coding are described herein. In the following detailed description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of various embodiments of the present invention. It will be apparent, however, that various embodiments of the present invention may be practiced without some of these specific details. In other instances, well-known structures and devices have not been described in exhaustive detail to avoid unnecessarily occluding, obscuring, or obscuring embodiments of the present invention.

[0018] <Summary> Example embodiments described herein relate to surface size scalability in video coding. In an embodiment, a processor includes: receiving an offset parameter for an adaptation window in a first layer; Accessing a reference picture width and a reference picture height of a coding region in a reference layer; receiving offset parameters for a first region of interest (ROI) in the first layer; receiving an offset parameter for a second ROI in the reference layer; calculating a first picture width and a first picture height for a coding region in the first layer based on the offset parameter for the fitting window; calculating a second picture width and a second picture height for a current ROI in the first layer based on the first picture width, the first picture height, and the offset parameter for the first ROI; calculating a third picture width and a third picture height for a reference ROI in the reference layer based on the reference picture width, the reference picture height, and the offset parameter for the second ROI in the reference layer; Calculating a horizontal magnification based on the second picture width and the third picture width; Calculating a vertical scale factor based on the second picture height and the third picture height; Scaling the reference ROI based on the horizontal and vertical scale factors to generate a scaled reference ROI; An output picture is generated based on the current ROI and the scaled reference ROI.

[0019] In a second embodiment, the decoder comprises: receiving an offset parameter for an adaptation window in a first layer; Accessing a reference picture width and a reference picture height of a coding region in a reference layer; receiving adjusted offset parameters for a first region of interest (ROI) in the first layer, the adjusted offset parameters combining offset parameters for the first ROI with the offset parameters for the fitting window in the first layer; receiving an adjusted offset parameter for a second ROI in the reference layer, the adjusted offset parameter combining an offset parameter for the second ROI with an offset parameter for a fitting window in the reference layer; Calculate a first picture width and a first picture height for a current ROI in the first layer based on the adjusted offset parameters for the first ROI in the first layer; calculating a second picture width and a second picture height for a reference ROI in the reference layer based on the adjusted offset parameter for the second ROI in the reference layer; Calculating a horizontal magnification based on the first picture width and the second picture width; Calculating a vertical scale factor based on the first picture height and the second picture height; Scaling the reference ROI based on the horizontal and vertical scale factors to generate a scaled reference ROI; An output picture is generated based on the current ROI and the scaled reference ROI.

[0020] <An Example Video Delivery Processing Pipeline> 1 illustrates an exemplary process of a conventional video distribution pipeline 100 showing various stages from video capture to video content display. A sequence of video frames 102 is captured or generated using an image generation block 105. The video frames 102 may be digitally captured (e.g., by a digital camera) or computer generated (e.g., by computer animation) to provide video data 107. Alternatively, the video frames 102 may be captured on film by a film camera. The film is converted to a digital format to provide the video data 107. In a production stage 110, the video data 107 is edited to provide a video production stream 112.

[0021] The video data of the production stream 112 is then provided to a processor for post-production editing in block 115. The post-production editing in block 115 may include adjusting or changing the color or brightness of certain areas of the image to improve image quality or achieve a particular look according to the video producer's creative intent. This is sometimes called "color timing" or "color grading." Other editing (e.g., scene selection and ordering, image blackening, adding computer-generated visual special effects, judder or blur control, frame rate control, etc.) may be performed in block 115 to generate a final version of the production 117 for distribution. During post-production editing 115, the video image is displayed on a reference display 125. Following post-production 115, the final production video data 117 may be delivered to a coding block 120 for downstream delivery to decoding and playback devices such as television sets, set-top boxes, movie theaters, etc. In some embodiments, the coding block 120 may include audio and video encoders, such as those defined by ATSC, DVB, DVD, Blu-Ray, and other distribution formats, to generate a coded bit stream 122. At the receiver, the coded bit stream 122 is decoded by a decoding unit 130 to generate a decoded signal 132 that represents the same as the signal 117 or a very close approximation of it. The receiver may be attached to a target display 140, which may have characteristics quite different from the reference display 125. In that case, a display management block 135 may be used to map the dynamic range of the decoded signal 132 to the characteristics of the target display 140 by generating a display mapped signal 137.

[0022] <Extensible coding> Scalable coding is already part of many video coding standards such as MPEG-2, AVC, and HEVC. In an embodiment of the present invention, scalable coding is extended to improve performance and flexibility, especially when related to ultra-high resolution HDR content.

[0023] <Extensibility of drawing surface size> As known in the art, spatial scalability is primarily used to enable a decoder to generate content at different resolutions. In an embodiment of the present invention, spatial or drawing surface scalability is designed to enable extraction of different regions of an image. For example, a content creator may choose to frame content (i.e., specify a display area) differently for a large display than for a small display. For example, the area framed for display may depend on the size of the screen, or the distance from the screen to the viewer. An embodiment of the present invention divides an image into overlapping regions (typically rectangular) and encodes them such that a selected number of sub-regions can be decoded for presentation independently of the other sub-regions.

[0024] An example is shown in FIG. 2A, where various regions contain and / or are contained by other regions. As an example, the smallest region 215 has 2K resolution and the largest region 205 has 8K resolution. The base layer bitstream corresponds to the smallest spatial region, while the additional layers in the bitstream correspond to increasingly larger image regions. Thus, a 2K display only displays content within the 2K region 215. A 4K display displays content in both the 2K and 4K regions (within 210), and an 8K display displays everything within the larger 205. In another example, a 2K display may display a downsampled version of 4K content, and a 4K display may display a downsampled version of 8K content. Ideally, the base layer region can be decoded by legacy devices, while the other regions can be used by future devices to expand the drawing surface size.

[0025] Existing coding standards such as HEVC may enable drawing surface scalability using tiles. In a tiled representation, a frame is partitioned into a set of rectangular non-overlapping regions. A receiver can decide to decode and display only the set of tiles required for display. In HEVC, coding dependencies between tiles are disabled. In particular, entropy coding and reconstruction dependencies are not allowed to cross tile boundaries. This includes motion vector prediction, intra prediction, and context selection. (In-loop filtering is the only exception, which is allowed across boundaries but can be disabled by a flag in the bitstream.) Furthermore, to ensure that the base layer is independently decodable, encoder-side constraints on the motion constrained tiles (MCTS) are required, and a temporal motion constrained tile set supplemental enhancement information (SEI) message is required. For bitstream extraction and adaptation purposes, a motion constrained tile set extraction information set SEI message is required. The deficiency of tile definition in HEVC, especially with the ability to decode independently, is a loss of coding efficiency.

[0026] In an alternative implementation, HEVC enables surface scalability using the pan-scan rectangle SEI message to extract a region of interest (ROI). The SEI messaging specifies a rectangular extent, but provides information or constraints that allow the ROI to be decoded independently of other regions. Typically, a decoder needs to decode the entire image to obtain the ROI.

[0027] In an embodiment, a novel solution is proposed by improving the HEVC tile concept. For example, given the region shown in FIG. 2A, in an embodiment, independent decoding is only required for region 2K. As shown in FIG. 2B, for tiles within 2K, the proposed method allows boundary crossing prediction (intra / inter) and entropy coding. For 4K, it allows boundary crossing prediction (intra / inter) and entropy coding from 2k and within 4K. For 8K, it allows boundary crossing prediction (intra / inter) and entropy coding from 2k and 4K and within 8K. Here, it is proposed to assign layer_id 0 to 2K, layer_id 1 to 4K, and layer_id 2 to 8K. Given a currently decoded layer_id=N, boundary crossing tile prediction and entropy coding are only allowed from layer_ids less than or equal to N. In this case, the loss of coding efficiency is reduced compared to HEVC type tiles. An example syntax is shown in Tables 1 and 2 below, where new syntax elements proposed for the proposed Versatile Video Codec (VVC) draft specification of Ref [2] are shown highlighted in grey. Table 1: Example sequence parameter set RBSP syntax to enable drawing surface resizing [Table 1] Table 2: Example Picture Parameter RBSP Syntax for Drawing Surface Resize [Table 2]

[0028] In SPS (Table 1), the flag sps_canvas_tile_enabled_flag has been added. sps_canvas_tile_enabled_flag equal to 1 specifies that drawing surface tiles are currently enabled in CVS. sps_canvas_tile_enabled_flag equal to 0 specifies that drawing surface tiles are currently not enabled in CVS.

[0029] In the PPS (Table 2), a new layer_id information parameter, tile_layer_id[i], specifies the layer id of the ith drawing surface tile. If one constrains tile_layer_id values ​​to be consecutive starting at 0, in an embodiment, the maximum possible value of tile_layer_id may be NumTilesInPic-1, in accordance with the proposed VVC working draft (Ref. [2]).

[0030] Although tiles are used as a description, "bricks", slices, and subpictures, as defined in VVC and known in the art, can be similarly constructed.

[0031] <Layer Adaptive Slice Addressing> As the inventors have recognized, in certain streaming applications the following features may be desirable: (1) When using network abstraction layer (NAL) units in a video coding layer (VCL), a 2K resolution bitstream must be self-contained and all its NAL units must have the same value of nuh_layer_id (e.g., layer 0). An additional bitstream enabling 4K resolution must also be self-contained and its NAL units must have the same value of nuh_layer_id (e.g., layer 1) but different from the nuh_layer_id value of the 2K layer. Finally, any additional bitstream enabling 8K resolution must also be self-contained and its NAL units must have the same value of nuh_layer_id (e.g., layer 2) but different from the nuh_layer_id values ​​of the 2K and 4K layers. Thus, by analyzing the NAL unit header, it must be possible to extract the bitstream with the target resolution or region of interest (e.g., 2K, 4K, or 8K) using the nuh_layer_id. (2) For non-VCL NAL units, the stream and picture parameter set headers (eg, SPS, PPS, etc.) must be self-contained for each resolution. (3) At the target resolution, the bitstream extraction process must be able to discard NAL units that are not needed for the target resolution. After bitstream extraction for the target resolution, the bitstream conforms to the single-layer profile, so the decoder can only decode the single-resolution bitstream. Note that 2K, 4K, and 8K resolutions are provided only as examples and not limitations, and the same method can be applied to any number of different spatial resolutions or regions of interest. For example, one may start with a picture of the highest possible resolution (e.g., res_layer[0]=8K) and define sub-layers or regions of interest at the lowest resolution, where res_layer[i]>res_layer[i+1] for i=1,2,...,N-1, and N indicates the total number of layers. Then, one may want to decode a particular sub-layer without first decoding the entire picture. This helps the decoder reduce complexity, save power, etc.

[0032] To meet the above requirements, in an embodiment, the following method is proposed: A high-level syntax that reuses the video parameter set (VPS) syntax to specify layer information including the number of layers, dependency relationships between layers, representation format of the layers, DPB size, and other information relevant to defining bitstream conformance including layer sets, output layer sets, profile tier levels, and timing-related parameters. Each signal parameter set (SPS) associated with a different layer, picture resolution, adaptation window, sub-picture, etc. should conform to a distinct resolution (e.g. 2K, 4K, or 8K). For each different layer, tile, brick, slice, etc. associated picture parameter sets (PPS), the information should conform to the distinct resolution (e.g. 2K, 4K, or 8K). If the distinct regions are set to be the same in the VCS, the tile / brick / slice information may also be set in the SPS. In a slice header, slice_address should be set to the lowest target resolution that contains the slice. As mentioned before, in independent layer decoding, during prediction a layer can only use tile / brick / slice neighborhood information from lower layers and / or the same layer.

[0033] VVC (Ref. [2]) defines an integer number of bricks of a picture, contained exclusively in a single NAL unit, as a slice. A brick is defined as a rectangular area of ​​a coding tree unit (CTU) row within a particular tile in a picture. A coding tree unit (CTU) is a block of samples with luma and chroma information.

[0034] In our 2K / 4K / 8K example, in an embodiment, the value of slice_address (which indicates the slice address of the slice) may need to have a different slice_address value in the 2K bitstream than in the 4K bitstream or the 8K bitstream. Thus, a conversion of slice_address from low resolution to high resolution may be required. Thus, in an embodiment, such information is provided in the VPS layer.

[0035] FIG. 2C shows an example of a 4K picture with one sub-layer (e.g., for 2K and 4K). Consider picture 220 with 9 tiles and 3 slices. Let the gray tiles specify a region with 2K resolution. In a 2K bitstream, the slice_address of the gray region must be 0, but in a 4K bitstream, the slice_address of the gray region must be 1. The proposed new syntax allows specifying the slice_address according to the resolution layer. For example, in a VPS, slice_address conversion information may be added to specify that for null_layer_id=1, slice_address is changed to 1 for 4K. To simplify implementation, an embodiment may want to constrain that slice information for each resolution must be kept the same in the coded video stream (CVS). An exemplary syntax in a VPS based on the HEVC video parameter set RBSP syntax is shown in Table 3 (Section 7.3.2.1 of Ref. [1]). Information may also be conveyed through other layers of high-level syntax (HLS), such as SPS, PPS, slice headers, and SEI messages. Table 3: Example syntax for a VPS supporting layer-adaptive slice addressing [Table 3] vps_layer_slice_info_present_flag equal to 1 specifies that slice information is present in the VPS() syntax structure. vps_layer_slice_info_present_flag equal to 0 specifies that slice information is not present in the VPS() syntax structure. When num_slices_in_layer_minus1[i] is set to plus 1, it specifies the number of slices in the i-th layer. The value of num_slices_in_layer_minus1[i] is equal to num_slices_in_pic_minus1 in the i-th layer. layer_slice_address[i][j][k] specifies the target i-th layer slice address of the k-th slice in the j-th layer.

[0036] By way of example, returning to the example of FIG. 2C, picture 220 includes two layers: Layer 0 (eg 2K) has one slice 230 (grey) with slice address 0. Layer 1 (e.g. 4K) has 3 slices (225, 230, and 235) with slice addresses 0, 1, 2. When decoding layer 1 (i=1), within layer 0 (j=0), slice 0 (k=0) 230 has slice address 1, and therefore, following the notation in Table 3, layer_slice_address[1][0][0]=1.

[0037] <SEI message after filtering> When implementing drawing surface scalability using bricks / tiles / slices / subpictures, a possible problem is the implementation of in-loop filtering across boundaries (e.g., deblocking, SAO, ALF). As an example, Ref. [4] describes a problem when component windows are coded using independent regions (or subpictures). When coding the entire picture using independent coding regions (which can be implemented by bricks / tiles / slices / subpictures, etc., as an example), in-loop filtering across independent coding regions can cause drift and boundary artifacts. For drawing surface size applications, it is important to have good visual quality for both high-resolution and low-resolution videos. For high-resolution videos, boundary artifacts must be reduced. Therefore, in-loop filtering across independent coding regions (e.g., deblocking filters) must be enabled. For low-resolution videos, drift and boundary artifacts must also be minimized.

[0038] In Ref. [4], a solution is proposed to store sub-picture border padding for inter prediction. This approach can be implemented with an encoder-only constraint to disallow motion vectors that use those pixels affected by in-loop filtering. Alternatively, in an embodiment, it is proposed to solve this problem using post-filtering that is communicated to the decoder via SEI messaging.

[0039] First, it is proposed that in-loop filtering across independent coding regions (e.g., slice boundaries in regions 225 and 230) is disabled. Filtering across independent coding regions for the whole picture may be done in post-filtering processing. Post-filtering may include one or more of deblocking, SAO, ALF, or other filters. Deblocking may be the most important filter to remove ROI boundary artifacts. Usually, the decoder or display / user may have their own choice of what filters should be used. Table 4 shows an example syntax for SEI messaging after ROI-related filtering. Table 4: Example syntax after ROI-related filtering [Table 4] As an example, the syntax parameters may be defined as follows:

[0040] deblocking_enabled_flag equal to 1 specifies that deblocking may be applied to independent ROI boundaries of a reconstructed picture for display purposes. deblocking_enabled_flag equal to 0 specifies that deblocking shall not be applied to independent ROI boundaries of a reconstructed picture for display purposes.

[0041] sao_enabled_flag equal to 1 specifies that sample adaptive offset (SAO) processing may be applied to independent ROI boundaries of the reconstructed picture for display purposes. sao_enabled_flag equal to 0 specifies that sample adaptive processing shall not be applied to independent ROI boundaries of the reconstructed picture for display purposes.

[0042] alf_enabled_flag equal to 1 specifies that adaptive loop filter process (ALF) may be applied to the independent ROI boundary of the reconstructed picture for display. alf_enabled_flag equal to 0 specifies that adaptive loop filter process shall not be applied to the independent ROI boundary of the reconstructed picture for display.

[0043] user_defined_filter_enabled_flag equal to 1 specifies that user-defined filtering may be applied to the independent ROI boundary of the reconstructed picture for display purposes. user_defined_filter_enabled_flag equal to 0 specifies that user-defined filtering shall not be applied to the independent ROI boundary of the reconstructed picture for display purposes.

[0044] In an embodiment, the SEI messaging in Table 4 can be simplified by removing one or more of the proposed flags. If all flags are removed, then the presence of the SEI message independent_ROI_across_boundary_filter(payloadSize){} alone indicates to the decoder that a post-filter should be used to mitigate ROI-related boundary artifacts.

[0045] <Region of interest (ROI) expandability> The latest specification of VVC (Ref. [2]) describes spatial, quality and view scalability using a combination of reference picture resampling (RPR) and reference picture selection (RPS), as discussed in more detail in Ref. [3]. It is based on single-loop decoding and block-based on-the-fly resampling. RPS is used to define the predictive relationship between the base layer and one or more enhancement layers, or more specifically, between the coding pictures assigned to either the base layer or one or more enhancement layers. RPR is used to code a subset of pictures, i.e., spatial enhancement layer pictures, at a higher / lower resolution than the base layer, while predicting from a smaller / higher base layer picture. Figure 3 shows an example of spatial scalability with the RPS / RPR framework.

[0046] As shown in FIG. 3, the bitstream includes two streams: a low-resolution (LR) stream 305 (e.g., standard definition (HD), 2K, etc.), and a higher-resolution (HR) stream 310 (e.g., HD, 2K, 4K, 8K, etc.). The arrows indicate possible inter-predictive coding dependencies. For example, HR frame 310-P1 depends on LR frame 305-I. To predict blocks in 310-P1, the decoder needs to upscale 305-I. Similarly, HR frame 310-P2 may depend on HR frame 310-P1 and LR frame 305P1. Any prediction from LR frame 305-P1 requires spatial upscaling from LR to HR. In other embodiments, the order of LR and HR frames may be reversed, so that the base layer may be the HR stream and the enhancement layer may be the LR stream. Note that scaling of base layer pictures is not performed explicitly as in SHVC. Instead, it is incorporated in the inter-layer motion compensation and calculated on the fly. In Ref. [2], the scalability ratio is implicitly derived using a cropping window.

[0047] ROI scalability is supported in HEVC (Ref. [1]) as part of Annex H "Scalable high efficiency video coding", commonly referred to as SHVC. For example, Section F.7.3.2.3.4 defines syntax elements related to scaled_ref_layer_offset_present_flag[i] and ref_region_offset_present_flag[i]. The related parameters are derived in Equations (H-2)-(H-21) and (H-67)-(H-68). VVC does not yet support region of interest (ROI) scalability. As the inventors have recognized, support for ROI scalability may enable drawing surface size scalability using the same single-loop VVC decoder, without requiring extension of scalability as in SHVC.

[0048] As an example, given the three data layers shown in FIG. 2B (e.g., 2K, 4K, and 8K), FIG. 4 shows an exemplary embodiment of a bitstream that supports surface size scalability using the existing RPS / RPR framework.

[0049] As shown in Fig. 4, the bitstream allocates its picture to three layers or streams, 2K stream 402, 4K stream 405, and 8K stream 410. The arrows indicate examples of possible inter-predictive coding dependencies. For example, a pixel block in 8K frame 410-P2 may depend on blocks in 8K frame 410-P1, 4K frame 405-P2, and 2K frame 402-P1. Compared with the traditional scalability scheme using multiple loop decoders, the proposed ROI scalability scheme has the following advantages and disadvantages. -Advantages: Requires a single loop decoder and does not require any other tools. The decoder does not need to care about how to handle brick / tile / slice / subpicture boundary issues. Disadvantages: To decode the enhancement layer, both the base and enhancement layer decoded pictures are needed in the decoded picture buffer (DPB), thus requiring a larger DPB size than non-scalable solutions. Since both the base and enhancement layers need to be decoded, it may also require a faster decoder speed.

[0050] The main difference in enabling ROI scalability support between the embodiments proposed for SHVC and VVC is that in SHVC, picture resolution needs to be the same for all pictures in the same layer. However, in VVC, with RPR support, pictures in the same layer may have different resolutions. For example, in FIG. 3, SHVC, 305-I, 305-P1, and 305-P2 need to have the same spatial resolution. However, in VVC, with RPR support, 305-I, 305-P1, and 305-P2 can have different resolutions. For example, 305-I and 305-P1 can have a first lower resolution (e.g., 720p), and 305-P2 can have a second lower resolution (e.g., 480p). The embodiments of the present invention aim to support both ROI scalability between different layers and RPR for pictures of the same layer. Another main difference is that in SHVC, motion vectors from inter-layer prediction are constrained to be 0. However, in VVC, there is no such constraint and a motion vector can be either 0 or non-0. This reduces the constraints for identifying inter-layer correspondence.

[0051] The coding tree of VVC only allows coding of whole coding units (CUs). Most standard formats code picture regions in multiples of 4 or 8 pixels, but non-standard formats may need to pad at the encoder to fit the minimum CTU size. The same problem existed in HEVC. It was solved by creating a "conformance window" that specifies the picture range that is considered to conform to the picture output. Conformance windows were also added to VVC (Ref. [2]) and are specified by four variables: conf_win_left_offset, conf_win_right_offset, conf_win_top_offset, and conf_win_bottom_offset. For ease of reference, the following section is copied from Ref. [2].

[0052] conf_win_left_offset, conf_win_right_offset, conf_win_top_offset, and conf_win_bottom_offset specify the sample of the picture in the CVS output from the decoding process in terms of the rectangular region specified in the picture coordinates for output. When conformance_window_flag is equal to 0, the values ​​of conf_win_left_offset, conf_win_right_offset, conf_win_top_offset, and conf_win_bottom_offset are inferred to be equal to 0. The adaptive cropping window constrains the luma samples by the horizontal picture coordinate from SubWidthC*conf_win_left_offsettopic_width_in_luma_samples-(SubWidthC*conf_win_right_offset+1) and the vertical coordinate from SubHeightC*conf_win_top_offsettopic_height_in_luma_samples-(SubHeightC*conf_win_bottom_offset+1), inclusive. The value of SubWidthC*(conf_win_left_offset+conf_win_right_offset) must be less than pic_width_in_luma_samples, and the value of SubHeightC*(conf_win_top_offset+conf_win_bottom_offset) must be less than pic_height_in_luma_samples. The variables PicOutputWidthL and PicOutputHeightL are derived as follows:

number

[0053] In a first embodiment, the newly defined ROI offset is combined with the existing offset of the adaptation window to derive a scaling factor. An exemplary embodiment of the proposed syntax elements is shown in Figure 5, which shows a base layer picture 520 and an enhancement layer picture 502 with their corresponding adaptation windows. The following ROI syntax elements are defined: Base Layer (BL)

number

number

[0054] The width 512 and height 514 of the EL picture 502 can be calculated using the adapted window parameters of the enhancement layer using equations (7-43) and (7-44) above. (For example, pic_width_in_luma_samples may correspond to width 512, and PicOutputWidth may correspond to the width of the dotted window 518.)

[0055] As an example, Table 5 shows how pic_parameter_set_rbsp(), defined in Section 7.3.2.4 of Ref. [2], is modified to support new syntax elements (edits are highlighted in grey). Table 5: Example syntax for supporting ROI extensibility in VVC [Table 5] num_ref_loc_offsets specifies the number of reference layer location offsets present in the PPS. The value of num_ref_loc_offsets should be in the range of 0 to vps_max_layers_minus1, inclusive. ref_loc_offset_layer_id[i] specifies the nuh_layer_id value for which the i-th reference layer position offset parameter is specified. NOTE: ref_loc_offset_layer_id[i] does not have to be directly among the reference layers, for example when the spatial correspondence of an auxiliary picture to its associated primary picture is specified. The i-th reference layer position offset parameter includes the i-th scaled reference layer offset parameter and the i-th reference region offset parameter. scaled_ref_layer_offset_present_flag[i] equal to 1 specifies that the i-th scaled reference layer offset parameter is present in the PPS. scaled_ref_layer_offset_present_flag[i] equal to 0 specifies that the i-th scaled reference layer offset parameter is not present in the PPS. When not present, the value of scaled_ref_layer_offset_present_flag[i] is inferred to be equal to 0. The i-th scaled reference layer offset parameter specifies the spatial correspondence of the picture referencing this PPS relative to the reference region in the composite picture with nuh_layer_id equal to ref_loc_offset_layer_id[i]. The sum of scaled_ref_layer_left_offset[ref_loc_offset_layer_id[i]] and conf_win_left_offset specifies the horizontal offset between the sample in the current picture that is co-located with the top-left luma sample of the reference region in the decoded picture with nuh_layer_id equal to ref_loc_offset_layer_id[i] and the top-left luma sample of the current picture in units of subWC luma samples, where subWC is equal to SubWidthC of the picture that references this PPS. The value of the sum of scaled_ref_layer_left_offset[ref_loc_offset_layer_id[i]] and conf_win_left_offset shall be -2 inclusive. 14 ~2 14Should be in the range -1. When not present, the value of scaled_ref_layer_left_offset[ref_loc_offset_layer_id[i]] is inferred to be equal to 0. The sum of scaled_ref_layer_top_offset[ref_loc_offset_layer_id[i]] and conf_win_top_offset specifies the vertical offset between the sample in the current picture that is co-located with the top-left luma sample of the reference region in the decoded picture with nuh_layer_id equal to ref_loc_offset_layer_id[i] and the top-left luma sample of the current picture in units of subHC luma samples, where subHC is equal to SubHeightC of the picture that references this PPS. The value of the sum of scaled_ref_layer_top_offset[ref_loc_offset_layer_id[i]] and conf_win_top_offset shall be -2 inclusive. 14 ~2 14 Should be in the range -1. When not present, the value of scaled_ref_layer_top_offset[ref_loc_offset_layer_id[i]] is inferred to be equal to 0. The sum of scaled_ref_layer_right_offset[ref_loc_offset_layer_id[i]] and conf_win_right_offset specifies the horizontal offset between the sample in the current picture that is co-located with the bottom right luma sample of the reference region in the decoded picture with nuh_layer_id equal to ref_loc_offset_layer_id[i] and the bottom right luma sample of the current picture in units of subWC luma samples, where subWC is equal to SubWidthC of the picture that references this PPS. The value of the sum of scaled_ref_layer_right_offset[ref_loc_offset_layer_id[i]] and conf_win_right_offset shall be -2 inclusive. 14 ~2 14Should be in the range -1. When not present, the value of scaled_ref_layer_right_offset[ref_loc_offset_layer_id[i]] is inferred to be equal to 0. The sum of scaled_ref_layer_bottom_offset[ref_loc_offset_layer_id[i]] and conf_win_bottom_offset specifies the vertical offset between the sample in the current picture that is co-located with the bottom-right luma sample of the reference region in the decoded picture with nuh_layer_id equal to ref_loc_offset_layer_id[i] and the bottom-right luma sample of the current picture in units of subHC luma samples, where subHC is equal to SubHeightC of the picture that references this PPS. The value of the sum of scaled_ref_layer_bottom_offset[ref_loc_offset_layer_id[i]] and conf_win_bottom_offset shall be -2 inclusive. 14 ~2 14 Should be in the range -1. When not present, the value of scaled_ref_layer_bottom_offset[ref_loc_offset_layer_id[i]] is inferred to be equal to 0. Let currTopLeftSample, currBotRightSample, colRefRegionTopLeftSample, and colRefRegionBotRightSample be the top-left luma sample of the current picture, the bottom-right luma sample of the current picture, the sample in the current picture that is co-located with the top-left luma sample of the reference region in the decoded picture with nuh_layer_id equal to ref_loc_offset_layer_id[i], and the sample in the current picture that is co-located with the bottom-right luma sample of the reference region in the decoded picture with nuh_layer_id equal to ref_loc_offset_layer_id[i], respectively. When the value of (scaled_ref_layer_left_offset[ref_loc_offset_layer_id[i]]+conf_win_left_offset) is greater than 0, colRefRegionTopLeftSample is located to the right of currTopLeftSample. When the value of (scaled_ref_layer_left_offset[ref_loc_offset_layer_id[i]]+conf_win_left_offset) is less than 0, colRefRegionTopLeftSample is located to the left of currTopLeftSample. When the value of (scaled_ref_layer_top_offset[ref_loc_offset_layer_id[i]]+conf_win_top_offset) is greater than 0, colRefRegionTopLeftSample is located below currTopLeftSample. When the value of (scaled_ref_layer_top_offset[ref_loc_offset_layer_id[i]]+conf_win_top_offset) is less than 0, colRefRegionTopLeftSample is located above currTopLeftSample. When the value of (scaled_ref_layer_right_offset[ref_loc_offset_layer_id[i]]+conf_win_right_offset) is greater than 0, colRefRegionBotRightSample is located to the left of currBotRightSample. When the value of (scaled_ref_layer_right_offset[ref_loc_offset_layer_id[i]]+conf_win_right_offset) is less than 0, colRefRegionTopLeftSample is located to the right of currBotRightSample. When the value of (scaled_ref_layer_bottom_offset[ref_loc_offset_layer_id[i]]+conf_win_bottom_offset) is greater than 0, colRefRegionBotRightSample is located above currBotRightSample. When the value of (scaled_ref_layer_bottom_offset[ref_loc_offset_layer_id[i]]+conf_win_bottom_offset) is less than 0, colRefRegionTopLeftSample is located below currBotRightSample. ref_region_offset_present_flag[i] equal to 1 specifies that the offset parameters of the i-th reference region are present in the PPS. ref_region_offset_present_flag[i] equal to 0 specifies that the offset parameters of the i-th reference region are not present in the PPS. When not present, the value of ref_region_offset_present_flag[i] is inferred to be equal to 0. The offset parameter of the i-th reference area specifies the spatial correspondence of the reference area in the decoded picture with nuh_layer_id equal to ref_loc_offset_layer_id[i], relative to the same decoded picture. Let refConfLeftOffset[ref_loc_offset_layer_id[i]], refConfTopOffset[ref_loc_offset_layer_id[i]], refConfRightOffset[ref_loc_offset_layer_id[i]], and refConfBottomOffset[ref_loc_offset_layer_id[i]] be the values ​​of conf_win_left_offset, conf_win_top_offset, conf_win_right_offset, and conf_win_bottom_offset, respectively, of the decoded picture having nuh_layer_id equal to ref_loc_offset_layer_id[i]. The sum of ref_region_left_offset[ref_loc_offset_layer_id[i]] and refConfLeftOffset[ref_loc_offset_layer_id[i]] specifies the horizontal offset between the top-left luma sample of the reference region in the decoded picture with nuh_layer_id equal to ref_loc_offset_layer_id[i] and the top-left luma sample of the same decoded picture in units of subWC luma samples, where subWC is equal to SubWidthC of the layer with nuh_layer_id equal to ref_loc_offset_layer_id[i]. The value of the sum of ref_region_left_offset[ref_loc_offset_layer_id[i]] and refConfLeftOffset[ref_loc_offset_layer_id[i]] shall be -2 inclusive. 14 ~2 14 Should be in the range -1. When not present, the value of ref_region_left_offset[ref_loc_offset_layer_id[i]] is inferred to be equal to 0. The sum of ref_region_top_offset[ref_loc_offset_layer_id[i]] and refConfTopOffset[ref_loc_offset_layer_id[i]] specifies the vertical offset between the top-left luma sample of the reference region in the decoded picture with nuh_layer_id equal to ref_loc_offset_layer_id[i] and the top-left luma sample of the same decoded picture in units of subHC luma samples, where subHC is equal to SubHeightC of the layer with nuh_layer_id equal to ref_loc_offset_layer_id[i]. The value of the sum of ref_region_top_offset[ref_loc_offset_layer_id[i]] and refConfTopOffset[ref_loc_offset_layer_id[i]] shall be -2 inclusive. 14 ~2 14Should be in the range -1. When not present, the value of ref_region_top_offset[ref_loc_offset_layer_id[i]] is inferred to be equal to 0. The sum of ref_region_right_offset[ref_loc_offset_layer_id[i]] and refConfRightOffset[ref_loc_offset_layer_id[i]] specifies the horizontal offset between the bottom right luma sample of the reference region in the decoded picture with nuh_layer_id equal to ref_loc_offset_layer_id[i] and the bottom right luma sample of the same decoded picture in units of subWC luma samples, where subWC is equal to SubWidthC of the layer with nuh_layer_id equal to ref_loc_offset_layer_id[i]. The value of the sum of ref_layer_right_offset[ref_loc_offset_layer_id[i]] and refConfRightOffset[ref_loc_offset_layer_id[i]] shall be -2 inclusive. 14 ~2 14 Should be in the range -1. When not present, the value of ref_region_right_offset[ref_loc_offset_layer_id[i]] is inferred to be equal to 0. The sum of ref_region_bottom_offset[ref_loc_offset_layer_id[i]] and refConfBottomOffset[ref_loc_offset_layer_id[i]] specifies the vertical offset between the bottom right luma sample of the reference region in the decoded picture with nuh_layer_id equal to ref_loc_offset_layer_id[i] and the bottom right luma sample of the same decoded picture in units of subHC luma samples, where subHC is equal to SubHeightC of the layer with nuh_layer_id equal to ref_loc_offset_layer_id[i]. The value of the sum of ref_layer_bottom_offset[ref_loc_offset_layer_id[i]] and refConfBottomOffset[ref_loc_offset_layer_id[i]] shall be -2 inclusive. 14 ~2 14 Should be in the range -1. When not present, the value of ref_region_bottom_offset[ref_loc_offset_layer_id[i]] is inferred to be equal to 0. Let refPicTopLeftSample, refPicBotRightSample, refRegionTopLeftSample, and refRegionBotRightSample be the top left luma sample of the decoded picture having nuh_layer_id equal to ref_loc_offset_layer_id[i], the bottom right luma sample of the decoded picture having nuh_layer_id equal to ref_loc_offset_layer_id[i], the top left luma sample of the reference region in the decoded picture having nuh_layer_id equal to ref_loc_offset_layer_id[i], and the bottom right luma sample of the reference region in the decoded picture having nuh_layer_id equal to ref_loc_offset_layer_id[i], respectively. When the value of (ref_region_left_offset[ref_loc_offset_layer_id[i]]+refConfLeftOffset[ref_loc_offset_layer_id[i]]) is greater than 0, refRegionTopLeftSample is located to the right of refPicTopLeftSample. When the value of (ref_region_left_offset[ref_loc_offset_layer_id[i]]+refConfLeftOffset[ref_loc_offset_layer_id[i]]) is less than 0, refRegionTopLeftSample is located to the left of refPicTopLeftSample. When the value of (ref_region_top_offset[ref_loc_offset_layer_id[i]]+refConfTopOffset[ref_loc_offset_layer_id[i]]) is greater than 0, refRegionTopLeftSample is located below refPicTopLeftSample. When the value of (ref_region_top_offset[ref_loc_offset_layer_id[i]]+refConfTopOffset[ref_loc_offset_layer_id[i]]) is less than 0, refRegionTopLeftSample is located above refPicTopLeftSample. When the value of (ref_region_right_offset[ref_loc_offset_layer_id[i]]+refConfRightOffset[ref_loc_offset_layer_id[i]]) is greater than 0, refRegionBotRightSample is located to the left of refPicBotRightSample. When the value of (ref_region_right_offset[ref_loc_offset_layer_id[i]]+refConfRightOffset[ref_loc_offset_layer_id[i]]) is less than 0, refRegionBotRightSample is located to the right of refPicBotRightSample. When the value of (ref_region_bottom_offset[ref_loc_offset_layer_id[i]]+refConfBottomOffset[ref_loc_offset_layer_id[i]]) is greater than 0, refRegionBotRightSample is located above refPicBotRightSample. When the value of (ref_region_bottom_offset[ref_loc_offset_layer_id[i]]+refConfBottomOffset[ref_loc_offset_layer_id[i]]) is less than 0, refRegionBotRightSample is located below refPicBotRightSample.

[0056] Given the proposed syntax elements, in an embodiment, but not by way of limitation, the corresponding VVC section may be modified as follows: Formulas marked (7-xx) and (8-xx) indicate new formulas that need to be inserted into the VVC specification and are renumbered as necessary.

number

number

number

[0057] To support ROI scalability, the specification must be modified as follows:

number

number

number

number

[0058]

number

number

[0059] In another embodiment, unlike SHVC, VVC has no constraints on the size of motion vectors during inter-layer coding, so there is no need to consider the top-left position of the reference layer ROI and the scaled reference layer (current picture) ROI when finding pixel correspondence between ROI regions. Therefore, in all the above formulas, the references to fRefLeftOffset, fRefTopOffset, fCurLeftOffset and fCurTopOffset can be removed.

[0060] Figure 6A provides an example summary of the process flow described above. As shown in Figure 6A, in step 605, the decoder may receive syntax parameters related to the adaptation window (e.g., conf_win_xxx_offset, where xxx is left, top, right, or bottom), the scaled reference layer offset (e.g., scaled_ref_layer_xxx_offset[]) for the current picture, and the reference layer region offset (e.g., ref_region_xxx_offset[]). If not inter-coding (step 610), the decoding proceeds as in single layer decoding, otherwise, in step 615, the decoder calculates the adaptation window for both the reference and current pictures (e.g., using equations (7-43) and (7-44)). If it is not inter-layer coding (step 620), it is still necessary to calculate the RPR scaling factor for inter prediction for pictures with different resolutions in the same layer, and then decoding proceeds as in single layer decoding; otherwise (with inter-layer coding), the decoder calculates the scaling factors for the current and reference pictures based on the received offsets (e.g., by calculating hori_scale_fp and vert_scale_fp in equations (8-753) and (8-754)).

[0061] As described above (e.g., see equations (8-x1) to (8-x2)), the decoder needs to calculate the width and height (e.g., fRefWidth and fRefHeight) of the reference ROI by subtracting the reference layer's left and right offset values ​​(e.g., RefLayerRegionLeftOffset and RefLayerRegionRightOffset) and top and bottom offsets (e.g., RefLayerRegionTopOffset and RefLayerRegionBottomOffset) from the reference layer picture's PicOutputWidthL and PicOutputHeightL.

[0062] Similarly (see, e.g., equations (8-x3) to (8-x4)), the decoder needs to calculate the width and height (e.g., fCurWidth and fCurHeight) of the current ROI by subtracting the left and right offset values ​​(e.g., ScaledRefLayerLeftOffset and ScaledRefLayerRightOffset) and the top and bottom offsets (e.g., ScaledRefLayerTopOffset and ScaledRefLayerBottomOffset) from the PicOutputWidthL and PicOutputHeightL of the current layer picture. Given these adjusted sizes of the current and reference ROIs, only minimal additional modifications are required (shown in the gray highlighted portion above), and the decoder determines the horizontal and vertical scaling factors (see, e.g., equations (8-753) and (8-754)) as in the existing VVC RPR block (e.g., processing equations (8-755) to (8-766)).

[0063] In equations (8-x5) through (8-x8), adjusted left and top offsets are also calculated to determine the correct positions of the reference and current ROIs relative to the upper-left corner of the matching window for proper pixel correspondence.

[0064] In a second embodiment, the definitions of the ref_region_xxx_offset[] and scaled_ref_region_xxx_offset[] offsets may be redefined to combine both the fitting window offset and the ROI offset (e.g., by adding them together). For example, in Table 5, scaled_ref_layer_xxx_offset may be replaced by scaled_ref_layer_xxx_offset_sum, which is defined as follows:

number

[0065] Similar definitions can be generated for ref_region_xxx_offset_sum, where xxx=bottom, top, left, and right. As will be explained, the processing in step 615 may be combined with the processing in step 625, so that these parameters allow the decoder to skip step 615.

[0066] For example, in FIG. a) In step 615, PicOutputWidthL may be calculated by subtracting the adaptive window left and right offsets from the picture width (see, for example, equation (7-43)). b) Let fCurWidth = PicOutputWidthL. c) Next, in step 625, we adjust fCurWidth (e.g., see (8-x3)) by subtracting the ScaledRefLayer left and right offsets, which from equation (7-xx) are based on the scaled_ref_layer left and right offsets. For example, considering that we are now only adjusting the width of the ROI, in simplified notation (i.e., by ignoring the SubWidthC scaling parameter), this can be calculated as follows: Picture Output Width = Picture Width -(Fit window left offset + Fit window right offset) (2) ROI current width = picture output width - (ROI current left offset + ROI current right offset) (3) By combining equations (2) and (3) together: ROI current width = Picture Width -((Fit window left offset + ROI current left offset) + (Fit window right offset + ROI current right offset)) (4)

[0067] If we assume the following: ROI current left total offset = fitting window left offset + ROI current left offset ROI current right total offset = fit window right offset + ROI current right offset Equation (4) can be simplified as follows: ROI current width = picture width - ((ROI current left total offset) + (ROI current right total offset)) (5) The definition of the new "sum" offset (eg, ROI current left sum offset) corresponds to the definition of ref_region_left_offset_sum defined in equation (1).

[0068] Thus, if we redefine the scaled_ref_layer left and right offsets to include the sum of the layer's conf_win_left_offset, as described above, we proceed to blocks 615 and 625 and calculate the width and height of the current and reference ROIs (e.g., equations (2) and (3) can be combined into one (e.g., equation (5))) (e.g., step 630).

[0069] As shown in Figure 6B, steps 615 and 625 can be combined into a single step 630. Compared to Figure 6A, this approach saves some additions, but the revised offsets (e.g., scaled_ref_layer_left_offset_sum[]) are now larger quantities and therefore they require more bits to be coded in the bitstream. Note that the conf_win_xxx_offset values ​​may be different for each layer and these values ​​can be extracted by the PPS information in each layer.

[0070] In a third embodiment, the horizontal and vertical scale factors (e.g., hori_scale_fp and vert_scale_fp) may be explicitly signaled between interlayer pictures. In such a scenario, the horizontal and vertical scale factors, as well as the top and left offsets, need to be communicated for each layer.

[0071] A similar approach is applicable to embodiments with pictures incorporating multiple ROIs, each with any upsampling and downsampling filters. <References> Each of the references cited herein is hereby incorporated by reference in its entirety. [1] High efficiency video coding, H.265, Series H, Coding of moving video, ITU, (02 / 2018) [2] B. Bross, J. Chen, and S. Liu, “Versatile Video Coding (Draft 6),” JVET output document, JVET-O2001, vE, uploaded July 31, 2019 [3] S. Wenger, et al., “AHG8: Spatial scalability using reference picture resampling,” JVET-O0045, JVET Meeting, Gothenburg, SE, July 2019 [4] R. Skupin et al., AHG12: “On filtering of independently coded region,” JVET-O0494 (v3), JVET Meeting, Gothenburg, SE, July 2019 Exemplary Computer System Implementation Embodiments of the invention may be implemented by a computer system, a system configured in electronic circuits and components, an integrated circuit (IC) device such as a microcontroller, a field programmable gate array (FPGA) or other configurable or programmable logic device (PLD), a discrete time or digital signal processor (DSP), an application specific IC (ASIC), and / or an apparatus including one or more of such systems, devices, or components. The computer and / or IC may execute, control, or perform instructions related to the drawing surface size scalability as described herein. The computer and / or IC may calculate any of the various parameters or values ​​related to the drawing surface size scalability as described herein. Image and video embodiments may be implemented in hardware, software, firmware, and various combinations thereof.

[0072] A particular implementation of the present invention includes a computer processor executing software instructions that cause the processor to perform the method of the present invention. For example, one or more processors in a display, an encoder, a set-top box, a transcoder, etc. may perform the above-mentioned method related to the drawing surface size scalability by executing software instructions in a program memory accessible to the processor. An embodiment of the present invention b may be provided in the form of a program product. The program product may include any non-transitory tangible medium that carries a set of computer-readable signals that include instructions that, when executed by a data processor, cause the data processor to perform the method of the present invention. A program product according to the present invention may be in any of a variety of non-transitory tangible forms. The program product may include a physical medium, such as, for example, a magnetic data storage medium including a floppy disk, a hard disk drive, an optical data storage medium including a CD-ROM, a DVD, an electronic data storage medium including a ROM, a flash RAM, etc. The computer-readable signals on the program product may be optically compressed or encrypted.

[0073] Although components (e.g., software modules, processors, components, devices, circuits, etc.) have been referred to above, unless otherwise indicated, references to those components (including references to "means") should be interpreted to include equivalents of those components, any components that perform the functions of the described components (e.g., are functionally equivalent), and components that are not structurally equivalent to the disclosed structures that perform the functions in the illustrated exemplary embodiments of the present invention.

[0074] <Equivalents, Extensions, Alternatives and Miscellaneous> Thus, exemplary embodiments related to drawing surface size scalability are described. In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. Thus, the sole and exclusive indication of what the invention is, and what the applicant intends to be the invention, is set forth in the claims issued in a particular form hereby, including any subsequent amendments. Any definitions expressly set forth herein for terms contained in such claims shall govern the meaning of such terms as used in the claims. Thus, any limitations, elements, features, advantages, or attributes not expressly set forth in the claims should not limit the scope of the claims in any manner. The specification and drawings should therefore be considered illustrative, and not restrictive.

Claims

1. 1. A device for decoding a coding bitstream, the device comprising: an input for receiving a coding bitstream; a processor for processing coded pictures in the coding bitstream; and for a current picture in the coding bitstream, the processor: receiving a current picture width and a current picture height having unsigned integer values; receiving a first offset parameter that defines a rectangular extent on the current picture, the first offset parameter comprising a signed integer value; calculating a current extent width and a current extent height of the rectangular extent on the current picture based on the current picture width, the current picture height, and the first offset parameter; For a reference range, accessing a reference range width, a reference range height, a reference range left offset, and a reference range top offset, and accessing the reference range width and the reference range height means, for a reference picture, Access the reference picture width and reference picture height; receiving a second offset parameter that defines a rectangular extent within the reference picture, the second offset parameter comprising a signed integer value; calculating the reference range width and the reference range height of the rectangular range within the reference picture based on the reference picture width, the reference picture height, and the second offset parameter; Calculating the reference range left offset and the reference range top offset based on the second offset parameter; Including, Calculate the horizontal scale factor (hori_scale_fp) and vertical scale factor (vert_scale_fp) as follows: [0010] fRefWidth represents the reference range width, fCurWidth represents the current range width, fRefHeight represents the reference range height, and fCurHeight represents the current range height; Calculating a left offset adjustment and a top offset adjustment for the current range based on the first offset parameter; The apparatus performs motion compensation based on the horizontal scale factor, the vertical scale factor, the left offset adjustment, the top offset adjustment, the reference range left offset, and the reference range top offset.

2. The apparatus of claim 1 , wherein the first offset parameters include a left offset, a top offset, a right offset, and a bottom offset.

3. One or more of the left offset, the top offset, the right offset, or the bottom offset is −2 １４ From 2 １４ 3. The device of claim 2, having a value between

Images