YouTubeの ヘルプには、どうがは 見ている ばしょに あわせて、きれいさが じどうで ととのえられる、と 書いて あります［1］。

では、どうやって かえて いるのでしょう。まず、おなじ どうがが、きれいさを かえて 何しゅるいも 用意されて います。そして どうがは、数びょうの みじかい 区切りに わけて あります［3］。

スマホは、区切りの つなぎめで、「つぎは どの きれいさに しよう」と えらぶ ことが できます。くつやさんで、足の大きさに あわせて サイズを えらびなおす ような ものです。ただし ほんとうは、えらぶ ものは くつでは なく、どうがの データです。

だから、きれいさが かわる ときは、区切りの つなぎめで かわります。

同じ動画が、何段階もつくられている

YouTubeの公式ヘルプは、動画の画質は視聴環境に合わせて自動で調節される、と説明しています［1］。これは、動画の側に仕掛けがあるからできることです。

HLS（ネット配信の方式の一つ）の規格RFC 8216では、同じ内容を別の品質で用意したものを「バリアントストリーム」と呼びます。再生側は、通信の状況に合わせて、バリアントを切り替えるべきだとされています［2］。切り替えの計算のしかたは、規格では決められていません［2］。

数秒の区切りで選び直す

MDNの解説では、適応型の配信は、品質の違うファイルを、時間ごとの区切りに分けて複数用意しておく仕組みです。プレイヤーは各ビットレートの一覧を見て、適したものを自動で選びます［3］。

区切りの長さは、HLSの規格では典型例として10秒が挙げられています。実際の配信では、これより短いこともあります［2］。つまり、画質を切り替える場合は、区切りの境目で起きます。ここまでで、画質を決めているのはスマホ側で、選び直せるのは数秒の区切りの境目だと分かりました。では、選ぶ手がかりは何なのでしょうか。

HLSのマスタープレイリストは、同一内容の別バージョンであるバリアントストリームの一覧を示し、クライアントは通信状況に応じてバリアントを切り替えるべきとされる。ただし切り替えの具体的な計算方法は規格の範囲外だ［2］。各バリアントは同じ内容を同じ時刻で並べなければならない（matching timestamps）ため、区切りの境目で入れ替えても映像はつながる［2］。

区切り（メディアセグメント）の最大長はEXT-X-TARGETDURATIONで示され、典型的な値は10秒とされる。固定値ではなく、実装によって6秒などのこともある［2］。MDNも、品質違いのファイルを時間ごとの区切りに分けて複数用意し、プレイヤーが各ビットレートの帯域を書いた一覧（MPD、またはHLSのindex）から自動で選ぶと説明し、特別なサーバー機能は要らないとする［3］。YouTubeの公式ヘルプも、画質は環境に応じて自動調節されると述べる［1］。ただしYouTube内部の切り替え計算は、公式資料で示されていないため、ここでは扱わない。

以上から、画質を切り替えるなら、それは区切りの境目の出来事だと分かる。では、何を手がかりに選べばよいのか。

いちばん かんたんな やり方は、ネットの はやさを はかって、それに あう きれいさを えらぶ ことです。

でも、はやさを ただしく はかるのは むずかしいと、Netflixと スタンフォード大学の けんきゅうでは いわれて います［4］。ネットの はやさは、かんがえるより ずっと こまかく ゆれうごくからです。

もし ほんとうの はやさより きれいな ほうを えらぶと、どうがの データが たりなくなり、ざいりょうを ためた ぶんが どんどん へって、とまって しまいます［4］。

では、ずっと いちばん ひくい きれいさに すれば いいのでしょうか。それなら とまりにくいですが、いつも ぼやけたままです。とまらない ことと、きれいな ことの あいだで、スマホは まよって いるのです。

見積もりは、思ったより当てにくい

Netflixとスタンフォード大学の研究者らが2014年に出した論文では、各動画はいくつもの再生レートで用意されています。当時の目安は、235kb/sから5Mb/sまででした。235kb/sから5Mb/sまでは、およそ21倍の開きです。再生側は、通信の状況を見て、このうちどれにするかを選びます［4］。この選択を、ABR（適応型ビットレート選択）と呼びます。この数字は2014年当時の例で、今の値ではありません。

通信の容量を正確に見積もるのは難しい、と論文は述べています。通信の制御がいくつも重なって動くので、測った値が実際とずれやすいからです［4］。

