專利名稱：支持錯(cuò)誤彈性的多媒體數(shù)據(jù)網(wǎng)絡(luò)實(shí)時(shí)傳送方法
技術(shù)領(lǐng)域：
本發(fā)明涉及多媒體數(shù)據(jù)實(shí)時(shí)傳送技術(shù)，特別涉及支持錯(cuò)誤彈性的多媒體數(shù)據(jù)實(shí)時(shí)傳送方法。
背景技術(shù)：
隨著計(jì)算機(jī)互聯(lián)網(wǎng)(Internet)和移動(dòng)通信網(wǎng)絡(luò)的飛速發(fā)展，流媒體技術(shù)的應(yīng)用越來越廣泛，從網(wǎng)上廣播、電影播放到遠(yuǎn)程教學(xué)以及在線的新聞網(wǎng)站等都用到了流媒體技術(shù)。當(dāng)前網(wǎng)上傳送視頻、音頻主要有下載(Download)和流式傳送(Streaming)兩種方式。流式傳送是連續(xù)傳送視/音頻信號(hào)，當(dāng)流媒體在客戶機(jī)播放時(shí)其余部分在后臺(tái)繼續(xù)下載。流式傳送有順序流式傳送(Progressive Streaming)和實(shí)時(shí)流式傳送(Realtime Streaming)兩種方式。實(shí)時(shí)流式傳送是實(shí)時(shí)傳送，特別適合現(xiàn)場(chǎng)事件，實(shí)時(shí)流式傳送必須匹配連接帶寬，這意味著圖像質(zhì)量會(huì)因網(wǎng)絡(luò)速度降低而變差，以減少對(duì)傳送帶寬的需求。“實(shí)時(shí)”的概念是指在一個(gè)應(yīng)用中數(shù)據(jù)的交付必須與數(shù)據(jù)的產(chǎn)生保持精確的時(shí)間關(guān)系。
尤其是隨著第三代移動(dòng)通信系統(tǒng)(3rd Generation，簡(jiǎn)稱“3G”)的出現(xiàn)和普遍基于網(wǎng)際協(xié)議(Internet Protocol，簡(jiǎn)稱“IP”)的網(wǎng)絡(luò)迅速發(fā)展，視頻通信正逐步成為通信的主要業(yè)務(wù)之一。而雙方或多方視頻通信業(yè)務(wù)，如可視電話、視頻會(huì)議、移動(dòng)終端多媒體服務(wù)等，更對(duì)多媒體數(shù)據(jù)流的傳送及服務(wù)質(zhì)量提出苛刻的要求。不僅要求網(wǎng)絡(luò)傳送實(shí)時(shí)性更好，而且等效的也要求視頻數(shù)據(jù)壓縮編碼效率更高。
鑒于媒體通信的需求現(xiàn)狀，國(guó)際電信聯(lián)盟標(biāo)準(zhǔn)部(InternationalTelecommunication Union Telecommunication Standardization Sector，簡(jiǎn)稱“ITU-T”)繼制定了H.261、H.263、H.263+等視頻壓縮標(biāo)準(zhǔn)后，于2003年正式發(fā)布了H.264標(biāo)準(zhǔn)。這是ITU-T和國(guó)際標(biāo)準(zhǔn)化組織(InternationalStandardization Organization，簡(jiǎn)稱“ISO”)的運(yùn)動(dòng)圖像專家組(Moving PictureExperts Group，簡(jiǎn)稱“MPEG”)一起聯(lián)合制定的適應(yīng)新階段網(wǎng)絡(luò)媒體傳送及通信需求的高效壓縮編碼標(biāo)準(zhǔn)。它同時(shí)也是MPEG-4標(biāo)準(zhǔn)第10部分的主要內(nèi)容。
制定H.264標(biāo)準(zhǔn)的目的在于更加有效地提高視頻編碼效率和它對(duì)網(wǎng)絡(luò)的適配性。事實(shí)上由于其優(yōu)越性，H.264視頻壓縮編碼標(biāo)準(zhǔn)很快就已經(jīng)逐漸成為當(dāng)前多媒體通信中的主流標(biāo)準(zhǔn)。大量的采用H.264多媒體實(shí)時(shí)通信產(chǎn)品(如會(huì)議電視，可視電話，3G移動(dòng)通信終端)和網(wǎng)絡(luò)流媒體產(chǎn)品先后問世，是否支持H.264已經(jīng)成為這個(gè)市場(chǎng)領(lǐng)域中決定產(chǎn)品競(jìng)爭(zhēng)力的關(guān)鍵因素?？梢灶A(yù)測(cè)，隨著H.264的正式頒布和廣泛使用，基于IP網(wǎng)絡(luò)和3G、后3G無線網(wǎng)絡(luò)的多媒體通信必然進(jìn)入一個(gè)飛躍發(fā)展的新階段。
如前所述多媒體通信不僅要求媒體壓縮編碼效率高，而且要求網(wǎng)絡(luò)傳送的實(shí)時(shí)性。目前多媒體流傳送基本上都是采用實(shí)時(shí)傳送協(xié)議(Real-timeTransport Protocol，簡(jiǎn)稱“RTP”)及其控制協(xié)議(Real-time Transport ControlProtocol，簡(jiǎn)稱“RTCP”)。RTP是針對(duì)Internet上多媒體數(shù)據(jù)流的一個(gè)傳送協(xié)議，由互聯(lián)網(wǎng)工程任務(wù)組(Internet Engineering Task Force，簡(jiǎn)稱“IETF”)發(fā)布。RTP被定義為在一對(duì)一或一對(duì)多的傳送情況下工作，其目的是提供時(shí)間信息和實(shí)現(xiàn)流同步。RTP的典型應(yīng)用建立在用戶數(shù)據(jù)包協(xié)議(UserDatagram Protocol，簡(jiǎn)稱“UDP”)上，但也可以在傳送控制協(xié)議(TransportControl Protocol，簡(jiǎn)稱“TCP”)或異步傳送模式(Asynchronous Transfer Mode，簡(jiǎn)稱“ATM”)等其他協(xié)議之上工作。
RTP本身只保證實(shí)時(shí)數(shù)據(jù)的傳送，并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機(jī)制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務(wù)。RTCP負(fù)責(zé)管理傳送質(zhì)量在當(dāng)前應(yīng)用進(jìn)程之間交換控制信息。在RTP會(huì)話期間，各參與者周期性地傳送RTCP包，包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計(jì)資料，因此，服務(wù)器可以利用這些信息動(dòng)態(tài)地改變傳送速率，甚至改變有效載荷類型。RTP和RTCP配合使用，能以有效的反饋和最小的開銷使傳送效率最佳化，故適合傳送網(wǎng)上的實(shí)時(shí)數(shù)據(jù)。
而H.264多媒體數(shù)據(jù)在IP網(wǎng)絡(luò)上傳送，不例外的也是基于UDP和其上層的RTP協(xié)議。RTP本身在結(jié)構(gòu)上對(duì)于不同的媒體數(shù)據(jù)類型都能夠適用，但是在多媒體通信中不同的高層協(xié)議或媒體壓縮編碼標(biāo)準(zhǔn)(如H.261，H.263，MPEG-1/-2/-4，MP3等)，IETF都會(huì)制定針對(duì)該協(xié)議的RTP凈荷(Payload)打包方法的規(guī)范文件，詳細(xì)規(guī)定RTP封裝大包的方法，對(duì)于該具體協(xié)議是經(jīng)過優(yōu)化的。同樣的，對(duì)于H.264也存在對(duì)應(yīng)的IETF標(biāo)準(zhǔn)是RFC 3984RTPPayload Format for H.264 Video。該標(biāo)準(zhǔn)目前是H.264視頻碼流在IP網(wǎng)絡(luò)上傳送的主要標(biāo)準(zhǔn)，應(yīng)用很廣泛。在視頻通信領(lǐng)域，各主流廠商的產(chǎn)品都是基于RFC 3984的，也是目前僅有的H.264/RTP傳送方式。
事實(shí)上，H.264和以往其它的視頻壓縮編碼協(xié)議不同的關(guān)鍵地方在于H.264定義了一個(gè)新的層面，稱為網(wǎng)絡(luò)抽象層(Network Abstract Layer，簡(jiǎn)稱“NAL”)。H.264為了增加其視頻編碼層(Video Coding Layer，簡(jiǎn)稱“VCL”)和下面具體的網(wǎng)絡(luò)傳送協(xié)議層的分離和無關(guān)性，帶來更大的應(yīng)用靈活性，定義了NAL這個(gè)新的層面，該層在ITU-T早期的視頻壓縮編碼協(xié)議比如H.261，H.263/H.263+/H.263++中都是沒有的。然而，如何在NAL和RTP協(xié)議承載協(xié)同工作中針對(duì)H.264的優(yōu)點(diǎn)設(shè)計(jì)效率更高、更好的方案，使得RTP對(duì)于H.264的承載性能更好，是一個(gè)很值得研究和有很大應(yīng)用價(jià)值的問題。
RFC3984規(guī)范所提出的RTP承載H.264的NAL層數(shù)據(jù)的方法是目前主流傳送方法，該方案在RTP協(xié)議(RFC 3550)的基礎(chǔ)上，將NAL層數(shù)據(jù)封裝在RTP凈荷中進(jìn)行承載。NAL層位于VCL和RTP之間，規(guī)定要把視頻碼流按照定義的規(guī)則和結(jié)構(gòu)，分割成一連串的NAL數(shù)據(jù)單元(NAL Units，簡(jiǎn)稱“NALU”)。在RFC3984中定義了RTP凈荷對(duì)于NALU的封裝格式。下面依次簡(jiǎn)單介紹RTP的幀格式和現(xiàn)有技術(shù)中NALU的封裝方法。
RTP設(shè)計(jì)的主要目的是實(shí)時(shí)多媒體會(huì)議和連續(xù)數(shù)據(jù)存儲(chǔ)、交互分布式仿真、控制和測(cè)量應(yīng)用等。RTP通常被承載于UDP協(xié)議之上，以利用其多路復(fù)用和校驗(yàn)的功能。如果底層提供多點(diǎn)分發(fā)，RTP支持多地址傳送。RTP提供的功能包括載荷類型鑒別、序列編號(hào)、時(shí)間戳、和發(fā)送監(jiān)測(cè)。
RTP的包格式如下RTP頭信息基本選項(xiàng)占用12字節(jié)(最小情況)，而IP協(xié)議和UDP協(xié)議的頭信息分別占用20字節(jié)和8字節(jié)，因此RTP包封裝在UDP包再封裝在IP包中，總的頭信息占用字節(jié)數(shù)是12+8+20＝40字節(jié)。RTP包的頭信息的詳細(xì)結(jié)構(gòu)如圖1所示。
圖1中所示從前到后RTP頭信息依次為第1字節(jié)(字節(jié)0)為一些關(guān)于頭信息結(jié)構(gòu)本身的字段，第2字節(jié)(字節(jié)1)為定義凈荷類型，第3、4字節(jié)(字節(jié)2、3)為包序號(hào)(Sequence Number)，第5-8字節(jié)為時(shí)間戳(timestamp)，第9-12字節(jié)為同步貢獻(xiàn)源標(biāo)識(shí)符(Synchronous Source Identifier，簡(jiǎn)稱“SSRCID”)，最后為貢獻(xiàn)源標(biāo)識(shí)符(Contributing Source Identifiers，簡(jiǎn)稱“CSRCIDs”)的列表，其數(shù)目不確定。注意到，在本文描述中第1個(gè)字節(jié)為標(biāo)注的字節(jié)0，之后依此類推。
其中前12個(gè)字節(jié)出現(xiàn)在所有不同類型的RTP數(shù)據(jù)包中，而頭信息中的其它數(shù)據(jù)，比如貢獻(xiàn)源標(biāo)識(shí)符標(biāo)識(shí)只有當(dāng)混合器插入時(shí)才有。因此CSRC一般用于存在媒體混合時(shí)候的情況，比如在多方會(huì)議中，音頻需要混合，視頻也可以用這種方法提供多畫面的功能。而同步源標(biāo)識(shí)SSRC其實(shí)就是所承載媒體流的標(biāo)識(shí)。
上述各個(gè)字段的具體意義及全稱分別描述如下
V字段為版本(Version)信息，占2比特(bits)，目前采用的版本為2，因此置V＝2，而其他值如V＝1表示更早的RTP版本，V＝0表示最原始的RTP前身，即在早期Mbone網(wǎng)絡(luò)上使用的語(yǔ)音IP(VOIP)通信系統(tǒng)中采用，后來演化成了RTP，而V＝3則尚未定義，因此本發(fā)明可以使用。；P字段為填充標(biāo)識(shí)(Padding)，占1比特，P如果置位，則表示數(shù)據(jù)包末尾包含一個(gè)或多個(gè)填充字節(jié)(Padding)，填充不屬于有效載荷的一部分；X字段為擴(kuò)展標(biāo)識(shí)比特(Extension)，占1比特，X如果置位，則RTP頭的最后必須跟一個(gè)可變長(zhǎng)的頭擴(kuò)展(如果有CSRC列表，頭擴(kuò)展要跟在其后)，主要是保留用于某些應(yīng)用環(huán)境下頭信息字段不夠用的情況，該頭信息擴(kuò)展包含一個(gè)16比特的長(zhǎng)度字段來計(jì)數(shù)擴(kuò)展中有多少個(gè)32比特長(zhǎng)的字，頭擴(kuò)展的前16比特是左開放的，以便區(qū)分標(biāo)識(shí)符和參數(shù)，這16比特的格式由具體的層面規(guī)范定義，該頭擴(kuò)展的格式定義在RFC3550第5.3.1節(jié)中有詳細(xì)描述，此處限于篇幅不再給出；CC字段為貢獻(xiàn)源數(shù)目(CSRC Count)，占4比特s，指明頭信息最后面的CSRC標(biāo)識(shí)符的個(gè)數(shù)，接收方根據(jù)CC字段可以確定頭信息后面的CSRCIDs列表長(zhǎng)度；M字段為標(biāo)識(shí)比特(Marker)，占1比特，該標(biāo)識(shí)比特的解釋在特定的層面(Profile)中定義，它允許標(biāo)識(shí)出數(shù)據(jù)包流中的重要事件，一個(gè)層面可以定義附加的標(biāo)識(shí)比特或規(guī)定沒有標(biāo)識(shí)比特，這里所謂層面就是指具體的應(yīng)用環(huán)境設(shè)置，由通信雙方具體協(xié)定，不受協(xié)議的限定；PT字段為載荷類型(Payload Type，簡(jiǎn)稱“PT”)，共7比特s，標(biāo)識(shí)RTP載荷的格式并確定他在應(yīng)用程序中的解釋；標(biāo)志比特和載荷類型共一個(gè)字節(jié)攜帶層面規(guī)定信息，這個(gè)字節(jié)可能會(huì)被具體層面重新定義以適應(yīng)不同需求，在具體應(yīng)用中可以定義所謂的profile，其實(shí)就是一組靜態(tài)(即通信雙方事先約定好的)對(duì)應(yīng)關(guān)系，將PT比特不同的取值和不同的媒體格式對(duì)應(yīng)起來。當(dāng)然也可以通過RTP之外的信令來進(jìn)行動(dòng)態(tài)協(xié)商定義PT取值和媒體格式之間的關(guān)系。在一個(gè)RTP會(huì)話(Session)中，RTP源是可以變更PT的。
接著的字段就是序號(hào)共16比特，每發(fā)送一個(gè)RTP數(shù)據(jù)包，該序號(hào)值加一，這樣接收者可以用它來檢測(cè)數(shù)據(jù)包丟失和恢復(fù)數(shù)據(jù)包順序，一次通信中的序號(hào)初始值可以隨機(jī)給定，不影響通信。
時(shí)間戳占32比特，它反映了RTP數(shù)據(jù)包中第一個(gè)字節(jié)的采樣時(shí)間，這里的采樣時(shí)間必須來源于一個(gè)單調(diào)線性增長(zhǎng)的時(shí)鐘，接收方根據(jù)其調(diào)整媒體播放時(shí)間或者進(jìn)行同步。
同步源SSRC ID占32比特，其具體值可隨機(jī)選擇，但要確保同一個(gè)RTP會(huì)話中的唯一性，即能唯一標(biāo)識(shí)一個(gè)媒體源，如果一個(gè)源改變了源傳送地址，必須選擇一個(gè)新的SSRC標(biāo)志符。
貢獻(xiàn)源CSRC列表，可以根據(jù)需要為0-15項(xiàng)，每項(xiàng)占32比特s，該列表的長(zhǎng)度即CSRC ID的數(shù)目正好由CC字段的4個(gè)比特標(biāo)出。事實(shí)上，用于標(biāo)識(shí)某個(gè)媒體源的CSRC標(biāo)志符與其對(duì)應(yīng)的貢獻(xiàn)源的SSRC標(biāo)志符是一致的，只不過在不同的接收方的角色不同，而被置為SSRC或CSRC。在多方通信中，CSRC ID是由混合器插入。
在承載H.264視頻的情況下，RTP把H.264的NALU封裝打包成RTP包流。在RFC 3984文件中主要定義了NALU，并且基于此給出H.264層NAL數(shù)據(jù)在RTP中的封裝打包格式。這種NALU的RTP封裝格式如圖2所示。
圖2中給出一個(gè)NALU在RTP的凈荷中的封裝結(jié)構(gòu)，前面第一個(gè)字節(jié)為NALU頭信息，之后為NALU的數(shù)據(jù)內(nèi)容，多個(gè)NALU首尾相接的填充到RTP包的凈荷中，在最后還有可選的RTP填充，這是RTP包格式規(guī)定的內(nèi)容，是為了使得RTP包的長(zhǎng)度符合某種特定要求(比如達(dá)到固定長(zhǎng)度)，可選的RTP填充數(shù)據(jù)一般都填零。
NALU頭信息即第1個(gè)字節(jié)，也稱為八比特組(Octet)，其共有三個(gè)字段，意義和全稱分別描述如下F字段定義為禁止比特(forbidden_zero_比特)，占1比特，用于標(biāo)識(shí)語(yǔ)法錯(cuò)等情況，如果有語(yǔ)法沖突則置為1，當(dāng)網(wǎng)絡(luò)識(shí)別此單元中存在比特錯(cuò)誤時(shí)，可將其設(shè)為1，以便接收方丟掉該單元，主要用于適應(yīng)不同種類的網(wǎng)絡(luò)環(huán)境(比如有線無線相結(jié)合的環(huán)境)；NRI字段定義為NAL參考標(biāo)識(shí)(nal_ref_idc)，占2比特，用于指示NALU數(shù)據(jù)的重要程度，其值為00表示NALU的內(nèi)容不用于重建幀間預(yù)測(cè)的參考圖像，而非00則表示當(dāng)前NALU是屬于參考幀的條帶(slice)或序列參數(shù)集(Sequence Parameter Set，簡(jiǎn)稱“SPS”)、圖像參數(shù)集(PictureParameter Set，簡(jiǎn)稱“PPS”)等重要數(shù)據(jù)，該值越大表示當(dāng)前NAL越重要；Type字段定義為NALU類型(Nal_unit_type)，共5比特，可以有32種NALU的類型，其值和具體類型的對(duì)應(yīng)關(guān)系在表1中詳細(xì)給出。
表1 NALU頭信息中Type字段取值與類型對(duì)應(yīng)關(guān)系表

