做流媒體自建服務(wù)這么長時間對接mediasoup的時候simulcast和svc這兩個詞幾乎天天見。但說句實(shí)話它們本身不難理解難的是搞明白它們在mediasoup里面到底怎么流轉(zhuǎn)、怎么選路、怎么和帶寬估計(jì)配合。如果你也卡在這一塊這篇文章應(yīng)該能幫你把這塊拼圖補(bǔ)上。這其實(shí)是我們流媒體學(xué)習(xí)之路系列的第7篇前面聊過mediasoup的基礎(chǔ)架構(gòu)、Router/Transport/PipeTransport這些核心概念也梳理過RTP和RTCP的調(diào)協(xié)細(xì)節(jié)。這次我把simulcast和svc放在一起講是因?yàn)樗鼈冊赟FU場景里解決的是同一個問題網(wǎng)絡(luò)帶寬不均衡時怎么給不同的接收端分發(fā)不同質(zhì)量的視頻流。但實(shí)現(xiàn)思路完全不同踩坑姿勢也完全不一樣。1. simulcast與svc兩種不同的視頻分層思路1.1 simulcast多路獨(dú)立編碼接收端按需挑一路simulcast翻譯過來叫“聯(lián)播”本質(zhì)上是發(fā)送端同時編碼產(chǎn)生多路分辨率、碼率、幀率都不相同的視頻流每一路都是獨(dú)立編碼、可單獨(dú)解碼的完整視頻流。比如一個1080p的信號源可以先出三層1080p高層、720p中層、360p低層然后同時往SFU推這三路。在WebRTC和mediasoup里這三路流通過不同的SSRC來區(qū)分同時通過RTP擴(kuò)展頭里的ridRTP Stream ID字段作為每路流的“身份證”。接收端想看清楚一點(diǎn)就問SFU要高層網(wǎng)絡(luò)不好就問SFU要低層切換閾值由應(yīng)用層決定。SFU不做任何轉(zhuǎn)碼只是按需轉(zhuǎn)發(fā)其中的某一層。這樣做的優(yōu)勢非常明顯SFU不需要轉(zhuǎn)碼延遲低、CPU消耗少。各層之間的質(zhì)量差別很穩(wěn)定高層清晰低層流暢。但它也有一個先天短板——帶寬利用效率低。因?yàn)榘l(fā)送端要同時編碼并上推多路流實(shí)際上行帶寬是“各層碼率之和”而不是單一編碼一路。如果在1對1通話場景里接收端只會用到其中一路其他層完全是白白浪費(fèi)。所以業(yè)內(nèi)才有“simulcast費(fèi)上行帶寬”這個說法。1.2 svc一層基礎(chǔ)層疊加增強(qiáng)層按需丟棄部分包SVCScalable Video Coding可伸縮視頻編碼換了一種思路只編碼一路視頻流但這路流內(nèi)部天然分層級。最低層通常叫基礎(chǔ)層base layer只有它才能獨(dú)立解碼圖像質(zhì)量最低、分辨率最低、幀率也最低。在基礎(chǔ)層之上還有若干增強(qiáng)層比如空間增強(qiáng)層可以拉高分辨率時間增強(qiáng)層可以補(bǔ)幀率質(zhì)量增強(qiáng)層可以降量化步長提升畫質(zhì)。SVC在RTP傳輸中的做法是整條流仍然只有一個SSRC和一路RTP包但每個包通過SVC規(guī)范里定義的RTP擴(kuò)展頭比如時間層的tsid、空間層的tlid來標(biāo)識自己屬于哪個層。接收端或SFU拿到包之后可以按層級做篩選丟棄。比如說當(dāng)前網(wǎng)絡(luò)只能撐住基礎(chǔ)層SFU就把所有增強(qiáng)層的包全部丟掉只轉(zhuǎn)發(fā)基礎(chǔ)層的包接收端照樣能解碼出視頻只是分辨率低、畫質(zhì)差點(diǎn)。SVC最大的優(yōu)點(diǎn)是帶寬利用率高因?yàn)榘l(fā)送端只需要編碼一條流增強(qiáng)層的碼率在必要時候才真正被轉(zhuǎn)發(fā)出去不會像simulcast那樣早早上行帶寬全都占滿。它的主要缺點(diǎn)也很現(xiàn)實(shí)編碼器復(fù)雜度高CPU占用比simulcast高不少而且終端支持不統(tǒng)一比如某些客戶端對H.264 SVC壓根不支持VP9和AV1的SVC支持情況也因平臺而異。1.3 二者最本質(zhì)的差異空間冗余的取舍如果用生活化的方式理解simulcast像是一家餐廳同時準(zhǔn)備小份、中份、大份三個獨(dú)立菜品顧客要哪個就給哪個沒點(diǎn)的那份就白白在廚房里放著換菜速度很快。SVC像是一個多層蛋糕第一層是可以單獨(dú)吃的上面的每一層必須疊加在下面才能吃服務(wù)員只會把客人夠得到的部分端上去但蛋糕本體做得更復(fù)雜。從SFU的角度看simulcast轉(zhuǎn)發(fā)的是“獨(dú)立流”的某個分支SVC轉(zhuǎn)發(fā)的是“同一條流”中的部分包。這兩種機(jī)制在媒資系統(tǒng)里都對RTCP帶寬估計(jì)敏感但在mediasoup的具體實(shí)現(xiàn)上有非常大的區(qū)別接下去我會把底層機(jī)制展開講。2. 深入mediasoup的simulcast與svc處理機(jī)制2.1 mediasoup怎么識別分層流mediasoup內(nèi)部設(shè)計(jì)了一套邏輯來統(tǒng)一處理simulcast和SVC。它把每一路可辨識的層抽象成“空間層”Spatial Layer和“時間層”Temporal Layer兩個維度然后用一個Layer集合來跟蹤。對于simulcast發(fā)送端上推的三路獨(dú)立視頻流在mediasoup看來就是三個空間層。每一層有自己的SSRC、獨(dú)立RTP序列號空間和獨(dú)立碼率統(tǒng)計(jì)。時間層的概念在simulcast里也存在比如VP8的動態(tài)時間層、H.264的某些編碼器實(shí)現(xiàn)會在一路流里再做時間分層但simulcast的時間層不像SVC那么突出。對于SVCmediasoup在接收端解析RTP包里的層標(biāo)識擴(kuò)展頭把包歸入不同空間層和時間層。SVC和一個SSRC配對所有層的包都混在這一個流里mediasoup必須通過RTP頭精確區(qū)分。以VP9 SVC為例同一個SSRC的RTP包既可能有空間層0的時間層0也可能有空間層1的時間層1各自對應(yīng)不同的RTP頭擴(kuò)展字段值。mediasoup在做轉(zhuǎn)發(fā)時不是簡單粗暴地把所有包都轉(zhuǎn)發(fā)給consumer而是通過consumer的targetLayer來確定當(dāng)前要轉(zhuǎn)發(fā)的空間層和時間層然后只轉(zhuǎn)發(fā)該層及其下層的包。對simulcast來說如果consumer選了空間層2那mediasoup只轉(zhuǎn)發(fā)空間層2那條SSRC的包。對SVC來說如果consumer選了空間層1時間層1mediasoup需要同時轉(zhuǎn)發(fā)空間層0和空間層1中不高于時間層1的包因?yàn)榭臻g層1的解碼依賴基礎(chǔ)層。2.2 RTP擴(kuò)展頭與SDP協(xié)商分層的“身份證”在這個體系里RTP擴(kuò)展頭是分層的核心標(biāo)識。mediasoup能夠正確識別simulcast和SVC完全取決于發(fā)送端是否在SDP協(xié)商階段帶上對應(yīng)的RTP擴(kuò)展頭并且在實(shí)際的RTP包里填上了正確的值。simulcast場景使用的擴(kuò)展頭主要是urn:ietf:params:rtp-hdrext:sdes:rid也就是我們常說的rid擴(kuò)展頭。發(fā)送端在編碼完三層流之后在每一層的RTP包里把rid字段寫成對應(yīng)的Stream ID。mediasoup拿到SDP時通過arid和asimulcast屬性來重建發(fā)送端的simulcast場景。SDP里simulcast的典型描述長這樣arid:f1 send arid:f2 send arid:f3 send asimulcast:send f1;f2;f3SVC則需要借助其他擴(kuò)展頭比如VP9 SVC里tsid和tlid或者是后來標(biāo)準(zhǔn)的http://www.webrtc.org/experiments/rtp-hdrext/vp9-tl0等。SDP里同樣會通過asvc等屬性來聲明。mediasoup對這些擴(kuò)展頭的解析實(shí)現(xiàn)在自家的RtpStream和Producer里面所以如果你要自定義擴(kuò)展頭不走offer里的擴(kuò)展頭協(xié)商機(jī)制mediasoup是識別不出來的。在WebRTC的常規(guī)協(xié)商流程里SDP的offer和answer都是自動生成的但用戶要確保編碼器設(shè)置正確。你要是配置了simulcast但沒開啟rid那mediasoup收到的還是一路平坦的視頻流根本沒法選層。同理SVC沒帶好層標(biāo)識頭mediasoup也無法感知這是SVC。2.3 WebRTC里的Simulcast流程從瀏覽器到mediasoup正常情況下一個基于mediasoup的WebRTC應(yīng)用瀏覽器端的流轉(zhuǎn)到mediasoup的路徑是這樣的瀏覽器端先用getUserMedia拿到攝像頭流然后通過RTCPeerConnection創(chuàng)建發(fā)送端。這里的關(guān)鍵是addTransceiver或者setParameters的encodings數(shù)組數(shù)組里的每一項(xiàng)就對應(yīng)一個simulcast層。瀏覽器在本地編碼器里會嘗試生成多個編碼層并在SDP里帶著對應(yīng)的rid和simulcast聲明發(fā)出去。mediasoup收到offer之后先是調(diào)協(xié)出公用的RTP能力再根據(jù)SDP信息創(chuàng)建RtpStreamRecv解析出每層的SSRC、rid、碼率參數(shù)然后通知應(yīng)用層“這個Producer有3個空間層”。應(yīng)用層通過router.createProducer創(chuàng)建producer把對應(yīng)的rtpParameters保存下來。這個時候Consumer端來了一個接收者mediasoup會通過RTP參數(shù)協(xié)商為接收者生成一個Consumer。如果接收者網(wǎng)絡(luò)狀況好應(yīng)用層會把Consumer的targetLayer設(shè)置為空間層2如果網(wǎng)絡(luò)不佳設(shè)為空間層1或0。mediasoup收到指令后就只轉(zhuǎn)發(fā)對應(yīng)層所在SSRC的包。整個流程看起來不復(fù)雜但每一環(huán)都有很多細(xì)節(jié)要扣。比如瀏覽器端是否真的開啟了編碼器的多路同時編碼碼率控制模式用的CBR還是VBR關(guān)鍵幀間隔多少都會直接影響后續(xù)的選層體驗(yàn)。3. 實(shí)操把simulcast跑起來3.1 Producer端配置encodings聲明三層在mediasoup中最核心的就是Producer端的encodings配置。我曾經(jīng)在一個自建流媒體服務(wù)項(xiàng)目里把1080p的視頻源做成了三層simulcast當(dāng)時用的mediasoup-client配置如下const producer await sendTransport.produce({ track, encodings: [ { maxBitrate: 1500000, scaleResolutionDownBy: 1 }, { maxBitrate: 500000, scaleResolutionDownBy: 2 }, { maxBitrate: 150000, scaleResolutionDownBy: 4 } ], codecOptions: { videoGoogleStartBitrate: 800 } });這里的scaleResolutionDownBy是mediasoup-client基于原始分辨率做等比縮放的核心參數(shù)。原始1080p第一次不縮放第二次縮小一半成540p第三次縮到270p。實(shí)際跑起來瀏覽器會開啟三個獨(dú)立的編碼器實(shí)例同時工作輸出的三層視頻流在SDP里對應(yīng)三個SSRC、三個rid。如果你的上層應(yīng)用不是瀏覽器而是自研客戶端直接對接mediasoup那rtpParameters要自己手動組織encodings數(shù)組里的每個對象要手動填好rid、maxBitrate、scaleResolutionDownBy等字段。在非瀏覽器環(huán)境里還要特別注意編碼器是否支持多路并發(fā)輸出很多硬編碼器雖然支持simulcast但層數(shù)限制為2層這個時候強(qiáng)行配3層會導(dǎo)致編碼失敗。3.2 Consumer端選層與切層Consumer端在mediasoup里最簡單的選層操作是直接指定空間層和時間層?？蚣軐用鎚ediasoup提供了一套清晰的API比如consumer.setPreferredLayers({ spatialLayer: 1, temporalLayer: 2 })。實(shí)際使用中我們在視頻會議場景里會在每個consumer上監(jiān)聽帶寬估計(jì)事件一旦檢測到接收端下行帶寬充足就把preferredSpatialLayer提高到2讓用戶看到高清畫面帶寬吃緊時先降時間層再降空間層這樣畫面模糊但不會卡頓。在mediasoup的消費(fèi)者選項(xiàng)中也有preferredSpatialLayer和preferredTemporalLayer的初始化參數(shù)配合上面的setPreferredLayers可以在創(chuàng)建consumer時就設(shè)定默認(rèn)層。有一個關(guān)鍵點(diǎn)需要注意mediasoup的consumer選層指令是實(shí)時的但切換的生效時機(jī)取決于關(guān)鍵幀。接收端要從低層切到高層必須等高層那個SSRC產(chǎn)生一個關(guān)鍵幀才可能無損切換。所以很多生產(chǎn)級應(yīng)用會讓編碼器在simulcast三路上周期性產(chǎn)生關(guān)鍵幀避免切層時出現(xiàn)長時間花屏。我們當(dāng)時把關(guān)鍵幀間隔設(shè)在2秒既保證帶寬不太浪費(fèi)又能快速切層。3.3 帶寬估計(jì)與選層策略的配合單純做了simulcast選層還不夠真正讓系統(tǒng)自適應(yīng)網(wǎng)絡(luò)的核心在于帶寬估計(jì)。mediasoup內(nèi)置了transport-cc帶寬估計(jì)機(jī)制它能夠在SFU側(cè)估算出每一條Transport的可用帶寬但默認(rèn)情況下它不會自動幫你切層。切層邏輯需要應(yīng)用層自己實(shí)現(xiàn)。我在實(shí)際項(xiàng)目里是這么做的首先在mediasoup的worker里開啟了transport-cc并且在各個consumer上監(jiān)聽score事件。mediasoup會定期為每個consumer的層評分包括空間層分?jǐn)?shù)、時間層分?jǐn)?shù)和編碼層分?jǐn)?shù)。一旦評分明顯下降說明當(dāng)前層碼率超出了接收端帶寬我會立刻把preferredSpatialLayer降一級再觀察評分是否恢復(fù)。這套邏輯在協(xié)議上依賴RTCP Receiver Report和Transport-CC反饋所以你們要在創(chuàng)建router的時候把enableTcp設(shè)為true同時確保rtcp配置合理。不開啟transport-ccmediasoup照樣能跑simulcast但選層就只能靠拍腦袋了。4. simulcast還是svc我該怎么選4.1 帶寬消耗與計(jì)算對比如果要從帶寬維度做選型必須先搞清楚simulcast和SVC的碼率構(gòu)成。simulcast下發(fā)送端的實(shí)際上行帶寬大約是各層碼率之和。假設(shè)11080p高層2.5Mbps、720p中層1Mbps、360p低層300kbps那上行就是約3.8Mbps。而下行帶寬取決于接收端選中的層。要是三個人同時收高層每人都消耗2.5MbpsSFU的出口就是7.5Mbps。如果是SVC發(fā)送端編碼一條總碼率約3.5Mbps的流上行就是這個數(shù)不需要為每個層單獨(dú)付出完整碼率。下行方面如果要1080pSFU轉(zhuǎn)發(fā)全部約3.5Mbps的包如果只能收360p只需要轉(zhuǎn)發(fā)基礎(chǔ)層的幾百kbps包。同等畫質(zhì)下SVC的總碼率一般能比simulcast節(jié)省20%到40%具體消耗還得看內(nèi)容復(fù)雜度、編碼器實(shí)現(xiàn)和層間相關(guān)度。但對于包含大量會議場景的多人視頻simulcast的上行浪費(fèi)是繞不開的痛。4.2 編碼復(fù)雜度與終端支持再看編碼與終端的適配。simulcast的編碼復(fù)雜度最低因?yàn)槊恳宦肪褪且淮纬Ｒ?guī)編碼多個編碼器并行工作。但編碼器數(shù)量多CPU使用率會上來。好在現(xiàn)代瀏覽器對simulcast的編碼支持已經(jīng)非常成熟主流平臺WebRTC的simulcast都穩(wěn)定。SVC起步晚目前主要在VP9和AV1上表現(xiàn)較好尤其是VP9的SVC模式在很多WebRTC引擎已經(jīng)可用。如果你用的是H.264SVC的支持就慘不忍睹了因?yàn)镠.264 SVC的profile在WebRTC和硬編碼器里基本是被冷落的。所以我做一個產(chǎn)品線建議如果是純WebRTC的會議場景優(yōu)先simulcast它生態(tài)成熟、問題容易排查如果是直播、云轉(zhuǎn)碼或者存儲邊界弱化的場景SVC優(yōu)勢更明顯帶寬利用率高、端到端延遲低。4.3 實(shí)際項(xiàng)目里的選型建議我接手的幾個自建流媒體服務(wù)項(xiàng)目里最后都是simulcast為主力。原因很簡單客戶端的兼容性最穩(wěn)編碼器不用搞復(fù)雜的層級設(shè)置開箱即用。而SVC我更多放在一些對帶寬極其敏感的1對1通話和移動端弱網(wǎng)場景里。如果你新項(xiàng)目要確定方案先從這兩個問題出發(fā)第一你的終端設(shè)備多樣嗎是否有老平臺第二你的瓶頸在上行還是下行。如果上行帶寬寬裕但下行各異simulcast最合適。如果上行本來就不夠且客戶端都能支持VP9/AV1 SVC那SVC值得賭一把。另外mediasoup實(shí)際上支持simulcast和SVC共存你可以讓同一個router里的不同producer用不同模式但為降低排查復(fù)雜度生產(chǎn)環(huán)境建議同一類終端統(tǒng)一切到一種模式。5. 常見問題與排查技巧5.1 simulcast流“選不了層”怎么辦這是我在做mediasoup聯(lián)調(diào)時最常遇到的問題。表現(xiàn)是producer明明跑了三層simulcast但consumer創(chuàng)建后設(shè)preferredSpatialLayer怎么都不生效或者只看到一層。排查順序一般是先看SDP。確認(rèn)offer里有沒有asimulcast:send有沒有rid聲明。如果沒有就能確定發(fā)送端根本沒有協(xié)商好simulcast。其次看mediasoup側(cè)producer的score事件看看各層評分是否都在正常輸出。如果某一層評分特別低可能是那層編碼器沒有產(chǎn)生足夠的關(guān)鍵幀或者碼率設(shè)置太低導(dǎo)致畫面靜止。還有一個容易忽略的細(xì)節(jié)simulcast的編碼器需要手動開啟“關(guān)鍵幀同時生成”功能。部分瀏覽器默認(rèn)只有高層會周期出關(guān)鍵幀低層只在初始時出一次。這種情況下你從高層切到低層沒問題但從低層切回高層就會等待一個很不確定的關(guān)鍵幀周期造成切層后卡片幾秒。建議在編碼器配置里對各層設(shè)置關(guān)鍵幀間隔。5.2 SVC在mediasoup中的限制SVC要跑通除了編碼器支持mediasoup本身也要能識別層信息。在部分mediasoup版本里SVC的consumer創(chuàng)建成功不等于你可以直接選層。你會發(fā)現(xiàn)有些時候設(shè)置preferredSpatialLayer沒有反應(yīng)原因是RTP擴(kuò)展頭沒協(xié)商上比如sdes:rtp-stream-id只對simulcast的rid有效SVC得用tsid和tlid那一套擴(kuò)展頭。所以排查SVC時要重點(diǎn)看協(xié)商出的RTP capabilities里擴(kuò)展頭是否包含SVC相關(guān)的uri。如果終端和mediasoup沒達(dá)成一致那就只能當(dāng)普通單流處理沒有任何分層收益。另外記住SVC不能和simulcast在同一路producer里混用這兩個模式在SDP里是互斥的你聲明了simulcast就別想同時有SVC層標(biāo)識。5.3 切層瞬間的體驗(yàn)優(yōu)化最后分享一個切層體驗(yàn)優(yōu)化的技巧。simulcast切層最怕什么不是切不到而是切了之后糊了很久。這通常是因?yàn)榫幋a器關(guān)鍵幀在切換目標(biāo)層上過慢。我們線上方案是給三層同時開啟如下編碼器選項(xiàng)videoKeyFrameInterval2同時啟動videoKeyFrameForce邏輯在用戶主動切層的指令到達(dá)SFU后通過信令通知瀏覽器那邊的編碼器立刻產(chǎn)生一次關(guān)鍵幀。這樣切層延遲能壓到半秒以內(nèi)。還有一個小技巧是針對Consumer端的緩存在mediasoup里切層前先不要立刻丟棄當(dāng)前層的包讓接收端保持一個關(guān)鍵的緩沖周期等新層的關(guān)鍵幀到達(dá)后再做切換畫面會平滑很多。這個和播放器的追幀策略有點(diǎn)像總的思路就是“先并行后切換”。流媒體這條路學(xué)的時候覺得每個點(diǎn)都懂聯(lián)調(diào)的時候到處都是坑。simulcast和SVC是SFU里最核心的兩個武器選對場景、配置對參數(shù)、做好切層策略整個視頻服務(wù)的體驗(yàn)立馬不一樣。上面這些內(nèi)容都是我在實(shí)際項(xiàng)目里的經(jīng)驗(yàn)總結(jié)希望能幫你少踩幾個坑也歡迎在評論區(qū)交流你們的選型方案。