要約

  • RFC 5371はmain header、tile-part header、JPEG 2000 packetをpacketization unitと定義し、複数単位を一つのRTP payloadに収めてもcodestream順序を維持するよう求める。大きな単位を分割したpayloadは次の単位を混載できない。
  • 24ビットfragment offsetは各断片の絶対位置を示すが、連続性を証明しない。main headerが失われれば画像はdecodeできず、MHFはheader材料の種類を示しても失われた部分を復元しない。
  • RTP順序、codestream位置、fieldの有効性、拡張契約、decoder結果は別の証跡である。受信済み断片が正順でも、完全な入力や表示画像までは証明されない。

境界を守る規則と配送の事実は違う

RFC 5371はpacketization unitを三種類に分ける。JPEG 2000 main header、tile-part header、そしてJPEG 2000 packetである。送信側は任意個数の単位を一つのRTP packetに入れられるが、codestream内の順序を崩してはならない。

単位がIP、RTP、payload headerを含めてMTUを超えるなら分割できる。ただし、その分割片と後続のpacketization unitを同じpayloadに混ぜてはならない。受信側がどこまでを一つの単位として再構成すべきかを曖昧にしないためだ。

この規則は送信物の構造を守る。ネットワークが全てを届けるとは言っていない。中間のfragmentが失われ、後続単位が正しい順で到着することは両立する。

「観測した順序が正しい」という記録だけでは不十分である。何が期待され、どのbyte区間が届き、どの境界が閉じたかを保存して初めて、欠落を順序の成功から分離できる。

順序は必要条件であり、受領証ではない。仕様がその範囲を狭く保ったからこそ、運用側が勝手に広げてはならない。

sequence numberとoffsetは別の座標軸だった

RTP sequence numberはtransport上の並びを観測する。RFC 5371の24ビットfragment offsetは、JPEG 2000 frameの先頭からpayloadが入るbyte位置を示す。

packetがネットワークで入れ替わっても、offsetを使えばcodestream上の位置へ戻せる。逆にsequenceが連続して見えても、capture開始前のpacketや別sessionの欠落を隠す可能性がある。

scalable deliveryを複数RTP sessionで行う場合、あるsessionで最初に受け取るpacketのoffsetがゼロでないことも正常である。offsetはそのsessionの開始ではなく、共通frameの開始を原点とする。

したがって監視は二つの座標を同一視してはならない。sequence gapはtransport観測、offset gapはcodestream再構成の観測である。layer配置やcapture位置が違えば、両者の原因も違う。

最小の再構成記録は、frame、session、sequence、offset、length、byte hashを結ぶinterval mapである。最大offsetだけを残すと、到達範囲と連続coverageを混同する。

main headerは小さくても支配的だった

RFC 5371はmain headerを失うと画像をdecodeできないと説明する。後続のtile dataが大量に届いていても、その共通parameterがなければdecoderは意味を確定できない。

MHFはpayload内のmain header状態を四つに分類する。ゼロはなし、一は分割headerの途中、二は最後の分割片、三は完全なmain headerを一payloadに含む状態である。

MHF=2のpacketが到着しても、先行片が届いたとは限らない。値二は現在のpayloadが最後の部分だと示すだけだ。MHF=3もheaderについての受領を強めるが、tileや画像全体の到着を保証しない。

header存在、header byteの連続性、parser受理、codestream全体、decode outputを分けて記録すべき理由がここにある。

informative appendixがheaderを他のdataから分けてpackすることを推奨するのは、回復を簡単にするためである。推奨は実施証明ではない。実際のpacket配置と喪失時の挙動を観測する必要がある。

mh_idは拡張なしでは識別権を持たなかった

payload headerには三ビットのmh_idがある。名前だけならmain header世代を識別し、過去のheaderを再利用できそうに見える。

しかしRFC 5371だけを実装する送信側はゼロに設定し、受信側は無視すべきだとされる。main header recoveryの詳細はRFC 5372が与える。

