1、MMS協議
MMS全稱Microsoft Multimedia Server，意思是微軟多媒體伺服器，它是微軟公司在上世紀九十年代釋出的多媒體伺服器解決方案，可用於傳輸微軟音影片格式的流媒體直播資料。
MMS協議的直播地址形如mms://***，可透過MMS傳輸的影片格式為WMV，音訊格式為WMA，音影片資料封裝之後的檔案格式為ASF。
MMS協議內部又分為MMSU和MMST，其中MMSU表示MMS協議結合UDP資料傳送。如果MMSU連線失敗，伺服器會嘗試使用MMST，這個MMST表示MMS協議結合TCP資料傳送。
因為MMS協議由微軟公司提出，不相容其他格式的音影片資料流，所以隨著WMV/WMA標準的式微，MMS協議也逐漸無人問津了。
2、RTSP協議
RTSP全稱Real Time Streaming Protocol，意思是實時流傳輸協議，它是網景公司和RealNetworks公司在上世紀九十年代聯合提出的多媒體實時傳輸協議。
RTSP協議的直播地址形如rtsp://***，早期可透過RTSP傳輸的影片格式為RM，音訊格式為RA，音影片資料封裝之後的檔案格式為RM或RMVB。後來RTSP協議增加支援MPEG的音影片標準，即支援傳輸影片格式H.264，音訊格式AAC。
RTSP協議的安全版本是RTSPS，也就是給RTSP協議增加了TLS/SSL支援。RTSPS使用了TLS/SSL協議來加密和保護資料傳輸，以防止資料在傳輸過程中被竊聽和篡改。
因為RTSP提出較早，對服務端的複雜度要求比較高，以至流媒體伺服器SRS乾脆放棄支援RTSP協議，直播錄製軟體OBS Studio也沒支援該協議。在流媒體伺服器中，EasyDarwin、MediaMTX、ZLMediaKit支援RTSP協議。手機直播軟體則有RTMP Streamer支援RTSP協議。
3、RTMP協議
RTMP全稱Real Time Messaging Protocol，意思是實時訊息傳輸協議，它是Adobe公司在零零年代提出的流媒體資料傳輸協議。
RTMP協議的直播地址形如rtmp://***，可透過RTMP傳輸的影片格式為H.264，音訊格式為MP3或者AAC，音影片資料封裝之後的檔案格式為FLV或F4V。
RTMP協議的安全版本是RTMPS，也就是給RTMP協議增加了TLS/SSL支援。RTMPS採用安全套接字層 (SSL) 和傳輸層安全性 (TLS) 兩種加密協議，使資料傳輸更加安全。
RTMP提出時間較早，最後一次更新時間在2012年，以至於未能支援HEVC和AV1等後期的音影片編碼標準。又因為FLV格式沒落已久，以至HTML5規範乾脆移除了Flash外掛，導致如今瀏覽器都不支援rtmp連結，連FFmpeg也遲至6.1版才給rtmp協議支援hevc格式。
不過好在RTMP的穩定性高，服務端的實現相對容易，並且之前的移動網際網路爆發迅速，新的流媒體協議未能及時推出，使得RTMP協議被大量應用於網路直播領域。
在流媒體伺服器中，MediaMTX、ZLMediaKit、SRS都支援RTMP協議。在直播軟體中，電腦端的OBS Studio支援RTMP協議，手機端的RTMP Streamer和SRT Streamer都支援RTMP協議。
透過RTMP協議實現直播功能的說明參見之前的文章《利用RTMP協議構建電腦與手機的直播Demo》和《使用RTMP Streamer開啟APP直播推流》。
4、HLS協議
HLS全稱HTTP Live Streaming，意思是基於HTTP的流媒體傳輸協議，它是蘋果公司於2009年提出的一種由於傳輸音影片的協議互動方式。
HLS採用HTTP協議傳輸音影片資料，訪問地址形如“http://***.m3u8”。HLS協議透過將音影片流切割成TS切片及生成m3u8的播放列表檔案，並通知客戶端透過HTTP協議下載播放列表檔案，按照列表檔案中的順序下載切片檔案並播放，從而實現邊下載邊播放，類似於實時線上播放的效果。
由於HLS在傳輸層只採用HTTP協議，因此它具備HTTP協議的網路優勢，比如很方便透過防火牆或者代理伺服器，可簡單的實現媒體流的負載均衡。因為HLS協議把影片流分片傳輸，使得在直播時延時較大，所以HLS更多用於影片點播領域。
關於HLS協議的更多說明參見之前的文章《分析SRS對HLS協議裡TS包的插幀操作》和《解析H.264碼流中的SPS幀和PPS幀》。
5、SRT協議
SRT全稱Secure Reliable Transport，意思是安全可靠傳輸協議，它由由Haivision 和 Wowza共同建立的SRT聯盟提出。
SRT協議協議的直播地址形如srt://***，它引入了AES加密演算法，無需像RTSP和RTMP那樣引入專門的SSL證書。作為較新的流媒體協議，SRT支援更多的音影片封裝格式。只是該協議的支援庫libsrt在2017年才開源，因此未能在移動網際網路時代大量鋪開，目前主要應用於大型電視直播領域。
FFmpeg從4.0開始支援整合第三方的libsrt庫。在流媒體伺服器中，MediaMTX、ZLMediaKit、SRS都支援SRT協議。在直播軟體中，電腦端的OBS Studio從在25.0開始支援SRT協議，手機端的和SRT Streamer支援SRT協議，而RTMP Streamer不支援SRT協議，只有其升級版才支援SRT協議。
透過SRT協議實現直播功能的說明參見之前的文章《利用SRT協議構建手機APP的直播Demo》和《使用SRT Streamer開啟APP直播推流》。
6、RIST協議
RTST全稱Reliable Internet Stream Transport，意思是可信賴的網際網路流媒體協議，它由2017年成立的RIST工作組提出。
RIST是一個在傳輸層使用UDP協議，並在應用層提供可靠性和流控制功能的流傳輸協議。它並不是一個純粹的應用層協議，而是在傳輸層和應用層之間操作的協議。RIST和SRT具有相同的加密級別，都支援大容量流媒體和前向糾錯功能。
RIST協議的制定時間比SRT還晚，雖然晚制定會多考慮新功能，比如RIST支援點到多點廣播，而SRT不支援；但是晚制定拖累了各開源軟體對RIST的支援力度，比如OBS Studio早在25.0開始支援SRT，遲至27.0才開始支援RIST，另一個直播錄製軟體RootEncoder已支援SRT尚未支援RIST，流媒體伺服器MediaMTX已支援SRT尚未支援RIST。
FFmpeg從4.4開始支援整合第三方的librist庫。在流媒體伺服器中，MediaMTX、ZLMediaKit、SRS都不支援RIST協議。在直播軟體中，電腦端的OBS Studio從在27.0開始支援SRT協議，手機端尚未有開源軟體支援RIST協議。
總的來說，目前國內佔據主要市場份額的直播協議仍是RTMP，不過擁有更好效能的SRT協議正在逐步迎頭趕上，比如騰訊影片雲、京東影片雲等等就引入了SRT協議。有關直播系統的搭建說明參見之前的文章《從0開始搭建直播系統的開源軟體架構》。
更多詳細的FFmpeg開發知識參見