本發(fā)明屬于網(wǎng)絡(luò)視頻流傳輸技術(shù)領(lǐng)域，涉及一種提高實時視頻播放質(zhì)量的方法。

背景技術(shù)：

隨著多媒體技術(shù)和網(wǎng)絡(luò)技術(shù)的迅速發(fā)展，網(wǎng)絡(luò)上傳輸?shù)拿襟w信息由原來的文字和圖片逐步過渡到聲音和視頻等多媒體格式，傳輸?shù)姆绞揭灿上认螺d再播放轉(zhuǎn)變成邊下載邊播放的流媒體方式，流媒體技術(shù)已成為網(wǎng)絡(luò)傳輸多媒體數(shù)據(jù)的主流技術(shù)。其主要思想就是把視頻和音頻等多媒體文件經(jīng)過特殊的壓縮方式分成一個個壓縮包，由服務(wù)器向用戶計算機連續(xù)、實時傳送；用戶無需將整個文件下載完畢，只需經(jīng)過較短時間的啟動延時即可在用戶計算機上進行播放，剩余的部分將繼續(xù)進行下載，直至播放完畢。

流媒體傳輸協(xié)議是流媒體技術(shù)的重要組成部分，包括rsvp(resourcereservationprotocol資源預(yù)留協(xié)議)、rtp(real-timetransportprotocol實時傳輸協(xié)議)、rtcp(rtpcontrolprotocol實時傳輸控制協(xié)議)、rtsp(realtimestreamingprotocol實時流協(xié)議)。其中，rtp(real-timetransportprotocol實時傳輸協(xié)議)為多媒體數(shù)據(jù)提供端到端的實時傳輸服務(wù)，是實時流傳輸?shù)闹匾獏f(xié)議之一。

h.264/mpeg-4avc(h.264)是1995年自mpeg-2視頻壓縮標準發(fā)布以后的最新、最有前途的視頻壓縮標準。通過該標準，在同等圖象質(zhì)量下的壓縮效率比之前的標準提高了2倍以上，因此，h.264/mpeg-4avc(h.264)被普遍認為是最有影響力的行業(yè)標準。

隨著人們對網(wǎng)絡(luò)通信服務(wù)的依賴性與要求越來越高，qos(qualityofservice傳輸服務(wù)質(zhì)量)成為實時流媒體系統(tǒng)中最為關(guān)注的問題。當前internet(因特網(wǎng))是以best-effort(標準的因特網(wǎng)服務(wù)模式)方式工作的異構(gòu)網(wǎng)絡(luò)，其終端接入方式、可用帶寬、延遲抖動和丟包等因素都是動態(tài)變化和不可預(yù)知的，難以滿足實時流媒體傳輸?shù)囊?，視頻信息的傳輸常常會因為網(wǎng)絡(luò)環(huán)境不穩(wěn)定而暫停或出現(xiàn)馬賽克，網(wǎng)絡(luò)狀態(tài)的波動極大的影響著視頻信息的播放效果，服務(wù)質(zhì)量很難保證。為使實時流媒體能夠適應(yīng)internet(因特網(wǎng))的特點，提高流媒體服務(wù)質(zhì)量，研究人員在針對rtp協(xié)議進行實時流傳輸?shù)倪^程中給出了很多解決和優(yōu)化方案，比如，對實時流傳輸過程中防丟包和丟包修復(fù)算法進行了研究，盡可能的解決丟包問題；通過對實時流傳輸過程中的傳輸速率和擁塞控制進行研究，來提高傳輸質(zhì)量；對實時視頻傳輸中接收端緩沖技術(shù)做了研究，來提高播放流暢度。

盡管如此，實時流媒體的服務(wù)質(zhì)量仍有相當大的改進空間，而在異構(gòu)、低比特率、高丟包率、強干擾及無線網(wǎng)絡(luò)等網(wǎng)絡(luò)環(huán)境下，實時流媒體傳輸技術(shù)更需要進一步的研究與完善。

技術(shù)實現(xiàn)要素：

本發(fā)明的目的是提供一種提高實時視頻播放質(zhì)量的方法，解決了現(xiàn)有實時流媒體技術(shù)，存在的丟包、視頻傳輸延時和畫面質(zhì)量較差的問題。

本發(fā)明所采用的技術(shù)方案是，一種提高實時視頻播放質(zhì)量的方法，按照以下過程實施：

設(shè)置滑動窗口，滑動窗口是將時間范圍對應(yīng)為rtp包的數(shù)量，滑動窗口是在一定的時間范圍內(nèi)，等待序號較小但接收較遲的包，將時間范圍對應(yīng)為包之間的跨度，滑動窗口有兩個范圍，即左邊界wl和右邊界wr，

