原文: "MPEG-DASH: Dynamic Adaptive Streaming Over HTTP Explained"(2021 年 2 月投稿分)
COVID-19 の流行により、オンラインビデオストリーミングの視聴時間はかつてないほど伸びています。Netflix や YouTube でコンテンツを楽しんでいる人がいる裏側では、MPEG-DASH プロトコルが重要な役割を果たしています。
では、MPEG-DASH とは何か、そしてそれはどのように機能するのか?この記事では、そのすべてを取り上げます。
MPEG-DASHとは?
MPEG-DASH は、インターネット上でメディアをストリーミングするためのアダプティブな HTTP ベースのプロトコルです。この技術は、ライブおよびオンデマンドのビデオコンテンツをウェブ サーバーから視聴者のデバイスに転送するために使用されます。
MPEG-DASH 規格の経緯については、以下の通りです。
まず、動画の標準化のための組織である MPEG(Moving Pictures Expert Group)がこの技術を開発しました。MPEG はデジタルオーディオとビデオの国際的な権威として、Apple の HTTP ライブ ストリーミング(HLS)プロトコルに代わる、業界標準の代替技術を開発しようとしていました。そして、それを DASH(Dynamic Adaptive Streaming over HTTP の略)と名付けました。
では、なぜ MPEG-DASH が必要だったのか、そして HLS と DASH はどのように比較されているのでしょうか?さあ、長い旅へ出発しましょう。
MPEG-DASH 概要
- オーディオコーデック: コーデック依存なし
- ビデオコーデック: コーデック依存なし
- 再生の互換性: 良いが優れてはいない
- HTML5 ビデオ プレーヤーは、すべての Android デバイス、2012 年以降の Samsung、Philips、Panasonic、Sony TV、Chrome、Safari、Firefox などほとんどのブラウザでの再生が可能
- iOS と Apple TV は DASH に非対応
- メリット: ベンダーに依存しない、アダプティブ・ビットレートの国際規格
- デメリット: iOS や Apple TV に非対応
- 遅延: 6-30 秒(チャンク転送エンコーディングでチューニングまたは配信された場合にのみ、より低遅延が可能)
- 関連フォーマット: MPEG-DASH CENC(汎用の暗号化)
MPEG-DASH の仕組み:
アダプティブ・ビットレート・ストリーミング
視聴している番組がぼやけた映像から数秒経つとシャープな映像に調整されている、という経験があるでしょうか。もしそうなら、あなたはアダプティブ・ビットレート・ストリーミング(ABR ストリーミング)のことをすでに知っているということになります。ストリーミングメディアを配信するこの方法は、高品質のビデオエンコードと低品質のビデオエンコードを切り替えることで、コンテンツを視聴者の状況に合わせて動的に適応させることができます。Netflix、Hulu、YouTube などはすべて MPEG-DASH フォーマットによって、ABR ストリーミングを実現しています。
多くの場合、ABR ストリーミングはメディアサーバーを使用して単一のビデオソースを取り込み、それを数種類の異なるレンディション(解像度とビットレートのセット)へトランスコードします。複数のレンディションは、様々なデバイスや接続速度でバッファを伴わない再生を可能にするために、解像度がそれぞれ異なります。これによって、高ビットレート、高フレームレート、高解像度のストリームを、高度な設定で視聴することができますし、また、画面が小さく、高度な設定に対応できないサービスの利用者のために、同じ動画を低品質で提供できます。
レンディションは、連続したストリームとしてではなく、10 秒未満のセグメントで配信されます。これにより、視聴者のインターネット速度が向上や低下に合わせて、解像度とビットレートのセットを自動的に調整することができます。
ABR ストリーミングにおいて、DASH の仕様は安定した視聴体験を提供しますが、個々のセグメントがダウンロードされる際に遅延が発生します。これを解決する方法の一つとして、セグメントサイズを小さくして遅延を調整する方法が挙げられます。もう一つの方法は、 Common Media Application Format(CMAF) です。
MPEG-DASH の歴史
ストリーミング プロトコルの最前線では、ストリーミングメディアの黎明期から競い合ってきた技術があります。Adobe の RTMP(Real-Time Messaging Protocol)、Apple の HLS(HTTP Live Streaming)、MPEG-DASH プロトコルなどです。
当初は、RTMP の存在があった
世紀の変わり目から説明します。ダイヤルアップのインターネット接続がまだ存在していた頃、クールな子供たちはノキアの携帯電話でスネークをプレイしていました。ストリーミングビデオはまだ黎明期であって、Netflix はまだ DVD を物理的に配送することに注力していました。
当時は RTMP が最高の地位を占めていました。当時専有していたプロトコルは Adobe Flash Player で再生するためにあって、インターネットを介してビデオとオーディオデータを迅速に転送していました。Flash プラグインは、当時のインターネットブラウザの 98% で利用され、2010 年代初頭まではライブストリーミングの配信方法として RTMP が主流でした。
Adobe の技術を使ってエンドユーザーに連続的なストリームデータを送信することによって、RTMP はユーザーの期待に応えていました。今日の最も一般的な配信プロトコルとは異なり、専用のストリーミングサーバーと Flash プレイヤーを必要としました。
ご存知のように、Flash は過去のものとなりました。スティーブ・ジョブズが、プレイヤーの絶滅に重要な役割を果たしたためです。iPhone を世界に紹介した直後に、彼はその独自の性質を理由に、Apple が Flash をサポートしないという選択を擁護しました。
HTTP ベースのアダプティブ・ビットレート・ストリーミングの登場
RTMP はすぐに HTML5 ベースの技術に取って代わられました。この新しいカテゴリーのストリーミングプロトコルは、普通の HTTP ウェブサーバーで構成されたコンテンツ配信ネットワーク(CDN)を利用して、チャンクベースのアダプティブ・ビットレート・メディアファイルを配信します。
アダプティブ・ストリーミングへの移行により、バッファリング対策とキャッシングの効率化が一挙に実現しました。RTMP の穴を埋めるために、新しい独自のプロトコルが次々と開発されました。2008 年にはマイクロソフトが Smooth Streaming を、2009 年には Apple が HLS を、そして 2010 年には Adobe が HTTP Dynamic Streaming(HDS)を発表しました。
MPEG-DASH 登場のきっかけ
では、どのようにして MPEG-DASH が登場したのでしょうか? Alex Zambelli 氏はガーディアン紙の取材に対して次のように述べています。
「独自のストリーミング技術が互いに再び衝突することは、成長しつつある業界にとってプラスになるどころか、マイナスになることは早くから明らかだったため、2009 年に 3GPP でアダプティブ・ストリーミングの業界標準を確立するための取り組みが始まりました。3GPP での初期の標準化作業は、2010 年に ISO/IEC の MPEG ワーキンググループに移行し、提案からドラフト状態、そして批准へと2年足らずの間に急速に進みました。Microsoft、Netflix、Apple など 50 社以上の企業が参加し、3GPP、DECE、OIPF、W3C などの他の業界団体とも連携して作業を進めました。2012 年 4 月には、Dynamic Adaptive Streaming over HTTP、通称 MPEG-DASH という新しい規格が誕生しました。」
別の言い方をすると、MPEG(Moving Pictures Expert Group)は、HLS やその他の独自技術に代わるものとして DASH を設計しました。
2020 年以降の MPEG-DASH ライブストリーミング
現在、HTTP ベースのプロトコルとしては、MPEG-DASH と HLS の 2 つが主流です。しかし、採用されている数に関しては、明らかな勝者がいます(ヒント:Apple が推奨している方です)。Streaming Latency Report への回答を見てみましょう。
どのストリーミングフォーマットを現在利用していますか?
さて、どうでしょうか…。独自仕様ではないプロトコルが頂点に登りつめることはできるでしょうか?私たちの希望は「イエス」です。しかし、それは時間が経ってみないとわかりません。
HLS vs DASH ストリーミング
HLS も DASH も技術的な観点からは同様の機能を持っています。2 つの技術の主な違いは、所有権に由来しています。HLS が Apple によって規定されているのに対し、DASH ではオープンソースのオプションが用意されています。
HLS は Apple が支持している技術であるため、Apple 製品全体でサポートが充実しています。なぜでしょうか?それは簡単です。Apple はオープンソースの代替手段よりも、独自の規格を優先しているからです。スティーブ・ジョブズが RTMP を批判したのは、HLS をリードしているためです。
つまり、HLS で配信されるストリーミング コンテンツは、Safari でネイティブに再生できますが、DASH を使ってストリーミングされるコンテンツを見るには HTML5 ビデオプレイヤーが必要になります。使用するプレイヤーは DASH クライアントであることが必須です。
同様に、Apple TV と iPhone は HLS ストリームしか受け付けません。これを回避するには、独自のアプリを作成するしかありません。
HLS と DASH の相違点は、エンコード形式と低遅延配信方法にありますが、以下のリストにまとめました。
HLSとMPEG-DASHの比較
- 独自性 vs 汎用性: HLS は Apple 独自のものであるのに対し、DASH は MPEG によって定義されたオープンな規格です。
- 再生の互換性: DASH よりも HLS の方が広くサポートされているのは、Apple が業界全体に与える影響力が大きいためです。
- コーデックの要件: HLS が特定のビデオコーデック(H.265、H.264)とオーディオコーデックの使用を規定しているのに対し、DASH はコーデックに依存しません。これにより、より高度なコーデックを利用した場合、より高品質な放送を低ビットレートで実現することができます。
- コンテナフォーマット: HLS は従来からの MPEG-2 トランスポートストリームのコンテナフォーマットである .ts(MPEG-TS)を使用していますが、DASH は MP4 フォーマットである .mp4 を使用していました。
- 遅延: どちらのプロトコルも以前から配信速度の面で遅れをとってきましたが、新しいアプローチによりこれを変えようとしています。DASH の場合、Common Media Application Format(CMAF)の形をとっていますが、Apple は現在 Low-Latency HLS という拡張機能を提供しています。
DASH のための低遅延 CMAF
CMAF は Common Media Application Format の略で、一言で言えば、HLS と DASH の両方のプロトコルに同じコンテナフォーマットである fragmented MPG(fMP4)を指定することで、HLS と DASH の相互互換性を高めるメディアフォーマットです。
遅延の短縮を目的とした大規模なシステムにこの仕様を組み込むことで、アカマイのような大手 CDN 企業も DASH で配信されるビデオの固有の遅延に取り組んでいます。
チャンクされたエンコードとチャンクされた転送エンコードを使用することで、低遅延の CMAF は、ストリームを一定の時間の小さなチャンクに分割し、エンコード時にすぐに公開することができます。ベンダー各社は、この新しい技術への対応を進めていますが、低遅延 HLS の登場によって採用が遅れています。
低遅延 CMAF の詳細については、こちらのブログをご覧ください。
"Low-Latency CMAF for Live Streaming at Scale"(英文)
DASH の相互運用性
DASH プロトコルは本質的に柔軟性がありますが、課題もあります。特に選択肢が多い状況で、放送局が最適な構成を決定するのは困難です。
DASH-IF はこの問題を認識し、採用する指針として DASH-AVC/264 実装ガイドラインを作成しました。彼らの言葉を借りれば
「DASH が標準化された後に直面した主な課題のひとつは、コア仕様で許可されている多くの機能とオプションによって表現されるDASH 自身の柔軟性でした。例えば、コーデックに依存しないということは、新しいコーデックオプションをサポートする際にはプラスになりますが、エンコーダやプレイヤーを作る際には課題となります。
DASH プレイヤーはどのコーデックをサポートしているか?
エンコーダはどのセグメントカプセル化を生成すべきか?
DRM はどのようにシグナリングすべきか?
どのようなクローズドキャプションフォーマットをサポートするのか?この規格は柔軟性があるため、初期の様々な実装の間で相互運用性を実現するのは難しくなっています。
完全な相互運用性が MPEG-DASH の迅速な市場導入の鍵であることを認識した上で、DASH-IF は生の DASH 標準をコーデックと結合し、厳しいプロファイルやその他の制限を適用して、誰もが苦労せずに相互運用可能な製品やサービスを構築できるベースライン勧告を作成することにしました。相互運用性は採用の鍵であり、あるフォーマットが「どこでも使える」ようになれば、その成長は加速します。この勧告の名前は「DASH-AVC/264 Implementation Guidelines」で、https://dashif.org からダウンロードすることができます。」
DASH 業界フォーラム(DASH-IF)より抜粋
プレイヤー
ブラウザで MPEG-DASH の再生をサポートしている、埋め込みが可能な HTML5 ビデオプレイヤーがいくつかあります。DASH-IF は、無料のオープンソースプレイヤーとして dash.js を発表していますが、他にも以下のような選択肢があります。
- THEOPlayer
- Video.js
- Flowplayer
- Clappr
- JWplayer
- Bitmovin
- VLC Media Player
サーバー
ほとんどのコンテンツ配信はオンラインビデオ用に RTMP か WebRTC、または SRT へエンコードして、ビデオストリーミング サーバーに到達すると、DASH によるアダプティブ・ビットレート配信用にビデオをトランスコードします。Wowza Streaming Engine メディアサーバーソフトウェアは、DVR での DASH 再生をサポートし、アカマイへの DASH Stream Target パブリッシングを提供します。
また最近、Wowza Streaming Cloud に DASH のサポートを追加しました。この強化の一環として、複数のプラットフォームでのデジタル著作権管理(DRM)が可能になり、お客様は不正な視聴からコンテンツをより効果的に保護できるようになりました。
とはいえ、幅広いデバイスの視聴者がコンテンツを視聴できるように、追加のフォーマット(HLS など)でビデオを配信するのは賢明です。繰り返しになりますが、Wowza Streaming Engine や Wowza Streaming Cloud のようなトランスコードソリューションは、可能な限り幅広い視聴者に届くようにストリームを複数のフォーマットへ再パッケージ化するための最善の方法です。
コンテンツデリバリーネットワーク(CDN)
DASH は、一度パッケージ化されると、従来のネットワーク サーバーやテクノロジーを使って転送できるため、コスト効率に優れています。そのため、CDN を使って簡単に拡張することができます。
DASH をサポートしているライブ ストリーミング用 CDN には次のようなものがあります。
- AKAMAI
- Fastly
- Microsoft Azure
- Amazon CloudFront
- Limelight Networks
- Wowza CDN
DASH の導入と次の展開
ベンダー独自のテクノロジーとオープンスタンダードとの間の権力争いは、ストリーミング業界では新しいことではありません。しかし、RTMP や HLS のような独自路線なプロトコルが依然として主流である一方で、DASH のようなオープンソースの代替プロトコルが将来の主流になるかもしれません。
その理由は?MPEG-DASH は、そのオープンな性質によって明確なメリットをもたらします。ひとつは、この業界で最高の人材が率いるコミュニティ主導の努力によって開発されていることです。この協力的な精神は、ストリーミング分野を悩ませてきた断片化に対処し、相互運用性の向上と複雑さの排除への取り組みを促進します。
DASH-IF は次のように説明しています:
「DASH はそれ自体、メディア、デバイス、市場の断片化という問題を解決する魔法の万能薬ではありません。しかし、コンバージェンスの長期的なメリットが、目標を達成するための短期的な努力に伴うコストを上回るというビジョンを DASH-IF のメンバーは共有しています。DASH を中心としたコンバージェンスによって、自分たちのビジネスやインターネットストリーミング市場全体が大きな利益を得ることができると信じ、推奨事項の作成やバグの報告、Plug Fests や Interop などのイベントへの参加といった作業を積極的に行っています」。
このように、HLS は依然として中心的な存在であり、DASH の普及を遅らせています。HLS と DASH の論争では、Apple デバイスへのストリーミングには HLS が最も適していると言えます。幸いなことに、Wowza Streaming Engine を使えば、ビデオを様々なフォーマットに多重化して、どんなデバイスにも確実に配信することができます。