2025,江端さんの忘備録

さすがに３つの案件の同時並列処理は無理　――　と、泣き言を言いながら、今、本当に泣きそうです。

I'm whining that “it's impossible to handle three projects simultaneously,” and I'm about to cry.

経験的に、こういう時『もっと大変な人が、沢山いる』という考え方をすることは、悪手です。

Empirically, thinking that “there are many people in worse situations” is a bad idea in a situation like this.

他人なんぞ、どーでもいい。

I don't care about other people.

「私が辛い」という状態だけで、必要かつ十分です。

The fact that I am in pain is sufficient.

-----

そういえば、今年の年賀状には、長女の結婚式の写真の下に、自分のコメントとして

Speaking of which, on this year's New Year's card, under the photo of my eldest daughter's wedding, I remember I wrote the following  comment 

『昨年、"うつ"になりました』

'I became depressed last year.'

と書いたのを思い出しました。

『これでは、長女の結婚で"うつ"になったように読める』と気がついたのは、年賀状をポストに投函した後でした。

It was only after I had posted the New Year's card in the post that I realized that it could be read as if I had become depressed because of my eldest daughter's marriage.

しかし、私を"うつ"にするのは、いつだって、仕事です。

However, it is always work that makes me depressed.

その正体の多くが、動かないプログラムであり、停止するシステムです。

Many are programs that don't work and systems that become stop.

世の中には「頼めない仕事」というものが、あるのです。

There are some jobs that I can't ask someone to do.

つまりですね、技術というのは、属人性が高く、他人への譲渡が恐しく困難なのです

2025,江端さんの技術メモ

bytes-received send-rate-mbps receive-rate-mbps bandwidth-mbps rtt-ms cb
0 0 0 12 100 1706
0 1.128166 0 6.216 43.597 2000
0 3.958326 0 10.008 80.069 1831
0 4.864244 0 69.084 74.593 2000

この表にでてくる、send-rate-mbps receive-rate-mbps bandwidth-mbps の単位は何ですか

表にある send-rate-mbps、receive-rate-mbps、bandwidth-mbps の単位は「Mbps（メガビット毎秒）」 です。

各項目の意味と単位

項目 意味 単位
send-rate-mbps 送信レート（今使っている帯域） Mbps（メガビット毎秒）
receive-rate-mbps 受信レート（今使っている帯域） Mbps（メガビット毎秒）
bandwidth-mbps 推定利用可能帯域（まだ使える帯域） Mbps（メガビット毎秒）

1. send-rate-mbps（送信レート）

  • 実際に送信しているデータ量の速度 を表す。
  • 今使っている帯域（現在の送信速度）。
  • 例えば send-rate-mbps = 4.864244 なら、約 4.86 Mbps でデータを送信している。

2. receive-rate-mbps（受信レート）

  • 実際に受信しているデータ量の速度 を表す。
  • 今使っている帯域（現在の受信速度）。
  • このデータでは receive-rate-mbps = 0 なので、受信データはない。

3. bandwidth-mbps（推定帯域幅）

  • SRTプロトコルが計算した「利用可能な最大帯域」。
  • まだ使える帯域の推定値。
  • 例えば bandwidth-mbps = 69.084 なら、SRTは「この回線では約 69.08 Mbps まで使える」と推定している。

単位換算

1 Mbps（メガビット毎秒）は：

  • 1,000 kbps（キロビット毎秒）
  • 1,000,000 bps（ビット毎秒）
  • 125 KB/s（キロバイト毎秒）
  • 0.125 MB/s（メガバイト毎秒）

例えば：

  • send-rate-mbps = 4.86 Mbps
    • = 4,860 kbps
    • = 約 607.5 KB/s
    • = 約 0.607 MB/s

結論

  • send-rate-mbps、receive-rate-mbps、bandwidth-mbps の単位は「Mbps（メガビット毎秒）」
  • send-rate-mbps は今使っている送信帯域
  • receive-rate-mbps は今使っている受信帯域
  • bandwidth-mbps はSRTが推定した利用可能な最大帯域

このデータから、送信レートは 最大 4.86 Mbps であり、ネットワークが 最大 69 Mbps まで利用可能 と推定されていることが分かります。

2025,江端さんの技術メモ

GStreamerのC言語のライブラリの、res = gst_structure_get_double(stats, "bandwidth-mbps", &bandwidth_mbps); g_print("bandwidth-mbps: %d %f\n", res, bandwidth_mbps);の値が何の値を返しているのか教えて下さい

