RU2574280C2 - Selection of common candidates of mode of convergence and adaptive motion vector prediction mode - Google Patents

Abstract

FIELD: physics.

SUBSTANCE: motion vector encoding in video encoding comprises the definition one of multiple modes for prediction of motion vector for the current set of video data to be encoded. Prediction of motion vector for the current set of video data is performed with the help of the definite mode and set of candidate units. Note here that the latter are identical for each of said multiple modes. Note also that said multiple modes includes the mode of convergence and adaptive motion vector prediction mode. Note that the set of candidate units comprises the left top candidate unit, top candidate unit, right top candidate unit, left candidate unit, bottom left candidate unit and temporary candidate unit.

EFFECT: reduced complexity of motion vector prediction.

28 cl, 21 dwg

Description

[0001] This application claims the priority of provisional patent application US No. 61 / 506,558, filed July 11, 2011, provisional patent application US No. 61 / 499,114, filed June 20, 2011 and provisional patent application US No. 61 / 509,007, filed July 18 2011, all of which are hereby incorporated by reference in their entirety.

FIELD OF TECHNOLOGY

[0002] The present disclosure relates to video coding, and in more detail, to methods for selecting motion vector prediction candidate blocks in a motion vector prediction process.

FIELD OF TECHNOLOGY

[0003] Digital video capabilities can be incorporated into a wide range of devices, including digital televisions, digital direct broadcast systems, wireless broadcast systems, personal digital assistants (PDAs), laptop or desktop computers, digital cameras, digital recorders, digital media players, video gaming devices, video game consoles, cellular or satellite radiotelephones, video conferencing devices, etc. Digital video devices implement video compression methods, such as those described in the standards defined by MPEG-2, MPEG-4, ITU-T H.264 / MPEG-4, Part 10, Advanced Video Coding (AVC), the standard for high-performance video coding (HEVC ), currently evolving, and extensions of such standards to transmit, receive and store digital video information more efficiently.

[0004] Video compression methods perform spatial (intra picture) prediction and / or temporal (between picture) prediction to reduce or remove the redundancy inherent in video sequences. For, based on the coding blocks of a video, a video frame or clipping can be divided into blocks. Each block can be further divided. Video blocks in an internally coded (I) clip of a picture are encoded using spatial prediction with respect to reference samples in neighboring blocks in the same frame or clip. Blocks in an externally encoded (P or B) frame or slice may use spatial prediction for reference samples in neighboring blocks in the same frame or slice or temporal prediction for reference samples in other reference frames. Spatial or temporal prediction results in a predictive block for the block to be encoded. The residual data represents pixel differences between the original block to be encoded and the predictive block.

[0005] An externally coded block is encoded according to a motion vector that points to a block of reference samples forming a predictive block, and residual data indicating a difference between the encoded block and the predictive block. The internally encoded block is encoded according to the internal encoding mode and the residual data. For further compression, residual data can be converted from the pixel region to the transformation region, resulting in residual transform coefficients, which can then be quantized. The quantized transform coefficients originally placed in a two-dimensional array can be scanned in a specific order to form a one-dimensional vector of transform coefficients for entropy coding.

SUMMARY OF THE INVENTION

[0006] In general, the present disclosure describes methods for encoding video data. The present disclosure describes methods for selecting motion vector prediction candidate blocks in a motion vector prediction process.

[0007] In one example disclosure, a method of encoding a motion vector in a video encoding process comprises determining one of a plurality of modes for a motion vector prediction process and performing a motion vector prediction process for the current video data block using a specific mode and a set of candidate blocks in which the set candidate blocks is the same for each of the many modes.

[0008] In another example disclosure, a method for decoding a motion vector in a video encoding process comprises determining one of a plurality of modes for a motion vector prediction process for the current video data block and determining a candidate block from the set of candidate blocks in which the set of candidate blocks is the same for each of the many modes, and in which the information associated with the candidate block is used to decode the motion vector for the current block.

[0009] In another example disclosure, a method for encoding a motion vector in a video encoding process comprises determining one of a plurality of modes for a motion vector prediction process and performing a motion vector prediction process for the current video data block using a specific mode and a set of candidate blocks, wherein candidate blocks is the same for each of the many modes in which one candidate block in the set of candidate blocks is defined as an additional candidate block, and in which Tel'nykh candidate block is used if the other of the set of candidate blocks of the candidate blocks is unavailable.

[0010] In another disclosure example, a method for decoding a motion vector in a video encoding process includes receiving a syntax element indicating one of a plurality of modes for the motion vector prediction process for the current video data block, and receiving an index indicating a candidate block from a set of candidate blocks, in which the set of candidate blocks is the same for each of the many modes, in which one candidate block in the set of candidate blocks is defined as an additional candidate block in which this complementary th candidate block is used if the other of the set of candidate blocks of the candidate blocks is unavailable and wherein the information associated with the candidate block, is used to decode the motion vector for the current block.

[0011] Details of one or more examples are set forth in the accompanying drawings and description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] FIG. 1A is a conceptual drawing illustrating candidate blocks for motion vector prediction according to the adaptive motion vector prediction (AMVP) mode.

[0013] FIG. 1B is a conceptual drawing illustrating candidate blocks for predicting a motion vector according to a merge mode.

[0014] FIG. 2 is a block diagram illustrating an example video encoding and decoding system.

[0015] FIG. 3 is a block diagram illustrating an example video encoder.

[0016] FIG. 4A is a conceptual drawing of signaling information for a merge mode.

[0017] FIG. 4B is a conceptual drawing of signaling information for AMVP mode.

[0018] FIG. 5A is a conceptual drawing illustrating candidate blocks for AMVP and merge mode in accordance with one disclosure example.

[0019] FIG. 5B is a conceptual drawing illustrating candidate blocks for AMVP and merge mode in accordance with another disclosure example.

[0020] FIG. 6 is a conceptual drawing illustrating candidate blocks for AMVP and merge mode in accordance with another disclosure example.

[0021] FIG. 7 is a conceptual drawing illustrating candidate blocks and a validation pattern for AMVP and merge mode in accordance with another disclosure example.

[0022] FIG. 8 is a block diagram illustrating an example video decoder.

[0023] FIG. 9 is a flowchart illustrating an example video encoding method.

[0024] FIG. 10 is a flowchart illustrating an exemplary method of merging video encoding.

[0025] FIG. 11 is a flowchart illustrating an example method for encoding video in AMVP mode.

[0026] FIG. 12 is a flowchart illustrating an example video decoding method.

[0027] FIG. 13 is a flowchart illustrating an example method for decoding video in a merge mode.

[0028] FIG. 14 is a flowchart illustrating an example method for decoding video in AMVP mode.

[0029] FIG. 15 is a flowchart illustrating another example video encoding method.

[0030] FIG. 16 is a flowchart illustrating another example video decoding method.

[0031] FIG. 17 is a flowchart illustrating another exemplary merge mode video decoding method.

[0032] FIG. 18 is a flowchart illustrating another exemplary method for decoding video in AMVP mode.

DETAILED DESCRIPTION

[0033] In general, the present disclosure describes methods for encoding video data. The present disclosure describes methods for selecting motion vector prediction candidate blocks in a motion vector prediction process. In one example, the present disclosure proposes that each of the plurality of motion vector prediction modes use the same set of candidate blocks to predict a motion vector for the current block. In another example, the present disclosure proposes that one candidate block in a set of candidate blocks is defined as an additional candidate block. This optional candidate block is used if the other one of the blocks in the set is unavailable.

[0034] Digital video devices implement video compression methods to encode and decode digital video information more efficiently. Video compression can apply spatial (intra-frame) and / or temporal (inter-frame) prediction methods to reduce or remove the redundancy inherent in video sequences.

[0035] For video encoding according to the high-performance video encoding standard (HEVC) currently being developed by the joint joint team for video encoding (JCT-VC), the video frame can be divided into encoding units. A coding unit (CU) generally refers to a region of an image that serves as a basic unit to which various coding tools are used to compress video. A CU typically has a luminance component denoted by Y and two color components denoted by U and V. Depending on the video sampling format, the size of the U and V components, in terms of the number of samples, may be the same or different from the size of the Y component. CU is typically square, and can be assumed to be similar to the so-called macroblock, for example, in other video coding standards such as ITU-T H.264.

[0036] In order to achieve better coding efficiency, the coding unit may have variable sizes depending on the video content. In addition, the coding unit may be divided into smaller blocks for prediction or conversion. In particular, each coding unit can be further divided into prediction units (PUs) and transform units (TUs). Prediction units can be considered similar to the so-called separation in other video coding standards such as H.264. Transformation units (TUs) refer to residual data blocks to which a transformation is applied to form transformation coefficients.

[0037] Coding according to some of the currently proposed aspects of the development of the HEVC standard will be described in this application for illustrative purposes. However, the methods described in this disclosure may be useful for other video encoding processes, such as those defined according to H.264 or other standard or proprietary video encoding processes.

[0038] The HEVC standardization efforts are based on a model of a video encoding device called the HEVC Test Model (HM). HM involves several additional features of video encoding devices over existing devices according to, for example, ITU-T H.264 / AVC. For example, while H.264 provides nine intra-prediction coding modes, HM provides as many as thirty-four intra-prediction coding modes.

[0039] According to the HM, a CU may include one or more prediction units (PUs) and / or one or more transformation units (TUs). The syntax data within the bitstream can determine the largest coding unit (LCU), which is the largest CU in terms of the number of pixels. Typically, a CU has a similar purpose to the H.264 macroblock, except that the CU does not have a difference in size. Thus, CUs can be divided into sub-CUs. Typically, references in this disclosure to CUs may refer to the largest picture coding unit or sub-CU in the LCU. The LCU can be divided into sub-CUs, and each sub-CU can be further divided into sub-CUs. The syntax data for the bitstream can determine the maximum number of times how many LCUs can be split, called the CU depth. Accordingly, the bitstream may also determine the smallest coding unit (SCU). The present disclosure also uses the term “block” or “part” to refer to any of a CU, PU, or TU. Typically, a “part” can refer to any subset of a video frame.

