MediaLiveで意図的にメディアの品質を下げたときのMedia Quality Confidence Score (MQCS)を確認してみた

はじめに

清水です。AWSを使ったライブ動画配信でメディアの品質を考慮した障害対応が可能になるMedia Quality-Aware Resiliency (MQAR)機能がサポートされました。

• [NEW] AWSを使ったライブ動画配信でメディアの品質を考慮した障害対応ができるようになりました！ [Media Quality-Aware Resiliency] | DevelopersIO

AWS Elemental MediaLive、AWS Elemental MediaPackage、そしてAmazon CloudFrontの統合機能として提供されるこのMQAR、本エントリではMediaLiveにスポットを当ててみます。MQAR機能を使う際、MediaLiveでは入力された映像に対して(Media Quality Confidence Score (MQCS)という情報を生成します。MQCSはMediaPacakgeに伝達され、MediaPackageでのInput switchや、後続のCloudFrontでのオリジンの選択に使用されます。

本エントリでは、このMediaLiveで生成されるMQCSについて、意図的にメディアの品質を下げた際にどのような値になるのか、実際にやってみて確認してみました。

MediaLiveでMedia Quality Confidence Scoreを使用するためのリソース準備

まずはMediaLiveでMQCSを使用するためのリソースの準備からはじめます。MediaLive User Guideの「Working with MQCS」のページを確認すると、MediaLiveでのMQCSの利用には「出力先がMediaPackageであり、CMAF Ingest output groupを使用していること」という以下があることがわかります。この条件を満たせば、MQCS機能は自動で有効になるとのことですね。

MediaPacakgeではv2でCMAF Ingest input typeに対応しています。以下ブログエントリを参考に、MediaPackage v2リソースならびにMediaLiveリソースを作成していきます。

• MediaLiveとMediaPackageをCMAF Ingestで連携させてみた！ | DevelopersIO

MediaPacakge v2リソースの作成

MediaLiveリソース作成の前に、MediaPackage v2リソースを作成しておきます。MediaPackageのマネジメントコンソール、Live v2のページに進みます。Channel groupsについては作成済みのものを使用しました。Channel groupsの詳細ページから(Create channel)ボタンで進みます。NameとDescriptionを適切に設定し、Input typeではCMAFを選択します。MediaPackageのMQCS settingsについては本エントリでは扱いませんが、いったんデフォルトの有効としておきました。Channel policyはDont' attach a policyで進めます。

Channel作成後、(Create endpont)ボタンからEndpointについても作成しておきます。こちらは映像視聴確認用に使用します。Container typeはCMAFを選択、Endpont policyではPublic policyをアタッチ、HLS manifestのみを設定しました。

以上でMediaPackageリソース作成は完了です。MediaLiveの出力先となる、ChannelのIngest endpointをSettingsの項目で確認しておきましょう。今回はSingle pipelineで検証を行うため、Ingest endpoint 1のみを使用します。

MediaLiveリソースの作成

続いてMediaLiveリソースの作成です。InputについてはRTMP (push) input typeのものをSINGLE_INPUTで使用しました。詳細については参考ブログエントリのとおりですので省略します。

Channelの作成については、参考ブログエントリ執筆時に作成したChannelリソースをテンプレートしたものをベースに使用します。具体的には以下のテンプレートファイルとなります。

medialive-cmaf-ingest-channel-template.json

MediaLiveのマネジメントコンソール、Channels一覧画面の[Create channel]ボタンから進みます。Channel templateの項目で上記テンプレートファイルを読み込み、Channel nameやIAM Roleを設定します。またChannel classはSINGLE_PIPELINEを選択しました。Input attachmentsでは作成済みのRTMP (push)なInputを選択して[Confirm]します。

Output groupsの1. cmaf-ingest (CMAF Ingest)の文字列をクリックし、設定画面に進みます。「CMAF Ingest destination A」のURL欄に先ほど作成したMediaPackage v2 ChannelのIngest endpoint （Ingest endpoint 1）のURLを入力します。

[Create channel]ボタンを押下してChannelを作成しましょう。以上でMediaLiveのリソースについても準備ができました。

MediaLiveに入力する意図的に品質を下げた映像について

MQCSをMediaLiveで生成するためのリソースが準備できました。続いては、メディアの品質を下げるたときにこのMQCSがどうなるかを確認するため、本エントリで扱った、「意図的に品質を下げたメディア」について確認します。

MediaLiveで生成されるMQCSですが、User Guideの「Working with MQCS」に品質スコアを下げうる条件について記載があります。具体的には以下の5種類です。

• Black Frames: 入力ソースに黒いフレームが含まれる場合
• Freeze Frames: 入力ソースがフリーズしたフレームの場合
• Fill Frame Insertion: MediaLiveが入力の問題を検出し、入力損失処理に従ってフレームをエンコードしている場合
• Video Frame Drops: MediaLiveが1つ以上のフレームをエンコードせずにドロップしている場合
• SVQ : MediaLiveがリアルタイム操作を維持するために、ビデオエンコードの品質を意図的に下げている場合

本エントリでこの中で、Black FramesとFreeze Framesを扱います。具体的なこれら、意図的に品質を下げた状態の発生方法について以下にまとめます。前提として、今回の検証ではMediaLiveに映像を入力するStreaming SoftwareとしてOBS Studioを使用しました。

通常の（品質が下げられていない）映像ソースとしては、事前にスマホで撮影した映像を使用します。以下の映像を準備しました。（使用した動画ファイルをYouTubeにアップロードしたものです。）

https://youtu.be/v9qw1Ib3YR0

ソースで「メディアソース」を追加、ループ（繰り返し）を有効にしておきます。

Freeze Framesについてはこのメディアソースを一時停止することで実現します。

以下が停止している状態です。

またBlack Framesの実現には、このメディアソースの表示を行わないことで対応しました。ソース一覧のメディアソースの項目、目のマーク（👁️）をクリックします。

真っ黒の映像になりました。これをBlack Framesとします。

意図的にメディアの品質を下げたときのMQCSを確認してみた

MediaLiveならびにMediaPackageのリソース、そして意図的に品質を下げた映像の準備ができました。実際に、MediaLiveでメディアの品質を下げたときにMQCSがどう変わるか、確認していきましょう。

MediaLive ChannelをStartさせ、OBS Studioから映像を打ち上げます。MediaLive ChannelのPreview表示やMediaPackageのOrigin endpointのPreviewなどで、映像視聴に問題ないことを確認しておきましょう。

CloudWatchのマネジメントコンソール、MetricsのAll metricsのページに進み、MediaLiveのメトリクスを確認します。Channel ID（今回は40XXX41）とmqcsで検索すると、以下のように合計7つのメトリクスが確認できました。

今回はその中で、MinMqcs、MqcsFreezeFrameDetected、MqcsBlackFrameDetectedを確認します。Graphed metricsの項目で、いずれもPeriodは1 second、StatisticはMinimumを選択しました。

Freeze Frames発生時のMQCSを確認

まずは意図的にFreeze Framesを発生させてみます。時刻は18:39を確認したところで（0秒ぴったりではなかったのですが）、OBS Studio上でメディアソースの再生を一時停止、Freeze Framesを発生させてみました。該当時間のCloudWatchメトリクスを確認すると、すぐにMqcsFreezeFrameDetectedとMinMqcsの値が下がっていることがわかります。MqcsBlackFrameDetectedについては変わらず100のままです。

最終的にMqcsFreezeFrameDetectedとMinMqcsの値は25まで低下しました。

Black Frames発生時のMQCSを確認

続いては意図的にBlack Framesを発生させてみます。こちらも時刻は18:46を確認したところでOBS Studioのメディアソースを非表示にしてBlack Framesを発生させました。すぐにMqcsFreezeFrameDetectedとMqcsBlackFrameDetected、MinMqcsといずれの値も下降しはじめます。

最終的には、MqcsFreezeFrameDetectedとMqcsBlackFrameDetectedの値は25まで低下、そしてMinMqcsの値については6まで低下しました。

mqcsで検索できたほかのメトリクスも確認してみましたが、この間、MqcsFreezeFrameDetected、MqcsBlackFrameDetected、そしてMinMqcs以外の値は100のままでした。MqcsFreezeFrameDetectedとMqcsBlackFrameDetectedの値を乗算などしてMinMqcsの値を計算しているのかもしれません。

まとめ

Media Quality-Aware Resiliency機能向けのAWS Elemental MediaLiveのアップデート、MQCS (media quality confidence score)について、実際にFreeze FramesやBlack Framesを発生させた際にどのように変化するのかを確認してみました。実際にFreeze Framesを発生させた際、MQCS自体の値は最終的に25になりました。またBlack Framesを発生させた場合は、MQCSの値が最終的に6になりました。メディアの品質を考慮したリージョン間フェイルオーバー用途ではなく、諸事情により単一のパイプラインなどで動作させる場合などでも、これらMQCSのメトリクスは有用ではないでしょうか。