AWSの機械学習を活用したライブ・放送ビデオモニタリングの自動化

放送およびオーバーザトップ（OTT）ライブストリームのサービスプロバイダーは、大量コンテンツの品質チェックを行う必要があります。品質チェックの範囲は、低レベルの信号エラーからコンテンツ自体のエラーなど高レベルの問題にまで至ります。従来のライブメディア解析ソフトウェアは、ETSI TR 101 290 プライオリティチェック1および2など、信号レベルでの品質チェックに重点を置いています。番組内容、字幕、音声言語の検証など、より高レベルな品質チェックは、放送ストリームで問題がないか人間のオペレーターによって常にモニタリングが行われています。放送ビデオストリームの数が増加するにつれて、追加のチャンネルや番組をサポートするために、手動のモニタリング作業をスケールすることは困難であり、コストもかかります。

近年、人工知能(AI)の進歩により、かつて完全に手動で行われていた多くの高レベルのモニタリングタスクは自動化が可能となってきています。AIベースの検出から得られるサポートにより、人間のオペレーターは、より高レベルのタスクに集中し、問題をより迅速に対応し、より多くのチャネルを、より高い精度でモニタリングすることができます。このブログ記事では、Amazon RekognitionなどのAWS AIサービスを使用して、HTTPライブストリーミング(HLS)ビデオストリームのコンテンツを分析する、サンプルアプリケーションについてご説明します。ほぼリアルタイム(15秒未満)でモニタリングチェックの様子をご確認いただくことができます。また、追加のユースケースをサポートするために、サンプルアプリケーションを拡張する方法についてもご説明します。

前提条件

サンプルアプリケーションコードをGitHubリポジトリで共有しました。ご自身のアカウントにアプリケーションをデプロイして、独自のモニタリングユースケースに合わせてカスタマイズを行う場合は、下記があることを確認してください。

管理者権限を持つAWSアカウント
Githubアカウント
Python 3とpipenvのインストールが完了していること
ソリューションをデプロイするために、AWS CloudFormationおよびPythonに関して事前にご経験があることが望ましいですが必須ではありません。

このソリューションをお試し頂く前に、この記事で使用しているテクノロジーとスタンダードをよく理解しておくこともお勧めします。

HLSは、HTTPアダプティブビットレートストリーミング通信プロトコルです。
AWS Elemental MediaLiveは、放送およびストリーミング配信用のライブ出力を作成できるリアルタイムビデオサービスです。
AWS Step Functionsは、サーバーレスワークフローオーケストレーターです。
Amazon Rekognition Custom Labelsを使用すると、ビジネスニーズに固有のオブジェクトとシーンを識別するモデルを構築することができます。

ソリューションの概要

放送品質管理のソリューションでは、ライブストリームのさまざまな側面をモニタリングして、次のことを確認する必要があります。

ビデオ— 空白の画面、ピクシレーションやブロック状のアーティファクトが存在しないこと。動きがスムーズで、スケジュールに従って正しいコンテンツが再生されていること。
オーディオ— 適切な音量で音声が流れていて、音声と映像にずれがなく、適切な言語であること。
ロゴとグラフィックオーバーレイーロゴが表示されており、トリミングされていないこと。オーバーレイがスケジュールに従って適切に行われており、すべてが正しくリフレッシュされていること。
クローズキャプション— 正しいタイミングで、字幕が音声に一致し、適切な言語で使用可能なこと。
埋め込まれたメタデータ（SCTEなど）― 正しく挿入されていて、メタデータが存在すること。

これらのチェックの一部は従来の画像および音声解析アルゴリズムを使っても実行できますが、多くはカスタム機械学習（ML）モデルを使った検出によく適しています。サンプルアプリケーションは、自動化のためのさまざまなアプローチを代表してこれらチェックのサブセットを実装します。

