annotate ffmpeg/doc/protocols.texi @ 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 @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