Derivation of temporal motion vector prediction candidates in video decoding

Abstract

An example method includes: decoding, by a video decoder via a decoded video bitstream, a syntax element that specifies whether the decoded video bitstream includes multiple syntax elements that specify parameters for a temporal motion vector prediction (TMVP) candidate derivation process; in a case where the syntax element specifies that the decoded video bitstream includes multiple syntax elements: decoding, by the video decoder via the decoded video bitstream, the multiple syntax elements; and deriving, by the video decoder and based on the parameters specified by the multiple syntax elements, a TMVP candidate for a current block of a current picture of video data; generating a list of motion vector candidates for the current block, the list including the derived TMVP candidate; and predicting the current block based on the list of motion vector candidates.

Description

[0001] This application claims priority to U.S. Application No. 16 / 909,856, filed on June 23, 2020, which claims the benefit of U.S. Provisional Application No. 62 / 866,536, filed on June 25, 2019, U.S. Provisional Application No. 62 / 867,021, filed on June 26, 2019, and U.S. Provisional Application No. 62 / 868,462, filed on June 28, 2019, the entire contents of each of which are hereby incorporated by reference. Technical Field

[0002] The present disclosure relates to video encoding and video decoding. Background Art

[0003] Digital video capabilities may be incorporated into a wide range of devices, including digital televisions, digital live broadcast systems, wireless broadcast systems, personal digital assistants (PDAs), laptop or desktop computers, tablet computers, e-book readers, digital cameras, digital recording devices, digital media players, video game devices, video game consoles, cellular or satellite wireless telephones, so-called "smart phones", video teleconferencing devices, video streaming devices, etc. Digital video devices implement video coding techniques (such as those described in standards defined by MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264 / MPEG-4 (Part 10, Advanced Video Coding (AVC)), ITU-T H.265 / High Efficiency Video Coding (HEVC), and extensions of such standards). By implementing such video coding techniques, video devices may more efficiently send, receive, encode, decode, and / or store digital video information.

[0004] Video coding techniques include spatial (intra-picture) prediction and / or temporal (inter-picture) prediction to reduce or remove redundancy inherent in video sequences. For block-based video coding, a video slice (e.g., a video picture or a portion of a video picture) may be partitioned into video blocks, which may also be referred to as coding tree units (CTUs), coding units (CUs), and / or coding nodes. Video blocks in an intra-coded (I) slice of a picture are encoded using spatial prediction relative to reference samples in neighboring blocks in the same picture. Video blocks in an inter-coded (P or B) slice of a picture may use spatial prediction relative to reference samples in neighboring blocks in the same picture or temporal prediction relative to reference samples in other reference pictures. Pictures may be referred to as frames, and reference pictures may be referred to as reference frames. Summary of the invention

[0005] In summary, the present disclosure describes techniques for deriving temporal motion vector prediction (TMVP) candidates for video coding. In order to determine a motion vector for a current block of video data, a video coder may generate a list of motion vector candidates. Examples of candidates that may be included in the list are spatial candidates, TMVP candidates, history-based MVP candidates, paired candidates, combined bidirectional candidates, and / or default candidates. Both a video encoder and a video decoder may generate exactly the same list, and the video encoder may signal the video coder an index indicating which candidate from the list to use.

[0006] The video decoder can derive TMVP candidates in the same manner for each block of video data. For example, the video decoder can derive TMVP candidates using inferred default parameters so that the video decoder derives TMVP candidates based on co-located prediction units (PUs) in co-located pictures. However, in some examples, the TMVP candidates derived based on the default parameters may not be the best TMVP candidates. For example, other motion vectors from other pictures can identify reference blocks with samples that more closely match samples of the current block. Making the reference block have samples that more closely match samples of the current block can improve decoding efficiency by reducing the size of the residual data.

[0007] According to one or more techniques of the present disclosure, the derivation of TMVP candidates can be made more flexible. For example, as opposed to inferring parameters (TMVP parameters) for controlling the derivation of TMVP candidates, a video decoder can explicitly signal parameters for controlling the derivation of TMVP candidates. Some example parameters that can be signaled include a reference picture list for the derivation of co-located pictures for deriving TMVP candidates, a reference index of co-located pictures, and a reference picture list for the derivation of motion vector candidates for deriving TMVP candidates. By explicitly signaling parameters, a video encoder may be able to select a TMVP candidate that identifies a reference block with samples that more closely match samples of the current block. The reduction in the size of the residual data generated may be greater than the data used to signal the TMVP parameters. In this way, the techniques of the present disclosure can improve decoding efficiency (e.g., by reducing the amount of data used to encode video data).

[0008] In some examples, the video decoder may selectively signal TMVP parameters. For example, in contrast to always inferring TMVP parameters or always explicitly signaling TMVP parameters, the video decoder may signal a syntax element indicating whether to explicitly signal TMVP parameters. In the case where the syntax element indicates that the TMVP parameters are explicitly signaled, the video decoder may decode multiple syntax elements that specify the TMVP parameters. Otherwise (e.g., in the case where the syntax element does not indicate that the TMVP parameters are explicitly signaled), the video decoder may infer the TMVP parameters. In some examples, in the case where the amount of data used to explicitly signal the TMVP parameters will be greater than the amount of data saved by using TMVP candidates other than TMVP candidates derived based on the inferred TMVP parameters, the video encoder may choose to infer the TMVP parameters. In this way, the technology of the present disclosure may improve decoding efficiency (e.g., by reducing the amount of data used to encode the video data).

[0009] In one example, a method includes: decoding, by a video decoder and via a decoded video bitstream, a syntax element specifying whether the decoded video bitstream includes multiple syntax elements that specify parameters for a TMVP candidate derivation process; in a case where the syntax element specifies that the decoded video bitstream includes multiple syntax elements: decoding, by the video decoder and via the decoded video bitstream, the multiple syntax elements; and deriving, by the video decoder and based on the parameters specified by the multiple syntax elements, a TMVP candidate for a current block of a current picture of video data; generating a list of motion vector candidates for the current block, the list including the derived TMVP candidate; and predicting the current block based on the list of motion vector candidates.

[0010] In another example, a device includes: a memory configured to store at least a portion of a decoded video bitstream; and one or more processors implemented in circuits and configured to: decode a syntax element via the decoded video bitstream, the syntax element specifying whether the decoded video bitstream includes multiple syntax elements that specify parameters for a temporal motion vector prediction (TMVP) candidate derivation process; where the syntax element specifies that the decoded video bitstream includes multiple syntax elements: decode the multiple syntax elements via the decoded video bitstream; and derive TMVP candidates for a current block of a current picture of video data based on the parameters specified by the multiple syntax elements; generate a list of motion vector candidates for the current block, the list including the derived TMVP candidates; and predict the current block based on the list of motion vector candidates.

[0011] In another example, a device includes: a unit for decoding a syntax element via a decoded video bitstream, the syntax element specifying whether the decoded video bitstream includes multiple syntax elements that specify parameters for a TMVP candidate derivation process; a unit for decoding multiple syntax elements via the decoded video bitstream if the syntax element specifies that the decoded video bitstream includes multiple syntax elements; a unit for deriving a TMVP candidate for a current block of a current picture of video data based on the parameters specified by the multiple syntax elements; a unit for generating a list of motion vector candidates for the current block, the list including the derived TMVP candidate; and a unit for predicting the current block based on the list of motion vector candidates.

[0012] In another example, a computer-readable storage medium stores instructions that, when executed by one or more processors of a video decoder, cause the one or more processors to perform the following operations: decode a syntax element via a decoded video bitstream, the syntax element specifying whether the decoded video bitstream includes multiple syntax elements that specify parameters for a TMVP candidate derivation process; where the syntax element specifies that the decoded video bitstream includes multiple syntax elements: decode the multiple syntax elements via the decoded video bitstream by the video decoder; and derive, by the video decoder and based on the parameters specified by the multiple syntax elements, a TMVP candidate for a current block of a current picture of video data; generate a list of motion vector candidates for the current block, the list including the derived TMVP candidate; and predict the current block based on the list of motion vector candidates.

[0013] The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 is a block diagram illustrating an example video encoding and decoding system that may perform the techniques of this disclosure.

[0015] Figure 2A and 2B is a conceptual diagram showing spatial neighboring candidates in HEVC.

[0016] Figure 3A and 3B is a conceptual diagram showing temporal motion vector prediction in HEVC.

[0017] Figure 4A and 4B is a conceptual diagram showing spatial and temporal neighboring motion vector candidates for merge / skip mode.

[0018] Figure 5is a conceptual diagram illustrating sub-PU motion prediction from a reference picture.

[0019] Figure 6 is a conceptual diagram showing related pictures in Advanced Temporal Motion Vector Prediction (ATMVP).

[0020] Figure 7 is a conceptual diagram illustrating the derivation of a non-sub-PU temporal spatial motion vector predictor.

[0021] Fig. 8A and Figure 8B is a conceptual diagram illustrating an example quadtree binary tree (QTBT) structure and a corresponding coding tree unit (CTU).

[0022] Fig. 9 is a block diagram illustrating an example video encoder that may perform the techniques of this disclosure.

[0023] Fig.10 is a block diagram illustrating an example video decoder that may perform the techniques of this disclosure.

[0024] Fig.11 is a flow chart illustrating an example method for encoding a current block.

[0025] Fig.12 is a flow chart illustrating an example method for decoding a current block.

[0026] Fig.13 is a flow chart illustrating an example method for deriving temporal motion vector predictor (TMVP) candidates in accordance with one or more techniques of this disclosure. DETAILED DESCRIPTION

[0027] Figure 1 1 is a block diagram illustrating an example video encoding and decoding system 100 that can perform the techniques of the present disclosure. In general, the techniques of the present disclosure relate to coding (encoding and / or decoding) video data. In general, video data includes any data used to process video. Thus, video data can include original unencoded video, encoded video, decoded (e.g., reconstructed) video, and video metadata (e.g., signaling data).

[0028] like Figure 1As shown, in this example, system 100 includes a source device 102 that provides encoded video data to be decoded and displayed by a destination device 116. Specifically, source device 102 provides the video data to destination device 116 via computer-readable medium 110. Source device 102 and destination device 116 may include any of a wide range of devices, including desktop computers, notebook computers (i.e., laptop computers), tablet computers, set-top boxes, telephone handsets (such as smart phones), televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, etc. In some cases, source device 102 and destination device 116 may be equipped for wireless communication, and thus may be referred to as wireless communication devices.

[0029] exist Figure 1 In the example of , source device 102 includes video source 104, memory 106, video encoder 200 and output interface 108. Destination device 116 includes input interface 122, video decoder 300, memory 120 and display device 118. According to the present disclosure, the video encoder 200 of source device 102 and the video decoder 300 of destination device 116 can be configured to apply the technology for the derivation of temporal motion vector prediction (TMVP). Therefore, source device 102 represents an example of a video encoding device, and destination device 116 represents an example of a video decoding device. In other examples, source device and destination device may include other components or arrangements. For example, source device 102 may receive video data from an external video source such as an external camera. Similarly, destination device 116 may be docked with an external display device instead of including an integrated display device.

[0030] like Figure 1 The system 100 shown in is only an example. In general, any digital video encoding and / or decoding device can perform the technology for TMVP. The source device 102 and the destination device 116 are only examples of such decoding devices, wherein the source device 102 generates encoded video data for transmission to the destination device 116. The present disclosure refers to a "decoding" device as a device that performs decoding (e.g., encoding and / or decoding) of data. Therefore, the video encoder 200 and the video decoder 300 represent examples of decoding devices (specifically, video encoders and video decoders), respectively. In some examples, the devices 102 and 116 can operate in a substantially symmetrical manner, so that each of the devices 102 and 116 includes video encoding and decoding components. Therefore, the system 100 can support one-way or two-way video transmission between the devices 102 and 116, for example, for video streaming, video playback, video broadcasting, or video telephony.

[0031] Typically, video source 104 represents the source of video data (i.e., original, unencoded video data), and provides a series of pictures (also referred to as "frames") of the order of the video data to video encoder 200, which encodes the data for the pictures. The video source 104 of source device 102 may include a video capture device, such as a camera, a video archive unit containing previously captured original video, and / or a video feed interface for receiving video from a video content provider. As another alternative, video source 104 may generate computer graphics-based data as source video, or a combination of real-time video, archived video, and computer-generated video. In each case, video encoder 200 may encode captured, pre-captured, or computer-generated video data. Video encoder 200 may rearrange pictures from the received order (sometimes referred to as "display order") to a decoding order for decoding. Video encoder 200 may generate a bitstream comprising encoded video data. Source device 102 may then output the encoded video data onto computer-readable medium 110 via output interface 108 to be received and / or retrieved by, for example, input interface 122 of destination device 116 .

[0032] The memory 106 of the source device 102 and the memory 120 of the destination device 116 represent general purpose memories. In some examples, the memories 106, 120 can store original video data, for example, original video from the video source 104 and original decoded video data from the video decoder 300. In addition or alternatively, the memories 106, 120 can store software instructions that can be executed by, for example, the video encoder 200 and the video decoder 300, respectively. Although shown as separate from the video encoder 200 and the video decoder 300 in this example, it should be understood that the video encoder 200 and the video decoder 300 can also include internal memories for functionally similar or equivalent purposes. In addition, the memories 106, 120 can store, for example, encoded video data output from the video encoder 200 and input to the video decoder 300. In some examples, portions of the memories 106, 120 can be allocated as one or more video buffers, for example, to store original decoded and / or encoded video data.

[0033] The computer-readable medium 110 may represent any type of medium or device capable of transmitting the encoded video data from the source device 102 to the destination device 116. In one example, the computer-readable medium 110 represents a communication medium that enables the source device 102 to directly send the encoded video data to the destination device 116 in real time, for example, via a radio frequency network or a computer-based network. The output interface 108 may modulate the transmission signal including the encoded video data according to a communication standard such as a wireless communication protocol, and the input interface 122 may demodulate the received transmission information according to a communication standard such as a wireless communication protocol. The communication medium may include any wireless or wired communication medium, for example, a radio frequency (RF) spectrum or one or more physical transmission lines. The communication medium may form a portion of a packet-based network such as a local area network, a wide area network, or a global network such as the Internet. The communication medium may include a router, a switch, a base station, or any other device that may be useful for facilitating communication from the source device 102 to the destination device 116.

[0034] In some examples, source device 102 may output the encoded data from output interface 108 to storage device 112. Similarly, destination device 116 may access the encoded data from storage device 112 via input interface 122. Storage device 112 may include any of a variety of distributed or locally accessed data storage media, such as a hard drive, Blu-ray disc, DVD, CD-ROM, flash memory, volatile or non-volatile memory, or any other suitable digital storage medium for storing encoded video data.

[0035] In some examples, the source device 102 may output the encoded video data to a file server 114 or another intermediate storage device that may store the encoded video generated by the source device 102. The destination device 116 may access the stored video data from the file server 114 via streaming or downloading. The file server 114 may be any type of server device capable of storing the encoded video data and sending the encoded video data to the destination device 116. The file server 114 may represent a web server (e.g., for a website), a file transfer protocol (FTP) server, a content delivery network device, or a network attached storage (NAS) device. The destination device 116 may access the encoded video data from the file server 114 via any standard data connection (including an Internet connection). This may include a wireless channel (e.g., a Wi-Fi connection), a wired connection (e.g., a digital subscriber line (DSL), a cable modem, etc.), or a combination of the two suitable for accessing the encoded video data stored on the file server 114. The file server 114 and the input interface 122 may be configured to operate according to the following: a streaming protocol, a download transmission protocol, or a combination thereof.