可見，NALU的頭信息的一個(gè)字節(jié)中給出的信息主要包含NALU的有效性、重要性等級(jí)，根據(jù)這些信息可以確定RTP所承載的數(shù)據(jù)重要性。
在了解了H.264/RTP的傳送結(jié)構(gòu)之后，與本發(fā)明的內(nèi)容密切相關(guān)的還有多媒體網(wǎng)絡(luò)傳送的錯(cuò)誤彈性機(jī)制。下面簡(jiǎn)單介紹有關(guān)于視頻網(wǎng)絡(luò)傳送的錯(cuò)誤彈性和相關(guān)技術(shù)背景。
H.264視頻是未來多媒體通信的主要協(xié)議，未來的多媒體通信應(yīng)用的網(wǎng)絡(luò)主要是以IP為代表的數(shù)據(jù)包交換網(wǎng)絡(luò)和無線網(wǎng)絡(luò)。這兩大類網(wǎng)絡(luò)都無法提供很好的服務(wù)質(zhì)量(Quality of Service，簡(jiǎn)稱“QoS”)保證，因此視頻在網(wǎng)絡(luò)上傳送必然會(huì)受到各種傳送錯(cuò)誤而丟包的影響，從而使得通信質(zhì)量降低。這里面的一個(gè)最主要的問題是IP網(wǎng)絡(luò)實(shí)現(xiàn)“盡力”(best effort)傳送，并不能保證傳送視頻信號(hào)的QoS。特別是對(duì)經(jīng)過高效壓縮編碼的H.264碼流，問題更為突出。IP網(wǎng)絡(luò)上的盡力傳送不能保證實(shí)時(shí)視頻通信的QoS，具體表現(xiàn)在三個(gè)方面數(shù)據(jù)包丟失、時(shí)延和時(shí)延抖動(dòng)。其中，數(shù)據(jù)包丟失對(duì)恢復(fù)視頻的質(zhì)量影響最大，由于H.264壓縮編碼算法使用運(yùn)動(dòng)估值和運(yùn)動(dòng)補(bǔ)償技術(shù)，一旦有數(shù)據(jù)包丟失存在，不僅影響當(dāng)前解碼圖像，而且會(huì)影響后續(xù)解碼圖像，即誤碼擴(kuò)散。誤碼擴(kuò)散對(duì)恢復(fù)視頻質(zhì)量的影響非常大，只有結(jié)合編碼端和解碼端聯(lián)合抗誤碼，才能完全避免誤碼擴(kuò)散。
錯(cuò)誤彈性(Error Resilience)是指?jìng)魉蜋C(jī)制具有預(yù)防錯(cuò)誤發(fā)生或者在錯(cuò)誤發(fā)生后能夠以一定能力糾正的能力(錯(cuò)誤強(qiáng)度在一定范圍內(nèi)，可以完全糾正；超過一定范圍，只能部分糾正)。在未來的廣泛(可以說無所不在)的多媒體通信環(huán)境中，一種視頻傳送機(jī)制是否具有錯(cuò)誤彈性將是非常關(guān)鍵的。
存在多種錯(cuò)誤彈性機(jī)制，比如前向糾錯(cuò)(Forward Error Correction，簡(jiǎn)稱“FEC”)、自動(dòng)重發(fā)請(qǐng)求(Automatic Retransmission Request，簡(jiǎn)稱“ARQ”)、錯(cuò)誤掩蓋(Error Concealment)、信源信道聯(lián)合編碼(Joint Source-ChannelCoding，簡(jiǎn)稱“JSCC”)、交織(Interleaving)及消除誤碼擴(kuò)散等。對(duì)于H.264視頻在數(shù)據(jù)包網(wǎng)絡(luò)上傳送，F(xiàn)EC是一種很實(shí)用的技術(shù)，效果很好。該方法主要采用多種糾錯(cuò)編碼來對(duì)于要保護(hù)的數(shù)據(jù)進(jìn)行編碼，實(shí)質(zhì)是形成數(shù)據(jù)冗余，從而增加抗御錯(cuò)誤的能力。
在數(shù)據(jù)包網(wǎng)絡(luò)上主要的錯(cuò)誤是丟包錯(cuò)誤，這種錯(cuò)誤在糾錯(cuò)編碼理論中叫做刪除錯(cuò)誤(Erasure Error)。針對(duì)刪除錯(cuò)誤的糾錯(cuò)編碼是一大類叫做糾刪碼(Erasure Codes)。所謂糾刪碼就是把數(shù)據(jù)碼流順序逐段分割成大小相同的一個(gè)個(gè)單元(Unit)，也叫做數(shù)據(jù)節(jié)點(diǎn)(Data Nodes)，為表示方便，假設(shè)共有n個(gè)數(shù)據(jù)節(jié)點(diǎn)。然后按照一定的數(shù)學(xué)運(yùn)算規(guī)則對(duì)于這些數(shù)據(jù)節(jié)點(diǎn)進(jìn)行計(jì)算產(chǎn)生出校驗(yàn)節(jié)點(diǎn)(Parity Nodes或Check Nodes)，為了增強(qiáng)保護(hù)能力，還可以對(duì)于這些校驗(yàn)節(jié)點(diǎn)繼續(xù)按照相同或者不同的數(shù)學(xué)運(yùn)算規(guī)則運(yùn)算產(chǎn)生出第二層校驗(yàn)節(jié)點(diǎn)，依次類推，可以生成第三層，第四層，直至第N層校驗(yàn)節(jié)點(diǎn)。
一般來說，如果涉及多層校驗(yàn)節(jié)點(diǎn)，每層上的節(jié)點(diǎn)數(shù)目相對(duì)于上一層是按照一定規(guī)律(最常見的是等比規(guī)律)遞減的，這樣就行成一個(gè)逐層遞縮的多層節(jié)點(diǎn)結(jié)構(gòu)?？梢孕蜗蟮乇硎緸橐粋€(gè)向右轉(zhuǎn)90度的金字塔。其中，最左邊是數(shù)據(jù)節(jié)點(diǎn)層，向右排列依次是第一層校驗(yàn)節(jié)點(diǎn)，第二層校驗(yàn)節(jié)點(diǎn)，......，第N層校驗(yàn)節(jié)點(diǎn)。
其中一類糾刪碼具有一種非常重要的性質(zhì)，即處理需要的時(shí)間復(fù)雜度是和數(shù)據(jù)節(jié)點(diǎn)數(shù)n存在線性關(guān)系，因此叫做線性時(shí)間特性(linear-time)。而很多其它的糾刪碼比如著名的Reed-Solomon碼需要的時(shí)間復(fù)雜度就要高得多，是n*log2n*log(logn)數(shù)量級(jí)的。因此，具有線性時(shí)間性的糾刪碼其在實(shí)時(shí)通信中的用途要好得多。
Tornado糾刪碼(下文均簡(jiǎn)稱Tornado碼)是1998年前后出現(xiàn)的一種的新型糾刪碼。Tornado碼結(jié)構(gòu)簡(jiǎn)單；運(yùn)算高效，因?yàn)樗哂芯€性時(shí)間性；保護(hù)能力強(qiáng)。在實(shí)際應(yīng)用中，獲得了很好的效果。目前已經(jīng)獲得較為廣泛的應(yīng)用。根據(jù)最新的ITU-T動(dòng)態(tài)，其中的SG16目前正在考慮對(duì)于錯(cuò)誤控制編碼類(Error Control Codes)技術(shù)進(jìn)行標(biāo)準(zhǔn)化的可能性，主要是針對(duì)視頻音頻網(wǎng)絡(luò)傳送進(jìn)行保護(hù)。Tornado碼及其多個(gè)變種很可能是其中的重要技術(shù)。
在Tornado碼中，從數(shù)據(jù)節(jié)點(diǎn)逐層產(chǎn)生出多個(gè)校驗(yàn)節(jié)點(diǎn)層。校驗(yàn)節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)都由發(fā)送端通過網(wǎng)絡(luò)發(fā)送給接收端。如果在網(wǎng)絡(luò)傳送過程中，部分節(jié)點(diǎn)丟失了，因?yàn)樯蠈庸?jié)點(diǎn)參加了下層節(jié)點(diǎn)的生成，因此上層節(jié)點(diǎn)的信息已經(jīng)包含在了下層節(jié)點(diǎn)以及更下層節(jié)點(diǎn)中，因此丟失節(jié)點(diǎn)的信息可以通過足夠多數(shù)目的下層節(jié)點(diǎn)或者更下層節(jié)點(diǎn)來完全恢復(fù)。如果每個(gè)節(jié)點(diǎn)是一個(gè)包，則丟失的包可以由正確接收到的其它包完全恢復(fù)。設(shè)數(shù)據(jù)節(jié)點(diǎn)個(gè)數(shù)為n，產(chǎn)生的校驗(yàn)節(jié)點(diǎn)數(shù)為1。則定義糾刪碼的碼率和冗余率分別是r＝n/(n+1)，1-r＝1/(n+1)；在其它條件相同情況下(保護(hù)能力，造成的延遲等)，碼率越高(必然地，冗余率越低)，則糾刪碼的效率越高。
圖3示出了一種典型的Tornado碼數(shù)據(jù)節(jié)點(diǎn)及各層校驗(yàn)節(jié)點(diǎn)間的關(guān)系。圖中節(jié)點(diǎn)之間的連線稱為邊，表示邊的左側(cè)節(jié)點(diǎn)參與計(jì)算右側(cè)節(jié)點(diǎn)，可見前后兩層節(jié)點(diǎn)之間是一種多對(duì)多的邏輯關(guān)系。Tornado碼產(chǎn)生過程中最常采用的計(jì)算方法是異或運(yùn)算，因?yàn)楫惢蜻\(yùn)算具有很方便的恢復(fù)功能，任意一個(gè)節(jié)點(diǎn)丟失后，均可由所有其余節(jié)點(diǎn)恢復(fù)。由于最后一層校驗(yàn)節(jié)點(diǎn)的遞縮比例不同，因此一般采用常規(guī)的糾錯(cuò)編碼方案進(jìn)行計(jì)算，比如Reed-Solomon碼。
其實(shí)，糾刪碼的范圍很大，Tornado碼只是其中比較典型的一種，另外還有比如RS(Reed-Solomon)碼、低密度校驗(yàn)碼(Low Density Parity Codes，簡(jiǎn)稱“LDPC”)等。
糾刪碼的一個(gè)重要的性能指標(biāo)就是其糾錯(cuò)能力(或者叫做保護(hù)能力)，直接體現(xiàn)為能夠完全糾正丟包錯(cuò)誤所允許的最大丟包數(shù)量(在一定包的總數(shù)前體下)，或者當(dāng)丟包高于這個(gè)最大允許數(shù)量條件下，能夠正確糾正包的百分比。一般來說，在其他條件相同情況下，保護(hù)能力越高，冗余率越高。
保護(hù)能力不僅適用于糾刪碼，在更大范圍內(nèi)，所有FEC編碼都可以用保護(hù)能力來度量。在視頻數(shù)據(jù)中，有些數(shù)據(jù)相對(duì)重要性高，比如視頻序列的結(jié)構(gòu)參數(shù)、圖像的結(jié)構(gòu)參數(shù)、頭信息等；另外一些數(shù)據(jù)的重要性相對(duì)低，比如圖像內(nèi)容數(shù)據(jù)等。在使用FEC進(jìn)行保護(hù)時(shí)，對(duì)于相對(duì)重要的數(shù)據(jù)采用保護(hù)能力較強(qiáng)的編碼；而對(duì)于相對(duì)不重要的數(shù)據(jù)采用保護(hù)能力較弱的編碼。這樣可以在保護(hù)能力和效率之間達(dá)成平衡。不能一味強(qiáng)調(diào)保護(hù)能力，因?yàn)檫@樣會(huì)導(dǎo)致很高的冗余，犧牲了效率。這種根據(jù)數(shù)據(jù)相對(duì)重要性來進(jìn)行不同保護(hù)能力的FEC保護(hù)的方法叫做不等保護(hù)(Unequal Protection，簡(jiǎn)稱“UEP”)。通過不等保護(hù)，容易實(shí)現(xiàn)視頻通信服務(wù)的QoS保證。
目前傳送視頻多媒體數(shù)據(jù)的RTP協(xié)議是不提供錯(cuò)誤彈性的，要靠更高的應(yīng)用層來提供?，F(xiàn)有技術(shù)在對(duì)于H.264等視頻數(shù)據(jù)網(wǎng)絡(luò)傳送中，一般是使用糾刪碼保護(hù)來實(shí)現(xiàn)錯(cuò)誤彈性的。以H.264為例，現(xiàn)有技術(shù)方案所采取的措施是發(fā)送端在H.264的NALU層面，對(duì)于NALU數(shù)據(jù)單元直接使用某種糾刪碼，然后將結(jié)果(包括數(shù)據(jù)節(jié)點(diǎn)和校驗(yàn)節(jié)點(diǎn))直接封裝在RTP數(shù)據(jù)包中，然后進(jìn)行傳送。
接收端在收到RTP數(shù)據(jù)包后，進(jìn)行去封裝，提取出數(shù)據(jù)節(jié)點(diǎn)和校驗(yàn)節(jié)點(diǎn)，如果發(fā)生丟包，即某個(gè)或者某些RTP數(shù)據(jù)包丟失，那么根據(jù)這些丟失包中封裝了哪些數(shù)據(jù)節(jié)點(diǎn)或者校驗(yàn)節(jié)點(diǎn)，可以判斷是否能夠利用正確接收到的數(shù)據(jù)節(jié)點(diǎn)和校驗(yàn)節(jié)點(diǎn)來完全恢復(fù)或者部分恢復(fù)丟失的節(jié)點(diǎn)，并且進(jìn)行恢復(fù)操作。
當(dāng)然也有采用其他除了糾刪碼以外的錯(cuò)誤彈性機(jī)制實(shí)現(xiàn)的，但糾刪碼對(duì)于H.264數(shù)據(jù)的保護(hù)能夠提供最高效的錯(cuò)誤彈性機(jī)制。
可見，現(xiàn)有技術(shù)是在高層通過對(duì)NALU等多媒體數(shù)據(jù)進(jìn)行糾刪編碼然后在RTP傳送，在接收端進(jìn)行相應(yīng)的糾刪解碼。需要注意的是，收發(fā)雙方一般是通過傳送之前的信令交互來協(xié)商決定采用什么前向糾錯(cuò)編碼方案以及該方案所采用的參數(shù)設(shè)置等，比如采用H.323/H.245等協(xié)議通道供雙方進(jìn)行協(xié)商。
在實(shí)際應(yīng)用中，上述方案存在以下問題現(xiàn)有技術(shù)方案中錯(cuò)誤彈性機(jī)制均在RTP的高層實(shí)現(xiàn)，其中雙方協(xié)商或者告知所采用的糾刪碼類型及其參數(shù)設(shè)置時(shí)需要通過其他的邏輯信道實(shí)現(xiàn)，嚴(yán)重影響多媒體傳送效率，耗用網(wǎng)絡(luò)帶寬資源；而對(duì)于RTP傳送層面來說，錯(cuò)誤彈性機(jī)制是透明的，因此RTP層并不能得知FEC編解碼方案產(chǎn)生的編碼多媒體數(shù)據(jù)的結(jié)構(gòu)，從而無法進(jìn)行針對(duì)性的封裝去封裝，無法簡(jiǎn)化傳送層次架構(gòu)，加長(zhǎng)網(wǎng)絡(luò)傳送延時(shí)、傳送設(shè)備變得復(fù)雜；對(duì)于收發(fā)兩端在協(xié)商確定FEC編碼方案之后，即一直按照該方案?jìng)魉投嗝襟w數(shù)據(jù)，對(duì)于不同重要性的數(shù)據(jù)和不同時(shí)刻的網(wǎng)絡(luò)傳送狀態(tài)來說，無法實(shí)現(xiàn)不等保護(hù)機(jī)制，也無法由錯(cuò)誤彈性機(jī)制來實(shí)現(xiàn)QoS保證。
造成這種情況的主要原因在于，現(xiàn)有技術(shù)是在高層實(shí)現(xiàn)FEC等錯(cuò)誤彈性機(jī)制的，并沒有利用到RTP協(xié)議及其封裝，因此收發(fā)雙方需要另外建立邏輯信道或者利用具體的應(yīng)用層協(xié)議比如H.323協(xié)議體系中的某些協(xié)議H.245，來協(xié)商或通知所采用的FEC編碼類型，結(jié)構(gòu)參數(shù)等信息；沒有在RTP層涉及錯(cuò)誤彈性相關(guān)細(xì)節(jié)，沒有制定RTP數(shù)據(jù)包如何封裝經(jīng)過FEC保護(hù)產(chǎn)生的數(shù)據(jù)節(jié)點(diǎn)和校驗(yàn)節(jié)點(diǎn)；也沒有根據(jù)網(wǎng)絡(luò)狀況和多媒體數(shù)據(jù)的重要性來選擇FEC編解碼方案，缺乏提供對(duì)于具有不同相對(duì)重要性數(shù)據(jù)進(jìn)行不同保護(hù)能力FEC保護(hù)的機(jī)制，即無法實(shí)現(xiàn)不等保護(hù)。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的主要目的在于提供一種支持錯(cuò)誤彈性的多媒體數(shù)據(jù)網(wǎng)絡(luò)實(shí)時(shí)傳送方法，使得多媒體數(shù)據(jù)實(shí)時(shí)傳送的錯(cuò)誤彈性機(jī)制能在傳送協(xié)議層面得以實(shí)現(xiàn)；本發(fā)明進(jìn)一步的目的是實(shí)現(xiàn)針對(duì)不同數(shù)據(jù)和網(wǎng)絡(luò)狀況的不等保護(hù)機(jī)制和分級(jí)保護(hù)機(jī)制。
為實(shí)現(xiàn)上述目的，本發(fā)明提供了一種支持錯(cuò)誤彈性的多媒體數(shù)據(jù)網(wǎng)絡(luò)實(shí)時(shí)傳送方法，包含以下步驟A發(fā)送端選擇前向糾錯(cuò)編碼方案對(duì)所述多媒體數(shù)據(jù)進(jìn)行前向糾錯(cuò)編碼；B所述發(fā)送端用錯(cuò)誤彈性實(shí)時(shí)傳送協(xié)議封裝編碼后的多媒體數(shù)據(jù)，進(jìn)行過前向糾錯(cuò)編碼的多媒體數(shù)據(jù)分為數(shù)據(jù)節(jié)點(diǎn)和校驗(yàn)節(jié)點(diǎn)兩類，并在所述錯(cuò)誤彈性實(shí)時(shí)傳送協(xié)議包頭信息中攜帶所述前向糾錯(cuò)編碼方案相關(guān)信息，然后發(fā)送到接收端；C所述接收端將收到的錯(cuò)誤彈性實(shí)時(shí)傳送協(xié)議包去封裝，并從所述錯(cuò)誤彈性實(shí)時(shí)傳送協(xié)議包頭信息中提取所述前向糾錯(cuò)編碼方案相關(guān)信息；D如果在傳送過程中發(fā)生了數(shù)據(jù)節(jié)點(diǎn)對(duì)應(yīng)的錯(cuò)誤彈性實(shí)時(shí)傳送協(xié)議包的丟失，那么所述接收端根據(jù)所述前向糾錯(cuò)編碼方案相關(guān)信息，選擇所述前向糾錯(cuò)解碼方案進(jìn)行前向糾錯(cuò)解碼，恢復(fù)或者部分恢復(fù)所述丟失的多媒體數(shù)據(jù)。
其中，在所述步驟A中，所述發(fā)送端至少根據(jù)以下因素之一選擇所述前向糾錯(cuò)編碼方案當(dāng)前網(wǎng)絡(luò)傳送狀況、和待發(fā)送多媒體數(shù)據(jù)的服務(wù)質(zhì)量等級(jí)，而后者又決定于不同數(shù)據(jù)的相對(duì)重要性。
此外在所述方法中，所述錯(cuò)誤彈性實(shí)時(shí)傳送協(xié)議包頭信息中包含前向糾錯(cuò)編碼類型字段，用于指示所述前向糾錯(cuò)編碼方案采用的前向糾錯(cuò)碼類型；前向糾錯(cuò)編碼子類型字段，用于指示所述前向糾錯(cuò)編碼方案的相關(guān)參數(shù)設(shè)置；數(shù)據(jù)包長(zhǎng)度字段，用于指示所述前向糾錯(cuò)編碼方案在對(duì)所述多媒體數(shù)據(jù)進(jìn)行糾前向糾錯(cuò)碼后得到的節(jié)點(diǎn)的長(zhǎng)度；數(shù)據(jù)包數(shù)目字段，用于指示該錯(cuò)誤彈性實(shí)時(shí)傳送協(xié)議包所承載的所述節(jié)點(diǎn)的數(shù)目。
此外在所述方法中，當(dāng)所述多媒體數(shù)據(jù)為H.264網(wǎng)絡(luò)抽象層單元時(shí)，在所述步驟A中，所述發(fā)送端將至少一個(gè)所述H.264網(wǎng)絡(luò)抽象層單元?jiǎng)澐譃榈乳L(zhǎng)的至少一個(gè)數(shù)據(jù)節(jié)點(diǎn)，然后對(duì)其進(jìn)行前向糾錯(cuò)編碼，得到至少一個(gè)校驗(yàn)節(jié)點(diǎn)；在所述步驟B中，所述發(fā)送端將所述數(shù)據(jù)節(jié)點(diǎn)和所述校驗(yàn)節(jié)點(diǎn)分組封裝在至少一個(gè)所述錯(cuò)誤彈性實(shí)時(shí)傳送協(xié)議包中進(jìn)行發(fā)送；在所述步驟C中，所述接收端在接收到所述錯(cuò)誤彈性實(shí)時(shí)傳送協(xié)議包后，去封裝得到所述數(shù)據(jù)節(jié)點(diǎn)和所述校驗(yàn)節(jié)點(diǎn)；在所述步驟D中，如果發(fā)生了傳送過程中的數(shù)據(jù)節(jié)點(diǎn)丟失，則所述接收端根據(jù)所述校驗(yàn)節(jié)點(diǎn)對(duì)所述丟失數(shù)據(jù)節(jié)點(diǎn)進(jìn)行基于前向糾錯(cuò)解碼的恢復(fù)或者部分恢復(fù)，并劃分得到所述H.264網(wǎng)絡(luò)抽象層單元。
此外在所述方法中，在開始傳送之前，還包含步驟，所述發(fā)送端和所述接收端協(xié)商確定對(duì)于各種所述前向糾錯(cuò)碼類型，所述錯(cuò)誤前向糾錯(cuò)碼子類型字段的取值與其所指示的該種前向糾錯(cuò)碼的相關(guān)參數(shù)設(shè)置的對(duì)應(yīng)關(guān)系。
此外在所述方法中，所述發(fā)送端和所述接收端都根據(jù)所述前向糾錯(cuò)編碼子類型字段的指示對(duì)應(yīng)關(guān)系建立對(duì)應(yīng)關(guān)系表，用于根據(jù)所述前向糾錯(cuò)編碼類型字段和所述前向糾錯(cuò)編碼子類型字段查詢所對(duì)應(yīng)的前向糾錯(cuò)編碼或前向糾錯(cuò)解碼處理模塊；在所述步驟A中，所述發(fā)送端調(diào)用相應(yīng)前向糾錯(cuò)編碼處理模塊進(jìn)行前向糾錯(cuò)編碼；在所述步驟D中，所述接收端調(diào)用相應(yīng)前向糾錯(cuò)解碼處理模塊進(jìn)行前向糾錯(cuò)解碼。
此外在所述方法中，當(dāng)所述多媒體數(shù)據(jù)為所述H.264網(wǎng)絡(luò)抽象層單元時(shí)，在所述步驟A中，所述發(fā)送端根據(jù)所述H.264網(wǎng)絡(luò)抽象層單元的頭信息中的網(wǎng)絡(luò)抽象層參考標(biāo)識(shí)字段和網(wǎng)絡(luò)抽象層單元類型字段中的任意一者或兩者來評(píng)估對(duì)應(yīng)數(shù)據(jù)的相對(duì)重要性，從而確定所述服務(wù)質(zhì)量等級(jí)，進(jìn)而選擇所述前向糾錯(cuò)編碼方案，確定所述前向糾錯(cuò)編碼類型字段和前向糾錯(cuò)編碼子類型字段。
此外在所述方法中，在所述步驟A中，所述發(fā)送端根據(jù)所述接收端反饋的傳送報(bào)告評(píng)價(jià)所述網(wǎng)絡(luò)傳送狀況，進(jìn)而選擇所述前向糾錯(cuò)編碼方案，確定所述前向糾錯(cuò)編碼類型字段和前向糾錯(cuò)編碼子類型字段。
此外在所述方法中，所述錯(cuò)誤彈性實(shí)時(shí)傳送協(xié)議包頭信息中的版本信息字段取值為二進(jìn)制11(十進(jìn)制3)，以區(qū)別于實(shí)時(shí)傳送協(xié)議；所述前向糾錯(cuò)編碼類型字段位于貢獻(xiàn)源標(biāo)識(shí)符列表之后，占4比特；所述前向糾錯(cuò)編碼子類型字段位于所述前向糾錯(cuò)編碼類型字段之后，占9比特；所述數(shù)據(jù)包長(zhǎng)度字段位于所述前向糾錯(cuò)編碼子類型字段之后，占11比特；所述數(shù)據(jù)包數(shù)目字段位于所述數(shù)據(jù)包長(zhǎng)度字段之后，占8比特。
此外在所述方法中，所述前向糾錯(cuò)編碼方案包含改進(jìn)的“Tornado”糾刪碼；所述改進(jìn)的“Tornado”糾刪碼對(duì)于一組所述數(shù)據(jù)節(jié)點(diǎn)僅生成一層所述校驗(yàn)節(jié)點(diǎn)。
通過比較可以發(fā)現(xiàn)，本發(fā)明的技術(shù)方案與現(xiàn)有技術(shù)的主要區(qū)別在于，首先本發(fā)明在現(xiàn)有RTP基礎(chǔ)上提供了可以攜帶前向糾錯(cuò)編碼方案相關(guān)信息的ERRTP傳送層封裝格式，使得多媒體數(shù)據(jù)在ERRTP上傳送的同時(shí)標(biāo)記其相應(yīng)的前向糾錯(cuò)編碼方案信息，從而將錯(cuò)誤彈性機(jī)制融入傳送層；其次在發(fā)送端還可以根據(jù)當(dāng)前網(wǎng)絡(luò)狀況和多媒體數(shù)據(jù)重要性等級(jí)等因素來選擇采用各種備用的前向糾錯(cuò)編碼方案，從而達(dá)到不等保護(hù)的和分級(jí)保護(hù)的目的，實(shí)現(xiàn)保護(hù)能力和傳送效率的均衡；最后對(duì)于H.264的NALU的糾刪碼保護(hù)方案，給出了數(shù)據(jù)節(jié)點(diǎn)和校驗(yàn)節(jié)點(diǎn)的生成、傳送、封裝和去封裝方法。
這種技術(shù)方案上的區(qū)別，帶來了較為明顯的有益效果，即在傳送層實(shí)現(xiàn)錯(cuò)誤彈性機(jī)制大大簡(jiǎn)化錯(cuò)誤彈性傳送結(jié)構(gòu)，節(jié)省了網(wǎng)絡(luò)傳送帶寬；不等保護(hù)的實(shí)現(xiàn)，達(dá)到了保護(hù)能力和傳送效率的均衡，方便于多媒體傳送的QoS保證的實(shí)現(xiàn)；H.264數(shù)據(jù)的具體傳送方案的實(shí)現(xiàn)，可以大大提高基于H.264的多媒體通信產(chǎn)品比如會(huì)議電視、可視電話在IP網(wǎng)絡(luò)上應(yīng)用的性能和用戶體驗(yàn)，提高產(chǎn)品競(jìng)爭(zhēng)力，帶來顯著的經(jīng)濟(jì)效益。


