ブラウザベースのストリーミングビデオ/オーディオ(プログレッシブダウンロードではない)
-
07-07-2019 - |
質問
実際のストリーミングオーディオおよびビデオコンテンツを配信する最良の方法を概念的に理解しようとしています。プロプライエタリなテクノロジーを最小限に抑えて、Webブラウザーでそれを利用したいと思います。私は静的ファイルを提供せず、プログレッシブダウンロードを使用します。これはライブでキャプチャされる実際のオーディオストリームになります。ソースと合理的に同期するストリームをどのようにブロードキャストしますか?どのようなプロトコルが適切ですか?
編集:
研究で、RTSP、HTTPストリーミング、RTMP、およびRTPというプロトコルがいくつかあることがわかりました。
HTTPストリーミングは、何らかのライブパフォーマンス/通信をストリーミングしている場合、TCP(HTTPベース)に依存しており、パケットを失わないため、やや不適切です。低帯域幅の状況では、クライアントは再生でかなり遅れることがあります。 参照
RTMP は独自技術であり、フラッシュメディアサーバーが必要です。その上でクラップ。フラッシュを見た理由は、ユーザーエクスペリエンスに関しては非常に柔軟であるためです。 SoundManager2は、フラッシュでメディアを再生するための優れたJavaScriptインターフェイスを提供します。これは、私がクライアントアプリケーションで探すものです。
RTSP / RTP は、MicrosoftがMMSプロトコルを非推奨にしたものです。 RTSPは制御プロトコルです。 HTTPに似ていますが、いくつかの明確な違いがあります。サーバーはクライアントと通信することもでき、PAUSEなどの追加コマンドがあります。セッションIDで維持されるステートフルプロトコルでもあります。 RTPは、ペイロード(エンコードされたオーディオまたはビデオ)を配信するためのプロトコルです。いくつかのオープンソースプロジェクトがあり、そのうちの1つはアップルこちらでサポートされています。これは私が望んでいることをするかもしれないようであり、ややそれをサポートしているように見えます。 「ライブ」に適しているようです。このページからこちらからブロードキャストします。
ありがとう、 ジョシュ
解決
最初に、間違った2つのポイントをすばやく削除します。以下の詳細:
- RTMPは、Flash Media Server以外のサーバーで実行できます
- TCPはライブで問題ありません。 F.U.D.が多すぎるUDPを愛する人々から。 Appleは簡単なライブストリーミングを行うためのドラフト仕様をリリースしました iPhone用のHTTP(およびTCP)経由。私はそれがブラウザでも終わることを期待しています。また、TCPには企業のファイアウォールをはるかに頻繁かつ簡単に通過できるというボーナスがあります。
私の読んだところによると、複雑でUDPベースのストリーミングは徐々に減少しています。私は死を予測しておらず、市場のシェアはますます低くなっています。 UDPベースのストリーミングサーバーは、TCPベースのソリューション(10倍以上など)に比べて膨大なリソースを消費しますが、そのメリットは具体的なものではありません。
プロプライエタリテクノロジーは不要だと言って、" [Flash]"をたたく、、それでもリアルストリーミングをしたいですか?あなたにそれを破るのは嫌いですが、 RealAudio と RealVideo はどちらも独自仕様です。
もしあなたがオープンソースに行くことが本当に重要であるなら、それは理解できますが、ストリーミングメディア市場の大部分を無視する必要があります。をご覧ください
- Theora :ロイヤリティフリー、オープンスタンダード、損失のあるビデオ圧縮技術
- Vorbis :音声を生成するフリーソフトウェア/オープンソースプロジェクトstrong>形式仕様と非可逆オーディオ圧縮のソフトウェア実装。
- Ogg :無料のオープンな標準コンテナ形式
プラグマティズムがあなたのベストを得るなら、アドビ製品への嫌悪感を再考してください。 Flashは、他のブラウザベースのプレーヤー(Windows Media Player、Quick Time、Real Playerなど)よりも広く配布されていることを忘れないでください。
RTMPは引き続きオープンソースで使用できます。 Red5 はおそらく最も興味深いものです。Flashにライブストリーミングできます。対応ブラウザ。
優先事項について考えることをお勧めします。あなたの質問でそれらを綴ってください。
他のヒント
UDPベースのストリーミングプロトコルは、ファイアウォールまたはNATの背後にある場合に動作するために、多くの場合、さらに複雑になるというStuの回答に追加します。たとえば、自宅の外でWIFIアクセスポイントを使用する場合、これらの多くはUDP配信を使用したRTPをサポートしません。多くのクライアントには、タイムアウト前にパケットが受信されない場合、クライアントがTCP配信を試行するフェイルバックメカニズムがあります。