Newtek NDI®とUnreal EngineでAR/VR を作ってみた

 InterBEE 2021 (国際放送機器展)にCIS社の新製品Newtek NDI® 対応の4K60PカメラVCC-4KNDI、DCC-4KNDIを展示しました。カメラの展示というと何か撮って終わりというのが普通ですがそれでは芸がないのと、カメラには新機能があるのでそれを使ったアプリケーション展示の一例として簡単なバーチャルリアリティシステムを作ってみました。本当はグリーンバック使って合成したかったのですがブースの関係上そんなスペースも取れないのでARとして仕立ててみました。
 ブースにその辺の説明を提示していなかった私が悪いのですが、極小スペースでそんなことやっていると来場者に気づかれずカメラ見てもLANケーブル1本しか出てないのでどうやっているのかわからない、そもそもNewtek NDI®って何ですか?という質問が多くなかなかシステムの説明までは辿り着けなかったというのが実状でした。反省を踏まえどうやってAR/VRシステムを作ったかをここで公開いたします。


■ バーチャルスタジオの基本構造
 まず初めにテレビでよく見るバーチャルスタジオってどんな構造で作られているかを説明します。バーチャルリアリティの名のとおり現実空間と仮想空間を用意します。仮想空間を用意するというのはCGの空間ってことです。現実空間には実際にカメラを設置するのですが仮想空間にも同じ位置に仮想のカメラを設置します。この2つのカメラは全く同じスペックにする必要があります。スペックとはつまりイメージセンサーのサイズ、レンズの画角、焦点距離などです。これで両方のカメラで写したスケールが一致することになります。次に現実空間にあるカメラの位置や傾きを検出するトラッカーと呼ばれるものを使って同じ動きを仮想空間にあるカメラにシンクロさせます。最後に現実空間と仮想空間を合成して出来上がりです。
カメラを動かせば合成されたCGも同じように動いてテレビでよく見るようなバーチャルスタジオになります。あとはレンズのズームやフォーカスと連動してCGも動けばよりリアルに見えることになります。

AR-VR structure

■ バーチャルリアリティの構築にUnreal Engineを使う
 こんなシステムの構築に何を使う?お高いんでしょ?と思いがちですがうってつけのプラットフォームが存在します。ゲームエンジンと呼ばれるEpic社のUnreal Engineというものです。

Unreal Engine Logo

Epic Unreal Engine

外部リンクへ


 ゲームエンジンとはその名の通りゲームを作るためのソフトウェアツールです。現在では実写かと見間違えるような描写がガンガン動くゲームがたくさんありますがそういったものもUnreal Engineのようなゲームエンジンで作られています。ハイフレームレートでリアルタイムに映像が動いてしまうのと最近ではレイトレーシングなど高品質な画像を実現する機能も盛り込まれているためゲーム業界だけでなく映像製作や建築シミュレーションなど他分野でも使われるようになっています。(最近だとインカメラVFXなんか注目されてますね。)いくつかのバーチャルスタジオシステムでは内部のエンジンにUnreal Engineが組み込まれていたりします。

 というわけで、
 ・映像の入出力
 ・バーチャル空間(CG空間)の作成
 ・仮想カメラのコントロール
 ・実カメラのレンズ情報を取得
 ・実カメラの傾き、位置を取得
 ・合成(必要ならクロマキーなどの処理)
 以上をUnreal Engineでまかないます。ってほとんどコレで作るような感じです。Unreal Engineにはプラグインという形で機能拡張できるようになっており、サードパーティ製の製品に対応させたり新しい機能を追加ということができる仕組みになっています。ちなみにUnreal Engineの個人利用は無償で、サポートを受けたいとか成果物を販売するようなときに何%かEpic社に支払う仕組みになっています。Unreal Engineの対抗馬であるUnity Technologies社のUnityも同じような感じです。

 実際の動作環境は
CPU : Intel Core i7-5960X 3GHz
RAM : 32GB
GPU : NVIDIA Geforce 3080Ti 12GB
OS : Windows 10 Pro
Network : 1GB Ethernet(オンボード)
Unreal Engine : Ver 4.27
かなりへなちょこな構成です。CPUなんか数世代前です。マザーボードごと変えたい気分です。Unreal EngineはGPUを主に使うためグラフィクスボードだけは最新の強力なものを使います。とはいえ今回のプロジェクトはCPU20%くらい、GPU30%くらいの使用率でした。この辺りはプロジェクトの複雑さによって変わってきます。

