user4543: 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!

user1890: 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.

user3908: 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.

user9105: 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 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, because temporal stability isn't an issue for this use-case.  Further search results: from google.
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)

user2836: 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.

4543: <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>
 1890: <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>
 3908: <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>
 9105: <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>
 2836: <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>