[0036] Output interface 108 and input interface 122 may represent wireless transmitters / receivers, modems, wired networking components (e.g., Ethernet cards), wireless communication components that operate according to any of a variety of IEEE 802.11 standards, or other physical components. In examples where output interface 108 and input interface 122 include wireless components, output interface 108 and input interface 122 may be configured to transmit data (such as encoded video data) according to a cellular communication standard (such as 4G, 4G-LTE (Long Term Evolution), Advanced LTE, 5G, etc.). In some examples where output interface 108 includes a wireless transmitter, output interface 108 and input interface 122 may be configured to transmit data (such as encoded video data) according to other wireless standards (such as IEEE 802.11 specifications, IEEE 802.15 specifications (e.g., ZigBee TM ), Bluetooth TM Standards, etc.) to transmit data (such as encoded video data). In some examples, source device 102 and / or destination device 116 may include corresponding system-on-chip (SoC) devices. For example, source device 102 may include a SoC device for performing the functions assigned to video encoder 200 and / or output interface 108, and destination device 116 may include a SoC device for performing the functions assigned to video decoder 300 and / or input interface 122.

[0037] The techniques of the present disclosure may be applied to video decoding to support any of a variety of multimedia applications, such as over-the-air television broadcasting, cable television transmission, satellite television transmission, Internet streaming video transmission (such as Dynamic Adaptive Streaming over HTTP (DASH)), digital video encoded onto a data storage medium, decoding of digital video stored on a data storage medium, or other applications.

[0038] The input interface 122 of the destination device 116 receives the encoded video bitstream from the computer-readable medium 110 (e.g., the storage device 112, the file server 114, etc.). The encoded video bitstream may include signaling information such as the following syntax elements defined by the video encoder 200 (which are also used by the video decoder 300): the syntax elements have values ​​that describe the characteristics and / or processing of video blocks or other decoding units (e.g., slices, pictures, groups of pictures, sequences, etc.). The display device 118 displays the decoded pictures of the decoded video data to the user. The display device 118 can represent any of a variety of display devices, such as a cathode ray tube (CRT), a liquid crystal display (LCD), a plasma display, an organic light emitting diode (OLED) display, or another type of display device.

[0039] Despite Figure 1 2, but in some examples, the video encoder 200 and the video decoder 300 may each be integrated with an audio encoder and / or an audio decoder, and may include appropriate MUX-DEMUX units or other hardware and / or software to process multiplexed streams including both audio and video in a common data stream. If applicable, the MUX-DEMUX units may follow the ITU H.223 multiplexer protocol or other protocols such as the User Datagram Protocol (UDP).

[0040] The video encoder 200 and the video decoder 300 can each be implemented as any of a variety of suitable encoder and / or decoder circuits, such as one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), discrete logic, software, hardware, firmware, or any combination thereof. When the technology is partially implemented in software, the device can store instructions for the software in a suitable non-transitory computer-readable medium, and use one or more processors to execute the instructions in hardware to perform the technology of the present disclosure. Each of the video encoder 200 and the video decoder 300 can be included in one or more encoders or decoders, and any of the encoders or decoders can be integrated as part of a combined encoder / decoder (CODEC) in the corresponding device. The device including the video encoder 200 and / or the video decoder 300 can include an integrated circuit, a microprocessor, and / or a wireless communication device (such as a cellular phone).

[0041] The video encoder 200 and the video decoder 300 may operate according to a video coding standard such as the ITU-T H.265 (also known as the High Efficiency Video Coding (HEVC) standard) or an extension thereof such as a multi-view and / or scalable video coding extension. Alternatively, the video encoder 200 and the video decoder 300 may operate according to other proprietary or industry standards such as the Joint Exploration Test Model (JEM) or the ITU-T H.266 standard, also known as Versatile Video Coding (VVC). The latest draft of the VVC standard is described in the following document: Bross et al., "Versatile Video Coding (Draft 5)", Joint Video Experts Group (JVET) of ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11, 14th Meeting: Geneva, Switzerland, March 19-27, 2019, JVET-N1001-v9 (hereinafter referred to as "VVC Draft 5"), available at phenix.it-sudparis.eu / jvet / doc_end_user / documents / 14_Geneva / wg11 / JVET-N1001-v9.zip. Previous drafts of the VVC standard are described in the following documents: Bross et al., "Versatile Video Coding (Draft 4)", Joint Video Experts Group (JVET) of ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11, 13th Meeting: Marrakech, MA, January 19-18, 2019, JVET-M1001-v7 (hereinafter referred to as "VVC Draft 4"), available at phenix.it-sudparis.eu / jvet / doc_end_user / documents / 14_Geneva / wg11 / JVET-M1001-v7.zip. In other examples, the video encoder 200 and the video decoder 300 may operate according to one or more versions of the MPEG-5 / EVC (Essential Video Coding) standard under development. However, the techniques of the present disclosure are not limited to any particular coding standard.

[0042] Typically, the video encoder 200 and the video decoder 300 can perform block-based decoding of the picture. The term "block" generally refers to a structure that includes data to be processed (e.g., to be encoded, decoded, or otherwise used in the encoding and / or decoding process). For example, a block may include a two-dimensional matrix of samples of luminance and / or chrominance data. Typically, the video encoder 200 and the video decoder 300 can decode video data represented in a YUV (e.g., Y, Cb, Cr) format. That is, instead of decoding red, green, and blue (RGB) data for samples of a picture, the video encoder 200 and the video decoder 300 can decode luminance and chrominance components, wherein the chrominance components may include both red hue and blue hue chrominance components. In some examples, the video encoder 200 converts the received RGB formatted data to a YUV representation before encoding, and the video decoder 300 converts the YUV representation to an RGB format. Alternatively, a pre-processing and post-processing unit (not shown) may perform these conversions.

[0043] In general, the present disclosure may relate to the decoding (e.g., encoding and decoding) of a picture to include the process of encoding or decoding data for the picture. Similarly, the present disclosure may relate to the decoding of a block of a picture to include the process of encoding or decoding data for the block (e.g., prediction and / or residual decoding). The encoded video bitstream typically includes a series of values ​​for syntax elements that represent decoding decisions (e.g., decoding modes) and partitioning of the picture into blocks. Therefore, references to decoding a picture or a block should generally be understood as decoding the values ​​of the syntax elements used to form the picture or the block.

[0044] HEVC defines various blocks, including coding units (CUs), prediction units (PUs), and transform units (TUs). According to HEVC, a video decoder (coder) (such as video encoder 200) partitions a coding tree unit (CTU) into CUs according to a quadtree structure. That is, the video decoder partitions the CTU and CU into four equal, non-overlapping squares, and each node of the quadtree has zero or four child nodes. A node without child nodes may be referred to as a "leaf node", and the CU of such a leaf node may include one or more PUs and / or one or more TUs. The video decoder may further partition the PU and TU. For example, in HEVC, a residual quadtree (RQT) represents a partition of a TU. In HEVC, a PU represents inter-frame prediction data, and a TU represents residual data. An intra-predicted CU includes intra-frame prediction information, such as an intra-frame mode indication.

[0045] As another example, the video encoder 200 and the video decoder 300 may be configured to operate according to EVC, JEM, or VVC. According to EVC, JEM, or VVC, a video decoder (such as the video encoder 200) partitions a picture into a plurality of coding tree units (CTUs). The video encoder 200 may partition the CTU according to a tree structure (such as a quadtree-binary tree (QTBT) structure or a multi-type tree (MTT) structure). The QTBT structure removes the concept of multiple partition types, such as the separation between CU, PU, ​​and TU of HEVC. The QTBT structure includes two levels: a first level partitioned according to quadtree partitioning, and a second level partitioned according to binary tree partitioning. The root node of the QTBT structure corresponds to the CTU. The leaf nodes of the binary tree correspond to the coding units (CUs).

[0046] In the MTT segmentation structure, blocks can be segmented using quadtree (QT) segmentation, binary tree (BT) segmentation, and one or more types of ternary tree (TT) segmentation. A ternary tree segmentation is a segmentation in which a block is divided into three sub-blocks. In some examples, the ternary tree segmentation divides the block into three sub-blocks without dividing the original block through the center. The segmentation types in MTT (e.g., QT, BT, and TT) can be symmetric or asymmetric.

[0047] In some examples, the video encoder 200 and the video decoder 300 may use a single QTBT or MTT structure to represent each of the luma component and the chroma components, while in other examples, the video encoder 200 and the video decoder 300 may use two or more QTBT or MTT structures, such as one QTBT / MTT structure for the luma component and another QTBT / MTT structure for the two chroma components (or two QTBT / MTT structures for the respective chroma components).

[0048] The video encoder 200 and the video decoder 300 may be configured to use quadtree segmentation, QTBT segmentation, MTT segmentation, or other segmentation structures per HEVC. For purposes of explanation, a description of the techniques of the present disclosure is given with respect to QTBT segmentation. However, it should be understood that the techniques of the present disclosure may also be applied to video decoders configured to use quadtree segmentation or also use other types of segmentation.

[0049] Blocks (e.g., CTUs or CUs) may be grouped in a picture in various ways. As an example, a brick may refer to a rectangular area of ​​a CTU row within a particular slice in a picture. A slice may be a rectangular area of ​​a CTU within a particular slice column and a particular slice row in a picture. A slice column refers to a rectangular area of ​​a CTU having a height equal to the height of the picture and a width specified by a syntax element (e.g., such as in a picture parameter set). A slice row refers to a rectangular area of ​​a CTU having a height specified by a syntax element (e.g., such as in a picture parameter set) and a width equal to the width of the picture.

[0050] In some examples, a slice may be partitioned into multiple bricks, each of which may include one or more CTU rows within the slice. A slice that is not partitioned into multiple bricks may also be referred to as a brick. However, a brick that is a true subset of a slice may not be referred to as a slice.

[0051] Bricks in a picture can also be arranged in slices. A slice can be an integer number of bricks of a picture that can be exclusively contained in a single network abstraction layer (NAL) unit. In some examples, a slice includes a continuous sequence of complete bricks of multiple complete slices or only one slice.

[0052] This disclosure may use "NxN" and "N by N" interchangeably to refer to the sample size of a block (such as a CU or other video block) in terms of vertical and horizontal dimensions, for example, 16x16 samples or 16 by 16 samples. Typically, a 16x16 CU will have 16 samples in the vertical direction (y=16) and 16 samples in the horizontal direction (x=16). Similarly, an NxNCU typically has N samples in the vertical direction and N samples in the horizontal direction, where N represents a non-negative integer value. The samples in a CU may be arranged in rows and columns. In addition, a CU does not necessarily need to have the same number of samples in the horizontal direction as in the vertical direction. For example, a CU may include NxM samples, where M is not necessarily equal to N.

[0053] The video encoder 200 encodes video data representing prediction and / or residual information and other information for a CU. The prediction information indicates how the CU will be predicted in order to form a prediction block for the CU. The residual information typically represents the sample-by-sample difference between the samples of the CU before encoding and the prediction block.

[0054] In order to predict a CU, the video encoder 200 can generally form a prediction block for the CU by inter-frame prediction or intra-frame prediction. Inter-frame prediction generally refers to predicting a CU based on data of a previously decoded picture, while intra-frame prediction generally refers to predicting a CU based on previously decoded data of the same picture. In order to perform inter-frame prediction, the video encoder 200 can use one or more motion vectors to generate a prediction block. The video encoder 200 can generally perform motion search to identify a reference block that closely matches the CU, for example, in terms of the difference between the CU and the reference block. The video encoder 200 can use the sum of absolute differences (SAD), the sum of squared differences (SSD), the mean absolute difference (MAD), the mean square difference (MSD), or other such difference calculations to calculate a difference metric to determine whether the reference block closely matches the current CU. In some examples, the video encoder 200 can use unidirectional prediction or bidirectional prediction to predict the current CU.

[0055] Some examples of EVC, JEM, and VVC also provide an affine motion compensation mode, which can be considered an inter-frame prediction mode. In the affine motion compensation mode, the video encoder 200 can determine two or more motion vectors representing non-translational motion (such as zooming in or out, rotation, perspective motion, or other irregular motion types).

[0056] To perform intra prediction, the video encoder 200 may select an intra prediction mode to generate a prediction block. Some examples of EVC, JEM, and VVC provide sixty-seven intra prediction modes, including various directional modes, as well as planar modes and DC modes. Typically, the video encoder 200 selects an intra prediction mode that describes neighboring samples of a current block, based on which samples of a current block (e.g., a block of a CU) are to be predicted. Assuming that the video encoder 200 decodes CTUs and CUs in raster scan order (from left to right, from top to bottom), such samples may typically be above, above left, or to the left of the current block in the same picture as the current block.

[0057] The video encoder 200 encodes data representing a prediction mode for the current block. For example, for an inter-frame prediction mode, the video encoder 200 may encode data representing which inter-frame prediction mode of various available inter-frame prediction modes is used and motion information for the corresponding mode. For unidirectional or bidirectional inter-frame prediction, for example, the video encoder 200 may encode motion vectors using advanced motion vector prediction (AMVP) or merge mode. The video encoder 200 may use a similar mode to encode motion vectors for affine motion compensation mode.

[0058] After a prediction, such as intra prediction or inter prediction of a block, the video encoder 200 may calculate residual data for the block. The residual data, such as a residual block, represents the sample-by-sample difference between the block and a prediction block for the block, which is formed using a corresponding prediction mode. The video encoder 200 may apply one or more transforms to the residual block to produce transformed data in a transform domain rather than in a sample domain. For example, the video encoder 200 may apply a discrete cosine transform (DCT), an integer transform, a wavelet transform, or a conceptually similar transform to the residual video data. In addition, the video encoder 200 may apply a secondary transform, such as a mode-dependent non-separable secondary transform (MDNSST), a signal-dependent transform, a Karhunen-Loeve transform (KLT), etc., after the first transform. The video encoder 200 generates transform coefficients after applying one or more transforms.

[0059] As described above, after any transform to produce transform coefficients, the video encoder 200 may perform quantization of the transform coefficients. Quantization generally refers to a process in which transform coefficients are quantized to potentially reduce the amount of data used to represent the coefficients, thereby providing further compression. By performing the quantization process, the video encoder 200 may reduce the bit depth associated with some or all of the coefficients. For example, the video encoder 200 may round down an n-bit value to an m-bit value during quantization, where n is greater than m. In some examples, to perform quantization, the video encoder 200 may perform a bitwise right shift of the value to be quantized.

[0060] After quantization, the video encoder 200 can scan the transform coefficients to generate a one-dimensional vector according to a two-dimensional matrix including the quantized transform coefficients. The scan can be designed to place coefficients of higher energy (and therefore lower frequency) in front of the vector, and transform coefficients of lower energy (and therefore higher frequency) in the back of the vector. In some examples, the video encoder 200 can scan the quantized transform coefficients using a predefined scan order to generate a serialized vector, and then entropy encode the quantized transform coefficients of the vector. In other examples, the video encoder 200 can perform adaptive scanning. After scanning the quantized transform coefficients to form a one-dimensional vector, the video encoder 200 can entropy encode the one-dimensional vector, for example, according to context adaptive binary arithmetic coding (CABAC). The video encoder 200 can also entropy encode the values ​​of the syntax elements used to describe the metadata associated with the encoded video data for use by the video decoder 300 when decoding the video data.

[0061] To perform CABAC, the video encoder 200 may assign context within a context model to a symbol to be transmitted. The context may relate to, for example, whether neighboring values ​​of the symbol are zero values. The probability determination may be based on the context assigned to the symbol.

