例として、HTMLページ内からのメディアのストリーミング

Question

したがって、私はソフトウェアエンジニアであり、ストリーミングメディアのしくみに関する重要な詳細を理解しようとしています。私は、自分のアプリケーションに関連するさまざまなコーデック、コンテナー形式、およびストリーミングプロトコルを理解するために、その日の大部分を費やしてきました。これまでのところ、それがどのように機能するかについての私の理解です。

ストリーミングメディアは、実際にはコンテナ形式およびストリーミングプロトコル：[に要約されます。 ____。]
- すべてのオーディオデータは（オーディオコーデックを介して）オーディオビットストリームにエンコードされます。
- すべてのビデオデータは（再度、コーデックを介して）ビデオビットストリームにエンコードされます。
- 2つのストリームは、（multiplexed？）がcontainerにマージされ、最終的にファイル（このようなMP4など）
- 次に、特別なメディアサーバーがこのコンテナ（MP4ファイルまたはその他の形式）をクライアント（おそらく誰かのブラウザ内で実行されているHTML5ビデオプレーヤー）に配信します。 RTSP などのいくつかの標準ストリーミングプロトコル
  - ブラウザークライアントの場合、ブラウザー自体にRTSPクライアントがあり、それが何らかの形でユーザーにHTML5ビデオプレーヤーに提示されると思います
IcouldnginxなどのwebサーバーからMP4ファイルをホストしますまたはhttpd、ただしこれらのサーバーはRTSPサーバーではないため、MP4へのリクエストはダウンロードリクエストとしてのみ扱うことができるため、メディアファイルをストリーミングできません
- 同様に、curlを使用してnginxサーバーからファイルをフェッチすると、curlもnginxもRTSPを話さないため、ファイルのダウンロードとして扱われます。
しかし、ストリーミングメディアサーバー（VideoLAN、Red5、Wowzaなど）からMP4ファイルをホストし、RTSPクライアント（またはサポートされているストリーミングメディアクライアント）を使用してそのサーバーからのストリームを要求するとそのときだけ実際のストリーミングが発生します
- したがって、YouTubeまたはVimeoの「ビデオ」は、HTTPサーバーによってHTTP（S）で提供されるHTMLページでホストされていますが、それらのページに埋め込まれたビデオプレーヤー（ビデオが実際に再生される場所）であると想定していますストリーミングサーバーへの2番目の接続を実際に開始しており、RTSPまたはその他の非HTTPプロトコルを介してストリーミングが行われている

それが私の理解です、そして私が最初に私が上で述べた何かが間違っているなら私を訂正することから始めてくださいと私は最初に尋ねると思います！私は多かれ少なかれ正しいと仮定します：

HTMLページ内で実行され、HTMLサーバーによって提供されるストリーミングメディアプレーヤーは、どのようにして（RTSPリクエストを処理する）ストリーミングメディアサーバーとのストリーミング（RTSPなど）接続を確立しますか？

Pimp Juice IT · Accepted Answer

HTMLページ内で実行され、HTMLサーバーによって提供されるストリーミングメディアプレーヤーは、どのようにして（RTSPリクエストを処理する）ストリーミングメディアサーバーとのストリーミング（RTSPなど）接続を確立しますか？

一般的なアプリケーション

[〜＃〜] rtsp [〜＃〜] は現在、アプリケーション/デバイスインターフェイスで直接使用されているようですライブストリーム（IPカメラなど）またはre-stream（エンジンのように）保存されたメディアファイルを物理的な場所からストリーミングする埋め込みプレーヤーを備えたHTTP Web再生インターフェースを介して。

[〜＃〜] rtsp [〜＃〜] はstatefulプロトコルで、UDPを=より多く使用しているようですTCPストリーミングの場合、TCP/IPネットワークに接続され、UDPなどを介してストリームを出力するサーバーデバイス（IPカメラなど）としてより多く使用されます。その後、これらに接続します同じネットワーク上のクライアントとして（サーバー）をフィードし、それに応じてRTSPリクエストを発行して利用できます。

^{プロトコルディレクティブ}

^{いくつかの点でHTTPに似ていますが、RTSPはマルチメディア再生の制御に役立つ制御シーケンスを定義します。 HTTPは stateless ですが、RTSPには状態があります。識別子は、同時セッションを追跡する必要がある場合に使用されます。 HTTPと同様に、RTSPはTCP=を使用してエンドツーエンド接続を維持します。ほとんどのRTSP制御メッセージはクライアントからサーバーに送信されますが、一部のコマンドは他の方向（つまり、サーバーからクライアントへ）。}

