Changes between Version 42 and Version 43 of StreamingGuide


Ignore:
Timestamp:
Nov 4, 2012, 4:32:23 AM (7 years ago)
Author:
rogerdpack
Comment:

note tcp options...yikes

Legend:

Unmodified
Added
Removed
Modified
  • StreamingGuide

    v42 v43  
    101101}}}
    102102
     103Note 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
    103105== Codecs ==
    104106
    105107The 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
     109mpeg4 (the video codec) sometimes comes "within a few percentage" of the compression of x264, but using much less cpu to do the encoding.
    106110
    107111== HTTP Live Streaming and Streaming with multiple bitrates ==
     
    167171
    168172 ffmpeg -i INPUT -acodec libmp3lame -ar 11025 --f rtp rtp://host:port
    169   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).
     173  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).
    170174
    171175or
     
    173177   ffmpeg -i INPUT -f mpegts udp://host:port
    174178
    175 or possibly
     179If 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
     181Another 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
     183One option to use tcp is like this:
    176184
    177185  ffmpeg -i INPUT -f mpegts tcp://host:port
    178186
    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.
     187which 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
     189Another option is to use rtp (which by default uses udp) but specify tcp:
     190
     191  ffmpeg... -rtsp_transport tcp [http://ffmpeg.org/ffmpeg.html#rtsp see here]
     192
     193Then you may be able to receive it like this:
     194
     195 ffplay rtsp://blabla/file?tcp
     196
     197or possibly like
     198
     199  ffmpeg... -rtsp_flags listen [http://ffmpeg.org/ffmpeg.html#rtsp see here]
     200
     201ffmpeg also has a "listen" option for rtmp to it may be able to receive "straight" rtmp streams from a single client.
     202
     203With 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.
    182204
    183205== External links ==