LiveInstantly, LLC.

Resources: ストリーミング業界の 2023 年のトレンド

Wed, 01 Feb 2023 00:00:00 +0900

この記事は、当社パートナーの Wowza Media Systems の記事 10 Streaming Trends for 2023 の翻訳記事です。

2023 年は最初のライブストリームがインターネット上に登場してから 30 年になります。最初に登場して以来、ビデオストリーミングは日常生活に欠かせないものとなりました。休暇中は YouTube や Netflix などの配信プラットフォームで動画を視聴することで利用されます。また、ビジネスでは Zoom などのビデオ会議テクノロジーを使用してストリーミングが利用されます。 IoT ストリーミングでは、自律型ロボットから赤ちゃんモニターまであらゆるものをストリーミングが支えています。

非常に多くのアプリケーションでビデオの利用が急増したのは、拡大し続けるネットワーク接続性と技術革新によるものと考えられます。この記事では、人工知能、新しい収益化の手法、没入型の拡張現実 (XR) 体験など、ストリーミングの世界で最もエキサイティングな開発の可能性についていくつかを探っていきたいと思います。

今年のリストは、私が以前に行った予測を確かに反映しています。その理由は単純です。デジタルの進歩は革新しつづけていて、新しい革新は常に以前の革新の上に構築されているからです。

2023年のストリーミングトレンドのリストです。それぞれ見ていきましょう。

2023 年のストリーミングトレンドトップ 10

動的コンテンツ作成のための人工知能 (AI)
無料の広告付き (FAST) テレビ
新しい OTT 収益化モデル
没入型ビデオ体験とメタバース
ストリーミング速度とフィードの進歩
コネクティビティの向上: ATSC 3.0 および 5G
オムニチャネルビデオマーケティング
市場の統合
ブロックチェーンと非代替トークン (NFT)
ストリーミングのグリーン化

1. 動的コンテンツ作成のための人工知能 (AI)

デジタルマーケティングからソフトウェア開発者まで様々なロールで、2023 年の人工知能 (AI) について深く考えていることでしょう。実際、ChatGPT はブログの作成からコード開発まで様々な用途で昨年末に大きな注目を集めました。

ChatGPT はオープンソースのデータセットを使ってトレーニングされた自然言語 AI チャットボットです。デジタルの Magic 8 Ball と考えてください。ただし、“はい”/“いいえ” で回答する質問だけに限ることなく、ほとんど何でも好きなことを質問することができます。

私の同僚の 1 人が、2023 年のストリーミングトレンドというタイトルで wowza.com で公開するためのブログを書くように依頼しました。結果は驚くほどのものではありませんでした (結局、このブログを書くのに行き詰まったようです)が、これには十分な理由があります。このツールは 2021 年に学習を停止したため、2 年先の将来のテクノロジーの展望についての予測には限界がありました。

とはいえ、それでも (別の質問で) 印象的な結果が得られました。以下は、私の同僚が AI に書くように依頼したコマーシャルのスクリプトです。

[以下、翻訳]

質問：

ソフトウェア開発者をターゲットとした Wowza についての短いコマーシャルスクリプトを書いて

OpenAIの回答:

[スクロールしている数行のコードコンピューターの画面を表示しています]

ナレーター:「ソフトウェア開発者として、ストリーミングプラットフォームの構築が困難な場合があることをご存じでしょう」

[デスクに座ってイライラしている開発者の画面を表示]

ナレーター:「でも、あらゆる段階であなたを助けてくれるパートナーがいたらどうでしょうか？」

[Wowza のストリーミングソフトウェアのデモが実施されている画面に変わり、スムーズで高品質なビデオストリーミングが表示されます]

ナレーター:「ソフトウェア開発者向けの主要なストリーミングプラットフォームである Wowza を紹介します。 Wowza を使用すると、最小限の作業でストリーミングプラットフォームを簡単に構築、展開、スケール拡張をすることができます。」

[開発者が表示された直前の画面は、コンピューターの前で満足で自信を持っているように見えます]

ナレーター:「当社の最先端のテクノロジと専門家のサポートチームは、複雑なストリーミング技術をナビゲートしてくれます。そのため、開発者はコードを書くという最も得意なことに集中することができるようになります。」

[画面には Wowza のロゴと Web サイトが表示されます]

ナレーター:「ストリーミングに足を引っ張られないでください。今すぐ Wowza と提携して、あなたがたのストリーミングプラットフォームを次のレベルへ進めてください」

[Wowza のロゴをクローズアップ]

ナレーター:「Wowza - ソフトウェア開発者向けのストリーミングプラットフォーム」

ChatGPT を開発した OpenAI は、テキストプロンプトからリアルな画像を作成する DALL-E 2 というアートツールも提供しています。 ChatGPTのスクリプトで説明されている「コードがスクロールするコンピューターの画面を見てイライラするソフトウェア開発者」の画像を提供するように依頼したところ、次のようになりました。

繰り返しになりますが、素晴らしい結果というわけではありません。しかし、特定の入力に基づいて文書や視覚的な資料を動的に作成する AI の能力を示す説得力のある証拠になりえます。

コンテンツマーケティングチームは、ライターやグラフィックデザイナーを OpenAI のツールで置き換えますか？いいえ、そのためのものではありません。しかし、AI を活用してプロジェクトを活性化し、コンテンツ作成をスケール化し、その場ですぐにパーソナライズされた広告を生成することができる機会があります。

ワイアード誌の初代編集長であるケビン・ケリーは次のように説明しています :

“これはチームによるスポーツです: つまり、人間のアーティストと機械のアーティストのデュエットです。そして、役に立つものを生み出すには、経験だけでなく、多くの時間と労力が必要となります。相手を驚かせるのに AI を使うことは非常に簡単です (多くの場合、それだけです)。しかし、相手が従うように AI に仕事をさせるのは非常に困難です。”

ストリーミングの世界では、AI 主導のコンテンツ作成がどこにでもあります。

ニュース: Defiance Media などのリニア放送会社は、AI で生成されたニュースコンテンツを作成しています
スポーツ: オンラインのスポーツメディアである Ran.de はバーチャルヒューマンを使用してサッカーの中継をホストしています
ハリウッド: AI によって生成された映画が間近に迫っています。
エンタープライズ: DeepBrain の AI Studios や D-ID の Speaking Portrait などのツールは、トレーニング、顧客へのパーソナライズされたメッセージ、製品マーケティング資料など、作成に頭を悩ませるようなビデオの作成を自動化します

AI コンテンツ作成のもう 1 つの可能性のあるアプリケーションは、テレビコマーシャルです。これは、次のストリーミングトレンドの項目につながります。

2. 無料の広告付き (FAST) テレビ

1941 年に米国で最初のテレビ広告が放映され、 1950 年代にはテレビが一般的な家庭用品になりました。半世紀以上にわたり、家族はリビングルームに集まり、スケジュールされたTV番組やコマーシャルをリニア放送で視聴してきました。

その後、2007 年に、Netflix は、サブスクリプション型のビデオ・オンデマンド (SVOD) のビジネスモデルで、視聴者への直接のネットワークストリーミングを開始し、業界は混乱しました。視聴者は、テレビ番組ガイドが提供する番組を特定の開始時間に視聴するのではなく、都合のよいときにコンテンツを視聴することができるようになりました。また、サブスクリプション型の配信形態により、コンテンツディストリビューターはコマーシャルを切り離すこともできるようになりました。

2023 年には、古いものがすべて新しくなり、無料の広告付き (FAST = Free Ad-Supported TV) テレビが復活します。インターネットストリーミングと従来のリニアブロードキャストのこの組み合わせにより、コードカッター(*) に無料でチャネルが追加配信することができます。これにより、視聴者は無料のコンテンツにアクセスでき、放送局はコマーシャルで番組コンテンツを収益化できます。 FAST 分野のトッププレーヤーには、Roku, Pluto TV, Peacock などがあります。 Roku は、今年、独自のコネクテッド TV を構築する計画も発表しています。

訳注 [コードカッター(*)]: NetFlix などのインターネットベースのサブスクリプションサービスを指します。 TVのケーブルのコードを切ってしまうという意味合いで、コードカッターと呼ばれています。

なぜこのような原点回帰が生まれるのでしょうか？

その理由の 1 つには、ストリーミングサービスに対する疲労にあります。非常に多くのプラットフォーム (ストリーミングサービス) が私たちの注目を集めようと競い合っているため、視聴者は 10 もの異なるサービスにお金を払わなければならない現状にうんざりしています。また、昔ながらの視聴者の意思決定に関する疲労もあります。長い 1 日の終わりに、無数のタイトルを表示し自分が見たい順番に並べ替えるよりも、リニアチャンネルをオンにする方が簡単な場合があります。

FAST の成長は否定できませんが、多くの業界の先駆者達は新たなフラストレーションの原因を発見しました。それは、コマーシャルコンテンツの欠如です。同じテレビコマーシャル広告が短時間に何度も再生されたり、“コマーシャルを視聴しています” という静止画の画面に遭遇したりすることは珍しくありません。

これは、私が取り上げた最初のトレンドであげた “動的コンテンツ作成のための AI” が、シンプルで動的なコマーシャルの作成を支援することで役割を果たすことができる 1 つの方法です。

3. 新しい OTT 収益化モデル

OTT ストリーミングプロバイダーの主要な収益化モデルをすべて詳しく説明しましょう。

サブスクリプションベースのビデオオンデマンド (SVOD)
- 定期的な料金でコンテンツへの無制限のアクセスを提供する VOD サービスは、SVOD と呼ばれます。このモデルでは、視聴者は、コマーシャルによる中断なく、番組の放送スケジュールに関係なく、高品質のコンテンツを視聴できます。人気のある SVOD プロバイダーは、Netflix と Disney Plus などです。
広告ベースのビデオオンデマンド (AVOD)
- AVOD は、コマーシャルやその他の広告手法を使用して収益を生み出します。このモデルでは、FAST とは異なり、視聴者はリニアチャンネルではなくオンデマンドコンテンツを視聴します。 AVOD はアジア太平洋地域全体で主流のモデルとなっており、現在は米国でも成長しています。
無料の広告付きテレビ (FAST)
- 前述のように、FAST は従来のテレビ放送に非常に似ています。このモデルでは、広告とスケジュールされた番組を組み合わせて、無料コンテンツをストリーミング配信します。
トランザクションビデオオンデマンド (TVOD)
- TVOD は、視聴者が都度購入する PPV (ペイパービュー) のオンデマンドコンテンツを提供します。オリジナルビデオのシネマティックリリース(*)とペイウォールのを使って提供されるプレミアムライブコンテンツはどちらもこのモデルを活用しています。
ハイブリッドな収益化
- ほとんどの放送局は、複数のモデルを組み合わせてコンテンツ収益化を実現しており 1 つのカテゴリに収まりません。たとえば、Amazon Prime は SVOD プラン、AVOD プランを提供しながら、消費者が TVOD 形式でコンテンツをレンタルまたは購入できるようなサービスです。同様に、Netflix は、最近、より安い料金を支払う加入者向けに広告付きのサブスクリプションプランを追加しました。

訳注 [シネマティックリリース(*)]: 映画館で上映するかのようにオリジナルビデオをインターネットで都度課金で配信する方式です。映画館で上映し一定期間終了後に TVOD で映画を配信するサービスもあります。

これらの従来の収益化モデルの超えて、2023 年にはコンテンツ収益化するためのさらに多くの創造的な可能性がもたらされると予測しています。たとえば、Amazon Inspire はインフルエンサーの写真や動画コンテンツからショッピング可能なアイテムのフィードを作成します。視聴者は、ボタンを押すだけでインフルエンサーが着ている商品そのものを購入することができます。これは、Amazon が同様の方法で独自の Prime コンテンツのアプリ内購入を実装するための足がかりになる可能性があります。

同様に、NFL が革新的な収益モデルのために Amazon Prime での配信を活用する可能性があります。 Amazon は現在、伝統的なテレビの最後の砦の 1 つである “サーズデイナイトフットボール” の権利を管理しています。では、主要な放送の中での賭けのオーバーレイ機能やその他のインタラクティブな機能をサポートする、 Amazon のゲームプラットフォームである Twitch に組み込まれているテクノロジーを活用を妨げているものは何でしょうか？ SVOD、AVOD、および TVOD を超えて、ゲーム内の賭けは、スポーツ放送の収益化の論理的な次のステップになるでしょう。

4. 没入型ビデオ体験とメタバース

マーク・ザッカーバーグは昨年、メタバースに大きな賭けをし、Meta は時価総額で7000億ドルを失いました。とはいえ、さらなる没入型のインターネットが私たちを待っていないと言っているわけではありません。

Northeastern のゲームデザインの教授である Celia Pearce 氏は次のように考えています。

Meta は、利用者に向けて何かを作成するという点で、目標を達成できませんでした。彼らはまた、業界がどこにあるのかを理解するという点で、そして、人々がゲームから視覚的に何を期待しているのか、また、ゲーム以外の体験で人々が実際に何をしているのか、の両方の観点で、目標を達成できていません。クリエイティビティは、仮想世界のキラーアプリです。

ザッカーバーグの大惨事にもかかわらず、調査会社のガートナーは、

人口の 25% が 2026 年までに、仕事、教育、ショッピング、娯楽、またはその他の理由で、メタバースに少なくとも 1 時間の時間を費やす

と予想しています。

メタバースは、最終的に、拡張現実 (AR)、仮想現実 (VR)、そしてもちろんビデオテクノロジーを使用して、物理的な世界とデジタルを融合した世界を形作るでしょう。しかし、それに投資する企業は長期戦を戦わなければなりません。メタバースという用語自体は 30 年以上前に作られたものですが、コンテンツ、ハードウェア、そして、その概念はまだ構築中です。

AR は、Pokémon GO から Instagram の AR フィルターに至るまで、VR よりも速いペースで普及しています。これは、コンテンツとハードウェアの急増のおかげです。 AR は視聴者の現実の環境にデジタルオブジェクトを重ね合わせますが、VR にはまったく新しいデジタル環境が必要となります。このため、VR の世界を実現するには、はるかにコストがかかり、手間がかかります。同様に、誰もがポケットにスマートフォンを持っていますが、VR ヘッドセットはあまり一般的ではありません。

メタバースを適切に活用している主要な企業には、Minecraft, Roblox, Unreal Engine, Decentraland などがあります。また、誰もが Apple の VR ヘッドセット (今春発売予定) を手に入れるのを待っています。これは間違いなく VR とメタバース技術の将来を後押しするでしょう。

5.ストリーミング速度とフィードの進歩

ビデオの遅延は、前述の没入型ビデオ対応の世界を構築する上での最大の障害の 1 つです。遅延を最小限に抑えることは、ライブスポーツの賭け、遠隔手術、IoT デバイス、そして、その他の多くのアプリケーションに非常に重要です。

遅延は、インターネット上でストリームを転送するために使用される配信技術に関連しているため、 2023 年に業界がどのように進歩するかについてのチェックポイントを以下に示します。

プロトコル
- 低遅延 HLS と DASH 向けの低遅延 CMAF は業界の有望な方向性でした。しかし、3 秒未満の配信では、リアルタイムのインタラクティブ性が必要なユースケースに対応することはできません。多くの組織は、リアルタイムのビデオ配信に全面的に取り組むか、チューニングされた (通常の) HLS と DASH によってサポートされる 6 秒の配信時間に固執するかのいずれかを選択しています。このため、Web リアルタイムコミュニケーション (WebRTC) は、インタラクティブストリーミングの最も有望なテクノロジとして浮上しています。 1 秒未満のプロトコルは、ほぼ同時のデータ交換をサポートするため、DASH 向けの低遅延 CMAF と低遅延 HLS では実現できない方法で、対面でのやりとりを実現します。ここで言及する価値のある 4 番目のオプションは、High Efficiency Streaming Protocol (HESP) です。超低遅延ストリーミングのために THEO テクノロジによって開発され、既存の HTTP インフラストラクチャで 1 秒未満のストリーミングを実現することを目指しています。
コンテンツ配信ネットワーク (CDN) のスケーリング
- ビデオ配信のもう 1 つの目標は、低遅延としばしば相容れないものでありますが、配信のスケーラビリティです。これは、WebRTC のような (超低遅延を実現することが可能な) プロトコルが、1 対多のブロードキャストではなく、小規模なビデオチャット環境向けに設計されているためです。コンテンツディストリビューターは、CDN スケーリングへの革新的なアプローチでこれを克服しています。例えば、Wowza の大規模なリアルタイムストリーミング機能は、カスタム CDN 全体に WebRTC をデプロイして、100 万人の視聴者へのビデオ配信をサポートします。マルチ CDN の利用も増加しており、コンテンツプロバイダーは複数のインターネットサービスプロバイダー (ISP) 間でトラフィックを共有できるため、それぞれの弱点を最小限に抑えることができます。
ビデオコーデック
- ビデオコーデックは、ストリームのエンコード速度とそれをサポートするプロトコルを決定することによって、ビデオ配信の速度にも影響を与えます。 H.265/HEVC と AV1 は、標準レイテンシのライブおよびオンデマンドストリーミングコンテンツ向けに成長しているコーデックですが、リアルタイムストリーミングには最適な解決方法ではありません。むしろ、多くのコンテンツディストリビューターは、インタラクティブビデオアプリケーションに (古き良き) H.264 を使い続けることを計画しています。

6. コネクティビティの向上: ATSC 3.0 および 5G

ATSC 3.0 と呼ばれる技術のおかげで、無料の無線 4K ブロードキャストが実現しました。 NextGen TV としてブランド化されたこのデジタル放送モデルは、米国内のどこでも HDR (ハイダイナミックレンジ) のデジタルストリーミングをサポートします。テレビにアンテナを設置するだけで、ABS, CBS, その他の主要なネットワークの放送コンテンツへのアクセスを楽しむことができます。テレビだけでなく、ATSC 3.0 を使用して、従来のブロードバンドにアクセスできない地域にインターネットサービスを提供できる可能性があります。このように、コネクティビティを普及させることができる手法が進められています。5G もそうです。

