yading@10
|
1 @chapter Protocols
|
yading@10
|
2 @c man begin PROTOCOLS
|
yading@10
|
3
|
yading@10
|
4 Protocols are configured elements in FFmpeg which allow to access
|
yading@10
|
5 resources which require the use of a particular protocol.
|
yading@10
|
6
|
yading@10
|
7 When you configure your FFmpeg build, all the supported protocols are
|
yading@10
|
8 enabled by default. You can list all available ones using the
|
yading@10
|
9 configure option "--list-protocols".
|
yading@10
|
10
|
yading@10
|
11 You can disable all the protocols using the configure option
|
yading@10
|
12 "--disable-protocols", and selectively enable a protocol using the
|
yading@10
|
13 option "--enable-protocol=@var{PROTOCOL}", or you can disable a
|
yading@10
|
14 particular protocol using the option
|
yading@10
|
15 "--disable-protocol=@var{PROTOCOL}".
|
yading@10
|
16
|
yading@10
|
17 The option "-protocols" of the ff* tools will display the list of
|
yading@10
|
18 supported protocols.
|
yading@10
|
19
|
yading@10
|
20 A description of the currently available protocols follows.
|
yading@10
|
21
|
yading@10
|
22 @section bluray
|
yading@10
|
23
|
yading@10
|
24 Read BluRay playlist.
|
yading@10
|
25
|
yading@10
|
26 The accepted options are:
|
yading@10
|
27 @table @option
|
yading@10
|
28
|
yading@10
|
29 @item angle
|
yading@10
|
30 BluRay angle
|
yading@10
|
31
|
yading@10
|
32 @item chapter
|
yading@10
|
33 Start chapter (1...N)
|
yading@10
|
34
|
yading@10
|
35 @item playlist
|
yading@10
|
36 Playlist to read (BDMV/PLAYLIST/?????.mpls)
|
yading@10
|
37
|
yading@10
|
38 @end table
|
yading@10
|
39
|
yading@10
|
40 Examples:
|
yading@10
|
41
|
yading@10
|
42 Read longest playlist from BluRay mounted to /mnt/bluray:
|
yading@10
|
43 @example
|
yading@10
|
44 bluray:/mnt/bluray
|
yading@10
|
45 @end example
|
yading@10
|
46
|
yading@10
|
47 Read angle 2 of playlist 4 from BluRay mounted to /mnt/bluray, start from chapter 2:
|
yading@10
|
48 @example
|
yading@10
|
49 -playlist 4 -angle 2 -chapter 2 bluray:/mnt/bluray
|
yading@10
|
50 @end example
|
yading@10
|
51
|
yading@10
|
52 @section concat
|
yading@10
|
53
|
yading@10
|
54 Physical concatenation protocol.
|
yading@10
|
55
|
yading@10
|
56 Allow to read and seek from many resource in sequence as if they were
|
yading@10
|
57 a unique resource.
|
yading@10
|
58
|
yading@10
|
59 A URL accepted by this protocol has the syntax:
|
yading@10
|
60 @example
|
yading@10
|
61 concat:@var{URL1}|@var{URL2}|...|@var{URLN}
|
yading@10
|
62 @end example
|
yading@10
|
63
|
yading@10
|
64 where @var{URL1}, @var{URL2}, ..., @var{URLN} are the urls of the
|
yading@10
|
65 resource to be concatenated, each one possibly specifying a distinct
|
yading@10
|
66 protocol.
|
yading@10
|
67
|
yading@10
|
68 For example to read a sequence of files @file{split1.mpeg},
|
yading@10
|
69 @file{split2.mpeg}, @file{split3.mpeg} with @command{ffplay} use the
|
yading@10
|
70 command:
|
yading@10
|
71 @example
|
yading@10
|
72 ffplay concat:split1.mpeg\|split2.mpeg\|split3.mpeg
|
yading@10
|
73 @end example
|
yading@10
|
74
|
yading@10
|
75 Note that you may need to escape the character "|" which is special for
|
yading@10
|
76 many shells.
|
yading@10
|
77
|
yading@10
|
78 @section data
|
yading@10
|
79
|
yading@10
|
80 Data in-line in the URI. See @url{http://en.wikipedia.org/wiki/Data_URI_scheme}.
|
yading@10
|
81
|
yading@10
|
82 For example, to convert a GIF file given inline with @command{ffmpeg}:
|
yading@10
|
83 @example
|
yading@10
|
84 ffmpeg -i "data:image/gif;base64,R0lGODdhCAAIAMIEAAAAAAAA//8AAP//AP///////////////ywAAAAACAAIAAADF0gEDLojDgdGiJdJqUX02iB4E8Q9jUMkADs=" smiley.png
|
yading@10
|
85 @end example
|
yading@10
|
86
|
yading@10
|
87 @section file
|
yading@10
|
88
|
yading@10
|
89 File access protocol.
|
yading@10
|
90
|
yading@10
|
91 Allow to read from or read to a file.
|
yading@10
|
92
|
yading@10
|
93 For example to read from a file @file{input.mpeg} with @command{ffmpeg}
|
yading@10
|
94 use the command:
|
yading@10
|
95 @example
|
yading@10
|
96 ffmpeg -i file:input.mpeg output.mpeg
|
yading@10
|
97 @end example
|
yading@10
|
98
|
yading@10
|
99 The ff* tools default to the file protocol, that is a resource
|
yading@10
|
100 specified with the name "FILE.mpeg" is interpreted as the URL
|
yading@10
|
101 "file:FILE.mpeg".
|
yading@10
|
102
|
yading@10
|
103 @section gopher
|
yading@10
|
104
|
yading@10
|
105 Gopher protocol.
|
yading@10
|
106
|
yading@10
|
107 @section hls
|
yading@10
|
108
|
yading@10
|
109 Read Apple HTTP Live Streaming compliant segmented stream as
|
yading@10
|
110 a uniform one. The M3U8 playlists describing the segments can be
|
yading@10
|
111 remote HTTP resources or local files, accessed using the standard
|
yading@10
|
112 file protocol.
|
yading@10
|
113 The nested protocol is declared by specifying
|
yading@10
|
114 "+@var{proto}" after the hls URI scheme name, where @var{proto}
|
yading@10
|
115 is either "file" or "http".
|
yading@10
|
116
|
yading@10
|
117 @example
|
yading@10
|
118 hls+http://host/path/to/remote/resource.m3u8
|
yading@10
|
119 hls+file://path/to/local/resource.m3u8
|
yading@10
|
120 @end example
|
yading@10
|
121
|
yading@10
|
122 Using this protocol is discouraged - the hls demuxer should work
|
yading@10
|
123 just as well (if not, please report the issues) and is more complete.
|
yading@10
|
124 To use the hls demuxer instead, simply use the direct URLs to the
|
yading@10
|
125 m3u8 files.
|
yading@10
|
126
|
yading@10
|
127 @section http
|
yading@10
|
128
|
yading@10
|
129 HTTP (Hyper Text Transfer Protocol).
|
yading@10
|
130
|
yading@10
|
131 This protocol accepts the following options.
|
yading@10
|
132
|
yading@10
|
133 @table @option
|
yading@10
|
134 @item seekable
|
yading@10
|
135 Control seekability of connection. If set to 1 the resource is
|
yading@10
|
136 supposed to be seekable, if set to 0 it is assumed not to be seekable,
|
yading@10
|
137 if set to -1 it will try to autodetect if it is seekable. Default
|
yading@10
|
138 value is -1.
|
yading@10
|
139
|
yading@10
|
140 @item chunked_post
|
yading@10
|
141 If set to 1 use chunked transfer-encoding for posts, default is 1.
|
yading@10
|
142
|
yading@10
|
143 @item headers
|
yading@10
|
144 Set custom HTTP headers, can override built in default headers. The
|
yading@10
|
145 value must be a string encoding the headers.
|
yading@10
|
146
|
yading@10
|
147 @item content_type
|
yading@10
|
148 Force a content type.
|
yading@10
|
149
|
yading@10
|
150 @item user-agent
|
yading@10
|
151 Override User-Agent header. If not specified the protocol will use a
|
yading@10
|
152 string describing the libavformat build.
|
yading@10
|
153
|
yading@10
|
154 @item multiple_requests
|
yading@10
|
155 Use persistent connections if set to 1. By default it is 0.
|
yading@10
|
156
|
yading@10
|
157 @item post_data
|
yading@10
|
158 Set custom HTTP post data.
|
yading@10
|
159
|
yading@10
|
160 @item timeout
|
yading@10
|
161 Set timeout of socket I/O operations used by the underlying low level
|
yading@10
|
162 operation. By default it is set to -1, which means that the timeout is
|
yading@10
|
163 not specified.
|
yading@10
|
164
|
yading@10
|
165 @item mime_type
|
yading@10
|
166 Set MIME type.
|
yading@10
|
167
|
yading@10
|
168 @item cookies
|
yading@10
|
169 Set the cookies to be sent in future requests. The format of each cookie is the
|
yading@10
|
170 same as the value of a Set-Cookie HTTP response field. Multiple cookies can be
|
yading@10
|
171 delimited by a newline character.
|
yading@10
|
172 @end table
|
yading@10
|
173
|
yading@10
|
174 @subsection HTTP Cookies
|
yading@10
|
175
|
yading@10
|
176 Some HTTP requests will be denied unless cookie values are passed in with the
|
yading@10
|
177 request. The @option{cookies} option allows these cookies to be specified. At
|
yading@10
|
178 the very least, each cookie must specify a value along with a path and domain.
|
yading@10
|
179 HTTP requests that match both the domain and path will automatically include the
|
yading@10
|
180 cookie value in the HTTP Cookie header field. Multiple cookies can be delimited
|
yading@10
|
181 by a newline.
|
yading@10
|
182
|
yading@10
|
183 The required syntax to play a stream specifying a cookie is:
|
yading@10
|
184 @example
|
yading@10
|
185 ffplay -cookies "nlqptid=nltid=tsn; path=/; domain=somedomain.com;" http://somedomain.com/somestream.m3u8
|
yading@10
|
186 @end example
|
yading@10
|
187
|
yading@10
|
188 @section mmst
|
yading@10
|
189
|
yading@10
|
190 MMS (Microsoft Media Server) protocol over TCP.
|
yading@10
|
191
|
yading@10
|
192 @section mmsh
|
yading@10
|
193
|
yading@10
|
194 MMS (Microsoft Media Server) protocol over HTTP.
|
yading@10
|
195
|
yading@10
|
196 The required syntax is:
|
yading@10
|
197 @example
|
yading@10
|
198 mmsh://@var{server}[:@var{port}][/@var{app}][/@var{playpath}]
|
yading@10
|
199 @end example
|
yading@10
|
200
|
yading@10
|
201 @section md5
|
yading@10
|
202
|
yading@10
|
203 MD5 output protocol.
|
yading@10
|
204
|
yading@10
|
205 Computes the MD5 hash of the data to be written, and on close writes
|
yading@10
|
206 this to the designated output or stdout if none is specified. It can
|
yading@10
|
207 be used to test muxers without writing an actual file.
|
yading@10
|
208
|
yading@10
|
209 Some examples follow.
|
yading@10
|
210 @example
|
yading@10
|
211 # Write the MD5 hash of the encoded AVI file to the file output.avi.md5.
|
yading@10
|
212 ffmpeg -i input.flv -f avi -y md5:output.avi.md5
|
yading@10
|
213
|
yading@10
|
214 # Write the MD5 hash of the encoded AVI file to stdout.
|
yading@10
|
215 ffmpeg -i input.flv -f avi -y md5:
|
yading@10
|
216 @end example
|
yading@10
|
217
|
yading@10
|
218 Note that some formats (typically MOV) require the output protocol to
|
yading@10
|
219 be seekable, so they will fail with the MD5 output protocol.
|
yading@10
|
220
|
yading@10
|
221 @section pipe
|
yading@10
|
222
|
yading@10
|
223 UNIX pipe access protocol.
|
yading@10
|
224
|
yading@10
|
225 Allow to read and write from UNIX pipes.
|
yading@10
|
226
|
yading@10
|
227 The accepted syntax is:
|
yading@10
|
228 @example
|
yading@10
|
229 pipe:[@var{number}]
|
yading@10
|
230 @end example
|
yading@10
|
231
|
yading@10
|
232 @var{number} is the number corresponding to the file descriptor of the
|
yading@10
|
233 pipe (e.g. 0 for stdin, 1 for stdout, 2 for stderr). If @var{number}
|
yading@10
|
234 is not specified, by default the stdout file descriptor will be used
|
yading@10
|
235 for writing, stdin for reading.
|
yading@10
|
236
|
yading@10
|
237 For example to read from stdin with @command{ffmpeg}:
|
yading@10
|
238 @example
|
yading@10
|
239 cat test.wav | ffmpeg -i pipe:0
|
yading@10
|
240 # ...this is the same as...
|
yading@10
|
241 cat test.wav | ffmpeg -i pipe:
|
yading@10
|
242 @end example
|
yading@10
|
243
|
yading@10
|
244 For writing to stdout with @command{ffmpeg}:
|
yading@10
|
245 @example
|
yading@10
|
246 ffmpeg -i test.wav -f avi pipe:1 | cat > test.avi
|
yading@10
|
247 # ...this is the same as...
|
yading@10
|
248 ffmpeg -i test.wav -f avi pipe: | cat > test.avi
|
yading@10
|
249 @end example
|
yading@10
|
250
|
yading@10
|
251 Note that some formats (typically MOV), require the output protocol to
|
yading@10
|
252 be seekable, so they will fail with the pipe output protocol.
|
yading@10
|
253
|
yading@10
|
254 @section rtmp
|
yading@10
|
255
|
yading@10
|
256 Real-Time Messaging Protocol.
|
yading@10
|
257
|
yading@10
|
258 The Real-Time Messaging Protocol (RTMP) is used for streaming multimedia
|
yading@10
|
259 content across a TCP/IP network.
|
yading@10
|
260
|
yading@10
|
261 The required syntax is:
|
yading@10
|
262 @example
|
yading@10
|
263 rtmp://@var{server}[:@var{port}][/@var{app}][/@var{instance}][/@var{playpath}]
|
yading@10
|
264 @end example
|
yading@10
|
265
|
yading@10
|
266 The accepted parameters are:
|
yading@10
|
267 @table @option
|
yading@10
|
268
|
yading@10
|
269 @item server
|
yading@10
|
270 The address of the RTMP server.
|
yading@10
|
271
|
yading@10
|
272 @item port
|
yading@10
|
273 The number of the TCP port to use (by default is 1935).
|
yading@10
|
274
|
yading@10
|
275 @item app
|
yading@10
|
276 It is the name of the application to access. It usually corresponds to
|
yading@10
|
277 the path where the application is installed on the RTMP server
|
yading@10
|
278 (e.g. @file{/ondemand/}, @file{/flash/live/}, etc.). You can override
|
yading@10
|
279 the value parsed from the URI through the @code{rtmp_app} option, too.
|
yading@10
|
280
|
yading@10
|
281 @item playpath
|
yading@10
|
282 It is the path or name of the resource to play with reference to the
|
yading@10
|
283 application specified in @var{app}, may be prefixed by "mp4:". You
|
yading@10
|
284 can override the value parsed from the URI through the @code{rtmp_playpath}
|
yading@10
|
285 option, too.
|
yading@10
|
286
|
yading@10
|
287 @item listen
|
yading@10
|
288 Act as a server, listening for an incoming connection.
|
yading@10
|
289
|
yading@10
|
290 @item timeout
|
yading@10
|
291 Maximum time to wait for the incoming connection. Implies listen.
|
yading@10
|
292 @end table
|
yading@10
|
293
|
yading@10
|
294 Additionally, the following parameters can be set via command line options
|
yading@10
|
295 (or in code via @code{AVOption}s):
|
yading@10
|
296 @table @option
|
yading@10
|
297
|
yading@10
|
298 @item rtmp_app
|
yading@10
|
299 Name of application to connect on the RTMP server. This option
|
yading@10
|
300 overrides the parameter specified in the URI.
|
yading@10
|
301
|
yading@10
|
302 @item rtmp_buffer
|
yading@10
|
303 Set the client buffer time in milliseconds. The default is 3000.
|
yading@10
|
304
|
yading@10
|
305 @item rtmp_conn
|
yading@10
|
306 Extra arbitrary AMF connection parameters, parsed from a string,
|
yading@10
|
307 e.g. like @code{B:1 S:authMe O:1 NN:code:1.23 NS:flag:ok O:0}.
|
yading@10
|
308 Each value is prefixed by a single character denoting the type,
|
yading@10
|
309 B for Boolean, N for number, S for string, O for object, or Z for null,
|
yading@10
|
310 followed by a colon. For Booleans the data must be either 0 or 1 for
|
yading@10
|
311 FALSE or TRUE, respectively. Likewise for Objects the data must be 0 or
|
yading@10
|
312 1 to end or begin an object, respectively. Data items in subobjects may
|
yading@10
|
313 be named, by prefixing the type with 'N' and specifying the name before
|
yading@10
|
314 the value (i.e. @code{NB:myFlag:1}). This option may be used multiple
|
yading@10
|
315 times to construct arbitrary AMF sequences.
|
yading@10
|
316
|
yading@10
|
317 @item rtmp_flashver
|
yading@10
|
318 Version of the Flash plugin used to run the SWF player. The default
|
yading@10
|
319 is LNX 9,0,124,2.
|
yading@10
|
320
|
yading@10
|
321 @item rtmp_flush_interval
|
yading@10
|
322 Number of packets flushed in the same request (RTMPT only). The default
|
yading@10
|
323 is 10.
|
yading@10
|
324
|
yading@10
|
325 @item rtmp_live
|
yading@10
|
326 Specify that the media is a live stream. No resuming or seeking in
|
yading@10
|
327 live streams is possible. The default value is @code{any}, which means the
|
yading@10
|
328 subscriber first tries to play the live stream specified in the
|
yading@10
|
329 playpath. If a live stream of that name is not found, it plays the
|
yading@10
|
330 recorded stream. The other possible values are @code{live} and
|
yading@10
|
331 @code{recorded}.
|
yading@10
|
332
|
yading@10
|
333 @item rtmp_pageurl
|
yading@10
|
334 URL of the web page in which the media was embedded. By default no
|
yading@10
|
335 value will be sent.
|
yading@10
|
336
|
yading@10
|
337 @item rtmp_playpath
|
yading@10
|
338 Stream identifier to play or to publish. This option overrides the
|
yading@10
|
339 parameter specified in the URI.
|
yading@10
|
340
|
yading@10
|
341 @item rtmp_subscribe
|
yading@10
|
342 Name of live stream to subscribe to. By default no value will be sent.
|
yading@10
|
343 It is only sent if the option is specified or if rtmp_live
|
yading@10
|
344 is set to live.
|
yading@10
|
345
|
yading@10
|
346 @item rtmp_swfhash
|
yading@10
|
347 SHA256 hash of the decompressed SWF file (32 bytes).
|
yading@10
|
348
|
yading@10
|
349 @item rtmp_swfsize
|
yading@10
|
350 Size of the decompressed SWF file, required for SWFVerification.
|
yading@10
|
351
|
yading@10
|
352 @item rtmp_swfurl
|
yading@10
|
353 URL of the SWF player for the media. By default no value will be sent.
|
yading@10
|
354
|
yading@10
|
355 @item rtmp_swfverify
|
yading@10
|
356 URL to player swf file, compute hash/size automatically.
|
yading@10
|
357
|
yading@10
|
358 @item rtmp_tcurl
|
yading@10
|
359 URL of the target stream. Defaults to proto://host[:port]/app.
|
yading@10
|
360
|
yading@10
|
361 @end table
|
yading@10
|
362
|
yading@10
|
363 For example to read with @command{ffplay} a multimedia resource named
|
yading@10
|
364 "sample" from the application "vod" from an RTMP server "myserver":
|
yading@10
|
365 @example
|
yading@10
|
366 ffplay rtmp://myserver/vod/sample
|
yading@10
|
367 @end example
|
yading@10
|
368
|
yading@10
|
369 @section rtmpe
|
yading@10
|
370
|
yading@10
|
371 Encrypted Real-Time Messaging Protocol.
|
yading@10
|
372
|
yading@10
|
373 The Encrypted Real-Time Messaging Protocol (RTMPE) is used for
|
yading@10
|
374 streaming multimedia content within standard cryptographic primitives,
|
yading@10
|
375 consisting of Diffie-Hellman key exchange and HMACSHA256, generating
|
yading@10
|
376 a pair of RC4 keys.
|
yading@10
|
377
|
yading@10
|
378 @section rtmps
|
yading@10
|
379
|
yading@10
|
380 Real-Time Messaging Protocol over a secure SSL connection.
|
yading@10
|
381
|
yading@10
|
382 The Real-Time Messaging Protocol (RTMPS) is used for streaming
|
yading@10
|
383 multimedia content across an encrypted connection.
|
yading@10
|
384
|
yading@10
|
385 @section rtmpt
|
yading@10
|
386
|
yading@10
|
387 Real-Time Messaging Protocol tunneled through HTTP.
|
yading@10
|
388
|
yading@10
|
389 The Real-Time Messaging Protocol tunneled through HTTP (RTMPT) is used
|
yading@10
|
390 for streaming multimedia content within HTTP requests to traverse
|
yading@10
|
391 firewalls.
|
yading@10
|
392
|
yading@10
|
393 @section rtmpte
|
yading@10
|
394
|
yading@10
|
395 Encrypted Real-Time Messaging Protocol tunneled through HTTP.
|
yading@10
|
396
|
yading@10
|
397 The Encrypted Real-Time Messaging Protocol tunneled through HTTP (RTMPTE)
|
yading@10
|
398 is used for streaming multimedia content within HTTP requests to traverse
|
yading@10
|
399 firewalls.
|
yading@10
|
400
|
yading@10
|
401 @section rtmpts
|
yading@10
|
402
|
yading@10
|
403 Real-Time Messaging Protocol tunneled through HTTPS.
|
yading@10
|
404
|
yading@10
|
405 The Real-Time Messaging Protocol tunneled through HTTPS (RTMPTS) is used
|
yading@10
|
406 for streaming multimedia content within HTTPS requests to traverse
|
yading@10
|
407 firewalls.
|
yading@10
|
408
|
yading@10
|
409 @section rtmp, rtmpe, rtmps, rtmpt, rtmpte
|
yading@10
|
410
|
yading@10
|
411 Real-Time Messaging Protocol and its variants supported through
|
yading@10
|
412 librtmp.
|
yading@10
|
413
|
yading@10
|
414 Requires the presence of the librtmp headers and library during
|
yading@10
|
415 configuration. You need to explicitly configure the build with
|
yading@10
|
416 "--enable-librtmp". If enabled this will replace the native RTMP
|
yading@10
|
417 protocol.
|
yading@10
|
418
|
yading@10
|
419 This protocol provides most client functions and a few server
|
yading@10
|
420 functions needed to support RTMP, RTMP tunneled in HTTP (RTMPT),
|
yading@10
|
421 encrypted RTMP (RTMPE), RTMP over SSL/TLS (RTMPS) and tunneled
|
yading@10
|
422 variants of these encrypted types (RTMPTE, RTMPTS).
|
yading@10
|
423
|
yading@10
|
424 The required syntax is:
|
yading@10
|
425 @example
|
yading@10
|
426 @var{rtmp_proto}://@var{server}[:@var{port}][/@var{app}][/@var{playpath}] @var{options}
|
yading@10
|
427 @end example
|
yading@10
|
428
|
yading@10
|
429 where @var{rtmp_proto} is one of the strings "rtmp", "rtmpt", "rtmpe",
|
yading@10
|
430 "rtmps", "rtmpte", "rtmpts" corresponding to each RTMP variant, and
|
yading@10
|
431 @var{server}, @var{port}, @var{app} and @var{playpath} have the same
|
yading@10
|
432 meaning as specified for the RTMP native protocol.
|
yading@10
|
433 @var{options} contains a list of space-separated options of the form
|
yading@10
|
434 @var{key}=@var{val}.
|
yading@10
|
435
|
yading@10
|
436 See the librtmp manual page (man 3 librtmp) for more information.
|
yading@10
|
437
|
yading@10
|
438 For example, to stream a file in real-time to an RTMP server using
|
yading@10
|
439 @command{ffmpeg}:
|
yading@10
|
440 @example
|
yading@10
|
441 ffmpeg -re -i myfile -f flv rtmp://myserver/live/mystream
|
yading@10
|
442 @end example
|
yading@10
|
443
|
yading@10
|
444 To play the same stream using @command{ffplay}:
|
yading@10
|
445 @example
|
yading@10
|
446 ffplay "rtmp://myserver/live/mystream live=1"
|
yading@10
|
447 @end example
|
yading@10
|
448
|
yading@10
|
449 @section rtp
|
yading@10
|
450
|
yading@10
|
451 Real-Time Protocol.
|
yading@10
|
452
|
yading@10
|
453 @section rtsp
|
yading@10
|
454
|
yading@10
|
455 RTSP is not technically a protocol handler in libavformat, it is a demuxer
|
yading@10
|
456 and muxer. The demuxer supports both normal RTSP (with data transferred
|
yading@10
|
457 over RTP; this is used by e.g. Apple and Microsoft) and Real-RTSP (with
|
yading@10
|
458 data transferred over RDT).
|
yading@10
|
459
|
yading@10
|
460 The muxer can be used to send a stream using RTSP ANNOUNCE to a server
|
yading@10
|
461 supporting it (currently Darwin Streaming Server and Mischa Spiegelmock's
|
yading@10
|
462 @uref{http://github.com/revmischa/rtsp-server, RTSP server}).
|
yading@10
|
463
|
yading@10
|
464 The required syntax for a RTSP url is:
|
yading@10
|
465 @example
|
yading@10
|
466 rtsp://@var{hostname}[:@var{port}]/@var{path}
|
yading@10
|
467 @end example
|
yading@10
|
468
|
yading@10
|
469 The following options (set on the @command{ffmpeg}/@command{ffplay} command
|
yading@10
|
470 line, or set in code via @code{AVOption}s or in @code{avformat_open_input}),
|
yading@10
|
471 are supported:
|
yading@10
|
472
|
yading@10
|
473 Flags for @code{rtsp_transport}:
|
yading@10
|
474
|
yading@10
|
475 @table @option
|
yading@10
|
476
|
yading@10
|
477 @item udp
|
yading@10
|
478 Use UDP as lower transport protocol.
|
yading@10
|
479
|
yading@10
|
480 @item tcp
|
yading@10
|
481 Use TCP (interleaving within the RTSP control channel) as lower
|
yading@10
|
482 transport protocol.
|
yading@10
|
483
|
yading@10
|
484 @item udp_multicast
|
yading@10
|
485 Use UDP multicast as lower transport protocol.
|
yading@10
|
486
|
yading@10
|
487 @item http
|
yading@10
|
488 Use HTTP tunneling as lower transport protocol, which is useful for
|
yading@10
|
489 passing proxies.
|
yading@10
|
490 @end table
|
yading@10
|
491
|
yading@10
|
492 Multiple lower transport protocols may be specified, in that case they are
|
yading@10
|
493 tried one at a time (if the setup of one fails, the next one is tried).
|
yading@10
|
494 For the muxer, only the @code{tcp} and @code{udp} options are supported.
|
yading@10
|
495
|
yading@10
|
496 Flags for @code{rtsp_flags}:
|
yading@10
|
497
|
yading@10
|
498 @table @option
|
yading@10
|
499 @item filter_src
|
yading@10
|
500 Accept packets only from negotiated peer address and port.
|
yading@10
|
501 @item listen
|
yading@10
|
502 Act as a server, listening for an incoming connection.
|
yading@10
|
503 @end table
|
yading@10
|
504
|
yading@10
|
505 When receiving data over UDP, the demuxer tries to reorder received packets
|
yading@10
|
506 (since they may arrive out of order, or packets may get lost totally). This
|
yading@10
|
507 can be disabled by setting the maximum demuxing delay to zero (via
|
yading@10
|
508 the @code{max_delay} field of AVFormatContext).
|
yading@10
|
509
|
yading@10
|
510 When watching multi-bitrate Real-RTSP streams with @command{ffplay}, the
|
yading@10
|
511 streams to display can be chosen with @code{-vst} @var{n} and
|
yading@10
|
512 @code{-ast} @var{n} for video and audio respectively, and can be switched
|
yading@10
|
513 on the fly by pressing @code{v} and @code{a}.
|
yading@10
|
514
|
yading@10
|
515 Example command lines:
|
yading@10
|
516
|
yading@10
|
517 To watch a stream over UDP, with a max reordering delay of 0.5 seconds:
|
yading@10
|
518
|
yading@10
|
519 @example
|
yading@10
|
520 ffplay -max_delay 500000 -rtsp_transport udp rtsp://server/video.mp4
|
yading@10
|
521 @end example
|
yading@10
|
522
|
yading@10
|
523 To watch a stream tunneled over HTTP:
|
yading@10
|
524
|
yading@10
|
525 @example
|
yading@10
|
526 ffplay -rtsp_transport http rtsp://server/video.mp4
|
yading@10
|
527 @end example
|
yading@10
|
528
|
yading@10
|
529 To send a stream in realtime to a RTSP server, for others to watch:
|
yading@10
|
530
|
yading@10
|
531 @example
|
yading@10
|
532 ffmpeg -re -i @var{input} -f rtsp -muxdelay 0.1 rtsp://server/live.sdp
|
yading@10
|
533 @end example
|
yading@10
|
534
|
yading@10
|
535 To receive a stream in realtime:
|
yading@10
|
536
|
yading@10
|
537 @example
|
yading@10
|
538 ffmpeg -rtsp_flags listen -i rtsp://ownaddress/live.sdp @var{output}
|
yading@10
|
539 @end example
|
yading@10
|
540
|
yading@10
|
541 @table @option
|
yading@10
|
542 @item stimeout
|
yading@10
|
543 Socket IO timeout in micro seconds.
|
yading@10
|
544 @end table
|
yading@10
|
545
|
yading@10
|
546 @section sap
|
yading@10
|
547
|
yading@10
|
548 Session Announcement Protocol (RFC 2974). This is not technically a
|
yading@10
|
549 protocol handler in libavformat, it is a muxer and demuxer.
|
yading@10
|
550 It is used for signalling of RTP streams, by announcing the SDP for the
|
yading@10
|
551 streams regularly on a separate port.
|
yading@10
|
552
|
yading@10
|
553 @subsection Muxer
|
yading@10
|
554
|
yading@10
|
555 The syntax for a SAP url given to the muxer is:
|
yading@10
|
556 @example
|
yading@10
|
557 sap://@var{destination}[:@var{port}][?@var{options}]
|
yading@10
|
558 @end example
|
yading@10
|
559
|
yading@10
|
560 The RTP packets are sent to @var{destination} on port @var{port},
|
yading@10
|
561 or to port 5004 if no port is specified.
|
yading@10
|
562 @var{options} is a @code{&}-separated list. The following options
|
yading@10
|
563 are supported:
|
yading@10
|
564
|
yading@10
|
565 @table @option
|
yading@10
|
566
|
yading@10
|
567 @item announce_addr=@var{address}
|
yading@10
|
568 Specify the destination IP address for sending the announcements to.
|
yading@10
|
569 If omitted, the announcements are sent to the commonly used SAP
|
yading@10
|
570 announcement multicast address 224.2.127.254 (sap.mcast.net), or
|
yading@10
|
571 ff0e::2:7ffe if @var{destination} is an IPv6 address.
|
yading@10
|
572
|
yading@10
|
573 @item announce_port=@var{port}
|
yading@10
|
574 Specify the port to send the announcements on, defaults to
|
yading@10
|
575 9875 if not specified.
|
yading@10
|
576
|
yading@10
|
577 @item ttl=@var{ttl}
|
yading@10
|
578 Specify the time to live value for the announcements and RTP packets,
|
yading@10
|
579 defaults to 255.
|
yading@10
|
580
|
yading@10
|
581 @item same_port=@var{0|1}
|
yading@10
|
582 If set to 1, send all RTP streams on the same port pair. If zero (the
|
yading@10
|
583 default), all streams are sent on unique ports, with each stream on a
|
yading@10
|
584 port 2 numbers higher than the previous.
|
yading@10
|
585 VLC/Live555 requires this to be set to 1, to be able to receive the stream.
|
yading@10
|
586 The RTP stack in libavformat for receiving requires all streams to be sent
|
yading@10
|
587 on unique ports.
|
yading@10
|
588 @end table
|
yading@10
|
589
|
yading@10
|
590 Example command lines follow.
|
yading@10
|
591
|
yading@10
|
592 To broadcast a stream on the local subnet, for watching in VLC:
|
yading@10
|
593
|
yading@10
|
594 @example
|
yading@10
|
595 ffmpeg -re -i @var{input} -f sap sap://224.0.0.255?same_port=1
|
yading@10
|
596 @end example
|
yading@10
|
597
|
yading@10
|
598 Similarly, for watching in @command{ffplay}:
|
yading@10
|
599
|
yading@10
|
600 @example
|
yading@10
|
601 ffmpeg -re -i @var{input} -f sap sap://224.0.0.255
|
yading@10
|
602 @end example
|
yading@10
|
603
|
yading@10
|
604 And for watching in @command{ffplay}, over IPv6:
|
yading@10
|
605
|
yading@10
|
606 @example
|
yading@10
|
607 ffmpeg -re -i @var{input} -f sap sap://[ff0e::1:2:3:4]
|
yading@10
|
608 @end example
|
yading@10
|
609
|
yading@10
|
610 @subsection Demuxer
|
yading@10
|
611
|
yading@10
|
612 The syntax for a SAP url given to the demuxer is:
|
yading@10
|
613 @example
|
yading@10
|
614 sap://[@var{address}][:@var{port}]
|
yading@10
|
615 @end example
|
yading@10
|
616
|
yading@10
|
617 @var{address} is the multicast address to listen for announcements on,
|
yading@10
|
618 if omitted, the default 224.2.127.254 (sap.mcast.net) is used. @var{port}
|
yading@10
|
619 is the port that is listened on, 9875 if omitted.
|
yading@10
|
620
|
yading@10
|
621 The demuxers listens for announcements on the given address and port.
|
yading@10
|
622 Once an announcement is received, it tries to receive that particular stream.
|
yading@10
|
623
|
yading@10
|
624 Example command lines follow.
|
yading@10
|
625
|
yading@10
|
626 To play back the first stream announced on the normal SAP multicast address:
|
yading@10
|
627
|
yading@10
|
628 @example
|
yading@10
|
629 ffplay sap://
|
yading@10
|
630 @end example
|
yading@10
|
631
|
yading@10
|
632 To play back the first stream announced on one the default IPv6 SAP multicast address:
|
yading@10
|
633
|
yading@10
|
634 @example
|
yading@10
|
635 ffplay sap://[ff0e::2:7ffe]
|
yading@10
|
636 @end example
|
yading@10
|
637
|
yading@10
|
638 @section tcp
|
yading@10
|
639
|
yading@10
|
640 Trasmission Control Protocol.
|
yading@10
|
641
|
yading@10
|
642 The required syntax for a TCP url is:
|
yading@10
|
643 @example
|
yading@10
|
644 tcp://@var{hostname}:@var{port}[?@var{options}]
|
yading@10
|
645 @end example
|
yading@10
|
646
|
yading@10
|
647 @table @option
|
yading@10
|
648
|
yading@10
|
649 @item listen
|
yading@10
|
650 Listen for an incoming connection
|
yading@10
|
651
|
yading@10
|
652 @item timeout=@var{microseconds}
|
yading@10
|
653 In read mode: if no data arrived in more than this time interval, raise error.
|
yading@10
|
654 In write mode: if socket cannot be written in more than this time interval, raise error.
|
yading@10
|
655 This also sets timeout on TCP connection establishing.
|
yading@10
|
656
|
yading@10
|
657 @example
|
yading@10
|
658 ffmpeg -i @var{input} -f @var{format} tcp://@var{hostname}:@var{port}?listen
|
yading@10
|
659 ffplay tcp://@var{hostname}:@var{port}
|
yading@10
|
660 @end example
|
yading@10
|
661
|
yading@10
|
662 @end table
|
yading@10
|
663
|
yading@10
|
664 @section tls
|
yading@10
|
665
|
yading@10
|
666 Transport Layer Security/Secure Sockets Layer
|
yading@10
|
667
|
yading@10
|
668 The required syntax for a TLS/SSL url is:
|
yading@10
|
669 @example
|
yading@10
|
670 tls://@var{hostname}:@var{port}[?@var{options}]
|
yading@10
|
671 @end example
|
yading@10
|
672
|
yading@10
|
673 @table @option
|
yading@10
|
674
|
yading@10
|
675 @item listen
|
yading@10
|
676 Act as a server, listening for an incoming connection.
|
yading@10
|
677
|
yading@10
|
678 @item cafile=@var{filename}
|
yading@10
|
679 Certificate authority file. The file must be in OpenSSL PEM format.
|
yading@10
|
680
|
yading@10
|
681 @item cert=@var{filename}
|
yading@10
|
682 Certificate file. The file must be in OpenSSL PEM format.
|
yading@10
|
683
|
yading@10
|
684 @item key=@var{filename}
|
yading@10
|
685 Private key file.
|
yading@10
|
686
|
yading@10
|
687 @item verify=@var{0|1}
|
yading@10
|
688 Verify the peer's certificate.
|
yading@10
|
689
|
yading@10
|
690 @end table
|
yading@10
|
691
|
yading@10
|
692 Example command lines:
|
yading@10
|
693
|
yading@10
|
694 To create a TLS/SSL server that serves an input stream.
|
yading@10
|
695
|
yading@10
|
696 @example
|
yading@10
|
697 ffmpeg -i @var{input} -f @var{format} tls://@var{hostname}:@var{port}?listen&cert=@var{server.crt}&key=@var{server.key}
|
yading@10
|
698 @end example
|
yading@10
|
699
|
yading@10
|
700 To play back a stream from the TLS/SSL server using @command{ffplay}:
|
yading@10
|
701
|
yading@10
|
702 @example
|
yading@10
|
703 ffplay tls://@var{hostname}:@var{port}
|
yading@10
|
704 @end example
|
yading@10
|
705
|
yading@10
|
706 @section udp
|
yading@10
|
707
|
yading@10
|
708 User Datagram Protocol.
|
yading@10
|
709
|
yading@10
|
710 The required syntax for a UDP url is:
|
yading@10
|
711 @example
|
yading@10
|
712 udp://@var{hostname}:@var{port}[?@var{options}]
|
yading@10
|
713 @end example
|
yading@10
|
714
|
yading@10
|
715 @var{options} contains a list of &-separated options of the form @var{key}=@var{val}.
|
yading@10
|
716
|
yading@10
|
717 In case threading is enabled on the system, a circular buffer is used
|
yading@10
|
718 to store the incoming data, which allows to reduce loss of data due to
|
yading@10
|
719 UDP socket buffer overruns. The @var{fifo_size} and
|
yading@10
|
720 @var{overrun_nonfatal} options are related to this buffer.
|
yading@10
|
721
|
yading@10
|
722 The list of supported options follows.
|
yading@10
|
723
|
yading@10
|
724 @table @option
|
yading@10
|
725
|
yading@10
|
726 @item buffer_size=@var{size}
|
yading@10
|
727 Set the UDP socket buffer size in bytes. This is used both for the
|
yading@10
|
728 receiving and the sending buffer size.
|
yading@10
|
729
|
yading@10
|
730 @item localport=@var{port}
|
yading@10
|
731 Override the local UDP port to bind with.
|
yading@10
|
732
|
yading@10
|
733 @item localaddr=@var{addr}
|
yading@10
|
734 Choose the local IP address. This is useful e.g. if sending multicast
|
yading@10
|
735 and the host has multiple interfaces, where the user can choose
|
yading@10
|
736 which interface to send on by specifying the IP address of that interface.
|
yading@10
|
737
|
yading@10
|
738 @item pkt_size=@var{size}
|
yading@10
|
739 Set the size in bytes of UDP packets.
|
yading@10
|
740
|
yading@10
|
741 @item reuse=@var{1|0}
|
yading@10
|
742 Explicitly allow or disallow reusing UDP sockets.
|
yading@10
|
743
|
yading@10
|
744 @item ttl=@var{ttl}
|
yading@10
|
745 Set the time to live value (for multicast only).
|
yading@10
|
746
|
yading@10
|
747 @item connect=@var{1|0}
|
yading@10
|
748 Initialize the UDP socket with @code{connect()}. In this case, the
|
yading@10
|
749 destination address can't be changed with ff_udp_set_remote_url later.
|
yading@10
|
750 If the destination address isn't known at the start, this option can
|
yading@10
|
751 be specified in ff_udp_set_remote_url, too.
|
yading@10
|
752 This allows finding out the source address for the packets with getsockname,
|
yading@10
|
753 and makes writes return with AVERROR(ECONNREFUSED) if "destination
|
yading@10
|
754 unreachable" is received.
|
yading@10
|
755 For receiving, this gives the benefit of only receiving packets from
|
yading@10
|
756 the specified peer address/port.
|
yading@10
|
757
|
yading@10
|
758 @item sources=@var{address}[,@var{address}]
|
yading@10
|
759 Only receive packets sent to the multicast group from one of the
|
yading@10
|
760 specified sender IP addresses.
|
yading@10
|
761
|
yading@10
|
762 @item block=@var{address}[,@var{address}]
|
yading@10
|
763 Ignore packets sent to the multicast group from the specified
|
yading@10
|
764 sender IP addresses.
|
yading@10
|
765
|
yading@10
|
766 @item fifo_size=@var{units}
|
yading@10
|
767 Set the UDP receiving circular buffer size, expressed as a number of
|
yading@10
|
768 packets with size of 188 bytes. If not specified defaults to 7*4096.
|
yading@10
|
769
|
yading@10
|
770 @item overrun_nonfatal=@var{1|0}
|
yading@10
|
771 Survive in case of UDP receiving circular buffer overrun. Default
|
yading@10
|
772 value is 0.
|
yading@10
|
773
|
yading@10
|
774 @item timeout=@var{microseconds}
|
yading@10
|
775 In read mode: if no data arrived in more than this time interval, raise error.
|
yading@10
|
776 @end table
|
yading@10
|
777
|
yading@10
|
778 Some usage examples of the UDP protocol with @command{ffmpeg} follow.
|
yading@10
|
779
|
yading@10
|
780 To stream over UDP to a remote endpoint:
|
yading@10
|
781 @example
|
yading@10
|
782 ffmpeg -i @var{input} -f @var{format} udp://@var{hostname}:@var{port}
|
yading@10
|
783 @end example
|
yading@10
|
784
|
yading@10
|
785 To stream in mpegts format over UDP using 188 sized UDP packets, using a large input buffer:
|
yading@10
|
786 @example
|
yading@10
|
787 ffmpeg -i @var{input} -f mpegts udp://@var{hostname}:@var{port}?pkt_size=188&buffer_size=65535
|
yading@10
|
788 @end example
|
yading@10
|
789
|
yading@10
|
790 To receive over UDP from a remote endpoint:
|
yading@10
|
791 @example
|
yading@10
|
792 ffmpeg -i udp://[@var{multicast-address}]:@var{port}
|
yading@10
|
793 @end example
|
yading@10
|
794
|
yading@10
|
795 @c man end PROTOCOLS
|