左邊界wl的表達式如下：

wl由兩部分組成，一部分是固定值num，另外一部分是客戶端在接收num個rtp包的時間里，視頻提供端產(chǎn)出多少個rtp包；mtu表示最大傳輸單元，即1500字節(jié)，s表示播放程序每秒鐘收到的視頻字節(jié)數(shù)，fps表示視頻的分辨率；

右邊界wr的表達式如下：wr＝λ×f×num+wl，

wr的值是在wl的基礎(chǔ)上，加上一個播放端能夠容忍的包間隔；f*num粗略的表示了在理想情況下1秒時間內(nèi)播放端接收到的包；λ作為程序的配置參數(shù)，是播放端接收的最大延遲時間秒數(shù)；

滑動窗口將整個數(shù)值范圍分為三部分，當w＝r-1-n，也就是未收到的包的序號和當前接收包的序號的差值，落在不同的范圍內(nèi)時，進入不同的處理過程：

1)當0<w<wr時，說明未接收到的包與當前接收包的時差較小，此時不解碼，繼續(xù)等待；

2)當wl<w<wr時，則利用整個集合中的rtp包重組nalu，準備進行解碼；

若集合中的rtp包是某個關(guān)鍵幀的打包，則需要進行重傳處理，這要求發(fā)送方或者視頻數(shù)據(jù)中轉(zhuǎn)方有一定的rtp包緩存能力，在播放端請求最近傳輸過的關(guān)鍵幀的某個rtp包時，重新傳遞給播放端；對于重傳的包，要有超時機制，超時的時間最終對應(yīng)在包數(shù)目上，這種等待是改變wl的值，即wl＝wl+num，進入下次接收；

若集合中的rtp包非關(guān)鍵幀的打包，則是將整個集合中的數(shù)據(jù)丟棄，并從當前開始丟棄所有非關(guān)鍵幀的rtp包，直到接收到關(guān)鍵幀的rtp包重新開始處理；

3)當w>wr時，則需要丟棄整個集合中的rtp包，從當前接收包pr處開始重新處理。

本發(fā)明的有益效果是，針對視頻播放端接收rtp(real-timetransportprotocol實時傳輸協(xié)議)協(xié)議傳輸?shù)膆.264(視頻編解碼技術(shù)標準之一)視頻流，并重組h.264nalu的過程中，根據(jù)網(wǎng)絡(luò)狀況、被傳輸視頻的分辨率、幀率等參數(shù)，盡可能的利用接收到rtp數(shù)據(jù)包進行nalu重組并解碼，在必要時要求發(fā)送方對關(guān)鍵幀進行重傳，有效改善了在較差網(wǎng)絡(luò)環(huán)境條件下，視頻傳輸延時和畫面質(zhì)量較差的問題，提高了視頻播放質(zhì)量。包括以下幾個方面優(yōu)點：

1)當前，大部分的nvr/dvr(networkvideorecorder即網(wǎng)絡(luò)硬盤錄像機/digitalvideorecorder即硬盤錄像機)的廠商都提供了sdk(softwaredevelopmentkit即軟件開發(fā)工具包)，開發(fā)者通過該sdk得到攝像頭的實時視頻數(shù)據(jù)，而具體的視頻傳輸過程、解碼過程都需要開發(fā)者自主實現(xiàn)，本發(fā)明算法實施的階段是從nvr/dvr得到視頻數(shù)據(jù)，進行打包傳輸以及在播放端組包、解碼播放的這一過程，算法的實現(xiàn)不需要依賴nvr/dvr廠商的修改或者更新。

2)本發(fā)明改善實時視頻畫面的質(zhì)量。本發(fā)明對非i幀的不完整nalu直接丟棄，而對不完整的i幀，則會進行重傳，這使得畫面的花屏、卡頓次數(shù)減少；對部分非i幀的丟棄，可能使得畫面有跳躍現(xiàn)象，但在實際監(jiān)控過程中不會影響監(jiān)控的整體效果。

3)本發(fā)明改變了傳統(tǒng)方法根據(jù)時戳、序號進行排序的思路，在保證準確性的條件下，簡化了視頻包排序流程，快速完成視頻流的順序解包及播放過程，并保證結(jié)果的實時性和準確性。實驗結(jié)果表明，使用本發(fā)明不僅在網(wǎng)絡(luò)環(huán)境優(yōu)良的情況下，能保持較高的視頻清晰度，而且在網(wǎng)絡(luò)不穩(wěn)定的情況下，通過相應(yīng)處理，依然能保證視頻播放的流暢度和準確性。