スマートフォン以外の対応デバイスが出現するにつれて 5G の領域では進歩が続いています。エンコーダー、スマート TV、Switch などのゲームコンソール、VR ヘッドセットがそのパワーを利用できるようになりました。これは何を意味するのでしょうか？ RV クロスカントリーを運転しながら、スマート TV でライブコンテンツのストリーミングを開始できるかもしれません。同様に、VR、高度な AI、普及している IoT はすべて 5G を使ったモバイルで利用することができるようになります。

7. オムニチャネルビデオマーケティング

オムニチャネルマーケティングには、Web サイト、アプリ、ソーシャルメディアチャネル、メール、SMS など、あらゆる接点を通じてシームレスな顧客体験を提供することが含まれます。多くのブランドは、まさにそのために動画に依存しており、それによって、顧客とやり取りするたびに顧客を満足させることができています。

Ulta Beauty の事例を紹介します。この化粧品ブランドは、Facebook と YouTube でビデオポッドキャストをホストし、ウェブサイトでメイクアップ学習クラスをライブ放送し、さらに、ライブストリーミング美容アプリ Supergreat と提携して、新製品の発表を行ったり、メイクアップ愛好家のコミュニティと交流しています。

それだけではありません。そこから、Ulta Beauty アプリを使用すると、顧客は AR を使用して仮想的に製品を試着したり、AI を利用した肌分析によって洗練された製品を選択したりできます。製品の小売業者は、ギフトアドバイザーとのパーソナライズされたビデオチャットサービスを提供したり、多くのデジタル技術を通してさらなる革新的な仮想体験を提供します。

2023 年、各企業のマーケティング担当者は、このようなモデルを参考にして、新たなビジネス戦略を検討する必要があるでしょう。

オムニチャネルビデオマーケティングを成功させるには、それを可能にするソフトウェアソリューションと同じくらい、その背後にあるクリエイティビティが重要となります。 Mediaocean の COO である Ben Kartzman は次のように述べています :

予算が厳しくなり、マーケターとそのエージェンシーはより少ないリソースでより多くのことを行うよう求められるため、広告主にとって、パブリッシャーやプラットフォーム全体にクリエイティブアセットを拡張することが重要になります。ブランドは引き続き、動画やディスプレイだけでなく、すべてのソーシャルチャネルに存在する必要があり、さまざまなパブリッシャー間で効率的に展開できるクリエイティブを自動化するためのソフトウェアが必要になります。さらに、クリエイティブは、それが実行されているチャネル専用に構築されているように感じられる必要があります。マーケティング担当者が Sun Microsystems が Java 用に開発した古いマントラに従うことを可能にすることで、広告技術はこれを可能にする重要な役割を果たします。クリエイティブを一度作成すれば、どこでも実行できます。

8. 市場統合

過去数年間、ストリーミング戦争は断片化を引き起こしました。しかし、加入者をめぐる戦いは 2022 年に頂点に達し、サインアップは減少し、視聴者は別の消費モデルに移行していきました (上記のトレンド項目 1、2、および 6 を参照ください)。

昨年の同じ時期には、グローバル加入者ベースで Netflix の成長はすでに鈍化していました。 2 回のレイオフが続き、同じことがストリーミングと技術の分野の多くの企業で行われました。その結果、2023 年以降は統合という名前のゲームが続くでしょう。

2022 年には、ストリーミング業界で次のような M&A が行われました。

ディズニーは BamTech で MLB の残りの株式を 9 億ドルで買収
ワーナーブラザーズはディスカバリーとの合併を最終決定しました
Amagi が Streamwise を買収
Telestream が Encoding.com を買収
ドルビーが Millicast を買収
Limelight Networks が Yahoo の Edgecast を買収
Wowza が Flowplayer を買収
3Play Media が Captionmax を取得
Enhouse Systems が Qumu を 1800 万ドルで買収

企業が無料のサービスを組み合わせるトレンドは、2023 年を通して続くと私は予測しています。

9. ブロックチェーンと非代替トークン (NFT)

NFT やブロックチェーンと言うと、ほとんどの読者はデジタル通貨を思い浮かべると思います。コンセプトはすべて結びついていますが、NFT がストリーミング業界に与える影響は、リスクの高い投資機会よりも、分散型のビジネスモデルに大きく関係しています。

従来の富が現金とユニークな資産 (アートや収集品と考えてください) の両方の観点から測定できるのと同様に、デジタルの富は暗号通貨と NFT の観点から測定できます。 NFT は、車の所有権のように、購入した資産のデジタル証明書として機能します。

YouTube のようなサードパーティの仲介者に依存するのではなく、直接の収益化を可能にすることで、デジタル台帳技術として、ビデオコンテンツの交換方法を民主化することを約束します。個人のクリエイターと企業の両方が NFT の恩恵を受けることができます。たとえば、イベントへのチケット、使用料を提供する契約上の合意、さらには個人情報の保護としても機能します。

収益化と著作権管理を個々の所有者の手に委ねることで、NFT はストリーミング配信に革命を起こすことができるでしょうか？

10. ストリーミングのグリーン化

ストリーミングのグリーン化は、ビデオ配信に関連するエネルギー要件に対する意識の高まりを表しています。ビデオは現在、すべてのインターネットトラフィックの 80% を占めているため、無駄な慣行を抑制し、効率を改善する方法を特定することは非常に理にかなっています。さらに、ストリーミングのグリーン化は、多くの場合、コンテンツディストリビューターのコスト削減につながるため、双方にとってメリットがあります。

2023 年、動画開発者は、動画配信エコシステム全体のエネルギー消費を削減する機会に、より注意を払っています。ビデオ分析は、ストリーミングセッションごとの二酸化炭素排出量の見積もり、ディスプレイの解像度、画面の明るさ、最適なコーデックの選択などに関する重要な洞察を提供できます。

結論

以上が 2023 年のストリーミング業界に関する私の 10 の予測となります。これらすべてのトピックについて、1 年を通してさらに深く掘り下げていきます。 Wowza ブログを購読することを忘れないでください。

Resources: ストリーミングプロトコル: 知っておくべきこと

Thu, 27 Oct 2022 00:00:00 +0900

この記事は、当社パートナーの Wowza Media Systems の記事 Streaming Protocols: Everything You Need to Know (Update) の翻訳記事です。

オンラインビデオ配信に関して議論する際に、RTMP、HLS、MPEG-DASH、および WebRTC は、ポイント A から B にコンテンツを取得するために使用されるストリーミングプロトコルを指します。様々なプロトコルが、様々な種類のブロードキャストで役割を果たすため、あるプロトコルが別のプロトコルより優れているとは必ずしも言えません。

すべてのプロトコル技術を区別することは、ビデオストリーミングのスペースに参画するすべての人々にとっては困難なことです。各プロトコルが互換性、遅延、セキュリティ（これらの項目は追継続的に追加されています）の点でわずかに異なるという事実を考慮すると、本当に複雑になります。

この記事では、プロトコルとは何か、2022 年に最も一般的な 10 種類のビデオストリーミングプロトコル、そして、ユースケースに適したテクノロジを選択する際の考慮事項について、詳しく説明します。

プロトコルとは

プロトコルとは、ある通信システムから別の通信システムにデータを転送する方法を制御する一連の規約です。これらは、あるプロトコルスタックを形成するためにもうひとつのプロトコルの上に多重に重ねて形成されます。このようにして、各層のプロトコルは、特定の機能に集中し、プロトコル間で互いに協調することができます。最下層は基盤として機能し、その上の各層は（訳注: 各層に含まれる様々な機能が追加されることで）複雑になっていきます。

インターネットプロトコルを意味する IP および IP アドレスについて、聞いたことがあるでしょう。このプロトコルは、インターネットを使用するデバイスが通信する方法を構造化します。インターネットプロトコルは、ネットワーク層に位置し、通常、トランスポート層で Transmission Control Protocol (TCP) を重ねて形成され、同様に、アプリケーション層では Hypertext Transfer Protocol (HTTP) を重ねて形成されます。

上記の図のように、物理層、データリンク層、ネットワーク層、トランスポート層、セッション層、プレゼンテーション層、および、アプリケーション層を含む 7 つの層 (レイヤー) は、国際標準化機構 (ISO) のオープンシステム相互接続モデルによって定義されました。

ストリーミングプロトコルとは

ライブストリームやビデオオンデマンドの視聴をするたびに、ビデオストリーミングプロトコルを使用してインターネット経由でデータが配信されます。このビデオストリーミングのデータ通信は、アプリケーション層、プレゼンテーション層、および、セッション層で実行されています。

オンラインビデオ配信では、専用のストリーミングプロトコルと HTTP ベースのプロトコルの両方が使用されています。 Real-Time Messaging Protocol (RTMP) や Real-Time Streaming Protocol (RTSP) のストリーミングプロトコルは、専用のストリーミングサーバーを使用してビデオを配信します。

一方、HTTP ベースのプロトコルは、通常の Web サーバーを使って、視聴体験を最適化しながら、素早くスケーリングして配信します。

最後に、Apple の Low-Latency HLS (低遅延 HLS) などの新しい HTTP ベースの技術は、大規模な低遅延 (レイテンシー) ストリーミングをサポートすることで、両方のオプションの最良の部分を提供しようとしています。

訳注: 一般的に、専用のストリーミングプロトコルは配信の遅延を削減しながらビデオ配信ができますが、その代わりに、大規模配信のためのスケーリングが難しくなります。一方で、HTTPベースの技術は、大規模配信のスケーリングが容易です。

UDP vs. TCP: 簡単な背景

訳注: 本記事では、ビデオストリーミングプロトコルの比較の前に、プロトコルの性質の違いの理解のために UDP と TCP について触れます。

ユーザーデータグラムプロトコル (UDP) と伝送制御プロトコル (TCP) はどちらもインターネットプロトコル群のコアとなるコンポーネントであり、トランスポート層に位置します。ストリーミングに使用されるプロトコルは、これらのプロトコル層の上にあります。 UDP と TCP は品質と速度の点で性質が異なるため、詳しく調べる価値があります。

上図は https://microchipdeveloper.com/tcpip:tcp-vs-udp より転用

UDP と TCP の主な違いは、データを転送するときに TCP が 3 方向のハンドシェイクを必要とするという事実が大きなポイントです。(通信の) イニシエーター (クライアント) がアクセプター (サーバー) に接続の開始を要求し、アクセプターが応答し、イニシエーターが応答を確認して、両端間の (TCP) セッションを維持します。このため、TCP は非常に信頼性が高く、パケットの損失やパケットの順序付けの問題を解決できます。一方、UDP はハンドシェイクを必要とせずに開始します。帯域幅の制約に関係なくデータを転送するため、より高速で通信ができますが、通信の信頼性のリスクが高くなります。 UDP は再送信、パケットの順序付け、またはエラーチェックをサポートしていないため、ネットワークの不具合等により、途中でデータが破損する可能性があります。

Secure Reliable Transport (SRT) などのプロトコルは UDP を使用し、HTTP ライブストリーミング (HLS) などのプロトコルは TCP を使用します。

ビデオストリーミングの最も一般的なプロトコル

ビデオストリーミングプロトコルの比較を行います。一般的な 10 種類のビデオストリーミングプロトコルは以下の通りです。

リアルタイムメッセージングプロトコル (RTMP)
リアルタイムストリーミングプロトコル (RTSP)
APple HTTP ライブストリーミング (HLS)
低遅延 HTTP ライブストリーミング (Low-Latency HLS)
HTTP 動的アダプティブストリーミング (MPEG-DASH)
MPEG-DASH 向けの低遅延 CMAF
Microsoft スムースストリーミング (Smooth Streaming)
Adobe HTTP ダイナミックストリーミング (HDS)
SRT (セキュアリライアブルトランスポート)
WebRTC (Web リアルタイム通信)

従来のビデオストリーミングプロトコル

RTSP や RTMP などの従来のストリーミングプロトコルは、低遅延のストリーミングをサポートしています。ただし、ほとんどのエンドポイント (ブラウザー、モバイルデバイス、コンピューター、テレビなど) では、これらのプロトコルをネイティブにサポートしていません。現在、これらのストリーミングプロトコルは、IP カメラまたはエンコーダーと専用メディアサーバーの間でビデオを転送するのに最適となっています。

上記の図ように、RTMP はケーブル放送とほぼ同じ遅延でビデオを配信することができます — わずか 5 秒強です。 RTSP/RTP は約 2 秒の遅延と、さらに高速です。どちらのプロトコルも、ローカルでのダウンロードやキャッシュを必要とせずに、消防ホースアプローチを使用して (注釈参照) データを送信することで、このような速度を実現しています。しかし、RTMP と RTSP をサポートする映像再生プレーヤーはほとんどないため、大規模な視聴体験の実現には最適ではありません。多くの放送局は、RTMP などのステートフルプロトコルを使用して、ライブストリームをメディアサーバーに転送することを選択しています。そこから、マルチデバイスへの配信のための HTTP ベースの技術を使ってトランスコードします。

訳注: 消防ホースのアプローチとは、一度サーバーにデータ取得のリクエストを送信すると、その後、サーバーで受信または生成されたデータが可能な限り素早くレスポンスとして永続的に流れてくることを指します

Adobe RTMP

Adobe は、ビデオストリーミングの黎明期に RTMP 仕様を設計しました。このプロトコルでは、専用のストリーミングサーバーと Adobe Flash Player の間でオーディオデータとビデオデータを転送できます。このプロトコルは、信頼性が高く効率的で、ライブストリーミングに最適でした。しかし、オープンスタンダードとアダプティブビットレートストリーミングの技術によって、最終的に RTMP は追い抜かれてしまいました。この記事は、Adobe が Flash の廃止 (正式に 2020 年に終了しました) を発表された際に書かれました。

Adobe Flash のサポート終了日は過ぎましたが、「映像の入力に RTMP を利用すること」は終わっていません。 RTMP エンコーダーは、専用プロトコルがラストマイルの配信 (訳注: エンドユーザー向けの配信) で支持されなくなったにもかかわらず、依然として多くのコンテンツプロデューサーにとって頼りになる存在です。

実際、Wowza の 2021 年のビデオストリーミングレイテンシーレポートでは、コンテンツディストリビューターの 76% 以上が、映像の入力に RTMP を使用していると回答しています。


ビデオコーデック	H.264, VP8, VP6, Sorenson Spark®, Screen Video v1 & v2
オーディオコーデック	AAC, AAC-LC, HE-AAC+ v1 & v2, MP3, Speex, Opus, Vorbis
再生の互換性	広い範囲でサポートされない
	Flash Player, Adobe AIR, RTMP 互換プレーヤーのみでサポート
利点	低遅延でバッファリングが不要
欠点	エクスペリエンスやスケーラビリティの品質が最適化されていない
遅延 (レイテンシー)	5 秒
プロトコルのバリアント	RTMPT (HTTP 経由でトンネリング), RTMPE (暗号化), RTMPTE (トンネリングおよび暗号化), RTMPS (SSL 経由で暗号化), RTMFP (TCP ではなく UDP 経由で転送)

RTSP/RTP

RTMP と同様に、RTSP/RTP は映像の入力に使用される昔ながらの技術です。 RTSP と RTP は、しばしば同じ意味で使用されます。ただし、違いを明確にするため詳細を記載すると、RTSP は再生や一時停止などの機能を介してメディアサーバーにコマンドをエンドユーザーが送信できるようにするプレゼンテーション層プロトコルであり、RTP はデータを転送するために使用されるトランスポート層のプロトコルです。

Android および iOS デバイスには、すぐに使用できる RTSP 互換のプレーヤーがないため、再生に使用されることはほとんどありません。とはいえ、RTSP は多くの監視カメラや閉回路テレビ (CCTV) のアーキテクチャで標準とされたままです。なぜでしょうか？理由は簡単です。まだ、色々な IP カメラでは RTSP がサポートされているからです。

訳注: CCTVとは、閉回路テレビを意味し、特定の建物や施設内での利用される有線のテレビです。防犯カメラのモニターとして使われることが多い。


ビデオコーデック	H.265 (preview), H.264, VP9, VP8
オーディオコーデック	AAC, AAC-LC, HE-AAC+ v1 & v2, MP3, Speex, Opus, Vorbis
再生の互換性	広い範囲でサポートされない
	Quicktime Player およびその他の RTSP/RTP 準拠のプレーヤー, VideoLAN VLC メディアプレーヤー, 3GPP 対応のモバイルデバイス
利点	低遅延で、かつ、ほとんどの IP カメラでサポートされる
欠点	エンドユーザーへのビデオ配信には利用されなくなった
遅延 (レイテンシー)	2 秒
プロトコルのバリアント	RTP, RTCP (Real-Time Control Protocol), および RTSP のスタック全体は、多くの場合、RTSP と呼ばれる

アダプティブ (適応型) HTTP ベースのストリーミングプロトコル

HTTP 経由で展開されたビデオストリームは、技術的には「ストリーム」ではありません。むしろ、通常の Web サーバー経由で送信されるプログレッシブダウンロードです。アダプティブビットレートストリーミングを使用する HTTP ベースのプロトコルは、接続されたネットワーク、ソフトウェア、または、デバイスに関係なく、可能な限り最高のビデオ品質と視聴者体験を提供します。最も一般的な HTTP ベースのプロトコルには、MPEG-DASH や Apple HLS などがあります。