■ 入力のカメラとしてNDI対応 CIS社 VCC-4KNDIを使う
 Unreal Engineには外部から映像を取り込むことができます。制作用のカメラということであればSDI対応キャプチャーカードを使うことになります。AJA社のKONAカードとかBlackMagicDesign社のDeckLinkカードが一般的でUnreal Engineにそのプラグインがあります。今回はSDIではなく放送用IPであるNewtek NDI®を使っています。これならキャプチャカードが必要なくマザーボードのオンボードにある1Gb Ethernetで十分役割を果たします。

CIS VCC-4KNDI

NDI対応 4K60P 18倍ズームレンズ搭載カメラ
CIS VCC-4KNDI, DCC-4KNDI レビュー

レビュー記事へ


 使用したNDI®カメラはCIS社のVCC-4KNDIという4K/60Pに対応したBOXカメラです。NDIカメラというとPTZカメラばかりなのですが後述のトラッカーを使うためにはBOXタイプであることが都合が良かったりします。またVR/ARにはフレームレートが高い方が良く、60P以上が扱えることが重要です。NDIカメラにはNDI|HXというLong-GOPのコーデックを採用しているものがほとんどですがこのカメラはFull NDIを採用して高画質、低遅延を実現しています。VR/ARで使うことを考えるとシステム的に低遅延であることが望ましく、グリーンバックを使ってキーイングが必要な時には高画質であることが要件となります。Unreal Engineからも制御しやすい機能がカメラに備わっている上、PoEにも対応のため映像、制御、電源がLANケーブル一本で済ますことができます。

Newtek NDI® Logo

NDI SDK for Unreal Engine

外部リンクへ


 NDI®をUnreal Engineで使うにはプラグインがNewtek社から提供されているのでそれをインストールします。現在のところUnreal Engineへの対応バージョンが4.25と4.26なのですが4.27で使おうとしてコンパイルが走ったので問題はなさそうと勝手に思ってます。VR/ARのソースとして使えるようにコードを書いていきます。Unreal EngineにはBlueprintというコードを視覚的に書いていく機能(実際には各機能のノードを繋いでいく)がありプログラマーでなくても作れるというのがウリなのですが実際にはプログラム行為そのものなのでその素養はあった方がいいと思います。Blueprintも複雑になると見にくくなるのでコードで書いた方が見やすいなぁと思うこともあります。(もちろんC++で書いていくことも可能)


 Blueprintを使ってNDIが取り込めるようコードを書いていきます。(上の左の図)NDI Unreal Engine SDKには送受信のやり方が載っていてそれを踏襲するだけなのですが受信方法がこちらのやりたいこととは違っていたのでSDK記載の関数表を見ながらこうなんじゃないの?という感じで書きました。ARに使うカメラが一台だけなのでIP直打ちで設定しても問題なかったのですがNDIの説明をするためにUnreal Engine実行中にメニューを出してそこからNDIソースを選べるようにしました。
 NDIではmDNS(AppleだとBonjour)を使って同一ネットワークにあるNDI機器をスキャンします。この時はまだ映像のストリームは流れていなくてお互いの機器のリンクが確定してから実ストリームを流すようになっていて無駄なネットワーク帯域を使わないような仕組みになっています。NDIソースは機器名(アプリ名)という形式になります。入力だけでなくNDI出力ができるようにしたので表示されていますがモザイクで隠れているコンピュータ名がUnreal Engine機です。これを選んでしまうと当然映像は回ることになります。VCC-4KNDI、DCC-4KNDIはカメラのほうで名前やアプリ名部分を変更することができます。

■ カメラの傾きや位置を追跡するVR用トラッカーを用意する
 AR/VRで重要なカメラの動きを検出するトラッカーの存在があります。古くはカメラ三脚のヘッドにジャイロセンサー、ローラーに回転検出装置なんてつけたり赤外線を使った光学式トラッカーなんてものがあります。だいたいはシリアル信号(RS422とか)で出てきたデータを使用するバーチャルスタジオシステムに合わせるよう変換ボックスなるものをこしらえてデータを渡すという超絶面倒かつお高くなってしまうというのが常でした。展示会で使うのにそんなコストはかけられないので安価なもので試してみました。

VIVE Tracker&BaseStation

VIVE Tracker

外部リンクへ

Valve Index Base station

