一：目前主流的視頻分發協議
頭條算是內容分發
流媒體分發方式以HLS和RTMP為主
RTMP指Adobe的RTMP(Realtime Message Protocol)，廣泛應用於低延時直播，也是編碼器和服務器對接的實際標准協議，在PC（Flash）上有最佳觀看體驗和最佳穩定性。
HLS指Apple的HLS(Http Live Streaming)，蘋果公司提出的基於HTTP的流媒體網絡傳輸協議，本身就是Live（直播）
HLS（Http Live Streaming）： 用於實時流傳輸的協議，HLS基於HTTP協議實現，傳輸內容包括兩部分，一是M3U8描述文件，二是TS媒體文件。它的工作原理是把整個流分成一個個小的基於HTTP的文件來下載，每次只下載一些，當媒體流正在播放時，客戶端可以選擇從許多不同的備用源中以不同的速率下載同樣的資源，允許流媒體會話適應不同的數據速率。
HLS的優勢就是：可以自適應調整播放碼流，即網絡暢通時選擇高碼流，網絡繁忙時選擇低碼流，二者可以隨意自行切換，以保證視頻流的流暢度。當然該方法需要服務器提供多碼流視頻數據了，還需在列表文件中注明，播放形式會根據用戶實際情況來調整。直播的方式最好用hls的方式，因為它自己做了獨立的功能模塊，專門適用直播流。
二：基本概念
格式:
M3U: 本質上是音頻文件的列表，純文本格式。播放軟件根據它的記錄找到網絡地址進行在線播放
M3U8: 是M3U中的一種，編碼格式為UTF-8格式
TS片段：Apple 為了提高流播效率開發的技術，將流媒體切分成若干TS片段，然后通過一個m3u列表文件將這些TS片段集中起來供客戶端播放器播放
HLS：HTTP Live Streaming是Apple的動態碼率自適應技術。包括一個m3u8索引文件，TS媒體分片文件和key加密串文件。
TS文件選擇原因：因為兩個 TS 片段可以無縫拼接，播放器能連續播放。
HLS 對應的文件格式是 .m3u8 文件及對應的 .ts 播放文件，即服務器端會有一份 .m3u8 文件和其它很多的 .ts 文件，說得簡單好理解一些是這樣，m3u8文件是一個索引文件，ts為實際的播放內容。
以下內容了解就行：https://blog.csdn.net/weixin_38890593/article/details/96965164
ffmpeg 切割ts流的方法
有兩種方式來切割，一種適合點播，一種適合直播。
一、segment方式
參數
-segment_list_flags +live ：表示直播，加此參數可當做直播來用，但不代表該方式適合直播。
segment_list_size ：對列表數量進行控制在6個。
該方式其實適合點播，因為它的ts流會被保存，相當於錄制下來，如果你需要錄制功能，那么此方法倒是變成了一個優勢。
二、hls方式
直播的方式最好用hls的方式，因為它自己做了獨立的功能模塊，專門適用直播流。
目前新版本的ffmpeg的HLS模塊加了很多參數，函數相關參考libavformat/hlsenc.c、 hls.c、 hlsproto.c
參數解析：
-re ：該參數表示ffmpeg將會按照當前視頻的播放速率進行轉碼，這樣就不會說切片的速度和播放速度不一致。不加這個參數，切片速度會非常快，客戶端還來不及播放，列表已經被更新了。
-hls_time n ：設置每片的長度，默認值為2，單位為秒。
-hls_list_size n ：設置m3u8文件播放列表保存的最多條目，設置為0會保存有所片信息，默認值為5。一般用於直播流，點播文件可以設置成0，即全部保存。
-hls_wrap n ：設置多少片之后開始覆蓋，設置為0則不會覆蓋，默認值為0。這個選項能夠避免在磁盤上存儲過多的片，而且能夠限制寫入磁盤的最多的片的數量。
以上參數可以自己嘗試調整看看效果。
上面兩個命令就是制作m3u8文件的。
m3u8文件介紹
m3u8的直播和點播區別
1、直播沒有#EXT-X-ENDLIST屬性，因為是直播流，不會結束，否則就是點播了。
2、直播不斷更新，移除前面的文件進行替換，且#EXT-X-MEDIA-SEQUENCE屬性標簽以步長為1進行遞增。
不同的協議:
不常見的：
UDP：譬如YY的實時應用，視頻會議等等，或者RTSP之類。這類應用的特點就是實時性要求特別高，以毫秒計算。TCP家族協議根本就滿足不了要求，所以HTTP/TCP都不靠譜。這類應用沒有通用的方案，必須自己實現分發（服務端）和播放（客戶端）。
P2P：譬如RTMFP或者各家自己的協議。這類應用的特點是節省帶寬。目前PC/flash上的RTMFP比較成熟，Android上的P2P屬於起步群雄紛爭標准不一，IOS上P2P應該沒有聽說過。
RTSP：這種不是互聯網上的主要應用，在其他領域譬如安防等有廣泛應用。
常見的：
HTTP progressive：早期流媒體服務器分發http文件時，以普通的http文件分發，這種叫做漸進式下載，意思就是如果文件很大譬如1小時時長1GB大小，想從中間開始播放是不行的。但這種方式已經是作古了，很多http服務器支持http文件的seek，就是從中間開始播放。
HTTP stream：支持seek的HTTP流，譬如各家視頻網站的點播分發方式。或者稍微復雜點的，譬如把一個大文件切幾段之后分發。目前在pc/flash上點播國內的主流分發是這種方式。
HLS：這種是現在適配方式最廣（除了flash, 需要額外的as庫支持），在PC上有vlc，Android/IOS原生播放器就支持播放HLS，HTML5里面的url可以寫HLS地址。總之，在移動端是以HLS為主。
至於DASH/HDS，好像沒有什么特別的理由，就像linux已經大行其道而且開放，其他的系統很難再廣泛應用。
DASH/HDS是什么： 各家提出的HLS，目前還沒有廣泛應用。HDS：adobe自己的HLS，沒啥用。
主流：
HLS：apple的HLS，支持點播和直播。
HTTP：即HTTP stream，各家自己定義的http流，應用於國內點播視頻網站。
RTMP：直播應用，對實時性有一定要求，以PC為主。
總之，SRS支持HLS主要是作為輸出的分發協議，直播以RTMP+HLS分發，滿總各種應用場景。點播以HLS為主。
三：HLS主要的應用場景
跨平台：PC主要的直播方案是RTMP，也有一些庫能播放HLS，譬如jwplayer，基於osmf的hls插件也一大堆。
HLS這種是現在適配方式最廣（除了flash, 需要額外的as庫支持），HTML5里面的url可以寫HLS地址。總之，在移動端是以HLS為主。所以實際上如果選一種協議能跨 PC/Android/IOS，那就是HLS。Android/IOS原生播放器就支持播放HLS
IOS上苛刻的穩定性要求：IOS上最穩定的當然是HLS，穩定性不差於RTMP在PC-flash上的表現。
友好的CDN分發方式：目前CDN對於RTMP也是基本協議，但是HLS分發的基礎是HTTP，所以CDN的接入和分發會比RTMP更加完善。能在各種CDN之間切換，RTMP也能，只是可能需要對接測試。
HLS作為流媒體協議非常簡單，apple支持得也很完善。Android對HLS的支持也會越來越完善。
RTMP本質上是流協議，主要的優勢是：
實時性高：RTMP的實時性在3秒之內，經過多層CDN節點分發后，實時性也在3秒左右。在一些實時性有要求的應用中以RTMP為主。
支持加密：RTMPE和RTMPS為加密協議。雖然HLS也有加密，但在PC平台上flash對RTMPE/RTMPS支持應該比較不錯。
穩定性高：在PC平台上flash播放的最穩定方式是RTMP，如果做CDN或者大中型集群分發，選擇穩定性高的協議一定是必要的。HTTP也很穩定，但HTTP是在協議上穩定；穩定性不只是服務端的事情，在集群分發，服務器管理，主備切換，客戶端的支持上，RTMP在PC分發這種方式上還是很有優勢。
編碼器接入：編碼器輸出到互聯網（還可以輸出為udp組播之類廣電應用），主要是RTMP。譬如專業編碼器，或者flash網頁編碼器，或者FMLE，或者ffmpeg，或者安防攝像頭，都支持RTMP輸出。若需要接入多種設備，譬如提供雲服務；或者希望網頁直接采集攝像頭；或者能在不同編碼器之間切換，那么RTMP作為服務器的輸入協議會是最好的選擇。
系統容錯：容錯有很多種級別，RTMP的集群實現時可以指定N上層，在錯誤時切換不會影響到下層或者客戶端，另外RTMP的流沒有標識，切到其他的服務器的流也可以繼續播放。HLS的流熱備切換沒有這么容易。若對於直播的容錯要求高，譬如降低出問題的概率，選擇RTMP會是很好的選擇。
可監控：在監控系統或者運維系統的角度看，流協議應該比較合適監控。HTTP的流監控感覺沒有那么完善。這個不算絕對優勢，但比較有利。
RTMP的劣勢是：
• 協議復雜：RTMP協議比起HTTP復雜很多，導致性能低下。測試發現兩台服務器直連100Gbps網絡中，HTTP能跑到60Gbps，但是RTMP只能跑到10Gbps，CPU占用率RTMP要高很多。復雜協議導致在研發，擴展，維護軟件系統時都沒有HTTP那么方便，所以HTTP服務器現在大行其道，apache/nginx/tomcat，N多HTTP服務器；而RTMP協議雖然早就公開，但是真正在大規模中分發表現良好的沒有，adobe自己的FMS在CDN中都經常出問題。
• Cache麻煩：流協議做緩存不方便。譬如點播，若做RTMP流協議，邊緣緩存RTMP會很麻煩。如果是HTTP，緩存其實也很麻煩，但是HTTP服務器的緩存已經做了很久，所以只需要使用就好。這是為何點播都走HTTP的原因。
HLS的主要優勢是：
性能高：和HTTP一樣。
穿牆：和HTTP一樣。
原生支持很好：IOS上支持完美。Android上支持差些。PC/flash上現在也有各種as插件支持HLS。
HLS的主要劣勢是：
實時性差：基本上HLS的延遲在10秒以上。
文件碎片：若分發HLS，碼流低，切片較小時，小文件分發不是很友好。特別是一些對存儲比較敏感的情況，譬如源站的存儲，嵌入式的SD卡。