<p>I'm with AJ. Unless you know the characteristics of every player that might view this, it would be unwise to rely on a small sample of test results. Using a standard frame rate like 24 fps with a keyframe interval of 24 frames will give you essentially the same thing with no compromise in compatibility. The intermediate frames will be minimally small because there will be no detectable changes to encode.</p>

CC BY-SA 3.0
2015-03-01T02:06:20.593Z
yup, a bit-identical frame only takes about 15 bytes.  All macroblocks = skip, and CABAC compresses the repeated bit pattern for that very well.
Peter Cordes
CC BY-SA 3.0
2015-03-01T02:08:25.897Z
I'd only worry about hardware players that are assuming they'll output to a 60 or 50Hz TV signal, though.  h.264 doesn't care about timing, it's just frames, even in a VFR video.  Frame timestamps is a container issue.  Container formats are very flexible.  It's easily possible to have a single frame shown for 1 minute, then 150fps for several frames, then another frame shown for a while, or anything you like.  Storing VFR video in mkv, mp4, and some other modern containers is a solved problem.
Peter Cordes
CC BY-SA 3.0
2013-08-16T16:36:01.767Z
2013-08-16T16:36:01.767Z
Jim Mack
<p>I'm not sure how it will behave at very low frame rates, but it is worth pointing out this would also limit your options on how and when you could change frames since they would have to follow on the clock cycles.  What is more likely to work in this case is a long keyframe interval.  The majority of frames in a compression like H.264 only store the changes from the previous frame.  In the case of a still image, the compression ratios will be huge because very little (no) change occurs between frames.  I'm not sure that you would really pick up enough of a savings from dropping the frame rate to be worth the loss of control over when you can make a change to the frame.</p>

<p>The best bet would be to try it with your media and see the results.  Compression is a highly content dependent thing and the best quality and compression for any particular clip is going to depend a lot on the nature of that clip, so trial is still the best way to test it out.</p>

CC BY-SA 4.0
2019-04-18T08:40:57.977Z
There is a compression downside beyond what my earlier comment on another answer said: If there is much redundancy between the different images (i.e. it's still a video, not a slideshow), padding with identical images will make it harder for the encoder to find and exploit that. Depending on encoding settings, the encoder will only keep some number of old frames as possible references for new frames, and can only search within a GOP (e.g. default 250 frames for x264).  If all those candidates are the same image, that doesn't give it multiple options to find a better reference for each block...
Peter Cordes
CC BY-SA 4.0
2019-04-18T08:41:05.287Z
... e.g. after a foreground object moves in front of some background detail, the encoder can save bits by referencing what it looked like in an older frame before it was obscured.  h.264 can choose reference frames on a per-block basis.  This is a relatively small effect; good h.264 encoders do ok with only 1 reference frame, but it's still somewhat harmful to compression efficiency
Peter Cordes
CC BY-SA 4.0
2019-04-18T11:19:06.517Z
Sure, you still need proper encoding settings, but you can grow your GOP size rather than reduce your frame rate if things are all that static.  If they aren't, then dropping frame rate isn't a great option to begin with.  I wonder if there has been any work on a variable GOP format.
AJ Henderson
CC BY-SA 4.0
2019-04-18T11:41:20.857Z
I think repeated images are still going to reduce the opportunity for useful B-pyramid and multiple reference P-frames options.  But I guess an encoder can keep an old P frame from anywhere within the GOP so losing out on reference B-frames is probably all in theory, but IDK about in practice.
Peter Cordes
CC BY-SA 4.0
2019-04-18T11:45:11.050Z
Most formats *are* variable GOP, and any good encoder will use that!  x264's default is to opportunistically end GOPs on scenecut detection, inserting an IDR frame.  (`keyint=250` is the *max* GOP length.  `keyint_min=25` is the minimum interval so it won't insert another keyframe even if it thinks it sees another scenecut; there are tuning options for scenecut bias, etc.)  x26**5** even has an extra GOP-lookahead parameter for opportunistically extending a GOP.  https://x265.readthedocs.io/en/default/cli.html#cmdoption-gop-lookahead.  And of course adaptive B-frame decisions are on by default
Peter Cordes
CC BY-SA 4.0
2019-04-18T12:05:57.303Z
Nice, amazing how much they've advanced since I last got in to the real nitty gritty of encoders.  I keep a high level overview but my last extreme deep dive was mpeg 2 era...  Might be time to do another deep dive on h265 though.
AJ Henderson
CC BY-SA 4.0
2019-04-18T12:27:20.267Z
Good MPEG-2 encoders can make keyframe decisions based on scenecuts, and P vs B frame decisions based on content. :P  ffmpeg's `mpeg2video` encoder lists a `-sc_threshold` option, and a `-b_strategy` option to control I/P/B selection strategy.  But anyway, h.265 is neat, with up to 32x32 DCT blocks, and very large 64x64 prediction units which can break down into smaller blocks if needed. https://sonnati.wordpress.com/2014/06/20/h265-part-i-technical-overview/.  vs. h.264 16x16 macroblocks with only 4x4 or 8x8 (high profile only) DCT blocks.  Also https://forum.doom9.org/showthread.php?t=167081
Peter Cordes
CC BY-SA 3.0
2013-08-16T15:30:34.987Z
2013-08-16T15:30:34.987Z
AJ Henderson
<p>I've played around with turning a bunch of still photos into a h.264 slideshow, mostly to compare the compression efficiency of JPG vs. h.264.  I got <a href="http://forum.doom9.org/showthread.php?t=145005" rel="nofollow noreferrer">some useful replies about the technical implications of this</a> from x264 devs on doom9.  e.g. force x264 to not use B frames for this, because not-very-related images will need a lot of I macroblocks, and coding them in B frames is more expensive.</p>