2つの失敗のあいだ

通信の容量よりも高い画質を選ぶと、ためた動画が減っていき、やがて再生が止まります。これをリバッファといいます。反対に、いちばん低い画質で流し続ければ止まりにくくなりますが、画質は低いままです［4］。

「止まらない」と「きれい」の間でうまく選ぶには、速さの見積もりより、もっと確かな手がかりがほしい。そこで研究者たちは、別のものを見ることにしました。

Huangらの論文によれば、各動画は複数の再生レートで符号化され、クライアントが通信状況を監視して選ぶ。この選択がABR（適応型ビットレート選択）だ。論文が挙げる例は235kb/s（SD）から5Mb/s（HD）で、およそ21倍（5000÷235≒21）の幅がある［4］。ただしこれは2014年当時のNetflixの例で、現在の値ではない。

利用可能な容量の見積もりには、HTTPの制御ループ、ABRの制御ループ、TCPの輻輳制御が相互に作用するため、困難が多いと論文は指摘する［4］。見積もりが外れたときの失敗は2種類ある。容量より高いレートを選べば、バッファが減ってリバッファ（再生停止）が起き、最低レートに固定すれば止まりにくいが画質は低い［4］。つまり、速度の推定だけに頼る設計は、止まるか、ぼやけるかの二択に追いこまれやすい。

そこで論文は、推定が難しい量に頼るのをやめ、クライアントが確実に知っている量、つまりバッファの量に着目した。

スマホは、まだ 見ていない どうがを、先に すこし ダウンロードして ためて います。この ためた ぶんを、「バッファ」と いいます。

ためた ぶんが すくないうちは、いちばん ひくい きれいさを えらびます。ふえて くるほど、すこしずつ きれいな ほうを えらびます［4］。

この やり方を、Netflixで 数百万人の 人が つかう 中で ためすと、とまる 回数が、むかしの やり方より 20%ほど へったと ほうこくされました［4］。これは Netflixの その ときの やり方との くらべで、いつも そうなるという 意味では ありません。

どうがが はじまった ばかりの ときは、ためた ぶんが ほとんど ありません。だから はじめは ぼやけて いることが おおい、と かんがえられます。ためて いくうちに、きれいに なって いくのです。

バッファの量を、画質の合図にする

この論文が提案したのは、通信の速さの見積もりをほとんど使わず、手元にためた動画の量を主な手がかりにして画質を選ぶ方式です。ためた量が少ないうちは最低の画質を選び、量が増えるにつれて、画質を少しずつ上げていきます［4］。

Netflixでの数百万人規模の実験では、この方式は、当時のNetflixの標準方式と画質を同程度に保ったまま、再生が止まる割合を約20％減らしたと報告されています［4］。これはNetflixの当時の方式との比較で、どんな場合にも20％減る、という保証ではありません。

余裕をもたせる理由

大きな区切りをダウンロードしている最中に通信が急に遅くなると、画質を切り替える前にバッファが尽きることがあります。そのため、最低の画質を選び続ける「余裕」の量を持たせます。論文の実験では、区切りは4秒でした［4］。

動画の始まりがぼやけやすい理由

再生を始めた直後は、バッファが空です。この間は、ためた量が少ないので、低い画質から始まります。この時期だけは、直近の通信の速さからの簡単な見積もりも役に立つ、と論文は述べています［4］。動画の最初がぼやけやすいのは、このためだと考えられます。

Huangらが提案した方式は、バッファ量Bに応じて画質（レートR）を決める。0≦B≦reservoirのあいだは最低レートRminを要求し、reservoirが満ちたあとは、バッファが増えるにつれて線形に画質を上げる［4］。論文の説明用の例ではreservoirは90秒だが、実装では動画などに応じて計算され、8〜140秒に制限された。論文の実験での区切りは4秒だった。

reservoirが必要な理由は、大きな区切りのダウンロード中に通信が急に遅くなると、画質を切り替える前にバッファが尽きうるからだ［4］。Netflixでの数百万人規模の実験の結果、この方式は画質を同程度に保ったまま、当時の標準方式よりリバッファ率を約20％減らしたとarXiv版の要旨は述べる［4］。ただし20％はNetflixの当時の方式との比較で、他のサービスや他の条件での保証ではない。

