Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-05-19T09:10:44.957Z
Answers.Text: 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.
Answers.UserDisplayName: Jamie Kitson
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-05-19T02:34:30.143Z
Answers.LastActivityDate: 2014-05-19T02:34:30.143Z
Answers.UserDisplayName: hendry
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-05-18T23:23:26.637Z
Answers.Text: "...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.
Answers.UserDisplayName: Jim Mack
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-05-18T23:40:30.883Z
Answers.Text: @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.
Answers.UserDisplayName: AJ Henderson
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-05-18T19:45:06.400Z
Answers.LastActivityDate: 2014-05-18T19:45:06.400Z
Answers.UserDisplayName: AJ Henderson
Body: <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>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-05-18T12:57:53.937Z
Comments.Text: 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?
Comments.UserDisplayName: Jim Mack
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-05-18T13:07:08.350Z
Comments.Text: 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?
Comments.UserDisplayName: hendry
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-05-18T15:49:26.410Z
Comments.Text: 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.
Comments.UserDisplayName: Jim Mack
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-05-18T16:40:13.837Z
Comments.Text: I'm not sure what is best without seeing the result. Don't have the experience. I do hate black bars though.
Comments.UserDisplayName: hendry
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-05-20T16:57:34.170Z
Comments.Text: 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?
Comments.UserDisplayName: llogan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-04-09T11:04:23.863Z
Comments.Text: What's the GStreamer command you are using?
Comments.UserDisplayName: aleb
Tags: <ffmpeg><time-lapse>
Title: Why does FFMPEG fail when converting Intervalometer photos into a time lapse movie?
UserDisplayName: hendry
ThreadText: # 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](http://ix.io/cmF)
  
  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](http://ix.io/coC)
  
  **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 username_5'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](http://webconverger.org/screensaver/).
  
  > **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**: @username_1 - 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.  
  
  ---
  
  