Zusammenfassung

  • RFC 5371 enthält ein acht Bit großes Prioritätsfeld, weist Basisimplementierungen aber an, 255 zu senden und den Wert beim Empfang zu ignorieren. Prioritätsmodi für Progression, Schicht, Auflösung und Komponente gehören zum Erweiterungsvertrag RFC 5372.
  • Auch unter der Erweiterung beschreibt das Feld Wichtigkeit im Payload. Es belegt weder eine Queue-Aktion noch Lieferung. Dafür braucht es Aushandlung, Mapping, Scheduler-Entscheidung und gemessenes Ergebnis.
  • Dasselbe Autoritätsprinzip gilt für mh_id, Tile-Gültigkeit, Header-Flags, Fragment-Offsets und Session-Marker: Bits, Vertrag, Transport, Decoder und Anzeige müssen getrennt belegt werden.

Ein Name kann mehr Autorität vortäuschen als ein Feld besitzt

„Priority“ klingt wie eine unmittelbare Anweisung an Router und Queues. Der Name lädt dazu ein, aus einem Byte eine Dienstklasse abzuleiten.

RFC 5371 begrenzt diese Lesart. Wer nur diese Spezifikation implementiert, sollte 255 senden; der Empfänger sollte das Feld ignorieren. Der Wert hält einen Platz im Header frei, ohne im Basisvertrag eine Verarbeitungsentscheidung zu tragen.

RFC 5372 aktiviert zusätzliche Semantik. Es beschreibt verschiedene Prioritätsordnungen entlang von JPEG-2000-Schichten, Auflösungen, Komponenten und Progressionsfolgen. Diese Modi müssen als Teil des erweiterten Vertrags verstanden werden.

Ein Analyzer, der jedes RFC-5371-Paket mit 255 als „höchste Priorität“ klassifiziert, kehrt den Standard um. Er macht aus einem zu ignorierenden Basiswert eine wirksame Policy.

Protokollanalyse muss deshalb mehr speichern als Bits. Sie muss wissen, welcher Vertrag aktiv war. Ein Feldname ist kein Beweis seiner Aktivierung.

Aushandlung, Absicht, Aktion und Ergebnis sind vier Stufen

Selbst wenn RFC 5372 ausgehandelt wurde, endet die Beweiskette nicht am Prioritätswert. Das Byte drückt eine durch das gewählte Mapping bestimmte Wichtigkeit aus.

Danach muss eine Transport- oder Queue-Policy den Wert tatsächlich lesen. Sie muss ihn in eine Aktion übersetzen. Schließlich muss gemessen werden, ob die bevorzugten Daten mit anderem Verlust, anderer Verzögerung oder höherer Verfügbarkeit ankamen.

Diese vier Stufen sind getrennt: Extension ausgehandelt; Senderwert gültig; Scheduler handelte; Receiver erhielt Ergebnis. Ein Log der ersten zwei darf die letzten zwei nicht behaupten.

Das ist besonders wichtig für kommerzielle QoS. Ein Anbieter kann einen gesetzten Wert zeigen, ohne bevorzugte Lieferung nachzuweisen. Abrechnung und SLA sollten auf beobachtbarer Behandlung und Ergebnis beruhen.

Ein Source-Feld ist eine Absichtserklärung. Es ist keine Quittung des Netzes.

Der Standard verlangte Messung trotz QoS

RFC 5371 verpflichtet Receiver auch bei verbessertem QoS-Service, Paketverlust zu beobachten und zu prüfen, ob der angeforderte Dienst tatsächlich geliefert wird. Wenn nicht, sollen sie Best Effort annehmen und entsprechend reagieren.

Unter Best Effort muss der Fluss Verlust und Fairness gegenüber TCP berücksichtigen. Mögliche Reaktionen sind geringere Rate, weniger abonnierte Schichten oder das Verlassen der Session.

Diese Regel widerspricht der Vorstellung, ein Prioritätswert genüge. Der Standard verlangt gerade den Vergleich zwischen deklarierter Behandlung und gemessener Lieferung.

Ein fehlender Layer kann aus Netzverlust, bewusster Congestion-Anpassung oder geänderter Subscription entstehen. Das Byte-Intervall zeigt die Lücke; der Control-Log erklärt die Entscheidung.

Ohne beide Belege wird verantwortliche Degradation zum Fehler erklärt oder echter Verlust als Policy kaschiert.

mh_id war ebenfalls nur unter Erweiterung aktiv

Der dreibitige mh_id trägt einen ähnlich suggestiven Namen. Er scheint eine Main-Header-Generation zu identifizieren.

Im reinen RFC-5371-Vertrag sollte der Sender null setzen und der Receiver den Wert ignorieren. RFC 5372 definiert erst, wann IDs gleich bleiben, wann sie bei geänderten Encoderparametern steigen und wie ein Receiver gespeicherte Header zur Kompensation nutzen darf.

