スマホの 画面は、ものすごく 小さな 点が たくさん ならんで できて います。よこに 1920こ、たてに 1080こ ならぶ 画面が あります。

点 1こに つき、色を 表す 数字が 24こ いります。1まいの 絵で、およそ 5000万この 数字です。どうがは、その 絵を 1秒に 30まい ぐらい 見せます。ぜんぶ かけると、1秒で およそ 15おくこです［1］。

ところが、ふだんの どうがは、1秒に 500万こ ぐらいの 数字で とどいて いる ようです。1まいぶんの 数字よりも、1秒ぶんの ほうが 小さい、ということです。

この 500万は、ある どうが会社の 一つの れいです。どうがの 中身や 時代で かわります。

画面は、横1920個・縦1080個の小さな点でできた「1080p」を例にします。点1つの色は24ビット（0か1が24個）で表します。

1コマは1920×1080×24＝約4977万ビットです。これを1秒に30コマ見せると、1,492,992,000ビット、つまり約1.49Gbpsになります。毎秒60コマなら、その2倍の約2.98Gbpsです［1］。掛け算だけなので、自分でも検算できます。

いっぽう、配信サービスの実際の速さは、数Mbpsといわれます。ある大手サービスでは4〜6Mbps程度とされ、5Mbpsで計算すると、圧縮しない場合の約300分の1です［1］。これは二次資料にある一例で、内容や時期で変わります。

1秒ぶん（約500万ビット）が、圧縮前の1コマぶん（約4977万ビット）の約10分の1しかありません。どうやって、ここまで減らせるのでしょうか。

1コマは1920×1080×24＝49,766,400ビット。これに毎秒30コマを掛けると1,492,992,000ビット毎秒（約1.49Gbps）、毎秒60コマなら約2.98Gbpsになる［1］。単純な掛け算で、検算できる。

一方、配信サービスの実際の速度は数Mbps程度とされる。ある大手のH.264配信は4〜6Mbpsという記述があり、5Mbpsで割ると約300分の1（1.49Gbps÷5Mbps≒299）だ［1］。ただし4〜6Mbpsは二次資料にある一例で、公式の固定値ではなく、映像の内容や時期で変わる。

1秒ぶん（約500万ビット）が、圧縮前の1コマぶんの約10分の1にすぎない。この差を作る技術は、1980年代後半以降の主要規格（H.26x系、MPEG系）で、空間方向のDCTと時間方向の動き補償を組み合わせる形に共通している［2］。

人の 目は、あかるさの ちがいには 気づきやすい けれど、色の こまかい ちがいには あまり 気づきません［5］。

そこで、あかるさは そのままに して、色の 数字は 少ない 点だけに します。たとえば 4つの 点に つき、色は 1つぶんだけ 書きます。ぜんぶの 数字で 見ると、およそ 半分に なります。

もう 1つ、絵を 小さな ますに 分けて、こまかい もようの ぶぶんを あらく して、すてて しまう やりかたも あります［4］。ちょっと 見ただけでは、ちがいが 分かりにくい ところです。

1つ目の工夫は、色の情報を減らすことです。人の目は、明るさの変化に比べて、色の細かい違いに鈍いことが知られています［5］。

映像は、明るさ1つと色2つの情報に分けて持つことがあります。4:2:0という方式では、色の情報を明るさより少ない点数で記録します（縦横それぞれ半分にした形で、色の点の数は4分の1）。明るさは減らしません。私が、3つの成分を8ビットずつと仮定して計算すると、1点あたり24ビットが12ビットになり、全体では約半分です。

2つ目はDCT（離散コサイン変換）です。8×8画素などのブロックを、粗い模様と細かい模様の成分に分け、目立ちにくい細かい成分を粗く記録したり、捨てたりします。1972年に提案され、JPEG（1992年）や、動画の規格の土台になりました［4］。

ここまでは、1枚の絵の中の無駄を減らす話です。次は、コマとコマの間に目を向けます。

空間方向の圧縮には主に2つある。1つ目はクロマサブサンプリングで、人の視覚が明るさの変化に比べて色の変化に鈍いことを使う［5］。4:2:0では色差成分を輝度より少ない点数（縦横とも半分）で記録する。輝度・色差2成分を各8ビット、1点24ビットと仮定して筆者が計算すると、4点あたり（輝度4＋色差1＋色差1）×8＝48ビットで、1点あたり12ビット。減るのは色の成分だけで、全体は約半分だ（4分の1ではない）。

