<p>This is a complex topic, with the exact algorithm unique to each encoder. </p>

<p>Below is a pseudocode <a href="http://forum.doom9.org/showthread.php?p=942548#post942548" rel="nofollow noreferrer">explanation</a> from a x264 developer. B-frames aren't accounted for, but basic logic should be similar.</p>

<pre><code>encode current frame as (a really fast approximation of) a P-frame and an I-frame.

if ((distance from previous keyframe) &gt; keyint) then
    set IDR-frame
else if (1 - (bit size of P-frame) / (bit size of I-frame) &lt; (scenecut / 100) * (distance from previous keyframe) / keyint) then
    if ((distance from previous keyframe) &gt;= minkeyint) then
        set IDR-frame
    else
        set I-frame
else
    set P-frame

encode frame for real.
</code></pre>

<p><code>scenecut</code> is the scene change threshold value. <code>0</code> means current frame is identical to previous frame, and <code>100</code> means it is completely different.</p>

<p><code>keyint</code> is the maximum permitted distance between two keyframes; <code>minkeyint</code> is the minimum.</p>

<p><code>IDR</code> (instantaneous decoder refresh) frames are keyframes such that no future frame requires to refer to a frame earlier than the IDR-frame for decoding. Not necessarily true for plain I-frames. </p>

CC BY-SA 3.0
2017-01-23T10:47:24.240Z
2017-01-23T11:24:34.370Z
2017-01-23T11:24:34.370Z
Gyan
<p>I'm reading a bit on I-frames and their counterparts, P-frames and B-frames. I understand the usage. I-frames are the key to the compression and following P and B-frames can use the data in I-frames to save on bits.</p>

<p>However, what I would find interesting is knowing how the encoder determines which frames should be I-frames and which should be P's and B's and pull their data from them. How does the encoder decide which frames will be I-frames?</p>

<hr>

<p>Side thoughts (you don't have to answer, but these are interesting and useful to me in the future): Are I-frames easier, as in faster, to find and extract than say extracting every 30th frame? If a video is a slide show with audio and no slide animations, are I-frames likely to coincide with slide changes? Would compression be better on a video made from slides images rather than the same images taken in via stream in real time?</p>

CC BY-SA 3.0
2017-01-23T10:20:32.613Z
Should I have used the [tag:keyframes] tag? Should there be an [tag:i-frames] tag or should it be a synonym?
user3643
CC BY-SA 3.0
2017-01-23T15:43:32.060Z
In addition to @Mulvya's fine answer, there is the case of older codecs and encoders that place I-frames at fixed intervals regardless of need. This was the era of the 'fixed-length GOP'.
Jim Mack
CC BY-SA 3.0
2017-01-23T22:26:05.440Z
'keyframe' is used in After Effects and other animation apps to describe a point on a timeline where a value is set. 'I-Frame' is more specific
stib
CC BY-SA 3.0
2017-01-24T03:56:09.540Z
The same term is used within ffmpeg and x264 code, and I suspect, most/all other codecs.
Gyan
<encoding><compression><h.264><keyframes>
How does the h.264 encoder determine where to put i-frames?
user3643
# How does the h.264 encoder determine where to put i-frames?

(Asked by: username_0 on 2017-01-23)

I'm reading a bit on I-frames and their counterparts, P-frames and B-frames. I understand the usage. I-frames are the key to the compression and following P and B-frames can use the data in I-frames to save on bits.

However, what I would find interesting is knowing how the encoder determines which frames should be I-frames and which should be P's and B's and pull their data from them. How does the encoder decide which frames will be I-frames?

---

Side thoughts (you don't have to answer, but these are interesting and useful to me in the future): Are I-frames easier, as in faster, to find and extract than say extracting every 30th frame? If a video is a slide show with audio and no slide animations, are I-frames likely to coincide with slide changes? Would compression be better on a video made from slides images rather than the same images taken in via stream in real time?

**Tags:** encoding, compression, h.264, keyframes

> **Comments:**
> **username_0**: Should I have used the [tag:keyframes] tag? Should there be an [tag:i-frames] tag or should it be a synonym?  
> **username_1**: In addition to @Mulvya's fine answer, there is the case of older codecs and encoders that place I-frames at fixed intervals regardless of need. This was the era of the 'fixed-length GOP'.  
> **username_2**: 'keyframe' is used in After Effects and other animation apps to describe a point on a timeline where a value is set. 'I-Frame' is more specific  
> **username_3**: The same term is used within ffmpeg and x264 code, and I suspect, most/all other codecs.  

---

## 1 answers

### Answer by username_3 on 2017-01-23. Score: 3

This is a complex topic, with the exact algorithm unique to each encoder. 
Below is a pseudocode explanation from a x264 developer. B-frames aren't accounted for, but basic logic should be similar.
encode current frame as (a really fast approximation of) a P-frame and an I-frame.

if ((distance from previous keyframe) > keyint) then
    set IDR-frame
else if (1 - (bit size of P-frame) / (bit size of I-frame) < (scenecut / 100) * (distance from previous keyframe) / keyint) then
    if ((distance from previous keyframe) >= minkeyint) then
        set IDR-frame
    else
        set I-frame
else
    set P-frame

encode frame for real.

scenecut is the scene change threshold value. 0 means current frame is identical to previous frame, and 100 means it is completely different.
keyint is the maximum permitted distance between two keyframes; minkeyint is the minimum.
IDR (instantaneous decoder refresh) frames are keyframes such that no future frame requires to refer to a frame earlier than the IDR-frame for decoding. Not necessarily true for plain I-frames.


---

