Why does avconv bit rate lowering take ages, and cause fan to work overtime?

Question

Summary:

1. I've read that the way to reduce the size of mp4 files is by lowering the video bit rate. So I'm using avconv to do this. The following is the command I'm using:

avconv -i input-file.mp4 -b:v 300k output-file.mp4

So in the above example, say input-file.mp4 has a video bit rate of 1600 kb/s, then the command should produce output-file.mp4 with a video bit rate of 300 kb/s.

2. Well, the command runs, but with the following effects:

a) input-file.mp4 is 500 MB in size, but after 8 minutes, output-file.mp4 had reached only 45 MB in size. At that rate, it would take 1 hour 30 minutes to complete! So I aborted the run.

b) The laptop fan ran noticeably louder, and was blowing air out that was much hotter than normal.

c) There is a cpu usage monitor on the status bar at the bottom of the screen. In normal use, this shows a moving green waveform that takes up only a slight to moderate amount of the black background. Whereas when running the said avconv command, the entire black background was obliterated with solid green!

3. My Questions:

a) Is there a faster way to do the bit rate lowering?

b) Why is the fan working so hard; why is the air that's being blown out so hot; and how do I stop it happening?

c) Do the same things happen on your computer when you run this avconv command?

Full Details:

1. My laptop is an Acer Aspire 5755G, i5, with 8 GB of RAM, running Knoppix 7.7.1 from a memory stick (which works fine for all my other uses).

2. The following shows parts of the output from the following command that I think might be relevant. The "ME:" entries are my own notes. (SORRY, THE QUESTION SUBMISSION THING WOULDN'T LET ME FORMAT IT AS A CODE SAMPLE.) :

$ time avconv -i input-file.mp4 -b:v 300k output-file.mp4

...
Input #0 ...
...
network : BBC One
Duration: 00:44:13.04, start: 0.000000, bitrate: 1699 kb/s Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt470bg), 960x540 [SAR 1:1 DAR 16:9], 1599 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc (default)

[ME: I think the "1599 kb/s" above is the bitrate (of input-file.mp4).]
...
Stream #0:2: Video: mjpeg, yuvj420p(pc, bt470bg/unknown/unknown), 192x108
[SAR 72:72 DAR 16:9], 90k tbr, 90k tbn, 90k tbc
[libx264 @ 0x8192320] using SAR=1/1
[libx264 @ 0x8192320] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX

[ME: The "cpu capabilities" just above might mean something.]
...
Output #0, mp4, to 'output-file.mp4':
...
network : BBC One
encoder : Lavf57.41.100
Stream #0:0(und): Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv420p, 960x540 [SAR 1:1 DAR 16:9], q=-1--1, 300 kb/s, 25 fps, 12800 tbn, 25 tbc (default)

[ME: I think the "300 kb/s" just above shows that it IS converting it to 300 kb/s bitrate.]

...

ME: I aborted the run after about 8m30s (CTRL+C). The following is the output just before, and during the abort. I think the messg "Exiting normally, received signal 2." is in response to the CTRL+C:

