同じ回線、同じエンコーダー。違ったのは光の量だけだった
手元で実験をした。同じ構図の映像を、被写体に届く光の量だけ変えて2本つくる。光量1倍の映像と、光量16倍の映像だ。この2本を、同じエンコーダー（x264）で、同じ4,000kbpsの上限に押し込んだ。
出来上がりを、元のきれいな映像と見比べる。画質の近さを表す数値PSNRは、光量1倍の側が32.9dB、光量16倍の側が41.3dB。差は8.5dBだ。回線にも、エンコーダーにも、設定にも、一切触っていない。照明だけで、これだけ違った。
配信の画が荒れたとき、最初に出る処方箋は「ビットレートを上げよう」だ。だが、上限が決まっている回線ではその手が使えない。使えたとしても、直るとは限らない。実験では、ビットレートを上げるほど画質の数値が下がる場面さえあった。
（実験は計算機の上で作った擬似映像で行った。条件は有料部分にすべて書いてある。）
暗さはノイズになり、ノイズはビットを食う
暗い場所で撮った映像には、ザラザラした粒が乗る。ノイズだ。
映像を送れる大きさに縮める役目のエンコーダーは、前のコマを手本にして次のコマを描く。ところがノイズの粒は、1コマごとに位置が変わる。手本にならない。研究者の言い方を借りれば、ノイズは画面内の予測もコマ間の予測も外し、エンコーダーはそのノイズを表すためにビットを浪費する（Encoding in the Dark Grand Challenge: An Overview, arXiv:2005.03315）。
数字で見よう。Netflixは、AV1の粒状ノイズ合成（粒を送らず、受け側で足し直す方式）の導入で、平均ビットレートを31.6%減らしたと報告している（Netflixの発表、2025年報道）。粒は乱数のかたまりで、圧縮の手本にならないからだ。
私の擬似実験では、画質の目標を一定（x264のCRF23）に保つと、光量1倍の映像は22,244kbps、光量8倍の映像は2,920kbpsだった。必要量は86.9%減る（計算：1−2,920.3÷22,243.5）。
あなたの腕の問題ではない。数字を決める人が、別々なのだ
ビットレートの上限は、回線が決める。ノイズの量は、照明が決める。この2つの数字は、別の担当者が、別の机で、別の日に決める。それが1本のストリームの中で、ぶつかる。
たとえ話をしよう。砂ぼこりにまみれた原稿を、写経で丸写しする場面を思い浮かべてほしい。制限時間は決まっている。文字より先に砂粒を1粒ずつ写し始めたら、本文は最後まで書き終わらない。エンコーダーは写経の達人だ。ただし基準にするのは、入力された原稿そのもの。砂粒が混じっていれば、砂粒も忠実に写し取ろうとする。原稿から砂を払う仕事は、照明の側にある。
光とビットレートは、換算できる
方法はある。光量1段分が、ビットレート何kbps分に相当するのか。これは現場で測り、数字で決められる。必要なのは、照度計と、無料のソフトと、45分だ。
この記事の有料部分で手に入るもの
- 光量1段ごとの必要ビットレート表（擬似実験の全データ。条件と再現手順つき）
- 現場で回せる測定の7ステップ（所要時間と判定基準つき）
- 回線の上限から「何段の光が必要か」を逆算する早見表（YouTubeライブの推奨ビットレートに対応）
- 「光を足す」「ゲインを下げる」「ノイズ除去を前段に入れる」の使い分け判定
- よくあるミス4種と、珍しいトラブル2種の原因と正解
- 圧縮が入る区間と、入らない区間の見分け方（IP伝送の設計に効く）
有料部分を読み終えたとき、光量とビットレートの換算表、45分で回せる測定コマンド、本番前の判定チェックリストが手元に揃う。次の現場では、回線を太くする話の前に、光を足す話ができる。
ここから先は有料部分だ。
コメント