Signaling reference picture resampling in the video bitstream together with the resampling picture size indication

Abstract

To provide a reference picture resampling method in a method, device and computer-readable medium for decoding a video bitstream.SOLUTION: The method includes: obtaining a first flag indicating that a conformance window is present in a current picture; on the basis of the first flag, obtaining a second flag indicating whether the conformance window is used for reference picture resampling; if the second flag indicates that the conformance window is used for the reference picture resampling, then determining a resampling ratio between the current picture and a reference picture on the basis of the conformance window size; and, if the second flag indicates that the conformance window is not used for the reference picture resampling, then determining the resampling ratio on the basis of the resampling picture size.SELECTED DRAWING: Figure 10

Description

[Background technology]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Application No. 62 / 903,639, filed September 20, 2019, U.S. Provisional Application No. 62 / 905,319, filed September 24, 2019, and U.S. Patent Application No. 17 / 010,163, filed September 2, 2020, each of which is incorporated herein in its entirety.

[0002] Technical Field The subject matter disclosed relates to video coding and decoding, and more particularly to signaling reference picture resampling with a resampling picture size indication.

[0003] Background technology Video coding and decoding utilizing inter-picture prediction with motion compensation is known. Uncompressed digital video may consist of a sequence of pictures, each having a spatial dimension of, for example, 1920x1080 luminance samples and associated chrominance samples. The sequence of pictures may have a constant or variable picture rate (also informally known as frame rate), for example, 60 pictures per second, i.e., 60 Hz. Uncompressed video has significant bitrate requirements. For example, 1080p60 4:2:0 video (1920x1080 luminance sample resolution at 60 Hz frame rate) at 8 bits per sample requires a bandwidth approaching 1.5 Gbit / s. One hour of such video requires more than 600 Gbytes of storage space.

[0004] One goal of video coding and decoding may be to reduce redundancy in the input video signal by compression. Compression may help reduce the aforementioned bandwidth or storage space requirements, in some cases by more than two orders of magnitude. Both lossless and non-lossless compression, as well as combinations thereof, may be used. Lossless compression refers to techniques where an exact copy of the original signal can be reconstructed from the compressed original signal. When using non-lossless compression, the reconstructed signal may not be identical to the original signal, but the distortion between the original and reconstructed signals is small enough to make the reconstructed signal useful for the intended application. For video, non-lossless compression is widely used. The amount of tolerable distortion depends on the application, for example, a user of a particular consumer streaming application may tolerate higher distortion than a user of a television-serving application. The achievable compression ratio may reflect that a higher tolerable / bearable distortion may result in a higher compression ratio.

[0005] Video encoders and decoders can utilize a number of broad categories of techniques, including motion compensation, transform, quantization, and entropy coding, some of which are introduced below.

[0006] Historically, video encoders and decoders have tended to work with a given picture size, which in most cases remains fixed and constant for a coded video sequence (CVS), group of pictures (GOP), or similar multi-picture time frame. For example, in MPEG-2, system designs are known to vary the horizontal resolution (and therefore the picture size) depending on factors such as scene activity, but only in I-pictures and thus typically for GOPs. Resampling of reference pictures to use different resolutions within a CVS is known, for example, from ITU-T Rec. H.263AnnexP. However, in this case the picture size remains the same, and only the reference pictures are resampled, which may result in only a portion of the picture canvas being used (in the case of downsampling) or only a portion of the scene being used (in the case of upsampling). Furthermore, H.263AnnexQ allows individual macroblocks (in each dimension) to be resampled upwards or downwards by a factor of two. Again the picture size remains the same: the macroblock size is fixed in H.263 and therefore does not need to be signaled.

[0007] In modern video coding, picture size changes of predicted pictures are becoming more and more mainstream. For example, VP9 allows resolution changes of the whole picture and reference picture resampling. Similarly, some proposals made for VVC (see, e.g., Hendry, et. al, “On adaptive resolution change (ARC) for VVC”, Joint Video Team document JVET-M0135-v1, Jan 9-19, 2019, incorporated herein in its entirety) allow resampling of the whole reference picture to a different—higher or lower—resolution. In that document, it is suggested that different resolution candidates be coded in the sequence parameter set and referenced by per-picture syntax elements in the picture parameter set. Summary of the Invention

[0008] In an embodiment, a method for decoding an encoded video bitstream using at least one processor is provided, the method comprising the steps of: obtaining a first flag indicating the presence of a conformance window in a current picture; obtaining a second flag indicating whether the conformance window is used for reference picture resampling based on the first flag indicating the presence of a conformance window; determining a resampling ratio between the current picture and the reference picture based on a conformance window size of the conformance window based on the second flag indicating the conformance window is used for the reference picture resampling; determining a resampling ratio based on a resampling picture size based on the second flag indicating the conformance window is not used for reference picture resampling; and performing the reference picture resampling on the current picture using the resampling ratio.

[0009] In an embodiment, an apparatus is provided for decoding an encoded video bitstream, the apparatus including at least one memory configured to store program code; and at least one processor configured to load the program code and operate as instructed by the program code, the program code comprising: first obtaining code configured to cause the at least one processor to obtain a first flag indicating a presence of a conformance window in a current picture; second obtaining code configured to cause the at least one processor to obtain a second flag indicating whether a conformance window is used for reference picture resampling based on the first flag indicating the presence of a conformance window; a first decision code configured to cause the at least one processor to determine a resampling ratio between the current picture and the reference picture based on a conformance window size of the conformance window based on a second flag indicating that the conformance window is not used for reference picture resampling; and a second decision code configured to cause the at least one processor to determine a resampling ratio based on a resampling picture size based on a second flag indicating that the conformance window is not used for reference picture resampling; and an execution code configured to cause the at least one processor to perform reference picture resampling on the current picture using the resampling ratio.

[0010] In an embodiment, a non-transitory computer-readable medium is provided that stores instructions, which when executed on one or more processors of an apparatus for decoding an encoded video bitstream, cause the one or more processors to perform the steps of: obtaining a first flag indicating a conformance window exists for a current picture; obtaining a second flag indicating whether the conformance window is used for reference picture resampling based on the first flag indicating the conformance window exists; determining a resampling ratio between the current picture and the reference picture based on a conformance window size of the conformance window based on the second flag indicating the conformance window is used for reference picture resampling; determining a resampling ratio based on a resampling picture size based on the second flag indicating the conformance window is not used for reference picture resampling; and performing reference picture resampling for the current picture using the resampling ratio. [Brief description of the drawings]

[0011] Further features, nature and various advantages of the disclosed subject matter will become more apparent from the following detailed description and the accompanying drawings.

[0012] [Figure 1] FIG. 1 is a schematic diagram of a simplified block diagram of a communication system according to an embodiment.

[0013] [Diagram 2] FIG. 1 is a schematic diagram of a simplified block diagram of a communication system according to an embodiment.

[0014] [Diagram 3] FIG. 2 is a schematic diagram of a simplified block diagram of a decoder according to an embodiment;

[0015] [Figure 4]FIG. 2 is a schematic diagram of a simplified block diagram of an encoder according to an embodiment;

[0016] [Diagram 5] FIG. 13 is a schematic diagram of options for signaling ARC parameters according to an embodiment.

[0017] [Figure 6A] 1 is a schematic diagram of an example syntax table according to an embodiment. [Figure 6B] 1 is a schematic diagram of an example syntax table according to an embodiment.

[0018] [Figure 7] FIG. 1 is a schematic diagram of signaling picture size and conformance window in SPS according to an embodiment;

[0019] [Figure 8A] 1 is a schematic diagram of signaling picture size and conformance window in PPS according to an embodiment. [Figure 8B] 1 is a schematic diagram of signaling picture size and conformance window in PPS according to an embodiment.

[0020] [Figure 9] FIG. 1 is a schematic diagram of signaling resampling picture size in a PPS according to an embodiment.

[0021] [Figure 10] 1 is a flowchart of an exemplary process for decoding an encoded video bitstream according to an embodiment.

[0022] [Figure 11] 1 is a schematic diagram of a computer system according to an embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0023] FIG. 1 shows a simplified block diagram of a communication system (100) according to an embodiment of the present disclosure. The system (100) may include at least two terminals (110-120) interconnected via a network (150). For one-way transmission of data, a first terminal (110) may code video data at a local location for transmission to the other terminal (120) via the network (150). The second terminal (120) may receive the coded video data of the other terminal from the network (150), decode the coded data, and display the recovered video data. One-way data transmission is common in media serving applications and the like.

[0024] 1 shows a second pair of terminals (130, 140) provided to support bidirectional transmission of coded video, such as may occur during a video conference. For the bidirectional transmission of data, each terminal (130, 140) can code video data captured at a local location for transmission over the network (150) to the other terminal. Each terminal (130, 140) can also receive coded video data transmitted by the other terminal, can decode the coded data, and can display the recovered video data on a local display device.

[0025] In FIG. 1, the terminals (110-140) may be depicted as servers, personal computers, or smartphones, although the principles of the present disclosure are not so limited. Embodiments of the present disclosure find application in laptop computers, tablet computers, media players, and / or dedicated video conferencing devices. The network (150) represents any number of networks that transmit coded video data between the terminals (110-140), including, for example, wired and / or wireless communication networks. The communication network (150) may exchange data over circuit-switched and / or packet-switched channels. Exemplary networks include telecommunications networks, local area networks, wide area networks, and / or the Internet. For purposes of this description, the architecture and topology of the network (150) may not be important to the operation of the present disclosure, unless otherwise described below.

