図解 H.265 入門 (1) 動画データの正体：画素・YUV・ビット深度

この記事の本文は AI（Claude Code）で生成し、筆者が全文を読んで内容を確認したものです。事実と数値は脚注の一次資料と手元の実測で裏を取っています。

動画の設定を触っていると「4:2:0」や「10 bit」といった表記をよく見かけるけど、それぞれの数字が何を表しているのかを説明しようとすると案外むずかしいです。非圧縮の動画のデータ量を一度計算しておくと、配信で使うビットレートがどのくらい小さい数字なのかを比べられるようになります。地味な内容やけど、圧縮の章に入る前の準備として読んでもらえれば。

圧縮の仕組みに入る前に、圧縮の対象になる動画データがどういう形をしているのかを確認します。この章では画素・輝度・色差・ビット深度を定義し、「4:2:0」という表記の各数字が何を指すのか、非圧縮の動画が実際に何バイトになるのかを計算します。

TL;DR

• 動画は「$W \times H$ の格子に並んだ数値」を 1 秒あたり $f_{ps}$ 枚並べたものです。各画素は輝度 1 サンプルと色差 2 サンプルで表されます
• 4:2:0 の 3 つの数字は「幅 4 画素 × 高さ 2 画素の窓の中に色差サンプルを何個持つか」を表します。4:2:0 のデータ量は 4:4:4 の 50% です
• 1080p / 30 fps / 8 bit / 4:2:0 の非圧縮は 746.496 Mbit/s です。1 秒で 93.312 MB、1 時間で 335.9 GB になります
• 配信の目安の一例では、1080p の H.265 は 4500 kbit/s です¹。非圧縮の約 166 分の 1 に落としている計算になります
• 10 bit は 8 bit の約 4 倍の階調を持つため、グラデーションの段差（バンディング）に強くなります。H.265 の Main 10 プロファイルは 4:2:0 の 8〜10 bit を許します²

動画は「数字の 3 次元配列」

まず定義を並べます。

• 画素: 画像を格子状に区切った 1 マスです。動画の規格では「サンプル」という語で扱われます³
• 解像度 $W \times H$: フレームの幅（画素数）と高さ（画素数）です。1080p なら $1920 \times 1080$​⁴、4K（UHD）なら $3840 \times 2160$ です⁵
• フレーム: 動画を構成する静止画 1 枚です。規格では「ピクチャ」と呼びます³
• フレームレート $f_{ps}$: 1 秒あたりのフレーム数です。単位は fps です
• ビット深度 $b$: 1 サンプルを何ビットで表すかです。8 bit なら 1 サンプルが 0〜255 の整数になります

つまり非圧縮の動画は、「幅 $W$ × 高さ $H$ × 成分数」の数値の配列を、時間方向に $f_{ps}$ 枚/秒で積み上げたものです。ビットが集まって 1 サンプルになり、Y・Cb・Cr の 3 サンプルで 1 画素の色が決まり、画素が並んで 1 枚の画像になり、画像が並んで動画になる、という入れ子です。

8 個のビットが 1 サンプル、Y・Cb・Cr の 3 サンプルで 1 画素、画素が並んで 1 枚の画像、画像が並んで動画になる

flowchart LR
  A["動画<br/>（時間方向に積む）"] --> B["フレーム t<br/>W × H の格子"]
  B --> C["画素 (x, y)"]
  C --> D["輝度サンプル Y"]
  C --> E["色差サンプル Cb"]
  C --> F["色差サンプル Cr"]
  D --> G["b ビットの整数"]
  E --> G
  F --> G

この記事では、空間領域のサンプル値を $f(x, y)$ と書きます。$x$ が横（列）、$y$ が縦（行）で、左上が原点、0 始まりです。

ここで注意したいのが、画素とサンプルは 1 対 1 ではないことです。後で見るように、4:2:0 では色差のサンプル数が輝度の 4 分の 1 しかありません。後の非圧縮サイズの計算では、この「1 画素あたり何サンプルあるか」を形式ごとに求めて使います。

明るさと色を分ける：RGB から YCbCr へ

なぜ分けるのか

