I have been using the GUI (right click => compress) to try and compress a .tar containing 3 videos totalling 1.7gb (.H264 MP4s). gzip, lrzip, 7z etc. all do nothing to the file size and the compressed folder is also 1.7 gb.

I then tried running lrzip from the command line (in case it was a gui problem), and used the -z flag (extreme compression), and this was my output.

enter image description here

As the compression ratio shows, the actual size of the compressed folder is bigger than the original! I don't know why I am having no luck, lrzip in particular should be effective according to random reviews I have read and the official docs (files larger than 100mb, the larger the better) - see https://wiki.archlinux.org/index.php/Lrzip

Why can't I compress my files?

  • 2
    Personally I won't bother archiving mp4 videos since those videos are already compressed by the codec.
    – pram
    Apr 26, 2014 at 12:37
  • And you can achieve less size by using video converter/compressor tools like FFMpeg.
    – Jet
    Apr 27, 2014 at 6:46
  • pram and Jet are correct. This is expected behaviour. It is counter-productive to try to compress something that is already well compressed. If you use video conversion tools you may be able to save space at the expense of the quality of the video (apparent or not). Start with the highest quality least compressed copy you have, however. May 9, 2014 at 4:03

5 Answers 5


As @pram said above in the comment, mp4 videos are already compressed, and other video formats probably also use compression to some extent. Therefore, trying to compress them won't result in little (if any) reduction in size (this also applies, at least in part, to pictures and music). In this case, it looks like the metadata (for the compressed file itself) might be causing the increase. The only compression format that might (and that's a strong might) result in some reduction is xz.

On another note, if you want to reduce the size of those videos, look instead into re-encoding the videos using something like Handbrake.

  • 3
    I find that webm has good compression rates in general. Much smaller than mp4.
    – Seth
    Apr 27, 2014 at 1:52
  • @Seth actually MP4 (which is either AVC aka h.264 or the newer and better h.265 aka HEVC codec) gives smaller files at same quality (or better quality at same file size). Jul 25, 2016 at 12:59
  • @DavidBalažic we're comparing apples and apples here, when we're trying to talk about oranges. mp4 and webm are both containers, they have nothing to do with compression. You're right that h.264 and h.265 are both commonly used codecs in mp4 containers, but you can't compare h.265 to webm. h.264 is comparable to the vp8 codec commonly used in webm containers, just as h.265 is comparable to the vp9 codec, also typically contained by webm. tl;dr: use h.265 in mp4 and vp9 in webm and you'll get roughly the same quality/efficiency. Feb 21, 2019 at 23:48

