画面録画用にOBSの設定をいろいろ考えてみた

画面録画用にOBSの設定をいろいろ考えてみた
夏だね。大学の帰りに切ったシャッター

専業のYouTubeになるつもりなんてないのだが、それでもたまに画面を録画したいときってものがある。

定番だが、OBS Studioを使って録画している。

しかし、映像というものもなかなか進歩が速いうえに、謎の技術の詰め合わせでやたらと複雑で理解していてもすぐに忘れてしまうし、陳腐になってしまう。

一昔前まではFHDでいいと思っていたのに、いまやスマホでさえも4Kだ。実際に4Kのコンテンツを再生する場面があるかはさておき、FHD以上の解像度も検討しようかなと思ってくる。

OBS Studioの設定から、「出力」タブに移動し、「出力モード」を「詳細」に変更して、設定をいじくりまわしてみよう。

本稿の目的はこの「出力」タブの「録画」設定だけだから、他の一般的な設定は何にも触れないぞ!

ちなみに僕の使い方だが画面を録画して、あとで見直す用に使う感じだ。配信ではなく録画なうえ、ゲームなどを遊びながらという感じでもない。画質・音質重視で、ファイルサイズなんかは小さくしたいけれど互換性は大事にしたいなあという感じ。

とりあえず、録画設定から

「録画設定」をいじることから始めよう。

種別

そのまえに。

「種別」は「標準」でいいだろう。FFmpegを使ってもいいし、なんならOBS Studioは内部的にFFmpegを使っているのでニッチな設定をいじりたい人用の選択肢だ。別にオーソドックスな感じでいいので「標準」でいい。

録画設定

録画ファイルのパスは本当に適当でいいだろう。私はビデオフォルダーに保存してくれればいいので「 C:\\Users\\livec\\Videos 」としている。

  • スペースなしのファイル名を生成する

という任意の機能があるが、まあ別に好きにすればいいだろう。動画ファイルを処理するプログラムを書いたりする人は、ファイル名を二重引用符””で囲まなくていいというちょっとした楽ができるぐらいのメリットだろうか?あまりよくわからないが、たんに録画をするだけのユーザーからしたら正直どうでもいいだろう。

コマンドラインツールを使ったりする人なんかはチェックをしておけばいいだろう

録画フォーマット

Hybird MP4

  • Flash Video (.flv)
  • Matroska Video (.mkv)
  • MPEG-4 (mp4)
  • QuickTime (.mov)
  • Hybrid MP4 [ベータ版](.mp4)
  • Fragmented MP4 (.mp4)
  • Fragmented MOV (.mov)
  • MPEG-TS (.ts)
  • HLS (.m3u8 + .ts)

自分が再生できればそれでいい人は、自分の再生できるフォーマットを好きに選んでいい。

他の人も再生するし、自分も特殊なツールなしに、というか普通に使える動画ファイルが欲しいなって人はMP4を選択するのがいいと思う。問題はMP4にもいくつか種類があることだ。

途中でOBS Studioがクラッシュして数時間の録画ファイルがぶっ壊れることがある。

いままでのMP4なら録画ファイルがぶっ壊れてなにも再生できないわけだが、Fragmented MP4ならMP4のなかで細かく録画ファイルを分けてくれる。最後にクラッシュした録画データが壊れるだけで、それまでの録画データは再生できるというわけ。

「おー、すごい!」となるのだが、Fragmented MP4はあんまり普及していないので、再生できる方がレア。

ということで、Hybrid MP4が生まれた。

中身はFragmented MP4なのだが、外のハコは普通のMP4。普通のMP4扱いなので、互換性抜群。基本的にどこでも再生できるが、試験機能なので未知のエラーがあってもごめんという感じ。

まあ、Hybrid MP4でいいよね。

映像エンコーダ

NVIDIA HEVC

RTX 40シリーズGPUの場合はHardware (NVENC, AV1)を、そうでなければHardware (NVENC, HEVC)を選択でよし!

