大、中、小。
三つの箱には、同じ人物が同じ窓辺に立つ場面が入っていた。
大きな箱では、窓の雨粒まで見える。
中くらいでは、雨の線は見えるが、一粒ずつは分かりにくい。
小さな箱では、窓の外がやわらかな色の面になる。
第17話で大容量uploadを止めた直後、Wi-Fi laneが一度だけ大きく広がった。
イトは、最も大きな箱のleverへ手を伸ばす。
イト
道は戻った。次から、いちばんきれいな箱に戻そう
ピコ
戻ったのは、一度だけ？ 続いてる？
ユイ
bufferには、あと二箱です
次segmentのrequestまで、六秒。
道の光は広がり、すぐ細くなり、また広がった。
高画質leverだけが、イトの指先で青く光っている。
同じ場面に、別の重さ
三つの箱は、別の作品ではない。
時間の進み方も同じだ。
同じcontentを、異なるdata量で表したvideo streamの候補だった。
AppleのMultivariant Playlist解説では、同じcontentについて特定のbit rateを持つ複数のvariantを別々のplaylistとして用意し、clientのplayerが測定したnetwork bit rateに基づいて適切なvariantへ切り替える。
bit rateは、一定時間あたりに運ぶdata量の目安だ。
大きいvariantは、同じ時間ぶんでも多くのdataを運ぶ。
細部を残しやすい一方、到着に必要な道の余裕も増える。
小さいvariantはdata量を抑えられる。
細部は減りうるが、同じ時間内に届く可能性を上げられる。
マコト
画面を後からぼかすだけではなく、次にどのstreamを受け取るかが変わるんだね
ピコ
うん。この部屋では、次のsegment requestでvariantを選び直せる
AppleのHLS overviewも、異なるbit rateのalternate streamと、network bandwidthの変化に応じたstreamの切替をHLSの機能として挙げている。
画質を変える主体は、遠いserverが勝手に画面を書き換えるとは限らない。
利用できるvariantの一覧を読み、測定結果から次に何を要求するかをclient/player側が選ぶ仕組みがある。
残り五秒。
上げるか、下げたままか
切替台に、三枚の方針cardが立った。
- 一度の回復を信じ、最大variantへ固定する
- 二度と止めないよう、最小variantへ固定し続ける
- 次は中variantへ下げ、連続した到着とbuffer回復を見てから一段上げる
一つ目なら、雨粒はすぐ戻る。
だが道がもう一度細くなれば、大きなsegmentが到着せず、二箱しかないbufferを使い切るかもしれない。
二つ目なら、必要なdata量は小さくなる。
しかし道が十分広い時間まで、細部を失い続ける。
三つ目は、その間だ。
細くなったときは、次を軽くする。
広がったときは、瞬間だけで飛びつかず、到着が続くかを見る。
このplayerでは、二つの連続segmentが再生による消費より先に届き、bufferが三箱へ戻ったら、次の境界で一段だけ上げる。
二回や三箱は、すべてのplayerに共通する規則ではない。
イトたちが、この不安定なlab laneのために選ぶ説明用policyだ。
ピコ
止まるriskと、細部を失う時間。どちらを、どれだけ引き受ける？
イト
一度広がっただけなら、まだ高画質へは戻さない
残り三秒。
イトは最大variantのleverから手を離した。
中くらいの箱を、次segmentのrequest laneへ置く。
高画質へ戻るgateは、閉じたままにした。
先に下げて、続きを守る
requestが出た直後、道はまた細くなった。
もし最大箱を選んでいたら、残る二箱のbufferを使う間に届くか分からない。
中variantは、細いlaneを進む。
再生がbufferの先頭を一箱使う。
その直後、中variantのsegmentが末尾へ入った。
bufferは空にならない。
screenの人物は歩き続ける。
雨粒の細部だけが減った。
ユイ
止まりません。でも、窓の雨粒は少し消えました
イト
見えなくしたかったんじゃない。続きを切らさない方を選んだんだ
高画質から中画質へ変わることは、この場面では失敗ではない。
playerが利用可能なvariantから、いまの測定とbuffer余裕に合わせて次を選んだ結果だ。
W3C Media Source Extensionsも、applicationがSourceBufferへdata segmentを追加し、system performanceなどに基づいて追加するdataのqualityを適応させられる仕組みを扱う。
ただし、画質を下げれば必ず止まらないわけではない。
最小variantさえ届かないほど道が遅ければ、bufferは減る。
端末の処理やmedia errorなど、network bit rate以外が問題なら、variant変更だけで解決しない場合もある。
この一件で守ったのは、変動するlaneに対するdata量の余裕だった。
一度目の青では、gateを開けない
中variantの一箱目が届いた後、道が大きく広がった。
測定灯が青になる。
高画質leverも点いた。
イトの手が、ほんの少し動く。
大きな箱へ戻せば、次の場面から雨粒が見える。
けれどbufferは、まだ二箱。
広がった測定も、一回だけだ。
イトは手を止めた。
中variantの二箱目をrequestする。
その最中、道は一度細くなった。
大きな箱へ戻していれば、また切替台の手前で待ったかもしれない。
中箱は、再生が次を使い切る前に到着した。
bufferの末尾へ入る。
マコト
一度目の回復で上げなかったから、すぐの揺れに巻き込まれなかった
イト
速さの一枚写真じゃなく、続いたかを見てる
一度の速い測定で上げ、次の遅い測定ですぐ下げる。
それを繰り返せば、画質が細かく行き来し、bufferの余裕も読みにくくなる。
下げる条件と上げる条件を同じにしないpolicyは、こうした往復を抑える考え方の一つになる。
どの指標をどう重ねるかは、playerの実装によって違う。
二つ続いて、三箱へ戻った
道の青が、今度は途切れなかった。
中variantの次のsegmentが、再生より先に届く。
さらに次も、先に届く。
bufferには、三箱の余裕が戻った。
イトが決めた二つの条件がそろう。
- 連続する二segmentが、消費より先に到着した
- bufferが、三箱まで回復した
次のsegment boundaryが光る。
イトはそこで初めて、高variantのlaneを一段だけ開いた。
すでに再生中の中segmentを途中で取り替えない。
次に要求するsegmentを、高variant側から選ぶ。
大きな箱がlaneを進む。
bufferの余裕が残っている間に、末尾へ届いた。
screenは止まらない。
次の場面で、窓の雨粒が一粒ずつ戻った。
止めなかった代わりに、二場面ぶん待った
画面の細部は戻った。
bufferも空になっていない。
その代わり、道が一度広がった後も、二segmentぶんは中画質だった。
高画質へすぐ戻しても届いた可能性はある。
イトのpolicyは、その可能性よりstall riskを抑える側を選んだ。
複数variantを配信側で用意する必要もある。
playerは到着実績やbufferを測り続ける。
切り替えてよい境界をそろえる配信設計も要る。
画質の自動切替は「常に最高を出す」仕組みではない。
利用できる候補の中から、今後も再生を続けられそうなdata量を選び直す仕組みだ。
イト
画質を戻すのが遅れたんじゃない。戻す条件を、止まらない側へ置いた
ピコ
そして条件は、目的やplayerが変われば変わるよ
一つのsegmentから、小さな封筒があふれた
高variantのsegmentが、bufferへ入る直前で透明になった。
一つの大きな箱に見えたdataが、network laneでは細かな単位に分かれている。
同じsegmentを運ぶ小さな封筒が、次々に現れた。
一列ではない。
別々のlaneへ分かれ、同じ宛先へ向かう。
一つが遅れ、後ろが追いつく。
playerが選んだのは、どのvariantのsegmentを要求するかだった。
しかし、そのsegmentのbytesがnetworkを渡るときは、さらにpacketという小さな荷物で運ばれる。
イトは、一枚の雨粒が戻ったscreenと、無数の小さな封筒を見比べた。
イト
一箱を選んだのに、道ではこんなに分かれるの？
ピコ
次は、segmentとpacketを混ぜずに追いかけよう
高画質gateは一段だけ開いた。
その下を、小さな封筒が何本ものlaneへ走っていく。
次回：一つのsegmentは、どう運ばれる？
同じcontentにbit rateの異なるvariantがあれば、client/playerはnetworkの測定やbufferなどを見て次のrequestを選べる。
今回は一度の回復で上げず、連続到着とbuffer回復を待って一段戻した。
その代わり、二segmentぶんの細部を手放した。
次に追うのは、選ばれたsegmentを運ぶ小さなpacket。
次回、ピコルート第19話。
一つのsegmentは、いくつのpacketで届く？
画面のむこう側をもっと知る
variant、bit rate、bufferと画質切替の関係を図で整理するなら、画質が自動で変わる仕組みで確かめられます。