WebRTC と Rust と 8K 60fps

libwebrtc を Vibe Coding で制御したくて Rust で扱えるようにしてみました。あと 8K 60fps な WebRTC 送信装置を作ったので 8K 60fps やべぇ話です。

Transcript

1. WebRTC と Rust と 8K 60fps tnoho
2. 自己紹介 tnoho なんだかんだでずっとWebRTC 時雨堂の momo や Sora Python SDK の原作者 ずっとメンテしてる時雨堂の皆さん、すごいなーとみている
3. 最近作ったもの • 8K 60fps • ミニPCサイズ • 110W なので。。。 • 8K 30fps / 4K 120fps • お弁当箱サイズ • 60W Type-C PD対応 中身はいつも通り libwebrtc ベースのネイティブアプリケーション
4. お問い合わせは ミサオネットワークまで ご不用品の引き取りもミサオネットワークまでw データ消去の証明書とかも出してくれます
5. libwebrtc + Rust
6. 脱 momo 昨年展示した QIKENC8KP は時雨堂のネイティブ WebRTC クライアントである momo のカスタム でも、 8K や 4K の高画質を扱うと高画質なメインストリームの他に、 プレビューに使える低解像度なサブストリームが欲しくなる しかし、momo は1本しかストリームを扱えない よし、脱 momo だ！ momo
7. C++ つらい WebRTC のライブラリだと一番リッチな libwebrtc を使いたい でも、 C++ は LLM との相性が悪いのでイマイチ。。。 その上ストリームを複数本扱うとなると複雑になるのは確定 せめてもうちょっと LLM が得意な言語で書きたい そうだ！libwebrtc を Rust から扱えるようにしよう！
8. Sora Python SDK で目指したこと Sora Python SDK は自由度の高さとPythonの利便性の両立を狙った • WebRTC の基本構造に忠実なクラス設計 ◦ Sora => PeerConnectionFactory ◦ SoraConnection => PeerConnection ◦ SoraVideoSource => VideoSource • 使う側がリソース管理を意識しないリソースマネージメント ◦ Pythonらしくつかえるように しかし、リソースマネージメントで課題に当たってしまった　 ※解消済みです
9. 起こった問題 Pythonのガベージコレクションが意図した動きをせずに、 デッドロックやメモリーリーク、セグメンテーション違反を引き起こしてしまう ※すでに解消されています Sora ③ SoraConnection ① SoraVideoSource ② AddTrack Sora SoraConnection SoraVideoSource AddTrack ①=>②=>③で消したい Python は最初に消そうとする 先に見るように伝える でも、先に消してくれない デッドロック or 循環参照でメモリーリーク 無理に消すとセグメンテーション違反 実際
10. どう解消したか もちろん、所有権に配慮して実装しているのに発生する どうしようもないので、DisposePublisher と DisposeSubscriber を作った Sora SoraConnection (Subscriber) SoraVideoSource (Publisher) AddTrack Subscribe Publish Dispose 参照解除 これにより、PythonのGCとは独立してリソースマネージメントされる
11. 生まれた負債と得られた教訓 結局Pythonのリファレンスカウンタとは別にリファレンス管理をすることとなり、メンテナ ンスコストが上がってしまった GCは信用できない、GCに依存した言語を使ってはならない C++サイドで親子関係のあるものの所有権管理を C++の外側でやろうとすると同じ問題に当たる可能性がある
12. 実際のリソース管理は C++ 内で完結させる Rust SDK は弱参照を保持するイメージ これでリソースの解放は C++側の都合でできるので、 セグメンテーション違反はなくなる C++とRustのインターフェイスはフラットとし、 親子関係はRustの中で再構築する いずれは解放されるので問題がない Rust SDK でどうしたか Rust SDK C++ ライブラリ libwebrtc Rust クライアント リソース管理
13. これでシグナリングやPeerConnection制御は楽勝！ あとは LLM に任せればいいぜ！ だと、思っていたことが僕にもありました。 Q: WebRTC のシグナリングプロセスを文字だけで説明してください なお、 PeerConnection は 2 本張るものとします。 あー。もう自分でプログラム書いた方が早くね。。。？ でもまぁ、Rustにしたおかげでだいぶ楽になりました。WebSocketとか。
14. 8K 60fps
15. 8K 60fps の撮れるカメラって？ 8K 120fps まで撮れる 業務用のカメラ • 出力は 12G SDI ケーブル x 4 • 一人で持てないくらい重い • 光源が結構必要 ニコンの一眼Zシリーズの HDMIから8K 60fps出て欲しい。。。
16. 8K の高解像度が生きるのは大画面 しかし大画面でフレームレートが低いと フレーム間の画の移動量が大きく感じる 結果的にカクついて見える なので、 8K 放送規格も 60fps ！ 8K 30fps で展示しても 30fps じゃなぁ。。。 って言われる。。。た。。。 なぜ 8K 60fps なのか
17. でも 8K 60fps って…？ エンコーダに入力する 8K の I420 データは 7680 x 4320 x 1.5 byte だから。。。1フレーム 50 MB かぁ。。。 秒間 60 フレームだから。。。50 x 60 = 3000。。。1秒で3GB。。。 1秒で3GB！？ やばい、全然いける気がしない。。。 ※元信号が「12G」 SDI 4 本という時点で察するべき
18. 大体発生するピクセルフォーマット変換 カメラのセンサーやディスプレイの画面はRGBだけど、 伝送レートの都合から伝送はYUVで行われる しかし、このYUVの並び順はそれぞれの都合で違う • libwebrtc の中で扱われるピクセルフォーマットは I420 ◦ Y,U,VがそれぞれまとまっているのでCPUで処理する時に高速 • ハードウェアエンコーダーは大体 NV12 ◦ Y, UV(交互) I420に比べるとメモリ参照が2本で済む • キャプチャーカードは大体 YUY2 ◦ 縦方向の色を混ぜないのでリニアに処理できて映像機器が作りやすい
19. YUY2からNV12にする計算量を想像する 実際にやるのは • Y 取り出して並べるだけ • UV は取り出して 一つしたの行の UV と足して並べる それを 8K 60 fps だと 7680 x 4320 x 3 = 約 20 億...2G…1命令で終わるわけないから CPUだとマルチコアでも、それだけで使い切る。。。
20. Q: じゃあどうするの？ A: 全部ハードウェアでやるんだよ
21. こゆこと キャプチャーカード ハードウェアピクセル変換 ハードウェアエンコード libwebrtc さん 後よろ 解決