ブラウザで色を扱うときは rgb(255, 0, 0) のように赤・緑・青の 3 成分で書きます。一方、動画コーデックは R・G・B ではなく、輝度（Y）と色差（Cb、Cr）という組に変換してから扱います。この形式は慣習的に「YUV」とも呼ばれますが、規格が使う名前は Y、Cb、Cr です³。以下でも Y / Cb / Cr で書きます。

イメージとしては、カラー写真を「白黒写真 1 枚」と「そこに何色を足すかの指示 2 枚」に分ける操作です。細かい形の情報はほとんどが白黒写真（輝度）に入っていて、色の指示（色差）は大づかみでも見た目が保てます。この性質を後の「色差サブサンプリング」の節で使います。ただし色差は文字どおり「輝度との差」なので、色差の 2 枚だけを眺めても色は決まりません。輝度と組にして初めて RGB に戻せる、という点は「足す色」のイメージと違います。

4×4 の純色が Y・Cb・Cr の 3 枚に分かれる。数値は後の「数値例」の純色の表と同じ。Cb・Cr の面の色は、値を分かりやすく色付けした便宜的なもの

変換式

変換の係数は「どの色空間の規定に従うか」で変わります。この章では、HDTV の色を定めた規格である BT.709 の係数を使います⁴。ほかの規格では、次の表のように別の係数を使います。

同じ「YUV」と呼ばれていても係数が複数あるので、変換するときはどれを使うか明示する必要があります。以下は BT.709 で進めます。

輝度の定義は次のとおりです。$E'_R, E'_G, E'_B$ はガンマ補正済みの R'G'B' 信号で、0〜1 に正規化されています⁴。

緑の係数が一番大きい理由は、同じ強さの光でも緑が最も明るく見えることにあります。明るい環境での視覚（明所視）の感度のピークは 555 nm、つまり緑の波長です⁷。ただし 0.7152 という値そのものは感度のピーク波長から出るのではなく、その色空間が使う原色の色度座標と白色点から計算されます⁸。

色差は、輝度との差を決まった値で割って作ります⁴。

分母は天下りに見えますが、$E'_{Cb}, E'_{Cr}$ が $-0.5 \sim +0.5$ に収まるよう正規化した値です。実際、$2(1 - 0.0722) = 1.8556$、$2(1 - 0.2126) = 1.5748$ と一致します。

最後に、この実数を整数に丸めます。連続的な値を決まった段数の整数に落とすこの操作を量子化（quantization）と呼びます。$b$ がビット深度、$\mathrm{INT}(\cdot)$ は小数部 0.5 以上を切り上げる演算です⁴。

$D_{Cr}$ も $D_{Cb}$ と同じ式です。8 bit のとき黒が 16、白が 235、色差の中央が 128 になります⁴。0〜255 を目一杯使わず上下に余白を残すこの取り決めを限定レンジ（limited range）、全域を使う取り決めをフルレンジ（full range）と呼びます。どちらで符号化したかは VideoFullRangeFlag という 1 ビットで区別されます⁸。

なぜわざわざ余白を残すのかというと、信号処理で生じる行き過ぎに備えるためです。映像信号にフィルタをかけると波形が黒より下や白より上に飛び出すことがあり、その行き過ぎ分を捨てずに持っておく余裕（フットルーム・ヘッドルーム）が要ります。8 bit で 16 より下と 235 より上に残した範囲がその余白です⁹。さらに 0 と 255 は映像データには使えず、同期のタイミング基準として予約されています⁴。映像では、指定がなければ限定レンジとみなすのが既定です⁸。

数値例：純赤は Y, Cb, Cr で何になるか

rgb(255, 0, 0)、つまり $E'_R = 1, E'_G = 0, E'_B = 0$ を 8 bit の BT.709 で変換してみます。

純赤は (Y, Cb, Cr) = (63, 102, 240) です。Cr は色差が取りうる上限近くの値になっている一方、Y は 63 と黒に近い値です。純赤は「派手だが明るくはない」色だということが、この数値から分かります。

ほかの純色も同じ式で計算すると次のようになります。