Bits sind Format; Recovery ist Verhalten. Zwischen beiden liegt der ausgehandelte Vertrag.

Ein Dashboard darf mh_id=0 nicht als erfolgreiche Nutzung von Headergeneration null melden. Es muss Extension-Parameter, Headerhash, Cachegeneration und tatsächliche Kompensationsentscheidung kennen.

Andernfalls entsteht eine private Semantik, die Interoperabilität und spätere Diagnose an ein einzelnes Produkt bindet.

MHF beschrieb Material, nicht vollständige Wiederherstellung

Das zweibitige MHF zeigt an, ob ein Payload keinen Main Header, einen nicht letzten Fragmentteil, den letzten Fragmentteil oder einen ganzen Main Header enthält.

Der letzte Teil kann eintreffen, obwohl ein früherer verloren ging. MHF=2 bleibt dann wahr, der Header bleibt unvollständig. MHF=3 beweist einen vollständigen Header in diesem Payload, aber nicht die restlichen Bilddaten.

RFC 5371 erklärt, dass ein verlorener Main Header das Dekodieren des Bildes verhindert. Kleine Headerbytes besitzen damit mehr Interpretationsautorität als ihre Größe vermuten lässt.

Monitoring braucht Headerintervalle, Parse-Ergebnis und die vom Decoder verwendete Parametergeneration. Paketanzahl oder Gesamtbytes reichen nicht.

Die informative Empfehlung, Header separat zu packen, erleichtert Recovery. Sie belegt nicht, dass der Sender so arbeitete oder dass Recovery gelang.

Der Offset koordinierte, aber quittierte nicht

Der 24-Bit-Fragment-Offset misst vom Anfang des JPEG-2000-Codestreams. Er sagt, an welche Byteposition der aktuelle Payload gehört.

Bei skalierbarer Lieferung über mehrere RTP-Sessions kann das erste Paket einer Session einen Offset ungleich null tragen. Der Ursprung ist das gemeinsame Frame, nicht der lokale Sessionbeginn.

Diese Präzision macht Lücken sichtbar. Sie füllt sie nicht. Ein später hoher Offset beweist keine kontinuierliche Abdeckung davor.

Die richtige Struktur ist eine Intervallkarte pro Frame, Session und Layer. Sie zeigt empfangene Bereiche, Gaps, Überschneidungen und widersprüchliche Bytes.

Der Grund einer Lücke bleibt separat: Verlust, Layer-Abwahl, Capture-Standort oder Senderfehler. Priorität liefert diese Kausalität nicht.

T entzog dem Tilewert die Leseberechtigung

Das Tile-Feld umfasst 16 Bit. Das T-Bit entscheidet, ob es gültig ist. Bei T=1 muss der Receiver den Tilewert ignorieren.

Nur Main Header im Payload bedeutet: keine Tile-Part vorhanden. Mehrere Tile-Parts bedeuten: ein einzelner Wert kann sie nicht vertreten. In beiden Fällen ist T=1 vorgeschrieben.

Die Bits können trotzdem wie eine Zahl aussehen. Ohne Gültigkeit dürfen sie nicht in Statistiken eingehen.

Ein Analytics-Schema, das T verwirft und tile_number behält, produziert falsche räumliche Attribution. Das Problem ist nicht fehlende Präzision, sondern unzulässige Präzision.

Gated values sollten gemeinsam gespeichert werden: gültiger Tilewert oder ungültig mit Grund. Erst dann bleiben spätere Auswertungen erklärbar.

Ein Session-Marker war nicht das Ende aller Layer

Der RTP Marker steht im letzten Paket eines Frames. Bei mehreren RTP-Sessions markiert jede Session ihr eigenes letztes Framepaket.

Ein Basislayer kann enden, während ein Enhancement-Layer weiterläuft. Alle Marker können eintreffen, obwohl innerhalb einer Session ein Paket fehlt. Eine erwartete Session kann ganz fehlen, wenn das Layer-Manifest nicht erhalten blieb.

Completion erfordert erwartete Sessions, terminalen Marker je Session, Bytecoverage und eine Qualitätsregel. Für einen Dienst mag der Basislayer genügen; ein anderer verlangt alle Layer.

Ein Timer, der beim ersten Marker stoppt, misst das Ende einer Sessionbeitrags. Er misst weder Decoderabschluss noch Display.

Auch hier beweist ein Feld nur seinen benannten, begrenzten Gegenstand.

Packetization schützte Reihenfolge und Grenze

RFC 5371 nennt Main Header, Tile-Part Header und JPEG-2000-Packet jeweils packetization unit. Mehrere Einheiten dürfen ein RTP-Paket teilen, solange ihre Codestream-Reihenfolge erhalten bleibt.

