JP6793778B2 - Rules for in-picture prediction mode when wave plane parallelism is enabled - Google Patents

Description

Engineers use compression (also known as source coding or source encoding) to reduce the bit rate of digital video. Compression reduces the cost of storing and transmitting video information by converting the information to a lower bit rate format. Decompression (also called decoding) reconstructs a version of the original information from a compressed form. A "codec" is an encoder / decoder system.

Over the last 25 years, ITU-T H. 261 and H. 262 (MPEG-2 or ISO / IEC 13818-2), H.M. 263 and H. 264 (MPEG-4 AVC or ISO / IEC 14496-10) standard, MPEG-1 (ISO / IEC 11172-2) and MPEG-4 Visual (ISO / IEC 14496-2) standard, and SMPTE 421M (VC-1) Various video codec standards, including standards, have been adapted. Furthermore, in recent years, H. The 265 / HEVC standard (ITU-TH.265 or ISO / IEC 23008-2) has been approved. H. Extensions to the 265 / HEVC standard (eg, for scalable video coding / decoding, for coding / decoding of video with higher fidelity with respect to sample bit depth or chroma sampling rate, for screen capture content, or for multi-view coding / decoding Is currently under development. Video codec standards typically define syntax options for encoded video bitstreams and detail the parameters within the bitstream when certain features are used in encoding and decoding. Often, the video codec standard provides more details about the decoding behavior that the decoder should perform to achieve a conforming result in decoding. In addition to the codec standard, a variety of proprietary codec formats define other options for the syntax of encoded video bitstreams and their corresponding decoding behavior.

Wavefront parallel processing (“WPP”) is described in H.W. A tool available for encoding and decoding in the 265 / HEVC standard. When WPP is enabled, a portion of the picture is divided into lines in a special section called the Coded Tree Unit (“CTU”). During encoding or decoding, the first line of the CTU can be processed from left to right on a CTU-by-CTU basis. The processing of the second row of the CTU (encoding or decoding) does not have to wait for the processing of the first row of the CTU to complete. Instead, after processing is complete for some of the CTUs in the first row, this provides the information used when processing the first CTU in the second row, in the second row. The process can start. Similarly, after processing for some of the CTUs in the second row is complete, processing in the third row of the CTUs can begin. WPP facilitates parallel processing of different rows of CTUs. Different threads or processing cores can process different rows of CTUs in an alternating time delay manner.

Intrablock copy (“BC”) is available from H.M. Prediction mode under development for 265 / HEVC expansion. In the intra-BC prediction mode, the sample values of the current block in a picture are predicted using the pre-reconstructed sample values in the same picture. The block vector (“BV”) indicates the displacement of the picture from the current block to the reference block, which contains the pre-reconstructed sample values used for prediction. The BV is signaled in the bitstream. Intra BC prediction is a form of intra-picture prediction, and intra BC prediction for a block of pictures does not use any sample values other than the sample values in the same picture. Intrastring copy (“SC”) mode and intraline copy (“LC”) mode are other examples of in-picture prediction modes and are used for prediction using offset values, similar to intraBC mode. Shows the displacement to a certain position in the pre-reconstructed sample values. Palette prediction mode is another example of in-picture prediction mode, which predicts the palette used to represent colors within a section such as a coding unit (“CU”). H. Various in-picture prediction modes are not effectively used when WPP is enabled, as is currently clarified with respect to the extension of the 265 / HEVC standard.

In general, the detailed description presents innovations in the rules enforced for in-picture prediction modes when wave-plane parallelism (“WPP”) is enabled. A syntax element in the bitstream can indicate whether WPP is enabled for a video sequence, a set of pictures, or a picture. Innovation makes it easier for encoders or decoders to use in-picture prediction modes such as palette prediction mode, intra-block copy mode, intra-line copy mode, and intra-string copy mode when WPP is enabled. ..

According to one aspect of the innovation described herein, the encoder encodes the picture with WPP enabled. The encoding produces encoded data. For palette encoding modes, the encoder uses the previous palette data from the previous unit in the previous WPP row of the picture to predict the palette for the first unit in the current WPP row of the picture. The encoder outputs the encoded data as part of a bitstream.

The corresponding decoder receives the encoded data as part of the bitstream. The decoder decodes the encoded data with WPP available. The decoding reconstructs the picture. For palette decoding mode, the decoder uses the previous palette data from the previous unit in the previous WPP row of the picture to predict the palette for the first unit in the current WPP row of the picture.

According to another aspect of the innovation described herein, the encoder encodes the picture with WPP enabled. The encoding produces encoded data. For intracopy modes (eg, intrablock copy mode, intrastring copy mode, intraline copy mode), the encoder enforces one or more constraints due to WPP. The encoder outputs the encoded data as part of a bitstream.

The corresponding decoder receives the encoded data as part of the bitstream. For intracopy modes (eg, intrablock copy mode, intrastring copy mode, intraline copy mode), the encoded data meets one or more constraints due to WPP. The decoder decodes the encoded data with WPP available. The decoding reconstructs the picture.

The innovation is a tangible computer-readable medium that stores computer-executable instructions that make a computing system perform the method, as part of a computing system configured to perform the method, as part of the method. As part, it can be achieved. Various innovations can be used in combination or separately. This overview is provided to introduce in a simplified form the selected concepts described below in the detailed description. This Summary is not intended to identify the material or essential features of the Claimed Item, nor is it intended to be used to limit the scope of the Claimed Item. The above and other objects, features, and advantages of the present invention will become more apparent with the following detailed description, which proceeds with reference to the accompanying drawings.

FIG. 3 illustrates an exemplary computing system that can implement some of the embodiments described. It is a figure which shows the exemplary network environment which can realize some of the embodiments described. It is a figure which shows the exemplary network environment which can realize some of the embodiments described. It is a figure which shows the exemplary encoder system which can realize several embodiments described together. It is a figure which shows the exemplary decoder system which can realize some of the embodiments described together. It is a figure which shows an exemplary video encoder which can realize several embodiments described together. It is a figure which shows an exemplary video encoder which can realize several embodiments described together. It is a figure which shows the exemplary video decoder which can realize several embodiments described together. It is a figure which shows the timing of WPP. FIG. 5 shows reconstructed content that can be used for prediction when WPP is enabled. It is a figure which shows the mode of the pallet prediction by some of the embodiments described. It is a figure which shows the mode of the pallet prediction by some of the embodiments described. FIG. 5 is a flow chart showing encoding with palette prediction when WPP is enabled, according to some of the embodiments described. FIG. 6 is a flow chart showing decoding with palette prediction when WPP is enabled, according to some of the embodiments described. It is a figure which shows the aspect of an example of the intra-block copy prediction with respect to the current block of a picture. It is a figure which shows the aspect of an example of the intra-block copy prediction with respect to the current block of a picture. It is a figure which shows the aspect of an example of an intraline copy prediction. It is a figure which shows the aspect of an example of an intrastring copy prediction. It is a figure which shows the example z scan order about the unit of a picture. It is a figure which shows an example of the constraint on the place of the reference area about the intracopy mode when WPP is enabled by some of the embodiments described. FIG. 5 is a flow chart illustrating encoding with rules enforced for intracopy mode when WPP is enabled, according to some of the embodiments described. FIG. 5 is a flow chart illustrating decoding with rules enforced for intracopy mode when WPP is enabled, according to some of the embodiments described.

This detailed description presents innovations in enforced rules for intra-picture prediction mode when wavefront parallel processing (“WPP”) is enabled. .. For example, some of the innovations are about predicting palettes for palette coding / decoding modes when WPP is enabled. Another innovation concerns the constraints imposed during intracopy mode (intrablock copy mode, intraline copy mode, or intrastring copy mode) when WPP is enabled. The innovation facilitates the use of in-picture prediction modes by encoders or decoders when WPP is enabled.

The operations described herein are described as being performed by a video encoder or video decoder in some cases, but are often described by another type of media processing tool (eg, an image encoder or image decoder). The operation can be carried out.

Some of the innovations described herein include H. et al. Illustrated with reference to terms specific to the extension of the 265 / HEVC standard. For example, H. See JCTVC-R1005, "High Efficiency Video Coding (HEVC) Screen Content Coding: Draft 1", JCTVC-R1005_v2, August 2014, draft extension of screen content coding / decoding of 265 / HEVC standard. The innovations described herein can also be implemented for other standards or methods.

Many of the innovations described herein can improve rate distortion performance when encoding certain "artificially created" video content, such as screen capture content. In general, screen-captured video (also called screen-content video) is captured when drawn on a drawing text, computer graphics, animation-generated content, or computer display, as opposed to only the video content captured by the camera. A video that contains other similar types of content. Screen capture content typically includes repeating structures (eg graphics, text characters). Screen capture content is typically encoded in a format with high chroma sampling resolution (eg, YUV4: 4: 4 or RGB4: 4: 4), but in addition, a format with lower chroma sampling resolution (eg, YUV4:). It may be encoded at 2: 0). Common scenarios for encoding / decoding screen capture content include remote desktop conferencing, as well as encoding / decoding of graphical overlays for unprocessed (natural) video or other "mixed content" video. Some of the innovations described herein are adapted to the encoding of screen content video or other artificially created video. These innovations can be used for unprocessed video, but they may not be equally effective.

More generally, various alternatives to the examples described herein are possible. For example, some of the methods described herein can be modified by changing the order of the described method operations, dividing, repeating, or omitting specific method operations. Various aspects of the disclosed techniques can be used in combination or separately. Different embodiments use one or more of the innovations described. Some of the innovations described herein address one or more of the challenges mentioned in the Background Technology section. Typically, a given technique / tool does not solve all of these challenges.

I. Illustrative Computing System Figure 1 shows a generalized example of a suitable computing system (100) where some of the innovations described may be realized. The computing system (100) does not attempt to propose any limitation regarding the scope of use or functionality, as innovation may be realized in various general purpose or dedicated computing systems.

Referring to FIG. 1, the computing system (100) includes one or more processing units (110, 115) and memory (120, 125). The processing units (110, 115) execute computer executable instructions. The processing unit can be a general purpose central processing unit (“CPU”), a processor in an application specific integrated circuit (“ASIC”), or any other type of processor. In a multi-processing system, multiple processing units execute computer-executable instructions to increase processing power. For example, FIG. 1 shows a central processing unit (110) as well as a graphics processing unit or coprocessing unit (115). Tangible memory (120, 125) may be volatile memory (eg, registers, cache, RAM), non-volatile memory (eg, ROM, EEPROM, flash memory, etc.), or any of the two, accessible to the processing unit. It may be a combination. The memory (120, 125) allows the processing unit to execute software (180) that implements one or more innovations in the rules enforced for in-picture prediction mode when WPP is enabled. Store in the form of a suitable computer executable instruction.

The computing system may have additional features. For example, a computing system (100) has a storage device (140), one or more input devices (150), one or more output devices (160), and one or more communication connections (170). Including. An interconnect mechanism (not shown), such as a bus, controller, or network, interconnects the components of a computing system (100). Typically, operating system software (not shown) provides an operating environment for other software running on computing system (100) and coordinates the activities of components of computing system (100).

The tangible storage device (140) may be removable or non-removable and can be used to store magnetic disks, magnetic tapes or cassettes, CD-ROMs, DVDs, or information, computing systems. Includes any other medium that can be accessed within (100). The storage device (140) stores software (180) instructions that implement one or more innovations in the rules enforced for in-picture prediction mode when WPP is enabled.

The input device (150) may be a touch input device such as a keyboard, mouse, pen, or trackball, a voice input device, a scanning device, or another device that provides input to the computing system (100). For video, the input device (150) is a camera, video card, TV tuner card, screen capture module, or similar device that accepts video input in analog or digital format, or video input to a computing system (100). It may be a CD-ROM or a CD-RW to be read. The output device (160) may be a display, a printer, a speaker, a CD writer, or another device that provides output from the computing system (100).

The communication connection (170) allows communication to another computing entity through a communication medium. The communication medium carries information such as computer executable instructions, audio or video inputs or outputs, or other data in the form of modulated data signals. A modulated data signal is a signal that has one or more of its characteristics set or modified in a manner that encodes the information in the signal. By way of example, the communication medium can use electrical, optical, RF, or other carriers, without limitation.

This innovation can be explained in the general context of computer readable media. A computer-readable medium is any available tangible medium that can be accessed within a computing environment. By way of example, but not limited to, a computer-readable medium, along with a computing system (100), includes a memory (120, 125), a storage device (140), and any combination of those described above.

This innovation can be described in the general context of computer executable instructions, such as those contained within a program module and executed on a real or virtual processor of interest within a computing system. In general, a program module includes routines, programs, libraries, objects, classes, components, data structures, etc. that perform a particular task or achieve a particular abstract data type. The functionality of the program modules may be combined or divided between the program modules as desired in various embodiments. The computer executable instructions of the program module may be executed locally or within a distributed computing system.

The terms "system" and "device" are used interchangeably herein. Neither term suggests any limitation on a computing system or type of computing device, unless otherwise explicitly indicated by the context. In general, a computing system or computing device can be local or decentralized, with any combination of dedicated hardware and / or general purpose hardware and software that provides the functionality described herein. Can include.

The methods described can also be implemented using dedicated computing hardware configured to implement any of the disclosed methods. For example, the disclosure method is an ASIC, graphics processing unit ("eg,") such as an integrated circuit (eg, an ASIC digital signal processor ("DSP"), specially designed or configured to implement any of the disclosure methods. It can be realized by a programmable logic device (“PLD”) such as a GPU ”) or a field programmable gate array (“FPGA”).

For the purposes of presentation, this detailed description describes computer behavior in a computing system using terms such as "determine" and "use." These terms are a higher level abstraction of the actions performed by a computer and should not be confused with the actions performed by humans. The actual computer behavior corresponding to these terms will vary from implementation to implementation.

II. Illustrative Network Environments Figures 2a and 2b show exemplary network environments (201, 202) including a video encoder (220) and a video decoder (270). The encoder (220) and decoder (270) are connected through the network (250) using the appropriate communication protocol. The network (250) can include the Internet or another computer network.

In the network environment (201) shown in FIG. 2a, each real-time communication (“RTC”) tool (210) includes both an encoder (220) and a decoder (270) for bidirectional communication. A given encoder (220) is H.I. It is possible to produce output that conforms to the 265 / HEVC standard, SMPTE 421M standard, ISO / IEC 14496-10 standard (also known as H.264 or AVC), another standard, or a variant or extension of a proprietary format. , The corresponding decoder (270) accepts the encoded data from the encoder (220). Two-way communication can be part of a video conferencing, video telephone call, or other two- or multi-party communication scenario. The network environment (201) of FIG. 2a includes two real-time communication tools (210), but the network environment (201) may instead include three or more real-time communication tools (210) involved in multiple communications. it can.

The real-time communication tool (210) manages the encoding by the encoder (220). FIG. 3 shows an exemplary encoder system (300) that can be included in a real-time communication tool (210). Alternatively, the real-time communication tool (210) uses another encoder system. The real-time communication tool (210) also manages decoding by the decoder (270). FIG. 4 shows an exemplary decoder system (400) that can be included in a real-time communication tool (210). Alternatively, the real-time communication tool (210) uses another decoder system.

In the network environment (202) shown in FIG. 2b, the encoding tool (212) includes an encoder (220) that encodes the video for delivery to a plurality of playback tools (214), including a decoder (270). Simplex communication can be provided for video surveillance systems, webcam surveillance systems, remote desktop conference presentations, or other scenarios where video is encoded and sent from one location to one or more other locations. .. The network environment (202) of FIG. 2b includes two playback tools (214), while the network environment (202) can include more or fewer playback tools (214). Generally, the playback tool (214) communicates with the encoding tool (212) to determine the stream of video received by the playback tool (214). The playback tool (214) receives the stream, buffers the received encoded data for an appropriate period of time, and initiates decoding and playback.

