webrtc 音頻傳輸出了編解碼有fec外，還會根據丟包率額外帶red包來抵抗丟包。
在硬件信道傳輸中，有一種rs_fec （ RS碼即裏德-所羅門碼）的編碼來做糾錯。
本文主要對比red 和rs_fec的特點。
red ：代碼簡單，計算效率高，接收端恢復時主要看丟包時是不是剛好其他接收的包剛好
攜帶了這個包，冗餘程度取決於red的策略，發包數不變。
rs_fec ：代碼複雜，計算量大，接收端恢復時取決rs_fec 的策略，一倍冗餘一個包組隨機丟
一半就能恢復所有的包，冗餘程度包括額外的包頭以及一個包組合的每一個包一樣
長所產生的額外字節，發包數增加。
本文主要提出特點，各種使用場景比如下，希望有條件的同學一起討論：
1、編解碼不同，應該如何選擇？
2、不同丟包場景，哪一種更好？
3、帶寬受限時，哪一種更好？
歡迎大家加音頻算法討論羣：153268894 （作者 zeark）。