白と黒で色差が 128（中央値）になっているのが確認できます。無彩色では色差が 0 になる、という定義どおりの結果です。

import math

KR, KG, KB = 0.2126, 0.7152, 0.0722

def INT(v):
    return math.floor(v + 0.5)

def rgb_to_ycbcr(red, green, blue, b=8):
    """red, green, blue は 0..1 に正規化した R'G'B'。戻り値は b ビットの整数。"""
    ey = KR * red + KG * green + KB * blue
    ecb = (blue - ey) / 1.8556
    ecr = (red - ey) / 1.5748
    return (INT((219 * ey + 16) * 2 ** (b - 8)),
            INT((224 * ecb + 128) * 2 ** (b - 8)),
            INT((224 * ecr + 128) * 2 ** (b - 8)))

色差サブサンプリング：4:2:0 の 3 つの数字を読む

輝度と色差に分けた後、色差だけサンプル数を減らしても見た目が大きく崩れません。色差の解像度だけを輝度より下げるこの操作を色差サブサンプリング（chroma subsampling）と呼びます。

色を粗くしても気づきにくい理由

網膜には桿体（かんたい）と錐体（すいたい）という 2 種類の視細胞があります。

• 桿体: 数は 1 億 1000 万〜1 億 2500 万個と圧倒的に多く⁷、わずかな光にも反応します¹⁰。その代わり視物質が 1 種類しかないので、色を区別できません¹⁰。夜道で物の形は見えるのに色が分からない、あの見え方を担っているのが桿体です。感度のピークは 507 nm です¹¹
• 錐体: 数は 640 万個と桿体のおよそ 20 分の 1 ですが⁷、感度のピークが違う 3 種類（S・M・L）があります。ピークは S が 442 nm（青）、M が 543 nm（緑）、L が 570 nm（赤）で¹¹、この 3 つの反応の比率が色の感覚のもとになります

数だけ見て「桿体のほうが圧倒的に多いから明るさに敏感」と結論するのは誤りです。桿体が働くのは暗所視（暗いところでの視覚）で、ディスプレイを見ているような明るさは錐体が働く明所視の領域です¹²。明所視で輝度の知覚を主に担うのは錐体で、明所視の輝度は L 錐体と M 錐体が吸収した光子の重み付き和に比例します。暗所視の輝度が桿体の吸収光子数に比例するのとは別系統です⁷。桿体の数は色差サブサンプリングの根拠にはなりません。

4 種類の細胞の反応を 1 枚にすると次のようになります。

L・M・S 錐体と桿体（グレーの破線）の分光感度。各曲線はピークを 1 に正規化してあり、桿体と錐体の絶対感度の差は表していません。S 錐体は測定値のある 615 nm までを描いています¹¹

M と L のピークは 27 nm しか離れておらず、曲線が大きく重なっています。「赤の錐体」「緑の錐体」と呼ばれるものの、実際にはどちらも可視光の広い範囲に反応していて、色は 3 つの出力の差から間接的に決まります。

では、なぜ色だけ粗くしてよいのでしょうか。根拠になるのは、錐体からの信号を組み合わせて作られる「輝度の系統」と「色の系統」とで、細かい模様を見分ける感度が違うことです。感度は、ある細かさの縞模様を見分けられる最小のコントラストの逆数であるコントラスト感度で比べます。縞の細かさは、視角 1 度あたりの縞の周期数である cycles/deg で測ります。

• 色による識別の限界解像度は、赤-緑・青-黄のどちらでも 11〜12 cycles/deg 程度です¹³
• 輝度の縞に対するコントラスト感度は、明所視で 50〜60 cycles/deg あたりまで伸びます¹⁴

見分けられる細かさは、輝度と色でおおまかに 4〜5 倍違います。測定条件の違う実験どうしの比較なので、厳密な倍率ではありません。実際、0.5 cycles/deg より高い細かさでは、輝度の縞のほうが色の縞よりコントラスト感度が高くなります¹³。細かい縞になるほど色の違いは見分けられなくなるので、「色差は輝度より粗く持っても気づきにくい」が成り立ちます。

4×2 の窓で数える

