<div dir="ltr"><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><span style="background:transparent;margin-top:0pt;margin-bottom:0pt">Hi Em,</span></p><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><span style="background:transparent;margin-top:0pt;margin-bottom:0pt">Thanks for your suggestion!</span></p><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><span style="background:transparent;margin-top:0pt;margin-bottom:0pt">I changed my source pictures(*) and encoded them directly with lossless compression. The resolution of the source picture is 64x64 and the black block size is 16x16. I still can not explain the printed MV values(**), many of the values is 64. Do you have any clue to interpreting the result?</span></p><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><span style="background:transparent;margin-top:0pt;margin-bottom:0pt">The following command is what I executed in the experiment.</span></p><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><strong style="background:transparent;margin-top:0pt;margin-bottom:0pt"><span style="background:transparent;margin-top:0pt;margin-bottom:0pt">./x264 --log-level debug --input-res 64x64 -b 0 --partitions none --ref 1 --qp 0 -o /path/to/the/source/block_move_png.mkv /path/to/the/source/%02d.png</span></strong></p><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><br></p><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><span style="background:transparent;margin-top:0pt;margin-bottom:0pt">*: </span><a style="background:transparent;margin-top:0pt;margin-bottom:0pt;color:rgb(74,110,224)" target="_blank" href="https://drive.google.com/drive/folders/1PWtzsEc7udKczNfQ0MqVzkoF8BEt4kSw?usp=sharing" class="editor-rtfLink"><span style="background:transparent;margin-top:0pt;margin-bottom:0pt">https://drive.google.com/drive/folders/1PWtzsEc7udKczNfQ0MqVzkoF8BEt4kSw?usp=sharing</span></a></p><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><span style="background:transparent;margin-top:0pt;margin-bottom:0pt">**: </span><a style="background:transparent;margin-top:0pt;margin-bottom:0pt;color:rgb(74,110,224)" target="_blank" href="https://gist.github.com/dmvictor/712b82e015b1a46294e70bf5b0de4a1e" class="editor-rtfLink"><span style="background:transparent;margin-top:0pt;margin-bottom:0pt">https://gist.github.com/dmvictor/712b82e015b1a46294e70bf5b0de4a1e</span></a></p><p style="color:rgb(14,16,26);background:transparent;margin-top:0pt;margin-bottom:0pt"><br></p></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 2 Dec 2020 at 14:02, Emily Bowman <<a href="mailto:silverbacknet@gmail.com">silverbacknet@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"><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" target="_blank">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>
_______________________________________________<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>