Figure 2. Document your command strings before your run the tests.

My FFmpeg-Related New Year’s Resolution: Document Before I Test

My typical workflow for testing-related articles and reports is to create the command string, run the tests, analyze the results, and then write or create the presentation. Since encoding is often so time-consuming, and I’m always in a hurry, I tend to quickly create the command strings with minimal thought, then run the tests, analyze the results, and start to write.

The problem with this approach is that I don’t really think about the command strings until I write about them or start creating the presentation. As you know, there are an infinite number of configurations, all of which produce different results. FFmpeg has a terrible habit of producing precisely what the command string tells it to, not necessarily what you want it to produce.

Figure 1. The typical project workflow. Ready > Fire > Aim.

Figure 1. The typical project workflow. Ready > Fire > Aim.

The latest example involved producing x264 and x265 output. The x264 command string was exactly what I wanted, but when I started encoding to HEVC, I simply changed c:v x264 to c:v x265. Bad idea. One of the switches in the x264 command line was lookahead, which converts to -rc-lookahead for x265. FFmpeg didn’t stop the encoding; it simply displayed a yellow error message for a millisecond or two during the encoding, which I missed. GOP controls are also expressed differently, another yellow message that I missed.

None of this hit me until I pasted the x265 command string into Google Docs and started writing about the individual switches. The nickel dropped; I recognized the error and had to re-run the tests and the analysis, which cost me several hours, though past errors have cost me days if not weeks.

Figure 2. Document your command strings before your run the tests.

The cure? My New Year’s Resolution. I resolve not to run any encodes until I document the command string in the article or presentation. This should move the thinking up and minimize, though probably not eliminate, wasted cycles. I’ve considered this approach before, but wanted to document it to help ensure that I actually implement it.

If you’re one of those folks who fully thinks things through before starting the time-consuming task, good for you. If not, find the structure that moves your thinking ahead of the time-consuming processing and analysis and consider making a similar New Year’s Resolution.

About Jan Ozer

Avatar photo
I help companies train new technical hires in streaming media-related positions; I also help companies optimize their codec selections and encoding stacks and evaluate new encoders and codecs. I am a contributing editor to Streaming Media Magazine, writing about codecs and encoding tools. I have written multiple authoritative books on video encoding, including Video Encoding by the Numbers: Eliminate the Guesswork from your Streaming Video ( and Learn to Produce Video with FFmpeg: In Thirty Minutes or Less ( I have multiple courses relating to streaming media production, all available at I currently work as as a Senior Director in Marketing.

Check Also

ASIC was the overall cost and performance leader.

Comparing CPUs, GPUs, and ASICs for High-Volume Transcoding

This case study compares CAPEX, power consumption, and co-location costs for GPU, CPU, and ASIC-based …

B-Frames, Ultra Low-Latency Encoding, and Parking Lot Rules

One of my sweetest memories of bringing up our two daughters was weekly trips to …

Figure 2. Cost per hour to produce a single 1080p stream using the x264 codec and FFmpeg. Graviton is clearly the most cost effective.

Which is the Best AWS CPU for FFmpeg?

If you encode with FFmpeg on AWS, you probably know that you have three CPU …

Leave a Reply

Your email address will not be published. Required fields are marked *