Answers.Body: <p>Just remove <code>-c:v copy</code>. So it should look like this:</p>
  
  <pre><code>ffmpeg -loop 1 -i image.jpg -i audio.m4a -c:a copy -shortest -y video.mp4
  </code></pre>
  
  <p>ffmpeg will select H.264 encoder to encode your image. You could also try <code>-c:v libx264 -tune stillimage</code> option. But probably the result will be similar.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-19T22:33:30.823Z
Answers.LastActivityDate: 2016-01-19T22:33:30.823Z
Answers.UserDisplayName: Dimitri Podborski
Answers.Body: <p>You are right about -r 1 and -vf fps=1 but you said also that you have 30 mins audio, in this case even if you keep fps at 1 it will be still 1800 seconds, 1800 times the repetitions of the same image converted as bitmap data.</p>
  
  <p>Different thing is if you start using a codec that could take advantage of the redundancy of the data present in the stream. For example, even using h264 in lossless fashion retaining the 100% of the quality will make you save a huge amount of disk space.</p>
  
  <p>Take your video 41 GB video as input and try:</p>
  
  <pre><code>ffmpeg -i video.mp4 -c:v libx264 -preset slow -crf 0 output.mp4
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-20T05:35:33.190Z
Answers.Text: ffmpeg will not create an I-frame for each second. Default keyframe distance is 250 frames, and there's no scene change here to trigger earlier placement by x264.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-20T10:15:51.353Z
Answers.Text: @Mulvya Ok for the default keyframe distance but he used copy as codec with a jpeg input not h264 in his original post, how h264 scene change detection algorithm is pulled in in this case?
Answers.UserDisplayName: user3450548
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-20T10:54:34.837Z
Answers.Text: Ah, I just tested the OP's command and expected an error or warning but got none. Turns out that although MJPEG isn't an ISO registered codec for MP4, it is an Apple registered one, so ffmpeg generates a MJPEG stream with a major brand of M4A for the .mp4. So, yeah x264 does not come into the OP's command.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-19T22:13:24.083Z
Answers.LastActivityDate: 2016-01-19T22:13:24.083Z
Answers.UserDisplayName: user3450548
Answers.Body: <p>Try</p>
  
  <pre><code>ffmpeg -loop 1 -framerate 1 -i image.jpg -i audio.m4a -c:a copy -fflags +genpts -shortest -y video.mp4
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-20T05:45:59.030Z
Answers.LastActivityDate: 2016-01-20T05:45:59.030Z
Answers.UserDisplayName: Gyan
Body: <p>I have one image ~1MB (jpg) and a ~30 mins audio file ~7MB (m4a).</p>
  
  <p>What I am trying to get is a final video that lasts like the audio file (30 mins) with the same image displayed. I get that with the following <code>ffmpeg</code> usage:</p>
  
  <pre><code>ffmpeg -loop 1 -i image.jpg -i audio.m4a -c:v copy -c:a copy -shortest -y video.mp4
  </code></pre>
  
  <p>The final result is correct but the size of the file is way far too big ~41GB as we consider the original size of the 2 files (image+audio ~8MB).</p>
  
  <p>Is there a way to get a smaller size for the final video? I have used <code>-r 1</code>, <code>-vf fps=1</code> etc but it didn't change.</p>
  
  <p><strong>EDIT</strong></p>
  
  <p>Following your suggestions I have changed the command into this:</p>
  
  <pre><code>ffmpeg -loop 1 -r 1 -i image.jpg -i audio.m4a -c:a copy -vf fps=1 -shortest -y video.mp4
  </code></pre>
  
  <p>and now the  final video size is dropped from 41GB to only 22MB and it built all in 2 mins.</p>
  
  <p>Anyway it comes out a new issue: The image appears after 3/4 seconds that video is started. How can I fix that to have the image displayed from the beginning?</p>
  
  <p>I think the solution for the delay is using <code>fps=3</code>.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-01-19T22:13:37.660Z