^{ここに提示されているのは、基本的なRTSPリクエストです。 OPTIONSリクエストのようないくつかの典型的なHTTPリクエストも利用できます。デフォルトのトランスポート層ポート番号は554 [3]であり、TCP=とUDPの両方）であり、後者は制御要求にほとんど使用されません。}

^{^_ソース}

^{ステートレス}

^{ステートレスプロトコルでは、サーバーが複数の要求の間、各通信パートナーに関するセッション情報やステータスを保持する必要はありません。対照的に、サーバーの内部状態を維持する必要があるプロトコルは、ステートフルプロトコルと呼ばれます。}

^{ステートレスの欠点は、すべてのリクエストに追加情報を含める必要があり、この追加情報をサーバーが解釈する必要があることです。}

^_ソース

論理フロー

この形式のストリーミングメディアの流れを理解する方法は次のとおりです。

メディアコンテンツが存在するサーバーは、ストリーム配信用の適切な形式とセグメントでビデオ/オーディオデータコンテンツをカプセル化、圧縮、エンコードなどします。
ストリーミングメディアにアクセスするための接続をリッスンするWebサーバーは、メディアのストリーミングに必要なすべてのリソースを配信します
クライアントは、該当するリソースとファイルを要求してダウンロードし、構成されたURLポインターやその他のパラメーターを介して再生するために、継続的な方法でそれらを組み立てます。クライアントレベルの再生ソフトウェアは、順番に送信されるパケットを組み立てて、コンテンツを適切に再生できるようにします。

HTTPとRTSPの一般的な比較については、以下のStreaming Technologiesセクションを参照してください。

さらに

以下の自分の動画をホストしてはいけない10の理由セクションで、質問への回答に役立つ部分を引用しました。一般的です」.

基本的に、メディアプレーヤーコントロールが埋め込まれたWebサイトは次のようになると述べています。

^（1）クライアントからの「接続と要求」時にクライアントのWebブラウザー設定を検出し、
^（2）これにより、コーデックとその他のクライアント側の検出設定が適切なパラメーター値に設定されます。
^（3）ビデオとオーディオファイルをホストするストリーミングサーバーから直接ビデオをストリーミングしますホストされたサーバー上のメディアファイルのURLを指す埋め込みメディアプレーヤー構成。

^{ストリーミング技術}

^{クライアントブラウザは、サーバーからデータを受信し、それをストリーミングアプリケーションに渡して処理する必要があります。ストリーミングアプリケーションは、データを画像と音声に変換します。このプロセスの成功における重要な要素は、アプリケーションが情報を表示できるよりも速くデータを受信するクライアントの能力です。過剰なデータは、アプリケーション内のデータストレージ用に予約されたメモリ領域であるバッファに格納されます。 2つのシステム間のデータ転送が遅れると、バッファが空になり、資料の提示がスムーズに行われなくなります。}

^{HTTPプロトコル}

^{HTTPは、ドキュメントがインターネット上でリンクされる主な方法です。クライアントは、ストリーミングされるファイルを含むサーバーに接続し、ファイルが取得され、接続が閉じられます。 HTTPサーバーは、転送するファイルのタイプをブラウザーに通知します。}

^{HTTPを使用する利点}

^{HTTPを使用してファイルをストリーミングする場合、特別なストリーミングサーバーは必要ありません。ブラウザがMIMEタイプを理解している限り、HTTPサーバーからストリーミングファイルを受信できます。 HTTPを使用したファイルのストリーミングの明確な利点の1つは、ファイアウォールを通過してプロキシサーバーを利用できることです。}

^{いくつかの欠点}

^{HTTPストリーミングでは、TCP/IP（伝送制御プロトコルとインターネットプロトコル）を使用して、ファイルの確実な配信を保証します。このプロセスは、欠落しているパケットをチェックし、それらを再送信するように要求します。これは、データが配信中に失われた場合にデータを無視する必要があるストリーミングシナリオで問題になるため、動的ファイルは再生を続けます。 HTTPはモデムの速度を検出できないため、サーバー管理者は、さまざまな種類の接続を持つサーバーユーザーに対して、さまざまな圧縮率で意図的にファイルを作成する必要があります。要求の厳しい状況では、HTTPサーバーからのファイルのストリーミングはお勧めしません。}

^{RTSPプロトコル}

^{RTSPは、ほとんどのストリーミングサーバーベンダーで使用されている標準プロトコルです。 RTSPサーバーは、UDP（ユーザーデータグラムプロトコル）を使用してメディアファイルを転送します。 UDPは、ファイルが宛先に到着したことを継続的にチェックしません。これは、遅延が長すぎない限り、ファイル転送の中断を可能にするため、ストリーミングアプリケーションにとって有利です。この方法の結果、データが失われることがありますが、遅延が小さい場合はファイルの再生が続行されます。}

