はじめに
前回記事 では、obs-plugintemplate を使い、Windows + Visual Studio 2022 環境で OBS Studio プラグインをビルドし、OBS Studio でロードできることを確認しました。
今回は、配布に必要な設定変更と、配布物の作成手順を書きます。
OBS プラグインを配布する場合は、ライセンス要件を先に確認してください。obs-plugintemplate の配布ガイド では、libobs を使うプラグインは GPL (GNU General Public License) の combined work として扱われるため、プラグイン側も GPL で配布し、受け取り手がソースコードへ到達できる必要があると説明されています。本記事の後半でも、配布前の確認事項として改めて触れます。
最初に、buildspec.json でプラグイン名やバージョンなどを変更します。その後、配布に必要なファイル一式を dist に集めます。最後に、それらを zip にまとめ、GitHub Releases から配布します。
この記事でやること
- プラグイン名 (識別子) と表示名 (日英併記) の変更
- 配布に必要なファイル一式の zip 化
- GitHub Releases に zip を添付して配布
対象読者
- OBS Studio のフィルタを触ったことがあり、プラグインのビルドに一度成功している方
- 作成した OBS プラグインを友人へ配布したくなった方
検証環境
- OS:
Windows 11 - OBS Studio:
32.0.4(32. 系) - Visual Studio:
Visual Studio 2022 Community - CMake:
4.2.1 - Git:
2.52.0.windows.1
OBS プラグインとして配布すべきファイル群の実体とインストール先
配布物は .dll だけでは足りない
Windows のプラグインは、概ね次のような構造です。配布物はフォルダーごと渡す必要があります。
<plugin-root>/bin/64bit/<plugin>.dll-
<plugin-root>/bin/64bit/<plugin>.pdb(これは任意。クラッシュ調査に役立つが、配布しない選択もある) <plugin-root>/data/locale/*.ini-
<plugin-root>/data/...(画像などのリソース)
インストール先は ProgramData 配下になる
少なくとも OBS Studio 28.0 時点の Plugins Guide では、手動インストールの推奨先として C:\ProgramData\obs-studio\plugins が案内されています (参考)。この場所へ入れる場合は、プラグイン名のフォルダー配下に bin と data を作り、bin\64bit\<plugin>.dll と data\... (+ 任意で bin/64bit/<plugin>.pdb ) を置く必要があります。
古い手順として C:\Program Files\obs-studio\obs-plugins\64bit へ .dll を直接コピーする例も存在します。しかしながら、 obs-plugintemplate によるビルド成果物は ProgramData 配下へ入れる構造を前提としているため、今回は Program Files 配下へのコピーについては扱いません。
プロジェクトフォルダーの名前を変更する
前回記事 の手順どおりに進めた場合、作業フォルダー名が obs-plugintemplate のようなテンプレート由来の名前のままになっていることがあります。このままでも開発はできますが、配布や共有の段階ではフォルダー名も分かりやすいほうが迷いにくくなります。
ここでは例として、プロジェクトフォルダー名を test-plugin に変更します。
ここで変更するのは「作業フォルダー名」です。プラグインの識別子 (name) や表示名 (displayName) は、次の章で編集する buildspec.json によって決まります。フォルダー名を変えただけでは、プラグイン名は変わりません。
1. フォルダー名を変更する前に確認する
ファイルがロックされているとリネームできないことがあるため、次を終了してください。
- OBS Studio
- Visual Studio 2022
2. フォルダー名を変更する
エクスプローラーでリネームしても構いません。本記事では Git Bash を前提に、コマンド例を示します。
まず、プロジェクトフォルダーの 1 つ上へ移動します。
cd <プロジェクトの親フォルダー>
<プロジェクトの親フォルダー> の部分は適宜読み替えてください。例: /c/Users/AllegroMoltoV
次に、フォルダー名を変更します。
mv obs-plugintemplate test-plugin # フォルダー名を「obs-plugintemplate」→「test-plugin」に変更
obs-plugintemplate の部分は、現在のフォルダー名に置き換えてください。
Windows 環境では次のようなメッセージが出て、フォルダー名を変更できない場合があります。
mv: cannot move 'obs-plugintemplate' to 'test-plugin': Permission denied
このときは、エクスプローラーを開き「名前の変更」で直接変更してください。
3. build_x64 と .deps 配下の build キャッシュを作り直す
フォルダー名を変更したあとは、CMake のキャッシュが「旧フォルダーのパス」を保持していることがあります。この状態で cmake --preset ... を実行すると失敗します。このため、フォルダー名変更後は build_x64 と.deps 配下の obs-studio-*/build_* を削除します。
cd test-plugin
rm -rf build_x64 # フォルダーごと強制削除
rm -rf .deps/obs-studio-*/build_* # OBS ソース側のビルドキャッシュを削除
buildspec.json を編集しプラグイン設定を整える
buildspec.json は、ビルドに必要な依存関係と、プラグインのメタデータをまとめた JSON ファイルです。あなたの buildspec.json は、先頭に dependencies と platformConfig があり、末尾にメタデータがあります。
dependencies は OBS Studio 本体やビルド用依存物の取得に使います。Windows 配布だけを目的にする場合、まず触るのはファイル末尾のメタデータ部分です。
たとえば、テスト用の値は次のようになります。
{
"name": "test-plugin",
"displayName": "テストプラグイン / Test Plugin",
"version": "0.1.0",
"author": "AllegroMoltoV",
"website": "https://www.allegromoltov.jp",
"email": "your-email@example.com"
}
-
nameは、英小文字と-を中心にします。フォルダー名や.dll名に影響するためです。 -
displayNameは、OBS Studio の UI に表示される名前です。本記事では日本語 / Englishの形式で統一します。 -
versionは0.1.0のように 3 つの数字で表す形式にそろえます。更新のたびに増やします。
Visual Studio ソリューションファイルのビルド
その後、前回記事 と同じ手順で CMake の生成をやり直します。コマンドも前回記事と同じです。
例:
cmake --preset windows-x64-local
このコマンドは、前回記事 で使ったものに合わせてください。もし前回記事で別の生成オプションを使っている場合は、同じオプションで再実行します。
以降の手順では cd <プロジェクトフォルダーのパス> のようにフォルダー名を含むパスを入力します。フォルダー名を変更した場合は、ここも新しい名前に合わせてください。 例: /c/Users/AllegroMoltoV/test-plugin
配布するファイルのビルド
ビルドした build_x64/test-plugin.sln を Visual Studio で開きます。ビルドの構成には、Debug, MinSizeRel, Release, RelWithDebInfo が選択可能です。
| 構成名 | 解説 |
|---|---|
Debug |
開発中の動作確認や原因調査をしやすくする構成。「調査用のラベルをたくさん貼った状態」で、Visual Studio のデバッガーで 1 行ずつ追いかけたり、変数の中身を見たりできる。 その代わり、動作が重くなりやすく、配布物としては不向き。 |
MinSizeRel |
配布向けの構成の一種。ファイルサイズをできるだけ小さくすることを優先した構成。 DL 容量を抑えたいときに意味があるが、OBS プラグインのように .dll と data フォルダー一式で配布するケースでは体感できる差が小さいことも。動作速度が常に有利になるとは限らない。 |
Release |
配布向けの構成。実行時の余計な情報を減らし、普段使いの状態に近い動作になる。 身内配布でも、まずは Release を基準にすると迷いにくい。 |
RelWithDebInfo |
配布向けの構成に加え、デバッグ情報 (Windows では主に .pdb ファイル) を出しやすい構成。普段使いの状態に「原因調査用の地図」を別添えするイメージ。クラッシュしたときに調査の手がかりになる。
|
本記事では、次の運用とします。
- 開発中:
RelWithDebInfo - 配布物:
Release
1. Visual Studio でビルドする
構成を Release x64 に設定し、 ビルド > ソリューションのビルド で配布用のファイルを生成します。
2. dist へビルド成果物を集める
配布物は、フォルダー構造を崩さずに渡す必要があります。cmake --install を使うと、配布に必要なファイル一式を、決まった構造でまとめて出力できます。配布物は Release にそろえたいので、--config Release を付けます。
cmake --install build_x64 --config Release --prefix dist
成功すると、dist/test-plugin/ 配下へ出力されます。
実行結果の例
-- Installing: /test-plugin/dist/test-plugin/bin/64bit/test-plugin.dll
-- Installing: /test-plugin/dist/test-plugin/bin/64bit/test-plugin.pdb
-- Installing: /test-plugin/dist/test-plugin/data
-- Installing: /test-plugin/dist/test-plugin/data/effects
-- Installing: /test-plugin/dist/test-plugin/data/effects/tint.effect
-- Installing: /test-plugin/dist/test-plugin/data/locale
-- Installing: /test-plugin/dist/test-plugin/data/locale/en-US.ini
-- Installing: /test-plugin/dist/test-plugin/data/locale/ja-JP.ini
zip を作る
次のフォルダーを zip にします。
dist/test-plugin/
dist 自体や、さらに上位のフォルダーを一緒に固めないでください。受け取り手が展開先を間違えやすくなるためです。
1. zip の作成
Windows のエクスプローラーで dist を開き、test-plugin フォルダーを SHIFT+右クリックします。送る > 圧縮 (zip 形式) フォルダー を選びます。
2. zip のインストール
ここでは、受け取り手と同じ手順で動作確認します。配布前にこの確認をしておくと、GitHub 側の作業で悩んだときも切り分けができます。
展開先は %PROGRAMDATA%\obs-studio\plugins です。
ProgramData 配下は、プラグイン構造に決まりがあります。
前回記事 の手順によって、ビルド後の cmake --install を自動化している場合、ここにすでに test-plugin フォルダーが生成されているはずです。 zip の動作検証を行うには、すでに生成されている test-plugin フォルダーを削除してください。
展開後のパスは、次のようになります。
%PROGRAMDATA%\obs-studio\plugins\test-plugin\bin\64bit\test-plugin.dll%PROGRAMDATA%\obs-studio\plugins\test-plugin\data\locale\...
OBS Studio を終了し、zip を展開します。test-plugin フォルダーごと %PROGRAMDATA%\obs-studio\plugins 配下へ置きます。
3. 動作確認
OBS Studio を起動してプラグインがロードされることを確認します。
GitHub Releases での配布
zip を Google Drive などで共有して配布する方法もあります。ただし、libobs を利用する OBS プラグインをバイナリ (今回ビルドした .dll ファイル) で配布する場合は、「受け取り手が対応するソースコードへ到達できる状態」を用意する必要があると obs-plugintemplate の配布ガイド で説明されています。このためソースコードの入手先を示さないまま zip だけを共有する配布は避けるほうが安全です。
また、ソースコードへの導線を用意していたとしても、Drive 等での配布を続けると次の困りごとが起きやすくなります。
- 友人が古い zip を持ったままになりがち
- どのファイルを落とすべきか、毎回説明が必要になる
- 更新のたびに URL を送り直すことになりがち
GitHub Releases を使うと、配布物 (アセットの zip) と、対応するソースコード (タグが指すリポジトリ) を同じ場所に揃えられます。バージョンごとに zip が並ぶため、ユーザーが迷いにくくなります。過去の配布物も残るので、問題が起きたときに前のバージョンへ戻す判断もしやすくなります。
GitHub 用語
| 用語名 | 意味 |
|---|---|
| リポジトリ (repository) | ソースコード置き場 |
| タグ (tag) | バージョン名など、ある時点のコードに付ける目印 |
| リリース (release) | タグに対して配布ページを作り、ファイルを添付する機能 |
| アセット (assets) | リリースに添付するファイル |
Git Bash で GitHub へ push する
まずは、作ったプラグインを GitHub へ push します。push とは、手元のソースコード一式を GitHub のリポジトリへアップロードし、バイナリ (.dll など) のソースを公開できる状態にする操作です。GitHub Releases を使うには、まずソースコードを GitHub リポジトリへ置く必要があります。
GitHub アカウントがない場合は、 GitHub のページ から作成します。すでにある場合は、このまま進めます。
1. GitHub で新規リポジトリを作る
GitHub の画面 から新規リポジトリを作成します。
ここでは、空のリポジトリとして作成します。
- Visibility:
Public - Start with a template:
No template - Add README:
Off - Add .gitignore:
No .gitignore - Add license:
No license
作成できたら、リポジトリのトップページを開きます。次の手順で使うため、SSH の URL を控えておきます。URL は git@github.com:<YOUR_NAME>/<YOUR_REPO>.git の形です。
2. SSH key を作る
GitHub へ安全に接続するために、まず「鍵」を作ります。Git Bash を開き、次を実行します。your-email@example.com は自分のメールアドレスに置き換えます。
ssh-keygen -t ed25519 -C "your-email@example.com"
次のように「どこに保存するか」を聞かれます。ここは何も入力せずに Enter を押します。既定の保存先は ~/.ssh/id_ed25519 です。
Enter file in which to save the key (.../.ssh/id_ed25519):
続いてパスフレーズを聞かれます。本記事では手順を簡単にするため、何も入力せず Enter を 2 回押して進めます。
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
公開配布や継続運用を前提にする場合は、パスフレーズを設定したほうが安全です。
次に、公開鍵をクリップボードへコピーします。
clip < ~/.ssh/id_ed25519.pub
もし clip: command not found のように出る場合は、clip.exe を明示します。
clip.exe < ~/.ssh/id_ed25519.pub
または、次で表示して手動コピーでも構いません。
cat ~/.ssh/id_ed25519.pub
~/.ssh/id_ed25519.pub が公開鍵である一方、 ~/.ssh/id_ed25519 は秘密鍵なので、GitHub やチャット、ブログに貼り付けてはいけません。 貼り付けてよいのは id_ed25519.pub だけです。
3. GitHub へ SSH key を登録する
GitHub の Settings を開き、SSH and GPG keys から New SSH key を選びます。
- Title: 自分の PC が分かる名前
- Key: さきほどコピーした id_ed25519.pub の中身
登録が完了したら、Git Bash へ戻ります。
4. GitHub へ接続できるか確認する
Git Bash で次を実行します。
ssh -T git@github.com
初回は確認のメッセージが出ることがあります。その場合は yes を入力します。成功すると、認証できた旨のメッセージが表示されます。
実行結果の例
The authenticity of host 'github.com (***.***.***.***)' can't be established.
ED25519 key fingerprint is: SHA256:****
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'github.com' (ED25519) to the list of known hosts.
Hi AllegroMoltoV! You've successfully authenticated, but GitHub does not provide shell access.
5. origin を GitHub に向けて push する
ここからは、あなたのプラグインのフォルダーで作業します。前回記事で作った作業フォルダーへ移動してください。
cd /c/Users/AllegroMoltoV/test-plugin
まず、いま設定されているリモートを確認します。
git remote -v
実行結果の例
origin https://github.com/obsproject/obs-plugintemplate.git (fetch)
origin https://github.com/obsproject/obs-plugintemplate.git (push)
例のように、この時点で origin が表示される場合は、origin を GitHub のリポジトリへ向け直します。ここでは、テンプレート側の origin を上書きします。
git remote set-url origin git@github.com:<YOUR_NAME>/<YOUR_REPO>.git
git@github.com:<YOUR_NAME>/<YOUR_REPO>.git の部分には、先ほど控えたリポジトリ URL を入力します。
もし git remote -v の出力が空で、origin がまだない場合は、次を実行します。
git remote add origin git@github.com:<YOUR_NAME>/<YOUR_REPO>.git
次に、現在のブランチ名を確認します。
git branch --show-current
出力が main ではない場合は、ブランチ名を main にそろえます。
git branch -M main
add → commit → push します。
git status
git add -A
git status
git commit -m "Initial commit"
git push -u origin main
1 回目の git status で「何が未保存か」を確認し、git add -A 後の 2 回目で「コミット対象が意図通りか」を確認します。
実行結果の例
Enumerating objects: 1110, done.
Counting objects: 100% (1110/1110), done.
Delta compression using up to 16 threads
Compressing objects: 100% (495/495), done.
Writing objects: 100% (1110/1110), 323.66 KiB | 2.59 MiB/s, done.
Total 1110 (delta 553), reused 1110 (delta 553), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (553/553), done.
To github.com:AllegroMoltoV/obs-test-plugin.git
* [new branch] main -> main
branch 'main' set up to track 'origin/main'.
リポジトリのページでブラウザリロードし、ソースコードが push されたことを確認します。
GitHub Actions の macOS ビルドでは、警告をエラー扱いしているため、ファイル末尾に改行がないだけでも次のようにビルドが失敗することがあります。
no newline at end of file [-Werror,-Wnewline-eof]
この問題は、Windows で編集したファイルが「末尾改行なし」で保存されてしまうと発生しやすいです。再発防止として、リポジトリ直下に .editorconfig を追加し、末尾改行の自動挿入と改行コードの統一 (LF) を強制します。
root = true
[*]
insert_final_newline = true
end_of_line = lf
charset = utf-8
これにより、OS やエディタの違いで改行周りの差分が混ざりにくくなり、macOS CI でのスタイル差によるビルドエラーを避けられます。これでも解決しない場合はファイル末尾に改行を追加しエラーが発生しないことを確認してください。
CI では CMake ファイルのフォーマットチェックに gersemi を使っています。ローカルで整形が済んでいないと CI が失敗するため、事前に gersemi をインストールしてから、整形して push するとよいです。
インストール例 (Python 環境がある場合) :
pip install --user gersemi
整形:
gersemi -i CMakeLists.txt
GitHub Releases で配布する
Web UI で Release を作成し、zip を添付します。リポジトリの Create a new release をクリックします。
Tag: Select Tag > Create new tag を選択してタグを作成します。buildspec.json で設定したバージョン番号とそろっているのが適切なので、今回は v0.1.0 とします。(初めの v は GitHub 側の慣例に従います。)
そのタグを選び、Release を作成します。
生成した zip をアセットとして添付します。
作成した Release を確認し、 zip が DL できることを確認します。
配布前に確認すること
このセクションでは、厳密な法的助言を行いません。判断に迷う場合は、詳しい方へ相談してください。
ソースコードへ到達できる状態にする
OBS Studio のプラグインは、少なくとも libobs に依存します。obs-plugintemplate の説明 では、バイナリを配布するなら、受け取り手がソースコードを入手できる必要があるという前提で説明されています。
身内向け配布でも、後から困らない形にするなら、リポジトリを public にし、GitHub Releases から配布するのが分かりやすい対応です。
同梱物のライセンスを確認する
画像、フォント、シェーダー、外部ライブラリを同梱している場合は、それぞれの配布条件を確認してください。配布に条件がある場合は、リリースノートに著作権表示と入手手段を書いてください。
OBS Studio 側の更新に追従する前提を持つ
OBS Studio は継続的に更新されます。プラグインが追従しない場合、クラッシュが起き、原因の切り分けが難しくなることがあります。
まとめ
本記事では buildspec.json のメタデータを更新し、cmake --install で配布に必要なファイル一式を dist に集め、zip を作りました。また、GitHub へ push し、GitHub Releases に zip を添付して配布する手順を書きました。
次回 は、OBS プラグイン開発で C++ を使えるようにするための環境構築について執筆します。