[0040] An LCU may be associated with a quad tree data structure. Typically, the quad tree data structure includes one node for each CU, where the root node corresponds to the LCU. If the CU is divided into four sub-CUs, the node corresponding to the CU includes four leaf (leaf) nodes, each of which corresponds to one of the sub-CUs. Each node of the quadtree data structure can provide syntax data for the corresponding CU. For example, a node in a quadtree may include a split flag indicating whether the CU corresponding to the node is divided into sub-CUs. The syntax elements for the CU can be defined recursively, and may depend on whether the CU is divided into sub-CUs. If the CU is not further divided, it is referred to as a leaf (terminal) CU.

[0041] In addition, TU units of leafy CUs may also be associated with corresponding quad tree data structures. Thus, the leafy CU may include a quadtree indicating how the leafy CU is divided into TU units. The present disclosure relates to a quad tree indicating how an LCU is partitioned as a CU quad tree and this quad tree indicates how a leaf CU is divided into TU units as a TU quad tree. The root node of the TU quad tree usually corresponds to the leaf CU, while the root node of the CU quad tree usually corresponds to the LCU. The TU units of the TU quad tree that are not split are referred to as leaf (terminal) TUs.

[0042] The leaf CU may include one or more prediction units (PUs). Typically, the PU represents all or part of the corresponding CU, and may include data in order to extract a reference sample for the PU. For example, when the PU is external encoded, the PU may include data defining a motion vector for the PU. The motion vector data can describe, for example, the horizontal component of the motion vector, the vertical component of the motion vector, the resolution for the motion vector (for example, one quarter pixel accuracy or one eighth pixel accuracy), a reference frame that the motion vector points to, and / or a reference list (e.g., list 0 or list 1) for the motion vector. The data for the leaf CU defining the PU unit (s) may also describe, for example, the division of the CU into one or more PUs. Separation modes may differ depending on whether the CU is prediction encoded, intra prediction mode encoded, or inter prediction mode encoded. For internal coding, the PU can be handled in the same way as the sheet conversion unit described below.

[0043] To encode a block (for example, a prediction unit (PU) of video data), a predictor for the block is first obtained. The predictor can be obtained from any of the external (I) prediction (i.e., spatial prediction) or external (P or B) prediction (i.e., temporal prediction). Therefore, some prediction blocks can be internally encoded (I) using spatial prediction with respect to neighboring reference blocks in the same frame, and other prediction blocks can be externally encoded (P or B) with respect to reference blocks in other frames.

[0044] After identifying the predictor, a difference between the original video data block and its predictor is calculated. This difference is also called the remainder of the prediction, and refers to the differences in pixel values between the pixels of the block to be encoded and the corresponding pixels of the reference block, that is, the predictor. In order to achieve better compression, the prediction remainder (i.e., an array of pixel difference values) is usually transformed, for example, using a discrete cosine transform (DCT), an integer transform, a Karhunen-Loeve transform (K-L), or another transform.

[0045] PU coding using inter prediction involves computing a motion vector between the current block and the block in the reference frame. Motion vectors are calculated using a process called motion estimation (or motion search). The motion vector, for example, may indicate the offset of the prediction block in the current frame relative to the reference sample of the reference frame. The reference sample may be a block that is found to closely match the portion of the CU, including the PU encoded in terms of the pixel difference, which can be determined by the sum of the absolute differences (SAD), the sum of the differences of the squares (SSD), or other difference metrics. The reference sample may take place anywhere within the reference frame or reference clipping. In some examples, a reference sample may take place at a fractional position of a pixel. After detecting the part of the reference frame that best matches the current part, the encoder determines the current motion vector for the current part as the difference in location from the current part to the matching part in the reference frame (that is, from the center of the current part to the center of the matching part).

[0046] In some examples, the encoder may signal a motion vector for each part in the encoded video bitstream. The signalized motion vector is used by the decoder to perform motion compensation to decode the video data. However, signaling the initial motion vector directly may lead to less efficient coding, since a large number of bits are usually necessary to transmit information.

[0047] In some cases, instead of directly signaling the initial motion vector, the encoder may predict the motion vector for each division, that is, for each PU. When performing this motion vector prediction, the encoder may select a set of motion candidate vectors determined from spatially adjacent blocks in the same frame as the current portion or motion candidate vector determined from a co-located block in the reference frame. The encoder can perform motion vector prediction, and if necessary, signal the prediction difference, rather than signal the original motion vector to reduce the bit rate in the signaling. Vectors of a motion candidate vector from spatially adjacent blocks may be referred to as spatial MVP candidates, while a motion candidate vector from a co-located block in another reference frame may be referred to as a temporary MVP candidate.

[0048] Two different modes or types of motion vector prediction are proposed in the current work draft of the HEVC standard. One mode is referred to as a merge mode. Another mode is referred to as adaptive motion vector prediction (AMVP). In merge mode, the encoder instructs the decoder, by signaling the bitstream of the prediction syntax, to copy the motion vector, the reference index (identifying the reference frame in the given list of reference pictures to which the motion vector points), and the direction of the motion prediction (which identifies the list of reference pictures (List 0 or List 1), that is, in terms of whether the reference frame temporarily precedes or follows the current frame) from the selected motion candidate vector for the current part of the frame. This is achieved by signaling the index bit stream to a list of motion candidate vectors identifying the selected motion candidate vector (i.e., a particular spatial MVP candidate or temporary MVP candidate). Thus, for the merge mode, the prediction syntax may include a flag identifying the mode (in this case, the "merge" mode) and an index identifying the selected motion candidate vector. In some cases, the motion vector candidate will be in the causal part in reference to the current part. Thus, the motion vector candidate will already be decoded by the decoder. As such, the decoder has already accepted and / or determined a motion vector, a reference index, and a motion prediction direction for the causal part. As such, the decoder can simply extract the motion vector, reference index, and motion prediction direction associated with the causal part from the memory and copy these values as motion information for the current part. To restore the block in merge mode, the decoder obtains the predictive block using the obtained motion information for the current part, and adds residual data to the predictive block to restore the encoded block.

[0049] In AMVP, the encoder instructs the decoder, through the signaling of the bitstream, to only copy the motion vector from the candidate part and use the copied vector as a predictor for the motion vector of the current part, and signal the motion vector difference (MVD). The reference frame and the prediction direction associated with the motion vector of the current part are reported separately. MVD is the difference between the current motion vector for the current part and the motion vector predictor obtained from the candidate part. In this case, the encoder, using the motion estimate, determines the actual motion vector for the block to be encoded, and then determines the difference between the actual motion vector and the motion vector predictor as the MVD value. Thus, the decoder does not use an exact copy of the motion candidate vector as the current motion vector, as in the merge mode, but can instead use the motion candidate vector, which may be “close” in value to the current motion vector determined from the motion estimate , and add MVD to restore the current motion vector. To restore a block in AMVP mode, the decoder adds the corresponding residual data to restore the encoded block.

[0050] In most circumstances, MVD requires fewer signaling bits than the entire current motion vector. Also, AMVP provides more accurate signaling of the current motion vector, while at the same time supporting the coding efficiency of sending the entire motion vector. In contrast, the merge mode does not provide the MVD specification, and as such, the merge mode sacrifices the accuracy of the motion vector signaling for increased signaling efficiency (i.e., fewer bits). The prediction syntax for AMVP may include a flag for this mode (in this case, the AMVP flag), an index for the candidate part, an MVD between the current motion vector and a predictive motion vector from the candidate part, a reference index, and a motion prediction direction.

[0051] Once the motion estimation is performed to determine the motion vector for the current part, the encoder compares the matching part in the reference frame with the current part. This comparison typically involves subtracting the part (which is commonly referred to as the “reference sample”) in the reference frame from the current part and yields the so-called residual data, as mentioned above. The residual data indicates the pixel difference between the current part and the reference sample. The encoder then converts this residual data from the spatial domain to a transform domain, such as a frequency domain. Typically, an encoder applies a discrete cosine transform (DCT) to residual data to achieve this transform. The encoder performs this conversion in order to facilitate compression of the residual data, since the resulting conversion coefficients represent different frequencies, in which most of the energy is usually concentrated on several low-frequency coefficients.

[0052] Typically, the resulting transform coefficients are grouped in a manner that allows encoding of series lengths, especially if the transform coefficients are first quantized (rounded). The encoder performs this encoding of the lengths of the series of quantized transform coefficients and then performs lossless statistical encoding (or the so-called "entropy") to further compress the series-encoded quantized transform coefficients.

[0053] After performing lossless entropy encoding, the encoder generates a bit stream that includes encoded video data. This bitstream also includes the number of prediction syntax elements in some cases that specify whether, for example, motion vector prediction has been performed, motion vector mode, and motion vector predictor index (MVP) (i.e., the candidate part index with the selected vector movement). The MVP index may also be referred to as its name "mvp idx" syntax element variable.

[0054] In the current structure proposed for adoption by ITU-T / ISO / IEC by an integrated joint team for video coding (JCT-VC) called high-performance video coding (HEVC), the encoder performs a number of motion vector prediction modes to predict the motion vector for the current part, including 1) AM VP and 2) the merge mode described above. The two modes are similar, although AMVP provides more flexibility in terms of the ability to define MVDs, motion prediction directions and reference indices, while the merge mode simply copies this motion vector information (i.e., motion vector, motion prediction direction, and reference index) and does not take into account the increased accuracy of MVD.

