メインコンテンツへスキップ
見出し画像

[Inter BEE 2025]展示会場では説明しきれなかったクラウドメディアワークフロー展示について書いてみました!

    今年も Inter BEE に出展!

    みなさんこんにちは!
    映像配信の話@IIJ 中の人の一人、ワタナベです。

    IIJは今年も国内最大級のメディア総合イベント「Inter BEE 2025」に参加しました。
    しっかりPRできておらずあまり知られていないのが残念ですが、IIJの出展は2014年の初出展から10回目となり、ISPとしてこれほど長く放送関係の展示会に参加しているのはIIJだけで、いまだに会場でも「なんでIIJが Inter BEEに?」とコメントいただく程度には「浮いている」存在かもしれません。

    もう10回目ですけど。

    画像
    Inter BEE 2025 IIJブース

    それでもイベントではIIJをご存知だったりSIMをご利用いただいている方が、「IIJが Inter BEEでどんなことをやってるんだろう?」と興味を持って立ち寄ってくださり「ユーザーです!」と伝えてくださるのは本当に嬉しいですね。
    ありがとうございます!

    出展の概要についてはこちらの記事をご覧ください。

    10回目のテーマ

    IIJが初めてInter BEEに参加した時のテーマは「4Kへの取り組み」でした。
    当時はそれが最先端と言えるものだったんですね。
    そして記念すべき?10回目の参加となる今年は

    • MoIP実現のための様々な取り組み

    • クラウドメディアワークフロー

    • 配信技術

    • 伝送技術

    という4つのテーマを設けて展示しました。

    本来は4つとも説明できればと思うのですが、出展内容全体をカバーしようとすると膨大な量になってしまうため、今回はその中で「クラウドメディアワークフロー」の展示内容にフォーカスしてお話させていただきます。

    今回は少し技術寄りのお話になります。

    「クラウドメディアワークフロー」

    「クラウドメディアワークフロー」はIIJのサービス名でもソリューション名でもありません。
    あくまでも展示の内容をわかりやすく伝えるために選んだ「テーマ」です。

    このテーマのもと、IIJの強みである「国内&国際バックボーンネットワーク」と「自社保有クラウドインフラ」を組み合わせて様々なアプリケーションを活用することで、より簡易に構築・利用できるIPベースの「メディアワークフロー」を展示しよう、というのが目的でした。

    画像
    IIJ バックボーンネットワーク
    https://www.iij.ad.jp/company/backbone/

    ワークフローのIP化というとST2110を用いたリモートプロダクションが代表的な例として挙がりますが、回線コストや構築コストなどがネックとなり、大規模な導入には至っていないのが現状です。
    また、いかにクラウドが便利とはいえ、一社のサービスに頼りきりになる状況もかなり不安が残ります。

    そこで今回の展示では、よりクラウドに親和性の高いシナリオを想定しクラウド上で実現できる利便性の高いワークフローの提案という形にすることで、訴求力がある展示にできればと考えました。

    国内、国外どこからの映像ソースにも対応、映像の入力からルーティング、モニタリングや品質チェック、そしてプレイアウトに至るまで様々なアウトプットを容易にしようというものです。

    そして何よりIIJが持つバックボーンネットワークを経由させることで、国際間の映像伝送も安定的に行うことができる、ということを来場者の皆様にご覧いただけたのではないか、と思います。

    取り組み

    ここから実際に構築した内容についてお話ししていきます。

     IIJ GIOとネットワーク

    まずはインフラについてです。
    今回インフラとして利用したのは、IIJが開発・提供する国産IaaS「IIJ GIOインフラストラクチャーP2 Gen.2(以下、IIJ GIO P2 Gen.2)」です。
    IIJ GIO P2 Gen.2には「IIJ GIO P2 Gen.2 フレキシブルサーバリソース(以下、FSR)」と「IIJ GIO P2 Gen.2 デディケイテッドサーバリソース(以下、DSR)」という2種類のサービスがあり、用途に応じてご契約・ご利用いただけます。

    画像
    IIJ GIO P2 Gen.2の2種類のサーバリソース
    https://www.iij.ad.jp/biz/p2-gen2/

    それぞれの特徴としてFSRは最小1vCPU/4GBメモリという仮想リソース単位で契約可能で用途に応じて自由なサイズの仮想マシンを作成できるVMwareベースのサービスであり、DSRはvSphere ESXiサーバ単位で契約できるVMware仮想化プラットフォームです。
    サービスについての詳細はこちらからご覧いただけます。

    それぞれのメリットとして、FSRはハイパーバイザーの管理が不要で利用者の運用負荷を大幅に軽減でき、DSRはVMware vCenter Serverを管理者権限付きで提供するため、オンプレミスのVMware環境と同等のものとして利用できるといった特徴があります。

    そしてDSR/FSR上に構築したインスタンスをInter BEE会場と接続し、プライベートなメディア環境を構築しました。
    会場からはIIJが開発・販売しているSEILというルーターを使い、データセンターを経由しDSR/FSR各インスタンスへ接続し、FSR/DSR間の通信やロンドン、ニューヨークのGIOとも接続し、バックボーンを介して通信が行える環境を用意しました。

    画像
    Inter BEE 2025 - IIJ DSR/FSRそしてバックボーンを経由しEU/USの拠点などと接続

    また、今回のデモでは様々なアプリケーションをそれぞれFSR/DSR上に構築して動作検証や拠点間の伝送時間の計測なども行いました。
    メディアを扱う場合、アプリケーションによってはそれなりのスペックが要求されることも珍しくないためです。

    さらに日本だけではなく、ロンドン、ニューヨークにもIIJ GIO P2 Gen.2を立ち上げ、それらをバックボーンで繋ぎ、映像伝送が可能なようにしました。

    画像
    Inter BEE 2025 - Media Cloud 構成イメージ

    上の構成図内に記載していますが、IIJ GIO P2 Gen.2上にメディアワークフローで使う様々なアプリケーションをインストールしてデモを行いました。
    以下、今回のデモで利用したサービスを列挙します。

    記載されているサービス名・商品名等は、各社の登録商標または商標です。画面イメージの画像の無断転載は固くお断りします。

    映像ルーティング[Media Stream Router]

    映像ルーティングはNTTテクノクロス社の「メディアストリームルーター」を使わせていただきました。
    「メディアストリームルーター」は後述するSRTのConnection Bondingにも対応したソフトウェアベースのIPストリームルーターで、今回東京、ロンドン、ニューヨークの環境にインストールして中継点として利用しました。

    画像
    NTTテクノクロス [Media Stream Router]
    入力された映像をどこに出力するかをマトリクスで管理

    プロトコル変換[Cambria Stream Manager & Cambria Stream]

    プロトコルやフォーマット変換はカペラシステムズ社の「Cambria Stream」を利用しました。
    基本はライブストリーム用のスケーラブルなパッケージングアプリケーションですが、モニタリングや映像・音声を個別に扱うといった柔軟性を備えています。

    画像
    Capella Systems [Cambria Stream Manager & Cambria Stream]
    Cambria Stream Managerで複数のCambria Streamを管理運用

    QoE&QoS[VB220 / HACOBE-CLOUD]

    映像品質のチェックはネットワークエレクトロニクスジャパン株式会社のご協力によりBridge Technologies社の「VB220」と株式会社トラフィック・シムのご協力により「HACOBE-CLOUD」を利用させていただきました。
    VB220はQoE(Quality of Experience)やQoS(Quality of Service)の改善のためのIPおよびTSアナライザーです。VB220はソフトウェアベース、VB330はソフトウェアorアプライアンス、そしてVB440はアプライアンスで、チェックするストリームの種類や数によって使い分けが想定されているようです。
    HACOBE-CLOUDはクラウド上で流れるTSアナライザでHACOBE 2+のクラウド版という位置付けのサービスで、PIDやコーデックなどのチェック、項目を選択してストリームの監視も可能です。
    ワークフローの中継ポイントなどでも容易にストリームのチェックが可能になります。

    画像
    Bridge Technologies [VB220]
    画像
    Traffic Sim [HACOBE-CLOUD]

    プレイアウト[VIPE]

    FASTなどで活用できるプレイアウトはBCNEXXT社のご協力により「VIPE」を利用させていただきました。
    Live映像入力、動画ファイルによるFAST、広告枠挿入など多彩な機能を持つプレイアウトのためのサービスです。
    2025年春に行われた「東京・春・音楽祭」のライブ配信でもこのサービスを活用して配信を行った実績もあります。

    画像
    BCNEXXT [VIPE]

    マルチビューア[MCM-9000]

    映像監視のサービスとしてはデジキャス合同会社のご協力によりTAG Video Systems社の「MCM-9000」を動かしています。
    複数のストリームをマルチビューで表示し、レイアウトや表示する項目も自由に編集可能で、多数の異なるフォーマットのストリームも一元監視することも可能です。

    画像
    TAG Video Systems [MCM-9000]

    簡易FASTソリューション

    24/365でコストを抑えてYouTubeなどへ配信可能なソリューション
    IIJ GIO P2 Gen.2に動画ファイルをアップロードするだけで、24/365でYouTubeや様々なOTTサービスに向けてライブ配信を可能にする環境も実験的に構築しています。

    画像
    動画ファイルをアップロードするだけですべての動画を24/365でループ配信
    簡易的なFASTサービスを低コストで実現可能

    これらのサービスとともにデモを行いました。

    ベルリンからの国際映像伝送とSRT

    ワークフローができても、映像ソースが無いと話になりません。
    今回のInter BEEでは、海外からの映像伝送のためにIIJとストリーミングパートナー契約を結んでいるBerlin Phil Mediaに伝送用の映像とイベント期間中ベルリンからのライブ配信をお願いしたところ、Inter BEEのためだけのスペシャルな映像を作ってくれました。
    国際映像伝送のデモとしては、ベルリン・フィルハーモニーのホールから4K 60p HEVC 30Mbps / ステレオ×4chという品質で映像を主副2本SRTで送ってもらいつつ、主系のストリームをさらにSRTのグループモード(Connection Bonding)で伝送し、会場のディスプレイで途切れることなく流していました。

    画像
    Inter BEE 2025 Connection Bonding イメージ

    SRT Connection Bonding

    今回のデモでは基本的にSRTというプロトコルを使用し映像を送っています。
    SRTはオープンソースであり、低遅延で安定した伝送が可能で、FEC(前方誤り訂正)でパケットのリカバーもできるプロトコルで、IIJでもライブ配信等で利用しています。
    そんなSRTに数年前SRT v1.5としてConnection Bondingという仕様が発表されました。

    あまり情報が多く無いのですが、実はこのConnection BondingによってST2022-7のようなヒットレス・フェイルオーバーをSRTのみで実現可能になります。
    現在2つのモード(Main/BackupとBroadcast)が定義・実装されており、今回はデモとしてBroadcastモードを利用しました。

    ここで少しだけこのSRT Connection Bondingで利用可能なモードについて説明させてください。

    Main/Backupモードでは片方がアクティブな時、別のルート(2つ以上でも可)による伝送は待機(stand-by)状態になり、Main側にトラブルが起きた、または起きると予測された場合に即座にBackup側に切り替えて伝送を継続することが可能です。そのためある程度信頼性の高いMain回線があり、伝送コストやトラフィックを抑えたいような場合に利用するものとされています。また現時点では「Pre-emptive switch」のみ実装されているようです(2025年11月時点)。これは何かしらの予兆を検知し切り替える機能です。たとえばMain回線のresponse timeが不安定になり任意の閾値を超えるような事象が発生した時にMain回線をunstableであると判断し、スタンバイ中のBackup回線をactiveに切り替えて最短でBackup側へ乗り換えます。ただし閾値の設定やネットワーク次第なところもあり切り替え時にパケットロスなどが発生してしまう可能性はあります。また将来的に「Mainが切れたらバックアップに切り替える」というシンプルな「Handover switch」が実装される可能性もあるようです。
    そしてBroadcastモードは、設定したすべてのルートに同じ映像を流し、一つのルートでジッタやパケットロスが発生しても受信時に別のルートで受信したデータを利用して修復することが可能なモードで、修復された正常なストリームを出力すると同時に不要になった冗長パケットは受信側で破棄します。Broadcastモードであれば設定されたルートのどれかが切断されたとしても、他のルートが一つでも繋がっていればヒットレス・フェイルオーバーが可能です。ただし、設定されたすべてのルートにストリームを送り、受信側で冗長パケットはすべて破棄されることになるため、オーバーヘッドが非常に大きくなります。
    InterBEEではバックボーンを活用できることもありBroadcastモードでのデモを行い、ベルリンからの映像を数週間エラーが全くないストリームとして受信することができました。

    ST2022-7と比較すると比較的安価に実現できる可能性が高いこともあり、SRTというプロトコルがさらに利用しやすくなったのではと考えています。

    そしてSRTというプロトコルの特性とConnection Bondingによって、国際映像伝送というとどうしても衛星中継というイメージがまだ強い中、IPストリームでも高品質で安定した伝送が可能であることを実証できたと考えています。(少なくとも天候には左右されないです。)
    また、今回の国際間映像伝送の遅延については、厳密な意味でEnd to Endの数値は計測していないのですが、SRTのConnection Bondingのためのバッファなどを考慮しつつ、日本側では余裕を持って1000msで設定していました。

    今後

    Inter BEEでの展示に向けて実際に映像を送受信するための環境構築を経て、放送に利用可能な高品質な映像の長距離映像伝送を実現する手段において、IP伝送も十分検討できるレベルになっていると感じています。
    ただ、実用に向けてはさらにテストを重ねていく必要があり、利用するエンコーダーやネットワーク環境によってはトラブルが発生する可能性もないとは言えません。

    また、より精緻なEnd to Endの時間の計測、TR 101 290によるストリームの確認などもできればと思います。

    近い将来IPによる伝送が浸透していくことは間違いなく、今回の展示でいただいたご意見や得られた知見をもとに、より安定した、利便性、コストパフォーマンスの高いクラウド上のメディアワークフローの提供に向けて、進んでいきたいと考えています。

    最後に

    今回のメディアワークフローの展示にご協力いただいた各社様に感謝申し上げます。

    (順不同、敬称略)

    また、このイベントのために素晴らしい映像を作成し、長期間にわたり映像を配信してくれたBerlin Phil Mediaに改めて感謝申し上げます。

    イベントや本記事に関するお問い合わせ

    お問合せ先

    株式会社インターネットイニシアティブ
    放送システム事業部
    担当:haishin-exh-info@iij.ad.jp


    あなたへのおすすめ