C#とWPFとOpenCVSharpでTrimViewer開発日記 0.9.2a 「表示周りの調整」

c#

また、デバッグほとんどなしに更新してる…
ここ一か月仕事でバタバタしていて全然更新ができていないのよ
(´・ω・`)
新潟のド田舎に引きこもって、近所の騒音が無いところで悠々自適な怠惰をむさぼる隠居生活が、やたら東京人やら人流が多いところに出かけなければならずストレス極まりない!(笑)。
そんな中だらだら更新してるとどこをいじったのかすら、メモやログを見ても何のためだったのかさっぱりできっとバグだらけになっているに違いないと戦々恐々している毎日です
(^◇^;

プロファイル「一時ファイルを削除せずに残す」オプション設定の利用を推奨

TrimViewerのアップデート報告

ガラクタツール置き場はこちら→

nln:★Idea Library★(永遠のβ)
■ 見た目には微調整内部はかなりの変更

・OpenCvSharp-4.5.3(4.5.2-20210405以降)
EDCBなど時間指定や任意のタイミングでパケット保存がされているTS、ファイルの先頭パケットがGOP単位に揃っていない状態のTSファイルで内部のずっと奥のFFMpegがエラーを起こしているようです。
「ver0.9.1c」で何人かに試してもらいましたが同じ症状という事で、沢山更新は入っているのですが、OpenCvSharp-4.5.1-20210210のままです。
TMSR6やMurdocCutterで切り抜いたTSは読めるようです。

・「ver0.9.2a」は1920×1080のモニタでフル画面操作をターゲットに作っていたので、フル画面じゃない場合に起きた不都合の緩和を中心にバグ取りをしてました。

・ニアパネル(表示フレームの前後を1フレーム単位で表示)追加でサムネイル用キャッシュがすぐに埋まるので、ニアパネルを表示してない場合は追加前と同じように負荷軽減するように処理を戻しました。
(キャッシュ周りは利用目的が変わってきているので、調整が必要かなとは思っています。サムネイルサイズ変更も考えているので、分離して別管理にしないといけないかな(^◇^;)

・(既知のバグ)ニアパネルを表示した状態で、ウィンドウサイズをサムネイルが表示できないサイズまで小さくすると、自動的に非表示処理が走ります。元のサイズに戻しても再表示されないバグがあります。軽量化の為、表示外のデータはどんどんブロックするので、更新後に気づきました。頻繁に起こる事でもないので優先度は低いですが、近いうちに手を入れますm(__)m

・フォーマット変更のある一部のTSの読み込みエラー時(画像が取得できない状態、または時間がかかっている状態)で終了させると、設定ファイルが保存できずに、設定が消えてしまうのでバックアップファイルを作ることにしました。消えた場合は設定ファイルが残っている可能性があります。2度再起動するとそれも消えますが…

・プレビュー画面のウィンドウサイズ変更時にほぼ中央になるようにサムネイルの仕様を変更。これが結構な大掛かりの回収になってしまって
(;^_^A アセアセ・・・
OSのGUIでやるよりOpenCvSharpに任せて裏で描画して切り抜いている(分散処理させないシングルタスクでやってる間はこっちの方が数倍速い)のですが、それでも描画エリアを減らしたくて固定にしてたところを全部可変にして、自分で自分の首絞めてました。
デメリットとしては処理が遅くなる。処理が煩雑になる。エラーチェックが増える。予想外の最大最小が発生しやすくなる(・・ゞポリポリ
メリットとして、表示周りが柔軟に対応できるようになりました。いずれサムネイルのサイズ変更も可能カモ?(固定しておけば楽なんですが)


余談:
・仕事でプログラム組んでる人にはやってはいけない対応を見本市ですなぁ
‘`,、’`,、(ノ∀`)’`,、’`,、
[更新タイミング(重い)]
サムネイル最終フレーム


サムネイル先頭フレーム


メモ書きと愚痴書きをしていて次はあれをしようこれがしたいと思いつくわけです。
来月にはWindows11も出る事ですし、そろそろAnyCPU(32bit)対応も終わりかなと。
そんな今日この頃、暑さも戻ってエアコンつけて気持ちよく昼寝しますわ~
またの~(´∀`)ノシ