Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-11-29T01:53:36.660Z
Answers.Text: 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)?
Answers.UserDisplayName: Arkoudinos
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-11-29T02:49:59.307Z
Answers.Text: 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.
Answers.UserDisplayName: Michael Tiemann
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-11-28T12:31:42.013Z
Answers.LastActivityDate: 2016-11-28T12:31:42.013Z
Answers.UserDisplayName: Michael Tiemann
Body: <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>
  
Tags: <compression>
Title: Prediction and Motion Estimation
UserDisplayName: Arkoudinos
ThreadText: # 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.  
  
  ---
  
  