Intra-block copy mode for screen content encoding

Abstract

To provide systems, methods and means for video coding.SOLUTION: A video block of a current image is coded in an IBC mode. Weighted prediction is disabled for the IBC-coded screen content video block. Fractional block vectors are used for chroma components of the IBC-coded video block. An interpolation filter is utilized to generate chroma prediction samples for the video block. A decoded version of a current reference image is added to both a reference image list L0 and a reference image list L1 that are associated with the IBC-coded video block. When constrained intra prediction is applied, reference samples that may be used to predict an intra-coded video block is limited to those in intra-coded neighboring blocks. A range of IBC searches is restricted by imposing a maximum absolute value for block vectors.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] The present invention relates to an intra-block copy mode for screen content encoding.

[0002] Cross - reference to related applications This application claims the benefit of U.S. Provisional Patent Application No. 62 / 172,645, filed on Jun. 8, 2015; U.S. Provisional Patent Application No. 62 / 241,708, filed on Oct. 14, 2015; and U.S. Provisional Patent Application No. 62 / 297,736, filed on Feb. 19, 2016, the entire disclosures of which are incorporated herein by reference.

Background Art

[0003] Due to the rapid increase in the use of video applications such as wireless displays and cloud computing, screen content encoding (SCC) has become increasingly important. Screen content videos typically include content generated by computers such as text and graphics, and thus can have different characteristics from natural content (e.g., videos captured by a camera). Systems, methods, and means can be designed to utilize the unique characteristics of screen content so that it can be encoded efficiently.

Summary of the Invention

[0004] This specification describes systems, methods, and means for encoding video (e.g., screen content video). Weighted prediction can be enabled or disabled when encoding a video block of the current image. For example, weighted prediction can be disabled when the video block is encoded in intra-block copy (IBC) mode. Whether IBC mode is enabled for a video block can be determined by comparing the image sequence count associated with the current image with the image sequence count associated with the reference image of the current image. If the two image sequence counts are different, it can be determined that IBC mode cannot be enabled and that weighted prediction can be applied. When weighted prediction is applied, the video bitstream associated with the video block can be generated using one or more weighted prediction parameters signaled in the video bitstream. In some embodiments, before decisions regarding IBC mode and weighted prediction can be made, a comparison can be made between the layer ID associated with the current image and the layer ID associated with the reference image. More specifically, if the layer IDs of the current image and the reference image are different, or if the image sequence counts of the current image and the reference image are different, it can be determined that IBC mode cannot be enabled, and that weighted prediction can be applied (for example, one or more weighted prediction parameters can be signaled).

[0005] A fractional block vector can be used to identify chromaticity reference samples for IBC-encoded video blocks. Interpolation filtering can be used to generate chromaticity prediction samples for video blocks based on the chromaticity reference samples. Furthermore, when IBC mode is enabled, pseudo-reference images (e.g., decoded versions of the current image) can be added to both the reference image list L0 and reference image list L1 of the current image. Constrained intra-prediction (CIP) can be applied. The application of CIP may adhere to several limitations, including, for example, predicting an intra-encoded video block using only samples from intra-encoded adjacent blocks.

[0006] The video encoding devices described herein may include video encoders and / or video decoders. The systems, methods, and means described herein are not limited to encoding screen content video, but may also be applied to encoding other video content. [Brief explanation of the drawing]

[0007] A more detailed understanding can be obtained from the following explanation, which is provided as an example along with the attached diagrams.

[0008] [Figure 1] This is a diagram illustrating one or more example video encoders described herein. [Figure 2] This is a diagram illustrating one or more example video decoders described herein. [Figure 3] This figure shows an example of a full-frame intrablock copy search. [Figure 4] This figure shows an example of a local intrablock copy search. [Figure 5A] This figure shows an example of BV clipping operation on the chromaticity component. [Figure 5B]This figure shows that reference samples from adjacent slices cannot be used for fractional chromaticity sample interpolation. [Figure 5C] This figure shows an example of slice boundary crossing sample padding for fractional chromaticity sample interpolation. [Figure 5D] This figure shows an example of BV clipping operation for the chromaticity component. [Figure 6] This diagram illustrates how errors can propagate from an inter-encoded reference block to the current block, which is encoded using constrained intra-prediction (CIP). [Figure 7] This diagram illustrates an example of how to perform intra-prediction when CIP is enabled. [Figure 8A] This is a diagram illustrating an exemplary communication system in which one or more disclosed embodiments can be implemented. [Figure 8B] Figure 8A is a system diagram of an exemplary wireless transmit / receive unit (WTRU) that can be used in the communication system shown. [Figure 8C] This is a system diagram of an exemplary wireless access network and an exemplary core network that can be used in the communication system shown in Figure 8A. [Figure 8D] Figure 8A is a system diagram of other exemplary wireless access networks and exemplary core networks that can be used in the communication system shown. [Figure 8E] Figure 8A is a system diagram of other exemplary wireless access networks and exemplary core networks that can be used in the communication system shown. [Modes for carrying out the invention]

[0009] A detailed description of exemplary embodiments will be given next with reference to various figures. This description provides examples of possible implementations, but it should be noted that these examples do not limit the scope of this application. Furthermore, video encoding devices as described herein may include video encoders and / or video decoders.

[0010] Figure 1 shows an exemplary video encoder 100 in which one or more disclosed embodiments can be implemented. The video encoder 100 can conform to international video coding standards such as MPEG-1, MPEG-2, MPEG-4, H.264 / MPEG-4 Advanced Video Coding (AVC), and / or High Efficiency Video Coding (HEVC). The video encoder 100 can be a standalone unit or part of a video broadcast system, cable system, network-based video streaming service, game application and / or service, multimedia communication system, and / or a variety of other applications and services. The video encoder 100 can be implemented in hardware, software, or a combination of hardware and software. For example, the video encoder 100 can utilize one or more dedicated processors, general-purpose processors, graphics processing units (GPUs), application-specific integrated circuits (ASICs), field-programmable gate array (FPGA) circuits, state machines, etc. One or more components of the video encoder 100 can be implemented using software or firmware embedded in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media such as read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (e.g., internal hard disks and removable disks), magneto-optical media, optical media (e.g., CD-ROM discs), and digital multipurpose discs (DVDs).

[0011] As shown in Figure 1, the video encoder 100 may include a spatial prediction unit 104, a temporal (or motion) prediction unit 106, a reference image storage unit 108, a motion determination and control logic unit 110, a conversion unit 112, an inverse conversion unit 113, a quantization unit 114, an inverse quantization unit 115, a scanning unit (not shown), an entropy coding unit 116, and / or a loop filter 124. Although Figure 1 shows the video encoder 100 having only one unit of each of the components described herein, those skilled in the art will understand that one or more units of the components may be used to perform the functions described herein.

[0012] The video encoder 100 can be configured to receive an input video signal 102. The input video signal 102 can have a standard resolution (e.g., 640×880) or a high resolution (e.g., 1920×1080 or higher). The video encoder 100 can process the input video signal 102 block by block. Each video block may be referred to herein as a MAC block ("MB") or "encoded tree unit" (CTU) and may have multiple sizes, including 4×4 pixels, 8×8 pixels, 16×16 pixels, 32×32 pixels, or 64×64 pixels. Extended block sizes (e.g., 64×64, 32×32, and 16×16 pixel CTUs) can be used to compress high-resolution video signals (e.g., 1080 or higher). Extended block sizes can be selected at the sequence level and signaled in the sequence parameter set (SPS). Extended block sizes (e.g., CTUs) can be divided into one or more encoding units (CUs), for example, by a quadtree partition. A CU (for example, a 64x64 pixel CU) can be divided into prediction units. The video encoder 100 can perform predictions (e.g., intra or inter-predictions) for each video block to reduce the amount of information required for compression and / or delivery, for example, by leveraging the inherent redundancy and irrelevance within the video block. In the example, the video encoder 100 can apply predictions at the CU level. When a CU is divided into prediction units, individual predictions can be applied to each prediction unit.

[0013] The video encoder 100 can be configured in a spatial prediction unit 104 to perform spatial prediction for the current video block. Such a prediction method allows the video encoder 100 to predict pixels in the current video block using, for example, pixels from one or more previously encoded adjacent blocks of the same video frame (the blocks used for prediction may be referred to herein as “prediction blocks”). Pixels in adjacent blocks can be highly correlated with pixels in the current video block, for example, because they may contain many regions of smoothly changing intensity across related video frames. Therefore, by using spatial prediction, the video encoder 100 can remove certain spatial redundancy from the current video block and encode only residual pixels that cannot be spatially predicted. Exemplary spatial prediction methods may include intra-prediction, intra-block copy prediction (IBC), etc. Intra-prediction can predict a specific sample value from the current frame (for example, unrelated to any other frame) using adjacent previously encoded pixel samples (e.g., columns or rows of samples). IBC prediction can predict sample values ​​for an entire block using a previously encoded block of samples from the current frame.

[0014] In addition to or instead of spatial prediction, the video encoder 100 can apply temporal prediction (e.g., "interpretation" or "motion-compensated prediction") to video blocks using a temporal prediction unit 106. Temporal prediction can take advantage of the fact that two adjacent video frames can have high temporal redundancy because a normal video sequence does not change rapidly from one frame to the next. Accordingly, the video encoder 100 can predict the current video block using one or more prediction blocks from previously encoded video frames, thereby removing the temporal redundancy inherent in the video signal 102. In an example, the video encoder 100 may be configured to calculate and / or signal the amount and direction of motion between the current video block and its prediction blocks, for example, using one or more motion vectors, and to further improve the efficiency of prediction using the calculated motion information. In one or more examples, the video encoder 100 can support multiple reference images and assign a reference image index to each encoded video block. The video encoder 100 can determine, based on the reference image index of the video block, which reference image and / or reference video block in the reference image storage unit 108 can generate a temporal prediction signal. The reference image index can be signaled.