...
frame=14350 fps= 43 q=39.0 size= 30338kB time=00:09:34.12 bitrate= 432.9kbits/s dup=1 drop=0 speed= 1.7x frame=14377 fps= 43 q=38.0 size= 30376kB time=00:09:35.18 bitrate= 432.6kbits/s dup=1 drop=0 speed=1.71x frame=20872 fps= 40 q=-1.0 Lsize= 45648kB time=00:13:55.02 bitrate= 447.8kbits/s dup=1 drop=0 speed=1.62x
video:31838kB audio:13194kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 1.367074%
[libx264 @ 0x8192320] frame I:378 Avg QP:30.76 size: 9510
[libx264 @ 0x8192320] frame P:6226 Avg QP:35.29 size: 2581
[libx264 @ 0x8192320] frame B:14268 Avg QP:37.13 size: 907
[libx264 @ 0x8192320] consecutive B-frames: 6.7% 4.4% 5.9% 83.0%
[libx264 @ 0x8192320] mb I I16..4: 33.2% 60.3% 6.5%
[libx264 @ 0x8192320] mb P I16..4: 9.1% 16.7% 0.3% P16..4: 23.7% 2.1% 0.7% 0.0% 0.0% skip:47.5%
[libx264 @ 0x8192320] mb B I16..4: 0.7% 0.8% 0.0% B16..8: 24.9% 0.8% 0.0% direct: 0.2% skip:72.5% L0:42.8% L1:56.4% BI: 0.8%
[libx264 @ 0x8192320] final ratefactor: 34.50
[libx264 @ 0x8192320] 8x8 transform intra:62.5% inter:93.0%
[libx264 @ 0x8192320] coded y,uvDC,uvAC intra: 15.2% 32.0% 1.7% inter: 2.2% 2.5% 0.0%
[libx264 @ 0x8192320] i16 v,h,dc,p: 35% 29% 8% 29%
[libx264 @ 0x8192320] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 10% 51% 3% 3% 3% 3% 3% 2%
[libx264 @ 0x8192320] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 20% 16% 5% 7% 7% 6% 5% 3%
[libx264 @ 0x8192320] i8c dc,h,v,p: 78% 9% 11% 2%
[libx264 @ 0x8192320] Weighted P-Frames: Y:2.7% UV:1.9%
[libx264 @ 0x8192320] ref P L0: 64.6% 13.5% 15.9% 5.8% 0.1%
[libx264 @ 0x8192320] ref B L0: 91.8% 6.5% 1.7%
[libx264 @ 0x8192320] ref B L1: 97.5% 2.5%
[libx264 @ 0x8192320] kb/s:312.40
[aac @ 0x8193840] Qavg: 645.192
Exiting normally, received signal 2.

real 8m36.597s
user 25m19.497s
sys 0m6.527s
$
^C
$

Answer 1

The short answer

You are decompressing and recompressing your video, which tends to be a very slow process. Your video quality will probably be significantly reduced, too.

The long answer

What people often don't realize is most (if not all) of the audio/video files they play on their devices are technically compressed in some way or another. I suspect this is the part where most people would say "But I'm not using WinZip on the video." Media formats tend to have compression algorithms that are specialized to either audio or video streams. MP3, for example, is a "triple-layered" variant of an audio compression format specified in the ancient MPEG-1 standard. In essence, what you're asking avconv to do is remove the compression, and put much tighter compression on the video.

Since your avconv output keeps saying a lot about about "libx264", we can safely assume that's the video compressor avconv is using, which is especially known to be slow. If speed is the *only* thing you want, you could use a different compressor, such as libxvid or mpeg2video. You can select a video compressor by specifying -c:v {codec}, where {codec} is the name of the codec.

Due note that the most commonly used video compression formats (including the ones I mentioned above), are lossy compression formats. This means that everytime a video is recompressed, the newly created copy suffers some amount of irreversible quality loss. How much quality is lost depends on a number of factors, with the bitrate often being the most significant variable: the lower the bitrate, the lower the quality retention.

At only 300K, this video will probably look like pixelated garbage. This is especially true with the "faster" compressors I mentioned above. The reason x264 is so slow is because it's doing as much as it can to keep the video quality reasonably high, and most other video compressors just can't do half as much on that front.

If you really want to compress the videos to around 300K, you'll probably want to consider adding a resolution scaler filter to the video, to reduce the resolution. This will leave the compressor with fewer pixels to deal with per frame, allowing it to:

A) work a bit faster.

B) allocate a few more of those precious bits to each pixel, hopefully reducing the "blocky" look a little.

PS: Yes, I know, reducing resolution in 2020 is sacrilegious, and probably seems counter-productive. However, at a bitrate of only 300K, something's gotta give.

To use a filter, specify -vf {filter}={options}, where "filter" is the name of the filter, and "options" is a colon-separated list of parameters to pass to the filter. For example, to reduce the resolution by half, do -vf scale=w=480:h=270.

Wait, what about audio?

Yes, we've been talking about video this whole time, but we haven't really mentioned audio, have we? Audio is not as complex as video, so encoding is faster, and the streams tend to take up significantly less disk space than video streams. From the avconv output, it doesn't look like that video file has audio, so what I'm about to say might not apply.

That said, you might be able to speed the encoding process up a bit by adding -c:a copy. This tells avconv to copy the audio stream without doing any (de)compression at all. This make the process quick and efficient... at least as far as the audio stream is concerned. The video is still the bottleneck, though.

Conclusion

Feel free to let the encoding process run overnight, if so desired, as (short of buying a PC with a very expensive CPU) that's the best you can do. Since you're running on a laptop, and since video conversion tends to eat one's battery life quickly, you might want to keep it plugged in.