<p>I followed Henderson's advice and wrote a little script to resize the images:</p>

<pre><code>$ cat jpg2mp4.sh
test -d "$1" || exit
tmpdir=$(mktemp -d -p .)
counter=0
find $1 -iname '*.jpg' | while read jpg
do
        convert -resize 1440x1080 $jpg $tmpdir/IMG_$(printf "%04d" $counter).JPG
        counter=$((counter + 1))
done
echo ffmpeg -i $tmpdir/IMG_%4d.JPG test.mp4
</code></pre>

<p>It does work! I still wish ffmpeg could handle the original images and I also wish gstreamer would work! For further tips to enlarge a photo or adjust time, see this <a href="http://webconverger.org/screensaver/" rel="nofollow">tip</a>.</p>

CC BY-SA 3.0
2014-05-19T09:10:44.957Z
I don't think you need to resize the images before giving them to ffmpeg, just tell ffmpeg what size you want the movie, these are the settings I tend to use: `ffmpeg -r 15 -i img%04d.JPG -b 15M -s 1440x1080 out.avi`. 15 frames per second, 15M bit rate, HD.
Jamie Kitson
CC BY-SA 3.0
2014-05-19T02:34:30.143Z
2014-05-19T02:34:30.143Z
hendry
<p>The problem is that a sequence of images is not a video file.  In order to convert it to a video format such as h.264, it has to load an entire group of pictures (probably somewhere around 15 of them) and then perform a whole bunch of calculations to determine how the images are related to each other.  It then uses that information to determine what to actually store.  </p>

<p>It doesn't store actual pictures, but rather it stores a couple of pictures (I frames) but then stores information about what changed from those frames to the next frames and what will change from those frames to the frames after (known as P and B frames).  This is a big part of why h.264 compression (and most other modern video formats) are able to fit so much video in to such small amounts of space compared to how much space the images take on their own.</p>

<p>If you were to save it as something like an MJPEG where each image is actually stored on its own, then it would just be a matter of appending them together, but then the file size of the video would probably be unplayably huge.</p>

CC BY-SA 3.0
2014-05-18T23:23:26.637Z
"...a sequence of images is not a video file". FWIW, that's just what ffmpeg treats it as: a stream in MJPEG format. Not that it helps the OP, just clarifying. What you say about compression is of course correct. But in a single-pass encoding there's no reason an encoder couldn't output / append each GOP as it's completed. I don't know of one that does, but it's not impossible.
Jim Mack
CC BY-SA 3.0
2014-05-18T23:40:30.883Z
@JimMack - yeah, I was oversimplifying a bit and you are correct about the mjpeg bit.  And yes, each GOP could be output separately, but just holding an entire GOP and the necessary analysis is going to take a fair bit of space for images that large.  I don't know exactly how much, but it is  a non-trivial task even for 1 GOP.
AJ Henderson
CC BY-SA 3.0
2014-05-18T19:45:06.400Z
2014-05-18T19:45:06.400Z
AJ Henderson
<p>I loaded CHDK firmware on my old Canon IXUS 980IS and took 796 images, each
weighing in at:</p>

<pre><code>JPEG 4416x3312 4416x3312+0+0 8-bit sRGB 9.182MB 0.050u 0:00.049
</code></pre>

<p>So I want to convert 796 images into a movie. Each still could be a frame in a 24fps movie, so:</p>

<p>796 / 24 = 30 sec = half a minute video</p>

<h2>FFMPEG fails with Killed</h2>

<pre><code>x264 [error]: malloc of size 83759040 failedime=00:00:00.-4 bitrate=N/A
Video encoding failed
Killed
</code></pre>

<p><a href="http://ix.io/cmF" rel="nofollow">Complete log</a></p>

<p>I guess the 4GB of RAM isn't enough memory. But why can't FFMPEG simply build the movie in a memory efficient manner?</p>

<h2>Gstreamer fails</h2>

<pre><code>ERROR: from element /GstPipeline:pipeline0/GstDecodeBin:decodebin0: Your GStreamer installation is missing a plug-in.
</code></pre>

<p><a href="http://ix.io/coC" rel="nofollow">Complete log</a></p>

CC BY-SA 3.0
2014-05-18T12:57:53.937Z
Did you want the output movie to be 4416x3312 like the source frames? As you can tell from the log, the encoder wants a great deal of free memory to make a clip that size. What's the final use of the clip?
Jim Mack
CC BY-SA 3.0
2014-05-18T13:07:08.350Z
Would be nice to be able to make a "4k movie" but 1080p size is probably more sensible. Still not sure why it needs so much memory. Can't it append frames?
hendry
CC BY-SA 3.0
2014-05-18T15:49:26.410Z
1080p is a 16x9 format, where your source frames are 4x3, so you'd have a pillar-box result. And '4K' can mean several things, but is also a widescreen format. So you'd need to crop to fit, or accept black bars.
Jim Mack
CC BY-SA 3.0
2014-05-18T16:40:13.837Z
I'm not sure what is best without seeing the result. Don't have the experience. I do hate black bars though.
hendry
CC BY-SA 3.0
2014-05-20T16:57:34.170Z
That's a x264 error, not ffmpeg. Does it work as expected if you use a native ffmpeg encoder? Just to test add `-vcodec mpeg4` before the output name. Are you using a 32 or 64-bit build?
llogan
CC BY-SA 3.0
2018-04-09T11:04:23.863Z
What's the GStreamer command you are using?
aleb
<ffmpeg><time-lapse>
Why does FFMPEG fail when converting Intervalometer photos into a time lapse movie?
hendry
# Why does FFMPEG fail when converting Intervalometer photos into a time lapse movie?

