Answers.Body: <p>Everything is possible!</p>
  
  <p>Let's image, you have a <code>/directory/</code> per video animation and files like <code>img0001.png</code>, <code>img0002.png</code>. You have 3 ways:</p>
  
  <ol>
  <li>Wait all images, <code>img0001.png</code>, <code>img0002.png</code> ... <code>img0100.png</code> to be in directory, run ffmpeg, get mp4 and remove images (current way)</li>
  <li>Write application in C with ffmpeg libraries: wait every single image, decode it in memory, remove from disk immediately and feed to encoder in libavcodec. When you got last image, for example <code>img0100.png</code>, you feed it to encoder and call something like <code>flush()</code> to complete image, so your mp4 will be completed. Drawback of this method is memory consumption - your process will live until all images processed, so if you downloading it long time, process will consume some memory all this time!</li>
  <li>You can try to implement same in bash script using pipes:</li>
  </ol>
  
  <p>Here we got any input, list files for example:</p>
  
  <pre><code>`    ls -1 | grep "jpg$" | while read filename; do`
  </code></pre>
  
  <p>Then unpack images:</p>
  
  <pre><code>`    ffmpeg -v 0 -nostdin -i "$filename" -f rawvideo -s 120x60 -pix_fmt rgb24 - `
  </code></pre>
  
  <p>And encode it:</p>
  
  <pre><code>`    done | ffmpeg -nostdin -f rawvideo -s 120x60 -r 10 -pix_fmt rgb24 -i - -s 320x240 -vcodec libx264 -y res.mp4`
  </code></pre>
  
  <p>I think, you got idea.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-31T01:05:53.433Z
Answers.LastActivityDate: 2017-08-31T01:05:53.433Z
Answers.UserDisplayName: bukkojot
Answers.Body: <p>MP4 is a compressed file structure. Once a compressed file is closed to write, naive attempts to append to it are more likely to corrupt it than append to it.</p>
  
  <p>@Bukkojot got the right idea - extract the file to an uncompressed format, append your images, and recompress the file.  His description is really an optimization of the approach that streams the decompression and recompression phases for existing video in parallel thread, but it illustrates the point.</p>
  
  <p>Since MP4 is a lossy compression, every time you decompress the video for re-rendering you lose quality. I would recommend keeping the uncompressed video in a directory and simply re-rendering the video from scratch with every file you append. </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-30T05:12:13.003Z
Answers.Text: MP4 is not a compressed file structure; it's a container, and it's not stored with any sort of compression. It usually contains bitstreams which encode lossy and compressed representations of their source data. But appending occurs at the packet level and codec internals are only relevant so far as to ensure that the consuming player can correctly display both the original and the appended data. ffmpeg can (sort of) trivially generate a new MP4 from multiple inputs without re-encoding anything. The key hurdle here is for the appendage to match existing codec properties just well enough.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-30T05:14:09.477Z
Answers.Text: For H.264 in MP4, there are hacks whereby it's possible to append streams which *don't need* to match i.e. different resolution, profile..etc. Codec ID is set as `avc3` but very few players are set to handle such streams.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-09-30T03:31:43.450Z
Answers.LastActivityDate: 2017-09-30T03:31:43.450Z
Answers.UserDisplayName: pojo-guy
Body: <p>I've been working on a service that downloads a number of images, saves them to disk, and then uses ffmpeg to create an animation (gif or mp4). This can be fairly intensive in terms of memory and CPU usage. </p>
  
  <p>Are there any methods that would allow me to dynamically append and encode a new image to the animation as they're ready, rather than having to read all of the images at the end and generate the animation at the end?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-08-18T05:03:08.403Z
