[發(fā)明專利]媒體流的實(shí)時(shí)接收方法及客戶端

有效

• 申請?zhí)枺?/td>: 201910161631.4
• 申請日: 2019-03-04
• 公開（公告）號(hào): CN111654725B
• 公開（公告）日: 2021-12-21
• 發(fā)明（設(shè)計(jì)）人: 姜紅旗
• 申請（專利權(quán)）人: 北京開廣信息技術(shù)有限公司
• 主分類號(hào): H04N21/2387
• 分類號(hào): H04N21/2387;H04N21/239;H04N21/2668;H04N21/6377;H04N21/6405;H04N21/6408;H04N21/643;H04N21/6437;H04N21/845;H04N21/8547;H04N21/858;H04L29/08
• 代理公司: 北京清亦華知識(shí)產(chǎn)權(quán)代理事務(wù)所(普通合伙) 11201
• 代理人: 張潤

本發(fā)明公開了一種媒體流的實(shí)時(shí)接收方法及客戶端，其中，方法包括：發(fā)送媒體段請求至服務(wù)器；接收并解析服務(wù)器反饋的媒體段，并從媒體段中解析出媒體單元，并生成目標(biāo)媒體流的第一接收報(bào)告；接收并解析至少一路推送的目標(biāo)媒體流，其中，從推送的目標(biāo)媒體流中解析出媒體單元，并生成目標(biāo)媒體流的第二接收報(bào)告；根據(jù)第一接收報(bào)告和第二接收報(bào)告生成新媒體段請求，其中，確定新媒體段請求攜帶的控制參數(shù)。根據(jù)本發(fā)明實(shí)施例的接收方法，集成拉取和推送兩種方式，支持媒體流的單播/多播/廣播傳送，提高實(shí)時(shí)媒體流的傳送效率和可靠性。

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

本發(fā)明涉及數(shù)字信息傳送技術(shù)領(lǐng)域，特別涉及一種媒體流的實(shí)時(shí)接收方法及客戶端。

背景技術(shù)

隨著互聯(lián)網(wǎng)特別是移動(dòng)互聯(lián)網(wǎng)的快速發(fā)展，通過互聯(lián)網(wǎng)來實(shí)時(shí)傳送音頻、視頻、圖像等多媒體數(shù)據(jù)成為許多應(yīng)用的基本需求，為滿足這一需求，人們提出了各種流媒體實(shí)時(shí)傳輸技術(shù)，目前得到廣泛使用的主要包括三類：實(shí)時(shí)傳送協(xié)議RTP((Real-time TransportProtocol，實(shí)時(shí)傳輸協(xié)議)/RTSP(Real Time Streaming Protocol，實(shí)時(shí)流傳輸協(xié)議))、RTMP(Real Time Messaging Protocol，實(shí)時(shí)消息傳送協(xié)議)和HTTP(HyperText TransferProtocol，超文本傳輸協(xié)議)自適應(yīng)性流傳輸HAS(HTTPAdaptive Streaming)。其中，HTTP自適應(yīng)流傳輸又包括多種方案：蘋果公司提出的HLS(HTTP Live Streaming)、微軟提出的平滑流Smooth Streaming、Adobe提出的HDS(HTTP Dynamic Streaming)、MPEG組織提出的DASH(Dynamic Adaptive Streaming over HTTP，基于HTTP的動(dòng)態(tài)自適應(yīng)流)。

上述HTTP自適應(yīng)性流傳輸方案的共同特點(diǎn)是將媒體流切割成短時(shí)間(2s～10s)的媒體片段，并同時(shí)生成描述這些媒體片段的索引文件或清單文件(例如HLS中的m3u8播放列表和DASH中的MPD文件)，然后將其保存到各Web服務(wù)器上，客戶端通過訪問播放列表或清單文件，獲得這些媒體片段的URL(Uniform Resource Locator，統(tǒng)一資源定位符)訪問地址，然后可以采用標(biāo)準(zhǔn)的HTTP協(xié)議來逐個(gè)下載這些媒體片段并進(jìn)行播放。這些方案的主要區(qū)別體現(xiàn)在媒體片段采用的封裝格式和清單文件格式的不同。

相對于RTP/RTSP和RTMP來說，HTTP自適應(yīng)流傳輸可以充分利用現(xiàn)有的互聯(lián)網(wǎng)Web緩存設(shè)施(如CDN和各種Web緩存服務(wù)器)，可以支持大規(guī)模的用戶訪問。同時(shí)，通過提供多種碼率的媒體片段，還可以支持客戶端根據(jù)網(wǎng)絡(luò)條件和終端能力來自行選擇合適碼率的片段，實(shí)現(xiàn)碼率自適應(yīng)。因此，HTTP自適應(yīng)流傳輸已成為目前互聯(lián)網(wǎng)上實(shí)時(shí)流媒體遞送的主流方式。

然而，相關(guān)技術(shù)的HTTP自適應(yīng)流傳輸方案均存在以下問題：

1、媒體片段的時(shí)長無法適應(yīng)動(dòng)態(tài)變化的網(wǎng)絡(luò)傳輸。相關(guān)技術(shù)的HAS方案均采用預(yù)分段的方式，即服務(wù)器按照預(yù)先設(shè)置的時(shí)長來生成媒體片段及其清單文件并提交給web服務(wù)器。當(dāng)網(wǎng)絡(luò)傳輸帶寬充足且延時(shí)較小時(shí)，設(shè)置較大的片段時(shí)長意味著增加實(shí)時(shí)傳送的延時(shí)；當(dāng)網(wǎng)絡(luò)傳輸帶寬不足且延時(shí)較大時(shí)，設(shè)置較小的片段時(shí)長意味著頻繁的文件請求，增加服務(wù)器的負(fù)擔(dān)和網(wǎng)絡(luò)傳輸開銷。由于互聯(lián)網(wǎng)上的傳輸帶寬和傳輸延時(shí)是動(dòng)態(tài)變化的，采用固定時(shí)長的預(yù)分段方式無法實(shí)現(xiàn)最優(yōu)傳輸。

2、清單文件增加了傳送延時(shí)和開銷。客戶端需要先得到清單文件，才能獲得媒體片段的URL地址。但是由于清單文件需要經(jīng)過一段時(shí)間才能傳輸給客戶端，因此，客戶端得到的清單文件并不能反映當(dāng)前最新的媒體片段的生成情況，此外，當(dāng)清單文件遇到阻塞或者傳輸出錯(cuò)時(shí)，將阻塞用戶對媒體片段的快速訪問，降低實(shí)時(shí)流媒體的傳送性能。