Answers.Body: <p>I am not sure your output stream video and audio distributions, let's assume the output size is mostly occupied by the video ES.</p>
  <p>In the H.266 era, x265 is not a new codec</p>
  <pre><code>!ffmpeg -y -i https://github.com/Matroska-Org/matroska-test-files/raw/master/test_files/test5.mkv -c:v libx265 -an VideoOnly_265.mp4
  </code></pre>
  <p>The file size of VideoOnly_265.mp4 is</p>
  <blockquote>
  <p>-rw-r--r-- 1 root root 4283630 Sep  7 12:38 VideoOnly_265.mp4</p>
  </blockquote>
  <pre><code>!ffmpeg -y -i https://github.com/Matroska-Org/matroska-test-files/raw/master/test_files/test5.mkv -c:v libx264 -an VideoOnly_264.mp4
  </code></pre>
  <p>The file size of VideoOnly_264.mp4 is</p>
  <blockquote>
  <p>-rw-r--r-- 1 root root 10956223 Sep  7 12:33 VideoOnly_264.mp4</p>
  </blockquote>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-09-07T20:45:51.110Z
Answers.Text: https://www.videoproc.com/resource/h266-vvc.htm  "Therefore, it would be 3-5 years before H.266 is generally supported by more hardware and software. Some experts expect that this new codec would not be widely accepted and used until 2027. It is not expected to replace H.264 and HEVC. Instead, we will enter a new era with the coexistence of multiple codecs."
Answers.UserDisplayName: Jason Conrad
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-09-08T01:09:28.077Z
Answers.Text: Excuse me, I am here to suggest to use x.265.
Answers.UserDisplayName: xer-rex
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-09-08T09:56:35.257Z
Answers.Text: So, how is this “the h.266 era?”
Answers.UserDisplayName: Jason Conrad
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-09-14T00:28:31.467Z
Answers.Text: h265 18 MB, h265 with the same arguments otherwise 11 MB, no blocky image, better than the 12 MB blocky image. I'm going to stick to 264 and will just use MP3 now. So far, this is the command for 264 (and 265 is the same except for 264->265): ffmpeg -loop 1 -y -i Title.jpg -i WhatsApp\ Audio\ 2020-09-02\ at\ 15.54.18.ogg -shortest -acodec copy -vcodec libx264 -preset ultrafast -crf 25  -pix_fmt yuv420p -g 100000 result264.mp4
Answers.UserDisplayName: Gunther Schadow
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-09-14T01:04:27.037Z
Answers.Text: OK, now definitely the MP3 is the biggest problem, turns to 66 MB just because of the recoded audio.. I'll see if YT can figure out the OGG stream.
Answers.UserDisplayName: Gunther Schadow
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-09-07T12:50:46.930Z
Answers.LastActivityDate: 2020-09-07T12:50:46.930Z
Answers.UserDisplayName: xer-rex
Answers.Body: <p>There are a couple of things which you may still tune in the x264 encoder like listed <a href="https://trac.ffmpeg.org/wiki/Encode/H.264" rel="nofollow noreferrer">here</a> but also in the mp3 decoder like shown <a href="https://trac.ffmpeg.org/wiki/Encode/MP3" rel="nofollow noreferrer">here</a> if you are OK with a lower audio bitrate.My assumption is that not everything is eaten up by the video.</p>
  <p>I have tried</p>
  <pre><code>ffmpeg -loop 1 -y -i image.jpg -i audio.ogg -shortest -acodec mp3 -qscale:a 7 -vcodec libx264 -preset ultrafast -tune stillimage -maxrate 5K -bufsize 100K -crf 25  -pix_fmt yuv420p -g 100000 result5.mp4
  </code></pre>
  <p>and got a video file that was half the size of the ogg file.</p>
  <p>Here is what the parameters do and how to use them:</p>
  <p>-maxrate 5K -bufsize 100K</p>
  <p>this has a direct impact on the video bitrate. I lowered the values until I got VBV underflow messages then raised it back again. The quality of the jpeg was very low but got better when I increased bufsize.</p>
  <p>-qscale:a 7</p>
  <p>This produces a 100 kbit Audio stream which was more than OK for my sample.</p>
  <p>In a nutshell, you may need to tweak these parameters a little bit in order to improve things. I suspect that it is actually the audio in your case consuming a large part.</p>
  <p>Let me know if it works.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-09-13T17:10:51.403Z