Really, the fact that the files are already compressed is not the crucial problem. It's this: compression in general can only work if the data has some kind of redundancy in it. That's practically always the case for uncompressed files – however, it's not necessarily obvious what the redundancy is. General-purpose compression algorithms mostly target the kind of thing obvious in text files: many words turn up not just once but plenty of times in identical form, perhaps phrases of words can be combined, etc. etc.. The algorithms are quite good in generalising this to anything from ASCII-encoded phone number lists over chinese poetry to binary machine code, but they can't possibly work for any kind of data. In particular, media files are conceptually analogue data, in a noisy digital representation. That means, there's not really any of the kind of textfile-reduncancy at all: some motives might be recurring, but always with a slightly different configuration of sensor noise. That's why all compressed image/AV formats use some cleverly chosen transformation as their first encoding step, normally based on DCT or wavelets. These transformations roughly speaking move the picture-portions and noise-portions into different locations, so they can well be seperated and with lossy compression you retain only the information you think is most "important", which does not include the noise, while the "good information" has lots of redundancy. (That's not really how it works, but sort of.)

If general-purpose compressors used these transformations, the effect would be the opposite: most digital information would actually be misclassified as some kind of noise, because it lacks the "smooth" structure you find in analogue signals. And after lossy video compression obviously neither analogue smoothness or digital recurrence can be found anymore (if it were, the codecs would use another bzip-stage or something themselves!)


The reason you're having no luck is that mp4 is already compressed, you can't compress it further. All you are doing is adding the compression format's header information to the file.

Since the files are already compressed and you can't compress them further, this results in an increase in file size since all you're doing is keeping the same information and adding a few more bytes of header info.


This is a nice example of the pigeonhole principle.

Since the file is already (lossy) compressed, there's little to no reduction to be had anywhere, which means that you're already at zero net gain. As the others mentioned, the compressed format itself has a certain, usually negligible loss in in its own meta-data. All of this comes together means that there is probably no pigeonhole left in the set of equal or smaller files and thus your compressed data falls into the set of larger files.

  • 5
    I'm sorry, but this is a misapplication of said principle. You could apply the same logic to a 1.7GB file full of zeroes, and get an incorrect answer. The pigeonhole principle is used generally to prove the existence of uncompressible files, not to prove that any particular file is actually uncompressible. (The latter is uncomputable, as the Kolmogorov complexity function is not a computable function).
    – nneonneo
    Apr 26, 2014 at 18:28
  • 1
    @nneonneo Then feel free to correct the linked Wikipedia article. The existence of incompressible files follows directly from it and then you add in the compression meta-data and suddenly you have a file larger than the original. Which is exactly what I said. The proof that the file is not further compressible under a given implementation of a given algorithm is that the output is not smaller. Of course, it is also possible that the meta-data is simply larger than the compression win, but I'm not sure I'd described that as compressed in the user-oriented sense.
    – Livius
    Apr 26, 2014 at 18:37
  • @Livius The wikipedia article is correct: it uses the pigeonhole principle to prove the existence of uncompressable files for any given lossless compression algorithm. But you can't derive uncompressability of any particular file just from the pigeonhole principle. Apr 27, 2014 at 12:36
  • @DavidRicherby Yes, but the fact that the file is not compressed by a given implementation of a given algorithm is the proof that it's not compressible. Unless there are other reasons for the existence of incompressible files, then it follows that the failure to compress is due to the PP. The only other possible reason would be because that a given algorithm sees no way to reduce its size, which again seems to be a case of "under the assumptions of the algorithm, there is no smaller file with the same information; such cases necessarily exist because of the PP".
    – Livius
    Apr 27, 2014 at 13:13
  • More precisely, the PP forces the algorithm to have inputs whose image does not lie in the space of smaller files. Every decision that leads to the image of a given file not fitting in that space is thus on some level driven by the PP and the compromises it forces, (assuming a sane definition of compression algorithm). Then any file whose image is not smaller belongs to the set that the PP excluded from being compressible. The proof that a given file is not compressible is its failure to compress; in a broad sense, the incompressibility is always a result of the PP and its compromises.
    – Livius
    Apr 27, 2014 at 13:20

If you want to compress these files you will have to reduce the quality.

Without knowing how long and what format and content type these files are its hard to tell if these files have room to be shrunk without much visible quality loss.

BluRays with 1080p video tends to be upwards of 25GB so its not unlikely you're already at an optimal quality-to-size ratio for H.264.

You can try using ffmpeg or avconv to convert files.

You could start with ffmpeg -i input_file.mp4 -preset slower -crf 20 -c:a copy output_file.mp4

The anconv command will work similarly.

  • Increase the -crf value to decrease file size and quality, I don't recommend any higher than 25.

  • You can change the preset to slow or medium to increase speed, but your file size will suffer compared to slower or even veryslow (if you're very patient!).

  • More settings can be found here: http://mewiki.project357.com/wiki/X264_Settings

  • I recommend staying away from most as the presets provide sane defaults, with -tune being the exception.

  • Try a denoiser if you content is film ( -vf hqdn3d ) you can improve visual quality compared to using a high -crf value.

  • Scale down your content -vf scale=-1:720 for 720p and -vf scale=-1:480 for 480p to improve encoding speed and maintain quality.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .