[x264-devel] Get MV during the x264 encoding process

[孫偉程]

Hi Em,


Thanks for your suggestion!


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?


The following command is what I executed in the experiment.

*./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*


*:
https://drive.google.com/drive/folders/1PWtzsEc7udKczNfQ0MqVzkoF8BEt4kSw?usp=sharing

**: https://gist.github.com/dmvictor/712b82e015b1a46294e70bf5b0de4a1e



On Wed, 2 Dec 2020 at 14:02, Emily Bowman <silverbacknet at gmail.com> wrote:

> 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.
>
> 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.)
>
> -Em
>
> On Tue, Dec 1, 2020 at 5:10 AM 孫偉程 <dmvictor at gmail.com> wrote:
>
>> Hi x264 developers,
>>
>> 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.
>>
>> The following three steps are the command I executed in the experiment.
>>
>> 1. ffmpeg -pattern_type glob -i '*.jpg' dot_move.mp4
>> 2. ffmpeg -i dot_move.mp4 dot_move.yuv
>> 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
>>
>> Here(***) are the pictures and generated video I used for the experiment.
>> Thank you!
>>
>> *:
>> https://gist.github.com/dmvictor/8d60eac9962fb762c74128f18fa57ec8#file-analyse-c-L40
>> **: https://gist.github.com/dmvictor/cb4f33c6296ce6d49e74ce5f991b8946
>> ***:
>> https://drive.google.com/drive/folders/19a3p7pPoUXx_31eU5zzGGilIo-miwfEe?usp=sharing
>> _______________________________________________
>> x264-devel mailing list
>> x264-devel at videolan.org
>> https://mailman.videolan.org/listinfo/x264-devel
>>
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> https://mailman.videolan.org/listinfo/x264-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20201205/7e1e7e19/attachment.html>