3.MPEG-DASH の技術概要(2021時点)
前回はインターネットトラフィックの現状と将来の予測を分析した。その中で、インターネットトラフィックはインターネット動画の視聴者数に応じて大きくそのトラフィック量が変化すると述べた。膨大なデータ量を擁する動画をインターネット上でどう配送するかは非常に重要な課題である。
最近ではAbemaTVでサッカーワールドカップが配信されたが、決してきれいな画質とは言えなかった。というのも、2000万人以上が同時視聴するようなリアル動画配信では膨大な量のトラフィックが発生するために、その上画質までよくすることは現在の技術的には難しいのである。むしろあれだけの視聴者を支えたAbemaのエンジニアチームは称賛を受けた。
ただ、今後5Gの本格導入などによって改善は見込まれるだろう。今回はそんなインターネット経由で動画をストリーミングするための技術の一つ「MPEG-DASH」について、その概要をまとめた。
3-1.初めに
昨今のインターネットにおいては、環境の進化・整備により映像配信をより気軽に行え
る環境が整っている。また、スマートフォンやビデオカメラなどの端末の普及により動画
撮影が手軽に行えたり、YouTube、Netflix などの動画配信サービスの利用者が増大したこ
とで、インターネット上で配信される動画の数は爆発的に伸びることとなった。
また、配信される動画の画質は年々向上し、最近では、4K や 8K といった超高画質のものも登場している。そのため、動画配信のトラヒック量は指数関数的に増加しており、世界のインターネットのトラヒックにおける動画のトラヒック数は過半数を占める状況となっている。このようなことを背景に、ストリーミングサービスにおいて、ネットワーク帯域に適応的に画質を切り替えるアダプティブビットレートストリーミングというプロトコルが開発された。アダプティブビットレートストリーミングは Apple の HLS、Microsoft の Smooth Streaming、Adobe の OSMF など、様々なプロトコルが開発されている。しかし、ベンダー毎に独自の開発がなされていたため、それらのプロトコル間には互換性がなかった。
そのため、動画配信のプロトコルの標準規格として MPEG-DASH が策定された。MPEGDASH は通信プロトコルに HTTP を使用するアダプティブビットレートストリーミングプロトコルの標準規格であり、動画共有サイトの YouTube ですべての動画がこの方式に対応するなど、現在急速に普及が進んでいる。ただし、標準化されたのが 2012 年であり、現在も広く研究が行われているが多くの問題が残っている[1]。以下では、MPEGDASH の技術の概要を述べた上で、技術的な課題を挙げ、その技術的な課題の中の一つの
課題についての自分なりの解決案を報告する。
3-2.MPEG-DASH の技術概要
動画におけるビットレートとは 1 秒間当たりの動画データ量を指す。単位は b/s(bit per
second で表され、動画が 1 秒間に何ビットのデータで構成されているかを示している。そ
して、アダプティブビットレートとは、そのビットレートを視聴者の通信環境に合わせて
自動的に変更する仕組みのことである。
アダプティブビットレートでは、あらかじめ配信サーバに複数のビットレートでエンコードされた同一内容の配信データ群を用意しておき、それらの情報をメタファイルに記述しておく。ストリーミングを開始する際に、クライアントがサーバからメタファイルを取得し、用意されているデータ群の詳細を把握・選択することで配信中にビットレートをより最適なものに変更することを可能にしている。
これらの仕組みを用いたストリーミングのものを総じてアダプティブビットレートストリーミングと言い、現在は、通信プロトコルに HTTP を用いた開発が主流となっている。そして、MPEG-DASH とは、アダプティブビットレートプロトコルの一つであり、各ベンチャーが開発したアダプティブビットレートプロトコルとの互換性を意図した国際標準規格である。
MPEG-DASH は主に動画音声ファイルのメタデータを記述した MPD ファイルと呼ばれるマニフェストファイルの使用を定める規格と、Segment Format と呼ばれる動画コンテンツの伝送に用いるファイルフォーマットの運用規格の 2 つの技術規格で構成される。MPD ファイルには配信サーバに用意されている動画コンテンツの構成情報が、階層構造で記述されている。階層構造は Media Presentation, Period, Adaptation Set, Representation, Segment Information の順に構成されており、それぞれに記述する情報が定められている。
MPEG-DASH の仕組みを図３-1 に示す。MPEG-DASH では、1 つの動画データに対して異なるビットレート、解像度でコーデックされたセグメント群が配信サーバに用意されており、動画の再生中におけるビットレートの変更が可能である。
図 3-1 の Media
Presentation on HTTP Server 内にある青いブロックが 1 つのコンテンツを表しており、
その中にある緑のブロックがそのコンテンツ内容の動画データを表している。動画データ
のエンコードのパラメータはブロックごとに異なり、1 つのコンテンツ内には、同一内容
の動画データが複数のパラメータでエンコードされて用意されている。
(一ヶ月の画像アップロード制限容量を超えてしまったため後で貼りなおしますm(_ _)m)
図 3-1 MPEG-DASH の仕組み
引用：https://library.naist.jp/mylimedio/dllimedio/showpdf2.cgi/DLPDFR013314_P1-67
そしてクライアント側は、サーバ側に用意された動画データが記述された MPD ファイ
ルを取得し、DASH Control Engine と呼ばれるアダプティブビットレート機能の制御ソフ
トウェアで解析する。
解析をする中で、自身のアダプティブビットレートアルゴリズムに従い、次に取得する動画データやセグメントを決定する。DASH Control Engine によって決定された次の動画データの情報は、HTTP Access Client と呼ばれるサーバとの送受信を制御するソフトウェアに渡され、サーバから HTTP を用いてダウンロードされる。
その際に、クライアントはサーバ側にある動画データをセグメント単位で要求できる。ダウンロードされた動画データは Media Engines に渡される。Media Engines はダウンロードされたセグメント同士をつなぎ合わせ、動画内容の整合性をとって再生する。そして、それらのダウンロードにより得られたネットワークスループットやバッファ状況が DASH Control Engine にフィードバックされ、再び次のセグメントが決定される。以上がMPEG-DASH の技術概要である。
3-3.MPEG-DASH の技術的課題
一つ目の課題として、遅延が挙げられる。MPEG-DASH におけるライブストリーミングは実時間より概ね、10~20 秒の遅延が発生する。これには様々な要因があり、エンコードにかかる時間やネットワークへのアップロード、そしてプレイヤーが再生初期にバッファするセグメントの数などが影響している。それに対し、ライブ視聴などのライブイベントはリアルタイムに近い形で再生させたいというニーズがあるため、これまで改善が試みられてきた。
二つ目の課題として、クライアント間で利用帯域の競合が起きることで、ビットレートの
振動、リバッファリングによる再生の一時停止、ネットワーク帯域の利用率の低下などが発
生するという課題がある。MPEG-DASH ではクライアント間でバッファ状況や選択してい
るビットレートの情報などを共有しない。そのため、高画質視聴に十分ではない回線でボト
ルネックを共有する状況下では利用帯域の競合を起こし、アダプティブビットレート機能
が十全に働かない問題が発生することが確認されている[2]。また、競合が発生する原因と
して、動画データを HTTP を用いてセグメント単位でダウンロードすることによる、「クラ
イアントの状態の移り変わり、そして複数のクライアントでそれらの状態が複雑に重なる
ことでお互いに使用できる帯域に影響を与え合い、帯域が激しく変化するため」とも分析さ
れている。そして、競合が発生した結果、上記に示した様々な問題が生じるのである。
3-4 技術的課題についての自分なりの解決案
3-3 ではいくつかの技術的課題を取り上げたが、私はその中で、「クライアント間で利用
帯域の競合が起きる」という課題に対する自分なりの解決案を上げたいと思う。
まず、一つ目として、私はこの課題を解決するために、競合が起きにくい環境を構築することを考えた。競合が起きにくい環境そのものを構築できれば、この課題は低減できると考えたからである。
その解決案とはクライアントごとに利用帯域を分割するという案である(図 3-2)。
図 3-2：クライアント間で利用帯域を分割している図
そもそも競合が起きる原因として、各クライアントが帯域を公平に分け合わず、互いの
利用帯域に影響し合う状況が生まれることが挙げられる。
そのような状況になることを防ぐために、ストリーミングを利用するクライアントごとに、利用可能な帯域を公平に分割する。そして、それを実現するために、クライアントに通信を送るルータは、ストリーミングを行うクライアントの数に応じて利用可能な帯域を設定する。クライアントが利用可能な帯域を超えるダウンロードを必要としている際に、遅延などを発生させることで、仮想的な利用帯域を設けるのである。つまり、「クライアント間で利用帯域の競合が起きる」という課題に対する自分なりの解決案の一つ目は、クライアントごとに利用可能な帯域を設定することで、競合が起きにくい環境を構築するという解決案である。
次に二つ目として、私はこの課題を解決するために、ビットレートの選択アルゴリズムを改善することを考えた。ビットレートの選択アルゴリズムを改善することで、ビットレート振動を抑制し、競合を回避できると考えたからである。その解決案とは、MPEGDASH のアダプティビットレートアルゴリズム内のビットレート選択アルゴリズムにおいて、「”バッファが潤沢な際には”、いきなり飛躍的な高ビットレート(高画質)を選択するのではく、徐々に高いビットレートを選択するアルゴリズムに改善する」という案である。
クライアント間で競合が起きる原因の一つとして、クライアントが適切にスループットを測定できず、ビットレート振動が生じ、他のクライアントが使用できる帯域をも急激に変化させてしまうということがある。ビットレートを大幅に変化させるアルゴリズムが実装されている場合には、クライアントが想定するスループットと実際の帯域との乖離が生じていた際に、ビットレートの振動が起きる原因になってしまう。そこで、クライアントが測定するスループットと実際の帯域との乖離が発生し、ビットレート振動が生じるのを防ぐためには、ビットレートを大幅に変化させるのではなく、少しずつ変化させるアルゴリズムを実装することが重要だと考えた。
少しずつビットレートを変化させる利点としては、クライアントが測定するスループットと実際の帯域との乖離が発生した際に、ビットレート振動が発生するほどの大きな影響を与えずに対応ができることだと考えている。
ただ、バッファが枯渇している際には、ビットレートを急激に低くすることで、バッファ枯渇を避けることも重要である。そのため、少しずつビットレートを変化させるアルゴリズムを適用する状況としては、バッファが潤沢の時にビットレートを高くする際が適切だと考えた。そうすることで各クライアントのビットレート振動をある程度抑制しつつ、いち早くビットレートが収束できると考える。
つまり、「クライアント間で利用帯域の競合が起きる」という課題に対する自分なりの解決案の二つ目は、MPEG-DASH のアダプティブビットレートアルゴリズム内のビットレート選択アルゴリズムにおいて、”バッファが潤沢な際には”、いきなり飛躍的な高ビットレートを選択するのではく、徐々に高いビットレートを選択するアルゴリズムに改善するという案である