SRTでストリーミング

最近使われるようになったビデオストリーミングプロトコル SRT (Secure Reliable Transport) 。　従来のRTPとかRTMPとかに変わるものでリアルタイム性と信頼性を兼ね備えた新しい配信技術になります。オープンソースということもあり採用する企業が短期間でかなりの数伸びているということも人気の一つです。ちょっとSRTを使う機会があったので少し書いていきます。

　

■ 映像配信で使う通信プロトコル
ネットワーク通信の基本はWebやメール通信などで使われるTCPプロトコルを使っています。一般のインターネット回線は専用線に比べて信頼度は低く、どうしてもパケットロスやジッターによるデータ欠損が生じてしまいます。TCPはそんなときにもう一度データを送ってくれる仕掛けがあるプロトコルです。今見てるページを見て所々文章が無くなっているとか画像が見えないってことはありませんよね？TCP通信でデータ欠損してもその部分を再送信しているために全データを送ることができるからです。

映像配信だとTCPはどうなのかいうとパケットロスのたびに再送信とかやってるとその度に映像が止まってしまいます。それだとイライラして誰も見てくれなくなってしまうので一旦バッファと呼ばれるデータを溜め込むところにプールしておいて時間差で映像を流すということをしています。パケットロスの頻度に応じてプールする容量を増やしておけば映像が止まらずに視聴することができます。一般的な視聴ではTCPを使ったHLSやMPEG-DASHという技術で通信を行っていてこういったバッファ処理が含まれています。その代わり遅延は数十秒以上になることがあります。
視聴者側からするとその遅延はあんまり気になりませんがライブプロダクションなど番組を作る側からするととんでもないことになります。外からの中継で片方向に数十秒もかかっていたらやりとりが出来ませんよね？何処の星との中継だよと言いたくもなります。

プロトコル	SMPTE-2110	SMPTE-2022-6	Evertz ASPEN	SONY NMI	NewTek NDI
通信方式	UDP	UDP	UDP	UDP	UDP/TCP

上の表は代表的な放送用IPフォーマットの一覧です。遅延はいずれも1フレーム以下（数ライン〜数十ライン）でほぼほぼTCPを使っていません。UDPはTCPと対となるプロトコルでTCPのようにちまちま処理をせずドッカンと送る方式です。リアルタイム性が高く放送向きである一方、データ欠損が起きた場合に再送信とかの処理は一切しません。（細かいことは気にしないタイプ）その代わりFEC（Forword Errror Correvtion, 前方誤り訂正）などの技術を併用して多少の欠損は復元させて問題がないようにしています。とはいえそれだけで対処するのは難しく放送用IPは専用線やガッツリ設計されたネットワーク網を使うのが前提で多分に怪しいインターネット網を使うことは想定していません。

■ インターネット回線で高品質を保持するSRT
インターネット網でリアルタイム性を追求した配信方式がSRTとなります。放送用IPと同じくUDPを使うのですが強力なエラー訂正により品質を保持するようになっています。
主な特徴として
・ARQ（Automatic Repeat reQuest）機能を搭載し送信受信側でパケットロスを検知すると自動でデータを再送信してくれる。
・低遅延（数百ms)
・ファイヤーウォール透過機能
・AES 128bit/256bitの暗号化
などがあります。
Caller、Listenerともにバッファを持ち常にデータの流れを監視していてデータロスがあればTCPと同じように再送信、処理が間に合わそうであればエンコーダーのパラメータを自動調整してストリームを途切れなくさせる仕組みが備わっています。
送受信合わせて数百msの遅延をどう捉えるかなのですが、例えば遠隔地から衛星中継のようなコンテンツであればさほど気にならないでしょうし一般のインターネット回線が使えるので高額な通信回線料を払わなくて済むようになるのは大きな利点だと思います。
ちょっと試してみたいところですがまだまだSRTが使える機材はまだまだ少なく、ハードウェアエンコーダー/デコーダーがほとんどのようです。

と、思ったら手元にSRT対応のカメラがッ！
とある用途で借りてたカメラですがSRT機能が使えるのはノーマークでした、、、手のひらサイズですが4K/60Pまでいける某社のOEM向けカメラです。（なので基盤剥き出し）さっそくセットアップしていきます。

■ SRTストリーミングを試してみる

SRTではカメラやエンコーダーなどの送信側をCaller、デコーダーなどの受信側をListenerと定義するようです。今回はListener側としてPCを使いフリーソフトウェアのFFmpegで受信してみます。SRT規格では1つのListenerに対し複数のCallerからのストリームが受信できますが今回は1対1で試しています。

・カメラ側の設定
　Destination IP　　　送信先のIPを設定します。ポートは1024以降で他の映像プロトコルで使用しない番号を選びます。(今回は8700としました）
　Latency　　　　　　バッファ時間（デフォルトは120ms）
　Encryption　　　　 暗号化。AES-128、AES-256が選べます。
　Passphrase　　　　 暗号のパスワード。10文字以上79文字以下に設定する。

以上を設定してストリーミングをスタートさせます。

FFmpegからはコマンドプロンプトで

$ ffplay -i srt://localhost:8700?mode=listener

暗号化をした場合は

$ ffplay -i srt://localhost:8700?mode=listener&passphrase=[Pass]

とします。[Pass]の部分は設定したパスワードと読み替えてください。
走らせてみると結構すぐにズバンと動画が流れてきます。遅延的には2秒くらいですが（カメラ処理、SRT通信、PC側のデコードの総合時間）何にもチューニングしていないのでもう少し時間は縮められそうです。映像は解像度1920×1080 60fps、H.264 7Mbpsくらいで送っています。海外でスポーツ中継の事例では遅延0.5秒というのがあるらしいです。

　

放送用IPほどの遅延のなさはありませんが従来のRTPやRTMPに比べて十分短く、エラー訂正機能も強化されていることから制作コストを抑えて伝送できるのは十分魅力的だと思います。遠隔地への中継や、ちょっと広いところでwifiを使ってケーブルを使わず伝送など気軽にリアルタイム中継ができるようになるのではないでしょうか？