ストリーミング・サーバーにおける音質劣化
「Apple Music」のデフォルト配信フォーマットはAAC 256kbpsとなっています。近年の動画ライブ•ストリーミング配信においても、音声はAAC 256kbpsが標準的ですが、同じビットレートとは思えないほど音質が悪く感じられます。その理由として、前回まで取り扱ってきたような事情（ビデオ•デバイスの貧弱なオーディオ入力設計、クロックの取り回し）もありますが、ストリーミング•サーバーにおける音質劣化も決して見逃してはならない大きな要因です。
ライブ動画配信におけるストリーミング・サーバーの役割
一般的なライブ動画配信においては、ライブ•エンコーダーから配信サーバーへのアップロード•プロトコルとして「RTMP (Real-Time Messaging Protocol)」が使われています。これは元々Macromedia社（後にAdobeに買収）が、FLASHプレイヤーに対して動画配信するために開発したプロトコルですが、現在でも配信サーバーへのアップロード用途として広く使われています。
ただし、FLASH亡き今、RTMPのままではクライアント側で再生ができないので、ストリーミング•サーバーがこれを「HLS (HTTP Live Streaming)」や「MPEG-DASH (Dynamic Adaptive Streaming over HTTP)」といったウェブ•ブラウザで再生できる形式にリアルタイム変換して、クライアントに配信しています。
ストリーミング•サーバー内でのデータ“再圧縮”
RTMPは何種類もの動画•音声コーデックに対応していますが、最近ではH.264動画 + AAC音声でアップロードするのが一般的です。また、ストリーミング•サーバーの出力（クライアントへの配信形式）も、通常は H.264動画 + AAC音声なので、ここでの品質劣化は無さそうに思えます。…が、実は全く違います！入出力コーデックが同一であっても、ストリーミング•サーバー内で動画や音声データに確実に“再圧縮"が掛かってしまい、これが画質や音質の劣化の最大の原因となっています。
それでは、なぜわざわざ品質を劣化させてまで再圧縮を掛けるのでしょうか？いくつか理由は考えられますが、その1つは「Adaptive Bitrate」への対応です。
Adaptive Bitrateとは
Adaptive Bitrateとは、コンテンツの情報量(圧縮率)を再生クライアント側の通信状態に応じてリアルタイムに変更させる技術で、低速回線でも（画質や音質は落ちるものの）再生が止まってしまう可能性を抑えることができます。
具体的な処理の流れは、
1) エンコーダーからアップロードされたデータをマスターとして、ストリーミング•サーバー内で低ビットレートから高ビットレートまで、2〜5種類ほどの“再圧縮”データが生成される
2) 再生クライアントは、現在の通信状態に応じて、ストリーミング•サーバー内から適切なビットレートのデータを選んでダウンロード再生する
となります。
ここで、通信状態が良ければ、ライブ•エンコーダーが出力した鮮度の高いデータが再生に使われて欲しいものですが、YouTubeやVimeoのようなストリーミング•サービス、あるいは各種サービスの裏で回っている「AWS Elemental MediaLive」のようなストリーミング•サーバーは、自ら生成した“再圧縮”データしか伝送しない仕様になっているようなのです。
YouTubeにおけるライブ•ストリーミング
この現象を確認するために、YouTubeを使った簡単な実験を行ってみました。
上記ページによると、YouTubeで推奨されているライブ•エンコーダーの音声設定は以下の通りです。
オーディオ コーデック: AAC または MP3
ビットレート エンコード: CBR
音声サンプルレート: 44.1 KHz
音声ビットレート: 128 Kbps ステレオ
この推奨設定の音声 (AAC-LC 128kbps) にH.264 (1080p30) 映像をつけてYouTubeでライブ配信したところ、以下の6種類のデータが生成されました。
・H.264 (144p15) + HE-AAC (44.1kHz, 2ch, 48kbps)
・H.264 (240p30) + HE-AAC (44.1kHz, 2ch, 48kbps)
・H.264 (360p30)+ AAC-LC (44.1kHz, 2ch, 128kbps)
・H.264 (480p30)+ AAC-LC (44.1kHz, 2ch, 128kbps)
・H.264 (720p30)+ AAC-LC (44.1kHz, 2ch, 128kbps)
・H.264 (1080p30)+ AAC-LC (44.1kHz, 2ch, 128kbps)
映像としては6段階のAdaptive Bitrateですが、音声はHE-AACとAAC-LCの2段階しかないことが分かります。
音声入力には440Hzの矩形波を用いたのですが、この入力信号（非圧縮）とエンコーダー出力（AAC-LC 128kbps)、ストリーミング•サーバー出力 (AAC-LC 128kbps および HE-AAC 48kbps) の波形とスペクトルを比較したのが以下の図です。
まずライブ•エンコーダーでの圧縮によって、16kHz以上のスペクトルに変化があることが分かりますが、ストリーミング•サーバー内での“再圧縮”によって更に情報が欠落していることも分かります。低速回線用のHE-AACは、サンプリング周波数をオリジナルの半分にダウンコンバートし、失われた高域データを疑似的に再現するアルゴリズムで、この影響で8kHzから上の帯域でスペクトルが大きく乱れている様子が観察できます。
ここでは音声についてのみ取り上げましたが、映像についてもライブ•エンコーダーから出力された画質に比べ、ストリーミング•サーバーの出力は“再圧縮”によって劣化することがわかっています。
YouTubeのライブ•エンコーダー設定推奨値はAAC 128kbpsとなっていますが、再圧縮が回避できない以上、YouTube Liveが対応している最大値 (AAC 160kbps) でエンコードしてアップロードした方が、音質的には有利そうです。
Vimeoにおけるライブ•ストリーミング
Vimeoのストリーミング•サーバーの処理も基本的にはYouTubeと同様で、H.264 (1080p30) 映像 + AAC-LC音声(48kHz, 2ch, 320kbps) 入力時に5種類のデータが生成されました。
・H.264 (240p30) + HE-AAC (48kHz, 2ch, 56kbps)
・H.264 (360p30) + AAC-LC (48kHz, 2ch, 132kbps)
・H.264 (540p30) + AAC-LC (48kHz, 2ch, 256kbps)
・H.264 (720p30) + AAC-LC (48kHz, 2ch, 256kbps)
・H.264 (1080p30) + AAC-LC (48kHz, 2ch, 256kbps)
全体的にYouTubeよりは高音質と言えそうですが、音質の上限はAAC-LC 256kbps。ここで、ライブ•エンコーダー出力をAAC-LC 256kbpsにしても、やはり“再圧縮”による音質劣化を回避することはできませんでした。
Live Extremeでデータ劣化が発生しない理由
Live Extremeでは、ライブ•エンコーダー内でHLSやMPEG-DASH形式に直接エンコードして、配信サーバーにアップロードします。
既にクライアント側で再生できる状態になっていますので、配信サーバーに求められている役割はアップロードされたデータをパススルー配信するだけであり、変換機能をもった特殊なストリーミング•サーバーは不要です。これはプラットフォームにおけるLive Extreme導入のハードルを下げるだけでなく、画質や音質がサーバー内で劣化する可能性をゼロにする効果もあります。
まとめ
4回にわたって、Live Extremeの高音質化技術について説明してきましたが、ご理解いただけましたでしょうか？繰り返しになりますが、技術の肝は動画ライブ•エンコーダー設計の抜本的な見直し、即ち
1) ASIO対応オーディオ・インターフェイスへの対応
2) オーディオ・クロックを基準としたビデオとの同期
3) ロスレス・オーディオ・コーデックよる音声のエンコード
4) MPEG-DASH & HLS形式でのダイレクト・アップロード
の組み合わせであり、単なる音声のハイレゾ化技術ではないことをご理解いただけたら幸いです。
この記事が気に入ったらサポートをしてみませんか？