このプログラムにおける bandwidth_mbps の値は、SRT（Secure Reliable Transport）通信における推定帯域幅（Mbps） を示していると考えられます。

bandwidth_mbps の取得と用途

1. どこで取得しているか

bandwidth_mbps は、以下のコードで取得されています。

c
res = gst_structure_get_double(stats, "bandwidth-mbps", &bandwidth_mbps);
g_print("bandwidth-mbps: %d %f\n", res, bandwidth_mbps);

この部分では、GStreamer の srtserversink から取得できる SRTの統計情報 (stats) から "bandwidth-mbps" というキーの値を取得しています。

GStreamer の SRTプラグイン (srtserversink) は、SRTプロトコルのメトリクス情報を提供し、その中に "bandwidth-mbps" というパラメータが含まれています。

つまり、SRT通信時の「利用可能な推定帯域幅」をリアルタイムで取得している。

bandwidth_mbps の意味

  • SRTの推定帯域幅（Mbps）
  • リアルタイムでSRTの通信状況から取得される
  • 現在のネットワーク環境で送信可能な最大帯域を示す

bandwidth_mbps の用途

  • エンコードのビットレート調整に使用
  • ネットワークの状況に応じて、適切なビットレートを決定

「SRTの推定帯域幅（Mbps）」というのは、「今使っている帯域なのか」、「まだ使える帯域なのか」どちらでしょうか

bandwidth_mbps は、SRT (Secure Reliable Transport) における「推定帯域幅 (Estimated Bandwidth)」を示す値であり、その意味合いは 「まだ使える帯域」＝ 利用可能な推定帯域 に近いものです。

1. bandwidth_mbps は「今使っている帯域」ではない

理由 ①: "send-rate-mbps" や "receive-rate-mbps" という項目が別にある

プログラム内では、SRTの統計情報 (stats) から bandwidth-mbps の他に、send-rate-mbps や receive-rate-mbps という値も取得できるようになっています。

c
res = gst_structure_get_double(stats, "send-rate-mbps", &send_rate_mbps);
g_print("send-rate-mbps: %d %f\n", res, send_rate_mbps);

res = gst_structure_get_double(stats, "receive-rate-mbps", &receive_rate_mbps);
g_print("receive-rate-mbps: %d %f\n", res, receive_rate_mbps);

  • send-rate-mbps → 現在の送信レート（今実際に使っている帯域）
  • receive-rate-mbps → 現在の受信レート（今実際に使っている帯域）
  • bandwidth-mbps → SRTプロトコルが推定した、利用可能な最大帯域

このことから、bandwidth-mbps は「現在使っている帯域」ではなく、「ネットワークが許容できる帯域の推定値」 であると考えられます。

2. bandwidth-mbps の定義（SRT公式の仕様より）

SRTの公式仕様では、"Estimated Bandwidth"（推定帯域）は次のように説明されています。

bandwidth-mbps: The estimated maximum available bandwidth of the connection, calculated by the SRT protocol based on observed network conditions such as packet loss and RTT.

要点

  • 「ネットワークの状況（パケットロスやRTTなど）を基にSRTが計算した、利用可能な最大帯域」 である。
  • 現在の送信レートとは異なる。
  • "available bandwidth"（利用可能な帯域） という表現が使われている。

つまり、SRTが「この回線ではこのくらいの帯域が利用できるはずだ」と推定している値 であり、今実際に使用している帯域とは違う ということです。

4. まとめ

指標 意味 役割
send-rate-mbps 今使っている帯域（送信速度） 実際の送信速度をモニタリング
receive-rate-mbps 今使っている帯域（受信速度） 実際の受信速度をモニタリング
bandwidth-mbps まだ使える帯域（推定値） SRTが計算した利用可能な最大帯域

結論

✅ bandwidth_mbps は「まだ使える帯域」＝ 利用可能な推定帯域
✅ SRTがネットワーク状況を解析して算出した、回線が許容できる最大帯域を示している
✅ 「今使っている帯域（現在の送信速度）」ではなく、「どのくらいの帯域が利用可能か」という指標

この値を使って、適切なビットレートを動的に調整し、映像配信を安定させる仕組みになっています。

2025,江端さんの技術メモ

GStreamer (gst-launch-1.0) と tc (Traffic Control) の "bitrate" の意味が異なるため、混乱するのは自然です。以下に、それぞれの設定が どの部分を制御しているのか を整理して説明します。

