WSL2(EC2-1)への映像転送・表示確認メモ(SRT版)
EC2-1からEC2-2のUDPトンネリングは、現時点で上手く動いていない。
WSL2(EC2-1)への映像転送・表示確認メモ(SRT版)
2026年1月2日
背景と動機
本メモは、RTSP/SRT を用いた映像転送系を、Windows 10 + WSL2 環境上で段階的に構築・検証する過程で得られた知見を整理することを目的として作成したものである。WSL2 が NAT 構成で動作することにより、LAN 上の別ホストから WSL2 へ UDP/SRT を直接到達させにくいという制約があり、Windows ホストを明示的な中継点として扱う構成に整理する必要があった。本メモは、SRT での転送と、WSL(EC2-1)側での映像表示が成立した最小構成を、今後の多段転送(EC2-1 → EC2-2)や実環境展開に再利用できる形で記録するものである。
1. 環境概要
ネットワーク構成
-
送信元(RTSP / mediamtx)
-
192.168.0.23
-
-
Windows ホスト(中継点)
-
192.168.0.3
-
-
WSL2(EC2-1)
-
eth0: 172.29.8.198
-
-
OS / バージョン
-
Windows 10
-
WSL2(Ubuntu 24.04)
-
WSL バージョン: 2.6.3.0
-
前提条件
-
mediamtx.exe は 192.168.0.23 上で起動済み
-
RTSP は以下で配信中
rtsp://127.0.0.1:8554/stream1 -
WSL2 は NAT 構成(172.29.0.0/20)
2. 課題と結論
課題
-
LAN 上の別ホスト(192.168.0.23)から、WSL2(EC2-1)へ直接 SRT(UDP)を到達させにくい
-
一方で Windows ホスト(192.168.0.3)は LAN と WSL2 の両方に接続点を持つ
原因
-
WSL2 は Windows 内部 NAT 配下であり、LAN 側から WSL2 の listener へ直接到達する前提が成立しないケースがある
-
そのため、SRT の受信点(listener)は Windows 側に置き、WSL 側へは caller で接続する構成が安定する
結論
-
Windows ホスト(192.168.0.3)を明示的な中継点にする
-
構成は以下に固定する
3. 今回確認したゴール
-
SRT 経由で EC2-1(WSL)に映像を到達させ、EC2-1 で映像が表示されること
→ 成功
4. 実行コマンド(成功構成:SRT)
ポートは以下で統一する。
-
Windows(中継)受信: 9999(listener)
-
EC2-1(WSL)受信: 10000(listener)
4.1 EC2-1(WSL)側:SRT受信・映像表示(listener)
※ 先に起動して待ち受け
要点:EC2-1 側は listener とし、Windows 側から caller で接続させる。
4.2 Windows ホスト(192.168.0.3):SRT 中継(受信 listener → 再送 caller)
役割:
-
192.168.0.23 からの SRT を 9999 で受信(listener)
-
EC2-1(172.29.8.198)の 10000 へ caller で接続して再送
4.3 送信側(192.168.0.23):RTSP → SRT 送信
要点:RTSP(mediamtx)を受けて、MPEG-TS 化した上で SRT で Windows(192.168.0.3)へ送る。
5. 結果
-
EC2-1(WSL)上で映像表示を確認
-
構成:
-
RTSP → SRT → Windows中継 → SRT → WSL
-
-
ネットワーク経路・GStreamer パイプラインともに正常
6. 補足事項
-
SRT は UDP 上で動作するため、疎通確認は UDP ポートで行う
-
Windows 側受信: UDP/9999
-
EC2-1 側受信: UDP/10000
-
-
Windows Defender Firewall により、上記 UDP ポートが遮断される場合がある(必要に応じて許可ルールを追加する)
-
実通信に使用される WSL 側インタフェースは eth0(172.29.8.198)とする
7. 次のステップ(予定)
-
EC2-1 → EC2-2 の UDP / socat 転送確認(WSL 内部の 172.29.x.x 間で実施)
-
制御系(戻り通信)の追加
-
ビットレート制御・制御パケット注入