Top Trends in Cybersecurity for 2024 | 
広告費と視聴者が従来のテレビから遠ざかっているため、コンテンツ所有者と放送局は、新しい視聴者を引き付け、オーバーザトップ（OTT）ストリーミングを通じて収益を拡大するために、広告支援型のライブイベントストリーミングを検討している。 OTTは新たな配信機会を提供し、出版社はこれまでテレビ放送にはなかったライセンスを受けたコンテンツを放送して収益化することができる。 しかし、パブリッシャーがライブイベントのストリーミングを開始する前に、ストリーミングビデオワークフローの最初のステップにおける技術的なハードルを考慮する必要がある。
- 会場とインジェストポイント間の接続品質と帯域幅の可用性は、ワークフローの弱いリンクになる可能性がある。 冗長性と信頼性が組み込まれている必要がある。
- ライブフィードは遅延を最小限に抑えながら、Apple HLSやMPEG-DASHなどのさまざまなアダプティブビットレート形式やプロトコルにエンコードする必要がある。
- アップロードとエンコーディングのソリューションは、4Kやその他の高品質フォーマットの出現に対応するために、将来性、信頼性、拡張性に優れている必要がある。
- 動画ワークフローは、最高の視聴体験と最適な収益化戦略のために、サーバーサイドの広告挿入をサポートできる必要がある。
このテクノロジーブログでは、パブリッシャーがストリーミングビデオワークフローの最初のステップを最適化できるようにするプラットフォームを構築した方法、関連する課題のいくつかを見て、ハイパフォーマンス、低レイテンシ、広告サポートされたライブストリーミングを可能にするライブストリーミングをエンコードする方法について説明する。
背景:スライサー
符号化の技術的な検討に入る前に、「スライサー」と呼ばれる技術について説明する必要がある。 強力なソフトウェアクライアントであるThe Slicerが、会場のライブストリームをクラウド動画プラットフォームにオンランプ。 柔軟性と機能性を犠牲にすることなく、非常に複雑なタスクを簡素化する。 スライサーは、広範な技術リソースを持つ放送局や、何もない放送局が当社のプラットフォームを活用して、強力に差別化されたOTT体験を作成できる主な理由である。
スライサーは、エンコーディング用のコンテンツを準備し、理想的なエンコーディング設定を計算し、広告挿入マーカーを管理する。 安全なハードウェア上でSlicerを実行するか、SDI、IPビデオ、RTP/FEC、RTMPなどのさまざまな形式をサポートするクラウドに依存しない場所のコスト削減とスケーラビリティを選択できる。
Slicerは、コンテンツを小さな断片に分割して暗号化してからISO認定のクラウドエンコーディングスタックに送信するため、コンテンツが常に安全であることを知っていることに伴う安心感を与える。 シンプルなワンクリック設定から、選択したプログラミング言語でのより高度なスクリプト、通知、ジョブ処理、機械学習統合のワークフローをトリガーするクラウド関数の記述まで、柔軟なワークフロー範囲を提供する。
Slicerのバージョンである「Live Slicer」は、ライブイベントストリーミング用に最適化されている。 HD-SDIまたはIPベースのフィードは素早く取り込まれ、2秒または4秒の暗号化セグメントに最高の望ましいビットレートでチャンクされるため、帯域幅要件は1080pでは3～5 Mbps、4Kでは約15 Mbpsに削減される。 当社のプロセスは、プログラムや広告の中断をトリガーしたり、コンテンツを置き換えたりするために、インバンドおよびアウトオブバンドのメタデータとメッセージを自動的に保持する。 プラグインアーキテクチャにより、独自のシグナリングイベント要件を処理するカスタマイズされたスクリプトを作成できる。 Live SlicerはSCTE 35/104メッセージを聞いたり、広告ブレーク、コンテンツ開始、ブラックアウトトリガーを挿入するAPI呼び出しを受信することもできる。
OTTストリームは、最小限の先行投資と低帯域幅要件でライブリニアフィードから生成される。
帯域幅を最小限に抑える
Slicerを理解したところで、ライブストリームをイベントからクラウドに移動するためのフロントエンドソフトウェアコンポーネントを開発する理由を疑問に思うかもしれない。 たとえば、パブリッシャーがRTMP (Real-Time Messaging Protocol)ストリームを介して送信できなかった理由は? (必要に応じてこれを行うことができるが、当社の顧客のほとんどはスライサーを利用している)その答えは、ライブ会場での帯域幅の課題に取り組むことと同様に、高品質のライブストリームに対する消費者の期待に大きく関係している。 それは多くの競合する要因間の正しいバランスを見つけることの問題である。 一方では、より高品質なフォーマットと4Kに目を向けて、可能な限り元のフィードを保存する必要がある。 一方で、パーソナライズされた広告などの追加オーバーヘッドによって行き詰まることなく効率的に配信できるように、ストリームを最適化する必要がある。 適切なバランスを見つけることは、ビデオワークフローのこのステップにとって重要である。
スライサーが不可欠なのはここだ。 前述したように、サイト上で最高のビットレートプロファイルを作成し、そのプロファイルをクラウドに送信するだけで、フィードに必要な帯域幅を大幅に削減する。 世界中の数十億人の視聴者に数百万時間のライブ映像をストリーミングすることに基づいた私たちの観察では、大幅に大きなRTMPストリームをクラウドに送信する代替アプローチは、視聴体験の質を著しく向上させることはできない。 しかし、帯域幅が大幅に増加し、コストが増加する。
バックホールコストはすぐに加算される。 あなたの要求が衛星のアップリンク、Kaバンドトラック、例えば、1日あたりの$2,000のための賃料および帯域幅の費用約$400 1時間を必要とするようなものであれば。 ホテルやカンファレンスセンター、さらには世界中のスポーツ会場など、一部の会場では帯域幅に制約があるため、視聴者に放送のような体験を提供しながら、アップロード帯域幅の要件を可能な限り削減することが常に良い考えである。
エンコーディングのハードル
ライブビデオフィードが会場から出ると、ワークフローの次のステップはエンコードである。 ここでは、ビデオエンコーダが異なるビットレート、解像度、品質レベルでオーディオとビデオの複数のバージョンまたはバリアントを作成する。 次に、バリアントを小さなファイルまたはメディアセグメントにセグメント化する。 バリエーションのメディアセグメントを指すURLのリストを含む各バリエーションのメディアプレイリストを作成するなど、いくつかの追加ステップを実行する必要がある。 結果として生成されるマスタープレイリストは、デバイスと現在測定されているまたは利用可能な帯域幅に最適なバリアントのプレイヤーの選択である。
2つの主要なビデオストリーミングプロトコルが複雑さを増す一方で、潜在的な再生デバイスの無数をカバーするためには他のプロトコルもサポートする必要があるかもしれない。 HLSは、アップルが実装したHTTPベースのストリーミングプロトコルである。 すべてのAppleデバイスと、ほとんどのGoogle、Android、Linux、Microsoftのブラウザとデバイスをサポートする。 全てではないがほとんど また、競合するHTTPベースのメディアストリーミングプロトコルであるMPEG-DASHも必要である。 ゲーム機用のMicrosoft Smooth Streamingのサポートを追加する必要がある場合もある。
DRMはまた、多数の視聴者の要件をサポートするために独自の複数のフォーマットのセットを必要とすることで、エンコーディングを複雑にすることができる。 例えば、DRMをサポートしていない年配のプレイヤーはHLSとAES-128を必要とする。 古いiOSデバイスにはHLSとFairPlayが必要。 新しいiOSデバイスはHLS、FairPlay、CMAF CBCをサポートしている。 古いWindowsとAndroidはCMAF CTRのみをサポートしている。 新しいAndroid、Windows、iOSはすべてのCMAF形式をサポートする必要がある。 すべてのデバイスで再生できるように、コンテンツを複数の形式でパッケージ化する必要がある。
これがエンコード作業の多くのように聞こえるならば、あなたは正しい。 解像度が高くなりコーデックが複雑になると、クラウドでもオンプレミスでも、単一のマシン上で完全なABRエンコーディングラダーをエンコードすることが難しくなる。 エンコーディングハードウェアでライブフィードに追いつくことができない場合は、エンコーディングラダーのラング数を減らす必要があり、最終的に視聴者の体験に影響を与える可能性がある。
より複雑な符号化要件に対応するために、従来のモデルでは生産者は速度と品質を維持するために新しいハードウェアに継続的に投資しなければならない。 最終的に、Edgio (旧Verizon Digital Media Services)のようなストリーミングサービスでは、1:1ストリームからエンコーダへのモデルでは、顧客の期待に応えるために必要な信頼性、柔軟性、拡張性を提供できない。
その代わりに、我々はクラウドベースのインフラストラクチャ上で実行されるエンコーダを必要なだけ使用できる高度な仲介システムを開発した。 仲介システムは、スライサーインスタンスからコンテンツのチャンクを受け取り、最適なエンコーダに移動する。 この動作は、エンコーディングプロセスが特定のマシンに過大な負荷をかけるのを防ぎ、チャンクがシステム内を通ってストレージに移動し、ビューアに移動し続けるようにする。
ブローカープロセスは、クラウドエンコーダインフラストラクチャをシームレスに、さらに重要なことに、自動的にスケールアップする。
我々の実装では、ブローカーインスタンスはスライサーとエンコーダの間で対話するマネージャーとして機能する。 ブローカーは、新しいスライサーがデータを適切なエンコーダにルーティングすることを保証し、エンコーダがワークロードを処理できることを検証する。 さらに、非常に能力の高いスケーリングインフラストラクチャを備えている。 もし、突然100万時間分のVODコンテンツをエンコードしなければならない場合、サーバーインスタンスを迅速に立ち上げ、コンテンツの処理を開始することができる。 また、資源を節約するために、同じくらい迅速に規模を縮小することもできる。 このブローカープロセスは、クラウドインフラストラクチャ全体をシームレスに管理し、さらに重要なことに、自動的に管理する。
ステートレスエンコーダ
もちろん、ライブストリームの需要に追いつくことができるかどうかを問わず、スライサーを単一のエンコーダーに向けるだけで、仲介システムの価値は限られているだろう。4Kの深刻な問題である。 私たちが開発したソリューションは、ステートレスエンコーダを使用することである。 ストリーム全体に1つのマシンを割り当てるのではなく、各エンコーダーは一度に2秒または4秒のビデオセグメントを1つだけ受け取る。 各セグメントにはエンコーダをプライミングするのに十分な情報が含まれているため、そのセグメントをエンコードし、リードインやリードアウトの情報など、プライミングに不要なものを破棄できる。 この時点で、完全なセグメントが完成して準備が整い、エンコーダーが解放されて、別のチャンネルや他のチャンネルからの別のコンテンツのエンコードを開始できるようになる。
このモデルはシステムにかなりの冗長性が組み込まれている。 例えば、あるセグメントの処理中にエンコーダがクラッシュした場合、同じセグメントが別のマシンで起動し、ストリーム内で問題が発生する前に完了する。
このアプローチにより、より費用対効果の高いハードウェアを使用することも可能になる。 例えば、遅いマシンがスライサーから4秒のファイルを処理するのに8秒かかることがわかっている場合、以下に示すように、ワークロードを複数のエンコーダーに分散させることができる。 その後、チャンクはすべて予測可能な時間に完了したため、問題なく配信された。 下のチャートに示すように、この例では、ライブの後に16-20秒の遅延が生じる。
クラウドで複数のエンコーダーを使用することで、遅延を最小限に抑え、ライブフィードに追いつくことができないサーバーの使用を可能にする。
最終的に、クラウド内のサーバーの量は、個々のサーバーが低速であっても、エンコードプロセスが常にライブの需要に追いつくことができることを意味する。 従来のモデルを使用してエンコーディングインフラストラクチャを設定したい場合は、高価な高性能マシンや特殊なハードウェアに投資する必要があり、それぞれがリアルタイムの支援なしに受信したビデオ全体を処理できる。 クラウドのスケーラビリティを活かし、エンコーディングコストを大幅に削減。
ステートレスクラウドエンコーディングのもう1つの利点は、専用のサーバー要件がないため、ワークロードを代替クラウドプロバイダーに簡単に移行できることである。 250 Tbps以上の容量を持つネットワークでは、マルチクラウドアプローチは固有の利点を提供する。
費用対効果の高いライブストリーミング
ライブコンテンツ制作者にとって、クラウドストリーミング用のライブビデオを準備するための技術的な考慮事項は、恐ろしい障害をもたらす可能性がある。 会場の帯域幅の制限からエンコーダやストリーミングプロトコルに関する複雑な質問まで、さまざまな問題に直面する。 会場での接続が不要になるわけではないが、フロントエンドの帯域幅要件を低減したシンプルなワークフローにより、視聴者が期待する高品質で低遅延のストリームを配信しながら、初期費用と継続的な費用を大幅に削減できる。