1. GStreamer (bitrate=1700) の意味

x264enc bitrate=1700
  • GStreamer の bitrate=1700 は、エンコード時のビットレートを指定 しています。
  • 単位は kbps（キロビット毎秒） なので、この場合 1.7 Mbps になります。
  • エンコード後の映像ストリームのデータ量を決定 し、これが ネットワークに流れるデータ量の目安 になります。
  • つまり、GStreamer の設定は「この映像ストリームのビットレートを 1.7 Mbps にしなさい」という指示 です。

✅ 換算

  • 1700 kbps = 1.7 Mbps
  • 1.7 Mbps = 約 0.212 MB/s（メガバイト毎秒）
    • 計算式: 1.7 Mbps ÷ 8 = 0.212 MB/s

2. tc (rate 5mbit) の意味

tc qdisc add dev eth0 root tbf rate 5mbit burst 10kb latency 50ms
  • tc の rate 5mbit は、ネットワークインターフェース (eth0) の最大帯域を制限する設定 です。
  • 単位は Mbps（メガビット毎秒） なので、この場合 5 Mbps になります。
  • これは 「eth0 から送信できる最大速度を 5 Mbps に制限しなさい」という指示 です。
  • つまり、GStreamer が 1.7 Mbps の映像を送信しようとしても、5 Mbps の帯域制限があるため、この範囲内なら問題なく送信できる。

✅ 換算

  • 5 Mbps = 約 0.625 MB/s（メガバイト毎秒）
    • 計算式: 5 Mbps ÷ 8 = 0.625 MB/s

3. GStreamer bitrate=1700 と tc rate=5mbit の関係

(1) GStreamer のビットレートが tc の制限内に収まる場合

  • GStreamer (bitrate=1700 kbps = 1.7 Mbps)
  • tc の制限 (rate=5mbit = 5 Mbps)
  • 1.7 Mbps < 5 Mbps → 問題なく通信できる
  • 映像ストリームのデータ量は 1.7 Mbps なので、帯域 5 Mbps では十分。

(2) GStreamer のビットレートが tc の制限を超える場合

例えば、GStreamer の bitrate=6000（6 Mbps）と設定した場合：

  • 6 Mbps > tc の rate=5mbit
  • 制限（5 Mbps）を超えているため、パケットロスが発生する可能性がある
  • 映像が乱れたり、ストリームが停止する可能性がある

このように、GStreamer の bitrate は映像のエンコード後のデータ量、tc の rate はネットワークの最大許容量を決める ため、両者の関係を考える必要があります。

4. まとめ

設定 役割 値の意味 設定値（例）
GStreamer bitrate 映像エンコードのビットレート 送信するストリームのデータ量 bitrate=1700 → 1.7 Mbps
tc rate ネットワークの最大帯域制限 インターフェースの最大通信速度 rate=5mbit → 5 Mbps

結論

  • GStreamer の bitrate は「どれだけのデータを送るか」
  • tc の rate は「送れるデータ量の上限」
  • GStreamer のビットレートが tc の制限内なら問題なし（1.7 Mbps < 5 Mbps）
  • GStreamer のビットレートが tc の制限を超えるとパケットロスの可能性あり（例: 6 Mbps > 5 Mbps）

つまり、現在の設定（bitrate=1700 と rate=5mbit）では 1.7 Mbps の映像を 5 Mbps の帯域内で余裕をもって送信できる ということになります。

よし、これは分かった。

2025,江端さんの技術メモ

添付ファイルのように、解像度やフレームレートが決まっているので、ビットレートは自動的に決まるような気がします。「1クライアントあたりのビットレート」とは何でしょうか？

「1クライアントあたりのビットレート」とは、ストリーミング配信時に1つのクライアント（視聴者）に対して割り当てられるビットレートを指します。

考えられる動作

  • 固定ビットレート（CBR: Constant Bitrate）の場合

    • 設定したビットレート（例：3072kbps）が、そのまま1クライアントあたりの配信ビットレートとして適用されます。
    • クライアントが増えても、各クライアントに同じビットレートで送信されるため、サーバーの総帯域は**「3072kbps × 接続クライアント数」**となる。

  • 可変ビットレート（VBR: Variable Bitrate）の場合

    • ネットワークの状態や映像の動きによってビットレートが変動する可能性があります。
    • クライアントごとに適応的に異なるビットレートが設定されることがある。