音声の無音検出—音量の閾値に基づいており機械学習は不要です。
ステーションロゴの検証—画像から既知のロゴを識別するには、畳み込みニューラルネットワーク（CNN）ベースのMLモデルがよく適しています。このアプリケーションでは、Amazon Rekognition Custom Labelsを活用して、この機能のためにオブジェクト検出モデルを構築しました。
正しいビデオコンテンツの検証（ドメイン固有）—正しい番組がスケジュールに従って再生されているかどうかを判断することは複雑なタスクですが、この課題をより具体的な問題として分解することで、ベストな解決に導くことが出来ます。さまざまなMLモデルのアンサンブルを使用すれば、ストリーミングされている番組をコンピュータで識別することができます。このアプローチを実証するために、特定のドメイン、すなわちライブストリームのチームスポーツに対するコンテンツ識別を実装しました。スポーツイベントの内容を、以下を組み合わせることによって検証することができます。
- 高レベルな番組タイプ：そのビデオはスポーツ番組に見えますか？もしそうなら、適切なスポーツが再生されていますか？（サッカーなど）。この質問に答えるために、我々はRecognition Custom Labelsを使用してカスタム画像分類モデルを構築しました。
- スポーツチームの識別:ビデオに正しいスポーツが表示されている場合、適切な試合がストリーミングされていることを確認できますか？サッカーやフットボールなどのチームスポーツでは、プレイしているチームを識別するさまざまな視覚信号と音声信号があります。サンプルアプリケーションでは、2つの異なるMLアプローチを組み合わせて、この質問に答えます。1つ目のアプローチでは、Amazon Rekognitionのテキストインイメージ抽出機能を使用して、画面上でチーム名や略語を検索しました。また、2つ目のアプローチでは、Rekognition Custom Labelsを活用して、特定のサッカーチームのロゴを認識するように、モデルをトレーニングしました。

ソリューションアーキテクチャ

アプリケーションのソリューションアーキテクチャは、次の3つの主要なコンポーネントで構成されています:

AWS Elemental MediaLiveによって生成されたHLSストリームをAmazon Simple Storage Service(Amazon S3)バケットに格納するビデオ取り込みパイプラインです。
AWS Step Functionsによってオーケストレートされたビデオ処理パイプラインです。各ビデオセグメントから抽出されたフレームとオーディオのモニタリングチェックを実行します。
ビデオストリームで実行されている各モニタリングチェックのリアルタイムステータスと詳細を示すWebアプリケーションです。

Broadcast Video Monitoring architecture

(放送ビデオモニタリングのアーキテクチャ)

ビデオの取り込み

今回紹介するサンプル放送モニタリングアプリケーションでは、AWS Elemental MediaLiveがソースコンテンツを取り込み、HLS形式にトランスコードします。ソースコンテンツは、ストリーミングカメラ、コントリビューションエンコーダアプライアンス、他のHLSストリームなど、多数のアップストリームシステムから入手できます。アプリケーションのテストと開発のためにAmazon S3に保存されたmp4ファイルをMediaLiveチャンネルの入力ソースとして使用することを選びました。入力にS3ファイルとMediaLiveの自動ループ機能を使用すると、開発用とテスト用のライブストリームを簡単に作成できます。

AWS Elemental MediaLiveのもう1つの便利な機能は、HLSファイルをAmazon S3に書き込む機能です。このS3のHLS出力オプションを有効にすると、ライブストリーム用に新しい.tsセグメントファイルが生成されるたびにそのファイルがS3オブジェクトに書き込まれ、新しいバージョンの.m3u8プレイリストファイルがアップロードされます。これにより、これらのS3のアップロードイベントにAWS Lambdaトリガーを直接設定して、新しいHLSセグメントごとに処理ワークフローを開始することができます。これについては、次のセクションで詳しく説明します。

ここではプッシュモデルを使用してビデオの取り込みを簡素化するために、MediaLiveのS3へのHLS出力機能を使用していますが、ポーリングモデルも使用できるという重要な点があります。これには、モニタリングが必要な各HLSストリームの新しいセグメントを継続的にポーリングしてダウンロードを行う、長時間稼働するAmazon EC2インスタンスまたはAWS Fargateコンテナのフリートを設定する必要があります。ポーリング方式では、より多くのエンジニアリングの労力と運用コストが必要になりますが、柔軟性が向上し追加でトランスコーディングを導入することなく、任意のメディアサーバーによって生成されるライブストリームをモニタリングするのに利用することができます。

ビデオの取り込みと処理パイプラインのデプロイ

サンプルアプリケーションのビデオ取り込みとバックエンド処理パイプラインをご自身のアカウントにデプロイする場合は、以下の手順に従います（そうでない場合は、次のセクションに進んで、続きを読んでください）。