FIG. 3 shows an exemplary encoder system (300) that can be included in the encoding tool (212). Alternatively, the encoding tool (212) uses another encoder system. The encoding tool (212) can also include server-side controller logic for managing connections with one or more playback tools (214). FIG. 4 shows an exemplary decoder system (400) that can be included in the playback tool (214). Alternatively, the playback tool (214) uses another decoder system. The playback tool (214) can also include client-side controller logic for managing connections with the encoding tool (212).

III. Illustrative Encoder System FIG. 3 is a block diagram of an exemplary encoder system (300) in which some of the embodiments described may be realized together. The encoder system (300) operates in one of a plurality of encoding modes, including a low latency encoding mode for real-time communication, a transcoding mode, and a higher latency encoding mode that produces media for playback from a file or stream. It can be a general purpose encoding tool, or it can be a dedicated encoding tool adapted for one such encoding mode. The encoder system (300) can be adapted to the encoding of a particular type of content (eg, screen capture content). The encoder system (300) can be implemented as part of an operating system module, as part of an application library, as part of a stand-alone application, or using dedicated hardware. Generally, the encoder system (300) receives a sequence of source video pictures (311) from the video source (310) and produces the encoded data as output to the channel (390). The encoded data output to the channel can include content encoded using the rules enforced for in-picture prediction mode when WPP is enabled.

The video source (310) can be a camera, tuner card, storage medium, screen capture module, or other digital video source. The video source (310) produces a sequence of video pictures, for example, at a frame rate of 30 frames per second. As used herein, the term "picture" generally refers to source encoded or reconstructed image data. For progressive scan video, the picture is a progressive scan video frame. For interlaced video, in an exemplary embodiment, the interlaced video frame may be deinterlaced before encoding. Alternatively, two complementary interlaced video fields are encoded together as a single video frame or as two separately encoded fields. In addition to referring to progressive scan video frames or interlaced scan video frames, the term "picture" refers to a single unpaired video field, a pair of complementary video fields, a video object plane representing a video object at a given time, Or it can indicate a region of interest in a larger image. A video object plane or area can be part of a larger image that contains multiple objects or areas in the scene.

The arriving source picture (311) is stored in the source picture temporary memory storage area (320) including a plurality of picture buffer storage areas (321, 322, ..., 32n). The picture buffer (321, 322, etc.) holds one source picture in the source picture storage area (320). After one or more of the source pictures (311) are stored in the picture buffer (321, 322, etc.), the picture selector (330) selects individual source pictures from the source picture storage area (320). The order in which the pictures are selected by the picture selector (330) for input to the encoder (340) may be different from the order in which the pictures are produced by the video source (310), eg, some The order of encoding the pictures may be delayed, allowing some later pictures to be encoded first, thus facilitating time-backward prediction. Prior to the encoder (340), the encoder system (300) may include a preprocessor (not shown) that performs preprocessing (eg, filtering) of the selected picture (311) prior to encoding. Preprocessing reduces color space conversion to primary (eg, Luma) and secondary (eg, chroma differences towards red and blue) components, as well as resampling for encoding (eg, reducing the spatial resolution of chroma components). ) Can be included. Prior to encoding, the video may be converted to a color space such as YUV, in which the sample value of the Luma (Y) component represents the brightness or brightness value and the sample value of the chroma (U, V) component. Represents the color difference value. The precise definition of the color difference value (and the conversion behavior between the YUV color space and another color space such as RGB) is implementation dependent. Generally, as used herein, the term YUV refers to a Luma (or brightness) component and one or more components, including variants such as Y'UV, YIQ, Y'IQ, and YDbDr, as well as YCbCr and YCoCg. Indicates an arbitrary color space having a chroma (or chrominance) component. Chroma sample values may be subsampled to lower chroma sampling rates (eg, in the YUV 4: 2: 0 format), or chroma sample values may have the same resolution as Luma sample values (eg, for YUV 4: 2: 0 format). For example, in the case of YUV 4: 4: 4 format). Alternatively, the video can be encoded in another format (eg, RGB 4: 4: 4, GBR 4: 4: 4, or BGR 4: 4: 4 format). In particular, the screen content video may be encoded in RGB 4: 4: 4 format, GBR 4: 4: 4 format, or BGR 4: 4: 4 format.

The encoder (340) encodes the selected picture (331) to generate an encoded picture (341) and also a memory management control operation (“MMCO”) signal (342) or reference picture set ( "RPS") Generate information. The RPS is a set of pictures that may be used for reference in motion compensation for the current picture or any subsequent picture. If the currently picture is not the first encoded picture, the encoder (340) will have one or more pre-stored in the decoded picture temporary memory storage area (360) when performing the encoding process. Encoded / decoded pictures (369) may be used. The stored encoded picture (369) is used as a reference picture for inter-picture predicting the content of the current source picture (331). The MMCO / RPS information (342) indicates to the decoder which reconstructed picture may be used as the reference picture and therefore should be stored in the picture storage area.

In general, the encoder (340) includes a plurality of encoding modules that perform encoding tasks such as tile segmentation, in-picture prediction and prediction, motion estimation and compensation, frequency conversion, quantization, and entropy coding. The exact operation performed by the encoder (340) can vary depending on the compression format. The format of the output encoded data is H.I. 265 / HEVC format, Windows® media video format, VC-1 format, MPEG-x format (eg MPEG-1, MPEG-2, or MPEG-4), H.D. It can be a 26x format (eg, H.261, H.262, H.263, H.264), or a variant or extension of another format.

The encoder (340) can divide the picture into a plurality of tiles of the same size or different sizes. For example, the encoder (340) divides the picture along tile rows and columns that define the horizontal and vertical boundaries of the tiles in the picture along with the picture boundaries, where each tile is a rectangular area. Tiles are often used to provide options for parallelism. Pictures can also be organized as one or more slices, which can be an entire picture or a section of a picture. Slices can be decoded independently of the other slices in the picture, which improves error tolerance. The content of slices or tiles is further subdivided into blocks of sample values or other sets for encoding and decoding purposes. Rows of a particular block (eg, rows of encoded tree units of slices according to the H.265 / HEVC standard) can be encoded in parallel using WPP, as described further below.

H. For syntax according to the 265 / HEVC standard, the encoder divides the content of the picture (or slice or tile) into encoded tree units. The coded tree unit (“CTU”) includes a Luma sample value organized as a Luma coded tree block (“CTB”) and a corresponding chroma sample value organized as two chroma CTBs. The size of the CTU (and its CTB) is selected by the encoder. The Luma CTB can include, for example, a Luma sample value of 64x64, 32x32, or 16x16. The CTU contains one or more coding units. The coding unit (“CU”) has a Luma coding block (“CB”) and two corresponding chroma CBs. For example, a CTU (YUV4: 4: 4 format) having a 64x64 Luma CTB and two 64x64 Chroma CTBs can be divided into four CUs, each of which is a 32x32 Luma CB and 2 Includes two 32x32 chroma CBs, each CU is optionally further subdivided into smaller CUs. Alternatively, as another example, a CTU (YUV 4: 2: 0 format) having a 64x64 Luma CTB and two 32x32 chroma CTBs can be divided into four CUs, each of which is 32x. Each CU is subdivided into smaller CUs, including 32 Luma CBs and two 16x16 Chroma CBs. The minimum acceptable size of CU (eg, 8x8, 16x16) can be signaled within the bitstream.

In general, the CU has a predictive mode such as inter or intra. The CU includes one or more prediction units for the purpose of signaling and / or predicting prediction information (prediction mode details, displacement values, etc.). The prediction unit (“PU”) has a Luma prediction block (“PB”) and two chroma PBs. H. For intra-predicted CUs according to the 265 / HEVC standard, PUs have the same size as CUs, unless the CUs have a minimum size (eg 8x8). In that case, the CU can be divided into four smaller PUs (eg, 4x4 each if the minimum CU size in the in-picture prediction is 8x8), or the PUs are the syntax elements of the CU. Can have a minimum CU size, as indicated by. However, in the case of the symmetric or asymmetric division used in the intra-BC prediction, the larger CU can be split into multiple PUs.

The CU further has one or more conversion units intended for residual coding / decoding, in which case the conversion unit (“TU”) contains a Luma conversion block (“TB”) and two chroma TBs. Have. The PU of the intra-predicted CU may include a single TU (equal in size to the PU) or multiple TUs. The encoder determines how the video is divided into CTU, CU, PU, TU, and so on.

H. In the 265 / HEVC implementation, slices can contain a single slice segment (independent slice segment) or can be divided into multiple slice segments (independent slice segment and one or more dependent slice segments). .. A slice segment is a contiguously ordered integer CTU in a tile scan and is contained within a single network abstraction layer (“NAL”) unit. For independent slice segments, the slice segment header contains the value of the syntax element that corresponds to the independent slice segment. For dependent slice segments, the truncated slice segment header contains some values of the syntax element that corresponds to that dependent slice segment, and the values of the other syntax elements for the dependent slice segment are earlier in the decoding order. Inferred from the value of the independent slice segment of.

As used herein, the term "block" can refer to a macroblock, residual data unit, CB, PB, or TB, or any other set of sample values, depending on the context. The term "unit" can refer to a set of macroblocks, CTUs, CUs, PUs, TUs, or any other block, depending on the context, or can refer to a single block.

Returning to FIG. 3, the encoder predicts the intra-encoded blocks, lines, or strings of the source picture (331) from other pre-reconstructed sample values in that picture (331). Represent. For intra-copy prediction, the in-picture estimator estimates the displacement from the current block, line, or string to position in another pre-reconstructed sample value. A reference block, line, or string of sample values in the picture is used to generate a prediction value for the current block, line, or string. For example, in the case of intra-block copy (“BC”) prediction, the in-picture estimator estimates the displacement from the current block to a position in the pre-reconstructed sample value in the picture. The reference block is a block of sample values in the picture that provides BC predictions for the current block. The reference block can be indicated by a block vector (“BV”) value (determined by BV estimation). As another example, in the case of intraline copy (“LC”) prediction, the in-picture estimator moves from the current line (of the current block) to a position in the pre-reconstructed sample value in the picture. Estimate the displacement. The reference line is a line of sample values in the picture that provides LC predictions for the current line. The reference line can be indicated by an offset value that indicates the displacement from the current line to the reference line. As another example, in the case of intrastring copy (“SC”) prediction, the in-picture estimator moves from the current string (of the current block) to a position in the picture with a pre-reconstructed sample value. Estimate the displacement. The reference string is a set of sample values in the picture that are used to generate SC predictions for the current string. The reference string can be indicated by an offset value (indicating the displacement from the current string to the reference string), and a string length value. Depending on the implementation, the encoder uses the input sample value or the reconstructed sample value (pre-encoded sample value of the same picture) to perform offset estimation of blocks, lines, or strings. be able to. When WPP is enabled, the in-picture estimator will perform displacements consistent with constraints on the location of the reference region (eg, with respect to the BV value of the intra BC prediction, or with the intra SC prediction or intra LC, as described below. (For the offset value of the prediction) can be determined.

For intra-spatial prediction for a block, the in-picture estimator estimates the extrapolation of adjacent reconstructed sample values to the block.

The in-picture estimator can output prediction information (BV value for intra BC prediction, offset value for intra LC or intra SC prediction, or prediction mode (direction) for intra space prediction), which is entropy encoded. Will be done. The in-picture predictor applies the forecast information to determine the intra-predicted value.

In the palette coding mode, the encoder (340) represents at least a portion of the sample values of the CU, or other unit that uses the palette. The palette represents the colors used in the unit. For example, the palette maps index values 0, 1, 2, ..., P to the corresponding colors. While encoding the unit, the appropriate index value replaces the sample value at a position within the unit. Rare values within a unit can be encoded using escape code values and literal values instead of using palette index values. The palette can be changed for each unit, and the information that specifies the palette can be signaled within the bitstream.

The encoder (340) represents an inter-picture encoded prediction block of the source picture (331) in terms of prediction from the reference picture. The motion estimator estimates the motion of the block with respect to one or more reference pictures (369). When a plurality of reference pictures are used, the plurality of reference pictures can be from different time directions or the same time direction. The motion-compensated predictive reference region is the region of sample values in the reference picture that is used to produce motion-compensated predictive values for the block of sample values in the current picture. The motion estimator outputs motion information such as motion vector (“MV”) information, which is entropy-encoded. The motion compensator applies the MV to the reference picture (369) to determine the motion compensated prediction value for the inter-picture prediction.

The encoder can determine the difference (if any) between the predicted value of the block (intra or inter) and the corresponding original value. These predicted residual values are further encoded using frequency conversion (if frequency conversion is not skipped), quantization, and entropy encoding. For example, the encoder (340) sets the value of the quantization parameter (“QP”) for other parts of the picture, tile, slice, and / or video and quantizes the conversion factor as appropriate. The entropy encoder of the encoder (340) compresses the quantized conversion coefficient value as well as specific side information (eg, MV information, BV information, QP value, mode determination, parameter selection). Typical entropy coding techniques include exponential Golomb coding, Golomlays coding, arithmetic coding, difference coding, Huffman coding, run length coding, variable length vs. variable length (“V2V”) coding, and variable. Long vs. fixed length (“V2F”) coding, Lempeljib (“LZ”) coding, dictionary coding, stochastic interval segment entropy coding (“PIPE”), and combinations of the above. Entropy encoders can use different coding techniques for different types of information and can apply a combination of techniques (eg, by applying arithmetic coding after Golomulais coding). ), You can choose from multiple code tables within a particular coding technique. In some implementations, frequency conversion can be skipped. In this case, the predicted residual value can be quantized and entropy coded. When the palette encoding mode is used, the entropy encoder can encode the palette data. The encoder (340) can use palette prediction as described below.

An adaptive deblocking filter is included within the motion compensation loop of the encoder (340) (ie, "in-loop" filtering) to smooth out discontinuities across block boundary rows and / or columns in the decoded picture. .. Alternatively or in addition, other filtering (deringing filtering, adaptive loop filtering (“ALF”), or sample adaptive offset (“SAO”) filtering, not shown) is applied as an in-loop filtering operation. be able to.

The encoded data generated by the encoder (340) contains syntax elements for various layers of bitstream syntax. H. In the case of syntax according to the 265 / HEVC standard, for example, the picture parameter set (“PPS”) is a syntax structure that includes syntax elements that may be associated with the picture. The PPS can be used for a single picture, or the PPS can be reused for multiple pictures in a sequence. The PPS is typically signaled separately from the encoded data for the picture (eg, one network abstraction layer (“NAL”) unit for the PPS, and one or more for the encoded data for the picture. Other NAL units). In the encoded data of the picture, the syntax element indicates which PPS to use for the picture. Similarly, H. For syntax according to the 265 / HEVC standard, the sequence parameter set (“SPS”) is a syntax structure that includes syntax elements that may be associated with the sequence of pictures. The bitstream can contain a single SPS or multiple SPS. The SPS is typically signaled separately from the other data for the sequence and indicates which SPS the syntax element in the other data uses.

Equivalent to MMCO / RPS information (342) due to the encoded picture (341) and MMCO / RPS information (342) (or the dependency and order structure for the picture already known in the encoder (340). Information) is processed by the decoding processing emulator (350). The decoding processing emulator (350) implements some of the functionality of the decoder, eg, the decoding task of reconstructing a reference picture. In a manner consistent with the MMCO / RPS information (342), the decoding processing emulator (350) has a given encoded picture (341) for use as a reference picture in the inter-picture prediction of the subsequent picture to be encoded. ) Needs to be reconstructed and stored. If the encoded picture (341) needs to be stored, the decoding processing emulator (350) receives the encoded picture (341) and produces the corresponding decoded picture (351). Model the decoding process that will be performed by the decoder. In doing so, if the encoder (340) is using the decoded picture (369) stored in the decoded picture storage area (360), the decoding processing emulator (350) will use the storage area (350). The decoded picture (369) from 360) is further used as part of the decoding process.