4:2:0 のような表記を読むには、画像を幅 4 画素・高さ 2 画素の小さな窓で切り取って、その中に色差のサンプルが何個あるかを数えます。この窓のことを参照ブロックと呼びます。輝度のサンプルはどの形式でも全画素に 1 個ずつあり、減るのは色差だけです。

3 つの数字が指すもの

3 つの形式について、窓の中の色差サンプルを数えたのが次の図です。

4×2 の窓に色差サンプルがいくつ入るか。上の行の個数が 2 番目の数字、下の行の個数が 3 番目の数字になる

4:2:0 の色差は、既定では図のとおり上下 2 本の輝度の行のちょうど間の高さにあります³。数えるときは、上の行の分として数えます。

図と見比べると、3 つの数字は次のように対応しています。ただしこの読み方は慣習的なもので、規格が表記法として定義しているわけではありません¹⁵。

4:2:0 なら上の行の分として 2 個、下の行の分は 0 個です。

引っかかりやすいのが 3 番目の 0 です。並びが Y : Cb : Cr に見えるので「Cr が 0 個」と読んでしまいがちですが、Cb と Cr は必ず同じ数だけ同じ場所にあります。0 が意味しているのは「下の行には色差を置かず、上の行の色差を共有する」、つまり縦方向にも半分に間引いているということです。

4:2:2 との違いも、この最後の数字に表れます。2 番目はどちらも 2 で横の間引き方は同じ、違うのは 3 番目だけです。4:2:2 は下の行にも 2 個置く（縦は間引かない）、4:2:0 は下の行に置かない（縦も間引く）という差です。

そこで引っかかるのが、横は 4 → 2 と個数で減っているのに、縦は 0 になるという非対称です。この非対称は記法の成り立ちから来ています。元は 2 番目が Cb、3 番目が Cr の横の間引きを表しており、縦の間引きは想定されていませんでした。いまは Cb と Cr を同じだけ間引くのが普通なので、2 番目が両方の横の間引きを表し、3 番目は「2 番目と同じなら縦は間引かない、0 なら縦も半分」という印として使われています¹⁵。間引く量は横も縦も同じ半分で、違うのは表し方だけです。

実際にどれだけ間引かれるか

間引く量そのものは規格で決まっています。色差の 2 枚が輝度に対してどれだけ小さいかは、次の 3 通りです³。

横の縮小率は SubWidthC、縦の縮小率は SubHeightC という名前で規格に出てきます³。4:2:0 はどちらも 2、4:2:2 は横だけ 2、4:4:4 はどちらも 1 です。小さくなるのは色差の 2 枚だけで、輝度の幅と高さは変わりません。

なお、色差を横だけ半分にする比率は SD 時代から続いています。当時の規格はサンプリング周波数を輝度で 13.5 MHz、色差でその半分の 6.75 MHz と定めていました⁶。横を 2 分の 1 にしたものが 4:2:2、さらに縦も半分にしたものが 4:2:0 です⁹。

サンプルの並びを形式ごとに見る

輝度サンプルを Y、色差サンプル（Cb と Cr が同じ位置に 1 組）を C として、4 画素 × 2 画素の窓を形式ごとに書き出します。

4:4:4 — 全画素に色差があります。

4:2:2 — 横 2 画素で色差 1 組を共有します。色差は窓の中に 4 組です。

4:2:0 — 2×2 の 4 画素で色差 1 組を共有します。色差は窓の中に 2 組だけです。

まとめた 1 個の値はどう決まるのか

4:2:0 では 2×2 の 4 画素分の色差が 1 個のサンプルにまとまります。その 1 個はどんな値なのでしょうか。

規格が決めているのは、色差サンプルが何個あるかと、輝度に対してどの位置にあるとみなすかまでです³。4 個から 1 個を作る計算はコーデックの規格では決まっておらず、エンコードに入る前の前処理で行います。

