今度、屋外でユーザーテストをする予定があって、映像をどう撮って見学者に配信するか検討をしています。屋外である製品を試用している参加者の様子を、見学者部屋またはリモートにリアルタイム中継したいという感じ。スマホで撮ってZoomとかTeamsに流せば簡単なんですが、やはり参加者が持つスマホの手元をアップで撮りたかったり、バッテリー含め連続稼働時間の問題や通信途絶時にも映像は録画しづづけたいも。やはりビデオカメラ自体でも録画をしつつ送信をしたい。HDMI出力映像ネット送信できてバッテリーでも稼働するものといえば、パッと思いつくのはLiveShellシリーズとXperia Proでしょうか。
ソニー Xperia PRO / 5G対応 / ミリ派対応/SIMフリースマホ/防水/防塵/Snapdragon 865 / RAM 12GB ROM 512G...
LiveShell ProはATEM MINIと入替で手放してしまったし、Xperia Proは高い上にHDMI入力を使えるアプリは限られていてバクチ要素も高い（例えばZoomは現状ダメっぽい？）。
もうちょっと手持ち機材でなんとかできないかなと思いついたのがHXR-NX80がもっているRTMP/RTMPSの送信機能です。以前にちょっと試して上手くいかなくて諦めたんですが、再挑戦してみることに。OBS Studioのソースの1つとして入れられれば他の映像とミックスして記録ができます。
■RTMP/RTMPSとは？
RTMPはNDIやWebRTCなどよりも昔から（FLASH時代？）からある映像伝送のプロトコルです。RTMPSはSSLで暗号化するバリエーション（以下まとめてRTMPと記述します）。今でもYoutube LiveやTwitchなどのライブストリーミングサービスへの送信に使われてたりします。USTREAM華やかなりし頃のビデオカメラは単体でWi-FiにつながりRTMP/RTMPS送信する機能がついていました。ただUSTREAMが終わってしまった現在、あくまでUSTREAMを想定した設計になっていた製品と、カスタムサーバーを手入力して使えるものとで命運が分かれ、Panasonicなどは「ライブ配信機能自体の終了」のお知らせを出してたりします。そこはちょちょっとファーム修正してカスタムサーバーに対応して欲しかったものです。
とりあえず手持ち機材ではSONYの業務用カメラであるHXR-NX80がカスタムサーバー（URLとストリームキー）指定による送信に対応しているので、まずはこれでテスト。受け側であるOBS Studioは「メディアソース」ソースで「ローカルファイル」のチェックを外すとURLが入力できるフィールドが出現し、そこから設定できる_はずでした_。
■RTMPにはpushとpullがある！
さて早速NX80からOBSに映像を流してみようとするも、ちょっと様子がおかしい。
こちらはNX80のRTMP接続先の設定画面。URL欄とストリームキー（暗号キー）欄があります。
そしてこちらはOBSの「メディアソース」ソースのプロパティ画面。
どちらにもURLを指定する欄があります。一方OBS側にストリームキーを指定する欄はありません。ストリームキーはURLの最後につければ良いみたいとわかりましたが、それぞれが相手のURLを指定するってあんまり見ない設定方法です。OBS側は受け口をパスとストリームキーをまとめてURLの形で指定するのかなと思い、自身のIPアドレスをベースに適当に作って見てもダメ。
おかしいと思ってググってみるも、OBSからRTMPサーバーに配信する時の記事ばかりでなかなかOBSでソースとしてRTMPを受けることに関する情報が見つけられません。NX80側もYoutube Live向けの簡単な例があるだけ。
それでも調べているうちにわかったこととして、RTMPにはpushとpullに2種類の指定方法があって、文字通りpushは映像出力側（エンコーダー）から受け側のURLを指定して送りつけるもの、pullは映像受信側（デコーダー）が送り側のURLを指定するものです。そしてNX80はpushのみに対応し、pullの受け役はできない。OBSはpullのみに対応し、pushの受け役にはなれない。つまりどちらもクライアントとしてサーバーに要求する側であって、サーバーとして待ち受けすることができないという訳です。NX80は送る側、OBSは受ける側でマッチしているにも関わらず、どちらも自分が言い出しっぺになれなければ気が済まず、「聞く耳」は持たない、という感じでしょうか。
■仲介者としてRTMPサーバーを用意する
ということで、聞く耳持たないクライアント両方からの声を聞き互いを仲介する者としてRTMPサーバーが別途必要だということがわかりました。これの仕事はあくまで取り持ちだけなのでそんなに処理性能は求められないらしく、Apacheのライバル的なWebサーバーソフトであるNGINX(エンジンエックスと読みます）にRTMPエクステンションを組み込めば実現でき（両方とも無料で使える）、Raspberry Piなどでも充分実用になるようです。Raspberri PiでRTMPを受けてオンボードのHDMI出力から出力するというBlackmagic designのStreaming Bridgeみたいなこともできてしまうぽい（遅延は大きそうなものの、これはいずれチャレンジしたい）。
とりあえず今回は本当につながるかテストする為、OBSを動かしているWindows PC上にDockerで仮想サーバーを建てて実験してみました。
参考にしたのは以下の動画。
ただしLinuxでコマンドラインでの説明だったのを、WindowsのDocker Desktop（GUI）向けに適宜読み替えて進めました。Docker Desktop自体、初めてでよくわからず、なんでもできそうで以外とコマンドラインに頼る感じ？少なくとも最初にDockerイメージをもってくるところはシェルからやる必要がありました。ポイントは、動画の1:15くらいにあるように
|
1 |
docker run -d -p 1935:1935 --name nginx-rtmp tiangolo/nginx-rtmp |
としてやることです。-p 1935:1935がポイントで、ホストPCのポート1935と仮想PCのポート1935 を紐付ける（ポートフォワード）してやるわけです。これをしないでダウンロードサイトの例文で導入してしまうと通信ができない状態になります。コレでハマりました。きっと後からでも変更できるんでしょうけど、Docker Desktopからは見つけられませんでした。GUIでやろうとする場合はお気を付けください。
設定が完了するとこんな感じになりました。右上の5つのボタンの真ん中で起動した状態です。
「Ports」欄の上段がIPv4、下段がIPv6のポートです。IPv4が「0.0.0.0:1935」となっていますが、これで「（ホストPCのIPアドレス）:1935」で通信が届きます。
5つボタンの左から2番目を押すとシェル（コマンドプロンプト）が出現するので、あとはまた動画に従い、nano（テキストエディタ）をインストールし、/etc/nginx/nginx.confを書き換えます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
worker_processes auto; rtmp_auto_push on; events {} rtmp { server { listen 1935; listen [::]:1935 ipv6only=on; application live { live on; record off; push rtmp://127.0.0.1/streamout; } application streamout { live on; record off; } } } |
完成形はこんな感じ。 これで、エンコーダー（今回はNX80）からは
|
1 |
rtmp://192.168.0.153/live |
を指定し（ストリーム名は空欄）とし、OBS Studioの「入力」欄は
|
1 |
rtmp://192.168.0.153/streamout |
とします（Dockerを動かしているホストPCのIPアドレスが192.168.0.153と仮定）。
NX80ではRTMP設定画面で「実行」し、カメラ映像画面に戻ったあと更に「THUMBNAIL」ボタンを押さないと配信が開始されないので注意。もちろんNX80上で同時に録画もできます。
■LAN内でも遅延が2秒程度、WAN経由で45秒！
ついにこれでNX80のリアルタイム映像をOBSソースとして入れることができました。NX80の内蔵Wi-Fi（2.4GHz）経由で自宅内LANでのやりとりですが遅延が2秒くらいあります。配信解像度が「640×360」と「1280×720」から選べますが、どちらも遅延は変わらない印象。DockerとはいえホストPCの能力はそれなりにあると思うので、NX80のエンコーダーによる遅延でしょうか。あるいはRTMPというプロトコル自体がそういう傾向なのかも知れません。
他のカメラやマイクとあわせることを思うと2秒という遅延はかなり厳しいですね。これがWAN経由だとどうでしょう？iPhone 12 Pro Maxにテザリングして、docomoの4G回線でテストしてみました（自宅側はdocomo光 PPPoE）。結果は45秒程度の遅延がありました。更に厳しいですね。
ちなみにOSB側の「メディアソース」プロパティで「可能場合ハードウェアデコードを使用」オプションはONにしてしまうと絵と音がズレてダメでした。なんでもハード支援を使えばいいってもんでもないですね。絵だけGPU処理になって同期が外れてしまうんでしょうか。音ズレが発生している場合は確認してみてください。
現地では中継拠点（受け）とカメラ側双方がモバイルルーター+LTE回線環境になることを考えるとさらに酷いかも知れません。また受け側はグローバルIPアドレスが必要になる点も注意が必要でしょう。ゲストWi-Fiなどが提供されていたとしても使えません。
そう思うとちょっと現実的には使いづらい方法な気がしてきました。
やはりTeamsを経由して受け側でNDIで取り出してOBSに持ってく方が素直かも知れません。
■まとめ
とりあえず定期的に興味がわきつつもなかなか成功しなかったRTMPが実際に動かせてみられて有意義な実験となりました。今後他のファクターも加味して活用の場を見定めていきたいと思います。