動画変換処理の概要

このドキュメントでは、AWS の ECS でホスティングしている Transcoder サーバーについての情報をまとめます。

NOTE

Transcoder サーバーの開発方法についてはこちらのドキュメントを参照してください。

全体の流れ

Frontend
- Vercel でホスティングされた Next.js です
Backend
- ECS でホスティングされた NestJS
SQS
- AWS SQS
Transcoder(ECS)
- ECS でホスティングされた、カスタマイズ ffmpeg を組み込んだ Ubuntu サーバー
MediaConvert
- CMAF ファイル (ストリーミング用ファイル群) を作成するために利用している

mermaid

sequenceDiagram
    participant Frontend
    participant Backend
    participant SQS
    participant Transcoder(ECS)
    participant MediaConvert

    Frontend->>+Backend: リクエストを送信
    Backend->>+SQS: job をキューに送信
    loop 定期的なキューの確認
        Transcoder(ECS)->>SQS: キューの確認
    end
    Transcoder(ECS)->>Transcoder(ECS): キューが存在する場合、動画変換処理を実行
    Transcoder(ECS)->>MediaConvert: 一部処理を job として送信
    Transcoder(ECS)->>+Backend: 完了通知を送信
    Note right of Backend: 一連の処理が終了

Transcoder サーバーとは

Transcoder サーバーは、動画の変換処理を行うサーバーです。Docker で image を作成して ECS でホスティングされています。 Docker 内部では、Ubuntu をベースイメージとして、カスタマイズした ffmpeg をビルドして環境を構築しています。

ffmpeg は、Cisco が配布する OpenH264 バイナリを組み込む形でカスタマイズしています。

参考:

OpenH264 に対応した FFmpeg をビルド | リアキテク・ラボ Tech Blog

実装詳細

`VideoConverterService` において `-full-cfr.webm` を新たに追加した理由

今回の Transcoder への処理移行に伴って、既存だった -full.webm に加えて -full-cfr.webm という suffix を追加しています。

これは -full.webm suffix を持つファイルがアップロードされた際に、既存の別の処理 (Backend 側で Event Bridge のイベントを受け取る部分) が動作しないようにするためです。

また、MediaConvert での CMAF 作成時に、入力ファイル名から拡張子を除いた文字列が、出力のファイル名に利用されるため、このような suffix を追加することで、MediaConvert でのファイル名の衝突を防ぐことができます。

今まで動画処理フローとの差分

今までのフローは下図のように、複数の動画変換サービスが、複数の処理を直列的に扱っており、複雑かつ処理時間が長くなってしまっていました。

TODO: このあたりは必要があればまた詳細にまとめる @YukiOta

参考:

動画変換処理の概要 ​

全体の流れ ​

Transcoder サーバーとは ​

実装詳細 ​