[0026] Figure 2 illustrates the arrangement of video encoders and decoders in a streaming environment as an example application of the disclosed subject matter, which may be similarly applicable to other video-enabled applications including, for example, video conferencing, digital TV, storage of compressed video on digital media (including CDs, DVDs, memory sticks, etc.), etc.

[0027] The streaming system may include a capture subsystem (213) that may include a video source (201), such as a digital camera, that generates an uncompressed video sample stream (202). The sample stream (202) is depicted as a thick line to emphasize its higher data volume when compared to an encoded video bitstream and may be processed by an encoder (203) coupled to the camera (201). The encoder (203) may include hardware, software, or a combination thereof and may enable or effectuate aspects of the disclosed subject matter, as described in more detail below. The encoded video bitstream (204) is depicted as a thin line to emphasize its lower data volume when compared to the sample stream and may be stored at the streaming server (205) for future use. One or more streaming clients (206, 208) may access the streaming server (205) to retrieve copies (207, 209) of the encoded video bitstream (204). The client (206) may include a video decoder (210) that decodes an incoming copy of the encoded video bitstream (207) and generates a running video sample stream (211) that can be rendered on a display (212) or other rendering device (not shown). In some streaming systems, the video bitstreams (204, 207, 209) may be encoded according to a particular video coding / compression standard. Examples of these standards include ITU-T Recommendation H.265. A video coding standard informally known as Versatile Video Coding (VVC) is under development.

[0028] FIG. 3 may be considered as a functional block diagram of a video decoder (210) according to an embodiment of the present disclosure.

[0029] The receiver (310) may receive one or more codec video sequences to be decoded by the decoder (210), one coded video sequence at a time, in the same or another embodiment, in which case the decoding of each coded video sequence is independent of the other coded video sequences. The coded video sequences may be received from a channel (312), which may be a hardware / software link to a storage device that stores the coded video data. The receiver (310) may receive the coded video data together with other data, such as coded audio data and / or auxiliary data streams, which may be transferred using entities (not shown), respectively. The receiver (310) may separate the coded video sequences from the other data. To address network jitter, a buffer memory (315) may be coupled between the receiver (310) and the entropy decoder / parser (320) (hereafter referred to as the "parser"). If the receiver (310) is receiving data from a store-and-forward device with sufficient bandwidth and controllability, or from an isosynchronous network, the buffer (315) may not be needed or may be small. For use with best-effort packet networks such as the Internet, the buffer (315) may be needed and may be relatively large and advantageously of adaptive size.

[0030] The video decoder (210) may include a parser (320) for reconstructing symbols (321) from the entropy coded video sequence. These categories of symbols include information used to manage the operation of the decoder (210) and information that may control a rendering device such as a display (212) that is not an integral part of the decoder but may be coupled to the decoder, as shown in FIG. 3. The rendering device control information may be in the form of a Supplementary Enhancement Information (SEI) message or a Video Usability Information (VUI) parameter set fragment (not shown). The parser (320) may parse / entropy decode the received coded video sequence. The coding of the coded video sequence may follow any video coding technique or standard and may follow principles well known to those skilled in the art, including variable length coding, Huffman coding, arithmetic coding with or without context effects, etc. The parser (320) can extract a set of subgroup parameters for at least one of the subgroups of pixels in the video decoder from the coded video sequence based on the at least one parameter corresponding to the group. The subgroup can include a group of pictures (GOP), a picture, a subpicture, a tile, a slice, a brick, a macroblock, a coding tree unit (CTU), a coding unit (CU), a block, a transform unit (TU), a prediction unit (PU), etc. A tile can refer to a rectangular area of ​​a CU / CTU in a particular tile column and row in a picture. A brick can refer to a rectangular area of ​​a CU / CTU row (rows) in a particular tile. A slice can refer to one or more bricks of a picture included in the NAL unit. A subpicture can refer to a rectangular area of ​​one or more slices in a picture.The entropy decoder / parser can also extract information from the coded video sequence, such as transform coefficients, quantization parameter values, motion vectors, etc.

[0031] The parser (320) can perform entropy decoding / parsing operations on the video sequence received from the buffer (315) to create symbols (321).

[0032] The reconstruction of the symbols (321) may involve different units depending on the type of coded video picture or portion thereof (e.g., inter-picture, intra-picture, inter-block, intra-block) and other factors. Which units are involved and how can be controlled by subgroup control information parsed by the parser (320) from the coded video sequence. The flow of such subgroup control information between the parser (320) and subsequent units is not depicted for clarity.

[0033] Beyond the functional blocks already mentioned, the decoder 210 can be conceptually subdivided into a number of functional units as described below. In a practical implementation operating under commercial constraints, many of these units will interact closely with each other and may be at least partially integrated with each other. However, for purposes of describing the disclosed subject matter, the following conceptual subdivision into functional units is adequate.

[0034] The first unit is a scalar / inverse transform unit (351), which receives the quantized transform coefficients as well as control information, including which transform to use, block size, quantization coefficients, quantization scaling matrix, etc., as symbols (321) from the parser (320). It is capable of outputting blocks containing sample values ​​that can be input to an aggregator (355).

[0035] In some cases, the output samples of the scalar / inverse transform (351) may be associated with intra-coded blocks, i.e. blocks that do not use prediction information from a previously reconstructed picture, but may use prediction information from a previously reconstructed part of the current picture. Such prediction information may be provided by an intra picture prediction unit (352). In some cases, the intra picture prediction unit (352) uses surrounding already reconstructed information taken from the current (partially reconstructed) picture (358) to generate blocks of the same size and shape of the block being reconstructed. The aggregator (355) adds, possibly on a sample-by-sample basis, the prediction information generated by the intra prediction unit (352) to the output sample information as provided by the scalar / inverse transform unit (351).

[0036] In other cases, the output samples of the scalar / inverse transform unit (351) may relate to an inter-coded, potentially motion-compensated block. In such cases, the motion compensation prediction unit (353) may access the reference picture memory (357) to retrieve samples used for prediction. After motion compensating the retrieved samples according to the symbols (321) associated with the block, these samples may be added by the aggregator (355) to the output of the scalar / inverse transform unit (in this case referred to as residual samples or residual signals) to generate output sample information. In the case where the motion compensation unit retrieves prediction samples, the addresses in the reference picture memory structure may be controlled by motion vectors available to the motion compensation unit, for example in the form of symbols (321) that may have X, Y, and reference picture components. Motion compensation may also include interpolation of sample values ​​fetched from the reference picture memory, motion vector prediction mechanisms, etc., in the case where sub-sample exact motion vectors are used.

[0037] The output samples of the aggregator (355) may be subjected to various loop filtering techniques in a loop filter unit (356). Video compression techniques may include in-loop filter techniques, controlled by parameters contained in the coded video bitstream and made available to the loop filter unit (356) as symbols (321) from the parser (320), which may be responsive to meta-information obtained during the decoding of a previous part (in decoding order) of the coded picture or coded video sequence, and may also be responsive to previously reconstructed loop filtered sample values.

[0038] The output of the loop filter unit (356) may be a sample stream that may be output to a rendering device (212) and may be stored in a reference picture memory for use in future inter-picture prediction.

[0039] Some coded pictures, once fully reconstructed, can be used as reference pictures for future prediction. Once a coded picture is fully reconstructed and the coded picture has been identified as a reference picture (e.g., by the parser (320)), the current reference picture (358) can become part of the reference picture buffer (357), and a new current picture memory can be reallocated before starting the reconstruction of a future coded picture.

[0040] The video decoder 210 may perform decoding operations according to a given video compression technique, which may be documented in a standard such as ITU-T Rec. H.265. The coded video sequence may conform to the syntax defined by the video compression technique or standard being used, in the sense that the coded video sequence conforms to the syntax of the video compression technique or standard as defined in the video compression technique document or standard, and in particular in a profile document therein. Also, a requirement for compliance may be that the complexity of the coded video sequence is within a range defined by the level of the video compression technique or standard. In some cases, the level limits the maximum picture size, maximum frame rate, maximum reconstruction sample rate (e.g., measured in megasamples per second), maximum reference picture size, etc. The limits set by the level may be further limited, in some cases, by metadata for HRD buffer management and hypothetical reference decoder (HRD) specifications signaled in the coded video sequence.

[0041] In an embodiment, the receiver (310) may receive additional (redundant) data along with the encoded video. The additional data may be included as part of the coded video sequence. The additional data may be used by the video decoder (210) to properly decode the data and / or to more accurately reconstruct the original video data. The additional data may be, for example, temporal, spatial, or in the form of SNR enhancement layers, redundant slices, redundant pictures, forward error correction codes, etc.

[0042] FIG. 4 may be considered as a functional block diagram of a video encoder (203) according to an embodiment of the present disclosure.

[0043] The encoder (203) can receive video samples from a video source (201) (not part of the encoder) capable of capturing video images to be coded by the encoder (203).

[0044] The video source (201) may provide a source video sequence to be coded by the encoder (203) in the form of a digital video sample stream that may be of any suitable bit depth (e.g., 8-bit, 10-bit, 12-bit, ...), any color space (e.g., BT.601 YCrCB, RGB, ...) and any suitable sampling structure (e.g., YCrCb 4:2:0, YCrCb 4:4:4). In a media serving system, the video source (201) may be a storage device that stores previously prepared video. In a video conferencing system, the video source (203) may be a camera that captures local image information as a video sequence. The video data may be provided as a number of individual pictures that convey motion when viewed in sequence. The pictures themselves may be organized as a spatial array of pixels, each pixel may contain one or more samples depending on the sampling structure, color space, etc. in use. Those skilled in the art can easily understand the relationship between pixels and samples. The following description focuses on samples.

