RTP: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
 
(2 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
=Zweck=
+
*[[RTP Grundlagen]]
Das Real-time Transport Protocol (RTP) wird für die Übertragung von Echtzeitdaten wie Audio- und Videostreams verwendet. Hier ist eine Zusammenfassung des Aufbaus von RTP:
+
*[[RTP Datendurchsatz]]
=Umsetzung=
 
*Der RTP-Header und der RTP-Payload werden in IP-Paketen verpackt und über das Internet Protocol (IP) transportiert.
 
*RTP ist selbst kein zuverlässiges Protokoll ist.
 
*Es stellt keine Mechanismen zur Fehlererkennung oder Fehlerkorrektur bereit.
 
*Für eine zuverlässigere Übertragung müssen zusätzliche implementiert werden.
 
*Maßnahmen wie z. B. das User Datagram Protocol (UDP) in Kombination mit Fehlerkorrekturverfahren wie Forward Error Correction (FEC) oder das Real-time Transport Control Protocol (RTCP) implementiert werden.
 
=RTP-Header=
 
*Der RTP-Header ist der erste Teil eines RTP-Pakets und enthält wichtige Informationen zur Steuerung und Verarbeitung des Datenstroms.
 
== RTP-Header ==
 
{| class="wikitable"
 
|- class="hintergrundfarbe5" style="text-align:left;"
 
| colspan="8" | Byte 0
 
| colspan="8" | Byte 1
 
| colspan="8" | Byte 2
 
| colspan="8" | Byte 3
 
|- style="background:#E8E8E8"
 
| Bit 0
 
| 1
 
| 2
 
| 3
 
| 4
 
| 5
 
| 6
 
| 7
 
| Bit 0
 
| 1
 
| 2
 
| 3
 
| 4
 
| 5
 
| 6
 
| 7
 
| Bit 0
 
| 1
 
| 2
 
| 3
 
| 4
 
| 5
 
| 6
 
| 7
 
| Bit 0
 
| 1
 
| 2
 
| 3
 
| 4
 
| 5
 
| 6
 
| 7
 
|- style="text-align:center;"
 
| colspan="2" | V=2
 
| colspan="1" | P
 
| colspan="1" | X
 
| colspan="4" | CC
 
| colspan="1" | M
 
| colspan="7" | PT
 
| colspan="16" | Sequence Number
 
|-
 
| colspan="32" style="text-align:center;" | Timestamp (in sample rate units)
 
|-
 
| colspan="32" style="text-align:center;" | Synchronization Source (SSRC) identifier
 
|-
 
| colspan="32" style="text-align:center;" |Contributing Source (CSRC) identifiers (optional)
 
|-
 
| colspan="32" style="text-align:center;" |Header Extension (optional)
 
|}
 
 
 
; Version (V), 2 bit: Versionsstand des RTP-Protokolls
 
; Padding (P), 1 bit: Das Füll-Bit ist gesetzt, wenn ein oder mehrere Füll-Bytes am Ende des Pakets angehängt sind, die nicht zum eigentlichen Dateninhalt (Payload) gehören. Das letzte Füll-Byte gibt die Anzahl der hinzugefügten Füll-Byte an. Füll-Byte werden nur dann benötigt, wenn nachfolgende Protokolle eine vorgegebene Blockgröße benötigen, z. B. Verschlüsselungsalgorithmen.
 
; Extension (X), 1 bit: Das Erweiterungs-Bit ist gesetzt, wenn der Header um genau einen Erweiterungs-Header ergänzt wird.
 
; CSRC Count (CC), 4 bit: Der CSRC-Zähler gibt die Anzahl der CSRC-Identifier an.
 
; Marker (M), 1 bit: Das Marker-Bit ist für anwendungsspezifische Verwendungen reserviert. Es wird genutzt zur Kennzeichnung von Ereignissen, z. B. dem Auftreten des Endes eines Einzelbildes einer Videosequenz.
 
; Payload Type (PT), 7 bit: Dieses Feld beschreibt das Format des zu transportierenden RTP-Inhalts, also der [[Nutzdaten]] (Payload).
 
{| class="wikitable" style="text-align:center"
 
|- class="hintergrundfarbe5"
 
| Payloadnr.
 
| Codec
 
| Audio/Video
 
| Abtastrate
 
| Audiokanäle
 
| RFC
 
|-
 
| 0
 
| µ-law
 
| A
 
| 8 kHz
 
| 1
 
| [RFC3551]
 
|-
 
| 3
 
| GSM
 
| A
 
| 8 kHz
 
| 1
 
| [RFC3551]
 
|-
 
| 4
 
| G723
 
| A
 
| 8 kHz
 
| 1
 
| [RFC3551]
 
|-
 
| 5
 
| DVI4
 
| A
 
| 8 kHz
 
| 1
 
| [RFC3551]
 
|-
 
| 6
 
| DVI4
 
| A
 
| 16 kHz
 
| 1
 
| [RFC3551]
 
|-
 
| 7
 
| Linear Predictive Coding
 
| A
 
| 8 kHz
 
| 1
 
| [RFC3551]
 
|-
 
| 8
 
| A-law
 
| A
 
| 8 kHz
 
| 1
 
| [RFC3551]
 
|-
 
| 9
 
| G.722
 
| A
 
| 8 kHz
 
| 1
 
| [RFC3551]
 
|-
 
| 10
 
| L16
 
| A
 
| 44,1 kHz
 
| 2
 
| [RFC3551]
 
|-
 
| 11
 
| L16
 
| A
 
| 44,1 kHz
 
| 1
 
| [RFC3551]
 
|-
 
| 12
 
| QCELP
 
| A
 
| 8 kHz
 
| 1
 
| [RFC3551]
 
|-
 
| 13
 
| CN
 
| A
 
| 8 kHz
 
| 1
 
| [RFC3389]
 
|-
 
| 14
 
| MPA
 
| A
 
| 90 kHz
 
| 1
 
| [RFC3551, RFC2250]
 
|-
 
| 15
 
| G.728
 
| A
 
| 8 kHz
 
| 1
 
| [RFC3551]
 
|-
 
| 16
 
| DVI4
 
| A
 
| 11,025 kHz
 
| 1
 
|
 
|-
 
| 17
 
| DVI4
 
| A
 
| 22,05 kHz
 
| 1
 
|
 
|-
 
| 18
 
| G.729
 
| A
 
| 8 kHz
 
| 1
 
| [RFC3551]
 
|-
 
| 25
 
| CelB
 
| V
 
| 90 kHz
 
|
 
| [RFC3551, RFC2029]
 
|-
 
| 26
 
| JPEG
 
| V
 
| 90 kHz
 
|
 
| [RFC3551, RFC2435]
 
|-
 
| 28
 
| nv
 
| V
 
| 90 kHz
 
|
 
| [RFC3551]
 
|-
 
| 31
 
| H.261
 
| V
 
| 90 kHz
 
|
 
| [RFC3551, RFC2032]
 
|-
 
| 32
 
| MPV
 
| V
 
| 90 kHz
 
|
 
| [RFC3551,2250]
 
|-
 
| 33
 
| MP2T
 
| AV
 
| 90 kHz
 
|
 
| [RFC3551,2250]
 
|-
 
| 34
 
| H.263
 
| V
 
| 90 kHz
 
|
 
| [RFC3551,2250]
 
|-
 
| 96-127
 
| dynamisch
 
|
 
|
 
|
 
| [RFC3551]
 
|}
 
 
 
; Sequence Number, 16 bit: Die Sequenznummer wird für jedes weitere RTP-Datenpaket erhöht. Die Startnummer wird zufällig ausgewählt und ist nicht vorherbestimmbar. Der Empfänger kann mit Hilfe der Sequenznummer die Paketreihenfolge wiederherstellen und den Verlust von Paketen erkennen.
 
; Timestamp, 32 bit: Der Zeitstempel gibt den Zeitpunkt des ersten Bytes des RTP-Datenpakets an. Der Zeitpunkt muss sich an einem Takt orientieren, der kontinuierlich und linear ist, damit die Synchronität des Streams sichergestellt und Laufzeitunterschiede der Übertragungsstrecke (Jitter) ermittelt werden können. Der Startwert sollte wie die Sequenznummer ein zufälliger Wert sein. Aufeinanderfolgende Pakete können den gleichen Zeitstempel haben, wenn die transportierten Daten z. B. zum selben Einzelbild ("video frame") gehören. Pakete mit aufeinanderfolgenden Sequenznummern können aber auch nicht aufeinanderfolgende Zeitstempel enthalten, wenn wie z. B. bei [[Group of Pictures|komprimiertem Video]] Übertragungs- und Wiedergabereihenfolge nicht übereinstimmen.
 
; SSRC, 32 bit: Dieses Feld dient zur Identifikation der Synchronisationsquelle. Der Wert wird zufällig ermittelt, damit nicht zwei Quellen innerhalb der RTP-Session die gleiche Identifikationsnummer besitzen.
 
; CSRC List, 0 bis 15 Felder je 32 bit: Die CSRC-Liste dient zur Identifikation der Quellen, die in den RTP-Nutzdaten enthalten sind. Die Anzahl der Listenfelder wird im CC-Feld angegeben. Falls mehr als 15 Quellen vorkommen, werden nur 15 identifiziert. Die Liste wird von Mixern eingefügt, die dazu den Inhalt des SSRC-Feldes der beteiligten Quellen einsetzen.
 

Aktuelle Version vom 27. Juni 2023, 15:56 Uhr