PCで人狼ジャッジメントが出ないので

マーダー・ミステリーJはSteam版あるのにね？

突発でAndroidの実環境が欲しくなる。

• 理由：「まとも」に人狼ジャッジメントやりたい。
• 「まとも」とは：文章入力に手間取りたくない＝キーボード環境が欲しい。
• ついで：配信なり動画収録などしたい。

元々Bluestacksを使って人狼ジャッジメントをPCで楽しんでいた勢である。同環境を用いられなくなってかなり経つが、やはりまともに遊べる環境が欲しいな、と。

という訳で家電量販店で見繕うと良いころ加減の辺りで置いてあるのがLavie Tabっていう。そこでT11NやT12Nを比較しつつ悩み、同スペックの他メーカ品どんなやろという所で見つけたのが

 Lenovo Idea Tab Plus

である。更にAmazonでタイムセールの文字、価格は四万円ほど。お試しともあればこの辺りが一番現実解であろうポチ。

 簡易スペック：12.1inch 2560x1600 / MediaTek Dimensity 6400 / 8GB RAM / 256GB Storage

使用感は後述する。さて算段としては、

• scrcpyで実機Androidに接続して映像・音声・キーボード操作をやりとりするよ！

…という想定だったのに、これは脆くも崩れ去る。scrcpyで接続するには

• Android実機側を開発者モードにし、
• USB接続で認識させて接続し、
• その後無線化(Wi-Fi)したいならコマンド使って切替…という流れ

になる。その二番目で躓いた。こいつ、認識しない。

adb(Android Debug Bridge)という機能で接続する訳だが、残念ながら認識されない。要はベンダー公式のadbドライバが必要になる様だが、Lenovoはコイツ用のドライバを提供していないor見つけられる場所に置いてない。詰んだ。なんだこの文鎮。いやまだだ、お風呂視聴でニコ生が見られなくなったiPad Air2の代わりにはなるし無駄にはせんぞー！

という事で、一先ずPCに繋ぐ事はさておいて人狼ジャッジメントを導入してみてレッツプレイ！以下感想。

• クッソ重いわぁ(※)…値段からしたら仕方ないのか？15fps出てるか心配になるレベル。
  (※：後述で評価変わります)
• 因みに開発者向けオプションで画面fpsのオーバーレイ表示をするとでかでかと90と出る。しかしながら実描写は前述のそんなレベルで、負荷状況にかかわらず90の表示は微動だにしない。これ固定で90って出してるだけでは…
• 当たり前ながらスマホとは違うので、デカ画面で直入力は非常に使いづらい。

どうしてくれようこのポンコツ。取り敢えずこの90表示は詐欺じゃなかろうか。まぁとはいえ流石に画面は綺麗。一先ず楽しむ分には良いけれどこれなら別にコイツでやらんでもえぇなぁという結論に。でもせめてキーボード繋いでみたいなぁ…

という所で思い出した。所有しているUSBキーボードは当然Type Aコネクタであるが、このTabletのポートはUSB-Cである。しかしアケ配信向けに仕入れたノートがUSB-Cオンリーだった事もあり、USB-C接続のUSBハブが転がっていた。これにキーボードとマウス繋いだら使えたりしないかなーハハハ…

…使えた。ていうかPCモードってのになった。ここで驚いたのだが

• PCモードでの方が描画がメチャスムーズ。なんだこりゃ。
• ただ難点があり、PCモードだと縦長画面にならない。なのでフル画面では遊べない。ち。
• 一方PCモードはマルチタスクを売りにしてるらしく、隣にメモ帳が置ける。メモ帳の操作感はWindowsのそれとは違うものの、ちゃんとコピペもできる。偉い。

という事で遂に人狼ジャッジメントキーボード環境を得るに至ったのである。ただ、やっぱり抜けはある。

• マウス操作でスワイプが効かないところがある。
  (下部のキャラ一覧の横スライド・ルーム一覧の縦スライド)

せめてタップに絡む部分の操作はマウスで完結できると有難いのだが、何故かできない。なのでその点は直接画面タップでカバーするしかない。