RFC 5372はencoder parameterが同じframeでは同じIDを使い、変化時にincrementし、範囲を超えれば規則に従って戻す。受信側が保持headerを補償に使える条件もそこで初めて形になる。

bitsの存在とsemanticsの発効は別である。parserがmh_id列を出力しても、extensionがnegotiatedでなければrecovery receiptにはならない。

実装監査は、active payload contract、SDP parameter、sender rule、receiver cache generation、補償実行結果を一つのchainとして残すべきだ。

tile番号はTが許可したときだけ読めた

十六ビットtile numberの意味はT bitが制御する。T=0なら有効、T=1なら無効で、receiverは無視しなければならない。

payloadがmain headerだけを含むとき、番号を付けるtile-partがない。複数tile-partを一payloadに詰めたとき、一つの番号では全体を表せない。どちらもT=1が必要である。

fieldのbit patternは残っていても、その値に所属関係を語る権利はない。ログがTを捨ててtile numberだけをindexすると、存在しないtile attributionを作る。

有効性は付属metadataではなく型の一部である。valid(tile 4)とinvalid(multi-tile)は違うobjectとして保存しなければならない。

この原則は障害解析に効く。header-only packetを特定tileの損失へ誤集計したり、multi-tile packetを一regionへ押し込んだりする誤りを防ぐ。

priorityという名前はQoSを発生させなかった

八ビットpriority fieldも同じ罠を持つ。RFC 5371だけのimplementationではsenderは255にし、receiverは無視すべきだとされる。

RFC 5372はprogression、layer、resolution、componentに基づくpriority modeを定める。extension negotiationによって初めて、値はそのcontract内の重要度を表せる。

それでもnetwork schedulerが実際に優遇したことは別証拠である。senderがpriorityを表示したこと、queueが読み取ったこと、packetが優先されたこと、receiverが得たことは四段階に分かれる。

baseline 255を「最高優先度」と読むdashboardは、無視すべきsentinelをservice classへ変換してしまう。

課金やSLAにpriorityを用いるなら、active extension、mapping、scheduler action、lossとarrivalの結果を結ぶ必要がある。field nameだけでは商業的権利を生まない。

各sessionのMarkerは全layerを閉じなかった

RTP Markerはframeの最後のpacketで一になる。複数RTP sessionを使うとき、各sessionのframe末尾でそれぞれ一になる。

一つのframeに複数の終点が存在する。base layer sessionのMarkerはenhancement sessionの状態を知らない。全sessionのMarkerを受けても、内部のpacket lossがないとは限らない。

completionには期待sessionのmanifest、各sessionのterminal marker、interval coverage、そしてquality policyが必要である。

baseだけでusableな場合も、全layerがcontract上必要な場合もある。どちらを採用するかはservice ownerの判断で、Marker bitに委任できない。

first Markerでlatency timerを止めれば指標は速くなるが、測っているのは一sessionの送信境界である。display timeと呼ぶにはdecoderとrenderingのreceiptが要る。

interlaceでは一つのfieldも画像全体ではない

tpはprogressive、odd field、even fieldを区別する。interlaced videoではmain headerのheightは表示画像の半分で、oddと続くevenをde-interlaceして交互のlineにする。

odd fieldが完全に届いても、even fieldが欠ければ表示frameの証明は閉じない。timestampが近くてもpairingとde-interlacingの結果が必要である。

SDPにinterlaceがなければpayloadはprogressiveでtp=0でなければならない。宣言とpacket fieldの一致も検査点になる。

transport packet countをdisplay frame countに変換するpipelineは、field単位とframe単位を混同しやすい。どのlogical objectの終点かを保存しなければならない。

sequenceの正しさはここでも半分の話である。正しいodd sequenceはevenの存在を保証しない。

SDPはdecoderの予約票ではなかった

video/jpeg2000ではRTP clock rateとsamplingが必須である。90 kHzは必須対応で、他のrateも選べる。非90 kHzを希望するsenderは別payload typeで90 kHzも提示することが推奨される。

