1回のアップロードで6つの成果物
今日のたった1つのソース映像は、9:16の縦型Reel、1:1のスクエアカット、16:9の横長バージョン、自動再生用のミュート・字幕付きバリアント、ロゴとイントロ/アウトロ付きのブランドカット、そして接続が不安定な場所でもすぐに読み込める圧縮バージョンにならなければなりません。同じコンテンツでも、6つ以上の異なる形式に毎日、すべてのキャンペーンとすべてのクリエイターに対して増幅されます。
これを大規模に解決するということは、ビデオは手動で編集されるのではなく、プログラムで変換される必要があるということです。それが私たちのパイプラインでFFmpegが果たす役割です。
FFmpegである理由
FFmpegは、オーディオとビデオの変換、フィルタリング、エンコーディングを行うための無料のオープンソースコマンドラインツールです。UIはありません。必要なことをコマンドとして正確に記述し、それが実行されます。これこそがその価値提案全体です。コマンドはコードによって生成され、ユーザーごとにパラメータ化され、パイプラインにキューイングされ、人手を介さずにサーバーで実行できます。ビデオ編集は、クリックして進めるものではなく、プログラムする対象になります。
単に「使えるビデオツール」であるだけでなく、以下の3つの特性がこの特定の問題に最適な理由です。
構成可能なフィルター。 FFmpegのfiltergraphを使用すると、スケール → クロップ → オーバーレイ → フェードを単一のパスで連結できます。これは、各ステップで中間ファイルを書き込むのを避けるため重要です。各操作間で再エンコードを行う素朴なパイプラインは、レンダリング時間とストレージのチャーンの両方を増やします。チェーニングにより、多段階の変換を1回のエンコードに抑えることができます。
再エンコードだけでなく、ストリームレベルの操作。 トリミングなどの操作では、FFmpegは既存のストリームをデコードして再エンコードする代わりにコピーできます。
ffmpeg -i input.mp4 -ss 00:00:08 -t 15 -c copy highlight.mp4
-c copyは、数秒で終わるトリムと、完全な再エンコードと同じくらい時間がかかるトリムとの違いです。ピクセルデータに触れる必要がない操作（トリミング、フォーマットのリマックスなど）ではこれを使用し、スケーリングやオーバーレイなど、実際に必要なステップのために完全な再エンコードを取っておきます。
ハードウェア対応エンコーディング。 FFmpegは、CPUのみのlibx264の代わりに、GPUエンコーダー（NVENC、QSV、VideoToolbox）を介してルーティングできます。GPUエンコーディングは大量処理における生の処理能力で優位に立ちます。一方、libx264は特定のビットレートでより予測可能で調整可能な品質を提供します。どちらを使用するかは、確定したデフォルトではなく、実際のトレードオフです。私たちは、品質管理が最も重要となるブランド向けのものはCPUエンコーディングに重点を置き、大量で優先度の低いバッチにはGPUパスを使用しています。
パイプラインでの実際の使用方法
リフレーミング。
最も一般的な要望は「これをどこにでも合うようにしてほしい」というものです。横長のソースは、スケールとクロップによって縦長のReelになります。単純なクロッピングは高速ですが、フレームの一部が切り捨てられます。被写体が中央にある場合は問題ありませんが、中央から外れる場合は不適切です。そのようなケースでは、正しくスケールされた前景コピーの背後に、ぼかされたフルフレームの背景を使用するフォールバックを行います。これにより、何も切り取られません。
ffmpeg -i input.mp4 -filter_complex \
"[0:v]scale=1080:1920,boxblur=20:5[bg]; \
[0:v]scale=1080:-2[fg]; \
[bg][fg]overlay=(W-w)/2:(H-h)/2" \
-c:a copy output_blurred.mp4
これは単一のデフォルトフィルターではなく、意図的な2パスの決定です。安全な場合はクロップし、そうでない場合はぼかしフォールバックを行います。
ブランディング、キャプション、オーディオ。 ロゴ、イントロ、アウトロは、パラメーター化されたオーバーレイと連結として適用されるため、パイプラインコードに触れることなく、ブランドごとに位置、サイズ、不透明度を変更できます。キャプションはフレームに直接焼き付けられます。個別の字幕トラックとして配信するのではなく、自動再生でミュートされるフィードでは、キャプションが宛先プラットフォームが適用するどのような再エンコードにも耐える必要があるためです。焼き付けられたキャプションは常にそれに耐えますが、字幕トラックはそうでない場合があります。オーディオはミキシングされ、ラウドネスが正規化されるため、スクロールフィード内で前のクリップよりも耳障りなほど大きいクリップはなくなります。
配信。 すべての出力は+faststartでエンコードされます。これはファイルメタデータを先頭に移動させることで、ファイル全体がダウンロードされる前に再生を開始できるようにします。特に短尺ビデオの知覚される読み込み時間に対して絶大な効果をもたらす小さなフラグです。
現在も検討中のトレードオフ
ここでのすべての決定が確定しているわけではありません。GPU対CPUエンコーディングは最も頻繁に見直す点です。ボリュームが増えるにつれてGPUのスループットは魅力的ですが、ブランドにとって重要な出力では、ビットレートあたりの品質の一貫性は依然としてCPUエンコーディングが優位です。現在、この分割はジョブタイプごとに手動で処理されています。これを自動的で品質を考慮したルーティング決定にすることは、このパイプラインで構築を進めている次の部分です。
これが重要な理由
まとめると、1回のアップロードで、それを縦長、スクエア、横長のバリアントにリフレーミングし、ブランディングし、キャプションを焼き付け、最も強力なカットにトリミングし、オーディオをミキシングおよび正規化し、高速配信のために圧縮するパイプラインがトリガーされます。これらはエディターがタイムラインを開くことなく実行されます。さらにスケールするには、各ジョブが独立しておりステートレスであるため、より多くのFFmpegワーカーを並行して実行することを意味します。
Reelsのトレンドは、コンテンツの見え方を変えただけでなく、手動編集では追いつけないタイムライン上で、1つのコンテンツが取らなければならない形式の数を変えました。FFmpegは、ビデオを手動でクリックして進めるものではなく、プログラム可能で構成可能なものとして扱うため、これに対応できます。これがこのパイプラインがスケールする本当の理由です。FFmpegが抽象的に強力だからではなく、その中のすべての決定 — クロップ対ぼかしフォールバック、ストリームコピー対再エンコード、GPU対CPU — がデフォルトではなく、ケースごとに意図的に行われるからです。
このようなパイプラインを構築中で、アーキテクチャについてセカンドオピニオンが必要な場合は、お問い合わせください。