[0015] The video encoder 100 can select a prediction mode based on logic stored in the mode determination and control logic unit 110. In the selection process, several factors may be considered, for example, including rate-distortion optimization (RDO) criteria and / or bitrate requirements. In one or more examples, the video encoder 100 can select the prediction mode that minimizes the sum of its absolute conversion differences (SATD). In one or more examples, the video encoder 100 can select the prediction mode with the smallest rate distortion cost. Various other techniques are also possible, all of which are within the scope of this disclosure.

[0016] The various prediction methods described herein can generate prediction residuals (e.g., by subtracting a predicted block from a current video block). The prediction residuals can comprise a large set of highly correlated pixels. The video encoder 100 converts (e.g., by the conversion unit 112) and quantizes (e.g., by the quantization unit 114) the prediction residuals into a smaller set of coefficients with less (e.g., no) correlation (referred to herein as “transform coefficients”), then scans these transform coefficients (e.g., by a scanning unit described herein) to form a one-dimensional sequence of coefficients and supplies the sequence to the entropy encoding unit 116. In one or more examples, the video encoder 100 can pass additional information, such as an encoding mode, a prediction mode, motion information, a residual differential pulse code modulation (RDPCM) mode, and / or other encoding parameters, to the entropy encoding unit 116. The additional information can be compressed and packed with the transform coefficients and sent to the video bitstream 120. The transform coefficients can be inverse quantized (e.g., in the inverse quantization unit 115), inverse transformed (e.g., in the inverse transform unit 112), and added back to the predicted block to reconstruct the video block. In-loop filtering 124, such as non-blocking filtering and adaptive loop filtering, can be applied to the reconstructed video block before it is placed in the reference picture memory 108 for use in encoding future video blocks.

[0017] Figure 2 shows an exemplary video decoder 200 in which one or more disclosed embodiments can be implemented. The exemplary video decoder 200 can be located at the receiving end of a bitstream 202 and can receive the bitstream 202 through a variety of transport media, including, for example, a public network (e.g., the Internet), an internal network (e.g., a corporate intranet), a virtual private network ("VPN"), a cellular network, a cable network, a serial communication link, an RS-485 communication link, an RS-232 communication link, an internal data bus, and the like. The video decoder 200 can utilize a block-based decoding method that conforms to international video standards such as MPEG-1, MPEG-2, MPEG-4, H.264 / MPEG-4 Advanced Video Coding (AVC), and / or High Efficiency Video Coding (HEVC). The video decoder 200 can be a standalone unit or as part of a computer device, a mobile device, a television system, a game console and application, a multimedia communication system, and / or a variety of other devices and applications. The video decoder 200 can be implemented in hardware, software, or a combination of hardware and software. For example, the video decoder 200 can utilize one or more dedicated processors, general-purpose processors, graphics processing units (GPUs), application-specific integrated circuits (ASICs), field-programmable gate array (FPGA) circuits, state machines, etc. One or more components of the video decoder 200 can be implemented using software or firmware embedded in a computer-readable medium for execution by a computer or processor.Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media such as read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (e.g., internal hard disks and removable disks), magneto-optical media, optical media (e.g., CD-ROM discs), and digital multipurpose discs (DVDs).

[0018] The video decoder 200 can be configured to reconstruct a video signal based on an encoded version of the video signal (e.g., one generated by the video encoder 100). The reconstruction process may include receiving blocks of the encoded video (e.g., SCC video), obtaining prediction blocks used to encode the video blocks, recovering the prediction residuals of the video blocks, and reconstructing the original video blocks. Thus, the video decoder 200 may have components that perform the reverse functions of those of the video encoder 100. For example, as shown in Figure 2, the video decoder 200 may include an entropy decoding unit 204, a spatial prediction unit 206, a temporal prediction unit 208, an inverse quantization unit 210, an inverse transform unit 212, a loop filter 214, and / or a reference image storage unit 216. The video decoder 200 can receive the video bitstream 202 in the entropy decoding unit 204. The entropy decoding unit 204 can unpack the bitstream 202 and entropy decode it, and then the entropy decoding unit 204 can extract information such as conversion coefficients generated by the conversion unit 112, quantization unit 114, and / or scanning unit of the video encoder 100. Additional information, including the encoding mode, prediction mode, RDPCM mode, and / or other parameters used to encode the video block, can also be extracted. Some of the extracted information can be sent to the spatial prediction unit 206 (e.g., if the video signal is intra-coded or IBC-coded) and / or the temporal prediction unit 208 (e.g., if the video signal is inter-coded) to obtain the prediction block. The conversion coefficient block can be reconstructed, inversely quantized (e.g., in the inverse quantization unit 210), and inversely transformed (e.g., in the inverse transform unit 212) to derive the prediction residual of the video block. The video decoder 200 can combine the residual video block and the prediction block to restore the video block to its original form.

[0019] The video decoder 200 can apply in-loop filtering to the restored video block, for example, in the loop filter 214. Various in-loop filtering techniques can be used, including, for example, non-blocking filtering and adaptive loop filtering. After restoration and filtering, the video decoder 200 can place the restored video 218 in the reference image memory unit 216, and then, using the video blocks of the reference image memory unit 216, other images can be encoded and / or a display device can be driven. As described herein, similar restoration and in-loop filtering can also occur in the video encoder 100, for example, by the inverse quantization unit 115, the inverse transform unit 113, the loop filter 124, and / or the reference image memory unit 108.

[0020] For encoding video, various techniques and / or tools can be used. These techniques and / or tools can include, for example, IBC, palette encoding, adaptive color conversion (ACT), and adaptive motion vector precision. IBC is a block matching technique. In an exemplary implementation of IBC, the current video block can be predicted as a displacement from a previously restored block (e.g., a reference block) in an adjacent region / area of the same image. The displacement can be measured and / or represented, for example, by a block vector (BV). The encoding system (e.g., encoder 100) can use various search techniques to identify the BV and / or the corresponding reference block. For example, to achieve a trade-off between encoding performance and memory bandwidth complexity, the encoding system can be configured to perform a full-frame IBC search or a local IBC search to identify the reference block.

[0021] Figure 3 shows an example of a full-frame IBC search. Block 302 can represent the current block to be encoded. Blank and shaded areas can represent encoded and unencoded areas, respectively. The full-frame IBC search option can be specified when configuring the encoding system (e.g., encoder 100). Under the full-frame IBC search option, the reference block 304 can be identified from previously reconstructed pixels in the current image (e.g., from all pixels in the reconstructed current image). Hash-based IBC search techniques can be used to determine BV306 to locate the reference block 304 and / or to control the encoding complexity. Samples of previously reconstructed areas can be retained during encoding and / or decoding processes before in-loop filtering (e.g., deblocking and / or sample-adaptive offset (SAO)).

[0022] Figure 4 shows an example of local IBC search. The local IBC search option can be specified when configuring the encoding system (e.g., encoder 100). Using local IBC search, the IBC prediction of the current coding unit 402 can be performed using previously recovered samples from a limited number of adjacent coding tree units (e.g., before in-loop filtering is initiated). For example, pixels that can be used for the IBC prediction of the current CU402 may include pixels from coding tree units located to the left of the current CU402 (e.g., CTU404), and / or previously encoded pixels of the current CTU (e.g., areas 403, 405, and 406, etc.). Since a smaller set of samples can be used during local IBC search, the memory bandwidth requirements associated with IBC-related write / read operations (e.g., by screen content coding software) can be reduced. For the current CU402, BV407 can be determined to locate the reference block 410.

[0023] Block vectors can be constrained to have integer pixel resolution / precision so that direct sample copies from a reference block can be used during motion compensation for IBCs (e.g., without pixel interpolation). Such constraints allow block vectors with fractional pixel precision to be clipped (e.g., during motion compensation) so that the block vector can point to the chromaticity component at the inter-pixel position. The clipping operation can be performed according to equations 1 and 2 if, for a given slice, the image with index refIdx from the reference image list LX (where X can be 0 or 1) is not the same as the current image. Otherwise, the clipping operation can be performed according to equations 3 and 4, where mvLX[0] and mvLX[1] can represent horizontal and vertical luminance motion vectors, mvCLX[0] and mvCLX[1] can represent horizontal and vertical chromaticity motion vectors, SubWidthC can represent the ratio of the horizontal resolution of luminance and chromaticity, and SubHeightC can represent the ratio of the vertical resolution of luminance and chromaticity. For 4:2:0 video, SubWidthC and SubHeightC can be equal to 2.

[0024]

number

[0025] The clipping operations described herein can be suitable for 4:4:4 chromaticity formats (where the chromatic and luminance components can have the same resolution) because, for example, clipping can reduce the coding complexity of IBC-encoded CUs and / or improve their quality (e.g., subjective and / or objective quality) (e.g., when IBC-encoded CUs have edges that have become obscured or distorted by interpolation filtering). For some non-4:4:4 chromaticity formats (e.g., 4:2:0 and 4:2:2), clipping may cause mismatch between the chromatic and luminance components because the chromatic component may have a different sampling rate than the luminance component (e.g., in either or both the horizontal and vertical directions). This can be illustrated in Figure 5A.

[0026] Figure 5 shows the effect of BV clipping (e.g., performed in motion compensation processing) using the exemplary clipping method. In the example, the current coding unit 502 can have a 4x4 block size, and the video sequence can be captured in a 4:2:0 chromaticity format. The luminance and chromaticity samples of the video can be represented by circles and triangles, respectively. The original BV 504 can point to a first reference block 506, and the clipped BV 508 can point to a second reference block 510. If the clipped BV 508 is used to fetch a chromaticity reference sample and the original BV 504 is used to fetch a luminance reference sample, the luminance and chromaticity reference samples (e.g., of reference blocks 506 and 510) may be mismatched. If the current CU is being IBC coded and a prediction signal with mismatched luminance and chromaticity samples is used to predict the current CU, the coding efficiency may be affected. Inconsistencies can result in undesirable artifacts (e.g., ghosting and / or color bleeding artifacts) appearing in the restored signal (e.g., along the boundaries between adjacent objects), which can impair the subjective quality of the restored video.

[0027] For the chromaticity component of an IBC-encoded CU, a fractional block vector can be enabled and used. The fractional block vector can be derived to identify one or more chromaticity reference samples (as described herein, for example). The fractional block vector can point to fractional pixel positions. Interpolation filtering can be used to generate chromaticity prediction samples for an IBC-encoded CU (for example, when the block vector points to fractional pixel positions). For example, returning to Figure 5A, a chromaticity sample (e.g., in area 506) can be identified based on a fractional BV and the length of an applicable interpolation filter. An interpolation filter can then be applied to the chromaticity sample to derive a chromaticity prediction sample for the IBC-encoded CU. Various interpolation filters can be used to derive the chromaticity prediction sample. For example, a 4-tap chromaticity filter (e.g., as defined in the HEVC standard) can be used.

[0028] When fractional sample filtering for the chromaticity component is enabled for IBC mode, and the current image contains multiple slices and / or tiles, chromaticity reference samples located near the boundaries between adjacent slices / tiles cannot be used for interpolation filtering. This can be illustrated in Figure 5B, which shows that reference sample P0 located outside slice boundary 540 cannot be used for fractional chromaticity sample interpolation. In Figure 5B, circles can represent chromaticity samples at integer positions, and triangles can represent interpolated chromaticity samples with fractional pixel precision. One illustrative reason why reference sample P0 cannot be used for chromaticity interpolation is that the reference sample is not in the same slice / tile as the current IBC-encoded CU (e.g., the reference sample may be in an adjacent slice / tile). Another illustrative reason is that slices / tiles in the current image can be decoded independently. Another illustrative reason is that the design goal may be to predict the current IBC-encoded CU using reference samples from a previously encoded area (e.g., an already decoded area of ​​the current image). Accordingly, chromaticity reference samples that cannot be used for prediction cannot be used for fractional chromaticity sample interpolation of IBC-encoded CUs. As described herein, a chromaticity sample can be considered usable if, for example, it is from an area of ​​the current image that has already been decoded, and it belongs to the same slice or tile as the current CU.

[0029] The illustrative chromaticity sample derivation process using interpolation described herein can be performed by conforming to one or more of the following: For example, the luminance motion vector mvLX can conform to several bitstream conformance constraints when the reference image is the current image. An illustrative constraint is that the variables xRef and yRef can be derived based on equations 5 and 6. When the derivation process for z scan order block availability is invoked with (xCurr, yCurr) (e.g., this can be set to equal to (xCb, yCb)) and adjacent luminance positions (xNbY, yNbY) (e.g., this can be set to equal to (xRef, yRef)) as inputs, the output can be equal to TRUE.

[0030]

number

[0031] The example bitstream compatibility constraint is that the variables xRef and yRef can be modified according to equations 7 and 8. When the derivation process for z-scan order block availability is invoked with (xCurr, yCurr) (for example, this can be set to be equal to (xCb, yCb)) and adjacent luminance positions (xNbY, yNbY) (for example, this can be set to be equal to (xRef, yRef)) as inputs, the output can be equal to TRUE.

[0032]

number

[0033] The example bitstream compatibility constraint may be such that one or more of the following conditions are met: First, the value of (mvLX[0]≫2)+nPbW+((mvLX[0]%(1≪(1+SubWidthC))==0)?0:2)+xB1 can be less than or equal to 0. Second, the value of (mvLX[1]≫2)+nPbH+((mvLX[1]%(1≪(1+SubHeightC))==0)?0:2)+yB1 can be less than or equal to 0. Third, the value of xRef / CtbSizeY-xCurr / CtbSizeY can be less than or equal to the value of yCurr / CtbSizeY-yRef / CtbSizeY.

[0034] One or more of the bitstream conformance constraints described herein can be implemented by an encoder (e.g., encoder 100) and / or a decoder (e.g., decoder 200). The encoder can encode the video into a bitstream in compliance with one or more of the constraints. The decoder can check whether the constraints are met before and / or during the decoding of the bitstream, and can generate an error if the constraints are not complied with.

[0035] As described herein, a reference sample cannot be used for fractional chromaticity interpolation if, for example, the reference sample belongs to another slice / tile (e.g., one other than the current slice / tile) or has not been decoded. In these situations, padded samples from the current slice / tile or a decoded region can be used for fractional chromaticity interpolation. This is shown in Figure 5C, which illustrates an example of sample padding across slice boundaries. In Figure 5C, circles can represent chromaticity samples at integer positions, and triangles can represent chromaticity samples at decimal positions. As shown, integer sample P0 straddles slice boundary 550 and may therefore be unavailable for chromaticity interpolation. To enable chromaticity interpolation, the value of integer sample P1 can be duplicated to integer sample P0.

[0036] Reference samples used for interpolation-based chromaticity derivation (e.g., for IBC-encoded CUs) may be from invalid regions (e.g., undecoded regions, different slices or tiles, etc.). Therefore, verification can be performed to check whether the BV is using a chromaticity reference sample that is not available. Verification can introduce complexity to the encoder and / or decoder (in addition to the complexity that may result from the chromaticity interpolation process itself). As described herein, a BV with fractional pixel precision (e.g., for a chromaticity sample) can be clipped to a nearby (e.g., closest) integer chromaticity sample having equal or smaller horizontal and vertical coordinates. Returning to Figure 5A, chromaticity samples 516a, 516b, 516c, and 516d can be integer chromaticity samples obtained by BV clipping. However, these samples may not necessarily be the best reference for predicting the chromaticity sample of the current encoding unit 502. Other integer chromaticity samples may exist, for example, from the same block as the corresponding luminance component and / or closer to the current encoding unit 502.

[0037] Figure 5D shows the effect of BV clipping (e.g., in motion compensation processing) using the exemplary clipping method. The current encoding unit 562 can have a 4x4 block size, and the video sequence can be captured in a 4:2:0 chromaticity format. Luminance and chromaticity samples can be represented by circles and triangles, respectively. The original BV564 can point to a first reference block 566, while the clipped BV568 can point to a second reference block 570. Using the exemplary clipping method, a set of integer chromaticity samples can be derived (e.g., 566a, 566b, 566c, 566d in Figure 5D). The integer chromaticity samples derived from the exemplary clipping method may include one or more chromaticity samples (e.g., 566a, 566b shown in Figure 5D) from the same block as the corresponding luminance sample. Furthermore, the integer chromaticity samples 566a, 566b, 566c, and 566d in Figure 5D can be approximated to the current coding unit. The integer chromaticity samples generated by the exemplary BV clipping method can be used to predict the current coding unit.

[0038] A trade-off between IBC prediction efficiency and complexity can be achieved when extracting chromaticity reference samples for IBC-encoded coding units. More specifically, for a given slice, equations 9 and 10 can be used if the image with index refIdx from the reference image list LX (e.g., X can be 0 or 1) is not the current image, and equations 11 and 12 can be used if the image with index refIdx from the reference image list LX is the current image.

[0039]

number

[0040] Signaling for IBC mode can be unified with that for inter-mode. For example, an IBC-encoded CU in the current image can be signaled as an inter-encoded CU by adding a pseudo-reference image to the reference image list of the current image. The pseudo-reference image can be a decoded version of the current image. The pseudo-reference image may consist of, for example, a sample recovered before the current image (e.g., before in-loop filtering is applied to the recovered sample). When IBC mode is enabled (e.g., by setting the flag curr_pic_as_ref_enabled_flag to true), the reference image list of the current image (e.g., reference image list L0) can be constructed in a specific order (e.g., one or more temporal reference images before the current image, one or more temporal reference images after the current image, and a pseudo-reference image (referred to herein as "currPic")). The pseudo-reference image can be inserted into the reference image list through a reference image list modification operation. The pseudo-reference image can be used to determine whether IBC mode is enabled. More specifically, if the reference image list L0 contains a decoded version of the current image (for example, as a pseudo-reference image) (for example, after a change in the reference image list), then it can be determined that IBC mode is enabled.

[0041] Prior to in-loop filtering (e.g., deblocking and / or sample adaptive offset (SAO)), an additional reference image buffer can be created to store samples recovered before the current image (e.g., within the decoded image buffer (DPB)). Memory access operations can be performed to write samples to or read from the reference image buffer. Changes to the current reference image list can be signaled in the slice segment header. Different slices within a given image may use different reference images. For example, some slices may use pseudo-reference images (e.g., when IBC mode is enabled), while others cannot (e.g., when IBC mode is disabled). When decoding the current slice, information about the reference image list for future slices of the same image may be unknown. Therefore, memory can be accessed (e.g., between both encoding and decoding) to write samples (e.g., unfiltered samples) to buffer memory before in-loop filtering (e.g., even if IBC mode is not enabled for any slice of the current image). As a result of the above operation, encoding efficiency may be affected because currently stored images may not be used as a reference in IBC mode (for example, they may never be used).

[0042] A flag (e.g., curr_pic_as_ref_enabled_flag, as described herein) can be set (e.g., to TRUE) to signal that a slice referencing a given sequence parameter set (SPS) is allowed to use a pseudo-reference image. The pseudo-reference image may include samples decoded before the current image (e.g., before in-loop filtering is activated). The pseudo-reference image can be used as a reference image for prediction (e.g., in IBC mode). When the flag (e.g., curr_pic_as_ref_enabled_flag) is set to true, a memory buffer can be allocated to store the pixel values ​​before the deblocking and sample-adapted offset of the current image.

[0043] Whether a pseudo-reference image is included in the final reference image list of the current image can be determined after the reference image list modification process for the current slice is complete. If a pseudo-reference image is not included, IBC mode can be disabled at the slice level (e.g., completely disabled). On the decoder side, if the decoder receives an image-level indication that one or more slices of the current image (e.g., all of the slices) cannot use the pseudo-reference image as a reference, the memory access operations associated with IBC mode can be skipped. Such an indication can allow the decoder to make an initial decision on whether to allocate a buffer to store the pseudo-reference image.

[0044] A flag (e.g., use_curr_pic_as_ref_flag) can be used in the slice segment header to indicate whether the current image is included in any of the reference image lists for the current slice. Bitstream compatibility constraints can be added to ensure that the value of this additional flag remains the same for one or more slices of a given image (e.g., all slices). Table 1 shows an example slice segment header syntax using the additional flag.

[0045] [Table 1]

[0046] When a flag (e.g., use_curr_pic_as_ref_flag) is set to equal 1, this can indicate that the decoded version of the current image is included in the reference image list L0 for the current slice. When an additional flag is set to equal 0, this can indicate that the decoded version of the current image is not included in any reference image list for the current slice. When no additional flag is present, this can be treated the same as when the flag is set to equal 0.

[0047] For the purpose of bitstream compatibility, the flag value can be set to the same value for one or more slices (e.g., all slices) associated with a given image. An example of a reference image list construction process according to the techniques described herein can be shown in Table 2. An example of a construction process for a reference image list L0 (e.g., RefPicList0) can be shown in Table 3.

[0048] [Table 2]

[0049] [Table 3]

[0050] When IBC mode is enabled in SPS, bitstream compatibility constraints can be imposed on the construction of the reference image list (e.g., without using the syntax described in Tables 2 and 3). Under these constraints, the reference image list for one or more slices (e.g., all slices) in a given image can behave consistently in terms of whether a pseudo-reference image will be included in the reference image list. After receiving the bitstream of a slice in a given image, the decoder (e.g., decoder 200) can assess the likelihood that IBC mode will be applied to other slices of the same image by checking whether a pseudo-image is included in the reference image list. For example, if the slice header indicates that a pseudo-image is not included in the reference image list, the decoder can decide to skip one or more memory access operations (e.g., all memory access operations) currently associated with writing / reading samples of the image.

[0051] As described herein, the IBC mode can be enabled for the current image by adding a pseudo-reference image (e.g., a decoded version of the current image before in-loop filtering) to the reference image list L0 of the current image. The pseudo-reference image can also be included in the reference image list L1 of the current image (e.g., in some cases of bidirectional prediction use). Bidirectional prediction can be enabled by combining prediction signals from two reference images, for example, one from reference image list L0 and the other from reference image list L1. When bidirectional prediction is enabled and the pseudo-reference image is included only in reference image list L0, the reference block from the pseudo-reference image can be combined with that of the temporal reference image in L1, but not with that of other reference images in L0 (e.g., non-pseudo-reference images). As a result, the benefits of encoding for IBC-encoded CUs may be affected.

[0052] When IBC mode is enabled, the initial reference image list for the current image can be generated by adding pseudo-reference images to both reference image list L0 and reference image list L1 (for example, for a B slice). The reference image list construction process can be shown as follows. Tables 4 and 5 show exemplary syntax for constructing reference image list L0.

[0053] [Table 4]

[0054] [Table 5]

[0055] Table 6 shows an example syntax for constructing the list RefPicListTemp1 when the slice is a B slice. In the example syntax, the variable NumRpsCurrTempList1 can be set to equal Max(num_ref_idx_l1_active_minus1+1, NumPicTotalCurr).

[0056] [Table 6]

[0057] The list RefPicList1 can be constructed using the syntax shown in Table 7.

[0058] [Table 7]

[0059] If both reference image lists L0 and L1 contain pseudo-reference images, two prediction blocks from the pseudo-reference images can be combined for a CU encoded using bidirectional prediction mode. However, bidirectional predictions between the two reference blocks from the same pseudo-reference image can occur (although the block vectors may differ). Such bidirectional predictions can affect coding efficiency. Bitstream compatibility constraints can be used to prevent the combination of two reference blocks from pseudo-reference images.

[0060] IBC-encoded CUs in the current image can be distinguished from inter-encoded CUs based at least on the image order count (POC) of the current image and the image order count of the reference image used for encoding. More specifically, if the reference image has the same POC as the current image, it can be determined that the current CU was encoded in IBC mode; otherwise, it can be determined that the current CU was encoded in inter-mode.

[0061] In some embodiments, whether IBC mode is enabled can be determined based on additional criteria. For example, the respective layer identifiers (IDs) associated with the current image and the reference image can be compared (in addition to comparing the POCs, for example) to determine whether IBC mode is enabled. For example, under the Scalable Extension of HEVC (SHVC), an inter-layer reference image from an adjacent layer can be used to predict the current image. Similarly, under the 3D / Multiview Extension of HEVC, an inter-view reference image from an adjacent view at the same time can be used to predict the current image. In any of these illustrative scenarios, the reference image used for inter-prediction may have the same POC as the current image, but a different layer ID. Accordingly, in order to distinguish an IBC-encoded CU from an inter-encoded CU, the layer ID associated with the reference image can be compared with the layer ID associated with the current image (in addition to comparing the POCs of the images) to determine whether IBC mode is enabled. More specifically, if the reference image and the current image have the same POC and the same layer ID, it can be determined that the current CU was encoded in IBC mode.

[0062] Pseudoreference images can generally be treated like temporal reference images. However, there are some differences in how the two types of reference images are handled. An illustrative difference is that a pseudoreference image can be marked as a long-term reference image before the encoding (e.g., encoding and / or decoding) of the current image is complete. After the encoding of the current image is complete, the encoded image (e.g., after in-loop filtering) can be stored in the decoded image buffer (e.g., if the image was marked as a reference image for encoding future images), and the pseudoreference image can be replaced by the encoded current image (e.g., after in-loop filtering is applied) and marked as a short-term reference image in the decoded image buffer. An illustrative difference is that in some cases, a pseudoreference image cannot be used as a co-reference image for temporal motion vector prediction (TMVP). An illustrative difference is that in a random access point (RAP), one or more temporal reference images (e.g., all temporal reference images) can be removed from the decoded image buffer, but the pseudoreference image for the current image can still be retained.

[0063] Some video signals (e.g., video signals captured by a camera) may contain illumination changes such as fade-in, fade-out, crossfade, dissolve, and flash. These illumination changes can occur locally (e.g., within a region of an image) or globally (e.g., within the entire image). Weighted prediction (WP) can be used to encode video sequences with illumination variations (e.g., between temporally adjacent images), such as fades and dissolves. In an exemplary implementation of weighted prediction, interpreted video blocks can be predicted using weighted samples from one or more temporal criteria according to a linear relationship, as shown, for example, in Equation 13. WP(x,y) = w·P(x,y) + o (13) P(x,y) and WP(x,y) can be the predicted pixel values ​​at positions (x,y) before and after the weighted prediction, respectively, and w and o can be the weights and offsets used in the weighted prediction. In the case of bidirectional prediction, the weighted prediction can be performed from a linear combination of two temporal prediction signals shown by Equation 14. WP(x,y)=(w0-P0(x,y)+W1P1(x,y)+O0+O1) / 2 (14) P0(x,y) and P1(x,y) can be the first and second prediction blocks before weighted prediction, WP(x,y) can be the bidirectional prediction signal after weighted prediction, w0 and w1 can be the weights for each prediction block, and O0 and O1 can be the offsets for each prediction block.

[0064] Parameters associated with weighted predictions can be signaled within the slice header (for example, different slices in a given image can generate reference blocks for temporal prediction using different weights and offsets). Weighted predictions can be applied to IBC-encoded CUs (e.g., signaled as intercoded CUs) using prediction signals obtained from the same image (e.g., pseudo-reference images as described herein).

[0065] Weighted prediction for IBC-encoded CUs can be disabled in various ways. For example, to indicate that weighted prediction is not applied to an IBC-encoded CU, a flag associated with weighted prediction (e.g., luma_weight_lx_flag and / or chroma_weight_lx_flag) can be set (e.g., to false or zero) during signaling (e.g., in a video bitstream). For example, the weighted prediction relation flag can be skipped during the signaling process for an IBC-encoded CU (e.g., the flag can not be sent in a video bitstream). The absence of the weighted prediction relation flag can serve as an indicator that weighted prediction is disabled. Whether IBC mode is enabled for the encoding unit of the current image can be determined based on the characteristics of the current image and / or the reference image associated with the current image. For example, as described herein, if the image order counts of the current image and the reference image have the same value, it can be determined that IBC mode is applied to the current CU (for example, as described herein, the reference image can be determined to be a pseudo-reference image). In this case, weighted prediction can be disabled for the IBC-encoded CU. If the image sequence counts of the current image and the reference image have different values, it can be determined that intermode has been applied to the current CU. In this case, weighted prediction can be enabled for the intercoded CU. In some embodiments, the layer IDs associated with the current image and the reference image can be further compared to determine whether IBC mode has been applied and / or whether weighted prediction should be enabled. More specifically, if the reference image and the current image have the same POC value and the same layer ID value, it can be determined that IBC mode has been applied and weighted prediction can be disabled. If either the POC value or the layer ID is different, it can be determined that intermode has been applied and weighted prediction can be enabled.

[0066] Table 8 shows the first example syntax for handling weighted predictions, which allows signaling of weighted prediction parameters to be disabled if the image order count of the current image and the reference image associated with the current image are the same. The syntax can be included in the slice segment header. As shown, the flag luma_weight_l0_flag[i] can be set to equal to 1, indicating that weight coefficients can exist for predicting the luminance components of the reference image list L0 using RefPicList0[i]. If the flag luma_weight_l0_flag[i] is set to equal to 0, indicating that no associated weight coefficients can exist. If the flag luma_weight_l0_flag[i] is not present, indicating that processing should proceed as if the flag had a value of 0. If the flag luma_weight_l1_flag[i] is set to equal to 1, indicating that weight coefficients can exist for predicting the luminance components of the reference image list L1 using RefPicList1[i]. If the flag luma_weight_l1_flag[i] is set to equal to 0, the display may indicate that those weight coefficients cannot exist. If the flag luma_weight_l1_flag[i] does not exist, the display may indicate that processing should proceed as if the flag had a value of 0.

