Intra block copy mode for screen content coding - Patents.com

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 coding.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 62 / 172,645, filed June 8, 2015, U.S. Provisional Patent Application No. 62 / 241,708, filed October 14, 2015, and U.S. Provisional Patent Application No. 62 / 297,736, filed February 19, 2016, the disclosures of which are incorporated herein by reference in their entireties. [Background technology]

[0003] Due to the rapidly growing use of video applications such as wireless display and cloud computing, screen content coding (SCC) is becoming increasingly important. Screen content video usually comprises computer-generated content such as text and graphics, and therefore may have different characteristics than natural content (e.g., video captured by a camera). Systems, methods, and means can be designed to exploit the unique characteristics of screen content so that it can be efficiently coded. Summary of the Invention

[0004] Described herein are systems, methods, and means for encoding video (e.g., screen content video). When encoding a video block of a current image, weighted prediction can be enabled or disabled. For example, if the video block is encoded in an intra block copy (IBC) mode, weighted prediction can be disabled. Whether an IBC mode is enabled for a video block can be determined by comparing a picture order count associated with the current image to a picture order count associated with a reference image of the current image. If the two picture order counts differ from each other, a determination can be made that the IBC mode cannot be enabled and that weighted prediction can be applied. When weighted prediction is applied, a 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, a comparison can be made between a layer ID associated with the current image and a layer ID associated with the reference image before a decision regarding the IBC mode and weighted prediction can be made. More specifically, if the respective layer IDs of the current image and the reference image are different, or if the respective image sequence counts of the current image and the reference image are different, a determination may be made that the IBC mode cannot be enabled and that weighted prediction may be applied (e.g., one or more weighted prediction parameters may be signaled).

[0005] The fractional block vector may be used to identify chrominance reference samples for the IBC coded video block. An interpolation filtering process may be utilized to generate chrominance prediction samples for the video block based on the chrominance reference samples. Furthermore, when the IBC mode is enabled, a pseudo reference image (e.g., a decoded version of the current image) may be added to both the reference image list L0 and the reference image list L1 of the current image. Constrained intra prediction (CIP) may be applied. The application of CIP may comply with several restrictions, including, for example, predicting the intra coded video block using only samples from intra coded neighboring blocks.

[0006] The video encoding device described herein may include a video encoder and / or a video decoder. 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 description of the drawings]

[0007] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which:

[0008] [Figure 1] 1 is a diagram of an example video encoder according to one or more examples described herein. [Diagram 2] 1 is a diagram of an example video decoder according to one or more examples described herein. [Diagram 3] FIG. 13 illustrates an example of a full-frame intra block copy search. [Figure 4] FIG. 13 illustrates an example of a local intra block copy search. [Figure 5A] FIG. 1 illustrates an example BV clipping operation for chrominance components. [Figure 5B]FIG. 13 illustrates that reference samples of adjacent slices may not be available for fractional chromaticity sample interpolation. [Figure 5C] A diagram showing an example of slice boundary crossing sample padding for fractional chromaticity sample interpolation. [Figure 5D] FIG. 1 illustrates an example BV clipping operation of chrominance components. [Figure 6] FIG. 1 illustrates how errors can propagate from an inter-coded reference block to a current block that is coded using constrained intra prediction (CIP). [Figure 7] FIG. 2 illustrates an example method for performing intra prediction when CIP is enabled. [Figure 8A] FIG. 1 illustrates an example communication system in which one or more disclosed embodiments may be implemented. [Figure 8B] FIG. 8B is a system diagram of an example wireless transmit / receive unit (WTRU) that may be used within the communications system shown in FIG. 8A. [Figure 8C] A system diagram of an example radio access network and an example core network that can be used within the communication system shown in FIG. 8A. [Figure 8D] A system diagram of another example radio access network and an example core network that can be used within the communication system shown in FIG. 8A. [Figure 8E] A system diagram of another example radio access network and an example core network that can be used within the communication system shown in FIG. 8A. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] A detailed description of exemplary embodiments will now be described in conjunction with various figures. It should be noted that while this description provides examples of possible implementations, the examples do not limit the scope of the present application. Furthermore, a video encoding device as described herein may include a video encoder and / or a video decoder.

[0010] FIG. 1 is a diagram of an example 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, a cable system, a network-based video streaming service, a gaming application and / or service, a 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 with software or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over 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 disks), and digital versatile disks (DVDs).

[0011] 1, video encoder 100 may include a spatial prediction unit 104, a temporal (or motion) prediction unit 106, a reference picture store 108, a motion decision and control logic unit 110, a transform unit 112, an inverse transform 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 illustrates video encoder 100 as having only one unit of each of the components described herein, those skilled in the art will understand that one or more, multiple units of the components may be used to perform the functions described herein.

[0012] The video encoder 100 may be configured to receive an input video signal 102. The input video signal 102 may have a standard resolution (e.g., 640×880) or a high resolution (e.g., 1920×1080 or higher). The video encoder 100 may process the input video signal 102 block by block. Each video block may be referred to herein as a MAC block ("MB") or a "coding 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. The extended block sizes (e.g., 64×64, 32×32, and 16×16 pixel CTUs) may be used to compress high resolution video signals (e.g., 1080 or higher). The extended block sizes may be selected at a sequence level and signaled in a sequence parameter set (SPS). The extended block sizes (e.g., CTUs) may be partitioned into one or more coding units (CUs), for example by quadtree partitioning. A CU (e.g., a 64×64 pixel CU) may be divided into prediction units. Video encoder 100 may perform prediction (e.g., intra or inter prediction) on each video block to, for example, exploit the redundancy and irrelevance inherent within the video block to reduce the amount of information that needs to be compressed and / or delivered. In an example, video encoder 100 may apply prediction at the CU level. When a CU is divided into prediction units, individual predictions may be applied to the prediction units.

[0013] Video encoder 100 may be configured to perform spatial prediction on the current video block in spatial prediction unit 104. Such prediction methods may enable video encoder 100 to predict pixels of the current video block, e.g., using pixels from one or more previously encoded neighboring blocks of the same video frame (the blocks used for prediction may be referred to herein as "prediction blocks"). The pixels of the neighboring blocks may be highly correlated to the pixels of the current video block, e.g., because the relevant video frames may contain many regions of smoothly varying intensity. Thus, by using spatial prediction, video encoder 100 may be able to remove certain spatial redundancies from the current video block and encode only the residual pixels that cannot be spatially predicted. Exemplary spatial prediction methods may include intra prediction, intra block copy prediction (IBC), and the like. Intra prediction may predict a particular sample value using adjacent previously encoded pixel samples (e.g., a column or row of samples) from the current frame (e.g., not related to any other frame). IBC prediction can predict sample values ​​for an entire block using a block of previously coded samples from the current frame.

[0014] In addition to or instead of spatial prediction, video encoder 100 may apply temporal prediction (e.g., “inter-prediction” or “motion-compensated prediction”) to the video block using temporal prediction unit 106. Temporal prediction may take advantage of the phenomenon that because a typical video sequence does not change rapidly from one frame to the next, two adjacent video frames may have high temporal redundancy. Accordingly, video encoder 100 may predict a current video block using one or more predictive blocks from a previously encoded video frame, such that temporal redundancy inherent in video signal 102 may be removed. In an example, video encoder 100 may be configured to calculate and / or signal an amount and direction of motion between a current video block and its predictive block, e.g., using one or more motion vectors, and to utilize the calculated motion information to further improve the efficiency of prediction. In one or more examples, video encoder 100 may support multiple reference pictures and assign a reference picture index to each encoded video block. Video encoder 100 may determine from which reference picture and / or reference video block in reference picture store 108 the temporal prediction signal may originate based on the reference picture index of the video block. The reference picture index may be signaled.

[0015] Video encoder 100 may select a prediction mode based on logic stored in mode decision and control logic unit 110. In the selection process, multiple factors may be considered, including, for example, rate-distortion optimization (RDO) criteria and / or bitrate requirements. In one or more examples, video encoder 100 may choose a prediction mode whose sum of absolute transform differences (SATD) is minimal. In one or more examples, video encoder 100 may select a prediction mode that has the smallest rate-distortion cost. Various other techniques may also be possible, all of which are within the scope of this disclosure.

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

[0017] 2 is a diagram of an example video decoder 200 in which one or more disclosed embodiments can be implemented. The example 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 a part of a computing device, a mobile device, a television system, a gaming 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, video decoder 200 may utilize one or more special purpose processors, general purpose processors, graphics processing units (GPUs), application specific integrated circuits (ASICs), field programmable gate array (FPGA) circuitry, state machines, etc. One or more components of video decoder 200 may be implemented using software or firmware embodied in a computer-readable medium for execution by a computer or processor.Examples of computer-readable media include electronic signals (transmitted over 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 disks), and digital versatile disks (DVDs).

[0018] The video decoder 200 may be operable to reconstruct a video signal based on an encoded version of the video signal (e.g., such as that generated by the video encoder 100). The reconstruction process may include receiving a block of an encoded video (e.g., an SCC video), obtaining a prediction block used to encode the video block, recovering a prediction residual of the video block, and reconstructing the original video block. Thus, the video decoder 200 may include components that perform functions inverse to those of the video encoder 100. For example, as shown in FIG. 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 store 216. The video decoder 200 may receive a video bitstream 202 at the entropy decoding unit 204. The entropy decoding unit 204 may unpack and entropy decode the bitstream 202, from which the entropy decoding unit 204 may extract information, such as transform coefficients, generated by the transform unit 112, the quantization unit 114, and / or the scanning unit of the video encoder 100. Additional information may also be extracted, including the coding mode, prediction mode, RDPCM mode, and / or other parameters used to encode the video block. Some of the extracted information may 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 a prediction block. The transform coefficient block may be reconstructed, inverse quantized (e.g., in inverse quantization unit 210), and inverse transformed (e.g., in inverse transform unit 212) to derive a prediction residual for the video block. The video decoder 200 may combine the residual video block and the prediction block to restore the video block to its original form.

[0019] The video decoder 200 may apply in-loop filtering to the reconstructed video blocks, such as in loop filter 214. Various in-loop filtering techniques may be used, including, for example, deblocking filtering and adaptive loop filtering. After reconstruction and filtering, the video decoder 200 may place the reconstructed video 218 in a reference picture store 216, which may then be used to encode other images and / or drive a display device. As described herein, similar reconstruction and in-loop filtering may also occur in the video encoder 100, such as by inverse quantization unit 115, inverse transform unit 113, loop filter 124, and / or reference picture store 108.

[0020] Various techniques and / or tools can be used to encode video. These techniques and / or tools can include, for example, IBC, palette coding, adaptive color conversion (ACT), and adaptive motion vector accuracy. IBC is a block matching technique. In an example implementation of IBC, a current video block can be predicted as a displacement from a previously reconstructed 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). An 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] FIG. 3 shows an example of a full-frame IBC search. Block 302 may represent the current block to be coded. The blank and shaded areas may represent coded and uncoded areas, respectively. The full-frame IBC search option may be specified during configuration of the coding system (e.g., encoder 100). Under the full-frame IBC search option, a reference block 304 may be identified among previously reconstructed pixels in the current image (e.g., from all of the pixels in the reconstructed current image). A hash-based IBC search technique may be used to determine the BV 306 to locate the reference block 304 and / or to control the encoding complexity. Samples of the previously reconstructed area may be retained during the encoding and / or decoding process before in-loop filtering (e.g., deblocking and / or sample adaptive offset (SAO)).

[0022] FIG. 4 illustrates an example of a local IBC search. A local IBC search option can be specified during configuration of an encoding system (e.g., encoder 100). With a local IBC search, an IBC prediction of a current coding unit 402 can be performed using previously reconstructed samples of a limited number of adjacent coding tree units (e.g., before in-loop filtering is activated). For example, pixels that can be used for IBC prediction of a current CU 402 can comprise pixels of coding tree units located to the left of the current CU 402 (e.g., CTU 404) and / or previously coded pixels of the current CTU (e.g., areas 403, 405, and 406, etc.). Because a smaller set of samples can be used during a local IBC search, memory bandwidth requirements (e.g., by screen content coding software) associated with IBC-related writes / reads can be reduced. For the current CU 402, a BV 407 can be determined to identify the location of a reference block 410.

[0023] Block vectors can be constrained to have integer pixel resolution / precision so that direct sample copies from reference blocks can be used during motion compensation for IBC (e.g., without pixel interpolation). Such constraints allow block vectors with fractional pixel precision to be clipped (e.g., during motion compensation) so that block vectors can point to chrominance components at inter-pixel locations. Clipping operations 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, clipping operations can be performed according to Equations 3 and 4, where mvLX[0] and mvLX[1] can represent horizontal and vertical luma motion vectors, mvCLX[0] and mvCLX[1] can represent horizontal and vertical chroma motion vectors, SubWidthC can represent the ratio of the horizontal resolution of luma and chroma, and SubHeightC can represent the ratio of the vertical resolution of luma and chroma. For 4:2:0 video, SubWidthC and SubHeightC can be equal to 2.

[0024]

number

[0025] The clipping operation described herein may be suitable for 4:4:4 chrominance formats (with which the chrominance and luma components can have the same resolution), for example, because clipping can reduce the coding complexity and / or improve the quality (e.g., subjective quality and / or objective quality) of the IBC coded CU (e.g., when the IBC coded CU has edges that are blurred or distorted by interpolation filtering). For some non-4:4:4 chrominance formats (e.g., 4:2:0 and 4:2:2), clipping may cause misalignment of the chrominance and luma components, because the chrominance components may have a different sampling rate than the luma components (e.g., in either or both the horizontal and vertical directions). This may be shown in FIG. 5A.

[0026] FIG. 5 illustrates the impact of BV clipping (e.g., performed in a motion compensation process) using an example clipping method. In an example, a current coding unit 502 may have a block size of 4×4, and a video sequence may be captured in a 4:2:0 chrominance format. Luminance and chrominance samples of a video may be represented by a circle and a triangle, respectively. An original BV 504 may point to a first reference block 506, and a clipped BV 508 may point to a second reference block 510. If the clipped BV 508 is used to fetch chrominance reference samples and the original BV 504 is used to fetch luma reference samples, the luma and chrominance reference samples (e.g., of reference blocks 506, 510) may be misaligned. If a current CU is being IBC coded and a prediction signal with misaligned luma and chrominance samples is used to predict the current CU, coding efficiency may be affected. The mismatch may result in undesirable artifacts (e.g., ghosting and / or color bleeding artifacts) in the reconstructed signal (e.g., along boundaries between adjacent objects), which may detract from the subjective quality of the reconstructed video.

[0027] For the chrominance components of the IBC encoded CU, a fractional block vector may be enabled and used. The fractional block vector may be derived (e.g., as described herein) to identify one or more chrominance reference samples. The fractional block vector may point to a fractional pel location. To generate a chrominance prediction sample for the IBC encoded CU, an interpolation filtering process may be utilized (e.g., when the block vector points to a fractional pel location). For example, referring back to FIG. 5A, a chrominance sample (e.g., one within area 506) may be identified based on the fractional BV and the length of an applicable interpolation filter. An interpolation filter may then be applied to the chrominance sample to derive a chrominance prediction sample for the IBC encoded CU. Various interpolation filters may be used to derive the chrominance prediction sample. For example, a 4-tap chrominance filter (e.g., as defined in the HEVC standard) may be used.

[0028] When fractional sample filtering for chroma components is enabled for an IBC mode, and when the current image includes multiple slices and / or tiles, chroma reference samples located near the boundaries between adjacent slices / tiles cannot be used for interpolation filtering. This can be illustrated in FIG. 5B, which shows that reference sample P0 located outside slice boundaries 540 cannot be used for fractional chroma sample interpolation. The circles in FIG. 5B can represent chroma samples at integer positions, and the triangles can represent interpolated chroma samples with fractional pixel accuracy. One example reason that reference sample P0 cannot be used for chroma interpolation processing can be because the reference sample is not in the same slice / tile as the current IBC coded CU (e.g., the reference sample can be in an adjacent slice / tile). Another example reason can be because slices / tiles in the current image can be independently decodable. Another example reason can be because it can be a design goal to predict the current IBC coded CU using reference samples from previously coded areas (e.g., already decoded areas of the current image). A chroma reference sample that cannot be used for prediction accordingly cannot be used for fractional chroma sample interpolation of an IBC coded CU. As described herein, a chroma sample can be considered usable, for example, if it is from an area of ​​the current image that has already been decoded and if it belongs to the same slice or tile as the current CU.

[0029] An example chrominance sample derivation process using the interpolation process described herein can be performed by conforming to one or more of the following: For example, the luma motion vector mvLX can comply with some bitstream compatibility constraints when the reference image is the current image. An example 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 inputs (xCurr, yCurr) (e.g., which can be set equal to (xCb, yCb)) and adjacent luma locations (xNbY, yNbY) (e.g., which can be set equal to (xRef, yRef)), the output can be equal to TRUE.

[0030]

number

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

[0032]

number

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

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

[0035] As described herein, the reference samples may not be available for fractional chromaticity interpolation processing, for example, if the reference samples belong to another slice / tile (e.g., other than the current slice / tile) or are not decoded. In these situations, padded samples from the current slice / tile or decoded region may be used for fractional chromaticity interpolation processing. This is illustrated in FIG. 5C, which shows an example of slice boundary crossing sample padding. The circles in FIG. 5C may represent chromaticity samples at integer positions, and the triangles may represent chromaticity samples at fractional positions. As shown, integer sample P0 crosses slice boundary 550 and may therefore be unavailable for chromaticity interpolation. To enable chromaticity interpolation processing, the value of integer sample P1 may be duplicated to integer sample P0.

[0036] The reference samples (e.g., for IBC coded CUs) used for the interpolation-based chrominance derivation may be from invalid regions (e.g., undecoded regions, different slices or tiles, etc.). Thus, a verification may be performed to check, for example, whether the BV uses a chrominance reference sample that is not available. The verification may introduce complexity to the encoder and / or decoder (e.g., in addition to the complexity that may result from the chrominance interpolation process itself). As described herein, the BV (e.g., for the chrominance samples) with fractional pixel precision may be clipped to a nearby (e.g., nearest) integer chrominance sample having equal or smaller horizontal and vertical coordinates. Referring back to FIG. 5A, the chrominance samples 516a, 516b, 516c, 516d may be integer chrominance samples obtained by BV clipping. However, these samples may not necessarily be the best reference for predicting the chrominance samples of the current coding unit 502. For example, there may be other integer chrominance samples from the same block as the corresponding luma component and / or closer to the current coding unit 502.

[0037] FIG. 5D illustrates the effect of BV clipping (e.g., in a motion compensation process) using an exemplary clipping method. A current coding unit 562 may have a block size of 4×4, and a video sequence may be captured in a 4:2:0 chrominance format. Luminance and chrominance samples may be represented by circles and triangles, respectively. An original BV 564 may point to a first reference block 566, while a clipped BV 568 may point to a second reference block 570. Using the exemplary clipping method, a set of integer chrominance samples may be derived (e.g., 566a, 566b, 566c, 566d in FIG. 5D). The integer chrominance samples derived from the exemplary clipping method may include one or more chrominance samples (e.g., 566a, 566b shown in FIG. 5D) from the same block as the corresponding luma sample. Additionally, integer chrominance samples 566a, 566b, 566c, and 566d in Figure 5D can be close to the current coding unit. The integer chrominance samples generated by the example 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 retrieving chrominance reference samples for an IBC coded coding unit. More specifically, for a given slice, 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, then equations 9 and 10 can be used, and if the image with index refIdx from the reference image list LX is the current image, then equations 11 and 12 can be used.

[0039]

number

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

[0041] An additional reference picture buffer may be created (e.g., in the decoded picture buffer (DPB)) to store reconstructed samples before the current picture before in-loop filtering (e.g., deblocking and / or sample adaptive offset (SAO)). A memory access operation may be performed to write or read samples to or from the reference picture buffer. Changes to the current reference picture list may be signaled in the slice segment header. Different slices in a given picture may use different reference pictures. For example, some slices may use a pseudo reference picture (e.g., when IBC mode is enabled) and other slices may not use a pseudo reference picture (e.g., when IBC mode is disabled). At the time of decoding of the current slice, information about the reference picture list for future slices of the same picture may be unknown. Thus, memory may be accessed (e.g., during both encoding and decoding) to write samples (e.g., unfiltered samples) to the buffer memory before in-loop filtering (even if IBC mode is not enabled for any slice of the current picture). As a result of the above operations, coding efficiency may be affected since the stored samples of the current picture may not (eg may never) be used as reference in IBC mode.

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

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

[0044] A flag (e.g., use_curr_pic_as_ref_flag) can be used in the slice segment header to indicate whether the current picture is included in any reference picture list of 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 (e.g., all slices) of a given picture. 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 equal to 1, it may indicate that the decoded version of the current picture is included in the reference picture list L0 of the current slice. When an additional flag is set equal to 0, it may indicate that the decoded version of the current picture is not included in any of the reference picture lists of the current slice. When the additional flag is not present, it may be treated the same as if the flag was set equal to 0.

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

[0048] [Table 2]

[0049] [Table 3]

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

[0051] As described herein, the IBC mode can be enabled for a 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 bidirectional prediction use cases). Bidirectional prediction can be enabled by combining prediction signals of 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 when the pseudo reference image is included only in reference image list L0, the reference blocks from the pseudo reference image can be combined with those of the temporal reference image in L1, but cannot be combined with those of other reference images (e.g., non-pseudo reference images) in L0. As a result, the coding benefit for IBC coded CUs can be affected.

[0052] When IBC mode is enabled, an initial reference picture list for the current picture can be generated by adding pseudo reference pictures to both reference picture list L0 and reference picture list L1 (e.g., for B slices). The reference picture list construction process can be shown as follows: Table 4 and Table 5 show an example syntax for constructing reference picture 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 may be set equal to Max(num_ref_idx_l1_active_minus1+1, NumPicTotalCurr).

[0056] [Table 6]

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

[0058] [Table 7]

[0059] If both reference picture lists L0 and L1 contain a pseudo reference picture, two prediction blocks from the pseudo reference picture can be combined for a CU that is coded using a bidirectional prediction mode. However, bidirectional prediction between two reference blocks both from the pseudo reference picture may occur (although the block vectors may be different). Such bidirectional prediction may affect coding efficiency. Bitstream compatibility constraints may be used to prevent combining two reference blocks from the pseudo reference picture.

[0060] An IBC coded CU in a current picture can be distinguished from an inter coded CU based at least on a picture order count (POC) of the current picture and a picture order count of a reference picture used for coding. More specifically, if the reference picture has the same POC as the current picture, a determination can be made that the current CU is coded in IBC mode, otherwise, a determination can be made that the current CU is coded in inter mode.

[0061] In some embodiments, whether the 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 (e.g., in addition to comparing the POC) to determine whether the IBC mode is enabled. As an example, under the scalable extension (SHVC) of HEVC, 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 example scenarios, the reference image used for inter prediction can have the same POC as the current image, but the layer ID is different. Accordingly, to distinguish IBC coded CUs from inter coded CUs, the layer ID associated with the reference image can be compared with the layer ID associated with the current image (e.g., in addition to comparing the POC of the images) to determine whether the IBC mode is enabled. More specifically, if the reference image and the current image have the same POC and the same layer ID, a determination can be made that the current CU is coded in IBC mode.

[0062] A pseudo reference picture may generally be treated like a temporal reference picture. However, there are some differences in the handling of the two types of reference pictures. An example difference is that a pseudo reference picture may be marked as a long-term reference picture before the coding (e.g., encoding and / or decoding) of a current picture is completed. After the coding of a current picture is completed, the coded picture (e.g., after in-loop filtering) may be stored in the decoded picture buffer (e.g., if the picture is marked as a reference picture for coding a future picture), and the pseudo reference picture may be replaced by the coded current picture (e.g., after in-loop filtering is applied) and marked in the decoded picture buffer as a short-term reference picture. An example difference may be that a pseudo reference picture may not be used as a collocated reference picture for temporal motion vector prediction (TMVP) in some cases. An example difference may be that at a random access point (RAP), one or more temporal reference pictures (e.g., all temporal reference pictures) may be removed from the decoded picture buffer, but the pseudo reference picture for the current picture may still be kept.

[0063] Some video signals (e.g., video signals captured by a camera) may include illumination changes such as fade-ins, fade-outs, cross-fades, dissolves, flashes, etc. 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 having illumination variations (e.g., between temporally adjacent images), such as fades and dissolves. In an example implementation of weighted prediction, an inter-predicted video block can be predicted using weighted samples from one or more temporal references, for example, according to a linear relationship as represented in Equation 13. WP(x,y)=w·P(x,y)+o (13) P(x,y) and WP(x,y) may be the predicted pixel values ​​at positions (x,y) before and after weighted prediction, respectively, and w and o may be the weights and offsets used in weighted prediction. In the case of using bi-prediction, the weighted prediction may be made from a linear combination of two temporal prediction signals as 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) may be the first and second prediction blocks before weighted prediction, WP(x,y) may be the bidirectional prediction signal after weighted prediction, w0 and w1 may be the weights for each prediction block, and O0 and O1 may be the offsets for each prediction block.

[0064] Parameters associated with weighted prediction may be signaled in the slice header (e.g., different slices in a given picture may use different weights and offsets to generate reference blocks for temporal prediction). For IBC coded CUs (e.g., signaled as inter-coded CUs), weighted prediction may be applied using a prediction signal obtained from the same picture (e.g., a pseudo-reference picture as described herein).

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

[0066] Table 8 shows a first example syntax for handling weighted prediction, whereby if the picture order counts of the current picture and the reference picture associated with the current picture are the same, the signaling of weighted prediction parameters can be disabled. The syntax can be included in a slice segment header. The flag luma_weight_l0_flag[i] can be set equal to 1 as shown, and the indication can be that a weighting factor for predicting the luma component of the reference picture list L0 using RefPicList0[i] can be present. If the flag luma_weight_l0_flag[i] is set equal to 0, the indication can be that no relevant weighting factor can be present. If the flag luma_weight_l0_flag[i] is not present, the indication can be that the processing should proceed as if the flag has a value of 0. If the flag luma_weight_l1_flag[i] is set equal to 1, the indication can be that a weighting factor for predicting the luma component of the reference picture list L1 using RefPicList1[i] can be present. If the flag luma_weight_l1_flag[i] is set equal to 0, then the indication may be that these weighting factors cannot be present. If the flag luma_weight_l1_flag[i] is not present, then the indication may be 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 prediction, whereby if the picture order counts of the current picture and the reference picture associated with the current picture are the same, and if the layer IDs of the current picture and the reference picture are also the same, the signaling of the weighted prediction parameters can be disabled. In the example syntax, the function LayerIdCnt(refPic) can be used to obtain the layer ID of the reference picture 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 the weighted prediction parameters.

[0069] [Table 9]

[0070] The example syntax shown in Table 9 can be further simplified. For example, when the IBC mode is enabled in the picture parameter set (PPS) (e.g., the flag pps_curr_pic_ref_enabled_flag is set to 1), the reference picture can have the same POC and the same layer id as the current picture. Accordingly, the flag pps_curr_pic_ref_enabled_flag can be removed from the signaling, and the simplified syntax can be represented 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., the decoder 200) determines that the reference image is from a layer different from 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). The information can be stored (e.g., in a memory). Then, when the encoding device parses the weighted prediction parameters (e.g., using the syntax table in Table 4), an additional condition can be added (e.g., in addition to the POC value check) based on the value of this binary variable to determine whether the signaling of the weighted prediction parameters can be skipped.