訳注: プログレッシブダウンロードとは、音声や映像をダウンロードしながら同時に再生することを指します。[こちらの記事](https://www.liveinstantly.jp/resources/blog/video-streaming-introduction/ も参照ください。

Apple HLS

Apple のデバイスは、インターネットに接続されたデバイスの世界で主要なプレーヤーであるため、Apple の HLS プロトコルが、デジタルビデオの世界を支配していることになります。 (Apple HLS プロトコルの重要な点の) 1 つには、このプロトコルは、視聴者体験の鍵となるアダプティブビットレートストリーミングをサポートしていることです。さらに重要なことは、HLS 経由で配信されたストリームが大部分のデバイスで再生でき、それによって多数の視聴者が確実にアクセスできるようになることです。

HLS のサポートは当初、iPhone や iPad などの iOS デバイスに限定されていましたが、その後、幅広いプラットフォームでネイティブにサポートされるようになりました。 Android、Linux、Microsoft、および macOS デバイスと同様に、すべての Google Chrome ブラウザは、HLS を使用して配信されたストリームを再生できます。


ビデオコーデック	H.265, H.264
オーディオコーデック	AAC-LC, HE-AAC+ v1 & v2, xHE-AAC, Apple Lossless, FLAC
再生の互換性	良好
	すべての Google Chrome ブラウザー, Android, Linux, Microsoft, および macOS デバイス, いくつかのセットトップボックス, スマート TV, およびその他のプレーヤー
利点	アダプティブビットレートのサポートと広いデバイスのサポート
欠点	低遅延よりもエクスペリエンスの質が優先される
遅延 (レイテンシー)	6 ～ 30 秒 (チューニングした場合のみレイテンシーを下げることが可能)
プロトコルのバリアント	低遅延 HLS (下記参照), PHLS (Protected HTTP Live Streaming)

低遅延 HLS

Low-Latency HLS (LL-HLS) は、低遅延のストリーミングに関する最新かつ最高の技術です。この Apple 独自のプロトコルは、ストリームを 3 秒以下遅延でグローバルに配信することを約束します。また、既存のクライアントとの下位互換性も提供します。

つまり、HLS と同じシンプルさ、スケーラビリティ、品質を提供しながら、遅延 (レイテンシー) を大幅に短縮するように設計されています。 Wowza では、この組み合わせをストリーミングトリフェクタと呼んでいます。

それでも、低遅延 HLS の展開を成功させるには、ビデオ配信エコシステムまたいだベンダーの統合が必要となります。ベンダーからのサポートはまだ不足しており、低遅延 HLS の大規模な展開はほとんどありません。


再生の互換性	低遅延 HLS 用に最適化されていないプレーヤーは、標準 (高い遅延の) HLS 動作にフォールバックできます
	HLS 互換デバイスには、macOS, Microsoft, Android および Linux デバイス, すべての Google Chrome ブラウザー, いくつかのセットトップボックス, スマート TV, およびその他のプレーヤーが含まれる
利点	低レイテンシ, スケーラビリティ, 高品質, 後方互換性
欠点	ベンダーはまだ新しい仕様としてサポートの実装作業中
遅延 (レイテンシー)	2 秒以下

MPEG-DASH

MPEG-DASH は、ベンダーに依存しない HLS の代替手段です。基本的に、DASH を使用すると、同じスケーラビリティと品質を保証するベンダー非依存（非プロプライエタリな) オプションを利用できます。しかし、Apple は自社の技術スタックを優先する傾向があるため、DASH のサポートは、多数の Apple デバイスの市場の中で 2 番目の役割を果たす傾向にあります。


ビデオコーデック	コーデックに依存しない
オーディオコーデック	コーデックに依存しない
再生の互換性	良好
	すべての Android デバイス, ほとんどの 2012 年以降の Samsung/Philips/Panasonic/Sony TV, Chrome/Safari/Firefox ブラウザ
利点	ベンダーに依存しないアダプティブビットレートの国際標準である
欠点	iOS または Apple TV ではサポートされない
遅延 (レイテンシー)	6 ～ 30 秒 (チューニングした場合のみレイテンシーを下げることが可能)
プロトコルのバリアント	MPEG-DASH CENC (共通暗号化)

MPEG-DASH 向けの低遅延 CMAF

MPEG-DASH 向けの低遅延 CMAF は、HTTP ベースのビデオ配信を高速化するためのもう 1 つの新しい技術です。まだ初期段階ですが、この技術は、短いデータセグメントを使用することで超高速で大規模にビデオを配信できる可能性を示しています。とはいえ、多くのベンダーは、DASH の低遅延 CMAF のサポートよりも、低遅延 HLS のサポートを優先しています。


再生の互換性	DASH の低遅延 CMAF 用に最適化されていないプレーヤーは、標準の DASH 再生にフォールバックできます。
利点	低遅延が (国際標準仕様の) HTTP ベースのストリーミングに対応
欠点	ベンダーはまだ新しい仕様としてサポートの実装作業中
遅延 (レイテンシー)	3 秒以下

Microsoft スムースストリーミング (Smooth Streaming)

Microsoft は、Silverlight プレーヤーアプリケーションで利用する Microsoft Smooth Streaming を 2008 年に開発しました。これにより、すべての Microsoft デバイスへのアダプティブストリーミングの配信が可能になりました。このプロトコルは他の HTTP ベースのストリーミングプロトコルと競争できず、使用されなくなりつつあります。実際、Wowza の 2021 年のビデオストリーミングレイテンシーレポートでは、この Microsoft スムースストリーミングプロトコルを使用していた回答者はわずか 5% でした。


ビデオコーデック	H.264, VC-1
オーディオコーデック	AAC, MP3, WMA
再生の互換性	良好
	Microsoft および iOS デバイス, Xbox, 多くのスマート TV, Silverlight プレーヤー対応ブラウザー
利点	アダプティブビットレートのサポート, iOS でサポート
欠点	Microsoft 独自の技術であり、HLS や DASH と競合
遅延 (レイテンシー)	6 ～ 30 秒 (チューニングした場合のみレイテンシーを下げることが可能)

現在使用しているストリーミングプロトコルについての調査結果:

Adobe HDS

Adobe HDS は、最初のアダプティブビットレートプロトコルとして Flash Player で使用するために Adobe 社で開発されました。 Flash はもはや存在しないため、徐々にすたれつつあります。上記の調査結果のグラフをもう一度確認してください。


ビデオコーデック	H.264, VP6
オーディオコーデック	AAC, MP3
再生の互換性	広い範囲でサポートされない
	Adobe Flash Player, Adobe AIR のみ
利点	Adobe Flash のアダプティブビットレート技術である
欠点	マルチデバイスのサポートが不足している Adobe 社の独自の技術
遅延 (レイテンシー)	6 ～ 30 秒 (チューニングした場合のみレイテンシーを下げることが可能)

新しい技術

最後になりましたが、WebRTC や SRT などの新しい技術は、ビデオ配信の状況を変えることを約束しています。 MPEG-DASH および Apple Low-Latency HLS で利用される低遅延 CMAF と同様に、これらのプロトコルは低遅延を考慮して設計されています。

SRT (Secure Reliable Transport)

このオープンソースプロトコルは、ネットワーク接続の品質に関係なく、信頼性の高いストリームを配信するのに役立ち、かつ、独自のトランスポート技術に代わる実証済みのプロトコルとして認識されています。ファーストマイルソリューションとして RTMP および RTSP と直接競合しますが、エンコーダー、デコーダー、および、プレーヤーでこの技術がサポートがされ採用されています。

失われたパケットの回復からタイミング挙動の維持まで、SRT はパブリックインターネットをまたいだビデオの入力と配信の課題を解決するように設計されています。そして、急速に業界を席巻しています。 SRT が有効であることが証明されたインタラクティブなユースケースの 1 つは、2020 年のバーチャル NFL ドラフトでした。 NFL は、最初の完全なバーチャルイベントのために 600 のライブフィードの接続にこの画期的な技術を使用しました。


ビデオコーデック	コーデックに依存しない
オーディオコーデック	コーデックに依存しない
再生の互換性	制限あり
	VLC Media Player, FFPlay, Haivision Play Pro, Haivision Play, Larix Player, Brightcove
利点	最適ではないネットワークを介した高品質で低遅延のビデオ
欠点	ビデオ再生が広くサポートされていない
遅延 (レイテンシー)	3 秒以下 - パケットロスと引き換えに必要な遅延に基づいて調整可能

WebRTC

WebRTC は、利用可能な最も高速な技術として、主要なブラウザとの間でほぼ瞬時にオーディオとビデオのストリーミングを提供します。また、エンド・ツー・エンドで使用できるため、入力および配信プロトコルと競合します。このフレームワークは、純粋なチャットベースのアプリケーション向けに設計されましたが、現在では、より多様なユースケースに採用されています。

ただし、WebRTC にとって、スケーラビリティは依然として課題であるため、この課題を克服するには、Wowza の Real-Time Streaming at Scale 機能などのソリューションを使用する必要があります。このソリューションは、カスタム CDN 全体に WebRTC サービスを展開して、ほぼ無限のスケールを提供します。これにより、放送局は 500 ミリ秒未満の配信で 100 万人の視聴者にリーチできる可能性があります (これはかつて不可能だった偉業です)。

訳注: WebRTC は Webベースの技術であるが、HTTPベースのアダプティブストリーミングとは異なり、オーディオやビデオのデータのキャッシュ配信ができないため、大規模向けの配信のようなスケーラビリティが必要となるシナリオに課題がある


ビデオコーデック	H.264, VP8, VP9
オーディオコーデック	Opus, iSAC, iLBC
再生の互換性	Chrome/Firefox/Safari でプラグインなしでサポート
利点	超高速でブラウザベースのサポート
欠点	ビデオ会議用に設計されており、スケーリングできない
遅延 (レイテンシー)	500 ミリ秒以下

ワークフロー: Wowza Video の大規模なリアルタイムストリーミング

ストリーミングプロトコルを選択する際の考慮事項

適切なストリーミングプロトコルの選択は、何を達成しようとしているのかを定義することから始まります。選択したプロトコルにより、遅延、再生の互換性、視聴体験のすべてが影響を受ける可能性があります。さらに、コンテンツディストリビューターは、コンテンツのキャプチャから再生まで常に同じプロトコルに固執する必要はありません。多くの放送局は、RTMP を使用してエンコーダーからサーバーに到達し、ストリームを HTTP ベースのアダプティブストリーミングプロトコルにトランスコードします。

メディアストリーミングプロトコルは、次の領域で異なります。

ファーストマイルの転送とラストマイルの配信
再生のサポート
エンコーダーのサポート
スケーラビリティ
遅延 (レイテンシー)
体験の品質 (アダプティブビットレートの有効化など)
セキュリティ

上記の考慮事項に優先順位を付けることで、それぞれのシナリオで最適なものを簡単に絞り込むことができます。

転送と配信

RTMP と SRT は最初のファーストマイルの転送 (訳注: 映像の入力) に大きく貢献しますが、再生（訳注: エンドユーザーに対するビデオ配信）に関しては MPEG-DASH と HLS の両方のプロトコルがリードしています。一方では、RTMP は配信のための技術としては完全に支持されなくなり、HLS は理想的な入力プロトコルではありません。そのため、ほとんどのコンテンツディストリビューターは、メディアサーバーまたはクラウドベースのビデオプラットフォームに依存して、コンテンツをあるプロトコルから別のプロトコルにトランスコードしています。

再生のサポート

もし視聴者がストリームにアクセスできないとしたら、ストリームを配信する意味は何でしょうか？エンドユーザーへの配信で RTMP が役割を果たさなくなった理由は、再生サポートの欠如です。また、ユビキタスな再生サポートが、HLS が今日最も人気のあるプロトコルである理由です。

エンコーダーのサポート

再生のサポートの逆は、エンコーダーのサポートです。 RTMP は、RTMP エンコーダーがすでに市場で普及しているため、多くの欠陥があるにもかかわらず、強い地位を確保しています。同様に、RTSP は IP カメラに最適なプロトコルであるため、監視映像の業界での地位が維持されています。

WebRTC は、追加の技術を必要とせずにブラウザーベースの映像の公開と再生に利用できるという点で独特な技術であり、プロダクション品質のエンコーダーとカメラを必要としないユースケースでシンプルなストリーミングを実現可能にします。

スケーラビリティ

HLS はスケーラビリティと同義です。幅広くサポートされている HTTP ベースのプロトコルは、Web サーバーを活用して、今日の配信対象となりえるあらゆるデバイスに配信することができます。しかし、スケーラビリティを持って配信されるプロトコルは、配信の遅延 (レイテンシー) の観点で欠点があります。これは、従来、遅延 (レイテンシー) とスケーラビリティが相容れないものであったためです。ただし、大規模なリアルタイムストリーミングなどの新しい技術は、この矛盾を解決することができます。

訳注: HLS, MPEG-DASH のような今日でも市場で広く使われている HTTP ベースのアダプティブストリーミングはスケーラビリティをもって配信することができます。

遅延（レイテンシー）

低遅延の HLS、MPEG-DASH 向けの低遅延の CMAF、および、WebRTC はすべて、(低遅延の) 高速な配信を念頭に置いて設計されています。インタラクティブビデオ環境を展開する場合は、これら 3 つの配信プロトコルのいずれかを検討する必要があります。

体験品質

一部のニッチなビデオエクスペリエンスではリアルタイム配信が不可欠ですが、高品質の配信が最低限必要なものになっています。視聴者はもはや、スムーズで高解像度のストリームを評価しなくなりました。彼らはただそれを (当たり前のものとして) 期待しています。そして、最高のユーザーエクスペリエンス (視聴者体験) を確保するための最善の策は、アダプティブビットレートストリーミングをサポートするプロトコルを使用することです。これは、HLS と MPEG-DASH によって展開されるコアとなる技術です。

セキュリティ

最後になりましたが、コンテンツ保護を検討する必要があるでしょう。暗号化とデジタル著作権管理 (DRM) は、HLS と MPEG-DASH では標準でサポートされています。一方、WebRTC はブラウザーによって保護されていますが、放送ワークフローのための DRM 機能と標準的なすぐに使えるセキュリティ対策が欠けています。したがって、ワークフローを設計するときは、このことを念頭に置いておく必要があります。

結論

2022 年の映像ストリーミングに最適なプロトコルは？

それはあなた次第です。

訳注: 特にどのプロトコルが優れているなどの比較ができないので、お客様のビデオワークフローの要件に依存します。

適切なビデオ技術は、各々のビジネスのニーズによって異なります。最適なプロトコルを探すのではなく、最も柔軟性のあるビデオプラットフォームを探すことがよいでしょう。

幅広いプロトコルから選択できることは、遅延を減らしたり、再生の互換性を高めたり、さらにはリモートビデオコントリビューションの課題に対処しようとする方法を探しているすべての人にとって不可欠となります。さらに、今日の多くのビデオエンジニアは、入力・転送と配信でさまざまなプロトコルを使用するハイブリッドワークフローを構築しています。

ビデオは、現在、あらゆる業界のビジネスに力を与えています。そのため、規範的なストリーミングワークフローや型にはまった技術だけではうまくいきません。しかし、読者にとっては幸運なことに、Wowza の柔軟なビデオプラットフォームは、幅広いプロトコルをサポートし、様々なニーズに合わせてカスタマイズできます。

ストリーミングワークフローを設計する最適な方法について専門家に相談したり、無料でトライアルを開始したりするには、今すぐお問い合わせください。

Resources: WebRTC とは？

Mon, 24 Oct 2022 00:00:00 +0900

この記事は、当社パートナーの Wowza Media Systems の記事 What Is WebRTC? (Update) の翻訳記事です。この記事では、WebRTC ストリーミングプロトコルを詳しく説明します。

ビデオ会議からオンラインの賭けや入札まで、インタラクティブなライブストリーミングソリューションでは、Web リアルタイムコミュニケーション (WebRTC) が不可欠な基盤技術になっています。 WebRTC の普及は、速度と互換性の組み合わせに行き着きます。

より具体的には、WebRTC は 500 ミリ秒未満のビデオ配信で最も遅延の低いストリーミング形式です。また、ブラウザーでのネイティブサポートにより、エンドユーザーが (不格好な) アプリをダウンロードして配信されるストリームを再生する必要がなくなります。

とは言え、WebRTC が設計された純粋なチャットベースのアプリケーションから外に出て開発者が他のシナリオを検討しはじめると、課題が発生する可能性があります。この記事では、WebRTC ビデオストリーミングの仕組み、それがもたらす利点、WebRTC の制限、および、それらを解決する方法について説明します。

WebRTCとは?

WebRTC は、その名前の通り、リアルタイム通信 (RTC) を可能にする Web のためのフリーのオープンフレームワークです。標準仕様、プロトコル、および、JavaScript API の組み合わせとして、WebRTC はブラウザー間でのピアツーピア接続を活用して、サードパーティのソフトウェアやプラグインを必要とせずに、ほぼ同時にデータを交換することができます。

つまり、WebRTC を使用すると、ユーザーはブラウザからクリックして開始するビデオチャットを開始し、対面でのやり取りと同様の十分な速さで情報を交換できます。これにより、一連の標準プロトコルを介したブラウザ間の通信が実現でき、個人間のインタラクティブなライブストリーミングのシナリオがサポートされます。

WebRTC はどのように機能しますか?

WebRTC は 3 つの HTML5 API を採用しており、ユーザーのブラウザーが相互にライブストリームをキャプチャ、エンコード、および、送信できるようにし、双方向通信を可能にします。このため、WebRTC はピアツーピアテクノロジと呼ばれ、各ブラウザは互いに直接通信します。

WebRTC の優れた点はそこにあります。追加の機器やソフトウェアは言うまでもなく、WebRTC の通信データの交換中に中間 Web サーバーが不要になります。 URL ベースのオンラインミーティングは、WebRTC が提供する利便性とリアルタイムコミュニケーションの優れた例です。

一部のストリーミングワークフローでは、ライブストリーミングカメラ、エンコーダー、およびメディアサーバーが必要ですが、最も単純な WebRTC ワークフローの展開では、接続された Web カメラとブラウザーですべてを実現できます。また、Flash ベースのビデオとは異なり、WebRTC は WebRTC API をサポートする任意の HTML5 プレーヤーで再生できます。

ただし、WebRTC は中間サーバーなしでネイティブに情報交換ができるよう設計されているため、多数の視聴者を処理することはできません. WebRTC を大規模にストリーミングしようとする場合は、ストリーミングサーバーまたはサービスの助けが必要です。コンテンツをよりスケーラブルな配信が可能な形式にパッケージ化することから、カスタム構築された WebRTC コンテンツ配信ネットワーク (CDN) を介してライブストリームを配信することまで、Wowza では WebRTC ワークフローを構成して最大 100 万人の視聴者の視聴に対応するためのオプションを提供できます。

WebRTC スナップショット

オーディオコーデック: Opus、iSAC、iLBC
ビデオコーデック: H.264、VP8、VP9
再生の互換性: Chrome、Firefox、および Safari は、プラグインなしで WebRTC をサポートします
利点: 超高速でブラウザベース
欠点: ビデオ会議用に設計されており、拡張性がないため、大勢の視聴者にストリーミングする場合は Wowza のようなストリーミングプラットフォームが必要です
遅延 (レイテンシ): サブ 500 ミリ秒の配信

WebRTC の成り立ち

WebRTC は、ブラウザがプラグインなしでリアルタイムの音声およびビデオ通信をサポートできることを目的とした Google オープンソースプロジェクトとして始まりました。多くの点で RTMP や Flash などの独自のストリーミング技術に対するアンチテーゼとなる WebRTC は、IETF と W3C によって標準化されています。 WebRTC は、コミュニティ主導のプロジェクトの力と確立された仕様のクロスプラットフォームサポートが組み合わさったことで、最初の開発の後、その後の 10 年間で成長しました。

現在、WebRTC は Chrome, Safari, Firefox, Opera, Microsoft Edge, Android, iOS (iOS 15 + Safari を除く) でサポートされています。また、Google ハングアウト, Facebook Messenger, Houseparty などのビデオチャットを強化する技術でもあります。 Google によると、

WebRTC をサポートする Chrome, Edge, Firefox, Safari によって、世界中でインストールされているすべてのブラウザーの 85% 以上がインターネット上のリアルタイム通信のクライアントになっている

とのことです。

WebRTC の利点

WebRTC がユーザーと開発者の両方に提供する多くの利点を考えると、WebRTC がこれほどまでに誇大宣伝されている理由は理にかなっています。低遅延の配信から相互運用性まで、すべてが魅力的な選択肢となっています。

本来の低遅延の性質: 配信速度に関して言えば、WebRTC は群を抜いています。 500 ミリ秒未満の Glass-to-Glass 遅延 (訳注: 送信元の画面の表示から受信先の画面の表示までの遅延) で、WebRTC はインターネット経由でビデオを転送するための最速の方法を提供します
プラットフォームとデバイスの非依存性: すべての主要なブラウザーとデバイスは WebRTC をサポートしているため、専用のインフラストラクチャーなしで幅広く Web アプリに簡単に統合できます; WebRTC は HTML5 API を使用するため、開発者は HTML5 プログラミング言語に組み込まれた多くの機能を軽量の組み込みフレームワークを通じて利用でき、さらに、ブラウザベースのエンコーディングにより、すべてのユーザーにとってアクセスしやすいエンドユーザーエクスペリエンスが保証されます
オープンソースの標準化: オープンソースフレームワークは IETF と W3C によって標準化されているため、独自のストリーミングテクノロジに伴う相互運用性の問題が解消されます; Computerworld の Shan Sinha 氏は次のように説明しています :

WebRTC は、何千人ものソフトウェア開発者が協力して作業し、会議プロトコルを標準化し、相互運用性をあまり気にしないという利点があります

ほとんどの企業は、プラットフォームにコードを提供する何千もの独立した開発者と競争することはできません — Google や Apple のような大規模な組織でさえ、Web コミュニティ主導の取り組みと比較すると見劣りします
様々なネットワーク条件に適応: WebRTC は、アダプティブネットワークエンコーディングにより、劣悪なネットワーク環境でも信頼性の高いパブリッシング (訳注: ビデオの送出) を保証します。これは、“サイマルキャスト” と呼ばれる機能をサポートしているためです。この用語の従来の定義である、「複数の宛先へのブロードキャスト」と混同しないよう注意してください。 WebRTC サイマルキャストを使用すると、クライアントはさまざまなビットレートと品質で複数のストリームを生成するため、ネットワークの状態が悪くてもビデオの送出が妨げられることはありません。再生中にストリームが動的に調整されるアダプティブビットレートストリーミングとは異なり、これはパブリッシング側 (訳注: ビデオの送出側) で行われ、ストリームの途中でビットレートを適応させる機能ではなく、複数のエンコーディングを提供します。

WebRTC の制限

WebRTC ストリーミングでは、低遅延配信が最優先されます。その結果、その他の追加の技術なしで WebRTC を展開する場合、スケーラビリティと配信品質に制限があります。

スケーラビリティ
- WebRTC はスケーラビリティを考慮して設計されていません。
- 帯域幅を集中的に使用するような構成では、参加している各ブラウザーがピア接続を介して相互に接続する必要があります。WebRTC の専門家である Tsahi Levent-Levi は 50 を超える同時ピア接続を避けることを推奨しています。
配信品質
- 一般的な誤解としては、ビットレートの制限により WebRTC の品質が十分でないというものです。
- ブラウザーベースの配信では、解像度の面では本質的にはネットワークの接続性とカメラの機能に依存しますが、高ビットレートのエンコーディングは依然として可能です。
- とはいえ、プロのエンコーダーとカメラを使用してストリーミングしたいコンテンツのディストリビューターにとっては、制作されたコンテンツのストリーミングにはこのタイプのワークフローが理想的とは言えないかもしれません。
- さらに、アダプティブビットレートストリーミングのサポートは、WebRTC では制限されています。

WebRTC ストリーミングのユースケース

WebRTC は、速度と双方向性に依存するアプリケーションにとって理想的な配信フレームワークです。たとえば、オンラインオークションを主催しているとします。カメラで入札を募っていますが、5 秒の遅延は、視聴者が少し遅れて入札することを意味します。 1 回、2 回、最終的なオファーを受け入れます。最後の 1 秒で誰かがより良い入札を入れようとしますが、その遅延のせいですでに入札を閉じてしまっているかもしれません。

WebRTC の 500 ミリ秒未満の遅延では、その遅延は問題とはなりません。その最終入札をほぼリアルタイムで受け付けることができます。 WebRTC は、次のようなアプリケーションにも役立ちます。

ゲーム
e-スポーツ
ライブスポーツ
フィットネス
ギャンブル
緊急対応
監視
遠隔医療
その他の様々なアプリケーション

配信するストリームをリアルタイムに近づける必要があるほど、WebRTC による解決の可能性が高くなります。

WebRTC セキュリティとは？

WebRTC は、SRTP (Secure Real Time Protocol) 暗号化およびその他の標準のグループ (結局のところ、単なるプロトコル以上のものとなっている) を義務付けているため、安全です。 WebRTC の標準化を支援した組織の 1 つである Internet Engineering Task Force は、暗号化を必要としない WebRTC 接続を完全に禁止しています。

プロトコルレベルで暗号化されるだけでなく、WebRTC はブラウザとコミュニティによってサポートされたセキュリティも活用しています。 Firefox, Chrome, Safari, Edge などの主要なブラウザはすべて WebRTC セキュリティを真剣に考えているため、WebRTC フレームワークにアクセスするために HTTPS、IP アドレス漏洩の保護、カメラとマイクへのアクセスを許可する前にユーザーが個々のサイトにアクセス許可を付与すること、および、その他のプライバシーコントロールを必要とします。オープンソースプロジェクトとして、WebRTC の開発者コミュニティも協力して、最高のセキュリティを確保しています。

標準の Web 暗号化とセキュリティが WebRTC の追加レイヤーとどのように比較されるか、理解を深めるために次のワークフローを確認してください。

WebRTC は他のプロトコルとの比較

上記に説明したように、WebRTC は単なるプロトコルではありませんが、HLS, RTMP, RTSP, SRT など、プロトコルのみの観点ではいくつかのビデオ配信形式に代わるものになります。WebRTC はこれらと比べてどのようになるでしょうか？

WebRTC と HLS

HTTP ライブストリーミング (HLS) は、通常、ラストマイル配信に使用される Apple 独自のプロトコルです。 Apple は、当初、ライブストリーム中の iPhone での再生に関する問題を解決するためにこのプロトコルを開発しましたが、その後、人気を博し、現在では無数のデバイスとブラウザーがサポートするほぼ普遍的に受け入れられているプロトコルになっています。

再生の互換性は、プロトコルを比較する主な理由となります。WebRTC と HLS をサポートしていないシステムはほとんどないため、視聴者を除外してしまうことを心配する必要はありません。

これらのプロトコルの主な違いは、遅延 (レイテンシー) とスケーラビリティにあります。 HLS 自体は実際にはかなり遅く、レイテンシーは 6 ～ 30 秒です。 Apple の Low Latency HLS 拡張機能を使用すると、その遅延を約 2 秒に短縮することができますが、それでも WebRTC で実現できる 500 ミリ秒未満の配信とは比較になりません。

ただし、HLS はスケーラブル配信を可能とします。このプロトコルにより、数千から数百万の視聴者に簡単に配信することができます。 WebRTC は大量の視聴者にコンテンツをストリーミングすることが意図された設計ではないため、最大 50 人の視聴者まではパフォーマンスが向上します。ただし、Wowza の Real-time Streaming at Scale のようなソリューションのカスタム CDN 部分を使用して、WebRTC のスケーラビリティの問題を克服し、何百万人もの視聴者にリーチすることは可能です。

WebRTC 対 RTMP および SRT

Real-Time Messaging Protocol (RTMP) は、Adobe Flash との緊密な関係のため、かつて業界で最も重要なプロトコルでした。 RTMP は、Flash の廃止後、ストリーミングワークフローの特定の部分でほとんどサポートされなくなりましたが、エンコーダーとの互換性により、最初の 1 マイル (ファーストマイル) のビデオの入力では依然として人気があります。たとえば、多くのワークフローでは、ビデオストリームを HLS にトランスコードしてラストマイル配信する前に、RTMP でエンコードして入力します。

RTMP の遅延は約 5 秒で、WebRTC の非の打ちどころのない遅延にはほど遠いですが、低遅延の拡張機能を使用しない場合、HLS と DASH (の引き起こす遅延) を凌駕しています。 WebRTC は、セキュリティや互換性 (RTMP をサポートするブラウザーはほとんどありません) など、他の多くの面で RTMP に匹敵するか、または、RTMP よりも優位性がありますが、キャプション、時刻付きのメタデータ、広告マーカーなどの機能では、RTMP が優位に立っています。 WebRTC は、トランスコーディングを必要としない Glass-to-Glass ストリーミングに最適な選択肢です (特にどちらか一方の終端に Web ブラウザーだけが利用できる場合)。

また、WebRTC と Secure Reliable Transport (SRT) の比較を検討することも重要です。 SRT は RTMP の代替として開発され、低遅延で信頼性の高いストリームを配信するためにネットワーク品質の低さを補うことができます。そのため、SRT の長所と短所は、WebRTC と比較すると似ています。トランスコードする前に、最初の 1 マイル (ファーストマイル) のビデオの入力に使用でき、SRT を使用してジッターやパケット損失などの問題を解決できます。

WebRTC 対 RTSP

リアルタイムストリーミングプロトコル (RTSP) は、厳密には、クライアントからサーバーへのデータの転送を行いません。データ転送は、リアルタイムトランスポートプロトコル (RTP) の役割です。しかし、RTSP/RTPは、マルチメディアの再生に対応し、RTMP とよく比較されます。

RTSP は多くの場合、IP カメラの既定のプロトコルであるため、RTSP と WebRTC は互いに補完し合うことがあります。これらのカメラは、最初の 1 マイル (ファーストマイル) のビデオの入力には RTSP を使用し、最後の 1 マイル (ラストマイル) の配信には映像を WebRTC にトランスコードすることで、レイテンシを劇的に短縮します (これは監視のシナリオでは特に重要となります)。 WebRTC はまだほとんどがブラウザベースの実装であるため、プロセスの両端で使用されていないので、IP カメラでのエンコードには RTSP を使ってこのワークフローが実現されます。

訳注: この記事の投稿時点では、WebRTC 出力をサポートする IP カメラはありませんので、IP カメラからの出力は RTSP となりますが、Wowza のソリューションを使うことで、WebRTC の出力で配信することができます

WebRTC スケーラビリティの問題の解決

従来のピアツーピア WebRTC 接続では、それぞれのブラウザーはグループ内の他のすべてのブラウザーに直接接続し、その結果として帯域幅を消費します。 Wowza は、WebRTC のスケーラビリティの制約を克服するための 3 つのオプションを提供します

Wowza Video の大規模なリアルタイムストリーミング

Wowza Video の大規模なリアルタイムストリーミング機能は、カスタム CDN 全体に WebRTC を展開し、ほぼ無限のスケールを提供します。コンテンツの配信者は、0.5 秒未満で 100 万人の視聴者にストリーミングできるため、リアルタイム配信と大規模なブロードキャストを組み合わせることができます。
Wowza ストリーミングエンジンを搭載した WebRTC

すべてのライブストリーミングの参加者を Wowza Streaming Engine のようなライブストリーミングサーバーに接続することで、コンテンツ配信者は大規模なリアルタイムストリーミングの恩恵を受けながら、それぞれのクライアントが確立および維持する必要のある接続数を最小限に抑えて帯域幅を最適化します。数百人の視聴者を超えて配信をスケーリングするには、追加のインフラストラクチャが必要になります。その場合、Wowza Video を使用した大規模なリアルタイムストリーミングがより適切な方法です。
WebRTC を HLS または DASH に変換する

最後に、ライブストリーミングサーバーまたはクラウドベースのサービスを使用して、WebRTC ストリームを HLS などのプロトコルにトランスコードし、数千人に配信できます。こうすることで、コンテンツ配信者は、待ち時間は長くなりますが、シンプルなブラウザーベースのパブリッシングと大規模なブロードキャストを組み合わせることができます。 WebRTC をストリーミングワークフローに組み込む主な理由がコンテンツの単純な配信 (リアルタイム配信ではない) である場合、このソリューションが最適です。

訳注: CDN を組み合わせることで数千から数百万の大規模の視聴者に配信することが可能となります。

WebRTC 配信品質の問題の解決

WebRTC 経由でストリーミングされるコンテンツの品質を向上させる場合、上記で概説した 2 つのオプションが再び有効になります。

Wowza Video の大規模なリアルタイムストリーミング

Wowza Video の大規模なリアルタイムストリーミングは、RTMP インジェストを使用するか、カスタムの OBS 統合を活用して、任意のエンコーダーを介してストリーミングを入力する柔軟性を提供します。つまり、コンテンツ配信者は、制作されたコンテンツの配信を検討する際に、ブラウザベースのキャプチャとエンコーディングに限定されないということです。
WebRTC を HLS または DASH に変換する

HLS と DASH は、アダプティブビットレートストリーミングを活用して、接続、ソフトウェア、またはデバイスに関係なく、可能な限り最高のビデオ品質と視聴者体験を提供します。そのため、WebRTC ストリームをこれらのプロトコルのいずれかに変換すると、配信規模と配信品質が解決されます。重要なトレードオフは遅延であるため、リアルタイム配信が優先されない場合にのみ、このワークフローをお勧めします。

WebRTC と Wowza を組み合わせる理由

リアルタイムの双方向性、大規模なブロードキャスト、または、その両方をサポートする必要がある場合でも、Wowza の WebRTC ソリューションはニーズに合わせてカスタマイズすることができます。小売業からゲーム業界まで、様々な業界の組織が、リアルタイム配信、ブラウザベースのビデオの取り込み、および、大規模なビデオ配信の実現のために、Wowza を利用した WebRTC に依存しています。

無限のスケーリング

WebRTC は、参加者が少数のビデオチャット環境向けに設計されていますが、Wowza の技術と組み合わせることで、最大 100 万人の視聴者にブロードキャストすることができます。 Wowza Video の大規模なリアルタイムストリーミングにより、超高速配信をシームレスに実現することができます。
拡張された可能性

ビデオ録画、セキュリティ、その他の機能強化など、WebRTC に追加機能を追加するには、バックエンドに強力なストリーミングソフトウェアが必要となります。 Wowza は、WebRTC の標準機能を強化するための強力なツール、API、および、モジュールを提供します。また、Wowza のライブストリーミングプラットフォームを使って、コンテンツ配信者が、ニーズに適した他のストリーミングプロトコルと WebRTC とを組み合わせたハイブリッドワークフローを構築できます。
シンプルなブラウザベースのブロードキャスト

WebRTC はブラウザーベースのパブリッシングを強化しますが、バックグラウンドで Wowza を使用することで、無数のユーザーにコンテンツをブロードキャストすることができます。Wowza の WebRTC ストリーミングソリューションは、エンコーダーを必要とせずに、あらゆる宛先へのシンプルなエンド・ツー・エンドのブロードキャストを保証します。

Wowza で WebRTC を強化する方法についての詳細は、以下のリンクのビデオをご覧ください。

大規模なリアルタイムストリーミングのための Wowza Video と WebRTC : Wowza Video を使用すると、インタラクティブなアプリケーションに必要なリアルタイムエクスペリエンスを備えた 100 万人の視聴者にすぐにスケーリングするライブストリーミングイベントを作成できます。

Wowza Streaming Engine と WebRTC : Wowza Streaming Engine に搭載された WebRTC を使用すると、強力な方法でトランスコード、再ストリーミング、WebRTC の機能を強化することができます。

結論

Mozilla の共同創設者である Brandan Eich は WebRTC を「オープンで邪魔されない Web を求める長い戦争の新たな最前線」と表現しましたが、WebRTC は、ブラウザベースのストリーミングとリアルタイムの双方向性を組み合わせています。フリーでオープンなフレームワークは、小規模なビデオベースの環境に最適です。また、大規模な配信や追加のストリーミング機能が必要な場合は、Wowza の技術は必要なサポートを提供します。

Resources: HLS (HTTP ライブストリーミング) とは？

Wed, 28 Sep 2022 00:00:00 +0900

この記事は、当社パートナーの Wowza Media Systems の記事 What Is HLS (HTTP Live Streaming)? [Update] の翻訳記事です。

Adobe Flash は 2020 年に最終的に廃止されました。そのため、Apple の HTTP ライブストリーミング (HLS) プロトコルがストリーミングビデオをユーザーに配信するための推奨される方法になりました。 HTTP ライブストリーミング (HLS) とは？どのように機能するか？少し長い記事になりますが、これから HTTP ライブストリーミング (HLS) プロトコルの詳細について説明します。

HLSとは？

HLS (HTTP Live Streaming) は、ビデオおよびオーディオデータをメディアサーバーから視聴者の画面に転送するためのアダプティブ HTTP ベースのストリーミング形式です。スマートフォンのアプリでライブストリームを視聴している場合でも、スマート TV でオンデマンドコンテンツを視聴している場合でも、HLS ストリーミングを使用している可能性があります。特に、Apple デバイスを使用している場合に HLS ストリーミングが使われている可能性があります。

