TW201215152A - System and method for enhanced DMVD processing - Google Patents

Abstract

To let decoder side motion vector derivation (DMVD) coded blocks be decoded in parallel, decoder side motion estimation (ME) dependency on spatially neighboring reconstructed pixels can be removed. Mirror ME and projective ME are only performed on two reference pictures, and the spatially neighboring reconstructed pixels will not be considered in the measurement metric of the decoder side ME. Also, at a video decoder, motion estimation for a target block in a current picture can be performed by calculating a motion vector for a spatially neighboring DMVD block, using the calculated motion vector to predict motion vectors of neighboring blocks of the DMVD block, and decoding the DMVD block and the target block in parallel. In addition, determining a best motion vector for a target block in a current picture can be performed by searching only candidate motion vectors in a search window, wherein candidate motion vectors are derived from a small range motion search around motion vectors of neighboring blocks.

Description

201215152 VI. Description of the Invention [Technical Field] The present invention relates to a system and method for enhanced decoder side motion vector derivation (DMVD) processing. [Prior Art] In a conventional video coding system, a motion estimation (ME) can be performed at an encoder to obtain a motion vector of a motion prediction of a current coding block. The motion vector can then be encoded into a binary stream and transmitted to the decoder. This allows the decoder to perform motion compensation for the current decoded block. In some advanced video coding standards, such as H.264/AVC, macroblocks (MB) can be partitioned into smaller blocks for encoding, and motion vectors can be assigned to each sub-partition. Therefore, if the MB is divided into 4x4 blocks, there will be up to 16 motion vectors for the predictive type of coded MB, and up to 32 motion vectors for the double predictive type of coded MB, which may represent a significant burden. Considering that the mobile coding block has strong temporal and spatially associated mobile coding blocks, the motion estimation can be performed on the decoding side according to the reconstructed reference image or the reconstructed spatial neighboring block. This allows the decoder to derive the motion vector of the current block by itself, instead of receiving the motion vector from the encoder. This decoder side motion vector derivation (DM VD) method can increase the computational complexity of the decoder, but it can improve the efficiency of the existing video codec system by saving the bandwidth. On the decoder side, if the block is coded using the DMVD method, its motion vector can only be obtained after performing the decoder side motion estimation. This can affect parallel decoding implementation in two ways. First, if the decoder side moves

S -5- 201215152 Estimating the use of spatially adjacent reconstructed pixels, decoding of DM VD blocks can only begin after all adjacent blocks have been decoded, which contain pixels for motion estimation. Second, if a block is coded in DMVD mode, its motion vector can be used for motion vector prediction of its neighboring blocks. Therefore, the decoding procedure of the adjacent block, which uses the motion vector of the current DMVD coding block for motion vector prediction, can only start after the motion estimation of the current DMVD block is ended. Therefore, there is a dependency in the above procedure, where these dependencies can slow down decoding. In particular, processing on the decoder side is less suitable for parallel DMVD algorithms. Additionally, in some implementations, motion estimation on the decoder side may require a search among potential motion vector candidates in a search window. The search may be an exhaustive search or may rely on any of several known fast search algorithms. Even if a relatively fast search algorithm is used, it may be necessary to evaluate a significant number of candidates before finding the best candidate. This also represents inefficiency in the processing on the decoder side. SUMMARY OF THE INVENTION An embodiment is described with reference to the drawings. While discussing specific configurations and configurations, it should be understood that this is for illustrative purposes only. Those skilled in the art will recognize that other configurations and configurations can be used without departing from the spirit and scope of the description. It will be apparent to those skilled in the art that it can be used in a variety of other systems and applications as described herein. Disclosed herein are methods and systems for enhancing the processing of decoders in video compression/decompression systems. -6- 201215152 The enhanced processing described herein can occur in the context of a video encoder/decoder system that implements video compression and decompression, respectively. Figure 1 depicts an exemplary H.264 video encoder architecture 100 that may include its own MV export module 140, where H.2 64 is a video codec standard. The current video information can be provided from the current video block 110 in the form of a plurality of frames. The current video can be transmitted to the difference unit 111. The difference unit 111 can be part of a differential pulse code modulation (DPCM) (also known as core video coding) loop, which can include a motion compensation stage 1 22 and a motion estimation stage 1 18 . The loop also includes an intra prediction stage 120 and an in-frame interpolation stage 124. In some cases, the de-blocking device 1 2 6 can also be used in the loop. The current video can be provided to the difference unit 111 and to the motion estimation stage 1 18 . The motion compensation stage 122 or the in-frame interpolation stage 124 can produce an output through the switch 123, which can then be subtracted from the video block 11 to produce a remainder. The remainder can then be transformed and quantized at transform/quantization stage 112 and entropy encoded in block 112. The channel output is obtained at block 1 16 . The output of the motion compensation stage 122 or the in-frame interpolation stage 124 may be provided to the adder 133, which may also receive inputs from the inverse quantization unit 130 and the inverse transform unit 132. The latter two units can cancel the transformation and quantization of the transform/quantization stage 112. Inverse transform unit 132 may provide dequantization and de-transformation information back to the loop. The self MV export module 140 can implement the processing described herein for deriving a motion vector from a previously decoded pixel. The self MV export module 140 can receive the output of the deblocking filter 126 in the loop and can provide an output to the shift