サーバー側の負荷との関係

  • クライアント数が増えると、総帯域も増加
    例えば、10人のクライアントが接続すると、合計ビットレートは 3072kbps × 10 = 30.72Mbps になります。
    サーバーの帯域幅が限られている場合、クライアント数が増えるとストリーミングの品質が低下する可能性があります。

  • マルチキャスト配信（UDP）であれば帯域が一定
    画像の設定では「インターネットモード：Off（UDP）」になっています。
    UDPマルチキャストを使う場合、同じストリームを複数のクライアントに送信できるため、クライアント数が増えてもサーバーの総帯域には影響しにくいです。

設定の意味

この設定が「1クライアントごとのビットレート」になっているため、

  • クライアントごとに3072kbpsで配信される
  • クライアント数が増えると、サーバーの帯域も比例して増加
  • UDP（マルチキャスト）であれば、帯域が固定されて効率的に配信可能

という仕組みになっていると考えられます。

つまり「1クライアントあたりのビットレート」というのは「1クライアントあたりのビットレートの上限値」という解釈で良いですか。つまり、それ以上のビットレートは出せない、という意味である、ということで良いですか？

「1クライアントあたりのビットレート」＝「1クライアントあたりのビットレートの上限値」 という解釈でほぼ正しいです。
つまり、設定したビットレートを超えるデータ量は送信されない という意味になります。

ただし、可変ビットレート（VBR） の場合は少し異なり、最大値としての上限 になりますが、実際のビットレートは映像の内容に応じて変動 します。
逆に、固定ビットレート（CBR） では 常に設定値で送信 されます。

具体的な挙動

配信モード 「1クライアントあたりのビットレート」の意味
固定ビットレート（CBR） 常に設定値のビットレートで送信（超えないし、下回らない）
可変ビットレート（VBR） 最大値としての上限（超えないが、低くなることはある）
フレームレート指定 フレームレートを固定しつつ、CBRまたはVBRを適用
ベストエフォート指定 ネットワーク状況に応じて変動（上限なしの場合も）

結論

「1クライアントあたりのビットレート」は、基本的には「上限値」として機能し、設定値を超えることはない。
ただし、ビットレートの挙動は配信モードに依存する ため、VBRでは上限値未満で可変、CBRでは常に設定値 という違いがある。

今回の場合、ユーザは数人程度しかいません。
配信モードは「固定ビットレート」「可変ビットレート」「フレームレート指定」「ベストエフォート指定」のメニューがあります。
解像度は640ｘ360で、5fps,10fps,20fpsの3種類の転送実験を行いたいと思っています。

選択すべき配信モード、解像度とfpsに対する、1クライアントあたりのビットレートを表にして示して下さい

推奨設定とビットレート表

1. 配信モードの選択

  • 「フレームレート指定」 が適切
    • 実験の目的が「解像度 640×360」で 5fps, 10fps, 20fps の転送実験 を行うことなので、フレームレートを固定できるモードを選択するのが適切。
    • 「固定ビットレート」では画質が保証されず、特に低fps時に無駄なビットレート消費が発生する可能性がある。
    • 「ベストエフォート指定」ではネットワーク状況に応じて変動するため、実験の統一性が損なわれる可能性がある。
    • 「可変ビットレート（VBR）」も画質を維持しやすいが、フレームレートとの相性が不明なため、今回の実験には適さない可能性がある。

2. 各設定における推奨ビットレート

解像度 フレームレート 推奨ビットレート（H.264, 1クライアントあたり）
640×360 5fps 93kbps（最低100～150kbps推奨）
640×360 10fps 185kbps（最低200～300kbps推奨）
640×360 20fps 370kbps（最低400～600kbps推奨）

3. 補足

  • ビットレートの決定方法
    • 参考値として フルHD(1920×1080, 30fps)の5000kbps を基準に、解像度とfpsの比率を使ってスケーリングして計算。
    • 実際の設定では、若干高めのビットレート（表の推奨範囲）を指定した方が安定する。
  • 配信モードの調整
    • 「フレームレート指定」＋「固定ビットレート」（上記の推奨値）で安定した画質を維持しやすい。
    • ネットワーク帯域に余裕があれば 「可変ビットレート（VBR）」を試して、最低ビットレートを表の値以上に設定する ことで、より滑らかな映像が得られる可能性もある。

4. 最適な設定の結論

設定項目 推奨値
配信モード フレームレート指定
解像度 640×360
フレームレート 5fps, 10fps, 20fps（それぞれ実験）
1クライアントあたりのビットレート 最低値を超えるよう設定（推奨範囲：100～600kbps）

