Changes between Version 42 and Version 43 of StreamingGuide

Timestamp:

11/04/2012 03:32:23 AM (7 months ago)

Author:

rogerdpack

Comment:

note tcp options...yikes

StreamingGuide

@@ -101 +101 @@
 }}}
 
+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.
+
 == Codecs ==
 
 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.
+
+mpeg4 (the video codec) sometimes comes "within a few percentage" of the compression of x264, but using much less cpu to do the encoding.
 
 == HTTP Live Streaming and Streaming with multiple bitrates ==
@@ -167 +171 @@
 
  ffmpeg -i INPUT -acodec libmp3lame -ar 11025 --f rtp rtp://host:port
-  where host is the receiving IP.  Then receive the stream using VLC or ffmpeg from that port (since rtp uses UDP, it can start up any time).
+  where host is the receiving IP.  Then receive the stream using VLC or ffmpeg from that port (since rtp uses UDP, the receiver can start up any time).
 
 or 
@@ -173 +177 @@
    ffmpeg -i INPUT -f mpegts udp://host:port
 
-or possibly
+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).
+
+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).
+
+One option to use tcp is like this:
 
   ffmpeg -i INPUT -f mpegts tcp://host:port
 
-which I would guess will try and (as a client) establish a connection with that host and port.
-
-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.
+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).
+
+Another option is to use rtp (which by default uses udp) but specify tcp:
+
+  ffmpeg... -rtsp_transport tcp [http://ffmpeg.org/ffmpeg.html#rtsp see here]
+
+Then you may be able to receive it like this:
+
+ ffplay rtsp://blabla/file?tcp
+
+or possibly like
+
+  ffmpeg... -rtsp_flags listen [http://ffmpeg.org/ffmpeg.html#rtsp see here]
+
+ffmpeg also has a "listen" option for rtmp to it may be able to receive "straight" rtmp streams from a single client.
+
+With tcp based streams you can probably use any formatting/muxer, but with udp  you need to be careful and use a muxer that supports 'connecting anytime' like mpegts.
 
 == External links ==