[0073] When a video block is coded in an inter-prediction mode as described herein, pixels from a previously coded video image can be used to predict the current coding 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 a current image). The error propagation can be, for example, due to time dependency (e.g., in an error-prone environment). To mitigate the error propagation, intra-coded blocks can be introduced (e.g., periodically) to break the time dependency. This technique can be called "intra-refreshing". Intra-coded blocks can use previously coded pixels of neighboring blocks as prediction references. If these prediction references were coded using inter prediction, errors can propagate to the intra-coded blocks through the references.

[0074] Constrained intra prediction (CIP) is an intra prediction technique whereby constraints are imposed on the use of neighboring blocks as reference blocks to enhance the accuracy of intra prediction. When CIP is enabled, intra prediction of the current CU can use pixels of neighboring blocks coded in either intra or IBC mode. However, the neighboring blocks that are intra or IBC coded may themselves be predicted using inter predicted reference samples. Thus, errors introduced during inter prediction can be propagated to the current CU.

[0075] FIG. 6 illustrates an example scenario in which an error may propagate from an inter-coded block to a current block being coded using CIP. In the example, a current CU 602 (e.g., at time t) of a current image 604 is intra predicted using a horizontal intra prediction mode. The intra prediction may utilize pixels in a neighboring block 606 to the left of the current CU. The neighboring block 606 itself may have been predicted using an IBC mode (e.g., using pixels of a previously coded block 608 in the current image 604). However, a reference block 608 may have been inter coded (e.g., from block 610) using pixels of a reference image 612 (e.g., at a previous time t-1). 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 CU 602. Error propagation may undermine CIP design goals, which may include preventing error propagation from inter-coded blocks to intra-coded blocks.

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

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

[0078] Intra-coded CUs can be allowed to use neighboring intra-coded samples. Intra-coded CUs can use neighboring IBC-coded samples under certain conditions. For example, intra-coded CUs can use neighboring IBC-coded samples if those samples refer to intra-coded samples in previously coded areas of the current picture as references. Intra prediction of CUs based on neighboring samples that directly or indirectly reference a temporal reference picture can be forbidden. TMVP can 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 that include normal inter-coded CUs (e.g., inter-coded CUs predicted from a temporal reference image). Some I-slices and P / B-slices can include pseudo-reference images in their reference image lists, but cannot include temporal reference images. Thus, there can be no inter-coded CUs that reference a temporal reference. Thus, errors in previously decoded temporal reference images can be prevented from propagating to the current image. Samples from previously reconstructed blocks can be used as reference samples for intra prediction.

[0080] The example techniques described herein may be applied to (e.g., only to) I-slices and P / B slices for which the respective reference image lists may include temporal reference images. If the current slice is an I-slice or a P / B slice for which the reference image lists include only pseudo reference images (e.g., no temporal reference images are included in the reference image list), intra-coded CUs and / or inter-coded CUs may be used as references for intra prediction. As described herein, whether the reference image list includes only pseudo reference images may be determined by comparing the image order count associated with the current image with the respective image order counts associated with the reference images on the reference image list. If the image order count associated with the current image is the same as the respective image order counts associated with each of the reference images, a determination may be made that one or more of the example techniques described herein may not be applied. If the current slice is a P / B slice that uses a temporal reference image for prediction, one or more of the constraints described herein may be applied. For example, the intra sample prediction process and the temporal motion vector prediction derivation process may be performed as follows:

[0081] In relation to intra sample prediction in general, an availability derivation process for a block in z-scan order may be launched with the current luma position (xCurr, yCurr) set equal to (xTbY, yTbY). The adjacent luma positions (xNbY, yNbY) may be used as input. The output may be assigned to a variable denoted as availableN. Sample p[x][y] may be derived as follows: If one or both of the following conditions hold, sample p[x][y] may be marked as not available for intra prediction. The first condition may be that the variable availableN is equal to FALSE (or zero). The second condition may be 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 hold, sample p[x][y] may be marked as "available for intra prediction" and the sample at position (xNbCmp,yNbCmp) may be assigned to p[x][y].

[0082] In connection with the derivation process for temporal luma motion vector prediction, the variables mvLXCol and availableFlagLXCol can be derived as follows: If slice_temporal_mvp_enabled_flag is equal to 0, then both components of mvLXCol can be set equal to 0, and availableFlagLXCol can be set equal to 0. If the reference image is the current image and constrained_intra_pred_flag is equal to 1, then setting both components of mvLXCol to 0 and setting availableFlagLXCol to 0 may be unnecessary.

[0083] The fourth example technique may be implemented in a decoder (e.g., decoder 200) or as part of a decoding process. The decoder may consider the limitations mentioned in connection with the fourth example technique when determining whether reference samples are available for intra prediction. If all reference samples are not available for intra prediction with a given prediction mode (e.g., DC, planar, and / or 33 directional prediction modes), the intra prediction mode may not be applicable. Some bitstream compatibility may be applied so that IBC encoded samples that refer to intra-coded areas of the current image may be used for intra prediction. For example, a flag (e.g., constrained_intra_pred_flag) may be set equal to 0 to indicate that the residual data and decoded samples of neighboring coding blocks may 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 using 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 that are coded without using a reference image that is not the current image. Take an example, when the flag is set to 1 and a reference sample A is used for intra prediction, the reference sample A cannot be predicted using a reference image that is not the current image. Further, in the above example scenario, if the reference sample A is predicted using a reference sample B from the current image, the reference sample B can also be coded using an intra prediction mode.

[0084] In the IBC mode as described herein, at least two types of searches can be performed: a full-frame IBC search, e.g., as shown in FIG. 3, and a local IBC search, as shown in FIG. 4. The scope of the IBC search can impact the complexity of the HEVC SCC codec. For example, a full-frame IBC search can be implemented to utilize off-chip memory to store unfiltered samples of the current image. Such a method of storing data can be slow. A local IBC search can be implemented to utilize on-chip memory, which can be faster than using off-chip memory.

[0085] Constraints on the range of the IBC search can be imposed. 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, respectively, for the IBC mode. The two constraints can be given the same or different values. When set to different values, the two constraints can enable the achievement of different trade-offs between coding efficiency and decoding complexity (e.g., for different profiles). To adapt 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 constraints can be applied as follows:

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

[0087] Syntax 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 picture parameter set (PPS) to indicate the maximum absolute values ​​of the horizontal and vertical BV. Table 11 shows examples of how the syntax elements described herein can be signaled.

[0088] [Table 11]

[0089] The variable max_block_vector_present_flag with a value of 1 may indicate that the syntax elements max_hor_block_vector_ibc_minus_min_coding_block_size and max_ver_block_vector_ibc_minus_min_coding_block_size are present. The variable max_block_vector_present_flag with a value of 0 may indicate that the syntax elements max_hor_block_vector_ibc_minus_min_coding_block_size and max_ver_block_vector_ibc_minus_min_coding_block_size are not present. When the variable max_block_vector_present_flag is not present, this may be treated the same as if the variable is present and has a value of 0.