[0062] The video encoder 200 may also generate syntax data (such as block-based syntax data, picture-based syntax data, and sequence-based syntax data) to the video decoder 300, for example in a picture header, a block header, a slice header, or other syntax data (such as a sequence parameter set (SPS), a picture parameter set (PPS), or a video parameter set (VPS). Likewise, the video decoder 300 may decode such syntax data to determine how to decode the corresponding video data.

[0063] In this way, the video encoder 200 can generate a bitstream that includes encoded video data, such as a syntax element describing the partitioning of a picture into blocks (e.g., CUs) and prediction and / or residual information for the blocks. Finally, the video decoder 300 can receive the bitstream and decode the encoded video data.

[0064] In general, the video decoder 300 performs a process that is reciprocal to the process performed by the video encoder 200 to decode the encoded video data of the bitstream. For example, the video decoder 300 may use CABAC to decode the values ​​of the syntax elements for the bitstream in a manner substantially similar to the CABAC encoding process of the video encoder 200, but reciprocal. The syntax elements may define partitioning information of the picture into CTUs, and partitioning of each CTU according to a corresponding partitioning structure (such as a QTBT structure) to define CUs of the CTU. The syntax elements may also define prediction and residual information for a block (e.g., CU) of video data.

[0065] The residual information may be represented by, for example, quantized transform coefficients. The video decoder 300 may inverse quantize and inverse transform the quantized transform coefficients of the block to regenerate a residual block for the block. The video decoder 300 uses the signaled prediction mode (intra-frame prediction or inter-frame prediction) and related prediction information (e.g., motion information for inter-frame prediction) to form a prediction block for the block. The video decoder 300 may then combine the prediction block and the residual block (on a sample-by-sample basis) to regenerate the original block. The video decoder 300 may perform additional processing, such as performing a deblocking process to reduce visual artifacts along the boundaries of the blocks.

[0066] As described above, video coding standards include ITU-T H.261, ISO / IEC MPEG-1 Visual, ITU-T H.262 or ISO / IEC MPEG-2 Visual, ITU-T H.263, ISO / IEC MPEG-4 Visual and ITU-T H.264 (also known as ISO / IEC MPEG-4 AVC), including its scalable video coding (SVC) and multi-view video coding (MVC) extensions, High Efficiency Video Coding (HEVC) or ITU-T H.265, including its range extension, multi-view extension (MV-HEVC) and scalable extension (SHVC), which have been developed by the Joint Collaborative Team on Video Coding (JCT-VC) and the Joint Collaborative Team on Development of Three-Dimensional Video Coding Extensions (JCT-3V) of the ITU-T Video Coding Experts Group (VCEG) and the ISO / IEC Motion Picture Experts Group (MPEG). The draft of the HEVC standard can be obtained from itu.int / rec / T-REC-H.265-201802-I / en (hereinafter referred to as the "HEVC standard").

[0067] ITU-T VCEG (Q6 / 16) and ISO / IEC MPEG (JTC 1 / SC 29 / WG 11) have studied the potential need for standardization of future video coding techniques with compression capabilities significantly exceeding the HEVC standard, including its current extensions and near-term extensions for screen content coding and high dynamic range coding. These groups are jointly conducting this exploration activity in a collaborative effort known as the Joint Video Exploration Team (JVET) to evaluate compression technology designs proposed by their experts in this field. The first meeting of JVET was held from October 19 to 21, 2015. And the latest version of the reference software (i.e., Joint Exploration Model 7 (JEM7)) is available from jvet.hhi.fraunhofer.de / svn / svn_HMJEMSoftware / tags / HM-16.6-JEM-73.0 / .

[0068] The Joint Video Experts Group (JVET) of ITU-T WP3 / 16 and ISO / IEC JTC 1 / SC 29 / WG 11 held its eleventh meeting from 10 to 18 July 2018 at GR – Ljubljana Exhibition and Congress Centre (Dunajska cesta 18, 1000 Ljubljana, Slovenia). The name Versatile Video Coding (VVC) was chosen as an informal nickname for the new standard. The reference software VTM and BMS can be downloaded from jvet.hhi.fraunhofer.de / svn / svn_VVCSoftware_VTM / and jvet.hhi.fraunhofer.de / svn / svn_VVCSoftware_BMS / . As mentioned above, the current draft of the VVC standard is referred to herein as VVC draft 5.

[0069] The following is a review of the CU structure and motion vector prediction in HEVC. In HEVC, the largest coding unit in a slice is called a coding tree block (CTB) or coding tree unit (CTU). The CTB contains a quadtree whose nodes are coding units.

[0070] In the HEVC Main Profile, the size of a CTB can range from 16x16 to 64x64 (although 8x8 CTB size can technically be supported). The size of a coding unit (CU) can be the same as a CTB, as small as 8x8. Each coding unit is coded using a mode, such as inter-coding or intra-coding. Inter-coding can also be referred to as inter-prediction decoding or inter-prediction. Intra-coding can also be referred to as intra-prediction decoding or intra-prediction.

[0071] When a CU is inter-coded, the CU can be further partitioned into 2 or 4 prediction units (PUs), or the CU can be one PU when no further partitioning is applied. When there are two PUs in a CU, the PU can be a rectangle of half size or two rectangles of 1 / 4 or 3 / 4 of the CU size. When a CU is inter-coded, each PU has a set of motion information derived using the inter prediction mode.

[0072] The following is a review of motion vector prediction. In the HEVC standard, there are two inter-frame prediction modes for prediction units (PUs), which are called merge (skipping special cases that are considered merges) mode and advanced motion vector prediction (AMVP) mode. In AMVP or merge mode, a motion vector (MV) predictor list (also called MV candidate list) is maintained for multiple motion vector predictors. The motion vector predictor list may be called a motion vector predictor list. The motion vector of the current PU and the reference index in merge mode are generated by selecting a candidate from the motion vector predictor list. The motion vector predictor list may contain up to 5 candidates for merge mode and only two candidates for AMVP mode. The merge candidate may include a set of motion information, for example, a motion vector corresponding to both a reference picture list (list 0 and list 1) and a reference index. If a merge candidate is identified by a merge index, the reference picture used for the prediction of the current block and the associated motion vector are determined. In other words, the motion vector and reference picture identified in the motion vector predictor list by the merge index are set equal to the motion vector and reference picture of the current block.

[0073] On the other hand, in AMVP mode, for each potential prediction direction from list 0 or list 1, since the AMVP candidate contains only motion vectors, the reference index needs to be explicitly signaled together with the MV predictor (MVP) index of the motion vector predictor list. In AMVP mode, the predicted motion vector can be further refined (e.g., based on the motion vector difference (MVD) described above). Candidates for both modes are similarly derived based on the same spatial and temporal neighboring blocks.

[0074] Figure 2A and 2B is a conceptual diagram showing spatial neighbor candidates in HEVC. Although for a specific PU (PU0), according to Figure 2A and 2B The neighboring blocks shown in derive spatial MV candidates, but the method for generating candidates according to blocks is different for merge mode and AMVP mode.

[0075] In Merge mode, you can press Figure 2A Up to four spatial MV candidates are derived in the order shown by numbers in , and the order is as follows: left (0, A1), top (1, B1), top right (2, B0), bottom left (3, A0) and top left (4, B2), as shown in Figure 2A That is, in Figure 2AIn the example, block 1000 includes PU0 1040A and PU1 1040B. When the video decoder is to decode the motion information for PU0 1040A using merge mode, the video decoder adds the motion information from spatial neighboring blocks 1080A, 1080B, 1080C, 1080D, and 1080E to the candidate list in this order. As in HEVC, blocks 1080A, 1080B, 1080C, 1080D, and 1080E may also be referred to as blocks A1, B1, B0, A0, and B2, respectively.

[0076] In AVMP mode, in some examples, adjacent blocks are divided into two groups: a left group including blocks 0 and 1, and an upper group including blocks 2, 3, and 4, as shown in FIG. Figure 2B These blocks are shown in Figure 2B In FIG. 1 , the blocks 1100A, 1100B, 1100C, 1100D and 1100E are marked respectively. Specifically, Figure 2B , block 1020 includes PU0 1060A and PU1 1060B, and blocks 1100A, 1100B, 1100C, 1100D, and 1100E represent spatial neighbors of PU0 1060A. For each group, potential candidates in neighboring blocks that reference the same reference picture as the reference picture indicated by the signaled reference index have the highest priority to be selected to form the final candidate for the group. It is possible that all neighboring blocks do not contain motion vectors pointing to the same reference picture. Therefore, if such a candidate cannot be found, the first available candidate will be scaled to form the final candidate; thus, the temporal distance difference can be compensated.

[0077] Figure 3A and 3B : is a conceptual diagram showing the temporal motion vector prediction (TMVP) in HEVC. Specifically, Figure 3A An example CU 520 is shown including PU0 522A and PU 1 522B. PU0 522A includes a center block 526 for PU 522A and a lower right block 524 of PU0 522A. Figure 3A Also shown is an external block 528 whose motion information may be predicted based on the motion information of PU0 522A, as described below. Figure 3B A current picture 530 including a current block 538 whose motion information is to be predicted is shown. Specifically, Figure 3B Collocated picture 534 of current picture 530 (including collocated block 540 of current block 538), current reference picture 532, and collocated reference picture 536 are shown. Collocated block 540 is predicted using motion vector 544, which is used as a temporal motion vector predictor (TMVP) 542 for motion information of block 538.

[0078] If TMVP is enabled and TMVP candidates are available, the video coder can add the TMVP candidate (e.g., TMVP candidate 542) to the MV candidate list after any spatial motion vector candidates. The process of motion vector derivation for TMVP candidates is the same for both merge mode and AMVP mode. However, according to HEVC, the target reference index for TMVP candidates in merge mode is set to 0.

[0079] The main block position for TMVP candidate derivation is the bottom right block outside the co-located PU (such as in Figure 3A 524 is shown in the figure below the right block of PU0522A to compensate for the deviation of the upper and left blocks used to generate the spatial neighboring candidates. However, if the block 524 is outside the current CTB row or the motion information is not available for the block 524, the block is replaced with the center block 526 of the PU, as shown in FIG. Figure 3A The motion vector of the TMVP candidate 542 is derived from the co-located block 540 of the co-located picture 534, as indicated in the slice level information.

[0080] Similar to the temporal direct mode in AVC, the motion vectors of the TMVP candidates may be subject to motion vector scaling, which is performed to compensate for the picture order count (POC) distance differences between the current picture 530 and the current reference picture 532, and between the co-located picture 534 and the co-located reference picture 536. That is, the motion vector 544 may be scaled based on these POC differences to generate the TMVP candidate 542.

[0081] Motion vector prediction in merge / skip mode will now be described. For skip mode and merge mode, a merge index is signaled to indicate which candidate in the merge candidate list to use. Inter prediction indicators, reference indices, or MVD are not sent. Two types of merge candidates can be considered in merge mode: spatial motion vector predictor (SMVP) and temporal motion vector predictor (TMVP). For SMVP derivation, the MVD is located at Figure 2A Select up to four merge candidates from the candidates of the depicted positions. The order of derivation is A1 → B1 → B0 → A0 → (B2). Position B2 is considered only if any PU of position A1, B1, B0, A0 is unavailable or intra-coded, or if the total number of candidates from positions A1, B1, B0, A0 after pruning is less than four.

[0082] In the derivation of TMVP, a scaled motion vector may be derived based on a co-located PU of a reference picture in a reference picture of a current picture in a signaled reference picture list. The reference picture list used to derive the co-located PU may be explicitly signaled in a slice header (e.g., ref_pic_list_idx). The scaled motion vector of the temporal merge candidate is obtained using the scaled motion vector of the co-located PU using the POC distances tb and td, where tb is defined as the POC difference between the reference picture of the current picture and the current picture, and td is defined as the POC difference between the reference picture of the co-located picture and the co-located picture. The reference picture index of the temporal merge candidate is set to zero. The actual implementation of the scaling process is described in the HEVC specification. For B slices, two motion vectors (one for reference picture list 0 and the other for reference picture list 1) are obtained and combined to form a dual-prediction merge candidate. This process may be referred to as deriving TMVP based on implicit parameters.

[0083] Figure 4A and 4B is a conceptual diagram showing spatial and temporal neighboring motion vector candidates for merge / skip mode. Figure 4B As shown, the position of the co-located PU is selected between two candidate positions C and H. If the PU at position H is not available, or is intra-coded, or is outside the current CTU row, position C is used. Otherwise, position H is used to derive the temporal merge candidate.

[0084] In addition to SMVP and TMVP, there are two additional types of synthetic merge candidates: combined bi-predicted MVP and zero MVP. The combined bi-predicted MVP is generated using SMVP and TMVP. The combined bi-predicted merge candidate is only used for B slices. For example, two candidates in the original merge candidate list (which have mvL0 and refIdxL0 or mvL1 and refIdxL1) are used to create a combined bi-predicted merge candidate.

[0085] During the candidate selection process, duplicate candidates with the same motion parameters as the previous candidate in the processing order are removed from the candidate list. This process is defined as a pruning process. In addition, candidates inside the same merge estimation region (MER) are not considered to help parallel merge processing. In order not to simulate a virtual 2Nx2N partition, redundant partition shapes are avoided.

[0086] Between each generation step, if the number of candidates reaches MaxNumMergeCand, the derivation process is stopped. Under the current common test conditions, MaxNumMergeCand is set equal to five. Since the number of candidates is constant, the index of the best merge candidate is encoded using truncated unary binarization (TU).

[0087] Several aspects of motion prediction in HEVC are discussed below.

[0088] Motion vector scaling: It is assumed that the value of a motion vector is proportional to the distance between pictures in presentation time. A motion vector relates two pictures: a reference picture and a picture containing the motion vector (i.e., a containing picture). When video encoder 20 or video decoder 30 uses a motion vector to predict another motion vector, the distance between the containing picture and the reference picture is calculated based on a picture order count (POC) value.

[0089] For the motion vector to be predicted, its associated containing picture and reference picture are different. That is, for two different motion vectors: the first motion vector to be predicted and the second motion vector used to predict the first motion vector, there are two POC difference values. In addition, the first POC difference is the difference between the current picture and the reference picture of the first motion vector, and the second POC difference is the difference between the picture containing the second motion vector and the reference picture referenced by the second motion vector. The second motion vector can be scaled based on these two POC distances. For spatially adjacent candidates, the containing pictures of the two motion vectors are the same, but the reference pictures are different. In HEVC, motion vector scaling is applied to both TMVP and AMVP for spatially and temporally adjacent candidates.

[0090] Artificial motion vector candidate generation: If the motion vector candidate list is incomplete, artificial motion vector candidates may be generated and inserted at the end of the list until the list includes a predetermined number of candidates.

[0091] In merge mode, there are two types of artificial MV candidates: combined candidates derived only for B slices; and zero candidates used only for AMVP if the first type does not provide enough artificial candidates.

[0092] For each pair of candidates already in the candidate lists and having the necessary motion information, a bidirectional combined motion vector candidate is derived by combining the motion vector of the first candidate referencing a picture in list0 and the motion vector of the second candidate referencing a picture in list1.

[0093] In some examples, the video encoder 200 and the video decoder 300 may perform a pruning process for candidate insertion. Candidates from different blocks may happen to be the same, which reduces the efficiency of the merge / AMVP candidate list. A pruning process can be applied to solve this problem. According to the pruning process, the video decoder can compare a candidate with other candidates in the current candidate list to avoid inserting identical candidates to a certain extent. In order to reduce complexity, only a limited number of pruning processes are applied, rather than comparing each potential candidate with all other existing candidates already in the list.

[0094] Advanced temporal motion vector prediction (ATMVP) is proposed to allow each PU to obtain multiple sets of motion information (including motion vectors and reference frames). The motion information in ATMVP comes only from the reference picture. In order to derive the ATMVP of the current PU, the first step is to determine where to get the temporal motion vector. The video decoder searches for the first available motion vector in five neighboring blocks in the order of left, top, top right, bottom left, and top left. The definition of the five neighboring blocks is the same as the spatial merge candidates of the current PU. In order to avoid the repeated scanning process of adjacent blocks, the video decoder can only search for the motion vector of the first merge candidate in the already derived merge candidate list to determine where to get the temporal motion vector. The video decoder can split the PU into square NxN sub-PUs (for example, N is set to 4). The motion vector of the sub-PU is recursively derived in a raster scan order.

[0095] Figure 5 884 (e.g., PU 884). In this example, motion vector 892 identifies PU 886 of reference picture 882 relative to PU 884. PU 886 is partitioned into sub-PUs 888A-888D, each with a corresponding motion vector 890A-890D. Therefore, although current PU 884 is not actually partitioned into separate sub-PUs, in this example, motion information from sub-PUs 888A–888D can be used to predict current PU 884. Specifically, a video coder can use corresponding motion vectors 890A–890D to decode sub-PUs of current PU 884. However, the video coder does not need to decode syntax elements indicating that current PU 884 is partitioned into sub-PUs. In this manner, the current PU 884 may be efficiently predicted using multiple motion vectors 890A-890D inherited from corresponding sub-PUs 888A-888D without the signaling overhead of syntax elements for partitioning the current PU 884 into multiple sub-PUs.

[0096] Figure 6ATMVP (similar to TMVP) is a conceptual diagram showing the relevant pictures in ATMVP. Specifically, Figure 6 A current picture 904, a motion source picture 906, and reference pictures 900, 902 are shown. More specifically, the current picture 904 includes a current block 908. A temporal motion vector 912 identifies a corresponding block 910 of the motion source picture 906 relative to the current block 908. The corresponding block 910, in turn, includes a motion vector 914, which references the reference picture 902 and serves as an advanced temporal motion vector predictor for at least a portion of the current block 908 (e.g., a sub-PU of the current block 908). That is, the motion vector 914 may be added as a candidate motion vector predictor for the current block 908. If selected, the corresponding motion vector (i.e., the motion vector 916, which references the reference picture 900) may be used to predict at least a portion of the current block 908.

[0097] History-based motion vector prediction (HMVP) (e.g., as described in the following document: L. Zhang, K. Zhang, H. Liu, Y. Wang, P. Zhao, and D. Hong, "CE4-related: History-based Motion Vector Prediction", JVET-K0104, July 2018) is a history-based method in which the video encoder 200 and the video decoder 300 determine the MV predictor for each block based on a list of previously decoded MVs (except for those MVs in the directly adjacent causal neighboring motion fields). HMVP involves maintaining a table for previously decoded motion vectors as HMVP candidates.

[0098] The video encoder 200 and the video decoder 300 maintain a table with multiple HMVP candidates during the encoding / decoding process. Maintaining the table may include adding HMVP candidates to the table and removing HMVP candidates from the table. The video encoder 200 and the video decoder 300 may be configured to clear the table (e.g., remove the HMVP candidate) when encountering a new slice. Whenever there is an inter-coded block, the video encoder 200 and the video decoder 300 may be configured to insert the associated motion information into the table as a new HMVP candidate in a first-in, first-out (FIFO) manner. Then, the video encoder 200 and the video decoder 300 may be configured to apply constrained FIFO rules. When inserting an HMVP candidate into the table, the video encoder 200 and the video decoder 300 may be configured to first apply a redundancy check (e.g., pruning) to determine whether there are identical HMVP candidates in the table. If found, the video encoder 200 and the video decoder 300 may be configured to remove the specific HMVP candidate from the table and move all HMVP candidates after the candidate.

[0099] The video encoder 200 and the video decoder 300 may be configured to use HMVP candidates in the merge candidate list construction process. For example, the video encoder 200 and the video decoder 300 may be configured to insert all HMVP candidates from the last entry into the first entry after the TMVP candidate in the table. The video encoder 200 and the video decoder 300 may be configured to apply pruning to the HMVP candidates. When the total number of available merge candidates reaches the maximum allowed number of merge candidates signaled or predetermined, the video encoder 200 and the video decoder 300 may be configured to terminate the merge candidate list construction process.

[0100] Similarly, the video encoder 200 and the video decoder 300 may be configured to use HMVP candidates in the AMVP candidate list construction process. The video encoder 200 and the video decoder 300 may be configured to insert the motion vectors of the last K HMVP candidates into the table after the TMVP candidates. The video encoder 200 and the video decoder 300 may be configured to construct the AMVP candidate list using only HMVP candidates that have the same reference picture as the AMVP target reference picture. The video encoder 200 and the video decoder 300 may be configured to apply pruning to the HMVP candidates.

[0101] A non-sub-PU temporal spatial motion vector predictor (STMVP) prediction mode is proposed for the next generation video coding standard (VVC). Figure 7 is a conceptual diagram showing the derivation of a non-sub-PU temporal spatial motion vector predictor. A video decoder (e.g., video encoder 200 and / or video decoder 300) may check up to two of the positions: the upper position (PU_width-1, -1) and (PU_width x 2, -1)) and the left position (-1, PU_height-1), (-1, PU_height x2)). The video decoder may generate a non-sub-PU STMVP by averaging three candidates including two spatial candidates and one temporal candidate. If only two or one of the candidates are available, the video decoder may generate the STMVP by averaging the two available candidates, or use only one motion vector.

