延播需求
直播一般要(yao)求實時(shi)性(xing)，但有(you)些需要(yao)審核的場景，則需要(yao)延遲(chi)播放，留出充足的審核時(shi)間。
因而在直播功(gong)能中(zhong)，需(xu)要人(ren)為引入延(yan)遲。
直播協議分析
直(zhi)播常用(yong)的(de)協(xie)議(yi)有三種，RTMP(專屬推拉(la)流協(xie)議(yi)）,FLV(基(ji)于(yu)(yu)http長鏈接），M3U8(基(ji)于(yu)(yu)http短連接）。
其(qi)中(zhong)RTMP和FLV都是流(liu)式協(xie)議，如果要增加延遲，則需(xu)要在推流(liu)或者拉流(liu)時引(yin)入一個buffer負責緩(huan)存數據。
當緩存(cun)數(shu)據足夠延(yan)遲(chi)的時間時再(zai)將數(shu)據吐(tu)給用(yong)戶(hu)。
對于M3U8協議(yi)來說，用戶首先拉到的(de)是ts列(lie)表，然(ran)后(hou)再選取(qu)列(lie)表中的(de)ts文件進(jin)行下載播放，通過(guo)持續(xu)刷新列(lie)表來實現(xian)直播。
如果要增加延遲，只需要返(fan)回(hui)較舊的ts列表就可以實(shi)現。
ts片已經在服(fu)務器上實現(xian)了數據存儲，因而(er)無需對(dui)數據部分再做更多的處理。
實現方案
1 在直播基礎(chu)上做m3u8的錄制
直(zhi)播(bo)列表通常只返(fan)回最(zui)近的(de)(de)幾個ts片，在做延播(bo)時，需要把最(zui)大延播(bo)時間(jian)的(de)(de)片名都記錄下來，直(zhi)到超過時間(jian)再(zai)做刪(shan)除。對(dui)服務器(qi)上的(de)(de)ts文件，也要適用同樣的(de)(de)刪(shan)除策(ce)略。
2 拉取延播流時(shi)，回放錄制的數據
到達(da)延播(bo)時間時，才(cai)允許響(xiang)應(ying)(ying)延播(bo)數據，否則返回(hui)404。延播(bo)數據就從(cong)錄制的(de)ts列(lie)表(biao)中(zhong)返回(hui)。對ts文件(jian)的(de)響(xiang)應(ying)(ying)，則與(yu)響(xiang)應(ying)(ying)直播(bo)文件(jian)相(xiang)同。
3 其它協議(yi)通過轉推(tui)實現
如果(guo)有(you)其它協議的延播(bo)流(liu)(liu)需求，則通(tong)過轉(zhuan)(zhuan)碼服(fu)務器(qi)，拉取m3u8的延播(bo)流(liu)(liu)，轉(zhuan)(zhuan)推到直播(bo)服(fu)務器(qi)，就可以實現rtmp和flv協議的延播(bo)流(liu)(liu)。
方案特點
優點
- 改造的工作量最小。
- 對斷流重推，尤其是推流到不同機器時的兼容性最好。
缺點
- 受限于切片時長的限制，延播的時間不能精確控制。