HLS を使用すると、ビデオとオーディオのコンテンツが一連のチャンク (断片) に分割され、圧縮されて配信され、HTTP 経由でエンドユーザーのデバイスに送信されます。視聴者は、バックグラウンドですべてが進行しているにもかかわらず、スムースなストリームの再生を享受することができます. MPEG-DASH 等の技術は、HLS と同様の方法でストリームを配信しますが、あまり広範囲で使用されていません。

Wowza の 2021 年のビデオストリーミングレイテンシレポートでは、レポートの回答者の 70% 以上がコンテンツ配信に HLS プロトコルを使用していると回答しています。その他の代替プロトコルに対する HLS の人気は、プレイヤーでの再生の互換性とエクスペリエンス品質のおかげです。これは、すべての Mac、Android、Microsoft、および Linux デバイスが、HLS を使用して配信されたストリームを再生できるためです。

HLS を使用すると、コンテンツディストリビューターは、グローバルな配信のためにコンテンツ配信ネットワーク (CDN) に依存しつつ、幅広いデバイスで優れた視聴体験を保証することができます。従来では、スケールと品質を保つことによって迅速な配信を犠牲にしてきましたが、Apple が Low-Latency HLS (低遅延 HLS) をリリースしたことで、すべてが変わりました。

HLS は Apple 独自の技術ですが、技術仕様は Internet Engineering Task Force (IETF) を通じて公開されています。 Apple は定期的に技術仕様を更新し、パッケージャーとクライアントが互換性を維持できるようにしています。

訳注: HLS (HTTP Live Streaming) は、2017年 8月に正式な RFC (Request For Comment) 8216 として採択されています。また、Apple は、最新仕様である第2版をドラフト仕様として公開し、定期的に更新しています。

Apple HLS スナップショット

項目	説明
まとめ	HLS (HTTP Live Streaming) は、スケーラビリティとアダプティブビットレートストリーミングのために HTTP 技術を活用したライブおよびオンデマンドストリーミングコンテンツを配信するために開発されたプロトコルです
特徴	字幕早送りと巻き戻しフォールバックの代替手段タイムメタデータのサポート広告挿入コンテンツ保護
長所	ユビキタスにサポート視聴者のデバイスとインターネット速度に適応信頼性スケーラビリティ
短所	本質的に低遅延ではない Apple 独自の技術多くの場合、Transmuxing (トランスマックス) が必要

HLS (HTTP Live Streaming) の歴史

2009 年 5 月: HLS プロトコルの初期リリース
2015 年 1 月: Microsoft が Windows 10 での HLS のネイティブサポートを発表
2016 年 6 月: Apple が fMP4 形式のサポートを発表
2019 年 6 月: Apple が Low-Latency HLS 拡張機能の仕様を発表
2019 年 11 月: Wowza は、Wowza Streaming Engine 4.7.8 リリースで Apple Low-Latency HLS のサポートを発表
2020 年 5 月: Low-Latency HLS (低遅延 HLS) 仕様が包括的な HLS 標準に組み込まれた

訳注: HLS (HTTP Live Streaming) は、2017年 8月に正式な RFC (Request For Comment) 8216 として採択されています。また、Apple は、最新仕様である第2版をドラフト仕様として公開し、定期的に更新しています。

HLS ストリーミングはどのように機能するか？

訳注: この例では、カメラのライブ映像の入力をエンコーダーで RTMP エンコードを行い、Wowza Streaming Engine などのメディアサーバーを使って、RTMP 方式で入力されたストリームを HLS にパッケージ化し (プロトコルの形式の変換を行い)、エンドユーザーに向けて、HLS ストリーミング方式で配信しています。

一般的な RTMP から HLS へのワークフロー

HLS ビデオストリームは、情報の連続した流れとして配信されるのではなく、データのセグメント (チャンクまたはパケットとも呼ばれます) に分割されます。従来のストリーム配信方法からの脱却により、高品質のストリームをより多くの視聴者に届けることができるようになりました。とはいえ、HLS ストリーミングの方式では遅延も大きくなるため、ほとんどのコンテンツディストリビューターは RTMP (リアルタイムメッセージングプロトコル) を使用して入力されたストリーミングコンテンツをエンコードし、メディアサーバーに到達したら HLS 配信用にパッケージ化します。

アダプティブビットレートストリーミングのトランスコーディング

小さな画面のデバイスの視聴者やネットワーク接続状態の悪い視聴者を含め、視聴しているすべての人に対して可能な限り最高品質のストリームを配信するために、HLS ストリーミングは解像度を各個人の状況に動的に適応させます。アダプティブビットレートストリーミングと呼ばれるこの機能により、(ストリームの) ブロードキャスターは、優れたネットワーク帯域幅と処理能力を備えたユーザーに高品質のストリームを配信できると同時に、ネットワーク帯域幅と処理能力が欠けているユーザーにも対応することができます。

1 つのビットレート (訳注: 1 つのビットレートと解像度) で 1 つのライブストリームを作成するのではなく、トランスコーダー (通常はメディアサーバーに配置) を使用して、異なるビットレートと解像度で複数のストリームを生成します。次に、サーバーは、視聴者の画面と接続速度に応じて可能な限り最高の (訳注: ビットレートと) 解像度のストリームを送信します。

1 つのストリームの複数のレンディションを作成すると、(訳注: プレイヤーで再生中の) バッファリングやストリームの再生中断を防ぐことができます。さらに、視聴者の信号強度が 2 本のバーから 3 本のバーに変わると、再生ストリームは動的に調整され、サーバーはより優れたレンディションを提供します。

訳注: 「レンディション」とは、同じストリームの異なる解像度と異なるビットレートの組み合わせのバリアントを意味します

配信とスケーリング

Flash Player と組み合わせて使用される RTMP プロトコルとは異なり、HLS は、通常の Web サーバーを使用して、グローバルなコンテンツ配信ネットワーク (CDN) を経由することで、簡単に配信をスケールすることができます。 HTTP サーバーのネットワークをまたいでワークロードを共有することにより、CDN は拡散された視聴者数の急増と予想を超えるライブ視聴者数に対応することができます。 CDN は、オーディオとビデオのセグメントをキャッシュすることで、視聴者のエクスペリエンスの向上にも役立ちます。

HLS と比較すると、RTMP は専用のストリーミングサーバーを使用する必要があるため、(訳注: スケールした配信のためには)　展開するリソースが多くなります。

HTTP ライブストリーミングツールとサービス

HLS ストリーミングサーバー

前述のように、ほとんどのコンテンツディストリビューターはストリーミングサーバーを使用して、RTMP、WebRTC、または SRT などのストリーミングプロトコルで入力されたコンテンツを取り込み、ストリーミングサーバーに到達したら HLS 形式を使用してビデオ (ストリーム) をパッケージ化します。ビデオ (ストリーム) をその他の形式 (MPEG-DASH など) で追加で配信して、さまざまなデバイスの視聴者がコンテンツを確実に視聴できるようにすることも賢明です。 Wowza Video のようなクラウドベースのサービスや、Wowza Streaming Engine のようなストリーミングサーバーソフトウェアは、このパッケージ化の変換プロセスやアダプティブビットレート配信のためのストリームのトランスコーディングの実現には不可欠です。

コンテンツ配信ネットワーク (CDN)

コンテンツ配信ネットワーク (CDN) は、世界中のサーバーに接続することで、ビデオストリームを配信元からエンドユーザーに配信するのにかかる時間を短縮するスーパーハイウェイ (超高速道路) を作り出します。CDN は、多数の視聴者または地理的に分散した地域に向けてストリーミングするすべての人にとって、信頼性の高いコンテンツ配信を実現するのに不可欠です。 Wowza Video プラットフォームには、ライブストリームの配信をスケーリングするための統合 CDN が含まれています。さらに、Wowza Streaming Engine サブスクリプションのアドオンストリームターゲットとして Wowza CDN を提供しています。 Akamai, Fastly, Microsoft Azure が提供する CDN も HLS ストリーミングの CDN の優れたオプションです。これらはすべて、Wowza の製品ポートフォリオを使用してアドオンストリームターゲットとして利用することができます。

HTML5 プレーヤー

最後に、視聴者には、互換性のあるデバイス、または、HTML5 プレーヤーが必要となります。 HLS は、Adobe Flash の衰退を受けてデファクトスタンダードになっています。つまり、ほとんどのデバイスとブラウザーには、既にこの HLS 再生の機能が組み込まれています。最高の HTML5 ビデオプレーヤーのリストについては、このブログ記事をご覧ください。

HLS ストリーミングの技術概要

HLS の仕組みの基本的な概要はわかりましたが、詳細はどうでしょうか。エンコーディング要件からセグメントのサイズまで、ここから掘り下げて見ていきましょう。

サポートするオーディオコーデック: AAC-LC, HE-AAC+ v1 & v2, xHE-AAC, Apple Lossless, FLAC
サポートするビデオコーデック: H.265, H.264
再生の互換性: 良好 (すべての Google Chrome ブラウザー、Android、Linux、Microsoft、および MacOS デバイス、いくつかのセットトップボックス、スマート TV、およびその他のプレーヤー)
利点: アダプティブビットレート、信頼性が高く、広範囲のデバイスでのサポート
欠点: 低遅延よりもエクスペリエンスの質を優先
遅延 (レイテンシー): HLS は従来 6 ～ 30 秒の遅延で配信を提供していましたが、現在、低遅延 HLS 拡張機能が HLS の機能セットとして組み込まれており、2 秒未満の遅延を提供することが約束されている

UDP 対 TCP

ほとんどすべての HTTP アプリケーションは、伝送制御プロトコル (TCP) の上で実行されます。TCP は、信頼性が高く慎重にデータ転送を行うよう設計されたトランスポートレベルのプロトコルです。HTTP ベースの HLS プロトコルも同様に TCP 上で実行されます。これにより、UDP ベースのワークフローよりも高い品質が保証されます。

正確な配信が優先されるため、TCP の欠点の 1 つは速度です。しかし、HLS は、以下で説明する Low-Latency HLS (低遅延 HLS) 拡張機能によってこれを克服します。

コンテナ形式

MPEG-4 Part 14 (MP4) コンテナー形式を使用するほとんどの HTTP ベースのプロトコルとは異なり、HLS は当初、MPEG-2 トランスポートストリーム (TS) コンテナー形式の使用を指定していました。これは、Apple がフラグメント化された MP4 (fMP4) 形式のサポートを発表した 2016 年に変更されました。現在、fMP4 は (MPEG-DASH および Microsoft Smooth Streaming を含む) すべての HTTP ベースのストリーミングで推奨される形式です。これらのビデオファイルには、通常、AVC/H.264 でエンコードされたビデオと AAC でエンコードされたオーディオが含まれます。

エンコード要件

Apple は、HLS でストリーミングする場合のビットレートバリアントの典型的なセットの例として、以下のエンコードターゲットを提供しています。 HLS ストリームの構成方法の詳細については、Apple の推奨事項を確認してください。

HLS エンコードターゲットの例 :

解像度 (16:9 アスペクト比)	H.264/AVC	Framerate
416 x 234	145	≤30 fps
640 x 360	365	≤30 fps
768 x 432	730	≤30 fps
768 x 432	1,100	≤30 fps
960 x 540	2,000	ソースと同じ
1280 x 720	3,000	ソースと同じ
1280 x 720	4,500	ソースと同じ
1920 x 1080	6,000	ソースと同じ
1920 x 1080	7,800	ソースと同じ

.M3U8 マニフェストファイル

HLS ビデオセグメントは、ビデオプレーヤーが (ストリームの) データの編成方法を理解できるように、メディアプレイリストの中でインデックス化されます。マスター .m3u8 プレイリストファイルも作成する必要があります (これをインデックスのインデックスと考えてください)。これは、プレイヤーにバリアント固有のプレイリスト間で切り替える方法を指示するためです。これは、マニフェストファイルとも呼ばれます。ストリームを配信するには、.m3u8 を参照する URL を Web ページに埋め込むか、.m3u8 ファイルをダウンロードするアプリケーションを作成することで、コンテンツを配信できます。

訳注: バリアントは、この記事内では、レンディションとも呼ばれています。ビデオプレイヤーを実行するクライアントデバイスの接続ネットワークの帯域幅や処理能力に応じてレンディション固有のプレイリストを切り替えることで、ビデオプレイヤーが再生するレンディション (解像度やビットレート) を切り替え、アダプティブストリーミングを実現します。

セグメントのサイズとレイテンシ

HLS ライブストリームの遅延 (レイテンシ) はセグメントのサイズと密接に関連しており、通常は 10 ～ 45 秒の範囲内になります。

具体的には、次のようになります: HLS 経由で配信されるビデオストリームは、メディアサーバーでチャンク (訳注: セグメント) に分割されます。視聴者が再生をクリックすると、ビデオの再生が開始される前にデバイスがこれらのチャンクを 3 つ読み込む必要があります。セグメント化された配信により、プレーヤーは利用可能なリソースに応じて異なるレンディション間を切り替えることができ、同時に再生時のバッファリングやその他の再生の中断を減らすこともできます。

2016 年まで、Apple は HLS に 10 秒のセグメントを使用することを推奨していました。また、HLS の仕様では、再生を開始する前に 3 つのセグメントをロードする必要があるとしていました。 10 秒の推奨事項に従うと、(エンコーディング、トランスコーディングなどによって引き起こされるラグも考慮しないとしても) 30 秒の遅延から開始することになります。 Apple は最終的にデフォルトのセグメントサイズを 6 秒に減らしましたが、それでも “ライブ” ストリームがほぼ 20 秒遅れる可能性があることを意味していました。

訳注: 再生の開始前に、(セグメントサイズ x 3) の秒分のコンテンツがクライアントデバイスに配信されるのを待つことになるため、10秒セグメントの場合は 30秒の遅延、6秒セグメントの場合は 18秒の遅延が少なくとも発生する (エンド・ツー・エンドのライブワークフローの中のその他の遅延を考慮しなくても)

この遅延を減らす一般的な方法は、セグメントのサイズを小さくすることです。これは、低遅延の “チューニングされた” HLS と呼ばれます。チャンク (訳注: セグメント) が短いほど、ダウンロード時間が短縮され、速度が向上します。しかし、それだけが HLS による高速ストリーミングへの道ではありません。 2019 年、Apple は Apple Low-Latency HLS (低遅延 HLS) と呼ばれる拡張機能の仕様を発表しました。最近では、この拡張機能が機能セットとして包括的な HLS 標準に組み込まれています。 Low-Latency HLS は 3 秒以下の遅延を約束します。

訳注: 単純にセグメントサイズを 1秒やそれ以下に構成変更したとても、同じ時間のストリームのセグメントのリクエスト数が増えたり、プレイリスト (マニフェスト) のサイズが大きくなったりしますので、単純な方法では解決するわけではありませんでした。これらの点が、2019年に Apple が低遅延のために Low-Latency HLS という新しいアプローチを考案した背景になります。

Apple 低遅延 HLS (Low-latency HLS)

Apple は Low-Latency HLS 拡張機能を設計して、レイテンシを大幅に削減しました。この新しい Low-Latency HLS のプロトコルはもともと HTTP/2 PUSH 配信に依存するよう設計されていましたが、この要件は削除されました。さらに、Internet Engineering Task Force (IETF) は、最近、Low-Latency HLS 拡張機能を機能セットとして従来の HLS に組み込みました。これには 2 つの重要性があります。新しい技術をさらに標準化されるという点、および、技術を提供する企業が (標準仕様として) サポートを追加できるようにするという点です。

再生の互換性: 低遅延 HLS 用に最適化されていないプレーヤーは、標準 (高レイテンシ) HLS 動作にフォールバックできる
利点: 低遅延が HTTP ベースのストリーミングに対応
欠点: 新しい仕様としてベンダーはまだサポートを実装中
遅延 (レイテンシ): 3 秒以下

Apple Low-Latency HLS を Periscope が作成したオープンソースの Low-Latency HLS ソリューション (LHLS) と混同しないよう注意してください。両者の技術の主な違いは配信方法にあります。 Apple の拡張機能とは異なり、Periscope が提唱する仕様では Chunked Transfer Encoding (チャンク転送エンコーディング) を使用します。(LHLS の提唱に関わった) ビデオ開発者コミュニティは、Apple の標準仕様を支持して、このオープンソースの代替手段を放棄しました。

昨年末、Wowza Streaming Engine ソフトウェアに Low-Latency HLS のサポートを追加しました。Wowza は、アーリーアダプターとして、この新しいテクノロジに対応する開発を続けており、製品ポートフォリオ全体にこのサポートを拡張するために取り組んでいます。

訳注: 本記事は 2022年の記事になります。

HLS の代替手段

ラストマイル配信の主な代替となるストリーミングプロトコルは、MPEG-DASH と WebRTC です。 DASH は機能的には HLS と非常に似ていますが、Apple デバイス全体でのサポートが不足しています。一方で、WebRTC はリアルタイム配信に関してはまったく別物であり、(配信規模の) スケールを考慮して設計されていません。

HLS と MPEG-DASH の比較

独自仕様と国際仕様: HLS は Apple 独自のものですが、MPEG-DASH は MPEG によって定義されたオープンスタンダードの仕様です
再生の互換性: HLS は Apple が業界全体に与える多大な影響力により、MPEG-DASH よりも広くサポートされています
コーデック要件: HLS は特定のビデオコーデック (H.265、H.265) と特定のオーディオコーデック (詳細はこちら ) の使用を指定しますが、MPEG-DASH はコーデックに依存しません: これにより、より高度なコーデックが利用される場合、より低いビットレートでより高品質のブロードキャストが可能になります
コンテナー形式: HLS は従来 MPEG-2 トランスポートストリームコンテナー形式 (.ts (MPEG-TS)) を使用してきましたが、MPEG-DASH は MP4 形式 (.mp4) を使用していました
遅延: どちらのプロトコルも配信遅延の点で伝統的に遅れをとっていましたが、新しいアプローチはこれを変えようとしています: MPEG-DASH の場合、これは Common Media Application Format (CMAF) の形式をとることで実現できますが、Apple は現在 Low-Latency HLS 拡張機能を提供します

訳注: Low-Latency MPEG-DASH では CMAF 形式のセグメントと Chunked Transfer Encoding (チャック転送エンコーディング) を活用することで低遅延でセグメントを転送することができます

	Apple HLS	MPEG-DASH