[0090] The variable max_hor_block_vector_ibc_minus_min_coding_block_size together with MinCbSizeY may specify the maximum value for horizontal motion vectors for which the reference picture is a pseudo-reference picture (e.g., currPic). When the variable max_hor_block_vector_ibc_minus_min_coding_block_size is not present, it may be inferred to be pic_width_in_luma_sample-MinCbSizeY. The value of max_hor_block_vector_ibc_minus_min_coding_block_size may range from 0 to pic_width_in_luma_samples-MinCbSizeY, inclusive.

[0091] The variable max_ver_block_vector_ibc_minus_min_coding_block_size together with MinCbSizeY may specify the maximum value for vertical motion vectors for which the reference picture is a pseudo-reference picture (e.g., currPic). When the variable max_ver_block_vector_ibc_minus_min_coding_block_size is not present, it is inferred to be pic_height_in_luma_samples-MinCbSizeY. The value of max_ver_block_vector_ibc_minus_min_coding_block_size may range from 0 to pic_height_in_luma_samples-MinCbSizeY, inclusive.

[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 encoding algorithms can be used to encode the maximum BV absolute value. For example, the two values ​​can be encoded using an unsigned exponential-Golomb code (ue). To reduce the signaling overhead of the associated syntax, a constraint can be imposed to limit the maximum absolute value of the horizontal and vertical BV to a power of two, so that their logarithmic values ​​(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 syntax 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 may be signaled so that the values ​​of MaxHorizontalBV and MaxVerticalBV can be derived. For example, using these logarithmic values, 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 value of the horizontal and vertical block vectors can be limited to a multiple of 2 so that the quotient of a division by 2 operation can be signaled. For example, two syntax 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] 8A is a diagram of an example communication system 800 in which one or more examples disclosed herein can be implemented. The communication system 800 can be a multiple access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. The communication system 800 can enable multiple wireless users to access such content through 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), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), etc.

[0094] 8A, the communications system 800 may include wireless transmit / receive units (WTRUs) 802a, 802b, 802c, and / or 802d (which may be collectively or collectively referred to as WTRUs 802), a radio access network (RAN) 803 / 804 / 805, a core network 806 / 807 / 809, a public switched telephone network (PSTN) 808, the Internet 810, and other networks 812, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 802a, 802b, 802c, 802d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 802a, 802b, 802c, 802d may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, consumer electronics devices, and the like.

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

[0096] The base station 814a may be part of the RAN 803 / 804 / 805, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 814a and / or the base station 814b may be configured to transmit and / or receive wireless signals within a particular geographical area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, the cell associated with the base station 814a may be divided into three sectors. Thus, in one embodiment, the base station 814a may include three transceivers, one for each sector of the cell. In other embodiments, the base station 814a may use multiple-input multiple-output (MIMO) technology and thus may utilize multiple transceivers for each sector of the cell.

[0097] The base stations 814a, 814b may communicate with one or more of the WTRUs 802a, 802b, 802c, 802d over an air interface 815 / 816 / 817, which may be any suitable wireless communications link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 815 / 816 / 817 may be established using any suitable radio access technology (RAT).

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

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

[0100] In other embodiments, the base station 814a and the WTRUs 802a, 802b, 802c may implement a radio technology such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN), or the like.

[0101] The base station 814b of FIG. 8A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT for facilitating wireless connectivity within a localized area, such as an office, a home, a vehicle, a campus, etc. In one embodiment, the base station 814b and the WTRUs 802c, 802d may implement a radio technology, such as IEEE 802.11, to establish a wireless local area network (WLAN). In another embodiment, the base station 814b and the WTRUs 802c, 802d may implement a radio technology, such as IEEE 802.15, to establish a wireless personal area network (WPAN). In another embodiment, the base station 814b and the WTRUs 802c, 802d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 8A, the base station 814b may have a direct connection to the Internet 810. Therefore, base station 814b may not need to access the Internet 810 via the core networks 806 / 807 / 809.

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

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

[0104] Some or all of the WTRUs 802a, 802b, 802c, 802d in the communications system 800 may include multi-mode capabilities, i.e., the WTRUs 802a, 802b, 802c, 802d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 802c shown in FIG. 8A may be configured to communicate with a base station 814a that may use a cellular-based radio technology and with a base station 814b that may use an IEEE 802 radio technology.

[0105] Figure 8B is a system diagram of an example WTRU 802. As shown in Figure 8B, the WTRU 802 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 source 834, a Global Positioning System (GPS) chipset 836, and other peripherals 838. It will be understood that the WTRU 802 may include any subcombination of the above elements while remaining consistent with an embodiment. Embodiments also contemplate that the base stations 814a and 814b, and / or nodes that they may represent, such as, but not limited to, a transceiver station (BTS), a Node B, a site controller, an access point (AP), a Home Node B, an Evolved Home Node B (eNodeB), a Home Evolved Node B (HeNB), a Home Evolved Node B Gateway, and a proxy node, among others, may include some or all of the elements shown in FIG. 8B and described herein.

[0106] The processor 818 may be a general purpose processor, a special purpose 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 may perform signal coding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 802 to operate in a wireless environment. The processor 818 may be coupled to the transceiver 820, which may be coupled to the transmit / receive element 822. Although FIG. 8B depicts the processor 818 and the transceiver 820 as separate components, it will be understood that the processor 818 and the transceiver 820 may be integrated together in an electronic circuit package or chip.

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

[0108] 8B as a single element, the WTRU 802 may include any number of transmit / receive elements 822. More specifically, the WTRU 802 may use MIMO technology. Thus, in one embodiment, the WTRU 802 may include two or more transmit / receive elements 822 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 815 / 816 / 817.

[0109] The transceiver 820 may be configured to modulate signals to be transmitted by the transmit / receive element 822 and to demodulate signals received by the transmit / receive element 822. As mentioned above, the WTRU 802 may have multi-mode capabilities. Thus, the transceiver 820 may include multiple transceivers to enable the WTRU 802 to communicate over multiple RATs, such as, for example, UTRA and IEEE 802.11.

[0110] The processor 818 of the WTRU 802 may be coupled to and may receive user input data from 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). The processor 818 may also output user data to the speaker / microphone 824, the keypad 826, and / or the display / touchpad 828. Further, the processor 818 may access information from and store data in any type of suitable memory, such as a non-removable memory 830 and / or a removable memory 832. The non-removable memory 830 may include a random access memory (RAM), a read only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 832 may include a subscriber identity unit (SIM) card, a memory stick, a secure digital (SD) memory card, or the like. In other embodiments, the processor 818 may access information from, and store data in, memory that is not physically located on the WTRU 802, such as on a server or home computer (not shown).

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

[0112] The processor 818 may also be coupled to a GPS chipset 836, which may be configured to provide location information (e.g., longitude and latitude) regarding a current location of the WTRU 802. In addition to or instead of information from the GPS chipset 836, the WTRU 802 may receive location information from a base station (e.g., base stations 814a, 814b) over the air interface 815 / 816 / 817 and / or may determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 802 may obtain location information by way of any suitable location determination method while remaining consistent with an embodiment.