次のボタンをクリックして、CloudFormationスタックを起動します:
「次へ」のボタンを選択し、続行します。
「Step 2: Specify stack details」で、スタックパラメータを確認します。これらの設定は、アプリケーションによって生成およびモニタリングされたAWS Elemental MediaLiveパイプラインの、HLSストリームのソースを設定します。初期設定を維持することで、提供したS3でホストされているサンプルmp4ファイルを使用してテストストリームを生成します。これらの設定は、自分のビデオファイルやストリームを指定するように変更できます。スタックが作成されたら、AWS Elemental MediaLiveコンソールで上記の操作をすることで、入力設定をいつでも変更できます。AWS Elemental MediaLiveパイプラインでは、変更前にパイプラインを停止することで、異なる入力ソース間をシームレスに切り替えることができます。
(ビデオの取り込みと処理パイプラインのCloudFormationスタックパラメータ)
「次へ」のボタンをクリックします。Step 3 Configure stack optionsページで、すべて初期設定のままもう一度[Next]をクリックします。
Step 4 Review ページで、チェックマークをクリックしてCloudFormationが　IAMリソースとCAPABILITY_AUTO_EXPAND機能を作成できることを確認し、“Create stack”をクリックします。
スタックの起動が完了するのを待っている間、このブログの残りの部分を読み進めてください（動画再生用のCloudFrontディストリビューションが作成されるため、約10分かかる場合があります）。

デプロイメント手順の詳細については、Githubリポジトリの README.md を参照してください。

※CloudFormation実行時にStackNameを変更すると後のStepでエラーが発生しますので、初期設定値のままお試しください。

新しいビデオセグメントのイベントドリブンな処理

新しいビデオセグメントによって生成されるイベントは、ビデオ処理パイプラインのモニタリングチェックを進めます。Elemental MediaLiveによって.m3u8プレイリストファイルの新しいバージョンがS3に書き込まれるたびに、AWS Lambda関数StartSfnFunction（ソースコードはこちら）がトリガーされます。呼び出されたLambda関数は、新しいHLSセグメントで分析ワークフローを実行するStep Functionsステートマシンを起動します。

AWS Step Functionsワークフローは、処理毎に個別のAWS Lambda関数によって実装される処理ステップで構成されます。本番環境では、必要なモニタリングチェックの数とメディアのサンプリングレートは、ライブストリームのスケジュールとコンテンツによって大きく異なる場合があります。サーバーレスおよびモジュラーコンポーネントを使用して処理パイプラインを構築することにより、このアーキテクチャは、変動する需要をサポートするために、簡単でコスト効率に優れた伸縮自在なスケーリングが出来るようになります。サンプルアプリケーションには、実行時に個々のモニタリングチェックを無効にできるシンプルな機能フラグシステムも含まれています(StartSfnFunction Lambda関数の環境変数によって制御されます)。

AWS StepFunctionsステートマシンを作成する場合、Express WorkflowとStandard Workflowの2つのオプションがあります（これらの違いについては、こちらのドキュメントを参照してください）。Express Workflowオプションは、大量かつ短時間のユースケース向けに特に最適化されています。本番環境でExpressモードを活用してビデオストリームを大規模にモニタリングすることをお勧めしますが、StandardオプションのグラフィカルなワークフローUIは、初期開発やテストを行う際により適していることがわかりました。ワークフロータイプは、ステートマシンの作成時に選択され、CloudFormationのパラメータで設定できます（例を参照）。

以下は、あるHLSセグメントでのモニタリングワークフローの実行例をグラフィカルに表したものです。Step Functionsで定義されているワークフローを使用すると、さまざまなモニタリングチェックの実行を並列化して、エンドツーエンドの検出レイテンシーを最小限に抑えることができます。私の行ったテストでは、HLSストリームの各セグメントは、6秒間に設定されています。これは、ライブストリーミングで通常設定される秒数です。処理ワークフローでは、各セグメントのすべての分析ステップを15秒未満で完了できます。ユースケースでレイテンシーを低くする必要がある場合は、HLSのセグメントサイズを2～4秒に減らすことができます。これにより、セグメント全体を読み込む必要のある、パイプラインにおけるステップ（Extract Framesなど）の時間を短縮できます。ただし、AWS Lambda関数呼び出しの数や、S3 put/　getリクエストの数が増加するなど、セグメントを短くすることでシステムに与える可能性がある追加の負荷を考慮してください。

次のセクションでは、その主要な処理手順の詳細について説明します。

Processing pipeline state machine graph
(処理パイプラインのステートマシンのグラフ)

HLSマニフェストを解析する

前出のワークフローの図が示すように、処理パイプラインは、.m3u8 HLSマニフェストファイル(別名：プレイリストファイル)をダウンロードして解析する「マニフェストの解析」ステップから始まります。Elemental MediaLiveによって生成された、HLSの出力ファイルを保存するS3バケットでS3オブジェクトのバージョニング機能を有効にすると、マニフェストファイルをアップデートするたびに、新しいS3オブジェクトのバージョンが作成されます。これにより、マニフェストファイルに対する各アップデートを、少なくとも1回はイベントドリブンな処理フローで処理できます。