widthとheightはoptional maximumで、片方を出すなら両方必要である。syntax上は2^32−1まで表せる。大きな数字を受諾したことは、receiverがmemoryを予約した証明ではない。

offer/answerは読み方のenvelopeを選ぶ。実際のframe parameter、decoder version、現在の負荷、resource ceiling、parse result、output qualityはruntime receiptで確認する。

「SDP accepted」を「decode possible」に置き換えると、resource refusalをnetwork faultとして報告することになる。

unspecified parameterはunknownとして扱い、都合の良い実装defaultを観測事実へ昇格させてはならない。

authenticationはcodecの正しさを署名しなかった

RFC 5371はconfidentiality、integrity、source authenticationを区別する。適切なsecurity mechanismはpacketがRTP session memberから来たかを判断できる。

認証されたmemberも、誤ったoffset、矛盾するflag、malformed codestream、過大parameterを送れる。integrityはその誤りを改ざんなしで届けるだけである。

失われたunitは、周囲のpacketがすべて認証済みでも戻らない。crypto receiptとcodec receiptを一つの“secure media”へまとめると、何を確認したかが消える。

2008年のSRTP、IPsec、RTP over TCP向けTLSへの参照は歴史的文脈として扱うべきで、現在のnamed deploymentを示さない。

運用記録は、identity、protected bytes、session context、structural validation、resource decision、decode outputを別欄に持つべきだ。

QoSを名乗ってもloss測定は免除されなかった

RFC 5371はenhanced QoS serviceでもreceiverがpacket lossを監視し、requested serviceが実際に提供されているか確認するよう求める。満たされなければbest effortとみなして動く。

best effortでは、同条件のTCP flowと比べて不公正にならないようrateやlayer subscriptionを適応させ、lossが許容できなければsessionを離れる。

offset gapの原因はnetwork lossだけでなく、意図したlayer削減、subscription変更、capture locationにもなり得る。adaptation logがなければ原因を分けられない。

QoS labelもpriority byteもdelivered resultではない。requested class、observed loss、control action、receiver outcomeが一組になって初めて運用証拠になる。

正しい順序で届いた残りpacketだけを見ても、なぜ一単位が消えたかは分からない。

RFC 9828は早期送信の別問題を扱う

後年のRFC 9828はsub-codestream latency向けのJPEG 2000 payloadを定義し、Main PacketとBody Packet、resync、extended sequence、timing、quality、resolutionのsignalを持つ。

既存のBTW記事は、最初のpacketをencoding完了前に出せてもdisplay latency、recovery、full qualityまでは証明しないという論点を所有する。

本稿は早さを主題にしない。RFC 5371のpacketization unitが順序を保っても、欠落unitとdecoder outcomeが別であるというauthority boundaryを扱う。

RFC 5372も自動追加ではない。mh_idやpriorityの拡張意味はnegotiationと実装証拠が必要である。

三つの文書を一つの理想payloadとして混ぜると、現実には存在しないcapability setを評価してしまう。

最小仕様は境界を再現できなければならない

Lu HengのMinimum Initial Specificationを公開した分析lensとして適用すると、共通仕様の役割は全receiverへ同じ判断を強いることではない。将来のlocal decisionに必要で、後から復元不能な事実を残すことである。

必要なのはSDP contract、frame/session/layer identity、sequence、timestamp、Marker、tp、MHF、mh_id、T、priority、tile、offset、length、byte interval、unit boundary、extension mode、decoder resultである。

各値は関係の中で意味を持つ。tileはTに、priorityとmh_idはextensionに、Markerはsession manifestに、offsetはframe originに依存する。

Reality Layersは推論の停止線を示す。ordered packetはtransport observation、continuous codestreamはreconstruction、parser acceptanceはsoftware result、displayed pictureはproduct eventである。

RFC 5371の順序規則は強い。強いからこそ、それが証明していない欠落と出力を別に残せる。