[發明專利]一種媒體數據包丟包恢復的方法及系統

有效

• 申請號: 200910224255.5
• 申請日: 2009-11-25
• 公開（公告）號: CN101719809A
• 公開（公告）日: 2010-06-02
• 發明（設計）人: 黃宇軒
• 申請（專利權）人: 中興通訊股份有限公司
• 主分類號: H04L1/00
• 分類號: H04L1/00;H04L1/16;H04L12/56;H04L29/06
• 代理公司: 北京派特恩知識產權代理事務所(普通合伙) 11270
• 代理人: 武晨燕;周義剛

技術領域

本發明涉及交互式網絡電視(IPTV，Internet?Protocol?Television)領域的丟 包恢復技術，尤其涉及一種媒體數據包丟包恢復的方法及系統。

背景技術

在IPTV業務中，媒體數據包由流媒體服務器到客戶端的傳輸質量，直接 影響著用戶的視頻觀看效果。如果在傳輸過程中出現媒體數據包丟失的情況， 則視頻畫面就會出現停頓或馬賽克花屏的情況，這嚴重影響了用戶的使用體驗。 因此，如何保證媒體數據包的傳輸質量，以給用戶提供高質量的視頻觀看效果， 是IPTV領域面臨的關鍵技術問題。

傳統的傳輸控制協議(TCP)傳輸方式提供自動丟包重傳功能，但是其丟 包重傳機制是必不可少的，即如果有一個數據包丟失，則整個傳輸過程將會被 堵塞，直到該數據包傳輸完成，因此TCP傳輸方式不適合實時的流媒體傳輸。 相對而言，用戶數據報協議(UDP)傳輸方式則更適合于實時的流媒體傳輸。 IPTV系統采用UDP傳輸方式時，存在兩種常見的丟包恢復技術，即重傳技術 和前向糾錯(FEC)技術。采用重傳技術，帶來的開銷比較有限，因為只重傳 丟失的媒體數據包；但是，帶來的相關延遲比較大：丟包越多，延遲越大，所 以有可能出現雖然媒體數據包重傳完成，但卻已經過時的情況。采用FEC技術， 流媒體服務器在發送媒體數據流的同時不斷發送FEC數據，客戶端能夠根據 FEC數據重建丟失的媒體數據包，實時性相對比較好；但是，不斷發送FEC數 據會帶來固定的帶寬消耗，特別是在網絡狀況比較好的情況下，盡管不丟包或 丟包機率小，仍然會存在固定的帶寬消耗。

發明內容

有鑒于此，本發明的主要目的在于提供一種媒體數據包丟包恢復的方法及 系統，能夠節省網絡帶寬，并減輕流媒體服務器的中央處理器(CPU)負荷。

為達到上述目的，本發明的技術方案是這樣實現的：

一種媒體數據包丟包恢復的方法，包括：

流媒體服務器發送并緩存媒體數據流；

客戶端接收并緩存媒體數據流；當客戶端檢測到緩存的媒體數據流中丟 失媒體數據包時，向流媒體服務器發送否認(NACK)消息，所述NACK消 息中攜帶有媒體數據流的丟包信息；

流媒體服務器根據收到的NACK消息中攜帶的媒體數據流的丟包信息， 設定FEC編碼冗余度并從自身緩存的媒體數據流中獲取需恢復的媒體數據 包；并根據FEC編碼冗余度將需恢復的媒體數據包編碼成FEC數據發送給 客戶端；

客戶端結合收到的FEC數據以及自身緩存的媒體數據流，恢復出媒體 數據流中丟失的媒體數據包。

其中，在客戶端檢測到緩存的媒體數據流中丟失媒體數據包之后，所述 方法進一步包括：

客戶端啟動預先設置的丟包檢測定時器，當丟包檢測定時器超時時，檢 測到丟失的媒體數據包仍未收到時，向流媒體服務器發送所述NACK消息。

其中，在檢測到丟失的媒體數據包仍未收到之后，所述方法進一步包括：

客戶端判斷自身是否存在能夠恢復丟失的媒體數據包的FEC數據；如 果存在，則根據FEC數據恢復出媒體數據流中丟失的媒體數據包；否則， 向流媒體服務器發送所述NACK消息。

其中，所述設定FEC編碼冗余度還根據FEC算法以及實際允許的網絡 冗余度上限。

其中，在將需恢復的媒體數據包編碼成FEC數據發送給客戶端之后， 所述方法進一步包括：

流媒體服務器結合后續發送的媒體數據流和FEC編碼冗余度生成FEC 數據并發送給客戶端。

一種媒體數據包丟包恢復的系統，包括流媒體服務器和客戶端，所述流 媒體服務器包括：媒體數據發送模塊、第一媒體數據緩存模塊、丟包補償模 塊和FEC數據編碼模塊；所述客戶端包括：媒體數據接收模塊、第二媒體 數據緩存模塊、丟包上報模塊和FEC恢復模塊；其中，

媒體數據發送模塊，用于向媒體數據接收模塊發送媒體數據流；

第一媒體數據緩存模塊，用于緩存媒體數據發送模塊發送的媒體數據 流；

媒體數據接收模塊，用于接收媒體數據流；

第二媒體數據緩存模塊，用于緩存媒體數據接收模塊接收的媒體數據 流，并當檢測到緩存的媒體數據流中丟失媒體數據包時，觸發丟包上報模塊；

丟包上報模塊，用于向丟包補償模塊發送NACK消息，所述NACK消 息中攜帶有媒體數據流的丟包信息；