Comments.Text: just remove `-c:v copy`
Comments.UserDisplayName: Dimitri Podborski
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-01-19T23:08:08.933Z
Comments.Text: @incBrain is a good practice also specify the codec that you want to use and some settings instead of relaying on defaults that can always change in future ;)
Comments.UserDisplayName: user3450548
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-01-20T00:25:50.040Z
Comments.Text: its actually not important in this case since we have only one input frame. So we actually can go with quite every codec. It is only important to remove this `copy` option because it tells ffmpeg not to change jpeg and replicate it with some framerate for some duration. But the best way to encode it would be to use IPPPPPPP......P structure. But I have no idea how to tell ffmpeg to do that.
Comments.UserDisplayName: Dimitri Podborski
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-01-20T10:13:19.930Z
Comments.Text: @incBrain is indeed important, the encode you talking about is the compression strategy chosen by the codec. And there are some codecs that doesn't take advantage of intra - predictive frame scheme you talking about. Also if you don't specify the codec ffmpeg nowadays (in future who knows) pick h264 for you but in a lossy fashion, i don't think that one is the solution OP was searching for.
Comments.UserDisplayName: user3450548
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-01-20T10:18:59.147Z
Comments.Text: so your assumption is that ffmpeg will use less efficient codec by default in the future?
Comments.UserDisplayName: Dimitri Podborski
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-01-21T00:21:33.427Z
Comments.Text: @incBrain no the assumption it's that is better have control over the process, specifying 1-2 more parameters won't kill anyone but you will have a portable command line valid for thousands of more transcodings, regardless ffmpeg version and the environment in use..
Comments.UserDisplayName: user3450548
Tags: <ffmpeg>
Title: ffmpeg: final video too big
UserDisplayName: Randomize
ThreadText: # ffmpeg: final video too big
  
  (Asked by: username_0 on 2016-01-19)
  
  I have one image ~1MB (jpg) and a ~30 mins audio file ~7MB (m4a).
  
  What I am trying to get is a final video that lasts like the audio file (30 mins) with the same image displayed. I get that with the following `ffmpeg` usage:
  
  ```
  ffmpeg -loop 1 -i image.jpg -i audio.m4a -c:v copy -c:a copy -shortest -y video.mp4
  
  ```
  
  The final result is correct but the size of the file is way far too big ~41GB as we consider the original size of the 2 files (image+audio ~8MB).
  
  Is there a way to get a smaller size for the final video? I have used `-r 1`, `-vf fps=1` etc but it didn't change.
  
  **EDIT**
  
  Following your suggestions I have changed the command into this:
  
  ```
  ffmpeg -loop 1 -r 1 -i image.jpg -i audio.m4a -c:a copy -vf fps=1 -shortest -y video.mp4
  
  ```
  
  and now the final video size is dropped from 41GB to only 22MB and it built all in 2 mins.
  
  Anyway it comes out a new issue: The image appears after 3/4 seconds that video is started. How can I fix that to have the image displayed from the beginning?
  
  I think the solution for the delay is using `fps=3`.
  
  **Tags:** ffmpeg
  
  > **Comments:**
  > **username_1**: just remove `-c:v copy`  
  > **username_2**: @incBrain is a good practice also specify the codec that you want to use and some settings instead of relaying on defaults that can always change in future ;)  
  > **username_1**: its actually not important in this case since we have only one input frame. So we actually can go with quite every codec. It is only important to remove this `copy` option because it tells ffmpeg not to change jpeg and replicate it with some framerate for some duration. But the best way to encode it would be to use IPPPPPPP......P structure. But I have no idea how to tell ffmpeg to do that.  
  > **username_2**: @incBrain is indeed important, the encode you talking about is the compression strategy chosen by the codec. And there are some codecs that doesn't take advantage of intra - predictive frame scheme you talking about. Also if you don't specify the codec ffmpeg nowadays (in future who knows) pick h264 for you but in a lossy fashion, i don't think that one is the solution OP was searching for.  
  > **username_1**: so your assumption is that ffmpeg will use less efficient codec by default in the future?  
  > **username_2**: @incBrain no the assumption it's that is better have control over the process, specifying 1-2 more parameters won't kill anyone but you will have a portable command line valid for thousands of more transcodings, regardless ffmpeg version and the environment in use..  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_1 on 2016-01-19. Score: 1
  
  Just remove `-c:v copy`. So it should look like this:
  
  ```
  ffmpeg -loop 1 -i image.jpg -i audio.m4a -c:a copy -shortest -y video.mp4
  
  ```
  
  ffmpeg will select H.264 encoder to encode your image. You could also try `-c:v libx264 -tune stillimage` option. But probably the result will be similar.
  
  
  ---
  
  ### Answer by username_2 on 2016-01-19. Score: 0
  
  You are right about -r 1 and -vf fps=1 but you said also that you have 30 mins audio, in this case even if you keep fps at 1 it will be still 1800 seconds, 1800 times the repetitions of the same image converted as bitmap data.
  
  Different thing is if you start using a codec that could take advantage of the redundancy of the data present in the stream. For example, even using h264 in lossless fashion retaining the 100% of the quality will make you save a huge amount of disk space.
  
  Take your video 41 GB video as input and try:
  
  ```
  ffmpeg -i video.mp4 -c:v libx264 -preset slow -crf 0 output.mp4
  
  ```
  
  > **Comments:**
  > **username_3**: ffmpeg will not create an I-frame for each second. Default keyframe distance is 250 frames, and there's no scene change here to trigger earlier placement by x264.  
  > **username_2**: @Mulvya Ok for the default keyframe distance but he used copy as codec with a jpeg input not h264 in his original post, how h264 scene change detection algorithm is pulled in in this case?  
  > **username_3**: Ah, I just tested the OP's command and expected an error or warning but got none. Turns out that although MJPEG isn't an ISO registered codec for MP4, it is an Apple registered one, so ffmpeg generates a MJPEG stream with a major brand of M4A for the .mp4. So, yeah x264 does not come into the OP's command.  
  
  ---
  
  ### Answer by username_3 on 2016-01-20. Score: 0
  
  Try
  
  ```
  ffmpeg -loop 1 -framerate 1 -i image.jpg -i audio.m4a -c:a copy -fflags +genpts -shortest -y video.mp4
  
  ```
  
  
  ---
  
  