[0055] FIG. 1A shows a set of candidate blocks 100 (or parts / blocks in a PU) currently proposed in the HEVC standard for use in AMVP mode, while FIG. 1B shows a set of candidate blocks 110 currently proposed in the HEVC standard for use in merge mode. AMVP mode uses six candidate blocks: the lower left (BL) block 101, the left (L) block 102, the upper right (RA) block 103, the upper (A) block 104, the upper left (LA) block 105, and the temporary block ( T) 106. It should be noted that in addition to the set of candidate blocks, the AMVP mode also determines the procedure for checking candidate blocks. In the example of FIG. 1A, the verification pattern is as follows: BL-L-RA-A-LA-T. As shown in FIG. 1B, the merge mode uses five candidate blocks: the lower left (BL) block 111, the left (L) block 112, the upper right (RA) block 113, the upper (A) block 114, and the temporary (T) block 115. The motion vectors associated with these candidate blocks are used to determine the motion vector predictor in merge mode and AMVP mode. Merge mode may use a similar validation pattern as AMVP, or may use a different validation pattern.

[0056] As described above, the AMVP mode uses six candidate blocks, while the merge mode uses five candidate blocks. In addition to the right upper (RA), lower left (BL), and temporary (T) blocks, the candidate blocks for AMVP mode and merge mode are in different locations. As such, a large number of candidate blocks must be stored and reviewed both during the encoding process and during the decoding process. In addition, the validation pattern for AMVP may not be optimal, since the lower left block may not be available in all circumstances. Such circumstances include when the lower left block has not yet been encoded (for example, it crosses the cut border or CU), or if the data for the lower left block is corrupted.

[0057] In this disclosure, a combined set of candidate blocks is proposed for both the AMVP mode and the merge mode. Typically, the same set of candidate blocks is used, regardless of which motion vector prediction mode is used (e.g., merge mode or AMVP mode). Also, less memory is needed in order to save motion vectors, and other information related to external prediction (for example, a reference frame, prediction direction, etc.). In other examples of this disclosure, methods are provided for using a set of candidate blocks that includes an additional candidate block. In addition, methods for a more optimal check pattern are also disclosed.

[0058] FIG. 2 is a block diagram illustrating an example video encoding and decoding system 10 that can be configured to use methods for predicting a motion vector in accordance with examples of this disclosure. As shown in FIG. 2, system 10 includes a source device 12 that transmits encoded video to a destination device 14 via a communication channel 16. Encoded video data can also be stored on a storage medium 34 or file server 36 and can be accessed by the destination device 14 if necessary. When stored on a storage medium or file server, video encoder 20 may provide encoded video data to another device, such as a network interface, a burning device or stamping compact disc (CD), Blu-ray or digital video disc (DVD), or other device , in order to save the encoded video data to the storage medium. Similarly, a device separate from the video decoder 30, such as a network interface, a CD or a DVD reader, or the like, can extract encoded video data from the storage medium and feed the extracted data to the video decoder 30.

[0059] The source device 12 and the destination device 14 may comprise any of a wide variety of devices, including desktop computers, laptop computers (that is, laptops), tablet computers, set-top boxes, handsets such as so-called smartphones, televisions , cameras, display devices, digital media players, video game consoles, or the like. In many cases, such devices may be equipped for wireless communication. Therefore, the communication channel 16 may comprise a wireless channel, a wired channel, or a combination of wireless and wired channels suitable for transmitting encoded video data. Likewise, destination device 14 can be accessed by file server 36 via any standard data connection, including an Internet connection. It can include a wireless channel (for example, a Wi-Fi connection), a wired connection (for example, DSL, cable modem, etc.) or a combination of both, which is suitable in order to access encoded video data, stored on a file server.

[0060] Methods for predicting a motion vector, in accordance with examples of this disclosure, can be applied to video encoding in support of any of a variety of multimedia applications, such as television broadcasts, cable television, satellite television, video streaming, for example, over the Internet, encoding digital video for storage on a storage medium, decoding a digital video stored on a storage medium, or other applications. In some examples, system 10 may be configured to support one-way or two-way video transmission to support applications such as video streaming, video playback, video broadcasting, and / or video telephony.

[0061] In the example of FIG. 2, source device 12 includes a video source 18, video encoder 20, modulator / demodulator 22, and transmitter 24. In source device 12, video source 18 may include a source, such as a video capture device, such as a video camera, video archive comprising previously captured video, a video feed interface for receiving video from a video content provider, and / or a computer graphics system in order to generate computer graphics data as source video, or a combination of such sources. As one example, if the video source 18 is a video camera, the source device 12 and the destination device 14 can form so-called camera phones or video phones. However, the methods described in this disclosure may be applicable generally to video encoding, and may be applied to wireless and / or wired applications, or an application in which encoded video data is stored on a local disk.

[0062] Captured, pre-captured, or computer generated video may be encoded by video encoder 20. The encoded video information may be modulated by modem 22 according to a communication standard, such as a wireless communication protocol, and transmitted to destination device 14 via transmitter 24. Modem 22 may include various mixers, filters, amplifiers or other components designed to modulate the signal. The transmitter 24 may include circuits designed to transmit data, including amplifiers, filters, and one or more antennas.

[0063] Captured, pre-captured, or computer generated video that is encoded by video encoder 20 may also be stored on a storage medium 34 or file server 36 for later use. The storage medium 34 may include Blu-ray discs, DVDs, CD-ROMs, flash memory, or any other suitable digital storage media in order to store encoded video. The encoded video stored on the storage medium 34 can then be accessed by the destination device 14 for decoding and playback.

[0064] File server 36 may be any type of server capable of storing encoded video and transmitting this encoded video to destination device 14. Example file servers include a web server (e.g. for a website), an FTP server, network attached storage (NAS) devices, a local disk drive, or any other type of device capable of storing encoded video data and transmitting him to the destination device. Transmission of encoded video data from file server 36 may be streaming, download transfer, or a combination of both. The file server 36 can be accessed by the destination device 14 through any standard data connection, including an Internet connection. It can include a wireless channel (e.g. Wi-Fi connection), a wired connection (e.g. DSL, cable modem, Ethernet, USB, etc.), or a combination of both that is suitable for access to encoded video data stored on a file server.

[0065] The destination device 14 in the example of FIG. 2 includes a receiver 26, a modem 28, a video decoder 30, and a display device 32. A receiver 26 from destination device 14 receives information on channel 16, and modem 28 demodulates the information to form a demodulated bitstream for video decoder 30. Information transmitted on channel 16 may include various syntax information generated by video encoder 20 for using video decoder 30 when decoding video data. Such syntax may also be included with encoded video data stored on a storage medium 34 or file server 36. Each video encoder 20 and video decoder 30 may be part of a corresponding decoder-encoder (codec) that is capable of encoding or decoding video data.

[0066] The display device 32 may integrate with, or be external to, the destination device 14. In some examples, the destination device 14 may include an integrated display device and also be configured to connect to an external display device. In other examples, the destination device 14 may be a display device. Typically, the display device 32 displays the decoded video data to the user, and may include any of a variety of display devices, such as a liquid crystal display (LCD), a plasma display, an organic light emitting diode (OLED) display, or another type of display device.

[0067] In the example of FIG. 2, communication channel 16 may comprise any wireless or wired communication medium, such as a radio frequency (RF) spectrum or one or more physical transmission lines, or any combination of wireless and wired media. Communication channel 16 may be part of a packet-based network, such as a local area network, a regional network, or a wide area network, such as the Internet. Communication channel 16 typically represents any suitable communication medium, or collection of various communication media, in order to transmit video data from source device 12 to destination device 14, including any suitable combination of wired or wireless media. Communication channel 16 may include routers, switches, base stations, or any other equipment that may be useful to facilitate communication from source device 12 to destination device 14.

[0068] Video encoder 20 and video decoder 30 may operate according to a video compression standard, such as the high-performance video encoding standard (HEVC) being developed, and may conform to the HEVC Test Model (HM). Alternatively, video encoder 20 and video decoder 30 may operate according to other proprietary or industry standards, such as ITU-T H.264, alternatively called MPEG-4, Part 10, Advanced Video Encoding (AVC), or extensions to such standards . The methods of this disclosure, however, are not limited to any particular coding standard. Other examples include MPEG-2 and ITU-T H.263.

[0069] Although not shown in FIG. 2, in some aspects, video encoder 20 and video decoder 30 may each integrate with an audio encoder and decoder, and may include respective MUX-DEMUX (multiplexer-demultiplexer) units, or other hardware and software to perform encoding as audio and video in the general data stream or in separate data streams. If applicable, the MUX-DEMUX units may conform to the ITU H.223 multiplexer protocol, or other protocols, such as the user datagram protocol (UDP).

[0070] Video encoder 20 and video decoder 30 can each be implemented as any of a variety of suitable encoder circuits, such as one or more microprocessors, digital signal processors (DSPs), specialized integrated circuits (ASICs), field programmable gate arrays (FPGAs) , discrete logic, software, hardware, firmware, or any combination thereof. When the methods are implemented in part in software, the device may store instructions for the software in a suitable non-transitory computer-readable medium and execute instructions in the hardware using one or more processors to perform the methods of the present disclosure. Each of video encoder 20 and video decoder 30 may be included in one or more encoders or decoders, any of which may be integrated as part of a combined encoder / decoder (codec) in a corresponding device.

[0071] Video encoder 20 may implement any of the methods of this disclosure for predicting a motion vector in a video encoding process. Similarly, video decoder 30 may implement any or all of these methods for predicting a motion vector in a video encoding process. A video encoder, as described in this disclosure, may refer to a video encoder or video decoder. Similarly, a video encoding device may refer to a video encoder or video decoder. Similarly, video encoding may relate to video encoding or video decoding.

[0072] In one disclosure example, video encoder 20 from source device 12 may be configured to determine one of a plurality of modes for the motion vector prediction process, and perform the motion vector prediction process for the current video data block using a specific mode and a set of candidate blocks, in which the set of candidate blocks is the same for each of the many modes.