S 201215152 Dynamic compensation stage 122. Figure 2 shows the h.264 video decoder 200 with its own centistroneous derivation module 21〇. Here, the decoder 200 for the encoder 1 of the i-th diagram may include a channel input 238 coupled to the entropy decoding unit 240. The output from decoding unit 240 may be provided to inverse quantization unit 242 and inverse transform unit 244, and to its own μV derivation module 210. The own MV export module 2 1 〇 can be coupled to the motion compensation unit 248. The output of the entropy decoding unit 240 may also be provided to an in-frame interpolation unit 254, which may feed the selector switch 223. The information from the inverse transform unit 244, and the motion compensation unit 248 or the inter-frame interpolation unit 254 as selected by the switch 223 may then be summed and provided to the in-loop deblocking unit 246, and fed back into the interframe interpolation. Unit 254. The output of the deblocking unit 246 in the loop can then be fed to the own MV derivation module 210. The encoder's own MV export module can be synchronized with the video decoder side. The self MV export module can be applied to the general video codec architecture instead, and is not limited to the 264 encoding architecture. The encoders and decoders described above, and the processes performed by them as described above, can be implemented in hardware, firmware, or software, or a combination of the above. In addition, any or more of the features disclosed herein can be implemented in hardware, software, firmware, or a combination of the above, including discrete or integrated circuit logic, application specific integrated circuit (ASIC) logic, and micro The controller can be implemented as part of a combination of a specific domain integrated circuit package or an integrated circuit package. The term "software", as used herein, means a computer program product, including a computer readable medium having computer program logic stored therein, to enable the computer system to perform one or more of the features disclosed herein and/or Or a combination of features. Dependency of spatially adjacent reconstructed pixels The decoder side motion estimation (ME) is based on those in which the current coding block in the reference picture can be moved with those of its spatially adjacent blocks and those of its temporally adjacent blocks. Associated assumptions. Figures 3 through 6 show different decoder side ME methods that can use different kinds of associations. The mirror type ME in Fig. 3 and the derivation type ME in Fig. 4 can be executed between the two reference frames by using time shift association. In the embodiment of FIG. 3, there may be two dual prediction frames (B frames) 310 and 315 between the forward reference frame 320 and the backward reference frame 330. Frame 310 can be the current coded frame. When the current block 3 40 is encoded, the mirrored ME can be executed to perform the motion vector by performing a search in the search windows 360 and 370 of the reference frames 320 and 330, respectively, as described above, when in the current input area of the decoder. When the block is not available, the mirror type ME can be executed by the two reference frames. Fig. 4 shows an exemplary derivation type ME program 400, which can use two front image reference frames, front image (FW) RefO (displayed as Reference frame 420) and FW Refl (shown as reference frame 430). These reference frames can be used to derive the motion vector of the current target block 440 in the current frame P (shown as frame 410). A search window 470 can be specified in reference frame 420 and a search path can be specified in search window 470. For each motion vector M V0 in the search path, the push-type motion vector MV1 can be determined in the search window 460 of the reference frame 430. For each pair

