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