2025年7月4日金曜日

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の停止下での録画 → 解消

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

2025年6月30日月曜日

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への高負荷によって引き起こされている様だよ?」というご意見が提示されており、根本の解決にはなっていない模様。ある日突然起こるようになったのやら、同時配信系全部止めてからやっても発生してるとか、なんなら配信使わずに録画だけ試しても起きるんだけどっていう事象の説明になってないから多分何らかのバグを内包してるものと思われるが。エンコーダ設定弄ってみるかなぁ…

2024年7月8日月曜日

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

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

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

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

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

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

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

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

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

  • 基本的な配信接続は RTMP URL とストリームキーの対が全て。
  • Twitch は RTMP URL が分かりにくい!!!
  • ストリームキーはクリエイターダッシュボードの設定の中の配信に取得枠があるので、ここからぺちって使おう!
  • 配信枠の情報は配信マネージャの下部にあるクイックアクションの「配信情報の編集」からいじれるよ!
  • まず外れ無しでならニコ生上限設定とおんなじでええんちゃうかな。映像5808kbps + 音声192kbps CBRで。( ホントは音声は128kbps上限らしいんだが(軒並み )

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

2024年4月24日水曜日

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

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

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

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

これで事足りる。

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

但し。

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

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

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

2024年4月12日金曜日

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;
}

2022年6月26日日曜日

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 はアップデートしなくても動くので、ここらへんまでのチェックしか公式がしてないって事なんじゃないかな。

2022年6月7日火曜日

INFINITAS 環境と状況

結論:これは検証じゃなくて、備忘録的な何か。

確か 2019 年頃から INFINITAS と立ち環境の構築については検討を始めており、新しく TV を買うこと、テーブルを買う段階から INFINITAS 立ち環境を含めた構成にしようとしていました。

TV : TOSHIBA REGZA 65Z730X
https://archived.regza.com/regza/lineup/spec/65z730x.html

65インチ 4K ( 3840x2160 ) で、1920x1080 なら 120Hz も対応している凄い奴だよ!低遅延モードも捗るよ!

その前から Dead by Daylight もやってたけど、でかい画面でド迫力環境でやりたいなぁと常々考えてこの選択を。全く後悔はしていない。丁度後継の 740X が出始めた頃で 730X の限定処分品だった。

なお 1280x720 で拡張表示をやめると丁度 43 インチほどで表示されるので、アーケードに近い感じが出るのではなかろうかと。これ今後の事を考えても買い直すケースでも 65 インチが最適解なんじゃなかろうか。 43 インチ少なくなってるみたいですし。

TV スタンド : MV901
https://sp-direct.jp/products/detail/?product_id=518

当然高さを変えられる術を用意せねばならん!という中で検討して導き出された唯一解。電動のは高すぎるし調整可能幅などを検討した結果、これがベストだと判断。

デメリットは足部分が無骨ででかい位ですが、どうせメタルラックで避けるし隠すし問題はない。

因みにスタンド上部にカメラなどを取り付けられるパーツまで同梱されていたが HA-HA-HA カメラなんて付けるわけないじゃないか、なーんて付けずに組み立てを完了してしまったあの日の自分を殴りたい。手元カメラぇ…

テーブル : ニトリ 昇降デスク(マーフィー2 120 DBR)
https://www.nitori-net.jp/ec/product/6201500s/

TV をパソコンモニターとして使う、すなわち座って使う事と、立ち環境の両立を検討して、それなりの天板サイズ、高さ調整幅、お値段と相談して選びました。お値段 3 万円という秀逸さ。

メリットはそれなりの重量感、頑丈さ、高さ調整の容易さ、そして何より天板サイズのジャストフィット感。天板の手前両隅にプロコンを配置すると中央部に丁度 10cm 程度の隙間ができるという最適設計。

デメリットは、場所は取る事。ただ快適な環境な分だから仕方がないのではなかろうかと!あと組み立ては二人でやろうね!一人はかなりしんどい。


以下進行状況。

  • 2020/2 ~ 4 : TV やら色々購入
  • 2020/11/17 プロコン申込 / 2021 夏を待ちわびる
  • 2021/6 : 待ちきれなくなりつつ INFINITAS の動作検証をトライアル版で keyboard ポチポチしてお茶を濁す
  • 2021/8 : 夏も終わりかける中、「夏の定義とは!?」と騒ぎ出して数日後、無情にも延期のお知らせが告知
  • 2021/10/29 : 専用コントローラもある内に買わないとと、血迷ってポップンコン購入
  • 2021/11/1 : プロコン宛先確認のお知らせに歓喜 / なお同日発送完了通知に「?」も、ポップンコンの方…
  • 2021/11/12 : プロコン発送完了通知
  • 2021/11/13 : INFINITAS コース加入も keyboard プレイ
  • 2021/11/15 : プロコン到着
  • 2021/11/17 : SP 段位認定 七級 ~ 四段
  • 2021/11/20 : SP 段位認定 五段失敗 DP 段位認定 七級 ~ 六段
  • 2022/4/12 : SP 夏の匂い。キミの残像。(H)初フルコンボ
  • 2022/4/23 : SP 段位認定 五段 六段
  • 2022/5/15 : DP 夏の匂い。キミの残像。(H)初フルコンボ
  • 2022/7/12 : DP 段位認定 七段
  • 2022/8/28 : DP 夏の匂い。キミの残像。(A)ノマゲギリクリア
  • 2022/12/4 : AC(RESIDENT) DP 段位認定 三段 ~ 七段
  • 2023/5/17 : DP 段位認定 八段
  • 2023/8/5 : AC(RESIDENT) DP 段位認定 極七段+八段

ここから今のところ動きがなく、地力上げしてくしかないのかなと。指動かなーい。

LogiTune、おまえかい!

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