專利名稱：一種iptv系統(tǒng)中丟包處理的方法、服務(wù)器及系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域，尤其涉及一種在IPTV系統(tǒng)中丟包處理的方法、服務(wù)器及系 統(tǒng)。
背景技術(shù)：
隨著流媒體業(yè)務(wù)發(fā)展迅速，流媒體業(yè)務(wù)的內(nèi)容和形式豐富多樣，越來越多的用戶 通過機(jī)頂盒或移動(dòng)手機(jī)享受各種各樣的音視頻業(yè)務(wù)。流媒體業(yè)務(wù)由于自身的技術(shù)特點(diǎn)，業(yè) 務(wù)的廣泛應(yīng)用受到視頻編碼效率以及網(wǎng)絡(luò)傳輸質(zhì)量的影響。視頻編碼技術(shù)可以實(shí)現(xiàn)視頻數(shù)據(jù)的大量壓縮，是流媒體業(yè)務(wù)廣泛開展前提。隨著 視頻編碼技術(shù)的進(jìn)步，視頻數(shù)據(jù)編碼效率大幅提高，特別是H. 264編碼算法的推廣，推動(dòng)了 流媒體業(yè)務(wù)的發(fā)展。但是，由于受網(wǎng)絡(luò)帶寬的限制，流媒體業(yè)務(wù)經(jīng)常出現(xiàn)各種各樣影響業(yè)務(wù) 質(zhì)量(Quality of Service,Qos)的問題。其中，由于網(wǎng)絡(luò)擁塞導(dǎo)致數(shù)據(jù)包丟失的問題對(duì)用 戶的體驗(yàn)影響最為嚴(yán)重，經(jīng)過編碼處理后的任何數(shù)據(jù)丟失，都將影響用戶終端的解碼播放 的圖像。針對(duì)網(wǎng)絡(luò)擁塞導(dǎo)致數(shù)據(jù)丟失進(jìn)而影響用戶的體驗(yàn)，現(xiàn)有技術(shù)一般采用如下方案1、超時(shí)重傳(Automatic Repeat Request, ARQ)技術(shù)信宿終端在一定時(shí)間內(nèi)沒有 收到某個(gè)數(shù)據(jù)報(bào)文，信宿端會(huì)向信源端發(fā)送超時(shí)重傳的請(qǐng)求，然后信源根據(jù)報(bào)文的需要進(jìn) 行數(shù)據(jù)報(bào)文的重傳。通過數(shù)據(jù)報(bào)的重傳，減少傳輸數(shù)據(jù)包丟失，提升信宿端解碼的質(zhì)量。但 是當(dāng)網(wǎng)絡(luò)嚴(yán)重?fù)砣?，丟包(數(shù)據(jù)包丟失)率超過一定比例時(shí)，過度的超時(shí)重傳不僅會(huì)進(jìn)一步 增加網(wǎng)絡(luò)的擁塞程度，還會(huì)導(dǎo)致傳輸碼率的突發(fā)，產(chǎn)生更嚴(yán)重的丟包，嚴(yán)重影響一段時(shí)間內(nèi) 的網(wǎng)絡(luò)傳輸質(zhì)量。2、傳輸控制協(xié)議(Transmission Control ftOtocol，TCP)承載技術(shù)信源和信宿之 間采用TCP傳輸方式，信源端發(fā)包線程負(fù)責(zé)讀取流媒體數(shù)據(jù)，并按照固定的速率調(diào)用網(wǎng)絡(luò) 層的接口，向網(wǎng)絡(luò)緩存區(qū)寫入數(shù)據(jù)，然后并由網(wǎng)絡(luò)層獨(dú)立處理數(shù)據(jù)的網(wǎng)絡(luò)發(fā)送過程。而網(wǎng)絡(luò) 層根據(jù)TCP的流量控制和擁塞控制機(jī)制，和信宿端協(xié)商數(shù)據(jù)的發(fā)送方式和速率，保證數(shù)據(jù) 完整可靠地被信宿接收。通過TCP傳輸機(jī)制，可以確保信源和信宿之間傳輸鏈路上沒有數(shù) 據(jù)報(bào)文的丟失，但是由于信源服務(wù)器的應(yīng)用層沒有實(shí)時(shí)監(jiān)控網(wǎng)絡(luò)層的狀況，很可能發(fā)生網(wǎng) 絡(luò)層緩存區(qū)的寫入速率大于讀出速率的情況，最終導(dǎo)致發(fā)送緩存區(qū)溢出，數(shù)據(jù)報(bào)文丟失采用ARQ技術(shù)或者TCP技術(shù)，在網(wǎng)絡(luò)擁塞的情況下，由于數(shù)據(jù)包都是被隨機(jī)丟棄 的，當(dāng)丟失的正好是關(guān)鍵數(shù)據(jù)時(shí)將導(dǎo)致其整個(gè)一個(gè)序列所有幀的圖像都無法解碼，最終嚴(yán) 重影響信宿端解碼的質(zhì)量。導(dǎo)致終端播放的文件出現(xiàn)嚴(yán)重失真、延時(shí)，甚至無法播放等問 題，用戶體驗(yàn)較差。