エンコード設定はCQVBRにして目標品質20でプリセットもP6: Slowerにして画質をよくしたいなあって。

チューニングも高画質にしてる。

選べる映像エンコーダーはこれ。

  • AMD HW H.264(AVC)
  • AMD HW H.265(HEVC)
  • AOM AV1
  • NVIDIA H.264
  • NVIDIA HEVC
  • SVT-AV1
  • x264

エンコーダーの解説

  • x264 スタンダードだけど、古いし、わかりやすく画質が悪い。選びたくない。
  • NVIDIA HEVC(H.265) Nvidia GPUに搭載されているNVEncエンコーダーです。NVIDIAは何世代にもわたってハードウェアエンコーダーを改良しており、RTXシリーズのエンコーダーは優秀。特にHEVCエンコーダーは、同世代のAMDよりも画質が良い(といううわさ)。
  • AMD HW H.265(HEVC) AMDのVCEエンコーダーです。My LaptopにはRyzen 7 5800Hが搭載されているけれども、CPUについてる統合GPU(Radeon Graphics)で使用可能。しかし、一般的にNVIDIAのエンコーダーの方が画質面で優秀とされているので、ナシかな。
  • AV1 AV1は比較的新しい映像コーデックで、H.265よりもさらに高い圧縮効率を持つ。同じ画質でファイルサイズを30-50%削減できる可能性がある(が、今のところ耐えられないほど遅い)。
    • AOM AV1 Alliance for Open Mediaが開発したリファレンス実装です。AOMは、Google、Netflix、Amazon、Appleなどが参加する業界団体の略称です。高画質だが、エンコード速度が非常に遅いのが特徴。画質は最高クラスだが、エンコード速度が遅すぎてリアルタイム録画には不向き。基本的には事後エンコード専用と考えてください。実際YouTubeなんかもトランスコードに使ってるし。
    • SVT-AV1 Intel(とNetflix)が開発したAV1エンコーダー。SVTは「Scalable Video Technology」の略。AOM AV1よりも高速でありながら、画質もそれなりに良いバランス型。AV1に興味があるなら、SVT-AV1を試してみる価値がありますね。ファイルサイズの削減効果は確実にある一方で、エンコード速度がリアルタイム録画に追いつくかは、実際に試してみないとわからない。それに、古い再生機器では再生できない可能性があることだけご注意。

音声エンコーダ

FFmpeg Opus

  • FFmpeg AAC
  • FFmpeg ALAC (24bit)
  • FFmpeg FLAC(16bit)
  • FFmpeg Opus
  • FFmpeg PCM(16bit)
  • FFmpeg PCM(24bit)
  • FFmpeg PCM(32bit float)

FFmpeg Opus一択。普通にブラウザで再生できるから互換性の問題はなし!

極端な低ビットレートにしないし、極限的な高音質を求めるわけではないつもりだが、それ抜きでも、FFmpeg Opusを選んだほうがいい。

避けるべき選択肢はPCMとFLAC系のデータ損失ゼロ系のやつ。非圧縮にする意味がないし、可逆圧縮でも過剰。1時間の録画で600MB以上の音声データになり、メリットに対してコストが高すぎる。そもそも可逆圧縮の恩恵を受けるためには、非常に高品質な録音環境と再生環境が必要で、一般的な録画用途では違いを実感することは困難。

最悪FFmpegでAACに変換すればオッケー。

エンコーダ設定

レート制御

目標品質による可変ビットレート(CQVBR)

Nvidiaによる推奨はCQR(Constant Quality Rate)かVBR(Variable Bitrate)だけれども、外質を重視しつつもファイル容量を気にしたいのでCQVBRを選びます。

目標品質

20

最大ビットレート

250000 Kbps

2K解像度で録画するので、こんなもん。その代わりフレームレートは23.976(つまり24フレームでドロップフレームあり)にして気休め程度にデータ量を抑えてます。

