轉自：http://blog.csdn.net/Stone_OverLooking/article/details/77752076
繼續上文講解：
3）
標准的RTP頭結構如下所示：
其中第一個字節中的x標志位是否擴展了RTP頭，RTP協議允許用戶自定義的擴展，擴展的字段緊挨上述RTP固定頭。RTP擴展投中承載如下信息：
1).當前包所在的Group組序號，碼流由連續的Group組成，每個Group擁有自己的唯一序號。（僅僅是小范圍的唯一，序號大於255時，計數清零）
2).當前包所在的Group組大小
3).當前包在Group內的位置
RTP頭中的7bit的PT字段標示負載的類型，對於標准類型如音頻AAC、視頻H264其參考值列出在RFC3551中。RTP負載除了音視頻數據外還包冗余包，為此我們指定一個自定義的FEC冗余包類型，這樣方便接收端做區分處理。
發送端對一組待發送的應用層數據進行FEC編碼並RTP打包發送，其流程如下所示：
圖中P1~P8代表外層傳入本模塊的原始媒體數據包，r1~r3代表冗余包。本示例中一個Group有8個媒體包外加3個冗余包組成。當模塊傳入媒體包p時，進行RTP封裝后發出，同時存入模塊內部隊列。當Group的最后一個媒體包P8發送完畢時，
對隊列中存放的各P1~P8進行FEC編碼生成冗余包r1~r3並RTP打包發送。如此循環，直至處理所有輸入數據包，Group與Group之間相互獨立的，他們的大小包數可以不同，比如前一個Group為（8,3）組合，下一個Group可以為（8,4）組合，
我們提供了一種動態冗余度的的模式，支持發送端根據接收端的網絡接收情況動態調整冗余度，已達到最佳的服務質量。比如信道條件較差，接收方丟包率上升，發送端可以調高冗余度，以增強抗丟包能力；反之，如果接收方丟包率很低，
發送端則可以降低冗余度，以節省網絡帶寬，所有的這些處理都封裝到了本模塊中，實現了對用戶透明。
接收端進行FEC解碼以實現丟包數據的恢復，其處理流程如下所示：
本例子中P4媒體包在網絡傳輸過程中丟失，下面說明其接收端FEC解碼的處理流程。
當接收到該Group的P1、P2、P3包時，因為他們沒丟失，可以直接輸出給應用層，如此同時在本地對流緩存一份，以供后續可能的FEC解碼使用（后續Group內若無丟白，則緩存數據清空）。
當收到P5包時，可以根據Group包序號判斷出P4包出現丟失，此時停止本Group數據的輸出，P5存入本地隊列。
當收到P6。。。繼續直至收到r1時，滿足了丟包恢復的條件：
收到的媒體包數+收到的冗余包數 >= Group原始媒體包數
對P1、P2、P3、P5、P6、P7、P8、r1進行FEC解碼處理，得到P4包數據。因為之前已經輸出了P1~P3，此處只需輸出P4~P8.
當繼續收到冗余包r2、r3時，可以直接丟棄。
如果收到的媒體包數加上冗余包數小於Group原始媒體包數，本Group的丟包無法恢復，系統直接按序輸出收到的包。
需要說明：當網絡沒有丟包時，本模塊不會引入延時。當網絡出現丟包時，將不得不等到本組FEC恢復完成后再繼續輸出，因此會引入一定延時，這是FEC的代價之一。