[0102] A simplified STMVP design is proposed in the following document: Y.-H. Chao, Y. Han, D. Rusanovskyy, W.-J. Chien, M. Karczewicz, CE4: STMVP Simplification (Test 4.2.3a), JVET-M0221 (hereinafter referred to as "JVET-M0221"), in which the number of spatial neighbors checked as input to the STMVP derivation is restricted to two, one above spatial neighbor and one left neighbor. For the above neighbor, the neighbors checked are (PU_width-1,-1) or (PU_width x 2,-1), and for the left neighbor, only (-1,PU_height-1) or (-1,PU_height x 2) are checked.

[0103] The derivation process for the STMVP output is defined as follows:

[0104] P STMVP =(MV S-Above +MV S-Left +2*MV T ) / 4

[0105] The values ​​of the multiplier and the denominator are both equal to powers of 2 and can therefore be easily implemented in hardware by bit shifting.

[0106] The values ​​of the multiplier and denominator are both equal to powers of 2 and can therefore be easily implemented in hardware by bit shifting. It is proposed to place the STMVP candidate in the fifth (5th) potential position of the merge / AMVP candidate list position, following the A0, A1, B1, B0 candidate positions (if they are available). Note that if any of the spatial candidates happens to be unavailable, the STMVP entry position index in the candidate list will be less than five (5).

[0107] An example of the merge list construction process proposed in VVC draft 4 is shown below, where the STMVP aspects are sandwiched between asterisk (*) symbols.

[0108] a. Spatial candidates for A1, B1, B0 and A0 blocks.

[0109] b. *STMVP Candidate*

[0110] c. If the number of candidates is less than 4, add B2.

[0111] d. TMVP candidate.

[0112] e. HMVP candidate.

[0113] f. Paired candidates.

[0114] g. Zero candidate.

[0115] It is also proposed to perform a pruning process on the STMVP candidates by performing redundancy checks on the STMVP output and STMVP input MVP.

[0116]

[0117] The MVP utilized in the merge mode of MPEG5 Basic Video Coding (EVC) WD1 considers the following motion vector candidates: a) 4 spatial candidates A1, B1, B0, A0 and B2; b) TMVP candidate; c) HMVP candidate; d) synthetic dual candidate; and e) zero candidate. In some examples, additional synthetic paired motion vector candidates can provide additional coding gain.

[0118] The present disclosure proposes several improvements to the TMVP design that can address the above-mentioned problems.Any of the improvements described herein can be used alone or in combination.

[0119] In general, the present disclosure may involve "signaling" certain information (such as syntax elements). The term "signaling" may generally refer to the transmission of values ​​for syntax elements and / or other data used to decode encoded video data. That is, video encoder 200 may signal values ​​for syntax elements in a bitstream. Generally, signaling refers to generating values ​​in a bitstream. As described above, source device 102 may transmit the bitstream to destination device 116 in substantially real time or not in real time (such as may occur when storing syntax elements to storage device 112 for later retrieval by destination device 116).

[0120] According to the first technique, a video coder (eg, video encoder 200 and / or video decoder 300) may derive a TMVP candidate as a scaled version of the MV of the co-located block. An example implementation of the scaling process is shown below:

[0121] The variable refPicListCol[refIdxCol] is set to the picture with reference index refIdxCol in the reference picture list listCol of the slice containing the prediction block colPb in the co-located picture specified by ColPic, and the following applies:

[0122] The POC distance (denoted as currPocDiffX) between the current picture and the reference picture list RefPicListX[refIdxLX] of the current picture with refIdxLX equal to 0 is calculated as follows: currPocDiffLX=DiffPicOrderCnt(currPic, RefPicListX[refIdxLX]) (3-300)

[0123] The POC distance between the co-located picture ColPic and the list X reference pictures of the co-located picture refPicListCol[refIdxLXCol] is denoted colPocDiffLX and is calculated as follows:

[0124] colPocDiffLX=DiffPicOrderCnt(ColPic,refPicListCol[refIdxLXCol]) (3-19)

[0125] For a valid refIdxColLX, the variable availableFlagLXCol is set equal to 1 and mvLXCol is derived as a scaled version of the motion vector mvColLX as follows:

[0126] distScaleFactorLX=currPocDiffLX<<5 / colPocDiffLX (3-2)

[0127] mvLXCol=Clip3(-32768,32767,Sign(distScaleFactorLX*mvCol)*((Abs(distScaleFactorLX*mvCol)+16)>>5)) (3-3)

[0128] where X is 0 or 1, specifying reference list 0 and reference list 1, respectively.

[0129] dptr[REFP_0]=ptr-refp[0][REFP_0].ptr;

[0130] dptr[REFP_1]=refp[0][REFP_1].ptr-ptr;

[0131] According to the second technique, a video decoder (eg, video encoder 200 and / or video decoder 300) may derive a TMVP with the following scaled parameters (colPocDiffLX, currPocDiffLX). An example implementation of the derivation is shown below:

[0132] For X equal to 0 or 1, the variables mvLXCol and availableFlagLXCol are derived as follows:

[0133] If colCb is coded in intra prediction mode, both components of mvLXCol are set equal to 0 and availableFlagLXCol is set equal to 0.

[0134] Otherwise, the motion vector mvCol, the reference index refIdxCol and the reference list identifier listCol are derived as follows:

[0135] If predFlagL0Col[x][y] is equal to 0 and predFlagL1Col[x][y] is equal to 1, then mvCol, refIdxCol, and listCol are set equal to mvLXCol[xColCb][yColCb], refIdxLXCol[xColCb][yColCb], and LX, respectively, where X is equal to 1

[0136] ○ If predFlagL0Col[x][y] is equal to 1 and predFlagL1Col[x][y] is equal to 0, then mvCol, refIdxCol, and listCol are set equal to mvLXCol[xColCb][yColCb], refIdxLXCol[xColCb][yColCb], and LX, respectively, where X is equal to 0.

[0137] ○ Otherwise (predFlagL0Col[x][y] is equal to 1 and predFlagL1Col[x][y] is equal to 1), mvCol, refIdxCol and listCol are set equal to mvLXCol[xColCb][yColCb], refIdxLXCol[xColCb][yColCb] and LX respectively.

[0138] - Derived mvLXCol and availableFlagLXCol as follows:

[0139] currPocDiffLX=DiffPicOrderCnt(currPic,RefPicListX[refIdxLX]) (3-300)

[0140] colPocDiffLX=DiffPicOrderCnt(ColPic,refPicListCol[refIdxLXCol]) (3-49)

[0141] dptr_co[REFP_0]=colPic.ptr-colPic.list_ptr[map_refi_co[neb_addr_coll][REFP_0]];

[0142] dptr_co[REFP_1]=colPic.list_ptr[map_refi_co[neb_addr_coll][REFP_1]]-colPic.ptr;

[0143]

[0144] According to the third technique, the video decoder (eg, video encoder 200 and / or video decoder 300) may utilize the following scaled parameters (colPocDiffLX, currPocDiffLX) to derive TMVP. An example implementation of the scaling process is shown below:

[0145] For X equal to 0 or 1, the variables mvLXCol and availableFlagLXCol are derived as follows:

[0146] If colCb is coded in intra prediction mode, both components of mvLXCol are set equal to 0 and availableFlagLXCol is set equal to 0.

[0147] Otherwise, the motion vector mvCol, the reference index refIdxCol and the reference list identifier listCol are derived as follows:

[0148] ■ If predFlagLXCol[x][y] is equal to 1, then mvCol, refIdxCol, and listCol are set equal to mvLXCol[xColCb][yColCb], refIdxLXCol[xColCb][yColCb], and LX, respectively, where X is equal to col_source_mvp_list_idx.

[0149] And derive mvLXCol and availableFlagLXCol as follows:

[0150] s8 refidx=map_refi_co[neb_addr_coll][collocated_mvp_source_list_idx];

[0151] dptr_co[REFP_0]=colPic.ptr-colPic.list_ptr[refidx];

[0152] In some examples of the third technique, the video decoder can generate a dual-prediction TMVP from a single-prediction MVC of an MVC. For example, the video decoder can derive the MVC and POC of the current picture and the POC dptr[REFP_0] and dptr_co[REFP_0] of the co-located picture from LIST0 of the co-located block, and use these values ​​to derive the scaled MVP. The video decoder can use the resulting scaled MVP to generate the MVP in LIST0 (mvp[REFP_0]) and LIST1 (mvp[REFP_1]) of the TMVP output by scaling the co-located motion vector (mvc) with different signs.

[0153] s16*mvc=colPic.map_mv[neb_addr_coll][collocated_mvp_source_list_idx];

[0154] int ratio_tmvp=((dptr[REFP_0])< <MVP_SCALING_PRECISION) / dptr_co[REFP_0];

[0155] scaling_mv(ratio_tmvp,mvc,mvp[REFP_0]);

[0156] ratio_tmvp=((dptr[REFP_1])< <MVP_SCALING_PRECISION) / dptr_co[REFP_0];

[0157] scaling_mv(-ratio_tmvp,mvc,mvp[REFP_1]);

[0158] mvLXCol[xColCb][yColCb]from col_source_mvp_list_idx list and assigned to two lists:

[0159] mvCol0=mvLXCol[xColCb][yColCb]from col_source_mvp_list_idx list

[0160] mvCol1=mvLXCol[xColCb][yColCb]from col_source_mvp_list_idx list

[0161] According to a fourth technique, a video decoder (e.g., video encoder 200 and / or video decoder 300) may signal (e.g., encode and decode) parameters of a TMVP derivation. As an example, a video decoder may signal parameters of a TMVP derivation. As another example, a video decoder may control a derivation stream. For example, a video decoder may switch between TMVP derivations (e.g., between any of the first, second, or third techniques described above) by an alternative method.

[0162] A sample syntax table for TMVP-derived parameters is provided below (additions are in italics):

[0163] Slice Group Header Syntax

[0164]

[0165] An example of the semantics of the syntax elements in the above syntax table is provided below.

[0166] temporal_mvp_asigned_flag specifies whether the temporal motion vector predictor derivation process will be configured with additional parameters signaled in the bitstream. When not present, the value of temporal_mvp_asigned_flag is inferred to be equal to 0.

[0167] col_pic_list_idx specifies a reference picture list used to derive a collocated picture for the purpose of temporal motion vector prediction. When col_pic_list_idx is not present and slice_type is equal to P, col_pic_list_idx is inferred to be equal to 0. When col_pic_list_idx is not present and slice_type is equal to B, col_pic_list_idx is inferred to be equal to 1.

[0168] col_pic_ref_idx specifies the reference index of the collocated picture used for temporal motion vector prediction. collocated_ref_idx refers to a picture in RefPicList[col_pic_list_idx] and the value of collocated_ref_idx shall be in the range of 0 to num_ref_idx_active_minus1[col_pic_list_idx], inclusive. When col_pic_ref_idx is not present, col_pic_ref_idx is inferred to be equal to 0.

[0169] col_source_mvp_list_idx specifies the reference picture list used to derive motion vector candidates for the purpose of temporal motion vector prediction. When col_source_mvp_list_idx is not present, col_source_mvp_list_idx is inferred to be equal to 0. tile_group_deblocking_filter_flag equal to 1 specifies that the operation of the deblocking filter applies to the current slice group. tile_group_deblocking_filter_flag equal to 0 specifies that the operation of the deblocking filter does not apply to the current slice group.

[0170] According to a fourth technique, a video decoder (e.g., video decoder 300) can derive a TMVP derivation method to use (e.g., which of the first, second, or third techniques described above). In some examples, the video decoder can employ a derivation process to select a TMVP method suitable for the current slice and parsing process of the bitstream. A non-limiting example of such a derivation process is provided below:

[0171] As a first example process for deriving which TMVP derivation method to use, the video decoder may calculate the POC distance between the current picture ptr and the target picture for the TMVP scaling in each of the reference picture lists (REFP_0 and REFP_1).