附圖說明

圖1是本發(fā)明方法中的rtp包采用哈希表緩存；

圖2是本發(fā)明方法中的rtp傳輸h.264nalu示意；

圖3是本發(fā)明與現(xiàn)有技術(shù)在不同環(huán)境下視頻數(shù)據(jù)的傳輸速率對比曲線；

圖4是本發(fā)明與現(xiàn)有技術(shù)的畫面質(zhì)量對比曲線；

圖5是本發(fā)明與現(xiàn)有技術(shù)的畫面延遲效果對比曲線。

具體實施方式

下面結(jié)合附圖和具體實施方式對本發(fā)明進行詳細說明。

rtp協(xié)議基于udp協(xié)議傳輸，而且rtp協(xié)議本身沒有任何機制保證數(shù)據(jù)傳輸?shù)挠行蛐院涂煽啃?。由于udp的不可靠性，nalu分割后的rtp包可能會出現(xiàn)亂序(out-of-order)和丟包的現(xiàn)象。

播放端在接收rtp包時，采用一張哈希表來緩存rtp包進行處理，在哈希表中，使用rtp包序號和rtp包一起組成一個鍵值對。當播放端接收部分，接收到一個rtp包后，將其序號和內(nèi)容組成一個鍵值對插入到哈希表中。而播放端解碼部分的工作是記錄下要解碼的rtp包序號，并不斷從哈希表中取出rtp包還原nalu后進行解碼，如圖1所示。處理過程中，只需要記錄當前正在處理的rtp包序列號和正在接收的rtp包序號。

在視頻傳輸過程中，同屬于一個nalu的rtp包的時間戳相同，且rtp包序號連續(xù)。所以，當接收rtp包的時候，若發(fā)現(xiàn)包的時間戳發(fā)生改變，是接收到了一個新的nalu的rtp包。一個完整的nalu能夠直接提供給解碼器進行解碼播放。

由于是基于rtp包的時間戳發(fā)生改變，來判斷一個nalu的rtp包是否接收完成，而時間戳的改變，可能會存在兩種情形：一種是兩個連續(xù)的nalu的rtp時間戳的改變；另一種是兩個nalu之間的一個或者多個nalu數(shù)據(jù)丟失，從而使兩個不連續(xù)的nalu的rtp時間戳的改變，如圖2所示，因此，這種不連續(xù)可能發(fā)生在集合中的某一個元素pn或者多個元素pn，pn-1…(n＝d,d+1,…,r-1)上。

當集合pnalu中的元素出現(xiàn)不連續(xù)時，組成的nalu直接交給解碼器解碼的話，會出現(xiàn)錯誤，導(dǎo)致畫面質(zhì)量出現(xiàn)問題。

綜合考慮以上情況，本發(fā)明方法的具體實施過程如下：

本發(fā)明主要的創(chuàng)新點在于重新設(shè)置了rtp包的視頻重組算法，核心思想是對屬于同一nalu的rtp包，給出一個可變化的時間范圍，在該時間范圍內(nèi)處理該nalu所屬rtp包的亂序、丟包，如果該nalu是關(guān)鍵幀的話，還會在一個可變化時間范圍內(nèi)支持重傳丟失的rtp包，這個可變化的時間范圍稱為滑動窗口；對屬于關(guān)鍵nalu的rtp包的重傳稱為關(guān)鍵幀重傳；

滑動窗口的核心是將時間范圍對應(yīng)為rtp包的數(shù)量，滑動窗口的目地是在一定的時間范圍內(nèi)，等待序號較小但接收較遲的包，而在具體過程上是將時間范圍對應(yīng)為包之間的跨度，具體的說，滑動窗口有兩個范圍，即左邊界wl和右邊界wr，

左邊界wl的表達式如下：

wl由兩部分組成，一部分是固定值num，另外一部分是客戶端在接收num個rtp包的時間里，視頻提供端產(chǎn)出多少個rtp包；mtu表示最大傳輸單元，即1500字節(jié)，s表示播放程序每秒鐘收到的視頻字節(jié)數(shù)，fps表示視頻的分辨率；

右邊界wr的表達式如下：wr＝λ×f×num+wl，

wr作為右邊界的主要目的是為了簡化處理邏輯，它的值是在wl的基礎(chǔ)上，加上一個播放端能夠容忍的包間隔(時間范圍)；f*num粗略的表示了在理想情況下1秒時間內(nèi)播放端接收到的包；λ作為程序的配置參數(shù)，是播放端接收的最大延遲時間秒數(shù)；