The decoded picture temporary memory storage area (360) includes a plurality of picture buffer storage areas (361, 362, ..., 36n). In a manner consistent with the MMCO / RPS information (342), the decoding processing emulator (350) manages the content of the storage area (360) and is no longer needed for use as a reference picture by the encoder (340). Identify any picture buffer (361, 362, etc.) with. After modeling the decoding process, the decoding process emulator (350) stores the newly decoded picture (351) in the picture buffers (361, 362, etc.) thus identified.

The encoded picture (341) and MMCO / RPS information (342) are buffered in a temporarily encoded data area (370). The encoded data aggregated in the encoded data area (370) contains the encoded data for one or more pictures as part of the syntax of the basic encoded video bitstream. The encoded data aggregated in the encoded data area (370) contains media metadata associated with the encoded video data (eg, one or more additional extended information (“SEI”) messages or videos. Usability information ("VUI") can be further included (as one or more parameters in the message).

The aggregated data (371) from the temporarily encoded data area (370) is processed by the channel encoder (380). The channel encoder (380) transmits the aggregated data as a media stream for transmission or storage (eg, a media program stream or transport stream format such as ITU-TH 222.0 | ISO / IEC 13818-1). It can be packetized and / or multiplexed (or according to an Internet real-time transport protocol format such as IETF RFC 3550), in which case the channel encoder (380) will make the syntax element part of the syntax of the media transmission stream. Can be added. Alternatively, the channel encoder (380) can organize the aggregated data for storage as a file (eg, according to a media container format such as ISO / IEC 14496-12), in which case the channel encoder (380). ) Can add syntax elements as part of the syntax of a media storage file. Alternatively, more generally, the channel encoder (380) can implement one or more media system multiplexing or transport protocols, in which case the channel encoder (380) has syntactic elements in the protocol. Can be added as part of the tax. A channel encoder (380) provides an output to a channel (390), which represents a storage device, a communication connection, or another channel for output. The channel encoder (380) or channel (390) may further include, for example, other elements (not shown) for forward error correction (“FEC”) encoding and analog signal modulation.

IV. An exemplary decoder system FIG. 4 is a block diagram of an exemplary decoder system (400) in which some of the embodiments described may be implemented together. The decoder system (400) can operate in any of a plurality of decoding modes, such as a low latency decoding mode for real-time communication and a higher latency decoding mode for playing media from a file or stream. It can be a general purpose decoding tool, or it can be a dedicated decoding tool adapted for one such decoding mode. The decoder system (400) can be implemented as part of an operating system module, as part of an application library, as part of a stand-alone application, or using dedicated hardware. In general, the decoder system (400) receives the encoded data from the channel (410) and produces the reconstructed picture as an output to the output destination (490). The encoded data received can include content encoded using the rules enforced for in-picture prediction mode when WPP is enabled.

The decoder system (400) includes a channel (410), which can represent another channel for encoded data as a storage device, communication connection, or input. Channel (410) produces coded data that is channel-encoded. The channel decoder (420) can process the encoded data. For example, the channel decoder (420) may be (eg, a media program stream or transport stream format such as ITU-TH 222.0 | ISO / IEC 13818-1, or an Internet real-time transport protocol format such as IETF RFC 3550. De-packetizes and / or demultiplexes the data aggregated as a media stream for transmission or storage (according to), in which case the channel decoder (420) is a media transmission stream. You can parse the syntax elements added as part of the syntax. Alternatively, the channel decoder (420) separates the encoded video data that is aggregated as a file for storage (eg, according to a media container format such as ISO / IEC 11496-12), in which case the channel decoder. (420) can parse the syntax elements added as part of the syntax of the media storage file. Alternatively, more generally, the channel decoder (420) can implement one or more media system multiplexing or transport protocols, in which case the channel decoder (420) is part of the syntax of the protocol. You can parse the syntax elements added as. The channel (410) or channel decoder (420) may further include, for example, other elements (not shown) for FEC decoding and analog signal modulation.

The encoded data (421) output from the channel decoder (420) is stored in the temporary encoded data area (430) until a sufficient amount of such data is received. The encoded data (421) includes the encoded picture (431) and MMCO / RPS information (432). The encoded data (421) in the encoded data area (430) contains encoded data for one or more pictures as part of the syntax of the basic encoded video bitstream. The encoded data (421) in the encoded data area (430) uses the media metadata associated with the encoded video data as one or more parameters in, for example, one or more SEI or VUI messages. ) Can be further included.

In general, the encoded data area (430) temporarily stores such encoded data (421) until the encoded data (421) is used by the decoder (450). At that time, the encoded data for the encoded picture (431) and the MMCO / RPS information (432) is transferred from the encoded data area (430) to the decoder (450). As the decoding continues, new encoded data is added to the encoded data area (430), and the oldest encoded data remaining in the encoded data area (430) goes to the decoder (450). Transferred.

The decoder (450) decodes the encoded picture (431) to produce the corresponding decoded picture (451). The picture can be divided into multiple tiles of the same size or different sizes. Pictures can also be organized as one or more slices. The content of slices or tiles can be further subdivided into blocks of sample values or other sets. If a picture is encoded with WPP enabled (using WPP or in a manner consistent with using WPP during decoding), then a specific block of lines (eg, for example, as described below). Lines of CTU according to H.265 / HEVC standard) can be decoded in parallel using WPP.

If necessary, the decoder (450) may use one or more pre-decoded pictures (469) as reference pictures for inter-picture prediction while performing the decoding process. The decoder (450) reads the pre-decoded picture (469) from the decoded picture temporary memory storage area (460). In general, the decoder (450) performs decoding tasks such as entropy decoding, in-picture prediction, motion-compensated inter-picture prediction, dequantization, reverse frequency conversion (if not skipped), and tile merging. Includes multiple decoding modules. The exact operation performed by the decoder (450) can vary depending on the compression format.

For example, the decoder (450) receives encoded data for a compressed picture or sequence of pictures and produces an output containing the decoded picture (451). In the decoder (450), the buffer receives the encoded data for the compressed picture and makes the received encoded data available to the entropy decoder in a timely manner. The entropy decoder entropy-decodes the entropy-encoded quantized data as well as the entropy-encoded side information, typically applying the reverse of the entropy encoding performed by the encoder. When the palette decoding mode is used, the entropy decoder can decode the palette data. The decoder (450) can use palette prediction as described below.

The motion compensator applies motion information to one or more reference pictures to form motion compensated predictions for any intercoded block of the reconstructed picture. The in-picture prediction module can spatially predict the sample value of the current block from adjacent pre-reconstructed sample values. Alternatively, for intra BC prediction, intra LC prediction, or intra SC prediction, the in-picture prediction module uses pre-reconstructed sample values of the picture reference block, line, or string indicated by the displacement value. , Current block, line, or string sample values can be predicted. Specifically, the reference block / line / string uses the BV value (in the case of intra BC prediction), the offset value (in the case of intra LC prediction), or the offset value and the string length value (in the case of intra SC prediction). Can be shown. When the WPP is enabled, the displacement (eg, with respect to the BV value of the intra BC prediction, or with respect to the offset value of the intra SC or intra LC prediction) is relative to the location of the reference region, as described below. Consistent with constraints.

The decoder (450) further reconstructs the predicted residual values. The dequantizer dequantizes the entropy-decoded data. For example, the decoder (450) sets QP values for pictures, tiles, slices, and / or other parts of the video based on the syntax elements in the bitstream, and dequantizes the conversion factors as appropriate. The inverse frequency converter converts the quantized frequency domain data into spatial domain data. In some implementations, frequency conversion can be skipped, in which case inverse frequency conversion is also skipped. In that case, the predicted residual value can be entropy-decoded and dequantized. For the inter-picture predicted block, the decoder (450) combines the reconstructed predicted residual value with the motion compensated predicted value. The decoder (450) can similarly combine the predicted residual value with the predicted value from the in-picture prediction.

For palette decoding mode, the decoder (450) uses a palette that represents at least a portion of the sample values for the CU or other unit. The palette maps index values to the corresponding colors. During decoding, the index values from the palette are replaced with the appropriate sample values for position within the unit. The escape coded value of the unit can be decoded using the escape code value and the literal value. The palette can be changed for each unit, and the information that specifies the palette can be signaled within the bitstream.

An adaptive deblocking filter is included within the motion compensation loop of the video decoder (450) to smooth out the discontinuities across the rows and / or columns of the block boundaries in the decoded picture (451). Alternatively, or in addition, other filtering (such as deringing filtering, ALF, or SAO filtering, not shown) can be applied as an in-loop filtering operation.

The decoded picture temporary memory storage area (460) includes a plurality of picture buffer storage areas (461, 462, ..., 46n). The decoded picture storage area (460) is an example of a decoded picture buffer. The decoder (450) uses the MMCO / RPS information (432) to identify a picture buffer (461, 462, etc.) that can store the decoded picture (451). The decoder (450) stores the decoded picture (451) in the picture buffer.

The output sequencer (480) identifies when the next picture generated in the output order is available in the decoded picture storage area (460). When the next picture (481) generated in the output order becomes available in the decoded picture storage area (460), it is read by the output sequencer (480) and output to the output destination (490) (eg, display). To. In general, the order in which pictures are output from the decoded picture storage area (460) by the output sequencer (480) may be different from the order in which the pictures are decoded by the decoder (450).

V. Illustrative Video Encoders FIGS. 5a and 5b are block diagrams of a generalized video encoder (500) in which some of the embodiments described may be realized together. The encoder (500) receives a sequence of video pictures, including the current picture, as an input video signal (505) and produces encoded data in a video bitstream (595) encoded as an output.

The encoder (500) is block-based and uses an implementation-dependent block format. The blocks may be further subdivided at different stages, such as prediction, frequency conversion, and / or entropy encoding. For example, a picture can be divided into 64x64 blocks, 32x32 blocks, or 16x16 blocks, which can then be divided into smaller blocks of sample values for coding and decoding. H. In the encoding implementation for the 265 / HEVC standard, the encoder classifies the picture into CTU (CTB), CU (CB), PU (PB), and TU (TB).

The encoder (500) uses intra-picture coding and / or inter-picture coding to compress the picture. Many of the components of the encoder (500) are used for both intra-picture coding and inter-picture coding. The exact behavior performed by those components can vary depending on the type of information to be compressed.

The tiling module (510) optionally divides the picture into multiple tiles of the same size or different sizes. For example, the tiling module (510) divides the picture along tile rows and columns that define the horizontal and vertical boundaries of the tiles in the picture along with the picture boundaries, where each tile is a rectangular area. H. In the 265 / HEVC implementation, the encoder (500) divides the picture into one or more slices, each slice containing one or more slice segments. Rows of a particular block (eg, CTU rows of slices according to the H.265 / HEVC standard) can be encoded in parallel using WPP, as described in more detail below.

The general encoding control (520) receives a picture for the input video signal (505) as well as feedback (not shown) from various modules of the encoder (500). In general, general encoding control (520) transfers control signals (not shown) to other modules (tilted module (510), converter / scaler / quantizer (530), scaler / inverse converter (535), picture Provided to the internal estimator (540), motion estimator (550), intra / interswitch, etc.) to set and change coding parameters between encodings. In particular, the general encoding control (520) can determine whether and how to use palette prediction, intra BC prediction, intra LC prediction, and intra SC prediction during encoding. General encoding control (520) can also evaluate intermediate results between encodings and perform, for example, rate distortion analysis. The general encoding control (520) generates general control data (522) indicating the decisions made during the encoding, so that the corresponding decoder can make consistent decisions. General control data (522) is provided to the header formatter / entropy encoder (590).

If the current picture is predicted using inter-picture prediction, the motion estimator (550) estimates the motion of the block of sample values of the current picture of the input video signal (505) for one or more reference pictures. The decoded picture buffer (570) buffers one or more reconstructed pre-encoded pictures for use as reference pictures. When a plurality of reference pictures are used, the plurality of reference pictures can be from different time directions or the same time direction. The motion estimator (550) generates motion data (552) such as MV data, merge mode index value, and reference picture selection data as side information. The motion data (552) is provided to the header formatter / entropy encoder (590) and the motion compensator (555).

The motion compensator (555) applies the MV to the reconstructed reference picture from the decoded picture buffer (570). The motion compensator (555) currently produces motion compensated predictions for the picture.

In a separate path within the encoder (500), the in-picture estimator (540) determines how to make an in-picture prediction for a block of sample values of the current picture of the input video signal (505). To do. Currently the picture can be encoded in whole or in part using in-picture coding. For intra-spatial prediction, using the value of the current picture reconstruction (538), the intra-picture estimator (540) is from the adjacent pre-reconstructed sample value of the current picture to the current block of the current picture Determine how to spatially predict sample values.

Alternatively, for intra-copy prediction, the in-picture estimator (540) estimates the displacement from the current block, line, or string to position in another pre-reconstructed sample value. A reference block, line, or string of sample values in a picture is used to generate a prediction value for the current block, line, or string. For example, in the case of intra-BC prediction, the in-picture estimator (540) estimates the displacement from the current block to the reference block, which can be indicated using the BV value. As another example, in the case of intra-LC prediction, the in-picture estimator (540) can be indicated using an offset value (indicating the displacement from the current line to the reference line), the present (in the current block). Estimate the displacement from the line to the reference line. As another example, for intra-SC prediction, the in-picture estimator can be shown using an offset value (indicating the displacement from the current string to the reference string) and a string length value (current block). Estimates the displacement from the current string to the reference string. When WPP is enabled, the in-picture estimator (540) is consistent with constraints on the location of the reference region, as described below (eg, for BV values in intra BC prediction, or for intra SC prediction or The displacement (in the case of the offset value in the intra LC prediction) can be determined.

Depending on the implementation, the in-picture estimator (540) uses the input sample value, the reconstructed sample value before in-loop filtering, or the reconstructed sample value after in-loop filtering to block the current block. Offset estimates can be made for lines, lines, or strings. In general, by using the input sample value for the offset estimation or the unfiltered reconstructed sample value, the in-picture estimator (540) will check the reference block, line, before the offset estimation / intracopy prediction. You can avoid bottlenecks in continuous processing (which can result from filtering reconstructed sample values such as strings). On the other hand, additional memory is used to store unfiltered reconstructed sample values. Also, if in-loop filtering is applied before offset estimation, the filtering process applied after the current block / line / string is decoded and the area used for offset estimation / intracopy prediction. There can be overlapping areas of influence between them. In such cases, offset estimation / intracopy prediction will be applied prior to that aspect of the filtering operation. In some implementations, the encoder may apply some in-loop filtering behavior prior to offset estimation / intracopy prediction and perform additional or alternative filtering at a later processing stage.

The in-picture estimator (540) generates intra-prediction data (542) as side information, such as whether the intra-prediction uses spatial prediction, intra-BC prediction, intra-LC prediction, or intra-SC prediction. Information indicating the prediction mode direction (for intraspace prediction), BV value (for intraBC prediction), offset value (for intraLC prediction), or offset value and length value (for intraSC prediction). And so on. The intra prediction data (542) is provided to the header formatter / entropy encoder (590) and the in-picture predictor (545).

According to the intra-prediction data (542), the intra-picture predictor (545) spatially predicts the sample values of the current block of the current picture from the adjacent pre-reconstructed sample values of the current picture. Alternatively, for intracopy prediction, the in-picture predictor (545) is a reference block, line, string, or other section indicated by a displacement (BV value, offset value, etc.) with respect to the current block, line, string, etc. Use the pre-reconstructed sample values in to predict the sample values for the current block, line, string, or other section. In some cases, the BV value (or other offset value) can be a predicted value. In other cases, the BV value (or other offset value) can differ from its predicted value, in which case the difference indicates the difference between the predicted value and the BV value (or other offset value). In the intra-SC mode, the in-picture predictor (545) further uses the string length value when predicting the sample value of the current string.

For palette coding mode, the encoder (500) uses palettes to represent at least some of the sample values for CU or other units. The palette represents the colors used in the unit. For example, the palette maps index values 0, 1, 2, ..., P to the corresponding colors, and the corresponding colors are RGB 4: 4: 4 format, BGR 4: 4: 4 format, GBR 4: 4: 4. It can be a format, YUV 4: 4: 4 format, or another format (color space, color sampling rate). The index value can represent an RGB triplet, a BGR triplet, or a GBR triplet for a pixel, where the pixel is a set of collated sample values. For unit encoding, the index value replaces the sample value of the pixels in the unit. Rare values for units can be encoded using escape code and literal values instead of using palette index values. The palette can be changed for each unit, and the palette data that specifies the palette can be signal-transmitted within the bitstream.

The intra / interswitch selects whether the prediction (558) for a given block is a motion-compensated prediction or an in-picture prediction.

In some exemplary implementations, no residuals are calculated for units encoded in palette coding mode or intracopy mode (intra BC prediction, intra LC prediction, or intra SC prediction). Instead, the residual coding is skipped and the predicted sample value is used as the reconstructed sample value.

If residual coding is not skipped, the difference (if any) between the block of predictions (558) and the corresponding portion of the original current picture of the input video signal (505) will result in residuals (518). ) Values are provided. If the residual value is encoded / signaled during the current picture reconstruction, the reconstructed residual value is combined with the prediction (558) to create the original content from the video signal (505). An approximate or accurate reconstruction (538) is generated (with lossy compression, some information is lost from the video signal (505)).