[0073] In another disclosure example, video encoder 20 from source device 12 may be configured to determine one of a plurality of modes for a motion vector prediction process for a current block of video data, and perform a motion vector prediction process for a current block using a specific mode and set of blocks candidates, in which the set of candidate blocks is the same for each of the multiple modes, and in which one candidate block in the set of candidate blocks is defined as an additional candidate block, and in Oromo additional candidate block is used if the other of the set of candidate blocks of the candidate blocks is unavailable.

[0074] In another disclosure example, the video decoder 30 from the destination device 14 may be configured to receive a syntax element indicating one of a plurality of modes for the motion vector prediction process for the current block of video data, and receive an index indicating a candidate block from the set of blocks - candidates, in which the set of candidate blocks is the same for each of the multiple modes, and in which the information associated with the candidate block is used to decode the motion vector for the current block .

[0075] In another disclosure example, the video decoder 30 from the destination device 14 may be configured to receive a syntax element indicating one of a plurality of modes for the motion vector prediction process for the current block of video data, and receive an index indicating a candidate block from the set of blocks - candidates, in which the set of candidate blocks is the same for each of the many modes, in which one candidate block in the set of candidate blocks is defined as an additional candidate block, this additional ny candidate block is used if the other of the set of candidate blocks of the candidate blocks is unavailable and wherein the information associated with the candidate block, is used to decode the motion vector for the current block.

[0076] FIG. 3 is a flowchart illustrating an example of a video encoder 20 that can use methods for predicting a motion vector, as described in this disclosure. Video encoder 20 will be described in the context of HEVC coding for purposes of illustration, but without limiting this disclosure, to other coding standards or methods that may require scanning of transform coefficients. Video encoder 20 may perform internal and external encoding of CU units within video frames. Internal coding relies on spatial prediction to reduce or remove spatial redundancy in video data within a given video frame. External coding relies on temporal prediction to reduce or remove temporal redundancy between the current frame and previously encoded frames of the video sequence. The internal mode (I-mode) may refer to any of several based on the spatial compression of video modes. External modes such as unidirectional prediction (P-mode) or bidirectional prediction (B-mode) may refer to any of several based on temporal compression of video modes.

[0077] As shown in FIG. 3, the video encoder 20 receives the current video block within the video frame to be encoded. In the example of FIG. 3, video encoder 20 includes a motion compensation unit 44, a motion estimation unit 42, an intra prediction unit 46, a reference frame buffer 64, an adder 50, a transform unit 52, a quantization unit 54, and an entropy encoding unit 56. The conversion module 52 illustrated in FIG. 3 is a structure or device that applies an actual transform or combination of transforms to a residual data block, and should not be confused with a transform coefficient block, which may be referred to as a transform unit (TU) in a CU. To reconstruct a video block, video encoder 20 also includes an inverse quantization block 58, an inverse transform module 60, and an adder 62. A deblocking filter (not shown in FIG. 3) may also be included to filter the block boundaries to remove blocking artifacts from the recovered video. If desired, the deblocking filter may typically filter the output of the adder 62.

[0078] During the video encoding process, the encoder 20 receives a video frame or clip to be encoded. A frame or clip can be divided into multiple video blocks, for example, largest coding units (LCUs). The motion estimation unit 42 and the motion compensation unit 44 perform external predictive coding of the received video block relative to one or more blocks in one or more reference frames to provide temporal compression. The intra prediction unit 46 may perform intra predictive coding of the received video block relative to one or more neighboring blocks in the same frame or clipping as the block to be encoded to provide spatial compression.

[0079] The mode selection unit 40 may select one of the encoding modes, internal or external, for example, based on error results (that is, distortion) for each mode, and outputs a resulting internally or externally predicted unit (eg, a prediction unit (PU) ) to adder 50 to generate residual block data, and to adder 62 to restore the encoded block for use in the reference frame. An adder 62 combines the predicted block with the inverse quantized inverse transformed data from the inverse transform unit 60 for that block to recover the encoded block, as described in more detail below. Some video frames can be defined as I-frames, where all blocks in the I-frame are encoded in intra-prediction mode. In some cases, intra prediction block 46 may perform intra prediction coding of the block in a P or B frame, for example, when the motion search performed by motion estimation block 42 does not lead to sufficient block prediction.

[0080] The motion estimation unit 42 and the motion compensation unit 44 may be highly integrated, but individually illustrated for conceptual purposes. Motion estimation (or motion search) is the process of generating motion vectors that evaluate motion for video blocks. The motion vector, for example, may indicate the offset of the prediction block in the current frame relative to the reference sample of the reference frame. Motion estimation unit 42 calculates a motion vector for an externally encoded frame prediction block by comparing the prediction block with reference samples of a reference frame stored in the reference frame buffer 64. The reference sample may be a block that is found to closely match the portion of the CU, including the PU, encoded in terms of pixel difference, which can be determined by the sum of the absolute differences (SAD), the sum of the differences of the squares (SSD), or other difference metrics. The reference sample may be anywhere within the reference frame or reference clipping. In some examples, the reference sample may be in the fractional location of a pixel.

[0081] The portion of the reference frame identified by the motion vector may be referred to as a reference sample. Motion compensation unit 44 may calculate a prediction value for the prediction unit of the current CU, for example, by extracting a reference sample identified by a motion vector for the PU. In some video encoding methods, the motion estimation block 42 sends the calculated motion vector, reference frame, and prediction direction (i.e., the direction in terms of whether the reference frame precedes or follows the current frame) to entropy encoding block 56 and motion compensation block 44 . Other video encoding methods use a motion vector prediction process to encode a motion vector. The motion vector prediction process can be selected from among a variety of modes, including merge mode and AMVP mode.

[0082] In merge mode, the encoder considers a set of candidate blocks and selects a block that has the same (or most closely matches), motion vector, reference frame, and prediction direction as the current block. This is achieved by checking each candidate block in turn and choosing the one that leads to the best transmission rate - distortion efficiency as soon as its motion vector, reference frame, and prediction direction are copied to the current block. Then, instead of signaling this motion vector information (i.e., motion vector, reference frame and prediction direction) in the encoded video bit stream, the encoder signals the index number for the selected candidate block. The decoder can copy the motion vector information from the candidate block indicated by the signaling index, and use the copied motion vector information for the current block. FIG. 4A shows an example of merge mode signaling. A merge flag 201 indicates that a merge mode is being used. The candidate block index 202 indicates which of the candidate blocks from the set of candidate blocks defined for the merge mode should be used to extract motion vector information for the current block.

[0083] It should be noted that in some cases, in order to satisfy a specific number of candidates for a set of merge mode candidates, some “artificial” motion vector information may be generated to populate the set of candidates. This “artificial” motion vector information can be generated using partial combinations of motion vector information from various candidate blocks. For example, the motion vector of List 0 from candidate block 1 can be combined with the motion vector of List 1 from candidate 2, together with the reference frame index and prediction direction, to generate new motion vector information in the candidate set. In some other examples, null motion vectors may also be added as additional motion vector information to populate the candidate set. However, no matter how the candidate set is formed, in the merge mode only the index in the candidate set should be signaled to the decoder to indicate which candidate is selected to provide motion vector information for the current block. The same set of candidates is formed on the decoder side, and the motion vector information can be identified through the signalized index into the set of candidates.

[0084] In AMVP mode, the encoder considers a set of candidate blocks and selects a block that generates the difference of the motion vectors (that is, the difference between the motion vector of the corresponding candidate block and the actual motion vector of the current block), which leads to the best value "distortion - speed transmission "or satisfies some predetermined threshold (for example, the threshold" distortion - transmission speed "). AMVP mode may consider candidate blocks in a validation pattern until a satisfactory candidate is found and selected. Alternatively, in some examples, all candidate blocks can be checked, and the candidate block leading to the best result is selected as MVP for the block to be encoded. The encoder may then signal the index for the candidate block used to form the difference of the motion vectors, along with the difference of the motion vectors. The decoder can then update the motion vector for the current block by summing the received motion vector difference with the motion vector extracted from the candidate block indicated by the signaling index. FIG. 4B shows an example of AMVP mode signaling. The AMVP mode flag 205 indicates that AMVP mode is being used. The candidate block index 206 indicates which of the candidate blocks from the set of candidate blocks defined for the AMVP mode should be used to extract the motion vector. The AMVP mode also signals the difference of 207 motion vectors, the reference frame 208 and the prediction direction 209. In some examples, instead of explicitly signaling the reference frame and the prediction direction, the reference frame and the prediction direction are instead extracted from the motion vector information associated with the candidate block .

[0085] In the examples described above, signaling motion vector information in an encoded bit stream does not require real-time transmission of such elements from an encoder to a decoder, but instead means that such information is encoded in a bit stream and made available to the decoder in any way. This may include real-time transmission (e.g., in video conferencing), as well as storing the encoded bit stream on computer-readable media for future use by the decoder (e.g., in streaming, downloading, disk access, card access, DVD, Blu-ray, etc.).

[0086] In accordance with examples of this disclosure, the merge mode and AMVP mode use the same set of candidate blocks (that is, in terms of quantity and in terms of block location). Also, both the encoder and the decoder can reduce the amount of memory needed to store motion vector information for candidate blocks. It can also reduce the memory bandwidth requirement when recovering such motion vectors during the encoding process of the current block.

[0087] In the first disclosure example, the merge mode and the AMVP mode both use the same set of candidate blocks 120 shown in FIG. 5A. In this example, the merge mode will now use six candidate blocks instead of five. However, the total number of candidate blocks for both the merge mode and the AMVP mode is reduced, since both modes use candidate blocks at the same locations. In this example, candidate blocks are in the lower left (BL) 121, left (L) 122, left upper (LA) 125, upper (A) 124, upper right (RA) 123, and temporary (T) 126 positions, as shown in FIG. 5A. In this example, the left candidate block 122 is adjacent to the left edge of the current block 127. The lower edge of the left block 122 is aligned with the lower edge of the current block 127. The above block 124 is adjacent to the upper edge of the current block 127. The right edge of the above block 124 is aligned with the right edge of the current block 127.

[0088] In the second disclosure example, the AMVP mode and the merge mode use the set of candidate blocks 130 shown in FIG. 5B. In this example, the number of candidate blocks for AMVP mode has been reduced to 5. Further reduction of candidate blocks has been achieved since both merge mode and AMVP mode now use candidate blocks at the same locations. In this example, candidate blocks are located in the lower left (BL) 131, left (L) 132, upper (A) 134, upper right (RA) 133, and temporary (T) 135 locations. It should be noted that the locations of the above block 134 and the left block 132 are different from the locations of the above block 124 and the left block 122 in the example of FIG. 5A. In this example, the left candidate block 132 is adjacent to the left edge of the current block 137. The upper edge of the left block 132 is aligned with the upper edge of the current block 137. The above block 134 is adjacent to the upper edge of the current block 137. The left edge of the above block 134 is aligned with the left the edge of the current block 137. In one example, the check pattern for AMVP mode is as follows: BL-L-RA-T.

[0089] In the third disclosure example, the merge mode and the AMVP mode use the candidate block set 140 shown in FIG. 6. In this example, the number of candidate blocks has been reduced; both reducing the total for each mode to 5, and also combining the locations of the candidate blocks for both modes. In this example, the candidate blocks are in the lower left (BL) 141, left (L) 142, upper (A) 143, upper right (RA) 144, and temporary (T) 145. In this example, the left candidate block 142 is adjacent to the left edge of the current block 147. The lower edge of the left block 142 is aligned with the lower edge of the current block 147. The above block 143 is adjacent to the upper edge of the current block 147. The right edge of the above block 143 is aligned with the right edge of the current block 147.

[0090] In another example, the disclosure describes an improved verification pattern for AMVP mode. As shown in FIG. 7, for example, the verification pattern is as follows: L-BL-A-RA-LA-T. Instead of starting at the BL candidate block, as shown in FIG. 1A, the example of FIG. 7 starts at candidate block L. The blocks on the left side are usually more correlated to the current block, since video content typically moves horizontally. The candidate block L is checked first, since the candidate block BL may not be available (that is, it may not have already been encoded) in all situations. In addition, candidate block A is checked before the candidate block RA, since the motion vector of block candidate A has been shown to have a higher statistical correlation to the motion vector of the current block than that of the candidate block RA.

[0091] The merge mode may use the same validation pattern shown in FIG. 7, or may use a different validation pattern. As one example, a check pattern for a merge mode may be as follows: L-A-RA-BL- (LA) -T. In this example, the inclusion of an LA block is optional or adaptive depending on if one of the first four candidate blocks is unavailable.

[0092] The example of FIG. 7 is shown with respect to a set of candidate blocks in FIG. 5A. However, this validation pattern may be applicable to any set of candidates. Usually the left candidate block should be checked before the lower left candidate block. Then, the above candidate block should be checked in front of the upper right candidate block. Any remaining candidate blocks can then be checked in any order. In some examples, the temporary candidate block may be checked last.

[0093] In another example disclosure, flexible additional candidates are disclosed for both the merge mode and the AMVP mode. As shown in the example of FIG. 5A, there are five spatial candidate blocks (i.e., L, BL, A, RA, and LA) and one temporary candidate block (i.e., T), for a total of six candidate blocks. In the previous sentence to the HEVC standard, the maximum number of candidate blocks for the merge mode is five. Also, one of the candidate blocks shown in FIG. 5A may be deleted for merge mode. In one example, an LA candidate block can be defined as an additional candidate block (that is, it is not initially considered as part of a set of candidate blocks for the merge mode).

[0094] However, as mentioned above, not all candidate blocks are available in all situations. For example, a BL candidate block may not yet be encoded while the current block is being encoded. In addition, the data for some candidate blocks may become corrupt or may not be received at all (for example, when decoding in real time). Also, the present disclosure proposes the use of additional candidate blocks in situations where it is found that the candidate block in the set is not available. Thus, the total number of candidates is kept equal to the maximum limit, without wasting a check on an inaccessible candidate.

[0095] In one example, candidates L and BL are first checked by an encoder or decoder, as applicable. If one of these candidate blocks is not valid (for example, damaged), or unavailable, an additional candidate block (for example, LA) can be used instead. If both candidate blocks L and BL are valid, candidate blocks A and RA are checked. If one of these candidate blocks is not valid or not available, the LA candidate block may be used instead. If both candidate blocks A and RA are valid, then candidate block LA will not be used. In this example, the block candidate LA is used as an additional block candidate. However, any additional candidate block at any causal position (i.e., at a position relative to the current block where the candidate block has already been encoded) relative to the current block can be used.

[0096] In another example, all candidate blocks shown in FIG. 5A. For the merge mode, where the maximum number of candidate blocks is N (where N is less than 6), the first N available candidate blocks in the check pattern will be used as candidate blocks for the merge mode. In the example of FIG. 5A there are six candidate blocks with a validation pattern L-RA-BL-LA-T. The first N available candidate blocks in the test pattern will form the final set of candidate blocks for the merge mode. In this example, the validation pattern is fixed. In another example, a validation pattern may be selected based on block size, partition size, and / or partition index. In another example, the verification pattern may be updated adaptively during encoding and decoding. The update may depend on the merge index, motion vector prediction mode, separation size, separation index and / or motion vector information (e.g., reference index, motion vector difference, motion vector predictor) of previously encoded / decoded blocks.

[0097] According to another example, methods for using an additional candidate block can also be applied to AMVP mode. The AMVP mode in the current working draft of the HEVC standard already takes into account the verification of all six candidate blocks shown in FIG. 5A. However, as mentioned above, some of these candidate blocks may be unavailable or invalid. In such a case, an additional merger candidate may be determined. Such a merger candidate may be in any position that is causal to the current PU.

[0098] Returning to FIG. 3, the intra prediction block 46 may perform intra prediction with respect to the received block, as an alternative to the inter prediction performed by the motion estimation block 42 and the motion compensation block 44. The intra prediction block 46 may predict the received block relative to neighboring, previously encoded blocks, for example, blocks above, above and to the right, above and to the left, or to the left of the current block, taking the coding order from left to right from top to bottom for the blocks. Block 46 intra prediction can be configured using many different modes of intra prediction. For example, intra prediction unit 46 may be configured using a number of directional prediction modes, for example, thirty-four directional prediction modes, based on the size of the encoded CU.

[0099] The intra prediction unit 46 may select an intra prediction mode, for example, calculating prediction error values for various intra prediction modes and selecting a mode that results in the lowest error value. Directional prediction modes may include functions to combine the values of spatially adjacent pixels and apply the combined values to one or more pixel positions in the PU. Once the values for all the pixel positions in the PU have been calculated, the intra prediction unit 46 may calculate the error value for the prediction mode based on the pixel differences between the calculated or predicted PU values and the received original block to be encoded. Inter prediction unit 46 may continue to check intra prediction modes to intra prediction mode until an acceptable error value is detected. Inter prediction unit 46 may then send the PU to adder 50.

[0100] Video encoder 20 generates a residual block by subtracting the prediction data calculated by the motion compensation block 44 or the intra prediction block 46 from the original encoded video block. The adder 50 represents the component or components that perform this subtraction operation. The residual block may correspond to a two-dimensional matrix of pixel difference values, where the number of values in the residual block is the same as the number of pixels in the PU corresponding to the residual block. The values in the residual block may correspond to the differences, that is, the error, between the values of the co-located pixels in the PU and in the original block to be encoded. Such an operation is applied to the components of both luminance and chrominance, so that the differences can be color or luminance differences depending on the type of block that is encoded.

[0101] Transformation unit 52 may generate one or more transformation units (TU units) from a residual block. Transform unit 52 selects a transform from among a plurality of transforms. The transform may be selected based on one or more encoding characteristics, such as block size, encoding mode, or the like. The transform unit 52 then applies the selected transform to the TU, producing a video block containing a two-dimensional array of transform coefficients.

[0102] The transform unit 52 may send the resulting transform coefficients to quantization unit 54. The quantization unit 54 may then quantize the transform coefficients. Entropy coding unit 56 may then scan the quantized transform coefficients in the matrix according to the scanning mode. The present disclosure describes entropy encoding unit 56 as performing a scan. However, it should be understood that in other examples, other processing units, such as quantization unit 54, may perform a scan.

[0103] Once the conversion coefficients are scanned into a one-dimensional array, entropy coding unit 56 may apply entropy coding, such as context adaptive variable-length coding (CAVLC), context adaptive binary arithmetic coding (CABAC) based on contextual syntax adaptive binary arithmetic coding (SBAC), or another way of entropy coding, to coefficients. Entropy coding can also be applied to syntax elements, such as syntax elements used in merge mode and AMVP mode.

[0104] To perform CAVLC, entropy encoding unit 56 may select a code with a variable code length for the character to be transmitted. Code words in VLC can be constructed so that relatively shorter codes correspond to more likely characters, while longer codes correspond to less likely characters. Thus, the use of VLC can achieve bit saving, for example, using codewords of equal length for each character to be transmitted.

[0105] To perform CABAC, entropy coding unit 56 may select a context model to apply to some context to encode characters to be transmitted. In the case of transform coefficients, the context may relate, for example, to whether neighboring values are nonzero or not. Entropy encoding unit 56 may also entropy encode syntax elements, such as a signal representing a selected transform. In accordance with the methods of this disclosure, entropy encoding unit 56 may select a context model used to encode these syntax elements based on, for example, the intra prediction direction for intra prediction modes, the scan position of the coefficients corresponding to the syntax elements, block type, and / or type of transformation, among other factors used to select a context model.

[0106] After entropy encoding by entropy encoding unit 56, the resulting encoded video may be transmitted to another device, such as video decoder 30, or archived for later transmission or retrieval.

