クラウドMac mini動画トランスコード実践:FFmpeg + VideoToolboxバッチパイプライン

先週、映像編集の外注仕事をしている読者からチケットで質問がありました。クライアントから4K ProRes素材200本を丸ごと渡され、H.264で納品しなければならない――ノートPCで1本転送するのに18分かかり、全部処理し終わる頃には深夜まで作業する羽目になる、とのことでした。この種の作業のボトルネックはアルゴリズム選定ではなく、常にエンコーダーのスループットです。そしてApple SiliconのVideoToolboxハードウェアエンコーダーは、多くの人が過小評価している処理能力そのものなのです。

シーン:なぜトランスコードをクラウドに移すべきか

トランスコードは典型的な「不定期の重負荷」作業です。普段は使わず、納品直前に一気に負荷が集中します。Mac Studioを自前で用意しても普段は遊ばせておくだけで割に合いません。一方、クラウドサービスのGPUインスタンスは大半がCUDAエコシステム向けで、H.264/HEVCのハードウェアエンコードはむしろソフトウェアエンコードに回されがちです。専有Mac miniの強みはここで明確になります。VideoToolboxはシステムレベルのAPIであり、仮想化レイヤーを選びません。日単位でレンタルして処理が終わればすぐ解約でき、コストとスケジュールの両方をコントロールできます。

経験則として、1本あたりのトランスコード時間×並列上限×1.3倍の余裕を掛けた値が、レンタルすべき日数の目安です。「理論上のフル速度」でスケジュールを組んではいけません――マシンにも休息やリトライ、バッファが必要です。

VideoToolboxは何を高速化しているのか

VideoToolboxは、H.264/HEVCの動き推定や変換・量子化といった計算量の多い処理を、メディアエンジン(Media Engine)の専用ハードウェアモジュールに委譲します。CPUはスケジューリングとコンテナ処理だけを担当します。ソフトウェアエンコードのlibx264と比較すると次の通りです。

その差の代償は画質です。同じビットレートではVideoToolboxのディテール保持力はx264のslow設定にやや劣りますが、通常の視聴距離ではほとんど気になりません。バッチ納品用途としては十分実用的です。

環境構築

インストールと動作確認

クラウドのMac miniを入手したら、まずハードウェアエンコーダーが使えるか確認します。

brew install ffmpeg
ffmpeg -encoders 2>/dev/null | grep videotoolbox

h264_videotoolbox と hevc_videotoolbox の2行が表示されればOKです。画質の仕上がりを先に確認したい場合は、短いサンプルを1本転送してみましょう。

ffmpeg -i sample.mov \
  -c:v h264_videotoolbox -b:v 12M -tag:v avc1 \
  -c:a aac -b:a 192k \
  sample_out.mp4

エンコードパラメータ対照表

バッチ処理を始める前に、パラメータのテンプレートを決めておきましょう。素材ごとにその場でパラメータを調整すると、出力の一貫性が崩れてしまいます。

バッチ処理パイプライン

コマンドを1本打つだけなら誰でもできます。本当に時間を節約できるのは、「ファイルを入れれば自動的に結果が出てくる」仕組みをパイプライン化することです。

ディレクトリ監視スクリプト

ポーリングスクリプトで入力ディレクトリを監視し、新しいファイルが見つかればタスクキューに投入します。並列数を制御して、ハードウェアエンコードチャンネルの取り合いを防ぎます。

#!/bin/bash
WATCH_DIR="$HOME/incoming"
OUT_DIR="$HOME/transcoded"
MAX_JOBS=3

mkdir -p "$OUT_DIR"

while true; do
  for f in "$WATCH_DIR"/*.mov; do
    [ -e "$f" ] || continue
    base=$(basename "$f" .mov)
    lock="$OUT_DIR/${base}.lock"
    [ -e "$lock" ] && continue

    running=$(jobs -r | wc -l)
    if [ "$running" -ge "$MAX_JOBS" ]; then
      sleep 5
      continue
    fi

    touch "$lock"
    (
      ffmpeg -y -i "$f" \
        -c:v h264_videotoolbox -b:v 12M -tag:v avc1 \
        -c:a aac -b:a 192k \
        "$OUT_DIR/${base}.mp4" \
        && mv "$f" "$OUT_DIR/${base}.mov.done" \
        && rm -f "$lock"
    ) &
  done
  sleep 10
done

MAX_JOBS=3 は経験値であり、万能の数字ではありません。機種によってメディアエンジンのエンコードチャンネル数が異なるため、まず1本だけ処理して速度を測定し、そこから並列数を段階的に増やしていくことをお勧めします。1本あたりの処理時間が明らかに増え始めたら(通常は2~3並列を超えたあたり)、それがそのマシンのハード的な上限です。

よくある落とし穴とチェック項目

• 一時ファイルはローカルSSDに置く:トランスコードのキャッシュにネットワークドライブを使わないこと。I/Oの揺れによりエンコーダーが待機状態になり、全体のスループットが低下します。
• 音声のサンプリングレートが統一されていない:クライアントの素材には44.1kHzと48kHzが混在していることがあります。バッチ処理の前に ffprobe で一度スキャンして統一しておかないと、結合時に音声と映像がずれる原因になります。
• カラースペースのタグ欠落:HDR素材をトランスコードする際は、-colorspace bt2020nc -color_primaries bt2020 -color_trc smpte2084 を明示的に指定してください。指定しないと、プレイヤーがSDRとして解析し、映像が灰色っぽく見えることがあります。
• ロックファイルの残留:スクリプトが異常終了すると .lock ファイルが残り、キューが止まってしまいます。2時間以上経過したロックファイルを定期的に削除する処理を追加しておきましょう。
• ディスク容量の見積もり:トランスコード前後でファイルが同時に存在するため、一時的に2倍の容量を消費します。バッチ処理を始める前に、素材の総容量が機種の内蔵ストレージの70%を超えないか計算しておきましょう。

容量計画:どのプランをレンタルすべきか

映像のトランスコードはメモリ帯域とストレージのスループットに敏感で、チップの型式そのものは決定的な要因にはなりません。日常的なバッチ納品(1回あたり数十本の4K素材)であれば、M4R M(M4 / 24GB / 512GB SSD、$40.8/日、$203.9/月)で基本的に十分です。素材の容量が大きく、複数のHEVCマスターを同時処理したり、マルチトラック合成プレビューを行う場合は、M4R L(M4 Pro / 64GB / 2TB SSD、$60.6/日、$302.8/月)の方がメモリとストレージに余裕があり、キャッシュ不足によるエラー中断を避けられます。

よくある質問