UPX worthiness about static-ffmpeg HOT 7 CLOSED

Thanks, adding to reading list!

from static-ffmpeg.

It would probably require a full set of test for each library... which wouldnt be such a bad idea in the grand scheme of things.

from static-ffmpeg.

Nope only heard of it but never used it. Is is known to cause issues?

Yes some kind of tests could be nice (even without UPX). What would you like to test? encode/decode with various libs? one could also run ffmpeg fate.

from static-ffmpeg.

no idea about ffmpeg fate and no idea either about which tests could be reliable. It could be left to uses to find bugs but that can cause issues with integration at a later date for you. Regressions and such. UPX is great and as far as i know, is not known to cause issues. It does slow up start times tho. But it compresses binaries ALOT.

Maybe only worth for when yuo download the thing but if you use it enough, in the long run, the longer start time will bite you back. Maybe offer a choice when compiling, maybe dismiss this altogether? Just a thought about UPX.

from static-ffmpeg.

Ok will think about it. In my use cases it has not been a concern that the binaries are quite large (in some projects they are small compared to other things in the image :). At least docker will compress the images quite well, latest it 60MB compressed 160MB uncompressed.

from static-ffmpeg.

What about UPX? If you’re not familiar with UPX, it’s an amazing tool that reduces the size of binaries. It does so by compressing the binary, and adding a small stub to uncompress and run it transparently. If we want to reduce the footprint of our containers, UPX will also be very counter-productive. First, the disk and network usage won’t be reduced a single bit, since layers are compressed anyway; so UPX won’t get us anything here.

from https://www.ardanlabs.com/blog/2020/04/docker-images-part3-going-farther-reduce-image-size.html

from static-ffmpeg.

docker-slim seems interresting. maybe not here but in general.

from static-ffmpeg.