[0067] [Table 8]

[0068] Table 9 shows a second example syntax for handling weighted predictions, in which signaling of weighted prediction parameters can be disabled if the image order count of the current image and the reference image associated with the current image are the same, and the layer IDs of the current image and the reference image are also the same. In the example syntax, the function LayerIdCnt(refPic) can be used to obtain the layer ID of the reference image refPic. The variable nuh_layer_id can represent the NAL layer ID of the current layer. The flag pps_curr_pic_ref_enabled_flag can be used to condition the signaling of weighted prediction parameters.

[0069] [Table 9]

[0070] The example syntax shown in Table 9 can be further simplified. For example, when IBC mode is enabled in the Image Parameter Set (PPS) (e.g., the flag pps_curr_pic_ref_enabled_flag is set to 1), the reference image can have the same POC and the same layer ID as the current image. Accordingly, the flag pps_curr_pic_ref_enabled_flag can be removed from the signaling, and the simplified syntax can be shown in Table 10.

[0071] [Table 10]

[0072] As shown in Tables 9 and 10, the layer ID of the reference image associated with the current image can be checked to determine whether the reference image is from the same layer as the current image. Such a determination can also be made based on stored information (e.g., a binary variable) about whether the reference image is an inter-layer or inter-view reference image. Such information can be derived during the reference image list construction process. More specifically, while generating the reference image list, if the encoding device (e.g., decoder 200) determines that the reference image is from a different layer than the current layer, the encoding device can set the corresponding variable (e.g., a binary variable) to 1 (or true), and if not (e.g., the reference image is from the same layer as the current image), the encoding device can set the corresponding variable to 0 (or false). This information can be stored (e.g., in memory). Then, when the encoding device parses the weighted prediction parameters (e.g., using the syntax table in Table 4), additional conditions can be added based on the value of this binary variable (e.g., in addition to the POC value check) to determine whether the signaling of the weighted prediction parameters can be skipped.

[0073] When video blocks are encoded in interprediction mode as described herein, pixels from previously encoded video images can be used to predict the current encoding unit. Packet errors (e.g., due to packet loss during transmission of a compressed video bitstream) can propagate between adjacent images (e.g., from a reference image to the current image). Error propagation can be time-dependent (e.g., in error-prone environments). To mitigate error propagation and eliminate time dependence, intra-encoded blocks can be introduced (e.g., periodically). This technique can be called "intra-refreshing." Intra-encoded blocks can use previously encoded pixels of adjacent blocks as prediction criteria. If these prediction criteria are encoded using interprediction, errors can propagate through the criteria to the intra-encoded blocks.

[0074] Constrained Intra-Prediction (CIP) is an intra-prediction technique that imposes constraints on the use of adjacent blocks as reference blocks in order to enhance the accuracy of intra-prediction. When CIP is enabled, the intra-prediction of the current CU can use pixels of adjacent blocks encoded in either intra-mode or IBC mode. However, intra- or IBC encoded adjacent blocks may themselves have been predicted using inter-predicted reference samples. Therefore, errors introduced during inter-prediction can propagate to the current CU.

[0075] Figure 6 illustrates an illustrative scenario in which an error may propagate from an inter-encoded block to the current block being encoded using CIP. In the example, the current CU602 of the current image 604 (e.g., at time t) is intra-predicted using horizontal intra-prediction mode. The intra-prediction can utilize pixels in the adjacent block 606 to the left of the current CU. The adjacent block 606 itself may be predicted using IBC mode (e.g., using pixels from a previously encoded block 608 in the current image 604). However, the reference block 608 may be inter-encoded using pixels from the reference image 612 (e.g., at the previous time t-1) (e.g., from block 610). In such a scenario, an error from the reference image 612 at (t-1) may propagate to the reference block 608 in the current image 604. The error may further propagate to block 606 and then to the current CU602. Error propagation can compromise the CIP design objectives, which may include preventing error propagation from inter-encoded blocks to intra-encoded blocks.

[0076] CIP can be adapted to restrict predictions so that a block being encoded in IBC mode can be predicted using intra- or IBC-encoded pixels. Figure 7 shows how intra-predictions can be performed as proposed when CIP is enabled. In the figure, pixels from adjacent inter-encoded blocks are shown as blank rectangles, and pixels from adjacent intra-encoded blocks are shown as shaded rectangles. When CIP is enabled, restrictions (referred to herein as "CIP restrictions") can be applied so that intra-predictions of the current block can use intra-encoded neighboring samples but not inter-encoded neighboring samples. When CIP is not enabled, CIP restrictions cannot be applied.

[0077] When CIP is enabled, one or more of the following techniques may be applied. In the example, when CIP is enabled, the IBC mode may be disabled. For example, the IBC mode may be disabled by setting a flag in the Image Parameter Set (PPS) from a high level (e.g., setting curr_pic_as_ref_enabled_flag to 0). In the example, only samples of intra-encoded CUs may be allowed to be used as reference samples for intra-prediction. Samples of adjacent inter-encoded CUs (including inter-encoded CUs that refer to a temporal reference image and / or a pseudo-reference image) may not be used as reference samples for intra-prediction. In the example, intra-prediction may use an IBC-encoded CU as a reference if the IBC-encoded CU itself uses only intra-encoded CUs as a reference. In this example, temporal motion vector prediction (TMVP) may be disabled for the IBC mode. In some embodiments, IBC-encoded samples from a pseudo-reference image may not be allowed to predict an intra-encoded CU. Accordingly, errors due to temporal BV prediction can be prevented from propagating within the intra-encoded CU, and in these embodiments, TMVP can be enabled for IBC mode.

[0078] Intra-encoded CUs may be permitted to use adjacent intra-encoded samples. Under certain conditions, intra-encoded CUs may use adjacent IBC-encoded samples. For example, intra-encoded CUs may use adjacent IBC-encoded samples if those samples refer to intra-encoded samples in a previously encoded area of ​​the current image as a reference. Intra-prediction of CUs based on adjacent samples that directly or indirectly refer to a temporal reference image may be prohibited. TMVP may be disabled for IBC mode.

[0079] The exemplary techniques described herein can be applied as bitstream compatibility constraints. The exemplary techniques described herein can be applied to multiple types of images. For example, the exemplary techniques can be applied to images containing normal intercoded CUs (e.g., intercoded CUs predicted from a temporal reference image). Some I-slices and P / B-slices can contain pseudo-reference images within their reference image list, but they cannot contain temporal reference images. Therefore, intercoded CUs referencing a temporal reference cannot exist. Thus, errors in previously decoded temporal reference images can be prevented from propagating to the current image. Samples from previously recovered blocks can be used as reference samples for intra-prediction.

[0080] The exemplary techniques described herein can be applied to (e.g., only to) I-slices and P / B-slices whose respective reference image lists can include temporal reference images. If the current slice is an I-slice or P / B-slice whose reference image list contains only pseudo-reference images (e.g., the reference image list does not contain temporal reference images), then intra-encoded CUs and / or inter-encoded CUs can be used as references for intra-prediction. As described herein, whether the reference image list contains only pseudo-reference images can be determined by comparing the image sequence count associated with the current image with the respective image sequence count associated with each reference image on the reference image list. If the image sequence count associated with the current image is the same as the respective image sequence count associated with each of the reference images, then it can be determined that one or more of the exemplary techniques described herein cannot be applied. If the current slice is a P / B-slice that uses temporal reference images for prediction, then one or more of the constraints described herein can be applied. For example, the intra-sample prediction process and the temporal motion vector prediction derivation process can be performed as follows:

[0081] In relation to general intra-sample prediction, the availability derivation process for a block in the z-scan order can be invoked with the current luminance position (xCurr, yCurr) set to equal (xTbY, yTbY). The adjacent luminance position (xNbY, yNbY) can be used as input. The output can be assigned to a variable represented as availableN. The sample p[x][y] can be derived as follows. The sample p[x][y] can be marked as not available for intra-prediction if one or both of the following conditions are met. The first condition is that the variable availableN is equal to FALSE (or zero). The second condition is that the value of pictureCuPredMode[xNbY][yNbY] is not equal to MODE_INTRA, the value of DiffPicOrderCnt(aPic,CurrPic) is not equal to 0 for at least one image aPic in RefPicList0 and RefPicList1 of the current slice, and the value of constrained_intra_pred_flag is equal to 1 (or TRUE). If none of the above conditions are met, the sample p[x][y] can be marked as "available for intra-prediction", and the sample at location (xNbCmp,yNbCmp) can be assigned to p[x][y].

[0082] In relation to the derivation process for predicting temporal luminance motion vectors, the variables mvLXCol and availableFlagLXCol can be derived as follows: If slice_temporal_mvp_enabled_flag is equal to 0, both components of mvLXCol can be set to equal to 0, and availableFlagLXCol can be set to equal to 0. If the reference image is the current image and constrained_intra_pred_flag is equal to 1, it is not necessary to set both components of mvLXCol to 0 and to set availableFlagLXCol to 0.

