一箱目だけが、映写台へ滑り込んだ。
GET /video/finale/segment-001公開previewまで、あと七秒。
二箱目は光の道を走っている。
三箱目は、その後ろ。
最後の八箱目は、まだ遠いserverの棚から動いていない。
なのにイトは、巨大な「全体到着」のgateへ手をかけていた。
videoは一本の作品だ。
ならば最後までそろわなければ、最初も映せない。
第15話で細い箱が並ぶところを見ても、その思い込みだけは残っていた。
イト
最後の箱まで来たら、再生する
ピコ
それだと、七秒後の画面はどうなる？
ユイ
待っている丸い印のままです
観客席の画面に、白いcountdownが浮かぶ。
六。
一本の動画に、八つの入口
ピコが空中に一枚のplaylistを開いた。
そこには、短いvideo fileの場所が、再生する順番に並んでいる。
segment-001
segment-002
segment-003
...
segment-008AppleのHTTP Live Streaming解説では、stream segmenterが映像を短いmedia fileの列へ分け、index fileにその一覧を置く。clientは選んだstreamのmedia fileを順にdownloadし、十分な量が届いたら、つなぎ直した映像を利用者へ見せる。
この上映室の八箱も、一本の動画を時間順に分けたmedia segmentだ。
一箱は、一場面だけを切り離した意味の単位とは限らない。
けれど再生位置には順番がある。
冒頭の001を飛ばし、遠い008だけ先に映写機へ入れても、最初から続けては見せられない。
マコト
全部で一本でも、運ぶときは短い単位に分けられるんだね
イト
だから一箱目だけ、先に着いたのか
二箱目が到着した。
残り五秒。
「待たない」だけでは、足りない
映写台の前に、三本のleverがせり上がった。
- 八箱すべてがそろうまで待つ
- 001が届いた瞬間に再生する
- 冒頭の連続した箱を少しためてから再生し、後続を受け取り続ける
一つ目なら、始まった後に八箱目まで不足しない。
しかし七秒後のpreviewには間に合わない。
二つ目は、最も早い。
ただし001を再生し終えるまでに002が映写機へ入らなければ、画面はそこで止まる。この上映室では、次の一箱の到着予測がぎりぎりだった。
三つ目は、数箱を待つぶんだけ開始が遅い。
そのかわり、先頭を再生している間に、もう少し先の到着を待てる。
ピコはleverに触れなかった。
ピコ
待つ時間をゼロにするか、最後まで待つか。その間を、イトが決めて
ユイ
何箱あれば絶対安全、という話ではありません。今回は到着予測から選びます
三箱目がlaneの角を曲がった。
残り四秒。
イトは、全体到着gateから手を離した。
001直結leverにも触れない。
透明なtrayを、映写機の手前へ引き寄せた。
三箱ぶんの、短い余裕
一箱目をtrayの先頭へ置く。
二箱目を、その後ろへ置く。
到着した三箱目も、順番を崩さず末尾へ差し込む。
trayの輪郭が、青く点いた。
これが、このplayerのstartup bufferだった。
ここでいうbufferは、再生する少し先のmedia dataを一時的に持つ余裕だ。
第15話のcacheのように、後のrequestへresponseを再利用することが中心ではない。
いま再生する先頭と、すぐ次に必要になるdataを切らさないために置かれている。
W3CのMedia Source Extensionsにも、web applicationがmedia segmentをSourceBufferへ追加し、browserがbufferedな時間範囲を扱う仕組みが定められている。
実際のplayerが再生開始にどれだけためるかは、固定で三segmentとは限らない。
network、segmentの長さ、playerの方針などで変わる。
この上映室では、三箱が七秒以内に作れる小さな開始余裕だった。
イト
全部は待たない。でも、一箱目だけで飛び出しもしない
マコト
先の三箱を持ってから、走りながら続きを受け取るんだね
残り二秒。
イトはplay leverを押した。
同時に、004以降のrequest laneを開いたままにした。
GET /video/finale/segment-004
GET /video/finale/segment-005
GET /video/finale/segment-006最後の箱がなくても、画面は動いた
映写機が001をtrayから取り出した。
観客席の暗い画面に、アニメの冒頭が映る。
公開preview開始。
残り、ゼロ秒。
最終segmentは、まだ届いていない。
それでも映像は始まった。
001を再生している間、004が光の道を進む。
001が終わると、映写機は002を使う。
trayの列は一箱減る。
その末尾へ004が届き、列がまた一箱伸びた。
再生はbufferの先頭を時間とともに消費する。
受信は後続segmentを末尾へ追加する。
全部を先に持つのではない。
減る列を、後ろから補い続ける。
それが、全体のdownload完了を待たずに見始められる仕組みだった。
早さは、待ち時間を消すことではなかった
画面は動いている。
イトは、暗い全体保管庫を振り返った。
八箱を全部入れるだけの棚は、最後まで使わなかった。
だから、観客は作品全体の到着時間を待たずに済んだ。
一方で、イトは001が届いた瞬間にはplayしなかった。
三箱のstartup bufferを作る短い時間は、観客に待ってもらった。
bufferを持つ容量も使っている。
segmentを正しい再生位置へ並べる必要もある。
イト
すぐ見られるって、何も待たないことじゃないんだ
ピコ
うん。全部を待つ時間を、再生に必要な最初の余裕へ縮めたんだ
もし後続の到着が、再生による消費より速いか同じくらいなら、trayの余裕を保ちやすい。
一時的に到着が遅くても、先にためた分があれば、その間は再生を続けられる。
ただし、遅い状態が長く続けば、bufferは減る。
startup bufferは、どんな遅れも消す魔法ではない。
待つ場所を「全体の前」から「必要な少し先」へ変えただけだ。
一箱だけ、赤いlaneへ落ちた
005が末尾へ入った。
映写機は003を使っている。
trayには、まだ先がある。
ところが遠くで、008を運ぶlaneだけが赤く点滅した。
箱が止まる。
006は届いた。
007も届いた。
008だけが来ない。
映写機は一箱ずつ、確実に前へ進む。
bufferの青い列は、三箱から二箱へ減った。
やがて、一箱になった。
ユイ
受信より、再生の方が先へ進み始めました
イト
この一箱を使い切る前に、008が来なかったら？
ピコは答えず、赤いlaneと映写機の間に立った。
画面では、まだアニメが動いている。
だから観客には、遅れが見えない。
手前の一箱が、その時間を隠している。
しかし透明なtrayの底は、もう見えていた。
イトが最後の箱を待たずに始めたから、映像は七秒で動いた。
今度は、始めた映像を止めないための時間が減っていく。
次回：届く速さが、再生に負けたら？
動画は短いmedia segmentとして順に届く。
冒頭の十分な量をbufferへためれば、全体未着でも再生を始められる。
再生中は先頭を消費しながら、後続を末尾へ足していく。
だが008は、まだ赤いlaneにいる。
次回、ピコルート第17話。
bufferが空へ近づくと、なぜ動画は止まる？
画面のむこう側をもっと知る
streaming、media segment、bufferの関係を図で整理するなら、ストリーミングとはで確かめられます。