In the converter / scaler / quantizer (530) as part of the residual coding, if the frequency conversion is not skipped, the frequency converter will convert the spatial domain video information into frequency domain (ie, spectral, conversion) data. Convert to. For block-based video coding, the frequency converter performs a discrete cosine transform (“DCT”), its integer approximation, or another type of forward block transform (eg, a discrete sine transform or its integer approximation). It is applied to a block of difference data (or sample value data when the prediction (558) is null) to generate a block of frequency transform coefficients. The transducer / scaler / quantizer (530) can apply variable block size transforms. In this case, the transducer / scaler / quantizer (530) can determine which block size transform to use for the residual value of the current block. The scaler / quantizer scales the conversion factors and quantizes them. For example, a quantizer performs dead zone scaler quantization in a picture-by-picture, tile-by-tile, slice-by-slice, block-by-block, frequency-specific, or other criteria-variable quantization step. Applies to frequency domain data by size. The quantized conversion coefficient data (532) is provided to the header formatter / entropy encoder (590). If frequency conversion is skipped, the scaler / quantizer scales and quantizes a block of predicted residual data (or sample value data when the prediction (558) is null) and a header formatter / entropy encoder. The quantized value provided in (590) can be generated.

In order to reconstruct the residual values, in the scaler / inverse converter (535), the scaler / inverse quantizer performs inverse scaling and inverse quantization on the quantized conversion coefficients. If the conversion step is not skipped, the inverse frequency converter performs the inverse frequency conversion to produce a reconstructed block of predicted residual values or sample values. If the conversion step is skipped, the inverse frequency conversion is also skipped. In this case, the scaler / inverse quantizer can perform inverse scaling and inverse quantization on a block of predicted residual data (or sample value data) to generate the reconstructed value. If the residual values are encoded / signaled, the encoder (500) will use the reconstructed residual values as the predicted (558) values (eg, motion compensated predicted values, in-picture predicted values). Combine to form a reconstruction (538). If the residual value is not encoded / signaled, the encoder (500) uses the predicted (558) value as the reconstruction (538).

In the case of in-picture prediction, the value of the reconstruction (538) can be fed back to the in-picture estimator (540) and the in-picture predictor (545). The value of reconstruction (538) can be used for motion-compensated prediction of subsequent pictures. The value of reconstruction (538) can be further filtered. The filtering control (560) determines how to perform deblock filtering and SAO filtering on the value of reconstruction (538) for a given picture of the video signal (505). Filtering control (560) produces filter control data (562), which is provided to the header formatter / entropy encoder (590) and merger / filter (565).

In the merger / filter (565), the encoder (500) merges content from different tiles into a reconstructed version of the picture. The encoder (500) selectively performs deblock filtering and SAO filtering according to the filter control data (562) and the rules of filter adaptation to adaptively smooth discontinuities across picture boundaries. Alternatively, or in addition, other filtering (such as deringing filtering or ALF, not shown) can be applied. The tile boundaries can be selectively filtered or not filtered at all, depending on the settings of the encoder (500), which will place the syntax elements in the encoded bitstream. It may be provided to indicate whether such filtering has been applied. The decoded picture buffer (570) buffers the reconstructed current picture for use in subsequent motion-compensated predictions.

The header formatter / entropy encoder (590) collects general control data (522), quantized conversion coefficient data (532), intra prediction data (542), motion data (552), and filter control data (562). Format and / or entropy encode. For motion data (552), the header formatter / entropy encoder (590) can select the merge mode index value and entropy encode it, or the default MV predictor can be used. In some cases, the header formatter / entropy encoder (590) also determines the MV difference of the MV value (relative to the MV predictor of the MV value) and then uses, for example, context-adaptive binary arithmetic coding to determine the MV difference. Is entropy-coded. For intra-prediction data (542), the prediction can be used to encode the BV value (or other offset value). The prediction can use a default predictor (eg, a BV value from one or more adjacent blocks or another offset value). If more than one predictor is possible, the predictor index can indicate which of the multiple predictors is used to predict the BV value (or other offset value). The header formatter / entropy encoder (590) can select a predictor index value (for intracopy prediction) and entropy encode it, or a default predictor can be used. In some cases, the header formatter / entropy encoder (590) also determines the difference (relative to the predictor of the BV value or other offset value) and then uses, for example, context-adaptive binary arithmetic coding to determine the difference. Entropy encode. In the palette encoding mode, the header formatter / entropy encoder (590) can encode the palette data. In particular, the header formatter / entropy encoder (590) can use palette prediction as described below.

The header formatter / entropy encoder (590) provides encoded data in the encoded video bitstream (595). The format of the encoded video bitstream (595) is H.I. 265 / HEVC format, Windows® media video format, VC-1 format, MPEG-x format (eg MPEG-1, MPEG-2, or MPEG-4), H.D. It can be a 26x format (eg, H.261, H.262, H.263, H.264), or a variant or extension of another format.

Depending on the implementation and the type of compression desired, encoder (500) modules can be added, omitted, split into multiple modules, combined with other modules and / or replaced with similar modules. .. In an alternative embodiment, encoders with different modules and / or other configurations of modules implement one or more of the techniques described. Specific embodiments of the encoder typically use a modified or supplemented version of the encoder (500). The illustrated relationships between the modules within the encoder (500) show the general flow of information within the encoder, other relationships are not shown for brevity.

VI. An exemplary video decoder FIG. 6 is a block diagram of a generalized decoder (600) in which some of the embodiments described may be realized together. The decoder (600) receives the encoded data in the encoded video bitstream (605) and produces an output containing a picture of the reconstructed video (695). The format of the encoded video bitstream (605) is H.I. 265 / HEVC format, Windows® media video format, VC-1 format, MPEG-x format (eg MPEG-1, MPEG-2, or MPEG-4), H.D. It can be a 26x format (eg, H.261, H.262, H.263, H.264), or a variant or extension of another format.

Pictures can be organized as multiple tiles of the same size or different sizes. Pictures can also be organized as one or more slices. The content of slices or tiles can be further organized as blocks of sample values or other sets. The decoder (600) is block-based and uses an implementation-dependent block format. The blocks may be further subdivided at different stages. For example, the picture can be divided into 64x64 blocks, 32x32 blocks, or 16x16 blocks, which in turn can be divided into blocks with smaller sample values. H. In the implementation of decoding for the 265 / HEVC standard, pictures are divided into CTU (CTB), CU (CB), PU (PB), and TU (TB). If the picture is encoded with WPP enabled (using WPP or in a manner consistent with using WPP during decoding), then a specific block of lines (eg, for example, as described below). Lines of CTU according to H.265 / HEVC standard) can be decoded in parallel using WPP.

The decoder (600) stretches the picture using in-picture decoding and / or inter-picture decoding. Many of the components of the decoder (600) are used for both in-picture decoding and inter-picture decoding. The exact behavior performed by those components can vary depending on the type of information being stretched.

The buffer receives the encoded data in the encoded video bitstream (605) and makes the received encoded data available to the parser / entropy decoder (610). The parser / entropy decoder (610) entropy-decodes the entropy-encoded data and typically applies the reverse of the entropy encoding performed by the encoder (500) (eg, context-adaptive binary arithmetic decoding). .. As a result of parsing and entropy decoding, the parser / entropy decoder (610) has general control data (622), quantized conversion coefficient data (632), intra prediction data (642), motion data (652), And filter control data (662) is generated. In the intra-prediction data (642), if the predictor index value is signaled, the parser / entropy decoder (610) may entropy decode the predictor index value, for example using context-adaptive binary arithmetic decoding. it can. In some cases, the parser / entropy decoder (610) also entropy-decodes the differences to BV values or other offset values (eg, using context-adaptive binary arithmetic decoding), and then the differences are the corresponding predictors. In combination with, the BV value (or other offset value) is reconstructed. In other cases, the difference is omitted from the bitstream and the BV value (or other offset value) is simply a predictor (eg, indicated using a predictor index value). In the palette decoding mode, the parser / entropy decoder (610) can decode the palette data. In particular, the parser / entropy decoder (610) can use palette prediction as described below.

The general decoding control (620) receives the general control data (622) and transmits the control signal (not shown) to other modules (scaler / inverse converter (635), in-picture predictor (645), motion compensator). (655), and intra / interswitch, etc.) to set and change decoding parameters during decoding.

If the current picture is predicted using inter-picture prediction, the motion compensator (655) receives motion data (652) such as MV data, reference picture selection data, and merge mode index value. The motion compensator (655) applies the MV to the reconstructed reference picture from the decoded picture buffer (670). The motion compensator (655) currently produces motion compensated predictions for the intercoded blocks of the picture. The decoded picture buffer (670) stores one or more pre-reconstructed pictures to be used as reference pictures.

In a separate path within the decoder (600), the intra-picture predictor (645) receives intra-prediction data (642), which, for example, intra-picture prediction is spatial prediction, intra BC prediction, intra LC prediction, Or whether to use intra SC prediction, as well as the prediction mode direction (for intra space prediction), BV value (for intra BC prediction), offset value (for intra LC prediction), or offset and length values (for intra LC prediction). Information indicating (in the case of intra-SC prediction). For intra-spatial prediction, using the current picture reconstruction (638) value, according to the prediction mode data, the in-picture predictor (645) is now from the adjacent pre-reconstructed sample value of the current picture. Spatially predict the sample value of the current block of the picture. Alternatively, for intra-copy prediction, the in-picture predictor (645) is a reference block, line, string, or other section indicated by the displacement (BV value, offset value, etc.) of the current block, line, string, etc. Use the pre-reconstructed sample values in to predict the sample values for the current block, line, string, or other section. In some cases, the BV value (or other offset value) can be a predicted value. In other cases, the BV value (or other offset value) can differ from its predicted value, in which case the BV value (or other offset value) is reconstructed using the difference and the predicted value. .. In the intra-SC mode, the in-picture predictor (645) further uses the string length value when predicting the sample value of the current string.

For palette decoding mode, the decoder (600) uses a palette that represents at least a portion of the sample values for the CU or other unit. The palette maps index values to the corresponding colors used in the unit. For example, the palette maps index values 0, 1, 2, ..., P to the corresponding colors, and the corresponding colors are RGB 4: 4: 4 format, BGR 4: 4: 4 format, GBR 4: 4: 4. It can be a format, YUV 4: 4: 4 format, or another format (color space, color sampling rate). The index value can represent an RGB triplet, a BGR triplet, or a GBR triplet for a pixel. During decoding, the index value from the palette is replaced with the appropriate sampling value for position within the unit. The escape coded value of the unit can be decoded using the escape code value and the literal value. The palette can be changed unit by unit based on the palette data signaled within the bitstream.

The intra / interswitch selects a motion-compensated or in-picture prediction value to be used as the prediction (658) for a given block. For example, H. When following 265 / HEVC syntax, the intra / interswitch can be controlled based on the syntax elements encoded for the CU of the picture which can contain the intra-predicted CU and the inter-predicted CU. .. If the residual values are encoded / signaled, the decoder (600) combines the prediction (658) with the reconstructed residual values to generate a reconstructed content (638) from the video signal. .. If the residual value is not encoded / signaled, the decoder (600) uses the predicted (658) value as the reconstruction (638).

To reconstruct the residuals when the residual values are encoded / signaled, the scaler / inverse transducer (635) receives and processes the quantized conversion factor data (632). In the scaler / inverse transducer (635), the scaler / inverse quantizer performs descaling and dequantization on the quantized transform coefficients. The inverse frequency converter performs inverse frequency conversion to generate a reconstructed block of predicted residual values or sample values. For example, an inverse frequency converter applies an inverse block transformation to a frequency conversion factor to generate sample value data or predicted residual data. The inverse frequency transform can be the inverse DCT, its integer approximation, or another type of inverse frequency transform (eg, the inverse discrete sine transform or its integer approximation). If the frequency conversion is skipped during the encoding, the inverse frequency conversion is also skipped. In this case, the scaler / inverse quantizer can perform inverse scaling and inverse quantization on a block of predicted residual data (or sample value data) to generate the reconstructed value.

In the case of in-picture prediction, the value of reconstruction (638) can be fed back to the in-picture predictor (645). In the case of inter-picture prediction, the value of reconstruction (638) can be further filtered. In the merger / filter (665), the decoder (600) merges content from different tiles into a reconstructed version of the picture. The decoder (600) selectively performs deblock filtering and SAO filtering according to the filter control data (662) and the rules of filter adaptation to adaptively smooth discontinuities across picture boundaries. Alternatively, or in addition, other filtering (such as deringing filtering or ALF, not shown) can be applied. The tile boundaries can be selectively filtered or not filtered at all, depending on the settings of the decoder (600) or the syntax elements in the encoded bitstream data. The decoded picture buffer (670) buffers the reconstructed current picture for use in subsequent motion-compensated predictions.

The decoder (600) can further include a post-processing filter. The post-processing filter (608) can include deblocking filtering, deringing filtering, adaptive winner filtering, film particle reproduction filtering, SAO filtering, or another type of filtering. "In-loop" filtering is performed on the reconstructed sample values of the pictures in the motion compensation loop, thus affecting the sample values of the reference picture, but the post-processing filter (608) outputs for display. Before doing so, it is applied to the reconstructed sample values outside the motion compensation loop.

Depending on the implementation and the type of decompression desired, modules of the decoder (600) may be added, omitted, split into multiple modules, combined with other modules and / or replaced with similar modules. it can. In an alternative embodiment, a decoder with a different module and / or other configuration of the module implements one or more of the techniques described. Specific embodiments of the decoder generally use a modified or supplemented version of the decoder (600). The illustrated relationships between the modules within the decoder (600) show the general flow of information within the decoder, other relationships are not shown for brevity.

VII. Rules for In-Picture Prediction Modes When WPP Is Enabled This section presents examples of rules for in-picture prediction modes when wave plane parallelism (“WPP”) is enabled. The innovation includes palette prediction mode, intra-block copy (“BC”) mode, intra-line copy (“LC”) mode, and intra-string copy (“SC”) mode by encoder or decoder when WPP is enabled. ”) Facilitates the use of in-picture prediction modes such as mode.