[0172] dptr[REFP_0]=ptr-refp[0][REFP_0].ptr;

[0173] dptr[REFP_1]=refp[0][REFP_1].ptr-ptr;

[0174] As a second example process for deriving which TMVP derivation method to use, the video decoder may identify whether two target pictures for MV scaling are in the same prediction direction (e.g., whether the POC of each target picture is less than the POC of the current picture):

[0175] test_result=(dptr[REFP_0]>0)&&(-dptr[REFP_1]>0);

[0176] if (test_result)

[0177] Apply TMVP Method 1 (e.g., in clause 2)

[0178] otherwise

[0179] Apply TMVP Method 2 (e.g., in clause 3)

[0180]

[0181] Alternatively, in some examples, the video decoder may check whether the two target pictures for MV scaling are in the same prediction direction (e.g., whether the POC of each target picture is less than the POC of the current picture or both POCs are greater than the POC of the current picture):

[0182] test_result=(dptr[REFP_0]>0)==(-dptr[REFP_1]>0);

[0183] if (test_result)

[0184] Apply TMVP Method 1 (e.g., in clause 2)

[0185] otherwise

[0186] Apply TMVP Method 2 (e.g., in clause 3)

[0187]

[0188] In one example, the techniques of this disclosure are implemented as follows:

[0189]

[0190] temporal_mvp_asigned_flag specifies whether the temporal motion vector predictor derivation process will be configured with additional parameters signaled in the bitstream. When not present, the value of temporal_mvp_asigned_flag is inferred to be equal to 0.

[0191] col_pic_list_idx specifies a reference picture list used to derive a collocated picture for the purpose of temporal motion vector prediction. When col_pic_list_idx is not present and slice_type is equal to P, col_pic_list_idx is inferred to be equal to 0. When col_pic_list_idx is not present and slice_type is equal to B, col_pic_list_idx is inferred to be equal to 1.

[0192] col_pic_ref_idx specifies the reference index of the collocated picture used for temporal motion vector prediction. collocated_ref_idx refers to a picture in RefPicList[col_pic_list_idx] and the value of collocated_ref_idx shall be in the range of 0 to num_ref_idx_active_minus1[col_pic_list_idx], inclusive. When col_pic_ref_idx is not present, col_pic_ref_idx is inferred to be equal to 0.

[0193] col_source_mvp_list_idx specifies the reference picture list used to derive motion vector candidates for the purpose of temporal motion vector prediction. When col_source_mvp_list_idx is not present, col_source_mvp_list_idx is inferred to be equal to 0.

[0194] Decoding process for co-located pictures without backward prediction flag

[0195] This process is called at the start of the decoding process for each P or B slice (or slice group), after decoding the slice (or slice group) header and calling the decoding process for reference picture sets specified in clause 8.3.3 and calling the decoding process for reference picture list construction for a slice (or slice group) specified in clause 8.3.2, but before decoding any coding units. The variable ColPic is set equal to RefPicList[col_pic_list_idx][col_pic_ref_idx].

[0196] Derivation process for co-located motion vectors

[0197] The inputs to this process are:

[0198] – the variable currCb, which specifies the current decoding block,

[0199] – a variable colCb, which specifies the co-located coding block within the co-located picture specified by ColPic,

[0200] - luma position (xColCb, yColCb) which specifies the top left sample of the collocated luma coding block specified by colCb relative to the top left luma sample of the collocated picture specified by ColPic,

[0201] – Reference index refIdxLX, where X is 0 or 1,

[0202] The output of this process is:

[0203] – Motion vector prediction mvLXCol, 1 / 16 fractional sample precision, where X is equal to 0 or 1

[0204] – Availability flag availableFlagCol (jointly used for list 0 and list 1).

[0205] The variable currPic specifies the current picture.

[0206] The arrays predFlagL0Col[x][y], mvL0Col[x][y], and refIdxL0Col[x][y] are set equal to PredFlagL0[x][y], MvL0[x][y], and refIdxL0Col[x][y], respectively, of the co-located picture specified by ColPic, and the arrays predFlagL1Col[x][y], mvL1Col[x][y], and refIdxL1Col[x][y] are set equal to PredFlagL1[x][y], MvL1[x][y], and RefIdxL1[x][y], respectively, of the co-located picture specified by ColPic.

[0207] For X equal to 0 or 1, the variables mvLXCol and availableFlagLXCol are derived as follows: If colCb is coded in intra prediction mode, both components of mvLXCol are set equal to 0 and availableFlagLXCol is set equal to 0.

[0208] Otherwise, the motion vector mvCol, the reference index refIdxCol and the reference list identifier listCol are derived as follows:

[0209] - If temporal_mvp_asigned_flag is equal to 0, the following applies:

[0210] - If predFlagL0Col[x][y] is equal to 0 and predFlagL1Col[x][y] is equal to 1, then mvCol, refIdxCol, and listCol are set equal to mvLXCol[xColCb][yColCb], refIdxLXCol[xColCb][yColCb], and LX, respectively, where X is equal to 1

[0211] - If predFlagL0Col[x][y] is equal to 1 and predFlagL1Col[x][y] is equal to 0, then mvCol, refIdxCol, and listCol are set equal to mvLXCol[xColCb][yColCb], refIdxLXCol[xColCb][yColCb], and LX, respectively, where X is equal to 0.

[0212] - Otherwise (predFlagL0Col[x][y] is equal to 1 and predFlagL1Col[x][y] is equal to 1), mvCol, refIdxCol and listCol are set equal to mvLXCol[xColCb][yColCb], refIdxLXCol[xColCb][yColCb] and LX respectively.

[0213] - If temporal_mvp_asigned_flag is equal to 1, the following applies:

[0214] - If predFlagLXCol[x][y] is equal to 1 with X equal to collocated_mvp_source_list_idx, then mvCol, refIdxCol, and listCol are set equal to mvLXCol[xColCb][yColCb], refIdxLXCol[xColCb][yColCb], and LX, respectively, where X is equal to col_source_mvp_list_idx.

[0215] mvLXCol and availableFlagLXCol are derived as follows:

[0216] The variable refPicListCol[refIdxCol] is set to the picture with reference index refIdxCol in the reference picture list listCol of the slice containing the prediction block colPb in the co-located picture specified by ColPic, and the following applies:

[0217] – The POC distance (denoted as currPocDiffX) between the current picture and the reference picture list RefPicListX[refIdxLX] of the current picture with refIdxLX equal to 0 is calculated as follows:

[0218] currPocDiffLX=DiffPicOrderCnt(currPic,RefPicListX[refIdxLX]) (8-300)

[0219] – The POC distance (denoted as colPocDiffLX) between the co-located picture ColPic and the list X reference pictures of the co-located picture refPicListCol[refIdxLXCol] is calculated as follows:

[0220] colPocDiffLX=DiffPicOrderCnt(ColPic,refPicListCol[refIdxLXCol]) (8-299)

[0221] – For a valid refIdxCol and colPocDiffLX not equal to 0, the variable availableFlagLXCol is set equal to 1 and mvLXCol is derived as a scaled version of the motion vector mvColLX as follows:

[0222] distScaleFactorLX=currPocDiffLX<<5 / colPocDiffLX (8-294)

[0223] mvLXCol = Clip3 (-32768, 32767, Sign (distScaleFactorLX * mvCol) * ((Abs (distScaleFactorLX * mvCol) + 16) >> 5)) (8-296) - Otherwise (invalid refIdxCol or colPocDiffLX is equal to 0), the variable availableFlagLXCol is set equal to 0, and

[0224] mvLXCol=0 (8-297)

[0225] where X is 0 or 1, specifying reference list 0 and reference list 1, respectively.

[0226] The picture boundary based clipping process is called for a variable of the co-located motion vector mvLXCol as specified in clause 8.5.2.21 with mvLXCol, (xCb, yCb), pic_width_in_luma_samples and pic_height_in_luma_samples as input parameters.

[0227] AvailableFlagCol is derived as follows:

[0228] – If availableFlagLXCol is valid for both X being 0 and 1, availableFlagCol is set to 3,

[0229] – Otherwise, if availableFlagLXCol is valid for X equal to 0 and availableFlagLXCol is invalid for X equal to 1, then availableFlagCol is set to 1,

[0230] – Otherwise, if availableFlagLXCol is valid for X equal to 1 and availableFlagLXCol is invalid for X equal to 0, then availableFlagCol is set to 2,

[0231] – Otherwise, availableFlagCol is set to 0.

[0232] Note that references to slice groups may be considered as references to VVC Draft 4, while references to slices may be considered as references to VVC Draft 5. Thus, in some examples, data included in a slice group header may be included in a slice header or any similarly partitioned header.

[0233] According to the techniques of the present disclosure, a video coder (e.g., video encoder 200 and / or video decoder 300) may derive a temporal motion vector prediction (TMVP) candidate for a current block of a current picture of video data; generate a list of motion vector candidates for the current block, the list including the derived TMVP candidate; and predict the current block based on the list of motion vector candidates.

[0234] Fig. 8A and 8B 1 is a conceptual diagram showing an example quadtree binary tree (QTBT) structure 130 and a corresponding coding tree unit (CTU) 132. Solid lines represent quadtree splits, and dashed lines indicate binary tree splits. In each split (i.e., non-leaf) node of the binary tree, a flag is signaled to indicate which split type (i.e., horizontal or vertical) is used, where, in this example, 0 indicates horizontal splitting, and 1 indicates vertical splitting. For quadtree splitting, since the quadtree node splits the block horizontally and vertically into 4 sub-blocks of equal size, there is no need to indicate the split type. Accordingly, the video encoder 200 can encode the following, and the video decoder 300 can decode the following: syntax elements (such as split information) for the regional tree level (i.e., solid line) of the QTBT structure 130, and syntax elements (such as split information) for the prediction tree level (i.e., dashed line) of the QTBT structure 130. The video encoder 200 may encode video data (such as prediction and transform data) for a CU represented by a terminal leaf node of the QTBT structure 130 , and the video decoder 300 may decode the video data.

[0235] generally, Figure 8B The CTU 132 may be associated with parameters defining the size of blocks corresponding to nodes at the first and second levels of the QTBT structure 130. These parameters may include a CTU size (indicating the size of the CTU 132 in samples), a minimum quadtree size (MinQTSize, which indicates the minimum allowed quadtree leaf node size), a maximum binary tree size (MaxBTSize, which indicates the maximum allowed binary tree root node size), a maximum binary tree depth (MaxBTDepth, which indicates the maximum allowed binary tree depth), and a minimum binary tree size (MinBTSize, which indicates the minimum allowed binary tree leaf node size).

[0236] The root node of the QTBT structure corresponding to the CTU may have four child nodes at the first level of the QTBT structure, each of which may be segmented according to a quadtree segmentation. That is, the node of the first level is a leaf node (without child nodes) or has four child nodes. The example of the QTBT structure 130 represents such a node as including a parent node and a child node with a solid line branch. If the node of the first level is not larger than the maximum allowed binary tree root node size (MaxBTSize), the node may be further segmented by the corresponding binary tree. The binary tree splitting of a node may be iterated until the node generated from the split reaches the minimum allowed binary tree leaf node size (MinBTSize) or the maximum allowed binary tree depth (MaxBTDepth). The example of the QTBT structure 130 represents such a node as having a dotted line branch. The binary tree leaf node is called a coding unit (CU), which is used for prediction (e.g., intra-picture or inter-picture prediction) and transformation without any further segmentation. As discussed above, a CU may also be referred to as a "video block" or "block".

[0237] In one example of a QTBT partitioning structure, the CTU size is set to 128x128 (luminance sample and two corresponding 64x64 chrominance samples), MinQTSize is set to 16x16, MaxBTSize is set to 64x64, MinBTSize (for both width and height) is set to 4, and MaxBTDepth is set to 4. Quadtree partitioning is first applied to the CTU to generate a quadtree leaf node. The quadtree leaf node can have a size from 16x16 (i.e., MinQTSize) to 128x128 (i.e., CTU size). If the leaf quadtree node is 128x128, the leaf quadtree node will not be further split by the binary tree because the size exceeds MaxBTSize (i.e., 64x64 in this example). Otherwise, the leaf quadtree node will be further split by the binary tree. Therefore, the quadtree leaf node is also the root node for the binary tree and has a binary tree depth of 0. When the binary tree depth reaches MaxBTDepth (4 in this example), no further splitting is allowed. When a binary tree node has a width equal to MinBTSize (4 in this example), it means that no further horizontal splitting is allowed. Similarly, a binary tree node with a height equal to MinBTSize means that no further vertical splitting is allowed for the binary tree node. As described above, the leaf nodes of the binary tree are called CUs and are further processed according to prediction and transformation without further segmentation.

[0238] Fig. 9 is a block diagram illustrating an example video encoder 200 that may perform the techniques of this disclosure. Fig. 9 The present disclosure is provided for purposes of explanation and should not be considered limiting of the techniques broadly exemplified and described in this disclosure. For purposes of explanation, this disclosure describes the video encoder 200 in the context of video coding standards such as the HEVC video coding standard and the EVC and VVC video coding standards being developed. However, the techniques of this disclosure are not limited to these video coding standards and are generally applicable to video encoding and decoding.

[0239] exist Fig. 9In the example of , the video encoder 200 includes a video data memory 230, a mode selection unit 202, a residual generation unit 204, a transform processing unit 206, a quantization unit 208, an inverse quantization unit 210, an inverse transform processing unit 212, a reconstruction unit 214, a filter unit 216, a decoded picture buffer (DPB) 218, and an entropy coding unit 220. Any one or all of the video data memory 230, the mode selection unit 202, the residual generation unit 204, the transform processing unit 206, the quantization unit 208, the inverse quantization unit 210, the inverse transform processing unit 212, the reconstruction unit 214, the filter unit 216, the DPB 218, and the entropy coding unit 220 may be implemented in one or more processors or in processing circuits. In addition, the video encoder 200 may include additional or alternative processors or processing circuits to perform these and other functions.

[0240] The video data memory 230 may store video data to be encoded by the components of the video encoder 200. The video encoder 200 may receive video data from, for example, the video source 104 ( Figure 1 ) receives video data stored in the video data memory 230. The DPB 218 may act as a reference picture memory that stores reference video data for use in predicting subsequent video data by the video encoder 200.

[0241] Video data memory 230 and DPB 218 can be formed by any one of a variety of memory devices, such as dynamic random access memory (DRAM) (including synchronous DRAM (SDRAM)), magnetoresistive RAM (MRAM), resistive RAM (RRAM), or other types of memory devices. Video data memory 230 and DPB 218 can be provided by the same memory device or separate memory devices. In various examples, video data memory 230 can be on chip with other components of video encoder 200 (as shown), or off chip relative to those components.

[0242] In the present disclosure, references to the video data memory 230 should not be interpreted as limited to memory internal to the video encoder 200 (unless specifically described as such) or memory external to the video encoder 200 (unless specifically described as such). Rather, references to the video data memory 230 should be understood as a reference memory that stores video data received by the video encoder 200 for encoding (e.g., video data for a current block to be encoded). Figure 1 The memory 106 may also provide temporary storage for outputs from the various units of the video encoder 200 .

[0243] Shows Fig. 9The various units of the video encoder 200 are provided to help understand the operations performed by the video encoder 200. The unit may be implemented as a fixed-function circuit, a programmable circuit, or a combination thereof. A fixed-function circuit refers to a circuit that provides a specific function and is pre-set with respect to the operations that can be performed. A programmable circuit refers to a circuit that can be programmed to perform various tasks and provide flexible functions with the operations that can be performed. For example, a programmable circuit can execute software or firmware that causes the programmable circuit to operate in a manner defined by the instructions of the software or firmware. A fixed-function circuit can execute software instructions (e.g., to receive parameters or output parameters), but the type of operation performed by the fixed-function circuit is generally immutable. In some examples, one or more of the units in the unit may be different circuit blocks (fixed-function or programmable), and in some examples, one or more units may be integrated circuits.

