Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

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?

share|improve this question
2  
Personally I won't bother archiving mp4 videos since those videos are already compressed by the codec. –  pram Apr 26 at 12:37
    
And you can achieve less size by using video converter/compressor tools like FFMpeg. –  Jet Apr 27 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. –  John S Gruber May 9 at 4:03

5 Answers 5

up vote 22 down vote accepted

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.

share|improve this answer
3  
I find that webm has good compression rates in general. Much smaller than mp4. –  Seth Apr 27 at 1:52

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.

share|improve this answer

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!)

share|improve this answer

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.

share|improve this answer
2  
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 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 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. –  David Richerby Apr 27 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 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 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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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