srt
v1.5.4
SRTについて |特長 |はじめに |組み立て説明書 |サンプルアプリとツール |貢献する |ライセンス |リリース
Secure Reliable Transport (SRT)は、超低遅延 (1 秒未満) のライブ ビデオおよびオーディオ ストリーミング、および一般的な大量データ転送用のトランスポート プロトコルです1 。 SRT は、GitHub 上のコード、公開されたインターネット ドラフト、および成長を続ける SRT ユーザー コミュニティでオープン ソース テクノロジとして利用できます。
SRT は、ビデオ ストリーム ワークフローの一部としてコントリビューションおよび配信エンドポイントに適用され、常に最高の品質と最小の遅延ビデオを配信します。
| 安全な | ビデオストリームを暗号化します |
| 信頼性のある | 深刻なパケット損失から回復します |
| 輸送 | 変化するネットワーク状況に動的に適応します |
ライブ ストリーミング構成では、SRT プロトコルは一定のエンドツーエンドの遅延を維持します。これにより、ライブ ストリームの信号特性を受信側で再現できるようになり、バッファリングの必要性が減ります。パケットが送信元から宛先にストリーミングされると、SRT は 2 つのエンドポイント間のリアルタイムのネットワーク状態を検出し、それに適応します。ノイズの多いネットワーク上の輻輳によるジッターと帯域幅の変動を補正するのに役立ちます。
SRT は AES 暗号化を実装してメディア ストリームのペイロードを保護し、インターネット接続に特有のパケット損失を最小限に抑えるためのさまざまなエラー回復メカニズムを提供します。その主要な方法は自動再送要求 (ARQ) です。 ARQ では、受信者がパケットの欠落を検出すると、この欠落パケットの再送信を要求するアラートを送信者に送信します。このプロトコルでは、前方誤り訂正 (FEC) と、シームレスなストリーム保護とヒットレス フェイルオーバーを追加する接続ボンディングもサポートされています。
プロトコルの詳細については、次の Innovation Labs ブログを購読してください。
質問するには、 #developmentチャンネルの会話に参加してください。 
? ► ボタンをクリックして機能の説明を展開します。
ネットワークの信頼性がどれほど低くても、SRT は深刻なパケット損失やジッターから回復し、ビデオ ストリームの整合性と品質を保証します。
SRT のストリーム エラー修正は、ユーザーの展開条件に合わせて構成できます。リアルタイム IP 通信の開発を活用して従来のネットワーク エラー回復手法を拡張することで、SRT は TCP/IP よりも大幅に遅延の低いメディアを提供すると同時に、信頼性が大幅に向上した UDP 伝送速度を提供します。
特定のビデオおよびオーディオ形式のみをサポートする他のストリーミング プロトコルとは異なり、SRT はペイロードに依存しません。 SRT はネットワーク トランスポート レベルで動作し、コンテンツのラッパーとして機能するため、あらゆるタイプのビデオ フォーマット、コーデック、解像度、またはフレーム レートをトランスポートできます。
SRT で使用されるハンドシェイク プロセスは、ファイアウォールで永続的な外部ポートが開かれることによる潜在的なリスクや危険を回避してアウトバウンド接続をサポートするため、企業 LAN セキュリティ ポリシーが維持され、IT 介入の必要性が最小限に抑えられます。
SRT は、世界中の政府や組織に信頼されている 128/192/256 ビット AES 暗号化を使用して、貴重なコンテンツが配布への寄与からエンドツーエンドで保護され、権限のない第三者が聞くことができないようにします。
SRT 1.4 では、パケット フィルタ APIが導入されています。このメカニズムにより、ネットワーク パケットを送信する前に送信側で、またネットワークから受信した後に受信側でネットワーク パケットに対してカスタム処理を実行できます。 API を使用すると、ユーザーは独自のプラグインを作成できるため、あらゆる種類のさまざまなパケット フィルタリングを使用して SRT プロトコルの機能をさらに拡張できます。ユーザーは、カスタム暗号化、パケット検査、送信前のデータへのアクセスなど、結果として得られるパケット フィルター データを任意の方法で操作できます。
パケット フィルター API で実現できることの例として作成された最初のプラグインは、前方誤り訂正 (FEC) 用で、特定の使用例では、自動繰り返し要求 (ARQ) よりもわずかに低い遅延を提供できます。このプラグインでは 3 つの異なるモードが可能です。
ARQ のみ – 失われたパケットを再送信します。
FEC のみ – 受信側での FEC リカバリに必要なオーバーヘッドを提供します。
FEC と ARQ – FEC が回復できなかった損失パケットを再送信します。
管理されたネットワーク上の SMPTE-2022-7 と同様に、接続ボンディングはシームレスなストリーム保護とヒットレス フェイルオーバーを SRT プロトコルに追加します。このテクノロジーは、複数の IP ネットワーク パスに依存して、ネットワークの輻輳や停止が発生した場合のライブ ビデオ ストリームの中断を防ぎ、サービスの継続性を維持します。
これは、SRT v1.5 で導入されたソケット グループを使用して実現されます。ソケット グループの一般的な概念は、複数のソケットを含むグループを持つことを意味し、1 つのデータ信号を送信するための 1 つの操作がそのグループに適用されます。グループ内の単一のソケットがこの操作を引き継ぎ、受信者に信号を配信するために必要な処理を実行します。
次の 2 つのモードがサポートされています。
ブロードキャスト -ブロードキャストモードでは、データはグループ内のすべてのメンバー リンクを介して冗長的に送信されます。リンクの 1 つで障害が発生したり、ネットワーク ジッターやパケット損失が発生したりすると、欠落したデータはグループ内の別のリンク経由で受信されます。冗長なパケットは受信側で単純に破棄されます。
メイン/バックアップ -メイン/バックアップモードでは、一度に 1 つの (メイン) リンクのみがデータ送信に使用され、他の (バックアップ) 接続はスタンバイ状態になり、メイン リンクに障害が発生した場合でも送信が継続されます。メイン/バックアップ モードの目的は、潜在的なリンク切断を発生前に特定し、バックアップ リンクの 1 つにシームレスに切り替えるための時間枠を提供することです。
アクセス制御により、上流アプリケーションはストリーム ID を個々の SRT ストリームに割り当てることができます。自動生成またはカスタマイズされた一意のストリーム ID を使用することにより、アップストリーム アプリケーションは複数の SRT ストリームを単一の IP アドレスと UDP ポートに送信できます。受信側はストリーム ID を使用して、取り込みストリームを識別および区別したり、ユーザー パスワード アクセス方法を適用したり、場合によってはストリーム ID の命名に基づいた自動化を適用したりすることもできます。たとえば、投稿はビデオ制作ワークフローに送信され、監視は監視サービスに送信されます。
放送局にとって、ストリーム ID は、ビデオ ストリーム、特に HEVC/H.265 コンテンツを、受信ビデオ用に単一の IP ソケット (アドレス + ポート) が開いているクラウド サービスまたは CDN に取り込むための RTMP を置き換える鍵となります。
| SRT API | IETFインターネットドラフト | サンプルアプリ |
| SRT ライブラリ API のリファレンス ドキュメント | SRT プロトコル インターネット ドラフト | テストアプリの使用手順 ( srt-live-transmit 、 srt-file-transmitなど) |
| SRT の技術概要 | SRT 導入ガイド | SRT クックブック |
| 初期ドラフトの技術概要 (インターネット ドラフトの前身) | 導入ガイドラインを含むプロトコルの包括的な概要 | SRT プロトコルの開発ノート |
| イノベーションラボのブログ | SRTLab YouTube チャンネル | スラック |
| SRT 関連の技術記事が掲載されている Medium のブログ | 役立つビデオを備えたテクニカル YouTube チャンネル | Slack チャンネルで最新情報を入手したり、質問したりできます Slack で SRT アライアンスに参加する |
なぜSRTなのか？ - Marc Cymontkowski による SRT の簡単な歴史と理論的根拠。
RTMP と SRT: 遅延と最大帯域幅の比較に関するホワイト ペーパー。
SRT API ドキュメント、機能の説明などを含む GitHub 上のドキュメント。
SRT プロトコル インターネット ドラフト: Datatracker |最新バージョン |最新の作業コピー | GitHub リポジトリ
Linux (Ubuntu/CentOS) |ウィンドウズ | macOS | iOS |アンドロイド |パッケージマネージャー
C++03以降に準拠したコンパイラ。
ビルド システムとして CMake 2.8.12 以降。
暗号化を有効にする場合は OpenSSL 1.1、それ以外の場合は-DENABLE_ENCRYPTION=OFFを使用してビルドします。
マルチスレッドは、次のいずれかによって提供されます。
C++11: 標準ライブラリ ( -DENABLE_STDCXX_SYNC=ON CMake オプションによるstd )、
C++03: Pthreads (POSIX システムの場合は組み込まれており、Windows の場合は移植されたライブラリがあります)。
Tcl 8.5 はオプションであり、 ./configureスクリプトによって使用されます。それ以外の場合は、CMake を直接使用します。
ビルド システムとオプションの詳細については、SRT ビルド オプションのドキュメントを参照してください。
現在のリポジトリでは、SRT ライブラリ API の使用法を示すサンプル アプリケーションとコード例が提供されています。その中には、 srt-live-transmit 、 srt-file-transmit 、およびその他のアプリケーションがあります。それぞれのドキュメントはここにあります。すべてのサンプルは教育目的で提供されており、運用環境では使用しないでください。
srt-xtransmitユーティリティは、内部テストとパフォーマンス評価に積極的に使用されています。他の機能の中でも、ダミー ペイロードの生成、トラフィック ルーティング、接続ボンディングがサポートされています。追加の詳細は、 srt-xtransmitリポジトリ自体で入手できます。
開発中に役立つ可能性のある Python ツールは次のとおりです。
srt-stats-plotting - SRT .csv統計に基づいてグラフをプロットするように設計されたスクリプト。
lib-tcpdump-processing - .pcap(ng) tcpdump または Wireshark トレース ファイルを処理し、さらなる分析のために目的の SRT パケットを抽出するように設計されたライブラリ。
lib-srt-utils - 実験構成に基づいて SRT テストを実行するためのサポート コードを含む Python ライブラリ。
どなたでもご参加いただけます。参加することに決めた場合は、ガイドラインをよくお読みください。
SRT 開発者ガイド
貢献する
問題の報告
インターネット ドラフトへの貢献や問題の提出については、次のリポジトリにアクセスしてください。 SRT CookBook に貢献するためのリポジトリはここにあります。
SRT プロジェクトにコードを貢献することにより、MPLv2.0 ライセンスに基づいて貢献をライセンスすることに同意したことになります。
リリースノート
SRT のバージョン管理
「ライブ ストリーミング」という用語は、遅延管理を伴う継続的なデータ送信 (MPEG-TS または同等のもの) を指します。 HTTP ライブ ストリーミング (HLS) プロトコル (RFC8216 で説明されている) のようなファイルのセグメント化と送信に基づくライブ ストリーミングは、この使用例には含まれません。この場合、メッセージ モードまたはバッファ モードでのファイル送信を考慮する必要があります。詳細については、インターネット ドラフトのセクション 7. SRT を介したデータ送信のベスト プラクティスと構成のヒントを参照してください。 SRT はコンテンツに依存しないことに注意してください。これは、あらゆる種類のデータをそのペイロードを介して送信できることを意味します。 ↩