キーフレーム間隔

0 s

0 = 自動なので、キーフレームは自動でよろしくということ。

プリセット

PS5: Slow (高画質)

チューニング

高品質

マルチパスモード

2パス(1/4解像度)

  • 1パス
  • 2パス(1/4解像度)
  • 2パス(フル解像度)

ざっくりいえば、ビットレートの配分を決める方法の話。

1パスエンコーディングは、本を最初から最後まで一度だけ読みながら、その場その場で重要度を判断していく感じです。次に何が来るか分からないので、最適な判断ができない場合があります。 2パスエンコーディングは、まず本全体をざっと読んで全体の構造や重要な部分を把握してから、もう一度詳しく読み直す感じです。全体を知っているので、より適切にリソースを配分できます。

1/4解像度とフル解像度は分析に使う解像度の違い。

1/4はまず映像を4分の1の解像度(例:1920x1080 → 480x270)に縮小して高速で全体を分析する。フル解像度は文字通りフル解像度で詳細な分析を行うことで、最も正確な統計データが得られますが、処理時間が大幅に増加します。

ビットレートが画質を決定するので、フル解像度で2パスにするのが理想だけれども、読書だって何回もするのはめんどくさいし、時間が足りないこともある。

無難にデフォルトの2パス(1/4解像度)でいいかと。

リアルタイム配信ならまよわず1パスでOK。

プロファイル

main

  • main10
  • main

普通はmainでOK。HDRで録画したいならmain10で。そもそもRTX 40シリーズのGPUを使っているならAV1エンコーダを使っていると思うが、その場合そもそもmainしか選べないハズ。

  • Look-ahead(オン)
  • 適応量子化(オン)

いろいろなブログで書かれているが、このLook-aheadの説明が意味不明。

OBSのLook-ahead機能は本当にいらない子なのか?|ulosto123
ネットでOBSのオススメ設定を調べてみると、必ずと言っていいほど「Look-aheadはONにするな」と書いています。 その理由はと言いますと「動きの少ない場面ではいいけれど、動きの激しい場面では画質が下がる」とのこと。 それは本当なのでしょうか? 本当にそれほどにダメな機能なんでしょうか? ということで、実際にOBSでの説明を読んでいきます↓ 『動的Bフレームを有効にします。有効にした場合、GPU使用率の増加を犠牲にして最大数まで、必要な分だけ多くのBフレームを使用することで視覚的品質を向上させます。』 英語だとこう↓ ↑有効にすると、GPUの使用率が高くなる代わりに、
OBS StudioのLook-aheadに関する日本語の説明は間違っている - Photo Cafeteria
どうしても納得がいきません。 下はOBS studioのLook-aheadに関する説明なのですが、この記述は

いちおうNvidiaの説明もあるので、そっちを参考にしてみよう。

NVIDIA NVENC Obs Guide
Configure OBS to get the most quality out of your stream.

Look-aheadの記述がある部分を抜き出すとこう。

Look-ahead: Checked. This allows the encoder to dynamically select the number of B-Frames, between 0 and the number of B-Frames you specify. B-frames are great because they increase image quality, but they consume a lot of your available bitrate, so they reduce quality on high motion content. Look-ahead enables the best of both worlds. This feature is CUDA accelerated; toggle this off if your GPU utilization is high to ensure a smooth stream.
Max B-Frames: Set to 4. If you uncheck the Look-ahead option, reduce this to 2 B-Frames.

それぞれ訳してみるとこんな感じ。

Look-ahead(先読み): チェック済み。この機能により、エンコーダーは0から指定したBフレーム数の間で、Bフレームの数を動的に選択できます。Bフレームは画質を向上させる優れた機能ですが、利用可能なビットレートを多く消費するため、動きの激しいコンテンツでは逆に画質を低下させてしまいます。Look-ahead機能を使えば、両方の利点を活かすことができます。この機能はCUDAアクセラレーションに対応しています。GPUの使用率が高い場合は、スムーズな配信を確保するためにこの機能をオフにしてください。
最大Bフレーム数: 4に設定。Look-aheadオプションのチェックを外す場合は、これを2 Bフレームに減らしてください。

