[發(fā)明專利]一種低延時流化HLS實現(xiàn)方法

在審

• 申請?zhí)枺?/td>: 201710610605.6
• 申請日: 2017-07-25
• 公開（公告）號: CN107396205A
• 公開（公告）日: 2017-11-24
• 發(fā)明（設(shè)計）人: 雷健;楊默涵
• 申請（專利權(quán)）人: 觀止云（北京）信息技術(shù)有限公司
• 主分類號: H04N21/643
• 分類號: H04N21/643;H04N21/6437;H04N21/845;H04N21/24;H04N21/258;H04N21/231;H04N21/81;H04N21/458;H04L29/08
• 代理公司: 暫無信息
• 代理人: 暫無信息

技術(shù)領(lǐng)域

本發(fā)明涉及流媒體系統(tǒng)設(shè)計領(lǐng)域，具體地，尤其涉及一種低延時流化HLS實現(xiàn)方法。

背景技術(shù)

近年來，隨著在線視頻技術(shù)多維度的整體提升，“秀場”、“游戲直播”等互動直播模式為廣大網(wǎng)民帶來了實時觀看、深度互動的全新體驗，讓互動直播模式迅速崛起，并逐漸成為新時代的互聯(lián)網(wǎng)社交入口。支撐互動直播的在線視頻技術(shù)是一個較為復(fù)雜和專業(yè)的領(lǐng)域，涉及音視頻編解碼、圖像優(yōu)化處理、流媒體傳輸分發(fā)、多終端播放等多學科技術(shù)的應(yīng)用。互動直播的吸引人之處，在于終端用戶將自己“代入”直播場景中，與主播、其它觀眾像是在一間屋子內(nèi)，不是在看視頻，而是場景中的一員。而這種場景式互動，在直播技術(shù)上極其依賴“低延時”。

目前，各直播平臺的技術(shù)架構(gòu)大同小異，在“低延時”保障方面，PC端和移動APP端通過RTMP或HTTP-FLV協(xié)議將延遲控制到3-5秒，以此配合各種互動功能的實現(xiàn)。而在移動Web端(即基于移動設(shè)備瀏覽器的H5播放器)只能用延遲較大的HLS協(xié)議，因此目前移動Web端還只能實現(xiàn)原始的看直播、看彈幕，最重要的互動功能無法實現(xiàn)。

移動Web端目前唯一可用的HLS協(xié)議，全稱是Http Live Streaming，是由蘋果公司提出的一套基于HTTP傳輸流媒體的網(wǎng)絡(luò)協(xié)議。對于直播來說，它的工作原理是把直播流切分成TS流媒體切片文件，同時生成m3u8索引文件，播放端按照索引文件順序依次下載每個切片文件進行播放。標準的HLS協(xié)議規(guī)定，瀏覽器需要獲取到3個已經(jīng)生成的完整TS切片文件才可以開始播放，而蘋果官方建議的流媒體切片文件時長為10秒左右，加之CDN等網(wǎng)絡(luò)傳輸延時，基于HLS協(xié)議的直播延時理論上會超過40秒。這就是基于HLS協(xié)議的移動Web端直播延時達不到互動直播要求的原因。

發(fā)明內(nèi)容

本發(fā)明的目的在于克服上述問題，從而提出了一種低延時流式HLS技術(shù)(我們首次提出此概念，并命名其為HLS+)，將移動Web端的播放延時降低到接近APP的水平，真正為移動Web端帶來低延時解決方案。移動Web端互動直播避免了終端用戶觀看直播前下載APP的繁瑣。

參見附圖1，它示出了本發(fā)明實施例的低延時流式HLS技術(shù)流程。

本發(fā)明的低延時流式HLS技術(shù)基于標準HLS協(xié)議之上，采用Variant跳轉(zhuǎn)，快速啟動切片算法以及Stage增量算法等多項技術(shù)，動態(tài)地為每個播放請求生成獨立的m3u8列表，把服務(wù)器上緩存的媒體數(shù)據(jù)動態(tài)快速地生成僅對這個播放請求的小切片文件，以此將傳統(tǒng)的HLS流式處理，從而可大大降低標準HLS的延時。播放流程包括以下步驟：

步驟1.播放用戶向邊緣服務(wù)器提出播放請求；

步驟2.邊緣服務(wù)器接到請求，自動分配一個UUID給用戶作為標識；

步驟3.邊緣服務(wù)器啟動RTMP回源拉流(若之前已有其它用戶請求過同一流，則邊緣服務(wù)器已有此流，無須重新拉流)；

步驟4.對要播放的RTMP流數(shù)據(jù)快速啟動切片(每片長度1-2S，甚至更小)，并生成獨立的m3u8列表；

步驟5.播放器拿到獨立的m3u8列表，及最初的3個切片即可開始播放；

步驟6.播放器刷新m3u8列表，然后獲得后續(xù)切片播放；

上述步驟2中，系統(tǒng)利用UUID標識用戶，以保證為每個播放請求獨立切片。上述步驟3中，邊緣服務(wù)器回源與標準HLS協(xié)議不同，拉流采用RTMP流，簡化了回源。上述步驟4中，采用快速啟動切片算法，將gop cache的數(shù)據(jù)快速切片成小切片；并且采用Stage增量算法，保持啟動時切出4個TS片，播放器每次請求m3u8都有新的TS片。

附圖說明

附圖1是本發(fā)明實施例的系統(tǒng)結(jié)構(gòu)及方法流程圖。

具體實施方式

以下將結(jié)合附圖對本發(fā)明的實施例進行詳細說明。應(yīng)當理解此處所描述的實施例僅用于解釋說明本發(fā)明，并不用于限定本發(fā)明。

參見附圖1，它示出了本發(fā)明實施例的低延時流化HLS(即HLS+)的系統(tǒng)結(jié)構(gòu)及方法流程。本發(fā)明的低延時流化HLS技術(shù)在回源拉流時，與RTMP流的回源是完全相同的，無須另外建設(shè)HLS切片系統(tǒng)，簡化了回源過程。

所述的低延時流化HLS(即HLS+)的工作流程如下，包括以下步驟：

步驟1.播放用戶向邊緣服務(wù)器提出播放請求；

步驟2.邊緣服務(wù)器接到請求，通過302跳轉(zhuǎn)或Variant跳轉(zhuǎn)，自動分配一個UUID給用戶作為標識；