一般的なのは、色差の面にローパスフィルタをかけてから間引く方法です。先にならしておかないと、間引きで拾いきれなかった細かい模様が偽の色として現れてしまいます。SD 時代の規格には 4:4:4 から 4:2:2 に落とすフィルタ特性の目安が図で示されており⁶、RGB から色差を作る流れにも「サブサンプリングフィルタ」の段が置かれています⁹。変換ツールでも輝度と色差に別のフィルタを割り当てられます。ffmpeg の bicublin は輝度に bicubic、色差に bilinear を使います¹⁶。

最も単純な例が 4 個の単純平均です。2×2 の Cb が次の値だったとします。

100  104
 98  102

まとめた値は $(100 + 104 + 98 + 102) / 4 = 101$ です。

既定の「2 行の間の高さにある」というのは、上下 2 行の値をまとめた結果が、縦方向にはちょうど 2 行の真ん中を代表している、という意味です。横方向は事情が違い、既定では色差は左側の輝度の列と同じ横位置に置かれます³。そのため規格上の色差の位置は、単純平均の重心（2×2 の中心）から横にずれています。実際のフィルタの重みは、この規格上の位置に合わせて決めます³。

表示するときは、間引きと逆向きの処理を行います。データの上では 2×2 の 4 画素が 1 個の Cb・Cr を共有しているので、デコードのあとで色差を輝度と同じ数まで引き伸ばします。これをアップサンプリング（upsampling）と呼びます。同じ値を 4 つコピーすれば 4 画素は同じ色になりますが、復号側では補間フィルタで隣の色差サンプルとの間をならすので、画面上では 4 画素の色がわずかに違って見えます⁹¹⁷。データ上は 1 個を共有し、表示では補間でなだらかにされる、ということです。

データ量は何%になるか

1 画素あたりのサンプル数は「輝度 1 個 ＋ 色差 2 枚 ÷（横の縮小率 × 縦の縮小率）」で求まります。

4:2:0 は 4:4:4 のちょうど半分です。16×16 画素のブロックで数えると次のようになります。

ここまでの流れを 1 本にまとめると次のようになります。

色差サンプルが横に半分（4:2:2）、さらに縦にも半分（4:2:0）と間引かれていく。バーは 4:4:4 を 100% としたデータ量。4:2:0 では 2×2 の色差 4 個を 1 個にまとめて 2 行の間に置く（図は Cb を単純平均で示したもので、Cr も同じ）。輝度の格子は最後まで変わらない

離散コサイン変換（DCT）や量子化といった圧縮らしい処理を一切かける前に、色差を間引くだけでデータが半分になります。しかも自然な映像では見た目の劣化がほとんど分かりません。これが動画で 4:2:0 が既定になっている理由です。

一方で、彩度の高い細い線や文字（赤地に白抜きの文字など）は 4:2:0 が苦手とする素材です。色の境界を 2 画素単位でしか置けないため、輪郭の色がにじみます。字幕やスクリーンキャプチャで色のにじみが目立つのはこのためです。

ビット深度：8 bit と 10 bit

階調を「階段」として見る

ビット深度 $b$ は 1 サンプルを何ビットで表すかです。黒から白までの明るさの変化を階段に例えると、ビット深度は階段の段数に当たります。段数が少ないと 1 段の高さが大きくなり、なめらかな坂のつもりが段差として見えてしまいます。実際の段の高さが均一でない点は、階段の比喩とは違います。ガンマ補正があるため、1 段あたりの明るさの変化は暗部では小さく、明部では大きくなります。

グラデーションが階段状の縞に見えてしまうこの現象をバンディング（banding）と呼びます。規格の言葉では「階調再現の不連続」です¹⁸。

数えてみる

限定レンジでは、8 bit のとき黒が 16、白が 235 に割り当てられます。10 bit ではそれぞれ 64、940 です⁴。使える階調の段数は次のとおりです。

10 bit は 8 bit の約 3.99 倍の階調を持ちます。1 段あたりの明るさの差が約 4 分の 1 になる、ということです。

段差が見えるかどうかは、1 段上がったときに明るさが元の明るさに対してどれだけの割合で変わるか、という比で決まります。ビット深度を決める基準は、隣り合うコードの間で表示輝度がどれだけ変わるか（再現コントラスト）が、知覚できる最小のコントラストを下回ることです¹⁸。最小知覚コントラスト $\Delta L / L$ は、中程度の明るさでは 1/50 から 1/100 の間です¹⁸（暗い所と非常に明るい所では大きくなります）。段数を 4 倍にすれば 1 段あたりの比は 4 分の 1 になるので、10 bit のほうが余裕を持ってこの基準を満たせます。

