透明なtrayに、最後の一箱が残っていた。
映写機は、その箱を引き込む。
bufferは空になった。
遠いlaneの向こうで、008だけが橙色に点滅している。
画面の人物が、振り向きかけた姿勢で止まった。
音も消える。
丸い読み込み印が、静止したframeの上で回り始めた。
イト
来なかった。最後の一箱を使い切ったから？
ピコ
いま再生したい位置の、すぐ先を見て
ユイ
続きのdataがありません
復旧確認まで、あと二十秒。
イトの右手は、赤いmaster resetのcoverへ伸びた。
TVも、appも、routerも、Wi-Fiも。
全部いったん止めてやり直せば、どれかは直る。
どれが詰まったかは、その後で考えればいい。
bufferの底で、時間が止まる
ピコが、停止位置を一本の白い線で照らした。
線の左には、再生済みのframeがある。
右には、何もない。
008がまだbufferへ追加されていないからだ。
W3C Media Source Extensionsのbuffer監視では、現在の再生位置を含むbuffered rangeがその位置で終わり、直後を覆うrangeがない場合、media elementはHAVE_CURRENT_DATAへ移り、timelineを先へ進めるdataがないため再生を一時停止する。
WHATWG HTML Standardのwaiting eventも、次のframeがまだ利用できず、後で届くと見込まれるためplaybackが止まった状態を扱う。
画面が壊れたから、必ず止まるのではない。
serverが落ちたから、ともまだ決められない。
いま観察できるのは一つだけだ。
再生位置の直後に必要なdataがなく、playerが続きを進められない。
マコト
止まった現象と、届かなかった理由は分けるんだね
イト
bufferが空なのは見える。でも、なぜ008が来ないかはまだ見えない
残り十八秒。
全部を変えると、答えまで消える
master resetの下に、四本のcableが集まった。
TV。
app。
router。
network。
一度にresetすれば、運よく再生が戻るかもしれない。
けれど、四つの状態が同時に変わる。
直っても、どれが効いたか分からない。
直らなくても、四つのどこを次に見るべきか分からない。
しかもappの起動とrouterの再接続を待つ間、停止中のrequestとbufferの状態は消える。
ピコが、reset coverの横に三枚のcardを置いた。
- TV、app、router、Wi-Fiを一度に再起動する
- 遠い配信serverの遅れだと決めて、そのまま待つ
- 停止状態を残し、同じstreamを端末と経路だけ変えて比べる
一つ目は、原因の手がかりごとresetする。
二つ目は、serverだという証拠がまだない。
三つ目は、比較の回数だけ時間を使う。
ただし、結果の違いが出た場所から、詰まりの範囲を狭められる。
ピコ
二十秒で、何を直す？ 何を残す？
ユイ
同じところと、変えるところを一つずつ決めましょう
残り十六秒。
イトはmaster resetから手を離し、赤いcoverを閉じた。
停止したTVとrequestは、そのまま残す。
「同じ動画で比べる」
一本目：別の端末、同じWi-Fi
イトはphoneを取り出した。
TVと同じWi-Fiへつながっている。
同じ時刻、同じstreamの同じ続きへrequestを送る。
GET /video/finale/segment-008phoneのrequestも、橙色になった。
bufferは増えない。
画面には、同じ読み込み印。
TVだけでなく、別の端末でも同じWi-Fi経路では遅れた。
これだけでphoneとTVに同じ故障がないとは証明できない。
それでも「TV一台だけの問題」という範囲は、前より弱くなった。
イト
端末を変えても、同じWi-Fiだと来ない
マコト
変えたのは端末。残したのはstreamと無線の道だね
残り十二秒。
二本目：同じrouter、違う入口
次にイトはlaptopを、一本のEthernet cableで同じrouterへつないだ。
配信serviceも、streamも、要求するsegmentも変えない。
家の外へ出るrouterは同じ。
変えるのは、端末からrouterまでをWi-Fiで渡るか、cableで渡るかだ。
三台のrequestを、ほぼ同時に並べる。
TV → Wi-Fi → router → segment-008
phone → Wi-Fi → router → segment-008
laptop → cable → router → segment-008laptopのlaneだけが青く点いた。
008が届く。
TVとphoneの無線laneには、まだ橙色の待ちが残る。
同じ時刻に、同じrouterの外側から同じstreamを有線で受け取れた。
少なくともこの瞬間、配信serviceからrouterを通ってlaptopへ届く道は動いている。
二台のWi-Fi側だけが遅れる差が出た。
「serverが全部止まった」と決めるより、端末からrouterまでの無線区間を先に見る根拠ができた。
ユイ
有線だけ届いた。だから、Wi-Fi区間に違いがあります
ピコ
そう。ただし、まだ『Wi-Fiの何が原因』までは決めない
残り八秒。
止めるのは、一つだけ
イトは無線laneを見た。
TVの横で、使っていないと思っていたtabletが光っている。
写真の大きなbackupを、同じWi-Fiでuploadしていた。
無線の道には、TVのsegment requestだけがいるわけではない。
同じradio channelを使う機器や近くのnetworkなど、Wi-Fiの利用状況は通信の余裕へ影響しうる。AppleのWi-Fi router設定資料も、同じchannelを使うrouterやdeviceによるinterferenceをnetwork環境の要因として挙げている。
ただし、目の前のuploadが今回の停止原因かは、見つけただけでは決まらない。
tabletを再起動する必要もない。
routerの設定を全部変える必要もない。
イトは、大容量uploadだけを一時停止した。
ほかは変えない。
TVから、もう一度008をrequestする。
残り五秒。
橙色だったboxが動いた。
routerを越え、Wi-Fi laneを抜け、TVの空だったbufferへ入る。
buffered rangeが、停止位置の右へ伸びた。
playerがwaitingを抜ける。
画面の人物が、振り向き終えた。
音が戻る。
今回分かったのは「今回の道」
復旧確認まで、あと一秒。
TVのbufferに、008の続きが加わった。
previewは同じ位置から進んでいる。
今回の観察は、こうつながった。
- TVのWi-Fiでは、同じstreamが止まった
- phoneの同じWi-Fiでも、同じstreamが止まった
- 同じrouterの有線laptopでは、同じstreamが届いた
- 大容量uploadだけを止めると、TVのWi-Fiでも届いた
だから、この一件では無線区間の利用状況が停止へ関与した可能性が高い。
「動画が止まる原因は、いつもWi-Fiだ」とは言えない。
別の日ならappかもしれない。
端末処理かもしれない。
回線、配信service、segmentそのものの問題かもしれない。
比較したのは、この時刻の、このstreamの、この経路だ。
イト
原因を当てたんじゃない。違いが出る境目まで、道を狭めたんだ
マコト
一つ止めて、同じ条件でもう一度届くか確かめた。そこまでが今回の結果だね
観客を待たせた時間は、十六秒。
比較requestは三回。
全部resetするより、手数は増えた。
しかし、次に同じ差が出たとき、最初から四つ全部を変えずに済む。
直ったという結果だけでなく、どこまで届いていたかが残った。
三つの大きさが、入口へ並んだ
再生が安定すると、008の後ろに三つの箱が現れた。
どれも同じ次の場面。
一つは大きく、光の粒が細かい。
一つは中くらい。
一つは小さく、軽そうだ。
無線laneは、いまは空いている。
けれどtabletのuploadを再開すれば、また余裕は変わる。
playerの選択台が、三つの箱の前で左右に揺れた。
イト
同じ場面なのに、どうして三つもあるの？
ピコ
道が変わったとき、止まる以外の選択をするためだよ
赤いmaster resetは、最後まで閉じたまま。
その隣で、三つの大きさだけが青く光っている。
次回：playerは、どの箱を選ぶ？
buffered rangeが現在位置で終わり、直後のdataがなければ、再生は先へ進めない。
止まった理由は一つに決めず、同じstreamを端末と経路だけ変えて比べる。
今回、差が出たのはWi-Fi区間だった。
次に現れたのは、同じ場面を入れた大・中・小の箱。
次回、ピコルート第18話。
画質は、誰がいつ切り替える？
画面のむこう側をもっと知る
動画が止まるときのbufferと切り分けを図で整理するなら、動画が止まる原因で確かめられます。