UEFA欧州選手権2024の期間中、1,150万を超える英国の世帯がBTのブロードバンド網を通じて、英国内代表の試合を少なくとも1試合ストリーミングで視聴しました。BTは後に、BBCとITVからのトラフィックが通常の週間量の30倍以上にまで急増し、両放送局が一時的にNetflix、Facebook、YouTubeを抜いて同網最大のコンテンツ源になったと報告しています。大会で最も高い単一のトラフィックのピークは、決勝でコール・パーマーが同点ゴールを決めた瞬間に訪れました。
その規模の次の試練は、わずか1か月先に迫っています。FIFAワールドカップ2026は6月に開幕し、米国、カナダ、メキシコで開催されます。そのライブ視聴者は、同じ試合を各世帯に別々のストリームとして送るようには決して設計されていない、同じ固定網とモバイル網に降りかかることになります。
こうしたピークは網にとって吸収しにくく、その理由は構造的なものです。今日広く使われているストリーミング形式は、HLSもDASHも含め、すべてユニキャストの上に成り立っています。視聴者はそれぞれ自分のセッションを開き、各セグメントの自分のコピーを取得します。同じチャンネルの視聴者が10人なら、網を横断する同一ストリームは10本です。100万人なら、同一ストリームは100万本です。コンテンツは全員にとって同じなのに、網はそれを、コピーごとに別物であるかのように運びます。
Multicast ABR、通常はmABRと略されるこの技術は、その問題に対するストリーミング業界の主たる答えです。新しいものではなく、すでに標準化されており、ひと握りの大手通信事業者がすでに本番運用しています。すべての解決策と見なす前に理解しておくべき、現実の限界もあります。本記事では、mABRとは何か、どう動くのか、実際に何を節約するのか、どこで力不足なのか、誰が導入したのか、そしてGPACとMotion Spellが主導するオープンソースの取り組みがなぜこの技術の将来にとって重要なのかを扱います。
Multicast ABRとは何か
Multicast ABRは、ありふれたアダプティブビットレートのコンテンツ、つまり通常のプレーヤーがすでに期待しているのと同じHLSやDASHのセグメントを、ユニキャストではなくIPマルチキャストで配信します。事業者の管理網では、チャンネルは網を通じて一度だけマルチキャストストリームとして送られ、いくつの世帯でもそれに参加できます。標準的なユニキャストHTTPへの変換は家庭の中またはその近くで行われるため、デバイスとそのプレーヤーは何かが変わったことを決して知りません。プレーヤーの視点では、近くのCDNエッジのように見えるものに対して、相変わらずHTTPでセグメントを要求しているだけです。
核心となる考え方は単純です。ユニキャストでは、1人の視聴者は1本のストリームを意味します。マルチキャストでは、何世帯が視聴していようと、1つのチャンネルは1本のストリームを意味します。
正確に述べておくべき点が2つあります。第一に、mABRはハイブリッドです。マルチキャストが配信の大半を担い、ユニキャストは修復経路およびフォールバック経路として回路の中に残ります。第二に、mABRはライブおよびリニアのコンテンツ向けに設計されています。Streaming Video Technology Allianceが公開した技術ブリーフ、つまりそのmABR文書がEricssonのエンジニアによって主導され、Comcastを含む事業者の寄稿を受けた業界団体のものは、はっきりと述べています。ビデオオンデマンドは依然としてCDNから来る、と。mABRが真価を発揮するのは、多くの人が同じものを同時に見るとき、すなわちライブのスポーツとライブのニュースです。
マルチキャスト映像は新しくない、とりわけフランスでは
はっきりさせておく価値があります。テレビのマルチキャスト配信には数十年の歴史があり、フランスはそれが大規模に機能している最良の例の1つです。2000年代初頭、FreeがFreeboxを展開したとき、同事業者はIPマルチキャストによるテレビ配信を、自社の卸売り解除されたDSL網に直接組み込みました。当時、既存事業者のDSLAMが提供していなかったものです。2008年までに、Freeは世界最大のIPTV事業者として1位に位置づけられていました。マルチキャストこそが、採算が合った理由でした。各チャンネルのコピーは、それを見ているFreebox世帯がいくつあろうと、網を1本だけ流れていたのです。
Freeはそのマルチキャストフィードを、Multiposteというサービスを通じて加入者に直接公開もしていました。これにより、テレビと並行してコンピューター上でFreebox TVのチャンネルを、VLCでチャンネルのプレイリストを開いて視聴できました。ストリームは単純なIPマルチキャストで、Freeboxを経由して運ばれ、IGMPで参加し、セットトップボックスは一切関与しませんでした。フランスのブロードバンド利用者の世代まるごとが、事実上、PC上でマルチキャストのテレビ受信機を動かしていたのです。
道具立てもまた、決して特殊なものではありませんでした。Multiposteが頼っていたのと同じプレーヤーであるVLCは、ユニキャストストリームを入力として受け取り、1つのストリーム出力設定でUDPまたはRTP上のマルチキャストアドレスへ再送出できます。1本のユニキャストフィードをマルチキャストフィードに変えること自体は、ありふれた、とうの昔に解決された問題です。
では、マルチキャストが古く、道具がどこにでもあるのなら、Multicast ABRに本当に新しいものは何でしょうか。古典的なマルチキャストIPTV、すなわちFreeboxモデルは、固定された連続的なトランスポートストリームを事業者自身のセットトップボックスへ運んでいました。mABRは代わりに、現代的なアダプティブビットレートのコンテンツ、つまりあらゆる携帯電話、タブレット、スマートTV、ストリーミングスティックがすでに話すHLSとDASHのセグメントを運び、それを1つの専有箱ではなく、断片化したデバイスのエコシステム全体に向けます。mABRの難しい部分はマルチキャストそのものではありません。セグメント化された、アダプティブで、複数デバイスにまたがるストリーミングのためにマルチキャストを行うこと、それに必要なゲートウェイ、ランデブー、修復の仕組みごと行うことこそが難しいのです。
mABRの仕組み
DVB-MABR仕様は、DVB Projectが開発し、ETSIがTS 103 769として公開したもので、名前のついた小さな機能群から構成される参照アーキテクチャを定義しています。
- マルチキャストサーバー。 CDNのオリジンまたはエッジから標準のABRコンテンツを取り込み、各セグメントを1つ以上のマルチキャスト転送オブジェクトに対応づけ、IPマルチキャストで送出します。事業者は設定用APIを通じて、どのストリームを取り込み、どう送るかを指示します。
- マルチキャストゲートウェイ。 マルチキャストストリームを受信し、ローカルのプレーヤー向けに普通のHTTPへ変換し直します。小さなローカルキャッシュ兼HTTPプロキシのように振る舞います。
- マルチキャストランデブーサービス。 プレーヤーの最初の要求を、HTTPリダイレクトによって、事業者のサービスプランやビジネスルールに基づき、適切なゲートウェイへ振り分けます。
- ユニキャスト修復。 マルチキャストパケットが失われたとき、ゲートウェイは欠けた部分をユニキャストで、通常はHTTPのバイトレンジ要求を用いて取りに行き、再生が途切れないようにします。
ゲートウェイが動く場所
仕様は、マルチキャストゲートウェイがどこに置かれるかについて意図的に柔軟です。事業者の網の中、家庭用ゲートウェイやルーター、光回線終端装置、あるいはセットトップボックスの中で直接動かせます。ゲートウェイとプレーヤーが同じデバイス上にある場合、DVB仕様は、その間のインターフェースは単なるローカルAPIでよいとしています。SVTAのブリーフは、同じ構成要素をマルチキャストクライアントと呼び、セットトップボックス、家庭用ゲートウェイ、ONT、あるいは事業者のエッジキャッシュの中に展開できるものとして説明しました。最後の選択肢はそれ自体が有用です。CDNエッジに組み込まれたmABRクライアントは、マルチキャストでキャッシュを満たし、オリジンへ戻る要求を減らせます。
トランスポートプロトコル
その下で、mABRは一方向マルチキャスト向けに作られたファイル配信プロトコルを使います。DVB-MABRはそのうち2つを必須としています。FLUTE(File Delivery over Unidirectional Transport、RFC 6726)は3GPPの世界から来ています。ROUTE(Real-Time Object Delivery over Unidirectional Transport、RFC 9223)はATSC 3.0から来ています。2023年の仕様改訂で、任意のプロトコルが2つ加わりました。NORM(NACK-Oriented Reliable Multicast、RFC 5740)とMSYNCです。いずれもUDPの上で動き、前方誤り訂正とともにセグメント化されたコンテンツを運びます。
有用な性質が1つあります。mABRはフォーマット、コーデック、DRMに依存しません。HLSでもDASHでも、MPEG-TSでもCMAFでも、暗号化されていてもいなくても運び、何も再エンコードしません。バイトがどう旅するかを変えるのであって、それが何であるかは変えません。
Multicast ABRの利点
スケール、これこそが眼目
mABRを支持する核心的な論拠は、人気のあるライブチャンネルの網コストが、視聴者とともに増えるのをやめる、という点です。SVTAの技術ブリーフは、これを2つのアクセス網の例で示しています。DOCSISのケーブル網では、ユニキャストABRに必要なチャンネル数は、視聴者が加わるにつれて直線的に増えますが、mABRでは短く立ち上がったあと、視聴者が同じマルチキャストストリームを共有するため平らになります。GPONの光ファイバー網について、ブリーフは次のように見積もっています。500の線形チャンネルを抱える事業者で、視聴者の80パーセントが番組表の10パーセントを見る場合、コア網の帯域節約はPONあたり32契約で約50パーセントに達し、視聴者あたりの帯域需要は、視聴者が数万に達した時点でユニキャスト値の3パーセント未満に下がります。ブリーフはあけすけにこう要約しています。mABRは、きわめて人気のあるライブイベントについて、網の端での帯域需要をペタバイトの規模からメガバイトの規模へ下げられる、と。
モデル化された推計ではなく、事業者から直接来た数字が1つあります。2025年3月、BT GroupはMAUD、すなわち同社がMulticast-Assisted Unicast Deliveryと呼ぶものの最初の試験成功を報告しました。これはBBC Twoのライブコンテンツを、本番網のEEのセットトップボックスへ届けるものでした。ピーク時、この試験はトラフィックの60パーセント超をユニキャストからマルチキャストへ転換しました。
体感品質
mABRはベストエフォートのサービスではなく、管理されたサービスとして提供されます。SVTAのブリーフは、これが再生のジッターを和らげると指摘しています。事業者が経路を制御し、オリジンと視聴者の間の開かれたインターネットに頼らないからです。ライブの決勝にとっては、見ている全員への安定した配信は、純粋な帯域節約と同じくらい重要です。
すでにあるものを再利用する
SVTAのブリーフは、mABRのインフラコストが他のスケーリングの選択肢より低くなりうると強調しています。関係するルーターや網要素のほとんどが、すでに事業者の網に展開されているからです。mABRはまた、CDNのキャッシュを置き換えるものではなく補完するものであり、エッジキャッシュを満たすコンテンツ源として働けます。
Multicast ABRの欠点
加わる遅延
マルチキャストゲートウェイは、セグメントを配信できるようになる前に、それを受信して組み立て直さなければならず、これが元のABRストリームの上に遅延を加えます。Techne Digitaleが公開したある技術分析は、mABRが典型的なOTT配信の上におよそ2セグメント分の遅延を加え、エンドツーエンドの数字を約8秒から約12秒へ押し上げると見積もっています。SVTAのブリーフは、より短いセグメント長やCMAFのチャンク転送を含む丁寧な設計によって、mABRを素のユニキャストABRと競争できる水準、あるいはそれ以下にも保てると論じています。いずれにせよ、遅延はライブスポーツにとって現実の検討事項です。動きが自分の画面に届くより先に隣人の反応が聞こえる視聴者は、それに気づくでしょう。
クライアントエコシステムの問題
SVTAのブリーフは、展開されたクライアントエコシステムの欠如を、mABRのより広い普及に対する第一の障壁と呼んでいます。古い家庭用ゲートウェイやONTは、マルチキャストクライアントを動かすためのCPUとメモリを備えていないことが多いです。新しいハードウェアならできますが、デバイスメーカーには、それを使うインフラがないうちはマルチキャストクライアントのソフトウェアを作り、試験し、保守する理由がほとんどなく、事業者には、デバイスがそれを使えないうちはインフラを展開する理由がほとんどありません。2023年初頭のCSI Magazineのイベントで、BTのTVアーキテクトであるサイモン・ジョーンズは、BTが10年以上にわたってマルチキャストテレビを運用してきたが、それをテレビにだけ届け、接続デバイスには届けてこなかったこと、そしてBTは既存のインフラではワールドカップのようなものを届けられないだろうと述べました。DAZNの映像再生・配信アーキテクトであるボブ・ハネントは、同じ議論の中で、市場はまだ「本当に未成熟だ」と語りました。両者とも、GoogleやAppleのようなデバイスメーカーからの支援の欠如を、最大の妨げとして挙げました。
管理網でしか動かない
公共のインターネットにマルチキャストはありません。mABRは単一の事業者の管理網の中で、事業者が運用するマルチキャストサーバーと、事業者が制御するゲートウェイの間で動きます。Netflixのような純粋なOTTサービスは、自前でmABRをエンドツーエンドに展開することはできません。ISPに支援を求めることはできますが、各ISPに個別に依存します。
断片化
mABRは網ごとにローカルであるため、それが動くISPの分しか効果がありません。視聴者を支えるISPの半分がそれを支援していても、残り半分の視聴者は依然としてユニキャストの体験と同じ輻輳を受けます。ユニキャストCDNと違い、単独の企業が視聴者全体にエンドツーエンドのmABR体験を届けることはできません。
現代の網では問題が小さくなっているかもしれない
Techne Digitaleの分析は、1対64の分岐でも各世帯に毎秒数十メガビットを残す現代のGPON光ファイバーでは、mABRが対象として設計された最終マイルの帯域のひっ迫はそもそも存在しないかもしれず、mABRが最も意味を持つのは古いケーブル網だと論じています。SVTAのブリーフ自身も同様の問いを投げかけ、長年にわたるCDNエッジの増強、HEVC、AV1、VVCといったより優れたコーデック、そして新しいトランスポートプロトコルが、業界をすでに成長曲線の前に保たせてきたのではないかと問うています。Comcast自身の初期のmABRプロジェクトが、同社のVIPER研究グループによって2015年ごろに進められながら、ついに展開には至らなかったことは、思い出す価値があります。
複数のバリエーションが節約を食う
事業者が提供したいフォーマット、ビットレートのはしご、DRMのバリエーションのそれぞれを、別々にマルチキャストしなければなりません。関わるデバイスの種類とコンテンツ保護が多いほど、必要な並行マルチキャストストリームは多くなり、効率の正味の利得は小さくなります。
実際に誰がmABRを使っているのか
mABRは実験室の段階を過ぎています。最も明確な公開事例は、自前の管理アクセス網を運用する通信事業者から来ています。
- 英国のBT Groupが、これについて最も率直でした。BTは2024年にMAUDの取り組みを発表し、2025年3月に最初のライブ試験成功を報告しました。これはBBC TwoをEEのセットトップボックスへ届け、ピークトラフィックの60パーセント超をマルチキャストへ転換しました。BTは、目標は大規模視聴者のライブイベントに対応することだと述べており、業界の報道は、放送局がFIFAワールドカップ2026に向けてMAUDを評価していると伝えています。
- スペインのOrangeは、最も視聴者の多いライブイベントにmABRストリーミングを提供する同国初の事業者であると、自社の顧客に伝えており、LaLiga、フォーミュラ1、MotoGPを挙げ、それをセットトップボックスを越えて家庭内の他のデバイスへ広げています。
- イタリアのTIMは、自社の技術誌で、2021年以来ETSIのM-ABR標準に準拠したマルチキャストのコンテンツ配信プラットフォームを運用しており、スポーツのような大規模ライブイベントにスケーラビリティを加えるために用い、既存のユニキャストモデルと自動フォールバックで統合していると書いています。
- フランスのBouygues Telecomは、2023年以降、商業的にmABRでストリーミングする最初のフランスの事業者として、業界紙に紹介されました。
すべての事業者が納得しているわけではありません。Deutsche Telekomは、mABRを公に、長期的な到達点としてではなく、インフラがまだ純粋なユニキャストを支えられないところで有用な過渡的技術として位置づけています。
これらの展開を通じて、1つのパターンが際立ちます。それらはほぼすべて、相互運用可能な標準準拠のスタックではなく、単一ベンダーの同じ専有実装、すなわちBroadpeakのnanoCDNの上に構築されてきました。これは技術的な推奨ではなく、市場の事実です。DVB-MABR仕様は公開されていますが、何年もの間、それを基に構築し、それに対して試験できる中立的で公開された実装が存在しなかったため、本番でmABRを望む事業者には、ベンダーの実際的な選択肢がほとんどありませんでした。
デバイス側
ハードウェア側では、セットトップボックスとCPEのメーカーは事業者と同じくらい重要です。CommScopeは、DVBとCableLabsの両標準の一部に基づくと説明するMulticast ABRソリューションを提供しており、そのクライアントはセットトップボックスまたは家庭用ゲートウェイに組み込んで動かすことができ、同社は家庭内のストリーミングデバイスに変更は不要だと述べています。Vantiva、かつてのTechnicolorは、マルチキャストABRクライアントのソフトウェアを統合したセットトップボックスを出荷してきました。Broadcomのようなサプライヤーのセットトップボックス向けチップセットは、網レベルでIPマルチキャストの対応を提供しますが、mABRそのものはデバイス上で動くソフトウェアとして実装されており、名前のついたチップセットの機能ではありません。
その隔たりは、最大のデバイスプラットフォームで最もよく見えます。素のAndroid TVはユニキャストしか対応しないため、それらのデバイスでのmulticast ABRは、マルチキャストクライアントを加える事業者向けの統合に依存します。Google自身のプレーヤーライブラリであるExoPlayerとMedia3は、multicast ABRを標準では提供しておらず、それを求める未解決の機能要望があります。
標準は存在する。難しいのは相互運用性だ。
mABRは標準の欠如によって足を引っ張られている、という思い込みはよくあります。そうではありません。
CableLabsは2014年ごろ、IPマルチキャストABRの初期のアーキテクチャ作業を行いました。DVB Projectは2018年にmulticast ABRの参照アーキテクチャを業界の意見募集のために公開し、そのSteering Boardは2020年初頭に完全な仕様を承認し、それは2020年11月にETSI標準TS 103 769として公開されました。それ以来、何度か改訂されており、その中には2023年の更新があって、任意のトランスポートプロトコルであるNORMとMSYNC、ならびに報告、真正性、改ざん防止の機能を加えました。その背後にあるDVBの作業部会MCASTは、BBC R&DのリチャードDOTブラッドベリが議長を務めています。実在し、公開され、国際的に認められた標準が存在し、DVB-MABRの実装ガイドラインやDVB-Iのサービス発見仕様といった付随する作業も伴っています。モバイル側では、3GPPが独自の並行した道を進んでおり、Release 17の5G Multicast-Broadcast Servicesのアーキテクチャは、同じFLUTEとROUTEのプロトコルの系譜を共有しています。
欠けていたのは、実践における相互運用性です。今日までのほぼすべての商業的なmABR展開は、同じ専有スタック、すなわちBroadpeakのnanoCDNの上で動いています。MSYNCは、2023年にDVB-MABRに取り込まれた任意のトランスポートプロトコルの1つですが、仕様に持ち込まれる前はBroadpeakのプロトコルとして始まりました。大半が1つのベンダーによって実装される標準は、紙の上の標準です。紙の仕様を、複数ベンダーが機能する市場へ変えるのは、誰もがその上に構築し、それに対して試験できる中立的な実装です。
GPACとMotion Spellの出番
これが、本物の標準化への道を指し示す、mABRの物語の部分です。
GPACは長く続くオープンソースのマルチメディアフレームワークで、LGPLライセンスのもとで配布され、その商業パートナーであるMotion Spellとともに開発されています。Telecom Parisでの学術研究にルーツを持ち、1億回近くダウンロードされています。GPACは何年も前にATSC 3.0向けにROUTEプロトコルを実装し、その仕事は2018年にNABのイノベーション賞を受賞しました。そしてGPACは、DVB-MABRの2つの必須トランスポートプロトコルであるROUTEとFLUTEの両方を対応する唯一のオープンソースプロジェクトです。2024年には、DVB-MABRのためのFLUTE対応を特に追加しました。GPACのメディアサーバーはすでにマルチキャストからABRへのゲートウェイとして働くことができ、マルチキャストセッションを通常のHTTPストリーミングサービスとして公開し、ユニキャスト修復と設定可能なタイムシフトウィンドウを備えています。
その後DVBは、DVB-MABR実装を検証・妥当性確認するためのオープンソースツールの提案依頼を出しました。その結果であるDVB-MABR Reference Toolsは、GPACとMotion Spellの上に構築されています。これはオープンソースで、GPACライブラリの上にPythonで書かれており、2つのモードで動きます。HTTPソースからマルチキャストストリームを生み出すサーバーモードと、マルチキャストを受信してHTTPで返し直す、HTTP修復を含むゲートウェイモードです。DVB自身のGitHubの組織で公開されており、マルチキャストサーバー、ゲートウェイ、標準的なDASHプレーヤーが実際に相互運用することを確認する必要がある、エンジニア、インテグレーター、検証チームに向けられています。
だからこそ、この仕事はもう1つの製品発表より重い意味を持ちます。ロイヤリティフリーで公開された参照実装は、あらゆる事業者、デバイスメーカー、ソフトウェアベンダーに共通の基盤を与えます。それは、DVB-MABRが単一ベンダーの展開の市場から、複数ベンダーにまたがる真の相互運用性へと進める実際的な仕組みであり、それこそが、公開された標準と、エコシステム全体が実際に使える標準との違いです。GPACの関与はまた、mABRをより広い研究、すなわちより持続可能な映像配信に取り組むSMART-CDコンソーシアムの仕事へと結びつけており、そこにはTelecom Paris、Ateme、Viaccess-Orcaといったパートナーが並びます。
余談:ピアツーピアは同じ問題に反対側から取り組む
人気のあるライブストリームが視聴者1人につき1回送られるのを防ぐ方法は、mABRだけではありません。ピアツーピア配信は、同じ無駄に反対方向から取り組みます。1つのコピーを管理網に送り込み、それを家庭の近くで扇状に広げる代わりに、ピアツーピアの層は、視聴者自身のデバイスにセグメントを互いに共有させます。各プレーヤーは最初のバイトをCDNから取得し、その後、同じものを見ている他のプレーヤーと直接チャンクを交換し、必要なときにだけCDNへ戻ります。
フランスの企業Quanteecは1つの例です。学術研究として始まったその技術は、既存のHLSまたはDASHのワークフローにピア支援の層を加えるもので、CDNとDRMに依存しません。Quanteecは、数十万の同時視聴者を支えたFrance Télévisionsとの展開が、平均しておよそ75パーセントのトラフィックをCDNから肩代わりし、50パーセントを超える省エネと、素のユニキャストより少ない再バッファリングを実現したと報告しています。
mABRとの重要な対比は、網です。mABRには管理アクセス網と事業者の協力が必要です。ピアツーピアは公共のインターネット上で、デバイスの間で、事業者の関与なしに動きます。それはまさに、mABRが届かない隙間です。トレードオフは、ピアツーピアが十分な数の同時視聴者がいることに依存し、また消費者デバイスのアップロード能力と振る舞いに依存することです。2つのアプローチは互いに排他的ではありません。最終マイルを制御できない放送局は今日からピアツーピアを使え、自前の網を制御する事業者はmABRを使え、大きなプラットフォームは両方に頼ることもできます。
これが事業者にとって意味すること
mABRは万能薬ではなく、新しくもありません。1つの具体的で高くつく問題のための、的を絞った道具です。すなわち、同じライブストリームを管理網上で非常に大きな視聴者へ、コピーごとに支払うことなく届けることです。大きなスポーツの決勝を担う事業者にとって、その問題は現実であり、シーズンごとに悪化します。最終マイルを制御できない純粋なOTTサービスにとって、mABRはISPに支援を求めることはできても、自前では構築できないものです。
正直な要約はこうです。技術は機能し、標準は存在し、展開は現実だが依然として単一ベンダーの専有スタックに集中しており、遅延とデバイスエコシステムは現実の制約として残り、そしてGPACとMotion Spellが主導するオープンソースの参照作業が、その集中を変える最も信頼できる道だ、と。
iReplay.TVは放送とストリーミングのエンジニアの集合体であり、mABR、ピアツーピア、素のユニキャストCDN配信の間のトレードオフは、その members が日常的に天秤にかける類のものです。Multicast ABRはいくつもあるレバーの1つであり、管理網の中でしか役に立ちません。視聴者が開かれたインターネット越しにあなたに届くのなら、節約はどこか別の場所から来なければなりません。ピア支援の配信、より賢いオリジン設計、より良いコーデックの選択、そしてより締まったCDN設定です。自分の数字を見たい人のために、サイトには無料のCDNコスト最適化ツールがあります。
出典とさらに読む
- DVB「Adaptive media streaming over IP multicast」(DVB-MABR仕様ページ): dvb.org
- DVB「DVB-I and DVB-MABR published as ETSI standards」: dvb.org/news
- DVB「DVB publishes updated Multicast ABR specification and guidelines」(2023年の更新): dvb.org/news
- DVB「DVB-MABR Reference Tools」: dvb.org
- GPAC「MABR: Multicast Adaptive BitRate」: gpac.io
- Motion Spell「DVB-MABR Open-Source Tool」(ソースコードリポジトリ): github.com/MotionSpell
- Streaming Video Technology Alliance「The Viability of Multicast ABR in Future Streaming Architectures」: svta.org
- BT Group「BT delivers first successful trial of new live streaming technology」: newsroom.bt.com
- CommScope、Multicast Adaptive Bitrate (MABR) Solution: commscope.com
- IETF: FLUTE (RFC 6726)、ROUTE (RFC 9223)、NORM (RFC 5740)、rfc-editor.orgで入手可能