Legend:

Note that rtp by default uses UDP, which, for large streams, can cause packet loss. See the "point to point" section in this document for hints if this ever happens to you.

104

103

105

== Codecs ==

104

106

105

107

The most popular streaming codec is probably [http://www.videolan.org/developers/x264.html libx264], though if you're streaming to a device which requires a "crippled" baseline h264 implementation, some have argued that the mp4 video codec is [http://forums.macrumors.com/showthread.php?t=398016 better]. You can also use mpeg2video, or really any other video codec you want, typically, as long as your receiver can decode it, and it suits your needs.

108

109

mpeg4 (the video codec) sometimes comes "within a few percentage" of the compression of x264, but using much less cpu to do the encoding.

If you run into packet loss (since UDP is not guaranteed delivery, this might occur) first make sure your FFmpeg is compiled with pthreads support enabled (if it is, then it uses a separate thread to receive from the UDP port, which can cause less packet loss).

180

181

Another option is to use some transmission type that uses TCP for your transport. (The rtmp protocol, popular in streaming to servers, uses TCP probably for this reason--you just can't use that for point to point streaming).

182

183

One option to use tcp is like this:

176

184

177

185

ffmpeg -i INPUT -f mpegts tcp://host:port

178

186

179

which I would guess will try and (as a client) establish a connection with that host and port.

180

181

With tcp you may be able to use any formatting/muxer, but with the others you need to be careful and only use a format that supports 'connecting anytime' like mpegts.

187

which I would guess will try and (as a client) establish a connection do that host on that port (assuming it has a server waiting for the incoming connection).

188

189

Another option is to use rtp (which by default uses udp) but specify tcp: