Answers.Body: <p><sub>I am not sure of my answer. The explanation at the end of it.*</sub></p>
  
  <p>Yes. The number of frames should not change. With one possible exception, I know of.</p>
  
  <p>First of all, normally a compressor takes some steps.</p>
  
  <ul>
  <li><p>Grab a keyframe</p></li>
  <li><p>Compares the difference between groups of pixels and if the difference is below one defined parameter it uses the same data to render them.</p></li>
  <li><p>And now compares the difference between adjacent frames and again, if the difference is below a threshold it uses the same data, using the keyframe as a reference to be compared with.</p></li>
  </ul>
  
  <p>If the keyframe fails to load you see the glitches, where the image is smushed because you are seeing the "differences" of the frame, but with an incorrect reference image.</p>
  
  <hr>
  
  <p>The exception is that some programs need to round the number of frames after a keyframe. Let us imagine you defined a keyframe every 10 frames for easy calculations.</p>
  
  <p>Now your clip needs to have 105 frames. Some programs will render the exact number of frames, but some programs could try to render the full "group" of frames attached to the previous keyframe, trying to render 109 frames, or some other could try to end in a keyframe, 110 on this case.</p>
  
  <hr>
  
  <ul>
  <li>I am not sure about my answer because, although it as happened to me on some programs, I can not recall that it was specifically using the h264 codec.</li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-09-28T04:14:37.663Z
Answers.LastActivityDate: 2019-09-28T04:14:37.663Z
Answers.UserDisplayName: Rafael
Body: <p>I'm trying to understand how h.264 compression works. So far I have clear what I, P, and B frames are and how are they used. But I'm unsure of is if after this process the number of original input frames are kept or not.</p>
  
  <p>In other words, if a raw video file containing 20 frames going into a h.264 encoder block, will the output compressed file have same number of frames?    </p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-09-27T09:35:14.433Z
Comments.Text: Normally, yes. The encoding process will output all frames. Exceptions I can think of would be real-time streaming applications with a latency threshold.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-09-27T12:51:31.370Z
Comments.Text: Understood , thanks Gyan.
Comments.UserDisplayName: pplur
Tags: <h.264><compression>
Title: h264 compression keeps same number of frames?
UserDisplayName: pplur
ThreadText: # h264 compression keeps same number of frames?
  
  (Asked by: username_0 on 2019-09-27)
  
  I'm trying to understand how h.264 compression works. So far I have clear what I, P, and B frames are and how are they used. But I'm unsure of is if after this process the number of original input frames are kept or not.
  
  In other words, if a raw video file containing 20 frames going into a h.264 encoder block, will the output compressed file have same number of frames?
  
  **Tags:** h.264, compression
  
  > **Comments:**
  > **username_1**: Normally, yes. The encoding process will output all frames. Exceptions I can think of would be real-time streaming applications with a latency threshold.  
  > **username_0**: Understood , thanks username_1.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2019-09-28. Score: 0
  
  I am not sure of my answer. The explanation at the end of it.\*
  
  Yes. The number of frames should not change. With one possible exception, I know of.
  
  First of all, normally a compressor takes some steps.
  
  * Grab a keyframe
  * Compares the difference between groups of pixels and if the difference is below one defined parameter it uses the same data to render them.
  * And now compares the difference between adjacent frames and again, if the difference is below a threshold it uses the same data, using the keyframe as a reference to be compared with.
  
  If the keyframe fails to load you see the glitches, where the image is smushed because you are seeing the "differences" of the frame, but with an incorrect reference image.
  
  ---
  
  The exception is that some programs need to round the number of frames after a keyframe. Let us imagine you defined a keyframe every 10 frames for easy calculations.
  
  Now your clip needs to have 105 frames. Some programs will render the exact number of frames, but some programs could try to render the full "group" of frames attached to the previous keyframe, trying to render 109 frames, or some other could try to end in a keyframe, 110 on this case.
  
  ---
  
  * I am not sure about my answer because, although it as happened to me on some programs, I can not recall that it was specifically using the h264 codec.
  
  
  ---
  
  