ニュース
4K映像の低遅延配信に「CMAF」が有効、コーデックは「AV1」主流に? Akamaiが解説
2018年6月21日 19:52
アカマイ・テクノロジーズ(Akamai)は21日、インターネット動画配信に関する最新の動向や製品などを紹介/解説する技術者向けのイベント「Akamai Tech Conference 2018」を開催。その中から、4K映像などの低遅延配信に関連して行なわれた2つのセッションの模様をレポートする。
遅延の改善には「CMAF」に注目
「MPEG-DASH/CMAFアップデート」と題したセッションでは、“地上波テレビライブと同等の遅延と品質をインターネット経由で実現するために必要な新しい配信フォーマット”として「CMAF(Common Media Application Format)」を紹介するという内容の予告もあり、テレビ関係者も多く参加した。
ストリーミング配信には、RTMPやHLS/DASHなどそれぞれ特徴を持つプロトコルや技術がある中で、大規模配信におけるレイテンシー(遅延)に注目。カメラで撮影、エンコードしてからCDN(Content Delivery Network)を介してスマホやテレビなどの端末で表示するまでのエンドツーエンドの遅延を、どのように縮める方法が有効かという点や、現状の課題などについて、アカマイのテクニカル・ソリューション部ソリューションズ・エンジニア 松野憲彦氏が解説した。
品質を保ちながら遅延抑えるための一つの対策として、一定時間分のストリーミングデータをセグメント化(分割)する際に、その分割を細かくする方法がある。
松野氏が重要だとしたのは、「ストリーム開始時間(Stream start-up time/再生ボタンを押してから実際に動画が再生されるまでの時間)と、エンドツーエンドの遅延(E2E遅延)に相関関係はない」という点。「ストリーム開始に5秒かかったとしても、実際のライブからは2秒遅れの場合もあれば、ストリーム開始が2秒だとしてもライブからは5秒遅れの場合もある」とした。
さらに、「ライブ再生プレーヤーが、バッファ領域を構築できるチャンスは1度きりで、それは再生が開始される前のみ」という点や、「セグメント化されたメディア配信のライブ遅延はセグメント長(秒)の係数である」、「低遅延配信とは常に安定再生とトレードオフの関係にある」といった点も挙げた。
今回注目する「CMAF」は、例えば2秒のセグメントを200ms(ミリ秒)にするなど、最小単位となる「チャンク」に分割して配信するもの。プレーヤー側は複数のセグメントを受信してデコード/再生するが、小さなチャンクで分割すると、1つのセグメントを受信してからすぐデコード/再生するため、遅延が小さくなる。
CMAFは'15年にマイクロソフトとAppleが8つの企業と会議を行ない、メディア形式を提案したことを皮切りに、'16年のMPEGのミーティングで定義。アカマイやAdobe、Cisco、Comcast、Qualcomm、LG、Samsungなども策定に関わった。その後、'17年に8月に最終ドラフトになり、'18年1月には「ISO/IEC 23000-19 Common Media Application Format」として認定。仕様書はダウンロードできる(198スイスフラン)。
CMAFはメディア形式のみを定義しており、配信にはDASHやMMTといったMPEGの技術を使う必要はあるが、配信側の意向に合わせて、1つのCMAFセグメントを様々な配信プロトコルでどう扱うか決められる。HEVCやVP9、VP10などもサポートするなど、将来の拡張性の高さなどもポイントとして挙げている。
チャンク(Chunked Transfer Encording/CTE)自体は、20年以上前の1997年から定義された配信に関する技術で、Googleの検索結果などを早く表示する仕組みなどにも使われているという。
Appleは'16年6月の開発者会議WWDCにおいて、CMAFへの対応方針を発表しており、macOS High Sierraは'17年のアップデートでH.265再生もサポート。AppleのHLS(HTTP Live Streaming)とH.265で配信する場合はCMAFのコンテナを使う必要があるという。
アカマイがCMAFを使った低遅延配信の例としては、Harmonicのエンコーダを使って、CMAFで低遅延を実現した例を紹介。パリから2,000km離れたストックホルムまで、通常は6秒ほどの遅延になるところを、CMAFの採用で2～3秒の遅延に抑えたという。また、東京からサンフランシスコへの伝送時も、500ms程度まで低遅延を実現している。
現状のまとめとしては、ストリーミングデータのセグメント化を2秒にすると約10秒まで低遅延が実現でき、さらにセグメント長を1秒にすると遅延は4～10秒まで、さらにCMAFを使うと1～3秒まで短縮できるという。松野氏は「1～3秒の遅延で送れる未来はすぐそこまで来ている」と述べた。一方で、課題としてはCTEをサポートするエンコーダやプレーヤーがまだ少ないという点などを指摘した。
なお、低遅延を最優先する場合は、WebRTCを使う選択肢もあるが、今回のテーマである大規模配信では現実的ではなく、例えば再生側の回線速度に応じた再生を可能にするマルチビットレートでの配信ができず、高画質で配信してもプレーヤー側で品質を落とす形になる点などを指摘。松野氏は「遅延が無いのが正義というわけではなく、用途や目指すところによって選ぶことになる」とした。
高画質で低遅延配信するためのビットレートの基準とは
「4K/低遅延ライブ ベスト・プラクティス」のセッションでは、4Kなど高画質でデータ量の多い映像を低遅延で配信するための取り組みとして、「エンコード」や「QUIC」などをテーマに、カスタマー・ソリューション部エンゲージメント・マネージャの時光潤氏が解説した。
エンコーディングで留意すべき点として時光氏は、配信時に適したビットレートについて説明。アカマイでは「ベストプラクティス」として、縦横の解像度やフレームレートなどに応じたビットレートを算出する指標を持っており、一般的にも解像度に応じたビットレートとされるものも示されることはあるが、「全てのドラマ、アクション映画で、同じビットレートが適しているわけではない」と指摘。
例えばNetflixが行なった実験では、1080pの映像をビットレートのみ変えてエンコードしたところ、映像ソースによって画質向上に違いがあったという。
時光氏は、あるコンテンツの適したビットレートを決める方法として、まずは現実的な解像度のサイズをいくつか用意し、はっきりと違いが出るレベル(丁度価値差異)で定義、エンコードした映像のPSNR(ピーク信号対雑音比)を測定し、結果のプロットから評価値の最大値の曲線をとるという方法を紹介。ビットレートが増加してもPSNRが上昇しないエンコード結果を採用しないことで、適した値を探すという。ただし、タイトルごとにこの基準を変えるのは現実的に難しいため、カテゴリ単位で最適な基準を設定するという方法を提案。PSNR以外にも、Netflixが提唱するVMAFや、SSIMといった品質評価指標で計測することや、主観評価も重要になることなども加えた。なお、アカマイでは有償でコンサルティングも請け負うという。
AV1が次の映像コーデックの主流に?
遅延に関しては、放送やサービスなどで4K対応は増えているものの、日本のインターネットサービスプロバイダ(ISP)の、夜の“ゴールデンタイム”とされる時間帯の帯域はトップのサービスでも4Mbps程度で、HEVCで20Mbpsを超えることも多い4Kには足りないのが現状だという。
一方、4K映像で主流となっているHEVCは、H.264に比べて画質や圧縮効率の面で優位なものの、デコードやPPV、サブスクリプションなど様々な用途でロイヤリティが発生する点を指摘。
こうした中、時光氏はロイヤリティフリーのコーデック「AV1(AOMedia Video 1)」について「数年以内にデファクトスタンダードへ成長する」とし、HEVCのライセンス料金も調整されるのではと予測した。
AV1はAlliance for Open Media(AOMedia)が策定。AmazonやFacebook、Google、Intel、NVIDIA、Netflix、Microsoftらが参加。1月よりAppleも加わった。
AV1は、HEVCやVP9などよりも高い圧縮効率を実現し、開発者向けブラウザのFirefox NightlyやChrome Canaryでは既に採用されているが、3月予定としていたコードフリーズには6月時点でまだ至っておらず、当初の予定より遅延。現在はエンコードをソフトウェアで行なっているため多くの時間がかかり、時光氏は「ハードウェア対応は'19年後半にずれ込む恐れがある」としている。
現状として「4K配信はチャレンジは進んでいるものの、エンドユーザー側への普及はこれから。今のうちに4Kハイブリッドキャストにトライして4Kのバリューを高めていくべき。本格的に進める場合は高圧縮コーデックの利用検討を。2019年にはAV1をサポートするチップが登場することが予想される。それがモバイル/テレビ/各種プレーヤーにも導入されると、一気にユーザーは拡大する」とした。
エンコードした後の、伝送による遅延に関しては、前述したセグメントの分割や、CMAFの採用を紹介したほか、「QUIC」をどの段階で使用するかについて解説。
QUICは、TCPの問題を解決するという次世代プロトコルとしてGoogleにより開発。YouTubeやGoogle検索などで使われている。アカマイのPrincipal Archtectを務めるMike Bishop氏がドラフトを執筆中。
TCPの順次配送を起因とした輻輳時の性能低下の問題を解決するなど利点はある一方で、時光氏は「QUICだから単純に速くなるわけではなく、TCPを使うべきネットワークではTCPで優先通信するよう制御することもある。使うべきユーザーでQUICを動作させるチューニングを実施している」とした。アカマイのプラットフォームにおけるQUICのネイティブサポートは7月16日より徐々に開始するという。