Comments.Text: Didn't you post this at SU few days back? I asked you a couple of Qs: does file size matter? Will you be appending exactly one image, or multiple?
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-08-18T05:45:25.163Z
Comments.Text: Hey @Mulvya. Nah that was a bit of a different question. The application process as it is now is that the app downloads a variety of sub images and combines them in memory into a single frame. That gets saved out as a png. When all the frames have been generated, a child process is launched that starts ffmpeg with encoding arguments to generate the final animation (MP4 or gif). The idea I'm exploring now is if it's possible to feed each image into an ongoing encoding process rather than waiting until all frames have been retrieved.
Comments.UserDisplayName: Geuis
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-08-18T06:55:13.950Z
Comments.Text: So, you wish to keep the ffmpeg process running, or is it ok to generate a MP4 which then gets appended to?
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-08-18T20:33:45.710Z
Comments.Text: @Mulvya I'm not sure which approach would be better, so your guidance would be very helpful. My concern about appending to a MP4 is that its going to re-encode the previous frames in the MP4 file and cause image quality loss. If that's not the case, then I'd love to hear your thoughts.
Comments.UserDisplayName: Geuis
Tags: <ffmpeg><mp4>
Title: Possible to stream/append images into an existing mp4?
UserDisplayName: Geuis
ThreadText: # Possible to stream/append images into an existing mp4?
  
  (Asked by: username_0 on 2017-08-17)
  
  I've been working on a service that downloads a number of images, saves them to disk, and then uses ffmpeg to create an animation (gif or mp4). This can be fairly intensive in terms of memory and CPU usage.
  
  Are there any methods that would allow me to dynamically append and encode a new image to the animation as they're ready, rather than having to read all of the images at the end and generate the animation at the end?
  
  **Tags:** ffmpeg, mp4
  
  > **Comments:**
  > **username_1**: Didn't you post this at SU few days back? I asked you a couple of Qs: does file size matter? Will you be appending exactly one image, or multiple?  
  > **username_0**: Hey @Mulvya. Nah that was a bit of a different question. The application process as it is now is that the app downloads a variety of sub images and combines them in memory into a single frame. That gets saved out as a png. When all the frames have been generated, a child process is launched that starts ffmpeg with encoding arguments to generate the final animation (MP4 or gif). The idea I'm exploring now is if it's possible to feed each image into an ongoing encoding process rather than waiting until all frames have been retrieved.  
  > **username_1**: So, you wish to keep the ffmpeg process running, or is it ok to generate a MP4 which then gets appended to?  
  > **username_0**: @Mulvya I'm not sure which approach would be better, so your guidance would be very helpful. My concern about appending to a MP4 is that its going to re-encode the previous frames in the MP4 file and cause image quality loss. If that's not the case, then I'd love to hear your thoughts.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2017-08-31. Score: 1
  
  Everything is possible!
  
  Let's image, you have a `/directory/` per video animation and files like `img0001.png`, `img0002.png`. You have 3 ways:
  
  1. Wait all images, `img0001.png`, `img0002.png` ... `img0100.png` to be in directory, run ffmpeg, get mp4 and remove images (current way)
  2. Write application in C with ffmpeg libraries: wait every single image, decode it in memory, remove from disk immediately and feed to encoder in libavcodec. When you got last image, for example `img0100.png`, you feed it to encoder and call something like `flush()` to complete image, so your mp4 will be completed. Drawback of this method is memory consumption - your process will live until all images processed, so if you downloading it long time, process will consume some memory all this time!
  3. You can try to implement same in bash script using pipes:
  
  Here we got any input, list files for example:
  
  ```
  `    ls -1 | grep "jpg$" | while read filename; do`
  
  ```
  
  Then unpack images:
  
  ```
  `    ffmpeg -v 0 -nostdin -i "$filename" -f rawvideo -s 120x60 -pix_fmt rgb24 - `
  
  ```
  
  And encode it:
  
  ```
  `    done | ffmpeg -nostdin -f rawvideo -s 120x60 -r 10 -pix_fmt rgb24 -i - -s 320x240 -vcodec libx264 -y res.mp4`
  
  ```
  
  I think, you got idea.
  
  
  ---
  
  ### Answer by username_3 on 2017-09-30. Score: 0
  
  MP4 is a compressed file structure. Once a compressed file is closed to write, naive attempts to append to it are more likely to corrupt it than append to it.
  
  @username_2 got the right idea - extract the file to an uncompressed format, append your images, and recompress the file. His description is really an optimization of the approach that streams the decompression and recompression phases for existing video in parallel thread, but it illustrates the point.
  
  Since MP4 is a lossy compression, every time you decompress the video for re-rendering you lose quality. I would recommend keeping the uncompressed video in a directory and simply re-rendering the video from scratch with every file you append.
  
  > **Comments:**
  > **username_1**: MP4 is not a compressed file structure; it's a container, and it's not stored with any sort of compression. It usually contains bitstreams which encode lossy and compressed representations of their source data. But appending occurs at the packet level and codec internals are only relevant so far as to ensure that the consuming player can correctly display both the original and the appended data. ffmpeg can (sort of) trivially generate a new MP4 from multiple inputs without re-encoding anything. The key hurdle here is for the appendage to match existing codec properties just well enough.  
  > **username_1**: For H.264 in MP4, there are hacks whereby it's possible to append streams which *don't need* to match i.e. different resolution, profile..etc. Codec ID is set as `avc3` but very few players are set to handle such streams.  
  
  ---
  
  