再生の互換性	ほぼすべてのデバイス、アプリ、ブラウザ	Safari、Apple TV、iOS を除くほとんどのブラウザ、アプリ、デバイス
トランスポートプロトコル	TCP	TCP
対応コーデック	ビデオ：H.264、H.265, オーディオ: AAC-LC、HE-AAC+ v1 & v2、xHE-AAC、Apple Lossless、FLAC	オーディオとビデオの両方でコーデックに依存しない
コンテナ形式	従来は MPEG-2 または MPEG-TS を使用していた	従来は MP4/.mp4 を使用していた
遅延	低遅延 HLS のレイテンシ: 約 2 秒, 低遅延なしの HLS: 6 ～ 30 秒	Low-Latency DASH または CMAF あり: 約 2 秒, 低遅延なしの DASH: 6 ～ 30 秒
開発者	HLS は Apple 独自のプロトコル	MPEG は DASH をオープンソースとして作成しました
セキュリティ	Common Encryption (CENC) と fmp4 をサポート, Apple Fairplay を DRM と暗号化に使用	Common Encryption (CENC) と fmp4 をサポート, Microsoft の PlayReady と Google Widevine を DRM に使用
広告	VPAID および VAST を使用した広告挿入をサポート	VPAID および VAST を使用した広告挿入をサポート

HLS と WebRTC の比較

遅延: WebRTC ストリームは、低遅延 HLS をはるかに凌ぐ 500 ミリ秒という猛烈な速度でインターネット上で転送されます
プロプライエタリ vs. オープンソース: HLS は Apple の独自技術ですが、WebRTC はオープンソースの技術です
再生の互換性: WebRTC はほとんどのブラウザーで機能するために追加のプラグインやソフトウェアを必要としませんが、HLS は多くのモバイルデバイスでより広くサポートされています
スケーラビリティ: 配信規模ためのスケーラビリティは HLS の特徴ですが、WebRTC については同じことは言えません: Wowza のようなストリーミングプラットフォームがなければ、WebRTC は小さなチャットベースの環境に限定されます
品質: WebRTC では品質よりもリアルタイム配信が優先されます

HLS と RTMP の比較

ファーストマイル vs. ラストマイル: RTMP は、入力のための技術として最も一般的に使用され、ビデオストリームをエンコーダからメディアサーバーに転送する際に利用されます。一方、HLS はエンドユーザーデバイスへの配信と再生に使用されます。
再生の互換性: HLS はマルチデバイスで十分にサポートされていますが、RTMP は iOS、Android、ほとんどのブラウザー、およびほとんどの埋め込み可能なプレーヤーでは受け入れられなくなりました
仕様開発の廃止: RTMP は Adobe によって更新またはサポートされなくなりましたが、Apple は HLS の開発を続けています
アダプティブビットレート: RTMP はアダプティブビットレートストリーミング用に設計されていません。そのため、アダプティブビットレートストリーミングが一般的になると、すぐに HLS がその役割を引き継ぎました
スケーラビリティ: HLS のような HTTP ベースのストリーミングプロトコルは通常の古い Web サーバーを使用することができますが、RTMP では専用のストリーミングサーバーを使用する必要があります
遅延: RTMP は常に HLS よりもはるかに速いビデオ配信速度 (訳注: 低い遅延) で配信することができます。とはいえ、Low-Latency HLS 拡張機能は、この遅延のギャップを埋めようとしています

HLS プロトコルを使用しないユースケース

Web 会議、カメラやドローンのリアルタイムデバイス制御、状況認識など、1 秒未満の配信が必要なユースケースでは、WebRTC (Web Real-Time Communications) のようなプロトコルが必要です。 Apple Low-Latency HLS でさえ、これらのシナリオでは受け入れられない固有の遅延が発生します。

HLS プロトコルを使用するユースケース

HLS は現在、メディアストリーミングで最も広く使用されているプロトコルであるため、大部分のブロードキャストにとって安全な方法です。インターネットに接続された (様々な) デバイスにストリーミングする場合は、少なくともこのプロトコルを考慮する必要があります。特に、品質が重要なライブイベントやスポーツを放送する場合はそうです。遅延は考慮する価値がありますが、Apple Low-Latency HLS 機能セットのサポートが実装されると、2 秒未満の配信がより一般的になるはずです。これにより、インタラクティブストリーミング、オンラインギャンブル、e-ゲームなどに適したものになります。

訳注: ギャンブルやインタラクティブストリーミングであっても、1秒以下の遅延が確実に必要となるシナリオでは、HLS が適さないケースもあります。詳細について、ご相談がありましたら、LiveInstantly 当社までご連絡ください。

モバイルデバイスにストリーミングする場合、HLS は必須です。携帯電話の世界で Apple iPhone が果たす役割を考えてみてください。多くのスマート TV、セットトップボックス、および、様々なプレーヤーもデフォルトで HLS に対応しているため、リビングルームのエンドユーザーに向けて配信しようとする放送局 (ストリームサービス提供者) も HLS を検討する必要があります。そして、最後に、Flash への配信にまだ RTMP を使用しているサービスは、切り替える時が来ています。

とはいえ、可能な限り多くの視聴者にリーチするには、追加のビデオフォーマット (訳注: ストリーミングプロトコル) に対応することから始めます。ストリームをさまざまな形式にトランスコードすることで、デバイスに関係なくビデオ配信のスケーラビリティを確保できます。

Wowza Video を使用すると、フルマネージドサービスを介してストリームをトランスコードおよび配信できます。または、Wowza Streaming Engine は、ストリーミングインフラストラクチャを企業内 (訳注: 企業のオンプレミスや企業のクラウドサブスクリプション内) に維持したい場合に適している可能性があります。

Wowza による HLS ストリーミング

統合されたビデオプラットフォームを使用して、遅延を削減した HLS ストリームのブロードキャストを検討していますか？

Wowza Video があなたをサポートします。

メディアサーバーを使用して単純な RTMP から HLS へのワークフローの構成を検討していますか？

そのためには、Wowza Streaming Engine が最適な手段です。

HLS ストリーミングのニーズが何であれ、私たちは必ずソリューションを提供します。 Wowza を使用した HLS ストリーミングの詳細については、記事内のチュートリアルをご覧ください。

訳注: チュートリアルについては、オリジナルの記事内のチュートリアルビデオを参照ください。詳細についてご不明点がございましたら、サポートいたしますのでご連絡ください。

Resources: CMAF とは？

Thu, 04 Aug 2022 00:00:00 +0900

この記事は、当社パートナーの Wowza Media Systems の記事 What Is CMAF? (Update) の翻訳記事です。この記事では、HLS ストリーミングプロトコルを詳しく説明します。

質の高い視聴体験を維持しながらビデオ配信の遅延を減らすという戦いは、適切に名付けられた Common Media Application Format (CMAF) の広範囲な採用につながってきました。このプロトコルは、業界全体で効率化を進め、配信の遅延を短縮するための協調的な努力の成果です。 Apple の最近の提案がこの取り組みを覆す恐れがあるにもかかわらず、CMAF は、ストリーミングプロセスの単純化と高速化を求めるすべての人々にとって、依然として多くの可能性を秘めています。

訳注: 「Apple の最近の提案がこの取り組みを覆す恐れがあるにもかかわらず」は、低遅延 HLS の提案を意味すると考えられますが。低遅延という仕組みについては、この CMAF が想定しているものとは別のアプローチになりますが、Apple は HLS の CMAFフォーマットをサポートしています。

では、CMAF とは正確にはどのようなものであり、ストリーミングの改善にどのように役立つのでしょうか?

CMAFとは？

Common Media Application Format (CMAF) は、様々な形式の HTTP ベースのメディアをパッケージ化して配信するためのフォーマット規格で、比較的新しい仕様です。この規格は、HLS プロトコルと MPEG-DASH プロトコルの両方でデータを統一されたトランスポートコンテナーファイルにパッケージ化することにより、再生デバイスへのメディアの配信を単純化します。また、チャンクエンコーディングとチャンク転送エンコーディングを使って遅延を低くします。これにより、必要なストレージが削減され、ビデオの遅延によるビジネス損失のリスクが軽減されるため、ほとんどの企業でコストが削減されます。

CMAF 自体はプロトコルではなく、HLS や MPEG-DASH などのプロトコルで動作する単一のアプローチでビデオストリーミングを実現するコンテナであり、一連の標準規格である、ということに注目してください。このように、CMAF ストリーミングの最大の成果は、ストリーミング市場全体を改善するための業界全体の取り組みを表すという点で、技術的というよりも政治的なものと言えるでしょう。

CMAFスナップショット


目的	ビデオストリームに共通のメディア形式を使用することで、コスト、複雑さ、遅延を削減します
目標	同じコンテンツの複数のコピーのエンコードとストレージに関する投資を削減しますワークフローを単純化し、CDN の効率を向上させますチャンクエンコードおよびチャンク転送エンコーディング CMAF により、ビデオの遅延を削減します
タイムライン	2016 年 2 月: Apple と Microsoft は、Moving Pictures Expert Group (MPEG) に CMAF を提案しました 2016 年 6 月: Apple は fMP4 形式のサポートを発表しました 2017年7月：仕様確定 2018 年 1 月: CMAF 標準規格が正式に公開されました

CMAFが必要な理由

競合するコーデック、プロトコル、メディア形式、および、デバイスにより、すでに複雑となっているライブストリーミングの世界はますます複雑になっています。さらに頭痛の種になることは、様々なメディア形式を使用するとストリーミングの遅延とコストが増加することです。

ストリームのそれぞれのレンディションに対して単一のフォーマットで実現できることであるのに、代わりに同じコンテンツの複数のコピーを作成することをコンテンツ配信者に必要とさせているのです。言い換えれば、ストリーミング業界は、ビデオ配信を不必要に高価で遅延を増やしていると言えます。

.ts, .mp4, .wma, .mpeg, .mov などの様々なコンテナーファイルの数だけでも膨大です。しかし、競合するテクノロジープロバイダーがすべての再生プラットフォームで標準のストリーミングフォーマットで合意ができたらどうでしょうか? それが Common Media Application Format (CMAF) です。

CMAF は、単一アプローチのエンコーディング、パッケージング、および、ストレージの理想的な世界に私たちを近づけることができます。さらに、エンド・ツー・エンドの配信時間の遅延を 30 ～ 45 秒から 3 秒未満に短縮できるることが約束されています。

なぜ、どのように、どのくらい、CMAF によってこれらの利点が実現可能となるのでしょうか？

以下に詳細を説明しますので、引き続き、読み進めてください。

CMAF に至るまで

当時に戻ると、RTMP (Real-Time-Messaging Protocol) は、インターネット経由でビデオをストリーミングするための主要な方法でした。この独自プロトコルにより、ストリーミングビデオ配信が可能になりましたが、ファイアウォールを経由して配信する場合に問題が発生しました。

多くのブラウザーが Flash のサポートを段階的に廃止し始めたため、業界はアダプティブビットレートストリーミングを使った HTTP ベース (Hypertext Transfer Protocol) ベースの技術に移行しました。 Apple は、Apple HLS (HTTP Live Streaming) というアダプティブビットレートストリーミングの形をとりました。一方、MPEG-DASH (Dynamic Adaptive Streaming over HTTP) は、アダプティブビットレートストリーミングの国際標準として確立しました。

しかし、ストリーミングのプロトコルが異なれば、ファイルコンテナーも異なります。 HLS は .ts 形式の使用を指定しますが、MPEG-DASH は ISOBMFF 仕様に基づく .mp4 コンテナーをほぼ一様に使用します。

訳注: ISOBMFF = ISO Base Media File Format: MPEG-4 Part 12 (ISO/IEC 14496-12) で規定されている仕様

多くの略語があり (混乱するかもしれませんが)、ここで重要なのは、テクノロジープロバイダーがそれぞれのストリーミングのために個別のコンテナーをサポートしていることです。これは、現在利用されている無数のデバイスでの再生に影響を与えます。

具体的にどんな問題でしょうか？ Apple デバイスと Microsoft デバイスの両方のエンドユーザーに配信したいコンテンツ配信者は、同じオーディオデータとビデオデータを 2 回エンコードして保存する必要があります。実際に、ユーザーは iPhone, スマート TV, Xbox、PC のストリームにアクセスしているため、この問題は明らかでした。

Akamai の言葉を借りれば:

これらの重複するファイルは、同じコンテンツを表しているにもかかわらず、パッケージ化に 2 倍のコストがかかり、オリジンのストレージに保存するのに 2 倍のコストがかかり、Akamai エッジキャッシュでキャッシングスペースをめぐって互いに競合するため、(本来) 効率的に配信可能であるコンテンツの配信効率を低下させます (以下注)

(注): 重複するストレージとエンコードのコストの解決手段として Streaming Media がWowza を推奨していることに注目してください:

Wowza Streaming Engine のような製品 […] を使用して、コンテンツを MP4 ファイルから DASH, HLS, Smooth Streaming 形式に動的にパッケージ化することで、ストレージとエンコードのコストの増加を回避できます

CMAFの登場

CMAFは企業間のコラボレーションから生まれました。 2016 年 2 月、Apple と Microsoft は、Moving Pictures Expert Group (MPEG) に提案を持ちかけました。 Common Media Application Format (CMAF) と呼ばれる新しい標準を確立することで、彼ら 2 つの組織が協力してビデオをオンラインで配信する際の複雑さを軽減するであろうことを意味しました。

この活動のプレイヤーとなる企業は、素早い対応で動きました。 Apple は、2016 年 6 月 15 日に、断片化された MP4 のサポートを HLS に追加すると発表しました。これは、Apple がビデオストリームに .mp4 配信を使用できるようにすることを意味しました。これは、Microsoft が既に使用しているまさにそのコンテナーです。

2017 年 7 月までに、共同開発者は CMAF の仕様を最終決定し、そして、2018 年 1 月に標準が公開されました。

ビデオ配信のための単一のコンテナーでエンコード、パッケージ化、および、キャッシングすることの利点は言うまでもありません。しかし、CMAF は複雑さを軽減するだけではありません。何年も前に RTMP から手を引いた後でも、HTTP ベースのビデオ配信には、視聴者が要求するリアルタイム配信オプションがまだありません。

CMAF も配信遅延をも改善できるのでしょうか？チャンクエンコーディングとチャンク転送エンコーディングにより、新しい仕様はまさに遅延の削減を行うように設計されました。

CMAFの仕組み

単一フォーマット:

CMAF 仕様が確立する以前は、Apple の HLS プロトコルは MPEG トランスポートストリームコンテナフォーマット、つまり .ts (MPEG-TS) を使用していました。 MPEG-DASH などの他の HTTP ベースのプロトコルは、断片化された MP4 形式、つまり .mp4 (fMP4) を使用していました。

Microsoft と Apple は、現在、標準化されたトランスポートコンテナー (断片化された MP4 の形式の ISOBMFF) を使用して、HLS および MPEG-DASH プロトコル全体で視聴者に配信することで合意しています。理論的には、これは、コンテンツ配信者が .mp4 コンテナーのみを使用してコンテンツを配信できることを意味します。

チャンクエンコーディング:

CMAF ストリーミングとは、チャンクエンコーディングとチャンク転送エンコーディングを使用して遅延を短縮するために、業界全体で相互に調整された取り組みを表します。このプロセスでは、ビデオをある設定された長さの小さなチャンクに分割し、エンコードが完了するとすぐに公開できるようにします。そうすれば、後のチャンクがまだエンコード処理されている間でも (その前にエンコード済みの) チャンクの配信を行うことができます。一度にすべてが来るのではなく、コースで食事をするようなものだと考えてください。すべての食事のプレートが “バッファリング” されるまで (訳注: 準備されるまで) 空腹で待つのではなく、キッチンで次のコースを準備している間、おいしい前菜を楽しむことができます。

ファイルの暗号化とデジタル著作権管理:

CMAF が対処しようとしていた様々なメディア形式の問題と同様に、業界全体に別の非互換性が存在します。それは、デジタル著作権管理 (DRM) とファイル暗号化です。複数の DRM (FairPlay、PlayReady、および Widevine) をサポートすることは、非互換の暗号化モードもサポートすることを意味します。

業界の関係者は、現在、共通暗号化 (CENC) と呼ばれるこの分野の標準を CMAF に適用することに合意していますが、標準化は一夜にして実現できるものではないことにも注意する必要があります。

CMAFとHLS

CMAF と HLS ストリーミングの違いを探る前に、まず HLS と低遅延 HLS について説明する必要があります。低遅延 HLS は CMAF の出現後に Apple によって開発されたものであり、CMAF が業界全体の標準になるという仮定に異議を唱えているようです。

訳注: Apple がフォーマットとしての CMAF には異議を唱えているようには見えませんが、CMAF フォーマットが想定する低遅延ストリーミングの方式には異議を唱えているように見えます。

HLS (HTTP ライブストリーミング) は Apple ベースのプロトコルであり、歴史的に遅延の問題よりもストリームの信頼性を優先しており、約 5 ～ 20 秒の遅延で配信することができます。これは、iPhone のライブストリーミング再生の問題に対する Apple の答えであり、最小限のバッファリングで視聴者のエクスペリエンスを改善することに成功しました。 CMAF は “cbcs” または “cenc” で暗号化されたプレゼンテーションプロファイルの HLS と連携できます。暗号化されていない 3 番目のプレゼンテーションプロファイルはサポートされていません。

低遅延 HLS (Low-Latency HLS) は、遅延を大幅に削減する HLS のプロトコル拡張であり、CMAF と同じニーズの多くに対応します。(HLS が)遅延を削減するための取り組みとして CMAF フォーマットを既に対応していたのに、なぜ Apple が HLS ストリーミングプロトコルを拡張する必要性を感じたのかは少し謎であり、Apple が CMAF の標準化の取り組みにどれだけコミットしているか疑問に思う人もいるでしょう。

これらすべてを念頭に置いて、HLS を使用する場合のオプションは 3 つあります:

高い信頼性と遅延を兼ね備えた従来の HLS
遅延を改善するための低遅延 HLS (Low-Latency HLS) プロトコル拡張を使用した HLS
遅延を改善しコンテナーファイルを標準化する CMAF 形式の HLS

どれくらいの遅延の違いがあるのでしょうか？