A. Wave Surface Parallel Processing-Introduction In general, WPP is a coding / decoding tool that facilitates parallel processing by differentially delaying the start of processing for a row of units in a picture. Once WPP is enabled, different rows of units in a picture can be encoded or decoded in parallel. During encoding or decoding, the first line of units can be processed unit-after-unit from left to right. The processing (encoding or decoding) of the second line of the unit does not have to wait for the processing of the entire first line of the unit to complete. Instead, after some of the units in the first row have completed processing, this provides the information used when processing the first unit in the second row, and the second row of units. Processing can start. Similarly, processing in the third row of units can begin after processing is complete for some of the units in the second row. Thus, WPP facilitates parallel processing of different rows of units, allowing different threads or processing cores to process different rows of units in an alternating time delay manner.

For example, H. According to the 265 / HEVC standard, when WPP is enabled, slices are divided into rows of CTU. While encoding or decoding, the first line of the CTU can be processed on a CTU-by-CTU-by-CTU basis. After processing is complete for the first two CTUs in the first row, this is the information used when processing the first CTU in the second row (eg, reconstructed sample values, reconstructed). The MV value or BV value, the context model information) is provided, and the processing of the second line of the CTU can be started. Similarly, the processing of the third row of CTUs can be started after the processing of the first two CTUs of the second row is completed.

FIG. 7 shows H. It shows the timing (700) of WPP with respect to the current picture (710) according to the 265 / HEVC standard. The picture (710) is divided into CTUs organized in CTU columns and CTU rows. Different CTU lines can be encoded or decoded in parallel using WPP. The timing of WPP reflects the dependencies between CTUs during encoding or decoding. In this example, a given CTU is (1) an adjacent CTU to its left, (2) an adjacent CTU to its upper left, (3) an adjacent CTU above the given CTU, and (4) given. It may depend on information from the adjacent CTU in the upper right corner of the CTU (reconstructed sample value, reconstructed MV or BV value, context model information, etc.), in which case such adjacent CTU (1). )-(4) are available (eg, in the picture, in the same slice and tile). Each adjacent CTU may then depend on CTUs (1)-(4) adjacent to it, if available. FIG. 8 shows the cascade dependency of the fifth CTU row for the first CTU. The first CTU in the fifth CTU row depends on the first two CTUs in the fourth CTU row, and they collectively depend on the first three CTUs in the third CTU row, and so on. Is.

Referring to FIG. 7, in the case of WPP, the first CTU row (that is, CTU row 0) is processed for each CTU for wave 0. In the case of wave 1, the processing of the first CTU in CTU row 1 can be started after the encoding / decoding of the second CTU in CTU row 0 is finished. Similarly, in the case of wave 2, the processing of the first CTU in CTU row 2 can be started after the encoding / decoding of the second CTU in CTU row 1 is finished. In the case of wave 3, the processing of the first CTU in CTU row 3 can be started after the encoding / decoding of the second CTU in CTU row 2 is finished, and in the case of wave 4, the first CTU in CTU row 4 The processing of the CTU can be started after the encoding / decoding of the second CTU in CTU line 3 is completed.

Even when the CTU rows are processed in parallel, this alternate time delay processing ensures that the dependencies between the CTUs are satisfied when processing begins for the CTU rows. In FIG. 7, two CTU advances are maintained for each CTU row during processing. For each CTU row, the processing of the current CTU (indicated by the thick outline) is two CTUs faster than the processing of the current CTU of the next CTU row. However, in practice, the processing of a given CTU row slows down or slows down and is cascaded in the processing of the CTU row after it depends (directly or indirectly) on the completion of the processing of the CTU in the given CTU row. Delays may occur. For a given CTU in a later CTU row, the dependencies cascade from the previous CTU row. In the example (800) shown in FIG. 8, the first two CTUs in the fourth CTU row are processed with respect to the first CTU in the fifth CTU row of the frame (810). Otherwise, the processing of the first CTU in the fifth CTU row cannot be started. In turn, the third CTU in the third CTU row is being processed because otherwise the processing of the second CTU in the fourth CTU row could not be initiated. Similarly, the fourth CTU of the second CTU row is processed as a precondition for processing the third CTU of the third CTU row. Finally, the fifth CTU of the first CTU row is processed as a precondition for processing the fourth CTU of the second CTU row. Thus, FIG. 8 shows the reconstructed content guaranteed to be available for prediction of the first CTU in wave 4 (fifth CTU row) when WPP is enabled. ..

In contrast, if WPP is not enabled, the CTU will be on the CTU row after CTU row picture (or slices and tiles, if used) from left to right within the CTU row. Processed from to bottom. The context model information (also called CABAC status information or entropy coding information) used for a given CTU is the earlier CTU in the coding / decoding order, the same CTU in the picture (or slice / tile). The results of processing any previous CTU and any previous CTU row in a row may be accounted for. For example, the processing of the second CTU in a CTU row depends on the result of the processing of the first CTU in the CTU row, and so on. As another example, the processing of the first CTU in one CTU row depends on the result of processing the last CTU in the previous CTU row in the picture (or slice / tile).

On the other hand, when WPP is enabled, the processing of the first CTU in the CTU row does not depend on the result of processing the last CTU in the previous CTU row in the picture (or slice / tile). The processing of the first CTU in the CTU row is for the second CTU in the previous CTU row in the picture (or slice / tile), even if the context model information from the last CTU in the previous CTU row is not available. It can be started after the process is finished. The processing of the third CTU in the previous CTU row still depends on the processing result of the second CTU in that CTU row, as when WPP is not available.

When WPP is enabled, the encoder may or may not actually use WPP during encoding. In any case, the encoder enforces constraints and prediction rules that apply when WPP is actually used. Similarly, when WPP is enabled, the decoder may or may not actually use WPP during decoding. A syntax element in the bitstream can indicate whether WPP is enabled for a video sequence, a set of pictures, or a picture. For example, syntax elements can be signaled in the form of SPS, PPS, or other syntax structures within a bitstream. H. In the implementation of 265 / HEVC, for example, the value of the syntax element signaled in the PPS syntax structure entropy_coding_sync_enable_flag indicates whether WPP is enabled for the picture associated with the PPS syntax structure. .. WPP is available for the picture if entropy_coding_sync_enable_flag is equal to 1. Otherwise, WPP is not enabled for the picture.

B. Palette Coding / Decoding Modes and Palette Predictions-Introduction In general, palette coding / decoding modes use palettes to sample units (eg, CUs in H.265 / HEVC implementations, or other units). Represents at least some of the values. For example, the palette maps index values 0, 1, 2, ..., P to the corresponding colors, and the corresponding colors are RGB 4: 4: 4 format, BGR 4: 4: 4 format, GBR 4: 4: 4. It can be a format, YUV 4: 4: 4 format, or another format (color space, color sampling rate). The index value can represent an RGB triplet, a BGR triplet, or a GBR triplet for a pixel. FIG. 9 shows two examples of pallets. The palette for the current unit (ie, the "current palette") contains p index values 0, ..., P-1 associated with the RGB triplet. The palette for the previous unit (represented by "previous palette data") contains q index values 0, ..., Q-1 associated with the RGB triplet. The values of p and q can be the same or different. During encoding, the encoder can use the index value to replace the sample value of the pixel, and the index value may be further encoded, for example using entropy coding. During decoding, the decoder can use a palette to restore pixel sample values from index values, for example, after entropy decoding of index values.

In particular, palette coding / decoding modes can be useful when the unit contains a relatively small number of distinguishable colors, which is a common characteristic of screen content video. For example, a 64x64CU in the RGB4: 4: 4 format may contain 64x64 = 4096 pixels, but may contain much fewer colors (eg, 1-20 colors). Rare colors within a unit can be encoded using escape code values and literal values (for each sample value) instead of including the rare colors directly in the palette.

Two units can use the same palette, but the colors typically change from unit to unit in the picture. As such, the palette typically changes from unit to unit in the picture. With respect to the palette, the encoder signals the palette data, which may be entropy-encoded, in a bitstream. The decoder receives the palette data, parses it, entropy decodes it if necessary, and reconstructs the palette. Encoders and decoders can use palette prediction to reduce the bit rate associated with signaling palette data.

In general, palette prediction is an arbitrary approach used during encoding or decoding, using palette data from one or more palettes of the previous unit (previous palette data) of the current unit. The value of the palette (current palette) can be predicted. Colors typically vary from unit to unit in the picture, but often at least some of the colors in a given unit are further used in adjacent units. Palette prediction takes advantage of that observation to reduce the bit rate for palette data.

FIG. 9 shows a simplified example (900) of palette prediction, where the current unit's palette (current palette) uses the previous unit's palette (represented in the form of previous palette data). Is predicted. For example, the previous palette data can be from the palette used by the previous unit that was encoded or decoded before the current unit if the previous unit used palette coding / decoding mode. If the previous unit did not use palette encoding / decoding mode, the previous palette data for the current unit can be "inherited" from the previous unit. That is, the previous palette data that was available for the previous unit can be reused as the previous palette data that was available for the current unit. (In some exemplary implementations, the previous palette data is effectively the status or state information of the current unit. Given units that do not use the palette coding / decoding mode themselves are the previous. It still has palette data, which may be inherited by the next unit.) Therefore, through the chain of inheritance, the previous palette data for the current unit is the most using palette coding / decoding mode. It can contain palette data from the palette of the most recent preprocessed unit (if any).

With respect to palette prediction, the encoder can determine if the current palette is the same as the previous palette data. If they are the same, the encoder can simply indicate that the previous palette data should be reused as the current palette. If not (the current palette is different from the previous palette data), the encoder determines the change between the previous palette data and the current palette and signals a syntax element that indicates the change. For example, as shown in FIG. 9, with respect to a given index value in the current palette, the encoder has the corresponding color of the given index value be the color of the previous palette data (“prev”) or is new. Signals whether it is a color (“new”). If the corresponding color is the color of the previous palette data, the encoder can be used to populate the current palette, the index value (from the previous palette data) for the color of the previous palette data. Is signaled. In FIG. 9, the color for the index value 1 of the previous palette data is reassigned to the index value 0 of the current palette, and the color for the index value 0 of the previous palette data is reassigned to the index value 2 of the current palette. Has been done. Thus, colors can be repositioned from palette to palette, so that, for example, the most common colors may have the lowest index value, which may improve the efficiency of entropy encoding. If the corresponding color of a given index value is a new color, the encoder signals a triplet for the new color. In FIG. 9, for example, for an index value of 1 on the current palette, the encoder signals a new triplet (215, 170, 200), which is used to update the current palette.

Based on the syntax elements signaled by the encoder, the decoder can determine if the current palette is the same as the previous palette data available in the decoder. If they are the same, the decoder can reuse the previous palette data as the current palette. If not (the current palette is different from the previous palette data), the decoder receives a syntax element that indicates the change between the previous palette data and the current palette and parses it. For example, as shown in FIG. 9, with respect to a given index value in the current palette, the decoder either has a corresponding color in the given index value that is the color of the previous palette data (“prev”) or is new. Determine if it is a color ("new"). If the corresponding color is the color of the previous palette data, the decoder can be used to fill the current palette with a thin indicating the index value (from the previous palette data) for the color of the previous palette data. Receives tax elements and parses them. If the corresponding color of a given index value is a new color, the decoder receives a syntax element indicating the new color and parses it.

After configuring the current palette, the encoder and decoder update the previous palette data for the next unit and store the palette data from the current palette. This new "previous palette data" can be used to predict the palette for the next unit.

FIG. 9 shows a simplified example (900). In practice, the syntax elements and rules used to signal palette data can be more complex. See, for example, Sections 7.3.8.8, 7.4.9.6, and 8.4.1 of JCTVC-R1005 for further details on palette coding / decoding and palette prediction in the exemplary implementation. Alternatively, another approach is used to signal the palette data.

C. Pallet Prediction When WPP Is Enabled Generally, the previous pallet data for pallet prediction is used to predict the pallet (current pallet) of the current unit. For example, the previous palette data is the actual palette data from the adjacent unit encoded or decoded before the current unit (if the adjacent unit used palette encoding / decoding mode). Alternatively (if the adjacent unit did not use the palette coding / decoding mode), the previous palette data available to the adjacent unit is reused as the previous palette data for the current unit (or ". It can be inherited ").

In some exemplary implementations, if WPP is not enabled, for the first unit in the current row, the previous palette data will be from the last unit in the previous row (eg, the last unit is the palette). If you used the encoding / decoding mode, it is from the palette of the last unit, otherwise from the previous palette data available to the last unit). When WPP is enabled, the previous palette data from the last unit in the previous row may not be available for the first unit in the current row. However, resetting the palette prediction at the beginning of each row of units (there is no predictor for the palette prediction of the first unit in the current unit) can have a negative effect on coding efficiency.

Instead, when WPP is enabled, the encoder or decoder is one of the first two units in the previous line that has already been processed to begin processing the first unit in the current line. Previous palette data from (eg, one of the first two CUs in the first two CTUs of the previous row) can be used. For example, for the first unit in the current row, the previous palette data for palette prediction is from the second unit in the previous row (the second unit has palette coding / decoding mode). If used, the actual pallet data of the second unit, or otherwise the previous pallet data available for the second unit in the previous row). Therefore, for the first unit in the current row, if the second unit did not use the palette coding / decoding mode, the previous palette data could potentially be from the first unit in the previous row. Palette data (if the first unit used palette coding / decoding mode) or (if neither of the first two units in the previous line used palette coding / decoding mode) ) It is the previous palette data from the first unit in the previous row, and the palette data may depend on the palette for the second unit in the previous row in the previous row, and so on. (Alternatively, if neither of the first two units in the previous row used palette coding / decoding mode, the previous palette data is null (no predictor) or uses the default predictor. After the first unit in the current line, for the current unit, the previous pallet data for pallet prediction is before the current unit, as if WPP was not enabled. Palette data from an adjacent unit encoded or decoded into (if the adjacent unit used palette encoding / decoding mode) or (if the adjacent unit did not use palette encoding / decoding mode) Previous palette data available for adjacent units.

FIG. 10 shows the palette prediction dependency (1000) for the current picture (1010) processed with WPP enabled, according to some exemplary examples. The picture (1010) is organized by CTU rows and CTU columns. In the example of FIG. 10, each CTU contains a single CU. More generally, a given CTU can be recursively divided into multiple CUs (eg, a single CU can be divided into 4 CUs, each of which is smaller. It may be further divided into CUs). The state of processing (eg, the current CTU is encoded or decoded) generally corresponds to the state of processing shown in FIG. The arrows in FIG. 10 indicate the direction of pallet prediction when WPP is enabled. There are no predictors for the first CU in the first CTU row. Alternatively, you can use the default predictor. For each later CU in the first CTU row, the previous palette data is from the left CU. For the first CU in any CTU row after the first CTU row, the previous palette data is from the second CU in the previous row. For each later CU in any CTU row after the first CTU row, the previous palette data is from the previous CU in the same row. For any CU that uses the palette coding / decoding mode, that palette is used to construct the previous palette data for predicting the palette for the next CU. If a given CU does not use the palette coding / decoding mode, the previous palette data available for the given CU is retained as the previous palette data for the next CU.

When the CTU contains multiple CUs, the previous CU can be the earlier CU in the z-scan sequence for the purpose of palette prediction for the current CU. The earlier CUs can be in the same CTU or different CTUs (relative to the first CU of the CTU). Section VII. D illustrates examples of z-scan sequences in some exemplary implementations with reference to FIG.

Encoders and decoders can use memory to store palette data before it is used for palette prediction. The amount of palette data saved for the previous palette data is implementation dependent. In general, the previous palette data includes the color count C in the previous palette data and the details of the sample values for the colors (eg, RGB 4: 4: 4 format, GBR 4: 4: 4 format, BGR 4: 4: 4 format, YUV4). : 4: 4 format, or a color triplet in another format) and can be included. Encoders and decoders can store all palette data for the previous palette. However, storing all palette data for the previous palette can consume a significant amount of memory for larger palettes. Alternatively, in some cases, the encoder and decoder limit C by a threshold count to reduce memory consumption, where the threshold count is implementation dependent. In this case, the encoder and decoder store the previous palette data for the first C different colors in the previous palette, where C is limited by the threshold count. For example, the threshold count is 16 or 32. Alternatively, when WPP is enabled, for palette predictions for the first unit in the current row, encoders and decoders store previous palette data for up to the first C ₁ different color. The encoder and decoder then store the previous palette data for up to the first C ₂ different colors for the palette prediction in the current row. For example, C ₁ is 16 or 32 and C ₂ is 64.