這樣，滑動窗口將整個數(shù)值范圍分為三部分，當w＝r-1-n，也就是未收到的包的序號和當前接收包的序號的差值，落在不同的范圍內(nèi)時，進入不同的處理過程：

1)當0<w<wr時，說明未接收到的包與當前接收包的時差較小，此時不解碼，繼續(xù)等待；

2)當wl<w<wr時，則利用整個集合中的rtp包重組nalu，準備進行解碼；

若集合中的rtp包是某個關(guān)鍵幀的打包，則需要進行重傳處理，這要求發(fā)送方或者視頻數(shù)據(jù)中轉(zhuǎn)方有一定的rtp包緩存能力，在播放端請求最近傳輸過的關(guān)鍵幀的某個rtp包時，重新傳遞給播放端；對于重傳的包，要有超時機制，超時的時間最終對應(yīng)在包數(shù)目上，這種等待是改變wl的值，即wl＝wl+num，進入下次接收；

若集合中的rtp包非關(guān)鍵幀的打包，則是將整個集合中的數(shù)據(jù)丟棄，并從當前開始丟棄所有非關(guān)鍵幀的rtp包，直到接收到關(guān)鍵幀的rtp包重新開始處理；

3)當w>wr時，則需要丟棄整個集合中的rtp包，從當前接收包pr處開始重新處理。

實施例

第一、實驗準備

當前，大部分的nvr/dvr的廠商都提供了sdk，開發(fā)者通過該sdk得到攝像頭的實時視頻數(shù)據(jù)，而具體的視頻傳輸過程、解碼過程都需要開發(fā)者自主實現(xiàn)，本發(fā)明方法實施階段是從nvr/dvr得到視頻數(shù)據(jù)，進行打包傳輸以及在播放端組包、解碼播放的，其中的算法實現(xiàn)不需要依賴nvr/dvr廠商的修改或者更新。

h.264視頻的分辨率越大，視頻流中的nalu就會越大。為了體現(xiàn)本發(fā)明在不同分辨率的實時視頻播放中產(chǎn)生的效果，在驗證的過程中，以?？禂z像頭實時產(chǎn)生的視頻碼流，作為實驗的數(shù)據(jù)，這種碼流的編碼信息為：15fps、1920*1080。將該編碼格式的視頻，截取8～10分鐘的視頻流保存為文件，作為發(fā)送方的視頻輸入源，這就保證了后續(xù)所有實驗過程是使用同樣內(nèi)容的視頻數(shù)據(jù)。

由于實驗數(shù)據(jù)的范圍受到網(wǎng)絡(luò)環(huán)境影響較大，本實驗是在大型內(nèi)網(wǎng)中進行，發(fā)送方pc和播放端pc分別處在不同的內(nèi)網(wǎng)中，發(fā)送方pc使用有線連接，播放端pc使用無線連接；該內(nèi)網(wǎng)中的這兩個子網(wǎng)之間的網(wǎng)絡(luò)傳輸在一段時間內(nèi)波動不大，且下文中的實驗結(jié)果都是在一個連續(xù)的時間段內(nèi)完成的。

本發(fā)明主要目標是在傳輸狀況較差的網(wǎng)絡(luò)環(huán)境中，改善實時視頻畫面質(zhì)量，且對視頻的實時性不會有較大的影響。為了能夠更清晰的展示本發(fā)明的優(yōu)點，選擇了1080p、15幀的視頻，在此使用另外兩種傳輸場景與本發(fā)明實現(xiàn)場景進行對比，以分析本發(fā)明的優(yōu)點和不足，這三種傳輸場景分別是：

場景a、基于udp的標準rtp/rtcp的傳輸場景，對有丟失rtp分包的nalu，直接丟棄，避免解碼器收到錯誤的nalu后出錯，下文中以rtp/rtcp代稱。

場景b、基于tcp的nalu傳輸，通過tcp將nalu傳送到播放端進行播放，沒有使用rtp協(xié)議，下文中以tcp代稱。

場景c、基于udp的rtp協(xié)議，并結(jié)合本文提出算法的傳輸場景，下文中以rtp+代稱。

第二、驗證對比

1)驗證視頻數(shù)據(jù)的傳輸速率

在同一網(wǎng)絡(luò)環(huán)境下，分別在場景a、場景b和場景c三種傳輸場景中進行播放，在播放端通過接收到的數(shù)據(jù)，來對比視頻數(shù)據(jù)的傳輸速率，其結(jié)果如圖3所示。