Bフレームの動作を簡単に図解すると、こんな感じ。

通常のフレーム順序

I → P → P → P → I
(Iフレーム:完全な画像、Pフレーム:前フレームからの差分)

Bフレームを使った場合

I → B → B → P → B → B → I
(Bフレーム:前後のフレームから予測して圧縮)

動きが激しい場面では効果がある感じですね。

  • Look-aheadがON → 自動的にBフレームを減らす
  • Look-aheadがOFF → 常に指定数のBフレームを使用(画質が落ちる可能性)

適応量子化についての説明もしておこう。

Nvidiaの説明はこんな感じ。

Psycho Visual Tuning: Checked. This enables the Rate Distortion Optimization in the encoder, which greatly optimizes the way you use bitrate, improving image quality on movement.

Bフレーム

Bフレームの説明をするにはちょこっと前知識が必要。

  • Iフレーム(キーフレーム) 完全な画像情報を持つフレーム
  • Pフレーム 前のフレームとの差分情報のみを持つフレーム
  • Bフレーム 前後両方のフレームを参照して作られる双方向予測フレーム

ここの設定をいじることで、連続するBフレームの最大数を設定することができる。数値を上げる(3〜4程度)ことで得られるメリットはこんな感じ。

  • さらに高い圧縮効率
  • より滑らかな動きの表現

一方でデメリットはこんな感じ。

  • エンコード負荷の大幅増加
  • メモリ使用量の増大

再生するときに、カクカクしてしまう原因になってしまうので、まああんまりいじらない方がいい。

結論だが、デフォルトの2のままでいい。

Bフレームを参照

「Bフレームを参照」設定は、エンコード時にBフレーム同士が互いを参照できるかどうかを決める設定。

基本的な仕組みから

Bフレームの参照パターンを理解するために、まず典型的なフレーム構造からみてみよう。

I - B - B - P - B - B - P

Bフレームがある場合、BフレームがIフレームやPフレームだけでなく、ほかのBフレームも参照できるかどうかでBフレームの予測精度が上がるよねって話。

3つの設定の違い

  1. 無効 各Bフレームは、IフレームとPフレームのみを参照。Bフレーム同士は互いを参照ない。最もシンプルで負荷もない方式。メリットは処理負荷が最も軽く、互換性も高いこと。古いハードウェアでも確実に動作し、エンコード時間も最短。デメリットは圧縮効率が劣るので、同じ品質を得るためにはファイルサイズが大きくなってしまうことになる。配信メインで低遅延を重視する場合や、古いハードウェアでの録画で使う感じ。
  2. それぞれ 各Bフレームが、ほかのすべてのBフレームを自由に参照可能。最も柔軟で高効率な圧縮が可能だけれども、計算もむちゃくちゃ複雑になって負荷が爆増。メリットは圧縮効率が最高で、同じファイルサイズでより高品質な映像を得られる(言い方を変えれば小さなファイルサイズで高画質な映像が手に入ること)。特に動きの複雑なシーンや長時間の録画で効果を発揮。デメリットは処理負荷が最も重く、エンコード時間が長くなること。高品質な録画を重視し、十分なハードウェア性能を用意して使う項目。
  3. 中央のBフレームのみ いいとこどりというかわるいとこどりというか、間をとった項目。連続するBフレームのグループの中で、中央に位置するBフレームのみがほかのBフレームを参照できるという制限的なアプローチ。中立的に言えば、「それぞれ」と「無効」の中間的な性能を狙った設定。メリットは「無効」よりも高い圧縮効率を得ながら、「それぞれ」ほど負荷をかけずに済むこと。バランス型の設定とも言える。デメリットは中途半端になりがちで、明確な利点が見えにくいこと。品質と負荷のバランスを取りたい、悪く言えばあんまり使う意味のない設定かもです。

