Shinobiで録画した空を見返すのがつらくなったので、流星を自動検出する OSS「Meteo」を作った

天体観測で流星を記録したいと思って、もともとは Shinobi というストリーミングカメラの録画サーバを使って空を録画していました。
ただ、録画できることと、そこから流星や火球を見つけられることは別問題でした。

実際には、あとで映像を見返して探すのにかなり時間がかかります。
そのため、よほどのことがない限りチェックしなくなってしまい、「自動で検出できないか」と以前から考えていました。

既存のツールも探してみたのですが、自分の環境ややりたい運用にぴったり合うものは見つからず、ちょうど昨今のヴァイブコーディング流行りの流れもあったので、
「では自分でどこまで作れるか試してみよう」と思って作り始めたのが Meteo です。

どんなものを作ったのか

Meteo は、流星観測向けのリアルタイム検出システムです。

• MP4動画からの流星検出
• RTSPストリームからのリアルタイム検出
• 複数カメラをまとめて見るWebダッシュボード
• 検出クリップやコンポジット画像の保存
• 全カメラに対する設定の一括反映

ざっくり言うと、

固定カメラで空を監視して、流星っぽいイベントだけを自動で拾い、あとで見返しやすくする仕組み

です。

画面イメージ

トップ画面

カメラ画面

設定画面

何がうれしいのか

単に検出スクリプトがあるだけではなく、運用まで含めて回せる ところを意識して作っています。

1. 単体スクリプトで終わらず、運用UIがある

Meteo には複数カメラの状態をまとめて見られるダッシュボードがあります。

• 各カメラのライブ映像
• 検出件数
• ストリーム状態
• スナップショット取得
• 再起動要求
• 全カメラ設定ページ

実験用のワンショットスクリプトではなく、常時動かして様子を見る ための構成にしています。

2. 固定カメラ運用で困る誤検出に対処している

屋外カメラだと、流星以外にもいろいろ映ります。

• 木の枝や建物の輪郭
• 電線
• 地上光
• 車のヘッドライト反射
• 部分照明のちらつき

そのため Meteo では、次のような仕組みを入れています。

• 昼間画像からの除外マスク生成
• 夜間画像からのノイズ帯マスク生成
• 軌跡の重なり率による除外
• 追跡点数や静止率によるフィルタ
• 感度プリセットによる調整

単純なフレーム差分だけではなく、固定カメラで実際に困るノイズ に寄せて作っています。

3. 調整がしやすい

ダッシュボードの /settings から、複数カメラに対して設定を一括適用できます。

• しきい値系は 即時反映
• 感度やスケールなどは 自動再起動で反映
• 一部設定は保存されて、再起動後も維持

見逃しが多い、誤検出が増えた、というときに、再ビルドなしで詰められる のはかなり便利でした。

4. 観測向けの発想を入れている

Meteo は一般的な監視カメラ向けというより、流星観測に寄せています。

• 感度プリセットに fireball がある
• 天文薄暮時間帯で検出時間を制限できる
• ピクセル閾値を観測者向けに読み替えられる

単に「明るいものを検出する」ではなく、流星観測で使うこと を前提にしています。

構成は意外とシンプル

全体はこんな構成です。

• 各カメラごとに meteor_detector_rtsp_web.py が動く
• 各検出器が RTSP を読んで、検出結果を /output に保存する
• dashboard.py が各カメラの状態や保存結果をまとめて表示する

つまり、

カメラごとの独立した検出器 + 全体を束ねるダッシュボード

です。

この分離のおかげで、カメラ単位の切り分けや追加がしやすくなりました。

まず試すなら

MP4で試す

python meteor_detector.py input.mp4

Web版と同じ検出ロジックで再検証するなら:

python meteor_detector.py input.mp4 --realtime

RTSPを単体で試す

python meteor_detector_rtsp_web.py rtsp://192.168.1.100:554/stream --web-port 8080

http://localhost:8080/ を開けば、映像と検出状況を確認できます。

複数台をDockerで回す

streamers に RTSP URL を並べて:

rtsp://user:pass@192.168.1.2/live
rtsp://user:pass@192.168.1.3/live
rtsp://user:pass@192.168.1.4/live

Compose を生成して起動します。

python3 generate_compose.py
./meteor-docker.sh start

地味に効いたのはマスク運用

固定カメラ運用では、マスクの有無でかなり変わります。

streamers に昼間画像を添えると、除外マスクを生成できます。

rtsp://user:pass@192.168.1.2/live | camera1.jpg
rtsp://user:pass@192.168.1.3/live  | camera2.jpg

これで建物や木、地上光などをあらかじめ除外しやすくなります。
さらに夜間画像ベースのノイズ帯マスクもあるので、電線や部分照明みたいな厄介な誤検出源 にも対応できます。

チューニングの考え方

見逃しを減らしたいときは、まずこのあたりを触るのが基本です。

• --sensitivity high
• --scale 1.0
• --exclude-bottom を小さくする

誤検出が多いときは、

• ノイズ帯マスクを導入する
• nuisance_overlap_threshold を調整する
• マスク範囲を見直す

