多分ファイルシステムが強固なwindowsなら、ファイル移動が失敗するのでしょうけど、linuxは簡単に移動できてしまう気がするのですが?
Windowsでも処理の実装方法によっては常にopenとcloseを繰り返している場合は処理中でも他からファイルを消したりすることはできるので、何とも言い難い部分だったり、そもそもそんな事するなと言うのが当たり前だったり。
まぁでもmotionだと内部からイベントの各タイミングで丁寧にフォークしてシェルコマンドが呼び出されてたりするので、かなり運用任せでいろいろできてしまうので表題のような処理になってしまいましたw
結論から言えば、運が良ければ動画ファイルとしては何とか通用するものとなりますが、ファイルフォーマット形式でいえば確実に破損状態となり、再生することもできなくなります。
motionで、ビルトインコーデックであれば外部イベント処理が呼び出される前に処理が完了している感じだったのですが、外部パイプでエンコーダ実行されている場合、エンコーダ自体もフォークされているっぽいので処理が終わってないことも。
試しに使ったlibx265とかだと、処理が重いためか確実に処理途中となってエラー処理になってしまっていました。ハードウェアが利用できると処理が軽くなるために今までは気になったことはないのですが、先ほど書いた記事にある通り、minimum_motion_framesを20とか頭の悪い設定していると、エンコード処理が間に合わずエラー処理へ。
で、そこからはエラー処理の話になるのですが、後からチェックできるようにエラーファイルはゴミも含めてフォルダに退避させているのですが…まだ出力中のファイルを移動することになって結局動画が死んでしまうというジレンマに。
そして結局取るべき措置としては、エンコードしている場合は処理を待ちましょうということ。
linuxではよくある話らしく、psとgrepを使ってプロセスを監視するのが当たり前の様で。
で、実装して処理を待つようにしました。ビルトインの場合はチェックができない…なのでまぁ外部パイプでエンコードしている場合のみですが回避できるように。
しかし、最初はそんなに大したことにはならないはずだったのに、結構色々詰め込んでしまった気がする。
0 件のコメント:
コメントを投稿