[0045] According to an embodiment, the encoder (203) can code and compress pictures of a source video sequence into a coded video sequence (443) in real-time or under any other time constraint required by the application. Imposing an appropriate coding rate is one function of the controller (450). The controller controls and is functionally coupled to other functional units as described below, whose coupling is not depicted for clarity. Parameters set by the controller can include rate control related parameters (picture skip, quantizer, lambda value for rate distortion optimization techniques, ...), picture size, group of pictures (GOP) layout, maximum motion vector search range, etc. One skilled in the art can easily identify other functions of the controller (450) as they may be relevant to a video encoder (203) optimized for a particular system design.

[0046] Some video encoders operate in what one skilled in the art would readily recognize as a "coding loop." As an oversimplified explanation, the coding loop can consist of an encoding part with an encoder (430) (hereafter referred to as the "source coder") (responsible for generating symbols based on the input picture to be coded and reference pictures) and a (local) decoder (433) built into the encoder (203) that reconstructs the symbols to create sample data that a (remote) decoder will also create (since in the video compression techniques contemplated by the disclosed subject matter, any compression between the symbols and the coded video bitstream is lossless). The reconstructed sample stream is input to a reference picture memory (434). Since the decoding of the symbol stream produces bit-exact results independent of the location of the decoder (local or remote), the contents of the reference picture buffer are also bit-exact between the local and remote encoders. In other words, the prediction part of the encoder "sees" exactly the same sample values ​​as the reference picture samples that the decoder would "see" if it used prediction during decoding. This basic principle of reference picture synchrony (if synchrony cannot be maintained, e.g. due to channel errors, drift will result) is well known to those skilled in the art.

[0047] The operation of the "local" decoder (433) may be the same as that of the "remote" decoder (210), which has already been described in detail in relation to Figure 3. However, briefly referring to Figure 4, since symbols are available and the encoding / decoding of symbols by the entropy coder (445) and parser (320) for the coded video sequence may be lossless, the entropy decoding portion of the decoder (210), including the channel (312), receiver (310), buffer (315) and parser (320), may not be fully implemented in the local decoder (433).

[0048] An insight that can be made at this point is that any decoder technique present in the decoder, with the exception of analysis / entropy decoding, must necessarily be present in the corresponding encoder, in substantially the same functional form. For this reason, the disclosed subject matter focuses on the operation of the decoder. A description of the encoder techniques can be omitted, since they are the inverse of the decoder techniques, which are described generically. Only in certain areas are more detailed descriptions required, and are provided below.

[0049] As part of its operation, the source coder (430) can perform motion-compensated predictive coding, which predictively codes an input frame with reference to one or more previously coded frames from the video sequence designated as “reference frames.” In this manner, the coding engine (432) codes differences between pixel blocks of the input frame and pixel blocks of the reference frames that can be selected as predictive references for the input frame.

[0050] The local video decoder (433) can decode the coded video data of frames that may be designated as reference frames based on the symbols generated by the source coder (430). The operation of the coding engine (432) can advantageously be a lossless process. When the coded video data is decoded by a video decoder (not shown in FIG. 4), the reconstructed video sequence may be a replica of the source video sequence, typically with some errors. The local video decoder (433) can replicate the decoding process that may be performed by the video decoder on the reference frames, and cause the reconstructed reference frames to be stored in the reference picture cache (434). In this way, the encoder (203) can store copies of locally reconstructed reference frames that have common content with the reconstructed reference frames obtained by the far-end video decoder (in the absence of transmission errors).

[0051] The predictor (435) can perform a prediction search for the coding engine (432). That is, for a new frame to be coded, the predictor (435) can search the reference picture memory (434) for sample data (as candidate reference pixel blocks) or specific metadata (e.g., reference picture motion vectors, block shapes, etc.) that may serve as suitable prediction references for the new picture. The predictor (435) can operate block-by-block on the samples to find suitable prediction references. In some cases, as determined by the search results obtained by the predictor (435), the input picture may have prediction references drawn from multiple reference pictures stored in the reference picture memory (434).

[0052] The controller (450) can manage the coding operations of the video coder (430), including, for example, setting the parameters and subgroup parameters used to encode the video data.

[0053] The output of all the aforementioned functional units may be subjected to entropy coding in an entropy coder (445), which converts the symbols produced by the various functional units into a coded video sequence by losslessly compressing the symbols according to techniques known to those skilled in the art, such as, for example, Huffman coding, variable length coding, arithmetic coding, etc.

[0054] The transmitter (440) can buffer the coded video sequence as produced by the entropy coder (445) and prepare it for transmission over a communication channel (460), which can be a hardware / software link to a storage device that stores the coded video data. The transmitter (440) can merge the coded video data from the video coder (430) with other data to be transmitted, such as coded audio data and / or auxiliary data streams (sources not shown).

[0055] The controller (450) can manage the operation of the encoder (203). During coding, the controller (450) can assign a particular coded picture type to each coded picture, which can affect the coding technique that can be applied to the individual picture. For example, pictures can often be designated as one of the following frame types:

[0056] An intra picture (I-picture) may be one that can be coded and decoded without using any other frame in a sequence as a source of prediction. Some video codecs allow different types of intra pictures, including, for example, independent decoder refresh pictures. Those skilled in the art are aware of these variations of I-pictures, as well as their respective uses and characteristics.

[0057] A predictive picture (P-picture) may be one that can be encoded and decoded using intra- or inter-prediction, using at most one motion vector and reference index to predict the sample values ​​of each block.

[0058] Bidirectionally predicted pictures (B-pictures) may be those that can be encoded and decoded using intra- or inter-prediction, using up to two motion vectors and reference indices to predict the sample values ​​of each block. Similarly, multiple predicted pictures can use more than two reference pictures and associated metadata for the reconstruction of a block.

[0059] A source picture is usually spatially divided into several sample blocks (e.g., 4x4, 8x8, 4x8, or 16x16 blocks of samples each) and can be coded block by block. Blocks can be predictively coded with reference to other (already coded) blocks as determined by the coding assignment applied to the respective picture of the block. For example, blocks of I pictures can be non-predictively coded or they can be predictively coded (spatial or intra-predicted) with reference to already coded blocks of the same picture. Pixel blocks of P pictures can be non-predictively coded with spatial prediction with reference to one previously coded reference picture or with temporal prediction. Blocks of B pictures can be non-predictively coded with spatial prediction with reference to one or two previously coded reference pictures or with temporal prediction.

[0060] The video coder (203) may perform coding operations according to a given video coding technique or standard, such as ITU-T Rec. H.265. During operation, the video coder (203) may perform various compression operations, including predictive coding operations that exploit temporal and spatial redundancies in the input video sequence. Thus, the coded video data may conform to a syntax specified by the video coding technique or standard being used.

[0061] In an embodiment, the transmitter (440) can transmit additional data along with the encoded video. The video coder (430) can include such data as part of the coded video sequence. The additional data can include temporal / spatial / SNR enhancement layers, other forms of redundant data such as redundant pictures and slices, Supplemental Enhancement Information (SEI) messages, Visual Usability Information (VUI) parameter set fragments, etc.

[0062] Recently, the compression domain aggregation or extraction of multiple semantically independent picture parts into a single video picture has attracted attention. In particular, for example in the context of 360 coding or certain surveillance applications, multiple semantically independent source pictures (e.g., six cubic surfaces of a cube-projected 360 scene, or individual camera inputs in case of a multi-camera surveillance setup) may require separate adaptive resolution settings to deal with the various scene-wise activities at a given time point. In other words, an encoder may choose to use different resampling factors for the different semantically independent pictures that make up the entire 360 ​​or surveillance scene at a given time point. If they are to be combined into a single picture, it requires that reference picture resampling is performed and adaptive resolution coding signaling is available for the parts of the coded picture.

[0063] The following introduces several terms that will be referenced in the remainder of this description.

[0064] A sub-picture may refer to a rectangular array of samples, possibly for samples, blocks, macroblocks, coding units, or similar entities that are semantically grouped and may be coded independently at a changed resolution. One or more sub-pictures may form a picture. One or more coded sub-pictures may form a coded picture. One or more sub-pictures may be assembled into a picture and one or more sub-pictures may be derived from a picture. In certain circumstances, one or more coded sub-pictures may be assembled in the compressed domain without transcoding the sample level into the coded picture, and in the same or other cases, one or more coded sub-pictures may be derived from a coded picture in the compressed domain.

[0065] Reference Picture Resampling (RPR) or Adaptive Resolution Change (ARC) may refer to mechanisms that allow changing the resolution of pictures or sub-pictures in a coded video sequence, for example by reference picture resampling. Hereinafter, RPR / ARC parameters refer to the control information needed to perform adaptive resolution change, which may include, for example, filter parameters, scaling factors, output and / or reference picture resolutions, various control flags, etc.

[0066] In an embodiment, coding and decoding may be performed on a single semantically independent coded video picture. Before describing the additional complexities of the meaning and implications of coding / decoding multiple sub-pictures with independent RPR / ARC parameters, options for signaling the RPR / ARC parameters shall be described.