という流れになります。

「とりあえず閾値を雑にいじる」ではなく、ドキュメントを見ながら順番に詰められるようにしています。

作っていて苦労した点

実装そのものより、ちゃんと使える形に持っていくところ で苦労しました。

1. 検出動画の形式調整が意外と難しかった

検出した流星クリップを見やすくしたかったのですが、動画形式まわりは思った以上に厄介でした。

macOS では普通に表示できる設定でも、Ubuntu ではブラウザ上で扱いにくく、結局ダウンロードして VLC などで再生しないと確認しづらいことがありました。
そのため、mov / mp4 のコンテナやメタデータをかなり詰める必要があり、この調整にはかなり時間を使いました。

2. ストリーム中継構成はむしろ不安定だった

最初は、各カメラサーバのストリームを一度 dashboard サーバで中継してからブラウザに見せる構成にしていました。
見た目はきれいなのですが、実際にはこれがかなり不安定でした。

ダッシュボードを表示しているブラウザをバックグラウンドにしたり、縮小したり、別デスクトップに移したりすると、表示が明らかに不安定になりました。
再接続や時差表示のような工夫も試したのですが、どうにもうまくいきませんでした。

最終的には、中継をやめて ブラウザがカメラサーバのストリームを直接表示する という一番単純な構成に変えたところ、表示がかなり安定しました。
凝った構成より単純な構成のほうが強い、という学びでした。

3. UI表示名と内部識別子を分ける設計で手間取った

カメラに人間向けの表示名を付けられるようにしたのですが、これを素直に扱うとディレクトリ名まで日本語になってしまい、保存先や内部識別まわりの修正が必要になりました。

UI上で見やすい名前と、内部で安定して使える識別子は別物なので、
表示用の名前 と 内部ID をきちんと分ける必要があり、この整理に意外と苦労しました。

4. AI コーディング支援ツールのコスト感に差があった

これは実装より開発体験の話ですが、AI コーディング支援ツールの使い勝手にもかなり差がありました。

個人的には、Claude Code はクレジット消費がかなり重く感じました。
一方で Codex は、今回のように試行錯誤が多い開発でも比較的リーズナブルに回せた印象があります。

この手の開発は「1回で正解を書く」より「試して直す」を何度も回すので、コスト感はかなり重要だと感じました。

5. Docker と Git の実践経験をかなり積めた

これは苦労というより副産物ですが、Meteo を作る過程で Docker と Git の実践的な経験値をかなり積めました。

• 複数カメラを Docker Compose でまとめて扱う
• 設定変更と再起動の責務を整理する
• イメージ再ビルドが必要な変更と不要な変更を分ける
• 機能追加や試行錯誤を Git で刻みながら進める

ソフトウェアを「動くコード」から「運用できる仕組み」に持っていく訓練になった気がします。

6. 検出漏れの原因が CPU 速度だったとわかるまで長かった

導入したサーバによっては、明らかに写っている流星なのに検出に至らないケースがありました。
最初はしきい値やマスク、検出ロジックの問題かと思ってかなり調べたのですが、最終的には CPU速度の違いによるフレーム取りこぼし が原因でした。

リアルタイム処理なので、処理が追いつかないと流星のような短時間イベントはそのまま取り逃がします。
この原因に辿り着くまでかなり時間がかかり、アルゴリズムだけでなく 処理性能の見積もり も重要だと痛感しました。

現在の運用状況

現状、自宅では 東・西・南の3方向 にカメラを設置して運用しています。
北面は隣家が入ってしまうため設置していませんが、3台構成でもかなり満足できるデータが取れています。

また、月光天文台 でも導入してもらっており、現在は 2台のカメラ で運用を開始しています。
今後はさらに台数を増やしていく予定です。

個人環境だけでなく別拠点でも動かし始められたので、単なる試作ではなく、ある程度実運用に耐えるところまで来た実感があります。

こんな人に向いている

• 自宅や観測拠点に固定カメラを置いている人
• 流星監視を半自動化したい人
• 複数カメラをまとめて運用したい人
• MP4再解析とRTSP本番運用を同じ系統で回したい人
• 誤検出と見逃しのバランスを現場で詰めたい人

逆に、学習済みの大規模モデルで何でも認識したい用途というより、流星観測に絞った軽量で実務的な仕組み を求めるケースに向いています。

まとめ

Meteo は、RTSPカメラを使った流星観測を

• 検出
• 保存
• 可視化
• 複数台運用
• チューニング

まで一通り回せるようにした OSS です。

特に良いのは、単なる検出ロジックだけでなく、

• ダッシュボードがある
• 一括設定ができる
• マスク運用が現実的
• 誤検出対策が細かい
• Docker で複数台展開しやすい

という、現場で使い続けるための設計 まで含まれている点です。

流星観測をもう少し自動化したい人、複数カメラの運用を整理したい人にはかなり相性がいいと思います。

ドキュメント：https://masakai.github.io/meteo/
リポジトリ：https://github.com/Masakai/meteo