Answers.Text: Thanks for the effort you put into this answer. To make sure it wasn't the audio, I just used the -acode copy form, and then the video still was 12 MB in size and it was terrible blocky even on that still image. You are certainly right that the re-coded audio in MP3 is going to take bandwidth. But the video part is still kind-a ridiculous. I remember many years ago I coded DVD rips into divx or so, and there was definition of the i-b-p frame sequences and also multi-pass so that I don't think it would have been so wasteful with still images.
Answers.UserDisplayName: Gunther Schadow
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-09-13T19:18:15.050Z
Answers.Text: True - I did that too at the time - thinking it over, is there a reason the picture needs to be 1024x768? If you reduce to SD (720x480 or 576) and maybe reduce the fps to 15 I am sure you could tweak another 30-40%.. Alternatively using another codec (Quicktime? Not sure it works with youtube) might be an option - have you seen https://learningsolutionsmag.com/articles/1203/video-compression-secrets-smaller-files-better-quality (something tells me you have ;-) )
Answers.UserDisplayName: onemarcfifty
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-09-12T19:15:31.707Z
Answers.LastActivityDate: 2020-09-12T19:15:31.707Z
Answers.UserDisplayName: onemarcfifty
Body: <p>I have a WhatsApp message of 1 hour duration, it is an .ogg audio of less than 9 MB in size.</p>
  <p>I want to upload it to YouTube, so I have to make it at least a single-frame video. So I made a JPEG cover picture of 1024 x 768 pixels. First I just used VLC and output a youtube SF or whatever output, but YouTube churns on that &quot;processing 0%&quot; for days on end now. So now I have to do something else. Using ffmpeg. Ideally I would just use the awesome ogg compression passing it through:</p>
  <pre><code>ffmpeg -loop 1 -y -i image.jpg -i audio.ogg -shortest -acodec copy -vcodec libx264 -crf 25  -pix_fmt yuv420p result.mp4
  </code></pre>
  <p>But that doesn't play in some players, so I won't even bother youtube with it.</p>
  <pre><code>ffmpeg -loop 1 -y -i image.jpg -i audio.ogg -shortest -acodec mp3 -vcodec libx264 -crf 25  -pix_fmt yuv420p result.mp4
  </code></pre>
  <p>That creates a huge file of over 120 MB in size! I have crappy internet, not going to blow a &lt;9 MB file into &gt;120 MB just to upload it you youtube.</p>
  <p>So I thought if I could have only one i-frame and the rest p-frames which should be basically empty because the &quot;video&quot; has no changes to the picture over time. I read about the -g option:</p>
  <pre><code>ffmpeg -loop 1 -y -i image.jpg -i audio.ogg -shortest -acodec mp3 -vcodec libx264 -crf 25  -pix_fmt yuv420p -g 100000 result.mp4
  </code></pre>
  <p>The -g 100000 covers the 94,288 frames. But still with that I get &gt;60 MB.</p>
  <p>How can I make the most compact mostly-audio + still image video that youtube will actually finish processing?</p>
  <p>Here is some more calculation to show just why anything above 20 MB should not be acceptable.</p>
  <p>Audio in the ogg compression is 8.61 MB in size. That makes a bitrate of</p>
  <pre><code>  8.61 MB * 1024^2 [B/MB] / 8 [b/B] / 62 [min] / 60 [s/min] 
  = 303.368... b/s
  </code></pre>
  <p>That is 303 bits per second! That's pretty awesome encoding power of this one channel mono ogg audio. Imagine what a 300 bits per second teletype terminal feels as you type! And now imagine how you can talk faster through this sort of low bandwidth line than you can type and see a screen refresh!</p>
  <p>But I'm perfectly OK with the MP3 audio perhaps being a little bigger. What I am not OK is the video encoding or something else giving this codec license to stream data out in ~200 kb/s, kilo-bit, even if that is at 4x the speed, 50 kb/s is still too much if the payload goes with less than 1 kb/s.</p>
  <p>BTW, that Title image JPEG is 170 kB in size. If I just put a new full key i-frame copy of it every minute, then I'd get 10 MB for the &quot;video&quot; payload, not 60 MB. So something is very wrong with these codecs or the way they are parameterized.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-09-07T00:32:44.540Z