^{^ソース}

^{自分の動画をホストしてはいけない10の理由}

^{埋め込み動画とセルフホスト動画について話し合っています}

^{まず、YouTube、Vimeo、Wistiaなどのサードパーティのビデオホスティングサービスにビデオファイルをアップロードします。}

^{次に、提供された小さなコードをコピーして、自分の投稿またはページに貼り付けますWordPressサイト。動画は、サイトの場所に表示されます埋め込みコードを貼り付けましたが、ビデオ自体は、WordPressサイトがホストされている独自のWebサーバーではなく、ビデオホストのサーバーからストリーミングされています。}

^{4。 Webビデオの単一ファイル形式の標準はありません}

^{現在のHTML5ドラフト仕様では、ブラウザーがサポートする必要のあるビデオ形式を指定していません。その結果、主要なWebブラウザーは分岐し、それぞれが異なるフォーマットをサポートしています。 Internet ExplorerとSafariはH.264（MP4）ビデオを再生しますが、WebMまたはOggは再生しません。 FirefoxはOggまたはWebMビデオを再生しますが、H.264は再生しません。ありがたいことに、Chromeはすべての主要なビデオ形式を再生しますが、ビデオがすべての主要なWebブラウザで確実に再生されるようにするには、ビデオを複数の形式に変換する必要があります。 .mp4、.ogv、および.webm}

^{5。あなたはビデオを変換するのが好きだと思います。たくさん。}

^{ほとんどの視聴者は、高速インターネット接続を利用して、デスクトップまたはラップトップから動画を見る可能性があります。それらの人々にとっては、HD品質の大きなファイルを配信して、彼らが選択した場合にフルスクリーンで視聴できるようにする必要があります。通常、これは高ストリーミングビットレート（5000〜8000 kbps）の1080pまたは720pファイルを意味します。}

^{ただし、携帯電話やタブレットなどのモバイルデバイスに配信したり、インターネット接続が遅い視聴者に配信したりするために、より小さく解像度の低いバージョンをエンコードする必要もあります。}

^{6。ビデオプレーヤー}

^{ビデオプレーヤーは、サイトにインストールする小さなWebソフトウェアで、ビデオを要求しているデバイスとその接続速度を自動的に検出し、適切なバージョンをそのユーザーに配信します。}

^{7。面倒なコード[またはショートコード]}

^{サードパーティのプラグインを使用する場合でも、WordPressの組み込みのビデオ機能を使用する場合でも、作成したフォーマットとサーバー上の場所をビデオプレーヤーに伝えるためのコードを作成する必要があります。こんな感じ…}
<video poster="movie.jpg" controls> <source src="movie.webm" type='video/webm; codecs="vp8.0, vorbis"'/> <source src="movie.ogg" type='video/ogg; codecs="theora, vorbis"'/> <source src="movie.mp4" type='video/mp4; codecs="avc1.4D401E, mp4a.40.2"'/> <p>This is fallback content</p> </video> 
では、サイトに動画を追加するための最良の解決策は何ですか？

サードパーティのビデオホスティングサービスを使用して、WordPress投稿またはページにビデオを埋め込むだけです。

ステップ1：Vimeo PROなどの定評のある人気のビデオホスティングサービスの1つにビデオをアップロードします。

ステップ2：ビデオがアップロードされ、表示の準備ができたら、URLをビデオにコピーします。 WordPressサイトに戻り、ビデオを表示する投稿またはページにURLを貼り付けます。

^{人々があなたのページを見るとき、ビデオはあなたがURLを貼り付けた場所に表示されます。ただし、ビデオファイル自体は、WordPressサイトがホストされている独自のサーバーではなく、ビデオホストのサーバーからストリーミングされます。}

_{埋め込まれたビデオプレーヤーは、ユーザーのデバイス、ブラウザ、インターネット接続速度を自動的に検出し、適切なバージョンのビデオファイルをユーザーに提供します。サイトにインストールするものはありません。最新の状態に保つためのプラグインはありません。トリッキーなコードはありません。}

_{_ソース}

harrymc · Answer

以下では、主に、ブラウザにビデオが表示されたときに何が起きているかという質問を扱います。テーマは広大なので、関連する項目のみを取り上げます。

