AWS Elemental MediaLiveで音量正規化をやってみた！

はじめに

清水です。ブロードキャストグレードのライブ動画処理サービスであるAWS Elemental MediaLiveの機能の一つ、音量正規化（Audio Normalization）をやってみました。

MediaLiveの音量正規化は追加料金が発生するアドオン機能です。私の記憶が定かであれば、2017年11月のAWS Elemental MediaLiveリリース時から実装されていた機能かと思います。

引用元: 料金 - AWS Elemental MediaLive | AWS

MediaLiveの料金ページなどではよく目にしつつも実際に使ったことはなかったのですが、先日MediaConvertの音量正規化機能を使ってみたことから、MediaLiveでも同様の機能を試してみることにしました。

MediaLiveで音量の正規化をしてみた

検証方法について

実際にMediaLiveで音量正規化をやってみます。今回の検証にあたり、MediaLiveの入出力は次のようにしました。ライブ動画配信っぽさはあまりありませんが、検証のしやすさを優先しています。

まず入力についてですが、以下の動画をMP4 Input typeとして使用しました。井の頭線の電車をスマホで撮影したものですね。（以前、ブログエントリ「AWS Elemental MediaConvertでVideo overlays（ビデオソースの置き換え）ができるようになっていました！ | DevelopersIO」で使用したもので、またMediaConvertの音量正規化を検証した際にも使用したものです。）

https://www.youtube.com/watch?v=pW_vFfOY8XY

もとのファイルはMOV形式ですが、MediaLiveの入力として使用できるようMP4形式に変換します。（今回、変換はDaVinci Resolveで行いました。）MP4に変換した動画ファイルをAmazon S3にアップロードし、MediaLiveのMP4 Input typeを作成、ChannelのInput attachmentsとして指定します。

なお、この入力動画の長さ（尺）は37秒と少し（数フレーム）です。MediaLiveのInput settingsでファイルをループするような処理はしていません。（Source End BehaviorをLOOPにすればファイルがループしますが、今回はCONTINUEのままです。）ChannelにほかのInputもattachせず、このChannelは開始から37秒と少しの間、この入力動画をライブ処理、その後は真っ黒な映像となります。

出力についてはArchive output groupを使用します。Archive settingsのAdditional settings、Rollover intervalで37を指定して、出力されるアーカイブM2TSファイルを37秒ごとに分割します。

アーカイブの1つの目のファイルと入力ファイルを比較して、音量の変化を確認します。アーカイブファイルは37秒ごとに区切られているので、入力ファイルとほぼ同じ尺になり比較がしやすい、というわけですね。

なお、音量の確認にはMediaConvertの音量正規化のブログエントリと同様、DaVinci Resolveを使って音量波形として視覚的に確認してみました。

MediaLiveのAudio Normalization設定

検証方法について確認できたところで、続いてはMediaLiveのAudio Normalizationの設定を行います。Output groupsのStream settingsの項目、Audioの箇所を確認すると、 Audio Normalization Settings がありますね。

ドロップダウンメニューからAudio normalizationを選択すると、詳細な設定項目が表れます。ラウドネスまわりを知っていないと少し見慣れない用語が並びますが、MediaConvertでの音量正規化やMediaLiveのAPI Referenceなどを参考に設定します。

今回はAlgorithmをITU_1770_1としました。Algorithm ControlはCORRECT _AUDIOとなっていることを確認します。そしてTarget LKFSでラウドネスの基準値、正規化後の音量の大きさを指定します。今回はまず、-24をTarget LKFSとして設定しました。

音量正規化したライブ動画処理と正規化された音量の確認

音量正規化の設定をしたChannelを作成しStartさせます。ChannelがRunningとなったらマネジメントコンソール上で入力映像のサムネイル画像を確認、映像が終わり真っ黒になったらChannelはStopしてしまいます。

Archive group destinationで指定したS3バケットを参照して出力されたアーカイブファイルを確認、ダウンロードして音量を確認します。

以下がDaVinci Resolveに読み込ませ、確認した音量の波形です。左側（タイムラインの前半）をMediaLiveのInputとして使用したもとの（音量正規化前の）動画ファイル、右側（タイムラインの後半）をMediaLiveで音量正規化したアーカイブファイルとして並べています。

音量を正規化した結果、波形が全体的に小さくなっていることが確認できますね。実際の音量としても全体的に小さくなっています。

Target LKFSを変えて正規化後の音量が変わることを確認してみた

MediaLiveで音量を正規化することで、出力音量が変化することが確認できました。続いてはAudio Normalization Settings の項目の1つ、 Target LKFS を変えて正規化後の音量の変化を確認します。

MediaConvertで音量正規化を検証した際に確認しましたが、日本ではラウドネスの基準値として-24 LUFS（LKFS）が多く使われます。このほか、例えばYouTubeなどでは-13 LUFSなど-24よりも大きめな値が使われることが多いです。値が大きくなることで、実際の音量としても少し大きくなります。

今回もMediaConvertのときと同様に、Target LKFSを先ほど確認した-24から-13にしてその変化を確認してみたいと思います。