發(fā)明內(nèi)容
有鑒于此，為了避免在網(wǎng)絡(luò)擁塞的情況下，由于IPTV系統(tǒng)媒體數(shù)據(jù)中的關(guān)鍵、核 心數(shù)據(jù)包被被動(dòng)、隨機(jī)丟棄，從而導(dǎo)致的無法解碼，最終嚴(yán)重影響信宿端的解碼質(zhì)量的問題。本發(fā)明實(shí)施例提供了一種IPTV系統(tǒng)中丟包處理方法和服務(wù)器。本發(fā)明實(shí)施例提供了一種IPTV系統(tǒng)中丟包處理方法，包括解析待發(fā)送媒體數(shù)據(jù)的網(wǎng)絡(luò)提取層(Network Abstraction Layer, NAL)頭和分片 Slice頭數(shù)據(jù)，確認(rèn)所述待發(fā)送媒體數(shù)據(jù)中數(shù)據(jù)包的重要等級(jí)；獲取客戶端根據(jù)接收媒體數(shù)據(jù)返回的結(jié)果信息，所述結(jié)果信息至少包括所述客戶 端接收所述媒體數(shù)據(jù)的數(shù)據(jù)丟失信息；根據(jù)所述數(shù)據(jù)丟失信息確定當(dāng)前傳輸網(wǎng)絡(luò)的擁塞等級(jí)；根據(jù)所述當(dāng)前傳輸網(wǎng)絡(luò)的擁塞等級(jí)和所述數(shù)據(jù)包的重要等級(jí)，結(jié)合預(yù)先制定的丟 包策略進(jìn)行丟包處理。另外，本發(fā)明實(shí)施例還提供了一種流媒體服務(wù)器，包括分析模塊，用于解析待發(fā)送媒體數(shù)據(jù)的網(wǎng)絡(luò)提取層NAL頭和分片Slice頭數(shù)據(jù)，確 認(rèn)所述待發(fā)送媒體數(shù)據(jù)中數(shù)據(jù)包的重要等級(jí)；獲取模塊，用于獲取客戶端根據(jù)接收媒體數(shù)據(jù)返回的結(jié)果信息，所述結(jié)果信息至 少包括所述客戶端接收所述媒體數(shù)據(jù)的數(shù)據(jù)丟失信息；確定模塊，用于根據(jù)所述獲取模塊獲取的所述數(shù)據(jù)丟失信息確定當(dāng)前傳輸網(wǎng)絡(luò)的 擁塞等級(jí)；處理模塊，用于根據(jù)所述確定模塊確定的所述當(dāng)前傳輸網(wǎng)絡(luò)的擁塞等級(jí)和所述分 析模塊確定的所述數(shù)據(jù)包的重要等級(jí)，結(jié)合預(yù)先制定的丟包策略進(jìn)行丟包處理。同時(shí)，本發(fā)明實(shí)施例還提供了一種IPTV系統(tǒng)丟包處理系統(tǒng)，包括客戶端，用于接收流媒體服務(wù)器發(fā)送的媒體數(shù)據(jù)，并根據(jù)接收的所述媒體數(shù)據(jù)向 所述流媒體服務(wù)器發(fā)送結(jié)果信息；所述流媒體服務(wù)器，用于解析待發(fā)送媒體數(shù)據(jù)的網(wǎng)絡(luò)提取層NAL頭和分片Slice 頭數(shù)據(jù)，確認(rèn)所述待發(fā)送媒體數(shù)據(jù)中數(shù)據(jù)包的重要等級(jí)，獲取所述客戶端返回的結(jié)果信息， 所述結(jié)果信息至少包括所述客戶端接收所述媒體數(shù)據(jù)的數(shù)據(jù)丟失信息，根據(jù)所述數(shù)據(jù)丟失 信息確定當(dāng)前傳輸網(wǎng)絡(luò)的擁塞等級(jí)，根據(jù)所述當(dāng)前傳輸網(wǎng)絡(luò)的擁塞等級(jí)和所述數(shù)據(jù)包的重 要等級(jí)，結(jié)合預(yù)先制定的丟包策略進(jìn)行丟包處理。本發(fā)明實(shí)施例在IPTV系統(tǒng)中媒體數(shù)據(jù)的傳輸過程中，通過通過解析待發(fā)送媒體 數(shù)據(jù)的網(wǎng)絡(luò)提取層NAL頭和分片Slice頭數(shù)據(jù)，確認(rèn)所述待發(fā)送媒體數(shù)據(jù)中數(shù)據(jù)包的重要 等級(jí)和判斷網(wǎng)絡(luò)擁塞等級(jí)，結(jié)合預(yù)先制定的丟包策略，有選擇性地、主動(dòng)丟棄數(shù)據(jù)包。避免 了媒體數(shù)據(jù)中的關(guān)鍵、核心數(shù)據(jù)包被被動(dòng)、隨機(jī)丟棄，從而導(dǎo)致的無法解碼，最終嚴(yán)重影響 信宿端的解碼質(zhì)量的問題。從而實(shí)現(xiàn)根據(jù)網(wǎng)絡(luò)擁塞等級(jí)，可以選擇相對(duì)不重要，或者影響程 度較小的數(shù)據(jù)，減少丟包對(duì)信宿端解碼的影響，最大程度保證播放的流暢性，極大地改善終 端用戶的體驗(yàn)。