[0067] With reference to Figures 5A-5E, several embodiments for signaling RPR / ARC parameters are shown. As mentioned in each of the embodiments, they may have certain advantages and certain disadvantages in terms of coding efficiency, complexity, and architecture. A video coding standard or technology may select one or more of these embodiments, or options known from the related art, for signaling RPR / ARC parameters. The embodiments may not be mutually exclusive and may be interchanged as far as possible based on the needs of the application, the related standardization technology, or the choice of the encoder.

[0068] RPR / ARC parameter classes may include:

[0069] -Up / downsampling factors, separate or combined in X and Y dimensions.

[0070] - Up / Down sample factor, which adds a time dimension and indicates a constant speed of zooming in / out for a given number of pictures.

[0071] Either of the above two may involve the coding of one or more possibly short syntax elements capable of pointing to a table containing the factors.

[0072] Resolution, in the X or Y dimension in units of samples, blocks, macroblocks, coding units (CUs), or any other suitable granularity, for each or a combination of input pictures, output pictures, reference pictures, coded pictures. If there is more than one resolution (e.g., one for input pictures and one for reference pictures), in some cases one set of values ​​may be inferred from another set of values. These can be gated, for example, by using flags. See below for more detailed examples.

[0073] - "warping" coordinates, similar to those used in H.263 AnnexP, again at the appropriate granularity as described above. H.263 AnnexP specifies one efficient way to code such warping coordinates, but other, potentially more efficient ways are possible. The variable-length, reversible "Huffman"-style coding of AnnexP warping coordinates could be replaced by an appropriate-length binary coding, in which the length of the binary code words is derived, for example, from the maximum picture size by offsetting it by a particular value, possibly multiplied by a particular factor, to allow "warping" outside the bounds of the maximum picture size.

[0074] -Up- or downsample filter parameters. In embodiments, there may be only a single filter for up- and / or downsampling. However, in embodiments, it may be desirable to allow more flexibility in filter design, which may require signaling of filter parameters. Such parameters may be selected by an index in a list of possible filter designs, the filter may be fully specified (e.g., by a list of filter coefficients, using an appropriate entropy coding technique), or the filter may be selected implicitly by the up / downsample ratio signaled according to any of the mechanisms described above.

[0075] In the following, the description assumes the coding of a finite set of up / down sample factors (the same factors used in both X and Y dimensions) specified by a codeword. This codeword can be variable length coded, for example using Ext-Golomb codes common to certain syntax elements in video coding specifications such as H.264 and H.265. One suitable mapping of values ​​to up / down sample factors can be, for example, according to Table 1: Table 1 [Table 1]

[0076] Many similar mappings can be devised, depending on the needs of the application and the capabilities of the up- and down-scaling mechanisms available in video compression techniques and standards. The table can be extended to many more values. The values ​​can also be represented by entropy coding mechanisms other than the Ext-Golomb code, for example using binary coding. This may have certain advantages if the resampling factor is of concern outside the video processing engine itself (encoder and decoder are the most important), for example by a MANE. In situations where no change of resolution is required, it is possible to choose a short Ext-Golomb code; note that in the above table, it is only one bit. This may have coding efficiency advantages over using a binary code for the most common cases.

[0077] The number of entries in a table, and their semantics, may be fully or partially configurable. For example, a basic overview of the table may be conveyed in a "high" parameter set, such as a sequence or decoder parameter set. In an embodiment, one or more such tables may be specified in a video coding technology or standard and may be selected, for example, through a decoder or sequence parameter set.

[0078] In the following, we will explain how the upsample / downsample factors (ARC information) coded as described above can be included in a video coding technique or standard syntax. Similar considerations can be applied to one or several codewords that control an up / downsample filter. If a relatively large amount of data is required for a filter or other data structure, please refer to the following explanation.

[0079] As shown in Figure 5, H.263 Annex P includes ARC information (502) in the form of four warping coordinates in the picture header (501), specifically in the H.263 PLUSPTYPE (503) header extension. This may be a wise design choice when a) there is a picture header available and b) frequent changes of the ARC information are expected. However, the overhead when using H.263-style signaling may be quite large, and since picture headers may be of a temporal nature, scaling factors may not be involved between picture boundaries.

[0080] In the same or another embodiment, the signaling of ARC parameters may follow detailed example outlined in Figures 6A-6B, which show syntax diagrams in a type of representation using a notation that generally follows C-style programming, e.g., as used in video coding standards since at least 1993. Bold lines indicate syntax elements present in the bitstream, while non-bold lines often indicate control flow or variable settings.

[0081] As shown in Fig. 6A, the Tile Group Header (601) as an example syntax structure for a header applicable to a portion of a (possibly rectangular) picture can conditionally contain a variable-length Exp-Golomb coded syntax element dec_pic_size_idx (602) (bold). The presence of this syntax element in the Tile Group Header can be gated by the use of Adaptive Resolution (603) - by the value of a flag not depicted here in bold, which means that the flag is present in the bitstream at the point where it occurs in the syntax diagram. Whether adaptive resolution is used for this picture or its portion can be signaled in any high-level syntax structure inside or outside the bitstream. In the illustrated example, it is signaled in the sequence parameter set, as outlined below.

[0082] Referring to FIG. 6B, an excerpt of a sequence parameter set (610) is shown. The first syntax element shown is adaptive_pic_resolution_change_flag (611). If true, that flag can specify that adaptive resolution will be used, which may require specific control information. In this example, such control information is conditionally present based on the value of the flag based on an if() statement in the parameter set (612) and the tile group header (601).

[0083] If adaptive resolution is in use, in this example the output resolution is coded in samples (613). The number 613 may refer to both output_pic_width_in_luma_samples and output_pic_height_in_luma_samples, which together specify the resolution of the output picture. Somewhere in the video coding technology or standard it may specify certain constraints on either value. For example, the level specification may limit the total number of output samples that can be the product of the values ​​of these two syntax elements. Also, a particular video coding technology or standard, or an external technology or standard, e.g. a system standard, may limit the range of numbers (e.g. one or both dimensions must be divisible by a power of two) or may limit the aspect ratio (e.g. width and height must have a relationship such as 4:3 or 16:9). Such restrictions may be introduced to facilitate hardware implementation or for other reasons and are well known in the art.

[0084] In certain applications, it may be desirable for an encoder to indicate to a decoder that a particular reference picture size is to be used, rather than implicitly assuming that that size is the output picture size. In this example, the syntax element reference_pic_size_present_flag (614) gates the conditional presence of reference picture dimensions (615) (again, the numbers refer to both width and height).

[0085] Finally, a table of possible decoded picture widths and heights is indicated. Such a table can be expressed, for example, by a table directive (num_dec_pic_size_in_luma_samples_minus1) (616). "minus1" indicates the interpretation of the syntax element's value. For example, if the coded value is zero, there is one table entry. If the value is 5, there are six table entries. For each "line" in the table, the decoded picture width and height are then included in the syntax (617).

[0086] The presented table entries (617) can be indexed using the syntax element dec_pic_size_idx (602) in the tile group header, thereby allowing for different decoded sizes (effectively zoom factors) per tile group.

[0087] Certain video coding techniques or standards, e.g., VP9, ​​support and enable spatial scalability by implementing a particular form of reference picture resampling (signaled quite differently in the disclosed subject matter) along with temporal scalability. In particular, certain reference pictures can be upsampled to higher resolutions using ARC-style techniques to form the basis of spatial enhancement layers. These upsampled pictures can then be refined using normal prediction mechanisms at higher resolutions, thus adding detail.

[0088] The embodiments described herein can be used in such environments. In certain cases, in the same or another embodiment, values ​​of the NAL unit header, e.g., the Temporal ID field, can be used to indicate not only temporal layers but also spatial layers. Doing so may have certain advantages for certain system designs; for example, existing Selective Transmission Units (SFUs) that are created and optimized for selective transmission of temporal layers based on the Temporal ID value of the NAL unit header can be used without modification for scalable environments. To enable this, there may be conditions on the mapping between coded picture sizes and temporal layers, specified by the Temporal ID field of the NAL unit header.

[0089] Recently, the compression domain aggregation or extraction of multiple semantically independent picture parts into a single video picture has attracted attention. In particular, for example in the context of 360 coding or certain surveillance applications, multiple semantically independent source pictures (e.g., six cubic surfaces of a cubic projected 360 scene, or individual camera inputs in case of a multi-camera surveillance setup) may require separate adaptive resolution settings to deal with the various scene-wise activities at a given time point. In other words, an encoder may choose to use different resampling factors for the different semantically independent pictures that make up the entire 360 ​​or surveillance scene at a given time point. If they are to be combined into a single picture, it requires that reference picture resampling is performed and adaptive resolution coding signaling is available for the parts of the coded picture.

[0090] In an embodiment, the conformance window may be a rectangular sub-part of the picture, and the encoder specifies that samples within the sub-part will be output by the decoder, while samples outside the window may be omitted from output by the decoder.

[0091] One issue we address here is that the conformance window may serve two purposes. One purpose is to dictate the output size as mentioned above. The output size may be application driven and may be quite different from the coded picture size, for example in stereoscopic or 360 cube map applications. The second purpose may be that the conformance window also inputs into the reference picture resampling mentioned above.

[0092] For both coded and resampled pictures, with certain combinations of conformance window size and picture size, samples outside the padding area may be referenced. This problem could be solved by a bitstream constraint on the size of the conformance window, but that solution would have the drawback that the conformance window is no longer freely selectable by the application. Separating the two functionalities may be advantageous in some applications.

