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 (https://amzn.to/3kV6R1j) and Learn to Produce Video with FFmpeg: In Thirty Minutes or Less (https://amzn.to/3ZJih7e). I have multiple courses relating to streaming media production, all available at https://bit.ly/slc_courses. I currently work as www.netint.com as a Senior Director in Marketing.

Check Also

Simplifying Streaming Workflows with Norsk: An Interview with Dom Robinson

I recently spoke with Dom Robinson, co-founder and Chief Business Development Officer of id3as, to …

Eric Schumacher-Rasmussen, id3as CMO

The Business Case for Norsk: Interview with id3as CMO Eric Schumacher-Rasmussen

I recently spoke with Eric Schumacher-Rasmussen, the Chief Marketing Officer at id3as, about their flagship …

Figure shows the different components to live streaming latency.

The Quality Cost of Low-Latency Transcoding

While low-latency transcoding sounds desirable, low-latency transcode settings can reduce quality and may not noticeably …

Leave a Reply

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