專利名稱：用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償方法與裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種用戶數(shù)據(jù)報協(xié)議(UDP，User Datagram Protocol)傳輸模式下丟 包補償方法與裝置。
背景技術(shù)：
網(wǎng)絡(luò)電視(IPTV, Internet Protocol Television)系統(tǒng)是基于互聯(lián)網(wǎng)協(xié)議(IP, Internet Protocol)網(wǎng)絡(luò)完成媒體數(shù)據(jù)傳輸、解碼播放的視頻業(yè)務(wù)系統(tǒng)，其核心技術(shù)是編 碼后的媒體數(shù)據(jù)以流的方式由媒體服務(wù)器傳送到客戶端(機頂盒)，客戶端解碼所接收的 媒體數(shù)據(jù)，根據(jù)所解碼的媒體數(shù)據(jù)產(chǎn)生模擬的活動視頻，并在電視機等顯示設(shè)備上進行顯 示。IPTV同時為用戶提供視頻媒體節(jié)目的點播、直播業(yè)務(wù)。上述業(yè)務(wù)實現(xiàn)過程中，媒體數(shù)據(jù)由媒體服務(wù)器到機頂盒的媒體數(shù)據(jù)的傳輸質(zhì)量， 直接影響著用戶的視頻觀看效果。如果媒體數(shù)據(jù)傳輸過程中出現(xiàn)了丟失，視頻畫面就會 出現(xiàn)停頓或者馬賽克畫屏的情況。如何保證媒體數(shù)據(jù)傳輸?shù)馁|(zhì)量，向用戶提供高質(zhì)量的視 頻觀看體驗，是IPTV領(lǐng)域面臨的最大技術(shù)問題。這是因為IP網(wǎng)絡(luò)不提供傳輸質(zhì)量保證， 需要應(yīng)用層通過技術(shù)手段來達到該目的。傳統(tǒng)的基于傳輸控制協(xié)議(TCP，Transmission Control Protocol)的傳輸方式提供丟包重傳功能，但其丟包重傳是不可丟棄的，即如果有 一個包丟失，整個傳輸過程將會被堵塞，直到該數(shù)據(jù)包傳輸完成，這種機制并不適合實時的 流媒體傳輸，實時性較好的UDP傳輸機制是更合適的選擇。但UDP傳輸方式并不提供丟包 補償機制，這制約了 IPTV系統(tǒng)所提供多媒體數(shù)據(jù)的質(zhì)量。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的主要目的在于提供一種用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償 方法與裝置，能在UDP傳輸機制中提供數(shù)據(jù)包重傳，保證了所傳輸數(shù)據(jù)的質(zhì)量。為達到上述目的，本發(fā)明的技術(shù)方案是這樣實現(xiàn)的一種用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償方法，包括檢測到所接收數(shù)據(jù)包丟包時，進行丟包補償啟動第一等待計時，所述第一等待計 時超時仍未接收到所述丟包時，將所述丟包的信息上報發(fā)送方，并啟動第二等待計時，所述 第二等待計時超時之前若接收到所述丟包，將其插入到所述所接收數(shù)據(jù)包中的對應(yīng)位置， 結(jié)束當前丟包補償，在檢測到新丟包時重新啟動所述丟包補償流程。優(yōu)選地，所述方法還包括所述丟包補償過程中連續(xù)未接收到丟包超過設(shè)定的第一閾值次數(shù)或/及丟包率 超過設(shè)定的第二閾值時，停止所述丟包補償流程；所接收數(shù)據(jù)包丟包率持續(xù)為0超過設(shè)定 的第三閾值時間時，重新啟動所述丟包補償流程。優(yōu)選地，所述方法還包括所述第一等待計時超時之前接收到所述丟包時，結(jié)束當前丟包補償流程，在檢測 到新丟包時重新啟動所述丟包補償流程。
一種用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償方法，包括接收到丟包的上報信息后，根據(jù)所述上報信息在所述丟包對應(yīng)的接收方已發(fā)送數(shù) 據(jù)包緩存中查找所述丟包，將所述丟包插入到所述接收方的待發(fā)送數(shù)據(jù)包隊列中，發(fā)送至 所述接收方。優(yōu)選地，接收到丟包的上報信息之前還包括檢測所述接收方是否具有丟包補償處理能力，有時以超過所述接收方數(shù)據(jù)編碼帶寬的速率發(fā)送數(shù)據(jù)包。一種用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償裝置，包括檢測單元及丟包補償單元， 其中檢測單元，用于檢測到所接收數(shù)據(jù)包丟包時觸發(fā)所述丟包補償單元的第一計時啟 動模塊；所述丟包補償單元包括第一計時啟動模塊，用于啟動第一等待計時；第一丟包檢測模塊，用于在所述第一等待計時過程中檢測是否接收到所述丟包， 未檢測到所述丟包時觸發(fā)丟包信息上報模塊；丟包信息上報模塊，用于將所述丟包的信息上報發(fā)送方，并觸發(fā)第二計時啟動模 塊；第二計時啟動模塊，用于啟動第二等待計時；第二丟包檢測模塊，用于在所述第二等待計時過程中檢測是否接收到所述丟包， 檢測到所述丟包時觸發(fā)丟包插入模塊，否則觸發(fā)所述檢測單元；丟包插入模塊，用于將所述丟包插入到所述所接收數(shù)據(jù)包中的對應(yīng)位置。優(yōu)選地，所述第二丟包檢測模塊檢測到連續(xù)未接收到丟包超過設(shè)定的第一閾值次 數(shù)或/及所述檢測單元檢測到所接收數(shù)據(jù)包丟包率超過設(shè)定的第二閾值時，停止所述丟包 補償單元；所述檢測單元檢測到所接收數(shù)據(jù)包丟包率超過持續(xù)為0超過設(shè)定的第三閾值時 間時，重新啟動所述丟包補償單元。優(yōu)選地，所述裝置還包括數(shù)據(jù)包存儲器，所述數(shù)據(jù)包存儲器至少包括三部分數(shù)據(jù) 緩存區(qū)一部分用于存儲未經(jīng)過丟包檢測的數(shù)據(jù)包；一部分用于存儲等待丟包重傳的待補 償數(shù)據(jù)包；一部分是完整數(shù)據(jù)包，該數(shù)據(jù)區(qū)用于存儲經(jīng)過丟包補償之后的數(shù)據(jù)包或者未檢 測到有丟包的數(shù)據(jù)包?！N用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償裝置，包括接收單元，用于接收丟包的上報信息；查找單元，用于根據(jù)所述上報信息在所述丟包對應(yīng)的接收方已發(fā)送數(shù)據(jù)包緩存中 查找所述丟包，查找到時觸發(fā)丟包插入單元；丟包插入單元，用于將查找到的所述丟包插入到所述接收方的待發(fā)送數(shù)據(jù)包隊列 中；以及發(fā)送單元，用于將所述待發(fā)送數(shù)據(jù)包隊列發(fā)送至所述接收方。優(yōu)選地，所述裝置還包括能力檢測單元，用于檢測接收方是否具有丟包補償處理 能力，有時觸發(fā)所述發(fā)送單元以超過所述接收方數(shù)據(jù)編碼帶寬的速率發(fā)送數(shù)據(jù)包。在接收方設(shè)置丟包補償處理機制，以在檢測到數(shù)據(jù)包丟包時通知發(fā)送方，使發(fā)送方重傳所述丟包。其中，檢測到數(shù)據(jù)包丟包時，并不立即通知發(fā)送方，而是啟動一定時器來 檢測在定時器周期內(nèi)是否能接收到所述丟包，若不能接收到所述丟包再將所述丟包的相關(guān) 信息上報發(fā)送方，觸發(fā)發(fā)送方重傳所述丟包。發(fā)送方在已發(fā)送的數(shù)據(jù)緩存區(qū)查找到所述丟 包，并將所述丟包插入到待發(fā)送數(shù)據(jù)包隊列，發(fā)送至接收方。接收方接收到所述丟包后按 其序號插入到所接收的相應(yīng)數(shù)據(jù)包隊列中，從而實現(xiàn)所接收數(shù)據(jù)的補償。本發(fā)明保證了接 收方所接收數(shù)據(jù)的完整性， 很好地保證了所接收數(shù)據(jù)的質(zhì)量，特別適合于目前的IPTV系統(tǒng) 中的流媒體傳輸機制，較好地保證了 IPTV的畫音質(zhì)量，提升了這一業(yè)務(wù)的競爭力及服務(wù)質(zhì) 量。