[0093] In an embodiment, the conformance window size may be signaled in the PPS. The conformance window parameters can be used to calculate a resampling ratio when the conformance window size of a reference picture differs from that of the current picture. A decoder may need to know the conformance window size of each picture to determine if a resampling process is necessary.

[0094] In an embodiment, the scale factor for reference picture resampling (RPR) may be calculated based on the output width and output height between the current picture and the reference picture, which may be derived from the conformance window parameters. This may allow the scaling factor to be calculated more accurately compared to using the decoded picture size. This may work well for most video sequences, where the output picture size is approximately the same as the decoded picture size, with a small amount of padding.

[0095] However, this can also cause various problems. For example, for immersive media applications (e.g., 360 cube maps, stereoscopic, point clouds), if the conformance window size is quite different from the decoded picture size due to a large offset value, the calculation of the scaling factor based on the conformance window size may not guarantee the quality of inter prediction at different resolutions. In extreme cases, there may be no collocated region of the current CU in the reference picture. If RPR is used for multi-layer scalability, the conformance window offset may not be used to calculate the inter-layer referenced region. Note that the referenced region of each directly dependent layer is explicitly signaled in the PPS-extension in the HEVC scalability extension (SHVC). If a sub-bitstream targeting a specific region (sub-picture) is extracted from the whole bitstream, the conformance window size does not quite match the picture size. Note that once a bitstream is encoded, the conformance window parameters cannot be updated as long as the parameters are used in the scaling calculations.

[0096] Due to the potential issues mentioned above, the calculation of the scaling factor based on the conformance window size may have corner cases where alternative parameters are needed. As a fallback, it is proposed to signal reference region parameters that can be used to calculate the RPR and scalability scaling when the conformance window parameters are not used to calculate the scaling factors.

[0097] 7, in an embodiment, conformance_window_flag may be signaled in the PPS. A conformance_window_flag equal to 1 may specify that a conformance cropping window offset parameter follows in the PPS. A conformance_window_flag equal to 0 may specify that a conformance cropping window offset parameter is not present.

[0098] Continuing to refer to Figure 7, in an embodiment, conf_win_left_offset, conf_win_right_offset, conf_win_top_offset, and conf_win_bottom_offset specify the sample of the picture that references the PPS output by the decoding process in terms of a rectangular area specified in output picture coordinates. If 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 may be inferred to be equal to 0.

[0099] In an embodiment, the conformance cropping window may include luma samples with horizontal picture coordinates from SubWidthC * conf_win_left_offset to pic_width_in_luma_samples - ( SubWidthC * conf_win_right_offset + 1 ) and vertical coordinates from SubHeightC * conf_win_top_offset to pic_height_in_luma_samples - ( SubHeightC * conf_win_bottom_offset + 1 ), inclusive.

[0100] The value of SubWidthC * (conf_win_left_offset + conf_win_right_offset) may be smaller than pic_width_in_luma_samples, and the value of SubHeightC * (conf_win_top_offset + conf_win_bottom_offset) shall be smaller than pic_height_in_luma_samples.

[0101] The variables PicOutputWidthL and PicOutputHeightL may be derived as shown in the following equations (Equation 1) and (Equation 2): PicOutputWidthL = pic_width_in_luma_samples ― SubWidthC * (conf_win_right_offset + conf_win_left_offset) (Equation 1) PicOutputHeightL = pic_height_in_pic_size_units ― SubHeightC * (conf_win_bottom_offset + conf_win_top_offset) (Equation 2)

[0102] If ChromaArrayType is not equal to 0, the corresponding specified samples of the two chroma arrays may be samples with picture coordinates (x / SubWidthC, y / SubHeightC), where (x,y) are the picture coordinates of the specified luma sample.

[0103] In an embodiment, a flag may be present in the PPS or other parameter set to indicate whether the resampling picture size (width and height) is explicitly signaled in the PPS or other parameter set. If the resampling picture size parameter is explicitly signaled, the resampling ratio between the current picture and the reference picture may be calculated based on the resampling picture size parameter.

[0104] Referring to FIG. 8A, in an embodiment, use_conf_win_for_rpr_flag equal to 0 may specify that resampled_pic_width_in_luma_samples and resampled_pic_height_in_luma_samples follow next in the appropriate location, e.g., PPS.

[0105] In an embodiment, use_conf_win_for_rpr_flag equal to 1 may specify that resampling_pic_width_in_luma_samples and resampling_pic_height_in_luma_samples are not present.

[0106] In an embodiment, resampling_pic_width_in_luma_samples may specify the width, in units of luma samples, of each reference picture that references the PPS for resampling. resampling_pic_width_in_luma_samples may not be equal to 0, may be an integer multiple of Max(8, MinCbSizeY), and may be less than or equal to pic_width_max_in_luma_samples.

[0107] In an embodiment, resampling_pic_height_in_luma_samples may specify the height, in units of luma samples, of each reference picture that references the PPS for resampling. resampling_pic_height_in_luma_samples may not be equal to 0, may be an integer multiple of Max(8, MinCbSizeY), and may be less than or equal to pic_height_max_in_luma_samples.

[0108] If the syntax element resampling_pic_width_in_luma_samples is not present, the value of resampling_pic_width_in_luma_samples may be inferred to be equal to PicOutputWidthL.

[0109] If the syntax element resampling_pic_height_in_luma_samples is not present, the value of resampling_pic_height_in_luma_samples may be inferred to be equal to PicOutputHeightL.

[0110] In an embodiment, an example partial interpolation process with reference picture resampling may be processed as follows:

[0111] The inputs to this process may be: the luma position (xSb, ySb) specifying the top-left sample of the current coding sub-block relative to the top-left luma sample of the current picture, a variable sbWidth specifying the width of the current coding sub-block, a variable sbHeight specifying the height of the current coding sub-block, a motion vector offset mvOffset, a refined motion vector refMvLX, a selected reference picture sample array refPicLX, a half-sample interpolation filter index hpelIfIdx, a bidirectional optical flow flag bdofFlag, and a variable cIdx specifying the color component indexes of the current block.

[0112] The output of this process may be: predSamplesLX, a (sbWidth + brdExtSize) x (sbHeight + brdExtSize) array of predicted sample values.

[0113] The predicted block border extension size brdExtSize may be derived according to Equation 3: brdExtSize = ( bdofFlag | | ( inter_affine_flag[ xSb ][ ySb ] && sps_affine_prof_enabled_flag ) ) ? 2 : 0 (Equation 3)

[0114] The variable fRefWidth may be set equal to resampling_pic_width_in_luma_samples of the reference picture in luma samples.

[0115] The variable fRefHeight may be set equal to resampling_pic_height_in_luma_samples of the reference picture in luma samples.

[0116] The motion vector mvLX may be set equal to (refMvLX - mvOffset).

[0117] When cIdx is equal to 0, the scaling factors and their fixed point representations may be defined according to the following Equations 4 and 5: hori_scale_fp = ((fRefWidth << 14 ) + ( resampling_pic_width_in_luma_samples >> 1)) / resampling_pic_width_in_luma_samples (Equation 4) vert_scale_fp = ((fRefHeight << 14 ) + ( resampling_pic_height_in_luma_samples >> 1)) / resampling_pic_height_in_luma_samples (Equation 5)

[0118] Let (xIntL, yIntL) be the luma position given in full samples, and (xFracL, yFracL) be the offset given in 1 / 16 samples. These variables can be used to specify a fractional sample position within the reference sample array refPicLX.

[0119] The top-left coordinate ( xSbIntL, ySbIntL ) of the border block of the reference sample padding may be set equal to ( xSb + ( mvLX

[0000] >> 4 ), ySb + ( mvLX

[0001] >> 4 ) ).

[0120] For each luma sample position ( xL = 0..sbWidth ― 1 + brdExtSize, yL = 0..sbHeight ― 1 + brdExtSize ) in the predicted luma sample array predSamplesLX, the corresponding predicted luma sample value predSamplesLX[ xL ][ yL ] may be derived as follows: - ( refxSb L , refySbL ) and ( refx L , refy L ) is the luma position pointed to by the motion vector ( refMvLX, refMvLX ) given in 1 / 16 sample units. L , refx L , refySb L , and refy L may be derived as shown in Equations 6 through 9 below: refxSb L = ( ( xSb << 4 ) + refMvLX

[0000] ) * hori_scale_fp (Equation 6) refx L = ( ( Sign( refxSb ) * ( ( Abs( refxSb ) + 128 ) >> 8 ) + x L * ( ( hori_scale_fp + 8 ) >> 4 ) ) + 32 ) >> 6 (Equation 7) refySb L = ( ( ySb << 4 ) + refMvLX

[0001] ) * vert_scale_fp (Equation 8) refyL = ( ( Sign( refySb ) * ( ( Abs( refySb ) + 128 ) >> 8 ) + yL * ( ( vert_scale_fp + 8 ) >> 4 ) ) + 32 ) >> 6 (Equation 9) - Variable xInt L , yInt L , xFrac L and yFrac L may be derived as shown in Equations 10 through 13 below: xInt L =refx L >> 4 (Equation 10) yInt L= refy L >> 4 (Equation 11) xFrac L =refx L & 15 (Equation 12) yFrac L = refy L & 15 (Equation 13)

[0121] When bdofFlag is equal to TRUE or (sps_affine_prof_enabled_flag is equal to TRUE and inter_affine_flag[xSb][ySb] is equal to TRUE), and one or more of the following conditions are TRUE, the predicted luma sample values ​​predSamplesLX[xL][yL] may be derived by invoking the luma integer sample acquisition process with (xIntL + (xFracL >> 3) ― 1), yIntL + (yFracL >> 3) ― 1) as input: - xL equals 0. - xL equals sbWidth + 1. - yL is equal to 0. - yL equals sbHeight + 1.