The S -9- 201215152 motion vector, MV0 and its associated motion vector MV1, can be calculated by (1) the reference block 480 pointed to by the MVO in the reference frame 420 and (2) by the MV1 in the reference frame 430. The metric between the reference blocks 450 pointed to, such as the sum of absolute differences. The motion vector MVO that produces the best metric 値 (e.g., the sum of the smallest absolute differences (SAD)) can then be selected as the motion vector of the target block 440. To improve the accuracy of the output motion vectors of the current block, some implementations may include spatially adjacent reconstructed pixels in the measurement metrics of the decoder side ME. In Fig. 5, the decoder side ME can be performed on spatially adjacent blocks by using spatial motion correlation. Table 5 shows an embodiment 500 that may employ one or more adjacent blocks 540 in the current image (or frame) 510 (shown here above and to the left of the target block 530). The generation of motion vectors based on the respective ones of the previous reference frame 520 and the subsequent reference frame 560, or the corresponding blocks 550 and 555, may be permitted, wherein the terms "front" and "back" mean chronological order. . The motion vector can then be applied to the target block 530. In one embodiment, the raster scan coding sequence can be used to determine spatially adjacent blocks above, to the left, to the top left, and to the top of the target block. This method can be used for frame detection, which uses both the front frame and the back frame to decode. The method exemplified in Fig. 5 can be applied to the available pixels of the spatially adjacent blocks in the current frame as long as the adjacent blocks are decoded earlier in the sequence scan coding order than the target block. In addition, this method can be applied to the mobile search by reference to the reference frame in the reference frame list of the current frame. The processing of the embodiment of FIG. 5 may occur as follows. First, one or more pixel blocks may be identified in the pre-frame of -10-201215152, wherein the identified block is adjacent to the target area of the current frame. Piece. The identified block motion search can then be performed based on the corresponding block in the subsequent reference frame at a time and the corresponding block in the previous reference frame. The mobile search produces a motion vector of the identified block. Alternatively, the motion vectors of adjacent blocks can be determined prior to identifying those blocks. The motion vector can then be used to derive the motion vector of the target block, which can then be used for motion compensation of the target block. This derivation can be performed using any suitable program known to those skilled in the art. Such procedures may be, for example but not limited to, weighted average or median filtering. If the current image has both backward and forward reference frames in the reference buffer, the same method for the mirrored ME can be used to obtain image level and block level adaptive search range vectors. Otherwise, if only the forward reference image is available, the above-mentioned method for the deductive ME can be used to obtain the image level and block level adaptive search range. The corresponding blocks of the previous and subsequent reconstruction frames in the chronological order can be used to derive the motion vector. This method is illustrated in Figure 6. To be encoded in target block 630 in current frame 610, the already decoded pixels are used, which may be in the corresponding block 640 of the previous image (shown here as frame 615) and in the next frame ( These pixels are found in the corresponding block 665 shown here as image 655). The first motion vector of the corresponding block 640 can be derived by performing a motion search through one or more blocks 650 of the reference frame (image) 620. Block 650 may be adjacent to a block corresponding to the corresponding block 64 0 of the previous image 615 in reference frame 620. One or more blocks 670 may be passed through a reference image (i.e., frame) 660.

