この記事では、新しいメディアクラスに起因するサービスの開発に関する一連の資料を公開します。 このサービスは、さまざまなプラットフォームでのビデオコンテンツの配信と再生のためのツール、セカンドスクリーンアプリケーション、およびオンラインブロードキャストの消費者の機能を拡張するために設計された他の多くのインタラクティブ製品を含むアプリケーションの大規模なグループです。
このトピックは非常に広範囲にわたるため、新しいメディアサービスの開発について、その基本段階の1つ、つまり、ライブモードでユーザーにビデオコンテンツを配信するプロセスから始めることにしました。 この記事では、ソリューションの全体的なアーキテクチャについて説明します。
すぐに、以下に説明するソリューション（ストーリー自体のような）が目新しさや天才であると主張することはありませんが、トピックは非常に関連性があり、開発は進行中ですので、サードパーティの問題を見るのに非常に役立ちます。
挑戦する
複数のカメラの助けを借りて行われる大規模なイベントは、通常、監督のバージョンで視聴者に提示されます。編集監督は、視聴者に送信される単一の非代替ビデオシーケンスを接着します。
私たちのタスクは、視聴者がインターネット放送を見ながらイベントを見るカメラを選択できるサービスを開発し、イベントの重要な瞬間を確認する機会を提供することです。
図1.一般的なソリューションアーキテクチャ
次のスキームを取得しました。
マスターサーバーは、ブロードキャストソースのブロードキャストステータスを監視し、スレーブサーバー間でストリームを配信します。 スレーブサーバーは、これらのストリームを処理し、結果をマスターサーバーから受信した構成で指定されたストレージに送信します。
ストレージはライブブロードキャストデータをキャッシュし、ストリームをFSに保存します。 マスターサーバー設定では、データ複製、データタイプなど、さまざまなモードでストレージサーバーを設定できます。
図2.クライアントへのブロードキャストの仕組み
負荷を分散するために、負荷スケジューラが使用されます。 バランサーは、システムへのクライアントエントリポイントです。 クライアントにサーバーへのアクセスを提供し、不要または期限切れのリクエストを除外します。 最初の顧客の要求は常にバランサーに向けられます。 バランサーは、設定に応じて、クライアントを許可サーバーにリダイレクトするか、ビデオブロードキャストをサーバーにバインドします。 ユーザーの数に応じて、バランサーの数を増やすことができます。 ロードバランシングのために、個別のインスタンスを使用して履歴フラグメントとオンラインブロードキャストのフラグメントをロードします。
図3.キャッシュ
オンラインブロードキャストの時点で、サーバーはストリームフラグメントをキャッシュしてからストレージに保存します。 クライアントが連絡すると、非同期的にフラグメントを配布します。
クライアントでのビデオフラグメントのバッファリングは、2つのダウンロードキューを使用して発生します。 まず、アクティブストリームのフラグメントがロードされます。 スムーズな再生に最適な数のフラグメントがロードされると、制御は2番目のストリームに転送され、このタイムラインセクションのカメラフラグメントの同期ロードが開始されます。 これにより、カメラを切り替える際のブロードキャスト遅延が回避されます。 切り替え時に、選択したカメラのバッファがメインストリームキューにロードされます。
結論の代わりに
この記事では、放送消費者にリアルタイムでビデオコンテンツの配信サイトを設計するためのアプローチを簡単かつ概略的に説明しようとしました。 次の記事では、結果として何が起こったのかを説明し、大規模な新しいメディアサービスの他の部分（特にクライアント部分）との相互作用について詳しく説明します。
ご清聴ありがとうございました:)