SRT
ライブ映像のために UDP を信頼できるものに。失ったものを再送する。ただし間に合う範囲で。
データパケット
映像の前に付く 16 バイト。順序、時刻、フラグ。
フレーム全体
UDP の上の 16 バイトのヘッダです。損失検出のためのパケットシーケンス番号、配送時刻を決めるタイムスタンプ、ソケット ID。これらが UDP を、信頼できる低遅延の回線に変えます。
| フィールド | 位置 | 例の値 | 意味 |
|---|---|---|---|
| F（制御フラグ） | 0 バイト目の bit 7 | 0 = data | 0 = データパケット、1 = 制御パケット（ハンドシェイク・ACK・NAK・キープアライブなど）。最初の 1 ビットで、残りの読み方が決まります。 |
| パケットシーケンス番号 | 0–3 バイト目にまたがる | 6699 | バイトではなくパケットを数えます。受信側は欠番に気づくと NAK で欠けた番号を要求し、送信側が再送します。これが SRT の損失回復です。 |
| PP（位置） | 4 バイト目の bits 7–6 | 11 = solo | メッセージ内でのこのパケットの位置。10 = 先頭、00 = 中間、01 = 末尾、11 = 単独（メッセージ全体が 1 パケット）。 |
| O（順序） | 4 バイト目の bit 5 | 0 | 1 = メッセージを順序どおりに渡す必要あり。ライブモードでは 0 にして、タイムスタンプに頼ります。 |
| KK（鍵） | 4 バイト目の bits 4–3 | 00 = clear | 暗号化。00 = 暗号化なし、01 = 偶数鍵、10 = 奇数鍵。SRT はペイロードを AES で暗号化できます。 |
| R（再送） | 4 バイト目の bit 2 | 0 = original | NAK を受けて再送するパケットで 1。受信側が、修復にどれだけ通信量が要るかを測れます。 |
| メッセージ番号 | 4–7 バイト目にまたがる | 1 | メッセージの識別番号。ライブ配信では、1 パケットが 1 メッセージです。 |
| タイムスタンプ | 8–11 バイト目 | 1,000,000 µs = 1.000 s | 接続開始からのマイクロ秒で、送信側が最初に送った時刻を入れます。受信側はこの時刻から一定のレイテンシだけ遅らせて渡すことで、ジッタを吸収し、再送の余地を作ります。 |
| 宛先ソケット ID | 12–15 バイト目 | 0x1A2B3C4D | ハンドシェイクで取り決めた、受信側のどの SRT 接続宛かを示す ID。1 つの UDP ポートを多数の SRT 接続で共有できます。 |
| ペイロード（先頭） | 16–19 バイト目 | 47 40 11 10 ... | 通常は MPEG-TS パケット 7 個（1,316 バイト）で、SRT パケット全体が Ethernet フレームに収まります。0x47 は TS の同期バイト。 |
概要
SRT（Secure Reliable Transport）は、ライブ映像を公衆インターネットで送ります。UDP の上で動き、必要なものだけを足します。損失したパケットを再送するためのシーケンス番号と NAK、再送が再生に間に合うようにするタイムスタンプ基準のレイテンシバッファ、AES 暗号化。
TCP も信頼できますが、1 つ失うと後ろのすべてが 1 往復以上止まります。SRT は欠けたものだけを再送し、遅すぎたものは捨てるので、遅延が小さく予測可能に保たれます。
基本情報
- トランスポート
- UDP
- ヘッダ
- 16 バイト
- 損失回復
- レイテンシ窓の中での NAK ベース ARQ
- 暗号化
- AES-128/192/256
- 典型的な遅延
- 往復時間の約 4 倍（たとえば 120〜500 ms）
- 規格
- IETF draft (SRT Alliance)
ハンドシェイク
UDP の上で、両端が接続に合意する手順。
やり取りの全体
UDP パケット 4 つで接続を作ります。軽いノック、cookie、設定、確認。UDP にない「接続」を、TCP のような再送の遅延なしに加えます。
11. コーラーがノックする
最初のハンドシェイクパケットで、UDP 上の制御パケットとして送ります。意図的に最小限で秘密を含まず、リスナーは相手のことを何も覚えずに答えられます。
22. リスナーが cookie で答える
応答はハンドシェイクのバージョン 5 に上がり、SRT の目印 0x4A17 と、コーラーのアドレスから作った cookie を含みます。TCP の SYN cookie と同じ考えで、相手がそのアドレスにいると確認でき、偽装した要求ではリスナーは何も消費しません。
33. コーラーが設定を添えて締める
コーラーは cookie を返し、拡張を添えます。SRT のバージョン、希望するレイテンシ（たとえば 120 ms）、暗号を使うなら鍵の素材、必要ならどのストリームが欲しいかを示すストリーム ID。
44. リスナーが確認: 接続成立
リスナーは自分のソケット ID と、合意したレイテンシ（双方の希望の大きいほう）を返します。以後、そのソケット ID 宛にデータパケットを流せます。
失われたパケットの回復
損失、NAK、再送。すべて期限の前に。
やり取りの全体
SRT は、修復が期限までに届くときだけ損失を直せます。レイテンシ設定がその取引です。大きいほど再送のチャンスが増え、小さいほど乱れる危険が増えます。
1パケット 100 が届く
各パケットにはタイムスタンプが付き、受信側は「タイムスタンプ + レイテンシ」まで保持してから、滑らかなペースでデコーダへ渡します。
2パケット 101 が失われる
ネットワークが落としました。素の UDP なら、映像にそのまま穴があきます。
3パケット 102 が欠番を明らかにする
102 が 100 の直後に届きます。受信側は、再生期限のずっと前に「101 がない」と分かります。
4受信側が再送を求める
NAK（否定応答）が、欠けたシーケンス番号をそのまま指名します。TCP と違い、ほかのパケットは止められず、あとのパケットが届き続けます。
5間に合う再送
送信側が R フラグを立てて 101 を再送します。設定したレイテンシ（通常は往復時間の数倍）に余裕があるので、101 の配送時刻までに間に合い、映像は途切れずに再生されます。
6定期的な ACK
受信側は 10 ms ごとに「ここまで全部届いた」という最大のシーケンス番号を報告し、送信側は再送用バッファを解放できます。
使われる場面
- リモートプロダクション・素材伝送。カメラ映像をインターネット越しにスタジオへ
- ライブ配信のエンコーダ（OBS、vMix、ハード機器）とサーバ（FFmpeg、Wowza）
- RTMP や旧来の衛星回線の置き換え
つまずきやすい点
- レイテンシ設定が往復時間の数倍より小さいと、再送が間に合わず、SRT でも映像が乱れます。
- コーラー/リスナーは「誰が接続を始めるか」の区別で、「誰が映像を送るか」ではありません。リスナーが送信側になることもでき、ファイアウォール越えに役立ちます。
- パスフレーズは両端で一致させる必要があり、不一致なら化けた映像ではなく接続拒否になります。
出典・規格
- draft-sharabayko-srt (The SRT Protocol), IETF
- SRT Alliance