Top Trends in Cybersecurity for 2024 | 
広告費や視聴者が従来のテレビから離れていく中、コンテンツ所有者や放送局は、新しい視聴者を引き付け、オーバーザトップ（OTT）ストリーミングを通じて収益を拡大するために、広告を利用したライブイベントストリーミングを検討してい ます。 OTTは新たな配信機会を提供します。これにより、パブリッシャーは、以前は放送テレビでは存在しなかったライセンスコンテンツを放送し、収益化することができます。 しかし、パブリッシャーがライブイベントのストリーミングを開始する前に、ストリーミングビデオワークフローの最初のステップにおける技術的なハードルを考慮する必要があります。
- Venueと取り込みポイント間の接続品質と帯域幅の可用性は、ワークフローの弱いリンクになる可能性があります。 冗長性と信頼性を組み込む必要があります。
- ライブフィードは、レイテンシを最小限に抑えながら、Apple HLSやMPEG-DASHなどのさまざまな適応型ビットレート形式やプロトコルにエンコードする必要があります。
- アップロードおよびエンコードソリューションは、4Kやその他の高品質フォーマットの出現に対応するために、将来にわたって信頼性と拡張性を備えている必要があります。
- 動画ワークフローは、最高の視聴体験と最適な収益化戦略を実現するために、サーバーサイド広告の挿入をサポートできる必要があります。
このテクノロジーブログでは、パブリッシャーがストリーミングビデオワークフローの最初のステップを最適化できるようにするためにプラットフォームを構築した方法、関連するいくつかの課題、高パフォーマンス、低レイテンシ、広告サポートライブストリーミングを実現するためにライブストリームをエンコードする方法について説明します。
背景：スライサー
エンコーディングの技術的な考慮事項に飛び込む前に、「スライサー」と呼ばれる当社の技術を説明する必要があります。 強力なソフトウェアクライアントであるSlicerは、会場のライブストリームを当社のクラウドビデオプラットフォームにアップします。 柔軟性と機能性を犠牲にすることなく、非常に複雑なタスクを簡素化します。 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ストリームは、最小限の先行投資と低帯域幅要件でライブリニアフィードから生成されます。
帯域幅の最小化
これで、ライセンスについて理解できた と思いますが、ライブストリームをイベントからクラウドに移動するためのフロントエンドソフトウェアコンポーネントを開発する理由を疑問に思うかもしれません。 たとえば、パブリッシャーがRTMP (Real-Time Messaging Protocol)ストリームを送信できないのはなぜですか。 (必要に応じてこれを行うことができますが、ほとんどのお客様はSlicerを利用しています)。その答えは、ライブ会場での帯域幅の問題に対処することと同様に、高品質のライブストリームに対する消費者の期待にも関係しています。 それは多くの競合する要因間で適切なバランスを見つけることの問題です。 一方では、より高品質のフォーマットと4Kを考慮して、元のフィードをできるだけ多く保存する必要があります。 一方、パーソナライズされた広告などの追加のオーバーヘッドによって行き詰まることなく、ストリームを効率的に配信できるように、ストリームを最適化する必要があります。 ビデオワークフローのこのステップでは、適切なバランスを見つけることが重要です。
ここでスライサーが不可欠です。 前述のように、サイトで最高のビットレートプロファイルを作成し、そのプロファイルをクラウドに送信するだけで、特定のフィードに必要な帯域幅を大幅に削減します。 世界中の数十億人の視聴者に数百万時間のライブ映像をストリーミングした結果、はるかに大きなRTMPストリームをクラウドに送信するという代替アプローチでは、視聴体験の品質が大幅に向上することはありません。 しかし、帯域幅が大幅に増加し、コストが増加します。
バックホールコストはすぐに加算されます。 衛星アップリンク、Kaバンドトラックなどを必要とする要件がある場合は、1日あたり約$2,000のレンタル、帯域幅のコストは1時間あたり約$400です。 ホテルやカンファレンスセンターなど、一部の会場では帯域幅に制約があるため、 また、世界中のスポーツ施設でさえ、視聴者に放送のような体験を提供しながら、アップロード帯域幅の要件を可能な限り減らすことが常に推奨されているということです。
エンコードのハードル
ライブビデオフィードが会場を離れると、ワークフローの次のステップはエンコードです。 ここで、ビデオエンコーダは、異なるビットレート、解像度、および品質レベルでオーディオとビデオの複数のバージョンまたはバリアントを作成します。 次に、バリアントを小さなファイルまたはメディアセグメントにセグメント化します。 バリアントのメディアセグメントを指すURLのリストを含む各バリアントのメディアプレイリストを作成するなど、いくつかの追加手順を実行する必要があります。 生成されたマスタープレイリストは、デバイスに最適なバリエーションと、現在測定されている帯域幅または使用可能な帯域幅をプレーヤーが選択したものです。
2つの主要なビデオ・ストリーミング・プロトコルは複雑さを増し、無数の再生デバイスをカバーするためにサポートが必要な場合もあります。 HLSは、Appleによって実装された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形式をサポートする必要があります。 すべてのデバイスで再生できるように、コンテンツを複数の形式でパッケージ化する必要があります。
これが多くのエンコード作業のように聞こえるなら、あなたは正しいです。 解像度が高くなり、コーデックが複雑になると、クラウドでもオンプレミスでも、1台のマシンで完全なABRエンコーディングラダーをエンコードすることが難しくなります。 エンコーディングハードウェアがライブフィードに対応できない場合は、エンコーディングラダーの段の数を減らす必要があり、最終的に視聴者の体験に影響を与える可能性があります。
より複雑なエンコーディング要件に対応するために、従来のモデルでは、生産者は速度と品質を維持するために新しいハードウェアに継続的に投資する必要があります。 最終的には、Edgio（旧称Verizon Digital Media Services）のようなストリーミングサービスでは、1:1のストリームツーエンコーダモデルでは、お客様の期待に応えるために必要な信頼性、柔軟性、拡張性を提供できません。
代わりに、必要な数のエンコーダを使用できる高度な仲介システムを開発し、すべてをクラウドベースのインフラストラクチャで実行しました。 仲介システムはSlicerインスタンスからコンテンツのチャンクを受け取り、最適なエンコーダに移動します。 これにより、エンコードプロセスが特定のマシンに過度の負担をかけることがなくなり、チャンクがシステムを通ってストレージに移動し、視聴者に送信されるようになります。
ブローカープロセスは、クラウドエンコーダインフラストラクチャをシームレスに、さらに重要なことに、自動的にスケールアップします。
私たちの実装では、ブローカーインスタンスはSlicerとエンコーダの間で対話するマネージャーとして機能します。 ブローカーは、新しいSlicerがデータを適切なエンコーダにルーティングし、エンコーダがワークロードを処理できることを確認します。 さらに、非常に優れた拡張インフラストラクチャもあります。 エンコードが必要なVODコンテンツが100万時間も突然廃棄された場合、サーバーインスタンスを迅速に立ち上げ、コンテンツの処理を開始できます。 また、リソースを節約するために迅速にスケールダウンすることもできます。 このブローカープロセスは、クラウドインフラストラクチャ全体をシームレスかつ自動的に管理します。
ステートレスエンコーダ
もちろん、ブローカーシステムは、ライブストリームの要求に追いつくことができるかどうかができる単一のエンコーダをSlicerに向けるだけであれば、限られた価値しかありません。これは4Kの深刻な問題です。 私たちが開発したソリューションには、ステートレスエンコーダの使用が含まれます。 1台のマシンをストリーム全体に割り当てる代わりに、各エンコーダーは一度に2秒または4秒のビデオセグメントを1つだけ受信します。 各セグメントには、エンコーダをプライミングするのに十分な情報が含まれているため、そのセグメントをエンコードし、リードインおよびリードアウト情報など、プライミングに不要なものを廃棄できます。 この時点で、セグメント全体が完了して準備が整い、エンコーダーが解放され、別のチャンネルやその他のコンテンツのエンコードを開始できるようになります。
このモデルには、システムにかなりの冗長性が組み込まれています。 たとえば、セグメントの処理中にエンコーダがクラッシュした場合、同じセグメントが別のマシンで起動し、ストリーム内で問題が発生する前に時間内に完了します。
このアプローチにより、よりコスト効率の高いハードウェアを使用することもできます。 たとえば、遅いマシンでSlicerから4秒のファイルを処理するのに8秒かかることがわかっている場合、以下に示すように、ワークロードを複数のエンコーダに分散できます。サーバーAはスライス1を取得し、サーバーBはスライス2を取得します。 その後、チャンクはすべて予測可能な時間に完了したため、問題なく納品されました。 下の図に示すように、この例では、16 ～ 20秒の遅延が発生します。
クラウドで複数のエンコーダを使用することで、レイテンシーを最小限に抑え、ライブフィードに追いつくことができないサーバーを使用できます。
最終的に、クラウド内のサーバーの量は、個々のサーバーが低速であっても、エンコードプロセスが常にライブの要求に対応できることを意味します。 従来のモデルを使用してエンコードインフラストラクチャをセットアップする場合は、高価な高性能マシンや専用ハードウェアに投資する必要があります。これらのハードウェアは、リアルタイムの支援なしで受信ビデオ全体を処理できます。 クラウドのスケーラビリティを活用することで、エンコーディングコストを大幅に削減します。
ステートレスクラウドエンコーディングのもう1つの利点は、特別なサーバー要件がないため、ワークロードを代替クラウドプロバイダーに簡単に移行できることです。 250 Tbps以上の容量を持つネットワークでは、マルチクラウドアプローチに固有の利点があります。
費用対効果の高いライブストリーミング
ライブコンテンツ制作者にとって、クラウドストリーミング用のライブビデオを準備するための技術的な考慮事項は、手ごわい障害をもたらす可能性があります。 会場の帯域幅の制限から、エンコーダーやストリーミングプロトコルに関する複雑な質問まで、さまざまな問題に直面します。 会場での接続の必要性をなくすことはできませんが、フロントエンドでの帯域幅要件を削減した簡素化されたワークフローにより、視聴者が期待する高品質で低遅延のストリームを配信しながら、先行投資と継続的な支出を大幅に削減できます。
