SonotaCo.JP

T.Nakamori

HK5のNakamoriです。UFOCaptureIPで記録したAVIに、フレームの欠落があることが分かりましたので報告します。

8/12-13夜の683クリップについて、XMLの frames(受け取った枚数)と、AVIに実際に書き込まれたフレーム数を比較しました。

・受け取り92,085枚のうち7,101枚(7.7%)がAVIに書き込まれておらず、288クリップ(42%)に欠落がありました。
・欠落した位置には印が残らず、前後のフレームが詰めて書かれています。そのため、欠落以降は時刻がずれます。
・XMLのタイムログでは、フレームは正常な間隔で届いています。
・欠落は深夜帯と長いクリップで多く、約58枚単位でまとめて失われる場合もあります。
・同じ局でUFOCaptureHD2で記録した89クリップでは、欠落は0でした。

詳細を添付PDFにまとめました。原因や対処について、ご教示いただけると幸いです。

T.Nakamori

SonotaCo

質問が妙に詳細なので、少し驚きました。AIの文面なのですね。 Wink

細かくは実際の環境で調査しないと分からないですが、とりあえず一般論をお答えしておきます。

UFOCaptureでは非圧縮aviを処理記録するため、処理能力が不十分なPCでは不完全なaviが記録されることがあります。
これは20年前の初代のUFOCaptureからすべてのUFOCaptureに共通した問題(いわゆるコマ落ち)です。,
UFOCaptureIPはUFOCaptureHD2とタイミングや処理量が若干違いますが、適切なPCを用意すればUFOCaptureIPでもコマ落ちなく記録できます。
(Tokyo8では現在720x480/30iから4096x2160/60pまでの16台のカメラをすべてUFOCaptureIPで処理していますが、SSDが古くなって連続書き込みができなくなったケースなどを除きコマ落ちは確認できません)

最初に理解をお願いしたい点ですが、UFOCaptureのPC内の動作は簡単には次の3つの非同期な処理からなります。
1)カメラからのフレーム画像をUFOCaptureアプリに入力する。
2)フレーム単位にUFOCaptureアプリの中で動体検出処理やマスク処理を行い、記録するフレームをDirectShowのFileWriterに渡す。
(この中で検出対象と判断したフレームの情報をxmlに書き出し、フレーム番号を付け、そのすべてのフレームをFileWriterに出力します)
3)DirectShowのFileWriterがHDD/SSDに書き込む。
で、コマ落ちが発生するのは 1)と3)、つまりシステムモジュールの中で、前のフレームの処理が終わる前に後続のフレームが押し寄せて、そこのバッファが溢れた場合てデータが捨られる時です。
1)で発生したコマ落ち(主にCPU能力不足)は、スーパーインポーズされたフレーム番号は連続しているのに動画内の対象の動きが跳んでいることで発見できます。
3)で発生したコマ落ち(主にストレージの連続書き込み能力不足)は、スーパーインポーズされたフレーム番号が不連続になることで発見できます。

というのが概要で、質問にお答えすると、

T.Nakamori

SonotaCo さま

早速のご教示をありがとうございます。

不慣れな分野のため、Claudeと相談しながら、主にPythonでコードを書いて不具合の実態を調べながら進めています。ご容赦ください。

ご説明を受けて、2台のPCの記録先SSDを調べました。いずれもノートPCで、システムドライブ(C Smile

にそのまま記録していました。問題はCPUではなく、SSDへの書き込みにあると理解しています。

1. 観測中のファイル移動
SSDの残りが200GBを切ったら外付けHDDへ自動で移動する仕組みにしていました。PER群の夜はこれが観測中に2回動いており(23:57〜1:19、2:04〜3:23、計約310GB)、欠落率は移動中が11.9%、移動していない時間帯が4.1%でした。

2. SSDの書き込み能力(1080p/29.97と同じフレームを連続書き込みして実測)
・IP用(IdeaPad Gaming 3):Intel SSDPEKNW512GZL(660p系、QLC、512GB)
　高速に書けるのは最初の約3GBだけで、その後は毎秒90〜110MB程度、ときに数秒間ほぼ停止(毎秒20〜30MB)。必要な約124MB/sを下回っていました。
・HD2用(ThinkPad X1 Carbon):SUNEAST SE811(512GB)
　約47GBまでは毎秒約830MB、その後は毎秒約60MB。普段の夜は余裕があり、HD2では欠落0でした。

IP用のSSDの能力不足に、観測中の移動が重なったことが主な原因と考えています。

3. 対策
・IdeaPad:空いているM.2 2280スロットに、観測専用のTLC・1TBのSSDを増設
・X1 Carbon:Thunderbolt接続の外付けSSDを観測専用に
・観測中はファイルを移動しない運用に変更

導入後に、同じ方法で書き込み能力と欠落を確認するつもりです。また相談に乗ってください!

以上、取り急ぎご報告と御礼まで[/quote]