低遅延 HLS と CMAF の範囲は少し異なります。通常、低遅延 HLS は約 2 ～ 8 秒の遅延で配信が実行されます。 CMAF は約 2 ～ 5 秒の遅延で配信が実行されると言われています。いずれにせよ、これらはかなり互角です。ただし、CMAF には、標準化されたコンテナーファイル (.fmp4) という追加の利点があり、これが広く採用されることで、すべてのストレージコストが削減されます。

CMAFとRTMP

RTMP (Real-Time Messaging Protocol) は、もともと Adobe の Flash プレーヤーと連携するために Macromedia によって開発され、ストリーミングテクノロジの最前線に位置付けられていました。しかし、その後、HTTP ベースの技術が支持され、脇に追いやられました。

確かに、RTMP は引き続き使用できますが、ビデオの入力取り込みとしてのみ機能し、実際にビデオの再生のためのオプションではなくなりました。また、より高品質の視聴体験のためにスケーラブルにする最新の技術の最適化も不足しています。

とはいえ、約 5 秒のレイテンシーで、様々な企業がこのプロトコルを利用して、迅速かつ確実にストリーミングを実現してきました。

CMAF と WebRTC

では、CMAF とは反対側にある最先端の WebRTC (Web Real-Time Communications) プロトコルを見てみましょう。これは利用可能なオプションの中の最速のライブストリーミングオプションであり、簡単に使うことができます。 CMAF ストリーミングを低遅延と呼ぶ場合、WebRTC は 1 秒未満のレイテンシーの超低遅延 (ULL = Ultra Low Layency) と呼ぶことができます。また、WebRTC は、様々なネットワーク要件に簡単に適応でき、フリーで使うことができます。

では、WebRTC の利点をどのように達成するのでしょうか？ WebRTC は、プラグインを必要とせずに、ブラウザーとデバイス間のリアルタイムの音声、テキスト、ビデオによる通信を追加することができます。とはいえ、WebRTC は、ビデオ会議用に特別に設計されているため、簡単に大規模な視聴者に向けた配信のために拡張することはできません。ここで、Wowza のようなストリーミングプラットフォームが役に立ちます。 Wowza の大規模向けのリアルタイムストリーミングソリューションは、機能的には、スケーリングをサポートするワークフローを備えた WebRTC です。

CMAF まとめ

配信の遅延と複数のメディアファイルタイプのストレージに関連するコストを削減する最も簡単な方法の 1 つは、ビデオ配信を単純化することです。 CMAF の目標は 3 つでした。

コスト削減
ワークフローの複雑さを最小化
遅延を短縮

これらは達成されるでしょうか？おそらくそうでしょう。

CMAF は、ほとんどのエンドポイントにサービスを提供するためのサーバー効率を最適化するでしょう。また、最近のデモでは、この新しい代替手段によって 3 秒未満の遅延を実現することができています。

とはいえ、アップグレードされていない従来のデバイスとブラウザーでは、再生のために独自のコンテナーファイルが引き続き必要になります。別の言い方をすれば、可能な限り視聴者に配信し続けるには、CMAF がさかのぼって対処できないことに対する追加の調整 (およびコスト) が必要となります。

そこで Wowza の出番です。Wowza Streaming Engine は、MPEG-TS, Apple HLS, Adobe FTMP など、様々なフォーマットでのビデオ配信をサポートしています。CMAF 準拠デバイスの普及が拡大し続けているので、これによりビデオのスケーラビリティが保証されます。さらに、Wowza Streaming Engine は CMAF ストリーミングをサポートするようになり、ロードマップでは低遅延の最適化が行われる予定です。

また、簡単に利用できる CMS へのアクセスを含む、最適化されたソリューションをお探しの場合は、新しく改善された Wowza ビデオストリーミングプラットフォームをお試しください。

Resources: MPEG-DASHとは？: HTTP ベースの動的アダプティブストリーミング

Mon, 18 Apr 2022 00:00:00 +0900

この記事は、当社パートナーの Wowza Media Systems の記事 MPEG-DASH: Dynamic Adaptive Streaming Over HTTP Explained (Update) の翻訳記事です。この記事では、MPEG-DASH ストリーミングプロトコルを詳しく説明します。

COVID-19 のパンデミックにより、これまで以上に画面を見る時間が増えています。また、Netflix や YouTube でコンテンツを視聴している場合でも、MPEG-DASH プロトコルが何らかの役割を果たしている可能性があります。

では、MPEG-DASH とはどのような技術で、どのように機能するのでしょうか？

この記事ではそれらの質問のすべてをカバーします。

MPEG-DASHとは？

MPEG-DASH は、インターネット経由でメディアをストリーミングするための HTTP ベースの適応型 (アダプティブ) プロトコルです。この技術は、ライブおよびオンデマンドのビデオコンテンツのセグメントを Web サーバーから視聴者のデバイスに転送するために使用されます。

MPEG-DASH 標準とは？略語の頭字語をたどっていくとよいでしょう。

まず、MPEG です。Moving Pictures Expert Group (MPEG) がこの技術を開発しました。デジタルオーディオおよびビデオ規格の国際的権威として、彼らは Apple の HTTP ライブストリーミング (HLS) プロトコルに代わる業界標準のプロトコルを作成しようとしていました。

次に、DASH です。彼らは、新しいプロトコルの名前を DASH と名付けました。これは、Dynamic Adaptive Streaming over HTTP の略です。

なぜ、MPEG-DASH が必要なのでしょうか？ HLS と MPEG-DASH はどう違うのでしょうか？少し長い記事になりますが、これから MPEG-DASH プロトコルの詳細について説明します。

MPEG-DASH スナップショット

オーディオコーデック: コーデックに依存しない
ビデオコーデック: コーデックに依存しない
再生の互換性: 良い、しかし、最良ではない: HTML5 ビデオプレーヤーはすべての Android デバイスで再生可能; 2012年以降のほとんどのSamsung、Philips、Panasonic、および、Sony TV; Chrome、Safari、および Firefox ブラウザーでサポート; iOS と Apple TV は MPEG-DASH をサポートしない
利点: ベンダーに依存しないアダプティブビットレートの国際標準仕様である
欠点: iOS または Apple TV ではサポートされていない
遅延 (レイテンシー): 6 ～ 30 秒 (チャンク転送エンコーディングを介して調整または配信された場合にのみ、遅延 (レイテンシー) を下げることができます)
バリアントフォーマット: MPEG-DASH CENC (共通暗号化)

MPEG-DASH の仕組み: アダプティブビットレートストリーミング

もし視聴している番組がぼやけた映像からくっきりとフォーカスされた映像に数秒で調整されることに気づいたことがあるなら、アダプティブビットレート (ABR) ストリーミングについてよくご存じかもしれません。ストリーミングメディアを配信するこの方法では、高品質のビデオエンコーディングと低品質のビデオエンコーディングを切り替えることで、再生するコンテンツを視聴者の帯域幅容量に動的に適応させることができます。 Netflix、Hulu、YouTube のビデオサービスはすべて、まさにそれを実現するために MPEG-DASH 形式に使用しています。

多くの場合、アダプティブストリーミングでは、ビデオプラットフォームまたはサーバーを使用して 1 つのビデオソースを取り込み、それを複数の異なるレンディションにトランスコードします。様々なデバイスや接続速度でバッファレス再生が可能となるように、それらの複数のレンディションはサイズ (訳注: 解像度やビットレート) が異なます。このようにして、高ビットレート、高フレームレート、高解像度のストリームを、最も高度な環境を利用する視聴者向けに再生できます。また、画面が小さく機能や処理能力の不十分な視聴者には、同じビデオが低品質で再生されます。

レンディションは、連続したストリームとしてではなく、10 秒未満のセグメントの連続として配信されます。そうすることで、視聴者のインターネット速度が向上したり急降下したりすると、再生するストリームは、ビデオで提供されている解像度とビットレートの複数のオプションの中から自動的に調整されます。

アダプティブストリーミングを使用することで、MPEG-DASH 仕様は安定した視聴体験を提供しますが、個々のセグメントがダウンロードされるため、(再生の) 初期遅延も発生します。この問題に対する 1 つの対処方法は、セグメントサイズを小さくして遅延 (レイテンシ) をチューニングすることです。別の対処方法としては、以下で説明する Common Media Application Format (CMAF) という技術を含む方法になります。

MPEG-DASHの歴史

ストリーミングメディアの黎明期以来、競合する様々な技術がストリーミングプロトコルの最前線で互いに激しく争ってきました。ライバル関係で最も有名な企業や団体の技術には、Adobe の Real-Time Messaging Protocol (RTMP)、Apple の HTTP Live Streaming (HLS) プロトコル、および、MPEG-DASH が含まれます。

最初は RTMP があった

世紀の変わり目から話を始めると、当時は、まだダイヤルアップインターネットがありました。クールな子供たちはノキアの携帯電話で「スネーク」をプレイしていました。ビデオのストリーミングはまだ始まったばかりで、Netflix はまだ郵送による DVD の配信に力を入れていました。

当時は RTMP が主流でした。この独自プロトコルは、Adobe Flash Player での再生に、ビデオとオーディオのデータをインターネット経由ですばやく転送することができました。当時、Flash プラグインはインターネットブラウザの 98% をサポートしていたため、2010 年代初頭までは RTMP がライブストリーミングの主要な配信メカニズムとなっていました。

RTMP は、Adobe の技術を介してエンドユーザーに連続したデータストリームを送信することで、期待どおりに動作しました。今日の最も一般的な配信プロトコルとは異なり、専用のストリーミングサーバーと Flash プレーヤーが必要でした。

ご存知のように、Flash は廃止されてもう使われなくなりました。そして、スティーブ・ジョブズは、このプレイヤーの絶滅に重要な役割を果たしました。世界に iPhone を紹介した直後、彼は Flash をサポートしないという Apple の選択を擁護し、その独自性を批判しました。

HTTP ベースのアダプティブビットレートストリーミングの登場

RTMP はすぐに HTML5 ベースの技術に取って代わられました。この新しいカテゴリのストリーミングプロトコルは、従来の HTTP Web サーバーで構成されるコンテンツ配信ネットワーク (CDN) を利用して、チャンクベースのアダプティブビットレートメディアファイルを配信しました。

アダプティブストリーミングへの移行は、バッファリングとの戦いとキャッシュ効率の向上に一挙に役立ちました。しかし、RTMP が活躍していたスペースを埋めるために、多くの新しい独自のプロトコルがすぐに開発されました。Microsoft は 2008 年に Smooth Streaming を提供し、Apple は 2009 年に HLS を提供し、Adobe は 2010 年に 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 月までに、MPEG-DASH として呼ばれる “HTTP 経由のダイナミックアダプティブストリーミング” という新しい標準が誕生しました。」

つまり、Moving Pictures Expert Group (MPEG) が、HLS やその他の独自技術に代わるものとして MPEG-DASH を設計した、ということです。

2020 年以降の MPEG-DASH ライブストリーミング

現在、MPEG-DASH と HLS は、最も一般的な HTTP ベースの 2 つのプロトコルです。しかし、市場での採用状況に関しては明らかな勝者がいます (ヒント: Apple が承認したものです)。Wowza の 2021 年のビデオストリーミングレイテンシレポートの回答をご覧ください。

非独占的なプロトコルがトップに立つことが今後あるでしょうか？私たちの希望は「はい」です。しかし、時間が経てばわかります。

HLS と MPEG-DASH ストリーミング

HLS と DASH は、技術的な観点からは同じように機能します。 2 つの技術の主な違いは所有権にあります。HLS は Apple によって管理されていますが、MPEG-DASH ではオープンソースが選択できます。

HLS は、Apple が開発支援する技術であるため、Apple 製品全体でより適切にサポートされています。どうしてそのようになっているのでしょうか？それは簡単です。 Apple は、オープンソースの代替技術よりも独自の標準技術を優先したいと考えています。スティーブ・ジョブズが RTMP について批判することを決意したまさにそのことが、HLS をリードし続けている理由です。

つまり、Safari では、HLS で配信されたストリーミングコンテンツをネイティブに再生することができますが、MPEG-DASH で配信されたストリーミングコンテンツを再生するには HTML5 ビデオプレーヤーが必要となります。使用するプレーヤーが MPEG-DASH クライアントであることが必須となります。

同様に、Apple TV と iPhone は HLS ストリームのみを受け入れます。これらのデバイスでの唯一の回避策は、独自のアプリを作成することです。

最後に、HLS と MPEG-DASH が相違するその他の点は、エンコード形式と低遅延の配信方法にあります。以下のリストに纏めた通りです。

HLS と MPEG-DASH の比較

独自仕様と国際仕様: HLS は Apple 独自のものですが、MPEG-DASH は MPEG によって定義されたオープンスタンダードの仕様です
再生の互換性: HLS は Apple が業界全体に与える多大な影響力により、MPEG-DASH よりも広くサポートされています
コーデック要件: HLS は特定のビデオコーデック (H.265、H.265) と特定のオーディオコーデック (詳細はこちら ) の使用を指定しますが、MPEG-DASH はコーデックに依存しません: これにより、より高度なコーデックが利用される場合、より低いビットレートでより高品質のブロードキャストが可能になります
コンテナー形式: HLS は従来 MPEG-2 トランスポートストリームコンテナー形式 (.ts (MPEG-TS)) を使用してきましたが、MPEG-DASH は MP4 形式 (.mp4) を使用していました
遅延: どちらのプロトコルも配信遅延の点で伝統的に遅れをとっていましたが、新しいアプローチはこれを変えようとしています: MPEG-DASH の場合、これは Common Media Application Format (CMAF) の形式をとることで実現できますが、Apple は現在 Low-Latency HLS 拡張機能を提供します

訳注: Low-Latency MPEG-DASH では CMAF 形式のセグメントと Chunked Transfer Encoding (チャック転送エンコーディング) を活用することで低遅延でセグメントを転送することができます

DASH 向けの低遅延 CMAF

CMAF は Common Media Application Format の略です。つまり、HLS と MPEG-DASH の両方のストリーミングプロトコルに同じコンテナーフォーマットを指定することで、HLS と MPEG-DASH 間の相互互換性を向上させるメディアフォーマット、つまり、フラグメント化された MPG (fMP4) です。

遅延 (レイテンシー) の削減を目的とした大規模なシステムに仕様を組み込むことで、Akamai のような業界をリードする企業や組織は MPEG-DASH 経由で配信されるビデオの本質的に発生する遅延の削減にも取り組んでいます。

チャンクエンコーディングとチャンク転送エンコーディングを使用すると、低遅延 CMAF を使用することで、ストリームを設定された長さの小さなチャンクに分割し、エンコード時にすぐに公開することができます。各ベンダーは、この新しい技術のサポートを追加するために取り組んでいますが、低遅延 HLS の出現により採用が遅れています。

低遅延 CMAF の詳細については、このブログ記事を参照してください。

DASHの相互運用性

DASH プロトコル仕様は本質的に柔軟である一方、この柔軟性が課題を引き起こす可能性があります。具体的には、例えば、放送事業者が DASH を使って何かを実現するときに最適な構成を決定するのは困難である、ということです。

DASH-IF (DASH Industry Forum) はこの課題を認識し、適切な技術の活用をサポートするために、DASH-AVC/264 実装ガイドラインを作成しました。

DASH-IF では以下のように述べられています :

標準化後に DASH が直面する主な課題の 1 つは、コア仕様で許可されている多くの機能とオプションによって表される、DASH 自体の柔軟性でした。たとえば、コーデックに依存しないことは、新しいコーデックのオプションをサポートする場合にはプラスになりますが、エンコーダーまたはプレーヤーの提供者にとっては課題となります。例えば、DASH プレーヤーでどのコーデックをサポートしていますか？、エンコーダーはどのセグメントのカプセル化を生成する必要がありますか？、DRM の信号はどのように通知する必要がありますか？、サポートしているクローズドキャプション形式は何ですか？、などの点になります。この標準化仕様にあるこれらの本質的な柔軟性により、様々な初期実装間で相互運用性を実現することがより困難になりました。

完全な相互運用性が MPEG-DASH 市場での迅速な採用の鍵であることを認識することで、DASH-IF は DASH 標準をそのままの形で採用し、それをコーデックと結び付け、厳しいプロファイルやその他の制限を適用し、誰もが面倒な統合を必要としない相互運用可能な製品とサービスの構築に使用できるベースラインの推奨事項を作成することを決定しました。もしフォーマットが “どこでも機能する” とすれば、その成長は加速するため、相互運用性は採用の鍵となります。この推奨事項を含んだ勧告の名前は “DASH-AVC/264 実装ガイドライン” であり、https://dashif.org からダウンロードできます。

プレイヤー

いくつかの埋め込み可能な HTML5 ビデオプレーヤーは、複数のブラウザの上で MPEG-DASH 再生をサポートしています。 DASH-IF は無料のオープンソースプレーヤーとして dash.js を立ち上げました。その他のプレイヤーのオプションには次のようなものがあります。

サーバー

ほとんどのコンテンツディストリビューターは、RTMP、WebRTC、または、SRT を使用してオンラインビデオをエンコードし、(エンコードされたビデオが) ビデオストリーミングサーバーに到達したら、DASH を使ったアダプティブビットレート配信のためにビデオをトランスコードすることを選択します。

Wowza の SaaS プラットフォーム (Wowza Video) とメディアサーバー (Wowza Streaming Engine) はどちらも DASH をサポートしており、顧客の特定の要件に応じて、取り込みと配信の両方で最適なストリーミングプロトコルを使用するワークフローを柔軟に構築できます。

とはいえ、ビデオを追加の形式 (HLS など) で配信して、様々なデバイスの視聴者がコンテンツを視聴できるようにすることをお勧めします。繰り返しになりますが、Wowza のようなストリーミングソリューションは、ストリームを複数の形式にパッケージ化して、可能な限り幅広い視聴者にリーチするための最善の策です。

コンテンツ配信ネットワーク (CDN)

DASH は、一度パッケージ化すると、従来のネットワークサーバーと技術を使用して転送できるため、費用対効果が高くなります。これにより、CDN を使用した配信規模のスケーリングが容易になります。

DASH サポートを提供するライブストリーミング向けの私たちのお気に入りの CDN には次のようなものがあります:

市場での DASH の採用と今後の予定