圖1為本發(fā)明一種實施例的用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償方法的流程示 意圖；圖2為本發(fā)明另一種實施例的用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償方法的流程 示意圖；圖3為本發(fā)明一種實施例的用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償裝置的組成結(jié) 構(gòu)示意圖；圖4為本發(fā)明另一種實施例的用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償裝置的組成 結(jié)構(gòu)示意圖。
具體實施例方式本發(fā)明的基本思想是在接收方設(shè)置丟包補償處理機制，以在檢測到數(shù)據(jù)包丟包 時通知發(fā)送方，使發(fā)送方重傳所述丟包。其中，檢測到數(shù)據(jù)包丟包時，并不立即通知發(fā)送方， 而是啟動一定時器來檢測在定時器周期內(nèi)是否能接收到所述丟包，若不能接收到所述丟包 再將所述丟包的相關(guān)信息上報發(fā)送方，觸發(fā)發(fā)送方重傳所述丟包。發(fā)送方在已發(fā)送的數(shù)據(jù) 緩存區(qū)查找到所述丟包，并將所述丟包插入到待發(fā)送數(shù)據(jù)包隊列，發(fā)送至接收方。接收方 接收到所述丟包后按其序號插入到所接收的相應(yīng)數(shù)據(jù)包隊列中，從而實現(xiàn)所接收數(shù)據(jù)的補 償。本發(fā)明保證了接收方所接收數(shù)據(jù)的完整性，很好地保證了所接收數(shù)據(jù)的質(zhì)量。為使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚明白，以下舉實施例并參照附圖，對 本發(fā)明進一步詳細說明。圖1為本發(fā)明一種實施例的用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償方法的流程示 意圖，如圖1所示，本發(fā)明實施例的用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償方法包括步驟101 對所接收數(shù)據(jù)包進行檢測，檢測到所接收數(shù)據(jù)包丟包時，啟動第一等待 計時。對所接收到的數(shù)據(jù)包進行丟包檢測，即判斷所接收到的數(shù)據(jù)包的序號是否連續(xù)， 若連續(xù)則意味著沒有丟包，不連續(xù)時缺失的數(shù)據(jù)包序號對應(yīng)的數(shù)據(jù)包即為丟包。其中的丟 包檢測，并不是接收到數(shù)據(jù)包后即進行檢測，而是設(shè)置一個待檢測數(shù)據(jù)區(qū)，所述待檢測數(shù)據(jù) 區(qū)存儲的數(shù)據(jù)包達到一定數(shù)量后才啟動檢測機制，這種機制能節(jié)約處理資源。接收方可設(shè)置至少三部分數(shù)據(jù)緩存區(qū)一部分用于存儲未檢測的數(shù)據(jù)包，該部分 數(shù)據(jù)尚未經(jīng)過丟包檢測，為待檢測數(shù)據(jù)包；一部分用于存儲等待丟包重傳的待補償數(shù)據(jù)包，該部分數(shù)據(jù)包是檢測到丟包的數(shù)據(jù)包，需要進行丟包補償處理；一部分是完整數(shù)據(jù)包，該數(shù) 據(jù)區(qū)用于存儲經(jīng)過丟包補償之后的數(shù)據(jù)或者是未檢測到有丟包的數(shù)據(jù)包，該部分數(shù)據(jù)包直 接用于解析并輸出至電視機等處理終端。步驟102 啟動第一等待計時，在所述第一等待計時周期內(nèi)檢測是否接收到所述 丟包，若接收到執(zhí)行步驟104，否則執(zhí)行步驟103。第一等待計時的時長一般設(shè)置為不超過80ms，這是因為，IP網(wǎng)絡(luò)中存在著時延，數(shù)據(jù)包并不一定會按照其序號依序到達接收方，因此，步驟101中所檢測到的丟包很可能 在傳輸途中，因此，設(shè)置一定的時延等待時刻，以確定所檢測丟包是否是因時延而導(dǎo)致的， 如果超過所設(shè)置時延仍未接收到所述丟包，則認為所述丟包已丟失，啟動步驟103。第一等 待計時的時長計時通過設(shè)置定時器而實現(xiàn)。這里，通過存儲檢測待檢測數(shù)據(jù)包的緩沖區(qū)來 確定是否接收到所述丟包的。步驟103 將所述丟包的信息上報發(fā)送方，并啟動第二等待計時，在所述第二等待 計時周期內(nèi)檢測是否接收到所述丟包，所述第二等待計時超時之前若接收到所述丟包，執(zhí) 行步驟104，否則執(zhí)行步驟105。這里，上報的所述丟包的信息主要是所述丟包的序號，接收方的IP標識如IP地址 等，主要是方便接收方查找到所述丟包。第二等待計時的時長一般設(shè)置為不超過200ms，即 IP網(wǎng)絡(luò)中數(shù)據(jù)重傳所需的合理時長，第二等待計時的時長計時也可通過設(shè)置定時器而實 現(xiàn)。在存儲檢測待檢測數(shù)據(jù)包的緩沖區(qū)檢測所接收到的數(shù)據(jù)包，判斷所接收數(shù)據(jù)包的序號 是否存在所述丟包的序號，有時即確定仍未接收到所述丟包，否則未接收到所述丟包。第二 等待計時超時仍未接收到所述丟包時，對丟包的數(shù)據(jù)包隊列不再補償，將有丟包的待補償 數(shù)據(jù)包轉(zhuǎn)存于完整數(shù)據(jù)包的緩存區(qū)，解碼處理后輸出至相應(yīng)的終端。步驟104 將所述丟包插入到所接收數(shù)據(jù)包中的對應(yīng)位置。將所接收到的所述丟包按其序號插入到所接收的數(shù)據(jù)包隊列中，即將所述丟包插 入到待補償數(shù)據(jù)包緩沖區(qū)中的對應(yīng)數(shù)據(jù)包隊列的對應(yīng)位置上，實現(xiàn)丟包的補償，使丟包的 數(shù)據(jù)包隊列形成完整數(shù)據(jù)，并將補償后的數(shù)據(jù)包隊列存儲于完整數(shù)據(jù)緩存區(qū)。步驟105 當前丟包補償流程結(jié)束，返回步驟101。本實施例的丟包補償方法尤其適用于IPTV系統(tǒng)中的流媒體接收方，如機頂盒等。 本發(fā)明實施例中，接收方(如機頂盒)與發(fā)送方(如媒體服務(wù)器)之間首先基于實時流傳輸 協(xié)議(RTSP，Real Time Streaming Protocol)進行信令交互，進行流媒體傳輸之前的準備 流程；同時，按照RTSP規(guī)范定義，雙方建立實時傳輸控制協(xié)議(RTCP，Real-time Transport Control Protocol)信道，從而實現(xiàn)雙方的流媒體的傳輸。本實施例還包括在丟包補償過程中連續(xù)未接收到丟包超過設(shè)定的第一閾值次數(shù) 或/及丟包率超過設(shè)定的第二閾值時，停止丟包補償流程。在進行本實施例的丟包補償時，若連續(xù)出現(xiàn)未接收到丟包情況，即待補償數(shù)據(jù)包 緩沖區(qū)中的數(shù)據(jù)包直接轉(zhuǎn)存于完整數(shù)據(jù)包緩沖區(qū)連續(xù)出現(xiàn)后，說明接收方與發(fā)送方之間信 道條件較差或發(fā)送方出現(xiàn)了如處理資源緊張等問題，再進行丟包補償流程無疑會導(dǎo)致更多 的丟包，因此，需要停止丟包補償而盡可能地多傳輸有效數(shù)據(jù)。當數(shù)據(jù)包的丟包率較大時說 明當前的信道的信噪比較低，應(yīng)停止丟包補償流程。一般地，連續(xù)三次出現(xiàn)未接收到丟包情 況且丟包率超過5%時，即停止丟包補償?shù)牧鞒獭τ趩为毷褂脕G包率或連續(xù)出現(xiàn)未接收到丟包的次數(shù)而停止丟包補償?shù)那闆r，參照前述的條件合理設(shè)置停止丟包補償?shù)臈l件即可， 如丟包率超過8%時即停止丟包補償?shù)牧鞒?，或者，連續(xù)六次出現(xiàn)未接收到丟包情況時即停止丟包補償?shù)牧鞒?。本實施例還包括所接收數(shù)據(jù)包丟包率持續(xù)為0超過設(shè)定的第三閾值時間時，重 新啟動所述丟包補償流程。當然，如果信道條件出現(xiàn)好轉(zhuǎn)之后，仍啟動丟包補償?shù)牧鞒蹋鐏G包率為0且持續(xù) 了 1秒鐘之后，重新啟動所述丟包補償流程。圖2為本發(fā)明另一種實施例的用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償方法的流程 示意圖，如圖2所示，本發(fā)明實施例的用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償方法包括步驟201 接收到丟包的上報信息后，根據(jù)所述上報信息在所述丟包對應(yīng)的接收 方已發(fā)送數(shù)據(jù)包緩存中查找所述丟包，若查找到執(zhí)行步驟202，否則結(jié)束當前流程。發(fā)送方接收到丟包的上報信息如丟包的序號，提取接收方的標識信息如IP地址 或MAC地址等，確定出接收方是身份，在該接收方的已發(fā)送數(shù)據(jù)包隊列緩存區(qū)中查找所述 丟包，如果查找到則執(zhí)行步驟202，否則結(jié)束當前流程。發(fā)送方為每個數(shù)據(jù)信道設(shè)置一個緩存區(qū)，用于存儲已發(fā)送至發(fā)送方的數(shù)據(jù)包，緩 沖區(qū)設(shè)置的越大越好，但考慮到成本等因素，只要能滿足接收到接收方的所述丟包的查詢 請求時仍存儲了之前所發(fā)送的所述丟包即可。發(fā)送方基于RTSP及RTCP與接收方之間進行信令交互及流媒體數(shù)據(jù)傳輸。在與接 收方進行初始信令交互時，發(fā)送方還確定接收方是否支持前述的丟包補償功能，支持時將 以超出設(shè)定帶寬要求的速率向所述接收方發(fā)送流媒體數(shù)據(jù)，以補償接收方因進行丟包補償 操作可能導(dǎo)致的消耗是帶寬數(shù)據(jù)。接收方通過在RTSP交互信令的DESCRIBE消息中附加一 個擴展字段來表示自己支持丟包補償能力，擴展字段定義為X-zmSSRtXSdp，該擴展字段在 DESCRIBE消息體中單獨占一行。發(fā)送方與接收方之間的丟包補償交互信令，采用RFC4585 中定義的Generic NACK消息，使用立即反饋模式，采用最小復(fù)合反饋包。關(guān)于GenericNACK 消息的格式，參見RFC4585協(xié)議。本實施例的丟包補償方法尤其適用于IPTV系統(tǒng)中的流媒體發(fā)送方，如媒體服務(wù)
嬰坐
-V^r ^t O步驟202 將所述丟包插入到所述接收方的待發(fā)送數(shù)據(jù)包隊列中，發(fā)送至所述接 收方。發(fā)送方將所查找出的所述丟包插入到待發(fā)送數(shù)據(jù)包隊列的最前面，以在第一時間 發(fā)送至所述接收方。發(fā)送方的數(shù)據(jù)包重傳機制采用同步源標識符復(fù)用(SSRC-multiplexing)方式。重 傳流與原始流的對應(yīng)關(guān)系通過在會話描述協(xié)議(SDP，Session DescriptionProtocol)中 添加相關(guān)屬性傳遞給接收方，重傳包及SDP包的具體格式及規(guī)定參見RFC4588，這里不再贅 述。本領(lǐng)域技術(shù)人員應(yīng)當理解，圖1及圖2所揭示的方法可結(jié)合于一起使用，其中，圖 1所示方法用于數(shù)據(jù)接收方，IPTV系統(tǒng)中的機頂盒，圖2所示方法用于數(shù)據(jù)發(fā)送方，如IPTV 系統(tǒng)中的媒體服務(wù)器。圖3為本發(fā)明一種實施例的用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償裝置的組成結(jié)構(gòu)示意圖，如圖3所示，本發(fā)明實施例的用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償裝置包括檢 測單元30、丟包補償單元31及存儲器32，其中，檢測單元30用于檢測到所接收數(shù)據(jù)包丟包 時觸發(fā)所述丟包補償單元31的第一計時啟動模塊310 ；存儲器32用于存儲所接收到的數(shù) 據(jù)包；丟包補償單元31包括第一計時啟動模塊310、第一丟包檢測模塊311、丟包信息上報 模塊312、第二計時啟動模塊313、第二丟包檢測模塊314及丟包插入模塊315，其中，第一 計時啟動模塊310用于啟動第一等待計時，第一等待計時的時長一般設(shè)置為不超過80ms， 可通過設(shè)置定時器而實現(xiàn)；第一丟包檢測模塊311用于在所述第一等待計時過程中檢測是 否接收到所述丟包，未檢測到所述丟包時觸發(fā)丟包信息上報模塊312 ；丟包信息上報模塊 312用于將所述丟包的信息上報發(fā)送方，并觸發(fā)第二計時啟動模塊313 ；第二計時啟動模塊 313用于啟動第二等待計時，第二等待計時的時長一般設(shè)置為不超過200ms，可通過設(shè)置定 時器而實現(xiàn)；第二丟包檢測模塊314用于在所述第二等待計時過程中檢測是否接收到所述 丟包，檢測到所述丟包時觸發(fā)丟包插入模塊，否則觸發(fā)所述檢測單元；丟包插入模塊315用 于將所述丟包插入到所述所接收數(shù)據(jù)包中的對應(yīng)位置。存儲器32中至少設(shè)置三部分數(shù)據(jù) 緩存區(qū)一部分用于存儲未檢測的數(shù)據(jù)包，該部分數(shù)據(jù)尚未經(jīng)過丟包檢測，為待檢測數(shù)據(jù) 包；一部分用于存儲等待丟包重傳的待補償數(shù)據(jù)包，該部分數(shù)據(jù)包是檢測到丟包的數(shù)據(jù)包， 需要進行丟包補償處理；一部分是完整數(shù)據(jù)包，該數(shù)據(jù)區(qū)用于存儲經(jīng)過丟包補償之后的數(shù) 據(jù)或者是未檢測到有丟包的數(shù)據(jù)包，該部分數(shù)據(jù)包直接用于解析并輸出至電視機等處理終 端。
圖3所示的裝置適用于IPTV系統(tǒng)中的發(fā)送方如機頂盒等。本領(lǐng)域技術(shù)人員應(yīng)當理解，本實施例的用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償裝置 是為實現(xiàn)圖1所示的用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償方法而設(shè)計的，圖3所示裝置中 的各處理單元及模塊的實現(xiàn)功能可參照圖1所示的方法中的相關(guān)描述而理解。本發(fā)明實施 例的用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償裝置中各單元、模塊的功能可通過運行于處理器 上的程序而實現(xiàn)，也可通過具體的邏輯電路而實現(xiàn)。圖4為本發(fā)明另一種實施例的用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償裝置的組成 結(jié)構(gòu)示意圖，如圖4所示，本發(fā)明實施例的用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償裝置包括 接收單元40、查找單元41、丟包插入單元42、發(fā)送單元43及能力檢測單元44，其中，接收單 元40用于接收丟包的上報信息；查找單元41用于根據(jù)所述上報信息在所述丟包對應(yīng)的接 收方已發(fā)送數(shù)據(jù)包緩存中查找所述丟包，查找到時觸發(fā)丟包插入單元42;丟包插入單元42 用于將查找到的所述丟包插入到所述接收方的待發(fā)送數(shù)據(jù)包隊列中；發(fā)送單元43用于將 所述待發(fā)送數(shù)據(jù)包隊列發(fā)送至所述接收方。能力檢測單元44用于檢測接收方是否具有丟 包補償處理能力，有時觸發(fā)發(fā)送單元43以超過接收方數(shù)據(jù)編碼帶寬的速率發(fā)送數(shù)據(jù)包，以 補償接收方因進行丟包補償操作可能導(dǎo)致的消耗是帶寬數(shù)據(jù)。接收方通過在RTSP交互信 令的DESCRIBE消息中附加一個擴展字段來表示自己支持丟包補償能力，擴展字段定義為 x-zmssRtxSdp,該擴展字段在DESCRIBE消息體中單獨占一行。能力檢測單元44通過接收 到的DESCRIBE消息來確定接收方是否具有丟包補償能力。圖4所示的裝置適用于IPTV系統(tǒng)中的接收方如媒體服務(wù)器等。本領(lǐng)域技術(shù)人員應(yīng)當理解，本實施例的用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償裝置 是為實現(xiàn)圖2所示的用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償方法而設(shè)計的，圖4所示裝置中的各處理單元的實現(xiàn)功能可參照圖2所示的方法中的相關(guān)描述而理解。本發(fā)明實施例的用 戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償裝置中各單元的功能可通過運行于處理器上的程序而 實現(xiàn)，也可通過具體的邏輯電路而實現(xiàn)。
以上所述，僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護范圍。
權(quán)利要求
一種用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償方法，其特征在于，包括檢測到所接收數(shù)據(jù)包丟包時，進行丟包補償啟動第一等待計時，所述第一等待計時超時仍未接收到所述丟包時，將所述丟包的信息上報發(fā)送方，并啟動第二等待計時，所述第二等待計時超時之前若接收到所述丟包，將其插入到所述所接收數(shù)據(jù)包中的對應(yīng)位置，結(jié)束當前丟包補償，在檢測到新丟包時重新啟動所述丟包補償流程。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述方法還包括所述丟包補償過程中連續(xù)未接收到丟包超過設(shè)定的第一閾值次數(shù)或/及丟包率超過 設(shè)定的第二閾值時，停止所述丟包補償流程；所接收數(shù)據(jù)包丟包率持續(xù)為O超過設(shè)定的第 三閾值時間時，重新啟動所述丟包補償流程。
3.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述方法還包括所述第一等待計時超時之前接收到所述丟包時，結(jié)束當前丟包補償流程，在檢測到新 丟包時重新啟動所述丟包補償流程。
4.一種用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償方法，其特征在于，包括接收到丟包的上報信息后，根據(jù)所述上報信息在所述丟包對應(yīng)的接收方已發(fā)送數(shù)據(jù)包 緩存中查找所述丟包，將所述丟包插入到所述接收方的待發(fā)送數(shù)據(jù)包隊列中，發(fā)送至所述 接收方。
5.根據(jù)權(quán)利要求4所述的方法，其特征在于，接收到丟包的上報信息之前還包括檢測所述接收方是否具有丟包補償處理能力，有時以超過所述接收方數(shù)據(jù)編碼帶寬的 速率發(fā)送數(shù)據(jù)包。
6.一種用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償裝置，其特征在于，包括檢測單元及丟包 補償單元，其中檢測單元，用于檢測到所接收數(shù)據(jù)包丟包時觸發(fā)所述丟包補償單元的第一計時啟動模塊；所述丟包補償單元包括第一計時啟動模塊，用于啟動第一等待計時；第一丟包檢測模塊，用于在所述第一等待計時過程中檢測是否接收到所述丟包，未檢 測到所述丟包時觸發(fā)丟包信息上報模塊；丟包信息上報模塊，用于將所述丟包的信息上報發(fā)送方，并觸發(fā)第二計時啟動模塊；第二計時啟動模塊，用于啟動第二等待計時；第二丟包檢測模塊，用于在所述第二等待計時過程中檢測是否接收到所述丟包，檢測 到所述丟包時觸發(fā)丟包插入模塊，否則觸發(fā)所述檢測單元；丟包插入模塊，用于將所述丟包插入到所述所接收數(shù)據(jù)包中的對應(yīng)位置。
7.根據(jù)權(quán)利要求6所述的裝置，其特征在于，所述第二丟包檢測模塊檢測到連續(xù)未接 收到丟包超過設(shè)定的第一閾值次數(shù)或/及所述檢測單元檢測到所接收數(shù)據(jù)包丟包率超過 設(shè)定的第二閾值時，停止所述丟包補償單元；所述檢測單元檢測到所接收數(shù)據(jù)包丟包率超 過持續(xù)為O超過設(shè)定的第三閾值時間時，重新啟動所述丟包補償單元。
8.根據(jù)權(quán)利要求6所述的裝置，其特征在于，所述裝置還包括數(shù)據(jù)包存儲器，所述數(shù)據(jù) 包存儲器至少包括三部分數(shù)據(jù)緩存區(qū)一部分用于存儲未經(jīng)過丟包檢測的數(shù)據(jù)包；一部分 用于存儲等待丟包重傳的待補償數(shù)據(jù)包；一部分是完整數(shù)據(jù)包，該數(shù)據(jù)區(qū)用于存儲經(jīng)過丟包補償之后的數(shù)據(jù)包或者未檢測到有丟包的數(shù)據(jù)包。
9.一種用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償裝置，其特征在于，包括 接收單元，用于接收丟包的上報信息；查找單元，用于根據(jù)所述上報信息在所述丟包對應(yīng)的接收方已發(fā)送數(shù)據(jù)包緩存中查找 所述丟包，查找到時觸發(fā)丟包插入單元；丟包插入單元，用于將查找到的所述丟包插入到所述接收方的待發(fā)送數(shù)據(jù)包隊列中；以及發(fā)送單元，用于將所述待發(fā)送數(shù)據(jù)包隊列發(fā)送至所述接收方。
10.根據(jù)權(quán)利要求9所述的裝置，其特征在于，所述裝置還包括能力檢測單元，用于檢 測接收方是否具有丟包補償處理能力，有時觸發(fā)所述發(fā)送單元以超過所述接收方數(shù)據(jù)編碼 帶寬的速率發(fā)送數(shù)據(jù)包。
全文摘要
本發(fā)明公開了一種用戶數(shù)據(jù)報協(xié)議傳輸模式下丟包補償方法，包括檢測到所接收數(shù)據(jù)包丟包時，進行丟包補償啟動第一等待計時，所述第一等待計時超時仍未接收到所述丟包時，將所述丟包的信息上報發(fā)送方，并啟動第二等待計時，所述第二等待計時超時之前若接收到所述丟包，將其插入到所述所接收數(shù)據(jù)包中的對應(yīng)位置，結(jié)束當前丟包補償，在檢測到新丟包時重新啟動所述丟包補償流程。本發(fā)明同時公開了一種實現(xiàn)前述方法的裝置。本發(fā)明特別適合于目前的IPTV系統(tǒng)中的流媒體傳輸機制，較好地保證了IPTV的畫音質(zhì)量，提升了這一業(yè)務(wù)的競爭力及服務(wù)質(zhì)量。
文檔編號H04L1/18GK101800632SQ20091007763
公開日2010年8月11日 申請日期2009年2月9日 優(yōu)先權(quán)日2009年2月9日
發(fā)明者劉繼年, 周茂林, 尤洪濤, 王芳 申請人:中興通訊股份有限公司