[0113] The processor 818 may further be coupled to other peripherals 838, which may include one or more software and / or hardware units that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 838 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos or videos), 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] FIG. 8C is a system diagram of a RAN 803 and a core network 806 according to an embodiment. As described above, the RAN 803 may communicate with the WTRUs 802a, 802b, 802c over an air interface 815 using UTRA radio technology. The RAN 803 may also communicate with the core network 806. As shown in FIG. 8C, the RAN 803 may include Node Bs 840a, 840b, 840c, each of which may include one or more transceivers for communicating with the WTRUs 802a, 802b, 802c over the air interface 815. The Node Bs 840a, 840b, 840c may each be associated with a particular cell (not shown) within the RAN 803. The RAN 803 may also include RNCs 842a, 842b. It will be understood that the RAN 803 may include any number of Node Bs and RNCs while remaining consistent with an embodiment.

[0115] As shown in FIG. 8C, Node B 840a, 840b can communicate with RNC 842a. Additionally, Node B 840c can communicate with RNC 842b. Node B 840a, 840b, 840c can communicate with their respective RNCs 842a, 842b via an Iub interface. The RNCs 842a, 842b can communicate with each other via an Iur interface. Each of the RNCs 842a, 842b can be configured to control the respective Node B 840a, 840b, 840c to which it is connected. Additionally, each of the RNCs 842a, 842b 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, data encryption, etc.

[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 a core network operator.

[0117] The RNC 842a in the RAN 803 may be connected to an MSC 846 in the core network 806 via an IuCS interface. The MSC 846 may be connected to a MGW 844. The MSC 846 and MGW 844 may provide the WTRUs 802a, 802b, 802c with access to circuit-switched networks, such as the PSTN 808, to facilitate communications between the WTRUs 802a, 802b, 802c and traditional land-line communications devices.

[0118] The RNC 842a in the RAN 803 may also be connected to an SGSN 848 in the core network 806 via an IuPS interface. The SGSN 848 may be connected to a GGSN 850. The SGSN 848 and GGSN 850 may provide the WTRUs 802a, 802b, 802c with access to packet-switched networks, such as the Internet 810, to facilitate communications between the WTRUs 802a, 802b, 802c and IP-enabled devices.

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

[0120] 8D is a system diagram of the RAN 804 and the core network 807 according to an embodiment. As described above, the RAN 804 can communicate with the WTRUs 802a, 802b, 802c over the air interface 816 using E-UTRA radio technology. The RAN 804 can also communicate with the core network 807.

[0121] The RAN 804 may include eNodeBs 860a, 860b, 860c, although it will be understood that the RAN 804 may include any number of eNodeBs while remaining consistent with an embodiment. The eNodeBs 860a, 860b, 860c may each include one or more transceivers for communicating with the WTRUs 802a, 802b, 802c over the air interface 816. In one embodiment, the eNodeBs 860a, 860b, 860c may implement MIMO techniques. Thus, the eNodeB 860a may transmit wireless signals to, and receive wireless signals from, the WTRU 802a, for example, using multiple antennas.

[0122] Each of the eNodeBs 860a, 860b, 860c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users on the uplink and / or downlink, etc. As shown in FIG. 8D, the eNodeBs 860a, 860b, 860c may communicate with one another over an 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 MME 862 may be connected to each of the eNodeBs 860a, 860b, 860c in the RAN 804 via an S1 interface and may act as a control node. For example, the MME 862 may be responsible for authenticating users of the WTRUs 802a, 802b, 802c, bearer activation / deactivation, selecting a particular serving gateway upon initial attach of the WTRUs 802a, 802b, 802c, etc. The MME 862 may also provide a control plane function for switching between the RAN 804 and other RANs (not shown) that use other radio technologies, such as GSM or WCDMA.

[0125] The serving gateway 864 may be connected to each of the eNodeBs 860a, 860b, 860c in the RAN 804 via an S1 interface. The serving gateway 864 may generally route and forward user data packets to or from the WTRUs 802a, 802b, 802c. The serving gateway 864 may also perform other functions such as anchoring the user plane during inter-eNodeB handovers, triggering paging when downlink data for the WTRUs 802a, 802b, 802c is available, managing and storing the context of the WTRUs 802a, 802b, 802c, etc.

[0126] The serving gateway 864 may also be connected to a PDN gateway 866, which may provide the WTRUs 802a, 802b, 802c with access to packet-switched networks, such as the Internet 810, to facilitate communications between the WTRUs 802a, 802b, 802c and IP-enabled devices.

[0127] The core network 807 may facilitate communications with other networks. For example, the core network 807 may provide the WTRUs 802a, 802b, 802c with access to circuit-switched networks, such as the PSTN 808, to facilitate communications between the WTRUs 802a, 802b, 802c and traditional land-line communications 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 the PSTN 808. Additionally, the core network 807 may provide the WTRUs 802a, 802b, 802c with access to networks 812, which may include other wired or wireless networks owned and / or operated by other service providers.

[0128] 8E is a system diagram of a RAN 805 and a core network 809 according to an embodiment. The RAN 805 may be an Access Service Network (ASN) that communicates with the WTRUs 802a, 802b, 802c over an air interface 817 using IEEE 802.16 radio technology. As discussed further below, communication links between different functional entities of the WTRUs 802a, 802b, 802c, the RAN 805, and the core network 809 may be defined as reference points.

[0129] As shown in FIG. 8E, the RAN 805 may include base stations 880a, 880b, 880c, and an ASN gateway 882, although it will be understood that the RAN 805 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 880a, 880b, 880c may each be associated with a particular cell (not shown) in the RAN 805 and each may include one or more transceivers for communicating with the WTRUs 802a, 802b, 802c over the air interface 817. In one embodiment, the base stations 880a, 880b, 880c may implement MIMO technology. Thus, the base station 880a may transmit wireless signals to and receive wireless signals from the WTRU 802a, for example, using multiple antennas. The base stations 880a, 880b, 880c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 882 may act as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 809, etc.

[0130] The air interface 817 between the WTRUs 802a, 802b, 802c and the RAN 805 may be defined as an R1 reference point that implements the IEEE 802.16 specification. Additionally, each of the WTRUs 802a, 802b, 802c may establish a logical interface (not shown) with the core network 809. The logical interface between the WTRUs 802a, 802b, 802c and the core network 809 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0131] The communication link between each of the base stations 880a, 880b, 880c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between the base stations. The communication link between the base stations 880a, 880b, 880c and the ASN gateway 882 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 802a, 802b, 802c.

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

[0133] The MIP-HA may be responsible for IP address management and may enable the WTRUs 802a, 802b, 802c to roam between different ASNs and / or different core networks. The MIP-HA 884 may provide the WTRUs 802a, 802b, 802c with access to packet-switched networks, such as the Internet 810, to facilitate communications between the WTRUs 802a, 802b, 802c and IP-enabled devices. The AAA server 886 may be responsible for user authentication and for supporting user services. The gateway 888 may facilitate interworking with other networks. For example, the gateway 888 may provide the WTRUs 802a, 802b, 802c with access to circuit-switched networks, such as the PSTN 808, to facilitate communications between the WTRUs 802a, 802b, 802c and traditional land-line communications devices. Additionally, the gateway 888 may provide the WTRUs 802a, 802b, 802c with access to the 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 the RAN 805 may be connected to other ASNs and the core network 809 may be connected to other core networks. The communication link between the RAN 805 and the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating mobility of the WTRUs 802a, 802b, 802c between the RAN 805 and the other ASNs. The communication link between the core network 809 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interoperation between a home core network and a visited core network.