ここで注意したいのは、バッファ方式が速度の見積もりを完全に捨てたわけではない点だ。定常状態では容量の見積もりは不要だが、開始直後はバッファが空なので、直近の通信速度による簡単な見積もりが重要になるとされる［4］。再生開始直後の画質が低めになりやすいのは、この仕組みの帰結と考えられる。

ここまでの説明では、画質の段の数字（たとえば5Mb/s）を、区切りごとに一定の大きさとして扱ってきた。実際はそうとも限らない。

「この きれいさは 1びょうに 〇〇の データ」と きまって いても、じっさいは すこし ちがいます。その 数字は、へいきんだからです［4］。

たとえば、おなじ 4びょうの 区切りでも、うごきの すくない 場面は データが すくなく てすみます。うごきの おおい 場面は、データが おおく なる ことが あります。どうがや ちぢめ方で ちがいます。

どうがは、1まい 1まいの え（コマ）を ぜんぶ おくる のでは なく、前の コマとの ちがいだけを きろくする ことが あります［7］。ちがいが おおいほど、きろくする ものが ふえる、と かんがえられます。

ただし、これは 仕組みからの せつめいで、すべての どうがで そうなるとは かぎりません。

画質の数字は「平均」

配信される動画の多くは、可変ビットレート（VBR）で作られています。画質の段に書かれた数字（公称のレート）は平均で、実際のデータの大きさは、その平均のまわりで上下します。そのため、同じ画質の段でも、区切りごとにデータの大きさは同じではありません［4］。

動きが多いと、なぜ大きくなりやすいか

動画圧縮では、前の画像との差だけを記録する方法があります。Pフレームは前の画像との差を、Bフレームは前後の画像との差を記録します。コマの間で共通するデータは、取り除けます［7］。

この原理から考えると、動きが激しい場面では差が大きくなり、記録するデータが増えることがあります。映像や圧縮方式によって異なります。これは差を記録するという原理からの説明で、出典が明言しているわけではありません。

平均では足りていても、データの大きい区切りでは足りなくなる。次は、この食い違いが、作品によってどれだけ違うかを見ます。

実際の配信動画はVBRで作られ、画質段の公称レートは平均値で、瞬間的なレートは平均のまわりで変動する。その結果、同じ画質段でも、区切りのデータサイズは一定にならない［4］。たとえば公称5Mb/sで4秒の区切りなら、平均で約2.5MB（5000kbit×4秒÷8）だが、これは平均の話で、個々の区切りの大きさは前後する。

変動の理由は、フレーム間予測の原理から説明できる。AWSの解説によれば、Pフレームは前の画像との差、Bフレームは前後との差を記録し、フレーム間で共通するデータ（時間冗長性）は削除できる［7］。差が大きい場面ほど、記録する量が増えると推論できるが、これは差分記録の原理からの説明で、出典が明示するものではない。

このことは、バッファ方式の設計にも関わる。区切りごとにサイズが異なるので、同じ画質段を選び続けても、ダウンロードにかかる時間は区切りごとに違う。だから、見積もりと現実のずれを吸収する余裕（リザーバー）が必要になる、と整理できる。

では、段そのものの設計はどうか。全作品に同じ段の組み合わせを使うことに、問題はないのか。

Netflixは、むかし、どの作品にも 同じ きれいさの「はしご」を つかって いました。ところが 2015ねんに、作品ごとに はしごを かえる やり方を はっぴょうしました［5］。

わけは こうです。いちばん たかい 5800キロビットの きれいさでも、むずかしい えいぞうでは、四角い ブロックのような ざらつきが 見えました。いっぽう、アニメの ような たんじゅんな えいぞうでは、5800は ひつよう いじょうでした［5］。

ひらたい 色や はっきりした ふち、うごきの すくない えいぞうは、ちぢめやすい といわれます。つぶつぶした 感じや、はやい うごき、たくさんの 人が いる 場面は、ちぢめにくい といわれます［6］。おなじ はしごが、アニメでは あまり、はげしい 場面では たりない れいが、かいせつに のっています。

おなじ 数字の きれいさでも、えいぞうに よって「たりる」「あまる」が あるのです。

全作品に同じ「はしご」を使うと

Netflixは従来、全作品に共通の画質のはしご（ラダー）を使っていましたが、2015年に、作品ごとの複雑さに合わせる方式を発表しました。難しい映像では、最高の5800kbpsでもブロック状の乱れが見え、アニメのような単純な映像では、5800kbpsは必要以上だった、と説明されています［5］。