マスターマニフェスト（詳細はこちら）を除き、指定されたビットレートのマニフェストファイルには、ストリーム内の最新のメディアセグメントとそのタイミング情報の一覧が含まれます。次の例を参照してください。

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:478
#EXT-X-PROGRAM-DATE-TIME:2020-03-12T21:08:45.867Z
#EXTINF:6.00000,
test_1_00478.ts
#EXT-X-PROGRAM-DATE-TIME:2020-03-12T21:08:51.867Z
#EXTINF:6.00000,
test_1_00479.ts
#EXT-X-PROGRAM-DATE-TIME:2020-03-12T21:08:57.867Z
#EXTINF:6.00000,
test_1_00480.ts
#EXT-X-PROGRAM-DATE-TIME:2020-03-12T21:09:03.867Z
#EXTINF:6.00000,
test_1_00481.ts
#EXT-X-ENDLIST

(HLSマニフェストファイルの例)

マニフェストファイルを解析すると、アプリケーションは最新のメディアセグメント(上記の例「test_1_00481.ts」)、プログラミング時間(上記の例では「2020-03-12T21:09:03.867Z」)、およびその持続時間（上記の例では6秒）を識別し、このセグメントに続く分析を行います。

HLSマニフェストファイルのEXT-X-PROGRAM-DATE-TIMEタグは、アプリケーションが各メディアセグメントのタイムスタンプを把握し、期待されるスケジュールのメタデータと比較できるように存在する必要があります。AWS Elemental MediaLiveでは、これはHLS出力設定の「Manifest and Segments」セクションで有効化できます。

AWS Elemental MediaLive configuration required produce the datetime tag （Datetimeタグを生成するには、AWS Elemental MediaLive設定が必要です)

マニフェストを解析するロジックのソースコードは、こちらのプロジェクトGitHubリポジトリにあります。

想定プログラムのメタデータとの同一性チェック

ブロードキャストのモニタリングアプリケーションが、現在のビデオセグメントで正しいステーションロゴを持ち、正しいコンテンツを再生しているかどうかを判断するには、ストリーム内で検出したものと、スケジュールが期待するものとを比較する必要があります。サンプルアプリケーションでは、期待されるプログラムメタデータがAmazon DynamoDBテーブル、video-processing-dev-Scheduleに格納されます。

DynamoDB view of expected program metadata (DynamoDB view of the expected program metadata)(想定されるプログラムメタデータのDynamoDBビュー)

ワークフローの「Find Expected Program」ステップは、各メディアセグメントのタイムスタンプと時間を読み取り、対応するプログラムとメタデータを検索します。また、スケジュールされたプログラムのメタデータに基づいて、関連の無いモニタリングチェックを動的に無効にします。例えば、前出の表の1行目では、期待される番組はニュース番組です。このタイプのプログラムにはスポーツ識別チェックが適用されないため、この手順では、後の処理でこのチェックをスキップする構成フラグを設定します。

このステップのソースコードはGitHub（こちら）にあります。提供したデモビデオフッテージの値の例を、スケジュールされたDynamoDBテーブルに簡単に入力するには、broadcast-monitoring/scripts/README.md （Githubリンク）の説明に従ってください。

前出の表とコードの例では、プログラムのタイミングに相対的な開始時間と終了時間が使用されています。これは、テスト用ビデオストリームが、録画されたビデオをループで再生することによって生成されるためです。これらのタイムスタンプは、本番環境では絶対的な日付と時刻の値に置き換えられます。

モニタリングチェック#1:オーディオ無音モニタリングの実装

「ラウドネス」のモニタリングは従来のライブメディアアナライザソフトウェアによく見られる機能です。しかし、このサンプルアプリケーションでは、ライブストリームのオーディオトラックでどれほど同等のモニタリングを実現できるかを示すために、無音チェックを実装しました。この実装ではffmpegライブラリを利用して各HLSセグメント上のラウドネスと無音期間を検出します。

このチェックにはMLは使用されませんが、AudioDetection機能はビデオセグメントレベルでチェックを実行する方法の一例です。AWS Step Functionsワークフローはステップ間で渡されるステートマシンデータから、トランスポートストリーム.tsファイルS3ロケーションを取り出し、この機能を実行します。次のコードサンプルに示すように、このサンプルアプリケーションは、Lambda Layersを利用することで、AWSサーバーレスアプリケーションリポジトリに保存されたアプリケーションから、ffmpeg実行可能ファイルをLayerとして利用することができると示しています。

