Video Production Stack Exchange is a question and answer site for engineers, producers, editors, and enthusiasts spanning the fields of video, and media creation. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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!

share|improve this question
up vote 2 down vote accepted

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.

share|improve this answer
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 Mar 1 '15 at 2:06
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 Mar 1 '15 at 2:08

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.

share|improve this answer

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.

share|improve this answer
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 Aug 17 '13 at 17:11

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.