The mobile search of S -11 - 201215152 derives the second motion vector of the corresponding block 665 of the next frame 655. Block 670 may abut one of the blocks 665 corresponding to the next frame 655 in another reference image 660. Based on the first and second motion vectors, the forward and/or backward motion vectors of the target block 630 can be determined. These latter motion vectors can then be used for motion compensation of the target block. The ME processing for this case can be as follows. First, a block is identified in the previous frame, wherein the identified block can correspond to the target block of the current frame. A first movement vector of the identified block of the previous frame may be determined, wherein the first motion vector may be defined relative to a corresponding block of one of the first reference frames. A block can be identified in a subsequent frame, where the block can correspond to the target block of the current frame. A second motion vector of the discerned block of the subsequent frame may be determined, wherein the second motion vector may be defined relative to a corresponding block of one of the second reference frames. The individual first and second motion vectors described above may be used to determine one or both of the target vectors. The same processing can be performed at the decoder. When the current image is encoded/decoded, the block motion vector between the previous frame 615 and the reference frame 620 can be obtained. These motion vectors can be used. The way ME determines the image level to adapt to the search range. In the case of a mirrored ME, the motion vector of the corresponding block and the block adjacent to the corresponding block space can be used to derive a block level adaptive search range. Since spatially adjacent reconstructed pixels can be used in the decoder side ME, decoding of a coded block in DM VD mode can only begin after all required spatial neighboring pixels have been decoded. This decoding dependency affects the efficiency of the parallel implementation of block -12-201215152 block decoding. In order for the DMVD encoded blocks to be decoded in parallel, the dependence of the decoder side ME on spatially adjacent reconstructed pixels can be removed. The mirror type ME and the derivation type ME in Figs. 3 and 4 can then be performed only on the two reference images, and the spatially adjacent reconstructed pixels can be ignored in the measurement metric of the decoder side ME. The spatially adjacent block ME in FIG. 5 can be replaced by the time-parallel block ME function shown in FIG. 6, that is, for the parallel block in the reference image instead of the space in the current image. The adjacent block performs the decoder side ME. This decoding strategy is illustrated in Figure 7. At 710, the DMVD encoding block can be received at the decoder. At 720, the ME can be executed. This can be done using the temporally reconstructed pixels in the reference image. Recreate pixels without using spatial neighbors. At 730, the DMVD coding block can be decoded. In an embodiment, the decoding can be performed in parallel with the decoding of the non-DM VD encoding block. Since the reconstructed reference picture is ready before the decoding of the current picture, so that the decoder side ME can only be performed on the reference picture, the DMVD coding block does not have decoding dependencies on spatially adjacent reconstructed pixels. Therefore, the DMVD coded block and the non-DMVD coded interframe coded block can be decoded in parallel. Motion Vector Prediction Dependency Although the above system and method can be used to solve the decoding dependence of spatially adjacent reconstructed pixels, there is still motion vector prediction dependency in the decoding process. In the H. 2 64/A VC standard, to remove motion vector redundancy, move a block

S -13- 201215152 Vectors can be predicted first from the motion vectors of their spatial or temporal neighbors. The difference between the final motion vector and the predicted motion vector can then be encoded into the bitstream transmitted to the decoder side. On the decoder side, to obtain the final motion vector of the current block, the predicted motion vector may be first calculated from the decoded motion vector of the spatial or temporal neighboring block, and then the decoded motion vector difference is added to the predicted motion vector to Get the final decoded motion vector of the current block. If DMVD mode is used, the decoder can derive the motion vector of the DMVD code block by itself. However, if a non-DMVD coding block is used, the motion vector can still be decoded in the above manner. Now, if a block is coded in the DMVD mode, its motion vector can only be obtained after executing the decoder side ME. If these motion vectors are to be used to predict the motion vector of the spatial neighboring blocks, the decoding of the spatial neighboring blocks can only be started after the decoder side ME of the DMVD encoding block is completed. This motion vector prediction dependency affects the efficiency of parallel implementation of block decoding. As shown in FIG. 8, when a current block is encoded, such as block 810, the motion vectors of four spatially adjacent blocks (A, B, C, and D) can be used to predict its motion vector. . If any of blocks A, B, C, and D are encoded in the DMVD mode, one of the following schemes can be applied to remove the motion vector dependency on the DMVD block. In an embodiment, if a spatially adjacent block is a DMVD block, its motion vector may be marked as unavailable in the motion vector prediction procedure. That is, the motion vector of the current block is predicted from the motion vector of the non-DMVD encoded adjacent block. This is shown in Figure 9. At 910, the current non-DMVD block can be received for the same -14-201215152 or more DMVD blocks. At 920, a determination can be made as to whether there is a spatially adjacent DMVD block compared to the current non-DMVD block. In particular, it is possible to determine whether or not there is a DMVD block of an adjacent non-DMVD block in any of the positions A...D shown in Fig. 8. If so, marking this DMVD block as a motion vector prediction for a non-DMVD block is not available. At 930, the motion vectors of the neighboring non-DMVD blocks can be used to predict the motion vector of the current non-DMVD block. At 940, the current non-DMVD block can be decoded. In an alternate embodiment, if there is a DMVD block of a spatially adjacent non-DMVD block in any of the locations A...D (see Figure 8), a different method can be used for decoding the non-DMVD block. This embodiment is shown in Fig. 10. At 1010, the decoder receives the current non-DMVD block with the same or more spatially adjacent DMVD blocks. At 1020, if a spatially adjacent block is a DMVD block, the motion vector of the DMVD block is calculated. At 1030, the calculated motion vector can be used to predict the motion vector of the current non-DMVD block. At 1040, the current non-DMVD block can be decoded with this predicted mobile vector. Since the calculated motion vector can be prepared before the decoder side ME is executed, the decoding procedure of the adjacent block, such as the current non-DMVD block, can be started immediately without waiting for the decoder side ME program of the DMVD coding block. carry out. Then, the DMVD coding block and the current non-DMVD coding block can be decoded in parallel. The moving vector of an adjacent DMVD block can be determined in any number of ways. For example, in one embodiment, the calculated motion vector of the DMVD block