[0107] In some cases, the entropy encoding unit 56 or another video encoder unit 20 may be configured to perform other encoding functions in addition to entropy encoding. For example, entropy coding unit 56 may be configured to determine coded block pattern (CBP) values for CUs and PUs. In addition, in some cases, entropy encoding unit 56 may encode the lengths of a series of coefficients.

[0108] The inverse quantization unit 58 and the inverse transform unit 60 apply inverse quantization and inverse transform, respectively, to restore the residual block in the pixel region, for example, for later use in reconstructing the reference block. Motion compensation unit 44 may calculate the reference block by summing the residual block with the predictive block formed from one of the frames of the reference frame buffer 64. Motion compensation unit 44 may also apply one or more interpolation filters to the reconstructed reference unit to calculate sub-integer pixel values for use in motion estimation. An adder 62 summarizes the reconstructed residual block with the motion compensated prediction block generated by the motion compensation block 44 to form the reconstructed video block for storing reference frames in the buffer 64. The reconstructed video block may be used by the motion estimation block 42 and the motion compensation block 44 as a reference block to externally encode the block in a subsequent video frame.

[0109] FIG. 8 is a block diagram illustrating an example of a video decoder 30 that decodes an encoded video sequence. In the example of FIG. 8, the video decoder 30 includes an entropy decoding unit 70, a motion compensation unit 72, an intra prediction unit 74, an inverse quantization unit 76, an inverse transform unit 78, a reference frame buffer 82, and an adder 80. The video decoder 30 in some examples may perform a decoding pass typically inverse to the coding pass described with respect to video encoder 20 (see FIG. 3).

[0110] The entropy decoding unit 70 performs an entropy decoding process with respect to the encoded bit stream to extract a one-dimensional array of transform coefficients. The entropy decoding process used depends on the entropy encoding used by video encoder 20 (e.g., CABAC, CAVLC, etc.). The entropy encoding process used by the encoder may be signaled in a coded bit stream or may be a predetermined process.

[0111] In some examples, entropy decoding unit 70 (or inverse quantization unit 76) may scan received values using a scan reflecting the scanning mode used by entropy encoding unit 56 (or quantization unit 54) of video encoder 20. Although coefficient scanning may be performed in the inverse quantization unit 76, the scan will be described for purposes of illustration as being performed by the entropy decoding unit 70. In addition, although it is shown as separate functional blocks for ease of illustration, the structure and functionality of the entropy decoding unit 70, the inverse quantization unit 76, and other blocks of the video decoder 30 can be highly integrated with each other.

[0112] The inverse quantization unit 76 inversely quantizes, that is, de-quantizes, the quantized transform coefficients provided in the bitstream and decoded by the entropy decoding unit 70. The inverse quantization process may include a conventional process, for example, similar to the processes proposed for HEVC, or defined by the H.264 decoding standard. The inverse quantization process may include using the quantization parameter QP computed by the video encoder 20 for the CU to determine the degree of quantization and, likewise, the degree of inverse quantization to be applied. The inverse quantization unit 76 may inverse quantize the transform coefficients either before or after the coefficients are converted from a one-dimensional array to a two-dimensional array.

[0113] The inverse transform unit 78 applies the inverse transform to the inverse quantized transform coefficients. In some examples, the inverse transform module 78 may determine the inverse transform based on signaling from the video encoder 20, or infer the transform from one or more encoding characteristics such as block size, encoding mode, or the like. In some examples, the inverse transform module 78 may determine the transform to apply to the current block based on the signaling transform in the root node of the quad tree for the LCU including the current block. Alternatively, a transformation may be reported at the root of the TU quad tree for the leaf CU in the LCU quad tree. In some examples, the inverse transform module 78 may apply a cascaded inverse transform in which the inverse transform module 78 applies two or more inverse transforms to the transform coefficients of the current decoded block.

[0114] The intra prediction block 74 may generate prediction data for the current block of the current frame, based on the signaled intra prediction mode and data from previously decoded blocks of the current frame.

[0115] According to examples of this disclosure, video decoder 30 may receive a prediction syntax from an encoded bitstream that identifies a motion vector prediction mode and associated motion vector information (eg, see Figs. 4A and 4B and related description). In particular, video decoder 30 may receive an index indicating a candidate block from a set of candidate blocks, in which the set of candidate blocks is the same for each of the plurality of modes, and in which information associated with the candidate block is used to decode a vector movements for the current block. The set of candidate blocks may be the sets shown in FIG. 5A, FIG. 5B or FIG. 6, or any other set of candidate blocks causal to the current block.

[0116] In the case where the syntax element indicates the merge mode, the video decoder is further configured to extract the motion vector, reference frame, and prediction direction associated with the candidate block having the received index, and perform an inter prediction process for the current block using the extracted motion vector, reference frame and direction of prediction.

[0117] In the case where the syntax element indicates an adaptive motion vector prediction (AMVP) mode, the video decoder is further configured to receive a reference frame index, a motion vector difference and a syntax element indicating a prediction direction to extract a motion candidate vector associated with by the candidate block having the adopted index, calculate the motion vector for the current block using the motion candidate vector and the difference of the motion vectors, and perform the inter prediction process using the calculated the first motion vector received reference picture index and prediction of the direction taken.

[0118] Regardless of the prediction mode, once the prediction direction, the reference frame index and the motion vector are determined for the current block, the motion compensation block forms a motion compensated block for the current block. These motion compensated blocks essentially re-create the predictive block used to generate the residual data.

[0119] The motion compensation unit 72 may form compensated motion blocks, possibly performing interpolation based on interpolation filters. Identifiers for interpolation filters, which should be used to evaluate motion with subpixel accuracy, can be included in syntax elements. The motion compensation unit 72 may use the interpolation filters that are used by the video encoder 20 during the encoding of the video block to calculate the interpolated values for the sub-integer pixels of the reference block. Motion compensation unit 72 may determine the interpolation filters used by video encoder 20 according to the received syntax information, and use these interpolation filters to form predictive blocks.

[0120] Additionally, the motion compensation unit 72 and the intra prediction unit 74, in the HEVC example, may use some of the syntax information (for example, provided by a quad tree) to determine the unit sizes of the LCUs used to encode the frame (s) of the encoded video sequence. Motion compensation unit 72 and intra prediction unit 74 may also use syntax information to determine partitioning information that describes how each unit of the CU frame of the encoded video sequence is divided (and similarly, how sub-CUs are divided). The syntax information may also include modes indicating how each CU is encoded (e.g., intra or inter prediction, and for intra prediction, intra prediction encoding mode), one or more reference frames (and / or reference lists containing identifiers for reference frames) for each externally coded PU, and other information to decode the encoded video sequence.

[0121] An adder 80 combines the residual blocks with corresponding prediction blocks generated by the motion compensation block 72 or the intra prediction block 74 to form decoded blocks. The decoded blocks, in fact, restore the originally encoded blocks subjected to loss due to quantization or other aspects of encoding. If desired, the deblocking filter may also be applied to filter decoded blocks to remove blocking artifacts. The decoded video blocks are then stored in a reference frame buffer 82, which provides reference blocks for subsequent motion compensation and also generates decoded video for presentation on a display device (such as the display device 32 of FIG. 2).

[0122] As mentioned above, the methods of this disclosure are applicable to both the encoder and the decoder. Typically, and as described above, the encoder uses the same set of candidate blocks to perform the motion vector prediction process (e.g., merge mode and AMVP mode). The decoder can then decode the motion vector based on the syntax elements received using the same set of candidate blocks used by the encoder. By combining candidate blocks for all motion vector prediction modes, the amount of memory that should store the motion vector information (e.g., motion vector, prediction direction, reference frame indices, etc.) is reduced. The memory bandwidth requirement for recovering motion vector information from those candidate blocks can also be reduced.

[0123] FIG. 9 is a flowchart illustrating an example video encoding method that can be performed by a video encoder, such as video encoder 20 according to FIG. 3. Video encoder 20 may be configured to determine a motion vector relative to a reference frame for the current video data block (900). Video encoder 20 may also determine one of a variety of modes (e.g., merge mode or AMVP) for the motion vector prediction process (901), and perform the motion vector prediction process for the current video data block using a specific mode and a set of candidate blocks. The set of candidate blocks is the same for each of the many modes.

[0124] A plurality of modes may include a merge mode and an adaptive motion vector prediction mode. FIG. 10 illustrates an example video encoding method when a motion vector prediction process is in a merge mode. In this case, the video encoder is further configured to determine the motion vector candidate from the set of candidate blocks, which leads to satisfactory distortion-transmission rate efficiency when its motion vector, reference frame, and prediction direction are copied to the current block (1001) and signals an index identifying a motion candidate vector (1002).

[0125] In one example, a set of candidate blocks may include an upper candidate block, a right upper candidate block, a left candidate block, a lower left candidate block, and a temporary candidate block. The left candidate block is adjacent to the left edge of the current block and the upper edge of the left candidate block is aligned with the main edge of the current block. The above candidate block is adjacent to, the top edge of the current block and the left edge of the above candidate block is aligned with the left edge of the current block.

[0126] In another example, the left candidate block is adjacent to the left edge of the current block, and the lower edge of the left candidate block is aligned with the lower edge of the current block. The above candidate block is adjacent to the top edge of the current block and the right edge of the above candidate block is aligned with the right edge of the current block.

[0127] In another example, a set of candidate blocks includes a left upper candidate block, an upper candidate block, a right upper candidate block, a left candidate block, a lower left candidate block, and a temporary candidate block.

[0128] FIG. 11 illustrates an example video encoding method when the motion vector prediction process is in AMVP mode. In this case, the video encoder is configured to determine the motion vector candidate from each candidate block in the set of candidate blocks (1101) and calculate the difference of the motion vectors between the motion vector for the current block and the motion vector of the candidate from each of the candidate blocks according to the pattern checks (1102). The video encoder is also configured to select one of the motion candidate vectors based on the calculated motion vector differences (1103) and signal an index identifying a candidate block having a selected one of the motion candidate vectors to signal the motion vector difference calculated with respect to selected one of the motion candidate vectors to signal a reference frame and signal a prediction direction (1104).

