[發明專利]一種利用RTP擴展頭部解決視頻幀丟包的方法及裝置

有效

• 申請號: 202010060865.2
• 申請日: 2020-01-20
• 公開（公告）號: CN110876091B
• 公開（公告）日: 2020-04-24
• 發明（設計）人: 董大源;張倩;劉鵬飛;黃永佳
• 申請（專利權）人: 翱捷科技（上海）有限公司
• 主分類號: H04N21/6437
• 分類號: H04N21/6437;H04N7/14;H04N21/4788;H04N21/6375
• 代理公司: 上海恒銳佳知識產權代理事務所(普通合伙) 31286
• 代理人: 殷曉雪

本申請公開了一種利用RTP擴展頭部解決視頻幀丟包的方法，包括如下步驟。步驟S10：提供一種新的RTP擴展頭部，其頭部標識具有兩種取值。步驟S20：發送端僅在關鍵幀后面的n個對應于非關鍵幀的RTP數據包中攜帶頭部標識為第一取值的所述RTP擴展頭部。步驟S30：接收端發現RTP數據包有丟失時，根據頭部標識為第一取值的所述RTP擴展頭部判斷丟失的RTP數據包是否屬于關鍵幀。如果是，接收端向發送端發送RTP數據包，其中攜帶頭部標識為第二取值的所述RTP擴展頭部。步驟S40：發送端根據頭部標識為第二取值的RTP擴展頭部向接收端重新發送相應的RTP數據包。本申請只重傳關鍵幀，所以耗費帶寬不是很大，但能有效地帶來視頻傳輸及播放質量的提升。

技術領域

本申請涉及一種視頻數據的傳輸方法，特別是涉及一種視頻數據在傳輸過程中丟包的解決方法。

背景技術

在網絡通信中，視頻通話比音頻通話要使用更大的帶寬。為了減少視頻通話的帶寬使用，一般的視頻編碼器在編碼時會對原始的視頻流編碼成不同類型的視頻幀。例如H.264視頻壓縮標準定義了I幀、P幀、B幀等。I幀采用幀內編碼（Intra-coded），優點是不依賴其他幀進行獨立解碼，缺點是編碼后的數據比較大。P幀和B幀都采用幀間編碼（Interframe prediction），相對I幀而言其優點是編碼后數據較小可以節省帶寬，但解碼需要依賴I幀，如果依賴的I幀丟失，P幀或B幀無法單獨解碼。在視頻通話過程中，為了節約帶寬減少時延，一般的視頻編碼器例如H.264、H.265等會采用I幀、P幀混合編碼，通過周期性的編碼I幀，并在兩個I幀之間編碼P幀達到節約帶寬、提高視頻質量的效果。例如每間隔1秒發送一個I幀，每兩個I幀中間發送P幀。

在TCP/IP網絡傳輸中定義有MTU（Maximum Transmission Unit，最大傳輸單元），例如以太網（Ethernet）的MTU為1500字節（byte）。當視頻通話采用VGA或更高分辨率時，一幀圖像的大小往往大于MTU的大小。此時發送端的應用層往往會將一個視頻幀分成多個RTP（Real-time Transport Protocol，實時傳輸協議）數據包（packet）發送，例如RFC 6184規范定義的FU-A分片的RTP數據包。接收端在收到RTP數據包后，根據其中的序列號（sequencenumber）和時間戳（timestamp）重新組成原始視頻幀。在視頻通話過程中，網絡狀況經常會發生不可預知的變化，從而造成視頻傳輸過程中丟包。當一個視頻幀的某些RTP數據包丟失，接收端就無法組成完整的視頻幀，并且不得不丟棄已經收到的該視頻幀的其他RTP數據包。如果丟失的是P幀，對接收端的視頻播放影響相對較小。如果丟失的是I幀，由于P幀的解碼需要參考I幀，I幀的缺失會對接收端的視頻播放產生比較大的影響，造成馬賽克或者花屏等顯示異常。并且，這種顯示異常直到接收端收到下一個I幀才能恢復，比如要過1秒。

目前應對網絡側丟包對于視頻通話的影響，已有一些解決方案。

其一，接收端通過RTCP（Real-time Transport Control Protocol，實時傳輸控制協議）發送NACK（Negative Acknowledgement，否定應答）通知發送端重發丟失的RTP數據包。該方案會加重網絡負荷。如果此時網絡丟包率比較大，會導致網絡丟包更加嚴重，效果可能更差。并且，發送端無選擇地重發所有丟失的包，也會在接收端引入較大的延遲。

其二，接收端發送PLI（Picture Loss Indication，圖像丟失指示）通知發送端立即編碼新的I幀發送。該方案中，發送端接收到PLI請求后，需要控制視頻編碼器編碼出新的I幀并分包傳輸，接收端需要接收這些RTP數據包并重組為新的I幀，視頻才能恢復。編碼、分包、傳輸、組包的延遲疊加，導致接收端的視頻恢復需要較長的時間。

發明內容

本申請所要解決的技術問題是提出了一種新機制，通過對RTP擴展頭部的擴充，標識出關鍵幀的索引。當網絡出現丟包時，利用關鍵幀的索引，優先傳送關鍵幀。這樣，在消耗帶寬不大的前提下，可以有效地提升視頻質量。