S -15- 201215152 A weighted average of the spatially adjacent block motion vectors available for it. In an alternate embodiment, the calculated motion vector of the DMVD block may be a median filter for the spatially adjacent block motion vector available to it. In an alternate embodiment, the calculated motion vector of the DMVD block may be a weighted average of the temporal neighbor block motion vectors available for scaling. In an alternate embodiment, the calculated motion vector of the DMVD block may be the median filter of the temporally adjacent block motion vector available for scaling. In an alternate embodiment, the calculated motion vector of the DMVD block may be a weighted average of the spatially adjacent block motion vectors and the time-adjacent block motion vectors available for calibration. In an alternate embodiment, the calculated motion vector of the DMVD block may be a spatially adjacent block motion vector available for it and a median filter of the time-adjacent block motion vector available for scaling. With the above scheme, the motion vector prediction dependence on the DMVD block motion vector can be removed. In conjunction with the removal of the dependence of spatially adjacent reconstructed pixels, the decoder can decode the inter-frame coding blocks in parallel (whether they are encoded in DMVD mode or non-DMVD mode). This may allow for greater use of parallel implementations of decoders on multi-core platforms. Fast candidate search for motion vectors The ME of a DMVD block can be executed using a complete search within a search window, or using any other fast motion search algorithm, as long as the encoder and decoder use the same mobile search scheme. In an embodiment, an ME program based on a quick candidate can be used. Here, the mobile search program only checks for a relatively small candidate motion vector group -1615 201215152 instead of checking all possibilities in the search window. The encoder and decoder use the same candidates to avoid any mismatch. The candidate motion vector may be derived from spatially encoded neighboring blocks and temporally encoded neighboring blocks. The candidate motion vector can be refined by performing a small range motion search near such a motion vector. In an embodiment, all candidate motion vectors may be examined first and the best ones selected (e.g., producing a minimum absolute difference sum). A small range motion search can then be performed near this best candidate to get the final motion vector. In an embodiment, a small range of motion seeks may be performed near each candidate motion vector to refine, and an optimal refined candidate (e.g., having a minimum SAD) may be selected as the final motion vector. Implementation The method and system are disclosed herein by means of the functional blocks of the functions, features, and relationships of the method and system. Here, for convenience of description, at least some of the boundaries of these functional building blocks have been arbitrarily defined herein. Alternative boundaries can be defined as long as the specified functions and relationships are properly performed. One or more features disclosed herein can be implemented in hardware, software, firmware, and combinations of the above, including discrete or integrated circuit logic, application specific integrated circuit (ASIC) logic, and a microcontroller. And it can be implemented as part of a combination of a specific domain integrated circuit package or an integrated circuit package. The term "software", as used herein, means a computer program product, package

S -17-201215152 includes computer readable media having computer program logic stored therein to cause the computer system to perform a combination of one or more of the features and/or features disclosed herein. A software or firmware embodiment of the above process is illustrated in Figure 11. System 1100 can include a processor 1120 and a body of a PC 1110 that can include one or more computer readable media that can store computer program logic 1 140. The memory 1110 can be implemented as, for example, a hard disk and a drive, a removable medium such as a compact disc and a drive, or a read only memory (ROM) device. Processor 1120 and memory 1110 can communicate using any of a number of techniques known in the art, such as bus bars. The logic contained in memory 1110 can be read and executed by processor 1120. - or more I/O ports and/or I/O devices, collectively shown as I/O 1 130, may also be coupled to processor 1120 and memory 1110. Computer program logic 1140 may include logic modules 1150 through 1170. In an embodiment, logic 1150 may be responsible for the processing described above for the case where the current block is a DMVD block. Logic 1160 may be responsible for the processing described above for the case where the current block is a non-DMVD block. Logic 1170 may be responsible for the implementation of the fast candidate search for the above described motion vectors. While various embodiments of the invention have been disclosed herein, it is understood that The spirit and scope of the method and system. Therefore, the breadth and scope of the patent application should not be limited to any example embodiments disclosed herein. -18- 201215152 [Simplified Schematic] FIG. 1 is a block diagram of a video encoder system according to an embodiment. FIG. 2 is a block diagram of a video decoder system according to an embodiment. Figure 3 is a diagram showing a specular motion estimation (Μ E ) at the decoder in accordance with an embodiment. FIG. 4 is a diagram showing a derivation type 在2 at the decoder according to an embodiment. Figure 5 is a diagram showing spatially adjacent blocks ME of a decoder in accordance with an embodiment. Figure 6 is a diagram showing the juxtaposition of adjacent blocks ME at the time of the decoder according to the embodiment. Figure 7 is a flow chart showing the motion estimation and decoding of a DMVD coding block according to an embodiment. Figure 8 illustrates a current block and adjacent blocks available for decoding of the current block, in accordance with an embodiment. FIG. 9 is a flow chart showing motion estimation and decoding of a non-DMVD coded block according to an embodiment. Figure 10 is a flow chart showing the motion estimation and decoding of a non-DMVD coding block according to an alternative embodiment. Fig. 11 is a diagram showing the implementation of a software or firmware of an embodiment. [Main component symbol description] 100 : Video encoder architecture 11 〇 : Video block

