My preferred method for transcoding mpeg2-ts streams recorded off my FiOS QAM cable tv with an HDHomeRun Prime is HandBrake. It does better than ffmpeg at dealing with slightly dirty video where the frames per second is not constant; ffmpeg fails to keep the audio in sync with the video which can be maddening. I prefer the CLI version since the beefiest machines in the household have 32 cores of AMD Opteron 6274 but no video screen.

I had been puzzling for a while as to why I was only managing to drive the VM that I'm running these transcodes in to a little less than 50% CPU utilization. Didn't prioritize it too highly because I assumed that it had something to do with some kind of hyperthreading pseudo-cores but I could find no indication that this was in fact the case from reading the cut sheet on the 6274.

This morning I noticed the following in my stderr:

{% raw %}

[mpeg2video @ 0x7ff8e80008c0] Application has requested 17 threads. Using a thread count greater than 16 is not recommended.

{% endraw %}

Well then. I guess "threads=auto" (which correctly found 32 cores and requested them all) wasn't such a hot choice. Sure enough, running two HandBrake processes at once on different content drove our CPU utilization to the mid 90s, with only a slight throughput hit on the reported transcode speed for each one.

Effectively I've doubled my throughput by running two queues on a 32 core machine. Worthy of consideration if you happen to have more cores at your disposal than the average bear.