<div dir="ltr"><div>Looks correct to me. Your input video is trash, so it's forced to use far more MVs than would be necessary, though they still all point in the same direction. After all, you first put it through one lossy compression (jpg), a second lossy compression with zero controls (x264 via ffmpeg), decompress it, and then encode that lossy with x264 via ffmpeg again. Open 
dot_move.mp4 in your favorite editor, crank up the contrast, and you can see just how much bleeding has resulted and how far from "pure white" it's become, especially along the right edge.</div><div><br></div><div>If you start with the original pngs instead, the MVs would be much simpler. (Though some will still point from all white to another all-white block, simply because the nature of direct prediction means that it may be cheaper to code that way that by explicitly resetting it to zero. That's why encoders do not make great input into mo-comp interpolation engines.)<br></div><div><br></div><div>-Em<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 1, 2020 at 5:10 AM 孫偉程 <<a href="mailto:dmvictor@gmail.com">dmvictor@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi x264 developers,<br><br>I want to get the Motion Vector(MV) during x264 encodes the video. After tracing the source code, I felt this line(*) in encoder\analyse.c could be the thing I want. For validation, I generated a video with one black dot moving from top left to top right on a pure white background. After that, I get the raw video and encoded it with x264. When I get the printed MV values(**), it doesn't make sense. Can somebody shed some light on what is going on? I want to get the MVs just after the motion estimation during the x264 encoding process.<br><br>The following three steps are the command I executed in the experiment.<br><br>1. ffmpeg -pattern_type glob -i '*.jpg' dot_move.mp4<br>2. ffmpeg -i dot_move.mp4 dot_move.yuv<br>3. ./x264 --log-level debug --input-res 64x64 -b 0 --partitions none --ref 1 -o /path/to/the/video/dot_move.264 /path/to/the/video/dot_move.yuv<br><br>Here(***) are the pictures and generated video I used for the experiment. Thank you!<br><br>*: <a href="https://gist.github.com/dmvictor/8d60eac9962fb762c74128f18fa57ec8#file-analyse-c-L40" target="_blank">https://gist.github.com/dmvictor/8d60eac9962fb762c74128f18fa57ec8#file-analyse-c-L40</a><br>**: <a href="https://gist.github.com/dmvictor/cb4f33c6296ce6d49e74ce5f991b8946" target="_blank">https://gist.github.com/dmvictor/cb4f33c6296ce6d49e74ce5f991b8946</a><br><div>***: <a href="https://drive.google.com/drive/folders/19a3p7pPoUXx_31eU5zzGGilIo-miwfEe?usp=sharing" target="_blank">https://drive.google.com/drive/folders/19a3p7pPoUXx_31eU5zzGGilIo-miwfEe?usp=sharing</a></div></div>
_______________________________________________<br>
x264-devel mailing list<br>
<a href="mailto:x264-devel@videolan.org" target="_blank">x264-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x264-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/x264-devel</a><br>
</blockquote></div>