<p>The prediction comes in when actually adding the motion estimation to both frames t and t+1.  Consider a video of a ninja cutting a melon in half, but shot at a very short shutter speed, so as to freeze motion in each frame.  The motion estimator notices that the sword is moving between frame t and frame t+1.  (It also moved between frame t-1 and t, and also frame t+1 to t+2).  Frame t gets half the motion from t-1 to t and half the motion from t to t+1.  The latter half is the prediction.  Frame t+1 gets half the motion from t to t+1 and half the motion from t+1 to t+2.  In this way, the video does not appear to shift half a frame later than the audio.</p>

CC BY-SA 3.0
2016-11-29T01:53:36.660Z
So by estimating the motion of the frame **t+1** (based on frame t), we're also "predicting" half the motion of the frame **t+2** (the "starting points" of its own motion vectors)?
Arkoudinos
CC BY-SA 3.0
2016-11-29T02:49:59.307Z
Nothing in t+2 contributes to the estimation of frame t.  Frame t gets half its motion estimate from the immediate past (frame t-1) and the immediate future (frame t+1).  It doesn't use the full motion difference between t-1 and t or t and t+1.  It should use at most half of those motion vectors (minus it's own instantaneous motion).  It could use less than half, depending on how much blurring you want.
Michael Tiemann
CC BY-SA 3.0
2016-11-28T12:31:42.013Z
2016-11-28T12:31:42.013Z
Michael Tiemann
<p>As far as I understand, the motion estimation is a process, where when we have two frames <strong>t</strong> and <strong>t+1</strong> we search for the blocks/pixels that changed position and then encode that change with a motion vector. So in the end we have only the frame <strong>t</strong> and its encoded successor.</p>

<p>After that we use compensation in order to use these motion vectors, and further encode only the difference between the "vectorized" frame <strong>t+1</strong> and the frame <strong>t</strong>.</p>

<p>Firstly, am I right? Secondly, when the <strong>prediction</strong> issue comes into play? I'm reading about prediction all the time, but in the sequence I've described, I don't see any prediction happening anywhere.</p>

<compression>
Prediction and Motion Estimation
Arkoudinos
# Prediction and Motion Estimation

(Asked by: username_0 on 2016-11-28)

As far as I understand, the motion estimation is a process, where when we have two frames **t** and **t+1** we search for the blocks/pixels that changed position and then encode that change with a motion vector. So in the end we have only the frame **t** and its encoded successor.

After that we use compensation in order to use these motion vectors, and further encode only the difference between the "vectorized" frame **t+1** and the frame **t**.

Firstly, am I right? Secondly, when the **prediction** issue comes into play? I'm reading about prediction all the time, but in the sequence I've described, I don't see any prediction happening anywhere.

**Tags:** compression


---

## 1 answers

### Answer by username_1 on 2016-11-28. Score: 2 | Accepted answer

The prediction comes in when actually adding the motion estimation to both frames t and t+1. Consider a video of a ninja cutting a melon in half, but shot at a very short shutter speed, so as to freeze motion in each frame. The motion estimator notices that the sword is moving between frame t and frame t+1. (It also moved between frame t-1 and t, and also frame t+1 to t+2). Frame t gets half the motion from t-1 to t and half the motion from t to t+1. The latter half is the prediction. Frame t+1 gets half the motion from t to t+1 and half the motion from t+1 to t+2. In this way, the video does not appear to shift half a frame later than the audio.

> **Comments:**
> **username_0**: So by estimating the motion of the frame **t+1** (based on frame t), we're also "predicting" half the motion of the frame **t+2** (the "starting points" of its own motion vectors)?  
> **username_1**: Nothing in t+2 contributes to the estimation of frame t.  Frame t gets half its motion estimate from the immediate past (frame t-1) and the immediate future (frame t+1).  It doesn't use the full motion difference between t-1 and t or t and t+1.  It should use at most half of those motion vectors (minus it's own instantaneous motion).  It could use less than half, depending on how much blurring you want.  

---