検証手順は先ほどのTarget LKFS -24のときと同様です。MediaLiveのChannelをおおよそ37秒ちょっと稼働させたあと、アーカイブファイルをダウンロードして確認します。

DaVinci Resolveで視覚化した音量の波形は以下のようになりました。タイムラインの先頭（一番左）から順に、入力に使用した音量正規化されていない動画、Target LKFS -24で音量正規化したアーカイブ動画、Target LKFS -13で音量正規化したアーカイブ動画となります。

Target LKFS -13で音量正規化した場合、入力（音量正規化されていない状態）よりも全体的に音量が大きくなっていることがわかりますね。Target LKFSの値を変えることで、入力から音量を全体的に小さくするほか、大きくできることが確認できました。

参考: MediaConvertの音量正規化との比較

MediaLiveの音量正規化機能を使って、ライブ動画変換処理時に音量を全体的に小さくしたり大きくしたりできることを確認してきました。MediaConvertの音量正規化同様、上手に活用していきたい機能ですよね。ところで、MediaConvertの音量正規化の検証ブログのときと同じ動画素材を用いて、また同じTarget LKFS（-24と-13）を指定して確認を行ってきましたが、正規化後の音量の波形はMediaConvertとMediaLiveとで微妙に異なるものでした。

具体的に確認してみましょう。MediaConvertの音量正規化を検証したブログエントリ「AWS Elemental MediaConvertで音量正規化をやってみた！ | DevelopersIO」の「Target LKFSを変えて正規化された音量が変わることを確認してみる」の節の最後に載せた音量波形を再掲します。

引用元: AWS Elemental MediaConvertで音量正規化をやってみた！ | DevelopersIO

先ほどのMediaLiveの音量正規化の比較とタイムラインの順序は同じです。（音量正規化なし、Target LKFS -24、Target LKFS -13の順です。）

MediaConvertで音量正規化をした場合、その波形は音量正規化する前の波形全体を上下に拡大・縮小したようなかたちになりました。もともとの波形での大きさの異なりが音量正規化後も確認できます。具体的には、この映像では冒頭から12秒間ほど奥から手前（左から右）方向に電車が通っていきます。その後、24秒ぐらいのところから、手前から奥（右から左）方向に電車が通過します。この12秒から24秒の間は比較的音量が小さくなっているのですが、MediaConvertの音量正規化では、このタイミングが波形からもわかりやすい結果となりました。

対して、MediaLiveの音量正規化の波形を改め確認してみましょう。音量正規化する前の波形の大きさの異なりが、音量正規化後は失われてしまっているように感じます。具体的には、12秒から24秒の間、音量正規化をしていない状態では比較的音量が小さくなっている箇所が、音量正規化後は区別しにくくなっている、という状態です。コンテンツ全体として音量を上げ下げした、というよりも、細かい（例えば1秒など）時間範囲の中で、基準を満たすよう音量を都度上げ下げしている、という状況でしょうか。

今回、MediaLiveとMediaConvertの音量正規化で、Audio Normalizationのパラメータについてはなるべく同じになるように選択したつもりです。具体的には、MediaLiveではAlgorithmとしてITU_1770_1を使用しました。MediaConvertではAlgorithmとしてITU-R BS.1770-1を使用、文字列として完全一致はしていませんが、同じアルゴリズムを示している認識です。MediaConvertは、MediaLiveにはなかったLKFS gateやTrue peak（Peak calculation）の設定がありますが、これらはデフォルト値、もしくは設定なしとしました。もしかしたらこれらが影響してくるのでしょうか。

もしくはライブ動画処理とファイルベースでの動画変換処理の違いなのかな、などとも考えています。ライブ動画処理を行うMediaLiveの場合、次にどのような音量がくるか、ということはわかりませんよね。対して、MediaConvertでは処理方法などにもよりますが、全体もしくはMediaLiveよりも広い範囲でどのぐらいの音量となっているのかを事前に確認して音量を調整しているのかな、と想像しています。

いずれにせよ、MediaLiveとMediaConvertの音量正規化では少し違いがある、という点は把握しておきましょう。

まとめ

AWS Elemental MediaLiveで音量の正規化をやってみました。Target LKFSを変えることで入力映像の音量を全体的に小さくしたり、大きくしたりできることが確認できました。

個人的にはMediaConvertの音量正規化機能を検証したあとにMediaLiveの本機能を確認したので、設定内容などがわかりやすかったかな、という印象です。（MediaConvertの検証の際には、ラウドネスとはなんだろうということで、なかなか大変だったのですが。）

とはいえ、MediaConvertの音量正規化の結果と異なる音量（波形）になったことは少し驚きました。ライブ動画処理なのか、ファイルベースの処理なのかといった違いによるものなのかな、などと想像していますが、機会があればもう少し詳しく調査してみたいと思います。

ライブ動画配信を行う際、例えば映像制作現場やBroadcast Software側などで音量の調整ができればよいのですが、それが難しい場合などに活躍する機能かと思います。上手に活用していきましょう。