4KVC00という安いのに YUY2 で 1080p60 出るキャプチャーボードと Splatoon 3 の画像認識をしてみた話
これは mstdn.maud.io Advent Calendar 2022 の19日目の記事です。前日はきーすとさん でした。
今日は AV Access というところが出している 4KVC00 というキャプチャーボードと、それを使って Splatoon 3 の画面を画像認識してみた話です。
約8000円、さらにクーポンが付いていることが多いっぽいのでそれより1000〜2000円ほど安い値段で YUY2 (=YUV422) の 1080p @ 60FPS での録画に対応していると謳っています。
繋いでみた
Macに繋いでみるとこんな感じ。
USB 3.0 には 1E4E:7016 の eEver USB Device、USB 2.0 は 1A40:0101 のハブの下に 040D:340B の USB Audio Device と 1A86:7523 の USB シリアルがあります。
基本的に HDMI キャプチャの映像や音声は 1E4E:7016 の eEver USB Device から UVC / UAC として提供されていて、USB Audio Device というのはおまけで付いているマイク/イヤホン端子のようです。USB シリアルは…何なんでしょうね？ファームウェアの更新とかできるのかな。
HDMI キャプチャ部分
UVC はちゃんと 1920×1080 の YUY2 (YUV422) が 60fps で降ってきているようです。いい話。公式には YUV2と書かれていますが恐らく YUY2 の typo だと思う。
遅延もパススルーで出した画面と比較して (60fpsで) 2〜3フレームほどなので結構良いんじゃないでしょうか。そんなにアクションが激しくないゲームならそのままプレイできそう。
ただし、macOS側の都合なのか何なのか、時と場合によってアプリ単位で遅延が大きく異なる場合があります。OBSは安定して最短+1フレーム遅延で済むっぽい？VSyncがちょっと怪しいですが。 QuickTime Player とAVCaptureVideoPreviewLayerは早い時は早いけど、遅れる時は追加で+5フレーム遅延したりするのであんまり信頼しないほうがいいです…。
ちなみに USB 2.0 で繋ぐと帯域が足りないので MJPEG にフォールバックされますが、MJPEGの画質は本当に終わっているので、ケーブルの相性とかで USB 2.0 に落ちた時に一発でわかって便利です (そうか？)。
|
|
UAC は普通に 48kHz/2ch/16bit が降ってきます。5.1chサラウンドもパススルーは(恐らく)できますが、キャプチャに乗るのは左右の2つ(どっちの左右かはわからない)だけのようです。
ちなみに、macOS いわくなぜか 9MHz のサンプリングレートに対応しているらしいです。どうやったらそうなるの？？
おまけの USB DAC
おまけの USB 2.0 にぶらさがっているほうの USB Audio Device は 48kHz or 44.1kHz で 2ch/16bit です。音質は使ってないから知らない。
互換性
とりあえず M1 Max 上の macOS 13.1 (22C65) で元気に動いています。誰も書いてなかったけど M1 Mac でも安心。
知りたい人がいるかどうかはさておき一応書いておくと、Asahi Linux でも動きました。ちょっと前だったらまだ Asahi Linux にイヤホンジャックのサポートがなかったのでおまけの USB DAC が有効活用できたかもしれないけど、もうサポートされるようになったので役に立つ機会はなさそうですね。
画質の参考にどうぞ。YouTubeに上げる前は Lossless H.264 で保存しているのでキャプボの出力ほぼそのままだけど、結局 YouTube がエンコードしてるのでまあ……。
中身
"eEver USB Device" と出るということはこの名前がチップメーカーなのかな〜と思って調べたらビンゴっぽい感じでした。EJ511あたりかなあ。
と思ったら開けて中見てる人がAmazonのレビュー欄にいました。こっちを見たほうがいいかも。
一部Amazonレビューには Type-C凸凸 ケーブルに A凸→C凹 変換 (規格違反) が付いてやってきたというコメントもありましたが、どうやら最近のロットは最初から Type-A凸 to C凸 が付いてくるようです (逆に言うと Type-C ポートに直接繋ぎたいなら別途変換なり C to C ケーブルが必要です) 。
おまけ: macOS 環境で FFmpeg で録画すると映像や音声が変な飛び方をするやつをどうにかする
FFmpeg の -f avfoundation で録画しようとすると、映像や音声が変な飛び方をするファイルができることがあります。
これはどうやら AVFoundation から FFmpeg が映像や音声を受け取る際にいい加減なバッファリングをしている影響で起こるらしく、チケットとパッチもあるのですが、どういうわけかマージはされていないようです。
とりあえず手元でパッチをマージしたら直ったっぽいので、パッチを適用済みのブランチを置いておきます。ただベースが古いままなことに注意。
https://github.com/rinsuki/FFmpeg/tree/buffered-avfoundation-input
コーデックを全部入れてコンパイルするのはだるいので、
./configure --disable-everything --enable-muxer=matroska --enable-protocol=pipe --enable-indev=avfoundation --disable-programs --enable-ffmpeg --disable-swresample --disable-swscale --disable-doc
あたりでコンパイルして、
./ffmpeg -f avfoundation -r 60 -pix_fmt yuyv422 -i "HDMI:HDMI" -codec copy -hide_banner -loglevel warning -f matroska - | ffmpeg -probesize 50M -i - -vcodec ...
のように完全に映像受け付け君としてだけ使うのが気軽で良いでしょう。まあ映像を受け付けてパイプに流すだけなら FFmpeg よりもうちょっといい方法がある気もしますが…。
Splatoon 3 の画像認識
というわけでキャプボが来て Splatoon 3 の録画ができて良かったね、というところまではいいんですが、とはいえ垂れ流しでずっと録画していてもどこにどのバトルがあるのかわかりづらいので微妙です。
というわけで、画像認識をしていい感じに録画を分割したりしたいね、という話になります (先駆者の IkaLog に憧れがあったのもある)。
基本的に Splatoon 3 の重要な情報は白色で表記されているので、適当にグレスケにした後二値化して、予め用意しておいた画像と比較するととりあえず座標が変わらない物に限ってはいい感じに判定できます (たぶん本当は適当にグレスケに変換して…とかではなくて白かどうかで判定したほうがいい)。
なので、あとは判定したい要素をキャプチャのスクショから切り抜いて判定用の画像を作る…ということをやっていれば、とりあえず stat.ink に投げるためのスクショや録画の開始/停止に必要な情報くらいは取ることができます (どうやら IkaLog3 が開発されているらしいので、それへの繋ぎとしてはこれくらいで十分でしょう)。
判定用の画像を作るツールを何で作るか迷ったのですが、結局 File System Access API を使って Web で書くことにしました。Blink系でしか動かないのがちょっとアレですが…。 オーバーエンジニアリング感あるけど気にしない。
ちなみに本体は s3s を直接呼ぶ都合で Python + OpenCV で書いています。
本体が動いている様子はこちらです。
というわけで画像を認識して stat.ink に各画面のスクリーンショットを投稿するところまではできたんですが、残念ながら stat.ink 側がまだ詳細ページでのSSの表示に対応していないようです…。トップ画面では表示されるので、一応なぜか一人だけ 2022 年にスクショを投稿している人になることはできます。
追記: 今日 (2022/12/19) の朝対応されたようです！ありがとうございます。
あとは録画の制御部分を作って YouTube あたりに無限にアップロードができたらいいなと考えています。
requirements.txt すら書いていない適当な体たらくですが、エスパー力が高い人向けに一応リポジトリも公開してあるので、我こそは！という人は試してみてください。
わたしの stat.ink アカウントはこちら。まだ rinsuki-lab/spl3historydumper から移行してなくてデータがすっからかんですが…。
明日はroutehachiさんです。
