Changes between Version 42 and Version 43 of StreamingGuide


Ignore:
Timestamp:
Nov 4, 2012, 4:32:23 AM (4 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 ==