HTML5では<VIDEO>タグが導入され、JavaScriptとCSSを使用しながら、表示されたビデオをブラウザーに統合する問題が解決されました。以前の<OBJECT>タグは外部ソフトウェアを必要とし、ページとうまく統合されていませんでした。新しいタグは事実上、ブラウザが動画プレーヤーになることを要求しましたが、標準は課されていませんでした。その結果、標準が完全に断片化されました。唯一の解決策は、ビデオサーバーがいくつかのビデオ形式を利用できるようにし、これらすべての代替ソースを<VIDEO>タグで指定し、そこからブラウザーが選択することです。サポートしています。

複数のソースを持つタグの例：

<video width=320 height=240 controls poster=image.jpg> <source src="movie.mpd"> <source src="movie.webm"> Your browser does not support the video tag. </video>

<VIDEO>タグ自体はプロトコルに依存しないため、RTSPを含むブラウザでサポートされている任意のプロトコルを使用できます。 MPEG-DASHプロトコル（Dynamic Adaptive Streaming over HTTP）のサポートは最近非常に包括的になり、ほとんどのデバイスとブラウザーでネイティブに、またはHTML5を使用して再生されます。つまり、追加のプラグインは必要ありません。こちらをご覧くださいデバイスとブラウザの互換性チャート。 MPEG-DASHを提供するためのサーバーの準備については、このMozilla記事も参照してください。 DASHはHTTP経由で機能するため、HTTPサーバーがバイト範囲リクエストをサポートし、mimetype="application/dash+xml"で.mpdファイルを提供するように設定されている限り、これは機能します。

クライアントとサーバー間の通常の相互作用は次のようになります。 HTML5ビデオの場合、ブラウザーはプレーヤーでもありますが、再生のために新しい接続を開く場合があります。

初期接続は、クライアントがビデオを表示するために使用するメタデータを提供します。 RTSPプロトコルを使用してメタデータを取得した場合は、後でビデオとオーディオデータを転送するためのRTP接続が作成されます。 RTCPプロトコルは、追加のコマンドをサーバーに転送するために使用されます。

RTP、RTCP、およびRTSPはすべて異なるポートで動作します。通常、RTPがポートNにある場合、RTCPはポートN + 1にあります。 RTPセッションには、受信側で組み合わせる複数のストリームを含めることができます。たとえば、オーディオとビデオが別々のチャネルにある場合があります。

コンテンツからロックアウトされないようにするには、ロイヤルティフリーのコーデック、webMまたはTheora、H.264ビデオ、およびVorbisとMP3オーディオの両方を利用できるようにする必要があります。（簡単に言うと、難しいです。）

これはRTSPで詳細に何が起こるかです：

クライアントは、サーバーへのTCP接続を、RTSPの既知のポートであるTCPポート554で確立します。
次に、クライアントは、HTTPに類似した形式の一連のRTSPヘッダーコマンドの発行を開始します。それぞれのコマンドはサーバーによって確認されます。これらのRTSPコマンド内で、クライアントは、サポートするRTSPのバージョン、データフローに使用されるトランスポート、関連するUDPまたはTCPポートなどのセッション要件の詳細をサーバーに説明します情報。この情報は、DESCRIBEヘッダーとSETUPヘッダーを使用して渡され、クライアントと一時的なプロキシデバイスがさらに交換でストリームを識別するために使用できるセッションIDでサーバーの応答に追加されます。
トランスポートパラメータのネゴシエーションが完了すると、クライアントはPLAYコマンドを発行して、RTPデータストリームの配信を開始するようサーバーに指示します。
クライアントがストリームを閉じることを決定すると、セッションIDとともにTEARDOWNコマンドが発行され、そのIDに関連付けられたRTP配信を停止するようサーバーに指示します。

参考文献：

Anton Liakhovitch · Answer

ここにすばやく汚い答えがあります

Webでビデオを再生することと実際にリアルタイムでストリーミングすることには違いがあります。

再生は、Webページに含まれているプレーヤーによって行われます（Flash、JS、またはhtml5ビデオオブジェクトを使用している可能性があります）。クライアント（ブラウザ）がこのプレーヤーをダウンロードして実行します。次に、プレーヤーは単純なダウンロードURLからビデオを取得します。実際には、YouTubeを使用していても、ホストされているビデオファイルに直接アクセスして、他のファイルと同じようにダウンロードできるプログラムがあります。システムは通常の古いダウンロードリンクを使用するため、RTSPなどの複雑なストリーミングプロトコルは必要ありません。

リアルタイムストリーミング（たとえば、Webカメラから）は、ややこしいです。 Flashにはこの機能が組み込まれていますが、今後は使用しないでください。 HTML5ビデオはリアルタイムストリーミングをサポートしていませんが、ファイルホスティングサーバーが提供するビデオファイルを常に変更することにより、人々はそれを「だます」ことができました。