例による内部HTMLページからのメディアのストリーミング

ですから、私はソフトウェアエンジニアであり、ストリーミングメディアの仕組みについての細かい点を理解しようとしています。私は、アプリケーションに関連するさまざまなコーデック、コンテナ形式、およびストリーミングプロトコルを理解しようとして、その日の大半を費やしました。これまでのところ、これがどのように機能するかについての私の理解は非常によく誤解される可能性があります：

• ストリーミングメディアは、実際にはコンテナ形式とストリーミングプロトコルに要約されます。
  • すべてのオーディオデータは（オーディオコーデックを介して）オーディオビットストリームにエンコードされます。
  • すべてのビデオデータは（再びコーデックを介して）ビデオビットストリームにエンコードされます。
  • 2つのストリームは、最終的にファイル（MP4など）になるコンテナーにマージ（多重化？）されます。
  • 次に、特別なメディアサーバーが、RTSPなどの標準ストリーミングプロトコルを介して、このコンテナ（MP4ファイル、またはその他の形式）をクライアント（おそらく、誰かのブラウザー内で実行されるHTML5ビデオプレーヤー）に提供します。
    • ブラウザークライアントの場合、ブラウザー自体にRTSPクライアントがあり、それが何らかの形でユーザーにHTML5 Video Playerを提示すると仮定します。
• 私は可能性からMP4ファイルをホストするウェブなどnginxのかHTTPDなど、サーバーが、これらのサーバーは、RTSPサーバではないため、専用としてMP4の要求を処理することができるだろうダウンロード要求、ひいては、ストリーミングすることができないであろうメディアファイル
  • 同様に、curlnginxサーバーからファイルを取得するために使用する場合、nginx curlもRTSPも話さないため、ファイルダウンロードとして扱われます
• ただし、ストリーミングメディアサーバー（VideoLAN、Red5、Wowzaなど）からMP4ファイルをホストし、RTSPクライアント（またはサポートされているストリーミングメディアクライアント）を使用して、そのサーバーからストリームを要求すると、その後、実際のストリーミングは発生しますか
  • したがって、YouTubeまたはVimeoの「ビデオ」はHTTPサーバーによってHTTP（S）経由で提供されるHTMLページでホストされますが、それらのページ（ビデオが実際に再生される場所）の埋め込みビデオプレーヤーは実際に2 、その後のストリーミングサーバーへの接続、およびストリーミングはRTSPまたは他の非HTTPプロトコルで発生しています

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

HTMLページ内で実行され、HTMLサーバーによって提供されるストリーミングメディアプレーヤーは、ストリーミングメディアサーバーとのストリーミング（RTSPなど）接続を確立する（RTSP要求を提供する）方法を教えてください。

HTMLページ内で実行され、HTMLサーバーによって提供されるストリーミングメディアプレーヤーは、ストリーミングメディアサーバーとのストリーミング（RTSPなど）接続を確立する（RTSP要求を提供する）方法を教えてください。

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

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

と思われるRTSPがあるステートフルなど、プロトコルおよびストリーミングするとき、それはより多くのTCPよりもUDPを使用し、それがより多くの（IPカメラのような）サーバ装置として使われているTCP / IPネットワークに接続されていること、およびUDP経由でストリームを送り出します次に、これらのフィード（サーバー）に同じネットワーク上のクライアントとして接続し、RTSP要求を発行してそれに応じて利用できます。

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

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

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

^_ソース

^{ステートレス}

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

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

^_ソース

論理フロー

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

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

HTTPとRTSPの一般的な比較については、以下のストリーミングテクノロジーのセクションをご覧ください。

さらに

以下に、自分の動画をホストしてはいけない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サイトがホストされている独自のサーバーではなく、ビデオファイル自体がビデオホストのサーバーからストリーミングされます。}

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

_ソース

以下では、主にブラウザでビデオが表示されたときに何が起こるかというあなたの質問を扱います。主題は広大であるため、関連する項目についてのみ触れます。

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プロトコル （HTTP経由ダイナミックアダプティブストリーミング）は、最近、それはネイティブのほとんどのデバイスやブラウザ上で再生されますので、非常に包括的になる、または余分なプラグインが必要とされないことを意味HTML5を使用しています。このデバイスとブラウザの互換性チャートをご覧ください。MPEG-DASHを提供するためのサーバーの準備については、このMozillaの記事も参照してください。DASHはHTTP経由で動作するため、HTTPサーバーがバイト範囲リクエストをサポートし、.mpdファイルを提供するように設定されている限り、これは動作しますmimetype="application/dash+xml"。

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

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

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

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

これがRTSPの詳細です。

1. クライアントは、通常、RTSPの既知のポートであるTCPポート554でサーバーへのTCP接続を確立します。

2. クライアントは、HTTPに類似した形式の一連のRTSPヘッダーコマンドの発行を開始します。各コマンドはサーバーによって確認されます。これらのRTSPコマンド内で、クライアントは、サポートするRTSPのバージョン、データフローに使用されるトランスポート、関連するUDPまたはTCPポート情報など、セッション要件の詳細をサーバーに記述します。この情報は、DESCRIBEヘッダーとSETUPヘッダーを使用して渡され、クライアントおよび一時的なプロキシデバイスがさらなる交換でストリームを識別するために使用できるセッションIDでサーバー応答に追加されます。

3. トランスポートパラメータのネゴシエーションが完了すると、クライアントはPLAYコマンドを発行して、RTPデータストリームの配信を開始するようにサーバーに指示します。

4. クライアントがストリームを閉じることを決定すると、TEARDOWNコマンドがセッションIDと共に発行され、そのIDに関連付けられたRTP配信を停止するようサーバーに指示します。

参考文献 ：

• ストリーミングプロトコルの基本
• アプリケーション層プロトコルについて-リアルタイムストリーミングプロトコル（RTSP）
• HTML5ビデオの概要（オペラ）
• HTML5オーディオとビデオ：知っておくべきこと
• RTSP分析Wireshark

ここに迅速で汚い答えがあります-

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

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

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