2つ目は離散コサイン変換（DCT、りさんコサインへんかん）だ。8×8画素などのブロックを周波数成分に分け、視覚に目立ちにくい高周波成分を粗く量子化したり捨てたりする。1972年に提案され、JPEG（1992年）とH.26x・MPEG系の土台になった［4］。

これらは1枚の中の冗長さを削る手法で、コマ間の似ている部分は、次章の時間方向の予測が扱う。

どうがは、絵を 1秒に 30まい ぐらい ならべた ものです。となりの 絵は、たいてい ほとんど 同じです。空も かべも、あまり かわりません。

そこで、どうがの ほとんどの 絵は、「前の 絵と ちがう ところ」だけを 書いて おきます［3］。まちがいさがしで、ちがう ところだけ 丸を つける ような ものです。ただし ほんとうは、ちがう ところを、ますごとに 計算で 見つけて います。

ほかの 絵に たよらず、1まいで ぜんぶ 書いて ある 絵も あります。それを Iフレーム と いいます。前の 絵から 作る ものを Pフレーム、前と 後ろの 絵から 作る ものを Bフレーム と いいます［3］。

動画のとなり合うコマは、たいてい大部分が同じです。そこで、前のコマの似た部分を手がかりに、変わった部分だけを記録します。これが時間方向の圧縮で、動き補償と呼ばれます［2］。

コマの種類は3つあります［3］。

• Iフレーム：ほかのコマに頼らず、1枚で完結する画像。JPEGのようなもの。
• Pフレーム：前のコマから予測して、変わった部分だけを記録する。
• Bフレーム：前後のコマから予測して、さらに小さくできる。

多くの動画では、PやBが使われます。ここでいう「差」は、予測とのずれのことです。1枚を丸ごと書く回数を減らして、予測との差だけで済ませることが、大きな節約になります。

もし途中から再生を始めるなら、どのコマから始めればよいのでしょうか。

時間方向の圧縮は、前後のコマの類似部分を予測に使う動き補償だ。DCTによる空間方向の圧縮と組み合わせる方式は、1980年代後半以降のH.26x・MPEG系の主要規格に共通する［2］。

コマは3種類に分けられる［3］。Iフレーム（アイ・フレーム）は他のコマに依存しない自己完結した画像で、JPEGのようなもの。Pフレームは、マクロブロック（小さな正方形の区画）ごとに、それ以前に復号したコマの領域から予測する。Bフレームは前後のコマを使い、さらに小さくできる。

予測との差だけを記録するため、PやBは小さくなる。ただし、Pは前のコマがないと復元できない。この性質が、途中から再生できる仕組みとどう関わるかを次章で見る。

「前の 絵と ちがう ところ」だけを 書いた 絵は、前の 絵が ないと、元に もどせません。だから、とちゅうから 見ようと しても、そのままでは 見られません。

そこで、とちゅうから 見はじめる 目じるしに できる Iフレームが、ときどき 入れて あります。Iフレームは 1まいで ぜんぶ 書いて あるので、Iフレームからなら、そこを はじめの 絵として 見はじめられます［3］。

どこに いくつ 入れるかは、作る ときに 決められて います。

差だけを書いたPフレームは、前のコマが手元にないと復元できません。もし動画の途中の、Pフレームだけを渡されたら、絵は作れません。

そこで、動画にはIフレームなどが混ぜてあります。Iフレームは、ほかのコマに頼らない完全な画像で、途中から再生を始める地点（ランダムアクセス点）として使えます［3］。動画のシークバーを途中に動かしたとき、少し待つことがあるのは、こうした仕組みが関わっているのかもしれません。

Iフレームを多くすれば途中から始めやすくなりますが、そのぶんデータが大きくなります。少なすぎると、その逆です。実際の間隔は、作る側が決めます。

Iフレームは他のコマに依存しない完全な画像で、デコーダがそこから復号を始められるランダムアクセス点として配置される（常に開始点になる保証まではない）［3］。Pフレームだけの区間は、直前のコマがなければ復元できないので、途中から再生を始める地点としては使えない。

