Mac mini向け技術週報 ｜ 2026年11月6日号

今週は、ネットワークカメラの運用に関わるFFmpegの修正提案を取り上げます。導入方針を見直すほどの更新は、今回の調査範囲では確認されませんでした。

カメラが切断されたとき、監視アプリはどう気づくか

RTSPでは、映像の受信とは別に、再生や接続維持のための制御メッセージをやり取りします。送信が途中で失敗すると、相手が残りのデータを待ち続け、次のメッセージを正しく処理できない場合があります。

FFmpegの修正提案（PR #25714）は、書き込みに失敗した制御接続を閉じ、その後の処理に未接続エラーを返すものです。接続維持の通信が失敗した場合も、読み取り側がエラーを受け取れるようにします。監視アプリは、このエラーをきっかけに、アプリ側で実装した処理で接続を開き直せます。

図1　FFmpegの開発報告をもとに作成した概念図。

判定：継続注視

開発者は、書き込みエラーを人工的に発生させた試験で、後続の送信が止まり、未接続エラーが返ることを報告しています。本号では、安定版への収録、Mac miniでの復旧時間、複数カメラの長時間稼働、映像遅延は確認できていません。採用時は、対象のmacOS向けビルドに修正が含まれるかと、同梱するバイナリのライセンス条件を確認します。

Apple Siliconの推論や人物・車両検出については、今回確認した範囲で、固定カメラのローカル運用の判断を変える実測資料は見つかりませんでした。ROD-Datasetは歩行者視点の評価資料であり、固定カメラとは撮影条件が異なります。

検証用カメラ1台で復旧時間を測る

監視アプリを起動したまま、検証用カメラの通信を一度切って戻し、通信復帰から新しい映像が表示されるまでの秒数を記録します。復旧しなければ、アプリの表示とログを控えます。受信ソフトの更新後も同じ条件で測ると、変化を比較できます。

参考資料

• FFmpeg-devel：PR #25714の開発報告とパッチ（2026年11月4日、日本時間）

• FFmpegのライセンス文書

• ROD-Datasetの原論文