結論：

  • 実験では「フレームレート指定」モードを選択
  • 各fpsに対応する最低ビットレートを超えるように設定
  • ネットワークに余裕があれば、少し高めのビットレート（推奨範囲内）を選択
  • 可変ビットレートも試してみる価値あり（最低値を超える設定で）

2025,江端さんの技術メモ

DockerのPostgreSQLデータベースをWindows→WSLのDockerへ移行する方法

Windows上のDockerで動作するPostgreSQLデータベースを、WSL（Windows Subsystem for Linux）のDockerに移行する 手順を説明します。

🔷 方法 1: Dockerボリュームごと移行する（推奨）

Windowsでは grep や busybox は不要 で、標準的な PowerShellコマンド を使用して移行できます。

📌 ① ボリューム名を確認

まず、PostgreSQLのデータが保存されているボリューム名を確認します。

powershell
docker volume ls

出力例：

DRIVER VOLUME NAME
local hakata_db-data

この hakata_db-data がPostgreSQLのデータが格納されているボリュームです。

📌 ② ボリュームをtarファイルにバックアップ

PowerShellを管理者権限で開き、以下のコマンドを実行します。

docker run --rm -v hakata_db-data:/data -v C:\Users\tomoi\backup:/backup ubuntu tar czf /backup/hakata_db_backup.tar.gz -C /data .

重要なポイント

  • C:\Users\tomoi\backup はWindows側のバックアップ保存先（任意のフォルダを指定）
  • ubuntu イメージを使用（busybox は不要）
  • hakata_db_backup.tar.gz という圧縮ファイルが作成される

この hakata_db_backup.tar.gz をUSBやネットワーク経由で 移行先のマシンへコピー します。

📌 ③ WSLのDocker環境にファイルをコピー

WSLのファイルシステムにバックアップを移動します。

powershell
wsl

WSL内で以下のコマンドを実行して、WindowsのバックアップファイルをWSLの /home/ ディレクトリにコピー。

cp /mnt/c/Users/tomoi/backup/hakata_db_backup.tar.gz /home/

📌 ④ WSLのDockerでボリュームを作成

WSL内で以下を実行し、新しいボリュームを作成します。

docker volume create hakata_db-data

作成したボリュームにデータを展開します。

docker run --rm -v hakata_db-data:/data -v /home:/backup ubuntu tar xzf /backup/hakata_db_backup.tar.gz -C /data

📌 ⑤ WSLのDockerでPostgreSQLコンテナを起動

WSL内で以下を実行し、データをマウントしたPostgreSQLコンテナを起動。

docker run -d --name postgres_hakata -p 15432:5432 -v hakata_db-data:/var/lib/postgresql/data postgres:16

📌 ⑥ データが正しく復元されたか確認

PostgreSQLコンテナに接続してデータを確認。

docker exec -it postgres_hakata psql -U postgres

データベース一覧を表示：

\l

2025,江端さんの技術メモ

音声を無視して、最も一般的な webm → mp4 変換コマンドは以下のようになります。

ffmpeg -i input.webm -vf "scale=640:360" -r 5 -c:v libx264 -preset slow -crf 23 -an output.mp4

説明：

  • -i input.webm：入力ファイルの指定
  • -vf "scale=640:360"：解像度を640x360に変更
  • -r 5：フレームレートを5fpsに変更
  • -c:v libx264：H.264コーデックでエンコード
  • -preset slow：エンコード速度と圧縮率のバランスをとる（品質優先）
  • -crf 23：品質を指定（数値が低いほど高品質）
  • -an：音声を削除（無音にする）
  • output.mp4：出力ファイルの指定

このコマンドで、音声なしの mp4 に変換できます。

2025,江端さんの技術メモ

TC帯域を設定して、レイテンシーを設定した後、パケロスや遅延を設定する場合、だいたい、こうやるのですが、

sudo tc qdisc add dev eth0 root handle 1: tbf rate 10mbit burst 10kb latency 500ms
sudo tc qdisc add dev eth0 parent 1:1 handle 10: netem delay 10000ms loss 1%

RTNETLINK answers: No such file or directory と言われます。

Webで調べてみたところ、山のように、同じ"悲鳴"が飛んでいました。

で、解決方ですが、ChatGPTが、逆転の発想のやりかたを教えてくれました。