[0083] The fourth exemplary technique can be implemented in a decoder (e.g., decoder 200) or as part of the decoding process. The decoder may consider the limitations described in relation to the fourth exemplary technique when determining whether a reference sample is available for intra-prediction. If not all reference samples are available for intra-prediction using a given prediction mode (e.g., DC, planar, and / or 3-directional prediction mode), the intra-prediction mode cannot be made applicable. Several bitstream conformances can be applied so that IBC-encoded samples referencing an intra-encoded area of ​​the current image can be used for intra-prediction. For example, a flag (e.g., constrained_intra_pred_flag) can be set to equal to 0 to indicate that the residual data of adjacent encoded blocks and the decoded samples can be used for intra-prediction. With the flag set to zero, the decoded samples may have been encoded using a reference image that is not the current image, or the decoded samples may have been encoded without such a reference image. The flag can be set to 1 to indicate that CIP can be enabled and that the intra-prediction process can use residual data and decoded samples from adjacent coding blocks, encoded without using a reference image that is not the current image. For example, when the flag is set to 1 and reference sample A is used for intra-prediction, reference sample A cannot be predicted using a reference image that is not the current image. Furthermore, in the above example scenario, if reference sample A is predicted using reference sample B from the current image, reference sample B can also be encoded using the intra-prediction mode.

[0084] As described herein, in IBC mode, at least two types of search can be performed (e.g., full-frame IBC search as shown in Figure 3, and local IBC search as shown in Figure 4). The scope of the IBC search can affect the complexity of the HEVC SCC codec. For example, a full-frame IBC search can be performed by utilizing off-chip memory to store currently unfiltered samples of the image. Such a method of storing data can be slow. A local IBC search can be performed by utilizing on-chip memory, which can be faster than using off-chip memory.

[0085] Constraints can be imposed on the range of the IBC search. For example, the maximum value of the decoded BV can be limited. More specifically, two separate values, MaxHorizontalBV and MaxVerticalBV, can be specified to limit the maximum absolute values ​​of the horizontal and vertical BV for each IBC mode. The two limits can be given the same or different values. When set to different values, the two limits can enable the achievement of different trade-offs between encoding efficiency and decoding complexity (e.g., for different profiles). To fit the bitstream, the absolute values ​​of the horizontal BV and vertical BV can be less than or equal to MaxHorizontalBV and MaxVerticalBV, respectively. The search range constraint can be applied as follows:

[0086] When the reference image is the current image, the luminance motion vector mvLX can conform to the following constraints: The absolute value of (mvLX[0]≫2) can be less than or equal to MaxHorizontalBV. The absolute value of (mvLX[1]≫2) can be less than or equal to MaxVerticalBV. When the derivation process for z-scan order block availability is initiated with input (xCurr,yCurr) set to equal (xCb,yCb) and adjacent luminance positions (xNbY,yNbY) set to equal (xPb+(mvLX[0]≫2) and (yPb+mvLX[1]≫2)), the output can be equal to TRUE. The derivation process for the z-scan sequence block availability can be equal to TRUE when the input (xCurr, yCurr) is set to be equal to (xCb, yCb) and adjacent luminance positions (xNbY, yNbY) are set to be equal to (xPb+(mvLX[0]≫2)+nPbW-1 and yPb+(mvLX[1]≫2)+nPbH-1).

[0087] Syntactic elements such as max_hor_block_vector_ibc and max_ver_block_vector_ibc can be signaled within a video parameter set (VPS), sequence parameter set, or image parameter set (PPS) to indicate the maximum absolute values ​​of horizontal and vertical BV. Table 11 shows examples of how the syntactic elements described herein can be signaled.

[0088] [Table 11]

[0089] A variable max_block_vector_present_flag with a value of 1 can indicate that the syntactic elements max_hor_block_vector_ibc_minus_min_coding_block_size and max_ver_block_vector_ibc_minus_min_coding_block_size exist. A variable max_block_vector_present_flag with a value of 0 can indicate that the syntactic elements max_hor_block_vector_ibc_minus_min_coding_block_size and max_ver_block_vector_ibc_minus_min_coding_block_size do not exist. When the variable max_block_vector_present_flag does not exist, this can be treated the same as when the variable exists and has a value of 0.

[0090] The variable max_hor_block_vector_ibc_minus_min_coding_block_size, along with MinCbSizeY, can specify the maximum value for a horizontal motion vector whose reference image is a pseudo-reference image (e.g., currPic). When the variable max_hor_block_vector_ibc_minus_min_coding_block_size does not exist, it can be inferred to be pic_width_in_luma_sample-MinCbSizeY. The value of max_hor_block_vector_ibc_minus_min_coding_block_size can be within the range of 0 to pic_width_in_luma_samples-MinCbSizeY, including both ends.

[0091] The variable max_ver_block_vector_ibc_minus_min_coding_block_size, along with MinCbSizeY, can specify the maximum value for a vertical motion vector whose reference image is a pseudo-reference image (e.g., currPic). If the variable max_ver_block_vector_ibc_minus_min_coding_block_size does not exist, it is inferred to be pic_height_in_luma_samples-MinCbSizeY. The value of max_ver_block_vector_ibc_minus_min_coding_block_size can be within the range of 0 to pic_height_in_luma_samples-MinCbSizeY, including both ends.

[0092] The variables MaxHorizontalBV and MaxVerticalBV can be derived as follows: MaxHorizontalBV = max_hor_block_vector_ibc_minus_min_coding_block_size + MinCbSizeY. MaxVerticalBV = max_ver_block_vector_ibc_minus_min_coding_block_size + MinCbSizeY. Various coding algorithms can be used to encode the maximum BV absolute value. For example, the two values ​​can be coded using unsigned exponential Golomb coding (ue). To reduce the signaling overhead of related syntax, constraints can be imposed to restrict the maximum absolute values ​​of horizontal and vertical BV to powers of 2 so that their logarithms (e.g., instead of the actual values) can be signaled. More specifically, instead of directly signaling max_hor_block_vector_ibc_minus_min_coding_block_size and max_ver_block_vector_ibc_minus_min_coding_block_size, two syntactic elements log2_max_abs_hor_block_vector_ibc_minus_min_coding_block_size and log2_max_abs_ver_block_vector_ibc_minus_min_coding_block_size can be signaled so that the values ​​of MaxHorizontalBV and MaxVerticalBV can be derived. For example, using these logarithms, MaxHorizontalBV and MaxVerticalBV can be derived as (1≪log2_max_abs_hor_block_vector_ibc_minus_min_coding_block_size)+MinCbSizeY and (1≪log2_max_abs_ver_block_vector_ibc_minus_min_coding_block_size)+MinCbSizeY, respectively.The maximum absolute values ​​of horizontal and vertical block vectors can be restricted to multiples of 2 so that the quotient of a division by 2 operation can be signaled. For example, two syntactic elements, max_hor_block_vector_ibc_minus_min_coding_block_size_div2 and max_ver_block_vector_ibc_minus_min_coding_block_size_div2, can be signaled to derive the values ​​of MaxHorizontalBV and MaxVerticalBV as (max_hor_block_vector_ibc_minus_min_block_size_div2≪1)+MinCbSizeY and (maxs_ver_block_vector_ibc_minus_min_block_size_div2≪1)+MinCbSizeY, respectively.

[0093] Figure 8A is a diagram of an exemplary communication system 800 in which one or more examples disclosed herein can be implemented. The communication system 800 can be a multiple access scheme that brings content such as voice, data, video, messaging, and broadcast to multiple wireless users. The communication system 800 can enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 800 can use one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), quadrature FDMA (OFDMA), and single-carrier FDMA (SC-FDMA).

[0094] As shown in Figure 8A, the communication system 800 may include wireless transmit / receive units (WTRUs) 802a, 802b, 802c and / or 802d (these may be collectively or together referred to as WTRU 802), radio access networks (RANs) 803 / 804 / 805, core networks 806 / 807 / 809, public switched telephone networks (PSTNs) 808, the internet 810, and other networks 812, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 802a, 802b, 802c, and 802d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRU802a, 802b, 802c, and 802d can be configured to transmit and / or receive wireless signals and may include user equipment (UEs), mobile stations, fixed or mobile subscriber units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, and consumer electronics.

[0095] The communication system 800 may also include base stations 814a and 814b. Each of the base stations 814a and 814b can be any type of device configured to wirelessly interface with at least one of the WTRUs 802a, 802b, 802c, and 802d to facilitate access to one or more communication networks, such as the core networks 806 / 807 / 809, the Internet 810, and / or network 812. As an example, base stations 814a and 814b may be base transceiver stations (BTS), node B, enode B, home node B, home enode B, site controller, access point (AP), wireless router, etc. Although base stations 814a and 814b are shown as single elements, it will be understood that base stations 814a and 814b may include any number of interconnected base stations and / or network elements.

[0096] Base station 814a can be part of RAN803 / 804 / 805, which can also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), and relay nodes. Base station 814a and / or base station 814b can be configured to transmit and / or receive wireless signals within a specific geographic area that can be called a cell (not shown). A cell can be further divided into cell sectors. For example, a cell associated with base station 814a can be divided into three sectors. Thus, in one embodiment, base station 814a can include three transceivers, i.e., one for each sector of the cell. In other embodiments, base station 814a can use multiple-input multiple-output (MIMO) technology, and thus multiple transceivers can be utilized for each sector of the cell.

[0097] Base stations 814a and 814b can communicate with one or more WTRUs 802a, 802b, 802c, and 802d through air interfaces 815 / 816 / 817, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interfaces 815 / 816 / 817 can be established using any suitable radio access technology (RAT).

[0098] More specifically, as described above, the communication system 800 can be a multiple access scheme and can use one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, base stations 814a and WTRU 802a, 802b, and 802c in RAN 803 / 804 / 805 can implement radio technologies such as Universal Mobile Communications System (UMTS) Terrestrial Radio Access (UTRA), which can establish air interfaces 815 / 816 / 817 using broadband CDMA (WCDMA®). WCDMA can include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0099] In other embodiments, base stations 814a and WTRUs 802a, 802b, and 802c can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can establish air interfaces 815 / 816 / 817 using Long-Term Evolution (LTE) and / or LTE-Advanced (LTE-A).

