假設在一個多個用戶參與的視頻直播系統中，大部分用戶的網絡都是非常好，但是隻有一兩個用戶用的是3G,4G上網，網絡質量不太好。這種情況下對於發佈方應該如何處理呢？一種比較容易想到的方案就是降低發佈方的視頻碼流，這樣不管網絡好還是網絡不好的用戶都可以流暢觀看視頻了，這種方案有個致命缺陷，大部分網絡好的用戶被少數幾個網絡差的用戶給拖累了。
如上圖所示，發佈方只能發佈低於0.5M的碼流了，白白浪費的其它用戶的10M帶寬。
哪有沒有什麼方案能照顧到網絡好的用戶和網絡差的用戶呢？當然是有的，還不只一種，我們現在先來介紹其中的一種，聯播(Simulcast)技術。顧名思義，聯播就是發佈方同時發佈幾路不同碼流的視頻到服務器（SFU)上來，SFU根據接收方的網絡狀態轉發相應的碼流給接收用戶，上面這種情況如果用聯播技術來解決的話，可以給出以下架構圖：
上圖中發佈方同時發佈9M視頻碼流和0.4M的視頻碼流，這樣就可以同時兼兼顧到網絡好的用戶和網絡差的用戶了。在這裏有些同學可能要問爲什麼不直接發佈10M的碼流和0.5M的碼流呢？哪是因爲我們平時說的多少M的碼流只是編碼好後的裸數據，在網絡傳輸中還要加上rtp頭之類的數據，所有在實際應用中，編碼出來的碼流一般都要比你的實際網絡帶寬低一些。
聯播技術在WebRTC中是如何實現的呢？WebRTC默認是沒有開啓聯播功能的。想要使用聯播功能，首先第一步我們要把他開啓起來，我們把生成的Offer SDP修改一下就好了：
原生的Offer SDP中有這麼一段:
a=ssrc-group:FID 3383221279 2661971602
a=ssrc:3383221279 cname:Yy4JddEmmT7fHiQO
a=ssrc:3383221279 msid:b5da8a66-f103-4828-a9ef-85b08903b9c2 62c5c8ff-ad5e-444e-bf2f-135554e4caa3
a=ssrc:3383221279 mslabel:b5da8a66-f103-4828-a9ef-85b08903b9c2
a=ssrc:3383221279 label:62c5c8ff-ad5e-444e-bf2f-135554e4caa3
a=ssrc:2661971602 cname:Yy4JddEmmT7fHiQO
a=ssrc:2661971602 msid:b5da8a66-f103-4828-a9ef-85b08903b9c2 62c5c8ff-ad5e-444e-bf2f-135554e4caa3
a=ssrc:2661971602 mslabel:b5da8a66-f103-4828-a9ef-85b08903b9c2
a=ssrc:2661971602 label:62c5c8ff-ad5e-444e-bf2f-135554e4caa3
我們修改成這樣
a=ssrc:3383221279 cname:Yy4JddEmmT7fHiQO
a=ssrc:3383221279 msid:b5da8a66-f103-4828-a9ef-85b08903b9c2 62c5c8ff-ad5e-444e-bf2f-135554e4caa3
a=ssrc:3383221279 mslabel:b5da8a66-f103-4828-a9ef-85b08903b9c2 62c5c8ff-ad5e-444e-bf2f-135554e4caa3
a=ssrc:3383221279 label:b5da8a66-f103-4828-a9ef-85b08903b9c2 62c5c8ff-ad5e-444e-bf2f-135554e4caa3
a=ssrc:728565452 cname:Yy4JddEmmT7fHiQO
a=ssrc:728565452 msid:b5da8a66-f103-4828-a9ef-85b08903b9c2 62c5c8ff-ad5e-444e-bf2f-135554e4caa3
a=ssrc:728565452 mslabel:b5da8a66-f103-4828-a9ef-85b08903b9c2 62c5c8ff-ad5e-444e-bf2f-135554e4caa3
a=ssrc:728565452 label:b5da8a66-f103-4828-a9ef-85b08903b9c2 62c5c8ff-ad5e-444e-bf2f-135554e4caa3
a=ssrc:700454278 cname:Yy4JddEmmT7fHiQO
a=ssrc:700454278 msid:b5da8a66-f103-4828-a9ef-85b08903b9c2 62c5c8ff-ad5e-444e-bf2f-135554e4caa3
a=ssrc:700454278 mslabel:b5da8a66-f103-4828-a9ef-85b08903b9c2 62c5c8ff-ad5e-444e-bf2f-135554e4caa3
a=ssrc:700454278 label:b5da8a66-f103-4828-a9ef-85b08903b9c2 62c5c8ff-ad5e-444e-bf2f-135554e4caa3
a=ssrc-group:SIM 3383221279 728565452 700454278
注意紅色標記的這行，在WebRTC代碼中，這表示同時發佈三個視頻流，後面跟的是三個視頻流的SSRC,我們用wireshark抓包看看有沒有生效
從圖中可以看到payload爲102的數據包有三個不同的ssrc,代表聯播生效了。
在WebRTC代碼simulcast.cc中有這樣的代碼
const SimulcastFormat kSimulcastFormats[] = {
{1920, 1080, 3, 5000, 4000, 800},
{1280, 720, 3, 2500, 2500, 600},
{960, 540, 3, 900, 900, 450},
{640, 360, 2, 700, 500, 150},
{480, 270, 2, 450, 350, 150},
{320, 180, 1, 200, 150, 30},
{0, 0, 1, 200, 150, 30}
};
我來介紹一下這些代碼的意思，第一行表示你攝像頭最大分辨率爲1920*1080時，會產生3個視頻流，第一路流分辨率爲1920*1080，最大碼流爲5000kpbs,起始碼流爲4000kpb,最小碼流爲800kbps,第二路流爲960*540，最大碼流爲900kpbs,起始碼流爲900kbps,最小碼流爲600kbps,第三路視頻爲480*270，最大碼流爲450kbps,起始碼流爲350kpbs,最小碼流爲150kbps。其餘分辨率以此內推。
當你是使用的是Native客戶端時，你可以自己修改這些值，配置不同的碼流。如果只是用的網頁版本，哪就沒有辦法了，只能用上述已經配置好的碼流了。
————————————————
版權聲明：本文爲CSDN博主「rtc8_com」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/onlycoder_net/article/details/77189613