外部リンクへ


 ここ数年DIYでバーチャルスタジオを作る方々にとっては定番のトラッカーが存在します。そんな人いるのか?と思うかもしれませんが世界広しです。十分いらっしゃいます。本来はヘッドセットつけてVR/ARを体験するシステムのオプション品です。BaseStationから照射された赤外線レーザーをVIVEトラッカーが受けて傾きや位置情報をBluetoothでPCへ飛ばすといったものになります。本来はヘッドマウントシスプレイ(HMD)が必要なのですがドライバソフトをハックすることにより無しでもいけます。(私もはなから買ってません)Epic社がその方法を公開しています。

  Unreal Engine LiveLinkXR
 Vive トラッカーを HMDなしで使用する
    外部リンクへ

 トラッカーとベースステーションの距離は最大5mくらいです。間に遮るものがあると計測できなくなってしまうので複数ベースステーションを置くやり方もあります。トラッカー自体はバッテリー動作し7.5時間もちます。

 カメラにトラッカーを取り付けます。Amazonで購入したリグを使ってます。PTZカメラだとこういう使い方は出来ません。内部にエンコーダーがあるPTZカメラもありますがメカなのでズレてくるのと高精度なパーツを使ってるカメラ=高価なものカメラになってしまいます。Unreal Engineではトラッカーとイメージセンサーの位置の違いを調整したり、トラッカー情報と映像入力のタイミングを合わせたりすることができます。実際のカメラの動きをUnreal Engine上の仮想カメラにリンクさせます。

■ レンズ情報をカメラからRestAPIで取得する
 カメラのレンズからズーム、フォーカス、アイリスの値を取り込みます。一般的に放送業務用レンズを使う場合キヤノンかフジノンのVR対応で400万くらいするモデルを使います。レンズにシリアル出力がありこれを使うことになります。もしくはPLレンズなどギアが付けられるものにエンコーダーをつけてシリアル出力といった感じになります。どちらにしてもカメラにごてごてケーブルなりボックスなりを付けることになります。今回使用したCIS VCC-4KNDIカメラにはシリアル経由でレンズ情報を読み出すこともできますがこのシリアル通信を別用に使いたかったのでもう一つの通信方法であるRestAPIを使いました。

RestAPI Logo

RestAPI(RestfulAPIとも言います)はhttp, httpsプロトコルを使って簡単な情報をデバイス間通信する方法です。映像ハードウェアではまだまだ使われることは少ないかもしれませんがWebサービスを構築するような業界では既に一般的です。今後映像機器がネットワークで機器が繋がるようになると必要になってくる技術です。CIS VCC-4KNDIではAPIを叩くとJSONでステータスが返ってくるようになっています。

VaRest Plugin logo

UE4 plugin VaRest

外部リンクへ


 Unreal Engine上でRestAPIを使って通信するプラグインは既に存在します。しかも無償。業界標準の機能を使えばインターフェースを一から作る必要はなくなるという好例です。これを使いBlueprint上でカメラから逐一レンズ情報を引っ張ってこれるようにします。なんならUnreal Engineからカメラのコントロールをすることも可能になります。もちろんシリアル通信を可能にさせるプラグインも存在するので繋ぐ機器によって使い分けることもできます。選択肢が多いことはいいことです。


 様々な種類のデータをやり取りしている割にはカメラとPC間のケーブルは1本のみです。(カメラは他にRS232→レンズコントローラー、ビューファインダー出力→ATOMOS SHINOBIに接続)通常バーチャルスタジオで使うカメラはそれ用だけでケーブルを数本〜十数本使ったりするのでかなりスッキリしてます。カメラをレンズコントローラーで操作してUnreal Engineから常にレンズ情報を取りにいくといった感じになります。


■ リアルタイムコンポジット(合成)
 最終的に仮想世界と現実世界を合成します。従来のバーチャルスタジオシステムではキーイングや合成を別の機器で行ったりしていたのですがUnreal Engineにはそのどちらの機能も備わっているのでそれを使うことにします。

 合成にはUnreal Engineのリアルタイムコンポジットを使用します。3種類のレイヤーが用意されていて
  ・Media Plate  入力動画レイヤー ここではNDI®入力映像
  ・CG Layer    Unreal Engineで作ったCG空間に置いたオブジェクト(アクタ)
  ・CG Matte   グリーンバックで抜けないものやスタジオの天井とか隠したいものに使ったりします。
AdobeのPhotoshopやAfterEffectsを使用している方であれば同じように理解できます。レイヤーは複数作ることができるので背景CGレイヤー、その前にグリーンバックで抜いた映像レイヤー、さらにその前にCGレイヤーを置くといった複雑な構成も可能です。