[0129] In one example, the set of candidate blocks includes an upper candidate block, a right upper candidate block, a left candidate block, a lower left candidate block, and a temporary candidate block. In this example, the validation pattern occurs in the following order: lower left candidate block, left candidate block, upper right candidate block, upper candidate block, temporary candidate block.

[0130] In another example, a set of candidate blocks includes a left upper candidate block, an upper candidate block, a right upper candidate block, a left candidate block, a lower left candidate block, and a temporary candidate block. The check pattern occurs in the following order: left candidate block, lower left candidate block, upper candidate block, upper right candidate block, left upper candidate block, temporary candidate block.

[0131] FIG. 12 is a flowchart illustrating an example video decoding method that may be performed by a video decoder, such as video decoder 30 of FIG. 3. Video decoder 30 may be configured to receive a syntax element indicating one of a plurality of modes for the motion vector prediction process for the current video data block (1201), and receive an index indicating a candidate block from a set of candidate blocks (1202), in which the set of candidate blocks is the same for each of the multiple modes, and in which the information associated with the candidate block is used to decode a motion vector for the current block. Many modes may include a merge mode and an adaptive motion vector prediction mode.

[0132] FIG. 13 is a flowchart illustrating an example video decoding method in a case where the motion vector prediction process is a merge mode. In this case, the video decoder is further configured to extract a motion vector, a reference frame, and a prediction direction associated with a candidate block having a received index (1301), and perform an inter prediction process on the current block using the extracted motion vector, reference frame, and direction predictions (1302).

[0133] In one example, a set of candidate blocks includes an upper candidate block, a right upper candidate block, a left candidate block, a lower left candidate block, and a temporary candidate block. The left candidate block is adjacent to the left edge of the current block and the upper edge of the left candidate block is aligned with the upper edge of the current block. The upper candidate block is adjacent to the upper edge of the current block and the left edge of the upper candidate block is aligned with the left edge of the current block.

[0134] In another example, the left candidate block is adjacent to the left edge of the current block, and the lower edge of the left candidate block is aligned with the lower edge of the current block. The upper candidate block is adjacent to the upper edge of the current block and the right edge of the upper candidate block is aligned with the right edge of the current block.

[0135] In another example, a set of candidate blocks includes a left upper candidate block, an upper candidate block, a right upper candidate block, a left candidate block, a lower left candidate block, and a temporary candidate block.

[0136] FIG. 14 is a flowchart illustrating an example video decoding method in the case where the motion vector prediction process is an AMVP mode. In this case, the video decoder is configured to receive the reference frame index, the motion vector difference and the syntax element indicating the direction of prediction (1401), and extract the motion candidate vector associated with the candidate block having the received index (1402). The video decoder is further configured to calculate a motion vector for the current block using a motion candidate vector and a motion vector difference (1403), and perform an inter prediction process using the calculated motion vector, a received reference frame index, and a received prediction direction (1404).

[0137] In one example, a set of candidate blocks includes an upper candidate block, a right upper candidate block, a left candidate block, a lower left candidate block, and a temporary candidate block, and a check pattern for the set of candidate blocks is in the following order: lower left candidate block, left candidate block, upper right candidate block, upper candidate block, temporary candidate block.

[0138] In another example, the set of candidate blocks includes a left upper candidate block, an upper candidate block, a right upper candidate block, a left candidate block, a lower left candidate block and a temporary candidate block, and a check pattern for a set of candidate blocks takes place in the following order: left candidate block, lower left candidate block, upper candidate block, right upper candidate block, left upper candidate block, temporary candidate block.

[0139] FIG. 15 is a flowchart illustrating another exemplary video encoding method that may be performed by a video encoder, such as video encoder 20 of FIG. 3. Video encoder 20 may be configured to determine a motion vector relative to a reference frame for the current video data block (1501), determine one of a plurality of modes for the motion vector prediction process for the current video data block (1502), and perform the motion vector prediction process for the current block, using a specific mode and a set of candidate blocks, in which the set of candidate blocks is the same for each of the many modes, and in which one candidate block in the set of candidate blocks is determined It is offered as an additional candidate block (1503). An additional candidate block is used if another of the candidate blocks of the set of candidate blocks is not available. Video encoder 20 may be further configured to update the check pattern based on one or more of a merge index, a specific mode, split size, reference frame index, motion vector difference, and motion vector prediction (1504).

[0140] The plurality of modes may include a merge mode and an adaptive motion vector prediction mode. The merge mode may have a maximum number of N candidate blocks for use in performing the motion vector prediction process. In this case, the motion vector prediction process is performed according to the check pattern, the check pattern determining the order for checking each of the candidate blocks in the set of candidate blocks. The set of candidate blocks is defined as the first N available candidate blocks in the set of candidate blocks along the check pattern. The validation pattern may be based on one or more of block size, partition size, and partition index. More specifically, for example, a check pattern for each different block size, split size, or split index can be updated or changed based on candidate selection statistics in many previous encoded blocks having the same block size, split size, or split index, and t .d.

[0141] In another example, a set of candidate blocks includes a lower left candidate block, a left candidate block, an upper candidate block, a right upper candidate block, a left upper candidate block, and a temporary candidate block. In this example, an additional candidate block is the upper left candidate block. However, the additional candidate block may be any candidate block that is in a causal relationship to the current block.

[0142] FIG. 16 is a flowchart illustrating another exemplary video decoding method that may be performed by a video decoder, such as video decoder 30 of FIG. 3. Video decoder 30 may be configured to receive a syntax element indicating one of a plurality of modes for the motion vector prediction process for the current video data block (1601), and receive an index indicating a candidate block from a set of candidate blocks in which the set candidate blocks is the same for each of a plurality of modes in which one candidate block in the set of candidate blocks is defined as an additional candidate block (1602). An additional candidate block is used if another of the candidate blocks of the set of candidate blocks is not available. The information associated with the candidate block is used to decode the motion vector for the current block.

[0143] A plurality of modes may include a merge mode and an adaptive motion vector prediction mode. FIG. 17 shows a decoding method when a received syntax element indicates that a merge mode is being used. In this case, the video decoder is further configured to extract a motion vector, a reference frame, and a prediction direction associated with a candidate block having a received index (1701), and perform an inter prediction process on the current block using the extracted motion vector, a reference frame, and direction of prediction (1702).

[0144] A merge mode can be defined as having a maximum number N candidate blocks for use in performing the motion vector prediction process. In this case, the motion vector prediction process can be performed according to the verification pattern, wherein the verification pattern determines the order with respect to verification of each of the candidate blocks in the set of candidate blocks. A set of candidate blocks is defined as the first N available candidate blocks in the set of candidate blocks along the check pattern. The validation pattern is based on one or more of block size, partition size, and partition index.

[0145] In another example, for both the merge mode and the AMVP mode, the set of candidate blocks may include a lower left candidate block, a left candidate block, an upper candidate block, a right upper candidate block, a left upper block candidate and temporary block candidate. The additional candidate block is the upper left candidate block. However, the additional candidate block may be any candidate block that is in a causal relationship to the current block.

[0146] FIG. 18 depicts a decoding method in the case where the received syntax element indicates that the AMVP mode is being used. In this case, the video decoder is further configured to receive a reference frame index, a motion vector difference and a syntax element indicating a direction of prediction (1801), and extract a motion candidate vector associated with the candidate block having the received index (1802). The video decoder is further configured to calculate a motion vector for the current block using a motion candidate vector and a motion vector difference (1803), and perform an inter prediction process using the calculated motion vector, a received reference frame index, and a received prediction direction (1804).

[0147] In one or more examples, the described functions may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted as one or more instructions or code, a computer-readable medium, and executed by a hardware-based processing unit. Computer-readable media may include computer-readable media that corresponds to a tangible medium, such as storage media, or communication media, including any medium that facilitates transferring a computer program from one place to another, for example, according to a communication protocol. In this method, a computer-readable medium can typically correspond to (1) material computer-readable storage media that is non-transitory or (2) a communication medium, such as a signal or carrier. Storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code, and / or data structures for implementing the methods described in this disclosure. A computer program product may include computer-readable media.

[0148] By way of example, and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage device, magnetic disk storage device, or other magnetic storage devices, flash memory, or any another medium that can be used to store the desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly referred to as a computer readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair cable, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then this coaxial cable , fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of media. It should be understood, however, that computer-readable storage media and storage media do not include connections, carriers, signals, or other temporary storage media, but are instead directed to non-temporal material storage media. The disc and disc, as used here, include a compact disc (CD), a laser disc, an optical disc, a digital versatile disc (DVD), a floppy disk and a blu-ray disc, where discs (disks) typically reproduce data in magnetic manner while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0149] Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, specialized integrated circuits (ASICs), user programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic scheme. Accordingly, the term “processor”, as used herein, may refer to any known structure or any other structure suitable for implementing the methods described herein. Also, in some aspects, the functionality described herein may be provided within specialized hardware and / or software modules configured for encoding and decoding, or integrated in a combined codec. Also, the methods could be fully implemented in one or more circuits or logic elements.

[0150] The methods of the present disclosure may be implemented in a wide variety of devices or apparatuses, including a cordless handset, integrated circuit (IC), or IC kit (eg, microprocessor kit). Various components, modules, or blocks are described herein to emphasize the functional aspects of devices configured to perform the disclosed methods, but not necessarily require the implementation of various hardware blocks. Instead, as described above, various units may be combined in a codec hardware unit or provided by a collection of interacting hardware units, including one or more processors, as described above, in conjunction with suitable software and / or firmware.

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

Claims (28)

