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

Emily Bowman silverbacknet at gmail.com
Wed Dec 2 07:00:41 CET 2020


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20201201/89f1f563/attachment.html>


More information about the x264-devel mailing list