■ まとめ
 放送用バーチャルスタジオを構築しようとするとどうしても数千万〜億超えのような金額になってしまいます。よほどの覚悟がないと導入するのにかなり躊躇することでしょう。自身がスタジオ設計者なのでバーチャルスタジオの話が出てきても金額聞いて話が流れたなんてことはよくあることです。今回のような方法を使えばかなり安価に済むので小規模スタジオでの運用や将来のステップアップを見据えた第一歩として考えることもいいのかもしれません。Unreal Engineを使うのにプログラムしなければならないという手間はありますが映像業界でのUnreal Engineの普及が見込まれることが予想されるので今のうちから慣れておくといった考え方もあると思います。


■ 最後に
 展示会向けにこのコンテンツを作ったのですがもう少し時間があれば実現できたかなぁと思ったことを出してみます。

・HDR対応にしてみたかった
Unreal Engine、CIS VCC-4KNDIともにHDR(High Dynamic Range)に対応しています。HDRが使えれば画質的によりリアルになるはずです。いかにもCGといった感じではなくなるのかもしれません。ただし対応HDRの種類が違うので(Unreal EngineはPQ、CIS VCC-4KNDIはHLG)カメラからのストリームをUnreal Engineに合わせる必要があります。

・VIVEトラッカーのブレを抑えたい
この手のセンサーにはよくあることですが受け取る生データに少なからず振れ幅が生じます。結果的に仮想カメラが見るCGオブジェクトが細かく揺れてしまうことがあります。データの揺らぎを抑えるためにローパス処理は追加していたもののまた別なノイズ除去フィルタを追加する必要がありそうです。


 

グローバルシャッターとローリングシャッター

カメラには一コマ一コマ確実に露光/遮光するためのシャッターが搭載されています。大きく分けてグローバルシャッターとローリングシャッターというものが存在していて世の中にあるほとんどのカメラはローリングシャッターが使われています。このローリングシャッターは普通に使っている分には問題がないのですが早い動きのある被写体やカメラが振動などでブレたりすると画面が歪んでしまうという特性があります。走っている電車の窓が歪んでるとかプロペラの形が変になっているとか、ドローンやアクションカメラの映像がぐにょぐにょになっているとかよく説明で使われることと思います。そういった現象の出ないグローバルシャッターとともにカメラシャッターの説明をしていきます。

  高速で移動する物体は歪んでしまう
  プロペラ系はキモいくらい変な形になる

■ ローリングシャッターだとなぜ画像が歪むのか?
ローリングシャッターで高速で動いている物体や振動で画像が歪んでしまう理由は全く同じ時間に一画面を記録していないからです。デバイスの種類にもよりますが記録のタイミングが全画面同時ではなくシャッターの降りる時間内である方向からスキャンして記録していきます。この時間内で被写体が動いてしまうと歪みやブレとなって現れてしまいます。デジタルカメラデバイスでよく使われるCMOSイメージセンサーで説明していきます。

ローリングシャッターのCMOSイメージセンサーでは撮像をある方向から1ラインずつ露光してデータを取り込んでいく構造になっています。横棒の長さはシャッタースピード時間です。次のライン読み込みまで時間がかかってしまうためこの時間のずれが画像の歪む原因となります。同じ画面の上下で露光しているタイミングが違うので当然そうなってしまいますね。最近では高速読み取り技術を使ってほとんど歪みが出ないようにしているセンサーもありますが細かいブレは抑えらていません。

一方グローバルシャッターのセンサーでは全画素同じタイミングで露光しデータの読み出しも同じタイミングで行われます。なのでローリングシャッタのような歪みというのは起こらないことになります。(ただし全く歪みとかブレが出ないというわけではなくシャッタースピードと被写体の移動スピードが適切でなければブレはでます。)
こうしてみるとローリングシャッターダメじゃんと思われるかもしれませんがいくつかの理由でそれが別に構わないとされてきた経緯があります。フィルム時代のシャッターがどうなっていたか説明します。

映画用フィルムカメラのシャッターはロータリーシャッターと言って図の回転するパックマンのような形の口にあたる部分を広げたり狭めたりすることで調整します。映画のフレームレートは24なので90°なら1/96sec、180°なら1/48sec というような感じです。(普通は180°を使う)パックマンは1コマにつき1回転して遮光している間に次のコマにフィルムが送られます。というわけで映画用フィルムカメラは全画面同時露光でなかったのです。スチルカメラで使う上下に幕が移動するフォーカルプレーンシャッターも同じことです。CMOSイメージセンサーほどのブレや歪みは出ませんがそれでもカメラってそういうものというイメージがありました。

ちなみにCMOSイメージセンサーと機械式回転シャッターを組み合わせてローリングシャッター歪みを低減したカメラってのも存在します。(SONY F65RS) ただしメカニカルシャッターはそれ自体振動の元になったり故障の原因にもなったりします。最新のデジタルシネマカメラはそういった機構は付いてないようです。後継のVENICEには無さそうですしね。
そもそも映画はフレームレートが低いので素早くカメラを振るような撮影はしません。

