ストリーミングに投資することで会社の戦略にどのように貢献できるか考えたことはありますか? テクノロジーは、リモートワーク、トレーニング、コース、エンターテイメント、販売など、さまざまな目的でますます使用されています。
私たちのほとんどは、ストリーミング ビデオを見ない日は XNUMX 日たりともありません。 コンテンツに対するこの種の消費者の行動の人気が高まっているのは、ビデオ ストリーミング プロトコルが利用できるようになったことによるものです。
ストリーミング ビデオ プロトコルは、ビデオ ファイルをより小さな部分に分割し、再構成して視聴できるようにエンド ユーザーに配信するための特別な標準化されたルールと方法です。
ファイルは転送のために圧縮する必要があります。 このプロセスは「」を使用して実現されます。コーデック最も一般的な H.264 など。ファイルを転送する前に、.mp4 や .avi などの「コンテナ形式」で保存する必要もあります。
ビデオ ファイルのソースは、ライブ ブロードキャストの場合はブロードキャスト ユーザーのカメラから直接、ビデオ オン デマンド (VoD) の場合は静的ファイルから直接取得できます。
インターネットの普及拡大もあってビデオストリーミングの需要が高まり続けるにつれ、ビデオストリーミングプラットフォームの数も増加しています。 1990 年代、ストリーミングは主にスポーツ放送に限定されていました; 2000 年代に、このテクノロジーは Flash と RTMP ベースのストリーミングで普及し始めました。。 その後、2010 年代には YouTube、Netflix、その他のプラットフォームが登場しました。
形式としてのライブ ストリーミングは 2010 年代半ばに普及し、その直後に Periscope と Facebook Live が開始されました。
現在、ビデオ ストリーミング市場は活気に満ちており、ライブ オーディオ、映画、ゲームのストリーミングなど、複数のプラットフォーム、プロバイダー、用途が存在します。 これらの発展に伴い、ビデオ ストリーミング プロトコルの機能も拡張されました。
現在、いくつかのビデオ ストリーミング プロトコルが存在しています。 中には時代遅れの標準と呼ばれるものもありますが、依然として適用されます。 逆に、主にオープンソースのおかげで急速に発展しているものもあります。
一部のプロトコルは比較的最近のものであり、普及するには時間がかかりますが、将来のビデオ ストリーミング パターンを形作る最も重要な可能性を秘めたプロトコルです。 すべてのプロトコルが同じコーデックをサポートしているわけではありません。
以下では、それらの中で最も一般的なものを検討します。
HLS は、現在ストリーミングに最も一般的に使用されているプロトコルです。 Apple はもともと、iPhone の Flash フォーマットとの戦いの一環として 2009 年にこれをリリースしました。 このプロトコルは、デスクトップ ブラウザ、スマート TV、セットトップ ボックス、Android および iOS モバイル デバイスから HTML5 ベースのビデオ プレーヤーまで、多くのデバイスと互換性があります。 当然のことながら、これによりストリーミング企業は可能な限り幅広い視聴者にリーチできるようになります。
HLS はアダプティブ ビットレート ストリーミングもサポートしています。 これは、動的なビデオ配信を可能にし、エンド ユーザーに最高のビデオ品質を提供するテクノロジーです。
HLS プロトコルの唯一の重大な欠点は、かなりの遅延があることです。。 レイテンシは、特に大量のデータが転送される場合に、配信されたコンテンツがソースから要求された場所に移動し、戻ってくるまでにかかる時間を指します。
MPEG-DASH は、HLS 標準の代替として Moving Pictures Expert Group (MPEG) によって開発された最新のストリーミング プロトコルの XNUMX つです。 これは、任意のオーディオまたはビデオ コーデック用に構成できるオープンソース標準です。
HLS と同様に、MPEG-DASH はアダプティブ ビットレート ストリーミングをサポートしており、視聴者はネットワークがサポートできるレベルに応じて最高品質のビデオを受信できます。
WebRTC は、リアルタイム応答のストリーミングを提供することを目的としたオープンソース プロジェクトでもあります。 当初は VoIP アプリケーション専用に開発されましたが、Google が買収した後、ビデオ チャットや会議アプリケーションで普及しました。
Google Meet、Discord、Houseparty、Gotomeeting、WhatsApp、Messenger など、現在最も一般的な消費者向けアプリケーションの一部は WebRTC プロトコルを使用しています。
WebRTC のユニークな点は、ピアツーピア ストリーミングに基づいていることです。 この方法は、ストリーミングに低遅延が必要な場合に推奨されるソリューションと言えます。
SRT は、ストリーミング テクノロジー プロバイダーの Haivision によって開発されたもう XNUMX つのオープンソース プロトコルです。 このプロトコルは、テクノロジーおよび電気通信プロバイダーを含む企業グループである SRT Alliance のメンバーにとって推奨されるプロトコルです。 SRT の主な利点は、セキュリティ、信頼性、高い互換性、低遅延ストリーミングです。
SRT は、ネットワーク状態が不安定な場合でも、高品質のビデオをストリーミングできます。 また、単一のコーデックから独立しているため、任意のオーディオまたはビデオ コーデックで使用できます。
RTMP は、すでに多くの人に知られているプロトコルです。 これは、ストリーミング サーバーと Adobe Flash Player の間でオーディオ ファイルとビデオ ファイルを転送するために、Macromedia (現在は Adobe として知られています) によって開発されました。
しかし、2020 年に Flash が段階的に廃止されると、Flash の使用はビデオ コンテンツの配信ではなく、RTMP 対応エンコーダを介してプラットフォームにライブ ストリームをアップロードすることに多くなりました。 これは、エンコーダからのビデオ ストリームが RTMP プロトコル経由でストリーミング プラットフォームに送信され、その後標準の HLS プロトコル経由でエンド ユーザーに配信されることを意味します。
RTSP は、エンターテインメント業界向けに開発されたもう XNUMX つのレガシー プロトコルで、主にエンドポイント間のマルチメディア セッションを確立および管理するために使用されます。 HLS プロトコルに似ていますが、リアルタイム ストリーミング データの転送には役立ちません。
RTSP サーバーは、ストリーミング タスクを実行するために、RTP および他のプロトコルと連携して動作する必要があります。
低遅延ストリーミングをサポートしていますが、ほとんどの標準的なデバイスやブラウザとの非互換性が問題になる可能性があります。 これは、専用サーバーから選ばれた少数の視聴者グループに低遅延ストリーミングを配信できるプロトコルと考えることができます。
ほとんどの IP カメラは依然として RTSP をサポートしているため、監視およびビデオ監視システムでは依然として RTSP が標準となっています。
リアルタイム メッセージング プロトコル (RTMP) は、伝送制御プロトコル (TCP) と連携して動作するテクノロジです。 RTSP と同様に、当初はオーディオ、ビデオ、その他のデータをリアルタイムで送信するために開発されました。 TCP 互換性により、録画デバイスとデータが送信されるサーバー間の高度な通信が可能になります。 ユーザーは、録画デバイスを通じて一貫した信頼性の高いストリームを楽しむことができます。
RTMP は、ライブ ストリーミング プラットフォームのプロトコルとして一般的に使用されます。 低コストのエンコーダを利用して、ストリームを再生可能な形式に変換します。
RTSP と RTMP は多くの共通の特性を共有しており、競合しません。 どちらを使用するかは、プラットフォームの要求と一般的なストリーミング操作によって決まります。
RTMP と RTSP の優れている点は、どちらも遅延が低く、安定した接続を介してオンデマンドでリアルタイムにメディアを提供することでストリームを制御できることです。
ただし、RTSP は、より安価でシンプルなストリーミングの代替手段として最適です。 RTMP が独自のテクノロジーとして分離されていたときに、エンジニアによって広く使用されたことにより、大幅に発展しました。 前述したように、RTSP はほとんどの IP カメラのデフォルトです。 これは、ローカライズされたストリームや、会議システムや監視システムへの入力として優れています。
RTSP には利点がありますが、欠点もあります。 より快適に再生するにはストリームを再パッケージ化する必要がありますが、残念ながらこれにより遅延の問題が発生する可能性があります。 非常に重要な監視状況で IP カメラが重要に使用されることを考えると、遅延の問題を克服して、画面上で何が起こっているかを識別できる鮮明でクリアな再生を促進できることが重要です。
より良いビデオ配信を保証するための最良の方法の XNUMX つは、Web リアルタイム通信 (WebRTC) を使用することです。 この API は、RTSP フィードを再生の問題なく鮮明な品質で表示されるリアルタイム ストリームに変換することにより、ストリーミング シーンを超越しました。
WebRTC はほとんどのブラウザと互換性があり、配信は 20 秒以内に完了します。 最大 XNUMX 秒の遅延が発生する可能性がある RTSP よりも一貫した視聴エクスペリエンスが提供されます。
WebRTC は RTSP コンテンツを中継することによって機能します。 アプリケーションは、効果的なメディア サーバーと連携して IP カメラ ストリームを取り込み、WebRTC に再パッケージ化することの重要性を強調しています。 Web でホストされているリプレイ ページの URL には、いつでもアクセスできます。
RTSP はコマンドを使用して、クライアントからサーバーにリクエストを送信します。 これはすべて、メディア ストリームの制御とネゴシエーションの一部です。
RTSP は次のコマンドを使用します。
これらは、メディアを可能な限り最良の形式で提示するために調整されます。 ユーザーは、データがサーバー上で転送および再パッケージ化されるときに、生成されたリンクを介してコンテンツにアクセスできます。 ファイルをデバイスに物理的に保存せずにオンデマンドで再生できる機能は、RTSP がストリーミングの世界で重要な役割を果たし続ける最大の理由の XNUMX つです。
プロトコル システムとして、RTSP はデバイス上で再生する物理ファイルを作成するようにフォーマットされていないため、再生に使用されることはほとんどありません。 ただし、Quicktime Player、3Gpp 互換モバイル デバイス、および VLC メディア プレーヤーと互換性があります。
RTSP は低遅延ストリーミングには最適ですが、エクスペリエンスの品質とスケーラビリティに関しては最適化されていません。 このため、アダプティブ ビットレート ストリーミングは、他のコンテキスト、特に IP カメラが動作していないときに広く使用されています。
ストリーミング送信で使用されるプロトコルとエンコーダーは、XNUMX つの異なる方法で作成できます。 通常、XNUMX つのモデルを組み合わせても、顧客にコンテンツを配信するための完全な戦略となります。
ライブ ストリーミングは、生成された信号がリアルタイムで公衆に送信されるストリーミングです。 この場合、ストレージは必要ありません。 オーディオとビデオはエンコーダーを使用してキャプチャおよび変換され、サーバーからインターネット経由で直接ストリーミングされます。
オンデマンドでは、送信はオンデマンドで行われます。 この場合、録画されたコンテンツ (ビデオ レッスンやポッドキャストなど) はサーバーに保存されます。 消費者が再生ボタンを押すとすぐに、そのファイルのストリームの再生が開始されます。 これらすべてを低遅延で実現します。
ビデオ ストリーミング プロトコルの選択は、ビジネス ニーズにとって重要となる可能性のある特定の要因によって異なります。 できるだけ幅広い視聴者にリーチしたり、待ち時間を最小限に抑えたりしたい場合があります。 もちろん、ストリームのセキュリティと機密性に注意を払う必要があります。
以下は、これらの要素に基づいて選択を行うための大まかなガイドです。
ストリーミング コンテンツで可能な限り幅広い視聴者にリーチしたい場合は、ほとんどのデバイス、プラットフォーム、ブラウザと互換性のあるプロトコルで十分です。 この場合、HLS が最適なオプションです。 疑問がある場合、プロトコルはそれをデフォルトのソリューションとして選択することもできます。
HLS はストリーミングに対して最も包括的なカバレッジを提供しますが、送信プロセスで最も遅延が発生します。 RTMP は低遅延ストリームを提供しますが、HTML5 ビデオ プレーヤーとは互換性がありません。
SRT は低遅延ストリームをサポートし、WebRTC はリアルタイムの遅延を提供します。 これらのオプションのいずれかを選択する場合、これらのプロトコルはストリーミング テクノロジー環境であまり広くサポートされていないため、視聴者へのリーチが危険にさらされる可能性があることに注意してください。
カバレッジまたは遅延のどちらかについて妥協できない場合、この状況における XNUMX つのオプションは、HLS プロトコルを使用することです。 したがって、高速化されたマルチメディア コンテンツを選択すると、超低遅延でストリーミングできるようになります。
エンド ユーザーに届くまでのストリームの整合性と安全性を確保することが最も重要である場合、セキュリティ機能を提供するプロトコルを使用する価値があります。 広く使用されている HLS 標準を含むほとんどのプロトコルは安全なストリーミングを提供しますが、SRT はクラス最高のセキュリティおよびプライバシー機能を備えたプロトコルです。
前述したように、アダプティブ ビットレートにより、ネットワーク、デバイス、エンドユーザー ソフトウェアの機能に基づいて可能な限り最高のビデオ品質が可能になります。 HLS と MPEG-DASH は、この機能をサポートするプロトコルです。 アダプティブ ビットレート ストリーミングの詳細については、ブログをご覧ください。
独自のビデオ プラットフォームを開発する予定がある場合は、次の点を考慮してください。
このような場合は、クラウドベースの VoD コンテンツ管理システム、またはビデオ ストリーミングの受信、管理、処理、公開、その他の側面を XNUMX つのプラットフォームに統合するオールインワンのリアルタイム ストリーミング ソリューションを検討してください。
インターネット用のマルチメディア アプリケーションを開発して成功させることは、非常に困難な問題です。 現在のストリーミング プロトコルのほとんどは、TCP または UDP に基づいています。 どちらにも長所と短所があります。
TCP は、信頼性の高いサービス、パケット再送信、輻輳とフロー制御を提供します。 信頼性の高いサービスは望ましいものですが、TCP の場合、遅延の増加やスループットの調整などの欠点が伴います。
パケット損失の各段階で、TCP は輻輳制御を通じて伝送速度を低下させます。 その後、伝送速度は徐々に増加し、新たなパケットロスが発生します。 このため、リアルタイム ストリーミング アプリケーションには TCP の使用を避けます。
したがって、UDP は信頼性が低く、輻輳制御機能がありませんが、RTP や RTCP などのリアルタイム アプリケーション用のトランスポート プロトコルとして選択されました。 マルチキャスト技術を使用すると、ライブ オーディオとビデオを多くの受信者に効率的に配信できます。
ストリーミングの品質を向上させるために現在使用されているいくつかのテクニックは次のとおりです。
そして、次のようないくつかの問題が残っています。
この記事では、現在のプロトコルではアプリケーションの適切な機能に必要な特性を提供することが難しいネットワーク上でマルチメディア アプリケーションの実行を可能にするいくつかのプロトコルについて説明しました。 現在の課題に対して、まったく異なるメカニズムを備えたソリューションがいくつかあります。 複数のデータ ソース、選択的なパケット ドロップ、輻輳制御、データ送信の冗長性、パケット転送、および複数のパケット転送は、新しいストリーミング プロトコルのツールのほんの一部です
At テユトでは、入力の RTMP、出力の HLS および Dash などの最も一般的なストリーミング プロトコルを提供し、さまざまなデバイスやプラットフォームの視聴者に最高のビデオ再生エクスペリエンスを提供します。
読んでよかったですか？