<p>Software player behaviour with low-fps video isn't ideal, in the past.  I think one older player only checked for keyboard input when it displayed a frame.  So there was lag between user input and player response.  mplayer2 and mpv don't have this problem.  Also, players that can only seek to keyframes will seek in really large chunks (2 minutes or so!) if you don't reduce the keyframe interval.  x264 won't insert IDR (GOP boundaries) all over the place if the images are somewhat related to each other.</p>

<p>Use <code>x264 -tune stillimage</code>.  It <a href="http://forum.doom9.org/showthread.php?p=1488646#post1488646" rel="nofollow noreferrer">cranks up the psy optimizations</a>, because temporal stability isn't an issue for this use-case.  Further search results: <a href="https://www.google.ca/search?q=x264%20stillimage%20site:forum.doom9.org" rel="nofollow noreferrer">from google</a>.</p>

<p>I'd agree with other suggestions to have some duplicated frames, to bring the FPS up to at least 5 or something, just in case of bad players.  However, smartphones / tablets should have no problem playing variable-FPS video, since they usually record that way when light levels drop.  Since variable-FPS videos from phones are now out there, hardware player support for them should be expected.  I wouldn't <em>expect</em> problems, but I also wouldn't be surprised if there at least some old hardware players that don't handle it well. </p>

<p>A frame of all "skip" macroblocks only takes about 20bytes at 1080p, IIRC.  One reason I don't like duplicated frames, though, is that it interferes with single-stepping to go through the images manually.</p>

<hr>