■ デバイスによって変遷するシャッター方式
ビデオの場合はちょっと複雑で時代により使う撮像デバイスによってローリングシャッターだったりグローバルシャッターだったりしていました。
撮像管:ローリングシャッター 1980年代まで
CCD:グローバルシャッター 1980年代〜2000年代初めまで
CMOS:ローリングシャッター 1990年代後半〜

撮像管はテレビ創生期からあったデバイスで真空管の一種のようなものです。焼き付きがあったり振動に弱く、レジずれ調整とかいろいろ手間のかかるもので長らく業務でないと使わない代物でした。その後CCDイメージセンサーが出てきて撮像管の持つ物理的なデメリットが解消され民生用カメラにまで一気に使われることになります。しかもこいつは最初からグローバルシャッターです。2000年代初めまでイメージセンサーといえばCCDでした。ただしデメリットがなかったわけではありません。CCD一番のデメリットはその複雑すぎる構造です。それゆえ製造コストが高く高解像度化も難しい、消費電力も高いということで現在ではほとんどCMOSにとって代わってしまいました。(工業用とか特殊用途にはCCDが現在でも使われています)そしてつい最近になってグローバルシャッターのCMOSが出てきたということになります。

■ グローバルシャッターとローリングシャッターの使い分け
世の中のカメラが全てグローバルシャッターCMOSになったかというとそうではありません。ローリングシャッターCMOSと比べるとCCDほどじゃありませんが構造が複雑なためコストは高く、感度は若干低め(同じセンサーサイズなら)、消費電力はチョイ上がります。コスト重視のカメラならローリングシャッター1択になってしまいます。なのでまだまだローリングシャッターカメラがほとんどで撮影する被写体によって使い分けることが必要だと思ってます。
グローバルシャッターカメラで優位な撮影を挙げると
 ・動きの速い被写体の撮影(スポーツ中継とかカメラで被写体を追う場合)
 ・撮影時に振動がどうしても避けられない場合(ドローン撮影、車載映像など)
 ・後で画像解析が必要な場合(歪みがアーティファクトノイズとなる)
 ・VFXでクオリティの高い合成を実現させたい場合(ブラーは後処理でかければいい)
 ・複数のセンサーを使うVRカメラの後処理でスティッチング(VR用に複数センサー画面を貼り合わせて合成すること)をするケース
ということになります。単純にブレない映像を見せる場合やローリングシャッターの歪みが余計なアーティファクトになるのを防ぐといった感じになります。

グローバルシャッターカメラで撮った映像の例を挙げておきます。CIS VCC-4K2 4K60Pカメラを使用し首都高の車載映像です。
 Metropolitan Expressway 4K/60P HDR Shooting HLG Version

標識の看板も読めますし、段差の振動も自然。両脇の流れもブレずに収録されていますがグローバルシャッターならではといったところです。CISグローバルシャッターカメラの実例としては
 ・国内某サーキットのゴール判定での使用(300km/h近いスピードでも歪まずブレない)
 ・VFX用ロボットカメラとして使用(ブンブン振り回すらしいのでグローバルシャッターが適当)
 ・大御所海外ヘビメタバンドのドラマーがライブで自身の撮影に使用(ドラムはかなりの振動になります。しかもドラマー個人の所有物)
というのがあります。

撮り方を工夫すればローリングシャッターでもいいところまで追い込めたりしますがグローバルシャッターカメラを経験するとあんまりローリングシャッターで撮りたくなくなるのも事実です。

SRTでストリーミング

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

SRT Logo


SRTはカナダの企業 Haivision社が提唱したストリーミング技術でSecure(安全)、Reliable(確実)、Transport(ネットワーク伝送)の頭文字をとったものです。類似の規格にZixiとかRISTなどがありますがオープンソースでアライアンス活動に積極的ということで450社以上のメンバーの参加、25,000以上の組織で使われているようです。(2020年12月時点)
ちなみに全米テレビ芸術科学アカデミー (NATAS) からエミー賞を受賞しています。(テクノロジー&エンジニアリング部門 2018年度)

 

 

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

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

プロトコルSMPTE-2110SMPTE-2022-6Evertz
ASPEN
SONY NMINewTek NDI
通信方式UDPUDPUDPUDPUDP/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を使ってケーブルを使わず伝送など気軽にリアルタイム中継ができるようになるのではないでしょうか?