ベンダー固有の技術とオープンスタンダードの技術の間の権力闘争は、ストリーミング業界では目新しいことではありません。しかし、RTMP や HLS などのベンダー独自のプロトコルが依然として目立っていますが、DASH などのオープンソースの代替手段が将来の道になる可能性があります。

MPEG-DASH は、そのオープンな性質により明確な利点をもたらします。その 1 つには、ビジネスの最高峰がリードするコミュニティ主導の取り組みを通じて開発されていることです。この協調的な精神によって、ストリーミング空間を悩ませてきた断片化の課題が対処され、それによって相互運用性の向上と複雑さの解消への取り組みが促進されます。

DASH-IF では、これを次のように詳しく述べています:

DASH 自体は、メディア、デバイス、市場の断片化の問題に対する魔法の万能薬ではありません。ただし、DASH-IF メンバーは、「断片化された事項の収束による長期的な利益がその目標を達成するための短期的な努力のコストを上回る」という共通のビジョンを共有しています。彼らは、推奨事項の作成、バグの報告、相互接続性試験や相互運用のためのイベントへの参加などの作業を進んで引き受けており、彼らのビジネスとインターネットストリーミング市場全体が、DASH を中心とした収束によって大きな利益を得ると信じています。

とはいえ、HLS は引き続き市場では中心的な役割を果たしており、DASH の採用が遅れています。したがって、HLS 対 DASH の議論のどこに着地しても、Apple デバイスにストリーミングする場合は HLS が最善の策であり続けます。

幸いなことに、Wowza を使用すると、動画をさまざまな形式に簡単にトランスマックスして、あらゆるデバイスに確実に配信することができます。

Resources: IETF が低遅延 HLS を HLS 仕様に盛り込む

Mon, 04 May 2020 00:00:00 +0900

この記事は、当社パートナーの Wowza Media Systems の記事 IETF Incorporates Low-Latency HLS Into the HLS Spec の翻訳記事です。この記事では、Apple 低遅延 HLS (Low-Latency HLS) の(2020年当時の)最新情報について説明します。

先週 Internet Engineering Task Force (IETF) によって公開された HTTP Live Streaming (HLS) 第 2 版で、Apple の Roger Pantos は、低遅延 HLS と HLS が 2 つの個別のストリーミングプロトコルではなくなったことを発表しました。そして、低遅延 HLS 拡張機能が 1 つの機能セットとして HLS 仕様に組み込まれることになりました。

これが何を意味し、ストリーミング業界にどのような影響を与えるのでしょうか？この記事で詳しく見て行きましょう。

HLS と低遅延 HLS の比較

詳細に入る前に基本を明確しましょう。では、HLS とは何であり、この開発の前に低遅延 HLS とどのように関連していたのでしょうか？

HLS

HLS (HTTP Live Streaming の略) は、現在使用されている最も一般的なストリーミングプロトコルです。 Apple は、ライブおよびオンデマンドストリーミングコンテンツのストリームを Apple デバイスに転送するためのプロトコルを設計しましたが、今日ではすべての Microsoft, Android, Linux デバイスでサポートされています。 HLS は高品質の視聴体験を実現するスケーラビリティとアダプティブビットレートストリーミングのために HTTP 技術を活用します。

低遅延 HLS

低遅延 HLS は、HLS と同じ簡潔さ、スケーラビリティ、品質を実現しながら、遅延を 2 秒未満に短縮するために開発された HLS プロトコルの拡張機能です。 Roger Pantos は、Worldwide Developer Conference (WWDC) 2019 でこの仕様をはじめて発表しました。翌年、業界全体のベンダーがこの仕様のサポートの追加に取り組み、Apple は市場での採用を合理的にするためのいくつかの更新を行いました。

低遅延 HLS を HLS に組み込むことの影響

HLS と Low-Latency HLS は常に密接に関連しています。しかし、HLS はストリーミングに広く使用されている実証済みのプロトコルですが、低遅延 HLS が登場してまだ 1 年しか経っていません。その間、その要件と利便性は流動的なままでした。

昨年末、Wowza Streaming Engine に低遅延 HLS のサポートを追加しました。ただし、低遅延 HLS の大規模な展開は依然として、希望的であり、現実ではありません。これは、エンド・ツー・エンドのワークフローには CDN およびプレーヤーとの統合が必要であり、多くのベンダーが新しい仕様のサポートを追加するためにまだ開発作業に取り組んでいるためです。

先週のアップデートでは、Apple は、この次世代の低遅延 HLS 拡張機能を従来の HLS 仕様に組み込みました。これには 2 つの意味があります。仕様をさらに標準化し、テクノロジープロバイダーにサポートを追加するよう強力に推進します。

TL;DR

HLS は、今日のストリーミングビデオ配信の主流プロトコルです。そして、現在、この包括的で重要となっている標準仕様の一部として、2 秒未満のビデオストリームを大規模に配信する機能を提供します。

低遅延 HLS 機能セットをコアとなる HLS 仕様に追加することで、Apple と IETF はこの技術の採用をさらに促進していきます。

Resources: 低遅延 HLS とは？そして CMAF との関連は？

Mon, 03 Feb 2020 00:00:00 +0900

この記事は、当社パートナーの Wowza Media Systems の記事 Update: What is Low-Latency HLS and How Does It Relate to CMAF の翻訳記事です。この記事では、Apple の低遅延 HLS (Low-Latency HLS) を詳しく説明します。

注意: このブログ記事の投稿の以降に、低遅延 HLS (Low-Latency HLS) 仕様は、包括的で重要となっている HLS 標準に組み込まれています。詳細については、仕様のアップデートに関するブログ記事をご覧ください。

昨年の (訳注: 2019年の) Worldwide Developer Conference (WWDC) で、Roger Pantos は HTTP ライブストリーミング (HLS) プロトコルのまったく新しい拡張のための仕様を発表しました。それが低遅延 HLS (Low-Latency HLS) です。この仕様では、大規模の配信で 2 秒未満の遅延を実現することが約束される一方で、既存のクライアントとの下位互換性も提供も約束されました。

業界ではいくつかの理由で注目を集めました。 HLS の拡張として、低遅延 HLS (Low-Latency HLS) の普及が想定されました。それは、HLS が結局のところ現在最も一般的に使用されているプロトコルだからです (2019 年のビデオストリーミングレイテンシレポートでは、コンテンツ配信者の 45% 以上が HLS を採用しています)。

しかし、ベンダーが低遅延 HLS (Low-Latency HLS) のサポートをどれくらい早く実装できるかは不明のまま残りました。その 1 つには、Apple の発表により、CMAF のチャンク転送エンコーディングによって遅延を削減するという業界全体の取り組みが中断された点です。また、低遅延 HLS (Low-Latency HLS) が、多くのコンテンツ配信ネットワーク (CDN) がまだ提供できていない HTTP/2 PUSH を必要とするという点でした。

そして、騒動はそれだけではありませんでした。この拡張機能が大規模配信で(適切に)機能するかどうか疑問を持っている人もいました。さらに、この技術を実際に実装する前に、Apple には解決すべきいくつかの問題があるという明確な意見の一致がありました。

低遅延 HLS の最新の更新

訳注: この記事は 2020年の記事になります

低遅延 HLS (または LL-HLS) は、当初からすでに大幅に進化しています。 HLS メーリングリストで通知されたように、Apple は数週間前に HTTP/2 PUSH 要件を削除しました。その代わりに、この拡張機能は短いメディアチャンクと #EXT-X-PRELOAD-HINT という新しいタグを使用するようになりました。この変更は、仕様がまだどれだけ流動的であるかを反映しています。

THEOplayer の私たちの友人たちは次のように説明しています :

低遅延 HLS ストリームを公開するサーバーは、このタグを使用して利用可能になる次のメディアデータの最も可能性の高い場所を通知する必要があります。これにより、プレーヤークライアントはセグメントの次の部分のリクエストを実行できるようになり、その結果、セグメントの次の部分が利用可能になるとすぐにデータをプレイヤーのバッファに入れることができるようになります。そして、このプロセスを繰り返すことで、新しいメディアデータをロードする際に追加の往復時間を削減することができます (元々、この往復時間の削減が HTTP/2 PUSH を使用する主な理由でした)。

Apple が最初に低遅延 HLS を発表したときのもう 1 つの大きな懸念は、MPEG-DASH の低遅延 CMAF との相互運用性の欠如でした。この更新によって、LL-HLS がチャンク転送のアプローチを模倣できるようになり、いくつかの障害が取り除かれました。低遅延 HLS とMPEG-DASH の低遅延 CMAF の間の互換性の向上は、複雑さを解消し、CDN のキャッシュ効率を向上させるのに役立つはずです。

この開発のインパクトをさらに明らかにするために、低遅延 HLS について最初から振り返ってみましょう。

CMAF と低遅延への競争

かつて Apple と Microsoft の両方のデバイスを利用するユーザーに配信したいコンテンツ配信者は、同じコンテンツのオーディオデータとビデオデータを 2 回エンコードしてストレージに保存する必要がありました。これは、Apple の HTTP ライブストリーミング (HLS) プロトコルが .ts 形式の使用するのに対して、HTTP の動的アダプティブストリーミング (DASH) は、たいていの場合 .mp4 コンテナーを使用するためです。

これは、電話やコンピューターの充電器のようなものだと考えてください。 Android と iPhone は同じ充電器を使用していないため、すでにコードだらけの世界の中で必要以上の充電コードが必要になります。 Apple は独自のポートに独自のケーブルを使用しているため、ユーザーは充電器を紛失するたびに Apple Store に行くことになります。 HLS プロトコルは、Apple の仕様をサポートするデバイスにストリーミングするための独自の充電器のようなものでした。一方、MPEG-DASH は、他のデバイスへの配信にも機能しました。

奇跡的に、Microsoft と Apple は、Common Media Application Format (CMAF) と呼ばれる新しい標準を発表することで、すべてを単純化することができました。この仕様では、HLS と MPEG-DASH の両方で参照できる断片化された .mp4 コンテナーを使用します。

これは素晴らしいニュースでした。コンテンツ配信者は、同じデータを 2 回エンコードしてストレージに保存するという必要がなくなりました。単一の形式は、コンテンツの配信者の費用を節約し、ビデオ配信を最適化することができます。

複雑さを解決するだけでなく、業界全体のベンダーが協力して、チャンクエンコーディングとチャンク転送エンコーディングを使用して HTTP ベースのストリーミングの遅延を短縮しはじめました。この技術を活用することで、CMAF を使用して 3 秒未満のビデオ配信を可能にすることができるでしょう。

遅延を短縮するための業界全体の取り組み

Wowza では、低遅延 CMAF のサポートに取り組みました。 Akamai , THEOPlayer , Fastly やその他の企業で構成されたチームは、同じ目標に向かって真剣に取り組んでいました。この低遅延 CMAF が機能するためには、ストリーミングエコシステム全体の各ベンダーがそれぞれの製品を最適化する必要があったため、このことは重要でした。低遅延の CMAF への早期アクセスにサインアップするようお客様を招待し、チャンク転送エンコーディングを使用して Apple と Microsoft の両方のデバイスにストリームを配信できる可能性に興奮しました。

Apple はこの業界の取り組みに対してコミットしていませんでしたが、コミュニティは熱狂的になっていました。 Periscope は、この技術を使用して開発したオープンソースの Low-Latency HLS (LHLS) 標準に関する記事を投稿しました。Akamai の Will Law は、チャンクエンコードおよびチャンク転送 CMAF に多くの時間を費やしました。私たち Wowza のエンジニアは彼と一緒に座って、それがストリーミング業界にどのような影響を与えるかについて話し合っていました。

その後、Apple は Low-Latency HLS を発表しました。

低遅延 CMAF と Apple 低遅延 HLS の比較

WWDC19 まで、ストリーミングコミュニティは、チャンク転送エンコーディングを使用して低遅延の CMAF を推進していました。 WWDC19 の Apple の発表では、HLS のための異なる低遅延の技術をサポートするであろうことが明らかになりました。低遅延 CMAF と Apple 独自の仕様との主な違いの 1 つは、HTTP/2 PUSH の使用でした。

この Apple の動きを支援するために、Wowza は Apple によって定義された低遅延 HLS (Low-Latency HLS) のサポートを追加することにしました。昨年 11 月までに、我々 Wowza のお客様は Wowza Streaming Engine 4.7.8 リリースを使用して、Apple 独自の低遅延 HLS ワークフローの構築を開始できるようになりました。

ただし、大規模で高速な (訳注: 低遅延の) ビデオ配信は、(Wowza ソリューションだけが) 孤立した状態では実現できません。ワークフロー全体をまたぐ様々なベンダーがこの仕様を機能させるためにサポートする必要がありました。そして、前述の通り、HTTP/2 PUSH 機能は、ほとんどの CDN にとって依然として課題となっていました。

HTTP/2 PUSH 要件の削除

Apple による低遅延 HLS 仕様の改訂には、実装の先頭でリードしている組織がこの変更に適応する必要があります。とはいえ、HTTP/2 PUSH の削除により、この仕様の採用は簡単になるはずです。

私たちは、CDN やプレーヤーとの統合を通じて、低遅延 HLS の大規模な展開をサポートすることに引き続き取り組んでいます。そして、進化する仕様に合わせて開発を続けます。

今後も進化するであろう仕様をキャッチアップし続けますが、現時点での低遅延 HLS のスナップショットを以下に示します。

Apple 低遅延 HLS: スナップショット

Apple は、この拡張機能を設計して、大規模な配信での遅延を削減しました。プロトコルはもともと HTTP/2 PUSH 配信機能に依存していましたが、この要件は削除されました。代わりにこの拡張機能は短いメディアチャンクと #EXT-X-PRELOAD-HINT という新しいタグを使用します。

再生の互換性: 低遅延 HLS 用に最適化されていないプレーヤーは、(高い遅延の)標準 HLS 動作にフォールバックできます。 HLS 互換デバイスには、MacOS, Microsoft, Android, および Linux デバイスが含まれます、そして、すべての Google Chrome ブラウザー、いくつかのセットトップボックス、スマート TV、およびその他のプレーヤーが含まれます。
利点: 大規模配信時の低遅延と下位互換性。
欠点: 新しい仕様として、ベンダーはまだこの機能のサポートを実装しており、まだ仕様の要件は流動的なままです
レイテンシ: 2 秒以下

訳注: 2022年現在では、Apple の低遅延 HLS の仕様は以前よりも固まってきていますが、HLS RFC仕様の第2版はまだドラフト仕様のままです。

LiveInstantly, LLC.

Resources: ストリーミング業界の 2023 年のトレンド

2023 年のストリーミング トレンド トップ 10

1. 動的コンテンツ作成のための人工知能 (AI)

2. 無料の広告付き (FAST) テレビ

3. 新しい OTT 収益化モデル

4. 没入型ビデオ体験とメタバース

5.ストリーミング速度とフィードの進歩

6. コネクティビティの向上: ATSC 3.0 および 5G

7. オムニチャネル ビデオ マーケティング

8. 市場統合

9. ブロックチェーンと非代替トークン (NFT)

10. ストリーミングのグリーン化

結論

Resources: ストリーミング プロトコル: 知っておくべきこと

プロトコルとは

ストリーミング プロトコルとは

UDP vs. TCP: 簡単な背景

ビデオ ストリーミングの最も一般的なプロトコル

従来のビデオ ストリーミング プロトコル

Adobe RTMP

RTSP/RTP

アダプティブ (適応型) HTTP ベースのストリーミング プロトコル

Apple HLS

低遅延 HLS

MPEG-DASH

MPEG-DASH 向けの低遅延 CMAF

Microsoft スムース ストリーミング (Smooth Streaming)

Adobe HDS

新しい技術

SRT (Secure Reliable Transport)

WebRTC

ストリーミング プロトコルを選択する際の考慮事項

転送と配信

再生のサポート

エンコーダーのサポート

スケーラビリティ

遅延（レイテンシー）

体験品質

セキュリティ

結論

Resources: WebRTC とは？

WebRTCとは?

WebRTC はどのように機能しますか?

WebRTC スナップショット

WebRTC の成り立ち

WebRTC の利点

WebRTC の制限

WebRTC ストリーミングのユースケース

WebRTC セキュリティとは？

WebRTC は他のプロトコルとの比較

WebRTC と HLS

WebRTC 対 RTMP および SRT

WebRTC 対 RTSP

WebRTC スケーラビリティの問題の解決

WebRTC 配信品質の問題の解決

WebRTC と Wowza を組み合わせる理由

結論

Resources: HLS (HTTP ライブ ストリーミング) とは？

HLSとは？

Apple HLS スナップショット

HLS (HTTP Live Streaming) の歴史

HLS ストリーミングはどのように機能するか？

一般的な RTMP から HLS へのワークフロー

アダプティブ ビットレート ストリーミングのトランスコーディング

配信とスケーリング

HTTP ライブ ストリーミング ツールとサービス

HLS ストリーミング サーバー

コンテンツ配信ネットワーク (CDN)

HTML5 プレーヤー

HLS ストリーミングの技術概要

UDP 対 TCP

コンテナ形式

エンコード要件

.M3U8 マニフェスト ファイル

セグメントのサイズとレイテンシ

Apple 低遅延 HLS (Low-latency HLS)

HLS の代替手段

HLS と MPEG-DASH の比較

HLS と WebRTC の比較

2023 年のストリーミングトレンドトップ 10

7. オムニチャネルビデオマーケティング

Resources: ストリーミングプロトコル: 知っておくべきこと

ストリーミングプロトコルとは

ビデオストリーミングの最も一般的なプロトコル

従来のビデオストリーミングプロトコル

アダプティブ (適応型) HTTP ベースのストリーミングプロトコル

Microsoft スムースストリーミング (Smooth Streaming)

ストリーミングプロトコルを選択する際の考慮事項

Resources: HLS (HTTP ライブストリーミング) とは？

アダプティブビットレートストリーミングのトランスコーディング

HTTP ライブストリーミングツールとサービス

HLS ストリーミングサーバー

.M3U8 マニフェストファイル

MPEG-DASH の仕組み: アダプティブビットレートストリーミング

HTTP ベースのアダプティブビットレートストリーミングの登場

2020 年以降の MPEG-DASH ライブストリーミング

Resources: 低遅延 HLS とは？そして CMAF との関連は？