Elemental Inferenceを使ってMediaConvertで縦動画を自動で作ってみた

AWS Elemental Inference

AWS Elemental Inferenceは、2026年2月下旬に提供開始されたサービスです。
サービスの概要については以前の記事で簡単に紹介しているので、あわせてご覧ください。
AWS Elemental Inferenceをローンチ当日に早速使ってみた

スポーツ中継などの16:9の横型映像をSNS向けの縦型動画として投稿したいとき、これまでは編集ソフトで切り出しや調整をしてから投稿する必要がありましたが、AWS Elemental Inferenceを使えば編集ソフトなしでリアルタイムに縦型変換が可能です。

ローンチ初期はライブ映像のリアルタイム変換のみに対応していたので、後日、以下の記事のようにMediaLiveとStep Functionsを組み合わせて、mp4を無理やりライブとして流して変換する力技をしていました。

Elemental Inferenceを使って横動画mp4をAI処理で縦動画に自動変換してみた

この記事の公開日が3月30日だったのですが、その2日後の4月1日にMediaConvertのユーザーガイドが更新されていました…。

Elemental Inference を使用したスマートトリミング MediaConvert は、Elemental Inference によるスマートクロッピングのサポートを追加しました。

前回の記事で「いつかMediaConvertにも実装されることを夢見つつ」と書いていたら、本当に実装されていました。 しかも2日後に。
ということで、半年経ってしまいましたが、ケリをつけるためにも早速使ってみます。

MediaConvertを使ったスマートクロッピング

まず今回使用するキューの最大同時フィード数を増やします。

スマートクロッピングを有効にしたジョブは、実行中にElemental Inferenceの「フィード」を1つ使います。MediaConvertではキューごとに「最大同時フィード数」を設定できるのですが、これがデフォルトでは0になっています。

左メニューの「キュー」から使用するキュー（今回はDefault）を選び、「キューの編集」で最大同時フィード数を設定します。

今回は最大同時フィード数を1にしました。
これで、このキューで同時に実行できるスマートクロッピングのジョブが1つになります。

次に、ジョブで指定するIAMロールに、Elemental Inference用のアクセス許可を追加します。ドキュメントに記載されているポリシーは以下のとおりです。

{
 "Version": "2012-10-17",
 "Statement": [
	 {
	 "Effect": "Allow",
	 "Action": [
		 "elemental-inference:CreateFeed",
		 "elemental-inference:AssociateFeed",
		 "elemental-inference:PutMedia",
		 "elemental-inference:GetMetadata",
		 "elemental-inference:DeleteFeed",
		 "elemental-inference:TagResource"
		 ],
	 "Resource": "*"
	 }
 ]
}

あとは普段どおりのMediaConvertの設定に進むだけです。
出力の動画設定で、幅1080・高さ1920の縦型に設定します。

そして「Scaling」の項目の「スケーリング動作」で「Elemental Inferenceを使用したスマートクロッピング」を選択します。

それだけです。 それだけで縦型動画を作ることができました。

今回の素材では、ジョブを送信してから完了まで約2分でした。
前回のStep Functions版では、チャネルの起動待ち、尺ぴったりで止められない問題、TSからmp4への変換、書き出し完了待ちなど、いろいろ工夫が必要でしたが、それが全部不要になりました。

出力結果

実際にスマートクロッピングを使ってみての所感です。

サッカー

公式ドキュメントでも例に挙がっているとおり、サッカーではボールを基本的に捉えながら追従してくれました。
通常のゲームフォローカメラでも前後に切り返すようなドリブルのときは一瞬見切れることがありましたが、基本的には全く問題なく見ることができました。
ゴールが決まったあとの寄りのカメラでのリプレイ映像では見切れてしまうこともありましたが、そもそもできるだけ大きく細かいプレイを見せている16:9の画角を無理やり9:16にしているので仕方ないのかなと思っています。

バスケットボール

こちらもElemental Inferenceがハイライト生成の対象としている競技です。
シュートが決まってそのまま切り返したときや、リバウンド後にすぐパスが出たときも、ちゃんと画角内にボールがある形で縦動画を作ることができました。

ラグビー

ラグビーもボールを中心に追従していたので、おおむね問題なく見ることができました。
一方で、「今はディフェンス側のラインが見たい」「今は後ろのフォーメーションが見たい」など、その時々でボールをどちら寄りに置くかの判断は難しいなと感じました。ただ、そもそも9:16の画角で見せられる幅ではないので、やむを得ないかなと思います。

野球

こちらはやっぱりしんどかったです。
野球はボールの近くだけが大事なスポーツではなく、16:9の画面いっぱいを使って、ボール、守備、走者の位置などを1枚の画で見せます。そのため「そっちじゃないのにな」ということもたくさんありました。
また、バックスクリーン側から投手と打者・捕手を1画面に収める、いわゆるP-C映像では、9:16ではそもそも両方を映すことができないのが難点でした。

ボールと選手の動きが画面の一部に集中する競技ほど相性が良く、画面全体の配置で状況を伝える競技ほど難しい、という印象でした。
（予想通りっちゃ予想通りですが…）

最後に

以前MediaLiveで力技で行っていたときよりも、簡単に、速く変換することができました。

今回はスポーツに特化していろいろ試してみましたが、スポーツ中継は16:9の画角の中でいろいろなものを表現しているんだな、と、中継映像の作り方のクオリティを再認識することができました。
単純に9:16で見せるだけでは物足りないとも感じました。 とはいえ、うまく使えば縦型動画でのSNS展開がスピードアップすることが見込まれます。

一方で、MediaConvertで変換したあとに、クオリティを上げるために一部だけ修正したい、ということもあると思います。
MediaLiveのときは、チャネルの設定時に裏でフィードが作られ、チャネルを削除してもARCHIVEDとして残っていたので、フィードが残っている限りは座標を取得できました。
一方、MediaConvertでは、フィードはジョブごとに作成され、ジョブ完了とともにDeleteFeedまで実行されるため、あとから「どういう座標で変換していたのか」を知ることができませんでした。

変換中に強引に読み取ることはできましたが、これを自動化しようとすると、EventBridgeでMediaConvertのジョブ開始を検知してLambdaを起動して…といった仕組みを自前で実装する必要があります。

マネージドサービスで簡単にサービスを連携して使えるメリットがたくさんある一方で、細かいところまで追求したくなると、少しかゆいところに手が届かない…。 「座標のJSONをS3に書き出すオプション」のように、公式で何か用意されるといいなと思いながら、またアップデートを待ちたいと思います。