為了更清楚地說明本發(fā)明實(shí)施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對(duì)實(shí)施例或現(xiàn) 有技術(shù)描述中所需要使用的附圖作簡(jiǎn)單地介紹，顯而易見地，下面描述中的附圖僅僅是本 發(fā)明的一些實(shí)施例，對(duì)于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動(dòng)性的前提下，還可 以根據(jù)這些附圖獲得其他的附圖。
圖1為本發(fā)明一種IPTV系統(tǒng)中丟包處理方法一個(gè)實(shí)施例的流程圖；圖2為本發(fā)明一種IPTV系統(tǒng)中丟包處理方法又一個(gè)實(shí)施例的流程3為本發(fā)明一種流媒體服務(wù)器一個(gè)實(shí)施例的結(jié)構(gòu)示意圖；圖4為本發(fā)明一種流媒體服務(wù)器又一個(gè)實(shí)施例的結(jié)構(gòu)示意圖；圖5為本發(fā)明一種IPTV系統(tǒng)中丟包處理系統(tǒng)一個(gè)實(shí)施例的結(jié)構(gòu)示意圖。
具體實(shí)施例方式下面將結(jié)合本發(fā)明實(shí)施例中的附圖，對(duì)本發(fā)明實(shí)施例中的技術(shù)方案進(jìn)行清楚、完 整地描述，顯然，所描述的實(shí)施例僅僅是本發(fā)明一部分實(shí)施例，而不是全部的實(shí)施例?；?本發(fā)明中的實(shí)施例，本領(lǐng)域普通技術(shù)人員在沒有做出創(chuàng)造性勞動(dòng)前提下所獲得的所有其他 實(shí)施例，都屬于本發(fā)明保護(hù)的范圍。流媒體服務(wù)器和客戶端建立連接，客戶端向流媒體服務(wù)器發(fā)送內(nèi)容請(qǐng)求，流媒體 服務(wù)器根據(jù)客戶端的請(qǐng)求讀取內(nèi)容源的媒體數(shù)據(jù)。請(qǐng)結(jié)合參看圖1，本發(fā)明實(shí)施例提供了一種IPTV系統(tǒng)中丟包處理方法，包括步驟102，解析待發(fā)送媒體數(shù)據(jù)的網(wǎng)絡(luò)提取層NAL頭和分片Slice頭數(shù)據(jù)，確認(rèn)所 述待發(fā)送媒體數(shù)據(jù)中數(shù)據(jù)包的重要等級(jí)。流媒體服務(wù)器根據(jù)客戶端的內(nèi)容請(qǐng)求向內(nèi)容源獲取媒體數(shù)據(jù)，解析待發(fā)送媒體數(shù) 據(jù)的NAL頭和Slice頭數(shù)據(jù)，根據(jù)待發(fā)送媒體數(shù)據(jù)的NAL頭和Slice頭數(shù)據(jù)確認(rèn)該待發(fā)送 媒體數(shù)據(jù)中各數(shù)據(jù)包的重要等級(jí)。流媒體服務(wù)器將經(jīng)過解析的媒體數(shù)據(jù)向客戶端發(fā)送?？蛇x的，流媒體服務(wù)器將獲 取的媒體數(shù)據(jù)承載在實(shí)時(shí)傳輸協(xié)議(Real-Time Transport Protocol,RTP)報(bào)文中，將承載 有媒體數(shù)據(jù)的RTP報(bào)文向客戶端發(fā)送。步驟104，獲取客戶端根據(jù)接收媒體數(shù)據(jù)返回的結(jié)果信息，所述結(jié)果信息至少包括 所述客戶端接收所述媒體數(shù)據(jù)的數(shù)據(jù)丟失信息。在流媒體服務(wù)器向客戶端發(fā)送媒體數(shù)據(jù)時(shí)，由于傳輸網(wǎng)絡(luò)可能存在網(wǎng)絡(luò)擁塞，導(dǎo) 致媒體數(shù)據(jù)的傳輸過程可能存在數(shù)據(jù)丟失，即丟包。即客戶端接收的可能不是流媒體服務(wù) 器發(fā)送的完整的媒體數(shù)據(jù)?？蛻舳嗽诮邮彰襟w數(shù)據(jù)后，向流媒體服務(wù)器反饋結(jié)果信息。該 結(jié)果信息中至少包括客戶端在接收流媒體服務(wù)器發(fā)送的媒體數(shù)據(jù)的數(shù)據(jù)丟失信息?？蛇x的，該結(jié)果信息可以承載在實(shí)時(shí)傳輸控制協(xié)議(Real-Time Transport Control Protocol, RTCP)報(bào)文中，客戶端將承載有該結(jié)果信息的RTCP報(bào)文信息向流媒體 服務(wù)器發(fā)送。步驟106，根據(jù)所述數(shù)據(jù)丟失信息確定當(dāng)前傳輸網(wǎng)絡(luò)的擁塞等級(jí)。流媒體服務(wù)器根據(jù)客戶端返回的數(shù)據(jù)丟失信息確定當(dāng)前傳輸網(wǎng)絡(luò)的狀況。該傳輸 網(wǎng)絡(luò)的狀況可以包括擁塞等級(jí)。可選的，流媒體服務(wù)器根據(jù)結(jié)果信息反饋的時(shí)間段內(nèi)的丟包數(shù)量確定當(dāng)前傳輸網(wǎng) 絡(luò)的擁塞等級(jí)。其中，該結(jié)果信息反饋的時(shí)間段是指客戶端接收流媒體服務(wù)器發(fā)送的媒體 數(shù)據(jù)的持續(xù)時(shí)間段。例如可以是客戶端在持續(xù)接收RTP報(bào)文的時(shí)間段?？梢允强蛻舳嗽?接收RTP報(bào)文的1毫秒-1000毫秒范圍內(nèi)的任意時(shí)間段、也可以是客戶端在持續(xù)接收RTP 報(bào)文最近1秒鐘內(nèi)、2秒鐘內(nèi)、3秒鐘內(nèi)、4秒鐘內(nèi)、5秒鐘內(nèi)等時(shí)間段內(nèi)。
步驟108，根據(jù)所述傳輸網(wǎng)絡(luò)的擁塞等級(jí)和所述數(shù)據(jù)包的重要等級(jí)，結(jié)合預(yù)先制定 的丟包策略進(jìn)行丟包處理。流媒體服務(wù)器根據(jù)當(dāng)前網(wǎng)絡(luò)的擁塞等級(jí)和待發(fā)送媒體數(shù)據(jù)中各數(shù)據(jù)包的重要等 級(jí)，結(jié)合預(yù)先制定的丟包策略進(jìn)行丟包處理。在IPTV系統(tǒng)中，流媒體業(yè)務(wù)中的媒體數(shù)據(jù)傳輸由于傳輸網(wǎng)絡(luò)的不穩(wěn)定性，導(dǎo)致媒 體數(shù)據(jù)傳輸過程丟包無法避免。本發(fā)明實(shí)施例通過判斷網(wǎng)絡(luò)擁塞等級(jí)和數(shù)據(jù)包的重要等 級(jí)，結(jié)合預(yù)先制定的丟包策略，有選擇性地、主動(dòng)丟棄數(shù)據(jù)包。避免了媒體數(shù)據(jù)中的關(guān)鍵、 核心數(shù)據(jù)包被被動(dòng)、隨機(jī)丟棄，從而導(dǎo)致的無法解碼，最終嚴(yán)重影響信宿端的解碼質(zhì)量的問 題?？蛇x的，在步驟104中，客戶端根據(jù)接收的媒體數(shù)據(jù)，向流媒體服務(wù)器反饋結(jié)果 信息，具體包括客戶端接收流媒體服務(wù)器通過RTP報(bào)文承載的媒體數(shù)據(jù)后，根據(jù)RTP報(bào) 文中的標(biāo)識(shí)字段，判斷丟包情況。若判斷產(chǎn)生丟包，則通過實(shí)時(shí)傳輸控制協(xié)議(Real-Time Transport Control Protocol, RTCP)報(bào)文向流媒體服務(wù)器反饋結(jié)果信息。該結(jié)果信息至 少包括媒體數(shù)據(jù)丟失信息。其中該媒體數(shù)據(jù)丟失信息可以至少包括丟包數(shù)量。請(qǐng)結(jié)合參看圖2，本發(fā)明實(shí)施例提供了一種IPTV系統(tǒng)中丟包處理方法，具體包括流媒體服務(wù)器和客戶端建立連接。步驟202，客戶端向流媒體服務(wù)器發(fā)送媒體數(shù)據(jù)請(qǐng)求?？蛻舳讼蛄髅襟w服務(wù)器發(fā)送媒體數(shù)據(jù)請(qǐng)求消息，請(qǐng)求流媒體服務(wù)器發(fā)送節(jié)目?jī)?nèi)容。步驟204，流媒體服務(wù)器解析待發(fā)送媒體數(shù)據(jù)。流媒體服務(wù)器解析待發(fā)送的媒體數(shù)據(jù)，并確認(rèn)該待發(fā)送媒體數(shù)據(jù)中各數(shù)據(jù)包的重 要等級(jí)。流媒體服務(wù)器可以采用H. 264編碼標(biāo)準(zhǔn)來壓縮媒體數(shù)據(jù)。為了大幅度的提高壓縮 效率，H. 264采用了幀間預(yù)測(cè)技術(shù)，通過前后幀之間的比較預(yù)測(cè)，減少冗余數(shù)據(jù)。因此H. 264 將圖像分成I幀、P幀、和B幀。其中I幀是幀內(nèi)預(yù)測(cè)幀，可以通過自身的數(shù)據(jù)恢復(fù)圖像，也 是其他幀編碼預(yù)測(cè)的參考頻；P幀是前向預(yù)測(cè)幀，只參考I幀和其他P幀；而B幀是雙向預(yù)測(cè) 幀，參考前后的I幀和P幀。同時(shí)，在本發(fā)明實(shí)施例中，H. 264標(biāo)準(zhǔn)采用網(wǎng)絡(luò)提取層(Network Abstraction Layer, NAL)機(jī)制，將不同的數(shù)據(jù)分成不同的NAL類型，這樣既可以減少數(shù)據(jù) 的冗余度，又可以在一定程度上減少數(shù)據(jù)的相關(guān)性。通過H. 264進(jìn)行編碼后的數(shù)據(jù)被封裝 到不同的單元之中，這些單元的重要性級(jí)別并不相同，丟失后對(duì)信宿端解碼的影響程度也 不一樣。在本發(fā)明實(shí)例中，流媒體服務(wù)器通過獲取前端編碼器發(fā)送的媒體數(shù)據(jù)，其中該媒 體數(shù)據(jù)中的各數(shù)據(jù)包已經(jīng)由前端編碼器封裝在不同的NAL類型中。流媒體服務(wù)器將獲取的 經(jīng)過前端編碼器編碼和封裝的媒體數(shù)據(jù)或媒體數(shù)據(jù)中各數(shù)據(jù)包。由于不同的NAL類型具有 不同的作用，即不同NAL類型種的數(shù)據(jù)或數(shù)據(jù)包存在不同的重要性；同時(shí)各NAL類型中的不 同Slice單元也封裝了不同類型的幀數(shù)據(jù)，分別有I、B、P幀數(shù)據(jù)。因此流媒體服務(wù)器可以 通過解析待發(fā)送給客戶端的媒體數(shù)據(jù)的網(wǎng)絡(luò)提取層NAL頭和分片Slice頭數(shù)據(jù)，確認(rèn)該待 發(fā)送的媒體數(shù)據(jù)中各數(shù)據(jù)包的重要等級(jí)。具體的，流媒體服務(wù)器首先通過解析待發(fā)送的媒體數(shù)據(jù)得到該媒體數(shù)據(jù)中數(shù)據(jù)或數(shù)據(jù)包的類型。流媒體服務(wù)器通過解析待發(fā)送的媒體數(shù)據(jù)中網(wǎng)絡(luò)提取層NAL頭和分片 Slice頭數(shù)據(jù)，得到該媒體數(shù)據(jù)中數(shù)據(jù)或數(shù)據(jù)包的NAL類型和Slice類型。一般可以將媒體 數(shù)據(jù)中的數(shù)據(jù)或數(shù)據(jù)包解析為如表1和表2的類型。表1H. 264標(biāo)準(zhǔn)中NAL單元類型
NAL typeNAL類型說明1Coded slice of a non-IDR5Coded slice of an IDR picture6Supplemental enhancement information7Sequence parameter set8Picture parameter set 表2H. 264標(biāo)準(zhǔn)中Slice類型
slice—typeSlice名稱0P (P slice)1B (B slice)2I (I slice)3SP (SP slice)4SI (Si slice)5P (P slice)6B (B slice)7I (I slice)8SP (SP slice)9SI (Si slice)根據(jù)將媒體數(shù)據(jù)中的數(shù)據(jù)或數(shù)據(jù)包按照表1和表2的類型的劃分，定義媒體數(shù)據(jù) 中數(shù)據(jù)或數(shù)據(jù)包的重要等級(jí)?？梢詫⒋l(fā)送媒體數(shù)據(jù)中數(shù)據(jù)包分為核心級(jí)、重要級(jí)、次重要 級(jí)以及普通級(jí)。具體可以參見表3的確認(rèn)。表 3
重要等級(jí)類型核心級(jí)NAL type為5、7、8中的至少一種重要級(jí)NAL type 為 1、6 以及 Slice—type 為 2、4、7、9 中的至少一種次重要級(jí)Slice—type為0、3、5、8的單元中的至少一種普通級(jí)Slice—type為1、6的單元中的至少一種步驟206，流媒體服務(wù)器根據(jù)客戶端的媒體數(shù)據(jù)請(qǐng)求向客戶端發(fā)送RTP報(bào)文。流媒體服務(wù)器將經(jīng)過解析的媒體數(shù)據(jù)向客戶端發(fā)送。流媒體服務(wù)器將經(jīng)過解析的 媒體數(shù)據(jù)承載在實(shí)時(shí)傳輸協(xié)議(Real-Time Transport Protocol,RTP)報(bào)文中，將承載有媒 體數(shù)據(jù)的RTP報(bào)文向客戶端發(fā)送。步驟208，客戶端根據(jù)接收的RTP報(bào)文得到接收的結(jié)果信息。具體的，在流媒體服務(wù)器向客戶端發(fā)送媒體數(shù)據(jù)時(shí)，由于傳輸網(wǎng)絡(luò)可能存在網(wǎng)絡(luò) 擁塞，導(dǎo)致媒體數(shù)據(jù)的傳輸過程可能存在丟包。即客戶端接收的數(shù)據(jù)可能不是流媒體服務(wù) 器發(fā)送的完整的媒體數(shù)據(jù)?？蛻舳私邮樟髅襟w服務(wù)器通過RTP報(bào)文承載的媒體數(shù)據(jù)后，根據(jù)RTP報(bào)文中的標(biāo) 識(shí)字段，判斷丟包情況，得到至少包括丟包數(shù)量的結(jié)果信息。步驟210，客戶端向流媒體服務(wù)器發(fā)送RTCP報(bào)文。客戶端在接收媒體數(shù)據(jù)后，向流媒體服務(wù)器反饋結(jié)果信息。該結(jié)果信息中至少包 括客戶端在接收流媒體服務(wù)器發(fā)送的媒體數(shù)據(jù)的數(shù)據(jù)丟失信息。具體的，該結(jié)果信息可以承載在RTCP報(bào)文中，客戶端將承載有該結(jié)果信息的RTCP 報(bào)文信息向流媒體服務(wù)器發(fā)送。具體的，客戶端根據(jù)RTP報(bào)文中的標(biāo)識(shí)字段，判斷數(shù)據(jù)丟失請(qǐng)求，即丟包情況，得 到至少包括丟包數(shù)量的結(jié)果信息承載在RTCP報(bào)文中?？蛻舳藢⒊休d丟包數(shù)量RTCP報(bào)文向 流媒體服務(wù)器發(fā)送。步驟212，流媒體服務(wù)器根據(jù)RTCP報(bào)文判斷當(dāng)前網(wǎng)絡(luò)的擁塞等級(jí)。流媒體服務(wù)器根據(jù)結(jié)果信息反饋的時(shí)間段內(nèi)的丟包數(shù)量確定當(dāng)前傳輸網(wǎng)絡(luò)的擁
塞等級(jí)。流媒體服務(wù)器根據(jù)RTCP報(bào)文中的丟包信息判斷當(dāng)前網(wǎng)絡(luò)的擁塞等級(jí)。流媒體服務(wù)器根據(jù)RTCP報(bào)文反饋的時(shí)間段內(nèi)的丟包數(shù)量確定當(dāng)前傳輸網(wǎng)絡(luò)的擁 塞等級(jí)。該時(shí)間段指客戶端在接收RTP報(bào)文的某個(gè)時(shí)間段。例如，可以是客戶端在接收RTPl 毫秒-1000毫秒范圍內(nèi)的任意時(shí)間段、也可以是客戶端在接收RTPl秒鐘、2秒鐘、3秒鐘、4 秒鐘、5秒鐘等時(shí)間段內(nèi)。具體的，流媒體服務(wù)器根據(jù)RTCP報(bào)文中反饋的某一時(shí)間段的丟包數(shù)量判斷當(dāng)前 網(wǎng)絡(luò)的擁塞等級(jí)。為了能夠盡可能真實(shí)地反映當(dāng)前網(wǎng)絡(luò)的擁塞等級(jí)，流媒體服務(wù)器可以根 據(jù)RTCP報(bào)文中最近的一個(gè)時(shí)間段的丟包數(shù)量判斷當(dāng)前網(wǎng)絡(luò)的擁塞等級(jí)?？蛇x的，流媒體服 務(wù)器可以根據(jù)RTCP報(bào)文反饋?zhàn)罱鼉擅腌娎鄯e的丟包數(shù)量確定當(dāng)前網(wǎng)絡(luò)的擁塞等級(jí)。其中， 該最近兩秒鐘可以是指離反饋RTCP報(bào)文前，客戶端兩秒鐘內(nèi)接收RTP數(shù)據(jù)包的時(shí)間段。流 媒體服務(wù)器根據(jù)RTCP報(bào)文反饋?zhàn)罱鼉擅腌娎鄯e的丟包數(shù)量確定當(dāng)前網(wǎng)絡(luò)的擁塞等級(jí)，可 以如表4所示。
表 權(quán)利要求
1.一種IPTV系統(tǒng)中丟包處理方法，其特征在于，所述方法包括解析待發(fā)送媒體數(shù)據(jù)的網(wǎng)絡(luò)提取層NAL頭和分片Slice頭數(shù)據(jù)，確認(rèn)所述待發(fā)送媒體 數(shù)據(jù)中數(shù)據(jù)包的重要等級(jí)；獲取客戶端根據(jù)接收媒體數(shù)據(jù)返回的結(jié)果信息，所述結(jié)果信息至少包括所述客戶端接 收所述媒體數(shù)據(jù)的數(shù)據(jù)丟失信息；根據(jù)所述數(shù)據(jù)丟失信息確定當(dāng)前傳輸網(wǎng)絡(luò)的擁塞等級(jí)；根據(jù)所述當(dāng)前傳輸網(wǎng)絡(luò)的擁塞等級(jí)和所述數(shù)據(jù)包的重要等級(jí)，結(jié)合預(yù)先制定的丟包策 略進(jìn)行丟包處理。
2.如權(quán)利要求1所述的方法，其特征在于，所述結(jié)果信息承載在實(shí)時(shí)傳輸控制協(xié)議 RTCP報(bào)文中。
3.如權(quán)利要求1所述的方法，其特征在于，所述數(shù)據(jù)丟失信息至少包括丟包數(shù)量；所述 根據(jù)所述數(shù)據(jù)丟失信息確定當(dāng)前傳輸網(wǎng)絡(luò)的擁塞等級(jí)包括根據(jù)丟包數(shù)量確定當(dāng)前傳輸網(wǎng) 絡(luò)的擁塞等級(jí)。
4.如權(quán)利要求3所述的方法，其特征在于，所述根據(jù)丟包數(shù)量確定當(dāng)前傳輸網(wǎng)絡(luò)的擁 塞等級(jí)，包括根據(jù)結(jié)果信息反饋的時(shí)間段內(nèi)的丟包數(shù)量確定當(dāng)前傳輸網(wǎng)絡(luò)的擁塞等級(jí)。
5.如權(quán)利要求4所述的方法，其特征在于，所述根據(jù)結(jié)果信息反饋的時(shí)間段內(nèi)的丟包 數(shù)量確定當(dāng)前傳輸網(wǎng)絡(luò)的擁塞等級(jí)，包括若根據(jù)RTCP報(bào)文反饋的最近兩秒鐘累計(jì)丟包數(shù)量為零，則當(dāng)前傳輸網(wǎng)絡(luò)的擁塞等級(jí) 為健康級(jí)；若根據(jù)RTCP報(bào)文反饋的最近兩秒鐘累計(jì)丟包數(shù)量不為零，但小于20，則當(dāng)前傳輸網(wǎng)絡(luò) 的擁塞等級(jí)為次健康級(jí)；若根據(jù)RTCP報(bào)文反饋的最近兩秒鐘累計(jì)丟包數(shù)量大于20且小于50，則當(dāng)前傳輸網(wǎng)絡(luò) 的擁塞等級(jí)為病態(tài)級(jí)；若根據(jù)RTCP報(bào)文反饋的最近兩秒鐘累計(jì)丟包數(shù)量大于50，則當(dāng)前傳輸網(wǎng)絡(luò)的擁塞等 級(jí)為嚴(yán)重病態(tài)級(jí)。
6.如權(quán)利要求1-5所述的任一方法，其特征在于，所述在解析待發(fā)送媒體數(shù)據(jù)的網(wǎng)絡(luò) 提取層NAL頭和分片Slice頭數(shù)據(jù)后，還包括根據(jù)解析待發(fā)送媒體數(shù)據(jù)的網(wǎng)絡(luò)提取層NAL頭和分片Slice頭數(shù)據(jù)，獲得所述待發(fā)送 媒體數(shù)據(jù)中數(shù)據(jù)包的類型；所述確認(rèn)所述待發(fā)送媒體數(shù)據(jù)中數(shù)據(jù)包的重要等級(jí)，包括根據(jù)所述待發(fā)送媒體數(shù)據(jù) 中數(shù)據(jù)包的類型確定所述待發(fā)送媒體數(shù)據(jù)中數(shù)據(jù)包的重要等級(jí)。
7.如權(quán)利要求6所述的方法，其特征在于，所述根據(jù)所述待發(fā)送媒體數(shù)據(jù)中數(shù)據(jù)包的 類型確定所述待發(fā)送媒體數(shù)據(jù)中數(shù)據(jù)包的重要等級(jí)，包括根據(jù)所述待發(fā)送媒體數(shù)據(jù)中數(shù)據(jù)包的類型將所述待發(fā)送媒體數(shù)據(jù)中數(shù)據(jù)包分為核心 級(jí)、重要級(jí)、次重要級(jí)以及普通級(jí)。
8.如權(quán)利要求7所述的方法，其特征在于，根據(jù)所述當(dāng)前傳輸網(wǎng)絡(luò)的擁塞等級(jí)和所述 數(shù)據(jù)包的重要等級(jí)，結(jié)合預(yù)先制定的丟包策略進(jìn)行丟包處理，包括若所述當(dāng)前網(wǎng)絡(luò)的擁塞級(jí)別為健康級(jí)時(shí)，不丟棄數(shù)據(jù)包；若所述當(dāng)前網(wǎng)絡(luò)的擁塞級(jí)別為次健康級(jí)時(shí)，選擇丟棄普通級(jí)數(shù)據(jù)包；若當(dāng)前網(wǎng)絡(luò)的擁塞級(jí)別為病態(tài)級(jí)時(shí)，先丟棄普通級(jí)數(shù)據(jù)包，并判斷當(dāng)前網(wǎng)絡(luò)的擁塞級(jí) 別是否已轉(zhuǎn)為次健康級(jí)或健康級(jí)，若否，則丟棄次重要級(jí)數(shù)據(jù)包；若當(dāng)前網(wǎng)絡(luò)的擁塞級(jí)別為嚴(yán)重病態(tài)級(jí)，先丟棄普通級(jí)數(shù)據(jù)包和次重要級(jí)數(shù)據(jù)包，并判 斷當(dāng)前網(wǎng)絡(luò)的擁塞級(jí)別是否已轉(zhuǎn)為病態(tài)級(jí)、次健康級(jí)、健康級(jí)中的一種，若否，則丟棄核心 級(jí)數(shù)據(jù)包。
9.一種流媒體服務(wù)器，其特征在于，所述流媒體服務(wù)器包括分析模塊，用于解析待發(fā)送媒體數(shù)據(jù)的網(wǎng)絡(luò)提取層NAL頭和分片Slice頭數(shù)據(jù)，確認(rèn)所 述待發(fā)送媒體數(shù)據(jù)中數(shù)據(jù)包的重要等級(jí)；獲取模塊，用于獲取客戶端根據(jù)接收媒體數(shù)據(jù)返回的結(jié)果信息，所述結(jié)果信息至少包 括所述客戶端接收所述媒體數(shù)據(jù)的數(shù)據(jù)丟失信息；確定模塊，用于根據(jù)所述獲取模塊獲取的所述數(shù)據(jù)丟失信息確定當(dāng)前傳輸網(wǎng)絡(luò)的擁塞 等級(jí)；處理模塊，用于根據(jù)所述確定模塊確定的所述當(dāng)前傳輸網(wǎng)絡(luò)的擁塞等級(jí)和所述分析模 塊確定的所述數(shù)據(jù)包的重要等級(jí)，結(jié)合預(yù)先制定的丟包策略進(jìn)行丟包處理。
10.如權(quán)利要求9所述的流媒體服務(wù)器，其特征在于，所述分析模塊包括解析單元，用于解析待發(fā)送媒體數(shù)據(jù)的網(wǎng)絡(luò)提取層NAL頭和分片Slice頭數(shù)據(jù)，獲得所 述待發(fā)送媒體數(shù)據(jù)中數(shù)據(jù)包的類型；數(shù)據(jù)包等級(jí)確認(rèn)單元，用于根據(jù)所述待發(fā)送媒體數(shù)據(jù)中數(shù)據(jù)包的類型確定所述待發(fā)送 媒體數(shù)據(jù)中數(shù)據(jù)包的重要等級(jí)。
11.一種IPTV系統(tǒng)中丟包處理系統(tǒng)，其特征在于，所述丟包處理系統(tǒng)包括客戶端，用于接收流媒體服務(wù)器發(fā)送的媒體數(shù)據(jù)，并根據(jù)接收的所述媒體數(shù)據(jù)向所述 流媒體服務(wù)器發(fā)送結(jié)果信息；所述流媒體服務(wù)器，用于解析待發(fā)送媒體數(shù)據(jù)的網(wǎng)絡(luò)提取層NAL頭和分片Slice頭數(shù) 據(jù)，確認(rèn)所述待發(fā)送媒體數(shù)據(jù)中數(shù)據(jù)包的重要等級(jí)，獲取所述客戶端返回的結(jié)果信息，所述 結(jié)果信息至少包括所述客戶端接收所述媒體數(shù)據(jù)的數(shù)據(jù)丟失信息，根據(jù)所述數(shù)據(jù)丟失信息 確定當(dāng)前傳輸網(wǎng)絡(luò)的擁塞等級(jí)，根據(jù)所述當(dāng)前傳輸網(wǎng)絡(luò)的擁塞等級(jí)和所述數(shù)據(jù)包的重要等 級(jí)，結(jié)合預(yù)先制定的丟包策略進(jìn)行丟包處理。
全文摘要
本發(fā)明公開了一種IPTV系統(tǒng)中丟包處理方法，包括解析待發(fā)送媒體數(shù)據(jù)的網(wǎng)絡(luò)提取層NAL頭和分片Slice頭數(shù)據(jù)，確認(rèn)待發(fā)送媒體數(shù)據(jù)中數(shù)據(jù)包的重要等級(jí)；獲取客戶端根據(jù)接收媒體數(shù)據(jù)返回的結(jié)果信息，該結(jié)果信息至少包括客戶端接收媒體數(shù)據(jù)的數(shù)據(jù)丟失信息；根據(jù)數(shù)據(jù)丟失信息確定當(dāng)前傳輸網(wǎng)絡(luò)的擁塞等級(jí)；根據(jù)當(dāng)前傳輸網(wǎng)絡(luò)的擁塞等級(jí)和數(shù)據(jù)包的重要等級(jí)，結(jié)合預(yù)先制定的丟包策略進(jìn)行丟包處理。本發(fā)明還公開了一種流媒體服務(wù)器和IPTV系統(tǒng)中丟包處理系統(tǒng)。通過判斷網(wǎng)絡(luò)擁塞等級(jí)，結(jié)合預(yù)先制定的丟包策略，有選擇性地、主動(dòng)丟棄數(shù)據(jù)包。避免了媒體數(shù)據(jù)中的關(guān)鍵數(shù)據(jù)包被隨機(jī)丟棄，從而導(dǎo)致的無法解碼，嚴(yán)重影響信宿端的解碼質(zhì)量問題。
文檔編號(hào)H04L29/06GK102130821SQ20101025038
公開日2011年7月20日 申請(qǐng)日期2010年8月11日 優(yōu)先權(quán)日2010年8月11日
發(fā)明者徐偉軍 申請(qǐng)人:華為技術(shù)有限公司