圖1是RTP數(shù)據(jù)包的頭信息結(jié)構(gòu)示意圖；圖2是RTP包凈荷對(duì)NALU數(shù)據(jù)的封裝格式示意圖；圖3是Tornado糾刪碼原理示意圖；圖4是根據(jù)本發(fā)明的第一實(shí)施方式的EERTP包頭信息結(jié)構(gòu)示意圖；圖5是根據(jù)本發(fā)明的第二實(shí)施方式的H.264多媒體數(shù)據(jù)傳送方法流程圖；圖6是根據(jù)本發(fā)明的第二實(shí)施方式的H.264NALU劃分編解碼過程示意圖。
具體實(shí)施例方式
為使本發(fā)明的目的、技術(shù)方案和優(yōu)點(diǎn)更加清楚，下面將結(jié)合附圖對(duì)本發(fā)明作進(jìn)一步地詳細(xì)描述。
針對(duì)現(xiàn)有技術(shù)存在的諸多問題，本發(fā)明提出一種改進(jìn)的支持錯(cuò)誤彈性的RTP協(xié)議，旨在將錯(cuò)誤彈性機(jī)制融入傳送層協(xié)議，不但可以簡(jiǎn)化傳送結(jié)構(gòu)降低復(fù)雜度，而且還能提高錯(cuò)誤彈性機(jī)制靈活性增強(qiáng)傳送可靠性。由于具有錯(cuò)誤彈性，本發(fā)明稱這種改進(jìn)的RTP協(xié)議為錯(cuò)誤彈性實(shí)時(shí)傳送協(xié)議(ErrorResilience Real-time Transport Protocol，簡(jiǎn)稱“ERRTP”或者“ER2TP”)。ERRTP與RTP的主要區(qū)別在于ERRTP協(xié)議數(shù)據(jù)包頭信息擴(kuò)展可以攜帶前向糾錯(cuò)編解碼方案相關(guān)信息，比如FEC類型、保護(hù)能力、編碼參數(shù)等。
在ERRTP基礎(chǔ)上，本發(fā)明很方便地實(shí)現(xiàn)了不等保護(hù)，首先提供多種保護(hù)能力不同的保護(hù)措施可供選擇使用，然后發(fā)送端在收集得到網(wǎng)絡(luò)狀況和多媒體數(shù)據(jù)重要性等信息后，可以根據(jù)這些因素來選擇合適的保護(hù)措施，從而達(dá)到不等保護(hù)的目的，實(shí)現(xiàn)保護(hù)能力和傳送效率的均衡。由于在每個(gè)ERRTP數(shù)據(jù)包上都攜帶了其所采用的FEC相關(guān)信息，因此發(fā)送端只需將所選擇的方案的信息填入ERRTP包頭信息中，接收端就能根據(jù)其進(jìn)行正確恢復(fù)或糾錯(cuò)。
最后對(duì)于H.264的NALU數(shù)據(jù)傳送應(yīng)用，給出了基于糾刪碼保護(hù)的具體實(shí)現(xiàn)方法，包括劃分、生成、封裝和去封裝數(shù)據(jù)節(jié)點(diǎn)和校驗(yàn)節(jié)點(diǎn)的步驟。將連續(xù)一串NALU一起等長(zhǎng)地劃分為若干個(gè)數(shù)據(jù)節(jié)點(diǎn)，然后用Tornado碼產(chǎn)生校驗(yàn)節(jié)點(diǎn)，所有這些節(jié)點(diǎn)又分布在若干個(gè)ERRTP包中傳送，接收端則進(jìn)行這個(gè)逆過程。
本發(fā)明的第一實(shí)施例中，收發(fā)雙方基于ERRTP實(shí)現(xiàn)不等保護(hù)，主要步驟如下所述發(fā)送端選擇前向糾錯(cuò)編碼方案對(duì)多媒體數(shù)據(jù)進(jìn)行糾刪編碼，用ERRTP封裝編碼后的多媒體數(shù)據(jù)，并在ERRTP包頭信息中攜帶前向糾錯(cuò)編碼方案相關(guān)信息，然后發(fā)送到接收端；接收端將收到的ERRTP包去封裝，并從ERRTP包頭信息中提取前向糾錯(cuò)編碼方案相關(guān)信息，然后根據(jù)前向糾錯(cuò)編碼方案相關(guān)信息，選擇前向糾錯(cuò)編碼方案進(jìn)行糾刪解碼，獲得多媒體數(shù)據(jù)。
其中，不等保護(hù)體現(xiàn)在發(fā)送端是根據(jù)當(dāng)前網(wǎng)絡(luò)傳送狀況和/或待發(fā)送多媒體數(shù)據(jù)的服務(wù)質(zhì)量等級(jí)來選擇前向糾錯(cuò)編碼方案的。
首先介紹ERRTP的具體結(jié)構(gòu)，下面給出具體ERRTP的頭信息結(jié)構(gòu)實(shí)施例。圖4是根據(jù)本發(fā)明的第一實(shí)施例的ERRTP頭信息結(jié)構(gòu)示意圖。從圖中可以看出，版本信息字段V取值為3，表示ERRTP協(xié)議，以區(qū)別于傳統(tǒng)的RTP協(xié)議(V＝2)。其中在頭信息擴(kuò)展也就是最后附有關(guān)于前向糾錯(cuò)編解碼方案的相關(guān)信息字段，此例中包括前向糾錯(cuò)編碼類型字段、前向糾錯(cuò)編碼參數(shù)字段、數(shù)據(jù)包長(zhǎng)度字段、數(shù)據(jù)包數(shù)目字段。
前向糾錯(cuò)編碼類型字段，用于指示前向糾錯(cuò)編碼方案采用的糾刪碼類型，也可以稱為FEC Type字段，即指示FEC編碼類型，占4比特，可以表示16種不同的FEC類型，從實(shí)際應(yīng)用中，是足夠的。這里定義的類型其實(shí)是大的類型，后面還將繼續(xù)細(xì)分為各種不同的方案，稱為子類型，實(shí)際應(yīng)用中的大類型例如0010表示Tornado碼，0011表示RS碼等。該字段可標(biāo)識(shí)16種不同的FEC碼大類型，通信雙方需要事先約定一個(gè)FEC編碼類型和編碼類型代號(hào)之間對(duì)應(yīng)關(guān)系的查表(Look-Up Table，簡(jiǎn)稱“LUT”)稱為FECTypeLUT。
前向糾錯(cuò)編碼子類型字段，用于指示前向糾錯(cuò)編碼方案的相關(guān)參數(shù)設(shè)置，對(duì)于每種類型的FEC編碼還需要確定各種參數(shù)的設(shè)置才能具體實(shí)施，這個(gè)字段就是起到明確具體參數(shù)的作用。由于ERRTP頭信息中資源有限，不可能把各種FEC編碼方案所對(duì)應(yīng)的具體參數(shù)及其規(guī)則等一一羅列，本發(fā)明的第一實(shí)施例通過用子類型的概念來指示各種備選的參數(shù)設(shè)置方案。該字段也稱為FEC編碼子類型字段，F(xiàn)EC Subtype，占9比特。該域主要表示在FECTypeLUT中定義的各大類型下面進(jìn)一步細(xì)分的子類型。
數(shù)據(jù)包長(zhǎng)度字段，用于指示前向糾錯(cuò)編碼方案在對(duì)多媒體數(shù)據(jù)進(jìn)行糾刪編碼后的數(shù)據(jù)節(jié)點(diǎn)長(zhǎng)度，稱為Data Length字段，占11比特。由于每個(gè)數(shù)據(jù)包長(zhǎng)度應(yīng)小于網(wǎng)絡(luò)傳送最大傳送單元(Maximum Transport Unit，簡(jiǎn)稱“MTU”)，而目前有線信道MTU＜1500＝0×5DC字節(jié)，無線信道MTU＜100字節(jié)，因此該字段11個(gè)比特足以存放數(shù)據(jù)包的長(zhǎng)度。
數(shù)據(jù)包數(shù)目字段，用于指示該ERRTP包所承載的數(shù)據(jù)節(jié)點(diǎn)的數(shù)目，又稱為Packet Number字段，占8比特，比如對(duì)于若干個(gè)NALU經(jīng)過前向糾錯(cuò)碼校驗(yàn)后，分組封裝在多個(gè)ERRTP中，每個(gè)ERRTP中所承載的數(shù)據(jù)節(jié)點(diǎn)數(shù)。
可見有了這些字段之后，解碼端或網(wǎng)絡(luò)節(jié)點(diǎn)可以根據(jù)該字段給出的FEC碼類型和數(shù)據(jù)包的校驗(yàn)類型對(duì)接收到的數(shù)據(jù)包進(jìn)行校驗(yàn)，并恢復(fù)丟失的數(shù)據(jù)包。
值得注意的是，上面提到的子類型FEC Subtype字段共9個(gè)比特是用來編碼指示各種備選的參數(shù)設(shè)置方案的，下面就給出本發(fā)明的第一實(shí)施例中如何進(jìn)行編碼指示的技術(shù)細(xì)節(jié)。
首先收發(fā)雙方需要協(xié)商確定該字段指示關(guān)系對(duì)應(yīng)表。在開始傳送之前，發(fā)送端和接收端協(xié)商確定對(duì)于各種FEC碼大類型，F(xiàn)EC Subtype的取值與其所指示的該種FEC碼的相關(guān)參數(shù)設(shè)置方案的對(duì)應(yīng)關(guān)系，及各種備選方案的具體參數(shù)設(shè)置情況。
然后，發(fā)送端和接收端都根據(jù)協(xié)商結(jié)果建立對(duì)應(yīng)關(guān)系表，用于根據(jù)FECType和FEC Subtype字段來查詢所對(duì)應(yīng)的FEC編碼類型或FEC編解碼處理模塊；在收發(fā)過程中，發(fā)送端調(diào)用相應(yīng)糾刪編碼處理模塊進(jìn)行糾刪編碼，接收端調(diào)用相應(yīng)糾刪解碼處理模塊進(jìn)行糾刪解碼。
在實(shí)際應(yīng)用中，子類型的信息實(shí)際上指示兩個(gè)方面A.FEC編碼的生成規(guī)則(Generation Rule)；B.保護(hù)強(qiáng)度/保護(hù)能力。
所謂生成規(guī)則就是在發(fā)送端如何將數(shù)據(jù)節(jié)點(diǎn)進(jìn)行處理生成各個(gè)校驗(yàn)節(jié)點(diǎn)的規(guī)則或者算法(Algorithm)。當(dāng)然在接收端所做的正好相反，如果在傳送過程中發(fā)生了丟包，即某些節(jié)點(diǎn)丟失了，那么根據(jù)生成規(guī)則可以恢復(fù)或者部分恢復(fù)丟失的節(jié)點(diǎn)?？梢娚梢?guī)則是很重要的信息，根據(jù)它，通信的雙方就可以基于FEC機(jī)制來工作了。在FECTypeLUT中列出的FEC類型中的每一類，都有不同的生成規(guī)則；而在每一類中，比如Tornado碼，下面的子類的生成規(guī)則還要結(jié)合具體的生成參數(shù)(generation parameters)。因此具體到這里的每個(gè)子類，聲稱規(guī)則將和生成參數(shù)結(jié)合起來。
比如對(duì)于Tornado碼，生成參數(shù)包括如下數(shù)據(jù)數(shù)據(jù)節(jié)點(diǎn)總數(shù)、校驗(yàn)節(jié)點(diǎn)總數(shù)、校驗(yàn)節(jié)點(diǎn)層數(shù)、相繼兩層之間節(jié)電數(shù)目的遞縮比例、表示相繼兩層之間節(jié)點(diǎn)關(guān)聯(lián)關(guān)系的關(guān)聯(lián)矩陣，如果有L層校驗(yàn)節(jié)點(diǎn)，那么這樣的關(guān)聯(lián)矩陣就有L個(gè)、或者等效的表示相繼兩層節(jié)點(diǎn)關(guān)聯(lián)關(guān)系的二部圖(Bipartite)的參數(shù)化數(shù)學(xué)表示(parametric mathematical representation)。
一般來說，在大的生成規(guī)則相同的前提下，生成參數(shù)往往決定子類型的保護(hù)強(qiáng)度。比如Tornado碼，在上面給出的各項(xiàng)生成參數(shù)中，數(shù)據(jù)節(jié)點(diǎn)總數(shù)和檢驗(yàn)節(jié)點(diǎn)總數(shù)基本上能夠在很大程度上決定保護(hù)能力(當(dāng)然嚴(yán)格來說，要完全決定保護(hù)能力，需要全部的生成參數(shù))。在本發(fā)明中，對(duì)于每個(gè)FEC大類型，選擇一些決定保護(hù)能力的主要參數(shù)(決定作用最大)作為代表性生成參數(shù)(representative generation parameters)。通過使用代表性生成參數(shù)，就可以把大類下面的子類按照保護(hù)能力從弱到強(qiáng)的順序(升序)排列起來。從而建立一個(gè)LUT叫做FECSubTypeLUT。
每個(gè)大類型下面具體支持多個(gè)子類型，可以有具體的應(yīng)用和通信雙方的通信能力(CPU處理速度、內(nèi)存、程序復(fù)雜度等因素)和需要決定。如果通信環(huán)境變化很大，網(wǎng)絡(luò)的性能波動(dòng)范圍很大，那么需要支持的子類型一般來說要多，相反可以較少。這個(gè)完全可以在通信開始前通過能力協(xié)商過程，由通信雙方來達(dá)成一致的約定。協(xié)商可以通過H.323或會(huì)話初始協(xié)議(SessionInitial Protocol，簡(jiǎn)稱“SIP”)等目前主流的多媒體通信框架協(xié)議進(jìn)行。
假定針對(duì)某個(gè)大類下面的子類，如果需要區(qū)分S個(gè)子類型(S≤29-1)，代表性生成參數(shù)有k個(gè)，用p1，p2，...，pk表示，那么表2給出一個(gè)對(duì)應(yīng)關(guān)系的例子，表中上標(biāo)表示FEC大類型，下標(biāo)表示具體哪個(gè)參數(shù)。
表2 FEC Subtype和參數(shù)設(shè)置方案對(duì)應(yīng)關(guān)系表