[0244] The video encoder 200 may include an arithmetic logic unit (ALU), an elementary function unit (EFU), a digital circuit, an analog circuit, and / or a programmable core formed from programmable circuits. In an example where the operation of the video encoder 200 is performed using software executed by a programmable circuit, the memory 106 ( Figure 1 ) may store object code for software that the video encoder 200 receives and executes, or another memory (not shown) within the video encoder 200 may store such instructions.

[0245] The video data memory 230 is configured to store the received video data. The video encoder 200 may retrieve pictures of the video data from the video data memory 230 and provide the video data to the residual generation unit 204 and the mode selection unit 202. The video data in the video data memory 230 may be original video data to be encoded.

[0246] The mode selection unit 202 includes a motion estimation unit 222, a motion compensation unit 224, and an intra prediction unit 226. The mode selection unit 202 may include additional functional units that perform video prediction according to other prediction modes. As an example, the mode selection unit 202 may include a palette unit, an intra-block copy unit (which may be part of the motion estimation unit 222 and / or the motion compensation unit 224), an affine unit, a linear model (LM) unit, etc.

[0247] The mode selection unit 202 typically coordinates multiple encoding passes to test combinations of encoding parameters and the resulting rate-distortion values ​​for such combinations. The encoding parameters may include partitioning of a CTU into CUs, a prediction mode for a CU, a transform type for residual data of a CU, a quantization parameter for residual data of a CU, etc. The mode selection unit 202 may ultimately select a combination of encoding parameters that has a better rate-distortion value than other tested combinations.

[0248] The video encoder 200 may partition the picture retrieved from the video data memory 230 into a series of CTUs, and encapsulate one or more CTUs in a slice. The mode selection unit 202 may partition the CTUs of the picture according to a tree structure (such as the QTBT structure or quadtree structure of HEVC described above). As described above, the video encoder 200 may form one or more CUs by partitioning the CTUs according to the tree structure. Such CUs may also be generally referred to as "video blocks" or "blocks".

[0249] Typically, the mode selection unit 202 also controls its components (e.g., the motion estimation unit 222, the motion compensation unit 224, and the intra prediction unit 226) to generate a prediction block for the current block (e.g., the current CU, or the overlapping portion of the PU and TU in HEVC). In order to inter-predict the current block, the motion estimation unit 222 may perform a motion search to identify one or more closely matching reference blocks in one or more reference pictures (e.g., one or more previously decoded pictures stored in the DPB 218). Specifically, the motion estimation unit 222 may calculate a value representing the degree of similarity of the potential reference block to the current block, for example, based on the sum of absolute differences (SAD), the sum of squared differences (SSD), the mean absolute difference (MAD), the mean squared difference (MSD), etc. The motion estimation unit 222 may typically perform these calculations using the sample-by-sample difference between the current block and the reference block under consideration. The motion estimation unit 222 may identify the reference block with the lowest value obtained from these calculations, which indicates the reference block that most closely matches the current block.

[0250] The motion estimation unit 222 may form one or more motion vectors (MVs) that define the position of the reference block in the reference picture relative to the position of the current block in the current picture. The motion estimation unit 222 may then provide the motion vectors to the motion compensation unit 224. For example, for unidirectional inter prediction, the motion estimation unit 222 may provide a single motion vector, while for bidirectional inter prediction, the motion estimation unit 222 may provide two motion vectors. The motion compensation unit 224 may then use the motion vectors to generate a prediction block. For example, the motion compensation unit 224 may use the motion vectors to retrieve data for the reference block. As another example, if the motion vectors have fractional sample precision, the motion compensation unit 224 may interpolate the values ​​for the prediction block according to one or more interpolation filters. In addition, for bidirectional inter prediction, the motion compensation unit 224 may retrieve data for two reference blocks identified by corresponding motion vectors and combine the retrieved data, for example, by sample-by-sample averaging or weighted averaging.

[0251] As another example, for intra prediction or intra prediction decoding, the intra prediction unit 226 can generate a prediction block based on samples adjacent to the current block. For example, for directional mode, the intra prediction unit 226 can generally mathematically combine the values ​​of adjacent samples and fill these calculated values ​​across the current block in a defined direction to produce a prediction block. As another example, for DC mode, the intra prediction unit 226 can calculate the average of adjacent samples of the current block and generate a prediction block to include the resulting average for each sample of the prediction block.

[0252] The mode selection unit 202 provides the prediction block to the residual generation unit 204. The residual generation unit 204 receives the original uncoded version of the current block from the video data memory 230 and the prediction block from the mode selection unit 202. The residual generation unit 204 calculates the sample-by-sample difference between the current block and the prediction block. The resulting sample-by-sample difference defines a residual block for the current block. In some examples, the residual generation unit 204 may also determine the difference between the sample values ​​in the residual block to generate the residual block using residual differential pulse code modulation (RDPCM). In some examples, the residual generation unit 204 may be formed using one or more subtractor circuits that perform binary subtraction.

[0253] In an example where the mode selection unit 202 partitions the CU into PUs, each PU may be associated with a luma prediction unit and a corresponding chroma prediction unit. The video encoder 200 and the video decoder 300 may support PUs of various sizes. As noted above, the size of a CU may refer to the size of a luma coding block of the CU, and the size of a PU may refer to the size of a luma prediction unit of the PU. Assuming that the size of a particular CU is 2Nx2N, the video encoder 200 may support PU sizes of 2Nx2N or NxN for intra-prediction, and 2Nx2N, 2NxN, Nx2N, NxN, or similar symmetrical PU sizes for inter-prediction. The video encoder 200 and the video decoder 300 may also support asymmetric partitioning for PU sizes of 2NxnU, 2NxnD, nLx2N, and nRx2N for inter-prediction.

[0254] In an example where the mode selection unit does not further split the CU into PUs, each CU may be associated with a luma coding block and a corresponding chroma coding block. As described above, the size of a CU may refer to the size of the luma coding block of the CU. The video encoder 200 and the video decoder 300 may support a CU size of 2Nx2N, 2NxN, or Nx2N.

[0255] For other video coding techniques (such as intra-block copy mode coding, affine mode coding, and linear model (LM) mode coding, to name a few examples), the mode selection unit 202 generates a prediction block for the current block being encoded via a corresponding unit associated with the coding technique. In some examples (such as palette mode coding), the mode selection unit 202 may not generate a prediction block, but instead generate syntax elements indicating how to reconstruct the block based on the selected palette. In such a mode, the mode selection unit 202 may provide these syntax elements to the entropy coding unit 220 for encoding.

[0256] As described above, the residual generation unit 204 receives video data for a current block and a corresponding prediction block. The residual generation unit 204 then generates a residual block for the current block. To generate the residual block, the residual generation unit 204 calculates the sample-by-sample difference between the prediction block and the current block.

[0257] The transform processing unit 206 applies one or more transforms to the residual block to generate a block of transform coefficients (referred to herein as a "transform coefficient block"). The transform processing unit 206 can apply various transforms to the residual block to form a transform coefficient block. For example, the transform processing unit 206 can apply a discrete cosine transform (DCT), a directional transform, a Karhunen-Loeve transform (KLT), or a conceptually similar transform to the residual block. In some examples, the transform processing unit 206 can perform multiple transforms on the residual block, for example, a primary transform and a secondary transform (such as a rotation transform). In some examples, the transform processing unit 206 does not apply a transform to the residual block.

[0258] The quantization unit 208 may quantize the transform coefficients in the transform coefficient block to produce a quantized transform coefficient block. The quantization unit 208 may quantize the transform coefficients of the transform coefficient block according to a quantization parameter (QP) value associated with the current block. The video encoder 200 (e.g., via the mode selection unit 202) may adjust the degree of quantization applied to the transform coefficient block associated with the current block by adjusting the QP value associated with the CU. Quantization may cause a loss of information, and therefore, the quantized transform coefficients may have a lower precision than the original transform coefficients produced by the transform processing unit 206.

[0259] The inverse quantization unit 210 and the inverse transform processing unit 212 may apply inverse quantization and inverse transform, respectively, to the quantized transform coefficient block to reconstruct a residual block from the transform coefficient block. The reconstruction unit 214 may generate a reconstructed block corresponding to the current block (although potentially with some degree of distortion) based on the reconstructed residual block and the prediction block generated by the mode selection unit 202. For example, the reconstruction unit 214 may add samples of the reconstructed residual block to corresponding samples of the prediction block generated by the mode selection unit 202 to generate a reconstructed block.

[0260] Filter unit 216 may perform one or more filter operations on the reconstructed blocks. For example, filter unit 216 may perform a deblocking operation to reduce blocking artifacts along the edges of the CU. In some examples, the operations of filter unit 216 may be skipped.

[0261] The video encoder 200 stores the reconstructed blocks in the DPB 218. For example, in an example where the operation of the filter unit 216 is not required, the reconstruction unit 214 can store the reconstructed blocks in the DPB 218. In an example where the operation of the filter unit 216 is required, the filter unit 216 can store the filtered reconstructed blocks in the DPB 218. The motion estimation unit 222 and the motion compensation unit 224 can retrieve the reference picture formed according to the reconstructed (and potentially filtered) blocks from the DPB 218 to perform inter-frame prediction on the blocks of the subsequently encoded pictures. In addition, the intra-frame prediction unit 226 can use the reconstructed blocks of the current picture in the DPB 218 to perform intra-frame prediction on other blocks in the current picture.

[0262] In general, the entropy coding unit 220 may entropy encode syntax elements received from other functional components of the video encoder 200. For example, the entropy coding unit 220 may entropy encode the quantized transform coefficient blocks from the quantization unit 208. As another example, the entropy coding unit 220 may entropy encode the prediction syntax elements (e.g., motion information for inter-frame prediction or intra-frame mode information for intra-frame prediction) from the mode selection unit 202. The entropy coding unit 220 may perform one or more entropy coding operations on syntax elements as another example of video data to generate entropy-encoded data. For example, the entropy coding unit 220 may perform a context-adaptive variable length coding (CAVLC) operation, a CABAC operation, a variable-variable (V2V) length coding operation, a syntax-based context-adaptive binary arithmetic coding (SBAC) operation, a probability interval partitioning entropy (PIPE) coding operation, an exponential Golomb coding operation, or another type of entropy coding operation on the data. In some examples, the entropy coding unit 220 may operate in a bypass mode in which the syntax elements are not entropy encoded.

[0263] The video encoder 200 may output a bitstream including entropy-encoded syntax elements required for reconstructing a block of a slice or picture. Specifically, the entropy encoding unit 220 may output a bitstream.

[0264] The above operations are described with respect to blocks. Such descriptions should be understood as operations for luma coding blocks and / or chroma coding blocks. As described above, in some examples, the luma coding blocks and chroma coding blocks are the luma components and chroma components of a CU. In some examples, the luma coding blocks and chroma coding blocks are the luma components and chroma components of a PU.

[0265] In some examples, operations performed with respect to luma coding blocks need not be repeated for chroma coding blocks. As an example, operations for identifying motion vectors (MVs) and reference pictures for luma coding blocks need not be repeated to identify MVs and reference pictures for chroma blocks. Instead, the MVs for luma coding blocks may be scaled to determine MVs for chroma blocks, and the reference pictures may be the same. As another example, the intra prediction process may be the same for luma coding blocks and chroma coding blocks.

[0266] As described above, a video decoder (such as video encoder 200 or video decoder 300) can generate a motion vector candidate list, where in some examples, at least one candidate in the list is a temporal motion vector predictor (TMVP) candidate. In some examples, the video decoder can use the inferred parameters to determine the TMVP candidate, so that the video decoder derives the TMVP candidate from the co-located PU in the co-located picture. For example, to determine the TMVP candidate using the inferred parameters, the video encoder can use the above reference to Figure 3A and 3B The described techniques determine TMVP candidates. However, in some examples, the TMVP candidate derived using the inferred parameters may not be the best TMVP candidate. For example, other motion vectors from other pictures may identify reference blocks using samples that more closely match samples of the current block. Enabling the reference block to have samples that more closely match samples of the current block may improve coding efficiency by reducing the size of the residual data.

[0267] According to one or more techniques of the present disclosure, the derivation of TMVP candidates can be made more flexible. For example, instead of inferring parameters (TMVP parameters) for controlling the derivation of TMVP candidates, a video decoder can explicitly signal parameters for controlling the derivation of TMVP candidates. Some example parameters that can be signaled include a reference picture list for the derivation of co-located pictures for deriving TMVP candidates, a reference index of co-located pictures, and a reference picture list for the derivation of motion vector candidates for deriving TMVP candidates. By explicitly signaling parameters, a video encoder may be able to select a TMVP candidate that identifies a reference block with samples that more closely match the samples of the current block. For example, a video decoder may select a reference picture list for the derivation of co-located pictures for deriving TMVP candidates, or any other parameters different from the reference picture list to be used with the inferred parameters. The reduction in the size of the residual data generated may be greater than the data used to signal the TMVP parameters. In this way, the techniques of the present disclosure can improve decoding efficiency (e.g., by reducing the amount of data used to encode video data).

[0268] In some examples, the video encoder 200 may signal parameters by signaling a plurality of syntax elements, each syntax element specifying one or more parameters of the TMVP candidate derivation process. For example, the mode selection unit 202 may cause the entropy encoding unit 220 to encode a plurality of syntax elements in a decoded video bitstream. The plurality of syntax elements specifying one or more parameters of the TMVP candidate derivation process may include one or more of the following: a syntax element (col_pic_list_idx) specifying a reference picture list for derivation of a co-located picture for deriving the TMVP candidate; a syntax element (col_pic_ref_idx) specifying a reference index of a co-located picture; and / or a syntax element (col_source_mvp_list_idx) specifying a reference picture list for derivation of a motion vector candidate for deriving the TMVP candidate.

[0269] In some examples, the video encoder 200 may selectively signal TMVP parameters (e.g., selectively signal multiple syntax elements, each syntax element specifying one or more parameters of the TMVP candidate derivation process). For example, as opposed to always inferring TMVP parameters or always explicitly signaling TMVP parameters, the video decoder may signal a syntax element (e.g., temporal_mvp_asigned_flag) indicating whether TMVP parameters are explicitly signaled. In the case where the syntax element indicates that the TMVP parameters are explicitly signaled, the video decoder may decode multiple syntax elements that specify the TMVP parameters. Otherwise (e.g., in the case where the syntax element does not indicate that the TMVP parameters are explicitly signaled), the video decoder may infer the TMVP parameters (e.g., determine the TMVP parameters without explicit signaling). In some examples, where the amount of data for explicitly signaling the TMVP parameters would be greater than the amount of data saved by using TMVP candidates other than TMVP candidates derived based on the inferred TMVP parameters, the mode selection unit 202 of the video encoder 200 may select to infer and cause the decoder to infer the TMVP parameters. In this way, the techniques of this disclosure may improve coding efficiency (e.g., by reducing the amount of data used to encode video data).

[0270] The following syntax and semantics are one example of how the video encoder 200 signals multiple syntax elements in a decoded video bitstream. In the following example, the multiple syntax elements are signaled in the slice group header syntax. However, in other examples, the multiple syntax elements may be signaled in other syntax structures such as a slice header, a picture header, a coding unit, or any other syntax structure.

[0271] Slice Group Header Syntax

[0272]

[0273] temporal_mvp_asigned_flag specifies whether the temporal motion vector predictor derivation process will be configured with additional parameters signaled in the bitstream. When not present, the value of temporal_mvp_asigned_flag is inferred to be equal to 0.

[0274] col_pic_list_idx specifies a reference picture list used to derive a collocated picture for the purpose of temporal motion vector prediction. When col_pic_list_idx is not present and slice_type is equal to P, col_pic_list_idx is inferred to be equal to 0. When col_pic_list_idx is not present and slice_type is equal to B, col_pic_list_idx is inferred to be equal to 1.

[0275] col_pic_ref_idx specifies the reference index of the collocated picture used for temporal motion vector prediction. collocated_ref_idx refers to a picture in RefPicList[col_pic_list_idx] and the value of collocated_ref_idx shall be in the range of 0 to num_ref_idx_active_minus1[col_pic_list_idx], inclusive. When col_pic_ref_idx is not present, col_pic_ref_idx is inferred to be equal to 0.

