專利名稱：：使用可變fec開銷和保護周期的流送和緩沖的制作方法
技術領域：
：本發明涉及編碼和解碼通信系統中的數據，尤其涉及編碼和解碼數據以解決所通信的數據中的差錯和間隙，同時應付接收器在接收到數據時快速地提供該數據的需求的通信系統。
背景技術：
：發送者與接收者之間的文件和流在通信信道上的傳輸已成為眾多文獻的主題。較佳地，接收者期望在某一級別的確定性下接收由發送者通過信道傳送的數據的正確副本。在信道不具有理想保真度(這包括幾乎所有在物理上可實現的系統)的情況下，所關心的是如何處理傳輸中丟失和混淆的數據。丟失的數據(擦除)通常較遭破壞的數據(差錯)更容易處理，因為接收者在遭破壞的數據被錯誤地接收到時并不總是能夠進行辨認。已開發出許多糾錯碼來糾正擦除和/或差錯。當傳送器與接收器具有通信所需的所有計算能力和電功率且傳送器與接收器之間的信道足夠干凈以允許相對無差錯的通信時，數據傳輸是簡單的。當信道處于不利環境或傳送器和/或接收器具有有限的能力時，數據傳輸問題變得比較艱難。一種解決方案是使用前向糾錯(FEC)技術，其中數據在傳送器處被編碼，以使得接收器能從傳輸擦除和差錯中恢復。在可行的情況下，從接收器到傳送器的反向信道允許接收器向傳送器就差錯進行傳達，該傳送器隨后可相應地調節其傳輸過程。然而，反向信道常常不可用或不可行，或者僅有限的能力可用。例如，在傳送器向大量接收器傳送時，傳送器不能處置來自所有這些接收器的反向信道。結果，通信協議常常需要被設計成沒有反向信道或具有有限容量的反向信道，這樣，傳送器可能必須處理寬泛變化的信道狀況而不具有對這些信道狀況的全面概觀。在用于可能丟失分組的信道上的數據輸送的分組協議的情形中，要在分組網絡上傳送的文件、流或其它數據塊被劃分成均勻大小的輸入碼元，使用FEC碼來從輸入碼元生成與這些輸入碼元相同大小的編碼碼元，并且在分組中放置并發送編碼碼元。碼元的"大小"可以比特來度量，無論碼元實際上是否被分割成比特流，其中當碼元是選自2M個碼元的字母表時，一個碼元具有M比特的大小。在此類基于分組的通信系統中，面向分組擦除的FEC編碼方案可能會是合適的。如果文件傳輸允許預期接收者恢復原始文件的正確副本——即使面臨網絡中的擦除時亦是如此——則該文件傳輸被認為是可靠的。如果流傳輸允許預斯接收者及時地恢復流的每個部分的正確副本—即使面臨網絡中的擦除時亦是如此—則該流傳輸被認為是可靠的。在流的某些部分不能被及時恢復的情況下文件或流的某些部分不能恢復或者進行流送這種意義上來說，文件傳輸和流傳輸兩者可能多少還是可靠的。通常因突發擁塞導致路由器中的緩沖機構達到其容量從而強制其丟棄傳入分組而M分組丟失。對抗輸送期間的擦除的保護已成為眾多研究的主題。在用于會破壞比特的嘈雜信道上的數據傳輸的協議的情形中，要在數據傳輸信道上傳送的數據塊被劃分成均勻大小的輸入碼元，從這些輸入碼元生成相同大小的編碼碼元，并且這些編碼碼元通過該信道被發送。對于此類嘈雜信道，碼元的大小典型為一比特或幾個比特，無論碼元實際上是否被分割成比特流。在此類通信系統中，面向比特流糾錯的FEC編碼方案可能是合適的。如果數據傳輸允許預期接收者恢復原始塊的正確副本——即使面臨差錯(信道中或者被檢測到或者未被檢測到的碼元破壞)時亦是如此——則該數據傳輸被認為是可靠的。在恢復之后塊的某些部分可能仍保留為遭破壞的這個意義上來說，輸出多少也還是可靠的。碼元通常遭到突發噪聲、周期性噪聲、干擾、弱信號、信道中的堵塞以及各種其它原因的破壞。某些FEC碼的一個問題在于，它們要求過量的計算能力或存儲器來操作。另一個問題在于，輸出碼元的數目必須在編碼過程之前被確定。如果高估分組丟失率，則這會導致低效率，而如果低估分組丟失率，則會導致失敗。鏈式反應碼是允許從文件或流的固定輸入碼元生成任意數目的輸出碼元的FEC碼。有時，它們被稱為噴泉或無比率碼，因為該碼不具有先驗固定傳輸速率，并且可能的輸出碼元的數目可能與輸入碼元的數目無關。例如，在Luby和Shokrollahi中示出了用于生成、使用或操作鏈式反應碼的新穎技術。還應當知道使用多級鏈式反應("MSCR")碼，諸如在Shokrollahi中所描述以及由DigitalFountain(數字方敦)股份有限公司在商標"Raptor，，碼下開發的那些。例如，在接收來自源文件或源流的輸入碼元、從輸入碼元生成中間碼元且這些中間碼元作為鏈式反應編碼器的源碼元的編碼器中使用多級鏈式反應碼。對于某些應用，這些碼的其它變體可能是更合適或較佳的。如本文中所用的，輸入碼元指接收自文件或流的數據，而源碼元指用于生成輸出碼元的碼元。在某些情形中，源碼元包括輸入碼元，而在某些情形中，源碼元是輸入碼元。然而，存在輸入碼元被編碼和/或轉換成中間碼元集合且此中間集合用于生成輸出碼元而不涉及輸入碼元(直接)的情形。因而，輸入碼元包括為與接收器通信的發送器所知的信息，源碼元是被編碼器的至少一個級使用并從輸入碼元導出的碼元，而輸出碼元包括由發送器傳送給接收器的碼元。在某些應用中，接收器可在傳輸完成之前開始使用數據。例如，在視頻請求(video-on-demand)系統中，接收器可在僅接收到很少一部分視頻數據之后開始播出視頻，并假定其余視頻數據將在其被需要之前被接收到。在此類系統中，編碼不應當在整個傳輸上進行，因為在傳輸末端的某些輸出碼元可能對視頻起始處所需的輸入碼元進行編碼，在此情形中那些輸出碼元是浪費的，因為其信息在它不可用時需要，而在它可用時不需要。為了避免這種情況，數據流通常被分割成塊，其中塊的輸入數據在下一塊準備好之前被編碼并發送，并且這些塊通常不依賴于這些塊之外的輸入碼元。對于此類應用，常常存在可靠性與傳輸何時開始和數據何時可開始被使用兩者間的滯后時間之間的權衡。例如，如果整個正片長度電影被編碼以使得傳輸開始處的差錯可使用傳輸結束處的數據來糾正，則接收器可能在向應用(或者應用的用戶)指示電影可進行回放之前將進行等待直至它接收到所有電影數據。然而，在傳輸總時間很長時，可能有無法接受的滯后時間。一種解決方案是編碼數據流以使得接收器在某一較小的滯后時間之后具有足以開始回放電影的信息，而接收器可能期望及時接收進一步信息以繼續回放。當然，如果接近傳輸末端的數據提供了對傳輸開始處的數據的冗余，則由于電影的第一部分被回放將遠遠早于后一信息被接收而浪費了該能力。因而，通常使得在有需要時可用的冗余在時間上靠近數據的解碼是有效的。然而，如果約束過于苛刻，則回放可能必須過早地開始，并且引發接收器遭遇電影中其還不具有足以進行解碼的數據的回放點的可能性并可能導致跳躍或暫停。在使用塊的情況下存在這樣的權衡塊大小過小，則沒有提供足夠的差錯保護，而塊大小過大，則接收器在等待要被完全恢復的塊時經歷過多的延遲。發明概要在本發明的實施例中，數據被從傳送器流送到接收器，其中流送是在假定接收器將在數據被全部傳送和接收到之前開始使用數據的情況下輸送數據。所流送的數據包括前向糾錯("FEC")且數據消耗的速率可變化。傳送器具有輸入速率——在該速率下用盡輸入數據——以及傳送速率——以該速率發送此數據(以及按需的FEC數據)，并且這兩個速率可以是不同的，且因此當涉及FEC時會改變，因為伴隨FEC編碼有某種幵銷。在接收器處，有接收速率(接收器按其接收數據)和消耗速率(接收器按其用盡數據以進行其輸出)。傳送器使用比消耗速率大的傳送速率進行傳送，并且額外的帶寬可用于FEC保護和緩沖。在某些實施例中，該超額速率隨傳輸周期改變。對本文所公開的本發明的特征和優點的進一步理解可通過參考說明書和附圖的剩余部分來實現。附圖簡述圖1是可使用本文所描述的可變FEC開銷技術的通信系統的框圖。圖2是FEC流送框架架構的示圖。圖3是FEC源分組的示圖。圖4是FEC修復(repair)分組的示圖。圖5是FEC對象信息塊的示圖。圖6是源FEC有效載荷ID格式的示圖。圖7是修復FEC有效載荷ID格式的示圖。圖8是替換性修復FEC有效載荷ID格式的示圖。圖9是FEC反饋協議消息格式的示圖。圖10是成功報告消息的有效載荷格式的示圖。發明詳細描述在本發明的實施例中，數據被從傳送器流送到接收器，其中流送是在假定接收器將在數據被全部傳送和接收到之前開始使用數據的情況下輸送數據。所流送的數據包括前向糾錯("FEC")，后者提供了對重傳-請求方案——其中如果檢測到分組丟失則由接收器請求重傳丟失分組——的改進。在流送過程中涉及各種速率。所流送的數據包括前向糾錯("FEC")且數據消耗的速率可變化。傳送器具有輸入速率——以該速率用盡輸入數據——以及傳送速率——以該速率發送此數據(以及按需的FEC數據)，并且這兩個速率可以是不同的，且因此當涉及FEC時可改變，因為涉及FEC編碼的情況下有某種開銷。在接收器處，有接收速率(接收器以該速率接收數據)和消耗速率(接收器以該速率用盡數據以進行其輸出)。在信道上不存在數據丟失時，接收速率與傳輸速率相同。存在原始接收速率，該接收速率是在不計入由于FEC的開銷的情況下數據被接收的速率。例如，如果接收器是向顯示設備輸出11兆/秒(MBS)視頻流的視頻播放器，則消耗速率是11MBS。在顯示器、音頻、處理器或其它數據播放器上播出所消耗的數據時，消耗速率可稱為"播出(playout)"速率。在有許多流的情況下，使消耗連續進行以使得所流送的數據的呈現不會停止或阻滯——如果接收器處的所有數據被消耗且接收速率小于消耗速率時會發生這種停止和阻滯——是合需的。為了避免這種情況，接收器通常具有緩沖器以使得接收速率可暫時跌至消耗速率之下(由于分組丟失、擁塞等)卻又未用盡要被消耗的數據。當接收速率恰好是消耗速率時，沒有要被緩沖的額外數據。為了填充接收器的緩沖器，流送系統可被設置成使得傳輸速率高于消耗速率，或者傳輸在播出開始之前啟動。在任一情形中，有充分的接收以便至少部分地填充接收器緩沖器。在任一情形中，使用FEC而非重傳常常是較好的辦法。在使用重傳的情況下，在接收器發送重傳請求并接收響應時，需要有足夠的接收器緩沖器來繼續播出數據，否則播放器在到達尚待還原的錯失數據時將停止。在具體實施例中，傳送器使用大于消耗速率進行傳送，并且額外的帶寬被部分用于FEC保護且部分用于緩沖器填充以允許諸如"快速開始"的特征，此時可在緩沖器充分填充的情況下在接收開始之后立即開始播出，從而降低停止播出的風險。在某些實施例中，用于FEC保護的帶寬和用于緩沖填充的開銷量隨時間變化。例如，整體傳輸比特率可以是略高于消耗速率的恒定值，其中超出量在傳輸開始時較多地用于緩沖器填充而在后續時間較少地用于緩沖器填充。使用恒定比特率時，FEC保護在傳輸開始時將較少而在稍后的時間將較多。不需要恒定的比特率，并且可使用恒定的FEC開銷。綜述在以下針對包括DVB-IPI應用的應用描述了使用多級鏈式反應(MSCR)碼的流送媒體的FEC保護的協議——諸如由DFRaptorTM編碼器和解碼器所用的那些。在ShokrolIahi中描述了這種多級碼的示例。應當理解，本公開的目的在于，MSCR碼僅用作多級碼的示例，而本公開的示教可與除Shokrollahi中所述的那些之外的多級碼聯用。多級碼可用于DVB-IPI實時應用(使用MPEG-2輸送流封裝以及音頻和視頻在RTP上的直接傳輸兩者的多播和單播)的FEC保護。由IETF可靠多播工作組定義的FEC構建塊[3]描述了一種使用FEC的協議規范的辦法，該規范將協議的定義與FEC碼本身的規范分隔開。這使得協議設計問題能夠獨立于極為不同的FEC碼選擇問題來解決。在FEC構建塊的術語中，提供了用于"內容遞送協議"和用于"FEC方案"的單獨規范，前者定義了協議而后者定義了實際FEC碼。FEC構建塊描述了這樣的規則兩種類型的規范都必須遵循以使得它們可一起使用，并由此提供內容遞送協議與FEC方案之間的"粘合(glue)"。根據這種辦法，此規范被組織成多個模塊化組件。隨后，這些組件被組合以形成適于DVB-IPI應用的完整協議。這些組件包括(l)FEC流送框架，它為將FEC應用到媒體流提供整體協議框架，并在第2章節中進行描述；(2)多個FEC方案，它們定義了適于各類應用的協議組件并定義了如何將核心MSCR碼應用于流送應用，在第3章節中進行描述；(3)模塊化協議組件，它可用于支持基于在此所定義的FEC流送框架和FEC方案的應用，在第4章節中示出；以及(4)用于使用MPEG-2輸送流封裝以及音頻和視頻在RTP上的直接傳輸兩者的多播和單播視頻的協議規范，它使用上述構建塊來構造(第5章節)。術語和縮略詞術語/縮略詞定義/描述包被集合成單個源塊并用于生成單個修復碼元流的流(又稱為流量)集合。例如，低比特率音頻流可與高比特率流一起打包，從而提供較未被打包的情況下更好的FEC保護。流量用于"流"的另一術語，用在包的上下文中。中間塊從原始源塊數據導出的數據塊——在MSCR編碼器的情形中，或者接收到的源碼元和修復碼元的組合在MSCR解碼器的情形中。修復碼元由MSCR編碼器生成的碼元，該碼元是從源碼元導出的。源塊源數據的塊，MSCR編碼器提供該塊上的FEC修復信息。源碼元來自源塊的數據單元。源塊中的所有源碼元是相同大小的。FEC前向糾錯。編碼碼元源碼元或修復碼元。源分組信息(SPI)包括在與源分組有關或來自其的源塊中的信息。FEC流送配置信息控制FEC流送框架的操作的信息。表2-術語和縮略詞編碼器和解碼器圖1是使用多級編碼且可使用本文所描述的可變FEC開銷技術的通信系統100的框圖。在通信系統100中，輸入文件101或輸入流105被提供給輸入碼元生成器110。輸入碼元生成器110從輸入文件或流生成一個或多個輸入碼元(IS(O)、IS(l)、IS(2)、...)的序列，并且每個輸入碼元具有值和位置(在圖1中標示為括號內的整數)。如上所說明的，輸入碼元的可能值——即其字母表——通常是2M個碼元的字母表，以使得每個輸入碼元碼對輸入文件的M個比特編碼。M值通常是根據通信系統100的使用來確定的，但是通用系統可包括對應于輸入碼元生成器110的碼元大小輸入以使得M可隨使用的不同而不同。輸入碼元大小生成器110的輸出被提供給編碼器115。靜態密鑰生成器130產生靜態密鑰流So、S,、....。所生成的靜態密鑰的數目通常是有限的，并取決于編碼器115的具體實施例。將在隨后更詳細地描述靜態密鑰的生成。動態密鑰生成器120為將由編碼器115生成的每個輸出碼元生成動態密鑰。每個動態密鑰被生成為對于相同輸入文件而言大部分動態密鑰是唯一的。例如，Lubyl描述了可被使用的密鑰生成器的實施例。動態密鑰生成器120和靜態密鑰生成器130的輸出被提供給編碼器115。根據由動態密鑰生成器120提供的每個密鑰I，編碼器115從由輸入碼元生成器提供的輸入碼元生成具有值B(I)的輸出碼元。將在以下更詳細地描述編碼器115的操作。每個輸出碼元的值是基于其密鑰、輸入碼元的一個或多個的某些函數、以及可能已從輸入碼元計算出的一個或多個冗余碼元來生成的。產生特定輸出碼元的輸入碼元和冗余碼元的集合在此稱為輸出碼元的"相關聯碼元"或簡單地稱為其"關聯物(associate)"。函數("價值函數")和關聯物的選擇是根據在以下更詳細描述的過程來進行的。通常，對于輸入碼元和輸出碼元而言，M是相同的，即它們兩者是相同比特數目的碼，但并非總是如此。在某些實施例中，輸入碼元的數目K被編碼器115用來選擇關聯物。如果K并非提前已知，諸如輸入是流送文件時，則K可以僅是估計。值K也可被編碼器115用來將存儲分配給輸入碼元和由編碼器115生成的任何中間碼元。編碼器115將輸出碼元提供給傳送模塊140。還將來自動態密鑰生成器120生成的每個此類輸出碼元的密鑰提供給傳送模塊140。傳送模塊140傳送輸出碼元，并且取決于所用的密鑰控制(keying)法，傳送模塊140還可在信道145上向接收模塊150傳送關于所傳送的輸出碼元的密鑰的某些數據。信道145被假定為擦除信道，但是對于通信系統100的適當操作而言，這并非是必需的。模塊140、145和150可以是任何合適的硬件組件、軟件組件、物理介質、或其任何組合，只要傳送模塊140適于向信道145傳送輸出碼元和任何所需的關于其密鑰的數據，且接收模塊150適于從信道145接收碼元和潛在可能的某些關于其密鑰的數據。如果用于確定關聯物，則值K可通過信道145發送，或者可通過編碼器115與解碼器155之間的協定提前被設置。如上所說明的，信道145可以是實時信道，諸如通過因特網的路徑或從電視傳送器到電視接收者的廣播鏈路或從一個點到另一點的電話連接，或者信道145可以是諸如CD-ROM、盤驅動、網站等的存儲信道。信道145甚至可以是實時信道和存儲信道的組合，諸如在個人通過電話線路自個人計算機向因特網服務提供商(ISP)傳送輸入文件時形成的信道，該輸入文件被存儲在Web服務器上并在隨后通過因特網傳送給接收者。由于信道145被假定為擦除信道，因此通信系統100并不假定離開接收模塊150的輸出碼元與進入傳送模塊140的輸出碼元之間一對一地對應。實際上，在信道145包括分組網絡時，通信系統100甚至不能假定任何兩個或多個分組的相對次序在通過信道145傳送時得以保持。因此，輸出碼元的密鑰是使用上述密鑰控制方案的一個或多個來確定的，而并非一定根據輸出碼元離開接收模塊150的次序來確定。接收模塊150向解碼器155提供輸出碼元，而接收模塊150接收到的關于這些輸出碼元的密鑰的任何數據被提供給動態密鑰再生器160。動態密鑰再生器160再生接收到的輸出碼元的動態密鑰，并將這些動態密鑰提供給解碼器155。靜態密鑰生成器163再生靜態密鑰SQ、S,、...并將它們提供給解碼器155。靜態密鑰生成器訪問用在編碼和解碼過程兩者期間的隨機數生成器135。如果隨機數是在相同的物理設備上生成，則這可以是訪問此設備的形式的訪問，或者是訪問隨機數生成的相同算法的形式以實現同樣的行為。解碼器155使用由動態密鑰再生器160和靜態密鑰生成器163提供的密鑰連同相應的輸出碼元一起來恢復輸入碼元(仍為IS(O)、IS(l)、IS(2)、...)。解碼器155將已恢復的輸入碼元提供給輸入文件重組器165，后者生成輸入文件101或輸入流105的副本170。編碼器115可使用本文所示的技術來編碼數據以使得FEC編碼具有可變開銷。2FEC流送框架2.1遊本章節定義了用于CDP的定義的框架，從FEC構建塊這個意義上來說，它提供了通過UDP流送的數據流量的FEC保護。本章節并不定義完全內容遞送協議，而是僅定義期望為支持通過UDP流送數據的所有內容遞送協議所共用的那些方面。在本章節中定義的框架并不專用于單個流送應用協議。該框架提供了對通過UDP的應用協議流量的FEC保護以及對多個此類流量的組合保護。例如，多個RTP流量可連同相關聯的RTCP流量以及諸如MIKEY分組的潛在可能其它相關流量一起被保護。對于許多丟失狀況中的許多FEC方案，通過對使用具有給定FEC開銷的FEC可達到的可靠性中的改進隨著作為單個塊保護的數據量的增加而增加。因此，在一起保護多個流的能力中有顯著的益處，在接收器要求所有流以便向用戶提供有用服務的情形中尤其如此。此框架不定義待保護的流量如何被確定，也不定義所保護的流量和保護它們的FEC流自發送器傳達到接收器的細節如何。完全內容遞送協議規范——諸如章節5中給出的那些——解決了這些信令要求。然而，本章節的確規定發送器和接收器處FEC流送框架所要求的信息——例如要進行FEC保護的流量以及將攜帶FEC保護數據的流量的細節。還規定了內容遞送協議用于傳達此信息的SDP屬性。在圖2中例示了以上概括的架構。2.2程序綜述2.2.1概要在本文章節中定義的機制包括三個組件(i)來自屬于一個或若干個UDP分組流量的源媒體分組的'源塊'的構造。UDP流量可包括例如RTP、RTCP和SRTP分組以及還有與流有關的其它協議。(ii)源分組的任選擴展，用于指示源塊以及該源塊中被來自源分組或與其有關的數據占據的位置。(iii)通過UDP發送的修復分組的定義，它可被FEC解碼器用來重構源塊的錯失部分。除源數據通過UDP攜帶之外，此機制不對可被一起保護的源數據施加任何限制。數據可以是來自被聯合保護的若干不同UDP流量。通常，對一個流構造多個源塊，這些源塊各自由不同源分組集構造成。例如，每個源塊可及時地構造自與流的特定段有關的那些源分組。支持這種流送架構的接收器應當支持FEC源分組的分組格式并且還應當支持FEC修復分組的分組格式。本章節并不定義發送器如何確定哪些源分組被包括在哪些源塊中。特定內容遞送協議可定義這種映射，或者它可留待作為發送器處的相關實現。然而，CDP規范應當定義接收器如何確定其為接收任何給定源塊的FEC修復分組所應等待的時間長度。在發送器處，該機制處理原始UDP分組以創建(i)一個或多個'源塊'形式的原始分組的存儲副本。源塊是隨后將對其應用FEC碼的邏輯數據塊。它是通過級聯每個源分組的"源分組信息(SPI)，來構造的。通常，分組的SPI包含該分組所屬的流量的較短標識符、分組的長度、UDP有效載荷和可能的填充字節。(ii訴于傳輸到接收器的FEC源分組。FEC流送框架使用由FEC方案指定的用于從源塊生成期望的修復碼元量的FEC編碼器。這些修復碼元隨后使用FEC修復分組格式發送給接收器。FEC修復分組可被發送到與由FEC流送配置信息指示的原始UDP分組的目的端口的任一個不同的UDP目的端口。接收器直接從接收到的任何FEC源分組恢復原始源分組。接收器還使用接收到的FEC源分組來構造與發送器處構造的相同源塊格式的原始分組的存儲副本。如果與給定源塊有關的任何FEC源分組已丟失，則接收器處的源塊的這個副本將是不完整的。如果已接收到與源塊有關的足夠的FEC源和FEC修復分組，則FEC框架可使用由FEC方案定義的FEC解碼算法來恢復源塊的副本(希望是完整的，但并不一定)。可隨后從源塊的完成部分中提取出錯失源分組的SPI，并將其用于重構要傳遞給應用的源分組。注意接收器可能需要緩沖接收到的源分組以便為FEC修復分組的到達以及在部分或全部接收到或恢復的分組被傳遞給應用之前進行FEC解碼留出時間。如果未提供這種緩沖，則應用必須能夠處理被需要的分組的嚴格的重排序。然而，這種緩沖是內容遞送協議和/或專用實現，且未在此指定。FEC源分組的接收器標識源塊以及該源塊內由從每個分組導出的SPI占據的位置。此信息被稱為FEC源分組標識信息并且可以多種方式來傳達。FEC源分組標識信息可被編碼到在本規范中定義的FEC源分組格式內的專用字段——稱為源FEC有效載荷ID字段——中。源FEC有效載荷ID字段的確切內容和格式由FEC方案來定義。或者，FEC方案或CDP可定義如何從源分組內的其它字段導出FEC源分組標識信息。本文獻定義了源FEC有效載荷ID字段——如果被使用——被附加到源分組以形成FEC源分組的方式。FEC修復分組的接收器還應當能夠標識源塊以及所包含的修復數據與原始源塊之間的關系。此信息稱為FEC修復分組標識信息。此信息應當被編碼成專用字段——修復FEC有效載荷ID字段——該字段的內容和格式由FEC方案來定義。結合該規范使用的任何FEC方案應當是系統的FEC方案并且應當基于源塊。FEC方案可為FEC源分組和FEC修復分組定義不同的FEC有效載荷ID字段格式。2.2.2發送器操作假定發送器已構造或接收到會話的原始數據分組。這些可以是RTP、RTCP、MIKEY或其它UDP分組。以下操作描述了用于生成順應FEC源分組和FEC修復分組流的可能方法1.如章節2.3.2中指定的那樣通過級聯每個原始源分組的SPI來構造源塊。通過如此進行，FEC源分組的源FEC分組標識信息可被確定并且被包括在源FEC有效載荷ID字段——如果被使用——中。在SPI中，分組的UDP流量的身份是使用本規范中定義的短'UDP流量ID'來作標記的。將UDP流量規范與UDP流量ID相關聯是通過FEC流送配置信息來定義的。2.FEC源分組是根據章節2.3.3來構造的。在攜帶從特定協議(例如，RTP、RTCP、SRTP、MIKEY等)的原始流生成的FEC源分組時，原始流量的身份由源分組通過使用由內容遞送協議(例如，使用DVB服務發現)已廣告的相同UDP端口和IP地址來維護。所生成的FEC源分組根據常規UDP程序來發送。3.FEC編碼器從源塊生成修復碼元，而FEC流送框架將這些碼元放置到FEC修復分組中，以便輸送到接收器。這些修復分組使用常規UDP程序發送到唯一目的端口以便將它們與源分組流的任一個分開。在FEC流送配置信息中定義要用于FEC修復分組的端口。2.2.3接收器操作以下描述了當接收FEC源或修復分組時的可能的接收器算法1.如果FEC源分組被接收到(如由在其上進行接收的UDP流量指示的)a.原始源分組通過移除源FEC有效載荷ID——如果被使用——來構造。結果分組可被緩沖以為FEC修復留出時間。b.源FEC分組標識信息是根據源FEC有效載荷ID——如果被使用——或根據其它手段來確定的。c.結果分組的SPI根據源FEC分組標識信息和章節2.3.2中所述的源塊格式來放置到源塊中。在其處接收/從其發送分組的IP地址和UDP端口被用于確定SPI內的UDP流量ID。2.如果接收到FEC修復分組(如由在其上接收到該分組的UDP流所指示的)，則所包含的修復碼元根據修復FEC有效載荷ID來與源塊相關聯。3.如果至少一個源分組錯失且針對源塊的至少一個修復分組已被接收到，則FEC解碼會是合需的。FEC解碼器確定在步驟1構造的源塊加上在步驟2中接收到的相關聯的修復碼元是否包含足以解碼源塊中的任何或全部錯失源碼元，并且如果是，則執行解碼操作。4.在解碼操作期間重構的任何SPI隨后被用于重構錯失的源分組，并且這些分組作為常規接收到的源分組來緩沖(參看上述步驟la)。注意上述過程可能導致并非所有原始源分組被恢復的情形。被正確接收到的源分組以及被重構的那些源分組可失序地且以與在接收器處到達的次序不同的次序遞送到應用。或者，將源分組重排序和重構成它們被放置到源分組中的次序可能需要進行緩沖和分組重排序——如果根據應用需要的話。2.3協議規范2.3.1輕本章節指定了FEC流送框架的協議元素。協議包括以下章節描述的三個組成1.源自源分組的源塊的構造。FEC碼可被應用到此源塊以產生修復數據。2.包含源數據的分組的格式。3.包含修復數據的分組的格式。FEC流送框架的操作由特定FEC流送配置信息來控制。在此章節中也定義了此配置信息。使用此框架的完全協議規范應當指定用于確定此信息并在發送器與接收器之間傳達它們的手段。2.3.2源塊的結構此條款定義了源塊的布局。源塊包括至少一個原始源UDP分組的SPI的級聯。令w為源塊中UDP分組的數目，可在源塊構造過程期間動態地確定n。F為以字節計的源碼元大小。注意此信息是由如章節2.3.6中定義的FEC方案來提供的。iA/標示要被添加到源塊的第i個UDP分組的UDP有效載荷的八位位組，0<=i<n。/A7以八位位組計的R[i]的長度。LA/標示以網絡字節次序表示的l[i]的值的兩個八位位組(首先是高位八位位組)標示標識取得第i個分組的UDP流量的整數'UDP流量ID'iY(/標示表示f[i]的值的單個八位位組W為使得s[i]*T>=(1[i]+3)的最小整數。注意s[i]是以碼元為單位計的SPI[i]的長度。iV(/標示s[ipT-(l[i]+3)個全零八位位組。注意P[i]是用于使每個UDP分組的起始與碼元的起始對齊的填充八位位組。S尸W為F[i]、L[i]、R[i]和P[i]的級聯。隨后，通過級聯SPI[i]——i=0,2,...n-l——來構造源塊。源塊大小S隨后通過sum{s[i]*T,i=0,...，11-1}來給出。源塊由整數源塊號來標識，而源塊內的碼元由整數編碼碼元ID來標識。本章節不指定如何將源塊號分配給源塊。在源塊內從零開始對碼元連續編號。每個源分組與包含該分組的SPI的第一碼元的編碼碼元ID相關聯。因此，與第j個源分組相關聯的編碼碼元ID值ESI[j]通過以下給出ESI[j]-O，其中』=0ESI[j]=sum{W,i=0,...,(/-l)}，其中0<)<"源FEC分組標識信息包括源塊的身份以及與該分組相關聯的編碼碼元ID。UDP流量是由IP源和目的地址以及UDP源和目的端口值來唯一地定義的。將UDP流量ID值指派給UDP流量是FEC流送配置信息的一部分。2.3.3FEC源分組的分組格式FEC源分組的分組格式應當用于輸送原始源UDP分組的有效載荷。如圖3中所示的，它包括其后任選地跟隨有源FEC有效載荷ID字段——如果被使用——的原始UDP分組。IP和UDP報頭字段應當與原始源分組的那些相同。原始UDP有效載荷字段應當等于原始源分組的UDP有效載荷。FEC源分組的UDP有效載荷應當包括其后跟隨有源FEC有效載荷ID字段的原始UDP有效載荷。源FEC有效載荷ID字段——如果存在——包含FEC算法的操作——尤其是導出源FEC分組標識信息時——所需的信息。源FEC有效載荷ID的格式以及源FEC分組標識信息的導出是由FEC方案來定義的。注意FEC方案或CDP可定義用于從源分組中的其它信息(例如，RTP序號)導出FEC分組標識信息的手段。在此情形中，本文所述的源FEC有效載荷ID字段不被附加到分組，且源FEC分組在各方面與原始源分組相同。2.3.4FEC修復分組的分組格式圖4中示出了FEC修復分組的分組格式。UDP有效載荷包括修復FEC有效載荷ID字段以及由FEC編碼過程生成的一個或多個修復碼元。修復FEC有效載荷ID字段包含FEC算法的操作所需的信息。此信息是由FEC方案定義。修復FEC有效載荷ID字段的格式是由FEC方案來定義的。任何數目的完整修復碼元可被包含在FEC修復分組中，該FEC修復分組服從由FEC方案定義的分組大小限制或其它限制。分組內修復碼元的數目可根據碼元長度和分組長度來確定。部分修復碼元不應當被包括在FEC修復分組中。2.3.5FEC流送配置信息FEC流送配置信息是FEC流送框架為了將FEC保護應用到UDP流量而需要的信息。使用在此指定的框架的用于流送的完全內容遞送協議規范應當包括此信息如何被導出以及如何在發送器與接收器之間傳達的細節。FEC流送配置信息包括對多個UDP分組流量的標識。每個UDP分組流量由元組(源IP地址、目的IP地址、源UDP端口、目的UDP端口》來唯一地標識。FEC-SF的單個實例經由包含修復分組的一個或多個UDP分組流量提供了對指定的一組源UDP分組流量的所有分組的FEC保護。對于FEC-SF的每個實例，FEC流送配置信息包括1.攜帶FEC修復分組的UDP分組流量——稱為FEC修復流量——的標識。2.對于由FEC修復流量保護的每個源UDP分組流量a.攜帶源分組的UDP分組流量的標識。b.整數標識符，對于此流量，在0與255之間。由同一FEC修復流量保護的所有源UDP分組流量之間，此標識符應當是唯一的。3.FEC編碼ID、FEC實例ID(如果可應用)以及任選地，碼元大小。以上的項目(3)被包括在FEC對象傳輸信息中。在發送器或接收器處可存在具有分開和獨立的FEC流送配置信息的多個FEC-SF實例。單個FEC-SF實例保護以上(2)中標識的所有源UDP分組流量的所有分組，即，這些流量上的所有分組應當是如章節2.3.3中所定義的FEC源分組。單個源UDP分組流量不應當由一個以上的FEC-SF實例來保護。單個FEC修復流量為單個FEC-SF實例提供了修復分組。其它分組不應當在此流量中發送，S卩，FEC修復流量中的所有分組應當是在章節2.3.4中定義的FEC修復分組且應當與相同的FEC-SF實例有關。需要向FEC-SF通知要用于每個源塊的碼元大小。此信息可被包括在FEC流送配置信息中或它可通過其它手段來傳達——例如在FEC修復有效載荷ID字段內。完全內容遞送協議規范應當指定此信息如何在發送器與接收器之間傳達。2.3.6FEC方案要求較佳的FEC方案是系統的，是基于離散源塊的，指定與源分組相關聯的源塊號和編碼碼元ID如何被導出或如何從發送器傳到接收器(例如，在源FEC有效載荷ID字段內)，以及指定碼元長度如何被導出或如何從發送器傳到接收器(例如，作為FEC對象傳輸信息的部分)。3.用于流送的FEC方案3.1用于任意分組流量的MSCRFEC方案此條款定義了用于UDP上任意分組流量的MSCR保護的FEC方案。3.1.1格式和碼3.1.1.1FEC對象傳輸信息3丄1丄1FEC對象傳輸元素FEC對象傳輸元素、FEC編碼ID被設為預定值。3丄1丄2公共的對于此方案，此公共FEC對象傳輸信息元素及其值范圍是這樣的最大源塊長度為小于216的非負整數——以碼元為單位計的——而編碼碼元大小是小于216的非負整數——以字節為單位計的。經編碼的公共FEC對象傳輸信息元素的格式可以是圖5中定義的四-八位位組字段。3.1.1.2FEC有效載荷ID3.1.1.2.1源FEC有效載荷ID源FEC有效載荷ID可以是如圖6中所示的。在那里，源塊號(SBN)(16比特)是與分組內的源數據有關的源塊的整數標識符，而編碼碼元ID(ESI)(16比特)是源塊中源分組的起始碼元索引。編碼碼元標識符的說明是由FEC流送框架來定義的(參見章節2)。3.1.1.2.2修復FEC有效載荷ID在圖7中定義了修復FEC有效載荷ID的結構，其中源塊號(SBN)(16比特)是與分組內的修復碼元有關的源塊的整數標識符，編碼碼元ID(ESI)(16比特)是分組內編碼碼元的整數標識符，而源塊長度(SBL)(16比特)是源塊內源碼元的數目。源塊號、編碼碼元標號符和源塊長度的說明可以是如FEC碼規范所定義的。3.1.2程序此FEC方案使用章節2中定義的框架的程序來構造可應用FEC碼的源塊。發送器應當向源塊順序分配源塊號，在源塊號216-1之后巻繞回到零。發送器不應當構造比在FEC對象傳輸信息中信令的最大源塊大的源塊。3.1.3FEC碼規范傳遞給MSCRFEC編碼器的源塊包括根據章節3丄2構造的、擴展成具有零或多個填充碼元以使得源塊中的碼元總數等于FEC對象傳輸信息中信令的最大源塊長度的源塊(參見章節3丄1丄2)。因此，由編碼的FEC使用的K值等于最大源塊長度。填充碼元可以是設置成值零的字節。要用于源塊構造和修復碼元構造的碼元大小T等于FEC對象傳輸信息中信令的編碼碼元大小(參見章節3丄1丄2)。參數T被設置成使得任何源塊中源碼元的數目最多為KMAX=8192。章節3丄3.3中給出了推薦參數。3丄3.1編碼分組構造如章節2.3.4中所述的，每個修復分組包含源塊號(SBN)、編碼碼元ID(ESI)、源塊長度(SBL)和修復碼元。包含在修復分組內的修復碼元的數目是從分組長度計算出的。放置入修復分組的ESI值以及用于生成修復碼元的修復碼元三倍數是如[2]的子條款<:.3.2.2中所描述的來計算的。修復FEC有效載荷ID字段的源塊長度字段被設置成包括在與源塊相關聯的分組的源分組信息中的碼元數目，即，在填充成最大源塊長度之前。3.1.3.2輸送此子條款描述了MSCR編碼器/解碼器與利用MSCRFEC進行流送的任何輸送協議之間的信息交換。用于流送的MSCR編碼器根據輸送協議對每個源塊使用以下信息-以字節計的碼元大小T-源塊中碼元的數目K-源塊號(SBN)-要被編碼的源碼元——KT個字節對于每個修復分組，MSCR編碼器向輸送協議提供包括以下的編碼分組信息-源塊號(SBN)-編碼碼元ID(ESI)-源塊長度(SBL)-修復碼元輸送協議向MSCR解碼器透明地傳達此信息。在本規范中定義了合適的輸送協議。3丄3.3示例參數3丄3.3.1參數導出算法本章節提供了對輸送參數T的導出的推薦。此推薦是基于以下輸入參數:-S以字節計的最大源塊大小-尸以字節計的最大修復分組有效載荷大小(不包括修復FEC有效載荷ID)，它應當是A的倍數。-J以字節計的碼元對齊因子-尺M4x每源塊的最大源碼元數目如在[2]中定義的，KMAX=8192。-每源塊的最小目標碼元數目-G皿每修復分組的最大目標碼元數目對這些輸入的要求是ceil(SAP)^^M。基于以上輸入，輸送參數T計算如令，G=min(ceil(尸lMWB),尸"，—每分組的適當碼元數目7=floor(尸/G4-G):M以上導出的r值應當被認為是對實際所用r值的指導。確保r除盡尸會是有益的，或者可有益地將r的值設置成較小以在全尺度修復碼元被用于在丟失源分組結束時恢復部分源碼元時最小化損耗(只要源塊中的最大源碼元數目不超過&^Y)。此外，對r的選擇取決于源分組大小分布，例如，如果所有源分組是相同大小的，則選擇r以使得修復分組p'的實際有效載荷大小等于(或以盡可能少的字節地大于)每個源分組在源塊中占用的字節數目，其中尸'是r的倍數。對輸入參數丄i^蔡和<^^的推薦設置是爿=16、Xm/w=640、Gm^=10。3.1.3.3.2示例在假定^、/^/w和GM"為推薦的值且尸-1424的情況下，以上算法導致如以下表3中的輸送參數<table>tableseeoriginaldocumentpage24</column></row><table>表3:示例參數設置3.2用于單個有序分組流量的MSCRFEC方案本章節定義了用于其中源分組各自攜帶唯一序號的單個分組流量的FEC保護的替換性FEC方案。稱此類分組流量為"有序流量"。主要示例可以是包含MPEG-2輸送流——其內關于服務的所有數據被復用——的RTP流量的FEC保護。在此情形中，RTP序號可用于導出源FEC分組標識信息。與章節3.1中定義的FEC方案相比，本方案的主要優點是它無論如何不更改源分組。因此，存在不能識別已根據章節3.1中定義的方案更改的源分組的傳承設備時，可使用此FEC方案。在此FEC方案中，章節3.1的方案中源FEC有效載荷ID扮演的角色由序號代替。要被保護的每個流量內的分組的序號應當針對流中的每個分組遞增1。給定有序流量內每個分組的給定源塊內的源分組信息的大小應當相同且是從FEC修復分組的大小導出的，它們對于給定源塊而言還應當是相同大小的。3.2.1格式和碼3.2.1.1FEC對象傳輸信息3.2.1.1.1強制性的此FEC方案是由預定FEC編碼ID來標識的。3.2丄1.2公共的參看章節3.1.1.1.23.2丄1.3方案專用沒有由此FEC方案中定義的方案專用FEC對象傳輸信息。3.2.1.2FEC有效載荷ID3.2.1.2.1源FEC有效載荷ID源FEC有效載荷ID字段未被此FEC方案使用。源分組未被此FEC方案以任何方式更改。3.2.1.2.2修復FEC有效載荷ID在圖8中示出了此FEC方案的修復FEC有效載荷ID格式。在那里，初始序號(流量iISN)是16比特字段，該字段指定了要被包括在此子塊中的第一分組的序號的最低16比特。如果序號少于16比特，則接收到的序號使用零比特來邏輯填充以相應地在長度上形成16比特。編碼碼元ID(ESI)是16比特字段，該字段指示哪些修復碼元被包含在此修復分組內。所提供的ESI是分組中第一修復碼元的ESI。源塊長度(SBL)是16比特字段，該字段是以碼元計的源塊的長度。3.2.2程序此FEC方案使用章節2中定義的框架的程序來構造可應用FEC碼的源塊。除在此定義的程序之外，還應用以下程序。3.2.2.1源FEC分組標識信息的導出源分組的源FEC分組標識信息是從分組的序號以及修復FEC分組中接收到的信息來導出的。源塊是由塊中第一源分組的序號來標識的。在與初始序號字段中的源塊相關聯的所有修復FEC分組中信令此信息。源塊內源分組的源分組信息的長度(以字節計)等于包含該塊的修復分組的編碼碼元的有效載荷的長度(即，不包含修復FEC有效載荷ID)，它們應當全都一樣。碼元中的源分組信息長度(SPIL)等于此長度除以編碼碼元大小(在公共FEC對象傳輸信息中信令)。包括在源塊中的源分組集合是根據初始序號(ISN)和源塊長度(SBL)如下來確定的令，/為源塊的初始序號&為以碼元計的源分組信息長度"為以碼元計的源塊長度然后，具有從/到(并且包含/和)的序號的源分組被包括在源塊中。注意如果沒有FEC修復分組被接收到，則FEC解碼是不可能的，并且無需接收器來標識源分組的源FEC分組標識信息。分組的編碼碼元ID是從以下信息導出的分組的序號Ns源塊的源分組化信息長度LP源塊的初始序號I然后，具有序號Ns的分組的編碼碼元ID是根據以下公式來計算的孤=(4乃丄尸注意與給定源塊相關聯的所有修復分組應當包含相同的源塊長度、源分組信息長度和初始序號。3.2.2.2修復分組編碼碼元ID的導出修復分組的編碼碼元ID指示分組包含哪些修復碼元。這由修復FEC有效載荷ID的編碼碼元ID字段直接給出。3.2.2.3RTP流量的程序隨后，在RTP分組流量的特定情形中，RTP序號字段被用作上述程序中的序號。3.2.3FEC碼規范適用章節3丄3的要求。3.2.3.1示例參數3.2.3丄1參數導出算法推薦使用章節3丄3.3.1的算法。然后，在RTP流攜帶MPEG-2輸送流的情形中，最大修復分組大小應當被設置成P=ceil(("188+15)/力^其中n是每IP源分組188字節TS分組的標稱數目。最大源塊大小是根據發送器處的應用配置來確定的。3.2.3.1.2示例在假定^、/^併和G皿為推薦值的情況下，以上算法導致如以下表4中MPEG-2輸送流的輸送參數<table>tableseeoriginaldocumentpage28</column></row><table>4公共協議元素本章節定義了可結合章節2中定義的框架和章節3中定義的FEC方案使用以構造用于流送媒體的FEC保護的完全協議的多個公共協議元素。4.1FEC反饋協議4.1.1概要本章節規定了用于接收器的任選的簡單協議以在單播流中提供關于FEC數據的接收的反饋。此反饋數據可被發送器用來調節FEC參數。為多組源塊提供關于接收以及解碼成功或失敗的反饋，這些源塊組被稱為'反饋組，。用于接收反饋的能力必須連同應當發送反饋的IP地址和目的UDP端口以及請求反饋的反饋組的請求大小由發送器向接收器來廣告。以"盡力"為基礎提供反饋——發送器不應當依賴于接收反饋消息。在此版本的協議中，提供單個反饋報告消息，該消息在單個反饋組上提供反饋。在每個反饋報告中提供以下信息反饋組中源塊的數目反饋組中接收到的沒有差錯的源塊的數目反饋組中被成功解碼的源塊的數目反饋組中不能被解碼的源塊的數目，反饋組中的任何源塊接收到的最大分組數目，反饋組中的任何源塊接收到的最小分組數目關于該反饋接收到的分組總數4.1.1格式和碼4.1.2.1通用消息格式FEC反饋協議消息伴隨根據圖9格式化的UDP有效載荷通過UDP來發送。在此類消息中，在此版本的協議中，版本字段被設為零(O)。消息類型0x00反饋報告0x01-Oxff保留源塊標識符標識此報告所涉及的組中的第一源塊。如果FEC方案定義源塊號，則此標識符被用作源塊標識符。源塊的數目此報告所及的源塊的數目。有效載荷有效載荷字段的內容取決于消息類型并且在以下定義。4丄2.2消息有效載荷格式在圖10中定義了反饋報告的有效載荷字段的格式。"無差錯"塊的數目指示反饋組中因所有源分組被無差錯地接收到而不要求解碼的源塊的數目。"解碼成功"的塊的數目指示反饋組中要求解碼且成功完成的源塊的數百。"解碼不成功"的塊的數目指示反饋組中要求解碼但因沒有接收到足夠的信息而不能成功完成的源塊的數目。最大接收到的分組指示為反饋組中的任何源塊接收到的最大分組(源和修復)數目。最小接收到的分組指示為反饋組中的任何源塊接收到的最小分組(源和修復)數目。接收到分組總數指示為反饋組中的所有源塊接收到的分組(源和修復)總數。4.1.3程序4.1.3.1FEC發送器程序本章節定義正發送FEC保護的數據并接收FEC反饋協議數據的設備處的程序。4.1.3.1.1概要在發送器處對FEC反饋協議的支持是任選的。發送器在FEC流送配置信息中廣告對FEC反饋協議的支持、所支持的最高版本、消息應當被發送至的IP目的地址和UDP目的端口、以及所請求的反饋組的大小。用于傳達FEC流送配置信息的機制是專用內容遞送協議。FEC發送器可忽略接收到的具有未被承認的版本號的FEC反饋協議分組以及接收到的具有保留消息類型的FEC反饋協議分組。在接收到比預期更長的FEC反饋協議消息的情形中，發送器應當丟棄附加字節并如往常那樣處理消息。4丄3丄2反饋報告消息的接收一旦接收到反饋報告消息，FEC發送器就可基于在反饋報告消息中接收到的信息來為后繼源塊改編FEC參數(源塊大小、發送速率和布置等)。在反饋組的大小為單個源塊的情形中，并且如果反饋報告指示源塊被成功接收到或被成功解碼，且FEC發送器仍在發送源塊的FEC修復分組，則FEC發送器應當停止發送源塊的FEC修復分組。4.1.3.2FEC接收器程序本章節定義了正接收FEC保護的數據并發送FEC反饋協議數據的設備處的程序。4.1.3.2.1概要在接收器處對FEC反饋協議的支持是任選的。如果對FEC反饋協議的支持尚未由FEC發送器廣告，則FEC接收器不應當發送FEC反饋協議消息。如果對FEC反饋協議的支持已由FEC發送器廣告，則FEC接收器可使用FEC流送配置信息中的信息來確定由FEC發送器支持的最高版本、消息應當被發送至的IP目的地址和UDP目的端口、以及反饋組的大小。FEC接收器不應當發送具有比由FEC發送器支持的最高版本高的版本號的FEC反饋協議消息。FEC接收器應當以每個FEC流送框架實例為基礎來確定FEC反饋協議是否將被使用。除未接收到針對其的修復分組的源塊不應當被包括在任何反饋組中之外，反饋組應當包括連續源塊序列。反饋組中源塊的數目應當等于在FEC流送配置信息中指示的所請求的反饋組大小。反饋組中的每個源塊應當被歸類為如在以下章節所述的或者"無差錯"、"解碼成功"或者"解碼不成功"。一旦反饋組中所有源塊的分類被確定，FEC接收器就應當發送反饋報告消息。4.1.3.2.2"無差錯"源塊一旦FEC接收器確定無需對源塊進行FEC解碼，源塊就可被認為是"無差錯，,。4.1.3.2.3"解碼成功"源塊一旦源塊成功解碼，源塊就可被認為是"解碼成功"。4丄3.2.4"解碼未成功"源塊一旦FEC接收器確定對源塊的FEC解碼是必需的但是不可能的，源塊就可被認為是"解碼未成功"。FEC接收器可確定對源塊的FEC解碼是必需的，但在以下情形中是不可能的源塊的至少一個源碼元是未知的，尚未接收到用于解碼源塊的足夠的修復碼元，以及應用要求源碼元(例如，媒體播放器)。FEC接收器可確定對源塊的FEC解碼是必需的，但是在其它時候是不可能的，例如，在由FEC接收器確定的某一時間段內尚未接收到源塊的其它修復碼元的情況下。4.2FEC發送布置在章節2中定義的FEC流送框架沒有規定所傳送的分組的任何布置。本章節描述了可被發送器用來確定流的FEC源和FEC修復分組的發送布置的辦法。4.2.1簡單恒定速率FEC發送本章節描述了每個源塊中FEC源分組和FEC修復分組的發送速率保持恒定的簡單發送布置。對于每個源塊，源分組首先被發送，繼之以修復分組。一個源塊的所有分組在后繼塊的任何分組之前被發送。源塊中的所有數據(源和修復)的發送數據率是恒定的，且由以下公式給出<formula>formulaseeoriginaldocumentpage32</formula>其中R發送是發送速率32Rs是源數據速率D修a是修復數據量(字節，包括分組化開銷)D，是源數據量(字節，包括分組化開銷)4.3確定FEC源塊邊界本章節給出可被發送器用來確定FEC源塊邊界的多個算法。4.3.1基于保護周期在此辦法中，源塊是基于稱為"保護周期"的時間周期來構造的。通常，保護周期對于一個流的每個源塊而言是相同的。然而，它可隨塊的不同而變化。在實時流的情形中，源塊的源分組確切地為在等于保護周期的時間段內到達的那些分組。在預編碼內容的情形中，源塊的源分組確切地為將在等于從該內容產生的非FEC保護流的常規發送布置中的保護周期的時間段內發送的那些分組。在此辦法中，使用章節4.2.1和在別處的發送布置，在接收器處緩沖分組至少與任何源塊的最長播出時間相等的時間。5內容遞送協議本章節利用章節2-4中定義的組件來定義若干完全內容遞送協議。5.1多播MPEG-2輸送流本章節定義了用于MPEG-2輸送流的FEC保護多播遞送的內容遞送協議。5.1.1控制協議會話信息包括每個修復流量的目的UDP端口在多個修復流量層被提供的情況下，每個修復流量的IP多播地址在多個修復流量層被提供的情況下，修復流量的聯結次序FEC對象傳輸信息(最大源塊大小和編碼碼元大小)在接收器處所需的最小緩沖時間MPEG-2TS流量的流量ID為零。5.1.2輸送協議MPEG-2輸送流的FEC保護可使用以下來提供章節2中描述的FEC流送框架章節3.3中定義的FEC方案4.2.1中描述的FEC發送布置4.3.1中描述的FEC源塊邊界標識機制每個MPEG-2輸送流應當被獨立地保護。5.2單播MPEG-2輸送流本章節定義了用于MPEG-2輸送流的FEC保護單播遞送的內容遞送協議。5.2.1控制協議會話信息可包括FEC對象傳輸信息(最大源塊大小和編碼碼元大小)在接收器處所需的最小緩沖時間所請求的FEC反饋組大小(或者在未要求反饋的情況下為零)與單播RTP流量相關聯的修復FEC流量可被發送到端口號較RTP流量被發送至的目的UDP端口大2的目的UDP端口號。MPEG-2TS流量的流量ID為零。如果FEC反饋是由發送器要求并由接收器支持的，則FEC反饋消息可被發送到用作自服務器到接收器的FEC修復流的源地址/端口的地址/UDP端口。5.2.2輸送協議MPEG-2輸送流的FEC保護可使用以下來提供章節2中描述的FEC流送框架章節3.3中定義的FEC方案4.2.1中描述的FEC發送布置4.3.1中描述的FEC源塊邊界標識機制每個MPEG-2輸送流應當被獨立地保護。5.3普通多播視頻本章節定義了用于任意音頻/視頻流(例如，封裝在RTP中的H.264)的的FEC保護多播遞送的內容遞送協議。提供本章節來描述如何可將FEC應用于針對音頻/視頻流在RTP中的直接封裝的DVBIPI手冊的將來擴展。流]5.3.1控制協議會話信息包括每個修復流量的目的UDP端口在多個修復流量層被提供的情況下，每個修復流量的IP多播地址在多個修復流量層被提供的情況下，修復流量的聯結次序FEC對象傳輸信息(最大源塊大小和編碼碼元大小)'IP多播地址、UDP目的端口號和受保護UDP流量(例如，音頻和視頻:)的流量ID。在接收器處所需的最小緩沖時間5.3.2輸送協議音頻/視頻流被假定為由一個或多個UDP流量(很可能為RTP流量)攜帶。這些UDP流量的FEC保護可使用以下來提供章節2中描述的FEC流送框架章節3.1中定義的FEC方案4.2.1中描述的FEC發送布置4.3.1中描述的FEC源塊邊界標識機制5.4普通單播視頻本章節定義了用于任意音頻/視頻流(例如，封裝在RTP中的H.264)的FEC保護單播遞送的內容遞送協議。提供本章節來描述如何可將FEC應用于針對音頻/視頻流在RTP中的直接封裝的DVBIPI手冊的將來擴展。5.4.1控制協議會話信息包括修復流量的目的UDP端口FEC對象傳輸信息(最大源塊大小和編碼碼元大小)UDP目的端口號和受保護UDP流量(例如，音頻和視頻流量)的流量ID。在接收器處所需的最小緩沖時間FEC反饋組大小(或者在未要求FEC反饋的情況下為零)如果FEC反饋是由發送器要求并由接收器支持的，則FEC反饋消息可被發送到用作自服務器到接收器的FEC修復流的源地址/端口的地址/UDP端口。5.4.2輸送協議音頻/視頻流被假定為由一個或多個UDP流量(很可能為RTP流量)攜帶。這些UDP流的FEC保護可使用以下來提供章節2中描述的FEC流送框架章節3.1中定義的FEC方案4.2.1中描述的FEC發送布置4.3.1中描述的FEC源塊邊界標識機制6.FEC流送建議本章節提供了對在DVB環境中使用以上FEC流送協議的某些其它任選建議。6.1多播6丄1分層FEC發送(任選)發送器可為與單個源流相關聯的修復分組廣告一個以上的IP多播地址。發送器應當對每個多播組發送不同修復分組。接收器可聯結任何數目的此類多播組以根據本地差錯率調節接收到的修復分組的速率。然而，應當注意，為了滿足IPTV質量目標，必須接收到足夠的開銷以克服即使相對較少差錯的事件，且由此接收器應當在足夠長的時間段上測量差錯率以便確定所需的修復數據量。6.2單播6.2.1流起始處的源塊構造(任選)源塊邊界應當使用章節4.4.1中定義的保護周期算法來標識。推薦以下算法來確定要在新的流被播出的任何時間(例如，流起始或當使用技巧(trick)模式時)使用的保護周期、FEC開銷和發送速率。此算法將在FEC修復數據與快速緩沖填充數據之間均勻地分配源速率之上的初始可用帶寬。初始可用帶寬可能大于標稱(長期)帶寬或它可以是相等的，但是不應當更小。令，Bmax為可為流所用的初始帶寬(源和FEC)Bnom為流的標稱帶寬(源禾口FEC)BSK;為源帶寬Pinit為初始緩沖延遲Pfinal(Ps后)為目標保護周期P為第i個保護周期，其中i=0，l，...Sinit為初始源發送速率Rinit為初始修復發送速率則，<formula>formulaseeoriginaldocumentpage37</formula>以及，對于所有Z使得<formula>formulaseeoriginaldocumentpage37</formula>則以及對于所有/使得P,>=P>a/對于持續時間小于Pfinal的保護周期，源發送速率應當是Sinit而修復發送速率是Rinit。在此之后，源發送速率應當被縮減至Bsrc。此布置意味著在初始周期期間，源發送速率大于實際源數據速率，由此每個保護周期包含播出將比發送占用更久的數據。結果，可根據以上算法在不使接收器缺乏分組的情況下使后繼保護周期更長。在服務發現信息中廣告的接收器處最小緩沖時間應當為Pinit。6.2.2FEC反饋的使用(任選)可以長期為基礎使用FEC反饋來調節被提供給各個用戶的FEC開銷。然而，應當注意，為了滿足IPTV質量目標，必須提供足夠的開銷以克服即使相對較少差錯的事件，且由此在較短時間段內收集到的反饋數據不足以確定所需的長期開銷。在保護周期顯著長于發送器與接收器之間的IP往返時間的情形下，則單個源塊的反饋組可能要求FEC反饋。在此情形中，反饋報告可用于放棄發送在接收到的指示此源塊已被成功接收到/解碼的報告中的源塊的FEC修復分組。雖然已參照示例性實施例描述了本發明，但是本領域技術人員應當認識到，許多更改是可能的。例如，本文所述的方法和過程可使用硬件組件、軟件組件和/或其任何組合來實現。因而，盡管已參照示例性實施例描述了本發明，但是應當領會，本發明旨在涵蓋落在所附權利要求的范圍內的所有更改和等效方案。權利要求1.一種用于流送數據的通信系統，其中數據被從傳送器流送到接收器，以使得所述接收器可在所述所流送的數據被全部接收到或傳送之前開始使用所述流送的數據，所述傳送器包括用于編碼所述要傳送的數據的前向糾錯(“FEC”)的邏輯，藉此所傳送的流包括數據和FEC信息，并且所述數據是使用比所述接收器的消耗速率大的傳送速率來傳送的。2.—種用于流送數據的通信系統，其中數據被從傳送器流送到接收器，以使得所述接收器可在所述所流送的數據被全部接收到或傳送之前開始使用所述流送的數據，所述傳送器包括用于編碼所述要傳送的數據的前向糾錯("FEC")的邏輯，藉此所傳送的流包括數據和FEC信息；用于定時傳輸以使得至少對于所述傳輸的部分，所述傳送器的輸入速率比所述接收器的消耗速率大的邏輯；以及用于隨流送傳輸的時間改變超額的FEC量和/或輸入速率的邏輯。全文摘要數據是從傳送器流送到接收器，其中流送是在假定接收器將在數據被全部傳送和接收之前開始使用該數據的情況下輸送數據的，并且所流送的數據包括前向糾錯(“FEC”)，且數據消耗速率可變化。傳送器具有輸入速率和傳送速率，且這兩個速率可以是不同的并且可改變。在接收器處，有接收速率(接收器以此速率接收數據)和消耗速率(接收器以此速率用盡數據以進行其輸出)。傳送器使用比消耗速率大的傳送速率進行傳送，并且額外的帶寬可用于FEC保護和緩沖。在某些實施例中，超額速率隨傳輸周期改變。文檔編號H03M13/00GK101405942SQ200780010032公開日2009年4月8日申請日期2007年2月13日優先權日2006年2月13日發明者M·G·盧比,M·沃森申請人:數字方敦股份有限公司