1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
|
This directory contains some RTP payloaders/depayloaders for different payload
types. Use one payloader/depayloder pair per payload. If several payloads can be
payloaded/depayloaded by the same element, make different copies of it, one for
each payload.
The application/x-rtp mime type
-------------------------------
For valid RTP packets encapsulated in GstBuffers, we use the caps with
mime type application/x-rtp.
The following fields can or must (*) be specified in the structure:
* media: (String) [ "audio", "video", "application", "data", "control" ]
Defined in RFC 2327 in the SDP media announcement field.
Converted to lower case.
* payload: (int) [0, 127]
For audio and video, these will normally be a media payload type as
defined in the RTP Audio/Video Profile. For dynamicaly allocated
payload types, this value will be >= 96 and the encoding-name must be
set.
* clock-rate: (int) [0 - MAXINT]
the RTP clock rate
ssrc: (uint) [0 - MAXINT]
The ssrc value currently in use.
clock-base: (uint) [0 - MAXINT]
The RTP time representing time 0
seqnum-base: (uint) [0 - MAXINT]
The RTP sequence number representing the first rtp packet
encoding-name: (String) ANY
typically second part of the mime type. ex. MP4V-ES. only required if
payload type >= 96. Converted to upper case.
encoding-params: (String) ANY
extra encoding parameters (as in the SDP a=rtpmap: field). only required
if different from the default of the encoding-name.
Converted to lower-case.
Optional parameters as key/value pairs, media type specific. The value type
should be of type G_TYPE_STRING. The key and value are converted to lower-case.
A parameter with no value is converted to <param>=1.
Example:
"application/x-rtp",
"media", G_TYPE_STRING, "audio", -]
"payload", G_TYPE_INT, 96, ] - required
"clock-rate", G_TYPE_INT, 8000, -]
"encoding-name", G_TYPE_STRING, "AMR", -] - required since payload >= 96
"encoding-params", G_TYPE_STRING, "1", -] - optional param for AMR
"octet-align", G_TYPE_STRING, "1", -]
"crc", G_TYPE_STRING, "0", ]
"robust-sorting", G_TYPE_STRING, "0", ] AMR specific params.
"interleaving", G_TYPE_STRING, "0", -]
Mapping of caps to and from SDP fields:
m=<media> <udp port> RTP/AVP <payload> -] media and payload from caps
a=rtpmap:<payload> <encoding-name>/<clock-rate>[/<encoding-params>]
-> when <payload> >= 96
a=fmtp:<payload> <param>=<value>;...
For above caps:
m=audio <udp port> RTP/AVP 96
a=rtpmap:96 AMR/8000/1
a=fmtp:96 octet-align=1;crc=0;robust-sorting=0;interleaving=0
in RTSP, the SSRC is also sent.
The optional parameters in the SDP fields are case insensitive. In the caps we
always use the lowercase names so that the SDP -> caps mapping remains
possible.
usage with UDP
--------------
To correctly and completely use the RTP payloaders on the sender and the
receiver you need to write an application. It is not possible to write a full
blown RTP server with a single gst-launch line.
That said, it is possible to do something functional with a few gst-launch
lines. The biggest problem when constructing a correct gst-launch line lies on
the receiver end.
The receiver needs to know about the type of the RTP data along with a set of
RTP configuration parameters. This information is usually transmitted to the
client using some sort of session description language (SDP) over some reliable
channel (HTTP/RTSP/...).
All of the required parameters to connect and use the RTP session on the
server can be found in the caps on the server end. The client receives this
information in some way (caps are converted to and from SDP, as explained above,
for example).
Some gst-launch lines:
gst-launch-0.10 -v videotestsrc ! ffenc_h263p ! rtph263ppay ! udpsink
Setting pipeline to PAUSED ...
/pipeline0/videotestsrc0.src: caps = video/x-raw-yuv, format=(fourcc)I420,
width=(int)320, height=(int)240, framerate=(fraction)30/1
Pipeline is PREROLLING ...
....
/pipeline0/udpsink0.sink: caps = application/x-rtp, media=(string)video,
payload=(int)96, clock-rate=(int)90000, encoding-name=(string)H263-1998,
ssrc=(guint)527842345, clock-base=(guint)1150776941, seqnum-base=(guint)30982
....
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Write down the caps on the udpsink and set them as the caps of the UDP
receiver:
gst-launch-0.10 -v udpsrc caps="application/x-rtp, media=(string)video,
payload=(int)96, clock-rate=(int)90000, encoding-name=(string)H263-1998,
ssrc=(guint)527842345, clock-base=(guint)1150776941, seqnum-base=(guint)30982"
! rtph263pdepay ! ffdec_h263 ! xvimagesink sync=false
The receiver now displays an h263 image. Note that the sync parameter on
xvimagesink needs to be FALSE because we do not have an RTP session manager
that controls the synchronisation in this pipeline.
Stream a quicktime file with mpeg4 video and AAC audio on port 5000 and port
5002.
gst-launch-0.10 -v filesrc location=~/data/sincity.mp4 ! qtdemux name=d ! queue ! rtpmp4vpay ! udpsink port=5000
d. ! queue ! rtpmp4gpay ! udpsink port=5002
....
/pipeline0/udpsink0.sink: caps = application/x-rtp, media=(string)video,
payload=(int)96, clock-rate=(int)90000, encoding-name=(string)MP4V-ES,
ssrc=(guint)1162703703, clock-base=(guint)816135835, seqnum-base=(guint)9294,
profile-level-id=(string)3, config=(string)000001b003000001b50900000100000001200086c5d4c307d314043c1463000001b25876694430303334
/pipeline0/udpsink1.sink: caps = application/x-rtp, media=(string)audio,
payload=(int)96, clock-rate=(int)44100, encoding-name=(string)MPEG4-GENERIC,
ssrc=(guint)3246149898, clock-base=(guint)4134514058, seqnum-base=(guint)57633,
encoding-params=(string)2, streamtype=(string)5, profile-level-id=(string)1,
mode=(string)aac-hbr, config=(string)1210, sizelength=(string)13,
indexlength=(string)3, indexdeltalength=(string)3
....
Again copy the caps on both sinks to the receiver launch line
gst-launch
udpsrc port=5000 caps="application/x-rtp, media=(string)video, payload=(int)96,
clock-rate=(int)90000, encoding-name=(string)MP4V-ES, ssrc=(guint)1162703703,
clock-base=(guint)816135835, seqnum-base=(guint)9294, profile-level-id=(string)3,
config=(string)000001b003000001b50900000100000001200086c5d4c307d314043c1463000001b25876694430303334"
! rtpmp4vdepay ! ffdec_mpeg4 ! xvimagesink sync=false
udpsrc port=5002 caps="application/x-rtp, media=(string)audio, payload=(int)96,
clock-rate=(int)44100, encoding-name=(string)MPEG4-GENERIC, ssrc=(guint)3246149898,
clock-base=(guint)4134514058, seqnum-base=(guint)57633, encoding-params=(string)2,
streamtype=(string)5, profile-level-id=(string)1, mode=(string)aac-hbr,
config=(string)1210, sizelength=(string)13, indexlength=(string)3,
indexdeltalength=(string)3"
! rtpmp4gdepay ! faad ! alsasink sync=false
The caps on the udpsinks can be retrieved when the server pipeline prerolled to
PAUSED.
The caps on the receiver side can be set on the UDP source elements when the
pipeline went to PAUSED. In that state no data is received from the UDP sources
as they are live sources and only produce data in PLAYING.
Relevant RFCs
-------------
3550 RTP: A Transport Protocol for Real-Time Applications. ( 1889 Obsolete )
2198 RTP Payload for Redundant Audio Data.
3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio.
2793 RTP Payload for Text Conversation.
2032 RTP Payload Format for H.261 Video Streams.
2190 RTP Payload Format for H.263 Video Streams.
2250 RTP Payload Format for MPEG1/MPEG2 Video.
2343 RTP Payload Format for Bundled MPEG.
2429 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video
2431 RTP Payload Format for BT.656 Video Encoding.
2435 RTP Payload Format for JPEG-compressed Video.
3016 RTP Payload Format for MPEG-4 Audio/Visual Streams.
3047 RTP Payload Format for ITU-T Recommendation G.722.1.
3189 RTP Payload Format for DV (IEC 61834) Video.
3190 RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio.
3389 Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)
2733 An RTP Payload Format for Generic Forward Error Correction.
2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony
Signals.
2862 RTP Payload Format for Real-Time Pointers.
3351 RTP Profile for Audio and Video Conferences with Minimal Control. ( 1890 Obsolete )
3555 MIME Type Registration of RTP Payload Formats.
2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links.
1305 Network Time Protocol (Version 3) Specification, Implementation and Analysis.
3339 Date and Time on the Internet: Timestamps.
2246 The TLS Protocol Version 1.0
3546 Transport Layer Security (TLS) Extensions. ( Updates 2246 )
do we care?
-----------
2029 RTP Payload Format of Sun's CellB Video Encoding.
usefull
-------
http://www.iana.org/assignments/rtp-parameters
|