Eine zu große Einheit darf fragmentiert werden. Ein Fragmentpayload darf nicht zugleich die nächste Einheit enthalten. Dadurch bleibt die Grenze rekonstruierbar.

Netzverlust und Reordering bleiben möglich. RTP sequence beschreibt Transportreihenfolge; offset beschreibt Codestreamposition; Unit-Regeln beschreiben Parsing.

Eine korrekt geordnete Folge kann eine Einheit vermissen. Ein vollständiger Codestream kann Resource-Limits verletzen. Ein erfolgreicher Decode kann die Produktqualität verfehlen.

Kein Zwischenresultat darf die späteren Stufen unterschreiben.

SDP beschrieb einen Rahmen, keine Ausführung

video/jpeg2000 verlangt Clockrate und Sampling. 90 kHz muss unterstützt werden; andere Raten sind möglich. Wer eine andere Rate bevorzugt, sollte zusätzlich 90 kHz unter einem anderen dynamischen Payload Type anbieten.

Width und height sind optionale Maxima und müssen gemeinsam erscheinen. Der Syntaxbereich reicht bis 2^32−1. Das ist keine Speicherreservierung.

Interlace fehlt bedeutet progressive Übertragung und tp=0. Bei Interlace bezeichnen tp=1 und tp=2 ungerades und gerades Feld; die Headerhöhe ist nur halb so groß wie das Displaybild.

Offer/Answer wählt eine Lesart. Danach müssen Pakete, Clock, Ressourcen, Decoder und Anzeige beobachtet werden.

„SDP akzeptiert“ ist Control-Plane-Evidence, nicht Runtime-Admittance.

Authentischer Ursprung war keine Codec-Prüfung

RFC 5371 trennt Vertraulichkeit, Integrität und Source Authentication. Ein Mechanismus kann belegen, dass ein Paket von einem Sessionmitglied stammt und geschützt unverändert blieb.

Ein authentisches Mitglied kann falsche Offsets, ungültige Flags, übergroße Parameter oder einen malformed Codestream senden. Integrität konserviert den Fehler.

Verlorene Pakete entstehen nicht aus authentischen Nachbarn neu. Crypto-Receipt und Codec-Receipt sind verschieden.

Die historischen Verweise auf SRTP, IPsec und TLS für RTP over TCP beschreiben 2008er Kontext, keine aktuelle Konfiguration eines benannten Systems.

Ein Bericht sollte genau sagen, welche Identität und Bytes geschützt waren und welchen Struktur- und Ressourcenentscheid der Decoder traf.

RFC 9828 besetzt die frühe Latenzfrage

RFC 9828 definiert einen späteren JPEG-2000-Payload für Sub-Codestream-Latenz, mit Main/Body Packets, Resync-, Zeit-, Qualitäts- und Auflösungssignalen.

Der bestehende BTW-Artikel fragt, warum ein früh ausgesendetes erstes Paket keine Ende-zu-Ende-Anzeige beweist. Dieser Artikel wiederholt das nicht.

Hier geht es um semantische Aktivierung und Zustellautorität: Wann darf ein Feld gelesen werden, wer handelte danach und wo liegt das Ergebnis?

RFC 5372 beantwortet die Erweiterungsfrage für priority und mh_id; RFC 9828 beantwortet eine andere Payload- und Latenzfrage. Keine davon beweist Deployment.

Eine Analyse muss das tatsächlich ausgehandelte Protokoll benennen, statt die besten Funktionen mehrerer RFCs zusammenzurechnen.

Die minimale Spezifikation enthält Bedingungen

Lu Hengs Minimum Initial Specification dient als offengelegte analytische Linse. Ein gemeinsamer Vertrag muss nicht jeden lokalen Decoderentscheid vorschreiben. Er muss die Bedingungen erhalten, die später nicht rekonstruiert werden können.

Das Minimum umfasst SDP, Frame/Session/Layer, sequence, timestamp, Marker, Flags, offset, Intervalle, Extension, Headerzustand, Scheduleraktion, Decoder- und Displayresultat.

Die Beziehungen sind entscheidend: priority und mh_id hängen von der Extension ab; Tile hängt von T ab; Marker hängt vom Sessionmanifest ab; offset vom Frameursprung.

Reality Layers stoppt die Überhöhung. Ein Prioritybyte ist Symbol. Eine Queue-Aktion ist Betrieb. Eine Zustellung ist Beobachtung. Ein decodiertes Bild ist Softwareergebnis. Nutzbare Qualität ist Produkturteil.

RFC 5371 ließ das Basisfeld schweigen. Erst Governance kann verhindern, dass ein Dashboard ihm nachträglich eine Stimme leiht.