Iフレームを増やせばシークしやすくなるが、1枚ごとのデータが大きいので、ビットレートは上がる。少なくすると、その逆だ。挿入の間隔は規格で固定されず、エンコードする側の設定による（本稿の資料からは具体的な値は確認していない）。

ここまでで、1枚の中の無駄と、前後のコマの似ている部分という2つの圧縮の考え方がそろった。これを実際の部品にしたものが、次章の規格とコーデックだ。

ここまでの 考え方を、みんなで 同じ ルールに して、書いた ものが あります。その ひとつが H.264 です。2003ねん5月30日に、ITU-Tと いう ところが 決めた ことが 書かれて います［6］。

H.264 は 「きまり」です。その きまりを 使って、実さいに 小さく したり、もとに もどしたり する 部品は、ほかに 作られて います。この 部品を、コーデックと いいます［2］。

おかしの 作り方の 本と、実さいに 作る 人の ちがいと 同じです。同じ きまりで 作る 部品でも、作った 人が ちがえば、少しずつ できが かわります。

H.264（AVCとも呼ばれます）は、ITU-TとISO/IECの専門家が共同で作った規格で、ITU-Tは2003年5月30日に承認しています［6］。ここまでに見た色の間引き、DCT、動き補償を組み合わせた形です。

ここで大切なのは、規格とコーデックが別のものだという点です。H.264は「書き方の決まり」で、それを実際のプログラムにした具体的な部品が、コーデックです。たとえば、OpenH264はH.264を実装した部品の一つです［2］。

コーデックは、圧縮して小さくする側と、元に戻す側の両方をまとめて指す言葉です。同じ規格でも、実装によって速さや画質は変わりえます。

H.264（AVC）は、ITU-T VCEGとISO/IEC MPEGの共同チームが作り、ITU-Tが2003年5月30日に承認した規格だ［6］。1章で述べた空間方向と時間方向の組み合わせを、規格として定めたものと位置づけられる［2］。

規格（形式）とコーデック（実装）は別の概念だ。コーデックは、エンコード（符号化）とデコード（復号）をする部品で、H.264は規格、OpenH264はそれを実装した具体的なコーデックにあたる［2］。Cという言語とGCCというコンパイラの関係に近い、という説明がある。

規格は出力の形を定め、どう圧縮するかの工夫（動きの探し方など）には、実装ごとの余地が残る。同じ規格でも、実装によって画質と処理時間が変わりうる。

小さく した どうがを、ネットで おくる ときは、ながい 1本の まま おくりません。数秒ぐらいの 短い 区切りに 切って おくって います。たとえば 6秒ぐらいに 切る やりかたも あります［7］。

どの 区切りを、どの じゅんばんで 見るか。それを 書いた 「ならべた 表」も いっしょに おくります。見る 人の スマホは、その 表を 見ながら、区切りを 1つずつ もらって、つなげて 見ます［7］。

この やりかたの 名前は、HLS です。ふつうの ホームページと 同じ きまりで とどけられるので、ふつうの ホームページの サーバーからでも おくれます。

圧縮した動画は、長い1本のファイルのままではなく、短い区切り（セグメント）に分けて置かれます。それを順に並べた一覧が、プレイリストです。プレイヤーは、この一覧を読んで、区切りを順にもらいながら再生します［7］。

この方式の一つがHLS（HTTP Live Streaming）です。Appleが作った方式で、通常のHTTP（ふつうのWebと同じ通信）で動くため、ふつうのWebサーバーやCDN（各地に置かれた配信用のサーバー）から届けられます［7］。

区切りの長さは規格で固定されていません。6秒程度の区切りを使う実装もあります［7］。

短く区切ると、どんな得があるのでしょうか。

HLSはAppleが開発した配信方式で、RFC 8216に仕様がまとめられている。動画を短いメディアセグメントに分け、メディアプレイリストがそれを順に並べた一覧になる。順に再生すると、一つの映像として見える［7］。

通信は通常のHTTPなので、専用の配信サーバーを立てなくても、ふつうのWebサーバーやCDNから届けられる。区切りの長さは規格で固定されず、6秒程度の区切りを使う実装もある［7］。

セグメントに分ける利点は、区切りごとに別の画質を選べることにある。これは次章の適応型配信の前提になる。

おくる がわは、同じ どうがを、きれいさが ちがう 何しゅるいかで、さいしょから 用意して おきます。ネットが 速いときは きれいな もの、おそいときは 小さな ものを つかえば、止まらずに 見られます［7］。

