第88話の作品棚が閉じると、壁いっぱいの番組表が下りてきた。
現在時刻は、二十時二十九分四十二秒。
次の枠は、二十時三十分開始のlive programだ。
雲の上から夜景を映す、十分間の中継。
ユイはテレビを全画面にし、マコトは音を上げた。
イトだけが、番組表の時刻を動かすleverに手を置いている。
第88話で00:00へ動かしても始まらなかった。
なら、番組表を先へ進めればいい。
イトは現在線を、二十秒先の20:30へ押した。
番組枠がcyanに変わる。
screenは暗いままだ。
guide entry loaded 1
scheduled state started
viewer eligible 1
live media segment 0
first frame rendered 0「startedなのに来ない。取りに行く回数が足りないんだ」
イトはplaylist refreshを、一秒に五回へ上げた。
番組表を先へ進めても、映像は生まれない
番組表の枠は、番組名、予定時刻、説明、視聴入口を持つmetadataだ。
その枠自体が、再生できるvideo assetとは限らない。
live programでは、現地のcameraから届いた映像をencodeし、配信用の短いmedia segmentへ順にする。
playerは更新されるmedia playlistを見て、現在取得できるsegmentをrequestする。
program guide
-> current eligibility
-> live ingest / encoder
-> media playlist / segment availability
-> playback session
-> buffer / decode / render予定時刻を迎えても、sourceや最初のsegmentがまだ届いていなければ、screenへ出すframeはない。
反対に、segmentが出てもviewer conditionを通らなければ、そのviewerのsessionは始められない。
guideの時計とmediaの現在地は、結び付くが同じstateではない。
ユイ
番組表は始まったことになったのに、取得できるsegmentはゼロです
マコト
中継先の映像がまだ来ていないなら、こちらの時計だけ進めても増えないね
イト
ぼくは予定を、保存済みepisodeの再生位置みたいに動かしてた
Picoは答えを選ばない。
二十時三十分を指す番組表と、空のmedia railを別々に照らした。
連打が、最初のsegmentを遠ざけた
lab fixtureで許可したplaylist refresh間隔は、四秒だった。
イトは開始前の八秒間に、四十回requestした。
このfixtureは同じviewerからの過剰なrefreshを止め、次の取得を二十時三十分三十二秒まで待たせる。
全serviceが同じ回数やbackoffを使うという意味ではない。
ここで観測するのは、空のplaylistを連打しても未来のsegmentを作れず、かえって次に確認できる時刻を遅らせたことだ。
現地から最初の映像が届いたのは、二十時三十分二十秒。
最初のsegmentがplaylistへ載ったのは、二十四秒。
しかしイトたちのplayerは、まだrefreshできない。
first ingest received 20:30:20
first segment available 20:30:24
next refresh permitted 20:30:32
avoidable wait 8 secondsscreen中央の待機円だけが回る。
予定時刻を先へ動かしたイトが、liveの入口でいちばん遅れていた。
三つの始め方
二十時三十分十六秒。
あと八秒で最初のsegmentが公開されることを、イトたちはまだ知らない。
暗いscreenの前に、三枚のroute cardが開いた。
イト
A。refreshをさらに増やし、startedになるまで空のplaylistをたたく
イト
B。保存されている予告映像を、説明せずliveとしてscreenへ出す
イト
C。時計の強制と予告bypassを閉じ、許可された間隔でcurrent segmentを待つ
Aは、番組表のstartedをmedia availabilityに変えられない。
Bならすぐ映像は出るが、いま起きていることではない。
Cは暗いscreenをすぐには消せない。
遅延を隠さず、届いたものだけをliveとして扱う選択だ。
開始に間に合わせるという約束は、もう守れない。
それでもイトは、早く見せたふりをする二つのrouteへ手を伸ばさなかった。
イトがfuture clockを戻し、current segmentを開いた
イトは左手で、番組表を先へ進めるfuture-clock leverを現在位置へ戻した。
同じ手で、予告映像からscreenへ抜けるamber bypassを閉じる。
右手は、playlistに実在するcurrent segmentだけを通すcyan gateへ置いた。
画面には、隠さず状態を出す。
番組は開始予定時刻を過ぎています。映像を待っています。
Picoはcurrent clockと空のrailの間を照らすだけで、gateへ触れない。
イトが四秒のrefresh間隔を設定し直す。
二十時三十分三十二秒。
playerがplaylistを取り直した。
guide entry 1
viewer eligibility 1
playback session 1
available segments 2
first segment sequence 540
available sequence range 540-541
live edge time 20:30:32最初から見るならsequence 540。
いまのlive edgeへ飛ぶなら、sequence 541の末尾へ近づく。
後者なら現在へ近づけるが、sequence 540の冒頭を飛ばす。
イトはsequence 540を選んだ。
失った八秒を、内容を捨てて取り戻さない。
画面は映った。時計は8秒ずれた
最初のsegmentがbufferへ入り、decodeされる。
雲の切れ間から街の灯りが見えた。
映像の中の時計は、二十時三十分二十四秒。
labの時計は、三十二秒。
first frame rendered 1
duplicate segment 0
preview shown as live 0
viewer playhead 20:30:24
live edge 20:30:32
distance from live edge 8 secondswatch partyは始まった。
けれど、八秒前のliveだ。
「ライブ」は、全員のscreenが現地と同じ瞬間を映すという意味ではない。
capture、encode、package、delivery、buffer、renderに時間がかかる。
playerが安定のために少しbufferを持つ場合もある。
遅れの大きさや作り方はservice、device、network、player policyで変わる。
このfixtureの八秒を、すべてのinternet TVへ一般化しない。
マコト
始まった。でも、僕たちは現地より八秒後ろだ
イト
連打で失った八秒を、予告や飛ばしで隠さない。今日は冒頭を残す
ユイ
成功しても、開始に遅れた結果は消えませんね
live edgeへ追いつくか、連続した映像を残すか
一分後も、viewer playheadはlive edgeの約八秒後ろにいる。
追いつく方法は一つではない。
途中を飛ばしてedgeへ移動できるplayerもあれば、再生速度を少し変えるplayerもある。
seekを許さず、一定の遅れを保つserviceもあり得る。
今回のfixtureでは、自動追従を使わない。
イトは冒頭からの連続を残し、八秒の遅れを受け入れた。
playback continuity kept
jump to live edge no
content skipped 0 seconds
latency residue 8 seconds同じ「liveを見る」でも、現在へ近いことと、内容を落とさないことは別の優先だ。
遅れをゼロにする操作を、いつでも正解にしない。
見逃しは、liveの巻き戻しとは限らない
番組表の下には、catch-up pendingの小さな枠がある。
live playlistに過去のsegmentが残っている間、playerが一定範囲をseekできる場合はある。
しかし、それだけで終了後の見逃し配信が保証されるわけではない。
終了後に保存assetを作るか。
いつから、いつまで公開するか。
どのviewerへ許可するか。
live windowとは別のpolicyや処理が入る場合がある。
program ended does not mean catch-up ready
segment buffered does not mean archive published
guide entry exists does not mean playable now番組表、live中のseekable range、終了後のcatch-up assetを一つの「巻き戻し」にしない。
テレビ画面でも、放送波とは限らない
雲の中継は、internet pathを通っている。
番組表metadataも、media playlistも、segmentsもnetworkから取得した。
同じテレビには、antennaから届く放送も映る。
見た目が同じscreenでも、入口は同じとは限らない。
放送は映るのにinternet TV appだけ止まる。
guideは出るのにlive segmentだけ来ない。
laptopでは続くのにテレビだけ止まる。
症状を、すべて「テレビが壊れた」へ戻さない。
guide → eligibility → source / playlist → session → home path → playerのどこまでgreenかを、一段ずつ見る。
同じliveが、テレビだけ止まった
二十時三十二分。
ユイのlaptopでは、夜景が流れ続けている。
テレビだけが、同じ一枚で止まった。
番組表は更新されている。
live playlistにも、新しいsegmentが増えている。
live source active 1
laptop next frame 1
television next frame 0イトはfuture-clock leverを見なかった。
番組表も巻き戻さない。
壁の入口からテレビへ伸びる、一本の青い線へ目を移した。
線の途中には、小さな光の箱、黒いrouter、無線の空間がある。
同じliveの一方が動いているなら、止まった側の最後の道を分けて見る。
イトは青い線の入口へ走った。
八秒遅れの夜景は、laptopだけで流れ続けている。
次回、ピコルート第90話。
イトは、テレビだけ止まった青い線をどこで切り分ける？｜光回線と家の入口