この話は、Netflix自身の発表そのものではなく、解説記事を通して知ったものです。この節は、解説記事にもとづいています。

圧縮しやすい映像、しにくい映像

Fora Softの解説によると、平たい色やはっきりした縁、動きの少ない映像は圧縮しやすく、粒子感や速い動き、群衆は圧縮しにくいとされます。固定のラダーは、ビットレートを固定して品質のほうを動かす方式です。解説記事は、同じラダーがアニメでは過剰になり、アクション場面では不足する例を挙げています［6］。

節約できた量として、作品別で約20％、場面別でさらに約28〜38％（コーデックによる）という報告もありますが、条件つきの報告値です。一般則ではありません［6］。

Netflixは従来、全作品に共通の画質のラダー（レートの組み合わせ）を使っていたが、2015年に作品ごとの複雑さに合わせる方式を発表した。解説記事（Streaming Learning Center、2016年）によれば、複雑な映像では最高の5800kbpsでもブロックが見え、アニメのような単純な映像では5800kbpsは過剰だった［5］。5800kbpsは5.8Mb/sで、4秒の区切りなら平均約2.9MB（5800kbit×4秒÷8）にあたる。同じ数字が、作品によって足りたり余ったりする。この節は二次資料にもとづく。

Fora Softの解説は、平たい色・明確な縁・動きの少ない映像は圧縮しやすく、粒子感・速い動き・群衆は圧縮しにくいとし、固定ラダーは「ビットレートを固定して品質が動く」方式だと整理する。同じラダーは、アニメには過剰で、アクションには不足するという［6］。節約率は、作品別で約20％、場面別でさらに約28〜38％（コーデックによる）との報告だが、条件つきの値で一般化はできない［6］。

ここで、ここまでの結論を重ねる。画質が途中で変わるのは、(1)区切りごとにスマホが選び直す、(2)選ぶ手がかりはバッファの量が中心、(3)同じ段でも映像の複雑さで足りなくなる、の3つが組み合わさるためと説明できる。(3)は、画質の「段」が変わらなくてもざらつきが目立つ場面がありうる、という点で、(1)(2)の話と別の現象だ。

どうがを 見ながら、きれいさが かわる ところと、ざらざらして 見える 場面を、さがして みましょう。目が つかれない よう、ときどき やすんで ください。

1つ目は、きゅうに ぼやけた ときです。それは、はじまった ばかりの ときですか。それとも、とちゅうですか。

2つ目は、ざらざらして 見える 場面です。しずかな 場面ですか。うごきの おおい 場面ですか。

ただし、場面と ざらつきの かんけいは、かならず そうなる わけでは ありません。気づいた ことを、メモして みましょう。

動画を見るとき、画質に注目してみましょう。一つ目は、画質が切り替わった瞬間です。それは再生を始めたばかりの頃でしたか。それとも途中でしたか。

二つ目は、画質は同じなのに、ざらざらして見える場面です。静かな会話の場面と、動きの激しい場面を比べてみてください。

ここで見えるのは、仕組みからの予想です。そうなるとは限りません。気づいたことを、「いつ」「どんな場面」でメモしておくと、あとで資料と照らし合わせられます。長く見て目が疲れないよう、ときどき休んでください。

同じ動画を、スマホとパソコンなど別の画面で見比べて、画質が変わる場面の違いを書き留めてみるのもよいでしょう。

観察するなら、動画を見ながら、(a)画質が切り替わった時刻（再生開始直後か途中か）と、(b)同じ画質のままざらつきが目立つ場面（静かな会話か、動きの激しい場面か）を、分けて記録するとよい。(a)はバッファと容量の話、(b)は映像の複雑さの話で、原因が別だと予想できる。ただしこれは仕組みからの予想で、個々の動画でそうなるとは限らない。長く見て目が疲れないよう、休みを入れること。

資料を読むなら、切り替えの規格上の位置づけはRFC 8216［2］、仕組みの全体像はMDN［3］、バッファ方式の設計と実験はHuangらの論文［4］が出発点になる。固定ラダーの限界は、二次資料［5］［6］から、Netflixの原文やコーデックごとの比較へ進める。YouTubeを含む各サービスの実際の選択ロジックは公開された資料が少なく、さらに調べる価値のある問いだ。