その どれを 使うか えらぶのは、見る がわの スマホです［8］。区切りごとに、「この 速さなら まにあう」ものを えらんで、もらって いきます。

くつやさんが 大きさの ちがう くつを 何足も 用意して、お客さんが 自分の 足に 合う ものを えらぶ 感じです。ただし ほんとうは、人が えらぶのでは なく、スマホの 中の プログラムが 自動で えらんで います。

だから、見て いる ときに、きゅうに ぼやけたり、また きれいに もどったり することが あります。

HLSでは、同じ動画をいくつかの画質（バリアント）で用意しておきます。見る側の機器が回線の状況を見ながら切り替えて、途切れずに、なるべくよい画質で再生し続けることをねらいます［7］。

ほかにも、2012年にISO/IEC 23009-1として国際規格になったMPEG-DASHという方式があります。こちらも通常のHTTPで、ふつうのWebサーバーが使えます。見る側の機器が、再生が止まらない範囲で、ダウンロードが間に合う最も高いビットレートの区切りを選びます［8］。

ポイントは、選ぶのが送る側ではなく、受け取る側だということです。送る側は、たくさんの選択肢を並べておくだけです。

動画を見ていて、急に画面がぼやけたあと、しばらくして鮮明になるのは、区切りごとに別の画質が選ばれている結果かもしれません。

HLSは、複数のバリアント（画質・ビットレート違いの版）を用意し、受信側が現在のネットワーク状況に合わせてビットレートを適応させることで、途切れない再生を最良の品質で保つことをねらう［7］。

MPEG-DASHは2012年にISO/IEC 23009-1として国際規格になった、HTTPによる適応型配信方式で、ふつうのWebサーバーで配信できる。クライアントはビットレート適応アルゴリズム（ABR）で、再生停止を避けられる範囲で、ダウンロードが間に合う最も高いビットレートのセグメントを、区切りごとに自動で選ぶ［8］。

要点は、選択の主体が送信側ではなく受信側にあることだ。サーバーは選択肢を並べ、クライアントが自分の回線状況に応じて選ぶ。

個別の実装の中身（どんな指標でどう切り替えるか）は、サービスごとに異なるとみられる。ここでは規格の枠組みまでを述べた。

ノートに 絵を かいて みましょう。空に くもが ひとつ、山と 家が あります。

同じ 絵を もう 1まい かきます。こんどは、くもだけ 少し 右に ずらします。2まいを ならべて、友だちに まちがいさがしを して もらいます。

ちがう ところは、くもの ぶぶんだけ でしたね。どうがでは、前の コマを 使う ものは、かわった ところを 中心に 書いて います。

気が むいたら、山や 家も 動かして みましょう。ちがう ところが 多いと、書く ことも 多く なります。

ノートに、空に雲が1つ、山と家がある絵を描きます。同じ絵をもう1枚描き、今度は雲だけを少し右にずらします。2枚を並べて、友だちにまちがいさがしをしてもらいます。

違う場所は雲の部分だけです。動画のPフレームは、これと同じ考えで、変わった部分だけを記録しています。今度は山や家も動かして、違う場所が増えると、書くことがどれだけ増えるかを比べてみてください。

もう一つ、家にあるもので試せます。ノートのはしに、パラパラ漫画を数ページ描き、動く部分と動かない部分を色分けしてみてください。動かない部分は、最初の1枚に書けば足りると気づけます。

差分の実験は、紙とペンでできる。同じ絵を1枚描き、もう1枚は一部だけ変えて、合計2枚にし、違う場所の数を数える。変化が小さいほど、Pフレームに記録する内容は少なくなるという考え方を、手で確かめられる。

数字の実験もある。自分の使う画面の縦横の点の数に24ビットと毎秒30コマを掛けて、生の映像の速さを求め、実際に使っているサービスの数Mbpsで割ってみる。倍率が、1章の約300分の1と同じ桁になるかを見る。

原典に当たるなら、HLSのRFC 8216［7］、H.264のITU-T勧告［6］が一次資料だ。いずれも英語だが、区切りと一覧の構造や、規格の位置づけを確認できる。ISO/IEC 23009-1（MPEG-DASH）は、Wikipediaの解説［8］から出典をたどれる。