ffmpeglambdalayer:
  Type: AWS::Serverless::Application
  Properties:
    Location:
      ApplicationId: arn:aws:serverlessrepo:us-east-1:496010403454:applications/ffmpeg-lambda-layer-python3
      SemanticVersion: 0.0.3

...


AudioDetectionFunction:
  Type: AWS::Serverless::Function
  Properties:
    CodeUri: ../src/audio_detect/app/
    Handler: main.lambda_handler
    Role: !GetAtt ProjectLambdaRole.Arn
    Layers:
      - !GetAtt ffmpeglambdalayer.Outputs.ffmpegLayerArn

（サーバーレスアプリケーションレポジトリアプリケーションからのLambdaレイヤーの使用例）

この機能はシンプルですが、Amazon Transcribeで使用するオーディオトラックを抽出して、言語を検出したり、キーワードをモニタリングしたり、または、その他の想像力豊かなユースケースを多数検出したりなど、簡単にソリューションとして利用することができます。

ビデオフレームサンプリング

すべての画像ベースのモニタリングチェック（サンプルアプリケーションにおいて、ステーションのロゴの検証、スポーツタイプ、チーム識別など）では、ビデオセグメントから抽出されたフレームでMLモデルを実行する必要があります。効率を最大化するために、Step Functionワークフローの「Extract Frame」ステップでは、OpenCVを使用してビデオからフレームを抽出し、S3に保存します（メタデータはDynamoDBに格納）。抽出されたフレームのセットは、その後の複数の処理ステップによって消費されます。

MLベースの検出の信頼性を高め、外れ値の誤検出に起因するノイズを低減するために、ワークフローは、1つのメディアセグメントから複数のフレームで実行された推論結果を評価します。問題のあるフレームの割合がしきい値を超えた場合にのみ、チェックのステータスを失敗として報告します。一方、ビデオストリームの各フレームでMLモデルを実行するのは、コストがかかるため必要でありません。デモアプリケーションは、Frame Extractor関数の環境変数を用いて、フレームのサンプリングレートを設定可能です。

モニタリングチェック#2:ステーションロゴモニタリングの実装

抽出されたフレームからステーションロゴを識別するために、このソリューションではAmazon Recognition Custom Labelsを使用します。Rekognition Custom Labelsは、データセットを迅速に生成するためのプロセスと組み合わせることで、カスタムオブジェクト検出モデルをこのソリューションに向けて迅速にトレーニング、検証、デプロイすることができます。詳細について説明するために、より深く掘り下げていきます。

トレーニング画像の生成

確実に検出を行うためには、通常カスタムMLモデルのトレーニングを、何千ものサンプルで数日または数週間かけてチューニングする必要があります。Amazon Rekognition Custom Labelsでは、わずか数十から数百のトレーニングイメージで同様の結果を得るためのモデルを構築できます。ステーションロゴのモデルをトレーニングするために、様々な背景画像に異なるステーションロゴを重ねて合成し、トレーニング用の画像を作りました。いくつかのバリエーション（異なるサイズ、グレースケール、不透明度など）で本番のビデオストリームに表示される可能性のあるロゴを検出できる、ロバストなモデルを構築するために画像拡張という手法を適用しました。

トレーニングデータの生成を繰り返し可能なプロセスにするために、これらのステップを自動化するスクリプト（generate-logo-images.py ）を作成しました。各ステーションロゴについて、モデルにそのロゴを認識するように指示します。スクリプトはまずimgugライブラリを使用してロゴを拡張し、次にランダムに選択された位置で異なる背景画像にオーバーレイします。次の図は、拡張されたAWS Elemental ロゴが背景画像にオーバーレイされた結果を示しています（画像に描かれているバウンディングボックスは説明用です）。このプロセスは、トレーニングデータセットで使用可能な画像の数を簡単にスケーリングできる、繰り返し可能なメカニズムを提供します。

Images with augmented logos overlaid used for Rekognition Custom Labels training （Rekognition Custom Labelsのトレーニングに使用される、拡張ロゴがオーバーレイされた画像）

Amazon Recognition Custom Labelsでデータセットを作成し、トレーニングする

Amazon Rekognition Custom Labelsプロジェクトデータセットは、カスタムモデルのトレーニングとテストに使用する画像、割り当てられたラベル、境界ボックスで構成されます。データセットを作成および管理するには、Custom Labelsコンソールを使用します。実験や小さなデータセットの場合、画像をコンソールにアップロードし、手動でラベルを付けて境界ボックスを描くことができます。SageMaker Ground Truthのマニフェストファイルをインポートしてデータセットを作成することもできます。ステーションのロゴを含む画像のコレクションがある場合は、Amazon SageMaker Ground Truthなどのデータラベル付けサービスを使用して、マニフェストファイルを作成できます。既知のラベル(ステーションロゴ)と境界ボックスを使用してトレーニングイメージを人工的に生成したため、生成スクリプトはGroundTruth.manifestファイルを出力して、トレーニングデータセットとテストデータセットを作成します。