コントラストの比だけでは実感がわきにくいので、画面上の帯の幅にも換算しておきます。横 1920 画素いっぱいに黒→白のグラデーションを敷いた場合、1 段分の帯の幅は 8 bit で 8.73 画素、10 bit で 2.19 画素です。8 bit では 9 画素弱の帯が 220 本並ぶことになります。ただしこれは感覚をつかむための換算で、見える／見えないの判定そのものは帯の幅ではなく上のコントラスト比で決まります。

4K / 8K の規格である BT.2020 は、ビット深度を 10 bit または 12 bit と定めています⁵。8 bit は選択肢に入っていません。

H.265 のプロファイルとの関係

そのビットストリームで何を使ってよいかを決める区分を、プロファイル（profile）と呼びます。H.264（AVC、Advanced Video Coding）にもある仕組みで、Apple 端末向けの HLS では、H.264 は High プロファイルが推奨されています¹。H.265（HEVC、High Efficiency Video Coding）では、プロファイルごとに使える色差の形式とビット深度が次のように制限されています²。

つまりこの章で扱った「4:2:0」と「8 bit / 10 bit」は、そのまま H.265 でどのプロファイルを選ぶかを決める条件になります。

プロファイルと組で出てくるのが、解像度やビットレートの上限を決める区分であるレベル（level）と、レベルの中でビットレート上限をさらに分ける区分であるティア（tier）です。Apple 端末で再生する HLS では、H.265 は Main 10 プロファイル、レベル 5.1、High ティア以下でなければなりません¹。互換性を優先する場合はさらに絞って Main 10 プロファイル、レベル 4.0、Main ティア以下が推奨されます¹（2026 年 9 月時点）。

プロファイルとレベルという概念そのものは → 4 章『H.264 の復習：マクロブロック・NAL ユニット・パラメータセット』で、H.265 固有の Main 10 とティアは → 5 章『H.265 で何が変わったか』で扱います。

非圧縮サイズを計算する

式

非圧縮サイズは、ここまでに定義した量を掛け合わせるだけで求まります。「1 フレームの画素数」に「1 画素あたりのサンプル数」を掛けると 1 フレームのサンプル数、それに「1 サンプルあたりのビット数」を掛けると 1 フレームのビット数、さらに「1 秒あたりのフレーム数」を掛けるとビットレート $R$（bit/s）になります。

以下では 1 MB = $10^{6}$ バイト、1 GB = $10^{9}$ バイト、1 TB = $10^{12}$ バイトとします。

1080p / 30 fps / 8 bit / 4:2:0

$= 746.496$ Mbit/s です。バイトに直すと 8 で割って 93.312 MB/s になります。

1 時間の非圧縮動画で 336 GB です。

比較のために、同じ 1080p30 8 bit で色差の形式だけ変えると次のようになります。

4K / 60 fps

$3840 \times 2160$、60 fps、8 bit、4:2:0 では次のようになります。

$= 5971.968$ Mbit/s、約 5.97 Gbit/s です。

10 bit にすると、ビットレートとサイズは単純に 10/8 = 1.25 倍になります。

実際の配信ビットレートと比べる

では HLS（HTTP Live Streaming）で配信される動画は実際どれくらいのビットレートなのでしょうか。HLS では同じ内容をビットレートや解像度の違うストリームとして何本も用意し、プレーヤーが回線状況に応じて切り替えます。この 1 本を変種（variant）と呼びます。変種ごとの平均ビットレートの例として、次の値が挙げられています（2026 年 9 月時点、文書の最終更新は 2025-06-26）¹。

この H.265 の表は 30 fps 基準です¹。したがって比較相手も 30 fps に揃えます。4K30 8 bit 4:2:0 の非圧縮は 2985.984 Mbit/s です。