負荷について具体的に

負荷の違いは、プロセス占有率で言えば「無効」を100%とすると、「中央のBフレームのみ」が120-130%、「それぞれ」が150-200%程度の印象です。

古いパソコン、例えば5年以上前のCore i5やGTX 1050クラスだと「それぞれ」設定では録画中にフレームドロップが発生する可能性があります。しかし「軽微」というよりは「明確に重くなる」レベルの差はあります。

カスタムエンコーダオプション

空欄でOK!


これでおっけー、たぶん。

いやあ、動画系の設定って大変だし謎すぎる。少しでも「分かった!」が増えてくれると嬉しいな。おつかれさん

Read more

TailscaleのSubnet Routesを消す

SynologyのNASにTailscaleを導入し、便利に使っている。 TailscaleにはSubnet routersという機能がある。 これは、Tailscaleネットワークに接続されたデバイスが、そのデバイスが接続されているローカルネットワーク(サブネット)全体へのアクセスを他のTailscaleデバイスに提供できる機能だ。つまり、Subnet routerとして設定されたデバイスを経由することで、Tailscaleネットワーク上の他のデバイスから、そのローカルネットワーク内の機器にアクセスできるようになる。 Subnet routers · Tailscale DocsUse subnet routers to give devices outside your local network access to services within specific subnets. Extend your private network with Tailscale.Tailscale 便利そうだなと思って設定をしてみたものの、結局使うことがなかった。 公式ドキュメント

By Sakashita Yasunobu

Boids

群れに指揮者はいない 鳥の群れは、誰かが指示を出しているわけではない。魚の群れも同じ。それぞれが周囲を見て、少しだけ動く。その繰り返しが、全体として秩序ある動きを生む。 これを1986年にCraig Reynoldsがコードで再現した。名前は Boids(bird + oid)。個体に与えるルールは3つだけ。 1. Separation ── 近すぎたら離れる 2. Alignment ── 周囲と同じ方向を向く 3. Cohesion ── 群れの中心に寄る これだけで、群れは群れらしく動く。 なぜ作ったか 群れの動きは、見ていて飽きない。 * 単純なルールから複雑な動きが生まれる ── 創発(emergence)の典型例。設計していないのに、設計したかのように見える。 * 自分のブログに置きたかった ── 静的なページに、動くものがあると空気が変わる。 * Web Components で作りたかった ── どこにでも持っていける部品として。 設計の話 見えないときは止める 画面外でアニメーションを回し続けるのは無駄。Inte

By Sakashita Yasunobu

Days Elapsed

一年を「面」で見る 一年は365日。数字で見ると多いけど、並べてみると案外少ない。 12ヶ月を並べて、過去を塗りつぶして、今日を光らせる。それだけのカレンダーを作った。進捗バーが「一次元」なら、これは「二次元」の進捗表示。 Year Progress一年は50週ちょっとしかない 2026年を週で数えると、52週とちょっと。 カレンダーで見ると長そうなのに、週で数えると急に短くなる。そんな感覚を形にしたくて、このページの上の方に進捗バーを置いた。 やっていることは単純で、「今年が何%進んだか」をリアルタイムで表示しているだけ。 なぜ作ったか 理由は3つある。 1. 時間を「量」として見たかった ── イベントや予定ではなく、単純に「どれだけ経ったか」を数値で見たかった。 2. 目に見える形にしたかった ── 抽象的な「一年」を、動く数字に落とすとどう感じるか試したかった。 3. 自分の場所に置きたかった ── 誰かのツールを借りるのではなく、自分のブログに自分で作ったものを置きたかった。 実装の話 せっかく作るなら、

By Sakashita Yasunobu