[0276] col_source_mvp_list_idx specifies the reference picture list used to derive motion vector candidates for the purpose of temporal motion vector prediction. When col_source_mvp_list_idx is not present, col_source_mvp_list_idx is inferred to be equal to 0.

[0277] The video encoder 200 represents an example of a device configured to encode video data, the device comprising: a memory configured to store the video data; and one or more processing units implemented in circuits and configured to: encode a syntax element via a decoded video bitstream, the syntax element specifying whether the decoded video bitstream includes multiple syntax elements that specify parameters for a temporal motion vector prediction (TMVP) candidate derivation process; where the syntax element specifies that the decoded video bitstream includes multiple syntax elements: encode the multiple syntax elements via the decoded video bitstream; and derive, by a video decoder and based on the parameters specified by the multiple syntax elements, a TMVP candidate for a current block of a current picture of the video data; generate a list of motion vector candidates for the current block, the list including the derived TMVP candidate; and predict the current block based on the list of motion vector candidates.

[0278] Fig.10 is a block diagram illustrating an example video decoder 300 that may perform the techniques of this disclosure. Fig.10 It is provided for the purpose of explanation and does not limit the techniques extensively illustrated and described in this disclosure. For the purpose of explanation, this disclosure describes the video decoder 300 according to the techniques of EVC, JEM, VVC and HEVC. However, the techniques of this disclosure can be performed by video decoding devices configured for other video decoding standards.

[0279] exist Fig.10 In the example of , the video decoder 300 includes a coded picture buffer (CPB) memory 320, an entropy decoding unit 302, a prediction processing unit 304, an inverse quantization unit 306, an inverse transform processing unit 308, a reconstruction unit 310, a filter unit 312, and a decoded picture buffer (DPB) 314. Any one or all of the CPB memory 320, the entropy decoding unit 302, the prediction processing unit 304, the inverse quantization unit 306, the inverse transform processing unit 308, the reconstruction unit 310, the filter unit 312, and the DPB 314 may be implemented in one or more processors or in processing circuits. In addition, the video decoder 300 may include additional or alternative processors or processing circuits to perform these and other functions.

[0280] The prediction processing unit 304 includes a motion compensation unit 316 and an intra prediction unit 318. The prediction processing unit 304 may include additional units that perform predictions according to other prediction modes. As an example, the prediction processing unit 304 may include a palette unit, an intra-block copy unit (which may form part of the motion compensation unit 316), an affine unit, a linear model (LM) unit, etc. In other examples, the video decoder 300 may include more, fewer, or different functional components.

[0281] CPB memory 320 may store video data, such as an encoded video bitstream, to be decoded by components of video decoder 300. For example, the video bitstream may be obtained from computer readable medium 110 ( Figure 1 ) obtains video data stored in CPB memory 320. CPB memory 320 may include a CPB that stores encoded video data (e.g., syntax elements) from an encoded video bitstream. In addition, CPB memory 320 may store video data other than syntax elements of decoded pictures, such as temporary data representing outputs from various units of video decoder 300. DPB314 typically stores decoded pictures, and video decoder 300 may output decoded pictures, and / or use decoded pictures as reference video data when decoding subsequent data or pictures of the encoded video bitstream. CPB memory 320 and DPB 314 may be formed by any of a variety of memory devices, such as DRAM, including SDRAM, MRAM, RRAM or other types of memory devices. CPB memory 320 and DPB 314 may be provided by the same memory device or separate memory devices. In various examples, CPB memory 320 may be on-chip with other components of video decoder 300, or off-chip relative to those components.

[0282] Additionally or alternatively, in some examples, video decoder 300 may retrieve the video from memory 120 ( Figure 1 ) to retrieve the decoded video data. That is, memory 120 may utilize CPB memory 320 to store data as discussed above. Likewise, when some or all of the functions of video decoder 300 are implemented in software to be executed by processing circuitry of video decoder 300, memory 120 may store instructions to be executed by video decoder 300.

[0283] Shows Fig.10 The various units shown in FIG. 3 are shown to help understand the operations performed by the video decoder 300. The units may be implemented as fixed function circuits, programmable circuits, or a combination thereof. Fig. 9, fixed-function circuits refer to circuits that provide specific functions and are pre-set with respect to the operations that can be performed. Programmable circuits refer to circuits that can be programmed to perform various tasks and provide flexible functions with respect to the operations that can be performed. For example, a programmable circuit can execute software or firmware that causes the programmable circuit to operate in a manner defined by the instructions of the software or firmware. Fixed-function circuits can execute software instructions (e.g., to receive parameters or output parameters), but the types of operations performed by fixed-function circuits are generally immutable. In some examples, one or more of the units may be different circuit blocks (fixed-function or programmable), and in some examples, one or more units may be integrated circuits.

[0284] The video decoder 300 may include an ALU, an EFU, a digital circuit, an analog circuit, and / or a programmable core formed from programmable circuits. In examples where the operation of the video decoder 300 is performed by software executed on the programmable circuits, an on-chip or off-chip memory may store instructions (e.g., object code) of the software that the video decoder 300 receives and executes.

[0285] The entropy decoding unit 302 may receive the encoded video data from the CPB and entropy decode the video data to regenerate the syntax elements. The prediction processing unit 304, the inverse quantization unit 306, the inverse transform processing unit 308, the reconstruction unit 310, and the filter unit 312 may generate decoded video data based on the syntax elements extracted from the bitstream.

[0286] Typically, the video decoder 300 reconstructs a picture on a block-by-block basis. The video decoder 300 may perform a reconstruction operation on each block individually (wherein a block currently being reconstructed (ie, decoded) may be referred to as a "current block").

[0287] The entropy decoding unit 302 may entropy decode syntax elements defining the quantized transform coefficients of the quantized transform coefficient block and transform information such as a quantization parameter (QP) and / or a transform mode indication. The inverse quantization unit 306 may use the QP associated with the quantized transform coefficient block to determine a degree of quantization and, likewise, a degree of inverse quantization to be applied by the inverse quantization unit 306. The inverse quantization unit 306 may, for example, perform a bitwise left shift operation to inverse quantize the quantized transform coefficients. The inverse quantization unit 306 may thereby form a transform coefficient block including the transform coefficients.

[0288] After the inverse quantization unit 306 forms the transform coefficient block, the inverse transform processing unit 308 may apply one or more inverse transforms to the transform coefficient block to generate a residual block associated with the current block. For example, the inverse transform processing unit 308 may apply an inverse DCT, an inverse integer transform, an inverse Karhunen-Loeve transform (KLT), an inverse rotational transform, an inverse directional transform, or another inverse transform to the coefficient block.

[0289] In addition, prediction processing unit 304 generates a prediction block based on the prediction information syntax elements entropy decoded by entropy decoding unit 302. For example, if the prediction information syntax elements indicate that the current block is inter-predicted, motion compensation unit 316 can generate a prediction block. In this case, the prediction information syntax elements can indicate a reference picture in DPB 314 from which to retrieve the reference block, and a motion vector that identifies the position of the reference block in the reference picture relative to the position of the current block in the current picture. Motion compensation unit 316 can generally generate a prediction block in the same manner as described for motion compensation unit 224 ( Fig. 9 )The inter-frame prediction process is performed in a manner substantially similar to that described in detail above.

[0290] As another example, if the prediction information syntax element indicates that the current block is intra-predicted, the intra-prediction unit 318 may generate a prediction block according to the intra-prediction mode indicated by the prediction information syntax element. Again, the intra-prediction unit 318 may generally generate a prediction block in the same manner as described with respect to the intra-prediction unit 226 ( Fig. 9 The intra prediction process is performed in a substantially similar manner as described in the foregoing description. The intra prediction unit 318 may retrieve data of neighboring samples of the current block from the DPB 314.

[0291] The reconstruction unit 310 may reconstruct the current block using the prediction block and the residual block. For example, the reconstruction unit 310 may reconstruct the current block by adding samples of the residual block to corresponding samples of the prediction block.

[0292] The filter unit 312 may perform one or more filter operations on the reconstructed block. For example, the filter unit 312 may perform a deblocking operation to reduce blocking artifacts along the edges of the reconstructed block. The operations of the filter unit 312 need not be performed in all examples.

[0293] The video decoder 300 may store the reconstructed blocks in the DPB 314. As discussed above, the DPB 314 may provide reference information (such as samples of the current picture for intra prediction and previously decoded pictures for subsequent motion compensation) to the prediction processing unit 304. In addition, the video decoder 300 may output decoded pictures from the DPB 314 for use in, for example, Figure 1 Subsequent presentation on a display device 118 of the display device.

[0294] According to one or more techniques of the present disclosure, the video decoder 300 may perform a process reciprocal to the video encoder 200 for deriving a TMVP candidate. For example, the entropy decoding unit 302 may decode a plurality of syntax elements from the decoded video bitstream, each syntax element specifying one or more parameters of the TMVP candidate derivation process. For example, the entropy decoding unit 302 may decode and provide to the prediction processing unit 304 the value of one or more of the following: a syntax element (col_pic_list_idx) specifying a reference picture list for derivation of a co-located picture for deriving a TMVP candidate; a syntax element (col_pic_ref_idx) specifying a reference index of a co-located picture; and / or a syntax element (col_source_mvp_list_idx) specifying a reference picture list for derivation of a motion vector candidate for deriving a TMVP candidate.

[0295] The prediction processing unit 304 may derive a TMVP candidate for a current block of a current picture of the video data based on the values ​​of the parameters specified by the plurality of syntax elements. The prediction processing unit 304 may insert the derived TMVP candidate into a list of motion vector candidates and predict the current block of the video data based on the list of motion vector candidates.

[0296] Similar to the video encoder 200, the video decoder 300 may selectively derive TMVP candidates based on explicitly signaled parameters, or derive TMVP candidates based on inferred parameters. For example, depending on the value of a control syntax element (e.g., temporal_mvp_asigned_flag), the video decoder 300 may decode multiple syntax elements and derive TMVP candidates based on explicitly signaled parameters specified by the multiple syntax elements, or not decode multiple syntax elements and derive TMVP candidates based on inferred (i.e., not explicitly signaled) parameters.

[0297] In this way, the video decoder 300 represents an example of a video decoding device, which includes: a memory configured to store video data; and one or more processing units implemented in a circuit and configured to: decode a syntax element via a decoded video bitstream, the syntax element specifying whether the decoded video bitstream includes multiple syntax elements that specify parameters for a temporal motion vector prediction (TMVP) candidate derivation process; in the case where the syntax element specifies that the decoded video bitstream includes multiple syntax elements: decode the multiple syntax elements via the decoded video bitstream; and derive TMVP candidates for a current block of a current picture of the video data based on the parameters specified by the multiple syntax elements; generate a list of motion vector candidates for the current block, the list including the derived TMVP candidates; and predict the current block based on the list of motion vector candidates.

[0298] Fig.11 2 is a flowchart illustrating an example method for encoding a current block. The current block may include a current CU. Although with respect to the video encoder 200 ( Figure 1 and 9 ), but it should be understood that other devices may be configured to perform the same Fig.11 A similar process to the method.

[0299] In this example, the video encoder 200 initially predicts the current block (350). For example, the video encoder 200 may form a prediction block for the current block. The video encoder 200 may then calculate a residual block for the current block (352). To calculate the residual block, the video encoder 200 may calculate the difference between the original unencoded block and the prediction block for the current block. The video encoder 200 may then transform and quantize the coefficients of the residual block (354). Next, the video encoder 200 may scan the quantized transform coefficients of the residual block (356). During or after the scan, the video encoder 200 may entropy encode the coefficients (358). For example, the video encoder 200 may encode the coefficients using CAVLC or CABAC. The video encoder 200 may then output the entropy coded data of the block (360).

[0300] Fig.12 is a flowchart illustrating an example method for decoding a current block of video data. The current block may include a current CU. Although with respect to the video decoder 300 ( Figure 1 and 10 ), but it should be understood that other devices may be configured to perform the same Fig.12 A similar approach to the one used in this paper.

[0301] The video decoder 300 may receive entropy coded data for a current block (such as entropy coded prediction information and entropy coded data for coefficients of a residual block corresponding to the current block) (370). The video decoder 300 may entropy decode the entropy coded data to determine prediction information for the current block and regenerate coefficients of the residual block (372). The video decoder 300 may predict the current block (374), for example, using an intra-frame or inter-frame prediction mode as indicated by the prediction information for the current block, to calculate a prediction block for the current block. The video decoder 300 may then inverse scan the regenerated coefficients (376) to create a block of quantized transform coefficients. The video decoder 300 may then inverse quantize and inverse transform the coefficients to generate a residual block (378). Finally, the video decoder 300 may decode the current block by combining the prediction block and the residual block (380).

[0302] Fig.13 is a flowchart illustrating an example method for deriving a temporal motion vector predictor (TMVP) candidate according to one or more techniques of this disclosure. Fig.10 ), but it should be understood that other devices may be configured to perform the same Fig.13 A similar method to that of video encoder 200 (eg, as part of a reconstruction loop).

[0303] The video decoder 300 may encode a syntax element via a decoded video bitstream, the syntax element specifying whether the decoded video bitstream includes a plurality of syntax elements specifying parameters for a temporal motion vector prediction (TMVP) candidate derivation process (1302). For example, the entropy decoding unit 302 of the video decoder 300 may decode temporal_mvp_asigned_flag according to a slice header syntax structure of the decoded video bitstream.

[0304] The video decoder 300 may selectively derive a TMVP candidate for a current block of video data (e.g., a current CU) based on the inferred parameters or based on parameters specified by a plurality of syntax elements. For example, in a case where the syntax element does not specify that the decoded video bitstream includes a plurality of syntax elements (e.g., temporal_mvp_asigned_flag has a value of 0) (the "No" branch of 1304), the video decoder 300 may derive a TMVP candidate for the current block of video data based on the inferred parameters (1306). For example, the prediction processing unit 304 may infer at least one of: a reference picture list for deriving a co-located picture for deriving the TMVP candidate; a reference index of the co-located picture; and a reference picture list for deriving a motion vector candidate for deriving the TMVP candidate. As a specific example, in order to derive the TMVP candidate based on the inferred parameters, the prediction processing unit 304 may utilize the above reference to Figure 3A and 3B In this manner, prediction processing unit 304 may infer parameters of a TMVP candidate derivation process; and derive, through a video coder and based on the inferred parameters, a TMVP candidate for a current block of a current picture of video data.

[0305] Alternatively, where the syntax element specifies that the decoded video bitstream includes multiple syntax elements (e.g., temporal_mvp_asigned_flag has a value of 1) (the "yes" branch of 1304), the video decoder 300 may decode the multiple syntax elements via the decoded video bitstream (1308). For example, the entropy decoding unit 302 may decode multiple syntax elements including one or more of the following: a syntax element specifying a reference picture list for derivation of a co-located picture for deriving a TMVP candidate (e.g., col_pic_list_idx); a syntax element specifying a reference index of a co-located picture (e.g., col_pic_ref_idx); and a syntax element specifying a reference picture list for derivation of a motion vector candidate for deriving the TMVP candidate (e.g., col_source_mvp_list_idx). In some examples, the entropy decoding unit 302 may decode the multiple syntax elements according to the slice header syntax structure.

[0306] The video decoder 300 may derive a TMVP candidate for a current block of a current picture of the video data based on the parameters specified by the plurality of syntax elements (1310). For example, the prediction processing unit 304 may obtain a motion vector from a picture having a specified reference index in a specified reference picture list for derivation of a co-located picture for deriving the TMVP candidate and having a specified source reference picture list.

[0307] Whether using implicit or explicit derivation, the video decoder 300 can generate a list of motion vector candidates for the current block, the list including the derived TMVP candidate (1312). For example, the prediction processing unit 304 can generate a motion vector candidate list to include a TMVP candidate and one or more spatial candidates, HMVP candidates, paired candidates, and zero candidates.