Comments.Text: A 120MB upload shouldn't be a problem in 2020.  Please tell me you're on a remote island or something.
Comments.UserDisplayName: Jason Conrad
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-09-07T00:48:20.207Z
Comments.Text: I am in Brazil with super crappy Internet. And there is no reason that a "video" of a still image must be so big.
Comments.UserDisplayName: Gunther Schadow
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-09-07T01:48:08.063Z
Comments.Text: It should be.  Somebody here knows.  Unfortunately, not me.  I'll follow this question though, and see if I can help you get an answer.
Comments.UserDisplayName: Jason Conrad
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-09-13T07:21:14.797Z
Comments.Text: I had a similar question before and found it answered here. The file size that I got after encoding was almost equal to the audio only file size. Hope it helps. https://video.stackexchange.com/questions/23061/adobe-premiere-video-size-with-static-image
Comments.UserDisplayName: abel
Tags: <audio><youtube>
Title: How to make a SMALL video from single still image + audio, one key frame and all the rest p frames or whatever
UserDisplayName: Gunther Schadow
ThreadText: # How to make a SMALL video from single still image + audio, one key frame and all the rest p frames or whatever
  
  (Asked by: username_0 on 2020-09-06)
  
  I have a WhatsApp message of 1 hour duration, it is an .ogg audio of less than 9 MB in size.
  
  I want to upload it to YouTube, so I have to make it at least a single-frame video. So I made a JPEG cover picture of 1024 x 768 pixels. First I just used VLC and output a youtube SF or whatever output, but YouTube churns on that "processing 0%" for days on end now. So now I have to do something else. Using ffmpeg. Ideally I would just use the awesome ogg compression passing it through:
  
  ```
  ffmpeg -loop 1 -y -i image.jpg -i audio.ogg -shortest -acodec copy -vcodec libx264 -crf 25  -pix_fmt yuv420p result.mp4
  
  ```
  
  But that doesn't play in some players, so I won't even bother youtube with it.
  
  ```
  ffmpeg -loop 1 -y -i image.jpg -i audio.ogg -shortest -acodec mp3 -vcodec libx264 -crf 25  -pix_fmt yuv420p result.mp4
  
  ```
  
  That creates a huge file of over 120 MB in size! I have crappy internet, not going to blow a <9 MB file into >120 MB just to upload it you youtube.
  
  So I thought if I could have only one i-frame and the rest p-frames which should be basically empty because the "video" has no changes to the picture over time. I read about the -g option:
  
  ```
  ffmpeg -loop 1 -y -i image.jpg -i audio.ogg -shortest -acodec mp3 -vcodec libx264 -crf 25  -pix_fmt yuv420p -g 100000 result.mp4
  
  ```
  
  The -g 100000 covers the 94,288 frames. But still with that I get >60 MB.
  
  How can I make the most compact mostly-audio + still image video that youtube will actually finish processing?
  
  Here is some more calculation to show just why anything above 20 MB should not be acceptable.
  
  Audio in the ogg compression is 8.61 MB in size. That makes a bitrate of
  
  ```
    8.61 MB * 1024^2 [B/MB] / 8 [b/B] / 62 [min] / 60 [s/min] 
  = 303.368... b/s
  
  ```
  
  That is 303 bits per second! That's pretty awesome encoding power of this one channel mono ogg audio. Imagine what a 300 bits per second teletype terminal feels as you type! And now imagine how you can talk faster through this sort of low bandwidth line than you can type and see a screen refresh!
  
  But I'm perfectly OK with the MP3 audio perhaps being a little bigger. What I am not OK is the video encoding or something else giving this codec license to stream data out in ~200 kb/s, kilo-bit, even if that is at 4x the speed, 50 kb/s is still too much if the payload goes with less than 1 kb/s.
  
  BTW, that Title image JPEG is 170 kB in size. If I just put a new full key i-frame copy of it every minute, then I'd get 10 MB for the "video" payload, not 60 MB. So something is very wrong with these codecs or the way they are parameterized.
  
  **Tags:** audio, youtube
  
  > **Comments:**
  > **username_1**: A 120MB upload shouldn't be a problem in 2020.  Please tell me you're on a remote island or something.  
  > **username_0**: I am in Brazil with super crappy Internet. And there is no reason that a "video" of a still image must be so big.  
  > **username_1**: It should be.  Somebody here knows.  Unfortunately, not me.  I'll follow this question though, and see if I can help you get an answer.  
  > **username_2**: I had a similar question before and found it answered here. The file size that I got after encoding was almost equal to the audio only file size. Hope it helps. https://video.stackexchange.com/questions/23061/adobe-premiere-video-size-with-static-image  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_4 on 2020-09-12. Score: 1 | Accepted answer
  
  There are a couple of things which you may still tune in the x264 encoder like listed [here](https://trac.ffmpeg.org/wiki/Encode/H.264) but also in the mp3 decoder like shown [here](https://trac.ffmpeg.org/wiki/Encode/MP3) if you are OK with a lower audio bitrate.My assumption is that not everything is eaten up by the video.
  
  I have tried
  
  ```
  ffmpeg -loop 1 -y -i image.jpg -i audio.ogg -shortest -acodec mp3 -qscale:a 7 -vcodec libx264 -preset ultrafast -tune stillimage -maxrate 5K -bufsize 100K -crf 25  -pix_fmt yuv420p -g 100000 result5.mp4
  
  ```
  
  and got a video file that was half the size of the ogg file.
  
  Here is what the parameters do and how to use them:
  
  -maxrate 5K -bufsize 100K
  
  this has a direct impact on the video bitrate. I lowered the values until I got VBV underflow messages then raised it back again. The quality of the jpeg was very low but got better when I increased bufsize.
  
  -qscale:a 7
  
  This produces a 100 kbit Audio stream which was more than OK for my sample.
  
  In a nutshell, you may need to tweak these parameters a little bit in order to improve things. I suspect that it is actually the audio in your case consuming a large part.
  
  Let me know if it works.
  
  > **Comments:**
  > **username_0**: Thanks for the effort you put into this answer. To make sure it wasn't the audio, I just used the -acode copy form, and then the video still was 12 MB in size and it was terrible blocky even on that still image. You are certainly right that the re-coded audio in MP3 is going to take bandwidth. But the video part is still kind-a ridiculous. I remember many years ago I coded DVD rips into divx or so, and there was definition of the i-b-p frame sequences and also multi-pass so that I don't think it would have been so wasteful with still images.  
  > **username_4**: True - I did that too at the time - thinking it over, is there a reason the picture needs to be 1024x768? If you reduce to SD (720x480 or 576) and maybe reduce the fps to 15 I am sure you could tweak another 30-40%.. Alternatively using another codec (Quicktime? Not sure it works with youtube) might be an option - have you seen https://learningsolutionsmag.com/articles/1203/video-compression-secrets-smaller-files-better-quality (something tells me you have ;-) )  
  
  ---
  
  ### Answer by username_3 on 2020-09-07. Score: 0
  
  I am not sure your output stream video and audio distributions, let's assume the output size is mostly occupied by the video ES.
  
  In the H.266 era, x265 is not a new codec
  
  ```
  !ffmpeg -y -i https://github.com/Matroska-Org/matroska-test-files/raw/master/test_files/test5.mkv -c:v libx265 -an VideoOnly_265.mp4
  
  ```
  
  The file size of VideoOnly\_265.mp4 is
  
  > -rw-r--r-- 1 root root 4283630 Sep 7 12:38 VideoOnly\_265.mp4
  
  ```
  !ffmpeg -y -i https://github.com/Matroska-Org/matroska-test-files/raw/master/test_files/test5.mkv -c:v libx264 -an VideoOnly_264.mp4
  
  ```
  
  The file size of VideoOnly\_264.mp4 is
  
  > -rw-r--r-- 1 root root 10956223 Sep 7 12:33 VideoOnly\_264.mp4
  
  > **Comments:**
  > **username_1**: https://www.videoproc.com/resource/h266-vvc.htm  "Therefore, it would be 3-5 years before H.266 is generally supported by more hardware and software. Some experts expect that this new codec would not be widely accepted and used until 2027. It is not expected to replace H.264 and HEVC. Instead, we will enter a new era with the coexistence of multiple codecs."  
  > **username_3**: Excuse me, I am here to suggest to use x.265.  
  > **username_1**: So, how is this “the h.266 era?”  
  > **username_0**: h265 18 MB, h265 with the same arguments otherwise 11 MB, no blocky image, better than the 12 MB blocky image. I'm going to stick to 264 and will just use MP3 now. So far, this is the command for 264 (and 265 is the same except for 264->265): ffmpeg -loop 1 -y -i Title.jpg -i WhatsApp\ Audio\ 2020-09-02\ at\ 15.54.18.ogg -shortest -acodec copy -vcodec libx264 -preset ultrafast -crf 25  -pix_fmt yuv420p -g 100000 result264.mp4  
  > **username_0**: OK, now definitely the MP3 is the biggest problem, turns to 66 MB just because of the recoded audio.. I'll see if YT can figure out the OGG stream.  
  
  ---
  
  