[0135] Although features and elements have been described above in certain combinations, one skilled in the art will understand that each feature or element can be used alone or in any combination with the other features and elements. Furthermore, the methods described herein can be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over 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 internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor can be used in conjunction with software to implement a radio frequency transceiver for use in a WTRU, UE, terminal device, base station, RNC, or any host computer.

Claims

1. 1. A video decoding method, comprising: determining whether an intra block copy (IBC) mode is enabled for a current coding unit (CU) of a current image; Based on a determination that the IBC mode is enabled for the current CU, adding a reference image representing a decoded version of the current image to a first reference image list associated with the current image; adding the reference picture to a second reference picture list associated with the current picture, provided that bidirectional prediction is also enabled for the current CU; Enabling temporal motion vector prediction (TMVP) for the current CU on the condition that constrained intra prediction (CIP) is also enabled for the current CU, and if CIP is enabled, IBC coded samples of a decoded version of the current picture are not allowed to predict intra coded CUs of the current picture; Decoding the current CU; A method for providing the above.

2. The method of claim 1 , wherein the current CU is decoded without weighted prediction based on a determination that the IBC mode is enabled for the current CU.

3. 2. The method of claim 1, wherein based on a determination that a prediction mode for the current CU is an intra mode and a CIP is valid for the current CU, the video decoding method further includes determining whether adjacent reference samples are available to predict the current CU based on an encoding mode of adjacent reference samples of the current CU, wherein the adjacent reference samples are determined to be unavailable to predict the current CU under the condition that the adjacent reference samples are encoded in an IBC mode.

4. Based on a determination that the IBC mode is valid for a current CU, the video decoding method further comprises: deriving a chrominance block vector for the current CU; determining that the chrominance block vector has fractional pixel resolution; deriving chrominance reference samples for the current CU by applying an interpolation filter to one or more chrominance reference samples associated with the current CU at respective integer sample positions in response to determining that the chrominance block vector has fractional pixel resolution; The method of claim 1 , further comprising:

5. 5. The method of claim 4, wherein applying the interpolation filter to the one or more chrominance reference samples at the integer sample positions further comprises determining that the one or more chrominance reference samples are in a decoded region of the current image and in the same slice or tile as the current CU.

6. determining whether an intra block copy (IBC) mode is enabled for a current coding unit (CU) of a current image; Based on a determination that the IBC mode is enabled for the current CU, adding a reference image representing a decoded version of the current image to a first reference image list associated with the current image; adding the reference picture to a second reference picture list associated with the current picture, provided that bidirectional prediction is also enabled for the current CU; Enabling temporal motion vector prediction (TMVP) for the current CU on the condition that constrained intra prediction (CIP) is also enabled for the current CU, and if CIP is enabled, IBC coded samples of a decoded version of the current picture are not allowed to predict intra coded CUs of the current picture; Decoding the current CU; 1. A video decoding device comprising: a processor configured to:

7. The video decoding device of claim 6 , wherein based on a determination that the IBC mode is enabled for a current CU, the processor is configured to decode the current CU without weighted prediction.

8. 7. The video decoding device of claim 6, wherein based on a determination that the prediction mode for the current CU is intra mode and that a CIP is valid for the current CU, the processor is further configured to determine whether adjacent reference samples are available to predict the current CU based on an encoding mode of adjacent reference samples of the current CU, and it is determined that the adjacent reference samples are unavailable to predict the current CU, provided that the adjacent reference samples are encoded in an IBC mode.

9. Based on a determination that the IBC mode is valid for a current CU, the processor: deriving a chrominance block vector for the current CU; determining that the chrominance block vector has fractional pixel resolution; deriving chrominance reference samples for the current CU by applying an interpolation filter to one or more chrominance reference samples associated with the current CU at respective integer sample positions based on determining that the chrominance block vector has fractional pixel resolution; The video decoding device of claim 6 , further configured to:

10. 10. The video decoding device of claim 9, wherein the processor configured to apply the interpolation filter to the one or more chrominance reference samples at the integer sample positions is configured to determine that the one or more chrominance reference samples are in a decoded region of the current image and in the same slice or tile as the current CU.

11. 1. A video encoding method, comprising: determining whether an intra block copy (IBC) mode is enabled for a current coding unit (CU) of a current image; Based on a determination that the IBC mode is enabled for the current CU, adding a reference image representing a decoded version of the current image to a first reference image list associated with the current image; adding the reference picture to a second reference picture list associated with the current picture, provided that bidirectional prediction is also enabled for the current CU; Enabling temporal motion vector prediction (TMVP) for the current CU on the condition that constrained intra prediction (CIP) is also enabled for the current CU, and if CIP is enabled, IBC coded samples of a decoded version of the current picture are not allowed to predict intra coded CUs of the current picture; encoding the current CU; A method for providing the above.

12. 12. The method of claim 11, based on a determination that the prediction mode for the current CU is an intra mode and that a CIP is valid for the current CU, the video encoding method further includes determining whether adjacent reference samples are available to predict the current CU based on an encoding mode of adjacent reference samples of the current CU, wherein the adjacent reference samples are determined to be unavailable to predict the current CU under the condition that the adjacent reference samples are encoded in an IBC mode.

13. determining whether an intra block copy (IBC) mode is enabled for a current coding unit (CU) of a current image; Based on a determination that the IBC mode is enabled for the current CU, adding a reference image representing a decoded version of the current image to a first reference image list associated with the current image; adding the reference picture to a second reference picture list associated with the current picture, provided that bidirectional prediction is also enabled for the current CU; Enabling temporal motion vector prediction (TMVP) for the current CU on the condition that constrained intra prediction (CIP) is also enabled for the current CU, and if CIP is enabled, IBC coded samples of a decoded version of the current picture are not allowed to predict intra coded CUs of the current picture; Decoding the current CU; 1. A video encoding device comprising: a processor configured to:

14. 14. The video encoding device of claim 13, wherein based on a determination that the prediction mode for the current CU is an intra mode and that a CIP is valid for the current CU, the processor is further configured to determine whether adjacent reference samples are available to predict the current CU based on an encoding mode of adjacent reference samples of the current CU, and it is determined that the adjacent reference samples are unavailable to predict the current CU, provided that the adjacent reference samples are encoded in an IBC mode.

15. Based on a determination that the IBC mode is valid for a current CU, the processor: deriving a chrominance block vector for the current CU; determining that the chrominance block vector has fractional pixel resolution; deriving chrominance reference samples for the current CU by applying an interpolation filter to one or more chrominance reference samples associated with the current CU that are at respective integer sample positions of a decoded region of the current image and that are in the same slice or tile as the current CU; The video encoding device of claim 13 , further configured to:

Images