[發(fā)明專利]減少直播時(shí)延和卡頓的方法及裝置、直播系統(tǒng)

在審

• 申請(qǐng)?zhí)枺?/td>: 201611146731.2
• 申請(qǐng)日: 2016-12-13
• 公開（公告）號(hào): CN106713947A
• 公開（公告）日: 2017-05-24
• 發(fā)明（設(shè)計(jì)）人: 楊松;趙潔;楊志云
• 申請(qǐng)（專利權(quán)）人: 飛狐信息技術(shù)（天津）有限公司
• 主分類號(hào): H04N21/238
• 分類號(hào): H04N21/238;H04N21/24;H04N21/4425;H04N19/89
• 代理公司: 天津創(chuàng)智天誠知識(shí)產(chǎn)權(quán)代理事務(wù)所(普通合伙)12214
• 代理人: 周慶路,田陽

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

本發(fā)明涉及實(shí)時(shí)視頻傳輸技術(shù)領(lǐng)域，特別是涉及一種減少直播時(shí)延和卡頓的方法及裝置、直播系統(tǒng)。

背景技術(shù)

互聯(lián)網(wǎng)直播日益盛行，視頻直播需要占用大量上傳帶寬，然而我國電信運(yùn)營商能夠提供的網(wǎng)絡(luò)上傳帶寬卻一直沒有量的變化，網(wǎng)絡(luò)經(jīng)常會(huì)有抖動(dòng)，主流的直播協(xié)議是rtmp協(xié)議，這個(gè)協(xié)議的基礎(chǔ)是tcp協(xié)議，根據(jù)tcp協(xié)議當(dāng)網(wǎng)絡(luò)發(fā)生波動(dòng)時(shí)，發(fā)送端沒有發(fā)送成功的數(shù)據(jù)包會(huì)等到網(wǎng)絡(luò)恢復(fù)平穩(wěn)后繼續(xù)發(fā)送，在主播端就會(huì)造成數(shù)據(jù)包堆積，這樣客戶端觀看到的直播流就會(huì)變成主播之前一小段時(shí)間的流，增加了直播的延時(shí)。導(dǎo)致互動(dòng)性降低，

直播平臺(tái)互動(dòng)的方式主要是主播進(jìn)行直播，觀眾通過觀看視頻直播，在文字聊天室打字和主播互動(dòng)，文字信息傳輸量小基本是實(shí)時(shí)傳輸，這樣的模式?jīng)Q定了主播端到客戶端的直播延時(shí)在3秒以內(nèi)是可以優(yōu)化互動(dòng)的，大于3秒就會(huì)有明顯的延時(shí)感，主播之前好長(zhǎng)時(shí)間做的事情，觀眾很久之后才能看到，極大地降低互動(dòng)性，而且因?yàn)檠訒r(shí)還導(dǎo)致畫面產(chǎn)生卡頓等情況。

我秀直播平臺(tái)目前采用rtmp協(xié)議進(jìn)行直播，經(jīng)常會(huì)有觀眾端出現(xiàn)觀看延時(shí)的現(xiàn)象，極大地影響了觀眾與主播之間的互動(dòng)。

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

本發(fā)明的目的是針對(duì)現(xiàn)有技術(shù)中存在的技術(shù)缺陷，而提供一種減少直播時(shí)延和卡頓的方法。

為實(shí)現(xiàn)本發(fā)明的目的所采用的技術(shù)方案是：

一種減少直播時(shí)延和卡頓的方法，包括，主播端和客戶端，

主播端包括，

將原數(shù)據(jù)進(jìn)行編碼成預(yù)定數(shù)據(jù)格式，

將編碼后的數(shù)據(jù)打包成數(shù)據(jù)包并發(fā)送至發(fā)送隊(duì)列，

判斷數(shù)據(jù)包發(fā)送隊(duì)列中數(shù)據(jù)包數(shù)量是否正常，

如不正常則主動(dòng)丟棄部分或全部數(shù)據(jù)包使其不進(jìn)入發(fā)送隊(duì)列；

客戶端接收有缺幀時(shí)，當(dāng)缺幀為缺B幀或P幀，則根據(jù)前后幀進(jìn)行補(bǔ)齊，如果缺幀為I幀，則復(fù)制上一組的正常畫面進(jìn)行播放。

所述的直播流的預(yù)定數(shù)據(jù)格式為H.264編解碼格式，所述的數(shù)據(jù)包的傳輸協(xié)議為Rtmp協(xié)議。

