正直まともに使いこなしていないgithub
こんな形にしたいのに、どうやったらそうなるのか全く分からない歯がゆさ。そしてコマンドラインとwebインタフェース上の言葉の違い。もう何が何やらｗ
そんな感じで適当に使ってきているわけですが、ようやく一つ上手く行くようになりました。
version31.0ベースとなりますが、
git clone --recursive https://github.com/siriuth/obs-studio.git -b 31.0.4-Custom --depth 1
でソースが展開されcmakeしてビルドすれば
公開されてましたが、まだリリースのLastestになっていない様子。
スピンエディットには変更がないようなので現行のままだと左右の余白が多すぎな状態でした。
個人的なカスタマイズ部分は変わりなくマージできたのでこの辺のテコ入れはなさそうと判断し、pullリクエストでも…とドキュメントを見たらちょっと面倒そうなのでこのままかなぁｗ
あと、メインウィンドウのドック状態のサイズ変更のフォーカス時の区切り線が残ったりするようになった感じ…前からかもしれませんが。
前々から気になっていた現象の一つで、PCの電源を入れ起動後のボリュームがなんかおかしい状態になるという問題。
最初に気づいたときは、モニターはHDMI接続でモニターの電源が入っていなかったり、接続コネクターが今までとは違うコネクターにつないだためにボリュームがおかしくなったのかと思っていました。
そのうちに気づいたのはPCの電源を入れた後、起動音が鳴るようになったこと。弄った記憶はなかったのですが、起動音が聞こえるのに気づきました。
その後、なんかスピーカーのボリュームが最大になっていることが多いなとは感じていました。
確実におかしいと気づいたときにはスピーカー出力の左右のバランスが変わる現象が起るように。実際には左だけボリュームが0になっていたり。
ログイン後のデスクトップのスピーカーボリュームの表示が最大になっているにもかかわらず、実際のボリュームはいつもと変わらない大きさ（10～20）で出力されている。しかし、これをタスクトレイ上のアイコンの上でマウスでボリュームを小さくしようとするといきなり大音量(98ぐらいかな？)に。表示は100でそこから小さくしたので98になるのは理解できる。けど困りますがｗ
で、そんな状態で使い続けていましたが、今日おもむろに起動音いらなくね？と
サウンドの設定からサウンドの詳細設定、で旧コントロールパネルでおなじみのダイアログウィンドウの設定ウィンドウから、サウンドタブへ切替て、Windowsスタートアップのサウンドを再生する(P)のチェックボックスをオフへ。
いままで、サウンドの既定のデバイスを切り替えたりいろいろしても何ともならなかったのですが、これで落ち着いてくれるといいなぁ…スタートアップのサウンドが鳴らなくなるのでちょっと寂しいですが…
最近古い動画ファイルの不要な部分をカットしようとしたところ音声がない動画ファイルになってしまうという症状に悩んでいました。
やってることは再エンコなしで
ffmpeg -to 00:15:00 -i FileName -c copy CutedFileName
といった感じで不要な末尾をカットしているだけなのですが…
動画ファイルの日付を見ると2022/10/05とか結構昔のファイルです。
ffprobeで元ファイルとカット後のファイルを比べてみると映像と音声のストリームは存在するものの、音声ストリームのDURATIONが00:00:00.000000000となってしまっている。
確かにファイルサイズも音声分サイズが小さくなっている感じにｗ
色々と検索して調べてみるものの、似たような現象はあるものの、そちらでは音声のみ切り出せるようなのですが、こちらでは切り出しは行えず、再エンコーディングすれば音声を取り出せるのみ。
少し現象が違うものの、原因はffmpegの過去のバグに起因するっぽい感じ。
aacで再エンコするとかなり高音域の音が歪まくるのでflacを使用するという手もあるのですが、ファイルサイズがそれなりに大きくなってしまうので、割り切って作業を進めることもできず途方に暮れていました。最悪、ffmpegのソースに手を入れて、バグ回避させてビルドすることも考えたのですが、手元にgcc環境が無いので少し時間をおいてみることに。
そして今日、過去のffmpegのバイナリーを使って試してみようかと。
現状メインで使っているのはffmpeg 7.1.1ですが、公式のリンクから存在したのはオートビルドのバイナリが格納されているBtbNさんのところで、現時点で最古のものはAuto-Build 2023-08-31 12:54のもの。
試しにmasterではなく、バージョン4.4.4-6を試してみました。
結果としては、あっさりと音声付きの動画を作ることができました。
同様に、5.1.3-16, 6.0-34でも問題なく動画が作成されました。
これらのバージョンで作成された後のファイルは7.1.1でも正しく処理が通るようになりました。
今度は逆にどこまでのバージョンがこのバグ回避が行えるか気になったので調べてみると、Auto-Build 2025-07-17 14:10の6.1.2-192でも問題なし。しかし7.1.1-56では音声が無くなる状況に。
version 7ベースで最古のものが Auto-Build 2024-04-30 12:51に含まれていた7.0-21を試したところ、こちらは音声が含まれ問題がなさそうでした。
結論として7.1以上では、どうもバグのあるファイルでは-acodec copyが機能しなくなるのでしょう。
公式でwindows版のビルドを公開しているhttps://www.gyan.dev/ffmpeg/builds/ではprevious release version: 7.0.2が残っているので試したところ問題はない様子。
問題がなければ、現状ffmpegは7.0.2を使うのが幸せなのかな？
obs-studioをビルドして確認するために実行する。
すると、メインで使っている画面で設定画面を開くと、設定のウィンドウが微妙に画面からはみ出しているという…
タスクバーを隠れるようにすればいいんだろうけど。というわけで、設定値を確認してみると、\obs-studio\frontend\forms\OBSBasicSettings.ui
<?xml version="1.0" encoding="UTF-8"?>
<ui version="4.0">
<class>OBSBasicSettings</class>
<widget class="QDialog" name="OBSBasicSettings">
<property name="geometry">
<rect>
<x>0</x>
<y>0</y>
<width>981</width>
<height>730</height>
</rect>
</property>
：
現在使用中のモニターを見ると1920x1080で大丈夫そうですが、拡大/縮小で150%(推奨)というのが問題になってそうです…
まぁ何と言うか、とりあえずやっつけでデフォルト値を弄っておけばいいかな？
ザックリ考えると、古典的な考えで800x600とかでいいかとか。
一般的にはメインウィンドウが存在するデスクトップウィンドウのサイズを取得して、作業領域に収まるように表示させるのですが、あまり凝りすぎると付加処理が悪さをすることも。まぁその辺は気が向いたらコードを弄るのがよさげかな？
グレー枠の原因はあきらめて、31.1からやたら大きくなってしまったSpinBoxの原因を探ってみました。
色々と見て行くとどうやらYami.obtというstylesheetフォーマットのファイル中にたどりつきました。
ただ実際にどのように反映されているのか良くわかっていなく、このファイルを反映するにはリビルドすることが必須となってしまっていてトライアンドエラー方式で確認するのは結構痛いかった。そのうちpowershellでfindstrを使ってソース検索したときに
obs-studio\build_x64\rundir\Release\data\obs-studio\themes\Yami.obt
obs-studio\frontend\data\themes\Yami.obt
と表示され、単純にコピーされているだけという事実に…。記憶でどこかにobs-studioを使い始めたときにスタイルシートがどこかに入っていた記憶があったのだが、ユーザーフォルダ内のAppData\Roamingの中を探してなかったのであきらめていたが、よく考えればインストールフォルダにあるのが当然なのですが。
コンパイルの必要が無くなり、ようやく細かな点を確認できるようになりました。
31.1からスペーシングやパディングを変更したために悪影響が出ているのと、全体的に修正作業がやっつけっぽいので細かいところでいろいろとおかしくなっています。
ザックリと31.0.4のYami.obtの比較しても全体的に修正が加わっているためにパッと見ではよくわかりませんが、細かく見て行くとQSpinBoxはベースとなるQPlainTextEditとQSpinBoxに付随するup-button,down-buttonが組み合わさって構成されていました。（Qtのドキュメントを見た方が早いとは思う…が、）
最初にQSpinBoxのpaddingの記述が違っているのでそこから様子を見ることに。
結論から言えば、QSpinBoxは内部のQPlainTextEditのpadding分と自身のpadding分が反映されるため、巨大化しているようです。極端な話、QSpinBoxのpaddingを 0px 0pxで指定すれば全体的にスッキリします。ただ、スピンのボタンが小さくなりすぎるので、UIデザイン的には反則気味にｗ
31.1の変更状態を考慮すると、marginは触らずにpaddingだけで行っている感じがするのと、QSpinBoxはやはり大きめにしたいのではないかと考え、
QSpinBox,
QDoubleSpinBox {
background-color: var(--input_bg);
border: 1px solid var(--input_bg);
border-radius: var(--border_radius);
padding: var(--input_padding) var(--input_text_padding);
padding: var(--input_padding) 0px;
height: var(--input_height);
max-height: var(--input_height);
}
としてみました。左右の無駄なパディングを消した形です。31.0.4と比べ、height指定が増えていますが、これ、正直意味をなしていないようで…。
あとは気になるポイントとしてはスピンボタンの上下にある間の隙間。それとこれでも右側の隙間が無駄に存在している点も気にはなります。min-widthとか設定できたりするのかな？
試行錯誤中の状態がこちら
このブログだとあまり明記していなかったので具体的なビルド手順を載せておこうかと。
必要な環境は、git, cmake, visual studio 2022ぐらいかな？現時点では全て誰でもダウンロード可能です。
ビルドに必要な空き容量NTFSで 6.26GB となっていました。
PowerShell 7.5.2
PS C:\Users\xxxxx> mkdir S:\obs\31.1.1\
Directory: S:\obs
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 25/07/15 09:12 31.1.1
PS C:\Users\xxxxx> s:
PS S:\> cd \obs\31.1.1
PS S:\obs\31.1.1> git clone --recursive https://github.com/obsproject/obs-studio.git -b 31.1.1 --depth 1
Cloning into 'obs-studio'...
remote: Enumerating objects: 5326, done.
remote: Counting objects: 100% (5326/5326), done.
remote: Compressing objects: 100% (4434/4434), done.
remote: Total 5326 (delta 879), reused 3056 (delta 657), pack-reused 0 (from 0)
Receiving objects: 100% (5326/5326), 14.86 MiB | 14.24 MiB/s, done.
Resolving deltas: 100% (879/879), done.
warning: refs/tags/31.1.1 4b56b9b214967c6f0143e36f722c64c6d755d55f is not a commit!
Note: switching to 'a32b3f9f6d5e1cf6fa0f8105a2ed46ec0b4d991c'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c <new-branch-name>
Or undo this operation with:
git switch -
Turn off this advice by setting config variable advice.detachedHead to false
Updating files: 100% (5043/5043), done.
Submodule 'plugins/win-dshow/libdshowcapture' (https://github.com/obsproject/libdshowcapture.git) registered for path 'deps/libdshowcapture/src'
Submodule 'plugins/obs-browser' (https://github.com/obsproject/obs-browser.git) registered for path 'plugins/obs-browser'
Submodule 'plugins/obs-websocket' (https://github.com/obsproject/obs-websocket.git) registered for path 'plugins/obs-websocket'
Cloning into 'S:/obs/31.1.1/obs-studio/deps/libdshowcapture/src'...
remote: Enumerating objects: 1037, done.
remote: Counting objects: 100% (604/604), done.
remote: Compressing objects: 100% (96/96), done.
remote: Total 1037 (delta 537), reused 511 (delta 508), pack-reused 433 (from 2)
Receiving objects: 100% (1037/1037), 332.23 KiB | 10.07 MiB/s, done.
Resolving deltas: 100% (722/722), done.
Cloning into 'S:/obs/31.1.1/obs-studio/plugins/obs-browser'...
remote: Enumerating objects: 3799, done.
remote: Counting objects: 100% (1676/1676), done.
remote: Compressing objects: 100% (444/444), done.
remote: Total 3799 (delta 1376), reused 1258 (delta 1232), pack-reused 2123 (from 2)
Receiving objects: 100% (3799/3799), 1.09 MiB | 10.11 MiB/s, done.
Resolving deltas: 100% (2594/2594), done.
Cloning into 'S:/obs/31.1.1/obs-studio/plugins/obs-websocket'...
remote: Enumerating objects: 6189, done.
remote: Counting objects: 100% (823/823), done.
remote: Compressing objects: 100% (203/203), done.
remote: Total 6189 (delta 656), reused 631 (delta 618), pack-reused 5366 (from 4)
Receiving objects: 100% (6189/6189), 1.75 MiB | 10.62 MiB/s, done.
Resolving deltas: 100% (4258/4258), done.
Submodule path 'deps/libdshowcapture/src': checked out '8878638324393815512f802640b0d5ce940161f1'
Submodule 'external/capture-device-support' (https://github.com/elgatosf/capture-device-support) registered for path 'deps/libdshowcapture/src/external/capture-device-support'
Cloning into 'S:/obs/31.1.1/obs-studio/deps/libdshowcapture/src/external/capture-device-support'...
remote: Enumerating objects: 60, done.
remote: Counting objects: 100% (60/60), done.
remote: Compressing objects: 100% (41/41), done.
remote: Total 60 (delta 30), reused 41 (delta 19), pack-reused 0 (from 0)
Receiving objects: 100% (60/60), 34.39 KiB | 5.73 MiB/s, done.
Resolving deltas: 100% (30/30), done.
Submodule path 'deps/libdshowcapture/src/external/capture-device-support': checked out 'fe9630974d47f51bf54826e72fb8b654e620aa93'
Submodule path 'plugins/obs-browser': checked out 'bdabf8300ecefeb566b81f4a7ff75f8a8e21f62b'
Submodule path 'plugins/obs-websocket': checked out '40d26dbf4d29137bf88cd393a3031adb04d68bba'
PS S:\obs\31.1.1> cmake-gui
PS S:\obs\31.1.1>
cmake-guiが起動した後は、上の方から設定します。
Configureを押し、ビルドするフォルダの作成の確認をした後、終了するまでしばらく待ちます。完了したらGenerateを押し、またしばらく待ちます。終わったらOpen Projectを押すとVisual Studio2022が起動します。
一回ビルドを通しておけば、ソースの修正などを行う時に型チェックなどがまともになるので時間があるのであれば一度ビルドしておくことをお勧めします。
失敗するパターンとしてはファイルシステムがWindowsではNTFSでないとcmakeでエラーが出て進まなくなりました。
昨日ビルドしたそばからgithubでは31.1.1がタグ付けされていました。
機械的に作業しているのか現状コンパイルは通っていますが、VisualStudio内のリンクが結構ぐちゃってる感じがします。まだまだアップデートが続きそうな気配。
31.1から変更となったUI上のパディングの変更によりスピンエディットボックス（Qtだと何て呼ぶんだろうか？ｗ）が巨大化してるので何とかしたいと思っているのですが、どうしたものか…
31.0と31.1はソースの配置位置が変わっていたりファイル名が変わっていたりと、内部的には大きく手が入っている印象がありました。
ドキュメントを見ると結構ダイアログの修正や内部的なバグの修正など行われているみたいです。
UIの見た目で嬉しいのは、コントロールの大きさがデザイン系から独立して変更できる点でしょうか？全体的にコンパクト収まるので、クラッシックを使用していましたが、今後はもう少し選べる選択肢が増える感じ。
時分秒のエディットボックスが大きくなってる気がします…世間的には出力タイマーのウィンドウは大きくしたいのだろうか？
そして相変わらずプレビューのグレー枠の原因が分からない…orz
細かいことはわかりませんが、いつも使っている出力タイマーウィンドウ
デザイナーでサイズ調節しておいてもいいのかな？とも思ったものの、どうせ自動で最小サイズがセットされるのであれば、デフォルトサイズを小さめにしておけばいいんじゃね？ということで早速試してみました。
obs-studio\UI\frontend-plugins\frontend-tools\forms\output-timer.ui
:
:
<widget class="QDialog" name="OutputTimer">
<property name="geometry">
<rect>
<x>0</x>
<y>0</y>
<width>0</width>
<height>0</height>
</rect>
</property>
:
:
最初は少し小さめにして試しましたが、どうせなら0にしてしまえということでこんな感じに
今回はこんなところでしょうか。小さくなりすぎな気もしますが、結局毎回ウィンドウのサイズを縮めて使っているので、その手間が一つなくなるだけでもいいことなのかな？
VisualStudio2022でファイル比較(Diff)が使えるようになっていたのでソースファイルの手直しがかなり楽になってはいました。
ですが、操作の起点がソリューションエクスプローラー限定っぽく、どうやってもメニューに「比較やコンペア」と言った文字が出てきてくれません。
唯一、ツールバーに「ファイルを比較」とかあったので『もしや！？』と期待して表示させてみましたが、どうもファイル比較状態のエディットウィンドウになっていないと使えない模様。残念。
途方に暮れこれまでも何度もネット検索で見てきましたが、もう少し地道に調べることに。
AIが嘘説明が多すぎて正直邪魔でしかありません。
調べてみると、2022 17.7からファイル比較ができるようになっているようで、
Microsoft、「Visual Studio 2022 17.7」に2つのファイルの中身を比較する機能を追加 https://codezine.jp/article/detail/18213
現状の17.14.7でも利用できそうなのですが、上記記事のような「Ctrlを押しながら２つのファイルを選択した状態で…」という形にしもどこのポップアップメニューにも比較できそうなメニュー項目は追加されず、
2つのファイルの内容を比較して差分を表示する https://www.javadrive.jp/vscode/editor/index3.html
で書かれているコマンドパレットなるものは表示される気配もなく…メニューもない。コマンドウィンドウというものがあったが、「比較」や「Compare」と入力してみても無駄でした。
そして行き着いた先が
「Visual Studio」にようやく差分表示（Diff）が実装へ？ ～叩き台となる拡張機能が公開 https://forest.watch.impress.co.jp/docs/news/1445493.html
おそらく現状の2022 17.14.7ではこのプラグインが取り込まれた形となっているようですが、ファイル比較の起点がただのファイル編集状態では機能しないのでこの記事にあるプラグインを使うことにしました。
ただ、プラグインってどうやってインストールするんだか知りませんｗ
そもそもマーケットプレイスとかあるし、なんだかオープンな様でオープンでない言葉を見るとやる気が失せるわけですが。
File Differ https://marketplace.visualstudio.com/items?itemName=MadsKristensen.FileDiffer
こちらより直接ダウンロードはできました。
なんかよくわからん拡張子だけどそのまま実行すると、インストーラっぽい感じでインストールが終わりました。
拡張機能(X) / 拡張機能の管理(M)
を選択すると
.png)
こんな画面が出てきてFile Diffと入力すればそのままいい感じで取り込んでくれそうな感じになっていました。
すでに正しくインストールが終わっているようで
.png)
プラグイン状態のおかげで、一つのファイルが開かれた状態からポップアップメニューにCompareの文字が表示され、無事ファイル比較ができるようになりました。
先日の出力タイマーの時間が保持されないと言った原因はリネームしたプラグインが原因でした。
.png)
やはりこちらはプレビューの枠が無い状態。ウィンドウの大きさを変えても出てこないのでどこかの設定が違うだけなのか？
プレビューのグレー枠が気にはなっていますが、それ以外にも少し気になる点が。
こちらは手を加えた出力タイマーですが、時間設定の変更をしてobs-studioを再起動するとどうも時間が変更する前の状態に戻っているという謎現象。
ソースを追うと時間設定値を開始時にはファイルからリストアされて、終了時にはファイルに保存されている部分がありました。具体的には
C:\Users\[ユーザー名]\AppData\Roaming\obs-studio\basic\scenes\[シーン名].json
内のoutput-timerに保存されています。更新状況を見ると毎回終了時に書き出されているのが確認できました。
コンパイル環境では出力タイマーの時間設定値は更新されていて、実際に使用している環境だと時間設定値が変わらないという状況で、原因がよくわからないので一旦obs-studioのファイルの整合性チェックを行って更新して見ましたが、変化がなかったので、再インストールすることに。31.0.4のインストーラが公開されていたのでこれで試してみます。
設定ファイルは消さない状態で再インストールしましたが、出力タイマーの時間設定値が更新されることを確認。
そしてカスタマイズした実行ファイルを被せてみます。
まずは本体。obs64.exeとobs64.pdbをリネームし、入れ替え再実行。→時間設定値が更新される。
次にプラグインとなるfrontend-tools.dllとfrontend-tools.pdbをリネームし、入れ替えて再実行。→時間設定値が更新されない。
さらに実行ログにはNumber of memory leaks: 1という明らかに良くなさそうなものがきろくされていました。
プラグインかぁ…とobs-studioのメニューのツール内を見てみると、なにやら英語と日本語表記がダブって表示されていることに気づき…frontend-tools.dllとfrontend-tools.pdbをリネームしてプラグインフォルダに残っていることが原因ではなかろうかと…。
不要なリネームしたファイルを一旦関係のない別のフォルダに移動してobs-studioを起動して試してみると、メニューはスッキリ日本語のみとなり、時間設定値も保存されるようになりました。実行ログもNumber of memory leaks: 0となったのでめでたしめでたし。
プラグインフォルダには余計なファイルを入れていおいてはダメみたいですねｗ
31.0.3をインストーラーからインストールして、更新して、カスタマイズした31.0.4のexeとカスタマイズしたプラグインの実行ファイルを放り込んだはずの環境のobsのウィンドウには31.0.3と出ている……。
インストールされているフォルダ内を確認してみると、差し替える元となるファイルのバージョンは31.0.3になっている。ということは、31.0.3の環境に31.0.4のカスタマイズされた実行ファイルと、プラグインを入れ替えたという状態になっているのだろうなぁ…単純にobs-studio内からアップデートかけてないということか…orz
そんなわけで、試しにobs-studio内から更新を行ってみると「最新の状態」となってしまい、何も変わらず。なのでファイルの整合性チェックを行い、更新してみると、ようやく31.0.4の状態になったっぽいです。
まぁカスタマイズで差し替えたものは綺麗さっぱり正規の状態に書き戻されたわけですが、ここで改めてカスタマイズし昨日作成した実行ファイルを差し替えて…。ようやく期待している状態になりましたｗ
そもそも31.0.xはそんなに違いは無いはずなのと、各モジュールとのインタフェースは変わってない感じなので当然と言えば当然ですが、もしかしてそれぞれの環境を個別にgit cloneする必要はなかったという事実ｗ
ちょうどいいタイミングでSDカードが飛んでしまったのでNTFSフォーマットにして作業場所ができたのでいいんですけど。
今まで特にこれと言ったこだわりが無かったため、その時々でPCで使うたび最新版のOBSをインストールしていました。OBS自体のバージョンチェックも止めているため、普段はバージョンを意識することはありませんでした…が、ここ最近カスタマイズしてファイルを入れ替えたりしているので個々のPCでバージョンが違っているために、バージョンごとに実行ファイルを作成するのに手間がかかってきたので、古いものをアップデートするか、ダウンロードした手持ちの最新のものに入れ替えるか…どうしようかと、結局バージョンチェックで直接アップデートすることに。（あれ？インストールしたディレクトリってバージョン含めてたかも…）
すると最新版がアップされている状態だったらしく、31.0.4とか…仕方がないのでgit cloneしてソースの変更もして31.0.4の実行ファイルをビルドしてみました。
さすがに慣れてきた感があって作業は非常にあっさりと、そう、今までコンパイルオプションで警告を無視しないとだめだった nv-filters と win-capture も警告が出なくなっていました。
なので本当にあっさりと。
今までうざかったプレビュー画面の枠が消えてスッキリしてくれてたり。
細かなところは全く分かりませんが、更新内容を見ると致命的な部分もあった様子。
実際使っているPCのファイルを差し替え…やっぱりインストールディレクトリにバージョンを含めた形に…。しかもWindowsのアプリ一覧に出てないし…直接zip展開してただけっぽい…
最新版をインストーラーを使ってインストールしてみるかと、ダウンロードしてみると最新版が31.0.3でした。なので、インストーラーを使った後にアップデートをして…
今まで使用していた実行ファイル群はフォルダごとゴミ箱へ。
QGridLayoutの詳細が分からなかったのであまり弄らないつもりでしたが、.uiファイルを見ているとやりたいことは一通りできそうなので少し調べてみました。
そもそも論として.uiファイルはxmlで記述されていて、そこの仕様が惜しいところで把握できなく…
Qt Widgets Designer's UI File Format(https://doc.qt.io/qt-6/designer-ui-file-format.html)
さらに見ていくとデザイナーなるアプリが存在していることも知ることができました。
最初は自動生成された.hを直接修正するとかイミフなことをやってたぐらいですｗ
デザイナーを使うためにQtのインストールをしようかと調べてみると、ユーザー登録とかなんか面倒そうなので途方に暮れてたところ、gitでダウンロードした中に .deps\obs-deps-qt6-2024-09-12-x64 / bin がありその中に一式ありそうでした。
一番知りたかったのがストレッチとスペーサーの違い。xml記述だとスペーサーに統合されているようで、ストレッチが記述できそうにないところまでは分かったのですが、実際にどんなパラメータを並べればストレッチのようになるのか知りたかったので、デザイナー上でスペーサーを追加し、保存したファイルの中を見てみることに。
その結果、
<spacer>
<property name="orientation">
<enum>Qt::Vertical</enum>
</property>
</spacer>
とすれば、今回必要だった縦方向に伸び縮みするエリアができてくれました。ストレッチのヒントとかデザイナーではデフォルトで追記するようになっていましたが、今回は省いても問題なしと判断。
そんな感じで出力タイマーの.uiファイルを弄っていて、気になったのが出力タイマー画面のデザイン。使い始めたときから気になっていた画面ではありますが、明らかにグリッドに配置されているセルの扱いがヤッツケ感が高いというかｗ
なのでcolspanを設定して変な余白が出ないようにするとこんな感じに。
キャンセルボタンの有効化/無効化はボタンの表示の切り替わるタイミングで行うようにして画面レイアウトもひとまず終了。
例えばタイマー設定をして記録し始めたときに、やっぱり延長したいなぁと思っても、OBSの録画タイマーのキャンセルって停止してから再開する他無いんだよなぁなんて思ったことはないですか？
私だけですか…？
そんな優柔不断な決断力と実行力のない人向けのボタン！
関係ないときや機能しない状態のときの無効化を意識しなければこのままでもいいかもしれない…
OBSの出力タイマーは個人的には独特の使用方法と感じましたが、慣れると結構便利で、例えば３０分間の動画をメインに作成しているときなど、何も考えずに開始すればグダグダになった動画でも強制停止されるために仮に途中で寝落ちしても巨大な動画ファイルが作成されずに済むとか…普通は無いですかｗ
結構重宝してるのですが、問題となるのは録画中に停止タイマーを切りたいときに一旦停止させる必要があるというのが、結構ヒッカカッテ使ってました。
ソースを追い始めて手間暇かかってる感じがして結構大変そうかな？とか挫折しそうになりましたが、結局のところこのタイマーは、開始時に終了までのインターバル時間を設定して開始させてるだけで、終了時間が経過するとイベント処理が行われる。という非常にシンプルな物でした。
録画の一時停止との連動はややトリッキー的に終了までの残り時間を保存してタイマーを停止。再開時には保存した残り時間をタイマーのインターバルに設定して開始しているだけ。
非常にシンプル。
メインとなるobsの動作はボタンが押されたときに録画を開始させたり、すでに録画状態であればタイマーだけ開始させたり、録画中でタイマーが動作している場合は録画停止を行ったりと１つのボタンで機能分けされている感じになっていました。
正直なところ、出力タイマーウィンドウを閉じたらキャンセルしてくれないかなぁとか最初は思ったりしたんですけど、UI的にそれはどうかとは思うｗ
タイマーだけ単独の一時停止とかもあってもよさそうな気もしますが、どうなんでしょうね？
Windowsはやたらとバックグラウンドで動作して作業中の邪魔になったり、ストレージ過負荷による短命化の印象があります。
プレビューとして使うことの多かった標準のフォトアプリですが、最近になって旧フォトビュワーが「フォトレガシ」として存在していることに気づきインストールしました。フォトアプリは、エクスプローラからのプレビューとして利用すると起動時のもっさり感や、フォトアプリ内で前後のファイルに移動できるようになるまでのもたつきが結構ストレスでした。フォトビュワーもそれなりにツッカカリはありますが、フォトアプリに比べればまだましかな？
ビュワーとしてまぁそれなりの満足はしていたものの、閉じているはずのフォトレガシがタスクマネージャーのプロセスに張り付いていたのは気にはなっていました。
さらに週末になり、PCで作業をしていると一定期間操作を放置しているとふとCPU負荷がかかっていることに気づきました。
タスクマネージャのパフォーマンスのグラフを見ていると放置して１０分程度時間が経過すると突然全ての論理プロセッサの使用率が100%に。ディフェンダーやデフラグのような動作の割にディスクアクセスもなく、またマウスを動かした程度で再び使用率が正常になるというものすごいメンドクサイ状況に。
手ごろなプロセス監視ツールでもあればと思い、その度にこんな感じで監視させればいいかなぁとか考えて終わるという…全く形に残らない無駄な設計をし続けること早ん十年。
最初はタスクスケジューラーで起動されているものを疑って片っ端から不要そうなタスクの自動起動を「無効」にしていたのですが、状況はあまり変わりがありませんでした。無効化したタスクの起動間隔がそもそも数時間～一日程度となっているので、今回気になっているものとは別のものだったのでしょう。
次にサービスを見たところ、フォト関連のサービス名が見つからず…
ほぼ確実に放置すると使用率が上がってしまうので、タスクマネージャをプロセスや詳細表示に切り替えて様子を見ていると、どうやらフォトレガシのプロセスのCPU使用率が上がっていることが目視できました。
敵が明確化できたものの、タスクでもなく、サービスでもなく、いったい何なのだろうと悩みつつ、アプリの設定でもなんかバックグラウンドなんたらかんたらとか書いてあったような気がするなということで、
設定→アプリ→インストールされているアプリ→フォトレガシ→詳細オプション
でバックグラウンド アプリのアクセス許可を「常にオフ」（いままでは電力最適化（省電力））
.png)
するとようやく変な負荷がかからなくなりました。
めでたしめでたしなのですが、、、メインで使っているPCがWindows11になってからタスクマネージャのパフォーマンスのグラフがいつみても荒ぶっていると感じていたのですが、フォトレガシのバックグラウンド負荷の確認をしていると今まで気にしていなかった
Shell Infrastructure Host
なるプロセスがなにやら張り付いていることに気づき、プロセス画面の負荷も58%とか…
詳細の方で見るとsihost.exeと出ているのが分かったので、ググってみました。
Windows 11 で sihost.exe が CPU を浪費する問題 https://qiita.com/Smriji/items/e1ce7987d1b81d044b18
を見ると、原因は確実に「フォト」ということ。ちなみにフォトアプリにはバックグラウンドうんぬんの設定項目は現状ありません（2025/06/24現在）。記事の日付を見ると結構初めからあった問題なのかな。私がこのプロセスに気づいたのが今日だったりします…
フォトレガシの存在を知った前後にフォトアプリがさらに処理が重くなりそうだというような記事を見かけたのですが、フォトアプリの起動時の処理を見直し、バックグラウンドで待機するとかなんとか…この前のアップデートで、一般向けにもリリースされたのかな？とか感じつつも、ここはサクッとフォトアプリをアンインストール。
アンインストール後もプロセス詳細にsihost.exeが残っていましたがしばらくすると消えてくれたので、これでようやくスッキリできるのかな？
タスクスケジューラのパフォーマンスをみると久しぶりに落ち着いているグラフを見た気がします。
ほかの使用しているPCでもフォトアプリはとっととアンインストールしておこう…
なお、フォトレガシのバックグラウンド動作はおそらくですが、Googleよろしく過去の写真や動画からいろいろな提案を行ってくれるのだと思いますが…正直イラナイデス。マーケティングには有用なんでしょうけども。
https://help.goo.ne.jp/help/article/2889/
ま、まじか…
地味に信用できるデジタル辞書だったのに…
オンライン辞書ではなく電子書籍版でも使えばいいのかなぁ？普通の人はどうやってるのだろう？
Windows10ぐらいからほぼ必須扱いのHotmailアカウント。
先日購入したミニPCにプレインストールされていたものはWindows11でした。
Windows10のときはオフラインでもローカルアカウントで起動できた気がしますが、Windows11ではWifi設定をうまく切り抜けたりしない限りローカルアカウントで起動できなくなっていた気がしたのですが、なぜかそのPCはオフラインのまま起動してしまいました。
OneDriveは賛否両論ありますが、個人的にはあってもいいかな？ぐらいの状態で使用していてそれなりに重宝もしてたりします。（そろそろ本気でバックアップしておかないと痛い目見そう…）
なのでOneDriveを使用するためにサインインさせようとしたのですが、コード送信ボタンを押した後、なぜか「xxxx@hotmail.comに送信したコードを入力してください」と画面が切り替わるものの、待てど暮らせど送付される気配もなく…
そもそも、認証用のコードってなんか手順が違ってるような…と。
別のPCでhotmailのメールを見れる状態のものがなかったので、直接webでアクセスしてみようとしたところ、そこでも認証用のコードのやり取りが行われました。
1.hotmailに紐づいている認証用のメールアドレスの入力を行う。
2.コード送信ボタンを押す。
3.認証コードがメールアドレスに届く
4.サインイン画面に表示されている画面にコードを入力する。
という手順を踏んでアクセスすることができました。。。今までこうだったよなぁ。。。
最近やたらとマイクロソフトアカウントに電話番号を追加して二段階認証を有効にしましょうとか出てた気もするし、そもそも二段階認証自体もそこまで確実じゃない気がするのだが…そう思いながらも「もしかしたら二段階認証にするとうまくいくのかも？」と期待して設定で登録してみました。
ですが、ミニPC側ではいつまでも上手く行きません。
ついでにアカウントのログインアクセス履歴を見てもミニPCからのアクセスは上がっていない様子
なんとなく気持ち悪いので、最近使ったUSBメモリーにWindows11のセットアップが入っていたので、クリーンインストールして、アカウントの紐づけを行いました。
インストール前にプロダクトコードだとか、ドライバのバックアップとか最低限行いましたが、マイクロソフトアカウントとライセンス認証が紐づいていると考えていましたが、クリーンインストールしたときにはプロダクトコードの入力やライセンス認証は自動に終わってました。
クリーンインストールはそれで無事終了したのですが、昨日githubを使っていると「二段階認証が必須になりました！」とか出てきたので慌てて右往左往したところ、いくつか手はあるようで、その中でもMicrosoft Authenticatorならちょうどいいんじゃないかなぁと。PCで完結できるかと思ったのですが、スマホアプリでした。まぁ仕方がない。インストールと…
そこでhotmailアカウント。コード送信ボタンはあるもののメールアドレス入力はなし…嫌な予感。
はい。全くコードが送信されてくる気配がありませんでした／(^o^)＼
ダメそうなので、なぜか存在する「スキップ」というリンクっぽい部分をクリックすると、そのままアプリが起動して…いくら画面を見てもアカウントに紐づけられない状態に。閉じて起動させてもサインイン画面が表示されず…こんな状態で二段階認証を行えるようにしても他のスマホに移行できなくなると困るので他に手はないかと思っていたらgithub謹製のgithub mobileなるアプリを使ってもオッケーな模様。早速インストールしたものの。。。いくらPC側でサインインしなおしても二段階認証が有効になっている気配はありません。
もう少し設定を見ていると、特定の国ではSMSによる二段階認証も可能とのことなので、スマホの番号を入力し、ようやく二段階認証の設定が完了しました。これならほかのスマホに移行できるしめでたしめでたし…ですが、するとgithub mobileアプリから通知が…いまさら二段階認証がアプリでできてもみたいなｗ
結局、マイクロソフトアカウントで認証確認用のメールアドレスを入力しないパターンのコード送信ボタンって正しく実装されているのでしょうかねぇ？
いまだに勝手に全角英文字に切り替わった後、マウスで戻しています。
「続」とあるのは、その後少しだけ再現率が高い状況に陥ったことと、さらにマウスで戻しても効果がなくなって常に全角英数字モードになってしまうという。
その回避方法というのが、メモ帳などでも何でもよいので別のウィンドウに切り替えて入力モードを切り替えると元に戻るというもの。
昔のWindowsでもあったのですが、IMEの入力モードがおかしくなるという状況に陥った場合、ほかの入力できるウィンドウに一度切り替えると元に戻るという謎現象。
またこの全角英数字に勝手に切り替わってしまう病はFireFoxでbloggerの入力を行っていると発生しやすくなるということ。
そもそもbloggerとFireFoxは相性が昔から悪く、テキストを編集しているとIMEの入力を切り替えたり、バックスペースで文字を消すと入力している編集中の文字が消えたり、エンターキーを入力しても改行されなくなったりと、非常にストレスがたまったりします。
そう考えると諸悪の根源はFireFoxなのか？？わからんｗ
ついついミッキーパン事件以降某パンメーカーを避けるようになっていましたが、パン祭りや特売で品切れで仕方なく問題のパンメーカーのものを食べたところそっちのほうが美味しかったり。
そのため、最近ではロイヤルブレッドか超熟のどちらかを食べるようになりました。個人的には超熟の方がおいしく感じています。昔、ダブルソフトを食べたときはおいしくて驚いたのですが、このまえ売り場にダブルソフトしかなく食べたところ、記憶のおいしさはまったくなく、正直「こんなもんだったっけ？」と。
そんな食パン私的な事情ですが、先日購入したもので…異物が…。
そーっと封を開けて取り出してみると…
まぁ焼かれてる感じでもないし、封をするタイミングで上に乗ったかしたのかな？と
トースターで焼くし、まぁ食べても問題なさそうなので食べちゃいましたけどｗ
蚊程度でよかったと思うべきか、蚊程度なら混入するような環境で製造されているのかと考えるべきか、悩ましいところ。
何も考えずひたすらビルドすることだけに進んでみたが、結局は素直にgit cloneするのが良いようです。
何も考えず、デベロッパー用のドキュメントの手順で進めると、github上のリポジトリからクローンした場合は、バージョンチェックで引っかかるので、
set(OBS_VERSION_OVERRIDE "31.1.0-beta2 master")
どこかでOBS_VERSION_OVERRIDEを設定してあげるか、cmake-guiだと変数のところでaddしてあげれば切り抜けられるとは思う。
色々と試行錯誤した結果として、github上だとデフォルトのブランチからしかフォークさせられないようで…ほしいものは、「実際に動かしている状態で実行ファイルだけ挿げ替えたい」なので、これではだめだということに。
ソースファイルのダウンロードの方法は、 obsproject/obs-studio でブランチなりタグなりを一覧表示させればそのものがダウンロードはできた。
そして、いざcmake！
一番最初にやったことですが、zipなりでソース展開するとどうもgit cloneで取得できるもののようで、内包される別リポジトリのソースは含まれていないようで…当たり前っちゃ当たり前だけど、結構不便。というか、知らないで後日何かしようとしても手遅れになりそう。
実際にcmakeを実行させると最後の方で、
-- Configuring done (0.4s)
CMake Error at plugins/win-dshow/virtualcam-module/CMakeLists.txt:93 (target_link_libraries):
Cannot find source file:
C:/obs/obs-studio-31.0.2/deps/libdshowcapture/src/dshowcapture.hpp
-- Generating done (0.7s)
CMake Generate step failed. Build files cannot be regenerated correctly.
CMake Error at cmake/windows/architecture.cmake:17 (execute_process):
execute_process failed command indexes:
1: "Child return code: 1"
Call Stack (most recent call first):
CMakeLists.txt:8 (include)
-- Configuring incomplete, errors occurred!
などと怒られるので、個別にソースを何とかしてあげたりするとcmakeは通ってくれるようにはなるものの、当たり前ですが、バージョンが一致してなければコンパイルすら通らなくなるという…
試行錯誤の末、結局git cloneで直接ローカルに持ってくるしかない。という結論に。
> git clone --recursive https://github.com/obsproject/obs-studio.git -b 31.0.2 --depth 1
欲しいのはこのタグ付けされたバージョンが欲しいので、これなら一気に持ってきてくれるハズ。
とはいえ、コミットされていないものがあるので、ワーニングが出たりしましたが、一通りダウンロードされたので、cmake!
なんだかんだと勘違いなどもあるので、cmake-guiを使った方がvisualstudioの起動まで行ってもらえるので便利かな？
ソースの場所や、プリセットを設定し、Configure Generate OpenProjectボタンを順番に押しました。
visualstudio上でソリューションのオープンもできたようなので、試しに▷ボタンで実行してみるとコンパイルが始まりました。しばらくすると、２つのビルドで（キャスト関連の）警告文が発生し警告がエラーとして扱われるためにビルドエラーが発生してしまいました。内容的には問題なさげなので、個別のプロジェクトのコンパイルオプションを変更して警告は無視させました。
そして待望の31.0.2のOBSの画面がでました。
で、ソースを手直しして…と思ったら、31.0と31.1はソースの配置換えを行っているようで、ファイル名まで違っていた様子。
目的の \obs-studio\UI\window-basic-stats.cpp ファイルも見つかったので、中身はほぼ一緒なので修正もすぐ終わり、構成をリリースに切替て実行させてみました。
.png)
いい感じになったので、実際に動かしている環境に実行ファイルを入れて動作確認。
昨日試しにインチキビルドした実行ファイルを挿げ替えて実行させたところライブラリなどのエントリポイントの不一致でエラーが発生させてしまったのですが、その時からコントロール内のボタンが一つ表示されなくなりました。正直消したかったのでいいのですが、ビルドした実行ファイルが原因で、レジストリのエントリーが消されたのかな？とは思います。
一通り動作はした感じですが、気になるのが実行ファイルのファイルサイズが結構違うところ。
もともとインストールされていたobs64.exeが4.89MBだったのに比べ、出来上がったものは4.69MBと、0.2MBほどの誤差が…付随する.pdbファイルも微妙にサイズが違ったりしているので、バンドルされているプラグインがdisable状態に変更になっているだけかもしれません。
足掛け３，４日でなんとかやりたいところまでようやくたどり着きました…。
蛇足
いまさらながら、統計ウィンドウはドック状態のウィンドウでもウィンドウのタイトルバーに「×」ボタンがついているという事実…ソース内では closable で単独ウィンドウなのかドック可能状態か区別しているのですが、どっちもクローズできるじゃん…とかｗ
非力なPCでOBSを使っていてもそれなりに動いてくれるのですが、画面的制約から無駄な領域が何とかならないかと思っていました。
最初はリソースっぽい何かがありそうかな？と期待していたのですが、GitHubを見る限りそんなものはなさそうで…クロスコンパイル前提のソースでディレクトリ階層がまったく把握できず。途方に暮れてましたが、どうせならコンパイル環境を作るところから始めてみました。が、最初は全くうまくいきませんでした。
必要なツールは個別にインストールし、説明されている通りにgit cloneからcmakeを実行したところでどうにもダメ。原因が不明なところどうやらFAT32ではなくNTFS上でソースを扱う必要があるという点と、PowerShellのバージョンが古いとエラーではまるらしいということで再度挑戦してみるとようやくVisualStudioで実際にビルドすることもできました。
実際にx64環境でVisualStudioで開いてみると、ソースをブラウズするのもかなり便利に。
そして肝心のリソースのようなものは存在していないというのが確定したこと。ダイアログとドックはほぼ共通化されていて、ウィンドウクラスは同じものという作りだということがわかりました。
OBSはQtが使用されていて、ソースを眺めていればそれなりに解りやすかった？
ターゲットとなるソースファイルは.\obs-studio\frontend\widgets\OBSBasicStats.cpp
メモを起こして、どんな感じの入れ子になっているのか確認しつつ実際に直接変更してみました。
その結果、
.png)
.png)
いまいち位置の固定方法がわかってないのでドック可能なパターンだとリセットボタンが割り当てられている領域の中心位置になってはいます。多分ストレッチを追加すると上か下に張り付かせられそうだけど、まぁ見た目的には満足なので…
ただ、これ、最新のmasterからのクローンなので、実際に使っているバージョンではなくてbeta版…GitHub上でフォークすればよかったかなｗ
これで統計を下にドックさせた状態でも少しだけだけどプレビュー画面が広がる…
とりあえず、GitHubにソースを反映させてみた。まだcloneしてコンパイル通していないけど… https://github.com/siriuth/obs-studio/tree/master
しばらく放置していたFireStickを使っていたら「なんか音量が小さくね？」と。ボリュームを最大にしてもいつも聞いている音量かなぁ？ぐらいまでしか大きくならず。
一度スリープにしてみる→変化なし
HDMIコネクタからFireStickを抜き差ししてみる→変化なし
そういえば設定を変えてみたなぁ…
オーディオ出力の自動になっていた項目をPCMに指定したり、接続機器のチェックを動かしてみたりと…
再度同じようなことをやっても変化なし
原因が全く分からないので、いつも使っているもうひとつのFireStickを使ってみたところ、ちゃんとした音量になった。
じゃぁもう一回放置してたFireStickを接続してみると、ちゃんとした音量に。
結論、ボリュームが半分程度になってしまったら電源のUSBケーブルをいったん抜いてみるといいカモ？
ボリュームが半分になるトリガーはハッキリしませんが、そのごしばらく問題なさげ。
色々と言いたいことはありますけども、ネーミングについて
古米（こまい）、古古米（ここまい）程度なら言葉として使ったことはあります（とはいえ小学３，４年ぐらいのときだけだと思う）が、さすがに古古古米なんて備蓄米放出問題が騒がれなければ使うことはなかったでしょう。
まぁそのままでいいんじゃね？って思っていましたが、おとといあたりから「ビンテージ米」などという言葉をみかけて「そりゃはんそくじゃね？」と思っていたらふと
古米（こまい）←そのまま
古古米（ここまい、にこまい）←ここまではどっちでもいい気がする
古古古米（みこまい）
古古古古米（しこまい）
古の数を先に言っちゃえばという発想ｗ
まぁ少なくてもどれだけ古いか解らなくなるような言葉をつけるべきではないと思うし。
備蓄米もブレンドじゃなければきちんと試食してみたかったかなぁ… ブレンド前提だと食べ比べても正確な判断はつかない気がする。
前々からかなり不便な部分で日本語入力をしているときに、全角英数字入力に切り替わってしまってマウス操作が必要になってしまうという問題。
日本語入力と全角英数字入力が切り替わるだけになってしまい、半角英数字（直接入力）にするためにマウスでタスクトレイのIMEのアイコンで入力モードを切り替える必要になってしまいます。
大抵の場合、入力切替時に発生しているのでキーボード操作によるものだろうと感じてはいるものの、はっきりと「このキーとこのキーを押したから切り替わってしまった」という結果にはならず、逆に全角英数字への切り替えもどうやるのかもわからないｗ
windows11でIMEが勝手に全角英数モードになる件 https://qiita.com/Oscer/items/132a8153cc5dcf0fad47
Windows10でも同様の現象が起っていた記憶があって、その時は互換モードに切り替えてしのいでいたのですが、Windows11だとそこまで互換モードにしなくても何とかなっていたので切り替えてはいませんでした。が、互換モードが最適解なのかな？と試したところ、状況はさらに斜め上に。悪化したというべきか、なんというか。
互換モードだと入力モードを日本語入力モードから英数字入力に切り替えた後やコピーペーストの後などに最初の入力文字だけが全角で入力されるという。
結構致命的なのが、スクリプトなどで
'test'
と入力したつもりが、
’test'
↑最初の文字が全角ｗ
と入力されてしまい、 実行時にエラーになってはまると言う…
しかもなんか画面を見ているとダメな人が言い訳しているかのように１文字だけ全角になってbackspaceで戻した後は直接入力モードになっていかにも「なにももんだいないよ」とか装っているというｗ
どっちがクソかと言えば、、、まだ入力切替時限定のほうがましかな？
アップデートが腐っててデータ災害はないものの、エクスプローラーが動作が不安定だったりするのでみんな本当にこんなOS使っているのかな？
.png)
.png)