(Asked by: username_0 on 2014-05-18)

I loaded CHDK firmware on my old Canon IXUS 980IS and took 796 images, each
weighing in at:
JPEG 4416x3312 4416x3312+0+0 8-bit sRGB 9.182MB 0.050u 0:00.049

So I want to convert 796 images into a movie. Each still could be a frame in a 24fps movie, so:
796 / 24 = 30 sec = half a minute video
FFMPEG fails with Killed
x264 [error]: malloc of size 83759040 failedime=00:00:00.-4 bitrate=N/A
Video encoding failed
Killed

Complete log
I guess the 4GB of RAM isn't enough memory. But why can't FFMPEG simply build the movie in a memory efficient manner?
Gstreamer fails
ERROR: from element /GstPipeline:pipeline0/GstDecodeBin:decodebin0: Your GStreamer installation is missing a plug-in.

Complete log

**Tags:** ffmpeg, time-lapse

> **Comments:**
> **username_1**: Did you want the output movie to be 4416x3312 like the source frames? As you can tell from the log, the encoder wants a great deal of free memory to make a clip that size. What's the final use of the clip?  
> **username_0**: Would be nice to be able to make a "4k movie" but 1080p size is probably more sensible. Still not sure why it needs so much memory. Can't it append frames?  
> **username_1**: 1080p is a 16x9 format, where your source frames are 4x3, so you'd have a pillar-box result. And '4K' can mean several things, but is also a widescreen format. So you'd need to crop to fit, or accept black bars.  
> **username_0**: I'm not sure what is best without seeing the result. Don't have the experience. I do hate black bars though.  
> **username_2**: That's a x264 error, not ffmpeg. Does it work as expected if you use a native ffmpeg encoder? Just to test add `-vcodec mpeg4` before the output name. Are you using a 32 or 64-bit build?  
> **username_3**: What's the GStreamer command you are using?  

---

## 2 answers

### Answer by username_0 on 2014-05-19. Score: 1

I followed Henderson's advice and wrote a little script to resize the images:
$ cat jpg2mp4.sh
test -d "$1" || exit
tmpdir=$(mktemp -d -p .)
counter=0
find $1 -iname '*.jpg' | while read jpg
do
        convert -resize 1440x1080 $jpg $tmpdir/IMG_$(printf "%04d" $counter).JPG
        counter=$((counter + 1))
done
echo ffmpeg -i $tmpdir/IMG_%4d.JPG test.mp4

It does work! I still wish ffmpeg could handle the original images and I also wish gstreamer would work! For further tips to enlarge a photo or adjust time, see this tip.

> **Comments:**
> **username_4**: I don't think you need to resize the images before giving them to ffmpeg, just tell ffmpeg what size you want the movie, these are the settings I tend to use: `ffmpeg -r 15 -i img%04d.JPG -b 15M -s 1440x1080 out.avi`. 15 frames per second, 15M bit rate, HD.  

---

### Answer by username_5 on 2014-05-18. Score: 1

The problem is that a sequence of images is not a video file. In order to convert it to a video format such as h.264, it has to load an entire group of pictures (probably somewhere around 15 of them) and then perform a whole bunch of calculations to determine how the images are related to each other. It then uses that information to determine what to actually store.

It doesn't store actual pictures, but rather it stores a couple of pictures (I frames) but then stores information about what changed from those frames to the next frames and what will change from those frames to the frames after (known as P and B frames). This is a big part of why h.264 compression (and most other modern video formats) are able to fit so much video in to such small amounts of space compared to how much space the images take on their own.

If you were to save it as something like an MJPEG where each image is actually stored on its own, then it would just be a matter of appending them together, but then the file size of the video would probably be unplayably huge.

> **Comments:**
> **username_1**: "...a sequence of images is not a video file". FWIW, that's just what ffmpeg treats it as: a stream in MJPEG format. Not that it helps the OP, just clarifying. What you say about compression is of course correct. But in a single-pass encoding there's no reason an encoder couldn't output / append each GOP as it's completed. I don't know of one that does, but it's not impossible.  
> **username_5**: @JimMack - yeah, I was oversimplifying a bit and you are correct about the mjpeg bit.  And yes, each GOP could be output separately, but just holding an entire GOP and the necessary analysis is going to take a fair bit of space for images that large.  I don't know exactly how much, but it is  a non-trivial task even for 1 GOP.  

---