[0308] Video decoder 300 may predict the current block based on the list of motion vector candidates (1314). For example, entropy decoding unit 302 may decode a syntax element that specifies which entry in the motion vector candidate list to use. Prediction processing unit 304 may obtain samples from a block of video data (referred to as a prediction block) identified by the motion vector candidate specified by the syntax element. As described above with reference to Fig.12 As discussed, prediction processing unit 304 may combine samples from a prediction block with residual data.

[0309] The following examples may illustrate one or more aspects of the present disclosure:

[0310] Example 1. A method of decoding video data, the method comprising: deriving, by a video decoder and for a current block of a current picture of the video data, a temporal motion vector prediction (TMVP) candidate; generating a list of motion vector candidates for the current block, the list including the derived TMVP candidate; and predicting the current block based on the list of motion vector candidates.

[0311] Example 2. The method according to Example 1, wherein deriving the TMVP candidate comprises: obtaining a motion vector of a co-located block of the current picture, the co-located block being located in a co-located reference picture of the current picture; and deriving the TMVP candidate as a scaled version of the obtained motion vector of the co-located block.

[0312] Example 3. The method according to Example 2, wherein deriving the TMVP candidate as the scaled version of the obtained motion vector of the co-located block comprises: determining a scaling factor based on a picture order count (POC) difference between the current picture and the co-located reference picture; and scaling the obtained motion vector of the co-located block based on the scaling factor to obtain the TMVP candidate.

[0313] Example 4. The method according to Example 3, wherein the scaling factor is a first scaling factor, the method further comprising: determining a second scaling factor based on a POC difference between the co-located reference picture and a reference picture of the co-located reference picture, wherein scaling the obtained motion vector of the co-located block to obtain the TMVP candidate comprises: scaling the obtained motion vector of the co-located block based on the first scaling factor and the second scaling factor to obtain the TMVP candidate.

[0314] Example 5. The method of any of Examples 1-4, further comprising: decoding, via the decoded video bitstream, one or more syntax elements that specify parameters of the TMVP candidate derivation process.

[0315] Example 6. The method of example 5, wherein the one or more syntax elements include one or more of: a temporal_mvp_asigned_flag syntax element, a col_pic_list_idx syntax element, a col_pic_ref_idx syntax element, and / or a col_source_mvp_list_idx syntax element.

[0316] Example 7. The method of any one of Examples 1-4, wherein the video decoder comprises a video decoder, the method further comprising: deriving, by the video decoder, parameters of the TMVP candidate derivation process.

[0317] Example 8. The method of any one of Examples 1-7, wherein the decoding comprises decoding.

[0318] Example 9. The method of any one of Examples 1-8, wherein decoding includes encoding.

[0319] Example 10. An apparatus for decoding video data, the apparatus comprising one or more means for performing the method according to any of Examples 1-9.

[0320] Example 11. The apparatus of Example 10, wherein the one or more units include one or more processors implemented in a circuit.

[0321] Example 12. The apparatus of any one of Examples 10 and 11, further comprising: a memory for storing the video data.

[0322] Example 13. The apparatus of any of Examples 10-12, further comprising: a display configured to display the decoded video data.

[0323] Example 14. The device of any of Examples 10-13, wherein the device comprises one or more of a camera, a computer, a mobile device, a broadcast receiver device, or a set-top box.

[0324] Example 15. The apparatus of any of Examples 10-14, wherein the apparatus comprises a video decoder.

[0325] Example 16. The apparatus of any of Examples 10-15, wherein the apparatus comprises a video encoder.

[0326] Example 17. A computer-readable storage medium having instructions stored thereon that, when executed, cause one or more processors to perform the method of any of Examples 1-9.

[0327] It is to be appreciated that, according to examples, certain actions or events of any of the techniques described herein may be performed in a different order, may be added, combined, or omitted entirely (e.g., not all described actions or events are necessary for the practice of the techniques). In addition, in some examples, actions or events may be performed concurrently rather than sequentially, such as through multithreading, interrupt handling, or multiple processors.

[0328] In one or more examples, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or sent through a computer-readable medium as one or more instructions or codes and executed by a hardware-based processing unit. A computer-readable medium may include a computer-readable storage medium corresponding to a tangible medium such as a data storage medium or a communication medium, the communication medium including, for example, any medium that facilitates the transfer of a computer program from one place to another according to a communication protocol. In this manner, a computer-readable medium may generally correspond to (1) a non-temporary tangible computer-readable storage medium, or (2) a communication medium such as a signal or carrier wave. A data storage medium may be any available medium that can be accessed by one or more computers or one or more processors to obtain instructions, codes, and / or data structures for implementing the techniques described in the present disclosure. A computer program product may include a computer-readable medium.

[0329] By way of example and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and can be accessed by a computer. In addition, any connection is appropriately referred to as a computer-readable medium. For example, if a coaxial cable, optical fiber cable, twisted pair, digital subscriber line (DSL) or wireless technology (such as infrared, radio and microwave) is used to send instructions from a website, server or other remote source, then the coaxial cable, optical fiber cable, twisted pair, DSL or wireless technology (such as infrared, radio and microwave) is included in the definition of the medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals or other temporary media, but are instead directed to non-temporary tangible storage media. As used herein, disks and optical disks include compact disks (CDs), laser optical disks, optical disks, digital versatile disks (DVDs), floppy disks and blue-ray disks, wherein disks usually copy data magnetically, while optical disks use lasers to optically copy data. Combinations of the above should also be included within the scope of computer-readable media.

[0330] Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Accordingly, the terms "processor" and "processing circuitry" as used herein may refer to any of the aforementioned structures or any other structure suitable for implementing the techniques described herein. In addition, in some aspects, the functions described herein may be provided within dedicated hardware and / or software modules configured for encoding and decoding, or incorporated into a combined codec. In addition, the techniques may be fully implemented in one or more circuits or logic elements.

[0331] The techniques of the present disclosure may be implemented in a wide variety of devices or apparatuses, including a wireless handset, an integrated circuit (IC), or a set of ICs (e.g., a chipset). Various components, modules, or units are described in the present disclosure to emphasize the functional aspects of a device configured to perform the disclosed techniques, but do not necessarily need to be implemented by different hardware units. Rather, as described above, the various units may be combined in a codec hardware unit, or provided by a collection of interoperable hardware units (including one or more processors as described above) in combination with appropriate software and / or firmware.

[0332] Various examples have been described. These and other examples are within the scope of the following claims.

Claims

1. A method for decoding video data, the method comprising: A syntax element is decoded, by a video coder and via a coded video bitstream, the syntax element explicitly specifying whether the coded video bitstream includes a plurality of syntax elements that specify parameters for a temporal motion vector prediction (TMVP) candidate derivation process, wherein the syntax element is a binary flag syntax element, wherein: a first value of the binary flag syntax element that explicitly specifies whether the decoded video bitstream includes the plurality of syntax elements that specify parameters for the TMVP candidate derivation process indicates that the decoded video bitstream includes the plurality of syntax elements that specify parameters for the TMVP candidate derivation process, and a second value of the binary flag syntax element that explicitly specifies whether the decoded video bitstream includes the plurality of syntax elements that specify parameters for the TMVP candidate derivation process indicates that the decoded video bitstream does not include the plurality of syntax elements that specify parameters for the TMVP candidate derivation process; In a case where the binary flag syntax element has the first value explicitly specifying that the coded video bitstream includes the plurality of syntax elements: decoding, by the video coder via the coded video bitstream, the plurality of syntax elements; and deriving, by the video coder and based on the parameters specified by the plurality of syntax elements, a TMVP candidate for a current block of a current picture of video data; generating a list of motion vector candidates for the current block, the list including the derived TMVP candidate; and The current block is predicted based on the list of motion vector candidates.

2. The method according to claim 1, wherein: The plurality of syntax elements specifying the parameters of the TMVP candidate derivation process include one or more of the following: specifying syntax elements for derivation of a reference picture list for derivation of a co-located picture for the TMVP candidate; a syntax element specifying a reference index of the co-located picture; as well as Syntax elements for specifying a reference picture list for derivation of motion vector candidates for the TMVP candidate.

3. The method according to claim 2, wherein: The syntax element specifying whether the decoded video bitstream includes the plurality of syntax elements comprises a temporal_mvp_asigned_flag syntax element; The syntax element specifying the reference picture list for derivation of the co-located picture for deriving the TMVP candidate comprises a col_pic_list_idx syntax element; The syntax element specifying the reference index of the co-located picture comprises a col_pic_ref_idx syntax element; as well as The syntax element specifying the reference picture list used for derivation of the motion vector candidate for deriving the TMVP candidate comprises a col_source_mvp_list_idx syntax element.

4. The method according to claim 1, wherein: Decoding the plurality of syntax elements includes decoding the plurality of syntax elements in a slice header syntax structure of the coded video bitstream.

5. The method according to claim 1, further comprising: In the event that the syntax element does not specify that the coded video bitstream includes the plurality of syntax elements: Inferring parameters of the TMVP candidate derivation process by the video decoder; as well as The TMVP candidate for the current block of the current picture of video data is derived by the video coder and based on the inferred parameters.

6. The method according to claim 1, wherein: The video decoder comprises a video decoder, and wherein decoding comprises decoding.

7. The method according to claim 1, wherein: The video decoder comprises a video encoder, and wherein decoding comprises encoding.

8. A device for decoding video data, the device comprising: a memory configured to store at least a portion of the decoded video bitstream; as well as One or more processors implemented in circuitry and configured to: A syntax element is decoded via a coded video bitstream, the syntax element explicitly specifying whether the coded video bitstream includes a plurality of syntax elements that specify parameters for a temporal motion vector prediction (TMVP) candidate derivation process, wherein the syntax element is a binary flag syntax element, wherein: a first value of the binary flag syntax element that explicitly specifies whether the decoded video bitstream includes the plurality of syntax elements that specify parameters for the TMVP candidate derivation process indicates that the decoded video bitstream includes the plurality of syntax elements that specify parameters for the TMVP candidate derivation process, and a second value of the binary flag syntax element that explicitly specifies whether the decoded video bitstream includes the plurality of syntax elements that specify parameters for the TMVP candidate derivation process indicates that the decoded video bitstream does not include the plurality of syntax elements that specify parameters for the TMVP candidate derivation process; In a case where the binary flag syntax element has the first value explicitly specifying that the coded video bitstream includes the plurality of syntax elements: decoding the plurality of syntax elements via the coded video bitstream; and deriving a TMVP candidate for a current block of a current picture of the video data based on the parameters specified by the plurality of syntax elements; generating a list of motion vector candidates for the current block, the list including the derived TMVP candidate; and The current block is predicted based on the list of motion vector candidates.

9. The device according to claim 8, wherein: The plurality of syntax elements specifying the parameters of the TMVP candidate derivation process include one or more of the following: specifying syntax elements for derivation of a reference picture list for derivation of a co-located picture for the TMVP candidate; a syntax element specifying a reference index of the co-located picture; as well as Syntax elements for specifying a reference picture list for derivation of motion vector candidates for the TMVP candidate.

10. The apparatus of claim 9, wherein: The syntax element specifying whether the decoded video bitstream includes the plurality of syntax elements comprises a temporal_mvp_asigned_flag syntax element; The syntax element specifying the reference picture list for derivation of the co-located picture for deriving the TMVP candidate comprises a col_pic_list_idx syntax element; The syntax element specifying the reference index of the co-located picture comprises a col_pic_ref_idx syntax element; as well as The syntax element specifying the reference picture list used for derivation of the motion vector candidate for deriving the TMVP candidate comprises a col_source_mvp_list_idx syntax element.

11. The device according to claim 8, wherein: To decode the plurality of syntax elements, the one or more processors are configured to decode the plurality of syntax elements in a slice header syntax structure of the decoded video bitstream.

12. The device according to claim 8, wherein: In a case where the syntax element does not specify that the decoded video bitstream includes the plurality of syntax elements, the one or more processors are configured to: Inferring parameters of the TMVP candidate derivation process; as well as The TMVP candidate for the current block of the current picture of video data is derived based on the inferred parameters.

13. The apparatus according to claim 8, wherein: The apparatus comprises a video decoder, and wherein, to code the syntax element and the plurality of syntax elements, the one or more processors are configured to decode the syntax element and the plurality of syntax elements.

14. The apparatus according to claim 8, wherein: The apparatus comprises a video encoder, and wherein, to decode the syntax element and the plurality of syntax elements, the one or more processors are configured to encode the syntax element and the plurality of syntax elements.

15. The apparatus according to claim 8, wherein: The one or more processors may include an application specific integrated circuit (ASIC).

16. A computer-readable storage medium storing instructions, wherein when the instructions are executed by one or more processors of a video decoder, the one or more processors are caused to perform the following operations: A syntax element is decoded via a decoded video bitstream, the syntax element explicitly specifying whether the decoded video bitstream includes a plurality of syntax elements that specify parameters of a temporal motion vector prediction (TMVP) candidate derivation process, wherein: The syntax element is a binary flag syntax element, where: a first value of the binary flag syntax element that explicitly specifies whether the decoded video bitstream includes the plurality of syntax elements that specify parameters for the TMVP candidate derivation process indicates that the decoded video bitstream includes the plurality of syntax elements that specify parameters for the TMVP candidate derivation process, and a second value of the binary flag syntax element that explicitly specifies whether the decoded video bitstream includes the plurality of syntax elements that specify parameters for the TMVP candidate derivation process indicates that the decoded video bitstream does not include the plurality of syntax elements that specify parameters for the TMVP candidate derivation process; In a case where the binary flag syntax element has the first value explicitly specifying that the coded video bitstream includes the plurality of syntax elements: decoding, by the video coder via the coded video bitstream, the plurality of syntax elements; and deriving, by the video coder and based on parameters specified by the plurality of syntax elements, a TMVP candidate for a current block of a current picture of video data; generating a list of motion vector candidates for the current block, the list including the derived TMVP candidate; and The current block is predicted based on the list of motion vector candidates.

17. The computer-readable storage medium of claim 16, wherein: The plurality of syntax elements specifying the parameters of the TMVP candidate derivation process include one or more of the following: specifying syntax elements for derivation of a reference picture list for derivation of a co-located picture for the TMVP candidate; a syntax element specifying a reference index of the co-located picture; as well as Syntax elements for specifying a reference picture list for derivation of motion vector candidates for the TMVP candidate.

18. The computer-readable storage medium of claim 16, wherein: The instructions that cause the one or more processors to decode the plurality of syntax elements include instructions that cause the one or more processors to decode the plurality of syntax elements in a slice header syntax structure of the decoded video bitstream.

19. The computer-readable storage medium of claim 16, further comprising instructions for causing the one or more processors to: if the syntax element does not specify that the decoded video bitstream includes the plurality of syntax elements: inferring parameters of the TMVP candidate derivation process; and The TMVP candidate for the current block of the current picture of video data is derived based on the inferred parameters.

20. A device for decoding video data, the device comprising: Means for coding, via a coded video bitstream, a syntax element that explicitly specifies whether the coded video bitstream includes a plurality of syntax elements that specify parameters for a temporal motion vector prediction (TMVP) candidate derivation process, wherein the syntax element is a binary flag syntax element, wherein: a first value of the binary flag syntax element that explicitly specifies whether the decoded video bitstream includes the plurality of syntax elements that specify parameters for the TMVP candidate derivation process indicates that the decoded video bitstream includes the plurality of syntax elements that specify parameters for the TMVP candidate derivation process, and a second value of the binary flag syntax element that explicitly specifies whether the decoded video bitstream includes the plurality of syntax elements that specify parameters for the TMVP candidate derivation process indicates that the decoded video bitstream does not include the plurality of syntax elements that specify parameters for the TMVP candidate derivation process; means for decoding, via the decoded video bitstream, the plurality of syntax elements if the binary flag syntax element has the first value that explicitly specifies that the decoded video bitstream includes the plurality of syntax elements; means for deriving a TMVP candidate for a current block of a current picture of the video data based on parameters specified by the plurality of syntax elements; means for generating a list of motion vector candidates for the current block, the list comprising the derived TMVP candidate; and A unit for predicting the current block based on the list of motion vector candidates.

Images