私のサンプルアプリケーションでは、トレーニングとテストのために80対20の割合で分割され生成されたデータセットを使用してモデルをトレーニングしました。次の画像は、2時間以内に行われた、800個の画像と200個のテスト画像を含むカスタムモデルのトレーニングと検証結果を示しています。手間のかかる大部分は、Amazon Recognition Custom Labelsが処理しました。

Training and validation results from an object detection custom labels training job （オブジェクト検出Custom Labelsのトレーニングジョブからのトレーニングと検証結果）

Amazon Recognition Custom Labelsを使用して推論を行う

モデルのパフォーマンスに満足したら、次はモデルを実行して処理パイプラインで推論を行います。Custom Labels推論ユニットのスループットを決定する要因は、いくつかあります。ユースケースにおけるパイプラインへ十分な容量をプロビジョニングするために、MinInferenceUnitsを2に設定して、ビデオセグメントを処理するためのバッファを提供します。各ビデオセグメントから抽出されたフレームはLogoDetectionLambda関数によって並列処理されます。AudioDetect関数と同様に、ステートマシンデータは各関数の呼び出しに対し、プログラム情報と、処理されるイメージのS3ロケーションとともに提供されます。

{
      "parsed": {...},
      "config": {...},
      "frame": {
        ...
        "DateTime": "2020-01-23T21:36:35.290000Z",
        "Chunk": "test_1_00016.ts",
        "Millis_In_Chunk": 0,
        "Frame_Num": 0,
        "S3_Bucket": "livestream-artifact-bucket",
        "S3_Key": "frames/test_video_single_pipeline/test_1/original/2020/01/23/21/36:35:290000.jpg"
      }
    }

(Step Functionsステートに渡されるステートマシンデータの例)

モデルのトレーニングを開始した後、次のコードでは推測のためにフレームデータがどのように準備されdetect_custom_labels関数に送信されるかを示します。

    frame_info = event['frame']
    bucket = frame_info['S3_Bucket']
    key = frame_info['S3_Key']
    min_confidence = int(os.getenv('LOGO_MIN_CONFIDENCE', 60))
    model_arn = os.getenv('LOGO_MODEL_ARN')

    ...

    img_data = {'S3Object': {'Bucket': bucket, 'Name': key}}

    with DDBUpdateBuilder(...) as update_builder:
        try:
            response = rekognition.detect_custom_labels(
                Image=img_data, 
                MinConfidence=min_confidence,
                ProjectVersionArn=model_arn
            )
        except ClientError as e:
            ...
        else:
            result = response.get('CustomLabels', [])
            ...

（Custom Labelsを検出するためにLambda関数で使用される、Rekognition APIコールを示すコードサンプル）

入力イベントから抽出されたデータを使用してdetect_custom_labelsを1回呼び出すだけで、カスタムモデルを使用してフレームで推論を行うことができます。その推論の結果は、期待されるプログラムのロゴと比較され、DynamoDBに書き込まれます。これで、以上です。推論を行う際に、手間のかかる大部分は、Amazon Rekognition Custom Labelsが対応します。

モニタリングチェック#3: スポーツの種類検証の実装

Amazon Rekognition Custom Labelsを使用して、静止画像内のロゴを検出する方法について説明しましたが、今度は、スポーツコンテンツを予測する方法を紹介します。放送局は、さまざまなプロバイダーから多くの異なるストリームを処理する場合があり、ストリーミングコンテンツが、プログラムされたコンテンツと一致することを確認する必要があります。コンテンツの正しいスポーツの種類を確認するには、Custom Labelsを活用します。カスタムオブジェクト検出モデルが必要な、ステーションロゴを検出するユースケースとは異なり、スポーツの種類を識別するカスタム画像分類モデルを構築しました。

画像分類のためのトレーニングデータの生成

様々なスポーツやアクティビティでは、どのチームがプレイしていて、どちらの競技者が勝っている、または負けているなどは関係なく、視覚的に似ている部分があります。Custom Labelsは、ラベル付けされた画像のデータセットから、画像分類モデルを構築する機能を提供します。このユースケースでは、データの準備が最も重要な部分ですが、S3においてソースイメージを構造化することで簡単に実現できます。

