「SRT」と検索すると、字幕ファイルの話と映像伝送の話が混ざって出てきます。片方は動画に字幕を付けるためのテキストファイル(SubRip形式)、もう片方はライブ映像そのものをインターネット越しに運ぶための伝送プロトコル。名前が同じだけの別物ですが、放送・配信の現場では厄介なことに、両方が同じ会話に登場します。「中継はSRTで受けて、字幕はSRTで納品」という文が、実際に成立してしまうのです。
この記事で扱うのは伝送プロトコルの側、Secure Reliable Transportです。字幕ファイルのほうの SRTの書き方や仕様 には立ち入りません。ここでは、品質の保証がない公衆インターネットでなぜライブ映像を運べるのか、その仕組みを現場の目線で整理します。
SRTプロトコルとは、放送機器メーカーが開いた規格
SRTはカナダの映像伝送機器メーカーHaivisionが開発したプロトコルです。もともとは自社製品のための技術でしたが、2017年のNAB Show(全米放送機器展)でソースコードごとオープンソース化されました。同じ年の5月にはHaivisionとWowzaが推進団体SRT Allianceを設立し、現在の参加企業は600社を超えています。特定ベンダーの独自技術ではなく、エンコーダーからクラウドサービスまで誰でも実装できる共通言語になった。この経緯が、後述する普及の速さを支えています。
名前の三語がそのまま設計思想です。Secure(暗号化)、Reliable(損失からの回復)、Transport(伝送)。並べてしまえば簡潔ですが、考えてみると「Reliable」は妙です。SRTは、信頼性をいっさい保証しないUDPの上に作られているからです。
UDPなのに確実に届く、ARQと遅延バッファの仕組み
信頼性が欲しいなら、最初から再送保証のあるTCPを使えばいいのではないか。そう考えたくなりますが、TCPの再送は律儀すぎます。パケットが1つ失われると、それが再送されて届くまで後続のデータ全体が待たされる。ライブ映像にとって、この「全員で待つ」挙動は致命的です。SRTが選んだのは逆の道でした。順序も到達も保証しないUDPで送り続け、失われたパケットだけをARQ(自動再送要求)でピンポイントに取り返すのです。UDPの上に必要な信頼性だけを自前で作り込むというこの発想は、HTTP/3を支える QUICプロトコル にも通じます。
これを支えるのが受信側の遅延バッファです。受信機は届いた映像をすぐ再生せず、設定した時間(既定値は120ミリ秒)だけ手元に貯めます。この待ち時間のうちに、抜けたパケットの再送を間に合わせるわけです。目安は往復遅延(RTT)の3〜4倍。海外との中継のように回線が荒れるなら長めに、国内の光回線どうしなら短めに、と現場の条件に合わせて調整します。
重要なのは、間に合わなかった再送をSRTが潔く諦めることです。期限切れのパケットは捨てられ、映像は一瞬乱れるかもしれませんが、止まりはしません。遅延と信頼性のトレードオフをプロトコルが勝手に決めるのではなく、運用者がバッファ長という一つの数字で決める。これがSRTの本質だと言っていいでしょう。Secureの側も実務的で、AES-128/256による暗号化が伝送層に最初から組み込まれています。
RTMPと何が違うのか
配信の現場で長く使われてきたRTMPと並べると、SRTの輪郭がはっきりします。
遅延:TCPベースのRTMPは実運用で2〜5秒程度になることが多いのに対し、SRTは1秒前後まで詰められます。中継先のリポーターとスタジオが会話する場面では、この差がそのまま「間」の不自然さになります。
暗号化とロス耐性:RTMPは素のままでは平文で、暗号化するにはRTMPS対応を送受両端で揃える必要があります。SRTは標準で暗号化され、パケットロス時も止まるのではなく乱れながら流れ続ける方向に倒れます。取材映像が「遅れて止まる」のと「一瞬乱れて続く」のと、生放送でどちらを取るかは明らかです。
コーデックの自由度:RTMPは事実上H.264とAACの組み合わせに縛られています。SRTは中身に関知せず、MPEG-TSに載るものならHEVCでも何でも運べます。4K中継でHEVCを使いたい、と決めた時点でRTMPは選択肢から外れるのです。
専用線の代わりにインターネットを使う
では、実際の放送現場でSRTは何を置き換えているのでしょうか。従来、中継先から局へ映像を送るには、専用線を引くか、衛星回線やFPU(無線中継装置)を確保するのが常道でした。信頼できる代わりに、高い。日程の決まったスポーツ中継ならまだしも、急な取材や小規模なイベントのために毎回用意できるものではありません。
SRTはここに「公衆インターネット+暗号化+損失回復」という選択肢を持ち込みました。中継先のカメラ映像を局に上げる、系列局間で素材を伝送する、クラウド上の処理系へライブ映像を打ち上げる。場面は違っても、やっていることは一つです。光回線やモバイル回線という保証のない経路を、遅延バッファの分だけ信頼できる「回線」に変えている。
回線費の桁が変わるのだから、広まらないはずがありませんでした。
NDIとの住み分け
似た文脈で名前の挙がるNDIとは、守備範囲が異なります。NDIは局内・スタジオ内のローカルネットワークで複数の映像ソースを低遅延にやり取りするための規格で、タリーやPTZカメラの制御まで面倒を見る、いわば構内の配線をIP化する技術です。NDI自体にもインターネット越えの拡張はありますが、出自も得意分野もLANの中にあります。放送設備の非圧縮IP化という文脈では SMPTE ST 2110 も同じくLANの中の規格です。一方のSRTは、不安定なWANを越えて映像を確実に届けることに特化しています。
だから両者は競合というより分業です。局の外からはSRTで受け、局内はNDIで引き回す。リモートプロダクションの構成図では、この組み合わせが半ば定石になっています。
NAXAの取り組み
NAXAはテレビ業界向けの独自技術として、日本語に特化した音声認識エンジンと、テロップ・字幕に対応した画像解析・OCRエンジンを保有し、システム開発を手掛けています。伝送プロトコルとしてのSRTが整えているのは、ライブ映像がリアルタイムに局やクラウドへ集まってくる環境であり、そこにこうしたAI処理をどう組み込むかは、私たちの取り組みと地続きの領域です。
映像がインターネット越しに自在に飛び交うようになった今、問いは「どう運ぶか」から「運んだ映像をどう活かすか」へ移りつつあります。ライブ・リモート環境の映像パイプライン構築やシステム開発に関心のある方は、お気軽にご相談ください。