比如，對(duì)于Tornado碼，可以設(shè)置對(duì)應(yīng)關(guān)系是000000010-(24，20)(數(shù)據(jù)節(jié)點(diǎn)總數(shù)＝20，校驗(yàn)節(jié)點(diǎn)總數(shù)＝4)，000000011-(30，20)，...，111111111-其它。
針對(duì)某種特性的FEC編碼的子類型，一組給定的生成規(guī)則結(jié)合相應(yīng)的生成參數(shù)對(duì)應(yīng)唯一的一個(gè)編碼方案，即唯一決定了如何由數(shù)據(jù)節(jié)點(diǎn)生成校驗(yàn)節(jié)點(diǎn)，以及如何恢復(fù)丟失的節(jié)點(diǎn)。可以建立一個(gè)數(shù)據(jù)庫(kù)，來存儲(chǔ)每種大類型和子類型對(duì)應(yīng)的生成參數(shù)。而生成規(guī)則本身用硬件或者軟件模塊來實(shí)現(xiàn)。因此，每種大類型在發(fā)送端對(duì)應(yīng)一個(gè)FEC處理模塊，負(fù)責(zé)生成校驗(yàn)節(jié)點(diǎn)；在接收端同樣對(duì)應(yīng)一個(gè)FEC處理模塊，負(fù)責(zé)恢復(fù)節(jié)點(diǎn)。但是，對(duì)應(yīng)每種大類型的模塊，需要從上述生成參數(shù)數(shù)據(jù)庫(kù)中讀取具體的每種子類型的生成參數(shù)，從而來進(jìn)行處理。因此，通行雙方都是根據(jù)FEC Type和FEC Subtype兩個(gè)信息域的信息來決定調(diào)用哪個(gè)FEC處理模塊和讀取那些生成參數(shù)。
由于目前多媒體通信技術(shù)的發(fā)展，H.264視頻編碼標(biāo)準(zhǔn)已逐漸成為主流媒體編碼格式，因此本發(fā)明的第二實(shí)施例在第一實(shí)施例的基礎(chǔ)上，給出了用ERRTP對(duì)H.264的NALU數(shù)據(jù)流進(jìn)行FEC編解碼的具體步驟，其流程如圖5所示。
在步驟501中，發(fā)送端將多個(gè)(假設(shè)為S個(gè))H.264NALU合并為一組統(tǒng)一進(jìn)行編碼傳送，先把S個(gè)NALU重新劃分為等長(zhǎng)的塊，假設(shè)為M個(gè)，這M個(gè)就是數(shù)據(jù)節(jié)點(diǎn)。
在該步中，將H.264的S個(gè)NALU分為一組；然后將S個(gè)NALU首尾相接(concatenated)，連接形成一個(gè)大塊，然后將該大塊等分為M個(gè)數(shù)據(jù)塊，其中每個(gè)數(shù)據(jù)塊的長(zhǎng)度為K個(gè)字節(jié)。這里如果該大塊的總的字節(jié)數(shù)(設(shè)為TB)不能被M整除，那么應(yīng)該進(jìn)行取整運(yùn)算，使得每個(gè)數(shù)據(jù)塊的長(zhǎng)度為Ceiling(TB/M)字節(jié)，Ceiling函數(shù)表示取整，即Ceiling(x)等于不小于x的最小整數(shù)，x為任意實(shí)數(shù)。那么在某些數(shù)據(jù)塊中的后面可能要采用填充零串(zeropadding)的操作，使得字節(jié)數(shù)湊齊到Ceiling(TB/M))。
接著在步驟502中，對(duì)M個(gè)數(shù)據(jù)節(jié)點(diǎn)其進(jìn)行FEC編碼，得到N個(gè)校驗(yàn)節(jié)點(diǎn)。對(duì)M個(gè)數(shù)據(jù)塊使用FEC碼編碼生成N個(gè)校驗(yàn)塊，生成過程采用前面描述過的方法，根據(jù)FEC Type和FEC Subtype信息，確定調(diào)用具體哪個(gè)FEC處理模塊進(jìn)行校驗(yàn)塊的生成。
然后在步驟503中，發(fā)送端將所有數(shù)據(jù)節(jié)點(diǎn)和校驗(yàn)節(jié)點(diǎn)分組封裝在ERRTP包中進(jìn)行發(fā)送。圖6示出了P個(gè)ERRTP包裝載M+N個(gè)數(shù)據(jù)節(jié)點(diǎn)的結(jié)構(gòu)。結(jié)合圖4給出的ERRTP的頭信息格式，在此例中各個(gè)字段應(yīng)該按如下設(shè)置
類型字段FEC Type＝0010，表示使用Tornado碼；子類型字段則由發(fā)送端具體根據(jù)實(shí)際情況選擇，比如取值為FECSubtype＝000000010，表示使用Tornado(24，20)碼，其中數(shù)據(jù)節(jié)點(diǎn)20個(gè)，校驗(yàn)節(jié)點(diǎn)4個(gè)，信道編碼冗余度為16.7％；該糾刪碼在丟包率小于等于3％時(shí)，可以完全恢復(fù)丟失的數(shù)據(jù)包；數(shù)據(jù)包長(zhǎng)度Data-Length＝K Bytes；數(shù)據(jù)包數(shù)目Packet Number＝(M+N)/P，表示一個(gè)ERRTP載荷中承載的數(shù)據(jù)節(jié)點(diǎn)個(gè)數(shù)。
在步驟504中，接收端在接收到這些ERRTP包后，去封裝得到數(shù)據(jù)節(jié)點(diǎn)和校驗(yàn)節(jié)點(diǎn)。接收端以P個(gè)數(shù)據(jù)包為周期，每接收到一組P個(gè)數(shù)據(jù)包就開始進(jìn)行一次解碼恢復(fù)。一組多少個(gè)數(shù)據(jù)包由雙方協(xié)商確定。
在步驟505中，接收端根據(jù)校驗(yàn)節(jié)點(diǎn)對(duì)數(shù)據(jù)節(jié)點(diǎn)進(jìn)行前向糾錯(cuò)解碼。每次在收到數(shù)據(jù)包P+1后開始檢測(cè)前面收到的P個(gè)數(shù)據(jù)包中是否有數(shù)據(jù)包丟失，如果有就采用前面描述的方法，根據(jù)FEC Type和FEC Subtype信息，確定調(diào)用具體哪個(gè)FEC處理模塊進(jìn)行解碼和恢復(fù)或者部分丟失的數(shù)據(jù)。
最后在步驟506中，最后在得到完整的數(shù)據(jù)節(jié)點(diǎn)后，重新合并就得到一個(gè)大塊，采用與發(fā)送端相同的方式，劃分得到S個(gè)NALU。
在實(shí)際應(yīng)用中發(fā)現(xiàn)，上例采用基于ERRTP的抗數(shù)據(jù)包丟失算法，可以在增加不到17％碼字的情況下，大大提高視頻碼流的抗數(shù)據(jù)包丟失能力。而與RTP載荷頭結(jié)構(gòu)相比，僅僅增加了4字節(jié)，可見對(duì)傳送效率基本沒有影響，取得了顯著的實(shí)際效果。
在前面已經(jīng)提到關(guān)于本發(fā)明的另外一個(gè)關(guān)鍵技術(shù)點(diǎn)就是不等保護(hù)的實(shí)現(xiàn)。主要體現(xiàn)在兩個(gè)方面，一個(gè)是根據(jù)不同重要等級(jí)的多媒體數(shù)據(jù)來選擇合適的編解碼方案或者參數(shù)，即確定前述FEC編碼類型與子類型，另一個(gè)就是根據(jù)不同時(shí)刻的網(wǎng)絡(luò)狀況來選擇。對(duì)應(yīng)這兩個(gè)方面，分別稱為混合和交替使用各種FEC編碼方案。所謂混合(Hybrid)，是指在同一時(shí)間內(nèi)同時(shí)使用多種FEC子類型，主要用于保護(hù)不同重要性的數(shù)據(jù)；而所謂交替(Alternation)，是指在不同時(shí)間(不同的網(wǎng)絡(luò)狀況下)使用不同的FEC子類型。
因此在本發(fā)明的第三實(shí)施例中，基于第一實(shí)施例給出這兩種不等保護(hù)機(jī)制。對(duì)于H.264NALU數(shù)據(jù)流，前面提到，其頭字節(jié)體現(xiàn)了數(shù)據(jù)的重要程度，因此發(fā)送端根據(jù)NALU的頭信息中的NRI字段或Type字段可以評(píng)估QoS等級(jí)，進(jìn)而選擇前向糾錯(cuò)編碼方案，即確定FEC Type字段和FEC Subtype字段。而對(duì)于網(wǎng)絡(luò)狀況，一般的網(wǎng)絡(luò)傳送都有相應(yīng)的網(wǎng)絡(luò)狀況監(jiān)測(cè)機(jī)制，發(fā)送端可以根據(jù)這些機(jī)制獲知接收端反饋的傳送報(bào)告，以此評(píng)價(jià)網(wǎng)絡(luò)傳送狀況，進(jìn)而選擇前向糾錯(cuò)編碼方案，即確定FEC Type字段和FEC Subtype字段。
H.264碼流是基于NALU進(jìn)行傳送或存儲(chǔ)，NALU由NAL頭信息和NAL載荷組成。在H.264的NALU中，不同NALU類型對(duì)解碼恢復(fù)圖像的影響不同。例如，NRI取0表示NALU中存放非參考圖象的一個(gè)Slice或Slice數(shù)據(jù)條帶，不會(huì)影響后續(xù)解碼；而NRI取非0表明NALU中存放一個(gè)序列/圖像參數(shù)集或者是參考圖像的一個(gè)Slice或Slice數(shù)據(jù)條帶，會(huì)嚴(yán)重影響后續(xù)解碼。
因此，在對(duì)H.264的碼流進(jìn)行數(shù)據(jù)包保護(hù)時(shí)，可以根據(jù)NRI或Nal_unit_type的取值將H.264的數(shù)據(jù)分為兩類一類為相對(duì)重要的圖像數(shù)據(jù)(例如Nal_ref_idc等于1)；另一類為次要的圖像數(shù)據(jù)(例如Nal_ref_idc等于0)。然后，對(duì)重要的圖像數(shù)據(jù)使用冗余度較大、抗丟包能力強(qiáng)的FEC1碼進(jìn)行保護(hù)；而次要的圖像數(shù)據(jù)可以使用冗余度較小、抗丟包能力較弱的FEC2碼進(jìn)行保護(hù)。
通過這種不等保護(hù)算法，保證了各類重要信息在高數(shù)據(jù)包丟失環(huán)境下的正確恢復(fù)，而對(duì)FEC2碼仍然未能恢復(fù)的圖像信息采用誤碼掩蓋和防止誤碼擴(kuò)散等技術(shù)。FEC1，F(xiàn)EC2這里只是一般的表示方法，表示任意兩種子類型。這兩種子類型可以屬于同一大類型，也可以屬于不同大類型。
很顯然，上述方法可以推廣到更加一般的情形，把數(shù)據(jù)按照NAL_unit-type的取值分成更多類，比如五類最重要數(shù)據(jù)、次重要數(shù)據(jù)、一般重要數(shù)據(jù)、較不重要數(shù)據(jù)、最不重要數(shù)據(jù)；也可以分成7類或者更多，那么，可以用相同數(shù)量的FEC子類型來保護(hù)，每類數(shù)據(jù)對(duì)應(yīng)一種不同的子類型。只要保護(hù)能力從弱到強(qiáng)就可以了，這些子類型不一定屬于同一個(gè)大類型。而對(duì)保護(hù)能力最強(qiáng)的FEC碼保護(hù)后仍然未能恢復(fù)的圖像信息采用誤碼掩蓋和防止誤碼擴(kuò)散等技術(shù)。
不等保護(hù)的另外一種情況也在本發(fā)明范圍內(nèi)，就是可以根據(jù)網(wǎng)絡(luò)實(shí)時(shí)狀況選擇不同保護(hù)能力的的FEC。然后通過ERRTP的頭信息來通知通信的雙方，使得它們能夠正確對(duì)數(shù)據(jù)進(jìn)行解碼和恢復(fù)丟失的數(shù)據(jù)?？梢园丫W(wǎng)絡(luò)當(dāng)前受到影響傳送性能下降的情況分成幾個(gè)級(jí)別。比如五級(jí)最嚴(yán)重、次嚴(yán)重、一般嚴(yán)重、較不嚴(yán)重、最不嚴(yán)重；也可以分成7級(jí)或者更多，那么，可以用相同數(shù)量的FEC子類型來保護(hù)，每級(jí)對(duì)應(yīng)一種不同的子類型。只要保護(hù)能力從弱到強(qiáng)就可以了，這些子類型不一定屬于同一個(gè)大類型。而對(duì)保護(hù)能力最強(qiáng)的FEC碼保護(hù)后仍然未能恢復(fù)的圖像信息采用誤碼掩蓋和防止誤碼擴(kuò)散等技術(shù)。感知網(wǎng)絡(luò)狀況可以通過現(xiàn)有的各種QoS監(jiān)測(cè)方法實(shí)現(xiàn)。
更為復(fù)雜的應(yīng)用方案也在本發(fā)明范圍內(nèi)，如果總共有T種FEC方案(不同類型/子類型)可以使用(通信雙方終端都支持)。決定采用哪種FEC，要同時(shí)取決于數(shù)據(jù)重要性和網(wǎng)絡(luò)的狀況。那么可以采用一個(gè)二維LUT的方法，如表3所示表3 多種FEC機(jī)制混合和交替使用的二維LUT
圖5示出了在該實(shí)施例中Node B高層軟件建立傳輸承載的信令交互過程，與上述實(shí)施例相比，主要區(qū)別在于IP資源分配由IP資源管理模塊實(shí)現(xiàn)的，即IP資源管理模塊收到NBAP模塊的TP Bear Setup request消息后，檢查傳輸資源可用狀態(tài)，并分配傳輸資源，然后直接建立內(nèi)、外部傳輸通道，其他過程與上述實(shí)施例相同，不再贅述。
在本實(shí)施例中，NBAP模塊向IP資源管理模塊發(fā)送的TP Bear Setup request消息的格式如下表所示，字段含義與第一實(shí)施例中的相應(yīng)字段相同，不再贅述