S3-bucket
└── sports
   ├── soccer
   │ ├── .
    │   └── .
    ├── .
   ├── .
   └── basketball
   ├── .
   └── .

(Custom Labels分類機能を使用するS3フォルダの構造の例）

この記事の範囲外ですが、データセットの生成ではAWS BatchジョブとOpenCVを使用して、5つのテストスポーツの動画からフレームを抽出し、イメージをS3に格納しました。

トレーニングと推論

Training and validation results from a Custom Labels training job （Custom Labelsのトレーニングジョブからのトレーニングと検証結果）

前出の、Rekognitionコンソールの図に見られるように、私たちは約5000枚の画像を含む5つの異なるラベルのスポーツ検出モデルを約2時間でトレーニングしました。データセットの作成における違いを除けば、分類モデルをデプロイする手順は、ロゴ検出モデルと同じです。サンプルアプリケーションのSportsDetectFunctionの実装を確認すると、同様の方法で推論を行うことが可能だとわかります。

モニタリングチェック#4: スポーツチームの検証

スポーツチームの検証のために、サンプルアプリケーションは、2つの異なるML技術を組み合わせて、モニタリングチェックを実行するデモンストレーションを行います。

チーム名と一致するフレームからテキストを抽出する
スポーツチームのロゴ表示を検出する

最初の方法は、放送されるチームスポーツでは、一般的にチーム名や、その略語が入ったグラフィックオーバーレイやバナーを表示するという事実に基づいています（以下の例を参照してください）。

Example of a scoreboard overlay used to detect teams （Custom Labelsのトレーニングジョブからのトレーニングと検証結果）

TeamDetection Lambda関数は、Amazon Rekognitionのテキストインイメージ機能を活用して、抽出されたビデオフレームに存在するテキストを検索します。次に、既知のチーム名、略語、ニックネームのコレクションに対してテキストを照合します。このテキストマッチング機能は、サンプルアプリケーションではかなり単純化されているようですが、Elasticsearchなどのデータベースやファジーマッチングなどのテクニックを使用して、より洗練されたルックアップアプローチをサポートするように拡張することができます。

検出における信頼性を増やし、チーム名のスコアリングバナーが画面に表示されない場合のサポートの時間を増やすために、サンプルアプリケーションは、画面に表示されるスポーツチームのロゴも識別します。特にクローズアップのカメラアングルでは、以下のフレームの例のように、チームのロゴとリーグのロゴが選手のユニフォームに表示されます。

Extracted frame with team logo clearly visible on players jersey （選手のジャージにチームロゴがはっきり見える、抽出されたフレーム）

サンプルアプリケーションでは、再びAmazon Rekognition Custom Labelsを使用して、このチームロゴの検出を行いました。これは、前出のステーションロゴの検出と非常によく似ています。

異なるタイプの情報を使用する2つの異なるMLメソッドの結果を組み合わせることで、両方のメソッドの結果が一致すれば、システムはより高い信頼性を備えた検出を行うことができます。

デモWebアプリケーションを使用してモニタリング結果を視覚化

モニタリングチェックの結果を調べて視覚化するために、AWS Amplify、AWS AppSync、およびVueJSを使用したデモウェブアプリケーションを開発しました。Webアプリケーションのフロントエンドは、Webソケット上のGraphQLサブスクリプションを使用して、新しい各HLSメディアセグメントの分析結果に関する最新情報を受信します。特定のセグメントをクリックしてより詳細な結果を表示すると、各サンプルフレームおよび各評価の信頼度スコアについて、抽出された情報と期待される情報を対比して調べることができます。AWS Elemental Media Packageの時間シフト表示機能によって、選択したセグメントのビデオを再生することもできます。

以下は、音声のないビデオストリームのセクションを検出した、サンプルアプリのスクリーンショットです。指定された時間にニュース番組が予定されているため、2つのスポーツ関連のチェックが無効になっていることにご注目ください。

Web application view where audio is not detected and sports monitoring is disabled (media credit: news video clip originally from the China News Service shared under the CC BY 3.0 License)

（音声が検出されず、スポーツモニタリングが無効になっているWebアプリケーションビューです。メディアクレジット: 情報源は、China News ServiceからCC BY 3.0 licenseで共有されたニュースビデオクリップです。)

スポーツライブストリームをモニタリングするアプリケーションの、別のスクリーンショットの例を次に示します。右側の「サンプルインスペクタ」の枠には、選択したセグメントが、すべてのモニタリングチェックを満たす方法に関する詳細が表示されています。

Web application view with check results for video segment frame （ビデオセグメントフレームのための、チェックの結果を含むWebアプリケーションビューです。）