100 分の 1 から 250 分の 1 という桁です。なおこの表は 30 fps が基準で、24 fps の H.265 ではビットレートを約 20% 下げるのが目安です¹。60 fps なら表の値より多くのビットレートが要ることになります。しかも 4:2:0 にした時点ですでに 4:4:4 の半分になっているので、4:4:4 の生データから数えると 1080p の H.265 で約 332 分の 1 ということになります。

この章の方法で減らせたのは、色差を間引く分の 2 分の 1 だけでした。残りの 100 分の 1 以上の圧縮をどうやって実現するのかは、次章以降で扱います。

ここから先：JPEG との違い

JPEG は非可逆圧縮（lossy）です。データを量子化で粗い段数に落とし、元に戻らない形で情報を捨てることでサイズを縮めています。捨てた情報は復元できないので、保存し直すたびに劣化が積み上がります。一方 PNG は可逆圧縮（lossless）で、展開すれば元のデータが 1 ビットも違わず戻ります。→ 2 章『圧縮の数学：DCT・量子化・エントロピー符号化』では、JPEG が具体的にどの数値を捨てているのかを、DCT・量子化・エントロピー符号化（entropy coding）の順で追いかけます。

そのうえで動画には JPEG に無い軸があります。時間方向です。

• JPEG: 1 枚の画像の中の冗長さ（隣の画素は似ている）を減らす
• 動画: それに加えて、フレーム間の冗長さ（前のフレームと似ている）を減らす

30 fps の動画では、1 秒間に 30 枚のフレームが並びます。カメラが止まっていれば隣り合うフレームはほとんど同じ絵です。100 分の 1 以上という圧縮率の大部分は、隣り合うフレームが「ほとんど同じ」であることを利用して得られます。時間方向の話は → 3 章『フレーム間予測と GOP』で扱います。

flowchart TB
  A["非圧縮 746 Mbit/s"] --> B["色差サブサンプリング<br/>（この章）"]
  B --> C["空間方向の冗長さを削る<br/>DCT・量子化・エントロピー符号化<br/>（2 章）"]
  C --> D["時間方向の冗長さを削る<br/>フレーム間予測<br/>（3 章）"]
  D --> E["配信 4.5 Mbit/s"]

まとめ

• 動画は $W \times H$ の格子に並んだサンプル値を $f_{ps}$ 枚/秒で積み上げたものです。1 サンプルは $b$ ビットの整数です
• RGB は輝度（Y）と色差（Cb、Cr）に変換されます。1080p では BT.709 の係数を使います。rgb(255, 0, 0) は 8 bit で (Y, Cb, Cr) = (63, 102, 240) になります
• 4:2:0 の 3 つの数字は「幅 4 画素 × 高さ 2 画素の窓で、上の行に色差 2 個、下の行に 0 個」を意味します。3 番目の 0 は「Cr が無い」ではなく「縦も半分に間引いている」という意味です。データ量は 4:4:4 の 50% です³
• 色差を間引ける根拠は「桿体が多いから」ではありません。桿体は暗所視の細胞です¹²。根拠は、色の細かさに対するコントラスト感度の限界（11〜12 cycles/deg¹³）が輝度側（50〜60 cycles/deg¹⁴）よりずっと低いことです
• 1080p30 8 bit 4:2:0 の非圧縮は 746.496 Mbit/s、1 時間で 335.9 GB です。配信の目安の一例では 1080p の H.265 は 4500 kbit/s なので¹、約 166 分の 1 に圧縮していることになります
• 10 bit は 8 bit の約 4 倍の階調を持ち、バンディングに強くなります。H.265 の Main 10 プロファイルは 4:2:0 の 8〜10 bit を許します²

1080p30 8 bit 4:2:0 の非圧縮は 746.496 Mbit/s もあって、配信ではそれを約 166 分の 1 まで小さくしている計算になります。4:2:0 で色差を間引いても、データ量は 4:4:4 の 50% までしか減りません。残りの差をエンコーダがどうやって縮めているのかを、次の → 2 章『圧縮の数学：DCT・量子化・エントロピー符号化』から見ていきます。

この章で出てきた用語と規格

出典