annotate ffmpeg/doc/ffmpeg-protocols.pod @ 13:844d341cf643 tip

Back up before ISMIR
author Yading Song <yading.song@eecs.qmul.ac.uk>
date Thu, 31 Oct 2013 13:17:06 +0000
parents 6840f77b83aa
children
rev   line source
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