Webアプリケーションをデプロイし、サンプルアプリケーションを実行する

AWS Cloud Formationを使用してビデオの取り込みと処理パイプラインをデプロイする手順に従った場合は、付属のウェブアプリケーションをセットアップし、モニタリングパイプラインをエンドツーエンドでテストできます。重要なことは、サンプルアプリケーションのいくつかの機能（スポーツ検出、ロゴ検出など）はAmazon Rekognitionに組み込まれているカスタムモデルに基づいているため、デフォルトでは有効になっていないということです。これらの機能を使用せずにアプリケーションを実行するには、次の手順に従います。

AWS Amplify Consoleを使用してアカウントでデモウェブアプリケーションをセットアップするには、GitHub README.mdの手順に従います（これを行う前に、バックエンド処理パイプラインのCloud Formationスタックの起動が完了していることを確認してください）。
DynamoDBで予想されるプログラミングスケジュールテーブルを入力します。提供されたテストソースビデオを使用している場合は、以下のコマンドを実行して、提供されたスクリプトとサンプルスケジュールを使用します。独自のビデオを使用する場合は、それに応じてコンテンツを調整します。
```
cd broadcast-monitoring 
pipenv run python scripts/load_csv_to_ddb.py scripts/schedule.csv video-processing-Schedule
```
DynamoDBコンソールで、ビデオ処理のスケジュールテーブルが入力されていることを確認します。
メディア処理パイプラインを開始します。MediaLiveコンソールに移動し、CloudFormationのスタックによって作成されたMediaLliveチャンネルを起動して、HLSストリームの作成を開始します。（AWS Elemental MediaLiveチャンネルを開始しています）
AWS Amplifyコンソールに移動し、ウェブアプリケーションのURLを見つけ、ChromeまたはFirefoxでウェブアプリケーションを開きます。
電子メールを使用してログイン登録します。確認コードでメールを確認したら、ウェブアプリケーションにログインできます。

ロゴとスポーツの検出機能を有効にするために、Amazon Rekognitionで独自のカスタムモデルをトレーニングし、対応するLambda関数にモデルARNを提供することができます。これを行う方法の詳細については、こちらをご覧ください。

リソースのクリーンアップ

サンプルアプリケーションを起動するために手順に従った場合は、次の手順に従ってデプロイされたインフラストラクチャを削除して、不要な料金が発生しないようにしてください。

AWS CloudFormationコンソールに移動し、amplify-broadcastで始まる名前の Amplifyウェブアプリケーションの、バックエンドリソースのルートスタックを削除します。
メディアの取り込みおよび処理パイプラインのe broadcast-monitoringスタックを削除します。
AWS Amplifyコンソールに移動し、ウェブアプリケーションを削除します。

サンプル・アプリケーションを超えて

この記事では、AWSのAIサービスを使用してライブストリームビデオモニタリングアプリケーションを構築するためのコンポーネントと考慮事項について説明しました。実装されたサンプルアプリケーションは、AI/MLを使用して自動化できるビデオモニタリングタスクのサブセットのごく一部です。AWS Step Functionsに基づくモジュラー処理フレームワークを使用すると、AWSのAIサービスによって提供されるビルディングブロックを使用して追加のモニタリングタスクを行うことで、アプリケーションを簡単に拡張できます。例えば次のような拡張が可能になります。

Amazon Transcribeを使用して、音声言語とクローズドキャプションの正確性を検証します。
Amazon Recognition Custom Labelsを使用してカスタム画像分類モデルをトレーニングすることにより、番組のジャンル（ニュース、トーク番組、クイズ番組、アニメなどを区別）を特定します。
Amazon Comprehend Custom Classificationを使用して、クローズドキャプションデータにテキスト分類を適用します。
Amazon Rekognitionを使用した画像ベースのMLモデル（テキスト検出、顔認識、画像分類など）と、Amazon Comprehendを使用したテキストベースモデル（名前付きエンティティ抽出とテキスト分類など）の組み合わせを適用することにより、各ジャンル内の特定の番組（あるクイズ番組の放送内容を、”Jeopardy”として識別するなど）を認識します。
Amazon SageMakerでカスタムモデル（この論文で説明するVIDMAPモデルなど）をトレーニングすることにより、画質低下を検出します。

参考リンク

AWS Media Services
AWS Media & Entertainment Blog　(日本語)
AWS Media & Entertainment Blog　(英語)

AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp
※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。

翻訳は BD山口とSA安司が担当しました。原文はこちらをご覧ください。

Amazon Web Services ブログ