FIG. 11 shows a generalized technique (1100) for encoding, including palette prediction, when WPP is enabled. Encoders, such as the encoders shown in FIGS. 3 or 5a and 5b, or other encoders can carry out the technique (1100). FIG. 12 shows a generalized technique (1200) for decoding, including palette prediction, when WPP is enabled. A decoder such as the decoder shown in FIG. 4 or FIG. 6, or another decoder, can carry out the technique (1200).

Referring to FIG. 11, the encoder encodes the picture with WPP enabled (1110). Encoding (1110) produces encoded data. As part of the encoding (1110), for palette encoding mode, the encoder uses the previous palette data from the previous unit in the previous WPP line of the picture to the first unit in the current WPP line of the picture. Predict the palette. The encoder outputs the encoded data as part of a bitstream (1120).

Referring to FIG. 12, the decoder receives the encoded data as part of a bitstream (1210). The decoder decodes the encoded data with WPP enabled (1220). Decoding (1220) reconstructs the picture. As part of decoding (1220), for palette decoding mode, the decoder uses the previous palette data from the previous unit in the previous WPP row of the picture to use the first unit in the current WPP row of the picture. Predict the palette for.

In some exemplary implementations, in an encoder or decoder, the current WPP line and the previous WPP line are the CTU lines, and the first unit and the previous unit are the CUs. Alternatively, the WPP row is a row of another type of unit, and / or the first unit and the previous unit are another type of unit. A syntax element in the bitstream can indicate whether WPP is enabled for a video sequence, set of pictures, or pictures. The syntax element can be signaled in the SPS syntax structure, the PPS syntax structure (eg, the syntax element entropy_coding_sync_enable_flag in the implementation of H.265 / HEVC), or other syntax structures in the bitstream.

In general, during encoding or decoding, the palette of the first unit in the current WPP line represents at least some of the colors used in the first unit in the current WPP line. The previous palette data from the previous unit in the previous WPP line may represent at least some of the colors used in the palette of the previous unit in the previous WPP line (the previous unit is palette coded / de). When using coding mode). Alternatively (if the previous unit did not use palette encoding / decoding mode), the previous palette data from the previous unit in the previous WPP line may be inherited by the previous unit from the earlier unit. Well, faster units may be using palette coding / decoding mode or may themselves inherit from previous palette data. Colors that are not represented in the palette can be escape coded. The previous WPP line can be the WPP line just above the current WPP line. The previous unit in the previous WPP row can be above the first unit in the current WPP row (eg, the first unit in the previous row in FIG. 10), or the first in the current WPP row. Can be in the upper right corner of the unit (eg, in FIG. 10, the second unit in the previous row). After processing the first unit in the current WPP row, for the palette of subsequent units in the current WPP row of the picture, the encoder or decoder will use the palette data from the palette of the first unit in the current WPP row. The palette (of subsequent units) can be predicted.

During encoding or decoding, palette prediction can include several steps. For example, during encoding, the encoder (based on a comparison of the current palette with the previous palette data) will palette the previous palette data from the previous unit in the previous WPP row to the first unit in the current WPP row. It is possible to decide whether or not to reuse it as (current palette). During decoding, the decoder (based on the information signaled by the encoder) palettes the previous palette data from the previous unit in the previous WPP row to the first unit in the current WPP row (current palette). It is possible to decide whether or not to reuse it. As another example, when there is a change to the palette during encoding, the encoder selects one or more colors from the previous palette data from the previous unit in the previous WPP line and is the first in the current WPP line. Can be included in the palette for the unit (current palette). The encoder signals a syntax element that represents the selected color. During decoding, the decoder can then receive the syntax element and parse it, and based on the syntax element, one or more from the previous palette data from the previous unit in the previous WPP line. Colors can be selected to be included in the palette (current palette) for the first unit in the current WPP line. Alternatively, encoders and decoders can signal palette data using alternative approaches.

Encoders and decoders can store all previous palette data from previous units in the previous WPP line. For example, encoders and decoders can store one or more color component values for each of the C colors in the previous palette data from the previous unit in the previous WPP line. Alternatively, to reduce memory consumption in some cases, encoders and decoders can limit C by a threshold count on the previous palette data, and thus for the first C colors limited by the threshold count. Palette data is stored for palette prediction.

D. Intracopy Prediction-Introduction In general, intracopy mode is a pre-reconstructed sample value in a reference block, line, string, or other section of a picture that has the same current block, line, string, or other section of the picture. Use intracopy prediction, which is predicted using. For example, the intracopy mode can use intrablock copy (“BC”) prediction, intraline copy (“LC”) prediction, or intrastring copy (“SC”) prediction.

Intra BC mode generally uses intra BC prediction, where the sample values of the current block of the picture are predicted using the sample values of the same picture. The block vector (“BV”) value indicates the displacement from the current block to the block (“reference block”) of the picture showing the sample value used for the prediction. The reference block provides a predicted value for the current block. The sample values used for prediction are pre-reconstructed sample values, so they are available in the encoder during encoding and in the decoder during decoding. The BV value is signaled in the bitstream and the decoder can use the BV value to determine the reference block of the picture to use for prediction.

FIG. 13 shows an example (1300) of an intra-BC prediction for the current block (1330) of the current picture (1310). The current blocks are the coding block (“CB”) of the coding unit (“CU”), the prediction block (“PB”) of the prediction unit (“PU”), and the conversion block (“TU”) of the conversion unit (“TU”). It can be "TB"), or another block. The size of the current block can be 64x64, 32x32, 16x16, 8x8, or some other size. The blocks can be symmetrically or asymmetrically divided into smaller blocks for the purpose of intra-BC prediction. More generally, the size of the current block is m × n, m and n are integers, respectively, and m and n can be equal to each other or have different values. Therefore, the current block can be square or rectangular. Alternatively, the current block can have some other shape.

The BV (1340) indicates the displacement (or offset) from the current block (1330) to the reference block (1350) of the picture containing the sample values used for prediction. The reference block (1350) can be the same as the current block (1330) or can be an approximation of the current block (1330). Assume that the upper left position of the current block is at the current picture position (x ₀ , y ₀ ) and that the upper left position of the reference block is at the current picture position (x ₁ , y ₁ ). BV indicates the displacement (x ₁ − x ₀ , y _{1 −} y ₀ ). For example, if the upper left position of the current block is at position (256,128) and the upper left position of the reference block is at position (126,104), the BV value is (-130, -24). In this example, a negative horizontal displacement indicates the position to the left of the current block and a negative vertical displacement indicates the position above the current block.

Intra BC prediction can improve the coding efficiency by utilizing the redundancy (such as the repetition pattern inside the picture) by using the BC operation. However, finding a matching reference block for the current block can be computationally complex and time consuming, given the number of candidate reference blocks that the encoder can evaluate. FIG. 14 shows an example (1400) exemplifying some of the candidate reference blocks for the current block (1430) of the current picture (1410) when WPP is not enabled. The four BVs (1441, 1442, 1443, 1444) indicate the displacements for the four candidate reference blocks. If WPP is not enabled, the candidate reference block can be anywhere in the reconstructed content of the current picture (1410). (Blocks are generally encoded from left to right, then from top to bottom.) Candidate reference blocks are other candidate reference blocks, as shown for candidate reference blocks indicated by BVs (1443, 1444). May overlap with. In some exemplary implementations, the reference block is constrained to be in the same slice and tile as the current block. Such intra-BC predictions do not use sample values in other slices or tiles. The location of the reference block may be subject to one or more other constraints, such as when WPP is enabled, as described below.

The block having the prediction mode of intra-BC prediction can be a CB, PB, or other block. When the block is a CB, the BV of the block can be signaled at the CU level (and other CBs in the CU use the same BV or its scaled version). Alternatively, when the block is PB, the block's BV can be signaled at the PU level (and other PBs without PU use the same BV or its scaled version). More generally, the BV of an intra-BC prediction block is signaled to the block at an appropriate syntax level.

Intra LC mode generally uses intra LC prediction, where the sample values of the current line of the current block of the picture are predicted using the sample values in the same picture. The offset value indicates the displacement from the current line to the line of the picture (“reference line”) that contains the sample values used for prediction. The offset value is signaled in the bitstream and the decoder can use the offset value to determine the reference line to use for the prediction.

FIG. 15 shows an example (1500) of an intra-LC prediction for the line of the current block (1530) of the current picture. The current block can be CB of CU, PB of PU, TB of TU, or other block. The size of the current block can be 64x64, 32x32, 16x16, 8x8, or some other size. More generally, the size of the current block is m × n, m and n are integers, respectively, and m and n can be equal to each other or have different values. Therefore, the current block can be square or rectangular. For intra LC prediction, the block is divided into horizontal or vertical lines. The horizontal line has the height of one sample and has the width of the current block. The vertical line has the width of one sample and has the height of the current block.

In FIG. 15, the first offset (1551) is from the first line (1541) of the current block (1530) to the reference line (1561) containing the sample values used to predict the first line (1541). ) Indicates the displacement. The reference line can be the same as a given line, or it can be an approximation of a given line. The second offset (1552) is the displacement of the current block (1530) from the second line (1542) to the reference line (1562) containing the sample values used to predict the second line (1542). Is shown. The offset values (1551, 1552) are similar to the BV values in that they now indicate the displacement in the picture. Although FIG. 15 shows a horizontal line, the current block (1530) can instead be split into vertical lines for intra-LC prediction. A block-by-block, unit-by-unit, or picture-by-picture syntax element can indicate whether horizontal or vertical lines are used for intra-LC prediction.

Intra LC prediction can improve coding efficiency by utilizing redundancy (such as a repeating pattern inside a picture) using LC operation. If WPP is not enabled, the candidate reference line can be anywhere in the reconstructed content of the current picture. The candidate reference line may overlap with other candidate reference lines. In some exemplary implementations, the reference line is constrained to be in the same slice and tile as the current line. The location of the reference line may be subject to one or more other constraints, such as when WPP is enabled, as described below.

Intra SC mode generally uses intra SC prediction, where the sample values of the current string in the current block of the picture are predicted using the sample values in the same picture. The offset value indicates the displacement from the current string to the string (“reference string”) of the picture that contains the sample values used for prediction. The string length value indicates the length of the string in terms of the sample value. The offset and string length values are signaled in the bitstream, and the decoder can use the offset and string length values to determine the reference string to use for prediction.

FIG. 16 shows an example (1600) of intra-SC predictions for the string of the current block (1630) of the current picture. The current block can be CB of CU, PB of PU, TB of TU, or other block. The size of the current block can be 64x64, 32x32, 16x16, 8x8, or some other size. More generally, the size of the current block is m × n, m and n are integers, respectively, and m and n can be equal to each other or have different values. Therefore, the current block can be square or rectangular. For intra SC prediction, the block is divided into one or more strings. In FIG. 16, the current block (1630) is divided into three strings. The string of blocks can be scanned horizontally from left to right within a given line, then to the next line, and so on. Alternatively, the blocks' strings can be scanned vertically from top to bottom, then to the next row, and so on in a given column. The string in FIG. 16 is scanned horizontally.

In FIG. 16, the first offset (1651) is from the first string (1641) of the current block (1630) to a reference string (1661) containing sample values used to predict the first string (1641). ) Indicates the displacement. The length of each of the first string (1641) and the corresponding reference string (1661) is a 6-sample value. The reference string can be the same as a given string, or it can be an approximation of a given string. The second offset (1652) is the displacement of the current block (1630) from the second string (1642) to the reference string (1662) containing the sample values used to predict the second string (1642). Is shown. The length of each of the second string (1642) and the corresponding reference string (1662) is 14 sample values. No offset is shown for the third string of the current block (1630), which has a length of 44 samples. Like the BV value, the offset values (1651, 1652) now indicate the displacement in the picture. Although FIG. 16 shows a horizontal scan, the current block (1630) can instead be split into strings that are scanned vertically for intra-SC prediction. A block-by-block, unit-by-unit, or picture-by-picture syntax element can indicate whether a horizontal scan order is used or a vertical scan order is used for intra-SC prediction.

Intra SC prediction can improve coding efficiency by utilizing redundancy (such as a repeating pattern inside a picture) using SC operation. Intra SC predictions are more flexible than Intra BC or Intra LC predictions (allowing division into arbitrary strings as well as fixed divisions), but with more information (offset value plus string length). Signal transmission. If WPP is not enabled, the candidate reference string can be anywhere in the reconstructed content of the current picture. Candidate reference strings may overlap with other candidate reference strings. In some exemplary implementations, the reference string is constrained within the same slices and tiles as the current string. The location of the reference string may be subject to one or more other constraints, such as when WPP is enabled, as described below.

