回答:
使用されるコーデック、ffmpegバージョン、およびCPUコア数に依存します。コアごとに単に1つのスレッドである場合もあります。時にはもっと複雑です：
libx264では、フレームスレッドの場合はコアx 1.5、スライススレッドの場合はコアx 1です。
2014年の時点では、最適な数が使用されています。
topffmpegのさまざまなオプションを使用してCPU負荷（Linux：、Windows：タスクマネージャー）を調べることにより、マルチコアコンピューターでこれを確認できます。
-threads 0 （最適な）;
-threads 1 （シングルスレッド）;
-threads 2 （たとえば、Intel Core 2 Duoの場合は2スレッド）。
なし（デフォルト、最適）。
2015年の編集： 12コアCPUの一部のffmpegコマンドでは、Linux topで最大200％のCPU（2コアのみ）が表示され-threadsます。したがって、デフォルトは「このffmpegバイナリが取得できる限り」という意味では依然として最適ですが、「リートCPUを完全に活用する」という意味では最適ではありません。
これらの回答のいくつかは少し古いので、Ryzen 5 2600Xシステムの6コア/ 12スレッドすべてを引数なしで最大ffmpeg 4.1化したを使用してエンコードします。libx264-thread
-vcodec libx264 -profile:v high444 -refs 14 -preset ultrafast -crf 18 -tune fastdecode。追加し-threads 12ても効果はありませんでした。
CentOS 6.5 VM（Ryzen 1700 8c / 16t-vmに16コアのうち12が割り当てられています）での変換で遊んでいました。480pムービーの実験では、次のことが明らかになりました。
スレッドオプション/変換レート（fps @ 60秒）
(none/default)/130fps
-threads 1/70fps
-threads 2/120fps
-threads 4/185fps
-threads 6/228fps
-threads 8/204fps
-threads 10/181fps
おもしろいのは、CPUのロード（htopそれを見るために使用）でした。130fpsの範囲で巻き上げられたオプション
を使用せず-threads、低負荷レベルですべてのコアに負荷が分散されます。
1つのスレッドを使用すると、まさにそれが行われ、1つのコアが100％でロードされました。他のものを使用すると、別の分散負荷状況が発生しました。
ご覧のとおり、リターンが減少する点もあるため、特定のマシンの-threadsオプションを調整する必要があります。具体的には、-threads 6（12コアマシン上）を使用すると、ビデオを変換するとき（異なるビットレートでh264からx264に強制的に変換する）に最高のFPSが得られ、実際に返されたスレッドは、より多くのスレッドそれ。
メモリの問題でもある可能性があります-VMに割り当てられたのは1GBのみでした。私はそれを微調整し、それが何かを変えるかどうか見るかもしれません。それでも-この-threadsオプションを使用するとパフォーマンスが向上する可能性があるため、特定のマシンでさまざまなレベルでテストを実行して、セットアップのスイートスポットを見つけてください。