[0122] Otherwise, the predicted luma sample values ​​predSamplesLX[ xL ][ yL ] are derived by invoking a luma sample 8-tap interpolation filtering process on inputs ( xIntL ― ( brdExtSize > 0 ? 1 : 0 ), yIntL ― ( brdExtSize > 0 ? 1 : 0 ) ), ( xFracL, yFracL ), ( xSbIntL, ySbIntL ), refPicLX, hpelIfIdx, sbWidth, sbHeight and ( xSb, ySb ).

[0123] Otherwise (if cIdx is not equal to 0), the following may apply:

[0124] Let (xIntC, yIntC) be the chroma position given in full samples, and (xFracC, yFracC) be the offset given in 1 / 32 samples. These variables can be used to specify a common fractional sample position within the reference sample array refPicLX.

[0125] The top-left coordinate ( xSbIntC, ySbIntC ) of the bounding box for the reference sample padding may be set equal to ( ( xSb / SubWidthC ) + ( mvLX

[0000] >> 5), ( ySb / SubHeightC ) + ( mvLX

[0001] >> 5 ) ).

[0126] For each chroma sample location (xC = 0..sbWidth - 1, yC = 0..sbHeight - 1) in the predicted chroma sample array preSamplesLX, the corresponding predicted chroma sample value preSamplesLX[xC][yC] may be derived as follows: - (refxSb C , refySb C ) and ( refx C , refy C ) is the chroma position that points to the motion vector (mvLX

[0000] , mvLX

[0001] ) given in 1 / 32 sample units. C , refySb C, refx C and refy C may be derived as shown in Equations 14 through 17 below: refxSb C = ( ( xSb / SubWidthC << 5 ) + mvLX

[0000] ) * hori_scale_fp (Equation 14) refx C = ( ( Sign( refxSbC ) * ( ( Abs( refxSb C ) + 256 ) >> 9 ) + xC * ( ( hori_scale_fp + 8 ) >> 4 ) ) + 16 ) >> 5 (Equation 15) refySb C = ( ( ySb / SubHeightC << 5 ) + mvLX

[0001] ) * vert_scale_fp (Equation 16) Refy C = ( ( Sign( refySb C ) * ( ( Abs( refySb C ) + 256 ) >> 9 ) + yC* ( (vert_scale_fp + 8 ) >> 4 ) ) + 16 ) >> 5 (Equation 17) - Variable xInt C , yInt C , xFrac C and yFrac C may be derived as shown in Equations 18 through 21 below: xInt C =refx C >> 5 (Equation 18) yInt C = refy C >> 5 (Equation 19) xFrac C = refy C & 31 (Equation 20) yFrac C = refy C & 31 (Equation 21)

[0127] The predicted sample values ​​predSamplesLX[xC][yC] may be derived by invoking a process with (xIntC, yIntC), (xFracC, yFracC), (xSbIntC, ySbIntC), sbWidth, sbHeight, and refPicLX as input.

[0128] 8B, in an embodiment, use_conf_win_for_rpr_flag equal to 0 may specify that resampled_pic_width_in_luma_samples and resampled_pic_height_in_luma_samples follow in the PPS. use_conf_wid_for_rpr_flag equal to 1 specifies that resampling_pic_width_in_luma_samples and resampling_pic_height_in_luma_samples are not present.

[0129] In an embodiment, ref_region_left_offset may specify the horizontal offset between the top-left luma sample of the reference region in the decoded picture. The value of ref_region_left_offset may be -2 14 ~2 14 It shall be in the inclusive range of -1. If not present, the value of ref_region_left_offset shall be inferred to be equal to conf_win_left_offset.

[0130] In an embodiment, ref_region_top_offset may specify the vertical offset between the top-left luma samples of the reference region in the decoded picture. The value of ref_region_top_offset may be -2 14 ~2 14 It shall be in the inclusive range of -1. If not present, the value of ref_region_top_offset shall be inferred to be equal to conf_win_right_offset.

[0131] In an embodiment, ref_region_right_offset may specify the horizontal offset between the bottom right luma samples of the reference region in the decoded picture. The value of ref_layer_right_offset may be -2 14 ~2 14 It shall be in the inclusive range of -1. If not present, the value of ref_region_right_offset shall be inferred to be equal to conf_win_top_offset.

[0132] In an embodiment, ref_region_bottom_offset may specify the vertical offset between the bottom-right luma samples of the reference region in the decoded picture. The value of ref_layer_bottom_offset may be -2 14 ~2 14 -1 inclusive. If not present, the value of ref_region_bottom_offset[ ref_loc_offset_layer_id[ i ] ] MAY be inferred to be equal to conf_win_bottom_offset.

[0133] The variables PicRefWidthL and PicRefHeightL may be derived as shown in Equations 22 through 23 below: PicRefWidthL = pic_width_in_luma_samples ― SubWidthC * (ref_region_right_offset + ref_region_left_offset) (Equation 22) PicRefHeightL = pic_height_in_pic_size_units ― SubHeightC * (ref_region_bottom_offset + ref_region_top_offset) (Equation 23)

[0134] The variable fRefWidth may be set equal to PicRefWidthL of the reference picture for the luma samples.

[0135] The variable fRefHeight may be set equal to PicRefHeightL of the reference picture for the luma samples.

[0136] The motion vector mvLX may be set equal to (refMvLX - mvOffset).

[0137] When cIdx is equal to 0, the scaling factors and their fixed point representations may be defined as shown in Equations 24 and 25 below: hori_scale_fp = ( ( fRefWidth << 14 ) + ( PicRefWidthL >> 1 ) ) / PicRefWidthL (Equation 24) vert_scale_fp = ( ( fRefHeight << 14 ) + ( PicRefHeightL >> 1 ) ) / PicRefHeight (Equation 25)

[0138] Top-left coordinate of the bounding box for the reference sample padding ( xSbInt L , ySbInt L ) may be set equal to (xSb + (mvLX

[0000] >> 4), ySb + (mvLX

[0001] >> 4)).

[0139] For each luma sample position ( x L = 0..sbWidth ― 1 + brdExtSize, y L = 0..sbHeight ― 1 + brdExtSize ), the corresponding predicted luma sample value predSamplesLX[ x L ][ y L] may be derived as follows: - ( refxSb L , refySb L ) and ( refx L , refy L ) is the luma position pointed to by the motion vector ( refMvLX, refMvLX ) given in 1 / 16 sample units. L , refx L , refySb L , and refy L may be derived as shown in Equations 26 through 29 below: refxSb L = ( ( (xSb+ ref_region_left_offset) << 4 ) + refMvLX

[0000] ) * hori_scale_fp (Equation 26) refx L = ( ( Sign( refxSb ) * ( ( Abs( refxSb ) + 128 ) >> 8 ) + x L * ( ( hori_scale_fp + 8 ) >> 4 ) ) + 32 ) >> 6 (Equation 27) refySb L = ( ( (ySb+ ref_region_top_offset) << 4 ) + refMvLX

[0001] ) * vert_scale_fp (Equation 28) refyL = ( ( Sign( refySb ) * ( ( Abs( refySb ) + 128 ) >> 8 ) + yL * ( ( vert_scale_fp + 8 ) >> 4 ) ) + 32 ) >> 6 (Equation 29)

[0140] 9, in an embodiment, when a resampling ratio for reference picture resampling is calculated based on a conformance window size, a decoder performing a current block decoding process involving inter-picture motion compensation prediction may access one or more pixels outside the decoded pixels in the reference picture. In some examples, the decoding process may use a decoded picture that is not available in the DPB, which may result in the decoder crashing or other undesirable decoding behavior.

[0141] For example, as shown in FIG. 9, based on a decoded picture having a decoded picture size 903 and a conformance window size 904 and a reference picture having a decoded picture size 901 and a conformance window size 902, the decoding process for a current block 906 may end up using a reference block 905 that is unavailable.

[0142] To address such issues, it may be possible to use explicit signaling of the resampling picture size in the calculation of the resampling ratio for reference picture resampling.

[0143] In an embodiment, if the conformance window size does not match the actual resampling ratio, the conformance window size may not be appropriate to use for the calculation of the resampling ratio for the reference picture resampling. For example, if the current picture is composed of stereoscopic sub-pictures (left and right) or multiple faces of a 360 picture (e.g., 6 faces of a cube map projection), the conformance window size may differ from the desired resampling ratio. In some cases, the conformance window size may cover a sub-region of the decoded picture. In such cases, the resampling picture size may be used instead for the calculation of the resampling ratio.

[0144] Figure 10 is an example process 1000 for decoding an encoded video bitstream. In some implementations, one or more process blocks of Figure 10 may be performed by the decoder 210. In some implementations, one or more process blocks of Figure 10 may be performed by another device or devices separate from or including the decoder 210, such as the decoder 203.

[0145] As shown in FIG. 10, the process 1000 may include obtaining a first flag indicating that a conformance window exists for the current picture (block 1010).

[0146] As further shown in FIG. 10, the process 1000 may include obtaining a second flag indicating whether a conformance window is used for reference picture resampling based on the first flag indicating that a conformance window exists (block 1020).