The intracopy prediction operation for the intraBC mode, the intraLC mode, or the intraSC mode is CB (when a BV value or other offset value is signaled for each CB or a part thereof), or PB (BV value or Other offsets can be applied at the level (when signaled per PB or part thereof). In this case, the reference area is constrained so as not to overlap the current area or the block containing the current area. Alternatively, the intracopy prediction operation applies to smaller sections within the PB or CB, even when the BV value or other offset value is signaled to the PB or CB (or part thereof). can do. For example, for the first section of the block, the reference area includes a position outside the block. However, for the second section of the block, the reference area used for the intracopy prediction operation can include a position within the pre-reconstructed first section of the same block. In this way, the BV value or offset value can refer to a position within the same PB or CB. Allowing intracopy prediction behavior to be applied to sections within PBs or CBs facilitates the use of relatively small magnitude BV values or other offsets.

If the reference area with respect to the current area in the current unit contains a position within the same unit, the encoder considers the z-scan order of the current area and reference area (in the same slice and tile). The validity of the BV value or other offset value can be checked. For example, in the encoder, the z-scan order of the block including the lower right position (x ₀ + offset _x + m-1, y ₀ + offset _y + n-1) of the reference area is the upper left position (x ₀ , y ₀ ) of the current area. Checked to be smaller than the z-scan order of the containing blocks, in which the offset indicates an offset value and the current region and the reference region have dimensions m × n. In that case, the block containing the lower right position of the reference area has been pre-constructed (and thus the rest of the reference area). The encoder can further check that the offset value satisfies at least one of the conditions offset _x + m ≦ 0 and offset _y + n ≦ 0 to ensure that the reference region does not overlap the current region.

In general, the z-scan order follows a continuously specified order of the units that separate the pictures. FIG. 17 shows an exemplary z-scan sequence (1700) for a unit that may include the current region (1730) and the lower right position of the reference region. The current region (1730) can be a rectangle containing CB, PB, or other blocks, lines, or strings. The z-scan sequence is generally assigned to units continuously from left to right within a row and repeated from top to bottom in subsequent rows. When a unit is split, the z-scan order is recursively assigned within the split unit. H. For 265 / HEVC standard encoding / decoding implementations, the z-scan sequence progresses from CTU to CTU along the CTU raster scan pattern (left to right within the CTU line, then top to bottom on the CTU line). To do. If the CTU is split, the z-scan order follows a raster scan pattern for the CU of the quadtree within the split CTU. Also, if the CU is split (eg, into multiple CUs, or into multiple PUs), the z-scan order follows a raster scan pattern for the blocks in the split CU.

In some exemplary implementations, the BV value or other offset value is signaled to the CU, PU, or other unit and applied to all blocks of the unit. Depending on the color space and color sampling rate, the BV value or other offset value can be used for all blocks without scaling, or can be scaled for blocks with different color components. Alternatively, different BV values or other offset values can be signaled to different blocks of the unit. In some exemplary implementations, the same prediction mode (eg, intra BC mode) applies to all blocks of the unit. Alternatively, different blocks can have different prediction modes.

E. Constraints on Intracopy Prediction When WPP Is Enabled In general, Intra BC Prediction, Intra LC Prediction, and Intra SC Prediction use pre-reconstructed sample values in the picture to present the same picture. Predict sample values for blocks, lines, or strings. As a rule, the area of the picture that contains the pre-reconstructed sample values when WPP is enabled is the area of the picture that contains the pre-reconstructed sample values when WPP is not enabled. different. For intracopy prediction, some restrictions on the location of the reference area are enforced regardless of whether WPP is enabled or not. One or more other constraints on the location of the reference area apply when WPP is enabled. The constraint on the location of the reference region can take the form of a limit on the BV value allowed for the intra BC prediction, or a limit on the offset value allowed for the intra LC or intra SC prediction.

FIG. 18 shows an example (1800) of constraints on the location of the reference area for the current area (1830) of the picture (1810) when WPP is enabled, with some exemplary implementations. The picture (1810) is organized by CTU rows and CTU columns.

The current region (1830) is encoded or decoded using the intracopy mode. The current region (1830) is part of the current CTU. For the current CTU, the dependencies cascade from the previous CTU row. When the WPP is enabled, the CTU on the left side of the current CTU is being processed and the CTU in the previous line up to the CTU on the upper right is being processed to start processing the current CTU. Similarly, for any one of these already processed CTUs, the CTU on the left in the same row and the CTU in the previous row up to the CTU on the upper right are processed. As shown in FIG. 18, these pre-processed CTUs provide reconstructed content that is guaranteed to be available for intracopy prediction when WPP is enabled.

FIG. 18 shows some of the candidate reference regions for the current region (1830) of the current picture (1810). The four offset values (1841, 1842, 1843, 1844) indicate the displacements for the four reference regions. The candidate reference area may overlap with other candidate reference areas. The candidate reference area can be anywhere in the reconstructed content of the current picture (1810). When WPP is not enabled, the reconstructed content of the current picture (1810) generally includes the CTU to the left of the current CTU and all CTUs in the previous CTU row. However, when WPP is enabled, less reconstructed content is available, as shown in FIG. In FIG. 18, three of the offset values (1841, 1842, 1843) indicate a valid reference region. These valid reference areas contain only sample values in the reconstructed content that are guaranteed to be available for intracopy prediction when WPP is enabled. One of the offset values (1844) indicates an invalid reference area of the reconstructed content, which is guaranteed to be available for intracopy prediction when WPP is enabled. Includes at least some outer sample values.

1. 1. Encoding and decoding with constraints on intracopy mode when WPP is enabled Figure 19 is a generalization for encoding where rules are enforced for intracopy mode when WPP is enabled. It shows the technology (1900). Encoders such as the encoders shown in FIG. 3 or FIGS. 5a and 5b, or other encoders, can implement the technique (1900). FIG. 20 shows a generalized technique (2000) for decoding, where rules are enforced for intracopy mode when WPP is enabled. A decoder such as the decoder shown in FIG. 4 or FIG. 6, or another decoder, can carry out technique (2000).

With reference to FIG. 19, the encoder encodes the picture with WPP enabled (1910). Encoding (1910) produces encoded data. As part of the encoding (1910), for intracopy modes (eg, modes that use intraBC prediction, intraLC prediction, or intraSC prediction), the encoder enforces one or more constraints due to WPP. The encoder outputs the encoded data as part of a bitstream (1920).

Referring to FIG. 20, the decoder receives the encoded data as part of a bitstream (2010). The encoded data meets one or more restrictions due to WPP for the intracopy mode (eg, a mode that uses intraBC prediction, intraLC prediction, or intraSC prediction). The decoder decodes the encoded data with WPP enabled (2020). Decoding (2020) reconstructs the picture.

A syntax element in the bitstream can indicate whether WPP is enabled for a video sequence, set of pictures, or pictures. The syntax element can be signaled in the SPS syntax structure, the PPS syntax structure (eg, the syntax element entropy_coding_sync_enable_flag in the implementation of H.265 / HEVC), or other syntax structures in the bitstream.

The intra copy mode can be the intra BC mode. In this case, for the current block in the picture, the offset value indicates the displacement to the reference block in the picture. The reference block contains pre-reconstructed sample values. Alternatively, the intracopy mode can be the intraLC mode. In this case, for the current line in the block of the picture, the offset value indicates the displacement to the reference line in the picture. The reference line contains pre-reconstructed sample values scanned in a line scan direction that can be horizontal or vertical. Alternatively, the intracopy mode can be the intraSC mode. In this case, for the current string in the block of the picture, the offset value indicates the displacement to the reference string in the picture. The reference string contains pre-reconstructed sample values scanned in a string scan order that can be horizontal or vertical. For the current string, the length value indicates the length of each of the current string and the reference string. Alternatively, intracopy mode uses an offset value to find a reference block, line, string, or other section in the same picture for the current block, line, string, or other section in the picture. It can be in some other mode, in which case reference blocks, lines, strings, etc. contain pre-reconstructed sample values.

Constraints due to WPP can include constraints that the horizontal displacement value from the reference region to the current region is less than or equal to the vertical displacement value from the current region to the reference region. For example, the horizontal displacement value measures the difference from the WPP column containing the right edge of the reference region to the WPP column containing the left edge of the current region, and the vertical displacement value is referenced from the WPP row containing the top edge of the current region. Measure the difference up to the WPP line, including the bottom edge of the region. In some exemplary implementations, each of the WPP columns is a CTU column and each of the WPP rows is a CTU row. Alternatively, the constraints due to WPP include one or more other and / or additional constraints.

When the intracopy mode is the intraBC mode, the current area is the current block and the reference area is the reference block. When the intracopy mode is the intraLC mode, the current area is the current line and the reference area is the reference line. When the intracopy mode is the intraSC mode, the current area is a rectangle containing the current string and the reference area is a rectangle containing the reference string. The encoder or decoder can be any position in the string scan order (eg, horizontal, vertical) between the current string start position and the current string end position, and the current string start and end positions. Can identify rectangles, including. The encoder or decoder can use the offset value applied to the rectangle containing the current string to identify the rectangle containing the reference string.

Encoders can also enforce one or more other constraints that are not due to WPP. For example, the encoder can check that the upper left position of the current area and the upper left position of the reference area are in the same slice if applicable and in the same tile if applicable. As another example, the encoder can check that the upper left position of the current area and the lower right position of the reference area are in the same slice if applicable and in the same tile if applicable. it can. As yet another example, the encoder can check that one of the following three conditions is met: (A) The CTU line including the lower end of the reference area is above the CTU line including the upper end of the current area, and (b) the CTU line including the lower end of the reference area is the CTU line including the upper end of the current area. If they are equal, the CTU column containing the right edge of the reference area is to the left of the CTU column containing the left edge of the current area, and (c) the CTU row containing the bottom edge of the reference area is the CTU row containing the top edge of the current region. If they are equal, and if the CTU column containing the right edge of the reference area is equal to the CTU column containing the left edge of the current area, then the lower right position of the reference area is earlier than the upper left position of the current area in the z scan order.

The following section is an example of the constraints, with some exemplary implementations, that the encoder can enforce on intra BC predictions, intra LC predictions, and intra SC predictions when WPP is enabled, respectively. Will be described in detail.

2. 2. Illustrative Constraints on BV Value of Intra BC Prediction When WPP Is Enabled This section is an example of the constraints that the encoder can enforce against the Intra BC Prediction when WPP is enabled. It will be described in detail. For the current block, the constraint is that the candidate reference block indicated by the BV value is a reconstructed sample value that becomes available when the current block is encoded or decoded, even when WPP is enabled. Verify that it contains.

Definition. The current block starts at the position (x ₀ , y ₀ ) with respect to the upper left position of the current picture. The width and height of the current block are w _block and h _block , respectively. The current block is part of the current CU. The CTU size is S. The current CU starts at (x _CU , y _CU ) with respect to the upper left position of the picture. The block vector is (BV _x , BV _y ).

The encoder verifies that all of the following constraints are met:

The first constraint. The encoder verifies that the position (x ₀ , y ₀ ) and position (x ₀ + BV _x , y ₀ + BV _y ) are in the same slice and in the same tile. That is, the encoder verifies that the upper left position of the current block and the upper left position of the reference block are in the same slice and in the same tile. If the two positions are in different slices or different tiles, the first constraint is not met.

The second constraint. The encoder verifies that the position (x ₀ , y ₀ ) and position (x ₀ + BVx + w _block -1, y ₀ + BV _y + h _block -1) are in the same slice and in the same tile. That is, the encoder verifies that the upper left position of the current block and the lower right position of the reference block are in the same slice and in the same tile. If the two positions are in different slices or different tiles, the second constraint is not met.

With respect to the first and second constraints, if multiple slices are not used, the two positions checked will necessarily be within the same slice and there is no need to check the first and second constraints on the slices. Similarly, if more than one tile is not used, the two positions checked are necessarily within the same tile and there is no need to check the first and second constraints on the tile. All positions of the current block are within a single slice and a single tile. If the first and second constraints are met, all positions of the reference block are also within its slices and tiles. The encoder checks the first and second constraints regardless of whether WPP is enabled.

Third constraint. With respect to the third constraint, the encoder verifies that one of the following three conditions is met. The encoder checks for a third constraint regardless of whether WPP is enabled.

The first condition of the third constraint. The encoder checks whether or not (y ₀ + BV _y + h _block -1) / S <y ₀ / S. That is, the encoder calculates the CTU line including the bottom edge of the reference block: (y ₀ + BV _y + h _block -1) / S. The encoder also calculates the CTU row containing the top edge of the current block: y ₀ / S. The encoder then checks if the CTU row containing the bottom edge of the reference block is above the CTU row containing the top edge of the current block. When on the upper side, the reference block necessarily contains pre-reconstructed sample values, at least when WPP is not enabled.

The second condition of the third constraint. When (y ₀ + BV _y + h _block -1) / S == y ₀ / S, the encoder checks whether or not (x ₀ + BV _x + w _block -1) / S <x ₀ / S. That is, if the CTU row containing the bottom edge of the reference block is equal to the CTU row containing the top edge of the current block (same CTU row), the encoder will (a) have a CTU column containing the right edge of the reference block ((x ₀ + BV _x). + W _block -1) / S), and (b) CTU column (x ₀ / S) including the left edge of the current block are calculated. The encoder then checks if the CTU row containing the right edge of the reference block is to the left of the CTU row containing the left edge of the current block. On the left side, the reference block necessarily contains pre-reconstructed sample values.

The third condition of the third constraint. When (y ₀ + BV _y + h _block -1) / S == y ₀ / S and (x ₀ + BV _x + w _block -1) / S == x ₀ / S, the encoder is in the position (x ₀ + BV _x + w). _It is checked whether or not the z-scan order of _block -1, y ₀ + _y BV + h _block -1) is smaller than the z-scan order of the position (x ₀ , y ₀ ). That is, if the CTU row containing the bottom edge of the reference block is equal to the CTU row containing the top edge of the current block (same CTU row), and the CTU column containing the right edge of the reference block is equal to the CTU column containing the left edge of the current block. If (same CTU row), the encoder checks if the lower right position of the reference block is earlier in the z scan order than the upper left position of the current block. The third condition applies when predictions from within the current CU are acceptable. If predictions from within the current CU are unacceptable, then (x ₀ , y ₀ ) should be (x _CU , y _CU ).

Fourth constraint. The encoder checks for a fourth constraint when WPP is enabled. Regarding the fourth constraint, the encoder verifies that (x ₀ + BV _x + w _block -1) / S-x ₀ / S <= y ₀ / S- (y ₀ + BV _y + h _block -1) / S. To do. That is, the encoder calculates the difference between the CTU column containing the right edge of the reference block and the CTU column containing the left edge of the current block: (x ₀ + BV _x + w _block -1) / S-x ₀ / S. The encoder also calculates the difference between the CTU line containing the top edge of the current block and the CTU line containing the bottom edge of the reference block: y ₀ / S- (y ₀ + BV _y + h _block -1) / S. The encoder verifies that the first difference (between CTU columns) is less than or equal to the second difference (between CTU rows). As shown in the jagged lines of the CTU above and to the right of the current CTU in FIG. 8 or 18, the above is available for prediction when the reference block is enabled for WPP. Verify that it is part of the guaranteed, reconstructed content.

3. 3. Illustrative Constraints on Intra LC Prediction Offset Values When WPP Is Enabled This section is an example of the constraints that the encoder can enforce on Intra LC Predictions when WPP is enabled. Will be described in detail. For the current line, the constraint is that the candidate reference line indicated by the offset value is a reconstructed sample value that becomes available when the current line is encoded or decoded, even when WPP is enabled. Verify that it contains.

Definition. The current block starts at the position (x ₀ , y ₀ ) with respect to the upper left position of the current picture. The width and height of the current block are w _block and h _block , respectively. The current block is part of the current CU. The CTU size is S. The offset value for the current line is (offset _x , offset _y ). The L line of the current block has already been processed.

The encoder defines the start and end positions of the current line of the current block. The position (x _{curr_line_start} , y _{curr_line_start} ) is the start position of the current line, and the position (x _{curr_line_end} , y _{curr_line_end} ) is the end position of the current line. When horizontal scan (also called row mode) is used, every line is the row of the current block: (x _{curr_line_start} , y _{curr_line_start} ) = (x ₀ , y ₀ + L), and (x _{curr_line_end} , y _{curr_line_end} ). = (X ₀ + w _block -1, y ₀ + L). When a vertical scan (also called column mode) is used, every line is the column of the current block: (x _{curr_line_start} , y _{curr_line_start} ) = (x ₀ + L, y ₀ ), and (x _{curr_line_end} , y _{curr_line_end} ). = (X ₀ + L, y ₀ + h _block -1).

The encoder also defines the start and end positions of the candidate reference line that predicts the current line. The position (x _{ref_line_start} , y _{ref_line_start} ) is the start position of the reference line. The position (x _{ref_line_end} , y _{ref_line_end} ) is the end position of the reference line. The reference line can be a row (when a horizontal scan is used) or a column (when a vertical scan is used). Horizontal scan (line mode) or vertical scan (column mode) is _{used: (x ref_line_start, y ref_line_start)} = (x curr_line_start, y curr_line_start) + (offset x, offset y), and _{(x ref_line_end, y ref_end)} = (X _{curr_line_end} , y _{curr_line_end} ) + (offset _x , offset _y ).

The encoder verifies that all of the following constraints are met: For some of these constraints, the upper left position of the current block (x ₀ , y ₀ ) is considered. Alternatively, for such constraints, the start position of the current line (x _{curr_line_start} , y _{curr_line_start} ) can be checked instead of the upper left position (x ₀ , y ₀ ) of the current block.

The first constraint. The encoder _verifies that the positions (x ₀ , y ₀ ) and positions (x _{ref_line_start} , y _{ref_line_start} ) are in the same slice and in the same tile. That is, the encoder verifies that the top left position of the current block and the start position of the reference line are in the same slice and in the same tile. If the two positions are in different slices or different tiles, the first constraint is not met.

The second constraint. The encoder _verifies that the positions (x ₀ , y ₀ ) and positions (x _{ref_line_end} , y _{ref_line_end} ) are in the same slice and in the same tile. That is, the encoder verifies that the top left position of the current block and the end position of the reference line are in the same slice and in the same tile. If the two positions are in different slices or different tiles, the second constraint is not met.

