深夜に撮影されていて何かと思っていたのですが、どうやらただの火球の様です。
とすると、２日前のアレも火球なのかな？2022年6月29日水曜日
2022年6月27日月曜日
またなんか映り込んでました
やっぱりこれも衛星なのかな？
2022年6月8日水曜日
windows11へのアップグレードの準備ができました
えっと…なんかwindows11にアップグレードできませんって言われていたPCにwindows11へのアップデートの準備ができましたとか表示されるんですが…
正直今更だったりします。
メインで使用しているPCは「準備ができました」とか表示されて更新ボタン押したんだけど、その後全然アップグレードされないし、ほかのPCはそれぞれの使用用途が止まってほしくないのでアップグレードする気はいまのところなかったりする。
で、当初アップグレードするための条件がTPM2.0とかだけだったので、ギリギリ手持ちのハードはアップグレードできるかな？と踏んでたのだが、CPU縛りも発生してもうwindows11はいいかな？とか。ゲームもハードウェアを購入するまで気合い入れてやることもなくなった現在、windowsである必要性はほとんどなくなってきているし。
時間ができたら更新するけど、PC止めてアップデートするほど暇はない。
それよりもwindows10で気づけばバックグラウンドで処理が動き続けて困ってるんだがｗ
2022年6月5日日曜日
gcc: インライン展開の効果
発端はやはりmotion。
ループ中の関数呼び出しを行った後のif文分岐で処理をキャンセルしている形が目についたので、これってかなり不利だよなぁとか引っかかってたので処理のオーバーヘッドがどの程度影響するのか確認してみました。
最初はソースを書き換えることを考えたのですが、この辺はコンパイラがどのような実行コードのするのか決めることができます。c言語でもinlineという指定があるのである程度指示することができます。ある程度と言う意味は、現状のc/c++コンパイラはinline修飾子をヒントとして用いているのでinline修飾子だけでは確定させることができません。
前置きはこのぐらいで、本題へ。
用意したのは単純なループと関数定義
#include <stdio.h>
#include <time.h>
int proc1(int i){
i++;
return(i);
}
inline static int iproc1(int i){
i++;
return(i);
}
int main(int argc, char *argv[]) {
int i, w;
long t0, t1, t2;
double s;
t0=clock();
w=1;
for(i=0; i<100; i++){
w=proc1(w);
}
t1=clock();
w=1;
for(i=0; i<100; i++){
w=iproc1(w);
}
t2=clock();
s=(double)(t1 - t0) / CLOCKS_PER_SEC;
printf("%f sec\n", s);
s=(double)(t2 - t1) / CLOCKS_PER_SEC;
printf("%f sec\n", s);
return 0;
}
インターバルの時間計測の比較で実行してみてみると…
pi@rasp2b:~/ctest $ gcc inlinetest.c -o inlinetest pi@rasp2b:~/ctest $ ls -l 合計 12 -rwxr-xr-x 1 pi pi 8152 6月 4 14:47 inlinetest -rw-r--r-- 1 pi pi 485 6月 4 14:47 inlinetest.c pi@rasp2b:~/ctest $ ./inlinetest 0.000023 sec 0.000013 sec
確かに早い結果は得られたが、この桁ではクロック変動や誤差の範囲ｗ
ループ回数をもう少し増やしてみましょう。ゼロを4つ増やして…
pi@rasp2b:~/ctest $ gcc inlinetest.c -o inlinetest pi@rasp2b:~/ctest $ ls -l 合計 12 -rwxr-xr-x 1 pi pi 8152 6月 4 14:56 inlinetest -rw-r--r-- 1 pi pi 493 6月 4 14:56 inlinetest.c pi@rasp2b:~/ctest $ ./inlinetest 0.050699 sec 0.051429 sec pi@rasp2b:~/ctest $ ./inlinetest 0.044166 sec 0.042028 sec pi@rasp2b:~/ctest $ ./inlinetest 0.048412 sec 0.044907 sec
最初に遅くなっているときはクロッキング時のオーバーヘッドがこれだけかかっているという結果でしょう。raspberry pi 2辺りの動作クロックのオーバーヘッドが結構大きいのですが、それだけで結果がひっくり返りました。
現実問題として、秒単位の処理で高速化のためにインライン展開を利用するのは効果は非常に薄いです。関数の引数の数で差はでるとしても、100万回の呼び出しでも4ms程度の差しかでない。
結局、サンプルコードも書いてみたものの、効果がほとんどないという結果は喜ぶべきか悔しがるべきか、悩みます。
ことの発端は、ボトルネックとなっている撮影開始時の処理で、処理が１ｓ以上程度処理落ちしている様で、それを何とかしたいと思ったから。
現状ではminimum_motion_framesとpre_captureの値で内部バッファが確保され、動作検知をした時点でバッファの画像をエンコードを行い、処理が終わるまでほかの処理が行われません。（実装を変えれば…）
しかしそのバッファを0になるように設定してもどうしても１秒程度のラグが発生してしまっているために何とかならないかと。一番マズそうなのは、pipeでffmpegエンコードしている部分だとは思いますが…
extpipeさせている理由は単純で記録される動画のファイルサイズを小さくしたいというだけなのですが、現状だとtmpf上に一回保存した後、soundと結合させたりしていることを考えると、動画も再エンコードさせてもいいのかもしれないが、無駄にデジタル劣化させるのもなぁと言ったところ。
2022年6月2日木曜日
motion: タイムラプス撮影させているカメラで雷が撮影されてた(*´▽｀*)
食後にごろごろ音がしていたのでもしかしてと思ってみてみると、いいのが撮れてました。
解像度を上げているため、CPU負荷の低減と、撮影カメラの発熱を抑えるためにfpsを2にしているので動作検知動画でも数フレームしか記録されずにそのうちの１フレームに稲光が！ｗ音も録音していたのですが、雨音しか録音されていなかった。
そんな努力？の結果が、
雲の中を水平に突き進む光をとらえていました。
タイムラプスの方にも記録されているといいのだけれど…あっちは１５秒間隔の映像なので運が良ければ…
motionplusだと…
ここ１か月ほどpullリクエストもなく平和そうだったmotion-project。
ふと見てみると、motionplusなるものが…あーそういうことだったのか…とちょっと納得。
ここ一か月ほど結構どっぷりとmotionのソースを見て、うまく動作してない部分や気になる部分に手を入れ様子を見ていましたが、別プロジェクトが立ち上がってしまったのならそちらに流れる必要がありそう。
積年の間どうにかしたいと思っていた部分は現状の実装では何ともなりそうもなく、根本的な部分をテコ入れするしかないかなと言う結論に至ったのが数日前。
ただ、それ以外の部分も少しpullリクエストして反映してほしい部分もあるようなないような。
特にマイクロスイッチの実装がよくわからない動作をしていてうまく機能していないので、ライトスイッチとは別になってほしいという気持ちが強い。ライトスイッチ自体は結構それなりに動作するし、誤作動も発生することはないはず。
なので未実装部分の余計な追加コードなどは削除したうえで早急にpullリクエストしておいた方がいいのかもと焦ってたり。
motionplusでは4.2.2をベースにc++へコンバートされていて、その時にコンバートでうまくいかない部分や無駄に拡張されてしまった部分を捨て去った上で、新たにサウンドの追加などを行っているようだ。
少しだけメインループの実装を確認したいと思っているが、当面の目標は早急に手持ちの修正の終息させねばｗ
人工衛星だとは思うけど…
https://stdkmd.net/sgt/
結局何見てもそれらしい軌道の衛星がわからない。
平面の世界地図で見ると「みちびき」かもと思いつつも、高度が高すぎる。
3D表示が可能な画面に切り替えてその他の衛星も表示させると今回は「STARLINK-1563」が一番ありえそうなのかな？と。ただし高度は、539.08km
今回に限れば太陽光の反射が強いはずなので人口衛星だとは思うのですが。
登録:
投稿 (Atom)