S -19- 201215152 1 11 : Difference unit 112: Transform/Quantization stage 114: Block 1 1 8 : Motion estimation stage 120: In-frame prediction stage 122: Motion compensation stage 123: Switch 1 24: In-frame interpolation stage 126: In-loop deblocking furnace 1 3 0: inverse quantization unit 132: inverse transform unit 1 3 3: adder 140: self MV export module 2 0 0: video video decoder 210: self MV derivation mode Group 223: selector switch 2 3 8 : channel input 240: entropy decoding unit 242: inverse quantization unit 244: inverse transform unit 246: in-loop deblocking unit 248: motion compensation unit 254: inter-frame interpolation unit 3 1 〇: Double prediction frame -20 201215152 3 1 5 : Double prediction frame 320: Forward reference frame 3 3 0 : Back reference frame 340: Current block 3 6 0 : Search window 3 7 0 : Search window 41 0: current frame 420: reference frame 430: reference frame 440: current target block 450: reference block 460: search window 470: search window 5 0 0: embodiment 510: current image (or frame) 520: reference frame 5 3 0 : target block 5 4 0 : adjacent block 550: block 555. block 5 6 0 : reference frame 610: current frame 615: frame 62 0 : Reference frame

S -21 - 201215152 6 3 Ο : Target block 640: Block 650 · Block 6 5 5 : Image 660: Reference frame 665: Block 670: Block 810 · Block 1 1 0 0 : System 1 120: Processor 1 130: Input/Output 1140: Computer Program Logic 1 1 5 0: Logic Module 1 1 6 0 : Logic Module 1 170: Logic Module-22

Claims (1)

