More than 5 years have passed since last update.

「新しい映像伝送プロトコル SRT を試す」の話をしました

Last updated at 2018-09-02Posted at 2018-09-02

先日開催されたStreaming Conference #4で「新しい映像伝送プロトコル SRT を試す(増強版)」の話をしました。
(実はその前の #3のときに5分のLT枠で話したのですが、全く時間が足りなかったので今回は15分枠でやらせてもらいました。)

発表資料のリンク: https://www.slideshare.net/tetsu.koba/try-new-transport-protocol-srt-ver-2

録画: https://freshlive.tv/tech-conference/232370
(開始後44分くらいから私の発表)

補足説明

latencyの設定

latencyの設定は送信側と受信側の双方から設定可能で、大きい方が採用されます。
なので、serverになるほうは小さな値(20ms)を設定しておいて、client側がRTTを測定して、その2.5倍の値を設定するのがよさそうです。
ひとつのserverに対して複数のclientが接続できますが、latencyの設定はそのコネクションごとに別々になります。

送信側と受信側のどちらもserver になれるのは開発時には特に便利

RTMPでは映像を送信する側がclient, 受信する側がserver になります。
開発中などでは映像を送信する側がserverになってくれるほうがネットワーク構成が単純で使いやすかったりします。
このために映像を送信する側にrtspサーバになれる機能を入れたりするのですが、ffmpegやgstreamerではあまり簡単にできなくて、それなりにプログラムを書かなければいけなかったりします。
gstreamerでSRTを使っている場合は、srtclientsink を srtserversink に入れ替えるだけなので、そういう場面でも簡単に対応することができます。

wasm からでもSRTは使える？

ブラウザの中で動作するWebAssembly からSRTが使えるようになったら面白いというアイディアがありますが、現状はブラウザの中で動作するWebAssemblyの環境からUDP socketを扱うことはできないので、残念ながらボツです。

回線状況悪化時のエンコーダへのフィードバック

SRTはその性質上、常に通信の実効帯域を把握しています。回線状況が悪化してパケットロスが増えると相手側に再送要求を出すわけですが、エンコーダ側にも実効帯域が低下したことを通知すれば、エンコードするビットレートを下げることができるはずです。ここまでの実験はしていませんが、これができると屋外からのライブ配信でも切れにくく粘ることができそうです。