ただキーボードで遊べるというのが何よりのメリットである。良かった。あとはこれを配信に載せられれば一番良いんだが…無理よな…あれ？無理じゃ…ない？

というところで出番となったのがStreamlabs(Android版)である。コイツで画面キャプチャして外部に送信したら良いんじゃねぇの？とはいえコメントやらの事を考えるとOBSに伝送できるのが一番やんなぁ…OBSではメディア ソースって奴で受け取れるのか…な？

となりつつも、StreamlabsはRTMPをpushするタイプで、OBSはRTMPをpullするタイプなので直送・直受信はできない。そこに取り出したりますは古のツール、RTMPRelayerですよ。かつて同時配信の負荷低減に利用されたこの子、上記のRTMPのpush/pullを仲介する役を担えます。偉い偉い。

というわけで、若干のラグはあるもののPC OBSにタブレットの映像が表示でき、PC側でコメント取得・読み上げ等もカバーでき、一先ず最低限の記録はできる様になったという所でして。一段落一段落。あとはもうちょっとまともなタブレットスタンドを拵えないとって話だったりキーマウ別PCからペチってきたのでちゃんと補充品買わないとって事だったりはしますけど、そこら辺はカバーして行きつつお試し&楽しんでカチャカチャッターンしてこかなと。この環境だとごろ寝スマホプレイみたいに凸しないしな！(凸すんな

因みにStreamlabsでのオーディオキャプチャをCamcorderにして伝送して、obs側でRNNoiseかけるとゲーム音が消えるｗ 完全ノイズ扱いであるｗ 本当は生の音がタブレットからで、マイクはPC側でというのが好ましそうだが、試している中ではゲーム音だけ伝送するのが成功していない。何か良い方法があれば…マイクはまたお外配信用に調達したSHOKZ使えば良いわけなんだが…

そんな訳でへっぽこジャッジメント。全敗であるが。時間泥棒である。またその内…

LogiTune、おまえかい！

やっぱりそうやんなぁ、っていう。

前回に引き続き、OBSでの録画終了できない問題です。まことしやかに「GPU負荷高すぎで処理が終われない」とか書いてあるけど、どれだけ負荷下げた設定にしたって、ソース構成をシンプルにしたって駄目だったし。そもそもx264のソフトウェアエンコードにした所で終わって貰えないんですよ。

現時点の最終解：「LogiTuneUpdaterServiceがobs-ffmpeg-mux.exeのファイナライズに干渉してハングアップしている」

対処方法：OBS起動前にLogiTuneUpdaterServiceを停止しておく

参考はこちら：reddit OBSが「録画を停止中」に固まっています

( https://www.reddit.com/r/obs/comments/tyqp4q/obs_stuck_on_stopping_recording/?tl=ja )

Update Serviceを無効化するのも手ではあるけれど、更新されないのもどうかとは思います。ただ頻度的には更新がそんなにありませんし、OBS起動してる時に動いててもらう必要は皆無かと。

という事で、自分はどちらにしろOBSを絡めたツール起動はバッチファイルにまとめているので、その先頭で「net stop "LogiTuneUpdaterService"」を記載する事で対処しました。この辺り開発が掘り下げてくれるのかどうか。

やった事一覧

• 録画エンコーダ制御変更 ( CBR / CQ / VBR / ビットレート下げ ) → 駄目
• 録画エンコーダ切替 ( HEVC / H264 / x264 ) → 駄目
• OBSのバージョンダウン ( 31.0.3 / 31.0.2 / 31.0.1 / 31.0.0 / 30.2.3 ) → 駄目
• NVIDIAの最新ドライバへの更新 → 駄目
• Elgato HD60Xのソースからの除去 → 解消、ただ実用不能(キャプチャ前提)
• LogiTuneUpdaterServiceの停止下での録画 → 解消

これで録画データ修復作業から解消される…

OBSでの録画、やっぱりMKVの方が良くね？っていう

先に結論から書く。

• 録画ファイルの形式は Matroska Video (.mkv) にしよう
• コイツならファイナライズミスってるファイルも VLC media player で修復できるよ

経緯

少し前から、OBSでの録画が、録画終了処理において絶対にハングアップする様になった。

最終的な対処としては、録画を担っているプログラム「obs-ffmpeg-mux.exe」を強制終了する事によって、OBS本体は支障なく終了する。あくまでハングアップしているのは前述の録画プログラムであって、OBSはそのプログラムの終了を待機しているだけだ。一応 Windows におけるプログラム強制終了コマンドである所の taskkill で当該プロセスを殺すバッチファイルを作っておくと都度手打ちするよりはナンボかマシである。「taskkill /F /IM obs-ffmpeg-mux.exe」と唱えるが良い。

めでたしめでたし、ではない。

当然、正規の方法で終了した録画ではない故に、ファイナライズ処理が行われずに保存された録画ファイルは破損している。ファイルの種類によっては正常に見ることは適わない。基本的に対応するのは Matroska Video(.mkv) か Fragmented MP4(.mp4) になる。(オススメされているのは後者である。)

但し。

この二つのファイルにおいてもファイナライズは行われていないので、再生において若干支障となる。ファイル再生に必要な情報が恐らくファイル終端に記録される形式であろうが、それが無い為に、ファイル内をシークして補間して再生する模様。録画時間によってはロードがかなり待たされる。再生が始まった後も、ジャンプするとかなり映像が乱れる。いうて恐らくキーフレームが来るまでの我慢であるが。

修復

正常な録画ファイルに戻す方法はあるのか？

という事において、mkv であれば VLC Player で正常に戻すことができる。

メニューバーのメディア - 変換/保存 を選び、対象ファイルを選択した上で画面下部の変換/保存を押す。

変換のプロファイルは追加しておくと良い。

カプセル化は MKV にし、ビデオコーデックもオーディオコーデックも「オリジナルの～～トラックを保持」とする。自分は分かりやすい様に「MKV repair」とプロファイル名を指定した。

後は出力ファイルパスを指定して開始するだけである。便利。

では Fragmented MP4 では？というと、残念ながら同じ方法では無理である。なんでやねんと。

変換作業が最終盤に差し掛かったまま動かなくなる。嫌なことにタスクマネージャなどで動作を見てみると頑張ってファイルに書いている(ディスク書込量がそこそこある)にも関わらず、全く進まなくなる。一体何を書いているのだろうか。

結論から言えば、MP4 の修復においては Aviutl を使うのが良い。実際には順当に導入していれば、プラグイン「L-SMASH Works File Reader」を導入しているであろうから、これ経由で読み込んだ後、メニューのファイル - エクスポート - L-SMASH Works Muxerから書き出せば良い。紹介のページではAviutlへの対象ファイルの読み込みがドラッグ＆ドロップでは駄目、とか書いてあるが、そんな事は無かった。気になる人は修復対象のファイルを開いた後にメニューのその他 - ファイルの情報 で表示されるファイル情報一覧でファイル制御がL-SMASH Works File Readerになっている事を確認してから作業したら良い。

とはいえ、皆が皆 Aviutl を導入しているかと言えばそうではなく、導入の簡単さから言えば VLC media player の方が簡単ではあろうと。そう考えるならば録画形式はMKVにしておいた方が楽なんではなかろうか。

なおOBSを導入して録画なんてしてるの配信者率高ぇだろAviutl入ってるに決まってんだろ的なご意見の持ち主はFragmented MP4にしても全く問題ないと思われる。

そもそも

ただ、事の発端から言うなら、なんで obs-ffmpeg-mux.exe がハングアップすんねん、という所から来ているのだが、一応は「どうもGPUへの高負荷によって引き起こされている様だよ？」というご意見が提示されており、根本の解決にはなっていない模様。ある日突然起こるようになったのやら、同時配信系全部止めてからやっても発生してるとか、なんなら配信使わずに録画だけ試しても起きるんだけどっていう事象の説明になってないから多分何らかのバグを内包してるものと思われるが。エンコーダ設定弄ってみるかなぁ…

Twitchはニコ生である(相当語弊のあるアレ

ニコ生が使えなくなり、新型コロナに罹患したり、回復後に仕事に追われたりと色々してたら相当に間が空いていた次第なのですが、その前の時点でもちょっと気になってた事が。

Twitchで配信するの、多分楽だよね？さくっとやってみっか！
→ 巧く映らないんですけどおおお！！！？

という事だったんですが、結論としては簡単でした！

こないだの三月に経験したニコ生での現象と同じく、TwitchさんはHEVCを飲まないです。

現象としては「通信はし始める」「ずっとオフライン」「転送データが途中で途切れる」「再接続してる」というもの。
大人しく H.264 を使え！以上！

という事で(２回目)、配信サイトにおける接続検証はこんな感じかな。

• 最初はエンコーダを H.264 にして試してみよう！巧く動いてから HEVC を試してみたら？ダメなら戻そう。
• ビットレートは低めで確認してから、望むレベルまで上げて繋いでみよう！ダメなら戻そう。
  ( 一応検索すると Twitch のビットレート上限は 6000kbps という記述がひっかかるので、それより下から攻めてみて )
• ビットレート制御もチョー基本的な CBR をまず試そう！その後にやってみたければ VBR にしてみたら？ダメなら戻そう。

という辺り。Twitchに置いてはこんな感じか。

• 基本的な配信接続は RTMP URL とストリームキーの対が全て。
• Twitch は RTMP URL が分かりにくい！！！
  • よく接続設定サイトに書いてある「rtmp://live-tyo.twitch.tv/app/」で一応は大丈夫。
  • Twitch公式での記述は辿り着きにくいけれど「Twitchストリームキーに関するよくある質問」https://help.twitch.tv/s/article/twitch-stream-key-faq?language=ja に記述あり。
    下部に「RTMPとは何ですか？」という記述があり、ここに指定できるサーバurlへのリンクがある。これを辿り着きやすくしてくれんかのう！？ Twitchにおいてはインジェストサーバという名称 ( TWITCH-INGEST-SERVER ) で、これらを一覧にして掲載しているのが「推奨されるインジェストエンドポイント」 https://help.twitch.tv/s/twitch-ingest-recommendation です。この中で恐らく近めの、空いていそうなサーバを選んで記述するのが良いよ！
• ストリームキーはクリエイターダッシュボードの設定の中の配信に取得枠があるので、ここからぺちって使おう！
• 配信枠の情報は配信マネージャの下部にあるクイックアクションの「配信情報の編集」からいじれるよ！
• まず外れ無しでならニコ生上限設定とおんなじでええんちゃうかな。映像5808kbps + 音声192kbps CBRで。( ホントは音声は128kbps上限らしいんだが(軒並み )

Twitchは多分提携配信ツールが多くて、配信設定部にTwitch用設定が用意されてるからRTMP URLを意識する必要が普段はないんだろうねと。ただ obs-multi-rtmp なんかの同時配信機能だったり、原始的な配信機構だったりと、そっち向けにも記述がもう少し引っ張りやすい位置にあってくれると助かるやぁつ…

INFINITASをWASAPI排他で配信したい場合のコスト低減方法

なんだかんだ言って音ズレが発生してる環境はWASAPI共有モードでプレイしてる事が多い。 でも排他にしたら普通には配信できないじゃん！と諦めてる人もいるっぽい。

そんなわけで、一番手っ取り早いのは

• 出してきた音をアナログ的に２分配 / 500円
• 片方を外部スピーカーに突っ込む / お好みで
• もう片方をPCのラインインに突っ込む / 6～700円
• OBSでラインインをキャプチャ

これで事足りる。

• 分配：https://www.amazon.co.jp/dp/B01AEK8GSI
• ケーブル：https://www.amazon.co.jp/dp/B00NO73Q84
• ケーブル：https://www.amazon.co.jp/dp/B0B7J6M1VC

ただ、コメント読み上げは「音声出力デバイスがブロックされてるから流せない」ので、「別の出力デバイスが必要」。

但し。

例えば表示してるディスプレイがHDMI接続でスピーカー付きなら、それがそもそも「別の出力デバイス」である。 その画面から読み上げが流れれば良いなら読み上げの出力先をそちらに向ければ良し。

ただ、ヘッドホン・イヤホンでプレイしてて、どうしてもゲーム音と読み上げを同系統で聞きたいならミキシングする機器が必要になる。 ここは何か安い方法あるかな…

配信に読み上げが流れて、自分は別に目視するから聞こえなくて良い、のなら先の様に別デバイスがあれば良い。
例えばこういうの。(下記参照)
ただアナログ端子側を結線しないと認識しない可能性はあるので注意。
認識したなら出力デバイスに指定できるしOBSもキャプチャできるので、配信に読み上げを載せるのだけなら事足りる。

• USBオーディオ変換コネクタ：https://www.amazon.co.jp/dp/B01N41607I
• USBオーディオ変換コネクタ：https://www.amazon.co.jp/dp/B06XZY8JTZ

ChromeでSNSをウィンドウサイズ固定で別ウィンドウで開きたい

という要望を持ったのだが。

• --window-position, --window-size などのコマンドラインオプションがまともに作用しない。
• JavaScript指定して調整する方法があるも、windowの体裁が変になる。
• プロファイルを別に指定するとオプションが効く風でもあるが、プロファイルが変わるとログインが面倒。

ということで、標準的な手順を断念。新規に起動したらいんじゃね？という事に。 Win32API の CreateProcess で chrome 直撃したらウィンドウが別に開いた。嬉しい。 悲報：CreateProcess の引数に渡す STARTUPINFO 構造体の座標・サイズ情報は有効に作用しない！ という訳で、新規に開いたウィンドウを自前で探索して移動してやろう！ やり方としてはもっとスマートな方法があるのやもしれんが、一先ずこれで。

1. その時点で開いているChromeのウィンドウのhWndを記録しておく。
2. CreateProcessでChromeを--new-windowオプションとURLを指定して開く。
3. ちょっと待機する。（即時にはウィンドウが開かない）
4. 再度ウィンドウを探索し、先に記録しておいたものと突合し、合致しないのが居たらそいつがルパン。
5. 対象ウィンドウをMoveWindowでお好きな位置に。

汎用性を持たせた書き方をしたいんだけどパラメータを設定ファイルに持たせるのが賢いのかな…全指定はきちゃない気がする。 一応これで動くよってサンプルはこんなところ。

#include <iostream>
#include <tchar.h>
#include <windows.h>
#include <list>

const TCHAR CHROME_PATH[] = _T( "C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe" );

struct TFindData {
	std::list<HWND> chromeWnds;
	bool bFound;
};

bool isChromeWindow( HWND hWnd, DWORD& dwProcessId ) {
	bool bResult = false;
	dwProcessId = 0;
	DWORD dwThreadId = GetWindowThreadProcessId( hWnd, &dwProcessId );

	HANDLE hProcess = OpenProcess( PROCESS_QUERY_LIMITED_INFORMATION, FALSE, dwProcessId );
	if ( hProcess ) {
		TCHAR buf[ MAX_PATH ] = {};
		DWORD dwBufLength = MAX_PATH - 1;
		if ( QueryFullProcessImageName( hProcess, 0, buf, &dwBufLength ) ) {
			if ( !lstrcmpi( CHROME_PATH, buf ) ) {
				bResult = true;
			}
		}
		CloseHandle( hProcess );
	}
	return bResult;
}

BOOL CALLBACK EnumChromeWndProc( HWND hWnd, LPARAM lParam ) {
	TFindData* pData = reinterpret_cast< TFindData* >( lParam );

	DWORD dwProcessId = 0;

	if ( isChromeWindow( hWnd, dwProcessId ) ) {
		pData->chromeWnds.push_back( hWnd );
	}
	return TRUE;
}

void MoveChromeWnd( HWND hWnd ) {
	MoveWindow( hWnd, 4380, 0, 740, 1440, TRUE );
}

BOOL CALLBACK MoveNewChromeWnd( HWND hWnd, LPARAM lParam ) {
	TFindData* pData = reinterpret_cast< TFindData* >( lParam );
	DWORD dwProcessId = 0;
	if ( isChromeWindow( hWnd, dwProcessId ) ) {
		for ( std::list<HWND>::iterator it = pData->chromeWnds.begin(); it != pData->chromeWnds.end(); it++ ) {
			if ( *it == hWnd ) {
				return TRUE;
			}
		}
		MoveChromeWnd( hWnd );
		pData->bFound = true;
		return FALSE;
	}
	return TRUE;
}

int _tmain( int argc, TCHAR* argv[] ) {
	setlocale( LC_ALL, "JAPANESE" );

	TFindData data;
	data.bFound = false;
	BOOL bResult = FALSE;

	bResult = EnumWindows( EnumChromeWndProc, reinterpret_cast< LPARAM >( &data ) );

	STARTUPINFO si = {};
	si.cb = sizeof( si );
	PROCESS_INFORMATION pi = {};
	TCHAR OPEN_TWITTER[] = _T( "\"C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe\" --new-window \"https://twitter.com/home\" \"https://bsky.app/\"\0\0" );
	bResult = CreateProcess( NULL, OPEN_TWITTER, NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi );
	if ( !bResult ) {
		return 0;
	}
	data.bFound = false;
	for ( int i = 0; i < 5; i++ ) {
		Sleep( 200 );
		bResult = EnumWindows( MoveNewChromeWnd, reinterpret_cast< LPARAM >( &data ) );
		if ( !bResult ) {
			break;
		}
		if ( data.bFound ) {
			break;
		}
		Sleep( 300 );
	}

	CloseHandle( pi.hThread );
	CloseHandle( pi.hProcess );
	return 0;
}

WOL の設定は環境整えてからやろうな

結論：ドライバは最新にしなさい

MeLE Quieter2Q というミニ PC を調達したのですよ。

発売当初は Windows 10 であった模様ですが、今では残念ながら(？) Windows 11 のモデルしか希望の構成がない…ので初 Windows 11 としゃれ込みました。

希望として WOL ( Wake On LAN ) があり、対応しているとの事だったので調達した次第。もうお分かりの通り…

S5 からの WOL が利かない

色んなページを検索してヒットするのですが、全然ダメでした。レジストリまでいじったよ。

この機種、そういう意味では優秀で、基本的な設定はしてあります。

• BIOS で WOL が ON になっている
• Realtek 系 NIC でレジストリの S5Wakeup みたいな設定が ON になっている
• 高速スタートアップの設定がそもそもない

なので殆ど確認をしていく、又は枝葉の設定を追加していったのですが全く改善せず。

Windows 11 用のドライバを入れ直して、基本設定をし直して事なきを得ました。 I got the KOTONAKI.

多分必要設定。

• ドライバを更新してインストール
• デバイスのプロパティを開いて詳細設定
  • ウェイク・オン・マジックパケット：有効
  • ウェイク・オン・パターンマッチ：有効
  • WOLとシャットダウンリンク速度：10Mbps
  • グリーンイーサネット：無効
  • 省電力型イーサネット(EEE)：無効
• デバイスのプロパティを開いて電源の管理
  • 全部のチェックを入れる
  • 電力の節約のために、～
  • このデバイスで、コンピューターのスタンバイ状態を～
  • Magic Packet でのみ、コンピューターのスタンバイ状態を～

恐らく利いているのはグリーンイーサネットやら省電力型イーサネット辺りで、何故かと言えばドライバ更新前にあった同設定について Disable に設定しても WOL が正常に動作しなかったのに、ドライバアップデート後にこの設定が有効になっていたから。ちゃんと反映できていないという事じゃなかろうか。

これで magic packet 投げ込めばちゃんと動きます。

なお S5 じゃない状態での WOL はアップデートしなくても動くので、ここらへんまでのチェックしか公式がしてないって事なんじゃないかな。