客戶端還包括根據(jù)上一幀和下一幀的時(shí)間戳及數(shù)據(jù)包序號(hào)計(jì)得缺失幀的時(shí)間戳。

所述的當(dāng)網(wǎng)絡(luò)出現(xiàn)抖動(dòng)時(shí)主動(dòng)丟棄部分?jǐn)?shù)據(jù)包直至數(shù)據(jù)包發(fā)送隊(duì)列數(shù)量正常為：

當(dāng)所述的數(shù)據(jù)包發(fā)送隊(duì)列的數(shù)量不大于第一閾值，不主動(dòng)丟棄數(shù)據(jù)包，

當(dāng)所述的數(shù)據(jù)包發(fā)送隊(duì)列的數(shù)量大于第一閾值且不大于第二閾值，主動(dòng)丟棄新傳送來的全部B幀數(shù)據(jù)包，

當(dāng)所述的數(shù)據(jù)包發(fā)送隊(duì)列的數(shù)量大于第二閾值且不大于第三閾值，，主動(dòng)丟棄新傳送來的全部B幀數(shù)據(jù)包，丟棄部分或全部P幀數(shù)據(jù)包，

當(dāng)所述的數(shù)據(jù)包發(fā)送隊(duì)列的數(shù)量大于第三閾值，主動(dòng)丟棄新傳送來的全部B幀數(shù)據(jù)包，丟棄全部P幀數(shù)據(jù)包，丟棄部分或全部I幀數(shù)據(jù)包。

客戶端若缺少B幀時(shí)，則根據(jù)播放的畫面根據(jù)相鄰的P幀的圖像做差值進(jìn)行圖像補(bǔ)齊，如相鄰的P幀也缺，則根據(jù)相鄰的P幀和I幀進(jìn)行B幀補(bǔ)齊；

如果缺幀為P幀則根據(jù)相鄰I幀的畫面做差值進(jìn)行圖像補(bǔ)齊。

一種減少直播時(shí)延和卡頓的裝置，包括，主播端和客戶端，

主播端包括，

編碼模塊，用以將原數(shù)據(jù)進(jìn)行編碼成預(yù)定數(shù)據(jù)格式，

傳輸模塊，用以將編碼后的數(shù)據(jù)打包成數(shù)據(jù)包并發(fā)送至發(fā)送隊(duì)列，

發(fā)送狀態(tài)監(jiān)控模塊，用以監(jiān)控?cái)?shù)據(jù)包發(fā)送隊(duì)列的數(shù)據(jù)包數(shù)量并判斷是否正常，

丟包模塊，用以當(dāng)發(fā)送隊(duì)列中數(shù)量不正常時(shí)主動(dòng)丟棄部分或全部數(shù)據(jù)包使其不進(jìn)入發(fā)送隊(duì)列；

客戶端包括，

缺幀處理模塊，當(dāng)缺幀為缺B幀或P幀，則根據(jù)前后幀進(jìn)行補(bǔ)齊，如果缺幀為I幀，則復(fù)制上一組的正常畫面進(jìn)行播放。

所述的編碼模塊H.264編解碼格式，所述的傳輸模塊的傳輸協(xié)議為Rtmp協(xié)議。

客戶端還包括時(shí)間戳計(jì)算模塊，其根據(jù)上一幀和下一幀的時(shí)間戳及數(shù)據(jù)包序號(hào)計(jì)得缺失幀的時(shí)間戳。

所述的丟包模塊的控制方法為，

當(dāng)所述的數(shù)據(jù)包發(fā)送隊(duì)列的數(shù)量不大于第一閾值，不主動(dòng)丟棄數(shù)據(jù)包，

當(dāng)所述的數(shù)據(jù)包發(fā)送隊(duì)列的數(shù)量大于第一閾值且不大于第二閾值，主動(dòng)丟棄新傳送來的全部B幀數(shù)據(jù)包，

當(dāng)所述的數(shù)據(jù)包發(fā)送隊(duì)列的數(shù)量大于第二閾值且不大于第三閾值，主動(dòng)丟棄新傳送來的全部B幀數(shù)據(jù)包，丟棄部分或全部P幀數(shù)據(jù)包，

當(dāng)所述的數(shù)據(jù)包發(fā)送隊(duì)列的數(shù)量大于第三閾值，主動(dòng)丟棄新傳送來的全部B幀數(shù)據(jù)包，丟棄全部P幀數(shù)據(jù)包，丟棄部分I幀數(shù)據(jù)包；