圖3中，場景b是使用tcp進行傳輸，由于tcp本身的機制，使得其傳輸視頻數(shù)據(jù)要遠遠慢于udp，而場景a和場景c都是使用udp進行傳輸，可見前者的傳輸效率遠慢于后兩者；場景c，也就是本發(fā)明方法相對于場景b有明顯的優(yōu)勢。對于場景a和場景c，單純從視頻傳輸來講，場景c需要在關(guān)鍵幀丟失后，進行關(guān)鍵幀重傳，其平均傳輸速率要低于場景a的傳輸速率。另外，場景a和場景c都包含了控制命令，場景a使用rtcp提供數(shù)據(jù)發(fā)送反饋信息，場景c需要在關(guān)鍵幀丟失時，通知發(fā)送方重新傳輸丟失的數(shù)據(jù)。rtcp協(xié)議包是間隔性發(fā)送的，而關(guān)鍵幀重傳的請求則只有在關(guān)鍵幀丟失后，才會發(fā)出。所以在控制信息上，場景c傳輸?shù)臄?shù)據(jù)要少于場景a。

當然，網(wǎng)絡(luò)環(huán)境對這種傳輸速率的對比也有較大的影響。在極差的網(wǎng)絡(luò)環(huán)境下，如果rtp丟包次數(shù)頻繁，那么關(guān)鍵幀丟失的可能性就會變大，需要重傳的次數(shù)就會變多。若重傳請求若是使用udp實現(xiàn)的話，重傳請求因為網(wǎng)絡(luò)變差的原因，也存在著丟失的可能，使得能被真正重傳的關(guān)鍵幀減少，這樣本發(fā)明方法傳輸?shù)男驶竞褪褂脠鼍癮的時候一致。

2)驗證對視頻畫面質(zhì)量的改善

將視頻流在同一網(wǎng)絡(luò)環(huán)境下，分別通過在場景a、場景b和場景c三種傳輸場景中進行播放，來統(tǒng)計大概8分鐘的時間內(nèi)，畫面的花屏、不連續(xù)畫面數(shù)，來進行對比，結(jié)果如圖4所示。

圖4中，每種類型的視頻類型在不同的傳輸場景中有兩個重要的衡量指標，視頻畫面花屏和畫面卡頓，分別用不同顏色的柱體表示，柱體的高度表示其數(shù)量的多少。當在播放1080p時，在場景c播放的畫面質(zhì)量優(yōu)勢就顯現(xiàn)出來了，無論是相對于場景b的卡頓，還是相對于場景a的畫面花屏數(shù)，都有明顯的優(yōu)勢。

本發(fā)明對非i幀的不完整nalu直接丟棄，而對不完整的i幀，則會進行重傳，這使得畫面的花屏、卡頓次數(shù)減少。對部分非i幀的丟棄，可能使得畫面有跳躍現(xiàn)象，但在實際監(jiān)控過程中不會影響監(jiān)控的整體效果。

3)驗證對nalu傳輸延遲的影響

以1080p、15fps的h.264視頻作為輸入源在場景a、場景b和場景c中分別進行播放，在每個播放場景中選取30個i幀的發(fā)出時間和提交給解碼器的時間，使用δt(該數(shù)據(jù)包的發(fā)送時間記為ts，接收時間記為tv，這兩個時間差的絕對值)修改后，用發(fā)出時間與提交給解碼器的時間作差，差值依序在平面坐標系中顯示后，其結(jié)果如圖5所示。

圖5中，在使用場景b，也就是tcp傳輸?shù)臅r候，延遲明顯大于場景a和場景c，甚至部分nalu成倍數(shù)的延時。而使用場景a，也就是標準的rtp/rtcp時，nalu的處理延遲最小。而使用場景c，nalu的處理延遲比較平穩(wěn)，但略大于使用標準rtp/rtcp的方式。

圖5所示的結(jié)果也能夠通過分析預(yù)測到，在傳輸大量數(shù)據(jù)的時候，必然會因為擁塞等原因產(chǎn)生丟包，而tcp協(xié)議的做法是實現(xiàn)重傳并進行確認，而標準rtp/rtcp是基于udp協(xié)議的，沒有實現(xiàn)任何保證數(shù)據(jù)可靠性的機制；而本發(fā)明只是在處理亂序的基礎(chǔ)上，對關(guān)鍵幀丟包進行重傳，且這種重傳機制具有時效性，并不保證一定能夠重傳到丟失的數(shù)據(jù)。

綜合上述結(jié)果的分析，本發(fā)明方法在視頻分辨率較大、視頻質(zhì)量較高的情況，均有比較明顯的優(yōu)勢。