1

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.

Improve this question
4
  • 1
    A 120MB upload shouldn't be a problem in 2020. Please tell me you're on a remote island or something.
    – Jason Conrad
    Sep 7, 2020 at 0:32
  • I am in Brazil with super crappy Internet. And there is no reason that a "video" of a still image must be so big.
    – Gunther Schadow
    Sep 7, 2020 at 0:48
  • 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.
    – Jason Conrad
    Sep 7, 2020 at 1:48
  • 1
    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. video.stackexchange.com/questions/23061/…
    – abel
    Sep 13, 2020 at 7:21

2 Answers 2

Reset to default
1

There are a couple of things which you may still tune in the x264 encoder like listed here but also in the mp3 decoder like shown here 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.

Improve this answer
2
  • 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.
    – Gunther Schadow
    Sep 13, 2020 at 17:10
  • 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 learningsolutionsmag.com/articles/1203/… (something tells me you have ;-) )
    – onemarcfifty
    Sep 13, 2020 at 19:18
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

Improve this answer
5
  • 1
    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."
    – Jason Conrad
    Sep 7, 2020 at 20:45
  • Excuse me, I am here to suggest to use x.265.
    – xer-rex
    Sep 8, 2020 at 1:09
  • 1
    So, how is this “the h.266 era?”
    – Jason Conrad
    Sep 8, 2020 at 9:56
  • 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
    – Gunther Schadow
    Sep 14, 2020 at 0:28
  • 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.
    – Gunther Schadow
    Sep 14, 2020 at 1:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.