[0147] 10, the process 1000 may include determining whether a second flag indicates that the conformance window is used for reference picture resampling (block 1030). If it is determined that the second flag indicates that the conformance window is used for reference picture resampling (YES at block 1030), the process 1000 may proceed to block 1040 and then to block 1060. At block 1040, the process 1000 may include determining a resampling ratio between the current picture and the reference picture based on a conformance window size of the conformance window.

[0148] If it is determined that the second flag does not indicate that a conformance window is to be used for reference picture resampling (NO at block 1030), the process 1000 may proceed to block 1050 and then to block 1060. At block 1050, the process 1000 may include determining a resampling ratio based on a resampling picture size.

[0149] As further shown in FIG. 10, the process 1000 may include performing reference picture resampling on the current picture using the resampling ratio (block 1060).

[0150] In an embodiment, the first flag and the second flag may be signaled in a picture parameter set.

[0151] In an embodiment, the conformance window size may be determined based on at least one offset distance from a boundary of the current picture.

[0152] In an embodiment, at least one offset distance may be signaled in a picture parameter set.

[0153] In an embodiment, the resampled picture size may be specified in the encoded video bitstream as at least one of a resampled picture size width and a resampled picture size height.

[0154] In an embodiment, at least one of the width and the height may be signaled in a picture parameter set.

[0155] In an embodiment, at least one of the width and the height may be expressed as a number of luma samples included in at least one of the width and the height.

[0156] In an embodiment, the resampling picture size may be determined based on at least one offset distance from a top-left luma sample of a reference region of the current picture.

[0157] In an embodiment, at least one offset distance may be signaled in a picture parameter set.

[0158] 10 illustrates example blocks of process 1000, although in some implementations process 1000 may include additional, fewer, different, or differently arranged blocks relative to those illustrated in FIG 10. Additionally or alternatively, two or more blocks of process 1000 may be performed in parallel.

[0159] Additionally, the proposed methods may be implemented by a processing circuit (e.g., one or more processors or one or more integrated circuits). In one example, the one or more processors execute a program stored on a non-transitory computer-readable medium to perform one or more of the proposed methods.

[0160] The techniques described above may be implemented as computer software using computer-readable instructions that may be physically stored on one or more computer-readable media. For example, Figure 11 illustrates a computer system 1100 suitable for implementing certain embodiments of the disclosed subject matter.

[0161] Computer software may be coded using any suitable machine code or computer language that may be affected by mechanisms such as assembly, compilation, linking, etc. to generate code including instructions that may be executed by a computer central processing unit (CPU), graphics processing unit (GPU), etc., either directly or through interpretation, microcode execution, etc.

[0162] The instructions may be executed in various types of computers or components thereof, including, for example, personal computers, tablet computers, servers, smartphones, gaming devices, Internet of Things (IoT), etc.

[0163] 11 for computer system 1100 are exemplary in nature and are not intended to suggest any limitation as to the scope of use or functionality of the computer software implementing the embodiments of the present disclosure, nor should the arrangement of components be interpreted as having any dependency or requirement related to any one or combination of components illustrated in the exemplary embodiment of computer system 1100.

[0164] The computer system 1100 may include certain human interface input devices. Such human interface input devices may be responsive to input by one or more human users, for example, via tactile input (e.g., keystrokes, swipes, data glove movements), audio input (e.g., voice, clapping), visual input (e.g., gestures), and olfactory input (not shown). Human interface devices may also be used to capture certain media that are not necessarily directly related to conscious human input, such as audio (e.g., speech, music, ambient sounds), images (e.g., scanned images, photographic images obtained from a still image camera), and video (e.g., two-dimensional video, three-dimensional video including stereoscopic video).

[0165] The input human interface devices may include one or more of a keyboard 1101, a mouse 1102, a trackpad 1103, a touch screen 1110 and associated graphics adapter 1150, a data glove, a joystick 1105, a microphone 1106, a scanner 1107, and a camera 1108.

[0166] The computer system 1100 may also include certain human interface output devices that may stimulate one or more of the human user's senses, for example, through tactile output, sound, light, and smell / taste. Such human interface output devices may include haptic output devices (e.g., haptic feedback via a touch screen 1110, data gloves, or joystick 1105, although it is possible that there may be haptic feedback devices that do not function as input devices), audio output devices (e.g., speakers 1109, headphones (not shown)), visual output devices (e.g., screens 1110 including cathode ray tube (CRT) screens, liquid crystal display (LCD) screens, plasma screens, organic light emitting diode (OLED) screens (each with or without touch screen input capability, each with or without haptic feedback capability, some of which may output two-dimensional visual output or three or more dimensional output by means such as stereoscopic output), virtual reality glasses (not shown), holographic displays, and smoke tanks (not shown)), and printers (not shown).

[0167] The computer system 1100 may also include human accessible storage devices and their associated media, such as optical media including CD / DVD ROM / RW 1120 with CD / DVD or similar media 1121, thumb drives 1122, removable hard drives or solid state drives 1123, legacy magnetic media such as tapes and floppy disks (not shown), specialized ROM / ASIC / PLD based devices such as security dongles (not shown), etc.

[0168] Those skilled in the art will also understand that the term "computer-readable medium" as used in connection with the subject matter of this disclosure does not encompass transmission media, carrier waves, or other transitory signals.

[0169] The computer system 1100 may also include interfaces to one or more communication networks (1155). The networks may be, for example, wireless, wired, or optical. The networks may further be local, wide area, metropolitan, vehicular and industrial, real-time, delay tolerant, etc. Examples of networks include Ethernet, wireless LANs, cellular networks (including Global System for Mobile Communications (GSM), 3rd Generation (3G), 4th Generation (4G), 5th Generation (5G), Long Term Evolution, etc.), TV wired or wireless wide area digital networks (including cable TV, satellite TV, terrestrial TV), vehicular and industrial including CANBus, etc. Certain networks typically require an external network interface adapter (1154) (e.g., a Universal Serial Bus (USB) port on the computer system 1100) that connects to a particular general-purpose data port or peripheral bus (1149); other networks are typically built into the core of the computer system 1100 by connection to a system bus as described below (e.g., an Ethernet interface is built into a PC computer system, a cellular network interface is built into a smartphone computer system). As an example, a network 1155 may be connected to the peripheral bus 1149 using a network interface 1154. Using any of these networks, the computer system 1100 can communicate with other entities. Such communications can be unidirectional, receive only (e.g., broadcast TV), unidirectional transmit only (e.g., CANbus to certain CANbus devices), or bidirectional, such as to other computer systems using local or wide area digital networks. Particular protocols and protocol stacks may be used in each of those networks and network interfaces (1154), as described above.

[0170] The aforementioned human interface devices, human accessible storage, and network interfaces may be attached to core 1140 of computer system 1100.

[0171] The core 1140 may include one or more central processing units (CPUs) 1141, graphics processing units (GPUs) 1142, specific programmable processing units in the form of field programmable gate areas (FPGAs) 1143, hardware accelerators for specific tasks 1144, etc. These devices may be connected via a system bus 1148 along with read only memory (ROM) 1145, random access memory (RAM) 1146, internal mass storage such as internal non-user accessible hard drives, solid state drives (SSDs), and the like 1147. In some computer systems, the system bus 1148 may be accessible in the form of one or more physical plugs to allow expansion with additional CPUs, GPUs, etc. Peripheral devices may be attached directly to the core's system bus 1148 or via a peripheral bus 1149. Peripheral bus architectures include peripheral component interconnect (PCI), USB, etc.

[0172] The CPU 1141, GPU 1142, FPGA 1143, and accelerator 1144 may combine to execute certain instructions that may make up the computer code described above. The computer code may be stored in ROM 1145 or RAM 1146. Temporary data may be stored in RAM 1146 while persistent data may be stored in, for example, internal mass storage 1147. A cache memory, which may be closely associated with one or more of the CPU 1141, GPU 1142, mass storage 1147, ROM 1145, RAM 1146, etc., may be used to enable fast storage and retrieval from any memory device.

[0173] The computer-readable medium can have computer code thereon for performing various computer-implemented operations. The medium and computer code can be specially designed and constructed for the purposes of the present disclosure, or they can be of the kind well known and available to those skilled in the computer software arts.

[0174] By way of example and not limitation, the architecture 1100, and in particular a computer system having a core 1140, can provide functionality derived from a processor (including a CPU, GPU, FPGA, accelerator, etc.) executing software embodied in one or more tangible computer-readable media. Such computer-readable media can be media associated with user-accessible mass storage as described above, as well as specific storage of the core 1140 of a non-transitory nature, such as the core internal mass storage 1147 or the ROM 1145. Software implementing various embodiments of the present disclosure can be stored in such devices and executed by the core 1140. The computer-readable media can include one or more memory devices or chips, depending on the particular needs. The software can cause the core 1140, and in particular the processor therein (including a CPU, GPU, FPGA, etc.), to perform certain processes or portions of certain processes described herein, including defining data structures stored in the RAM 1146 and modifying such data structures according to processes defined by the software. Additionally or alternatively, a computer system may provide functionality as a result of hardwired logic or otherwise embedded in circuitry (e.g., accelerator 1144) that may operate in place of or in conjunction with software to perform particular processes or portions of particular processes described herein. References to software may include logic, and vice versa, as appropriate. References to computer-readable media may include circuitry (e.g., integrated circuits (ICs)) that store software for execution, circuitry embodying logic for execution, or both, as appropriate. The present disclosure encompasses any suitable combination of hardware and software.

[0175] While this disclosure has described several exemplary embodiments, there are alterations, permutations, and various substitute equivalents that fall within the scope of this disclosure. It will thus be appreciated that those skilled in the art will be able to devise numerous systems and methods that, although not explicitly shown or described herein, embody the principles of the present disclosure and are therefore within its spirit and scope.

