MediaMTXでラズパイカメラV1の映像をストリーミングしてみた。

 この前作ったダイレクトドライブなラジコンにカメラを搭載してFPVで操作してみたいと思って、LuckFox上でμStreamerを動かしたやつを載せてみたんだけど、このモータが結構早いのでもっと低遅延にしたい。

ということでもっと低遅延にできる方法が無いかどうか試してみることに。LuckFoxはビルドしてFlashに書き込んでっていうのが何回も往復するのが面倒なので、まずはRaspberry Pi Zero上で試してみることに。

久しぶりにRaspberry Pi Zeroを出してきたのでまずはOSをクリーンインストール。Raspberry Pi Imagerからセットアップして、WiFi設定までできるのは便利になったなぁ。Debian Trixieになった。

カメラ回りも少し仕様が変わっているみたい。raspi-configからの設定はいらなくて自動で認識するとか。

とりあえずセットアップが終わったRaspberry Pi Zeroに昔購入したRaspberry Pi Camera V1の互換品を取り付けて起動してみる。この前uStreamerで不安定だったリベンジ。

起動したら

rpicam-hello --list-cameras

と実行してみる。前のバージョンではlibcameraだった部分がrpicamに変更になっている感じかな？

Available cameras
-----------------
0 : ov5647 [2592x1944 10-bit GBRG] (/base/soc/i2c0mux/i2c@1/ov5647@36)
    Modes: 'SGBRG10_CSI2P' : 640x480 [58.92 fps - (16, 0)/2560x1920 crop]
                             1296x972 [46.34 fps - (0, 0)/2592x1944 crop]
                             1920x1080 [32.81 fps - (348, 434)/1928x1080 crop]
                             2592x1944 [15.63 fps - (0, 0)/2592x1944 crop]

こんな感じで差し込んだだけで認識してるみたい。互換品でもとりあえず問題なく自動で認識できた。確かに電源を入れたときに一瞬カメラのLEDが点灯したのでその時に確認してるのかな？

rpicam-jpeg -n --output test.jpg

次に静止画を撮影するコマンドで写真を撮影して、WinSCPでPCに転送して確認してみた。(SSHで作業しているため)
写真もバッチリ取れてるのでまずはカメラの動作確認はOK。

カメラの動作確認ができたのでMediaMTXをダウンロードして実行可能にする。MediaMTXはWebRTCを使ってカメラの映像をブラウザからストリーミングできる。

wget -P ./mediamtx https://github.com/bluenviron/mediamtx/releases/download/v1.15.1/mediamtx_v1.15.1_linux_armv6.tar.gz
cd mediamtx
tar xzf mediamtx_v1.15.1_linux_armv6.tar.gz
chmod +x mediamtx

ラズパイZeroWにはH264のハードウェアエンコーダが内蔵されてるのでせっかくなので使ってみようということでH264でWebRTCでストリーミングのテストをしてみる。同じフォルダのmediamtx.ymlを開いて一番下の方のpaths:っていうサンプルがあるところをまるっと下記のように置き換える。

paths:
  cam0:
    source: rpiCamera
    sourceProtocol: automatic
    rpiCameraWidth: 1296
    rpiCameraHeight: 972
    rpiCameraFPS: 30
    rpiCameraBitrate: 2000000
    rpiCameraCodec: hardwareH264

保存したらあとは./mediamtxでMediaMTXを起動するだけ。

ブラウザからhttp://raspberrypi.local:8889/cam0/にアクセスしてみるとカメラの映像が見れるようになってるはず。MediaMTX簡単で良いな…

早速遅延を図ってみた。前に使ったように画面にストップウォッチを表示して、その隣にストリーミングの映像を表示させてスクショを撮るという方法。

遅延は440msぐらい？ラズパイZero WはWiFiでルータに接続してる状態で測定。ハードウェアエンコーダとはいえH264に変換してるからかなぁ？
カメラの方が赤みがかっているのはレンズ改造のところに隙間ができていたからかな。隙間埋め無いと…

UVC対応のWebカメラでuStreamerを同じラズパイZero Wで試してみた。

とりあえず前と同じ感じで最新版をビルドした。

ustreamer -m MJPEG -f 30 -s 0.0.0.0 -p 8080 -r 1280x720

解像度はLogicool C270の解像度に合わせて近いところに合わせてみた。

そんでもって遅延を測定すると140msぐらい。ラズパイ上だと結構低遅延じゃん…
しかしこの解像度でもMJPEGだと帯域は8.5Mbpsぐらいあったので、H264の2Mbpsだと電波状況が悪いときは有利かも。

H264ハードウェアエンコード対応のWebカメラも試してみたいな。UVCのH264も実装が色々あるみたいでLinuxで使う場合はUVC1.5対応じゃないとちょっと大変そう。DJI Osmo Action 4とかもUSBカメラモードでH264に対応してるっぽいけど、UVC1.0なのでV4L2からそのまま取り出せなさそう。

Windows 11へのアップグレードが31%で止まってしまった。

 そろそろWindows 10のサポートが終了するということで友人がWindows 11にアップグレードしようとしたところどうしてもアップグレードできないということで調べてみた。Windows Updateとかでも止まるらしいので最終手段のisoからインストールも試したみたいなんだけどどうしても毎回31%で止まってしまうらしい。