With respect to the first and second constraints, if more than one slice is not used, the two positions checked are necessarily within the same slice and there is no need to check the first and second constraints with respect to the slices. Similarly, if multiple tiles are not used, the two positions checked will necessarily be within the same tile, and there is no need to check the first and second constraints on the tiles. All positions of the current line are within a single slice and a single tile. If the first and second constraints are met, all positions of the reference line are also within the slice and tile. The encoder checks the first and second constraints regardless of whether WPP is enabled.

Third constraint. With respect to the third constraint, the encoder verifies that one of the following three conditions is met. The encoder checks for a third constraint regardless of whether WPP is enabled.

The first condition of the third constraint. The encoder checks whether or not y _{ref_line_end} / S <y ₀ / S. That is, the encoder calculates a CTU line that includes the bottom or bottom position of the reference line: _{yref_line_end} / S. The encoder also calculates the CTU row containing the top edge of the current block: y ₀ / S. The encoder then checks if the CTU line, including the bottom or bottom of the reference line, is above the CTU line, including the top of the current block. When on the upper side, the reference line necessarily contains pre-reconstructed sample values, at least when WPP is not enabled.

The second condition of the third constraint. When y _{ref_line_end} / S == y ₀ / S, the encoder checks whether or not x _{ref_line_end} / S <x ₀ / S. That is, if the CTU row containing the bottom or bottom of the reference line is equal to the CTU row containing the top of the current block (same CTU row), the encoder will (a) have the CTU column containing the right edge or right position of the reference line (a). x _{ref_line_end} / S), and (b) the CTU column (x ₀ / S) including the left edge of the current block. The encoder then checks if the CTU row containing the right edge or right position of the reference line is to the left of the CTU row containing the left edge of the current block. On the left side, the reference line necessarily contains pre-reconstructed sample values.

The third condition of the third constraint. When _{y ref_line_end / S == y 0 /} S and _{x ref_line_end / S == x 0 /} S, encoder position _{(x ref_line_end, y ref_line_end)} z scan order of the position _{(x curr_line_start, y curr_line_start)} of Check if it is smaller than the z scan order. That is, the CTU row containing the bottom or bottom of the reference line is equal to the CTU row containing the top of the current block (same CTU row), and the CTU column containing the right edge or right position of the reference line contains the left edge of the current block. If equal to the CTU row (same CTU row), the encoder checks if the end position of the reference line is earlier than the start position of the current line in the z-scan order. The third condition applies when predictions from within the current CU are acceptable. If predictions from within the current CU are unacceptable, then (x _{curr_line_start} , y _{curr_line_start} ) should be (x ₀ , y ₀ ).

Fourth constraint. The encoder checks for a fourth constraint when WPP is enabled. With respect to the fourth constraint, the encoder _verifies that x _{ref_line_end} / S-x ₀ / S <= y ₀ / S-y _{ref_line_end} / S. That is, the encoder calculates the difference between the CTU column containing the right edge or right position of the reference line and the CTU column containing the left edge of the current block: x _{ref_line_end} / S-x ₀ / S. The encoder also calculates the difference between the CTU line containing the top edge of the current block and the CTU line containing the bottom or bottom of the reference line: y ₀ / S-y _{ref_line_end} / S. The encoder verifies that the first difference (between CTU columns) is less than or equal to the second difference (between CTU rows).

4. Illustrative Constraints on Intra SC Prediction Offset Values When WPP Is Enabled This section is an example of the constraints that the encoder can enforce on intra SC Predictions when WPP is enabled. Will be described in detail. For the current string, the constraint is that the candidate reference string indicated by the offset and length values will be available when the current string is encoded or decoded, even when WPP is enabled. Verify that the sample values are included.

Definition. The current block starts at the position (x ₀ , y ₀ ) with respect to the upper left position of the current picture. The width and height of the current block are w _block and h _block , respectively. The current block is part of the current CU. The CTU size is S. The offset value for the current string is (offset _x , offset _y ) and the string length value for the current string is length _string . K pixels of the current block have already been processed using intra-SC prediction.

The encoder defines the start and end positions of the current string in the current block. Position _{(x curr _ string _ start,} y curr_string_start) is the start position of the current string, position _{(x curr_string_end, y curr_string_end)} is the end position of the current string. The encoder also defines a bounding rectangle that includes the start position of the current string, the end position of the current string, and any position between the start and end positions of the current string (in the string scan order). The upper left position of the bounding rectangle is _{(x curr _ rect _ TL,} y curr_rect_TL). Lower right position of the bounding rectangle is _{(x curr _ rect _ BR,} y curr_rect_BR). The encoder defines a reference rectangle (including a reference string) as a bounding rectangle displaced by an offset value. The upper left position of the reference rectangle is (x _{ref_rect_TL} , y _{ref_rect_TL} ). The lower right position of the boundary rectangle is (x _{ref_rect_BR} , y _{ref_rect_BR} ).

When a horizontal string scan is used (left-to-right, top-to-bottom line within the current block line), the starting position is: (x _{curr_string_start} , y _{curr_string_start} ) = (x ₀ + K% w _block , y _0). + K / w _block ). The end position is: (x _{curr_string_end} , y _{curr_string_end} ) = (x ₀ + (K + length _string -1)% w _block , y ₀ + (K + length _string -1) / w _block ). If the start and end positions of the current string in the same row of the current _{block, (x curr_rect_TL, y curr_rect_TL)} = (x curr_string_start, y curr_string_start), and _{(x curr_rect_BR, y curr_rect_BR) =} (x curr_string_end, y _{curr_string_end} ). Otherwise, the upper left position of the boundary rectangle is (x _{curr_rect_TL} , y _{curr_rect_TL} ) = (x ₀ , y ₀ + K / w _block ), and the lower right position of the boundary rectangle is (x _{curr_rect_BR} , y _{curr_rect_BR} ) = (x ₀ + _w block _-1), a _{y 0 + (K + length string} -1) / w block).

When the vertical scanning is used (from top to bottom in the column of the current block, the right column from the left column), the starting _{position: (x curr _ string _ start} , y curr_string_start) = (x 0 + K / h _block , y ₀ + K% h _block ). The end position is: (x _{curr_string_end} , y _{curr_string_end} ) = (x ₀ + (K + length _string -1) / h _block , y ₀ + (K + length _string -1)% h _block ). When the start position and end position of the current string in the same column of the current _{block, (x curr_rect_TL, y curr_rect_TL)} = (x curr_string_start, y curr_string_start), and _{(x curr_rect_BR, y curr_rect_BR) =} (x curr_string_end, y _{curr_string_end} ). Otherwise, the upper left position of the bounding rectangle is _{(x curr_rect_TL, y curr_rect_TL) =} (x 0 + K / h block, y 0), the lower right position of the boundary rectangle _{(x curr_rect_BR, y curr_rect_BR) =} (x _{0 + (K + length string -1} ) / h block), a _{y 0 + h block} -1).

Regardless of whether a horizontal scan is used or a vertical scan is used, the upper left position of the reference rectangle is (x _{ref_rect_TL} , y _{ref_rect_TL} ) = (x _{curr_rect_TL} , y _{curr_rect_TL} ) + (offset _x , offset _y ). _Yes , the lower right position of the reference rectangle is (x _{ref_rect_BR} , y _{ref_rect_BR} ) = (x _{curr_rect_BR} , y _{curr_rect_BR} ) + (offset _x , offset _y ). Finally, the starting position of the reference string is (x _{ref_string_start} , y _{ref_string_start} ) = (x _{curr_string_start} , y _{curr_start_start} ) + (offset _x , offset _y ).

The encoder verifies that all of the following constraints are met: For some of these constraints, the upper left position of the current block (x ₀ , y ₀ ) is considered. Alternatively, for such a constraint, the starting position of the current string or the upper left position of the bounding rectangle can be checked instead of the upper left position (x ₀ , y ₀ ) of the current block.

The first constraint. The encoder _verifies that the position (x ₀ , y ₀ ) and position (x _{ref_rect_TL} , y _{ref_rect_TL} ) are in the same slice and in the same tile. That is, the encoder verifies that the upper left position of the current block and the upper left position of the reference rectangle are in the same slice and in the same tile. If the two positions are in different slices or different tiles, the first constraint is not met.

The second constraint. The encoder _verifies that the position (x ₀ , y ₀ ) and position (x _{ref_rect_BR} , y _{ref_rect_BR} ) are in the same slice and in the same tile. That is, the encoder verifies that the upper left position of the current block and the lower right position of the reference rectangle are in the same slice and in the same tile. If the two positions are in different slices or different tiles, the second constraint is not met.

With respect to the first and second constraints, if more than one slice is not used, the two positions checked are necessarily within the same slice and there is no need to check the first and second constraints with respect to the slices. Similarly, if multiple tiles are not used, the two positions checked will necessarily be within the same tile, and there is no need to check the first and second constraints on the tiles. All positions of the current string are within a single slice and a single tile. If the first and second constraints are met, all positions of the reference rectangle (and thus the reference string) are also within its slices and tiles. The encoder checks the first and second constraints regardless of whether WPP is enabled.

Third constraint. With respect to the third constraint, the encoder verifies that one or more of the following conditions are met: The encoder checks for a third constraint regardless of whether WPP is enabled.

The first condition of the third constraint. The encoder checks whether or not y _{ref_rect_BR} / S <y ₀ / S. That is, the encoder calculates a CTU row that includes the bottom edge of the reference rectangle: _{yref_rect_BR} / S. The encoder also calculates the CTU row containing the top edge of the current block: y ₀ / S. The encoder then checks if the CTU row containing the bottom edge of the reference rectangle is above the CTU row containing the top edge of the current block. When on the upper side, the reference rectangle necessarily contains pre-reconstructed sample values, at least when WPP is not enabled.

The second condition of the third constraint. When y _{ref_rect_BR} / S == y ₀ / S, the encoder checks whether or not x _{ref_rect_BR} / S <x ₀ / S. That is, if the CTU row containing the bottom edge of the reference rectangle is equal to the CTU row containing the top edge of the current block (same CTU row), then the encoder (a) has the CTU column (x _{ref_rect_BR} / S) containing the right edge of the reference rectangle. And (b) calculate the CTU column (x ₀ / S) including the left edge of the current block. The encoder then checks if the CTU row containing the right edge of the reference rectangle is to the left of the CTU row containing the left edge of the current block. On the left side, the reference rectangle necessarily contains pre-reconstructed sample values.

The third condition of the third constraint. When y _{ref_rect_BR} / S == y ₀ / S and x _{ref_rect_BR} / S == x ₀ / S, the encoder has the z scan order of the position (x _{ref_rect_BR} , y _{ref_rect_BR} ) of the position (x ₀ , y ₀ ). Check if it is smaller than the z-scan order. That is, if the CTU row containing the bottom edge of the reference rectangle is equal to the CTU row containing the top edge of the current block (same CTU row), and the CTU column containing the right edge of the reference rectangle is equal to the CTU column containing the left edge of the current block ( In the same CTU column), the encoder checks if the lower right position of the reference rectangle is earlier than the upper left position of the current block in the z scan order.

The fourth condition of the third constraint. If prediction from within the current CU is acceptable, the encoder checks that x _{ref_string_start} <x ₀ when y _{ref_string_start} == y ₀ . That is, if predictions from within the current CU are allowed, the third constraint can be met if the current string and the reference string start on the same line and the reference string starts to the left of the current string.

Fourth constraint. The encoder checks for a fourth constraint when WPP is enabled. With respect to the fourth constraint, the encoder _verifies that x _{ref_rect_BR} / S-x ₀ / S <= y ₀ / S-y _{ref_rect_BR} / S. That is, the encoder calculates the difference between the CTU row containing the right or right position of the reference rectangle and the CTU row containing the left edge of the current block: x _{ref_rect_BR} / S-x ₀ / S. The encoder also calculates the difference between the CTU row containing the top edge of the current block and the CTU row containing the bottom edge or bottom position of the reference rectangle: y ₀ / S-y _{ref_rect_BR} / S. The encoder verifies that the first difference (between CTU columns) is less than or equal to the second difference (between CTU rows).

Fifth constraint. With respect to the fifth constraint, the encoder verifies that K + lens _string <= w _block × h _block . That is, the encoder checks that the current block contains enough positions for the current string, taking into account the count of positions already processed.

F. Alternatives and Variants In many of the examples described herein, intracopy prediction and motion compensation are implemented in separate components or processes, and offset and motion estimation are implemented in separate components or processes. Alternatively, intracopy prediction can be realized as a special case of motion compensation, and offset estimation can be realized as a special case of motion estimation in which the picture is currently used as a reference picture. In such an implementation, the offset value can be signaled as the MV value, but is used for intra-picture prediction (in the current picture) rather than inter-picture prediction. As used herein, the term "intracopy prediction" is currently used regardless of whether the prediction is provided using an in-picture prediction module, motion compensation module, or any other module. Shows the prediction in the picture. Similarly, BV values or other offset values can be represented using MV values or using distinguishable types of parameters or syntax elements, and offset estimation is an in-picture estimation module, motion estimation. It can be provided using a module, or any other module.

In view of the many possible embodiments to which the principles of the disclosed invention may be applied, the illustrated embodiments are merely preferred embodiments of the invention and should not be taken as limiting the scope of the invention. You should be aware of that. Rather, the scope of the invention is defined by the following claims. Therefore, the present invention claims everything within the scope and purpose of these claims.

Claims (8)

In the computer implementation method
An encoding step that encodes a picture with wave-plane parallel processing (WPP) possible, said encoding is one that produces encoded data and is consistent with said WPP for intrablock copy prediction. Including enforcing the above constraints, the one or more constraints say that the horizontal displacement value from the reference region to the current region is less than or equal to the vertical displacement value from the current region to the reference region. Encoding steps, including constraints,
The step of outputting the encoded data as a part of a bit stream, and
How to include. The horizontal displacement value is measured by measuring the difference from the coded tree unit (CTU) row including the right end of the reference region to the CTU row including the left end of the current region.
The vertical displacement value measures the difference from the CTU row including the upper end of the current region to the CTU row including the lower end of the reference region.
The method according to claim 1 . The current region is the current block in the encoding tree unit (CTU), and the encoding is
The horizontal displacement value is calculated as (x ₀ + BV _x + w _block -1) / S−x ₀ / S, where x ₀ is the horizontal position of the current block in the CTU. , BVx is the horizontal component of the vector of the intra-block copy prediction, w _block is the width of the current block, and S is the size of the CTU.
The vertical displacement value is calculated as y ₀ / S- (y ₀ + BV _y + h _block -1) / S, where y ₀ is the vertical position of the current block and BV _y is. , Is the vertical component of the vector of the intra-block copy prediction, and h _block is the height of the current block.
The method according to claim 1, wherein the method comprises. Regarding the intra-block copy prediction, other restrictions are
(1) the upper left position of the current region and the left upper position of the reference region is a same slice, and it is within the same tile,
(2) said that said top-left position of the current region and the lower right position of the reference region is the same in the slice, and it is within the same tile,
(3) The following three conditions, that is,
(A) The encoded tree unit (CTU) line including the lower end of the reference area is above the CTU line including the upper end of the current area.
(B) When the CTU row including the lower end of the reference region is equal to the CTU row including the upper end of the current region, the CTU column including the right end of the reference region is the left end of the current region. Being to the left of the including CTU column, and
(C) When the CTU row including the lower end of the reference region is equal to the CTU row including the upper end of the current region, and when the CTU column including the right end of the reference region is the current region. The lower right position of the reference area is earlier than the upper left position of the current area in the z-scan order when it is equal to the CTU column including the left end of the above.
That one of them is satisfied
The method according to claim 1, wherein the method comprises. The current region is the current block and the reference region is the reference block.
The method according to any one of claims 1 to 4 . For the current block in the picture, the offset value indicates the displacement with respect to the reference block in the picture, which reference block contains a pre-reconstructed sample value.
The method according to claim 5 . One or more computer-readable media storing computer-executable instructions that cause a programmed computing system to perform the method according to any one of claims 1-6 . A computing system configured to perform the method according to any one of claims 1-6 .

Images