低遅延（2秒未満）ライブビデオストリーミングHTML5ソリューション？
ChromeでデフォルトでFlashを無効にするとすぐにflash/rtmp html5置換ソリューションの調査を開始する必要があります。
現在、Flash + RTMPでは、1〜2秒未満の遅延のライブビデオストリームがあります。
ストリーミングの新しい業界標準であると思われるMPEG-DASHを試してみましたが、5秒の遅延が絞り出せる最高のものでした。
コンテキストでは、ユーザーがストリーム上で見ることができる物理オブジェクトを制御できるようにしようとしています。そのため、数秒を超える遅延はイライラするエクスペリエンスにつながります。
他のテクニックはありますか、それともライブストリーミング用の低レイテンシhtml5ソリューションはまだありませんか？
技術と要件
WebRTCは、低遅延に本当に適した唯一のWebベースのテクノロジーセットです。ビデオ会議用に構築されています。コーデックは、品質よりも待ち時間が短くなるように調整されています。ビットレートは通常可変であり、品質よりも安定した接続を選択します。
ただし、必ずしもすべてのユーザーにこの低レイテンシの最適化が必要なわけではありません。実際、私があなたの要件について収集できることから、すべての人の待ち時間が短いとユーザーエクスペリエンスが損なわれます。ロボットを制御しているユーザーは、合理的に制御できるように低レイテンシーのビデオを確実に必要としますが、制御していないユーザーにはこの要件はなく、代わりに信頼性の高い高品質のビデオを選択できます。
設定方法
ロボット接続へのインコントロールユーザー
ロボットを制御するユーザーは、カメラと制御サーバーに接続するためにいくつかのWebRTCコンポーネントを利用するページをロードします。 WebRTC接続を容易にするには、ある種のSTUNサーバーが必要です。 NATおよびその他のファイアウォールの制限を回避するには、TURNサーバーが必要になる場合があります。これらは通常、Node.jsベースのWebRTCフレームワークに組み込まれています。
Cam/controlサーバーもWebRTC経由で接続する必要があります。正直なところ、これを行う最も簡単な方法は、制御アプリケーションをある程度Webベースにすることです。 Node.jsを既に使用しているため、 NW.js または Electron を確認してください。どちらも、WebKitに既に組み込まれているWebRTC機能を利用できますが、Node.jsで何でも好きなことを行うことができます。
制御中のユーザーとカム/制御サーバーは、WebRTC（または必要に応じてTURNサーバー）を介してピアツーピア接続を確立します。そこから、メディアチャンネルとデータチャンネルを開きます。データ側を使用して、ロボットコマンドを送信できます。もちろん、メディアチャネルは、制御されていないユーザーに送り返される低遅延のビデオストリームに使用されます。
繰り返しになりますが、送り返されるビデオは、品質ではなくレイテンシーに対して最適化されることに注意することが重要です。この種の接続は、コマンドへの高速応答も保証します。
ユーザーを表示するためのビデオ
単にストリームを表示しているだけで、ロボットを制御していないユーザーは、通常のビデオ配信方法を使用できます。実際には、既存のCDNとトランスコーディングサービスを使用することが非常に重要です。ストリームを視聴している人は1万人から1万人です。多くのユーザーがいるので、おそらく2、3の異なるコーデック、そして確かにビットレートの配列でビデオを欲しくなるでしょう。 [〜＃〜] dash [〜＃〜] または [〜＃〜] hls [〜＃〜] を使用した配布は、現時点での作業が最も簡単で、解放されますあなたのフラッシュ要件。
また、おそらくあなたのストリームをソーシャルメディアサービスに送信したいと思うでしょう。これは、高品質のHDストリームから始めることが重要であるもう1つの理由です。これらのサービスはビデオを再びトランスコードし、品質を低下させます。最初に高品質から始めた場合、最終的にはより良い品質になります。
メタデータ（チャット、制御信号など）
要件からどのようなメタデータが必要かは明確ではありませんが、小さなメッセージベースのデータには、Socket.IOなどのWebソケットライブラリを使用できます。これをいくつかのインスタンスにスケールアップすると、 Redis などのpub/subを使用して、サーバー全体にメッセージングを分散できます。
メタデータをビデオと同期するかどうかは、そのメタデータの内容と、具体的には同期要件に少し依存します。一般的に言えば、ソースビデオとクライアントの間に合理的だが予測不可能な遅延があると想定できます。結局、バッファする時間を制御することはできません。接続変数ごとにデバイスが異なります。想定できるのは、クライアントがダウンロードした最初のセグメントから再生が始まるということです。つまり、クライアントがビデオのバッファリングを開始し、2秒後に再生を開始すると、ビデオは最初の要求が行われた時点から2秒遅れます。
再生が実際にクライアント側で開始するタイミングを検出することは可能です。サーバーは、ビデオがクライアントに送信されたタイムスタンプを知っているため、ビデオ再生の開始に対するオフセットをクライアントに通知できます。おそらくDASHまたはHLSを使用し、MCEをAJAXで使用してデータを取得する必要があるため、 セグメント応答で応答ヘッダーを使用 セグメントの開始のタイムスタンプを示すために、クライアントはそれ自体を同期することができます。
- クライアントは、アプリケーションサーバーからメタデータメッセージの受信を開始します。
- クライアントはCDNから最初のビデオセグメントを要求します。
- CDNサーバーはビデオセグメントで応答します。応答ヘッダーでは、
Date:ヘッダーは、セグメントの開始の正確な日付/時刻を示すことができます。 - クライアントは応答を読み取ります
Date:ヘッダー（たとえば2016-06-01 20:31:00）。クライアントはセグメントのバッファリングを継続します。 - クライアントは通常どおりバッファリング/再生を開始します。
- 再生が始まります。クライアントはプレーヤーでこの状態の変化を検出でき、
00:00:00ビデオプレーヤーの実際の2016-06-01 20:31:00。 - クライアントは、ビデオと同期したメタデータを表示し、以前の時間からのメッセージをドロップし、将来の時間のためにバッファリングします。
これにより、ニーズが満たされ、今後の動画で必要なことを何でも行える柔軟性が得られます。
なぜ[magic-technology-here]ではありませんか？
- 低遅延を選択すると、品質が低下します。品質は利用可能な帯域幅に由来します。帯域幅の効率は、エンコード時に画像シーケンス全体をバッファリングおよび最適化できることから得られます。完全な品質（各画像にロスのない）が必要な場合は、1トン（視聴者あたりのギガビット）の帯域幅が必要になります。そもそもこれらの不可逆コーデックがあるのはそのためです。
- 実際にほとんどの視聴者に低レイテンシーを必要としないため、視聴者の品質を最適化する方が良いでしょう。
- 低レイテンシを必要とする15,000人のうち2人のユーザーに対して、低レイテンシを最適化できます。彼らは標準以下のビデオ品質を取得しますが、ロボットを積極的に制御することができます。
- インターネットは敵対的な場所であり、期待どおりに機能するものは何もないことを常に忘れないでください。システムリソースと帯域幅は常に変化します。それが実際に、WebRTCが条件の変化に合わせて自動調整（可能な限り最適）する理由です。
- すべての接続が低遅延要件に対応できるわけではありません。これが、すべての低遅延接続でドロップアウトが発生する理由です。インターネットは回線交換ではなく、パケット交換です。使用可能な実際の専用帯域幅はありません。
- 大きなバッファー（数秒）を使用すると、クライアントは瞬間的な接続の損失を乗り切ることができます。アンチスキップバッファを備えたCDプレーヤーが作成され、非常に売れた理由です。ビデオが正常に機能する場合、15,000人のユーザーにとってははるかに優れたユーザーエクスペリエンスです。メインストリームより5〜10秒遅れていることを知る必要はありませんが、ビデオが1秒おきにドロップアウトするかどうかは確実にわかります。
どのアプローチにもトレードオフがあります。ここで説明したことは、懸念事項を分離し、各領域で最良のトレードオフを提供すると思います。明確化を求めるか、コメントでフォローアップの質問をしてください。
まだ準備ができていませんが（できれば今年の後半）、 DASH over Full Duplex HTTP-based Protocols を使用すると、DASH（オープンソース、 ABR、互換性...）、および他の形式の低レイテンシ（たとえば、WebRTC、 safari btwでは機能しません ）。
それで、今から数ヶ月後に低レイテンシーのビデオフォーマットを検討している人は、これに注目してみてください。
WebRTCを選択してください。
WebRTCは、ブラウザベースのリアルタイム通信をサポートする標準です。もともとGoogleによって開発されたこの標準は、現在W3Cによって管理されています。 WebRTCは、互換性のあるブラウザー以外の外部プラグインを必要とせずに、音声通話、ビデオチャット、およびファイル共有のためのブラウザー間アプリケーションを可能にします。
利点：
- WebRTCソリューションは、企業の枠を超えて、リアルタイム統合コミュニケーション（UC）を、WebRTC対応ブラウザを備えた顧客、パートナー、またはサプライヤに拡張するのに役立ちます。
- WebRTC対応テクノロジーにより、モバイルネットワークオペレーターはモバイルデバイスでより魅力的なカスタマーエクスペリエンスを作成できます。たとえば、モバイルオペレータが提供するアプリに音声またはビデオ機能を追加すると、加入者はカスタマーサービス担当者に連絡して、よりパーソナライズされたサポートを受けることができます。
- WebRTCは、ユーザーがユニファイドコミュニケーションクライアントを開く必要をなくすことにより、エンタープライズITの展開とサポートのコストを削減します。同時に、WebRTCを使用すると、通信事業者や開発者は、限られた/基本的な開発リソースでWebRTC対応のコミュニケーションおよびコラボレーションアプリケーションを作成できます。
- WebRTCは、オープンスタンダードとブラウザの使用により、ビデオコラボレーションと共有のためにファイアウォールを越えてユーザーを拡張する複雑なシステムの必要性を排除します。場合によっては、WebRTCは、顧客と見込み客が必要な情報をすばやく取得できるようにすることで、全体的な販売サイクルを実際に短縮できます。
WebRTC テスト中