201215152 VII. Patent application scope 1. A decoder side motion vector derivation (DMVD) method, comprising: receiving a DMVD coding block and a non-DMVD coding block; for the DMVD coding block, using in a reference image Temporally reconstructed pixels are used to perform motion estimation (ME) without using spatially adjacent reconstructed pixels in the current image; for the non-DMVD coded block, the motion vector of the non-DMVD coded block is predicted and recovered from the received data Moving the vector difference; and decoding the DMVD coding block and the non-DMVD coding block in parallel. 2. The method of claim 1, wherein the predicting the motion vector of the non-DMVD coding block comprises: for the motion vector prediction of the non-DMVD coding block, encoding the DMVD adjacent to the non-DMVD coding block The block is considered unavailable; and the motion vector of one or more adjacent non-DMVD coded blocks is used to predict the motion vector of the non-DMVD block. 3. The method of claim 1, wherein the predicting the motion vector of the non-DMVD coding block comprises: calculating a motion vector of a DMVD coding block adjacent to the non-DMVD block; and using the calculated The motion vector is used to predict the motion vector of the non-DMVD coding block. The method of claim 3, wherein the calculating the motion vector of the DMVD coding block adjacent to the non-DMVD coding block comprises calculating the adjacent DMVD area. A weighted average of the motion vectors of blocks adjacent to the block space. 5. The method of claim 3, wherein the calculating a motion vector of the DMVD coding block adjacent to the non-DMVD coding block comprises: calculating a region adjacent to the adjacent DMVD block space The median of the block's motion vector is filtered. 6. The method of claim 3, wherein the calculating a motion vector of the DMVD coding block adjacent to the non-DMVD coding block comprises: calculating a time adjacent to the adjacent DMVD coding block. The weighted average of the scaled motion vectors of the block. 7. The method of claim 3, wherein the calculating a motion vector of the DMVD coding block adjacent to the non-DMVD coding block comprises: calculating a time zone adjacent to the adjacent DMVD block The median filter of the scaled motion vector of the block is filtered. 8. The method of claim 3, wherein the calculating a motion vector of the DMVD coding block adjacent to the non-DMVD coding block comprises: calculating a weighted average of: -24- 201215152 (a) a motion vector of a block adjacent to the adjacent DM VD block space, and (b) a motion vector of the block adjacent to the adjacent DMVD block time. The method of claim 3, wherein the calculating the motion vector of the DMVD coding block adjacent to the non-DMVD coding block comprises: calculating the following median filter: (a) a motion vector of a block adjacent to the adjacent DMVD block space, and (b) a motion vector of the block adjacent to the adjacent DMVD block time. 10. The method of claim 3, wherein the calculating a motion vector of the DMVD coding block adjacent to the non-DMVD coding block comprises: performing motion estimation based on a fast candidate, by using a small range The best candidate motion vector of the DMVD block is searched for, and the best candidate motion vector is selected according to whether the candidate motion vector produces a minimum sum of absolute differences. 11. A system for decoder side motion vector derivation (DMVD), comprising: a processor; and a memory in communication with the processor for storing a plurality of processing instructions to direct the processor: S-25-201215152 Receiving a DMVD coding block and a non-DMVD coding block; for the DMVD coding block, performing temporal motion estimation (ME) using temporally adjacent reconstructed pixels in the reference image without using spatial neighbors in the current image Reconstructing a pixel: predicting a motion vector of the non-DMVD coding block and recovering a motion vector difference from the received data for the non-DMVD coding block; and decoding the DMVD coding block and the non-DMVD coding block in parallel. 12. The system of claim 1, wherein the processing instruction directing the processor to predict a motion vector of the non-DMVD coded block comprises: directing the processor to perform motion vector prediction for the non-DMVD coded block, The .DMVD coded block adjacent to the non-DMVD coded block is treated as a non-observable processing instruction; and the processor is instructed to use the motion vector of one or more adjacent non-DMVD coded blocks to predict the non-DMVD block The motion vector is where the instruction is processed. The system of claim 11, wherein the processing instructions that direct the processor to predict a motion vector of the non-DMVD coded block include: directing the processor to calculate a neighboring block of the non-DMVD block a processing instruction of a motion vector of a DMVD coding block; and a processing instruction instructing the processor to use the calculated motion vector to predict the motion vector of the non--26-201215152 DM VD coding block. 14. The system of claim 13 wherein the processing instructions directing the processor to calculate a motion vector of the DM VD encoding block adjacent to the non-DM VD encoding block comprises: directing the processor A processing instruction for calculating a weighted average of the motion vectors of the blocks adjacent to the adjacent DMVD block space. 15. The system of claim 13, wherein the processing instructions instructing the processor to calculate a motion vector of the DMVD coding block adjacent to the non-DMVD coding block comprises: directing the processor to calculate The processing vector of the motion vector of the block adjacent to the adjacent DMVD block space is filtered. The system of claim 13, wherein the processing instructions for directing the processor to calculate a motion vector of the DMVD coding block adjacent to the non-DMVD coding block include: guiding the processor A processing instruction for calculating a weighted average of the scaled motion vectors of the blocks adjacent to the adjacent DMVD coded block time. The system of claim 13, wherein the processing instructions for directing the processor to calculate a motion vector of the DMVD coding block adjacent to the non-DMVD coding block include: guiding the processor A processing instruction for the median filtering of the scaled motion vector of the block adjacent to the adjacent DMVD block time is calculated. 18. The system of claim 13 wherein the processing instructions directing the processor to calculate a motion vector of the DMVD coding block adjacent to the non-DMVD coding block include: S -27 - 201215152 Guidance The processor calculates the following weighted average processing instructions: (a) a motion vector of a block adjacent to the adjacent DMVD block space, and (b) a time zone adjacent to the adjacent DMVD block. The movement vector of the block. 1. The system of claim 13 wherein the processing instructions directing the processor to calculate a motion vector of the DMVD coding block adjacent to the non-DMVD coding block include: directing the processor The following processing instructions for the median filter are calculated: (a) the motion vector of the block adjacent to the adjacent DMVD block space, and (b) the time zone adjacent to the adjacent DMVD block. The movement vector of the block. 20. The system of claim 13, wherein the processing instructions instructing the processor to calculate a motion vector of the DMVD coding block adjacent to the non-DMVD coding block comprises: directing the processor to perform execution based on The processing instruction of the motion estimation of the fast candidate selects the best candidate by searching for the best candidate motion vector of the DMVD block in a small range and according to whether the candidate motion vector produces the smallest sum of absolute differences. Move the vector. 21. A computer program product for decoder side motion vector export (DMVD), the program comprising non-transitory computer readable medium having computer program logic stored therein, the computer program logic comprising: logic, The processor receives the DMVD code block and the non-DMVD code -28-201215152 code block; logic, causing the processor to perform motion estimation for the DM VD code block using temporally adjacent reconstructed pixels in the reference picture ( ME), without using spatially adjacent reconstructed pixels in the current image; logic, for the processor to predict the motion vector of the non-DMVD coded block for the non-DM VD coded block and recover the motion vector difference from the received data And logic to cause the processor to decode the DMVD code block and the non-DMVD code block in parallel. 2. The computer program product of claim 21, wherein the computer program logic for causing the processor to predict a motion vector of the non-DMVD code block comprises: logic for the processor to use the non-DMVD code region Block motion vector prediction, treating DMVD coded blocks adjacent to the non-DMVD coded block as unavailable: and logic, causing the processor to predict using motion vectors of one or more adjacent non-DMVD coded blocks The motion vector of the non-DMVD block. The computer program product of claim 21, wherein the computer program logic for causing the processor to predict a motion vector of the non-DMVD block comprises: logic to cause the processor to calculate the non-DMVD block a motion vector of a neighboring DMVD coded block; and logic that causes the processor to use the calculated motion vector to predict the motion vector of the S-29-201215152 non-DMVD coded block. 2. The computer program product of claim 23, wherein the processor calculates a computer program logic for the motion vector of the DMVD code block adjacent to the non-DMVD code block: logic, The processor is caused to calculate a weighted average of the motion vectors of the blocks adjacent to the adjacent DMVD block space. 25. The computer program product of claim 23, wherein the computer program logic for causing the processor to calculate a motion vector of the DMVD code block adjacent to the non-DMVD code block comprises: logic, The processor calculates a motion vector median filter for the block adjacent to the adjacent DM VD block space. The computer program product of claim 23, wherein the computer program logic for causing the processor to calculate a motion vector of the DMVD code block adjacent to the non-DMVD code block comprises: logic, The processor calculates a weighted average of the scaled motion vectors of the blocks that are temporally adjacent to the adjacent DMVD coded block. 27. The computer program product of claim 23, wherein the computer program logic for causing the processor to calculate a motion vector of the DMVD code block adjacent to the non-DMVD code block comprises: logic, The processor calculates a scaled motion vector median filter for the block adjacent to the adjacent DMVD block time. The computer program product of claim 23, wherein the computer program logic for causing the processor to calculate a motion vector of the DMVD code block adjacent to the non-DMVD code block comprises: -30 - 201215152 Logic, which causes the processor to calculate the following weighted averages: (a) the motion vector of the block adjacent to the adjacent DMVD block space, and (b) the time adjacent to the adjacent DMVD block The moving vector of the block. 2. The computer program product of claim 23, wherein the computer program logic for causing the processor to calculate a motion vector of the DMVD code block adjacent to the non-DMVD code block comprises: logic, The processor calculates the following median filter: (a) the motion vector of the block adjacent to the adjacent DMVD block space, and (b) the time zone adjacent to the adjacent DMVD block. The movement vector of the block. The computer program product of claim 23, wherein the computer program logic for causing the processor to calculate a motion vector of the DMVD code block adjacent to the non-DMVD code block includes = logic, The processor performs motion estimation based on fast candidates, and searches for the best candidate motion vector of the DMVD block in a small range, and selects the best according to whether the candidate motion vector produces a minimum sum of absolute differences. Candidate movement vector. S -31 -