[0176] (Appendix 1) 1. A method for decoding an encoded video bitstream utilizing at least one processor, comprising: obtaining a first flag indicating the presence of a conformance window in the current picture; obtaining a second flag indicating whether the conformance window is used for reference picture resampling based on the first flag indicating the existence of the conformance window; determining a resampling ratio between the current picture and the reference picture based on a conformance window size of the conformance window based on the second flag indicating that the conformance window is used for the reference picture resampling; determining the resampling ratio based on a resampling picture size based on the second flag indicating that the conformance window is not used for the reference picture resampling; performing the reference picture resampling on the current picture using the resampling ratio; The method includes: (Appendix 2) 2. The method of claim 1, wherein the first flag and the second flag are signaled in a picture parameter set. (Appendix 3) 2. The method of claim 1, wherein the conformance window size is determined based on at least one offset distance from a border of the current picture. (Appendix 4) 4. The method of claim 3, wherein the at least one offset distance is signaled in a picture parameter set. (Appendix 5) 2. The method of claim 1, wherein the resampled picture size is specified in the encoded video bitstream as at least one of a width of the resampled picture size and a height of the resampled picture size. (Appendix 6) 6. The method of claim 5, wherein at least one of the width and the height is signaled in a picture parameter set. (Appendix 7) 6. The method of claim 5, wherein at least one of the width and the height is expressed as a number of luma samples contained in at least one of the width and the height. (Appendix 8) 2. The method of claim 1, wherein the resampling picture size is determined based on at least one offset distance from a top-left luma sample of a reference region of the current picture. (Appendix 9) 9. The method of claim 8, wherein the at least one offset distance is signaled in a picture parameter set. (Appendix 10) 1. An apparatus for decoding an encoded video bitstream, comprising: at least one memory configured to store program code; at least one processor that reads said program code and operates as directed by said program code; the program code comprising: first obtaining code configured to cause the at least one processor to obtain a first flag indicating the presence of a conformance window in a current picture; second obtaining code configured to cause the at least one processor to obtain a second flag indicating whether the conformance window is used for reference picture resampling based on the first flag indicating that the conformance window exists; and a first decision code configured to cause the at least one processor to determine a resampling ratio between the current picture and the reference picture based on a conformance window size of the conformance window based on the second flag indicating that the conformance window is used for the reference picture resampling; second decision code configured to cause the at least one processor to determine the resampling ratio based on a resampling picture size based on the second flag indicating that the conformance window is not used for the reference picture resampling; executable code configured to cause the at least one processor to perform the reference picture resampling on the current picture using the resampling ratio; 13. An apparatus comprising: (Appendix 11) 11. The apparatus of claim 10, wherein the first flag and the second flag are signaled in a picture parameter set. (Appendix 12) 11. The apparatus of claim 10, wherein the conformance window size is determined based on at least one offset distance from a border of the current picture. (Appendix 13) 13. The apparatus of claim 12, wherein the at least one offset distance is signaled in a picture parameter set. (Appendix 14) 11. The apparatus of claim 10, wherein the resampled picture size is specified in the encoded video bitstream as at least one of a width of the resampled picture size and a height of the resampled picture size. (Appendix 15) 15. The apparatus of claim 14, wherein at least one of the width and the height is signaled in a picture parameter set. (Appendix 16) 15. The apparatus of claim 14, wherein at least one of the width and the height is expressed as a number of luma samples included in at least one of the width and the height. (Appendix 17) 11. The apparatus of claim 10, wherein the resampling picture size is determined based on at least one offset distance from a top-left luma sample of a reference region of the current picture. (Appendix 18) 18. The apparatus of claim 17, wherein the at least one offset distance is signaled in a picture parameter set. (Appendix 19) A non-transitory computer-readable medium storing instructions that, when executed by one or more processors of a device for decoding an encoded video bitstream, cause the one or more processors to: obtaining a first flag indicating the presence of a conformance window in the current picture; obtaining a second flag indicating whether the conformance window is used for reference picture resampling based on the first flag indicating the existence of the conformance window; determining a resampling ratio between the current picture and the reference picture based on a conformance window size of the conformance window based on the second flag indicating that the conformance window is used for the reference picture resampling; determining the resampling ratio based on a resampling picture size based on the second flag indicating that the conformance window is not used for the reference picture resampling; performing the reference picture resampling on the current picture using the resampling ratio; A non-transitory computer-readable medium for causing the computer to execute (Appendix 20) 20. The non-transitory computer-readable medium of claim 19, wherein the first flag and the second flag are signaled in a picture parameter set.

Claims

1. 1. A method for decoding an encoded video bitstream utilizing at least one processor, comprising: obtaining a first syntax element indicating the presence of a conformance window for a current picture; if the first syntax element indicates that the conformance window exists, obtaining a second syntax element indicating whether the conformance window is used for reference picture resampling (RPR); if the second syntax element indicates that the conformance window is to be used for the RPR, determining a resampling ratio between the current picture and the reference picture based on a conformance window size of the conformance window for the reference picture and the current picture; if the second syntax element indicates that the conformance window is not used for the RPR, determining the resampling ratio based on a size of the reference picture and a resampling picture size of the current picture; performing the RPR on the current picture using the resampling ratio; and the first syntax element includes a conformance window flag (conformance_window_flag), and if the conformance window flag (conformance_window_flag) is equal to 0, conf_win_left_offset, conf_win_right_offset, conf_win_top_offset, and conf_win_bottom_offset The value of is inferred to be equal to 0, conf_win_left_offset, conf_win_right_offset, conf_win_top_offset, and conf_win_bottom_offset The method of claim 1, further comprising: specifying a picture sample that references a picture parameter set (PPS) according to a rectangular area specified in picture coordinates as an output for decoding the current picture.

2. The method of claim 1 , wherein the first syntax element and the second syntax element are signaled in a picture parameter set.

3. The method of claim 1 , wherein the conformance window size is determined based on at least one offset distance from a border of the current picture.

4. The method of claim 3 , wherein the at least one offset distance is signaled in a picture parameter set.

5. 2. The method of claim 1, wherein the resampled picture size is specified in the encoded video bitstream as at least one of a width of the resampled picture size and a height of the resampled picture size.

6. The method of claim 5 , wherein at least one of the width and the height is signaled in a picture parameter set.

7. The method of claim 5 , wherein at least one of the width and the height is expressed as a number of luma samples contained in at least one of the width and the height.

8. The method of claim 1 , wherein the resampled picture size is determined based on at least one offset distance between an edge of the current picture and a top-left luma sample of a reference area.

9. The method of claim 8 , wherein the at least one offset distance is signaled in a picture parameter set.

10. 1. An apparatus for decoding an encoded video bitstream, comprising: at least one memory configured to store program code; at least one processor that reads said program code and operates as directed by said program code; 10. An apparatus comprising: a processor for executing a program code for executing a method according to any one of claims 1 to 9, the processor comprising:

11. A computer program product causing one or more processors to carry out the method according to any one of claims 1 to 9.

12. 1. A method for an encoder to generate and transmit an encoded video bitstream to a decoder, comprising the steps of: a first syntax element is included in the video bitstream to indicate the presence of a conformance window for a current picture; if the first syntax element indicates that the conformance window is present, a second syntax element is included in the video bitstream that indicates whether the conformance window is used for reference picture resampling (RPR); if the second syntax element indicates that the conformance window is used for the RPR, a resampling ratio between the current picture and the reference picture is determined based on a conformance window size of the conformance window for the reference picture and the current picture; If the second syntax element indicates that the conformance window is not used for the RPR, the resampling ratio is determined based on a size of the reference picture and a resampling picture size of the current picture; the RPR for the current picture is performed using the resampling ratio; The first syntax element includes a conformance window flag (conformance_window_flag), and if the conformance window flag (conformance_window_flag) is equal to 0, conf_win_left_offset, conf_win_right_offset, conf_win_top_offset, and conf_win_bottom_offset The value of is inferred to be equal to 0, conf_win_left_offset, conf_win_right_offset, conf_win_top_offset, and conf_win_bottom_offset The method of claim 1, further comprising: specifying a picture sample that references a picture parameter set (PPS) according to a rectangular area specified in picture coordinates as an output for decoding the current picture.

13. A method executed by at least one processor in an encoder, comprising: performing reference picture resampling (RPR) on the current picture based on a resampling ratio for encoding; signaling to a decoder a first syntax element indicating the presence of a conformance window for the current picture; if the first syntax element indicates that the conformance window exists, signaling to the decoder a second syntax element indicating whether the conformance window is used for the RPR; and when the conformance window is used for the RPR, the resampling ratio between the current picture and the reference picture is determined based on a conformance window size of the conformance window for the reference picture and the current picture; if the conformance window is not used for the RPR, the resampling ratio is determined based on a size of the reference picture and a resampling picture size of the current picture; The first syntax element includes a conformance window flag (conformance_window_flag), and if the conformance window flag (conformance_window_flag) is equal to 0, conf_win_left_offset, conf_win_right_offset, conf_win_top_offset, and conf_win_bottom_offset The value of is inferred to be equal to 0, conf_win_left_offset, conf_win_right_offset, conf_win_top_offset, and conf_win_bottom_offset The method of claim 1, further comprising: specifying a picture sample that references a picture parameter set (PPS) according to a rectangular area specified in picture coordinates as an output for decoding the current picture.

Images