So yesterday, I wanted to share a screen recording with a colleague over Slack. I didn’t however want them to spend unnecessary seconds downloading a “huge file” so obviously I went to Google, to figure out how to make a video for Slack smaller!
I know, I know.. There are plenty of websites where you can upload the video, and they will compress it for you for free, but do I really want to upload my videos to random places on the internet? Who knows where it’ll end up!?
Enter FFmpeg! From this answer on StackOverflow, on the question How can I reduce a video’s size with ffmpeg? it was suggested to compress it using libx264 and further using libx265. So, on to my WSL,
sudo apt-get install ffmpeg -yA ~260MB bundle of joy later, and I was ready to compress my mkv! And off I went with libx265..
ffmpeg -i 2021-06-24-21-07-54.mkv -vcodec libx265 -crf 28 output.mp4From 84MB to ~4.16MB a pretty nice reduction if I must say so myself! 4.95% of the original filesize to be exact.
I posted it on Slack and what happened. I’d sent a small video on Slack! “Yay….wait..” It didn’t work, the video did not play on Slack. My colleague could download the video and play it, but that’s not really what I wanted by “sending a video over Slack.” On to this issue MP4 videos are not playing in Slack with the solution “…Changing it to h264 fixed it!”
So I thought… The answer on SO actually did have an older solution embedded, where they just suggested libx264… Let’s try that,
ffmpeg -i 2021-06-24-21-07-54.mkv -vcodec libx264 -crf 28 output-lib264.mp4And great success! The compression was “only” to 4.25MB, so 5.05% of the original filesize, negligibly more than the 4.95%, but even better… It plays on Slack! Which was the problem I was trying to solve in the first place 💪
Very late to the party, but you’re doing yourself a disservice on multiple counts.
1. You’re missing audio reencoding. It is exactly _because_ reencoding video is so good (ffmpeg makes a great job at deduplicating, keyframes, etc.) and “windows’ recordings” such as slack screensharing has usually a low variability (hence the compression you had was so good) that audio ends up usually constituting quite a big part of the output’s size.
2. While probably not necessary at this very usecase since you had rendered (heh) the video both playable in Slack and compressed, but for the future – you haven’t selected a video encoding preset – which made it “medium” by default. If you’re looking for a good trade-off between filesize, quality and encoding time, this is the place. I usually opt for small filesize and high quality (and thus, by the “iron triangle” “law”, the encoding time goes up).
To address 1, you can e.g.:
ffmpeg -i -c:a libvorbis -qscale:a 5
(5 by most users achieves so-called transparency, anything above 6 is going overboard)
OR
ffmpeg -i -c:a libopus -b:a bitrate
I personally don’t use opus (despite it being dubbed “the best encoder”) since I really dislike bitrate metrics and never need to achieve a chosen filesize.
To address 2 just add:
-preset veryslow
OR
-preset slower
OR
-preset slow
Yes, they will increase the time of the encoding. Yes, the quality increase may not be linear with the time increase. But this is the way to go if you’re encoding for archive and possibly would want to see the video later on. Especially important in not “windows’ recordings” but from any other source (e.g. game footage) since there is much higher rate of change in those and quality loss will be substantial when using medium preset.
Wow, this is uncontested the best comment I have ever had. Thank you for your feedback!
You’re probably right of the reuse of frames, I also cared very little about audio, since I was mostly sharing quick demos.
I also don’t care about the encoding time, as long as it’s small, i.e. fast to receive and play.
Thank you so much, Anonymous person!
May your days be ever full of high fives, and may your sleeves always be dry after washing your hands!