47。
network台のcounterが、青く点滅した。
screenで待っている次の場面は、一つ。
窓辺の人物が、雨へ手を伸ばす六秒ぶんだ。
第18話でイトが選んだ一つの高variant segmentは、bufferへ入る直前で透明になった。
中から、小さな封筒があふれ出す。
一個、二個、三個。
床を埋めたところで、counterは47を示した。
イト
一つのsegmentを選んだのに、47個もある
ユイ
bufferには、47場面と記録するんでしょうか
ピコ
そのsegmentと、このpacket。同じ単位だと思う？
bufferの受付が閉じるまで、十二秒。
入力欄は一つしかない。
segment count。
イトの指が、47へ伸びた。
六秒ぶんの箱と、道を走る封筒
上段の透明棚に、元の長箱が残っている。
雨の場面、六秒ぶん。
これはplayer側で見る media segment だ。
W3C Media Source Extensionsは、media segmentを、media timelineの一部分についてpacket化されtimestampを持つmedia dataを含むbytesの並びとして定義している。
playerは、そのbytesを解析してcoded frameをtrack bufferへ加える。
この「segment」は、再生するmediaの時間と構造を扱う側の単位だ。
床を走る47個は、別の境界で区切られている。
networkを渡るための小さな単位だ。
同じsegmentやpacketという語が、層によって別のものを指す場合がある。
それを一つの箱として数えると、見えている数字は合っても、意味がずれる。
マコト
一冊の本と、配送中の四十七包みを、同じ冊数欄へ入れるようなものか
イト
包みが47でも、本が47冊とは限らない
ピコ
今の違いを、通信の層で確かめよう
残り十秒。
このlaneでは、TCP over IPv6で追う
47個の封筒が、三段の透視台へ上がった。
最上段には、六秒ぶんのmedia segment。
中央には、一本につながった青いbyte ribbon。
下段には、networkを走る小さなpacket。
今回のlabは、TCP over IPv6という一例に絞る。
実際のstreamingがすべてTCPを使うわけではない。
HTTPのversionやtransport、暗号化、OSやnetwork機器の処理も重なる。
ここでは、media segmentのbytesがnetwork packetと一対一ではないことを見るため、ほかの層を一時的に透かしている。
TCPの仕様であるRFC 9293では、applicationのbyte streamがTCP segmentでnetworkへ運ばれ、それぞれのTCP segmentがIP datagramとして送られると説明している。
TCP segmentにはTCP headerとdataがある。
そのTCP segmentをpayloadとして、外側にIP headerが重なる。
IPv6の仕様であるRFC 8200では、IPv6 packetに40-octetのbase headerがあり、その後ろにpayloadが続く。
入れ子にすると、こう見える。
- 外側: IPv6 headerと、そのpayload
- payloadの中: TCP headerと、そのdata
- TCP dataとして運ばれるもの: application byte streamの一部
- byte streamの中でapplicationが読むもの: media segmentのbytes
packetの封筒を開けば、小さな雨の絵が一枚ずつ入っているわけではない。
入っているのは、長いbytesのある範囲だ。
境界は、一粒の雨や一枚のvideo frameと一致するとは限らない。
残り七秒。
47を、どこへ書くか
仕分け台が三枚の処理cardを出した。
- 47個すべてを、別々のmedia segmentとしてbufferへ数える
- 同じ雨場面の札なので、一個だけ残して46個を捨てる
- networkでは47 packet、TCPではbyte stream、playerでは1 media segmentとして別々に数える
一つ目なら、counterの数字はそのまま使える。
だがnetwork packetの途中をmedia boundaryだと誤認する。
labの影screenには、解析できない断片が47個の場面枠へ無理に押し込まれた。
雨の人物は現れず、青い欠片だけが点滅する。
二つ目なら、同じ場面札の重複を消せる。
けれど一個のpacketは、media segment全体のbytesを持っていない。
残り46個を捨てれば、長箱の大半が戻らない。
三つ目なら、counterを三つに分けなければならない。
受信側でnetwork headerとtransportの情報を処理し、applicationへbyte streamを渡す。
media parserが一つのsegmentとして読めるbytesの境界まで、勝手に場面数を増やさない。
ピコ
同じ数字を一か所へ入れる方が速い。でも、何を数えた数字？
イト
47は道を走る数。一場面の数じゃない
残り四秒。
イトは、segment countへ47を入れなかった。
一つしかない入力欄のcoverを閉じる。
上段のmedia segment札を、一枚だけ残した。
47個の封筒は、下段のnetwork counterへ送る。
中央のbyte ribbonには、最初から最後まで切れ目なく並ぶ場所を作った。
封筒を外し、bytesへ戻す
最初のIPv6 packetが、受信台へ着く。
外側のIPv6 headerが処理され、そのpayloadにあるTCP segmentが次へ渡る。
TCP側はheaderを読み、dataをapplication byte streamの位置へ置く。
二個目、三個目、四個目。
青いribbonが伸びていく。
この一件では、47個すべてが受付期限までに届いた。
欠落や再送は、ここでは起こさない。
第3話で扱った「足りない一箱」とは別に、全部そろっても単位を混ぜれば間違える場面へ焦点を合わせる。
ユイ
networkでは47回受け取っているのに、mediaの時間はまだ一場面なんですね
イト
封筒の境界を、画面の境界にしない
最後のpacketからdataが外れる。
一本のbyte ribbonが、上段の長箱の端までつながった。
media parserが、そのbytesを一つのmedia segmentとして受け取る。
playerのbufferへ入った箱は、一つ。
network counterは、47増えた。
media segment counterは、1増えた。
screenは47回点滅しない。
窓辺の人物が、雨へ手を伸ばす六秒ぶんを、一度だけ進んだ。
47枚のheaderを引き受けた
screenには、雨粒の細部まで戻った。
bytesも捨てていない。
その代わり、47個のIP packetには、それぞれ運ぶためのheaderが付いた。
TCP headerも、それぞれのTCP segmentに必要になる。
小さく運ぶほど、payloadだけの巨大な一箱に比べてheaderの割合が増える場合がある。
送受信側は、層ごとの状態と境界を扱う。
一方で、network pathには一度に運べる大きさの上限がある。
RFC 9293も、path上の最小MTUより大きいIP datagramを避けることを、TCPが小さいsegmentを送る目的の一つとして挙げている。
ただし、47は標準値ではない。
media segmentのdata量、transport、header、path、実装で数は変わる。
同じ一場面でも、高variantならpacketが多くなりうる。だが「高画質は必ず47個」という意味ではない。
また、packet一個を見て「これは雨粒」「これは人物の手」と対応づけることもできない。
encoded mediaの構造とnetwork packetの境界は、別に決まる。
マコト
分けた数だけ、運ぶための外側も増えるんだね
イト
でも外側の数に、映像の意味まで決めさせない
ピコ
何の単位かを言えれば、同じsegmentという言葉にも迷いにくい
47個すべてに、二つのaddress欄
役目を終えたIPv6 headerが、受信台の上へ並んだ。
どれにも、二つの長い欄がある。
source address。
destination address。
イトには、まだ光の模様にしか見えない。
同じmedia segmentを運んだ47個は、同じdestinationへ向かったように見える。
けれど、途中の門は「雨の場面だから右」と判断したわけではない。
mediaの意味を読まず、外側のaddressを手がかりに次の道を選んだ。
配送門の向こうに、無数の数字の案内板が立ち上がる。
イト
中身が一つの場面だと知らなくても、届け先は選べるの？
ピコ
次は、packetの外側にあるdestinationを読もう
上段には、一つのmedia segment。
下段には、47個のIP packet。
その全部で、destination addressの欄が同時に光った。
次回：47個のpacketは、どこを目指す？
一つのmedia segmentと、network上を走るpacketは同じ単位ではない。
このlabのTCP over IPv6では、media segmentのbytesを含むapplication byte streamがTCP segmentへ区切られ、IP packetとして運ばれた。
イトは一つのcounterを使わず、networkでは47、playerでは1として境界を守った。
その代わり、47個ぶんのheaderと、層を分けて扱う手間を引き受けた。
次に読むのは、すべてのpacketの外側で光るdestination address。
次回、ピコルート第20話。
47個のpacketは、どこを目指す？
画面のむこう側をもっと知る
header、payload、分割と再構成を図で整理するなら、パケットとはで確かめられます。