Powerlifting and Mastodon Made Me Learn FFmpeg

FFmpeg was always one of those things I wanted to learn. But like AWK, which is also on that aspirational list, it’s intimidatingly complicated and I’ve only had limited use cases for it. Until powerlifting, that is.

This March marks three years of powerlifting for me🥳. For those who aren’t familiar, powerlifting is different from Olympic weightlifting. In powerlifting, the “big three” are the squat, bench, and deadlift.¹ Powerlifting as a regular gym practice involves a lot more than squats, benches, and deadlifts, but your accessory work is generally in service of building muscles to increase your totals on at least on of those. Powerlifting also involves a lot of recording yourself.

It’s not vanity … ok, it’s sometimes vanity, and that’s kind of what we’re going to be talking about here, but hear me out. Fundamentally, it’s not about vanity. I have a coach and she’s fantastic. But I don’t have “buy coaching 3x a week” money. Other people aren’t lucky enough to live in the same place as the person they want to coach or train them. Fortunately, we live in the era of the smartphone + tripod combo.

It depends on what kind of phase I’m doing, but I generally record my squat, bench, or deadlift sets. I record them to watch them myself while resting between sets. What’s the difference between my perception of the lift and the recording? Am I moving faster or slower than I thought? If it felt heavier than I expected, was my form off? Did my knees wobble on that squat? Was the bar path on the 4th rep of that set completely wild? Is my right arm consistently moving faster than my left? At what moment did I slow down on that movement?

Sometimes I slow it down so I can really focus in on things. Sometimes I use it to figure out whether I did the correct number of reps. It’s a standard joke that powerlifters can’t count above 4, but when you’re focusing so hard on every muscle in your body doing the right thing, it is actually pretty hard! And if I did 6 reps instead of 5, I’m going to update my app!

The training app my coach uses to write my programs also lets me upload corresponding videos for her review. I can add text notes to give more context if needed. This lets her see the big picture of my progress even though she only works with me on one kind of lift per week. If the whole set is extremely normal, I feel good, and I’m not working on something especially challenging, then maybe I don’t attach them and just write a note saying it was a normal training day.

Video and Vanity

While it might be cool to keep and compile these videos over time, most just serve their immediate purpose and get deleted. But sometimes, I set a PR (personal record). Sometimes things just all come together. Sometimes I want to connect with my virtual buddies who lift. Sometimes I’m just excited by how good a normal training day was and kind of in awe about how much weight I can move!

But it’s one thing to record a video and another to share it. My primary social media outlets these days are Mastodon and Discord. Mastodon doesn’t necessarily have a limit on video uploads, but I’m very aware that the GLAM server I’m on is always struggling a bit with storage space. Discord has a 10MB video upload limit unless you pay for “Nitro” or are in a server with a lot of Nitro members who’ve upped its capacity.

The video of a single lift might only be 5MB, but a whole set or a complex move like a Strongman carry can easily come in at 15-20MB. And the 5MB video is probably more than I actually need to share it with friends. This isn’t about creating a timeless version of the video. This is about sharing something while putting as little demand on associated services as possible.

So I Learned a Few Things in FFmpeg

Since I’m working with an iPhone and Mac, I generally start by airdropping from my phone to computer. That gives me an MP4 file. But if I’ve edited it on my phone or texted it to someone and downloaded from Messages, I can find myself working with a .MOV file.

So first, I want to convert MOV to MP4 without losing any quality at this point in the process. That one’s pretty simple:

ffmpeg -i input.mov output.mp4

Use -i to flag the input file, put in everything you want to do to it, and then put in your output filename. This is the simplest use of FFmpeg and actually reduces filesize a fair amount for going between these two. For example, a 19MB video became 8.7MB. We could also downscale quality at this point and probably reduce filesize, but since I primarily deal with MP4 to MP4, I just run it as a preliminary pass before running the big one:

ffmpeg -i input.mp4 -c:v h264 -b:v 700k -c:a copy output.mp4

This command takes the input file, re-encodes it with using the H.264/AVC standard for video. It downgrades things to a bitrate of 700k per second. The audio is simply copied over (-c:a copy).

For a 13.5MB file which came straight from my phone, this reduced it to to 3.9MB. For the 8.7MB (originally 19MB) which had already gone through FFmpeg re-encoding from MOV to MP4, this only took it down to 8.2MB. I was able to get it down to 5.2MB by changing the bitrate from 700k to 400k.

How I Learned

I learned this the way I learned a lot of code things – DuckDucking around the internet, including Stack Overflow and how-tos. I then researched each flag I didn’t understand and tried to gain at least a sense of what was happening. I used a mix of documentation pages and more searching online for just the flag.

For example, I had seen it before but looked up h264 and learned H.264/AVC is used for lossy encoding. Fantastic, I am specifically interested in reducing size. What about -b:v? That specifies the bitrate of the video (the :a and :v qualifications on a flag specify audio and video respectively). The -c flag is for specifying codecs/actions

I bookmarked things I found especially helpful, e.g. FFmpeg syntax and examples, so I can experiment and learn more later on.

But it’s also important to note that neither of these commands is what I found online. I started by finding something which actually worked and digging a little into understanding it. Then I asked questions based on what I was seeing and tried more experiments.

For example, the MOV to MP4 transformation initially included -qscale 0 between the filenames. I looked that up and saw normally it was used with values of 1-31 to specify how much something would be degraded in quality. Since 1 is the lowest, I figured 0 would be an attempt to specify changing nothing. And it worked! But then I ran the command without -qscale at all. That gave me a file of the same size which played just fine. I double checked my work by running exiftool against files transformed with and without qscale. The technical metadata was identical. At that point, I felt comfortable dropping it.

I did the same thing for the longer transformation. What I found mixed the -vcodec syntax, which searching has told me was semi-depricated (but working) with -c:a. It had two audio codec statements, one specifying mp3 and one specifying copy. Same process: I tried it with -c:v in place of -vcodec and removed the mp3 statement. It worked. I compared the technical metadata of files created with the original process and the revised one.

Learning for Use ++

“It plays” and “it’s the right size” along with “it’s not awful quality” are really my goals here, so an inefficient command wasn’t a dealbreaker. But it was also an opportunity. I have this desire to convert videos and reduce their sizes. I started with “it works” and then dug more into things which I found inconsistent, synthesizing my results. I developed a simple method of checking my work with exiftool.

I wouldn’t describe myself as an expert with ffmpeg, but I’m no longer intimidated by it. I feel like I can revisit the documentation if I need to do something slightly different in the future. And I have a process to follow if I want to try more things.