[0100] In other embodiments, base stations 814a and WTRUs 802a, 802b, and 802c can implement radio technologies such as IEEE 802.16 (i.e., Global Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Advanced High Speed ​​Data Rate (EDGE), and GSM EDGE (GERAN).

[0101] The base station 814b in Figure 8A can be, for example, a wireless router, home node B, home e-node B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity within a localized area such as a business, home, vehicle, or campus. In one embodiment, the base station 814b and WTRU 802c, 802d can establish a wireless local area network (WLAN) by implementing radio technologies such as IEEE 802.11. In another embodiment, the base station 814b and WTRU 802c, 802d can establish a wireless personal area network (WPAN) by implementing radio technologies such as IEEE 802.15. In yet another embodiment, the base station 814b and WTRU 802c, 802d can establish a picocell or femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.). As shown in Figure 8A, the base station 814b can have a direct connection to the internet 810. Therefore, base station 814b does not need to access the internet 810 via the core network 806 / 807 / 809.

[0102] RAN803 / 804 / 805 can communicate with core networks 806 / 807 / 809, which can be any type of network configured to bring voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more WTRU802a, 802b, 802c, and 802d. For example, core networks 806 / 807 / 809 can bring call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video distribution, etc., and / or high-level security functions such as user authentication. Although not shown in Figure 8A, it will be understood that RAN803 / 804 / 805 and / or core networks 806 / 807 / 809 can communicate directly or indirectly with other RANs using the same RAT or a different RAT as RAN803 / 804 / 805. For example, in addition to connecting to RANs 803 / 804 / 805 which can utilize E-UTRA radio technology, core networks 806 / 807 / 809 can also communicate with other RANs (not shown) that use GSM radio technology.

[0103] Core networks 806 / 807 / 809 can also act as gateways for WTRU 802a, 802b, 802c, and 802d to access PSTN 808, the Internet 810, and / or other networks 812. PSTN 808 may include circuit-switched telephone networks providing plain old telephone service (POTS). The Internet 810 may include a global system of interconnected computer networks and devices using common communication protocols such as the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) in the TCP / IP Internet Protocol suite. Network 812 may include wired or wireless networks owned and / or operated by other service providers. For example, network 812 may include other core networks connected to one or more RANs that can use the same or different RAT as RAN 803 / 804 / 805.

[0104] Some or all of the WTRU802a, 802b, 802c, and 802d within the communication system 800 may include multimode capability, i.e., WTRU802a, 802b, 802c, and 802d may include multiple transceivers for communicating with different wireless networks through different wireless links. For example, WTRU802c, shown in Figure 8A, may be configured to communicate with base station 814a, which can use cellular-based radio technology, and with base station 814b, which can use IEEE 802 radio technology.

[0105] Figure 8B is a system diagram of an exemplary WTRU802. As shown in Figure 8B, the WTRU802 may include a processor 818, a transceiver 820, a transmit / receive element 822, a speaker / microphone 824, a keypad 826, a display / touchpad 828, non-removable memory 830, removable memory 832, a power supply 834, a Global Positioning System (GPS) chipset 836, and other peripheral devices 838. It will be understood that the WTRU802 may include any subcombination of the above elements while maintaining consistency with the embodiment. Furthermore, the embodiments intend that the base stations 814a and 814b, and / or, not limited to, other nodes that base stations 814a and 814b can represent, such as transceiver stations (BTS), nodes B, site controllers, access points (APs), home nodes B, evolved home nodes B (e-nodes B), home evolved nodes B (HeNBs), home evolved node B gateways, and proxy nodes, may include some or all of the elements shown in Figure 8B and described herein.

[0106] The processor 818 can be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 818 can perform signal coding, data processing, power control, input / output processing, and / or any other functions that enable WTRU802 to operate in a wireless environment. The processor 818 can be coupled to a transceiver 820, which can be coupled to a transmit / receive element 822. Figure 8B shows the processor 818 and transceiver 820 as separate components, but it will be understood that the processor 818 and transceiver 820 can be integrated together in an electronic circuit package or chip.

[0107] The transmit / receive element 812 can be configured to transmit and / or receive signals from a base station (e.g., base station 814a) via the air interfaces 815 / 816 / 817. For example, in one embodiment, the transmit / receive element 812 may be an antenna configured to transmit and / or receive RF signals. In other embodiments, the transmit / receive element 822 may be a radiator / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In other embodiments, the transmit / receive element 822 may be configured to transmit and / or receive both RF and optical signals. It will be understood that the transmit / receive element 822 may be configured to transmit and / or receive any combination of wireless signals.

[0108] Furthermore, although the transmit / receive element 822 is shown as a single element in Figure 8B, the WTRU802 can include any number of transmit / receive elements 822. More specifically, the WTRU802 can utilize MIMO technology. Thus, in one embodiment, the WTRU802 can include two or more transmit / receive elements 822 (e.g., multiple antennas) for transmitting and receiving wireless signals through the air interfaces 815 / 816 / 817.

[0109] Transceiver 820 can be configured to modulate the signal to be transmitted by the transmit / receive element 822 and to demodulate the signal received by the transmit / receive element 822. As described above, WTRU802 can have multimode capability. Therefore, transceiver 820 can include multiple transceivers to enable WTRU802 to communicate with multiple RATs, such as UTRA and IEEE 802.11.

[0110] The WTRU802's processor 818 can be coupled to a speaker / microphone 824, a keypad 826, and / or a display / touchpad 828 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and receive user input data from them. The processor 818 can also output user data to the speaker / microphone 824, the keypad 826, and / or the display / touchpad 828. Furthermore, the processor 818 can access information from any type of suitable memory, such as non-removable memory 830 and / or removable memory 832, and store data therein. Non-removable memory 830 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 832 may include a subscriber identification unit (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 818 can access information from memory that is not physically located on the WTRU802, such as on a server or home computer (not shown), and store data therein.

[0111] The processor 818 can receive power from the power supply 834 and may be configured to distribute and / or control power to other components within the WTRU 802. The power supply 834 can be any suitable device for supplying power to the WTRU 802. For example, the power supply 834 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), a solar cell, a fuel cell, etc.

[0112] The processor 818 can also be coupled to a GPS chipset 836, which can be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 802. In addition to or instead of the information from the GPS chipset 836, the WTRU 802 can receive location information from base stations (e.g., base stations 814a, 814b) via air interfaces 815 / 816 / 817, and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 802 can acquire location information by any suitable location determination method, while maintaining consistency with the embodiments.

[0113] The processor 818 can be further coupled to other peripheral devices 838, which may include one or more software and / or hardware units that provide further features, functions, and / or wired or wireless connectivity. For example, peripheral devices 838 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photography or video), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® unit, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player unit, an internet browser, and the like.

[0114] Figure 8C is a system diagram of RAN803 and core network 806 according to an embodiment. As described above, RAN803 can communicate with WTRU802a, 802b, and 802c through air interface 815 using UTRA radio technology. RAN803 can also communicate with core network 806. As shown in Figure 8C, RAN803 may include nodes B840a, 840b, and 840c, each of which may include one or more transceivers for communication with WTRU802a, 802b, and 802c through air interface 815. Nodes B840a, 840b, and 840c may each be associated with a specific cell (not shown) within RAN803. RAN803 may also include RNC842a and 842b. It will be understood that RAN803 may include any number of nodes B and RNC while maintaining consistency with the embodiment.

[0115] As shown in Figure 8C, nodes B840a and B840b can communicate with RNC842a. Furthermore, node B840c can communicate with RNC842b. Nodes B840a, B840b, and B840c can communicate with each other via the Iub interface. RNC842a and B842b can communicate with each other via the Iur interface. Each of RNC842a and B842b can be configured to control each of the nodes B840a, B840b, and B840c to which it is connected. Furthermore, each of RNC842a and B842b can be configured to perform or support other functions such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, and data encryption.

[0116] The core network 806 shown in Figure 8C may include a media gateway (MGW) 844, a mobile switching center (MSC) 846, a serving GPRS support node (SGSN) 848, and / or a gateway GPRS support node (GGSN) 850. Although each of the above elements is shown as part of the core network 806, it will be understood that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0117] The RNC842a in RAN803 can be connected to the MSC846 in core network 806 via the IuCS interface. The MSC846 can be connected to the MGW844. The MSC846 and MGW844 can provide the WTRU802a, 802b, and 802c with access to a circuit-switched network such as the PSTN808 to facilitate communication between the WTRU802a, 802b, and 802c and conventional land line communication devices.

[0118] The RNC842a within RAN803 can also be connected to the SGSN848 in the core network 806 via the IuPS interface. The SGSN848 can be connected to the GGSN850. The SGSN848 and GGSN850 can provide the WTRU802a, 802b, and 802c with access to a packet-switched network such as the Internet 810 to facilitate communication between the WTRU802a, 802b, and 802c and IP-enabled devices.

[0119] As described above, the core network 806 can also be connected to network 812, which may include other wired or wireless networks owned and / or operated by other service providers.

[0120] Figure 8D is a system diagram of RAN804 and core network 807 according to an embodiment. As described above, RAN804 can communicate with WTRU802a, 802b, and 802c through air interface 816 using E-UTRA radio technology. RAN804 can also communicate with core network 807.

[0121] It will be understood that RAN804 may include e-nodes B860a, 860b, and 860c, but RAN804 may include any number of e-nodes B while maintaining consistency with the embodiment. Each of the e-nodes B860a, 860b, and 860c may include one or more transceivers for communicating with WTRU802a, 802b, and 802c through the air interface 816. In one embodiment, e-nodes B860a, 860b, and 860c can implement MIMO technology. Thus, e-node B860a can, for example, use multiple antennas to transmit a wireless signal to and from WTRU802a.

[0122] Each of the e-nodes B860a, 860b, and 860c can be associated with a specific cell (not shown) and configured to handle wireless resource management decisions, handover decisions, user scheduling on uplink and / or downlink, etc. As shown in Figure 8D, the e-nodes B860a, 860b, and 860c can communicate with each other through the X2 interface.

[0123] The core network 807 shown in Figure 8D may include a mobility management gateway (MME) 862, a serving gateway 864, and a packet data network (PDN) gateway 866. Although each of the above elements is shown as part of the core network 807, it will be understood that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0124] The MME862 can connect to each of the e-nodes B860a, 860b, and 860c within RAN804 via the S1 interface and can act as a control node. For example, the MME862 can be responsible for authenticating users of WTRU802a, 802b, and 802c, activating / deactivating bearers, and selecting a specific serving gateway during the initial attachment of WTRU802a, 802b, and 802c. The MME862 can also provide control plane functionality for switching between RAN804 and other RANs (not shown) using other radio technologies such as GSM or WCDMA.

[0125] The serving gateway 864 can be connected to each of the e-nodes B860a, 860b, and 860c in RAN804 via the S1 interface. The serving gateway 864 can generally route and forward user data packets to and from WTRU802a, 802b, and 802c. The serving gateway 864 can also perform other functions such as anchoring the user plane during e-node B handovers, triggering paging when downlink data is available for WTRU802a, 802b, and 802c, and managing and remembering the context of WTRU802a, 802b, and 802c.

[0126] Serving gateway 864 can also be connected to PDN gateway 866, which can provide WTRU802a, 802b, and 802c with access to packet-switched networks such as the Internet 810, facilitating communication between WTRU802a, 802b, and 802c and IP-enabled devices.

[0127] The core network 807 can facilitate communication with other networks. For example, the core network 807 can provide WTRU802a, 802b, and 802c with access to a circuit-switched network such as PSTN808 to facilitate communication between WTRU802a, 802b, and 802c and conventional land-line communication devices. For example, the core network 807 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the core network 807 and PSTN808. Furthermore, the core network 807 can provide WTRU802a, 802b, and 802c with access to network 812, which may include other wired or wireless networks owned and / or operated by other service providers.

[0128] Figure 8E is a system diagram of RAN805 and core network 809 according to an embodiment. RAN805 can be an access service network (ASN) that communicates with WTRU802a, 802b, and 802c through air interface 817 using IEEE 802.16 wireless technology. As will be discussed further below, communication links between different functional entities of WTRU802a, 802b, 802c, RAN805, and core network 809 can be defined as reference points.

[0129] As shown in Figure 8E, RAN805 may include base stations 880a, 880b, 880c and an ASN gateway 882, but it will be understood that RAN805 may include any number of base stations and ASN gateways while maintaining consistency with the embodiment. Base stations 880a, 880b, and 880c can each be associated with a specific cell (not shown) within RAN805 and each may include one or more transceivers for communicating with WTRU802a, 802b, and 802c through the air interface 817. In one embodiment, base stations 880a, 880b, and 880c can implement MIMO technology. Thus, base station 880a can, for example, use multiple antennas to transmit a wireless signal to WTRU802a and then receive a wireless signal from it. Base stations 880a, 880b, and 880c can also provide mobility management functions such as handoff triggering, tunnel establishment, radio resource management, traffic classification, and quality of service (QoS) policy enforcement. The ASN gateway 882 can act as a traffic aggregation point and can be responsible for paging, caching subscriber profiles, and routing to the core network 809.

[0130] The air interface 817 between WTRU802a, 802b, 802c and RAN805 can be defined as the R1 reference point for implementing the IEEE 802.16 specification. Furthermore, each of WTRU802a, 802b, and 802c can establish a logical interface (not shown) with the core network 809. The logical interface between WTRU802a, 802b, 802c and the core network 809 can be defined as the R2 reference point, which can be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0131] The communication links between base stations 880a, 880b, and 880c can be defined as R8 reference points, which include protocols to facilitate WTRU handover and data transfer between base stations. The communication links between base stations 880a, 880b, and 880c and the ASN gateway 882 can be defined as R6 reference points. R6 reference points may include protocols to facilitate mobility management based on mobility events associated with WTRUs 802a, 802b, and 802c, respectively.

[0132] As shown in Figure 8E, RAN805 can be connected to core network 809. The communication link between RAN805 and core network 809 can be defined as an R3 reference point, including protocols to facilitate data transfer and mobility management capabilities, for example. Core network 809 may include a Mobile IP Home Agent (MIP-HA) 884, an Authentication, Authorization, and Accounting (AAA) server 886, and a gateway 888. While each of the above elements is shown as part of core network 809, it will be understood that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0133] MIP-HA can be responsible for IP address management and can enable WTRU802a, 802b, and 802c to roam between different ASNs and / or different core networks. MIP-HA884 can provide WTRU802a, 802b, and 802c with access to packet-switched networks such as the Internet 810 to facilitate communication between WTRU802a, 802b, and 802c and IP-enabled devices. AAA server 886 can be responsible for user authentication and supporting user services. Gateway 888 can facilitate interaction with other networks. For example, gateway 888 can provide WTRU802a, 802b, and 802c with access to circuit-switched networks such as PSTN808 to facilitate communication between WTRU802a, 802b, and 802c and conventional land-line communication devices. Furthermore, gateway 888 can provide WTRU802a, 802b, and 802c with access to network 812, which may include other wired or wireless networks owned and / or operated by other service providers.

[0134] Although not shown in Figure 8E, it will be understood that RAN805 can connect to other ASNs, and core network 809 can connect to other core networks. The communication link between RAN805 and other ASNs can be defined as the R4 reference point, which may include protocols for coordinating the mobility of WTRU802a, 802b, and 802c between RAN805 and other ASNs. The communication link between core network 809 and other core networks can be defined as the R5 reference point, which may include protocols for facilitating interoperability between the home core network and the visited core network.

[0135] While the features and elements described above are in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in computer programs, software, or firmware embedded in a computer-readable medium for execution by a computer or processor. Examples of computer-readable mediums include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as built-in hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital multi-purpose disks (DVDs). A processor can be used in conjunction with software to implement a radio frequency transceiver for use in a WTRU, UE, terminal equipment, base station, RNC, or any host computer.

Claims

1. A method for video decoding, The process involves obtaining a chroma block vector associated with the current encoding unit (CU) of the current image, wherein the chroma block vector has a fractional pixel resolution. Determining whether a reference sample is available for deriving a chroma reference sample based on the chroma block vector, wherein the reference sample is determined to be available if it lies in the decoded region of the current image and in the same slice or tile as the current CU. In response to determining that the reference sample is available for deriving the chroma reference sample, The chroma reference sample of the current CU is derived by applying a 4-tap interpolation filter to the reference sample, and the derived chroma reference sample is made to correspond to a fractional sample position. Decoding the current CU based at least on the derived chroma reference sample, A method that includes this.

2. The method of claim 1, wherein the reference sample is located at each integer sample position, and each integer sample position is determined based on the chroma block vector.

3. The method of claim 1, wherein the chroma block vector is determined to have the fractional pixel resolution based on the determination that the chroma block vector points to one or more fractional chroma sample positions.

4. The method according to claim 1, wherein the current CU is decoded in intrablock copy mode.

5. The method of claim 1, wherein the current image is in 4:2:0 or 4:2:2 format.

6. The process involves obtaining a chroma block vector associated with the current encoding unit (CU) of the current image, wherein the chroma block vector has a fractional pixel resolution. Determining whether a reference sample is available for deriving a chroma reference sample based on the chroma block vector, wherein the reference sample is determined to be available if it lies in the decoded region of the current image and in the same slice or tile as the current CU. In response to determining that the reference sample is available for deriving the chroma reference sample, The chroma reference sample of the current CU is derived by applying a 4-tap interpolation filter to the reference sample, and the derived chroma reference sample is made to correspond to a fractional sample position. Decoding the current CU based at least on the derived chroma reference sample, A video decoding device equipped with a processor configured to perform the following actions.

7. The video decoding device according to claim 6, wherein the reference samples are located at each integer sample position, and each integer sample position is determined based on the chroma block vector.

8. The video decoding device according to claim 6, wherein the processor is configured to determine that the chroma block vector has the fractional pixel resolution based on the determination that the chroma block vector points to one or more fractional chroma sample positions.

9. The video decoding device according to claim 6, wherein the processor is configured to decode the current CU in intrablock copy mode.

10. The video decoding device according to claim 6, wherein the current image is in 4:2:0 or 4:2:2 format.

11. A video encoding method, The process involves obtaining a chroma block vector associated with the current encoding unit (CU) of the current image, wherein the chroma block vector has a fractional pixel resolution. Determining whether a reference sample is available for deriving a chroma reference sample based on the chroma block vector, wherein the reference sample is determined to be available if it lies in the decoded region of the current image and in the same slice or tile as the current CU. In response to determining that the reference sample is available for deriving the chroma reference sample, The chroma reference sample of the current CU is derived by applying a 4-tap interpolation filter to the reference sample, The predicted residual of the current CU is determined based at least on the derived chroma reference sample, Encoding the predicted residual and the chroma block vector, A method that includes this.

12. The process involves obtaining a chroma block vector associated with the current encoding unit (CU) of the current image, wherein the chroma block vector has a fractional pixel resolution. Determining whether a reference sample is available for deriving a chroma reference sample based on the chroma block vector, wherein the reference sample is determined to be available if it lies in the decoded region of the current image and in the same slice or tile as the current CU. Based on the determination that the aforementioned reference sample is available for deriving the aforementioned chroma reference sample, The chroma reference sample of the current CU is derived by applying a 4-tap interpolation filter to the reference sample, The predicted residual of the current CU is determined based at least on the derived chroma reference sample, Encoding the predicted residual and the chroma block vector, A video encoding device equipped with a processor configured to perform the following tasks.

13. The video encoding device according to claim 12, wherein the reference samples are located at each integer sample position, and each integer sample position is determined based on the chroma block vector.

Images