IP資源管理模塊向NBAP返回的TP Bear Setup Response消息的格式如下表所示，字段含義與第一實(shí)施例中的相應(yīng)字段相同，不再贅述

<p>Ttotal＝TFEC+Tcodec+Ttrans(2)該式中TFEC是加入FEC保護(hù)后引入的時(shí)延，Tcodec和Ttrans分別是H.264編解碼器處理時(shí)延和網(wǎng)絡(luò)傳送時(shí)延。由于數(shù)字信號(hào)處理技術(shù)和IP網(wǎng)絡(luò)的迅速發(fā)展，可以假定Tcodec和Ttrans都能夠滿足實(shí)時(shí)性要求Tcodec＜＝Tth，Ttrans＜＝Tth，其中Tth＝1/Ftarget(3)式(3)中Ftarget是解碼目標(biāo)幀率(可取值10Hz，30Hz等)，且設(shè)一幀圖像劃分為一個(gè)Slice，這時(shí)式(2)可改為Ttotal＜＝S*Tth+2*Tth＝(S+2)*Tth(4)由式(4)和式(1)可知，一幀圖像的延時(shí)Ttotal的延時(shí)基本由S的取值確定，而DataNode又大大影響S的取值。因此，要在能夠保證視頻通信抗數(shù)據(jù)包丟失能力的前提下，盡量減少FEC引入的時(shí)延，進(jìn)一步保證實(shí)時(shí)視頻通信的QoS。
本發(fā)明在DataNode受限的情況下，采用改進(jìn)的Tornado碼保護(hù)算法。該改進(jìn)的Tornado方法，不采用多級(jí)偶圖的編碼方式，而是只使用一層校驗(yàn)節(jié)點(diǎn)的編碼方式。與原來的Tornado編碼方式相比，改進(jìn)后的編碼方法大大提高了算法的靈活性，數(shù)據(jù)節(jié)點(diǎn)和校驗(yàn)節(jié)點(diǎn)的個(gè)數(shù)可以任意設(shè)置，也降低了編解碼算法的復(fù)雜度，可用于實(shí)時(shí)視頻通信的抗數(shù)據(jù)包丟失。另外，在數(shù)據(jù)節(jié)點(diǎn)受限的情況下，改進(jìn)Tornado碼的抗數(shù)據(jù)包丟失性能基本沒有下降。該改進(jìn)的Tornado編碼方法具體原理及詳細(xì)步驟，參考中國(guó)專利《一種基于糾刪碼的數(shù)據(jù)傳送保護(hù)方法》，受理號(hào)為200510066146.7。
熟悉本領(lǐng)域的技術(shù)人員可以理解，上述實(shí)施例中所給出的具體參數(shù)設(shè)置和數(shù)值以及其他實(shí)現(xiàn)細(xì)節(jié)舉例，在具體應(yīng)用中可以采用其他可行值或者方案，實(shí)現(xiàn)本發(fā)明目的而不影響實(shí)質(zhì)和范圍。
權(quán)利要求
1.一種支持錯(cuò)誤彈性的多媒體數(shù)據(jù)網(wǎng)絡(luò)實(shí)時(shí)傳送方法，其特征在于，包含以下步驟A發(fā)送端選擇前向糾錯(cuò)編碼方案對(duì)所述多媒體數(shù)據(jù)進(jìn)行前向糾錯(cuò)編碼；B所述發(fā)送端用錯(cuò)誤彈性實(shí)時(shí)傳送協(xié)議封裝編碼后的多媒體數(shù)據(jù)，并在所述錯(cuò)誤彈性實(shí)時(shí)傳送協(xié)議包頭信息中攜帶所述前向糾錯(cuò)編碼方案相關(guān)信息，然后發(fā)送到接收端；C所述接收端將收到的錯(cuò)誤彈性實(shí)時(shí)傳送協(xié)議包去封裝，并從所述錯(cuò)誤彈性實(shí)時(shí)傳送協(xié)議包頭信息中提取所述前向糾錯(cuò)編碼方案相關(guān)信息；D如果在傳送過程中發(fā)生了數(shù)據(jù)節(jié)點(diǎn)對(duì)應(yīng)的錯(cuò)誤彈性實(shí)時(shí)傳送協(xié)議包的丟失，那么所述接收端根據(jù)所述前向糾錯(cuò)編碼方案相關(guān)信息，選擇所述前向糾錯(cuò)解碼方案進(jìn)行前向糾錯(cuò)解碼，恢復(fù)或者部分恢復(fù)所述丟失的多媒體數(shù)據(jù)。
2.根據(jù)權(quán)利要求1所述的支持錯(cuò)誤彈性的多媒體數(shù)據(jù)網(wǎng)絡(luò)實(shí)時(shí)傳送方法，其特征在于，所述前向糾錯(cuò)編碼后的多媒體數(shù)據(jù)分為數(shù)據(jù)節(jié)點(diǎn)和校驗(yàn)節(jié)點(diǎn)兩類。
3.根據(jù)權(quán)利要求2所述的支持錯(cuò)誤彈性的多媒體數(shù)據(jù)網(wǎng)絡(luò)實(shí)時(shí)傳送方法，其特征在于，在所述步驟A中，所述發(fā)送端至少根據(jù)以下因素之一選擇所述前向糾錯(cuò)編碼方案當(dāng)前網(wǎng)絡(luò)傳送狀況、和待發(fā)送多媒體數(shù)據(jù)的服務(wù)質(zhì)量等級(jí)，而后者又決定于不同數(shù)據(jù)的相對(duì)重要性。
4.根據(jù)權(quán)利要求3所述的支持錯(cuò)誤彈性的多媒體數(shù)據(jù)網(wǎng)絡(luò)實(shí)時(shí)傳送方法，其特征在于，所述錯(cuò)誤彈性實(shí)時(shí)傳送協(xié)議包頭信息中包含前向糾錯(cuò)編碼類型字段，用于指示所述前向糾錯(cuò)編碼方案采用的前向糾錯(cuò)碼類型；前向糾錯(cuò)編碼子類型字段，用于指示所述前向糾錯(cuò)編碼方案的相關(guān)參數(shù)設(shè)置；數(shù)據(jù)包長(zhǎng)度字段，用于指示所述前向糾錯(cuò)編碼方案在對(duì)所述多媒體數(shù)據(jù)進(jìn)行糾前向糾錯(cuò)碼后得到的節(jié)點(diǎn)的長(zhǎng)度；數(shù)據(jù)包數(shù)目字段，用于指示該錯(cuò)誤彈性實(shí)時(shí)傳送協(xié)議包所承載的所述節(jié)點(diǎn)的數(shù)目。
5.根據(jù)權(quán)利要求4所述的支持錯(cuò)誤彈性的多媒體數(shù)據(jù)網(wǎng)絡(luò)實(shí)時(shí)傳送方法，其特征在于，當(dāng)所述多媒體數(shù)據(jù)為H.264網(wǎng)絡(luò)抽象層單元時(shí)，在所述步驟A中，所述發(fā)送端將至少一個(gè)所述H.264網(wǎng)絡(luò)抽象層單元?jiǎng)澐譃榈乳L(zhǎng)的至少一個(gè)數(shù)據(jù)節(jié)點(diǎn)，然后對(duì)其進(jìn)行前向糾錯(cuò)編碼，得到至少一個(gè)校驗(yàn)節(jié)點(diǎn)；在所述步驟B中，所述發(fā)送端將所述數(shù)據(jù)節(jié)點(diǎn)和所述校驗(yàn)節(jié)點(diǎn)分組封裝在至少一個(gè)所述錯(cuò)誤彈性實(shí)時(shí)傳送協(xié)議包中進(jìn)行發(fā)送；在所述步驟C中，所述接收端在接收到所述錯(cuò)誤彈性實(shí)時(shí)傳送協(xié)議包后，去封裝得到所述數(shù)據(jù)節(jié)點(diǎn)和所述校驗(yàn)節(jié)點(diǎn)；在所述步驟D中，如果發(fā)生了傳送過程中的數(shù)據(jù)節(jié)點(diǎn)丟失，則所述接收端根據(jù)所述校驗(yàn)節(jié)點(diǎn)對(duì)所述數(shù)據(jù)節(jié)點(diǎn)進(jìn)行前向糾錯(cuò)解碼，并劃分得到所述H.264網(wǎng)絡(luò)抽象層單元。
6.根據(jù)權(quán)利要求5所述的支持錯(cuò)誤彈性的多媒體數(shù)據(jù)網(wǎng)絡(luò)實(shí)時(shí)傳送方法，其特征在于，在開始傳送之前，還包含步驟，對(duì)于各種所述前向糾錯(cuò)碼類型，所述發(fā)送端和所述接收端協(xié)商確定所述錯(cuò)誤前向糾錯(cuò)碼子類型字段的取值與其所指示的該種前向糾錯(cuò)碼的相關(guān)參數(shù)設(shè)置的對(duì)應(yīng)關(guān)系。
7.根據(jù)權(quán)利要求6所述的支持錯(cuò)誤彈性的多媒體數(shù)據(jù)網(wǎng)絡(luò)實(shí)時(shí)傳送方法，其特征在于，所述發(fā)送端和所述接收端都根據(jù)所述前向糾錯(cuò)編碼子類型字段的指示對(duì)應(yīng)關(guān)系建立對(duì)應(yīng)關(guān)系表，用于根據(jù)所述前向糾錯(cuò)編碼類型字段和所述前向糾錯(cuò)編碼子類型字段查詢所對(duì)應(yīng)的前向糾錯(cuò)編碼或前向糾錯(cuò)解碼處理模塊；在所述步驟A中，所述發(fā)送端調(diào)用相應(yīng)前向糾錯(cuò)編碼處理模塊進(jìn)行前向糾錯(cuò)編碼；在所述步驟D中，所述接收端調(diào)用相應(yīng)前向糾錯(cuò)解碼處理模塊進(jìn)行前向糾錯(cuò)解碼。
8.根據(jù)權(quán)利要求7所述的支持錯(cuò)誤彈性的多媒體數(shù)據(jù)網(wǎng)絡(luò)實(shí)時(shí)傳送方法，其特征在于，在所述步驟A中，所述發(fā)送端根據(jù)所述H.264網(wǎng)絡(luò)抽象層單元的頭信息中的網(wǎng)絡(luò)抽象層參考標(biāo)識(shí)字段和網(wǎng)絡(luò)抽象層單元類型字段中的任意一者或兩者來評(píng)估對(duì)應(yīng)數(shù)據(jù)的相對(duì)重要性，從而確定所述服務(wù)質(zhì)量等級(jí)，進(jìn)而選擇所述前向糾錯(cuò)編碼方案，確定所述前向糾錯(cuò)編碼類型字段和前向糾錯(cuò)編碼子類型字段。
9.根據(jù)權(quán)利要求7所述的支持錯(cuò)誤彈性的多媒體數(shù)據(jù)網(wǎng)絡(luò)實(shí)時(shí)傳送方法，其特征在于，在所述步驟A中，所述發(fā)送端根據(jù)所述接收端反饋的傳送報(bào)告評(píng)價(jià)所述網(wǎng)絡(luò)傳送狀況，進(jìn)而選擇所述前向糾錯(cuò)編碼方案，確定所述前向糾錯(cuò)編碼類型字段和前向糾錯(cuò)編碼子類型字段。
10.根據(jù)權(quán)利要求8或9所述的支持錯(cuò)誤彈性的多媒體數(shù)據(jù)網(wǎng)絡(luò)實(shí)時(shí)傳送方法，其特征在于，所述錯(cuò)誤彈性實(shí)時(shí)傳送協(xié)議包頭信息中的版本信息字段取值為二進(jìn)制11，以區(qū)別于實(shí)時(shí)傳送協(xié)議；所述前向糾錯(cuò)編碼類型字段位于貢獻(xiàn)源標(biāo)識(shí)符列表之后，占4比特；所述前向糾錯(cuò)編碼子類型字段位于所述前向糾錯(cuò)編碼類型字段之后，占9比特；所述數(shù)據(jù)包長(zhǎng)度字段位于所述前向糾錯(cuò)編碼子類型字段之后，占11比特；所述數(shù)據(jù)包數(shù)目字段位于所述數(shù)據(jù)包長(zhǎng)度字段之后，占8比特。
11.根據(jù)權(quán)利要求8或9所述的支持錯(cuò)誤彈性的多媒體數(shù)據(jù)網(wǎng)絡(luò)實(shí)時(shí)傳送方法，其特征在于，所述前向糾錯(cuò)編碼方案使用改進(jìn)的“Tornado”糾刪碼；所述改進(jìn)的“Tornado”糾刪碼對(duì)于一組所述數(shù)據(jù)節(jié)點(diǎn)僅生成一層所述校驗(yàn)節(jié)點(diǎn)。
全文摘要
本發(fā)明涉及多媒體數(shù)據(jù)實(shí)時(shí)傳送技術(shù)，公開了一種支持錯(cuò)誤彈性的多媒體數(shù)據(jù)網(wǎng)絡(luò)實(shí)時(shí)傳送方法，使得多媒體數(shù)據(jù)實(shí)時(shí)傳送的錯(cuò)誤彈性機(jī)制能在傳送協(xié)議層面得以實(shí)現(xiàn)。本發(fā)明中，首先在現(xiàn)有RTP協(xié)議基礎(chǔ)上提供了可以攜帶前向糾錯(cuò)編碼方案相關(guān)信息的ERRTP協(xié)議來提供媒體數(shù)據(jù)的實(shí)時(shí)傳送，使得多媒體數(shù)據(jù)在ERRTP上傳送的同時(shí)標(biāo)記其相應(yīng)的前向糾錯(cuò)編碼方案信息，從而將錯(cuò)誤彈性機(jī)制融入傳送層；其次在發(fā)送端還可以根據(jù)當(dāng)前網(wǎng)絡(luò)狀況和多媒體數(shù)據(jù)重要性等級(jí)等因素來選擇采用各種備用的前向糾錯(cuò)編碼方案，從而達(dá)到不等保護(hù)和分級(jí)保護(hù)的目的，實(shí)現(xiàn)保護(hù)能力和傳送效率的均衡。
文檔編號(hào)H04L29/06GK1859580SQ200510113940
公開日2006年11月8日 申請(qǐng)日期2005年10月17日 優(yōu)先權(quán)日2005年10月17日
發(fā)明者羅忠, 宋彬 申請(qǐng)人:華為技術(shù)有限公司