# 既存の設定を削除
sudo tc qdisc del dev eth0 root (何か表示されるが無視する)

# `netem` を root にして、まずパケットロスを設定
sudo tc qdisc add dev eth0 root handle 1: netem loss 1% delay 10000ms

# その上に `tbf` を適用
sudo tc qdisc add dev eth0 parent 1:1 handle 10: tbf rate 10mbit burst 10kb latency 500ms

つまるところ、ルールの親と子を引っくり返す、という手法です。

まあ、理由は不明ですが、これで動いているようです。

2025,江端さんの技術メモ

例題: 水道の蛇口に例える

ネットワークの「ビットレート (bitrate)」と「帯域 (bandwidth)」 の違いを、水道の蛇口に例えて説明します。

1. 帯域 (bandwidth) = 水道管の太さ

  • 水道管の太さが 「ネットワークの帯域」 に相当する。
  • 例えば 「10Gbpsの回線」 というのは 「直径10cmの水道管」 に相当する。
  • 「最大で10Gbps流せる」 という意味だが、実際にどれくらい流すかは別の話。

2. ビットレート (bitrate) = 水の流量 (蛇口の開き具合)

  • 蛇口をどれくらい開くかが 「ビットレート」 に相当する。
  • 例えば tc で rate 5mbit を設定すると、蛇口を半分だけ開くようなイメージ。
  • 回線が10Gbps（帯域）でも、実際に使うのは5Mbps（ビットレート）に制限される。

3. tc を使った制限の具体例

(1) 10Gbpsの回線を持つPC (帯域 = 10Gbps)

  • 例えば、自宅のネット回線が 10Gbps だったとする。
  • しかし、tc を使って rate 5mbit に制限すると、実際のデータ転送は 5Mbps しか出ない。

(2) tc で 5Mbps のビットレート制限

sudo tc qdisc add dev eth0 root tbf rate 5mbit burst 10kb latency 1ms

この設定をすると、10Gbpsの回線を持っていても、実際の転送速度は 5Mbps に制限 される（＝蛇口を少ししか開かない）。

(3) tc で 5Mbps ～ 10Mbps の変動を許可

sudo tc qdisc add dev eth0 root handle 1: htb default 10
sudo tc class add dev eth0 parent 1: classid 1:1 htb rate 5mbit ceil 10mbit
  • 最低 5Mbps で 最大 10Mbps まで許可 する設定。
  • 普段は5Mbpsだが、ネットワークに余裕があれば 最大10Mbps まで利用可能。

4. 結論

項目 水道の例 ネットワークの意味
帯域 (bandwidth) 水道管の太さ 利用可能なネットワークの最大容量 (例: 10Gbps)
ビットレート (bitrate) 蛇口の開き具合 実際に流せるデータ速度 (例: 5Mbps)
  • 帯域は「最大でどれくらい流せるか」 を決める（物理的な上限）。
  • ビットレートは「実際にどれくらい流すか」 を tc で調整できる。

2025,江端さんの技術メモ

OBSの録画時にCPU負荷が増大し、操作が困難になる場合、以下の設定を調整することで負荷を軽減できます。

1. 録画のエンコーダを変更

設定 → 出力 → 録画 → エンコーダ

  • 「ハードウェアエンコード (NVENC, QuickSync, AMF)」を使用する
    • NVIDIA → NVENC (H.264)
    • Intel CPU内蔵GPU → QuickSync H.264
    • AMD GPU → AMF
    • ハードウェアエンコードがない場合 → x264のプリセットを変更（後述）

      私の場合、エンコードするハードウェアがにないからスキップ

2. 録画の品質を下げる

設定 → 出力 → 録画

  • 録画品質: 「低品質、ファイルサイズ優先」
  • 録画フォーマット: mp4（またはflv）
  • エンコーダ設定: CBR (固定ビットレート)
    • ビットレート: 1500～2500kbps（画質が多少荒くなるが負荷が下がる）
    • キーフレーム間隔: 2秒
    • CPUプリセット: 「ultrafast」（x264使用時のみ）

      録画の方には、上記メニューに該当するものがなかったので、こちらもスキップ

3. 解像度とフレームレートを下げる

設定 → 映像

    • 基本 (キャンバス) 解像度: 1280×720
    • 出力 (スケーリング) 解像度: 640×360 または 854×480
    • FPS: 30 FPS または 24 FPS

      出力は最低値に、FPSは手動で10fps位まで落した→ 動作が軽くなって、マウス操作ができるようになった