22. ほぼほぼフルスクラッチ できあがったもの Rust SDK C++ ライブラリ libwebrtc キャプチャーカード ハードウェア ピクセル変換 ハードウェア エンコーダー Rust クライアント
23. そんなこんなで 結構大変だったんですが 8K 60fps を達成 その技術を横展開するとQIKENC8KP も 安定性が向上 難しいことへのチャレンジは大切 というわけで Vibe Coding での開発が可能な WebRTC Native Client ができました お貸し出しのリクエストは ミサオネットワークさんまで！
24. EOF できあがってみたら、あんまり参考にならない話でごめんなさい🙏 ご不用品の引き取りはミサオネットワークまでw データ消去の証明書とかも出してくれます #PR
25. カメラちゃんと選んでますか？ • 光をちゃんと集めないとノイズまみれになってしまう ◦ 場所もレンズも明るい方が良い ◦ 明るいレンズは大きなレンズ ◦ センサーサイズも大きい方がよい ◦ じゃあ、解像度は？フレームレートは？ • 小さなレンズほど磨くのは難しいし粗の影響が出る ◦ 工学的にはレンズは大きい方が綺麗に写る そのみなさんの手の中にある小さなカメラは、 果たして本当に書かれている解像度の性能がありますか？
26. じゃあ 4K, 8K が綺麗に撮れるカメラって イチオシはニコンの一眼レフ Nikon Z8 / Z9 • HDMI から 4K 120fps / 8K 30fps が出力可 • 量販店で普通に買える • フルサイズの大きなセンサー • ニコンの明るく高精度なレンズ 皆さんが経費で買えるかもしれない一眼レフ！ というか、買ってくれないと機能がなくなっちゃうかも。。。