Windows 8のライセンスを使ってアップグレードでWindows 10をクリーンインストールしているんだけども、2023年9月27日からWindows 8のライセンスも使えなくなってしまったので再インストールしたらWindows 11のライセンスを購入しないといけない可能性もあるし…(ハードウェア変更無いので行けると思うけど。)
そもそも再インストール自体が面倒。

巷で噂のConexant SmartAudio HDデバイスは存在していないようだけれども…

ということでひとまずログファイルを確認してみることに。

C:\Windows\Panther

の中に「setupact.log」と「setuperr.log」というファイルが生成されていて、これがアップグレード時に残るログファイルらしい。

ログファイルは結構大きいけど、おそらく一番下の方だけを確認すれば良さそうな気がする。「setupact.log」の方を確認すると一番下の方でMIGのInfoがあったあとにMOUPGのErrorが出てログが途絶えていた。

2025-10-05 10:10:20, Info                  MIG        AddDriverFiles: Processing device: 4d36e96c-e325-11ce-bfc1-08002be10318
2025-10-05 10:10:20, Info                  MIG        AddDriverFiles: Processing driver: Sennheiser Communication Audio, Sennheiser, Sennheiser
2025-10-05 10:10:20, Info                  MIG        AddInfAndCatalog: Adding catalog file: C:\WINDOWS\system32\catroot\{f750e6c3-38ee-11d1-85e5-00c04fc295ee}\oem40.cat
2025-10-05 10:13:35, Info                  MOUPG  CInstallUI::ShowMessageBox: Showing MessageBox
2025-10-05 10:13:37, Info                  MOUPG  CInstallUI::ConfirmCanceled: User cancel confirmed
2025-10-05 10:13:37, Info                  MOUPG  CInstallUI::OnProgressChanged: Cancel is requested. Returning ERROR_REQUEST_ABORTED
2025-10-05 10:13:37, Error                 MOUPG  CInstallUI::OnProgressChanged(579): Result = 0x800704D3
2025-10-05 10:13:37, Error                 MOUPG  CSetupUIManager::OnProgressChanged(452): Result = 0x800704D3
2025-10-05 10:13:37, Error                 MOUPG  CSetupHost::OnProgressChanged(2531): Result = 0x800704D3
2025-10-05 10:13:37, Error                 MOUPG  CSetupManager::DlpManagerCallback(2341): Result = 0x800704D3
2025-10-05 10:13:37, Info                  MOUPG  Cancel of current task requested...
2025-10-05 10:13:37, Info                  MOUPG  Attempting to cancel current task...
2025-10-05 10:13:37, Info                  MOUPG  MoSetupPlatform: Calling SetupPlatform::INewSystem::RequestCancelOperations...
2025-10-05 10:13:37, Info                  MOUPG  Task cancel request returned: [0x0]
2025-10-05 10:13:37, Error                 MOUPG  SendCallbackMessage: [0x7] -> user callback returned 0x800704D3
2025-10-05 10:13:37, Error                 MOUPG  CDlpTask::Cancel(993): Result = 0xC1800108
2025-10-05 10:13:37, Info                  MOUPG  SendCallbackMessage: [0x7] -> Cancel request returned 0xC1800108

こんな感じのエラー。

この感じだと実はゼンハイザーのUSBヘッドホンが引っかかってる？

何度もアップデートが失敗しているのでUSBデバイスは抜いているんだけども、抜いていてもインストールしているドライバを移行する際にエラーで止まってしまってる模様。

ということでもう一度ゼンハイザーのUSBヘッドホンを差し込んでデバイスマネージャーからドライバを丸ごと削除してみる。

デバイスマネージャーのゼンハイザーのデバイスを右クリックしてデバイスのアンインストールを選択。

そんでもって出てきたダイアログで「このデバイスのドライバーソフトウェアを削除します。」にチェックを入れてアンインストール。とりあえずSennheiserのデバイス２つともこんな感じで削除。
削除したあとにUSBデバイスのスキャンが入ってしまうとまたインストールされてしまうので削除が終わったらUSBデバイスを抜く。

そんでもってWindows 11アップデートを掛けたら…

魔の31%を超えることができた。やっぱりWindowsのアップグレードはオーディオデバイスがネックになっているのかもしれないね。

EPOSのサイトにはドライバアンインストールツールでのアンインストール方法も公開されてるのでこれも参考にするとドライバをちゃんとアンインストールできるかもしれない。こっちのほうがデバイスマネージャーに表示されない部分も表示されるかもしれないので便利かも？

とりあえずWindows 11のアップグレードが止まってしまったらログファイルをみればなんとかなるかもしれないことがわかった。SetupDiagという、ログを見やすくする便利なツールもあるらしい。

ちなみに今回引っかかったゼンハイザーのGSP 350はアナログケーブルも市販(4極から3極も変換できるし)されてるようなので、こうやってドライバアップデートに引っかかるようだったら普通にアナログ化してオンボのRealtekとかで動かしても良さそう。7.1chのWindows 11対応のドングルに変更しても良いし。