1. A method of encoding a motion vector in the process of encoding a video, comprising:
determining one of a plurality of modes for the motion vector prediction process for the current block of video data to be encoded; and
the process of predicting the motion vector for the current block of video data using a specific mode and a set of candidate blocks, while the set of candidate blocks is the same for each of the many modes,
wherein the plurality of modes includes a merge mode and an adaptive motion vector prediction mode, and
wherein the set of candidate blocks includes a left upper candidate block, an upper candidate block, a right upper candidate block, a left candidate block, a lower left candidate block, and a temporary candidate block. 2. The method of claim 1, wherein the particular mode is a merge mode and wherein the method also comprises:
determining a motion candidate vector from a set of candidate blocks that satisfies the “distortion - transmission rate” threshold, and
signaling an index identifying a candidate motion vector. 3. The method of claim 1, wherein the specific mode is an adaptive motion vector prediction mode and wherein the method also comprises:
determining a motion candidate vector for each candidate block in the set of candidate blocks;
calculating the difference of motion vectors between the motion vector for the current block and the motion candidate vector for each of the candidate blocks according to the check pattern;
selecting one of the motion candidate vectors based on the calculated differences of the motion vectors; and
signaling an index identifying a selected one of the motion candidate vectors, the difference of the motion vectors being calculated relative to the selected one of the motion candidate vectors, a reference frame, and a prediction direction. 4. The method of claim 3, wherein the validation pattern occurs in the order starting from the left candidate block. 5. The method according to p. 3, in which the verification pattern occurs in the following order: the left candidate block, the transition to the lower left candidate block, the upper candidate block, the transition to the upper right candidate block. 6. The method according to p. 3, in which the verification pattern occurs in the following order: left candidate block, lower left candidate block, upper candidate block, upper right candidate block, left upper candidate block, temporary candidate block. 7. A device for encoding a motion vector in a video encoding process, comprising:
A video encoder configured to:
determine one of the many modes for the motion vector prediction process for the current block of video data to be encoded; and
perform the motion vector prediction process for the current block of video data using a specific mode and a set of candidate blocks, while the set of candidate blocks is the same for each of the many modes,
however, many modes includes a merge mode and an adaptive mode for predicting a motion vector, and
wherein the set of candidate blocks includes a left upper candidate block, an upper candidate block, a right upper candidate block, a left candidate block, a lower left candidate block, and a temporary candidate block. 8. The device according to claim 7, in which the specific mode is a merge mode and in which the video encoder is further configured to:
determine a motion candidate vector from a set of candidate blocks that satisfies the “distortion - transmission rate” threshold; and
signal an index identifying a motion candidate vector. 9. The device according to claim 7, in which the specific mode is the adaptive prediction mode of the motion vector and in which the video encoder is further configured to:
determine a motion candidate vector for each candidate block in the set of candidate blocks;
calculate the difference of motion vectors between the motion vector for the current block and the motion candidate vector for each of the candidate blocks according to the check pattern;
select one of the motion candidate vectors based on the calculated differences of the motion vectors; and
signal an index identifying the selected one of the motion candidate vectors, the difference of the motion vectors being calculated relative to the selected one of the motion candidate vectors, a reference frame, and a prediction direction. 10. The device according to claim 9, in which the verification pattern occurs in the order starting from the left candidate block. 11. The device according to claim 9, in which the verification pattern occurs in the following order: the left candidate block, the transition to the lower left candidate block, the upper candidate block, the transition to the upper right candidate block. 12. The device according to claim 9, in which the verification pattern occurs in the following order: left candidate block, lower left candidate block, upper candidate block, upper right candidate block, left upper candidate block, temporary candidate block. 13. A device for encoding a motion vector in a video encoding process, comprising:
means for determining one of a plurality of modes for the motion vector prediction process for the current block of video data to be encoded; and
means for performing a motion vector prediction process for the current video data block using a specific mode and a set of candidate blocks, wherein the set of candidate blocks is the same for each of the many modes,
however, many modes includes a merge mode and an adaptive mode for predicting a motion vector, and
wherein the set of candidate blocks includes a left upper candidate block, an upper candidate block, a right upper candidate block, a left candidate block, a lower left candidate block, and a temporary candidate block. 14. A computer-readable storage medium that stores instructions on it that, when executed, force one or more processors of the device to encode video data:
determine one of the many modes for the motion vector prediction process for the current block of video data to be encoded; and
perform the motion vector prediction process for the current block of video data using a specific mode and a set of candidate blocks, while the set of candidate blocks is the same for each of the many modes,
however, many modes includes a merge mode and an adaptive mode for predicting a motion vector, and
wherein the set of candidate blocks includes a left upper candidate block, an upper candidate block, a right upper candidate block, a left candidate block, a lower left candidate block, and a temporary candidate block. 15. A method of decoding a motion vector in the process of encoding a video, comprising:
determining one of a plurality of modes for the motion vector prediction process for the current video data block; and
determining a candidate block from the set of candidate blocks, wherein the set of candidate blocks is the same for each of the plurality of modes, and the information associated with the candidate block is used to decode a motion vector for the current block,
however, many modes includes a merge mode and an adaptive mode for predicting a motion vector, and
wherein the set of candidate blocks includes a left upper candidate block, an upper candidate block, a right upper candidate block, a left candidate block, a lower left candidate block, and a temporary candidate block. 16. The method of claim 15, further comprising:
receiving a syntax element indicating a motion vector prediction process in which the received syntax element indicates that the motion vector prediction process is a merge mode;
receiving an index indicating a candidate block;
extracting a motion vector, a reference frame, and a prediction direction associated with said candidate block having a received index; and
performing an inter prediction process with respect to the current block using the extracted motion vector, reference frame, and prediction direction. 17. The method of claim 15, further comprising:
receiving a syntax element indicating a motion vector prediction process, wherein the received syntax element indicates that the motion vector prediction process is an adaptive motion vector prediction mode;
receiving an index indicating a candidate block;
receiving an index of a reference frame, a difference of motion vectors and a syntax element indicating a direction of prediction;
extracting a motion candidate vector associated with the candidate block having the received index;
calculating a motion vector for the current block using a motion candidate vector and a difference of motion vectors; and
performing the inter prediction process using the calculated motion vector, the received reference frame index, and the adopted prediction direction. 18. The method of claim 17, wherein the validation pattern occurs in the order starting from the left candidate block. 19. The method according to p. 17, in which the verification pattern occurs in the following order: the left candidate block, the transition to the lower left candidate block, the upper candidate block, the transition to the upper right candidate block. 20. The method according to p. 17, in which the verification pattern occurs in the following order: left candidate block, lower left candidate block, upper candidate block, upper right candidate block, left upper candidate block, temporary candidate block. 21. A device for decoding a motion vector in the video encoding process, comprising:
A video decoder configured to:
determine one of the many modes for the motion vector prediction process for the current block of video data; and
determine a candidate block from the set of candidate blocks, wherein the set of candidate blocks is the same for each of the plurality of modes, and the information associated with the candidate block is used to decode a motion vector for the current block,
however, many modes includes a merge mode and an adaptive mode for predicting a motion vector,
wherein the set of candidate blocks includes a left upper candidate block, an upper candidate block, a right upper candidate block, a left candidate block, a lower left candidate block, and a temporary candidate block. 22. The device according to p. 21, in which the video decoder is also configured to:
accept a syntax element indicating the motion vector prediction process, wherein the received syntax element indicates that the motion vector prediction process is a merge mode;
accept an index indicating the candidate block;
extract a motion vector, a reference frame, and a prediction direction associated with a candidate block having a received index; and
perform an inter prediction process with respect to the current block using the extracted motion vector, reference frame, and prediction direction. 23. The device according to p. 21, in which the video decoder is also configured to:
receive a syntax element indicating a motion vector prediction process, wherein the received syntax element indicates that the motion vector prediction process is an adaptive motion vector prediction mode;
accept an index indicating the candidate block;
accept the reference frame index, the difference of the motion vectors and the syntax element indicating the direction of the prediction;
extract a motion candidate vector associated with the candidate block having the received index;
calculate the motion vector for the current block using the motion candidate vector and the difference of the motion vectors; and
perform the inter prediction process using the calculated motion vector, the received reference frame index, and the adopted prediction direction. 24. The device according to claim 23, wherein the verification pattern occurs in the order starting from the left candidate block. 25. The device according to p. 23, in which the check pattern occurs in the following order: the left candidate block, the transition to the lower left candidate block, the upper candidate block, the transition to the upper right candidate block. 26. The device according to p. 23, in which the verification pattern occurs in the following order: left candidate block, lower left candidate block, upper candidate block, right upper candidate block, left upper candidate block, temporary candidate block. 27. An apparatus for decoding a motion vector in a video decoding process, comprising:
means for determining one of a plurality of modes for the motion vector prediction process for the current block of video data; and
means for determining a candidate block from the set of candidate blocks, wherein the set of candidate blocks is the same for each of the plurality of modes, and in which the information associated with this candidate block is used to decode a motion vector for the current block ,
however, many modes includes a merge mode and an adaptive mode for predicting a motion vector,
wherein the set of candidate blocks includes a left upper candidate block, an upper candidate block, a right upper candidate block, a left candidate block, a lower left candidate block, and a temporary candidate block. 28. A computer-readable storage medium that stores instructions on it that, when executed, force one or more processors of the device to decode video data to:
determine one of the many modes for the motion vector prediction process for the current block of video data; and
determining a candidate block from the set of candidate blocks, wherein the set of candidate blocks is the same for each of the plurality of modes, and in which the information associated with said candidate block is used to decode a motion vector for the current block,
however, many modes includes a merge mode and an adaptive mode for predicting a motion vector,
wherein the set of candidate blocks includes a left upper candidate block, an upper candidate block, a right upper candidate block, a left candidate block, a lower left candidate block, and a temporary candidate block.

Images