<p><strong>There is a compression downside to duplicating frames, though</strong>: If there is much redundancy between the different images (i.e. it's still a video, not a slideshow), padding with identical images will make it harder for the encoder to find and exploit that.</p>

<p>Depending on encoding settings, the encoder will only keep some number of old frames as possible references for new frames, and can only search within a GOP (e.g. default 250 frames for x264).  If all those candidates are the same image, that doesn't give it multiple options to find a better reference for each block.</p>

<p>e.g. After a foreground object moves in front of some background detail, the encoder can save bits by referencing what it looked like in an older frame before it was obscured.  h.264 can choose reference frames on a per-block basis.  This is a relatively small effect; good h.264 encoders do ok with only 1 reference frame, but it's still somewhat harmful to compression efficiency, and <strong>a waste of power / battery life / CPU time on the decompression side to copy memory around decoding and displaying extra frames.</strong></p>

<hr>

<h3>Recovering VFR after an NLE forces all your clips to some high frame rate:</h3>

<p>FFmpeg has an <code>mpdecimate</code> filter that drops similar frames.  You can set limits on how many frames in a row it can drop.  With a tight similarity threshold, you should get it to only drop actual duplicates.</p>

<p>e.g. <code>ffmpeg -i input.mp4 -vf mpdecimate=max=9:hi=400 -c:a copy -c:v libx264 -preset veryslow -tune film output_vfr.mkv</code> drops up to 9 frames in a row, and only if the most-different block was different under "400", and (defaults): no more than 33% of the blocks were different by "320" units.  IIRC, it's basically an 8x8 SAD on pixel components.</p>

<p>(FFmpeg defaults to CFR for <code>.mp4</code> outputs, though, so <strong>use <code>-vsync 2</code> for variable-frame-rate <code>.mp4</code> output</strong>.  I <em>think</em> that's safe: <a href="https://superuser.com/questions/602950/problems-with-frame-rate-on-video-conversion-using-ffmpeg-with-libx264">Problems with frame rate on video conversion using ffmpeg with libx264</a>)</p>

CC BY-SA 4.0
2015-07-13T23:06:49.507Z
2019-04-18T09:01:11.107Z
2019-04-18T09:01:11.107Z
Peter Cordes
<p>Most NLE's will allow you to import a still image in the form of how long you want it to appear in the timeline assuming you have set the project properties to some standard frame rate such as 30 fps or 24 fps etc.</p>

<p>In Vegas Pro I can set the time a still picture should appear on the timeline, from a fraction of second to several seconds. If I set this to 1 second then when I drag and drop a still image in the timeline, Vegas will generate enough frames to meet my request. I usually edit with 30 fps videos, and when I add a still picture I am mixing a timeline with 30 fps video that is already there (AVCHD 1080p).</p>

<p>To give you a specific answer, I would need to know what NLE you are using.</p>

CC BY-SA 3.0
2013-08-17T17:11:24.490Z
I just apply a raw encoding software such as `ffmpeg` or `avconv`, so no need to talk about any NLE. I think the question is pretty much answered with "Just go by a standard frame rate which all players can deal with properly. There is no real 'waste of resources', because the encoding scheme is good enough to efficiently deal with still images".
Jan-Philip Gehrcke
CC BY-SA 3.0
2013-08-16T22:02:08.057Z
2013-08-16T22:02:08.057Z
filzilla
<p>When making a video from single image files whereas each image file should be visible for about one second, it does make sense to encode a video with an extremely low frame rate such as 1 frame per second. For this type of application, every frame rate greater than this would be a waste of resources.</p>

<p>I am wondering if the H264 codec (or any specific implementation, such as x264) itself has any lower limit for the frame rate below which it comes to technical problems or some kind of instabilities. In case there is no problem with encoding, can we expect video players to properly deal with such an unusual low frame rate?</p>

<p>Thanks for sharing your experience!</p>

CC BY-SA 3.0
2013-08-16T18:08:40.593Z
Also see: [Producing stable video from slow images with FFmpeg](http://superuser.com/a/601916/110524) and [FFmpeg for animation of image files outputs all-black video](http://superuser.com/a/632473/110524).
llogan
<encoding><framerate>
Minimal working frame rate for H264 codec
Jan-Philip Gehrcke
# Minimal working frame rate for H264 codec

(Asked by: username_0 on 2013-08-16)

When making a video from single image files whereas each image file should be visible for about one second, it does make sense to encode a video with an extremely low frame rate such as 1 frame per second. For this type of application, every frame rate greater than this would be a waste of resources.

I am wondering if the H264 codec (or any specific implementation, such as x264) itself has any lower limit for the frame rate below which it comes to technical problems or some kind of instabilities. In case there is no problem with encoding, can we expect video players to properly deal with such an unusual low frame rate?

Thanks for sharing your experience!

**Tags:** encoding, framerate

> **Comments:**
> **username_1**: Also see: [Producing stable video from slow images with FFmpeg](http://superuser.com/a/601916/110524) and [FFmpeg for animation of image files outputs all-black video](http://superuser.com/a/632473/110524).  

---

## 4 answers

### Answer by username_2 on 2013-08-16. Score: 2 | Accepted answer

I'm with AJ. Unless you know the characteristics of every player that might view this, it would be unwise to rely on a small sample of test results. Using a standard frame rate like 24 fps with a keyframe interval of 24 frames will give you essentially the same thing with no compromise in compatibility. The intermediate frames will be minimally small because there will be no detectable changes to encode.

> **Comments:**
> **username_3**: yup, a bit-identical frame only takes about 15 bytes.  All macroblocks = skip, and CABAC compresses the repeated bit pattern for that very well.  
> **username_3**: I'd only worry about hardware players that are assuming they'll output to a 60 or 50Hz TV signal, though.  h.264 doesn't care about timing, it's just frames, even in a VFR video.  Frame timestamps is a container issue.  Container formats are very flexible.  It's easily possible to have a single frame shown for 1 minute, then 150fps for several frames, then another frame shown for a while, or anything you like.  Storing VFR video in mkv, mp4, and some other modern containers is a solved problem.  

---

### Answer by username_4 on 2013-08-16. Score: 5

I'm not sure how it will behave at very low frame rates, but it is worth pointing out this would also limit your options on how and when you could change frames since they would have to follow on the clock cycles. What is more likely to work in this case is a long keyframe interval. The majority of frames in a compression like H.264 only store the changes from the previous frame. In the case of a still image, the compression ratios will be huge because very little (no) change occurs between frames. I'm not sure that you would really pick up enough of a savings from dropping the frame rate to be worth the loss of control over when you can make a change to the frame.

The best bet would be to try it with your media and see the results. Compression is a highly content dependent thing and the best quality and compression for any particular clip is going to depend a lot on the nature of that clip, so trial is still the best way to test it out.

> **Comments:**
> **username_3**: There is a compression downside beyond what my earlier comment on another answer said: If there is much redundancy between the different images (i.e. it's still a video, not a slideshow), padding with identical images will make it harder for the encoder to find and exploit that. Depending on encoding settings, the encoder will only keep some number of old frames as possible references for new frames, and can only search within a GOP (e.g. default 250 frames for x264).  If all those candidates are the same image, that doesn't give it multiple options to find a better reference for each block...  
> **username_3**: ... e.g. after a foreground object moves in front of some background detail, the encoder can save bits by referencing what it looked like in an older frame before it was obscured.  h.264 can choose reference frames on a per-block basis.  This is a relatively small effect; good h.264 encoders do ok with only 1 reference frame, but it's still somewhat harmful to compression efficiency  
> **username_4**: Sure, you still need proper encoding settings, but you can grow your GOP size rather than reduce your frame rate if things are all that static.  If they aren't, then dropping frame rate isn't a great option to begin with.  I wonder if there has been any work on a variable GOP format.  
> **username_3**: I think repeated images are still going to reduce the opportunity for useful B-pyramid and multiple reference P-frames options.  But I guess an encoder can keep an old P frame from anywhere within the GOP so losing out on reference B-frames is probably all in theory, but IDK about in practice.  
> **username_3**: Most formats *are* variable GOP, and any good encoder will use that!  x264's default is to opportunistically end GOPs on scenecut detection, inserting an IDR frame.  (`keyint=250` is the *max* GOP length.  `keyint_min=25` is the minimum interval so it won't insert another keyframe even if it thinks it sees another scenecut; there are tuning options for scenecut bias, etc.)  x26**5** even has an extra GOP-lookahead parameter for opportunistically extending a GOP.  https://x265.readthedocs.io/en/default/cli.html#cmdoption-gop-lookahead.  And of course adaptive B-frame decisions are on by default  
> **username_4**: Nice, amazing how much they've advanced since I last got in to the real nitty gritty of encoders.  I keep a high level overview but my last extreme deep dive was mpeg 2 era...  Might be time to do another deep dive on h265 though.  
> **username_3**: Good MPEG-2 encoders can make keyframe decisions based on scenecuts, and P vs B frame decisions based on content. :P  ffmpeg's `mpeg2video` encoder lists a `-sc_threshold` option, and a `-b_strategy` option to control I/P/B selection strategy.  But anyway, h.265 is neat, with up to 32x32 DCT blocks, and very large 64x64 prediction units which can break down into smaller blocks if needed. https://sonnati.wordpress.com/2014/06/20/h265-part-i-technical-overview/.  vs. h.264 16x16 macroblocks with only 4x4 or 8x8 (high profile only) DCT blocks.  Also https://forum.doom9.org/showthread.php?t=167081  

---

### Answer by username_3 on 2015-07-13. Score: 2

I've played around with turning a bunch of still photos into a h.264 slideshow, mostly to compare the compression efficiency of JPG vs. h.264. I got [some useful replies about the technical implications of this](http://forum.doom9.org/showthread.php?t=145005) from x264 devs on doom9. e.g. force x264 to not use B frames for this, because not-very-related images will need a lot of I macroblocks, and coding them in B frames is more expensive.

Software player behaviour with low-fps video isn't ideal, in the past. I think one older player only checked for keyboard input when it displayed a frame. So there was lag between user input and player response. mplayer2 and mpv don't have this problem. Also, players that can only seek to keyframes will seek in really large chunks (2 minutes or so!) if you don't reduce the keyframe interval. x264 won't insert IDR (GOP boundaries) all over the place if the images are somewhat related to each other.

Use `x264 -tune stillimage`. It [cranks up the psy optimizations](http://forum.doom9.org/showthread.php?p=1488646#post1488646), because temporal stability isn't an issue for this use-case. Further search results: [from google](https://www.google.ca/search?q=x264%20stillimage%20site:forum.doom9.org).

I'd agree with other suggestions to have some duplicated frames, to bring the FPS up to at least 5 or something, just in case of bad players. However, smartphones / tablets should have no problem playing variable-FPS video, since they usually record that way when light levels drop. Since variable-FPS videos from phones are now out there, hardware player support for them should be expected. I wouldn't *expect* problems, but I also wouldn't be surprised if there at least some old hardware players that don't handle it well.

A frame of all "skip" macroblocks only takes about 20bytes at 1080p, IIRC. One reason I don't like duplicated frames, though, is that it interferes with single-stepping to go through the images manually.

---

**There is a compression downside to duplicating frames, though**: If there is much redundancy between the different images (i.e. it's still a video, not a slideshow), padding with identical images will make it harder for the encoder to find and exploit that.

Depending on encoding settings, the encoder will only keep some number of old frames as possible references for new frames, and can only search within a GOP (e.g. default 250 frames for x264). If all those candidates are the same image, that doesn't give it multiple options to find a better reference for each block.

e.g. After a foreground object moves in front of some background detail, the encoder can save bits by referencing what it looked like in an older frame before it was obscured. h.264 can choose reference frames on a per-block basis. This is a relatively small effect; good h.264 encoders do ok with only 1 reference frame, but it's still somewhat harmful to compression efficiency, and **a waste of power / battery life / CPU time on the decompression side to copy memory around decoding and displaying extra frames.**

---

### Recovering VFR after an NLE forces all your clips to some high frame rate:

FFmpeg has an `mpdecimate` filter that drops similar frames. You can set limits on how many frames in a row it can drop. With a tight similarity threshold, you should get it to only drop actual duplicates.

e.g. `ffmpeg -i input.mp4 -vf mpdecimate=max=9:hi=400 -c:a copy -c:v libx264 -preset veryslow -tune film output_vfr.mkv` drops up to 9 frames in a row, and only if the most-different block was different under "400", and (defaults): no more than 33% of the blocks were different by "320" units. IIRC, it's basically an 8x8 SAD on pixel components.

(FFmpeg defaults to CFR for `.mp4` outputs, though, so **use `-vsync 2` for variable-frame-rate `.mp4` output**. I *think* that's safe: [Problems with frame rate on video conversion using ffmpeg with libx264](https://superuser.com/questions/602950/problems-with-frame-rate-on-video-conversion-using-ffmpeg-with-libx264))


---

### Answer by username_5 on 2013-08-16. Score: 1

Most NLE's will allow you to import a still image in the form of how long you want it to appear in the timeline assuming you have set the project properties to some standard frame rate such as 30 fps or 24 fps etc.

In Vegas Pro I can set the time a still picture should appear on the timeline, from a fraction of second to several seconds. If I set this to 1 second then when I drag and drop a still image in the timeline, Vegas will generate enough frames to meet my request. I usually edit with 30 fps videos, and when I add a still picture I am mixing a timeline with 30 fps video that is already there (AVCHD 1080p).

To give you a specific answer, I would need to know what NLE you are using.

> **Comments:**
> **username_0**: I just apply a raw encoding software such as `ffmpeg` or `avconv`, so no need to talk about any NLE. I think the question is pretty much answered with "Just go by a standard frame rate which all players can deal with properly. There is no real 'waste of resources', because the encoding scheme is good enough to efficiently deal with still images".  

---

